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

Tìm thấy 2194 câu.

Câu 461 Design Resilient Architectures

A leading carmaker would like to build a new car-as-a-sensor service by leveraging fully serverless components that are provisioned and managed automatically by AWS. The development team at the carmaker does not want an option that requires the capacity to be manually provisioned, as it does not want to respond manually to changing volumes of sensor data.

Given these constraints, which of the following solutions is the BEST fit to develop this car-as-a-sensor service?

  1. A

    Ingest the sensor data in an Amazon Simple Queue Service (Amazon SQS) standard queue, which is polled by an AWS Lambda function in batches and the data is written into an auto-scaled Amazon DynamoDB table for downstream processing
  2. B

    Ingest the sensor data in Amazon Kinesis Data Firehose, which directly writes the data into an auto-scaled Amazon DynamoDB table for downstream processing
  3. C

    Ingest the sensor data in Amazon Kinesis Data Streams, which is polled by an application running on an Amazon EC2 instance and the data is written into an auto-scaled Amazon DynamoDB table for downstream processing
  4. D

    Ingest the sensor data in an Amazon Simple Queue Service (Amazon SQS) standard queue, which is polled by an application running on an Amazon EC2 instance and the data is written into an auto-scaled Amazon DynamoDB table for downstream processing
Xem giải thích

Đáp án

A — Nạp dữ liệu cảm biến vào Amazon SQS standard queue, để AWS Lambda đọc theo lô và ghi vào bảng DynamoDB tự co giãn.

Vì sao đúng

Đề nêu hai ràng buộc, và đáp án là lựa chọn duy nhất thoả cả hai: | Ràng buộc | Cơ chế | |---|---| | Hoàn toàn SERVERLESS, do AWS tự cấp phát và quản lý | SQS + Lambda + DynamoDB đều serverless | | KHÔNG phải cấp phát năng lực THỦ CÔNG | cả ba tự co giãn |

Vì sao đây là lựa chọn duy nhất đúng:

SQS:      không có gì để cấp phát — tự nhận mọi khối lượng
Lambda:   tự co giãn theo số thông điệp
DynamoDB: chế độ on-demand tự co giãn theo tải
    ↓
    Không có tham số dung lượng nào phải chỉnh tay

Và điểm phân biệt then chốt với Kinesis:

Kinesis Data Streams (chế độ provisioned):
    → phải khai SỐ SHARD
    → tải tăng → phải TỰ tăng shard
        ↓
    Đúng thứ mà đề nói không muốn:
    "does not want an option that requires the capacity to be
     MANUALLY PROVISIONED"

Luồng dữ liệu:

Cảm biến trên xe
    ↓ HTTPS
SQS standard queue (hấp thụ mọi đỉnh tải)
    ↓ event source mapping
Lambda đọc theo LÔ (tới 10.000 bản ghi)
    ↓ BatchWriteItem
DynamoDB (on-demand)

Cấu hình Lambda đọc SQS theo lô:

aws lambda create-event-source-mapping   --function-name xu-ly-cam-bien   --event-source-arn <arn-sqs>   --batch-size 10 --maximum-batching-window-in-seconds 5

Và DynamoDB on-demand không cần khai dung lượng:

aws dynamodb create-table --table-name du-lieu-cam-bien   --attribute-definitions AttributeName=ma_xe,AttributeType=S                           AttributeName=thoi_diem,AttributeType=N   --key-schema AttributeName=ma_xe,KeyType=HASH                 AttributeName=thoi_diem,KeyType=RANGE   --billing-mode PAY_PER_REQUEST

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

  • **B. Nạp vào Kinesis Data Firehose, ghi trực tiếp vào DynamoDB — đây là phương án gần nhất và Firehose thực sự là serverless và tự co giãn, nhưng nó sai về mặt kỹ thuật: Firehose KHÔNG hỗ trợ DynamoDB làm đích. Các đích được hỗ trợ là S3, Redshift, OpenSearch, Splunk và một số endpoint HTTP.
  • **C. Kinesis Data Streams với ứng dụng chạy trên EC2 — vi phạm cả hai ràng buộc: EC2 không phải serverless, và Kinesis provisioned đòi khai số shard thủ công.
  • **D. SQS với ứng dụng chạy trên EC2 — vế SQS đúng nhưng EC2 không phải serverless: phải quản lý AMI, vá lỗi, cấu hình ASG.

Ghi nhớ

Bốn dịch vụ nạp dữ liệu — bảng cần thuộc: | Dịch vụ | Cấp phát năng lực | Thứ tự | Đích | |---|---|---|---| | SQS | KHÔNG cần | Standard: không / FIFO: có | consumer tự chọn | | Kinesis Data Streams (provisioned) | PHẢI khai số shard | ✅ trong shard | consumer tự chọn | | Kinesis Data Streams (on-demand) | không cần | ✅ trong shard | consumer tự chọn | | Kinesis Data Firehose | không cần | không đảm bảo | S3, Redshift, OpenSearch, Splunk, HTTP |

Đích của Firehose là chi tiết hay bị hỏi — DynamoDB KHÔNG nằm trong danh sách.

Và Kinesis on-demand đáng biết:

aws kinesis create-stream --stream-name luong-cam-bien   --stream-mode-details StreamMode=ON_DEMAND

Chế độ này ra mắt năm 2021, tự co giãn tới 200 MB/giây mà không cần quản lý shard — nó xoá bỏ đúng điểm yếu mà câu hỏi nhắm tới. (Các phương án trong đề không nêu chế độ này.)

SQS và Kinesis — chọn cái nào: | Tiêu chí | SQS | Kinesis | |---|---|---| | Thứ tự | FIFO mới có | ✅ trong shard | | Đọc lại dữ liệu cũ | ❌ | ✅ tới 365 ngày | | Nhiều consumer độc lập | ❌ | ✅ | | Cấp phát năng lực | không cần | provisioned thì cần | | Đơn giản | ✅ đơn giản nhất | phức tạp hơn |

Với "car-as-a-sensor" chỉ cần nạp và lưu, SQS là lựa chọn đơn giản và đúng nhất.

Ba mức "serverless" — phân biệt rõ: | Mức | Ví dụ | |---|---| | Serverless thật | Lambda, SQS, SNS, DynamoDB on-demand, Fargate, API Gateway | | Được quản lý nhưng phải chọn dung lượng | Kinesis provisioned, RDS, ElastiCache, OpenSearch | | Bạn quản lý máy | EC2, ECS trên EC2 |

Hai chế độ tính phí của DynamoDB: | Chế độ | Đặc điểm | |---|---| | On-demand (PAY_PER_REQUEST) | tự co giãn tức thì, trả theo request | | Provisioned | rẻ hơn khi tải ổn định, có auto scaling |

Quy tắc: tải khó đoán hoặc tăng đột biến → on-demand.

Ba cấu hình quan trọng của event source mapping: | Cấu hình | Việc | |---|---| | BatchSize | số thông điệp mỗi lần gọi (SQS tối đa 10.000 với lô lớn) | | MaximumBatchingWindowInSeconds | chờ gom đủ lô — giảm số lần gọi Lambda | | FunctionResponseTypes: ReportBatchItemFailures | chỉ trả lại thông điệp HỎNG, không cả lô |

Tuỳ chọn thứ ba rất quan trọng:

Không bật:
    Một thông điệp trong lô 10 bị lỗi
    → CẢ 10 quay lại hàng đợi
    → 9 thông điệp tốt bị xử lý LẠI

Có bật:
    → chỉ thông điệp hỏng quay lại

Ba lưu ý khi ghi hàng loạt vào DynamoDB: | Lưu ý | Chi tiết | |---|---| | BatchWriteItem tối đa 25 mục | chia lô nếu Lambda nhận nhiều hơn | | Xử lý UnprocessedItems | BatchWriteItem có thể thành công MỘT PHẦN | | Chọn partition key phân bố đều | tránh hot partition |

Dòng giữa là lỗi hay gặp: BatchWriteItem trả về HTTP 200 nhưng vẫn có mục chưa ghi được trong UnprocessedItems — bỏ qua là mất dữ liệu âm thầm.

phan_hoi = dynamodb.batch_write_item(RequestItems=yeu_cau)
while phan_hoi.get('UnprocessedItems'):
    time.sleep(0.1)   # có backoff
    phan_hoi = dynamodb.batch_write_item(RequestItems=phan_hoi['UnprocessedItems'])

Ba lưu ý về thiết kế khoá cho dữ liệu cảm biến: | Lưu ý | Chi tiết | |---|---| | Partition key = mã xe | phân bố tự nhiên qua hàng nghìn xe | | Sort key = thời điểm | truy vấn theo khoảng thời gian | | Bật TTL để tự xoá dữ liệu cũ | dữ liệu cảm biến tích tụ rất nhanh |

aws dynamodb update-time-to-live --table-name du-lieu-cam-bien   --time-to-live-specification "Enabled=true, AttributeName=het_han"

TTL xoá miễn phí — với dữ liệu telemetry, đây là cơ chế kiểm soát chi phí quan trọng nhất.

Ba biện pháp bảo vệ cho hệ thống nạp dữ liệu: | Biện pháp | Chi tiết | |---|---| | Dead-letter queue | thông điệp hỏng không kẹt mãi | | Reserved concurrency cho Lambda | bảo vệ các hàm khác | | Alarm cho ApproximateAgeOfOldestMessage | phát hiện xử lý không kịp |

Và một lời khuyên: hãy cân nhắc Kinesis Data Firehose ghi vào S3 cho dữ liệu thô, song song với DynamoDB cho truy vấn nhanh. Dữ liệu cảm biến ô tô có giá trị phân tích lâu dài, và giữ toàn bộ trong DynamoDB đắt hơn S3 rất nhiều — mẫu "nóng trong DynamoDB, lạnh trong S3" là kiến trúc chuẩn cho IoT quy mô lớn.

Câu 462 Design Secure Architectures

What does this IAM policy do?

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Mystery Policy",
      "Action": [
        "ec2:RunInstances"
      ],
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "34.50.31.0/24"
        }
      }
    }
  ]
}
  1. A

    It allows starting an Amazon EC2 instance only when they have an Elastic IP within the 34.50.31.0/24 CIDR block
  2. B

    It allows starting an Amazon EC2 instance only when they have a Private IP within the 34.50.31.0/24 CIDR block
  3. C

    It allows starting an Amazon EC2 instance only when they have a Public IP within the 34.50.31.0/24 CIDR block
  4. D

    It allows starting an Amazon EC2 instance only when the IP where the call originates is within the 34.50.31.0/24 CIDR block
Xem giải thích

Đáp án

D — Nó cho phép khởi động EC2 instance chỉ khi ĐỊA CHỈ IP NƠI PHÁT SINH LỜI GỌI nằm trong khối CIDR 34.50.31.0/24.

Vì sao đúng

Điểm mấu chốt nằm ở khoá điều kiện aws:SourceIp — nó nói về người GỌI, không phải về tài nguyên được tạo.

"Condition": {"IpAddress": {"aws:SourceIp": "34.50.31.0/24"}}

aws:SourceIp là gì:

aws:SourceIp = địa chỉ IP CÔNG CỘNG mà REQUEST được gửi đi từ đó
    → IP của máy trạm gọi AWS CLI
    → IP công cộng của văn phòng
    → IP của máy chủ CI/CD
        ↓
    KHÔNG liên quan gì tới IP của instance sắp được tạo

Ý nghĩa thực tế của chính sách này:

Chỉ khởi động được EC2 khi lệnh phát ra từ mạng 34.50.31.0/24
    → ví dụ: chỉ từ văn phòng công ty
    → thông tin đăng nhập bị đánh cắp mà dùng từ nơi khác → bị từ chối

Vì sao ba phương án kia sai về mặt khái niệm:

"instance có Elastic IP / Private IP / Public IP trong dải đó"
    ↓
    Đó là thuộc tính của TÀI NGUYÊN ĐƯỢC TẠO
    → cần khoá điều kiện khác hẳn (và IP thường chưa tồn tại
      tại thời điểm gọi RunInstances)

Ghi chú kỹ thuật: dải 34.50.31.0/24 là IP công cộng, phù hợp với aws:SourceIp — khoá này không khớp với IP riêng trong VPC.

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

  • **C. Cho phép khởi động instance khi chúng có Public IP trong dải đó — đây là phương án gần nhất vì dải 34.x.x.x đúng là dải IP công cộng, nhưng nó hiểu sai chủ thể: điều kiện nói về IP của người gọi API, không phải IP được gán cho instance mới.
  • **A. Khi instance có Elastic IP trong dải đó — cùng lỗi, và EIP còn được gán bằng lời gọi API riêng (AssociateAddress) sau khi instance đã tồn tại.
  • **B. Khi instance có Private IP trong dải đó — cùng lỗi, và aws:SourceIp không khớp với IP riêng khi lời gọi đi qua Internet.

Ghi nhớ

Các khoá điều kiện toàn cục của IAM — bảng cần thuộc: | Khoá | Ý nghĩa | |---|---| | aws:SourceIp | IP CÔNG CỘNG của người gọi ← câu này | | aws:SourceVpc | VPC mà request đi qua (khi dùng VPC endpoint) | | aws:SourceVpce | id của VPC endpoint | | aws:PrincipalArn | ARN của người gọi | | aws:PrincipalOrgID | id Organization của người gọi | | aws:MultiFactorAuthPresent | có dùng MFA không | | aws:RequestedRegion | Region của request | | aws:CurrentTime | thời điểm | | aws:SecureTransport | có dùng HTTPS không | | aws:ResourceTag/<key> | thẻ của tài nguyên | | aws:RequestTag/<key> | thẻ trong request |

Ba cạm bẫy của aws:SourceIp: | Cạm bẫy | Chi tiết | |---|---| | KHÔNG hoạt động khi request đi qua VPC ENDPOINT | phải dùng aws:SourceVpce hoặc aws:VpcSourceIp | | KHÔNG áp cho lời gọi do DỊCH VỤ AWS thực hiện thay bạn | ví dụ CloudFormation tạo tài nguyên | | Chỉ khớp IP CÔNG CỘNG | không dùng cho IP riêng |

Cạm bẫy đầu tiên gây sự cố thật sự:

Chính sách chặn theo aws:SourceIp
    → EC2 trong private subnet gọi S3 qua GATEWAY ENDPOINT
    → request KHÔNG đi qua Internet, không có SourceIp công cộng
        ↓
    → Bị TỪ CHỐI dù đúng ra phải được phép

Cách sửa: thêm điều kiện cho VPC endpoint:

{"Condition": {"IpAddress": {"aws:SourceIp": ["34.50.31.0/24"]}},
 "Bool": {"aws:ViaAWSService": "false"}}

Hoặc dùng StringEquals với aws:SourceVpce.

Và aws:ViaAWSService xử lý cạm bẫy thứ hai:

{"Condition": {
  "IpAddress": {"aws:SourceIp": "34.50.31.0/24"},
  "Bool": {"aws:ViaAWSService": "false"}}}

Điều này cho phép dịch vụ AWS (như CloudFormation) hành động thay bạn mà không bị chặn.

Bốn toán tử điều kiện hay dùng: | Toán tử | Dùng cho | |---|---| | IpAddress / NotIpAddress | so khớp CIDR ← câu này | | StringEquals / StringLike | chuỗi (StringLike có ký tự đại diện) | | Bool | true/false | | DateGreaterThan / DateLessThan | thời gian | | ArnEquals / ArnLike | ARN | | Null | kiểm tra khoá có TỒN TẠI không |

Toán tử Null rất hữu ích để bắt buộc một khoá:

{"Condition": {"Null": {"aws:RequestTag/DuAn": "true"}},
 "Effect": "Deny"}

Chặn tạo tài nguyên không có thẻ DuAn.

Ba nguyên tắc đánh giá chính sách IAM:

① Mặc định: TỪ CHỐI
② Có explicit Allow ở bất kỳ chính sách nào → cho phép
③ Có explicit DENY ở bất kỳ đâu → TỪ CHỐI (thắng mọi Allow)

Và thứ tự xét đầy đủ:

Organizations SCP → Resource policy → Identity policy
    → Permissions boundary → Session policy
        ↓
    Chỉ cần MỘT tầng Deny là toàn bộ bị từ chối

Ba mẫu chính sách hay dùng với điều kiện IP: | Mẫu | Chi tiết | |---|---| | Giới hạn quản trị viên theo IP văn phòng | ← câu này | | Chặn truy cập S3 ngoài VPC | dùng aws:SourceVpce | | Bắt buộc HTTPS | aws:SecureTransport |

Ví dụ bắt buộc HTTPS cho bucket:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho/*", "arn:aws:s3:::kho"],
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Ba lưu ý khi dùng điều kiện IP để bảo mật: | Lưu ý | Chi tiết | |---|---| | IP văn phòng có thể ĐỔI | chính sách hỏng mà không báo trước | | Nhân viên làm việc từ xa bị chặn | cần VPN với IP cố định | | Không thay thế được MFA | kết hợp cả hai thì mạnh hơn |

Kết hợp IP và MFA là cấu hình mạnh:

{"Condition": {
  "IpAddress": {"aws:SourceIp": "34.50.31.0/24"},
  "Bool": {"aws:MultiFactorAuthPresent": "true"}}}

Ba công cụ kiểm tra chính sách: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử một hành động và xem kết quả kèm lý do | | IAM Access Analyzer policy validation | phát hiện lỗi cú pháp và quyền quá rộng | | CloudTrail | xem lời gọi thật đã bị từ chối vì lý do gì |

Và một lời khuyên: hãy dùng IAM Policy Simulator trước khi áp chính sách có điều kiện IP lên môi trường sản xuất. Điều kiện IP là loại dễ khoá nhầm chính mình nhất — và nếu bạn khoá luôn quyền sửa chính sách, cách duy nhất để gỡ là dùng tài khoản root.

Câu 463 Design Cost-Optimized Architectures

An application runs big data workloads on Amazon Elastic Compute Cloud (Amazon EC2) instances. The application runs 24x7 all round the year and needs at least 20 instances to maintain a minimum acceptable performance threshold and the application needs 300 instances to handle spikes in the workload. Based on historical workloads processed by the application, it needs 80 instances 80% of the time.

As a solutions architect, which of the following would you recommend as the MOST cost-optimal solution so that it can meet the workload demand in a steady state?

  1. A

    Purchase 20 on-demand instances. Use Auto Scaling Group to provision the remaining instances as spot instances per the workload demand
  2. B

    Purchase 80 spot instances. Use Auto Scaling Group to provision the remaining instances as on-demand instances per the workload demand
  3. C

    Purchase 80 on-demand instances. Provision additional on-demand and spot instances per the workload demand (Use Auto Scaling Group with launch template to provision the mix of on-demand and spot instances)
  4. D

    Purchase 80 reserved instances (RIs). Provision additional on-demand and spot instances per the workload demand (Use Auto Scaling Group with launch template to provision the mix of on-demand and spot instances)
Xem giải thích

Đáp án

D — Mua 80 Reserved Instances; cấp phát thêm instance on-demand và spot theo nhu cầu bằng Auto Scaling group với launch template trộn hai loại.

Vì sao đúng

Đề cho ba con số, và mỗi con số quyết định một phần của giải pháp: | Dữ kiện | Kết luận | |---|---| | Tối thiểu 20 máy, chạy 24/7 quanh năm | phần nền tuyệt đối | | 80 máy trong 80% THỜI GIAN | đây là mức nền THỰC TẾ → mua RI cho 80 | | Đỉnh tới 300 máy | phần biến động → on-demand và spot |

Vì sao mua RI cho 80 chứ không phải 20:

Máy chạy 80% thời gian trong năm ≈ 7.008 giờ
    → RI trả trước một phần: giảm khoảng 40–60%
    → chỉ cần dùng trên ~60–70% thời gian là RI đã có lợi
        ↓
    80% > ngưỡng hoà vốn → mua RI cho cả 80 máy là tối ưu

Phép so sánh cho 60 máy (phần từ 20 tới 80): | Phương án | Chi phí tương đối cho 60 máy chạy 80% thời gian | |---|---| | On-demand | 100% × 0,8 = 80 đơn vị | | RI 1 năm | ~60% × 1,0 = 60 đơn vị (trả cả năm) | | Chênh lệch | RI rẻ hơn ~25% |

Và phần đỉnh dùng spot là hợp lý:

Đề nói "big data workloads"
    → thường chịu được gián đoạn
    → spot giảm tới 90%
        ↓
    Phần từ 80 lên 300 máy: trộn on-demand (đảm bảo) và spot (rẻ)

Cấu hình ASG trộn:

{"MixedInstancesPolicy": {
   "InstancesDistribution": {
     "OnDemandBaseCapacity": 0,
     "OnDemandPercentageAboveBaseCapacity": 20,
     "SpotAllocationStrategy": "capacity-optimized"},
   "LaunchTemplate": {"Overrides": [
     {"InstanceType": "m5.4xlarge"}, {"InstanceType": "m5a.4xlarge"},
     {"InstanceType": "m6i.4xlarge"}, {"InstanceType": "m5n.4xlarge"}]}}}

RI áp dụng TỰ ĐỘNG cho instance on-demand khớp thuộc tính — không phải gán thủ công.

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

  • **C. Mua 80 instance ON-DEMAND rồi cấp thêm on-demand và spot — đây là phương án gần nhất và cấu trúc giống hệt đáp án đúng, nhưng nó bỏ lỡ khoản giảm giá lớn nhất: 80 máy chạy 80% thời gian là mẫu tải hoàn hảo cho RI hoặc Savings Plans, và trả giá on-demand cho chúng là lãng phí 40–60%.
  • **A. Mua 20 on-demand và dùng spot cho phần còn lại — hai lỗi: phần nền 20 máy chạy 24/7 nên mua RI chứ không phải on-demand, và đặt 60 máy của mức nền thường xuyên lên spot là rủi ro — spot bị thu hồi hàng loạt sẽ đưa hệ thống xuống dưới ngưỡng hiệu năng chấp nhận được.
  • **B. Mua 80 SPOT rồi thêm on-demand — đảo ngược hoàn toàn nguyên tắc: phần nền ổn định phải dùng cam kết dài hạn (rẻ và đảm bảo), phần biến động mới dùng spot. Và "mua spot" không phải khái niệm đúng — spot không mua trước được.

Ghi nhớ

Nguyên tắc phân tầng chi phí EC2 — bảng phải thuộc:

Tải NỀN ổn định (chạy phần lớn thời gian)
    → Savings Plans hoặc Reserved Instances

Tải BIẾN ĐỘNG dự đoán được, cần đảm bảo
    → On-Demand

Tải BIẾN ĐỘNG chịu được gián đoạn
    → Spot

Bốn mô hình mua — bảng so sánh: | Mô hình | Cam kết | Giảm giá | Đảm bảo năng lực | |---|---|---|---| | On-Demand | không | 0% | ✅ | | Savings Plans | 1 hoặc 3 năm, theo USD/giờ | tới 72% | ❌ (trừ khi kèm ODCR) | | Reserved Instances (zonal) | 1 hoặc 3 năm | tới 72% | ✅ zonal RI có | | Reserved Instances (regional) | 1 hoặc 3 năm | tới 72% | ❌ KHÔNG đảm bảo | | Spot | không | tới 90% | ❌ bị thu hồi |

Dòng "regional RI không đảm bảo năng lực" là chi tiết hay bị hiểu sai — chỉ zonal RI và On-Demand Capacity Reservation mới giữ chỗ.

Savings Plans thường tốt hơn RI — bảng so sánh: | | Savings Plans | Reserved Instances | |---|---|---| | Cam kết theo | USD mỗi giờ | cấu hình instance cụ thể | | Đổi loại instance | ✅ tự do (Compute SP) | hạn chế | | Đổi Region | ✅ (Compute SP) | ❌ | | Áp cho Fargate và Lambda | ✅ (Compute SP) | ❌ | | Bán lại trên Marketplace | ❌ | ✅ (Standard RI) |

Hai loại Savings Plans: | Loại | Giảm giá | Linh hoạt | |---|---|---| | Compute Savings Plans | tới 66% | rất cao — mọi họ, mọi Region, cả Fargate và Lambda | | EC2 Instance Savings Plans | tới 72% | chỉ một họ trong một Region |

Với tải big data có thể đổi loại instance theo thời gian, Compute Savings Plans là lựa chọn an toàn hơn.

Ba lựa chọn thanh toán RI và Savings Plans: | Lựa chọn | Giảm giá | |---|---| | Trả trước TOÀN BỘ (All Upfront) | cao nhất | | Trả trước MỘT PHẦN (Partial) | cân bằng — thường được chọn | | Không trả trước (No Upfront) | thấp nhất, không cần vốn ban đầu |

Ba cách xác định mức nền để mua cam kết: | Cách | Chi tiết | |---|---| | Cost Explorer RI/SP Recommendations | AWS phân tích lịch sử và đề xuất con số | | Xem biểu đồ mức dùng 3–12 tháng | tìm đáy ổn định | | Mua THẬN TRỌNG rồi bổ sung | mua thiếu còn sửa được, mua thừa thì không |

Nguyên tắc quan trọng: mua cam kết ở mức bạn CHẮC CHẮN sẽ dùng.

Mua RI cho 80 máy nhưng thực tế chỉ dùng 60:
    → trả tiền cho 20 máy không tồn tại suốt cả năm
    → không huỷ được (Standard RI chỉ bán lại được trên Marketplace)

Ba chiến lược dùng spot cho phần đỉnh: | Chiến lược | Chi tiết | |---|---| | Đa dạng hoá loại instance | quan trọng nhất — nhiều pool thì ít bị thu hồi cùng lúc | | capacity-optimized | chọn pool có năng lực dồi dào | | Giữ mức on-demand tối thiểu | OnDemandPercentageAboveBaseCapacity |

Ba lưu ý về việc RI được áp dụng: | Lưu ý | Chi tiết | |---|---| | RI áp TỰ ĐỘNG cho instance khớp thuộc tính | không phải gán tay | | Regional RI có size flexibility trong cùng họ | 1 RI của m5.4xlarge = 2 RI của m5.2xlarge | | Chia sẻ RI trong Organization | bật ở tài khoản quản lý |

Chia sẻ RI giữa các tài khoản rất đáng bật — nó cho phép tận dụng hết cam kết ngay cả khi tải dịch chuyển giữa các tài khoản.

Ba công cụ theo dõi hiệu quả cam kết: | Công cụ | Việc | |---|---| | RI/SP Utilization Report | bao nhiêu phần trăm cam kết được dùng | | RI/SP Coverage Report | bao nhiêu phần trăm mức dùng được cam kết bao phủ | | Cost Anomaly Detection | phát hiện chi phí tăng bất thường |

Hai chỉ số này bổ sung nhau:

Utilization thấp  → mua THỪA, đang lãng phí
Coverage thấp     → mua THIẾU, còn cơ hội tiết kiệm
    → mục tiêu: utilization gần 100%, coverage cao ở phần nền

Và một lời khuyên: hãy cân nhắc Compute Savings Plans thay vì Reserved Instances cho tải big data. Mức giảm giá thấp hơn vài phần trăm, nhưng bạn được tự do đổi sang thế hệ instance mới hơn khi AWS ra mắt — và với chu kỳ cam kết 3 năm, thế hệ mới thường cho hiệu năng trên giá tốt hơn nhiều so với vài phần trăm chênh lệch đó.

Câu 464 Design Secure Architectures

A systems administrator has created a private hosted zone and associated it with a Virtual Private Cloud (VPC). However, the Domain Name System (DNS) queries for the private hosted zone remain unresolved.

As a Solutions Architect, can you identify the Amazon Virtual Private Cloud (Amazon VPC) options to be configured in order to get the private hosted zone to work?

  1. A

    Enable DNS hostnames and DNS resolution for private hosted zones
  2. B

    Remove any overlapping namespaces for the private and public hosted zones
  3. C

    Fix conflicts between your private hosted zone and any Resolver rule that routes traffic to your network for the same domain name, as it results in ambiguity over the route to be taken
  4. D

    Fix the Name server (NS) record and Start Of Authority (SOA) records that may have been created with wrong configurations
Xem giải thích

Đáp án

A — Bật DNS hostnames và DNS resolution cho private hosted zone.

Vì sao đúng

Đây là điều kiện tiên quyết kỹ thuật: private hosted zone KHÔNG hoạt động nếu VPC thiếu hai thuộc tính này.

Hai thuộc tính của VPC: | Thuộc tính | Việc | |---|---| | enableDnsSupport | VPC dùng máy chủ DNS của AWS (địa chỉ VPC+2) | | enableDnsHostnames | instance được gán tên DNS |

Vì sao private hosted zone cần cả hai:

Private hosted zone được phân giải bởi Route 53 Resolver
    → Resolver nằm ở địa chỉ VPC+2 (ví dụ 10.0.0.2)
        ↓
    enableDnsSupport = false
        → instance không dùng resolver của AWS
        → truy vấn không bao giờ tới được private hosted zone
        → mọi tên miền trong zone KHÔNG phân giải được

Kiểm tra và bật:

aws ec2 describe-vpc-attribute --vpc-id vpc-0abc --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-0abc --attribute enableDnsHostnames

aws ec2 modify-vpc-attribute --vpc-id vpc-0abc --enable-dns-support
aws ec2 modify-vpc-attribute --vpc-id vpc-0abc --enable-dns-hostnames

Và AWS nêu rõ đây là bước đầu tiên khi khắc phục sự cố private hosted zone — trước mọi nguyên nhân khác.

Lưu ý: VPC tạo qua console mặc định BẬT cả hai, nhưng VPC tạo bằng CloudFormation, Terraform hoặc CLI thường mặc định enableDnsHostnames = false — đó là lý do lỗi này hay xuất hiện trong môi trường dựng bằng mã.

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

  • **C. Sửa xung đột giữa private hosted zone và resolver rule cùng trỏ về mạng nội bộ cho cùng tên miền — đây là phương án gần nhất vì đó thực sự là một nguyên nhân gây sự cố DNS lai có thật, nhưng nó không phải điều kiện tiên quyết: xung đột chỉ xảy ra khi bạn đã cấu hình Resolver rule, mà đề không nhắc gì tới việc đó. Đây là nguyên nhân của tình huống phức tạp hơn.
  • **B. Gỡ không gian tên chồng lấn giữa private và public hosted zone — cũng là vấn đề có thật (split-horizon DNS), nhưng thực ra Route 53 xử lý được: private hosted zone được ưu tiên trong VPC đã gắn. Nó không làm truy vấn thất bại hoàn toàn.
  • **D. Sửa bản ghi NS và SOA bị cấu hình sai — Route 53 TỰ TẠO hai bản ghi này khi tạo hosted zone, và với private hosted zone chúng không được dùng để uỷ quyền. Chúng gần như không bao giờ là nguyên nhân.

Ghi nhớ

Hai thuộc tính DNS của VPC — bảng cần thuộc: | Thuộc tính | Mặc định (console) | Việc | |---|---|---| | enableDnsSupport | true | dùng resolver của AWS ở VPC+2 | | enableDnsHostnames | true cho VPC mặc định, false cho VPC mới tạo bằng API | gán tên DNS công khai cho instance |

Và bốn tính năng CẦN chúng: | Tính năng | Cần | |---|---| | Private hosted zone | cả hai | | VPC endpoint với private DNS | cả hai | | RDS endpoint | enableDnsSupport | | Tên DNS công khai của EC2 | enableDnsHostnames |

Public và private hosted zone — bảng phân biệt: | | Public | Private | |---|---|---| | Phân giải từ | Internet | CHỈ các VPC đã gắn | | Cần gắn VPC | ❌ | ✅ | | Yêu cầu thuộc tính DNS của VPC | ❌ | ✅ | | Dùng cho | tên miền công khai | tên miền nội bộ |

Ba bước để private hosted zone hoạt động:

① Bật enableDnsSupport và enableDnsHostnames trên VPC
② Tạo private hosted zone
③ GẮN hosted zone với VPC

Bước ba hay bị quên — tạo zone mà không gắn VPC thì không ai phân giải được.

aws route53 create-hosted-zone --name noi-bo.congty.local   --vpc VPCRegion=ap-northeast-1,VPCId=vpc-0abc   --caller-reference $(uuidgen)

# Gắn thêm VPC khác
aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z123   --vpc VPCRegion=ap-northeast-1,VPCId=vpc-0def

Ba đặc điểm của private hosted zone: | Đặc điểm | Chi tiết | |---|---| | Gắn được NHIỀU VPC, kể cả khác Region | | | Gắn VPC ở tài khoản KHÁC được | cần uỷ quyền hai bước | | Dùng tên miền tuỳ ý | kể cả tên miền công khai (split-horizon) |

Gắn VPC xuyên tài khoản cần hai bước:

# Tài khoản chứa hosted zone: uỷ quyền
aws route53 create-vpc-association-authorization --hosted-zone-id Z123   --vpc VPCRegion=ap-northeast-1,VPCId=vpc-tai-khoan-khac

# Tài khoản chứa VPC: thực hiện gắn
aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z123   --vpc VPCRegion=ap-northeast-1,VPCId=vpc-tai-khoan-khac

Split-horizon DNS là mẫu hữu ích:

Public hosted zone  congty.com  → IP công cộng của ALB
Private hosted zone congty.com  → IP RIÊNG của ALB nội bộ
    ↓
Trong VPC: dùng bản private (đi đường nội bộ, không ra Internet)
Ngoài VPC: dùng bản public

Private hosted zone LUÔN được ưu tiên trong VPC đã gắn — đó là hành vi đúng, không phải xung đột.

Thứ tự phân giải DNS trong VPC:

① Private hosted zone đã gắn với VPC
② Resolver rule (forwarding rule)
③ DNS công cộng

Bốn nguyên nhân phổ biến khi private hosted zone không hoạt động: | Nguyên nhân | Cách kiểm tra | |---|---| | Thuộc tính DNS của VPC chưa bật | describe-vpc-attribute ← câu này | | Chưa GẮN hosted zone với VPC | get-hosted-zone | | Instance dùng máy chủ DNS TUỲ CHỈNH | kiểm tra DHCP option set | | Bản ghi sai hoặc thiếu | list-resource-record-sets |

Nguyên nhân thứ ba đáng chú ý:

DHCP option set khai domain-name-servers = 8.8.8.8
    → instance KHÔNG hỏi resolver của AWS
    → private hosted zone vô hình
        ↓
    → Muốn dùng private hosted zone thì phải để AmazonProvidedDNS

Ba lệnh chẩn đoán DNS trong VPC:

# Kiểm tra instance đang dùng resolver nào
cat /etc/resolv.conf

# Hỏi thẳng resolver của AWS
dig @10.0.0.2 dich-vu.noi-bo.congty.local

# Xem bản ghi trong hosted zone
aws route53 list-resource-record-sets --hosted-zone-id Z123

Ba lưu ý về Route 53 Resolver: | Lưu ý | Chi tiết | |---|---| | Địa chỉ là VPC CIDR + 2 | và 169.254.169.253 | | Giới hạn 1.024 gói mỗi giây mỗi ENI | tải DNS rất cao có thể bị giới hạn | | Query logging ghi lại mọi truy vấn | hữu ích cho chẩn đoán và kiểm toán |

Và một lời khuyên cho môi trường dựng bằng mã: hãy khai tường minh enable_dns_hostnames = true trong Terraform hoặc CloudFormation. Giá trị mặc định của API khác với mặc định của console, và đây là nguyên nhân khiến private hosted zone hoạt động ở môi trường dựng bằng tay nhưng im lặng thất bại ở môi trường dựng tự động — một khác biệt rất khó tìm ra nếu không biết trước.

Câu 465 Design Resilient Architectures

A retail company wants to rollout and test a blue-green deployment for its global application in the next 48 hours. Most of the customers use mobile phones which are prone to Domain Name System (DNS) caching. The company has only two days left for the annual Thanksgiving sale to commence.

As a Solutions Architect, which of the following options would you recommend to test the deployment on as many users as possible in the given time frame?

  1. A

    Use Elastic Load Balancing (ELB) to distribute traffic across deployments
  2. B

    Use AWS Global Accelerator to distribute a portion of traffic to a particular deployment
  3. C

    Use Amazon Route 53 weighted routing to spread traffic across different deployments
  4. D

    Use AWS CodeDeploy deployment options to choose the right deployment
Xem giải thích

Đáp án

B — Dùng AWS Global Accelerator để chuyển một phần lưu lượng sang bản triển khai cụ thể.

Vì sao đúng

Đề nêu ba ràng buộc, và Global Accelerator là lựa chọn duy nhất thoả cả ba: | Ràng buộc | Cơ chế | |---|---| | Phần lớn người dùng dùng ĐIỆN THOẠI — hay bị CACHE DNS | Global Accelerator không phụ thuộc DNS | | Chỉ còn 48 GIỜ | chuyển lưu lượng có hiệu lực trong vài giây | | Thử nghiệm trên CÀNG NHIỀU người dùng CÀNG TỐT | traffic dial chia tỷ lệ chính xác |

Vì sao bộ đệm DNS là vấn đề then chốt:

Điện thoại di động cache DNS rất lâu:
    → hệ điều hành cache
    → trình duyệt cache
    → nhà mạng cache
    → nhiều thiết bị BỎ QUA giá trị TTL
        ↓
    Đổi bản ghi DNS → phần lớn người dùng vẫn dùng giá trị CŨ
    → trong 48 giờ, mẫu thử nghiệm quá nhỏ và không kiểm soát được

Và Global Accelerator giải quyết triệt để:

Hai địa chỉ IP anycast TĨNH — KHÔNG BAO GIỜ đổi
    → điện thoại cache IP đó cũng không sao
    → AWS đổi ĐÍCH phía sau IP
        ↓
    Chuyển lưu lượng ở tầng MẠNG, không đụng tới DNS
    → có hiệu lực trong VÀI GIÂY cho MỌI người dùng

Cấu hình chuyển tỷ lệ lưu lượng:

# Chuyển 10% sang bản triển khai mới
aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn-nhom-xanh> --traffic-dial-percentage 10

# Ổn thì tăng dần
aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn-nhom-xanh> --traffic-dial-percentage 50

# Có vấn đề thì quay lại NGAY
aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn-nhom-xanh> --traffic-dial-percentage 0

Khả năng quay lại tức thì là điều quan trọng nhất trước đợt sale Lễ Tạ ơn — nếu bản mới có vấn đề, một lệnh đưa 100% lưu lượng về bản cũ trong vài giây.

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

  • **C. Dùng Route 53 weighted routing để chia lưu lượng — đây là phương án gần nhất và là mẫu blue-green kinh điển, nhưng nó vấp đúng vấn đề mà đề nêu ra: nó dựa trên DNS, và điện thoại cache DNS khiến tỷ lệ thực tế lệch xa tỷ lệ đã đặt. Trong 48 giờ, nhiều người dùng sẽ không bao giờ tra DNS lại.
  • **A. Dùng Elastic Load Balancing phân phối giữa các bản triển khai — ALB chia được lưu lượng theo trọng số giữa target group, nhưng đề nói "global application" và ELB chỉ hoạt động trong một Region. Nó không giải quyết được bài toán ở quy mô toàn cầu.
  • **D. Dùng AWS CodeDeploy chọn kiểu triển khai phù hợp — CodeDeploy triển khai MÃ, không điều khiển lưu lượng toàn cầu: nó có blue/green cho ECS và Lambda, nhưng phạm vi là một Region và một dịch vụ, không phải chia lưu lượng giữa các bản triển khai toàn cầu.

Ghi nhớ

Ba cách chia lưu lượng cho blue-green — bảng so sánh: | Cách | Tốc độ có hiệu lực | Bị ảnh hưởng bởi cache DNS | |---|---|---| | Global Accelerator traffic dial | vài giây | ❌ KHÔNG | | Route 53 weighted routing | phụ thuộc TTL | ✅ CÓ — vấn đề lớn với di động | | ALB weighted target group | tức thì | ❌ (nhưng chỉ một Region) |

Từ khoá nhận diện:

"DNS caching", "mobile clients", "instant traffic shift", "global" → Global Accelerator "weighted routing", "gradual rollout" (không nhắc cache) → Route 53 "single Region", "between target groups" → ALB weighted

Ba đặc điểm của traffic dial: | Đặc điểm | Chi tiết | |---|---| | Giá trị 0–100 cho MỖI endpoint group | mỗi Region một dial | | Có hiệu lực trong vài giây | không chờ TTL | | Đặt 0 để rút endpoint group ra hoàn toàn | quay lại tức thì |

Và trọng số ở hai mức:

Traffic dial (mức endpoint GROUP): bao nhiêu phần trăm tới Region này
Weight (mức ENDPOINT):             chia trong nội bộ Region đó

Ba chiến lược triển khai — bảng cần thuộc: | Chiến lược | Cơ chế | |---|---| | Blue-Green | hai môi trường song song, chuyển toàn bộ | | Canary | chuyển tỷ lệ NHỎ trước (1–10%), tăng dần | | Rolling | thay từng phần của cùng một môi trường | | Linear | tăng đều theo khoảng thời gian cố định |

Với 48 giờ và mục tiêu thử trên nhiều người dùng, canary tăng dần là cách đúng:

Giờ 0–6:   10% → theo dõi tỷ lệ lỗi và độ trễ
Giờ 6–18:  30%
Giờ 18–36: 60%
Giờ 36–48: 100% (hoặc quay về 0 nếu có vấn đề)

Ba metric phải theo dõi khi chuyển dần: | Metric | Ngưỡng cảnh báo | |---|---| | Tỷ lệ lỗi 5xx | tăng so với bản cũ | | Độ trễ p99 | tăng đáng kể | | Chỉ số nghiệp vụ | tỷ lệ hoàn tất đơn hàng — quan trọng nhất |

Dòng cuối là chỉ số hay bị bỏ qua: bản mới có thể không lỗi kỹ thuật nào nhưng vẫn làm giảm tỷ lệ mua hàng — và với đợt sale, đó mới là thứ đáng lo.

Ba lý do bộ đệm DNS gây rắc rối: | Lý do | Chi tiết | |---|---| | Nhiều client BỎ QUA TTL | đặt TTL 60 giây cũng vô ích | | Nhiều tầng cache | hệ điều hành, trình duyệt, nhà mạng | | Java cache VĨNH VIỄN theo mặc định | networkaddress.cache.ttl = -1 |

Ba lợi ích khác của Global Accelerator cho ứng dụng bán lẻ toàn cầu: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp hơn | lưu lượng đi qua mạng riêng của AWS | | Chuyển vùng tự động khi Region hỏng | ~30 giây | | IP tĩnh | khách hàng doanh nghiệp đưa vào danh sách trắng |

Ba lưu ý khi chuẩn bị cho đợt sale lớn: | Lưu ý | Chi tiết | |---|---| | Làm ấm năng lực TRƯỚC | scheduled scaling, không chờ phản ứng | | Có kế hoạch quay lại rõ ràng | và đã DIỄN TẬP | | Đóng băng thay đổi trước ngày sale | không triển khai gì mới |

Dòng giữa quan trọng nhất: biết cách quay lại là chưa đủ — phải thử thật một lần để biết mất bao lâu và có tác dụng phụ gì.

Ba lưu ý khi dùng Global Accelerator cho blue-green: | Lưu ý | Chi tiết | |---|---| | Hai bản triển khai phải là endpoint riêng | hai ALB, hoặc hai endpoint group | | Health check của endpoint phải chính xác | endpoint hỏng bị rút tự động | | Trạng thái phiên phải dùng chung | người dùng có thể bị chuyển giữa hai bản |

Dòng cuối là bẫy kiến trúc: nếu phiên đăng nhập lưu cục bộ trên máy chủ, người dùng chuyển từ bản xanh sang bản lam sẽ bị đăng xuất. Trạng thái phải nằm ở ElastiCache hoặc DynamoDB dùng chung.

Và một lời khuyên: hãy giữ bản triển khai cũ chạy song song trong suốt đợt sale, kể cả sau khi đã chuyển 100% lưu lượng. Chi phí vài ngày chạy thừa là rất nhỏ so với việc phải dựng lại toàn bộ môi trường cũ vào giữa ngày cao điểm nhất trong năm.

Câu 466 Chọn nhiều đáp án Design Resilient Architectures

The engineering team at a logistics company has noticed that the Auto Scaling group (ASG) is not terminating an unhealthy Amazon EC2 instance.

As a Solutions Architect, which of the following options would you suggest to troubleshoot the issue? (Select three)

  1. A

    A user might have updated the configuration of the Auto Scaling group (ASG) and increased the minimum number of instances forcing ASG to keep all instances alive
  2. B

    The health check grace period for the instance has not expired
  3. C

    The instance maybe in Impaired status
  4. D

    The instance has failed the Elastic Load Balancing (ELB) health check status
  5. E

    The Amazon EC2 instance could be a spot instance type, which cannot be terminated by the Auto Scaling group (ASG)
  6. F

    A custom health check might have failed. The Auto Scaling group (ASG) does not terminate instances that are set unhealthy by custom checks
Xem giải thích

Đáp án

B, C và D.

  • B — Health check grace period của instance chưa hết
  • C — Instance có thể đang ở trạng thái Impaired
  • D — Instance đã trượt health check của Elastic Load Balancing

Vì sao đúng

Đề hỏi những khả năng cần kiểm tra khi chẩn đoán — và ba đáp án là ba nguyên nhân có thật.

B — grace period là nguyên nhân phổ biến nhất:

HealthCheckGracePeriod = khoảng thời gian ASG BỎ QUA health check
                          sau khi instance vào trạng thái InService
    ↓
    Trong khoảng này, instance dù hỏng cũng KHÔNG bị thay
    → mục đích: cho ứng dụng đủ thời gian khởi động

aws autoscaling describe-auto-scaling-groups   --auto-scaling-group-names asg-ung-dung   --query 'AutoScalingGroups[0].HealthCheckGracePeriod'

C — trạng thái Impaired là thứ cần kiểm tra:

EC2 có hai status check:
    ① System status check   — hạ tầng của AWS
    ② Instance status check — hệ điều hành và mạng của instance
        ↓
    Một trong hai trượt → instance ở trạng thái "impaired"
    → với HealthCheckType = EC2, ASG SẼ thay
    → nhưng cần kiểm tra xem nó có thật sự đang impaired không,
      hay chỉ ứng dụng hỏng mà OS vẫn chạy

D — trượt health check của ELB:

Với HealthCheckType = ELB:
    → ASG thay instance mà load balancer đánh giá hỏng

Với HealthCheckType = EC2 (mặc định):
    → ASG KHÔNG BIẾT ứng dụng đã hỏng
    → ALB ngừng gửi lưu lượng, nhưng ASG để yên
        ↓
    Đây là nguyên nhân số một khiến máy hỏng nằm mãi không được thay

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung --health-check-type ELB

Ba đáp án tạo thành một danh sách kiểm tra hợp lý: grace period còn hiệu lực → kiểm tra trạng thái thật của instance → kiểm tra loại health check đang dùng.

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

  • **F. Custom health check trượt, và "ASG KHÔNG chấm dứt instance bị đánh dấu hỏng bởi custom check" — đây là phương án gần nhất vì custom health check thực sự tồn tại, nhưng mệnh đề sau SAI: ASG CÓ chấm dứt instance được đánh dấu Unhealthy qua SetInstanceHealth. Đó chính là mục đích của cơ chế đó.
  • **A. Có người tăng MinSize khiến ASG phải giữ mọi instance sống — hiểu sai cơ chế: MinSize quyết định SỐ LƯỢNG máy, không quyết định máy NÀO được giữ. ASG vẫn chấm dứt máy hỏng và khởi động máy mới để duy trì số lượng.
  • **E. Instance là spot instance nên ASG không chấm dứt được — sai hoàn toàn: ASG quản lý và chấm dứt được spot instance bình thường.

Ghi nhớ

Bốn nguyên nhân ASG không thay instance hỏng — bảng chẩn đoán: | Nguyên nhân | Cách kiểm tra | |---|---| | HealthCheckType = EC2 mà ứng dụng hỏng | describe-auto-scaling-groups | | Grace period chưa hết | so thời gian InService với grace period | | Instance ở trạng thái Standby | describe-auto-scaling-instances | | Scale-in protection đang bật | ProtectedFromScaleIn |

Ba loại health check của ASG: | Loại | Kiểm tra gì | |---|---| | EC2 (mặc định) | chỉ status check của instance | | ELB | health check của load balancer — kiểm tra ỨNG DỤNG | | Custom | bạn tự gọi SetInstanceHealth |

Bảng khác biệt giữa EC2 và ELB health check: | Tình huống | EC2 check | ELB check | |---|---|---| | Instance bị tắt | ❌ trượt | ❌ trượt | | Hệ điều hành treo | ❌ trượt | ❌ trượt | | Ứng dụng crash, OS chạy | ✅ PASS | ❌ trượt | | Ứng dụng trả về 500 | ✅ PASS | ❌ trượt | | Đĩa đầy, ứng dụng không phản hồi | ✅ PASS | ❌ trượt |

Ba dòng cuối cho thấy vì sao HealthCheckType = ELB gần như luôn là lựa chọn đúng.

Custom health check qua SetInstanceHealth:

aws autoscaling set-instance-health --instance-id i-0abc   --health-status Unhealthy --no-should-respect-grace-period

Tuỳ chọn --no-should-respect-grace-period bỏ qua grace period — dùng khi chắc chắn máy hỏng.

Ba trường hợp dùng custom health check: | Trường hợp | Ví dụ | |---|---| | Kiểm tra sâu hơn HTTP | kết nối được database không | | Kiểm tra logic nghiệp vụ | hàng đợi nội bộ có kẹt không | | Tích hợp công cụ giám sát ngoài | Datadog, Nagios |

Hai status check của EC2: | Check | Ai chịu trách nhiệm | |---|---| | System status check | AWS — phần cứng, mạng, nguồn điện | | Instance status check | BẠN — hệ điều hành, cấu hình mạng, đĩa đầy | | Attached EBS status check | tình trạng volume gắn kèm |

Cách xử lý khác nhau:

System status check trượt:
    → STOP rồi START (máy chuyển sang phần cứng khác)
    → reboot KHÔNG giúp gì

Instance status check trượt:
    → thường do OS — kiểm tra log, reboot có thể giúp

Ba cấu hình quan trọng liên quan: | Cấu hình | Giá trị nên dùng | |---|---| | HealthCheckType | ELB | | HealthCheckGracePeriod | dài hơn thời gian khởi động ứng dụng | | Health check của target group | interval và threshold hợp lý |

Grace period quá NGẮN gây vòng lặp chấm dứt:

Ứng dụng cần 4 phút khởi động, grace period 60 giây:
    → máy mới bị đánh giá hỏng trước khi kịp sẵn sàng
    → ASG chấm dứt và khởi động máy khác
    → LẶP VÔ TẬN, không bao giờ có máy phục vụ

Và grace period quá DÀI thì máy hỏng nằm lâu:

Grace period 15 phút:
    → máy hỏng ngay sau khi khởi động vẫn được giữ 15 phút
        ↓
    → Đặt vừa đủ: thời gian khởi động thật + biên độ an toàn

Ba nơi để chẩn đoán: | Nơi | Thông tin | |---|---| | Activity history của ASG | lý do cụ thể của từng scaling activity | | Target group health | trạng thái từng target và lý do trượt | | CloudWatch Logs của ứng dụng | vì sao ứng dụng hỏng |

Activity history nói rất rõ:

"An instance was taken out of service in response to
 an ELB system health check failure."
"An instance was taken out of service in response to
 an EC2 instance status checks failure."

Ba lệnh chẩn đoán nhanh:

aws autoscaling describe-scaling-activities   --auto-scaling-group-name asg-ung-dung --max-items 10

aws elbv2 describe-target-health --target-group-arn <arn-tg>

aws ec2 describe-instance-status --instance-ids i-0abc

Và một lời khuyên: hãy kiểm tra HealthCheckType đầu tiên khi gặp tình huống này. Đó là nguyên nhân phổ biến nhất và cũng dễ sửa nhất — một lệnh, không gián đoạn, và nó biến ASG từ "đếm số máy đang chạy" thành "đảm bảo số máy đang phục vụ", vốn là điều bạn thật sự cần.

Câu 467 Design Resilient Architectures

An e-commerce application uses an Amazon Aurora Multi-AZ deployment for its database. While analyzing the performance metrics, the engineering team has found that the database reads are causing high input/output (I/O) and adding latency to the write requests against the database.

As an AWS Certified Solutions Architect Associate, what would you recommend to separate the read requests from the write requests?

  1. A

    Activate read-through caching on the Amazon Aurora database
  2. B

    Configure the application to read from the Multi-AZ standby instance
  3. C

    Set up a read replica and modify the application to use the appropriate endpoint
  4. D

    Provision another Amazon Aurora database and link it to the primary database as a read replica
Xem giải thích

Đáp án

C — Dựng read replica và sửa ứng dụng để dùng endpoint phù hợp.

Vì sao đúng

Đề mô tả vấn đề rõ: truy vấn ĐỌC gây I/O cao và làm chậm truy vấn GHI.

Mọi truy vấn đổ vào MỘT instance (writer)
    → đọc và ghi tranh nhau tài nguyên
    → truy vấn đọc nặng chiếm I/O
    → truy vấn ghi phải xếp hàng chờ
        ↓
    Giải pháp: TÁCH đọc sang instance khác

Và với Aurora, đó là thêm reader instance:

Cụm Aurora:
    Writer instance   ← nhận mọi INSERT, UPDATE, DELETE
    Reader instance 1 ← nhận SELECT
    Reader instance 2 ← nhận SELECT
        ↓
    Tất cả dùng chung TẦNG LƯU TRỮ — không sao chép dữ liệu

Aurora khác RDS thường ở điểm này: | | RDS read replica | Aurora reader | |---|---|---| | Cơ chế | sao chép ở tầng DATABASE | dùng chung TẦNG LƯU TRỮ | | Độ trễ | giây | thường dưới 100ms | | Thêm replica | tốn thời gian sao chép dữ liệu | rất nhanh, không sao chép | | Số lượng tối đa | 5 (hoặc 15 tuỳ engine) | 15 |

Và vế "dùng endpoint phù hợp" là phần quan trọng:

aws rds create-db-instance --db-instance-identifier reader-1   --db-cluster-identifier cum-thuong-mai   --engine aurora-mysql --db-instance-class db.r6g.large

# Ghi → cluster endpoint
ket_noi_ghi = connect(host='cum.cluster-abc123.ap-northeast-1.rds.amazonaws.com')
# Đọc → READER endpoint (tự cân bằng tải qua các reader)
ket_noi_doc = connect(host='cum.cluster-ro-abc123.ap-northeast-1.rds.amazonaws.com')

Reader endpoint tự cân bằng tải giữa mọi reader instance — thêm reader là tự động được dùng.

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

  • **D. Dựng một Aurora database KHÁC rồi liên kết làm read replica của database chính — đây là phương án gần nhất và có tồn tại cơ chế tương tự (Aurora cross-Region replica, hoặc replica từ RDS MySQL), nhưng nó phức tạp và tốn kém hơn hẳn: bạn tạo thêm một cụm riêng với tầng lưu trữ riêng, phải sao chép dữ liệu, và chịu độ trễ sao chép lớn hơn. Thêm reader instance vào chính cụm hiện có là cách đúng.
  • **B. Cấu hình ứng dụng đọc từ standby instance của Multi-AZ — không làm được: standby của Multi-AZ (RDS instance) KHÔNG phục vụ đọc. Nó chỉ tồn tại để chuyển đổi. (Aurora không có khái niệm standby riêng — mọi reader đều phục vụ đọc.)
  • **A. Bật read-through caching trên Aurora — không có tính năng nào tên như vậy. Aurora có buffer pool nội bộ, nhưng "read-through caching" là khái niệm của ElastiCache, không phải một công tắc bật trong Aurora.

Ghi nhớ

Bốn endpoint của Aurora — bảng cần thuộc: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance GHI hiện tại — tự đổi sau failover | | Reader | cân bằng tải qua MỌI reader instance | | Instance | một instance cụ thể | | Custom | nhóm instance do bạn định nghĩa |

Custom endpoint rất hữu ích cho phân tách tải:

aws rds create-db-cluster-endpoint --db-cluster-identifier cum-thuong-mai   --db-cluster-endpoint-identifier bao-cao --endpoint-type READER   --static-members reader-bao-cao-1

Reader endpoint  → reader nhỏ, phục vụ truy vấn ứng dụng
Custom endpoint  → reader LỚN, phục vụ truy vấn báo cáo nặng
    → truy vấn báo cáo không làm chậm ứng dụng

Ba cách giảm tải đọc cho database: | Cách | Đặc điểm | |---|---| | Read replica | mở rộng đọc thật sự ← câu này | | ElastiCache | loại bỏ hẳn truy vấn lặp lại | | Tối ưu truy vấn và index | thường hiệu quả nhất mà rẻ nhất |

Ba cách nên thử theo thứ tự:

① Tìm truy vấn chậm (Performance Insights) và tối ưu
② Đệm kết quả hay dùng (ElastiCache)
③ Thêm read replica

Thêm replica cho một truy vấn thiếu index chỉ là trả tiền để chạy nhanh hơn một chút cái vốn sai.

Ba lưu ý về độ trễ sao chép: | Lưu ý | Chi tiết | |---|---| | Aurora: thường dưới 100ms | rất thấp nhờ dùng chung lưu trữ | | Không dùng replica cho ĐỌC-SAU-GHI | người dùng vừa cập nhật hồ sơ có thể thấy dữ liệu cũ | | Theo dõi AuroraReplicaLag | tăng dần là dấu hiệu bất thường |

Mẫu xử lý đọc-sau-ghi:

def cap_nhat_ho_so(ma, du_lieu):
    ghi_vao_writer(ma, du_lieu)
    danh_dau_vua_ghi(ma, thoi_han=5)   # đánh dấu trong 5 giây

def doc_ho_so(ma):
    if vua_ghi(ma):
        return doc_tu_writer(ma)   # đọc từ writer để thấy dữ liệu mới
    return doc_tu_reader(ma)

Ba tính năng của Aurora để mở rộng đọc: | Tính năng | Chi tiết | |---|---| | Aurora Auto Scaling cho reader | tự thêm bớt reader theo CPU hoặc số kết nối | | Aurora Serverless v2 | tự co giãn năng lực từng instance | | Aurora Global Database | reader ở Region khác |

Auto Scaling cho reader rất phù hợp với thương mại điện tử:

aws application-autoscaling register-scalable-target   --service-namespace rds --resource-id cluster:cum-thuong-mai   --scalable-dimension rds:cluster:ReadReplicaCount   --min-capacity 2 --max-capacity 8

aws application-autoscaling put-scaling-policy   --policy-name giu-cpu-reader --service-namespace rds   --resource-id cluster:cum-thuong-mai   --scalable-dimension rds:cluster:ReadReplicaCount   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration     '{"TargetValue":60.0,"PredefinedMetricSpecification":
      {"PredefinedMetricType":"RDSReaderAverageCPUUtilization"}}'

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | AuroraReplicaLag | độ trễ sao chép | | ReadIOPS và WriteIOPS | phân bố tải | | DatabaseConnections | gần trần thì cần RDS Proxy |

Và Performance Insights là công cụ chẩn đoán tốt nhất:

Performance Insights cho biết:
    ✓ truy vấn nào tốn nhiều tài nguyên nhất
    ✓ đang chờ ở đâu (I/O, khoá, CPU)
    ✓ so sánh theo thời gian
        ↓
    Thường tìm ra một hai truy vấn chiếm phần lớn tải

Ba lưu ý khi thêm reader: | Lưu ý | Chi tiết | |---|---| | Reader nên CÙNG CỠ với writer | reader nhỏ hơn sẽ tụt lại phía sau | | Đặt ở AZ khác | vừa mở rộng đọc vừa tăng sẵn sàng | | Đặt PromotionTier | quyết định reader nào được chọn khi failover |

PromotionTier là chi tiết hữu ích:

Tier 0–15, số nhỏ được ưu tiên promote khi writer hỏng
    → đặt reader cùng cỡ writer ở tier 0
    → đặt reader nhỏ (dùng cho báo cáo) ở tier 15

Và một lời khuyên: hãy kiểm chứng ứng dụng thật sự đang dùng reader endpoint sau khi sửa. Rất thường gặp trường hợp mã được sửa nhưng một thư viện ORM hoặc một tác vụ nền vẫn dùng chuỗi kết nối cũ — và bạn trả tiền cho reader mà tải trên writer không giảm chút nào. Metric ReadIOPS trên từng instance cho biết ngay điều đó.

Câu 468 Design Cost-Optimized Architectures

An IT company wants to optimize the costs incurred on its fleet of 100 Amazon EC2 instances for the next year. Based on historical analyses, the engineering team observed that 70 of these instances handle the compute services of its flagship application and need to be always available. The other 30 instances are used to handle batch jobs that can afford a delay in processing.

As a solutions architect, which of the following would you recommend as the MOST cost-optimal solution?

  1. A

    Purchase 70 on-demand instances and 30 reserved instances
  2. B

    Purchase 70 reserved instances (RIs) and 30 spot instances
  3. C

    Purchase 70 reserved instances and 30 on-demand instances
  4. D

    Purchase 70 on-demand instances and 30 spot instances
Xem giải thích

Đáp án

B — Mua 70 Reserved Instances và dùng 30 Spot Instances.

Vì sao đúng

Đề chia rõ hai loại tải, và mỗi loại có mô hình mua đúng của nó: | Nhóm | Đặc điểm | Mô hình đúng | |---|---|---| | 70 máy chạy ứng dụng chính, PHẢI LUÔN SẴN SÀNG | ổn định, 24/7, cả năm | Reserved Instances | | 30 máy chạy job theo lô, CHẤP NHẬN ĐƯỢC TRỄ | chịu được gián đoạn | Spot Instances |

70 máy → RI vì tải ổn định và biết trước:

"need to be ALWAYS AVAILABLE" + tối ưu cho CẢ NĂM TỚI
    ↓
    → khối lượng biết trước, chạy liên tục
    → cam kết 1 năm giảm 40–60% so với on-demand
    → và RI (zonal) còn đảm bảo năng lực

30 máy → Spot vì chịu được gián đoạn:

"batch jobs that can AFFORD A DELAY in processing"
    ↓
    → đây là định nghĩa của tải phù hợp với Spot
    → giảm tới 90%
    → bị thu hồi thì job chạy lại sau, không ai bị ảnh hưởng

Phép so sánh chi phí tương đối cho 100 máy một năm: | Phương án | 70 máy | 30 máy | Tổng | |---|---|---|---| | B (RI + Spot) | ~55 | ~5 | ~60 ✅ | | C (RI + On-demand) | ~55 | 30 | ~85 | | D (On-demand + Spot) | 70 | ~5 | ~75 | | A (On-demand + RI) | 70 | ~23 | ~93 |

B rẻ nhất vì nó ghép đúng mô hình mua với đúng đặc tính tải.

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

  • **C. Mua 70 RI và 30 ON-DEMAND — đây là phương án gần nhất và vế 70 RI hoàn toàn đúng, nhưng vế thứ hai bỏ lỡ khoản tiết kiệm lớn nhất: đề nói rõ job theo lô chịu được trễ, tức là chịu được gián đoạn — đúng điều kiện của Spot. Trả giá on-demand cho chúng là trả gấp khoảng 6 lần mà không nhận thêm giá trị nào.
  • **D. Mua 70 ON-DEMAND và 30 Spot — vế Spot đúng nhưng bỏ lỡ RI cho phần nền: 70 máy chạy liên tục cả năm là mẫu tải hoàn hảo cho cam kết dài hạn.
  • **A. Mua 70 on-demand và 30 RI — đảo ngược hoàn toàn: dùng cam kết dài hạn cho phần chịu được gián đoạn, và trả giá cao nhất cho phần chạy liên tục.

Ghi nhớ

Nguyên tắc ghép mô hình mua với đặc tính tải — bảng phải thuộc:

Tải ỔN ĐỊNH, chạy liên tục
    → Savings Plans hoặc Reserved Instances (giảm tới 72%)

Tải BIẾN ĐỘNG, cần đảm bảo, ngắn hạn
    → On-Demand

Tải CHỊU ĐƯỢC GIÁN ĐOẠN
    → Spot (giảm tới 90%)

Từ khoá nhận diện trong đề thi:

"always available", "24/7", "steady state", "predictable" → RI hoặc Savings Plans "can afford delay", "fault-tolerant", "flexible timing", "batch" → Spot "unpredictable", "short-term spike", "temporary" → On-Demand

Bốn mô hình mua — bảng so sánh: | Mô hình | Cam kết | Giảm giá | Đảm bảo năng lực | |---|---|---|---| | On-Demand | không | 0% | ✅ | | Savings Plans | 1 hoặc 3 năm | tới 72% | ❌ | | RI (zonal) | 1 hoặc 3 năm | tới 72% | ✅ | | RI (regional) | 1 hoặc 3 năm | tới 72% | ❌ | | Spot | không | tới 90% | ❌ |

Savings Plans thường tốt hơn RI: | | Savings Plans | RI | |---|---|---| | Cam kết theo | USD mỗi giờ | cấu hình cụ thể | | Đổi loại instance, Region | ✅ (Compute SP) | hạn chế | | Áp cho Fargate và Lambda | ✅ (Compute SP) | ❌ |

Ba đặc điểm của Spot cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Báo trước 2 phút khi bị thu hồi | qua metadata và EventBridge | | Không đảm bảo năng lực | pool có thể hết máy | | Giá thay đổi theo cung cầu | nhưng ổn định hơn nhiều so với trước 2017 |

Ba cách tăng độ ổn định của Spot: | Cách | Chi tiết | |---|---| | Đa dạng hoá loại instance và AZ | quan trọng nhất | | Chiến lược capacity-optimized | chọn pool dồi dào nhất | | Xử lý êm khi bị thu hồi | lưu checkpoint trong 2 phút |

Cấu hình ASG cho 30 máy chạy job theo lô:

{"MixedInstancesPolicy": {
   "InstancesDistribution": {
     "OnDemandBaseCapacity": 0,
     "OnDemandPercentageAboveBaseCapacity": 0,
     "SpotAllocationStrategy": "capacity-optimized"},
   "LaunchTemplate": {"Overrides": [
     {"InstanceType": "m5.2xlarge"}, {"InstanceType": "m5a.2xlarge"},
     {"InstanceType": "m6i.2xlarge"}, {"InstanceType": "m5n.2xlarge"},
     {"InstanceType": "m6a.2xlarge"}]}}}

Càng nhiều loại instance thay thế được, càng ít bị thu hồi đồng loạt.

Và AWS Batch là lựa chọn ít công nhất cho job theo lô:

AWS Batch:
    ✓ tự quản lý hàng đợi công việc và mức ưu tiên
    ✓ tự cấp và thu hồi năng lực tính toán
    ✓ TỰ THỬ LẠI khi job bị gián đoạn
    ✓ dùng Spot với chiến lược tối ưu sẵn

Đây là cách vận hành 30 máy Spot mà không phải tự viết logic phục hồi.

Ba dịch vụ tự dùng Spot rất tốt: | Dịch vụ | Chi tiết | |---|---| | AWS Batch | xử lý lô — phù hợp nhất với đề | | EMR | node lõi On-Demand, node task Spot | | ECS/EKS với Fargate Spot | container không trạng thái |

Ba cách xác định mức nền để mua cam kết: | Cách | Chi tiết | |---|---| | Cost Explorer RI/SP Recommendations | AWS phân tích lịch sử và đề xuất | | Xem biểu đồ mức dùng 3–12 tháng | tìm đáy ổn định | | Mua thận trọng rồi bổ sung | mua thiếu sửa được, mua thừa thì không |

Ba công cụ theo dõi hiệu quả: | Công cụ | Việc | |---|---| | RI/SP Utilization | bao nhiêu phần trăm cam kết được dùng — mục tiêu gần 100% | | RI/SP Coverage | bao nhiêu phần trăm mức dùng được cam kết bao phủ | | Spot Instance Advisor | tần suất bị thu hồi của từng loại instance |

Ba lưu ý khi dùng Spot cho job theo lô: | Lưu ý | Chi tiết | |---|---| | Job phải có checkpoint hoặc chia nhỏ | bị thu hồi không mất hết công | | Xử lý thông báo thu hồi trong 2 phút | lưu trạng thái, thoát sạch | | Đặt hàng đợi bền vững phía trước | SQS giữ công việc chưa xong |

Mẫu chuẩn cho job theo lô dùng Spot:

SQS queue (công việc chờ)
    ↓ worker Spot đọc và xử lý
    ↓ visibility timeout dài hơn thời gian xử lý
Bị thu hồi giữa chừng
    → thông điệp quay lại hàng đợi sau khi hết visibility timeout
    → worker khác nhận và làm lại
        ↓
    KHÔNG mất công việc nào

Và một lời khuyên: hãy mua cam kết theo từng đợt nhỏ thay vì mua hết 70 máy một lần. Mua 40 máy trước, theo dõi báo cáo utilization vài tháng, rồi bổ sung — cách đó tránh được rủi ro cam kết cho năng lực mà tổ chức không thực sự cần suốt cả năm.

Câu 469 Design Secure Architectures

A developer needs to implement an AWS Lambda function in AWS account A that accesses an Amazon Simple Storage Service (Amazon S3) bucket in AWS account B.

As a Solutions Architect, which of the following will you recommend to meet this requirement?

  1. A

    The Amazon S3 bucket owner should make the bucket public so that it can be accessed by the AWS Lambda function in the other AWS account
  2. B

    Create an IAM role for the AWS Lambda function that grants access to the Amazon S3 bucket. Set the IAM role as the AWS Lambda function's execution role. Make sure that the bucket policy also grants access to the AWS Lambda function's execution role
  3. C

    AWS Lambda cannot access resources across AWS accounts. Use Identity federation to work around this limitation of Lambda
  4. D

    Create an IAM role for the AWS Lambda function that grants access to the Amazon S3 bucket. Set the IAM role as the Lambda function's execution role and that would give the AWS Lambda function cross-account access to the Amazon S3 bucket
Xem giải thích

Đáp án

B — Tạo IAM role cho Lambda có quyền truy cập bucket S3, đặt role đó làm execution role của hàm, VÀ đảm bảo bucket policy cũng cấp quyền cho execution role đó.

Vì sao đúng

Điểm mấu chốt: truy cập S3 xuyên tài khoản đòi quyền được cấp ở CẢ HAI PHÍA.

Tài khoản A (Lambda)              Tài khoản B (S3 bucket)
   Execution role                    Bucket policy
   "được phép gọi s3:GetObject"  +   "cho phép role đó truy cập"
        ↓                                    ↓
              CẢ HAI đều phải cho phép

Vì sao khác với truy cập trong CÙNG tài khoản:

Cùng tài khoản:
    → chỉ cần MỘT bên cho phép (identity policy HOẶC bucket policy)

KHÁC tài khoản:
    → phải CẢ HAI bên cho phép
    → thiếu một bên = AccessDenied

① Identity policy của execution role (tài khoản A):

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::kho-tai-khoan-b/*"}

② Bucket policy (tài khoản B):

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::111122223333:role/vai-tro-lambda"},
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::kho-tai-khoan-b/*"}

Và đây là ưu điểm so với việc đảm nhận role xuyên tài khoản:

Cách này: Lambda gọi S3 TRỰC TIẾP bằng execution role
    → không cần gọi sts:AssumeRole
    → mã đơn giản hơn
    → ít độ trễ hơn

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

  • **D. Tạo IAM role cho Lambda và đặt làm execution role, và điều đó ĐỦ để có quyền xuyên tài khoản — đây là phương án gần nhất và là bẫy chính: nó giống hệt đáp án B nhưng thiếu vế bucket policy. Với tài nguyên ở tài khoản khác, identity policy một mình không đủ — chủ sở hữu bucket phải chủ động cho phép.
  • **A. Chủ bucket để bucket ở chế độ CÔNG KHAI — rủi ro bảo mật nghiêm trọng và không cần thiết: nó phơi dữ liệu cho toàn Internet trong khi chỉ cần cấp quyền cho một role cụ thể. Block Public Access hiện cũng bật mặc định để ngăn điều này.
  • **C. Lambda không truy cập được tài nguyên xuyên tài khoản, phải dùng identity federation — sai hoàn toàn: đây là kịch bản được hỗ trợ đầy đủ và rất phổ biến.

Ghi nhớ

Quy tắc đánh giá quyền — bảng cần thuộc: | Ngữ cảnh | Yêu cầu | |---|---| | CÙNG tài khoản | identity policy HOẶC resource policy cho phép | | KHÁC tài khoản | CẢ identity policy LẪN resource policy đều phải cho phép |

Và explicit Deny ở bất kỳ đâu đều thắng mọi Allow.

Hai cách truy cập tài nguyên xuyên tài khoản: | Cách | Đặc điểm | |---|---| | Resource-based policy | gọi TRỰC TIẾP, không đổi thông tin đăng nhập ← câu này | | sts:AssumeRole | đổi sang danh tính của tài khoản kia |

Bảng so sánh: | | Resource policy | AssumeRole | |---|---|---| | Số lời gọi API | 1 | 2 (assume + thao tác) | | Danh tính trong CloudTrail của bên kia | role gốc của tài khoản A | role của tài khoản B | | Quyền hiệu lực | giao của hai chính sách | chỉ quyền của role được đảm nhận | | Dịch vụ hỗ trợ | S3, SQS, SNS, KMS, Secrets Manager, Lambda... | mọi dịch vụ |

Các dịch vụ có resource-based policy: | Dịch vụ | Tên gọi | |---|---| | S3 | bucket policy | | SQS, SNS | queue/topic policy | | KMS | key policy | | Lambda | resource policy (cho phép ai gọi hàm) | | Secrets Manager | resource policy | | EFS | file system policy | | ECR, API Gateway, EventBridge | resource policy |

Ba cạm bẫy của truy cập S3 xuyên tài khoản: | Cạm bẫy | Chi tiết | |---|---| | Object do tài khoản KHÁC ghi vào | chủ bucket có thể không đọc được | | Bucket mã hoá bằng KMS | key policy cũng phải cho phép | | Block Public Access | không ảnh hưởng truy cập xuyên tài khoản có chỉ định principal |

Cạm bẫy đầu tiên đáng nói kỹ:

Lambda ở tài khoản A ghi object vào bucket của tài khoản B
    → object thuộc sở hữu của tài khoản A (theo ACL cũ)
    → chủ bucket (B) KHÔNG đọc được object trong bucket của chính mình
        ↓
    Cách sửa hiện đại: bật S3 Object Ownership = BucketOwnerEnforced
    → ACL bị vô hiệu, chủ bucket LUÔN sở hữu mọi object
    → mặc định cho bucket mới từ tháng 4 năm 2023

Và với bucket mã hoá bằng KMS, phải cấp quyền ở ba chỗ:

// Key policy của tài khoản B
{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::111122223333:role/vai-tro-lambda"},
 "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
 "Resource": "*"}

① Identity policy: s3:GetObject VÀ kms:Decrypt
② Bucket policy:   s3:GetObject
③ Key policy:      kms:Decrypt
    → thiếu bước ba là AccessDenied với thông báo khó hiểu

Đây là nguyên nhân số một của lỗi "AccessDenied" khó chẩn đoán trong truy cập S3 xuyên tài khoản.

Ba lưu ý về execution role của Lambda: | Lưu ý | Chi tiết | |---|---| | Cần AWSLambdaBasicExecutionRole để ghi log | nếu không, log không xuất hiện | | Trong VPC thì cần thêm quyền ENI | AWSLambdaVPCAccessExecutionRole | | Đặc quyền tối thiểu | chỉ prefix và hành động thật sự cần |

Ví dụ chính sách chặt chẽ:

{"Effect": "Allow",
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho-tai-khoan-b/du-lieu-vao/*"}

Giới hạn tới prefix, không dùng * cho cả bucket.

Ba cách viết principal trong bucket policy: | Cách | Chi tiết | |---|---| | ARN của role cụ thể | chặt nhất ← nên dùng | | arn:aws:iam::111122223333:root | uỷ quyền cho cả tài khoản A tự quyết | | Điều kiện aws:PrincipalOrgID | mọi tài khoản trong Organization |

Điều kiện PrincipalOrgID rất tiện cho nhiều tài khoản:

{"Effect": "Allow", "Principal": "*",
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho-chung/*",
 "Condition": {"StringEquals":
   {"aws:PrincipalOrgID": "o-abc123xyz"}}}

Không phải sửa policy mỗi khi thêm tài khoản mới vào Organization.

Ba công cụ chẩn đoán lỗi quyền: | Công cụ | Việc | |---|---| | CloudTrail | xem lời gọi bị từ chối và principal nào gọi | | IAM Policy Simulator | thử một hành động, xem chính sách nào chặn | | IAM Access Analyzer | tìm tài nguyên đang chia sẻ ra ngoài tài khoản |

Và Access Analyzer nên bật ở mọi tài khoản:

aws accessanalyzer create-analyzer --analyzer-name phan-tich-truy-cap   --type ACCOUNT

Nó phát hiện bucket, role, khoá KMS đang cho phép truy cập từ ngoài — vừa là công cụ bảo mật vừa là cách kiểm chứng cấu hình xuyên tài khoản đúng như dự định.

Và một lời khuyên: hãy kiểm chứng bằng cách gọi thật từ Lambda, đừng chỉ đọc chính sách. Với truy cập xuyên tài khoản có mã hoá KMS, số tầng quyền đủ nhiều để việc đọc chính sách bằng mắt gần như luôn bỏ sót một chỗ — và thông báo AccessDenied của S3 cố ý không nói rõ tầng nào từ chối, vì lý do bảo mật.

Câu 470 Design Resilient Architectures

A wildlife research organization uses IoT-based motion sensors attached to thousands of migrating animals to monitor their movement across regions. Every few minutes, a sensor checks for significant movement and sends updated location data to a backend application running on Amazon EC2 instances spread across multiple Availability Zones in a single AWS Region. Recently, an unexpected surge in motion data overwhelmed the application, leading to lost location records with no mechanism to replay missed data. A solutions architect must redesign the ingestion mechanism to prevent future data loss and to minimize operational overhead.

What should the solutions architect do to meet these requirements?

  1. A

    Deploy an Amazon Data Firehose delivery stream to collect the motion data. Configure it to deliver data to an S3 bucket where the application scans and processes the files periodically
  2. B

    Create an Amazon Simple Queue Service (Amazon SQS) queue to buffer the incoming location data. Configure the backend application to poll the queue and process messages
  3. C

    Set up a containerized service using Amazon ECS with an internal queue built into the application layer. Configure the motion sensors to send location updates directly to the container endpoints
  4. D

    Implement an AWS IoT Core rule to route location updates directly from each sensor to Amazon SNS. Configure the application to poll the SNS topic for new messages
Xem giải thích

Đáp án

B — Tạo Amazon SQS queue làm vùng đệm cho dữ liệu vị trí gửi về; cấu hình ứng dụng nền đọc hàng đợi và xử lý thông điệp.

Vì sao đúng

Đề mô tả đúng triệu chứng của một hệ thống thiếu vùng đệm:

Đột biến dữ liệu chuyển động
    → EC2 nhận trực tiếp, không kịp xử lý
    → bản ghi vị trí BỊ MẤT
    → không có cách nào lấy lại

Và hàng đợi giải quyết đúng nguyên nhân gốc:

Cảm biến → SQS (nhận NGAY, lưu bền)
              ↓
         EC2 đọc theo tốc độ của mình
              ↓
    Đỉnh tải được HẤP THỤ, không có bản ghi nào bị bỏ

Đây là mẫu "queue-based load levelling" — hàng đợi làm phẳng đỉnh tải xuống mức mà tầng xử lý chịu được.

Ba đảm bảo của SQS phù hợp với yêu cầu: | Đảm bảo | Chi tiết | |---|---| | Lưu bền | thông điệp được sao chép qua nhiều AZ | | Giữ tới 14 ngày | tầng xử lý ngừng vài giờ cũng không mất gì | | Chỉ xoá khi consumer XÁC NHẬN | xử lý hỏng thì thông điệp quay lại |

Và về công vận hành, SQS gần như bằng 0:

SQS:
    ✓ không có gì để cấp phát
    ✓ không có shard để quản lý
    ✓ tự nhận mọi khối lượng

Cấu hình co giãn tầng xử lý theo hàng đợi:

aws cloudwatch put-metric-alarm --alarm-name hang-doi-day   --metric-name ApproximateNumberOfMessagesVisible   --namespace AWS/SQS --dimensions Name=QueueName,Value=vi-tri-dong-vat   --statistic Average --period 300 --threshold 10000   --comparison-operator GreaterThanThreshold

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

  • **A. Dùng Amazon Data Firehose đưa dữ liệu vào S3, ứng dụng quét và xử lý tệp định kỳ — đây là phương án gần nhất và cũng chống mất dữ liệu, nhưng nó kém phù hợp về độ trễ và công vận hành: Firehose gom dữ liệu theo lô (tối thiểu 60 giây, thường vài phút), rồi ứng dụng phải tự quét thư mục S3 — thêm logic theo dõi tệp nào đã xử lý, tệp nào chưa. Với dữ liệu vị trí cần xử lý gần thời gian thực, đây là bước lùi.
  • **C. Dựng ECS với hàng đợi NỘI BỘ trong tầng ứng dụng, cảm biến gửi thẳng tới container — không giải quyết vấn đề gì: hàng đợi trong bộ nhớ của ứng dụng mất hết khi container khởi động lại, và nó vẫn nằm trong cùng tiến trình đang quá tải.
  • **D. Dùng IoT Core rule đẩy sang SNS, ứng dụng "poll SNS topic" — sai về mặt kỹ thuật: SNS là mô hình đẩy (push), không poll được. Và SNS không lưu bền — subscriber không nhận được thì thông điệp mất.

Ghi nhớ

Bốn dịch vụ nhắn tin và luồng dữ liệu — bảng cần thuộc: | Dịch vụ | Mô hình | Lưu bền | Đọc lại được | |---|---|---|---| | SQS | hàng đợi, kéo (pull) | ✅ tới 14 ngày | ❌ xoá sau khi xử lý | | SNS | phát tán, đẩy (push) | ❌ | ❌ | | Kinesis Data Streams | luồng, kéo | ✅ tới 365 ngày | ✅ ĐỌC LẠI ĐƯỢC | | Data Firehose | luồng, giao thẳng vào đích | ❌ (đích lưu) | qua đích |

Từ khoá nhận diện:

"buffer", "decouple", "prevent data loss", "least overhead" → SQS "replay", "multiple independent consumers", "ordered" → Kinesis Data Streams "fan-out to many subscribers" → SNS "deliver to S3/Redshift/OpenSearch" → Firehose

Ghi chú về vế "replay" trong đề: đề nói hệ thống hiện tại "không có cơ chế phát lại dữ liệu bị bỏ lỡ". SQS chống mất dữ liệu (thông điệp nằm đó tới khi được xử lý), nhưng nó không cho đọc lại thông điệp đã xử lý xong — đó là khả năng của Kinesis Data Streams. Với yêu cầu "ít công vận hành nhất" và chỉ cần một consumer, SQS vẫn là lựa chọn đúng; nếu sau này cần phân tích lại lịch sử di chuyển, Kinesis mới là công cụ phù hợp.

Ba cấu hình SQS quan trọng: | Cấu hình | Chi tiết | |---|---| | Visibility timeout | dài hơn thời gian xử lý, nếu không sẽ xử lý hai lần | | Long polling (WaitTimeSeconds = 20) | giảm request rỗng và chi phí | | Dead-letter queue | thông điệp hỏng không kẹt mãi |

SQS Standard và FIFO: | | Standard | FIFO | |---|---|---| | Thông lượng | gần như không giới hạn | 300/giây (3.000 khi gom lô) | | Thứ tự | không đảm bảo | ✅ trong message group | | Trùng lặp | có thể | ❌ |

Với dữ liệu cảm biến gửi mỗi vài phút từ hàng nghìn con vật, Standard là lựa chọn đúng — thứ tự tuyệt đối không quan trọng vì mỗi bản ghi đã có dấu thời gian riêng.

Ba cách co giãn tầng xử lý theo hàng đợi: | Metric | Đặc điểm | |---|---| | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | Backlog mỗi instance | chuẩn xác nhất cho target tracking | | ApproximateAgeOfOldestMessage | cảnh báo khi xử lý không kịp |

Công thức backlog mỗi instance:

Backlog mỗi instance = số thông điệp chờ ÷ số instance đang chạy
    → đặt target tracking giữ con số này ở mức mong muốn

Ba lựa chọn cho tầng xử lý: | Lựa chọn | Đặc điểm | |---|---| | Lambda với SQS event source | ít công nhất, tự co giãn | | EC2 hoặc ECS với ASG theo độ sâu hàng đợi | cho việc chạy lâu ← kiến trúc hiện tại | | Fargate | container, không quản lý máy |

Với việc giữ nguyên EC2 như đề mô tả, chỉ cần thêm SQS vào giữa — thay đổi nhỏ nhất mà giải quyết đúng vấn đề.

Ba lưu ý về IoT quy mô lớn: | Lưu ý | Chi tiết | |---|---| | AWS IoT Core quản lý kết nối thiết bị | xác thực bằng chứng chỉ X.509 | | IoT Rule định tuyến tới SQS, Kinesis, Lambda, DynamoDB | | | Device Shadow lưu trạng thái khi thiết bị offline | phù hợp với cảm biến chập chờn |

Kiến trúc đầy đủ hơn cho tình huống này:

Cảm biến → AWS IoT Core (xác thực, quản lý thiết bị)
              ↓ IoT Rule
           SQS queue
              ↓
           EC2/Lambda xử lý
              ↓
           DynamoDB (vị trí mới nhất) + S3 (lịch sử)

Ba metric cần đặt alarm: | Metric | Ngưỡng | |---|---| | ApproximateAgeOfOldestMessage | tăng dần = xử lý không kịp | | Số thông điệp trong DLQ | > 0 là phải xem ngay | | Số thông điệp nhận vào mỗi phút | phát hiện đột biến |

Và một lời khuyên: hãy đặt dead-letter queue ngay từ đầu và alarm khi nó có thông điệp. Với dữ liệu theo dõi động vật hoang dã, một bản ghi rơi vào DLQ nghĩa là một điểm dữ liệu di cư bị mất — và dữ liệu đó không bao giờ thu thập lại được.