Ngân hàng đề — AWS Certified Solutions Architect Professional

Tìm thấy 1221 câu.

Câu 61 Domain - Design for New Solutions

A private bank is hosting a secure web application that allows its agents to view highly sensitive information about the clients. The amount of traffic that the web app will receive is known and not expected to fluctuate. An SSL will be used as part of the application's data security. The chief information security officer (CISO) is concerned about the security of the SSL private key. The CISO wants to ensure that the key cannot be accidentally or intentionally moved outside the corporate environment. The solutions architect is also concerned that the application logs might contain some sensitive information. The EBS volumes used to store the data are already encrypted. In this scenario, the application logs must be stored securely and durably so that they can only be decrypted by authorized employees.

Which of the following is the most suitable and highly available architecture that can meet all of the requirements?

A Distribute traffic to a set of web servers using an Elastic Load Balancer. Use TCP load balancing for the load balancer and configure your web servers to retrieve the SSL private key from a private Amazon S3 bucket on boot. Use another private Amazon S3 bucket to store your web server logs using Amazon S3 server-side encryption.
B
Distribute traffic to a set of web servers using an Elastic Load Balancer that performs TCP load balancing. Use an AWS CloudHSM to perform the SSL transactions and deliver your application logs to a private Amazon S3 bucket using server-side encryption.
C
Distribute traffic to a set of web servers using an Elastic Load Balancer that performs TCP load balancing. Use CloudHSM deployed to two Availability Zones to perform the SSL transactions and deliver your application logs to a private Amazon S3 bucket using server-side encryption.
D Distribute traffic to a set of web servers using an Elastic Load Balancer. To secure the SSL private key, upload the key to the load balancer and configure the load balancer to offload the SSL traffic. Lastly, write your application logs to an instance store volume that has been encrypted using a randomly generated AES key.

Xem giải thích

Đáp án

C — Phân phối lưu lượng qua Elastic Load Balancer làm TCP load balancing; dùng CloudHSM triển khai ở HAI Availability Zone để thực hiện các giao dịch SSL; và ghi log ứng dụng vào bucket S3 riêng tư có mã hoá phía máy chủ.

Vì sao đúng

Đề nêu ba yêu cầu, và chi tiết quyết định nằm ở yêu cầu về khoá riêng: | Yêu cầu | Cách đáp ứng | |---|---| | Khoá riêng SSL KHÔNG được rời khỏi môi trường | CloudHSM — khoá không xuất ra được | | Sẵn sàng cao | CloudHSM ở HAI AZ | | Log lưu an toàn, chỉ người có quyền giải mã | S3 riêng tư + SSE-KMS |

⚠ CloudHSM là dịch vụ duy nhất bảo đảm khoá KHÔNG BAO GIỜ rời khỏi phần cứng:

ACM: AWS quản lý khoá, bạn không thấy nó
    → nhưng cũng không kiểm soát được
        ↓
CloudHSM: khoá sinh ra và nằm TRONG HSM
    → không xuất ra được dưới bất kỳ hình thức nào
    → kể cả AWS cũng không truy cập được
        ↓
    Đây chính là yêu cầu của CISO

⚠ Và "hai Availability Zone" là điều làm C thắng B:

Một HSM đơn lẻ: hỏng là mất khả năng
                thực hiện giao dịch SSL
        ↓
    Cụm CloudHSM ở hai AZ: tự nhân bản khoá
    → mất một HSM vẫn phục vụ được

Dựng cụm CloudHSM:

aws cloudhsmv2 create-cluster \
  --hsm-type hsm1.medium \
  --subnet-ids subnet-a subnet-b

aws cloudhsmv2 create-hsm --cluster-id cluster-abc \
  --availability-zone ap-southeast-1a
aws cloudhsmv2 create-hsm --cluster-id cluster-abc \
  --availability-zone ap-southeast-1b

⚠ TCP load balancing là bắt buộc khi HSM giữ khoá:

ELB kết thúc TLS: cần khoá riêng ở ELB
    → khoá phải rời khỏi HSM
        ↓
    TCP passthrough: ELB chuyển tiếp byte thô
    → máy chủ web bắt tay TLS với HSM
    → khoá không bao giờ rời HSM

Máy chủ web dùng HSM qua SSL offload:

Cài CloudHSM client trên máy web
    → cấu hình NGINX/Apache dùng
      engine PKCS#11 của CloudHSM
        ↓
    Mọi phép ký RSA diễn ra TRONG HSM
    → máy web chỉ nhận kết quả

Log an toàn:

aws s3api put-bucket-encryption --bucket log-ung-dung \
  --server-side-encryption-configuration '{
    "Rules":[{"ApplyServerSideEncryptionByDefault":{
      "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"<arn-khoa>"},
      "BucketKeyEnabled":true}]}'

⚠ SSE-KMS cho phép kiểm soát "chỉ vài người giải mã được":

{"Sid": "ChiChoPhepNguoiDuocChon",
 "Effect": "Allow",
 "Principal": {"AWS": [
   "arn:aws:iam::123456789012:role/QuanTriBaoMat"]},
 "Action": ["kms:Decrypt"],
 "Resource": "*"}

Có s3:GetObject nhưng không có kms:Decrypt
    → tải object về được nhưng KHÔNG đọc được
        ↓
    Đây chính là "chỉ vài người dùng chủ chốt
      mới giải mã được"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Khoá riêng không bao giờ rời phần cứng | | | Cụm HSM hai AZ cho sẵn sàng cao | | | Log mã hoá, kiểm soát bằng key policy | |

Vì sao các phương án khác sai

**B. ELB TCP + CloudHSM (không nói số AZ) + S3 SSE — đây là phương án gần nhất và hầu như giống hệt C, nhưng nó không nói tới việc triển khai HSM ở nhiều AZ; đề yêu cầu "highly available architecture", và một HSM đơn lẻ là điểm hỏng duy nhất.
**A. Máy chủ web lấy khoá riêng từ bucket S3 riêng tư khi khởi động — khoá riêng nằm trong S3 và được tải xuống máy web nghĩa là nó đã rời khỏi môi trường được kiểm soát; vi phạm thẳng yêu cầu của CISO.
**D. Tải khoá lên load balancer và ghi log vào instance store — tải khoá lên ELB là đưa nó ra khỏi tầm kiểm soát; và instance store mất dữ liệu khi máy dừng, không đáp ứng "durably".

Ghi nhớ

⚠ KMS vs CloudHSM — bảng phải thuộc: | Tiêu chí | KMS | CloudHSM | |---|---|---| | Quản lý | AWS | bạn | | Chứng nhận | FIPS 140-2 Level 3 (HSM đơn) | Level 3, cụm riêng | | Khoá dùng chung phần cứng | có (multi-tenant) | KHÔNG (single-tenant) | | Chi phí | ~1 USD/khoá/tháng | hàng nghìn USD/tháng | | Tích hợp dịch vụ AWS | gốc | qua custom key store |

⚠ Chọn CloudHSM khi:

Quy định bắt buộc HSM CHUYÊN DỤNG
    → hoặc cần kiểm soát vật lý khoá
    → hoặc cần SSL offload trong HSM
        ↓
    Còn lại: KMS rẻ hơn và ít việc hơn nhiều

Từ khoá nhận diện:

"private key must never leave the environment" → CloudHSM "free auto-renewing TLS certificate" → ACM "encrypt data at rest with my key" → KMS "only a few people can decrypt" → KMS key policy

Ba loại load balancing với TLS: | Cách | Khoá ở đâu | |---|---| | TLS termination ở ALB | ở ACM/ALB | | TCP passthrough (NLB/CLB) | ở máy chủ backend hoặc HSM | | TLS termination ở NLB | ở ACM/NLB |

⚠ Chỉ TCP passthrough giữ được khoá ở HSM:

Kết thúc TLS ở load balancer
    → load balancer PHẢI có khoá riêng
        ↓
    Muốn khoá ở HSM: load balancer chỉ được
      chuyển tiếp byte thô

Ba lưu ý về CloudHSM: | Lưu ý | Chi tiết | |---|---| | Tối thiểu 2 HSM cho sản xuất | | | Đặt ở các AZ khác nhau | | | AWS KHÔNG khôi phục được khoá nếu mất | |

⚠ Trách nhiệm sao lưu thuộc về bạn:

Mất mọi HSM trong cụm và không có backup
    → khoá mất vĩnh viễn
        ↓
    CloudHSM tự sao lưu cụm
    → nhưng phải hiểu và kiểm chứng quy trình khôi phục

Ba lưu ý về CloudHSM custom key store: | Lưu ý | Chi tiết | |---|---| | KMS dùng CloudHSM làm nơi giữ khoá | | | Có API tiện lợi của KMS + phần cứng riêng | | | Cần cụm ít nhất 2 HSM | |

aws kms create-custom-key-store \
  --custom-key-store-name kho-khoa-rieng \
  --cloud-hsm-cluster-id cluster-abc \
  --trust-anchor-certificate file://customerCA.crt \
  --key-store-password <mat-khau>

⚠ Đây thường là lựa chọn tốt nhất khi cần cả hai:

Yêu cầu HSM chuyên dụng
    + muốn tích hợp gốc với S3, EBS, RDS
        ↓
    Custom key store cho cả hai

Ba lưu ý về mã hoá log: | Lưu ý | Chi tiết | |---|---| | SSE-KMS để kiểm soát ai giải mã | | | Bật S3 Bucket Key giảm phí KMS | | | CloudTrail ghi mọi lần dùng khoá | |

Ba lưu ý về độ bền của log: | Lưu ý | Chi tiết | |---|---| | S3 có độ bền 11 số 9 | | | Instance store MẤT khi máy dừng | | | Bật versioning chống ghi đè nhầm | |

Ba lưu ý về Object Lock: | Lưu ý | Chi tiết | |---|---| | Chế độ Compliance chống xoá tuyệt đối | | | Phải bật lúc TẠO bucket | | | Hợp cho log cần lưu theo quy định | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | HSM có giới hạn phép ký mỗi giây | | | Đề nói lưu lượng biết trước và ổn định | | | Ước lượng số HSM cần theo tải TLS | |

⚠ Đây là chi tiết đề đã cho sẵn:

"Amount of traffic is known and not expected
 to fluctuate"
        ↓
    Tính được số HSM cần
    → và không lo về co giãn đột ngột

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra cụm có HSM ở hai AZ | | | Thử tắt một HSM, xem còn phục vụ | | | Thử đọc log bằng vai trò không có kms:Decrypt | |

aws cloudhsmv2 describe-clusters \
  --query "Clusters[0].Hsms[].[HsmId,AvailabilityZone,State]" \
  --output table

Và một lời khuyên: hãy luôn triển khai ít nhất hai HSM ở hai vùng sẵn sàng khác nhau. CloudHSM bảo vệ khoá tuyệt đối, nhưng chính sự tuyệt đối đó khiến việc mất cụm trở thành thảm hoạ không đảo ngược — và một HSM đơn lẻ vừa là điểm hỏng dịch vụ vừa là rủi ro mất khoá.

Câu 62 Domain - Continuous Improvement for Existing Solutions

A company processes several petabytes of images submitted by users on their photo hosting site every month. Each month, the images are processed in its on-premises data center by a High-Performance Computing (HPC) cluster with a capacity of 5,000 cores and 10 petabytes of data. Processing a month’s worth of images by thousands of jobs running in parallel takes about a week and the processed images are stored on a network file server, which also backups the data to a disaster recovery site.

The current data center is nearing its capacity so the users are forced to spread the jobs within the course of the month. This is not ideal for the requirement of the jobs, so the Solutions Architect was tasked to design a scalable solution that can exceed the current capacity with the least amount of management overhead while maintaining the current level of durability.

Which of the following solutions will meet the company's requirements while being cost-effective?

A
Using a combination of On-demand and Reserved Instances as Task Nodes, create an EMR cluster that will use Spark to pull the raw data from an Amazon S3 bucket. List the jobs that need to be processed by the EMR cluster on a DynamoDB table. Store the processed images on a separate Amazon S3 bucket.
B
Utilize AWS Batch with Managed Compute Environments to create a fleet using Spot Instances. Store the raw data on an Amazon S3 bucket. Create jobs on AWS Batch Job Queues that will pull objects from the Amazon S3 bucket and temporarily store them to the EC2 EBS volumes for processing. Send the processed images back to another Amazon S3 bucket.
C
Package the executable file for the job in a Docker image stored on Amazon Elastic Container Registry (Amazon ECR). Run the Docker images on Amazon Elastic Kubernetes Service (Amazon EKS). Auto Scaling can be handled automatically by EKS. Store the raw data temporarily on Amazon EBS SC1 volumes and then send the images to an Amazon S3 bucket after processing.
D
Create an Amazon SQS queue and submit the list of jobs to be processed. Create an Auto Scaling Group of Amazon EC2 Spot Instances that will process the jobs from the SQS queue. Share the raw data across all the instances using Amazon EFS. Store the processed images in an Amazon S3 bucket for long term storage.

Xem giải thích

Đáp án

B — Dùng AWS Batch với Managed Compute Environment tạo đội máy trên Spot Instance; lưu dữ liệu thô trên S3; tạo job trong Batch Job Queue kéo object từ S3, xử lý tạm trên EBS rồi đẩy ảnh đã xử lý trở lại S3.

Vì sao đúng

Đề nêu bốn yêu cầu, và AWS Batch khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Hàng nghìn job chạy song song | Batch điều phối hàng nghìn job | | Vượt năng lực hiện tại (5.000 core) | Spot Fleet mở rộng gần như không giới hạn | | CÔNG QUẢN LÝ ÍT NHẤT | Managed Compute Environment — AWS lo hạ tầng | | Giữ độ bền hiện tại và tiết kiệm | S3 11 số 9 + Spot giảm tới 90% |

⚠ AWS Batch được thiết kế đúng cho bài toán "hàng nghìn job song song":

Tự dựng bằng SQS + ASG:
    → phải tự viết logic lấy việc, thử lại,
      theo dõi tiến độ, xử lý phụ thuộc
        ↓
    Batch: khai job definition và job queue
    → nó lo xếp hàng, cấp máy, thử lại, dọn dẹp

Dựng compute environment với Spot:

aws batch create-compute-environment \
  --compute-environment-name moi-truong-xu-ly-anh \
  --type MANAGED --state ENABLED \
  --compute-resources '{
    "type":"SPOT",
    "allocationStrategy":"SPOT_CAPACITY_OPTIMIZED",
    "minvCpus":0,"maxvCpus":20000,"desiredvCpus":0,
    "instanceTypes":["optimal"],
    "subnets":["subnet-a","subnet-b","subnet-c"],
    "securityGroupIds":["sg-abc"],
    "instanceRole":"ecsInstanceRole",
    "bidPercentage":80}'

⚠ minvCpus: 0 là chi tiết tiết kiệm quan trọng nhất:

Không có job nào chờ
    → Batch thu về 0 máy
    → KHÔNG tốn tiền tính toán
        ↓
    Có job → tự cấp máy trong vài phút

⚠ Và SPOT_CAPACITY_OPTIMIZED giảm rủi ro bị lấy lại: | Chiến lược | Ưu tiên | |---|---| | SPOT_CAPACITY_OPTIMIZED | pool có nhiều năng lực nhất | | SPOT_PRICE_CAPACITY_OPTIMIZED | cân bằng giá và năng lực — tốt nhất | | BEST_FIT_PROGRESSIVE | On-Demand |

⚠ Xử lý ảnh là tải LÝ TƯỞNG cho Spot:

Mỗi ảnh là một job độc lập
    → máy bị lấy lại giữa chừng
    → job đó được thử lại trên máy khác
        ↓
    Không mất dữ liệu, chỉ mất thời gian của một job

Job definition với thử lại:

{"jobDefinitionName": "xu-ly-anh",
 "type": "container",
 "containerProperties": {
   "image": "<id>.dkr.ecr.ap-southeast-1.amazonaws.com/xu-ly-anh:1.0",
   "vcpus": 4, "memory": 8192,
   "jobRoleArn": "<arn-role>"},
 "retryStrategy": {
   "attempts": 5,
   "evaluateOnExit": [
     {"onStatusReason": "Host EC2*", "action": "RETRY"},
     {"onReason": "*", "action": "EXIT"}]}}

⚠ evaluateOnExit phân biệt lỗi hạ tầng với lỗi ứng dụng:

Máy Spot bị lấy lại → `Host EC2*` → THỬ LẠI
Ảnh hỏng, mã lỗi   → EXIT, không thử lại vô ích
        ↓
    Không phân biệt: job hỏng thật cũng thử 5 lần
    → tốn tiền và che khuất lỗi thật

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không quản lý cụm nào | | | Spot giảm tới 90% chi phí tính toán | | | S3 giữ nguyên độ bền 11 số 9 | |

⚠ S3 thay hệ thống tệp mạng cũng bỏ luôn nhu cầu sao lưu DR:

Trước: file server + backup sang site DR
        ↓
    S3: 11 số 9 độ bền, nhân bản qua 3 AZ
    → thêm CRR nếu cần bảo vệ cấp Region
    → không có máy chủ nào để vận hành

Vì sao các phương án khác sai

**D. SQS + Auto Scaling group Spot + EFS chia sẻ dữ liệu thô — đây là phương án gần nhất và cũng dùng Spot cùng S3 cho kết quả, nhưng nó tự dựng lại AWS Batch: phải tự viết logic lấy việc, thử lại, theo dõi; và EFS cho petabyte dữ liệu thô đắt hơn S3 rất nhiều lần.
**A. Cụm EMR với Spark và danh sách job trong DynamoDB — EMR là công cụ xử lý dữ liệu phân tán (Spark, Hadoop); xử lý ảnh độc lập từng tệp không cần mô hình đó, và cụm EMR là hạ tầng phải quản lý.
**C. Đóng gói Docker và chạy trên EKS — EKS là điều phối container tổng quát, mạnh nhưng công vận hành cao hơn Batch nhiều; và EBS sc1 cho dữ liệu thô là sai loại (HDD chậm, và không chia sẻ được).

Ghi nhớ

⚠ Ba dịch vụ chạy job theo lô — bảng phải thuộc: | Dịch vụ | Khi nào | |---|---| | AWS Batch | hàng nghìn job độc lập, có phụ thuộc, ưu tiên | | ECS/EKS | dịch vụ chạy liên tục, hoặc job đơn giản | | Lambda | dưới 15 phút, sự kiện | | EMR | xử lý dữ liệu phân tán (Spark, Hive) |

Từ khoá nhận diện:

"thousands of parallel jobs, least management" → AWS Batch "Spark, Hadoop, distributed data processing" → EMR "event-driven, under 15 minutes" → Lambda "HPC with MPI, tightly coupled" → ParallelCluster + EFA

⚠ Batch vs EMR — khác biệt cốt lõi:

Batch: mỗi job ĐỘC LẬP, không nói chuyện với nhau
    → xử lý ảnh, render, chuyển mã
        ↓
EMR: các node PHỐI HỢP xử lý một tập dữ liệu
    → tổng hợp, join, machine learning phân tán

Ba thành phần của AWS Batch: | Thành phần | Việc | |---|---| | Compute environment | đội máy (Spot hoặc On-Demand) | | Job queue | hàng chờ, có độ ưu tiên | | Job definition | container, tài nguyên, thử lại |

⚠ Nhiều compute environment cho một queue:

{"computeEnvironmentOrder": [
  {"order": 1, "computeEnvironment": "<arn-spot>"},
  {"order": 2, "computeEnvironment": "<arn-on-demand>"}]}

Ưu tiên Spot
    → hết năng lực Spot thì dùng On-Demand
        ↓
    Vừa rẻ vừa bảo đảm job chạy được

Ba lưu ý về Fargate với Batch: | Lưu ý | Chi tiết | |---|---| | Không phải quản lý EC2 nào | | | Fargate Spot giảm tới 70% | | | Giới hạn 16 vCPU và 120 GB mỗi job | |

⚠ Với 5.000 core, EC2 Spot phù hợp hơn Fargate:

Fargate tính phí cao hơn mỗi vCPU
    → ở quy mô hàng nghìn core, khác biệt rất lớn
        ↓
    EC2 Spot rẻ hơn nhiều

Ba lưu ý về array job: | Lưu ý | Chi tiết | |---|---| | Một job definition, hàng nghìn task con | | | AWS_BATCH_JOB_ARRAY_INDEX phân biệt | | | Tới 10.000 phần tử mỗi array job | |

aws batch submit-job --job-name xu-ly-lo-thang-8 \
  --job-queue hang-cho-chinh \
  --job-definition xu-ly-anh \
  --array-properties size=10000

⚠ Array job là cách gửi hàng nghìn job trong một lời gọi:

Gửi từng job một: 10.000 lời gọi API
    → chậm và chạm giới hạn tần suất
        ↓
    Array job: một lời gọi, 10.000 task

Ba lưu ý về lưu trữ tạm: | Lựa chọn | Khi nào | |---|---| | EBS gắn vào máy | mỗi job xử lý riêng | | Instance store NVMe | nhanh nhất, miễn phí | | EFS | cần chia sẻ giữa job |

⚠ Instance store hợp cho scratch của xử lý ảnh:

Tải ảnh từ S3 → xử lý trên NVMe cục bộ → đẩy lên S3
    → dữ liệu tạm mất cũng không sao
        ↓
    IOPS cao nhất, không tốn thêm tiền

Ba lưu ý về S3: | Lưu ý | Chi tiết | |---|---| | Phân tán tiền tố nếu vượt 5.500 GET/giây | | | S3 Transfer Manager cho tải song song | | | Lifecycle chuyển ảnh cũ sang lớp rẻ hơn | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | Số job ở trạng thái RUNNABLE | tồn đọng | | Tỷ lệ job FAILED | | | desiredvCpus thật sự cấp được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | AWS Batch MIỄN PHÍ — chỉ trả tài nguyên | | | Spot giảm tới 90% | | | minvCpus: 0 không tốn khi rảnh | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi array job thử, xem cấp máy | | | Mô phỏng bị lấy lại Spot | | | So thời gian xử lý với hệ thống cũ | |

aws batch describe-jobs --jobs <id> \
  --query "jobs[0].[status,statusReason,attempts]"

Và một lời khuyên: hãy cấu hình evaluateOnExit để phân biệt lỗi hạ tầng với lỗi ứng dụng. Không có nó, một ảnh hỏng sẽ được thử lại năm lần trên năm máy khác nhau — vừa tốn tiền vừa che mất tín hiệu rằng dữ liệu đầu vào mới là thứ có vấn đề.

Câu 63 Domain - Design for New Solutions

A multi-national tech company has multiple VPCs assigned for each of its IT departments. VPC peering has been set up whenever intercommunication is needed between the VPCs. The solutions architect has been instructed to launch a new central database server that can be accessed by the other VPCs of the company using the database.tutorialsdojo.com domain name. This server should only be resolvable and accessible within the associated VPCs since only internal applications will be using the database.

Which of the following options should the solutions architect implement to meet the above requirements?

A
Set up a private hosted zone with a domain name of tutorialsdojo.com and specify the VPCs that you want to associate with the hosted zone. Create an A record with a value of database.tutorialsdojo.com which maps to the IP address of the EC2 instance of your database server. Modify the enableDnsHostNames attribute of your VPC to true and the enableDnsSupport attribute to true
B
Set up a public hosted zone with a domain name of tutorialsdojo.com and specify the VPCs that you want to associate with the hosted zone. Create an A record with a value of database.tutorialsdojo.com which maps to the IP address of the EC2 instance of your database server. Modify the enableDnsHostNames attribute of your VPC to true and the enableDnsSupport attribute to true
C
Set up a public hosted zone with a domain name of tutorialsdojo.com and specify the VPCs that you want to associate with the hosted zone. Create a CNAME record with a value of database.tutorialsdojo.com which maps to the IP address of the EC2 instance of your database server. Modify the enableDnsHostNames attribute of your VPC to false and the enableDnsSupport attribute to false
D
Set up a private hosted zone with a domain name of tutorialsdojo.com and specify the VPCs that you want to associate with the hosted zone. Create an A record with a value of database.tutorialsdojo.com which maps to the Elastic IP address of the EC2 instance of your database server. Modify the enableDnsHostNames attribute of your VPC to true and the enableDnsSupport attribute to false

Xem giải thích

Đáp án

A — Lập private hosted zone với tên miền tutorialsdojo.com và chỉ định các VPC cần gắn; tạo bản ghi A với giá trị database.tutorialsdojo.com trỏ tới địa chỉ IP của EC2 chạy CSDL; và bật thuộc tính enableDnsHostnames của VPC.

Vì sao đúng

Đề nêu ba yêu cầu, và private hosted zone khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Chỉ phân giải và truy cập được TRONG các VPC liên quan | private hosted zone — không lộ ra Internet | | Nhiều VPC đã peering cần dùng chung | gắn nhiều VPC vào một hosted zone | | Trỏ tới máy chủ CSDL | bản ghi A trỏ tới IP riêng tư |

⚠ "Chỉ resolvable trong VPC" là từ khoá loại ngay public hosted zone:

Public hosted zone: bất kỳ ai trên Internet
                    cũng truy vấn được
        ↓
    Lộ ra địa chỉ IP nội bộ của CSDL
    → vi phạm yêu cầu bảo mật

Đây là lý do phương án B và C sai.

Tạo private hosted zone:

aws route53 create-hosted-zone \
  --name tutorialsdojo.com \
  --caller-reference $(uuidgen) \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-a \
  --hosted-zone-config PrivateZone=true

Gắn thêm các VPC khác:

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id <id-zone> \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-b

Tạo bản ghi A:

aws route53 change-resource-record-sets --hosted-zone-id <id-zone> \
  --change-batch '{"Changes":[{
    "Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"database.tutorialsdojo.com","Type":"A","TTL":300,
      "ResourceRecords":[{"Value":"10.0.1.50"}]}}]}'

⚠ Trỏ tới IP RIÊNG TƯ, không phải Elastic IP — đây là lý do D sai:

Elastic IP là địa chỉ CÔNG KHAI
    → máy trong VPC khác gọi tới EIP
    → gói tin đi RA Internet rồi quay lại
        ↓
    Vừa chậm, vừa tốn phí truyền dữ liệu,
      vừa không đi qua peering
        ↓
    IP riêng tư đi thẳng qua VPC peering

Hai thuộc tính VPC bắt buộc:

aws ec2 modify-vpc-attribute --vpc-id vpc-a --enable-dns-support
aws ec2 modify-vpc-attribute --vpc-id vpc-a --enable-dns-hostnames

⚠ Thiếu chúng thì private hosted zone hoàn toàn im lặng:

Không có lỗi, không có cảnh báo
    → mọi truy vấn trả về NXDOMAIN
        ↓
    Kiểm tra chúng TRƯỚC khi tìm nguyên nhân khác

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tên miền không lộ ra Internet | | | Một hosted zone cho mọi VPC | | | Đổi máy chủ chỉ cần đổi bản ghi | |

⚠ Và đây là lý do dùng DNS thay vì cứng hoá IP:

Ứng dụng cứng hoá 10.0.1.50
    → đổi máy CSDL phải sửa mã và triển khai lại
        ↓
    Dùng tên miền: đổi bản ghi A là xong
    → mọi ứng dụng tự theo

Vì sao các phương án khác sai

**D. Private hosted zone nhưng bản ghi A trỏ tới Elastic IP của máy — đây là phương án gần nhất và chỉ sai một chi tiết, nhưng chi tiết đó khiến lưu lượng đi vòng qua Internet thay vì qua VPC peering: chậm hơn, tốn phí hơn, và có thể không tới được nếu security group chỉ mở cho dải riêng tư.
**B. Public hosted zone với bản ghi A — public hosted zone phơi bản ghi ra Internet, vi phạm yêu cầu "chỉ resolvable trong VPC"; và không có khái niệm "gắn VPC" cho public hosted zone.
**C. Public hosted zone với bản ghi CNAME trỏ tới địa chỉ IP — sai hai lần: public hosted zone như trên, và CNAME phải trỏ tới TÊN MIỀN, không phải địa chỉ IP.

Ghi nhớ

⚠ Bốn loại bản ghi hay dùng — bảng phải thuộc: | Loại | Trỏ tới | |---|---| | A | địa chỉ IPv4 | | AAAA | địa chỉ IPv6 | | CNAME | TÊN MIỀN khác — không phải IP | | Alias | tài nguyên AWS — dùng được ở apex |

⚠ CNAME không trỏ được tới IP — đây là ràng buộc của chuẩn DNS, không phải của AWS.

Từ khoá nhận diện:

"resolvable only within VPCs" → private hosted zone "public internet DNS" → public hosted zone "point to an IP address" → bản ghi A "point to ELB/CloudFront at apex" → alias record

Ba lưu ý về private hosted zone: | Lưu ý | Chi tiết | |---|---| | Gắn được nhiều VPC, nhiều Region, nhiều tài khoản | | | VPC phải bật cả hai thuộc tính DNS | | | Xuyên tài khoản cần authorization hai bước | |

⚠ Gắn VPC xuyên tài khoản:

# Ở tài khoản sở hữu hosted zone
aws route53 create-vpc-association-authorization \
  --hosted-zone-id <id-zone> \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-tai-khoan-khac

# Ở tài khoản sở hữu VPC
aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id <id-zone> \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-tai-khoan-khac

Ba lưu ý về VPC peering và DNS: | Lưu ý | Chi tiết | |---|---| | Peering KHÔNG tự cho phân giải DNS | | | Phải gắn VPC vào hosted zone | | | Hoặc bật DNS resolution cho peering | |

aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-abc \
  --requester-peering-connection-options \
    AllowDnsResolutionFromRemoteVpc=true

⚠ Hai cơ chế khác nhau:

Gắn VPC vào hosted zone
    → phân giải bản ghi TRONG hosted zone đó
        ↓
Bật DNS resolution cho peering
    → phân giải tên DNS công khai của AWS
      (như endpoint RDS) thành IP RIÊNG TƯ

Ba lưu ý về máy chủ CSDL trên EC2: | Lưu ý | Chi tiết | |---|---| | Cân nhắc dùng RDS thay vì tự quản lý | | | RDS có endpoint DNS sẵn, tự theo failover | | | Nếu dùng EC2, IP đổi khi thay máy | |

⚠ Đây là điểm yếu của bản ghi A trỏ IP tĩnh:

Máy CSDL bị thay
    → IP mới, bản ghi A vẫn trỏ IP cũ
        ↓
    Phải cập nhật thủ công, hoặc tự động hoá
      bằng Lambda nghe sự kiện EC2
        ↓
    RDS giải quyết chuyện này sẵn

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp = đổi IP có hiệu lực nhanh | | | TTL cao = ít truy vấn hơn, rẻ hơn | | | 300 giây là mức cân bằng thường dùng | |

Ba lưu ý về Route 53 Resolver: | Lưu ý | Chi tiết | |---|---| | Địa chỉ là VPC_CIDR + 2 | | | CHỈ dùng được từ trong VPC đó | | | Inbound endpoint cho truy vấn từ tại chỗ | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Security group của CSDL chỉ mở cho SG ứng dụng | | | CSDL ở subnet riêng tư | | | Không gán Elastic IP cho máy CSDL | |

⚠ Elastic IP cho máy CSDL là rủi ro bảo mật:

Có IP công khai
    → bị quét từ Internet
        ↓
    CSDL nội bộ không cần IP công khai
    → và đề nói rõ "chỉ ứng dụng nội bộ dùng"

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | VPC gắn mỗi hosted zone | 300 | | Bản ghi mỗi hosted zone | 10.000 | | Hosted zone mỗi tài khoản | 500 |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | nslookup từ máy trong mỗi VPC | | | Thử truy vấn từ ngoài Internet | phải không phân giải được | | Kiểm tra hai thuộc tính DNS | |

dig +short database.tutorialsdojo.com
aws route53 get-hosted-zone --id <id-zone> \
  --query "VPCs[].[VPCId,VPCRegion]" --output table

Và một lời khuyên: hãy trỏ bản ghi tới địa chỉ IP riêng tư chứ đừng bao giờ tới Elastic IP cho tài nguyên nội bộ. Elastic IP khiến lưu lượng giữa hai VPC đã peering đi vòng ra Internet — bạn vừa trả tiền truyền dữ liệu, vừa mất độ trễ, vừa để lộ một đường vào mà lẽ ra không nên tồn tại.

Câu 64 Domain - Continuous Improvement for Existing Solutions

A leading financial company is planning to launch its MERN (MongoDB, Express, React, Node.js) application with an Amazon RDS MariaDB database to serve its clients worldwide. The application will run on both on-premises servers as well as Reserved EC2 instances. To comply with the company's strict security policy, the database credentials must be encrypted both at rest and in transit. These credentials will be used by the application servers to connect to the database. The Solutions Architect is tasked to manage all of the aspects of the application architecture and production deployment.

How should the Architect automate the deployment process of the application in the MOST secure manner?

A
Upload the database credentials with a Secure String data type in AWS Systems Manager Parameter Store. Install the AWS SSM agent on all servers. Set up a new IAM role that enables access and decryption of the database credentials from SSM Parameter Store. Associate this role to all on-premises servers and EC2 instances. Use Elastic Beanstalk to host and manage the application on both on-premises servers and EC2 instances. Deploy the succeeding application revisions to AWS and on-premises servers using Elastic Beanstalk.
B
Upload the database credentials with a Secure String data type in AWS Systems Manager Parameter Store. Install the AWS SSM agent on all servers. Set up a new IAM role that enables access and decryption of the database credentials from SSM Parameter Store. Attach this IAM policy to the instance profile for CodeDeploy-managed EC2 instances. Associate the same policy as well to the on-premises instances. Using AWS CodeDeploy, launch the application packages to the Amazon EC2 instances and on-premises servers.
C
Upload the database credentials with key rotation in AWS Secrets Manager. Install the AWS SSM agent on all servers. Set up a new IAM role that enables access and decryption of the database credentials from SSM Parameter Store. Associate this role to all on-premises servers and EC2 instances. Use Elastic Beanstalk to host and manage the application on both on-premises servers and EC2 instances. Deploy the succeeding application revisions to AWS and on-premises servers using Elastic Beanstalk.
D
Upload the database credentials with a Secure String data type in AWS Systems Manager Parameter Store. Install the AWS SSM agent on all servers. Set up a new IAM role that enables access and decryption of the database credentials from SSM Parameter Store. Associate this role to the EC2 instances. Create an IAM Service Role that will be associated with the on-premises servers. Deploy the application packages to the EC2 instances and on-premises servers using AWS CodeDeploy.

Xem giải thích

Đáp án

D — Tải thông tin đăng nhập CSDL lên Systems Manager Parameter Store dạng SecureString; cài SSM Agent trên mọi máy chủ; tạo IAM role cho phép truy cập và giải mã tham số, gắn cho các EC2 instance; và tạo IAM Service Role cho việc triển khai.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Credential mã hoá khi LƯU và khi TRUYỀN | SecureString mã hoá bằng KMS, truyền qua TLS | | Máy tại chỗ VÀ EC2 cùng dùng | SSM Agent chạy được ở cả hai | | Tự động hoá triển khai | CodeDeploy với service role | | An toàn nhất | không có credential nào trong mã |

⚠ SecureString mã hoá bằng KMS và giải mã khi đọc:

aws ssm put-parameter \
  --name /ung-dung/csdl/mat-khau \
  --value "<mat-khau>" \
  --type SecureString \
  --key-id <arn-khoa>

aws ssm get-parameter \
  --name /ung-dung/csdl/mat-khau \
  --with-decryption --query Parameter.Value --output text

⚠ --with-decryption là chỗ IAM kiểm soát ai đọc được:

Có ssm:GetParameter nhưng không có kms:Decrypt
    → lấy được tham số nhưng ở dạng MÃ HOÁ
        ↓
    Hai lớp quyền cho một bí mật

IAM policy cần cả hai quyền:

{"Version": "2012-10-17",
 "Statement": [
  {"Effect": "Allow",
   "Action": ["ssm:GetParameter", "ssm:GetParameters",
              "ssm:GetParametersByPath"],
   "Resource": "arn:aws:ssm:ap-southeast-1:123456789012:parameter/ung-dung/*"},
  {"Effect": "Allow",
   "Action": "kms:Decrypt",
   "Resource": "<arn-khoa>"}]}

⚠ Máy TẠI CHỖ dùng được Parameter Store qua hybrid activation:

aws ssm create-activation \
  --iam-role VaiTroMayLai \
  --registration-limit 50 \
  --default-instance-name may-tai-cho

Máy tại chỗ đăng ký thành managed instance
    → nhận credential tạm từ vai trò đã gắn
        ↓
    Không cần nhúng access key nào
    → đây chính là "an toàn nhất" mà đề hỏi

⚠ Và EC2 dùng instance profile — cũng không có access key:

Instance profile gắn vai trò vào máy
    → SDK tự lấy credential tạm từ IMDS
        ↓
    Cùng một mã ứng dụng chạy được
      ở cả hai môi trường

Service role cho CodeDeploy:

aws iam create-role --role-name VaiTroCodeDeploy \
  --assume-role-policy-document '{"Version":"2012-10-17",
    "Statement":[{"Effect":"Allow",
      "Principal":{"Service":"codedeploy.amazonaws.com"},
      "Action":"sts:AssumeRole"}]}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có credential tĩnh nào trên máy | | | Cùng cơ chế cho tại chỗ và EC2 | | | Parameter Store Standard MIỄN PHÍ | |

⚠ Parameter Store đủ vì đề KHÔNG yêu cầu xoay tự động:

Đề nói: mã hoá at rest và in transit
    → không nói tới xoay khoá
        ↓
    Parameter Store Standard miễn phí
    → Secrets Manager tính ~0,40 USD mỗi secret

Vì sao các phương án khác sai

**A. Parameter Store SecureString, cài SSM Agent, gắn vai trò cho MỌI máy tại chỗ và EC2, dùng Elastic Beanstalk — đây là phương án gần nhất và phần lưu bí mật hoàn toàn đúng, nhưng nó thiếu vai trò cho quá trình triển khai và mô tả kiến trúc triển khai không khớp với việc ứng dụng chạy trên cả máy tại chỗ lẫn EC2 Reserved (Beanstalk chỉ quản lý EC2).
**B. Parameter Store nhưng gắn IAM policy vào instance profile do CodeDeploy quản lý — mô tả lẫn lộn: instance profile là của EC2, còn CodeDeploy dùng service role riêng; và không nói tới máy tại chỗ.
**C. Dùng Secrets Manager có xoay khoá nhưng vai trò lại cấp quyền "giải mã từ SSM Parameter Store" — phương án tự mâu thuẫn: lưu ở Secrets Manager mà cấp quyền cho Parameter Store thì ứng dụng không đọc được gì.

Ghi nhớ

⚠ Secrets Manager vs Parameter Store — bảng phải thuộc: | Tiêu chí | Secrets Manager | Parameter Store | |---|---|---| | Xoay tự động | ✅ | ❌ | | Giá | ~0,40 USD/secret/tháng | Standard MIỄN PHÍ | | Kích thước | 64 KB | 4 KB / 8 KB (Advanced) | | Sinh mật khẩu ngẫu nhiên | ✅ | ❌ | | Nhân bản xuyên Region | ✅ | ❌ |

⚠ Quy tắc chọn:

Đề nói "rotation" hoặc "lifecycle management"
    → Secrets Manager
        ↓
    Đề chỉ nói "encrypted at rest and in transit"
    → Parameter Store đủ và miễn phí

Từ khoá nhận diện:

"encrypted credentials, no rotation mentioned" → Parameter Store SecureString "key rotation, lifecycle management" → Secrets Manager "on-premises servers use AWS services" → hybrid activation + SSM Agent "no static credentials" → IAM role, không phải access key

⚠ Hybrid activation là cách đúng cho máy tại chỗ:

Cách sai: tạo IAM user, sinh access key,
          nhúng vào máy tại chỗ
    → key tồn tại vĩnh viễn, dễ rò rỉ
        ↓
    Hybrid activation: máy nhận credential TẠM
    → tự xoay, thu hồi được ngay

Ba lưu ý về Parameter Store: | Lưu ý | Chi tiết | |---|---| | Tổ chức theo đường dẫn phân cấp | | | GetParametersByPath lấy cả nhánh | | | Standard miễn phí, Advanced có phí | |

aws ssm get-parameters-by-path \
  --path /ung-dung/csdl/ --recursive --with-decryption

Ba lưu ý về phân cấp đường dẫn: | Đường dẫn | Ý nghĩa | |---|---| | /prod/ung-dung/csdl/mat-khau | môi trường / ứng dụng / thành phần | | IAM policy giới hạn theo tiền tố | | | Dễ tách quyền giữa các môi trường | |

⚠ Giới hạn quyền theo đường dẫn:

{"Effect": "Allow", "Action": "ssm:GetParameter*",
 "Resource": "arn:aws:ssm:*:*:parameter/prod/ung-dung/*"}

Ứng dụng sản xuất không đọc được tham số của dev
    → và ngược lại

Ba lưu ý về IMDS: | Lưu ý | Chi tiết | |---|---| | Bắt buộc IMDSv2 | | | Đặt hop limit = 1 | | | Chặn container truy cập IMDS | |

aws ec2 modify-instance-metadata-options \
  --instance-id i-abc --http-tokens required \
  --http-put-response-hop-limit 1

Ba lưu ý về CodeDeploy: | Lưu ý | Chi tiết | |---|---| | Service role cho CodeDeploy | | | Instance profile cho máy đích | | | Hỗ trợ cả EC2 và máy tại chỗ | |

⚠ CodeDeploy triển khai được lên máy tại chỗ:

Đăng ký máy tại chỗ vào CodeDeploy
    → cùng deployment group với EC2
        ↓
    Một pipeline cho cả hai môi trường

Ba lưu ý về mã hoá khi truyền: | Lưu ý | Chi tiết | |---|---| | Gọi API AWS luôn qua HTTPS | | | Kết nối tới RDS phải bật SSL | | | rds.force_ssl=1 ở parameter group | |

⚠ Đề nói "encrypted in transit" — phải bật cả hai vế:

Lấy credential: HTTPS (tự động)
Dùng credential kết nối CSDL: phải bật SSL
        ↓
    Quên vế thứ hai là mật khẩu đi trên dây dạng thô

Ba lưu ý về lựa chọn tốt hơn nữa: | Cách | Chi tiết | |---|---| | IAM database authentication | không có mật khẩu nào cả | | --manage-master-user-password của RDS | tự tạo và xoay | | RDS Proxy | giữ credential, gộp kết nối |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi GetParameter | | | Cảnh báo khi có truy cập bất thường | | | Parameter Store có lịch sử phiên bản | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đọc tham số từ máy tại chỗ | | | Thử bằng vai trò không có kms:Decrypt | | | Kiểm tra không có access key nào trên máy | |

aws ssm describe-instance-information \
  --query "InstanceInformationList[].[InstanceId,PingStatus,ResourceType]" \
  --output table

Và một lời khuyên: hãy dùng hybrid activation cho máy tại chỗ thay vì tạo IAM user và access key. Access key nhúng vào máy chủ là loại credential tồn tại vĩnh viễn và không ai nhớ xoay — còn credential tạm từ vai trò thì tự hết hạn, và thu hồi được ngay bằng một thao tác.

Câu 65 Domain - Continuous Improvement for Existing Solutions

An accounting firm hosts a mix of Windows and Linux Amazon EC2 instances in its AWS account. The solutions architect has been tasked to conduct a monthly performance check on all production instances. There are more than 200 On-Demand EC2 instances running in their production environment and it is required to ensure that each instance has a logging feature that collects various system details such as memory usage, disk space, and other metrics. The system logs will be analyzed using AWS Analytics tools and the results will be stored in an S3 bucket.

Which of the following is the most efficient way to collect and analyze logs from the instances with minimal effort?

A
Set up and configure a unified CloudWatch Logs agent in each On-Demand EC2 instance which will automatically collect and push data to CloudWatch Logs. Analyze the log data with CloudWatch Logs Insights.
B
Set up and install AWS Inspector Agent on each On-Demand EC2 instance which will collect and push data to CloudWatch Logs periodically. Set up a CloudWatch dashboard to properly analyze the log data of all instances.
C
Set up and install the AWS Systems Manager Agent (SSM Agent) on each On-Demand EC2 instance which will automatically collect and push data to CloudWatch Logs. Analyze the log data with CloudWatch Logs Insights.
D
Enable the Traffic Mirroring feature and install AWS CDK on each On-Demand EC2 instance. Create a custom daemon script that would collect and push data to CloudWatch Logs periodically. Set up CloudWatch detailed monitoring and use CloudWatch Logs Insights to analyze the log data of all instances.

Xem giải thích

Đáp án

A — Cài và cấu hình unified CloudWatch agent trên từng máy EC2 để tự động thu thập và đẩy dữ liệu lên CloudWatch Logs; phân tích bằng CloudWatch Logs Insights.

Vì sao đúng

Đề nêu ba yêu cầu, và unified agent là công cụ duy nhất đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Thu thập bộ nhớ, dung lượng đĩa, và metric hệ thống | CloudWatch KHÔNG tự thấy được chúng | | Cả Windows lẫn Linux | unified agent chạy trên cả hai | | Phân tích bằng công cụ của AWS | Logs Insights |

⚠ CloudWatch KHÔNG tự thấy bộ nhớ và dung lượng đĩa:

Metric mặc định của EC2 lấy từ HYPERVISOR
    → CPU, mạng, đĩa ở mức thiết bị
        ↓
    Bộ nhớ, swap, dung lượng đĩa còn trống
    → nằm BÊN TRONG hệ điều hành
    → phải cài agent mới đẩy ra được

Cài agent hàng loạt bằng Systems Manager:

aws ssm send-command \
  --document-name "AWS-ConfigureAWSPackage" \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'action=Install,name=AmazonCloudWatchAgent'

Cấu hình thu thập:

{"metrics": {
   "namespace": "UngDung/HeDieuHanh",
   "append_dimensions": {
     "InstanceId": "${aws:InstanceId}",
     "AutoScalingGroupName": "${aws:AutoScalingGroupName}"},
   "metrics_collected": {
     "mem": {"measurement": ["mem_used_percent"]},
     "disk": {"measurement": ["used_percent"], "resources": ["/"]},
     "swap": {"measurement": ["swap_used_percent"]}}},
 "logs": {
   "logs_collected": {"files": {"collect_list": [
     {"file_path": "/var/log/ung-dung/*.log",
      "log_group_name": "/ung-dung/san-xuat",
      "log_stream_name": "{instance_id}"}]}}}}

⚠ Unified agent làm CẢ metric LẪN log — đây là lý do nó thay thế các agent cũ:

Trước: CloudWatch Logs agent (log)
       + monitoring scripts (metric)
       → hai thứ phải cài và bảo trì
        ↓
    Unified agent: một agent, một tệp cấu hình
    → cho cả hai

Truy vấn bằng Logs Insights:

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
| sort @timestamp desc

Đẩy kết quả sang S3:

aws logs create-export-task \
  --log-group-name /ung-dung/san-xuat \
  --from 1725000000000 --to 1725600000000 \
  --destination kho-phan-tich \
  --destination-prefix log/2026-08/

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một agent cho cả metric lẫn log | | | Cấu hình tập trung qua SSM Parameter Store | | | Chạy trên cả Windows và Linux | |

⚠ Quản lý cấu hình tập trung cho 200 máy:

aws ssm put-parameter --name /cloudwatch/cau-hinh-agent \
  --type String --value file://cau-hinh.json --overwrite

aws ssm send-command \
  --document-name "AmazonCloudWatch-ManageAgent" \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'action=configure,mode=ec2,
    optionalConfigurationSource=ssm,
    optionalConfigurationLocation=/cloudwatch/cau-hinh-agent,
    optionalRestart=yes'

Sửa cấu hình ở MỘT chỗ
    → đẩy cho cả 200 máy bằng một lệnh

Vì sao các phương án khác sai

**C. Cài SSM Agent để "tự động thu thập và đẩy dữ liệu lên CloudWatch Logs" — đây là phương án gần nhất và SSM Agent thật sự cần thiết (để cài CloudWatch agent), nhưng bản thân SSM Agent KHÔNG thu thập metric hệ thống; nó chạy lệnh, quản lý bản vá, kiểm kê phần mềm.
**B. Cài Inspector Agent để thu thập và đẩy dữ liệu — Inspector quét lỗ hổng bảo mật (CVE, phần mềm chưa vá); nó không thu thập metric hiệu năng.
**D. Bật Traffic Mirroring, cài AWS CDK trên mỗi máy và viết daemon tuỳ chỉnh — Traffic Mirroring sao chép gói tin mạng, không liên quan tới metric hệ thống; và CDK là framework hạ tầng bằng mã, không phải agent.

Ghi nhớ

⚠ Metric EC2 có sẵn và KHÔNG có sẵn — bảng phải thuộc: | Có sẵn (hypervisor) | KHÔNG có sẵn (cần agent) | |---|---| | CPUUtilization | bộ nhớ (mem_used_percent) | | NetworkIn / NetworkOut | swap (swap_used_percent) | | DiskReadOps / DiskWriteOps | dung lượng đĩa còn trống | | StatusCheckFailed | số tiến trình, kết nối TCP |

⚠ Đây là một trong những câu hỏi hay gặp nhất về CloudWatch.

Từ khoá nhận diện:

"memory, disk space, system-level metrics" → CloudWatch agent "run commands, patch, inventory" → SSM Agent "scan for CVEs" → Inspector "capture network packets" → Traffic Mirroring

⚠ Ba agent hay bị lẫn: | Agent | Việc | |---|---| | CloudWatch agent | metric hệ thống và log | | SSM Agent | chạy lệnh, vá, kiểm kê | | Inspector agent | quét lỗ hổng (nay dùng SSM Agent) |

Cần cả ba? Thực ra chỉ cần hai:
    → SSM Agent (có sẵn trên phần lớn AMI)
    → CloudWatch agent (cài qua SSM)
        ↓
    Inspector hiện dùng SSM Agent, không cần agent riêng

Ba lưu ý về detailed monitoring: | Lưu ý | Chi tiết | |---|---| | Chỉ đổi TẦN SUẤT, không thêm metric | | | 5 phút → 1 phút | | | ~0,30 USD mỗi instance mỗi tháng | |

Ba lưu ý về chi phí custom metric: | Lưu ý | Chi tiết | |---|---| | ~0,30 USD mỗi metric mỗi tháng | | | Mỗi tổ hợp dimension là một metric riêng | | | 200 máy × 10 metric = 600 USD/tháng | |

⚠ Chỉ thu thập metric thật sự dùng để cảnh báo:

Bật hết mọi metric của agent
    → hàng chục metric mỗi máy
        ↓
    Nhân với 200 máy = khoản đáng kể
    → chọn lọc: mem, disk, swap là đủ

Ba lưu ý về Logs Insights: | Lưu ý | Chi tiết | |---|---| | Tính phí theo GB QUÉT | | | Luôn giới hạn khoảng thời gian | | | Lưu truy vấn để dùng lại | |

⚠ Truy vấn không giới hạn thời gian quét toàn bộ log:

Log group giữ 90 ngày, hàng trăm GB
    → một truy vấn quét hết = tốn thật
        ↓
    Luôn chọn khoảng thời gian hẹp

Ba lưu ý về retention: | Lưu ý | Chi tiết | |---|---| | Mặc định giữ VĨNH VIỄN | | | Đặt retention để tránh phí tích tụ | | | Export sang S3 cho lưu trữ dài hạn | |

aws logs put-retention-policy \
  --log-group-name /ung-dung/san-xuat --retention-in-days 30

Ba lưu ý về Log Class: | Lớp | Chi tiết | |---|---| | Standard | đầy đủ tính năng | | Infrequent Access | rẻ hơn ~50% phí nạp | | IA không dùng được với alarm và Live Tail | |

Ba lưu ý về cài agent hàng loạt: | Cách | Chi tiết | |---|---| | SSM Run Command | cài một lần | | SSM State Manager | giữ agent luôn được cài | | Đưa vào AMI | máy mới có sẵn |

⚠ State Manager tốt hơn cài một lần:

aws ssm create-association \
  --name AWS-ConfigureAWSPackage \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'action=Install,name=AmazonCloudWatchAgent' \
  --schedule-expression "rate(1 day)"

Máy mới do ASG tạo tự được cài
    → không phụ thuộc ai nhớ

Ba lưu ý về Windows: | Lưu ý | Chi tiết | |---|---| | Agent thu thập được Performance Counter | | | Và Windows Event Log | | | Cùng một tệp cấu hình JSON | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra agent đang chạy | | | Xem metric xuất hiện trong namespace | | | Chạy truy vấn Logs Insights thử | |

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a status

Và một lời khuyên: hãy chọn lọc metric trước khi triển khai cho 200 máy. CloudWatch tính phí theo từng metric tuỳ chỉnh, và bật toàn bộ những gì agent có thể thu thập sẽ tạo ra một hoá đơn lớn hơn nhiều so với giá trị của những con số mà không ai từng nhìn tới.

Câu 66 Domain - Continuous Improvement for Existing Solutions

A data analytics startup has been chosen to develop a data analytics system that will track all statistics in the Fédération Internationale de Football Association (FIFA) World Cup, which will also be used by other 3rd-party analytics sites. The system will record, store and provide statistical data reports about the top scorers, goal scores for each team, average goals, average passes, average yellow/red cards per match, and many other details. FIFA fans all over the world will frequently access the statistics reports every day and thus, it should be durably stored, highly available, and highly scalable. In addition, the data analytics system will allow the users to vote for the best male and female FIFA player as well as the best male and female coach. Due to the popularity of the FIFA World Cup event, it is projected that there will be over 10 million queries on game day and could spike to 30 million queries over the course of time.

Which of the following is the most cost-effective solution that will meet these requirements?

A
1. Launch a MySQL database in Multi-AZ RDS deployments configuration with Read Replicas.

2. Generate the FIFA reports by querying the Read Replica.

3. Configure a daily job that performs a daily table cleanup.
B
1. Generate the FIFA reports from MySQL database in Multi-AZ RDS deployments configuration with Read Replicas.

2. Set up a batch job that puts reports in an S3 bucket.

3. Launch a CloudFront distribution to cache the content with a TTL set to expire objects daily.
C
1. Launch a MySQL database in Multi-AZ RDS deployments configuration.

2. Configure the application to generate reports from ElastiCache to improve the read performance of the system.

3. Utilize the default expire parameter for items in ElastiCache.
D
1. Launch a Multi-AZ MySQL RDS instance.

2. Query the RDS instance and store the results in a DynamoDB table.

3. Generate reports from DynamoDB table.

4. Delete the old DynamoDB tables every day.

Xem giải thích

Đáp án

B — Sinh báo cáo từ CSDL MySQL Multi-AZ có read replica; dùng batch job đẩy báo cáo lên bucket S3; và dựng CloudFront distribution cache nội dung với TTL hết hạn mỗi ngày.

Vì sao đúng

Đề nêu bốn dữ kiện, và phương án này khớp từng cái: | Dữ kiện | Cách đáp ứng | |---|---| | 10-30 TRIỆU truy vấn mỗi ngày | CloudFront phục vụ từ cache, không chạm CSDL | | Người hâm mộ toàn cầu | edge của CloudFront ở khắp nơi | | Báo cáo là nội dung TĨNH sau khi sinh | cache được rất hiệu quả | | TIẾT KIỆM NHẤT | CSDL chỉ chịu vài truy vấn mỗi ngày |

⚠ Đây là mẫu "tính trước rồi cache" — chìa khoá của bài toán:

30 triệu truy vấn đọc CÙNG một báo cáo
    → nếu mỗi lượt đều truy vấn CSDL
    → cần cụm CSDL khổng lồ
        ↓
    Sinh báo cáo MỘT LẦN, lưu thành tệp tĩnh
    → CloudFront phục vụ 30 triệu lượt
    → CSDL chỉ chạy một truy vấn

Batch job sinh báo cáo:

aws events put-rule --name sinh-bao-cao-hang-ngay \
  --schedule-expression "rate(1 hour)"

aws events put-targets --rule sinh-bao-cao-hang-ngay \
  --targets 'Id=1,Arn=<arn-lambda-sinh-bao-cao>'

Cấu hình CloudFront với TTL một ngày:

{"DefaultCacheBehavior": {
   "TargetOriginId": "s3-bao-cao",
   "ViewerProtocolPolicy": "redirect-to-https",
   "CachePolicyId": "<id-chinh-sach>",
   "Compress": true}}

aws cloudfront create-cache-policy --cache-policy-config '{
  "Name":"cache-bao-cao-mot-ngay",
  "DefaultTTL":86400,"MaxTTL":86400,"MinTTL":86400,
  "ParametersInCacheKeyAndForwardedToOrigin":{
    "EnableAcceptEncodingGzip":true,
    "HeadersConfig":{"HeaderBehavior":"none"},
    "CookiesConfig":{"CookieBehavior":"none"},
    "QueryStringsConfig":{"QueryStringBehavior":"none"}}}'

⚠ Cache key KHÔNG chứa header, cookie hay query string:

Thêm bất kỳ thứ nào vào cache key
    → mỗi biến thể là một bản cache riêng
        ↓
    Tỷ lệ trúng cache sụp đổ
    → và origin chịu tải trở lại

⚠ Read replica tách tải sinh báo cáo khỏi CSDL chính:

Truy vấn tổng hợp thống kê rất nặng
    → chạy trên bản chính làm chậm việc bỏ phiếu
        ↓
    Chạy trên read replica
    → hai tải không cạnh tranh nhau

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | CSDL chỉ chịu vài truy vấn mỗi giờ | | | CloudFront phục vụ hàng chục triệu lượt | | | Chi phí gần như không tăng theo lượt xem | |

⚠ Tính thử chi phí:

30 triệu lượt xem × ~50 KB mỗi báo cáo = ~1,5 TB
    → CloudFront ~0,085 USD/GB ≈ 128 USD
        ↓
    So với việc dựng cụm CSDL chịu 30 triệu truy vấn
    → rẻ hơn hàng chục lần

⚠ Còn tính năng bỏ phiếu thì cần tầng khác:

Bỏ phiếu là thao tác GHI
    → không cache được
        ↓
    Ghi vào CSDL chính (hoặc DynamoDB)
    → và kết quả bỏ phiếu cũng được tổng hợp
      thành báo cáo tĩnh định kỳ

Vì sao các phương án khác sai

**A. Chỉ dùng read replica và truy vấn trực tiếp, kèm job dọn bảng hằng ngày — đây là phương án gần nhất và cũng tách tải đọc, nhưng 30 triệu truy vấn mỗi ngày đánh thẳng vào read replica đòi một cụm rất lớn; không có tầng cache nào.
**C. Dùng ElastiCache với tham số hết hạn mặc định — cache trong bộ nhớ giúp giảm tải CSDL, nhưng mọi lượt xem vẫn phải tới máy chủ ứng dụng ở một Region; không giải quyết được độ trễ toàn cầu, và cụm ElastiCache đủ lớn cho 30 triệu lượt là khoản chi lớn.
**D. Truy vấn RDS rồi lưu kết quả vào DynamoDB, xoá bảng cũ mỗi ngày — thêm một tầng dữ liệu không cần thiết cho nội dung tĩnh; và xoá bảng mỗi ngày là thao tác rủi ro, tốn kém.

Ghi nhớ

⚠ Bốn lớp cache — bảng phải thuộc: | Lớp | Dịch vụ | Phục vụ ai | |---|---|---| | Edge | CloudFront | người dùng toàn cầu | | Ứng dụng | ElastiCache | máy chủ trong VPC | | CSDL | DAX | chỉ DynamoDB | | API | API Gateway cache | phản hồi API |

⚠ Với nội dung ĐỌC NHIỀU, GIỐNG NHAU, CloudFront luôn là lớp đầu tiên:

Cache ở edge: request không rời khỏi châu lục của người dùng
        ↓
    Cache ở ứng dụng: vẫn phải đi tới Region
    → độ trễ cao hơn nhiều cho người ở xa

Từ khoá nhận diện:

"millions of reads of the same content, global" → CloudFront + S3 "reduce database read load in-Region" → ElastiCache hoặc read replica "user-specific data" → không cache được ở edge "write-heavy" → cache không giúp

Ba mẫu "tính trước rồi phục vụ tĩnh": | Mẫu | Ví dụ | |---|---| | Batch sinh báo cáo → S3 → CloudFront | bài này | | Static site generator | blog, tài liệu | | Materialized view trong CSDL | tổng hợp sẵn |

Ba lưu ý về TTL: | Nội dung | TTL | |---|---| | Báo cáo cập nhật hằng ngày | 86.400 giây | | Báo cáo cập nhật mỗi giờ | 3.600 giây | | Tệp có hash trong tên | rất dài |

⚠ Cần cập nhật gấp thì dùng invalidation:

aws cloudfront create-invalidation --distribution-id E1ABCDEF \
  --paths "/bao-cao/*"

1.000 đường dẫn đầu mỗi tháng miễn phí
    → sau đó ~0,005 USD mỗi đường dẫn
        ↓
    Hoặc đổi tên tệp có version
    → không cần invalidation

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Nhân bản bất đồng bộ — có độ trễ | | | Chấp nhận được cho báo cáo | | | Theo dõi ReplicaLag | |

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Standby của RDS KHÔNG phục vụ đọc | | | Multi-AZ là TÍNH SẴN SÀNG | | | Read replica mới là MỞ RỘNG ĐỌC | |

⚠ Aurora gộp hai vai trò này:

Aurora Replica vừa đọc được
              vừa là mục tiêu failover
        ↓
    Một instance, hai lợi ích
    → thường kinh tế hơn RDS cho bài toán này

Ba lưu ý về S3 làm origin: | Lưu ý | Chi tiết | |---|---| | Dùng OAC, giữ bucket riêng tư | | | Bật nén cho JSON và HTML | | | Đặt Content-Type đúng | |

Ba lưu ý về tính năng bỏ phiếu: | Lưu ý | Chi tiết | |---|---| | Ghi không cache được | | | DynamoDB hợp cho ghi tần suất cao | | | Chống bỏ phiếu trùng bằng khoá duy nhất | |

⚠ Bỏ phiếu là bài toán ngược với đọc báo cáo:

Đọc báo cáo: cùng nội dung, cache được
Bỏ phiếu: mỗi lượt là một ghi riêng
        ↓
    Hai tầng khác nhau, hai giải pháp khác nhau

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | CacheHitRate | mục tiêu trên 95% | | OriginRequests | origin chịu bao nhiêu | | RDS DatabaseConnections | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudFront rẻ hơn truyền thẳng từ S3 | | | Price class giới hạn edge để giảm giá | | | S3 lưu báo cáo rất rẻ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo CacheHitRate sau vài ngày | | | Kiểm tra báo cáo cập nhật đúng chu kỳ | | | Theo dõi tải CSDL trong ngày thi đấu | |

Và một lời khuyên: hãy giữ cache key gọn nhất có thể cho nội dung tĩnh. Một header hay cookie thừa trong khoá cache có thể nhân số bản cache lên hàng nghìn lần, và khi đó CDN trở thành một proxy không cache gì — đúng vào ngày thi đấu khi ba mươi triệu người cùng truy cập.

Câu 67 Domain - Design for New Solutions

A company has a hybrid set up for its mobile application. The on-premises data center hosts a 3TB MySQL database server that handles the write-intensive requests from the application. The on-premises network is connected to the AWS VPC with a VPN. On AWS, the serverless application runs on AWS Lambda and API Gateway with an Amazon DynamoDB table used for saving user preferences. The application scales well as more users are using the mobile app. The user traffic is unpredictable but there is an average increase of about 20% each month. A few months into operation, the company noticed the exponential increase of costs for AWS Lambda. The Solutions Architect noticed that the Lambda execution time averages 4.5 minutes and most of that is wait time due to latency when calling the on-premises data MySQL server.

Which of the following solutions should the Solutions Architect implement to reduce the overall cost?

A
1. Provision an AWS Direct Connect connection from the on-premises data
center to Amazon VPC instead of a VPN to significantly reduce the
network latency to the MySQL server.

2. Create a CloudFront distribution with the API Gateway as the origin to
cache the API responses and reduce the Lambda invocations.

3. Convert the Lambda functions to run them on Amazon EC2 Reserved
Instances. Use Auto Scaling on peak time with a combination of Spot
instances to further reduce costs.

4. Configure Auto Scaling on Amazon DynamoDB to automatically adjust
the capacity with user traffic.
B
1. Migrate the on-premises MySQL database server to Amazon RDS for MySQL. Enable Multi-AZ to ensure high availability.

2. Create a CloudFront distribution with the API Gateway as the origin to cache the API responses and reduce the Lambda invocations.

3. Gradually lower the timeout and memory properties of the Lambda functions without increasing the execution time.

4. Configure Auto Scaling on Amazon DynamoDB to automatically adjust the capacity with user traffic and enable DynamoDB Accelerator to cache frequently accessed records.
C
1. Provision an AWS Direct Connect connection from the on-premises data center to Amazon VPC instead of a VPN to significantly reduce the network latency to the MySQL server.

2. Configure caching on the mobile application to reduce the overall AWS Lambda function calls.

3. Gradually lower the timeout and memory properties of the Lambda functions without increasing the execution time.

4. Add an Amazon Elasticache cluster in front of DynamoDB to cache the frequently accessed records.
D
1. Migrate the on-premises MySQL database server to Amazon RDS for MySQL. Enable Multi-AZ to ensure high availability.

2. Configure API caching on Amazon API Gateway to reduce the overall number of invocations to the Lambda functions.

3. Gradually lower the timeout and memory properties of the Lambda functions without increasing the execution time.

4. Configure Auto Scaling on Amazon DynamoDB to automatically adjust the capacity based on user traffic.

Xem giải thích

Đáp án

D — Chuyển CSDL MySQL tại chỗ sang Amazon RDS for MySQL và bật Multi-AZ; cấu hình API caching trên API Gateway để giảm số lần gọi Lambda; và hạ dần timeout cùng bộ nhớ của các hàm Lambda.

Vì sao đúng

Đề chỉ ra chính xác nguyên nhân, và phương án này tấn công đúng nó:

Lambda chạy trung bình 4,5 PHÚT
    → phần lớn là THỜI GIAN CHỜ do độ trễ
      khi gọi MySQL tại chỗ
        ↓
    Lambda tính tiền theo GB-GIÂY
    → trả tiền cho thời gian ngồi chờ mạng

⚠ Đây là chỗ khác biệt cốt lõi giữa D và các phương án dùng Direct Connect:

Direct Connect giảm độ trễ mạng
    → nhưng vẫn là một chuyến đi ra khỏi AWS
        ↓
    Chuyển CSDL VÀO AWS: độ trễ từ hàng chục ms
      xuống dưới một ms
    → thời gian chạy Lambda giảm mạnh nhất

Ba tác động của việc chuyển CSDL: | Tác động | Chi tiết | |---|---| | Thời gian chạy Lambda giảm mạnh | ít GB-giây hơn | | Bỏ được phụ thuộc vào VPN | | | Multi-AZ cho sẵn sàng cao | |

Chuyển bằng DMS ít gián đoạn:

aws dms create-replication-task \
  --replication-task-identifier chuyen-mysql \
  --source-endpoint-arn <arn-mysql-tai-cho> \
  --target-endpoint-arn <arn-rds> \
  --replication-instance-arn <arn-may> \
  --migration-type full-load-and-cdc

⚠ 3 TB là khối lượng cần lập kế hoạch băng thông:

Full load 3 TB qua VPN
    → có thể mất nhiều giờ tới nhiều ngày
        ↓
    CDC bắt kịp thay đổi trong lúc đó
    → cắt chuyển khi độ trễ về 0

Bật API caching:

aws apigateway update-stage --rest-api-id abc123 \
  --stage-name prod \
  --patch-operations \
    op=replace,path=/cacheClusterEnabled,value=true \
    op=replace,path=/cacheClusterSize,value=0.5 \
    op=replace,path=/*/*/caching/enabled,value=true \
    op=replace,path=/*/*/caching/ttlInSeconds,value=300

⚠ API caching cắt thẳng số lần GỌI Lambda:

Cache trúng → API Gateway trả kết quả ngay
    → KHÔNG gọi Lambda
        ↓
    Không gọi = không tính tiền
    → giảm chi phí trực tiếp

Hạ dần timeout và bộ nhớ:

aws lambda update-function-configuration \
  --function-name ham-api --timeout 30 --memory-size 512

⚠ Timeout cao là bẫy chi phí âm thầm:

Timeout 15 phút
    → một lỗi treo kết nối chạy đủ 15 phút
    → rồi mới thất bại
        ↓
    Timeout 30 giây: thất bại nhanh, tốn ít
    → và lỗi lộ ra sớm hơn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thời gian chạy Lambda giảm nhiều lần | | | Số lần gọi Lambda giảm nhờ cache | | | Bỏ được rủi ro của kết nối VPN | |

⚠ Và nhớ dùng RDS Proxy khi Lambda gọi RDS:

aws rds create-db-proxy --db-proxy-name proxy-csdl \
  --engine-family MYSQL --role-arn <arn-role> \
  --auth '[{"AuthScheme":"SECRETS","SecretArn":"<arn-secret>"}]' \
  --vpc-subnet-ids subnet-a subnet-b --require-tls

Lambda mở rộng nhanh hơn RDS chịu được kết nối
    → RDS Proxy gộp kết nối
    → và giữ kết nối qua lúc failover

Vì sao các phương án khác sai

**B. Chuyển CSDL sang RDS Multi-AZ, dựng CloudFront trước API Gateway để cache, và hạ timeout — đây là phương án gần nhất và vế CSDL hoàn toàn đúng, nhưng CloudFront cache cho client ở xa; với API mà mỗi người dùng có dữ liệu riêng thì tỷ lệ trúng cache thấp, và API Gateway caching là công cụ trực tiếp hơn cho việc giảm số lần gọi Lambda.
**A và C. Dựng Direct Connect thay VPN để giảm độ trễ — Direct Connect giảm độ trễ và ổn định hơn VPN, nhưng CSDL vẫn nằm ngoài AWS: độ trễ vẫn cao hơn nhiều lần so với RDS trong cùng VPC, và Direct Connect là khoản chi lớn hàng tháng.

Ghi nhớ

⚠ Ba yếu tố quyết định chi phí Lambda — bảng phải thuộc: | Yếu tố | Ảnh hưởng | |---|---| | Số lần gọi | giảm bằng cache | | Thời gian chạy | giảm bằng cách bỏ thời gian chờ | | Bộ nhớ cấp phát | tính theo GB-giây |

⚠ Lambda tính tiền cả thời gian NGỒI CHỜ:

Hàm chờ 4 phút cho một truy vấn mạng chậm
    → trả tiền đủ 4 phút
        ↓
    Đây là lý do Lambda + phụ thuộc chậm
      là mô hình rất tốn kém

Từ khoá nhận diện:

"Lambda cost high due to wait time" → loại bỏ độ trễ, không chỉ giảm nó "reduce Lambda invocations" → API Gateway caching "Lambda exhausting DB connections" → RDS Proxy "long-running, over 15 minutes" → không dùng Lambda

⚠ Khi nào Lambda KHÔNG phải lựa chọn đúng: | Tình huống | Nên dùng | |---|---| | Chạy quá 15 phút | Fargate, Batch | | Phần lớn thời gian là chờ I/O chậm | sửa nguyên nhân, hoặc dùng Fargate | | Tải đều và rất cao 24/7 | container có thể rẻ hơn |

Ba lưu ý về tối ưu bộ nhớ Lambda: | Lưu ý | Chi tiết | |---|---| | CPU tỷ lệ với bộ nhớ | | | Bộ nhớ lớn hơn có khi RẺ hơn | | | Lambda Power Tuning tìm điểm tối ưu | |

⚠ Nhưng khi bottleneck là CHỜ MẠNG thì tăng bộ nhớ vô ích:

Hàm nặng CPU: tăng bộ nhớ → nhanh hơn → rẻ hơn
        ↓
Hàm chờ I/O: tăng bộ nhớ → vẫn chờ chừng ấy
    → chỉ đắt hơn
        ↓
    Đây chính là tình huống của đề

Ba lưu ý về API Gateway caching: | Lưu ý | Chi tiết | |---|---| | Chỉ REST API có, HTTP API không | | | Tính phí theo cỡ cache mỗi giờ | | | TTL tới 1 giờ | |

⚠ Cache chỉ hiệu quả với dữ liệu DÙNG CHUNG:

Dữ liệu riêng từng người dùng
    → cache key phải chứa định danh
    → tỷ lệ trúng thấp
        ↓
    Kiểm tra tỷ lệ trúng trước khi trả tiền cache

Ba lưu ý về RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Gộp kết nối cho Lambda | | | Giữ kết nối qua lúc failover | | | Tính phí theo vCPU của instance CSDL | |

Ba lưu ý về reserved concurrency: | Lưu ý | Chi tiết | |---|---| | Giới hạn số Lambda chạy đồng thời | | | Bảo vệ CSDL khỏi bị dồn kết nối | | | Cũng là trần chi phí | |

aws lambda put-function-concurrency \
  --function-name ham-api --reserved-concurrent-executions 50

Ba lưu ý về DynamoDB (đề đã dùng): | Lưu ý | Chi tiết | |---|---| | Không có khái niệm kết nối | | | Độ trễ mili giây một chữ số | | | Cân nhắc chuyển thêm dữ liệu sang đó | |

⚠ Nếu chuyển được nhiều hơn sang DynamoDB thì càng tốt:

Đề nói ứng dụng ghi nhiều vào MySQL
    → nếu mô hình dữ liệu cho phép
    → DynamoDB xử lý ghi tần suất cao tốt hơn
        ↓
    Nhưng đó là re-factor, đề không nói tới

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Nhân bản đồng bộ, failover tự động | | | Standby KHÔNG phục vụ đọc | | | Endpoint không đổi khi failover | |

Ba lưu ý về giám sát chi phí: | Việc | Cách | |---|---| | Cost Explorer lọc theo dịch vụ Lambda | | | Xem metric Duration trung bình và p99 | | | Đặt Budget cảnh báo | |

⚠ Metric Duration là chỉ số chi phí trực tiếp:

Duration giảm một nửa
    → hoá đơn Lambda giảm một nửa
        ↓
    Theo dõi nó như theo dõi chi phí

Ba lưu ý về VPN và Direct Connect: | Lưu ý | Chi tiết | |---|---| | VPN qua Internet — độ trễ biến động | | | Direct Connect ổn định nhưng vẫn có độ trễ vật lý | | | Trong cùng VPC luôn nhanh nhất | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo Duration trước và sau khi chuyển CSDL | | | Xem tỷ lệ trúng API Gateway cache | | | So hoá đơn Lambda tháng sau | |

Và một lời khuyên: hãy đo lại Duration trung bình sau khi chuyển cơ sở dữ liệu. Đó là con số duy nhất chứng minh việc chuyển đã giải quyết đúng nguyên nhân — và nếu nó không giảm đáng kể thì thời gian chờ đến từ chỗ khác, không phải từ độ trễ mạng như giả định ban đầu.

Câu 68 Domain - Continuous Improvement for Existing Solutions

A company currently hosts its online immigration system on one large Amazon EC2 instance with attached EBS volumes to store all of the applicants' data. The registration system accepts the information from the user including documents and photos and then performs automated verification and processing to check if the applicant is eligible for immigration. The immigration system becomes unavailable at times when there is a surge of applicants using the system. The existing architecture needs improvement as it takes a long time for the system to complete the processing and the attached EBS volumes are not enough to store the ever-growing data being uploaded by the users.

Which of the following options is the recommended option to achieve high availability and more scalable data storage?

A Upgrade to EBS with Provisioned IOPS as your main storage service and change your architecture to use an SQS queue to distribute the tasks to a group of EC2 instances. Use Auto Scaling to dynamically increase or decrease the group of EC2 instances depending on the length of the SQS queue.
B
Use EBS with Provisioned IOPS to store files, SNS to distribute tasks to a group of EC2 instances working in parallel, and Auto Scaling to dynamically size the group of EC2 instances depending on the number of SNS notifications. Use CloudFormation to replicate your architecture to another region.
C
Upgrade your architecture to use an S3 bucket with cross-region replication (CRR) enabled, as the storage service. Set up an SQS queue to distribute the tasks to a group of EC2 instances with Auto Scaling to dynamically increase or decrease the group of EC2 instances depending on the length of the SQS queue. Use CloudFormation to replicate your architecture to another region.
D
Use SNS to distribute the tasks to a group of EC2 instances. Use Auto Scaling to dynamically increase or decrease the group of EC2 instances depending on the length of the SQS queue.

Xem giải thích

Đáp án

C — Nâng cấp kiến trúc dùng bucket S3 có Cross-Region Replication làm dịch vụ lưu trữ; dựng hàng đợi SQS phân phối tác vụ cho một nhóm EC2 có Auto Scaling theo độ dài hàng đợi; và dùng CloudFormation nhân bản kiến trúc.

Vì sao đúng

Đề nêu ba vấn đề, và phương án này giải quyết cả ba: | Vấn đề | Giải pháp | |---|---| | EBS không đủ chỗ cho dữ liệu ngày càng lớn | S3 — dung lượng không giới hạn | | Hệ thống không dùng được khi có đợt tăng tải | SQS đệm + ASG mở rộng | | Xử lý mất nhiều thời gian | nhiều máy xử lý song song |

⚠ Một máy EC2 lớn là điểm hỏng duy nhất VÀ nút thắt cổ chai:

Một máy xử lý tuần tự
    → đợt hồ sơ dồn tới = xếp hàng dài
        ↓
    Và máy đó hỏng = toàn bộ hệ thống dừng

⚠ SQS biến đợt tăng tải thành hàng đợi, không thành sự cố:

Người nộp hồ sơ → ghi vào S3 → gửi tin nhắn vào SQS
    → trả về ngay cho người dùng
        ↓
    Nhóm EC2 tiêu thụ theo tốc độ của mình
    → đợt tăng làm hàng đợi dài hơn
    → không làm hệ thống ngừng

Mở rộng theo độ sâu hàng đợi:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-xu-ly \
  --policy-name theo-hang-doi \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 10.0,
    "CustomizedMetricSpecification": {
      "MetricName": "SoTinNhanMoiMay",
      "Namespace": "UngDung", "Statistic": "Average"}}'

⚠ Metric phải là "tin nhắn MỖI MÁY", không phải tổng:

Dùng tổng ApproximateNumberOfMessagesVisible
    → thêm máy KHÔNG làm con số đó giảm ngay
    → chính sách cứ thêm mãi tới trần
        ↓
    Chia tổng cho số máy đang chạy
    → đó mới là metric hội tụ được

S3 với Cross-Region Replication:

aws s3api put-bucket-versioning --bucket ho-so-di-tru \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-replication --bucket ho-so-di-tru \
  --replication-configuration '{
    "Role":"<arn-role>",
    "Rules":[{"ID":"nhan-ban-dr","Priority":1,"Status":"Enabled",
      "Filter":{},"DeleteMarkerReplication":{"Status":"Disabled"},
      "Destination":{"Bucket":"arn:aws:s3:::ho-so-di-tru-dr",
        "StorageClass":"STANDARD_IA"}}]}'

⚠ Versioning bật ở CẢ HAI bucket là điều kiện bắt buộc của CRR.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | S3 không bao giờ hết chỗ | | | Xử lý song song, nhanh hơn nhiều | | | Bản sao ở Region khác cho DR | |

⚠ Và S3 có độ bền 11 số 9 — cao hơn EBS:

EBS: 99,8-99,9% độ bền hằng năm
S3:  99,999999999%
        ↓
    Với hồ sơ di trú (giấy tờ pháp lý)
    → khác biệt này rất quan trọng

Vì sao các phương án khác sai

**A. Nâng cấp lên EBS Provisioned IOPS làm kho chính, kèm SQS và ASG — đây là phương án gần nhất và phần SQS + ASG hoàn toàn đúng, nhưng nó giữ EBS làm kho lưu trữ: EBS gắn vào một máy, nhiều máy trong ASG không dùng chung được, và dung lượng vẫn có trần.
**B. Dùng EBS Provisioned IOPS và SNS phân phối tác vụ — SNS là đẩy tức thì, không có bộ đệm: đợt tăng tải vẫn dồn thẳng vào các máy; và không có metric hàng đợi để mở rộng theo.
**D. Dùng SNS phân phối tác vụ và mở rộng theo "độ dài hàng đợi SQS" — tự mâu thuẫn: dùng SNS nhưng lại đo hàng đợi SQS; và không nói gì tới việc thay EBS.

Ghi nhớ

⚠ SQS vs SNS — bảng phải thuộc: | Dịch vụ | Mô hình | Bộ đệm | |---|---|---| | SQS | kéo, MỘT người tiêu thụ mỗi tin | ✅ | | SNS | đẩy, phát tán nhiều người nhận | ❌ |

⚠ Chỉ SQS có bộ đệm — đây là điều làm nó phù hợp cho phân phối tác vụ:

SNS đẩy tin ngay khi có
    → người nhận chậm hoặc chết
    → tin nhắn mất hoặc phải thử lại
        ↓
    SQS: tin nằm trong hàng đợi
    → tiêu thụ theo nhịp, không mất

Từ khoá nhận diện:

"distribute tasks to a group of workers, scale by backlog" → SQS "fan-out to multiple subscribers" → SNS "unlimited scalable storage" → S3 "shared file system for multiple instances" → EFS

⚠ Ba loại lưu trữ và khả năng dùng chung: | Loại | Nhiều máy dùng chung | |---|---| | EBS | KHÔNG (trừ Multi-Attach, cùng AZ) | | EFS | có, qua NFS | | S3 | có, qua API |

Ba lưu ý về mở rộng theo hàng đợi: | Lưu ý | Chi tiết | |---|---| | Dùng "tin nhắn mỗi máy" | | | Thu nhỏ chậm hơn mở rộng | | | Tính cả tin nhắn đang xử lý | |

⚠ Với tác vụ dài, tính cả NotVisible:

Metric chỉ đếm tin nhắn VISIBLE
    → tin đang xử lý không được đếm
        ↓
    ASG tưởng rảnh và thu nhỏ
    → giết máy đang xử lý hồ sơ dở

Ba lưu ý về visibility timeout: | Lưu ý | Chi tiết | |---|---| | Phải LỚN HƠN thời gian xử lý | | | Gia hạn động bằng ChangeMessageVisibility | | | Quá ngắn = xử lý trùng | |

Ba lưu ý về DLQ: | Lưu ý | Chi tiết | |---|---| | Luôn cấu hình | | | maxReceiveCount 5-10 cho tác vụ dài | | | Cảnh báo khi DLQ có tin | |

⚠ maxReceiveCount = 1 biến mọi gián đoạn thành thất bại vĩnh viễn:

Máy bị ASG thay giữa chừng
    → tin nhắn quay lại hàng đợi
        ↓
    maxReceiveCount = 1 → đẩy thẳng sang DLQ
    → dù không có lỗi ứng dụng nào

Ba lưu ý về bảo vệ máy đang xử lý: | Biện pháp | Chi tiết | |---|---| | Lifecycle hook EC2_INSTANCE_TERMINATING | | | Scale-in protection | | | Xử lý SIGTERM để hoàn tất việc | |

Ba lưu ý về S3 cho hồ sơ: | Lưu ý | Chi tiết | |---|---| | Mã hoá SSE-KMS cho dữ liệu cá nhân | | | Bật versioning chống xoá nhầm | | | Object Lock nếu có yêu cầu lưu giữ | |

⚠ Hồ sơ di trú là dữ liệu cá nhân nhạy cảm:

Bật Block Public Access ở cấp tài khoản
    + SSE-KMS với customer managed key
    + CloudTrail data event cho bucket
        ↓
    Và cân nhắc Macie quét PII

Ba lưu ý về CRR: | Lưu ý | Chi tiết | |---|---| | Versioning bật ở CẢ HAI bucket | | | Chỉ nhân bản object MỚI | | | Batch Replication cho object cũ | |

Ba lưu ý về xử lý bất đồng bộ: | Lưu ý | Chi tiết | |---|---| | Trả 202 Accepted cho người nộp | | | Lưu trạng thái để tra cứu tiến độ | | | Thông báo khi xử lý xong | |

⚠ Đây là thay đổi trải nghiệm người dùng đáng nói:

Trước: nộp xong chờ kết quả ngay (và bị treo)
        ↓
    Sau: nộp xong nhận mã hồ sơ
    → tra cứu hoặc nhận email khi có kết quả
    → chịu được đợt tăng tải bất kỳ

Ba lưu ý về Lambda (lựa chọn thay thế): | Lưu ý | Chi tiết | |---|---| | Nếu xử lý dưới 15 phút thì Lambda hợp hơn | | | Không phải quản lý máy nào | | | S3 event hoặc SQS làm nguồn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy tải giả mức đợt cao điểm | | | Theo dõi ApproximateAgeOfOldestMessage | | | Kiểm tra object nhân bản sang Region phụ | |

Và một lời khuyên: hãy mở rộng theo "số tin nhắn mỗi máy" chứ đừng theo tổng tồn đọng. Tổng số tin nhắn không giảm ngay khi bạn thêm máy, nên chính sách dựa trên nó sẽ cứ thêm mãi cho tới khi chạm trần — và bạn có một đội máy khổng lồ giải quyết một hàng đợi vốn đã sắp cạn.

Câu 69 Domain - Design Solutions for Organizational Complexity

The department of education just recently decided to leverage the AWS cloud infrastructure to supplement its current on-premises network. They are building a new learning portal that teaches kids basic computer science concepts and provides innovative gamified courses for teenagers where they can gain higher rankings, power-ups and badges. A Solutions Architect is instructed to build a highly available cloud infrastructure in AWS with multiple Availability Zones. The department wants to increase the application’s reliability and gain actionable insights using application logs. A Solutions Architect needs to aggregate logs, automate log analysis for errors and immediately notify the IT Operations team when errors breached a certain threshold.

Which of the following is the MOST suitable solution that the Architect should implement?

A
Download and install the Amazon Kinesis agent in the on-premises servers and send the logs to Amazon CloudWatch Logs. Create a metric filter in CloudWatch to turn log data into numerical metrics to identify and measure application errors. Use Amazon QuickSight to monitor the metric filter in CloudWatch and immediately notify the IT Operations team for any issues.
B
Download and install the Amazon Managed Service for Prometheus in the on-premises servers and send the logs to AWS Lambda to turn log data into numerical metrics that identify and measure application errors. Write the processed metrics back to the time series database in Prometheus. Create a CloudWatch Alarm that monitors the metric and immediately notifies the IT Operations team for any issues.
C
Download and install the Amazon CloudWatch agent in the on-premises servers and send the logs to Amazon EventBridge. Create a metric filter in CloudWatch to turn log data into numerical metrics to identify and measure application errors. Use Amazon Athena to monitor the metric filter and immediately notify the IT Operations team for any issues.
D
Download and install the Amazon CloudWatch agent in the on-premises servers and send the logs to Amazon CloudWatch Logs. Create a metric filter in CloudWatch to turn log data into numerical metrics to identify and measure application errors. Create a CloudWatch Alarm that monitors the metric filter and immediately notify the IT Operations team for any issues.

Xem giải thích

Đáp án

D — Cài CloudWatch agent trên máy chủ tại chỗ và đẩy log lên CloudWatch Logs; tạo metric filter biến dữ liệu log thành số liệu đo lường lỗi ứng dụng; và tạo CloudWatch Alarm theo dõi metric filter đó để cảnh báo ngay cho đội vận hành.

Vì sao đúng

Đề nêu ba yêu cầu, và chuỗi này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Gộp log từ nhiều nơi | CloudWatch agent đẩy về CloudWatch Logs | | Tự động phân tích lỗi | metric filter đếm mẫu lỗi | | Cảnh báo NGAY khi vượt ngưỡng | CloudWatch Alarm + SNS |

⚠ Metric filter là cầu nối giữa LOG và METRIC:

Log là văn bản — không đặt ngưỡng được
        ↓
    Metric filter đếm số dòng khớp mẫu
    → biến thành metric số
        ↓
    Metric số thì đặt alarm được

Tạo metric filter:

aws logs put-metric-filter \
  --log-group-name /ung-dung/cong-hoc-tap \
  --filter-name dem-loi \
  --filter-pattern "ERROR" \
  --metric-transformations \
    metricName=SoLoiUngDung,metricNamespace=UngDung,\
metricValue=1,defaultValue=0

⚠ defaultValue=0 là chi tiết quan trọng:

Không đặt: khi không có lỗi, metric KHÔNG có dữ liệu
    → alarm chuyển sang trạng thái INSUFFICIENT_DATA
        ↓
    Đặt 0: metric luôn có giá trị
    → alarm hoạt động ổn định

Tạo alarm:

aws cloudwatch put-metric-alarm --alarm-name loi-vuot-nguong \
  --namespace UngDung --metric-name SoLoiUngDung \
  --statistic Sum --period 300 --evaluation-periods 1 \
  --threshold 10 --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions <arn-sns-doi-van-hanh>

⚠ CloudWatch agent chạy được trên máy TẠI CHỖ:

Đề nói máy chủ tại chỗ
    → agent cần credential để đẩy log
        ↓
    Dùng hybrid activation của Systems Manager
    → máy nhận credential TẠM từ vai trò
    → không nhúng access key nào

aws ssm create-activation \
  --iam-role VaiTroMayLai --registration-limit 50 \
  --default-instance-name may-tai-cho

Mẫu lọc nâng cao cho log có cấu trúc:

aws logs put-metric-filter \
  --log-group-name /ung-dung/cong-hoc-tap \
  --filter-name loi-nghiem-trong \
  --filter-pattern '{ $.level = "ERROR" && $.statusCode >= 500 }' \
  --metric-transformations \
    metricName=LoiMayChu,metricNamespace=UngDung,metricValue=1

⚠ Log dạng JSON cho phép lọc chính xác hơn nhiều:

Lọc văn bản thô: "ERROR" khớp cả dòng
  "no ERROR found" — dương tính giả
        ↓
    Lọc JSON: `$.level = "ERROR"` chính xác tuyệt đối

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nơi gộp log của mọi máy | | | Cảnh báo tự động, không cần ai nhìn | | | Logs Insights truy vấn khi cần điều tra | |

⚠ Và Logs Insights bổ sung cho metric filter:

Metric filter: đếm liên tục, đặt ngưỡng được
        ↓
Logs Insights: truy vấn đặc biệt khi điều tra
    → "lỗi này xảy ra ở máy nào, lúc nào"

fields @timestamp, @message, @logStream
| filter @message like /ERROR/
| stats count() by @logStream
| sort count desc

Vì sao các phương án khác sai

**A. Cài Kinesis agent đẩy log lên CloudWatch Logs, tạo metric filter, rồi dùng QuickSight theo dõi và cảnh báo — đây là phương án gần nhất và metric filter đúng, nhưng QuickSight là công cụ trực quan hoá dashboard, nó không theo dõi metric và không gửi cảnh báo tức thì; CloudWatch Alarm mới là công cụ đó.
**C. CloudWatch agent đẩy log lên EventBridge, tạo metric filter, dùng Athena theo dõi — CloudWatch agent đẩy log lên CloudWatch Logs, không phải EventBridge; và Athena truy vấn dữ liệu tĩnh trên S3, không theo dõi liên tục.
**B. Cài Managed Service for Prometheus trên máy tại chỗ, đẩy log sang Lambda, ghi ngược vào Prometheus — Prometheus là dịch vụ được quản lý trên AWS, không cài lên máy tại chỗ; và nó dành cho metric, không phải xử lý log.

Ghi nhớ

⚠ Ba bước biến log thành cảnh báo — bảng phải thuộc: | Bước | Công cụ | |---|---| | Thu thập log | CloudWatch agent | | Biến log thành số | metric filter | | Cảnh báo khi vượt ngưỡng | CloudWatch Alarm + SNS |

Từ khoá nhận diện:

"turn log data into numerical metrics" → metric filter "alert when threshold breached" → CloudWatch Alarm "ad-hoc log queries" → Logs Insights "dashboards for business users" → QuickSight

⚠ Metric filter vs Logs Insights:

Metric filter: chạy LIÊN TỤC khi log tới
    → tạo metric, đặt alarm được
    → tính phí theo GB log nạp vào
        ↓
Logs Insights: chạy KHI BẠN GỌI
    → truy vấn linh hoạt hơn
    → tính phí theo GB quét mỗi lần chạy

Ba loại mẫu lọc: | Loại | Ví dụ | |---|---| | Văn bản thô | "ERROR" | | Nhiều từ | "ERROR" "timeout" (VÀ) | | JSON | { $.level = "ERROR" } | | Không gian phân tách | [ip, user, ..., status=5*] |

⚠ Mẫu văn bản thô phân biệt HOA THƯỜNG:

Mẫu "ERROR" KHÔNG khớp "error"
    → dùng "?ERROR ?error ?Error" cho HOẶC

Ba lưu ý về treat-missing-data: | Giá trị | Hành vi khi thiếu dữ liệu | |---|---| | notBreaching | coi như bình thường | | breaching | coi như vượt ngưỡng | | ignore | giữ nguyên trạng thái | | missing | mặc định |

⚠ Chọn sai làm alarm kêu liên tục hoặc không bao giờ kêu:

Ứng dụng ít lỗi → nhiều chu kỳ không có dữ liệu
    → `breaching` sẽ báo động giả liên tục
        ↓
    `notBreaching` + `defaultValue=0` là cặp đúng

Ba lưu ý về composite alarm: | Lưu ý | Chi tiết | |---|---| | Kết hợp nhiều alarm bằng AND/OR | | | Giảm nhiễu cảnh báo | | | Chỉ báo khi nhiều điều kiện cùng đúng | |

aws cloudwatch put-composite-alarm \
  --alarm-name su-co-that \
  --alarm-rule "ALARM(loi-vuot-nguong) AND ALARM(do-tre-cao)" \
  --alarm-actions <arn-sns>

⚠ Composite alarm giảm báo động giả rất hiệu quả:

Một mình lỗi tăng: có thể là bot quét
Một mình độ trễ cao: có thể là truy vấn nặng
        ↓
    Cả hai cùng lúc: gần như chắc chắn có sự cố

Ba lưu ý về CloudWatch agent trên máy tại chỗ: | Lưu ý | Chi tiết | |---|---| | Dùng hybrid activation, không nhúng access key | | | Cấu hình giống hệt trên EC2 | | | Quản lý tập trung qua SSM Parameter Store | |

Ba lưu ý về chi phí CloudWatch Logs: | Khoản | Chi tiết | |---|---| | Phí nạp theo GB | khoản lớn nhất | | Phí lưu trữ theo GB-tháng | | | Metric filter miễn phí, nhưng metric sinh ra tính phí | |

⚠ Đặt retention để tránh phí tích tụ:

aws logs put-retention-policy \
  --log-group-name /ung-dung/cong-hoc-tap --retention-in-days 30

Mặc định giữ VĨNH VIỄN
    → phí lưu trữ tăng mãi

Ba lưu ý về giảm lượng log nạp: | Cách | Chi tiết | |---|---| | Lọc bớt ở agent trước khi gửi | | | Giảm mức log ở sản xuất | | | Log Class Infrequent Access rẻ hơn ~50% | |

Ba lưu ý về SNS: | Lưu ý | Chi tiết | |---|---| | Người nhận phải xác nhận đăng ký | | | Đưa cảnh báo nghiêm trọng vào hệ thống trực | | | Cảnh báo không ai đọc là cảnh báo không tồn tại | |

Ba lưu ý về subscription filter: | Lưu ý | Chi tiết | |---|---| | Đẩy log sang OpenSearch, Lambda, Kinesis | | | Tối đa 2 filter mỗi log group | | | Dùng khi cần phân tích sâu hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một dòng log lỗi thử | | | Xem metric tăng trong CloudWatch | | | Xác nhận đội vận hành nhận cảnh báo | |

aws logs put-log-events --log-group-name /ung-dung/cong-hoc-tap \
  --log-stream-name thu-nghiem \
  --log-events timestamp=$(date +%s000),message="ERROR thu nghiem"

Và một lời khuyên: hãy đặt defaultValue=0 cho mọi metric filter đếm lỗi. Không có nó, metric chỉ tồn tại khi có lỗi — và alarm sẽ dành phần lớn thời gian ở trạng thái thiếu dữ liệu thay vì trạng thái bình thường, khiến bạn không phân biệt được "hệ thống khoẻ" với "giám sát đã hỏng".

Câu 70 Domain - Design Solutions for Organizational Complexity

A company runs a sports web portal that covers the latest cricket news in Australia. The solutions architect manages the main AWS account which has resources in multiple AWS regions. The web portal is hosted on a fleet of on-demand EC2 instances and an RDS database which are also deployed to other AWS regions. The IT Security Compliance Officer has given the solutions architect the task of developing a reliable and durable logging solution to track changes made to all of your EC2, IAM, and RDS resources in all of the AWS regions. The solution must ensure the integrity and confidentiality of the log data.

Which of the following solutions would be the best option to choose?

A Create a new trail in CloudTrail and assign it a new S3 bucket to store the logs. Configure AWS SNS to send delivery notifications to your management system. Secure the S3 bucket that stores your logs using IAM roles and S3 bucket policies.
B Create a new trail in AWS CloudTrail with the global services option selected, and create one new Amazon S3 bucket to store the logs. Create IAM roles, S3 bucket policies, and enable Multi Factor Authentication (MFA) Delete on the S3 bucket storing your logs.
C Create a new trail in AWS CloudTrail with the global services option selected, and assign it an existing S3 bucket to store the logs. Create S3 ACLs and enable Multi Factor Authentication (MFA) delete on the S3 bucket storing your logs.
D Create three new CloudTrail trails, each with its own S3 bucket to store the logs: one for the AWS Management console, one for AWS SDKs, and one for command line tools. Then create IAM roles and S3 bucket policies for the S3 buckets storing your logs.

Xem giải thích

Đáp án

B — Tạo trail mới trong AWS CloudTrail với tuỳ chọn global services được bật, dùng một bucket S3 MỚI để lưu log; tạo IAM role, bucket policy và bật MFA Delete trên bucket đó.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này thoả cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Theo dõi EC2, IAM, RDS ở MỌI Region | multi-region + global service events | | Bảo đảm TÍNH TOÀN VẸN của log | log file validation | | Bảo đảm TÍNH BẢO MẬT | KMS + bucket policy + MFA Delete | | Bảo đảm ĐỘ BỀN | S3 11 số 9 |

⚠ IAM là dịch vụ TOÀN CẦU — đây là chi tiết quyết định:

Đề nhắc IAM trong danh sách cần theo dõi
    → sự kiện IAM phát ra ở us-east-1
        ↓
    Không bật `--include-global-service-events`
    → mọi thay đổi IAM KHÔNG được ghi
    → bỏ sót đúng thứ nhạy cảm nhất

Lệnh đầy đủ:

aws cloudtrail create-trail --name duong-mon-tuan-thu \
  --s3-bucket-name log-cloudtrail-moi \
  --is-multi-region-trail \
  --include-global-service-events \
  --enable-log-file-validation \
  --kms-key-id <arn-khoa>

aws cloudtrail start-logging --name duong-mon-tuan-thu

⚠ Bucket MỚI thay vì bucket có sẵn — đây là lý do B thắng C:

Bucket có sẵn: có thể đã có quyền rộng,
               đã có lifecycle, đã có người dùng
        ↓
    Bucket mới dành riêng cho log
    → kiểm soát quyền từ đầu
    → và bật được Object Lock (chỉ lúc tạo)

⚠ Và C dùng S3 ACL thay vì bucket policy:

ACL là cơ chế CŨ, AWS khuyến nghị tắt hẳn
    → `BucketOwnerEnforced` vô hiệu hoá ACL
        ↓
    Bucket policy mới là cách kiểm soát hiện đại

Bật MFA Delete:

aws s3api put-bucket-versioning \
  --bucket log-cloudtrail-moi \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

⚠ MFA Delete chỉ bật được bằng credential ROOT:

Đây là một trong số rất ít việc BẮT BUỘC dùng root
    → và cần bật versioning trước
        ↓
    Không tự động hoá được bằng CloudFormation

⚠ Nhưng Object Lock thường tốt hơn MFA Delete:

aws s3api put-object-lock-configuration \
  --bucket log-cloudtrail-moi \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}'

Chế độ COMPLIANCE: KHÔNG AI xoá được, kể cả root
    → không cần thao tác MFA thủ công
        ↓
    Nhưng phải bật lúc TẠO bucket

Bucket policy chặn xoá:

{"Effect": "Deny", "Principal": "*",
 "Action": ["s3:DeleteObject", "s3:DeleteObjectVersion",
            "s3:PutBucketPolicy", "s3:DeleteBucketPolicy"],
 "Resource": ["arn:aws:s3:::log-cloudtrail-moi",
              "arn:aws:s3:::log-cloudtrail-moi/*"],
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/QuanTriLog"}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không Region nào bị bỏ sót | | | IAM và các dịch vụ toàn cầu được ghi | | | Log không sửa được, không xoá được | |

⚠ --enable-log-file-validation là thứ đáp ứng "tính toàn vẹn":

CloudTrail tạo tệp digest ký số mỗi giờ
    → chứa hash của các tệp log
        ↓
    Ai sửa hoặc xoá log → validate phát hiện ra

aws cloudtrail validate-logs --trail-arn <arn> \
  --start-time 2026-08-01T00:00:00Z

Vì sao các phương án khác sai

**C. Trail với global services nhưng dùng bucket S3 CÓ SẴN và S3 ACL — đây là phương án gần nhất và cờ CloudTrail đúng, nhưng dùng bucket có sẵn khiến không kiểm soát được quyền từ đầu; và ACL là cơ chế cũ mà AWS khuyến nghị tắt hẳn.
**A. Tạo trail và bucket mới nhưng KHÔNG bật global services — bỏ sót IAM và các dịch vụ toàn cầu, đúng thứ đề yêu cầu theo dõi.
**D. Tạo BA trail riêng cho console, SDK và command line — CloudTrail không phân chia theo cách đó: một trail ghi mọi lời gọi API bất kể đến từ đâu. Ba trail chỉ tạo ra ba bản sao trùng lặp và ba lần chi phí.

Ghi nhớ

⚠ Hai cờ của CloudTrail — bảng phải thuộc: | Cờ | Thiếu nó thì mất gì | |---|---| | --is-multi-region-trail | sự kiện ở các Region khác | | --include-global-service-events | IAM, CloudFront, Route 53, Organizations, STS |

⚠ CloudTrail ghi MỌI nguồn gọi API:

Console, SDK, CLI, SDK của bên thứ ba,
lời gọi từ chính dịch vụ AWS
        ↓
    Tất cả vào CÙNG một trail
    → không có khái niệm trail riêng theo nguồn

Từ khoá nhận diện:

"track changes in all Regions including IAM" → cả hai cờ "log integrity" → log file validation "prevent log deletion" → Object Lock hoặc MFA Delete "configuration state and history" → AWS Config (bổ sung)

⚠ CloudTrail và Config trả lời hai câu hỏi khác nhau:

CloudTrail: "AI đã gọi API gì"
Config:     "tài nguyên ĐANG thế nào, đã đổi ra sao"
        ↓
    Tuân thủ đầy đủ thường cần CẢ HAI

Ba loại sự kiện CloudTrail: | Loại | Mặc định | Ghi gì | |---|---|---| | Management | BẬT, miễn phí (trail đầu) | control plane | | Data | TẮT, có phí | s3:GetObject, lambda:Invoke | | Insights | TẮT, có phí | bất thường về tần suất |

Ba lưu ý về bảo vệ log: | Lưu ý | Chi tiết | |---|---| | Bucket log ở TÀI KHOẢN RIÊNG | | | Object Lock chế độ Compliance | | | Cảnh báo cho StopLogging | |

⚠ Việc đầu tiên kẻ tấn công làm là tắt log:

{"source": ["aws.cloudtrail"],
 "detail": {"eventName": ["StopLogging","DeleteTrail",
                          "UpdateTrail","PutEventSelectors"]}}

Ba lưu ý về organization trail: | Lưu ý | Chi tiết | |---|---| | Tạo từ management account | | | Ghi log MỌI tài khoản thành viên | | | Thành viên KHÔNG tắt được | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | KMS key policy phải cho CloudTrail dùng khoá | | | Người đọc log cần kms:Decrypt | | | Bật S3 Bucket Key giảm phí | |

Ba lưu ý về MFA Delete: | Lưu ý | Chi tiết | |---|---| | Chỉ bật được bằng credential ROOT | | | Cần bật versioning trước | | | Không tự động hoá bằng IaC được | |

⚠ Đây là lý do Object Lock thường được ưa hơn:

MFA Delete: thao tác thủ công mỗi lần xoá
    → và cần thiết bị MFA của root
        ↓
    Object Lock: chặn tự động, không cần ai
    → và tự động hoá bằng IaC được

Ba cách truy vấn log: | Cách | Đặc điểm | |---|---| | Console Event history | chỉ 90 ngày, chỉ management | | Athena trên bucket | rẻ nhất | | CloudTrail Lake | SQL, giữ tới 10 năm |

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Chuyển sang Glacier sau 90 ngày | | | Giữ theo yêu cầu tuân thủ | | | Object Lock chặn xoá trước hạn | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Trail đầu tiên (management) miễn phí | | | Trail thứ hai trở đi tính phí | | | Data event tính theo sự kiện | |

⚠ Đây là lý do phương án D tốn kém:

Ba trail = hai trail tính phí
    → và ba bản sao cùng một dữ liệu
        ↓
    Một trail đa Region là đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đổi một IAM policy, tìm sự kiện trong log | | | Tạo tài nguyên ở Region khác, tìm log | | | Chạy validate-logs | |

aws cloudtrail get-trail-status --name duong-mon-tuan-thu \
  --query "[IsLogging,LatestDeliveryTime]"

Và một lời khuyên: hãy kiểm chứng bằng cách đổi một IAM policy rồi đi tìm sự kiện đó. IAM là dịch vụ toàn cầu, nên tìm thấy nó trong log chứng minh cờ --include-global-service-events đã bật đúng — còn không thì bạn vừa phát hiện một lỗ hổng ngay ở chỗ nhạy cảm nhất.

Trang 7 / 123 — tổng 1221 câu hỏi