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

Tìm thấy 2194 câu.

Câu 131 Design High-Performing Architectures

A Solutions Architect needs to deploy a mobile application that collects votes for a singing competition. Millions of users from around the world will submit votes using their mobile phones. These votes must be collected and stored in a highly scalable and highly available database which will be queried for real-time ranking. The database is expected to undergo frequent schema changes throughout the voting period.

Which of the following combination of services should the architect use to meet this requirement?

  1. A

    Amazon DynamoDB and AWS AppSync
  2. B

    Amazon DocumentDB (with MongoDB compatibility) and Amazon AppFlow
  3. C

    Amazon Relational Database Service (RDS) and Amazon MQ
  4. D

    Amazon Aurora and Amazon Cognito
Xem giải thích

Đáp án

A — Amazon DynamoDB và AWS AppSync.

Vì sao đúng

Đề nêu bốn yêu cầu, và cặp DynamoDB + AppSync đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Hàng triệu người dùng toàn cầu bỏ phiếu | DynamoDB mở rộng gần như không giới hạn | | Sẵn sàng cao | dữ liệu tự sao chép trên ba AZ | | Truy vấn xếp hạng THỜI GIAN THỰC | AppSync với GraphQL subscription | | Lược đồ THAY ĐỔI THƯỜNG XUYÊN | DynamoDB không có lược đồ cố định |

Vế "frequent schema changes" là điểm loại mọi cơ sở dữ liệu quan hệ:

Cơ sở dữ liệu quan hệ:
    Thêm cột → ALTER TABLE
        → khoá bảng hoặc chạy nền nhiều giờ với bảng lớn
        → ảnh hưởng hiệu năng trong lúc bỏ phiếu

DynamoDB:
    Thêm thuộc tính → chỉ cần GHI item mới có thuộc tính đó
        → KHÔNG có thao tác lược đồ nào
        → item cũ và mới cùng tồn tại

Và AppSync là mảnh ghép cho "real-time ranking": | Khả năng | Chi tiết | |---|---| | GraphQL API được quản lý | client hỏi đúng dữ liệu cần | | Subscription qua WebSocket | đẩy cập nhật bảng xếp hạng NGAY khi có thay đổi | | Tích hợp gốc với DynamoDB | resolver trực tiếp, không cần Lambda | | Offline sync cho ứng dụng di động | phù hợp với ứng dụng bỏ phiếu trên điện thoại |

Dòng thứ hai là lý do AppSync vượt trội cho ứng dụng này: thay vì client phải hỏi liên tục xem thứ hạng đổi chưa, server chủ động đẩy về khi có thay đổi.

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

  • **B. Amazon DocumentDB (tương thích MongoDB) và Amazon AppFlow — đây là phương án gần nhất về mặt DocumentDB cũng là NoSQL lược đồ linh hoạt, nhưng nó thua ở quy mô và vận hành: DocumentDB là cụm phải quản lý và mở rộng thủ công, không tự co giãn như DynamoDB. Và AppFlow là dịch vụ tích hợp dữ liệu với SaaS bên thứ ba (Salesforce, Slack), hoàn toàn không liên quan tới API cho ứng dụng di động.
  • **D. Amazon Aurora và Amazon Cognito — Aurora là cơ sở dữ liệu QUAN HỆ với lược đồ cố định, trái yêu cầu thay đổi lược đồ thường xuyên. (Cognito thì đúng cho việc xác thực người dùng di động — nhưng nó không phải cơ sở dữ liệu.)
  • **C. Amazon RDS và Amazon MQ — sai cả hai: RDS là quan hệ, lược đồ cố định; và Amazon MQ là message broker cho ActiveMQ/RabbitMQ, không phải công cụ truy vấn thời gian thực.

Ghi nhớ

Bốn nhóm cơ sở dữ liệu của AWS: | Nhóm | Dịch vụ | Phù hợp | |---|---|---| | Quan hệ (OLTP) | RDS, Aurora | giao dịch, JOIN, lược đồ ổn định | | Khoá–giá trị / tài liệu | DynamoDB | quy mô lớn, độ trễ thấp, lược đồ linh hoạt ← câu này | | Tương thích MongoDB | DocumentDB | ứng dụng đã viết cho MongoDB | | Kho dữ liệu | Redshift | phân tích |

Từ khoá nhận diện:

"schema changes", "flexible schema", "millions of users", "single-digit millisecond" → DynamoDB "MongoDB compatible" → DocumentDB "complex joins", "transactions", "SQL" → RDS/Aurora

Ba dịch vụ API được quản lý của AWS: | Dịch vụ | Loại API | |---|---| | AWS AppSync | GraphQL — có subscription thời gian thực | | API Gateway | REST, HTTP, WebSocket | | Application Load Balancer | HTTP thuần |

AppSync mạnh nhất cho ứng dụng di động thời gian thực: một endpoint, client tự chọn trường cần lấy, và subscription đẩy cập nhật về.

Ba loại thao tác của GraphQL: | Thao tác | Việc | |---|---| | Query | đọc dữ liệu | | Mutation | ghi dữ liệu (bỏ phiếu) | | Subscription | nhận cập nhật thời gian thực khi mutation xảy ra |

Với ứng dụng bỏ phiếu, luồng là:

Người dùng bỏ phiếu → Mutation → AppSync ghi vào DynamoDB
                                     ↓ tự động
                    Subscription đẩy thứ hạng mới về MỌI client đang xem

Ba lưu ý khi thiết kế bảng DynamoDB cho ứng dụng bỏ phiếu: | Lưu ý | Chi tiết | |---|---| | Partition key độ phân biệt CAO | dùng thi_sinh_id, tránh hot partition | | Đếm phiếu bằng atomic counter | UpdateItem với ADD — an toàn khi đồng thời | | Dùng on-demand capacity | tải bỏ phiếu rất khó dự báo |

Cảnh báo về hot partition trong tình huống này: nếu một thí sinh nổi tiếng nhận phần lớn số phiếu, partition chứa bản ghi của họ sẽ bị throttling. Giải pháp là write sharding — ghi vào thi_sinh_id#1 tới thi_sinh_id#N rồi cộng lại khi đọc.

Ba tính năng nên bật: | Tính năng | Lợi ích | |---|---| | DAX | cache bảng xếp hạng — độ trễ microgiây cho dữ liệu đọc rất nhiều | | DynamoDB Streams | kích hoạt xử lý khi có phiếu mới | | Global Tables | người dùng toàn cầu đọc và ghi ở Region gần nhất |

Global Tables đáng cân nhắc mạnh cho "millions of users from around the world" — nó giảm độ trễ cho người bỏ phiếu ở xa và tăng tính sẵn sàng.

Và một cân nhắc về tính đúng đắn: với bỏ phiếu, cần chống gian lận — dùng Cognito để xác thực và giới hạn một phiếu mỗi người, cùng WAF rate-based rule trước AppSync để chặn bot bỏ phiếu hàng loạt.

Câu 132 Design Secure Architectures

A solutions architect is writing an AWS Lambda function that will process encrypted documents from an Amazon FSx for NetApp ONTAP file system. The documents are protected by an AWS KMS customer key. After processing the documents, the Lambda function will store the results in an S3 bucket with an Amazon S3 Glacier Flexible Retrieval storage class. The solutions architect must ensure that the files can be decrypted by the Lambda function.

Which action accomplishes the requirement?

  1. A

    Attach the kms:decrypt permission to the Lambda function’s execution role. Add a statement to the AWS KMS key’s policy that grants the function’s execution role the kms:decrypt permission.
  2. B

    Attach the kms:decrypt permission to the Lambda function’s resource policy. Add a statement to the AWS KMS key’s policy that grants the function’s resource policy ARN the kms:decrypt permission.
  3. C

    Attach the kms:decrypt permission to the Lambda function’s execution role. Add a statement to the AWS KMS key’s policy that grants the function’s ARN the kms:decrypt permission.
  4. D

    Attach the kms:decrypt permission to the Lambda function’s resource policy. Add a statement to the AWS KMS key’s policy that grants the function’s execution role the kms:decrypt permission.
Xem giải thích

Đáp án

A — Gắn quyền kms:Decrypt vào EXECUTION ROLE của Lambda function. Thêm một statement vào key policy của KMS key cấp quyền kms:Decrypt cho execution role đó.

Vì sao đúng

Đề cần Lambda giải mã được tệp — và KMS đòi hai lớp quyền cùng cho phép, đây là đặc điểm riêng của dịch vụ này.

Hai lớp quyền của KMS:

① KEY POLICY (gắn trên chính KMS key)
   → nguồn quyền GỐC
   → không có statement cho principal (hoặc uỷ quyền cho tài khoản)
     thì KHÔNG AI dùng được khoá

② IAM POLICY (gắn trên execution role)
   → chỉ có tác dụng nếu key policy đã uỷ quyền

Khác với hầu hết dịch vụ AWS — nơi IAM policy một mình là đủ — với KMS bạn phải cấu hình cả hai.

Và điểm phân biệt thứ hai: principal là EXECUTION ROLE, không phải ARN của function.

Lambda function chạy → ASSUME execution role
    → mọi lời gọi API AWS dùng danh tính của ROLE
    → KMS thấy principal là: arn:aws:iam::...:role/lambda-xu-ly-tep
    → KHÔNG BAO GIỜ thấy ARN của function

Key policy đúng:

{
  "Sid": "ChoPhepLambdaGiaiMa",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/lambda-xu-ly-tep"},
  "Action": "kms:Decrypt",
  "Resource": "*"
}

Và execution role cần policy tương ứng:

{
  "Effect": "Allow",
  "Action": "kms:Decrypt",
  "Resource": "arn:aws:kms:ap-northeast-1:111122223333:key/1234abcd-..."
}

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

  • **C. Gắn kms:decrypt vào execution role; thêm statement vào key policy cấp quyền cho ARN CỦA FUNCTION — đây là phương án gần nhất và có vế IAM policy đúng, nhưng nó sai principal trong key policy: ARN của Lambda function không phải một IAM principal. KMS chỉ nhận IAM user, IAM role, tài khoản AWS, hoặc service principal.
  • **D. Gắn kms:decrypt vào RESOURCE POLICY của Lambda; thêm statement vào key policy cấp cho execution role — nhầm vai trò của resource policy: resource policy của Lambda quy định AI ĐƯỢC GỌI function này, không phải function được làm gì.
  • **B. Gắn kms:decrypt vào resource policy của Lambda; key policy cấp quyền cho ARN của resource policy — sai cả hai vế, cộng thêm một khái niệm không tồn tại ("ARN của resource policy").

Ghi nhớ

Hai loại policy của Lambda — bảng phải thuộc: | Loại | Chiều | Việc | |---|---|---| | Execution role | Lambda → dịch vụ khác | quyền function dùng để gọi API ← câu này | | Resource-based policy | dịch vụ khác → Lambda | ai được phép GỌI function |

Hai cái này ngược chiều nhau và là nguồn nhầm lẫn thường xuyên:

Lambda đọc S3         → EXECUTION ROLE có quyền s3:GetObject
S3 event gọi Lambda   → RESOURCE POLICY cho phép s3.amazonaws.com

Ba cơ chế cấp quyền của KMS: | Cơ chế | Đặc điểm | |---|---| | Key policy | BẮT BUỘC — gốc của mọi quyền trên khoá | | IAM policy | chỉ có tác dụng nếu key policy uỷ quyền cho tài khoản | | Grant | cấp quyền tạm thời, chi tiết — dịch vụ AWS dùng nhiều |

Statement uỷ quyền cho tài khoản — thứ Console tự thêm khi tạo CMK:

{"Sid": "Enable IAM User Permissions",
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
 "Action": "kms:*", "Resource": "*"}

Có statement này thì IAM policy mới hoạt động. Xoá nó mà không thêm principal cụ thể nào là tự khoá mình ra khỏi khoá vĩnh viễn.

Quyền KMS theo thao tác: | Thao tác | Quyền | |---|---| | Đọc dữ liệu đã mã hoá | kms:Decrypt ← câu này | | Ghi dữ liệu mã hoá | kms:GenerateDataKey | | Multipart upload lên S3 | cả hai | | Đổi khoá cho dữ liệu | kms:ReEncrypt |

Quy tắc thực dụng: cấp cả Decrypt và GenerateDataKey cho principal cần đọc-ghi — thiếu một trong hai gây lỗi khó chẩn đoán ("đọc được nhưng ghi thất bại").

Ba điều kiện đáng thêm vào key policy để siết chặt:

// Chỉ dùng khoá THÔNG QUA một dịch vụ cụ thể
{"Condition": {"StringEquals": {"kms:ViaService": "fsx.ap-northeast-1.amazonaws.com"}}}

// Chỉ trong tổ chức
{"Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-abc123"}}}

kms:ViaService đặc biệt hữu ích: nó đảm bảo khoá chỉ dùng được qua dịch vụ đã định, không gọi trực tiếp qua API KMS — thu hẹp đáng kể phạm vi nếu role bị lạm dụng.

Và một chi tiết trong đề đáng lưu ý: kết quả được ghi vào S3 với lớp Glacier Flexible Retrieval. Nếu bucket đó cũng mã hoá bằng SSE-KMS, execution role cần thêm kms:GenerateDataKey trên khoá của bucket đích — quyền Decrypt một mình không đủ để ghi.

Ba lỗi thường gặp khi Lambda không giải mã được: | Triệu chứng | Nguyên nhân | |---|---| | AccessDeniedException từ KMS | thiếu quyền ở một trong hai lớp | | Chạy được ở dev, hỏng ở prod | key policy khác nhau giữa hai môi trường | | Timeout khi gọi KMS | Lambda trong VPC thiếu VPC endpoint cho KMS |

Câu 133 Design Secure Architectures

A Solutions Architect is managing a company's AWS account of approximately 300 IAM users. They have a new company policy that requires changing the associated permissions of all 100 IAM users that control the access to Amazon S3 buckets.

What will the Solutions Architect do to avoid the time-consuming task of applying the policy to each user?

  1. A

    Create a new IAM group and then add the users that require access to the S3 bucket. Afterward, apply the policy to the IAM group.
  2. B Create a new policy and apply it to multiple IAM users using a shell script.
  3. C Create a new S3 bucket access policy with unlimited access for each IAM user.
  4. D Create a new IAM role and add each user to the IAM role.
Xem giải thích

Đáp án

A — Tạo một IAM group mới, thêm những người dùng cần truy cập S3 bucket vào đó, rồi áp policy cho GROUP.

Vì sao đúng

Đề nêu vấn đề rõ: cần đổi quyền cho 100 người dùng và muốn tránh việc áp policy cho từng người.

IAM group được tạo ra chính xác cho việc này:

Trước:  policy gắn riêng cho từng user
        → đổi quyền = sửa 100 lần
        → sót một người là có lỗ hổng hoặc lỗi truy cập

Sau:    policy gắn cho GROUP
        → đổi quyền = sửa MỘT lần
        → mọi thành viên nhận thay đổi NGAY LẬP TỨC

Ba lợi ích của mô hình group: | Lợi ích | Chi tiết | |---|---| | Một điểm thay đổi | sửa policy là áp cho toàn nhóm | | Người mới chỉ cần thêm vào group | không phải nhớ gắn những policy nào | | Dễ kiểm toán | nhìn group là biết ai có quyền gì |

Và group là công cụ chuẩn cho IAM user — nó tồn tại đúng để giải quyết bài toán quản lý quyền theo nhóm.

aws iam create-group --group-name nhom-truy-cap-s3
aws iam attach-group-policy --group-name nhom-truy-cap-s3   --policy-arn arn:aws:iam::111122223333:policy/ChinhSachS3Moi
aws iam add-user-to-group --group-name nhom-truy-cap-s3 --user-name nguyen-van-a

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

  • **D. Tạo một IAM role mới và thêm từng user vào role — đây là phương án gần nhất về mặt cũng gom quyền lại một chỗ, nhưng nó mô tả sai cách role hoạt động: bạn không "thêm user vào role" như thêm vào group. User phải chủ động assume role qua STS, nhận thông tin đăng nhập tạm thời, và chuyển ngữ cảnh — đó là thay đổi quy trình làm việc, không phải giải pháp gán quyền tự động.
  • **B. Tạo policy mới và áp cho nhiều user bằng shell script — vẫn là gắn cho từng người, chỉ tự động hoá việc gõ lệnh: lần đổi quyền sau lại phải chạy script lại, và bạn phải tự quản lý danh sách 100 người đó ở đâu đó.
  • **C. Tạo bucket policy mới với quyền không giới hạn cho mỗi IAM user — hai vấn đề: liệt kê 100 principal trong bucket policy sẽ chạm giới hạn 20 KB của bucket policy; và "unlimited access" trái thẳng nguyên tắc đặc quyền tối thiểu.

Ghi nhớ

IAM Group và IAM Role — bảng phân biệt cốt lõi: | | IAM Group | IAM Role | |---|---|---| | Áp cho | CHỈ IAM user | user, dịch vụ AWS, danh tính LIÊN KẾT | | Cách nhận quyền | tự động khi là thành viên | phải chủ động AssumeRole | | Thông tin đăng nhập | dài hạn (của user) | tạm thời, tự hết hạn | | Dùng cho federation | ❌ | ✅ |

Câu hỏi phân biệt:

"nhóm nhiều IAM user có cùng quyền" → Group "dịch vụ AWS cần quyền", "truy cập chéo tài khoản", "federation" → Role

Bốn giới hạn IAM cần thuộc: | Đối tượng | Giới hạn | |---|---| | IAM user mỗi tài khoản | 5.000 | | Group mỗi user | 10 | | Managed policy gắn cho một entity | 10 (tăng được tới 20) | | Access key mỗi user | 2 |

Giới hạn "10 group mỗi user" đáng nhớ khi thiết kế cấu trúc nhóm phức tạp.

Ba loại policy trong IAM: | Loại | Đặc điểm | |---|---| | AWS managed | AWS viết và bảo trì (AmazonS3ReadOnlyAccess) | | Customer managed | bạn viết, tái sử dụng được, có phiên bản | | Inline policy | nhúng trực tiếp vào một entity — khó tái sử dụng |

Customer managed policy là lựa chọn tốt nhất cho tình huống của đề: gắn cho group, sửa một chỗ, và có lịch sử phiên bản để quay lui nếu sai.

Và với 300 IAM user như đề mô tả, hãy cân nhắc thay đổi lớn hơn: | Cách | Lợi ích | |---|---| | AWS IAM Identity Center | SSO, thông tin đăng nhập TẠM THỜI, quản lý nhiều tài khoản | | Federation với AD hoặc IdP | danh tính chỉ tồn tại ở một nơi | | IAM user + group | cách truyền thống ← câu này |

Ba lý do IAM Identity Center tốt hơn cho tổ chức lớn:

① Không có access key dài hạn nào để rò rỉ
② Nhân viên nghỉ việc → vô hiệu hoá ở thư mục → mất quyền NGAY trên mọi tài khoản
③ Permission set định nghĩa MỘT LẦN, gán cho nhiều tài khoản AWS

Với 300 IAM user, chi phí vận hành thật nằm ở vòng đời tài khoản — tạo, sửa quyền, và nhớ xoá khi người ta rời đi. Group giải quyết vế thứ hai; Identity Center giải quyết cả ba.

Ba thực hành khi dùng group: | Thực hành | Lý do | |---|---| | Đặt tên group theo VAI TRÒ, không theo người | nhom-lap-trinh-vien, không phải nhom-cua-anh-a | | Một group một trách nhiệm rõ ràng | dễ kiểm toán và tổ hợp | | Rà soát thành viên định kỳ | quyền tích tụ theo thời gian |

Và một công cụ nên dùng khi đổi quyền cho 100 người: IAM Access Analyzer với tính năng phân tích quyền chưa dùng — nó cho biết những quyền nào trong policy hiện tại thực sự chưa từng được sử dụng, giúp bạn viết policy mới hẹp hơn thay vì sao chép nguyên cái cũ.

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

A Solutions Architect for a global news company is configuring a fleet of EC2 instances in a subnet that currently is in a VPC with an Internet gateway attached. All of these EC2 instances can be accessed from the Internet. The architect launches another subnet and deploys an EC2 instance in it, however, the architect is not able to access the EC2 instance from the Internet.

What could be the possible reasons for this issue? (Select TWO.)

  1. A The Amazon EC2 instance does not have a public IP address associated with it.
  2. B The Amazon EC2 instance is not a member of the same Auto Scaling group.
  3. C

    The Amazon EC2 instance does not have an attached Elastic Fabric Adapter (EFA).
  4. D

    The route table is not configured properly to send traffic from the EC2 instance to the Internet through the Internet gateway.
  5. E

    The route table is not configured properly to send traffic from the EC2 instance to the Internet through the customer gateway (CGW).
Xem giải thích

Đáp án

A và D.

  • A — EC2 instance không có địa chỉ IP công khai gắn kèm
  • D — Route table chưa được cấu hình đúng để gửi lưu lượng từ instance ra Internet qua Internet Gateway

Vì sao đúng

Đề mô tả tình huống rõ: subnet cũ hoạt động được, subnet mới thì không — nên vấn đề nằm ở cấu hình của subnet mới.

Bốn điều kiện để một EC2 instance truy cập được từ Internet:

① VPC có Internet Gateway gắn vào          ✓ (đề nói đã có)
② Subnet có ROUTE 0.0.0.0/0 → IGW          ← D
③ Instance có ĐỊA CHỈ IP CÔNG KHAI          ← A
④ Security group và NACL cho phép lưu lượng

A — địa chỉ IP công khai không tự động có:

Thuộc tính "auto-assign public IPv4 address" của SUBNET
    → mặc định TẮT cho subnet tự tạo
    → instance khởi chạy trong đó KHÔNG có IP công khai
    → không ai từ Internet tới được, dù mọi thứ khác đúng

D — chính route table biến một subnet thành "public":

KHÔNG có khái niệm "public subnet" trong AWS

Subnet là "public" khi và chỉ khi:
    route table của nó có tuyến 0.0.0.0/0 → igw-xxxxx

Subnet mới tạo mặc định dùng MAIN route table của VPC — và nếu main route table chỉ có tuyến local, subnet đó là private.

# Tạo route table riêng cho subnet mới và thêm tuyến ra IGW
aws ec2 create-route --route-table-id rtb-0new   --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0abc

aws ec2 associate-route-table --subnet-id subnet-0new --route-table-id rtb-0new

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

  • **E. Route table chưa cấu hình đúng để gửi lưu lượng ra Internet qua customer gateway (CGW) — đây là phương án gần nhất và chỉ sai một thành phần: customer gateway là thiết bị VPN phía TẠI CHỖ của bạn. Lưu lượng ra Internet đi qua Internet Gateway, không phải CGW.
  • **B. Instance không thuộc cùng Auto Scaling group — không liên quan tới kết nối mạng: ASG quản lý số lượng và vòng đời instance. Nó không ảnh hưởng gì tới việc instance có truy cập được từ Internet hay không.
  • **C. Instance không có Elastic Fabric Adapter (EFA) gắn kèm — sai loại giao diện: EFA là giao diện mạng chuyên dụng cho HPC với độ trễ cực thấp giữa các node. Nó không liên quan tới truy cập Internet.

Ghi nhớ

Định nghĩa public subnet và private subnet: | | Public subnet | Private subnet | |---|---|---| | Route table | có 0.0.0.0/0 → IGW | không có, hoặc trỏ qua NAT | | Instance có IP công khai | thường có | không cần | | Truy cập từ Internet | ✅ | ❌ | | Đi RA Internet | ✅ trực tiếp | qua NAT Gateway |

Chỉ có route table quyết định — không có cờ "public" nào trên subnet cả.

Danh sách kiểm tra khi không truy cập được EC2 từ Internet:

① Instance có IP công khai hoặc Elastic IP chưa?
② Route table của subnet có tuyến 0.0.0.0/0 → IGW chưa?
③ Internet Gateway đã GẮN vào VPC chưa?
④ Security group có rule inbound cho cổng cần thiết chưa?
⑤ NACL có cho phép CẢ HAI CHIỀU chưa?  (stateless!)
⑥ Tường lửa của hệ điều hành có chặn không?
⑦ Ứng dụng có thực sự lắng nghe trên cổng đó không?

Bước ⑤ hay bị bỏ sót: NACL không có trạng thái, nên phải mở cả inbound (cổng dịch vụ) lẫn outbound (dải cổng tạm 1024–65535).

Ba cách gán IP công khai cho instance: | Cách | Đặc điểm | |---|---| | Auto-assign trên subnet | mọi instance mới tự có — tiện nhưng IP ĐỔI khi stop/start | | Khai lúc khởi chạy instance | ghi đè cài đặt của subnet | | Elastic IP | TĨNH, giữ nguyên qua stop/start |

IP công khai thông thường bị mất khi instance dừng và khởi động lại — chỉ Elastic IP là cố định.

Bốn loại gateway của VPC: | Gateway | Việc | |---|---| | Internet Gateway (IGW) | ra và vào Internet, IPv4 và IPv6 | | NAT Gateway | chỉ RA Internet, chỉ IPv4 | | Egress-Only IGW | chỉ ra Internet, chỉ IPv6 | | Virtual Private Gateway (VGW) | kết nối VPN tới customer gateway |

Customer Gateway (CGW) là thiết bị phía BẠN — nó ghép với VGW để tạo Site-to-Site VPN, không liên quan tới Internet.

Ba lưu ý về route table: | Lưu ý | Chi tiết | |---|---| | Mọi subnet mới dùng MAIN route table | trừ khi bạn gắn cái khác | | Tuyến local luôn có và không xoá được | cho phép mọi subnet trong VPC nói chuyện | | Tuyến cụ thể hơn được ưu tiên | /24 thắng /16 |

Và một mẹo chẩn đoán nhanh: dùng VPC Reachability Analyzer. Nó phân tích đường đi từ nguồn tới đích và chỉ ra chính xác thành phần nào đang chặn — nhanh hơn nhiều so với kiểm tra thủ công từng lớp.

Câu 135 Design High-Performing Architectures

A data analytics company is setting up an innovative checkout-free grocery store. Their Solutions Architect developed a real-time monitoring application that uses smart sensors to collect the items that the customers are getting from the grocery’s refrigerators and shelves then automatically deduct it from their accounts. The company wants to analyze the items that are frequently being bought and store the results in S3 for durable storage to determine the purchase behavior of its customers.

What service must be used to easily capture, transform, and load streaming data into Amazon S3, Amazon OpenSearch Service, and Splunk?

  1. A

    Amazon Data Firehose
  2. B

    Amazon DynamoDB Streams
  3. C Amazon Redshift
  4. D

    Amazon SQS
Xem giải thích

Đáp án

A — Amazon Data Firehose.

Vì sao đúng

Đề liệt kê chính xác ba đích: Amazon S3, Amazon OpenSearch Service và Splunk — và đó là danh sách đích được hỗ trợ của Data Firehose.

Data Firehose là đường ống giao dữ liệu luồng được quản lý hoàn toàn:

Nguồn (cảm biến, ứng dụng, agent)
    ↓
Amazon Data Firehose
    ├─ GOM theo lô (buffer)
    ├─ CHUYỂN ĐỔI (Lambda, hoặc JSON → Parquet/ORC)
    ├─ NÉN (GZIP, Snappy, ZIP)
    └─ MÃ HOÁ
    ↓
S3 / OpenSearch / Redshift / Splunk / HTTP endpoint

Ba từ khoá trong đề khớp chính xác với ba khả năng của Firehose: | Từ khoá trong đề | Khả năng | |---|---| | "capture" | nhận dữ liệu từ nhiều nguồn | | "transform" | gọi Lambda biến đổi, hoặc chuyển định dạng | | "load" | giao vào đích tự động |

Và "easily" là điểm quan trọng: Firehose không cần viết consumer nào:

Kinesis Data Streams:
    → bạn phải TỰ VIẾT ứng dụng consumer
    → tự quản lý shard, checkpoint, mở rộng

Data Firehose:
    → cấu hình đích, xong
    → AWS lo toàn bộ việc giao dữ liệu

aws firehose create-delivery-stream   --delivery-stream-name luong-mua-hang   --s3-destination-configuration     'BucketARN=arn:aws:s3:::kho-phan-tich,
     BufferingHints={SizeInMBs=64,IntervalInSeconds=60},
     CompressionFormat=GZIP'

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

  • **B. Amazon DynamoDB Streams — đây là phương án gần nhất về mặt cũng là một luồng dữ liệu, nhưng nó chỉ bắt thay đổi của một bảng DynamoDB. Nó không nhận dữ liệu từ cảm biến, không biến đổi, và không giao vào S3, OpenSearch hay Splunk — bạn phải tự viết consumer.
  • **C. Amazon Redshift — là kho dữ liệu, không phải đường ống: nó là ĐÍCH của Firehose, không phải công cụ nạp dữ liệu. Nó không "capture" hay "transform" luồng.
  • **D. Amazon SQS — là hàng đợi thông điệp: nó đệm thông điệp cho consumer kéo về, nhưng không tự giao vào bất kỳ đích nào. Bạn vẫn phải viết ứng dụng đọc từ SQS và ghi vào S3.

Ghi nhớ

Bốn dịch vụ trong họ Kinesis — bảng phân biệt: | Dịch vụ | Việc | |---|---| | Data Firehose | GIAO dữ liệu luồng vào đích — không cần viết mã ← câu này | | Kinesis Data Streams | hàng đợi luồng, bạn TỰ VIẾT consumer, PHÁT LẠI được | | Kinesis Video Streams | video và âm thanh | | Managed Service for Apache Flink | xử lý luồng phức tạp bằng SQL hoặc Flink |

Data Streams và Firehose — khác biệt cốt lõi: | | Data Streams | Data Firehose | |---|---|---| | Mô hình | hàng đợi, tự viết consumer | đường ống giao hàng được quản lý | | Độ trễ | mili giây | tối thiểu ~60 giây (gom lô) | | Phát lại (replay) | ✅ giữ 1–365 ngày | ❌ | | Nhiều consumer độc lập | ✅ | ❌ | | Quản lý shard | có | không | | Chi phí | theo shard-giờ | theo dữ liệu nạp vào |

Quy tắc chọn:

"đưa dữ liệu vào S3/OpenSearch/Redshift, đơn giản nhất" → Firehose "cần phát lại, nhiều consumer, độ trễ mili giây" → Data Streams

Các đích mà Firehose hỗ trợ:

Amazon S3
Amazon Redshift
Amazon OpenSearch Service
Splunk
HTTP endpoint tuỳ ý (Datadog, New Relic, MongoDB, Snowflake...)
Apache Iceberg tables

Ba khả năng biến đổi của Firehose: | Khả năng | Chi tiết | |---|---| | Lambda transformation | biến đổi tuỳ ý từng bản ghi | | Chuyển định dạng | JSON → Parquet hoặc ORC — giảm mạnh chi phí truy vấn | | Dynamic partitioning | tự phân vùng theo giá trị trong dữ liệu |

Hai khả năng cuối rất đáng bật khi đích là S3:

"Prefix": "du-lieu/nam=!{timestamp:yyyy}/thang=!{timestamp:MM}/ngay=!{timestamp:dd}/",
"DataFormatConversionConfiguration": {
  "OutputFormatConfiguration": {"Serializer": {"ParquetSerDe": {}}},
  "Enabled": true}

Kết quả: dữ liệu vào S3 đã ở dạng Parquet có phân vùng — truy vấn Athena sau đó rẻ hơn nhiều lần mà không cần bước xử lý nào thêm.

Hai tham số gom lô của Firehose: | Tham số | Ý nghĩa | |---|---| | SizeInMBs | gom đủ N MB thì giao (1–128) | | IntervalInSeconds | hoặc đủ N giây thì giao (60–900) |

Firehose giao khi điều kiện nào tới trước — nên đặt interval nhỏ cho độ trễ thấp, đặt size lớn cho ít tệp hơn.

Ba lưu ý khi dùng Firehose: | Lưu ý | Chi tiết | |---|---| | Không phát lại được | bản ghi giao rồi là xong — cần phát lại thì dùng Data Streams | | Có backup vào S3 cho bản ghi lỗi | bật S3BackupMode | | Buffer tối thiểu 60 giây | không phải "thời gian thực" tuyệt đối |

Và một kiến trúc kết hợp đáng biết: dùng Data Streams làm nguồn cho Firehose. Khi đó bạn có cả khả năng phát lại và nhiều consumer (từ Data Streams) lẫn việc giao dữ liệu tự động vào S3 (từ Firehose) — mẫu rất phổ biến cho hệ thống phân tích nghiêm túc.

Câu 136 Design Resilient Architectures

A tech startup is launching an on-demand food delivery platform using Amazon ECS cluster with an AWS Fargate serverless compute engine and Amazon Aurora. It is expected that the database read queries will significantly increase in the coming weeks ahead. A Solutions Architect recently launched two Read Replicas to the database cluster to improve the platform's scalability.

Which of the following is the MOST suitable configuration that the Architect should implement to load balance all of the incoming read requests equally to the two Read Replicas?

  1. A

    Use the built-in Reader endpoint of the Amazon Aurora database.
  2. B

    Use the built-in Cluster endpoint of the Amazon Aurora database.
  3. C

    Enable Amazon Aurora Parallel Query.
  4. D

    Create a new Network Load Balancer to evenly distribute the read queries to the Read Replicas of the Amazon Aurora database.
Xem giải thích

Đáp án

A — Dùng Reader endpoint dựng sẵn của Amazon Aurora.

Vì sao đúng

Đề cần phân phối đều các truy vấn đọc tới hai Read Replica — và Aurora có sẵn một endpoint làm đúng việc đó.

Reader endpoint tự cân bằng tải giữa mọi replica:

Ứng dụng kết nối tới reader endpoint
    cum-aurora.cluster-ro-abc123.ap-northeast-1.rds.amazonaws.com
        ↓ mỗi lần MỞ KẾT NỐI, DNS trả về một replica khác nhau
    ├─ Replica 1
    └─ Replica 2

Ba lợi ích của việc dùng reader endpoint: | Lợi ích | Chi tiết | |---|---| | Tự cân bằng tải | không cần load balancer nào | | Replica mới tự động vào vòng luân phiên | kết hợp Aurora Auto Scaling thì hoàn toàn tự động | | Replica hỏng bị loại tự động | không gửi kết nối tới máy chết |

Dòng giữa là lý do reader endpoint quan trọng hơn vẻ ngoài: nếu ứng dụng nối thẳng vào instance endpoint, replica mới thêm sẽ không nhận được lưu lượng nào.

Và cần tách rõ hai endpoint trong mã ứng dụng:

# Ghi → cluster endpoint (writer)
conn_ghi = connect("cum-aurora.cluster-abc123...")

# Đọc → reader endpoint
conn_doc = connect("cum-aurora.cluster-ro-abc123...")

Nếu ứng dụng gửi mọi truy vấn vào cluster endpoint, replica sẽ nằm không — dù bạn đã trả tiền cho chúng.

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

  • **B. Dùng Cluster endpoint dựng sẵn — đây là phương án gần nhất và là bẫy chính của câu hỏi: cluster endpoint luôn trỏ tới instance GHI (writer). Gửi truy vấn đọc vào đó nghĩa là chất toàn bộ tải lên primary — đúng thứ mà việc thêm replica muốn tránh.
  • **D. Tạo một Network Load Balancer phân phối truy vấn đọc tới các replica — tự dựng lại thứ đã có sẵn: reader endpoint làm đúng việc này mà không cần thêm dịch vụ, thêm chi phí, thêm chỗ hỏng. Và NLB không biết replica nào đang khoẻ theo cách Aurora biết.
  • **C. Bật Aurora Parallel Query — giải quyết vấn đề khác: Parallel Query đẩy một phần xử lý xuống tầng lưu trữ để tăng tốc truy vấn phân tích quét nhiều dữ liệu. Nó không phân phối tải giữa các replica.

Ghi nhớ

Bốn loại endpoint của Aurora — bảng phải thuộc: | Endpoint | Trỏ tới | Dùng cho | |---|---|---| | Cluster (writer) | instance GHI hiện tại | mọi thao tác GHI | | Reader | cân bằng tải qua MỌI replica | mọi thao tác ĐỌC ← câu này | | Custom | nhóm instance do BẠN chọn | phân tách workload theo dung lượng | | Instance | một instance cụ thể | gỡ lỗi — không nên dùng trong ứng dụng |

Cluster endpoint tự trỏ sang instance mới khi có chuyển đổi dự phòng — đó là lý do ứng dụng luôn nên dùng nó thay vì instance endpoint.

Kiến trúc Aurora — vì sao replica hiệu quả:

Compute:  1 writer + tối đa 15 reader
              ↓ tất cả dùng chung
Lưu trữ:  6 bản sao trên 3 AZ
Hệ quả Chi tiết
Thêm replica rất nhanh không phải sao chép dữ liệu
Replica lag rất thấp thường dưới 100 mili giây
Replica có kích thước KHÁC NHAU được cho phép phân tách theo dung lượng

Cách cân bằng tải của reader endpoint — chi tiết cần biết:

Reader endpoint phân giải DNS theo vòng luân phiên
    → cân bằng ở mức MỞ KẾT NỐI, không phải mức truy vấn
    → với connection pool giữ kết nối lâu, phân bố có thể LỆCH

Đây là hạn chế thật: nếu ứng dụng mở 10 kết nối và giữ mãi, chúng có thể rơi hết vào một replica. Cách khắc phục là định kỳ tái tạo kết nối trong pool, hoặc dùng RDS Proxy để phân phối ở mức truy vấn.

Ba cách mở rộng đọc cho Aurora: | Cách | Phù hợp | |---|---| | Thêm read replica + reader endpoint | ← câu này | | Aurora Auto Scaling | tự thêm bớt replica theo tải | | ElastiCache phía trước | rẻ nhất cho truy vấn lặp lại nhiều |

Aurora Auto Scaling đáng bật kèm cho tình huống đề mô tả ("read queries sẽ tăng mạnh trong vài tuần tới"):

aws application-autoscaling put-scaling-policy   --service-namespace rds --resource-id cluster:cum-aurora   --scalable-dimension rds:cluster:ReadReplicaCount   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "RDSReaderAverageCPUUtilization"}}'

Ba lưu ý về replica lag: | Lưu ý | Chi tiết | |---|---| | Aurora lag thường dưới 100 mili giây | rất thấp so với RDS thường | | Vẫn có thể đọc dữ liệu hơi cũ | ứng dụng cần chấp nhận điều đó | | Truy vấn cần dữ liệu mới nhất phải dùng writer | ví dụ đọc lại ngay sau khi ghi |

Dòng cuối là mẫu "read your own write" — sau khi người dùng đặt hàng, hiển thị đơn hàng đó nên đọc từ writer để tránh trường hợp replica chưa kịp đồng bộ.

Và một lựa chọn hiện đại đáng biết: Aurora Serverless v2 tự co giãn dung lượng của từng instance theo tải — kết hợp với reader endpoint, bạn có cả mở rộng ngang (thêm replica) lẫn mở rộng dọc (tăng dung lượng mỗi replica) một cách tự động.

Câu 137 Design Resilient Architectures

A manufacturing company has EC2 instances running in AWS. The EC2 instances are configured with Auto Scaling. There are a lot of requests being lost because of too much load on the servers. The Auto Scaling is launching new EC2 instances to take the load accordingly yet, there are still some requests that are being lost.

Which of the following is the MOST suitable solution that you should implement to avoid losing recently submitted requests?

  1. A

    Use an Amazon SQS queue to decouple the application components and scale-out the EC2 instances based upon the ApproximateNumberOfMessages metric in Amazon CloudWatch.
  2. B

    Replace the Auto Scaling group with a cluster placement group to achieve a low-latency network performance necessary for tightly-coupled node-to-node communication.
  3. C

    Use larger instances for your application with an attached Elastic Fabric Adapter (EFA).
  4. D

    Set up Amazon Aurora Serverless for on-demand, auto-scaling configuration of your EC2 Instances and also enable Amazon Aurora Parallel Query feature for faster analytical queries over your current data.
Xem giải thích

Đáp án

A — Dùng một Amazon SQS queue để tách rời các thành phần của ứng dụng, và mở rộng EC2 instance dựa trên metric ApproximateNumberOfMessages trong CloudWatch.

Vì sao đúng

Đề mô tả vấn đề rõ: request bị mất vì Auto Scaling không kịp thêm máy — và đó là hạn chế cố hữu của kiến trúc đồng bộ.

Nguyên nhân gốc: không có nơi nào đệm request trong lúc chờ máy mới.

Kiến trúc hiện tại (đồng bộ):
    Request → EC2 xử lý ngay
        → máy quá tải → request bị TỪ CHỐI hoặc TIMEOUT
        → Auto Scaling mất 2–5 phút mới có máy mới
        → mọi request trong khoảng đó MẤT

SQS biến kiến trúc thành bất đồng bộ và giải quyết đúng vấn đề:

Request → SQS queue (đệm, không giới hạn số thông điệp)
              ↓ EC2 kéo về xử lý theo tốc độ của mình
    → máy quá tải → thông điệp vẫn NẰM CHỜ trong queue
    → không có request nào bị mất
    → Auto Scaling thêm máy → tiêu thụ nhanh hơn

Và mở rộng theo độ sâu hàng đợi là chỉ báo chính xác hơn CPU: | Metric | Cho biết | |---|---| | CPUUtilization | máy đang bận — chỉ báo GIÁN TIẾP, có độ trễ | | ApproximateNumberOfMessages | còn bao nhiêu việc chưa làm — TRỰC TIẾP |

Cấu hình chuẩn dùng "backlog per instance":

Backlog per instance = ApproximateNumberOfMessages / số instance đang chạy
    → target tracking giữ con số này ở một mức nhất định

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

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

  • **B. Thay Auto Scaling group bằng cluster placement group để có độ trễ mạng thấp cho giao tiếp node-to-node — giải quyết vấn đề hoàn toàn khác: placement group tối ưu độ trễ mạng giữa các instance cho workload HPC. Nó không đệm request và không giúp gì khi máy quá tải.
  • **C. Dùng instance lớn hơn kèm Elastic Fabric Adapter (EFA) — máy to hơn chỉ nâng trần chịu tải, không giải quyết vấn đề: khi vượt trần mới, request vẫn mất. Và EFA dành cho HPC, không liên quan tới ứng dụng web.
  • **D. Dùng Aurora Serverless và bật Aurora Parallel Query — nhầm tầng hoàn toàn: đề nói về tải trên máy chủ ứng dụng, không phải cơ sở dữ liệu. Và Aurora Serverless không "auto-scale EC2 instance" như phương án mô tả.

Ghi nhớ

Nguyên tắc kiến trúc quan trọng nhất từ câu này:

Hàng đợi biến "mất request" thành "chờ lâu hơn". Với hệ thống chịu được xử lý bất đồng bộ, đó là đánh đổi gần như luôn đúng.

Ba lợi ích của việc chèn SQS: | Lợi ích | Chi tiết | |---|---| | Đệm đợt tăng đột biến | queue nhận nhanh hơn nhiều so với xử lý | | Tách rời producer và consumer | consumer chết thì công việc vẫn chờ | | Mở rộng theo backlog | chỉ báo trực tiếp về lượng việc tồn |

Các metric của SQS dùng để mở rộng: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | thông điệp đang CHỜ xử lý | | ApproximateNumberOfMessagesNotVisible | đang được xử lý | | ApproximateAgeOfOldestMessage | thông điệp cũ nhất chờ bao lâu — chỉ báo tốt về độ trễ |

Dòng cuối rất hữu ích để đặt cảnh báo: nếu thông điệp cũ nhất chờ quá N phút, hệ thống đang không theo kịp.

Ba cấu hình quan trọng của SQS: | Cấu hình | Việc | |---|---| | VisibilityTimeout | thời gian thông điệp bị ẩn khi đang xử lý — phải DÀI HƠN thời gian xử lý | | Long polling (20 giây) | giảm lời gọi API rỗng và chi phí | | Dead-letter queue | thông điệp lỗi sau N lần thử |

VisibilityTimeout sai là lỗi phổ biến nhất: đặt ngắn hơn thời gian xử lý khiến thông điệp xuất hiện lại và bị xử lý nhiều lần — sinh kết quả trùng lặp.

Hai loại SQS queue: | Loại | Đặc điểm | |---|---| | Standard | thông lượng gần như không giới hạn, thứ tự gần đúng, có thể trùng | | FIFO | đúng thứ tự, xử lý chính xác một lần, giới hạn thông lượng |

Với Standard queue, consumer nên được viết idempotent — xử lý cùng thông điệp hai lần cho cùng kết quả.

Ba mẫu kiến trúc phi kết dính: | Mẫu | Chi tiết | |---|---| | Work queue (SQS) | nhiều worker chia nhau công việc ← câu này | | Fan-out (SNS → nhiều SQS) | một sự kiện tới nhiều hệ thống | | Buffer trước cơ sở dữ liệu | hấp thụ đợt ghi đột biến |

Và một lưu ý về trải nghiệm người dùng: chuyển sang bất đồng bộ nghĩa là client nhận "đã tiếp nhận" thay vì "đã xong". Với thao tác cần phản hồi ngay, cần thêm cơ chế thông báo kết quả — ghi trạng thái vào DynamoDB để client hỏi, hoặc đẩy qua WebSocket.

Ba cách rút ngắn thời gian mở rộng — bổ trợ cho SQS: | Cách | Lợi ích | |---|---| | Warm pool | giữ instance ở trạng thái Stopped, khởi động rất nhanh | | AMI đã nướng sẵn ứng dụng | không cài đặt lúc khởi chạy | | Đặt MinSize đủ cao | có sẵn dung lượng nền cho đợt tăng |

Câu 138 Design Secure Architectures

A company has an On-Demand EC2 instance located in a subnet in AWS that hosts a web application. The security group attached to this EC2 instance has the following Inbound Rules:

The Route table attached to the VPC is shown below. You can establish an SSH connection into the EC2 instance from the Internet. However, you are not able to connect to the web server using your Chrome browser.


Which of the below steps would resolve the issue?

  1. A In the Security Group, add an Inbound HTTP rule.
  2. B In the Security Group, remove the SSH rule.
  3. C In the Route table, add this new route entry: 0.0.0.0 -> igw-b51618cc
  4. D In the Route table, add this new route entry: 10.0.0.0/27 -> local
Xem giải thích

Đáp án

A — Trong Security Group, thêm một Inbound rule cho HTTP.

Vì sao đúng

Đề cho hai dữ kiện, và đối chiếu chúng là ra ngay câu trả lời:

✓ SSH kết nối được từ Internet
✗ Trình duyệt Chrome KHÔNG mở được trang web

Suy luận từ hai dữ kiện đó: | Điều đã chứng minh | Bằng cách nào | |---|---| | Route table ĐÚNG | SSH từ Internet vào được nghĩa là có tuyến 0.0.0.0/0 → IGW | | Internet Gateway đã gắn | cùng lý do | | Instance có IP công khai | cùng lý do | | NACL cho phép ít nhất cổng 22 | cùng lý do |

Nên thứ duy nhất còn thiếu là quyền cho lưu lượng HTTP:

Security group hiện tại:
    Inbound: TCP 22 (SSH) từ 0.0.0.0/0   ← có, nên SSH chạy
    Inbound: TCP 80 (HTTP)               ← THIẾU, nên trình duyệt không vào được

Security group chỉ có rule Allow và mặc định chặn mọi thứ inbound — không có rule cho cổng 80 thì lưu lượng HTTP bị từ chối ngầm định.

aws ec2 authorize-security-group-ingress   --group-id sg-0abc123   --protocol tcp --port 80 --cidr 0.0.0.0/0

Đây là lối suy luận đáng học: dùng cái ĐANG HOẠT ĐỘNG để loại trừ. SSH chạy được đã chứng minh toàn bộ đường mạng từ Internet tới instance là thông — nên vấn đề chỉ có thể nằm ở lớp lọc theo cổng.

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

  • **C. Trong route table, thêm tuyến 0.0.0.0 -> igw-b51618cc — đây là phương án gần nhất và thoạt nhìn hợp lý, nhưng nó thừa: SSH đã kết nối được từ Internet, nên tuyến ra IGW chắc chắn đã tồn tại. (Và cú pháp 0.0.0.0 thiếu tiền tố — phải là 0.0.0.0/0.)
  • **D. Trong route table, thêm tuyến 10.0.0.0/27 -> local — tuyến này LUÔN có sẵn: mọi VPC tự động có tuyến local cho CIDR của mình, và không xoá được. Thêm nó không thay đổi gì.
  • **B. Trong Security Group, xoá rule SSH — làm tình hình tệ hơn: nó cắt mất đường quản trị duy nhất đang hoạt động, và không thêm quyền cho HTTP.

Ghi nhớ

Các cổng cần thuộc lòng: | Cổng | Dịch vụ | Giao thức | |---|---|---| | 22 | SSH (Linux) | TCP | | 3389 | RDP (Windows) | TCP | | 80 | HTTP | TCP | | 443 | HTTPS | TCP | | 3306 / 5432 | MySQL / PostgreSQL | TCP | | 1433 / 1521 | SQL Server / Oracle | TCP |

Bốn đặc điểm của security group: | Đặc điểm | Hệ quả | |---|---| | Có trạng thái (stateful) | chỉ cần rule một chiều — phản hồi tự động qua | | CHỈ có rule Allow | không khớp rule nào = từ chối ngầm định | | Mặc định: chặn inbound, cho mọi outbound | | | Nguồn nhận: IP, CIDR, security group, prefix list | không nhận IGW ID |

Dòng thứ hai là lý do câu trả lời là "THÊM rule", không phải "sửa rule" — không có cách nào "chặn" trong security group, chỉ có cho phép hoặc không.

Danh sách kiểm tra khi không truy cập được web server:

① Security group có rule inbound cho cổng 80/443 chưa?     ← câu này
② NACL có cho phép CẢ HAI chiều chưa?  (stateless)
③ Web server có ĐANG CHẠY và lắng nghe không?  (ss -tlnp)
④ Tường lửa của hệ điều hành có chặn không?  (iptables, firewalld)
⑤ Instance có IP công khai chưa?
⑥ Route table có tuyến ra IGW chưa?

Bước ③ và ④ nằm bên trong hệ điều hành — người ta hay chỉ nhìn cấu hình AWS và bỏ qua chúng. Với tình huống của đề, bạn đã SSH vào được nên kiểm tra rất nhanh:

sudo ss -tlnp | grep :80     # web server có lắng nghe không?
sudo systemctl status nginx  # dịch vụ có chạy không?
curl -I localhost            # thử từ chính máy đó

Nếu curl localhost thành công mà từ ngoài không vào được → chắc chắn là vấn đề security group hoặc NACL.

Security group và NACL — bảng phân biệt: | | Security group | Network ACL | |---|---|---| | Mức | ENI/instance | subnet | | Trạng thái | stateful | stateless | | Rule | CHỈ Allow | Allow VÀ Deny | | Mặc định (VPC) | chặn inbound | cho phép hết | | Mặc định (tự tạo) | chặn inbound | CHẶN HẾT |

Ba lưu ý về bảo mật khi mở cổng 80: | Lưu ý | Chi tiết | |---|---| | Cân nhắc mở 443 thay vì 80 | HTTPS nên là mặc định | | Đặt ALB hoặc CloudFront phía trước | thay vì phơi EC2 trực tiếp | | Đóng cổng 22, dùng Session Manager | loại bỏ hẳn nhu cầu SSH từ Internet |

Dòng cuối là cải thiện đáng làm nhất: Systems Manager Session Manager cho phép truy cập instance mà không cần mở cổng inbound nào, không cần SSH key, và ghi log toàn bộ phiên.

Và một mẹo chẩn đoán nhanh cho các trường hợp phức tạp hơn: VPC Reachability Analyzer phân tích đường đi từ nguồn tới đích và chỉ ra chính xác thành phần nào đang chặn — nhanh hơn kiểm tra thủ công từng lớp.

Câu 139 Design Secure Architectures

A company is using multiple AWS accounts that are consolidated using AWS Organizations. They want to copy several S3 objects to another S3 bucket that belonged to a different AWS account which they also own. The Solutions Architect was instructed to set up the necessary permissions for this task and to ensure that the destination account owns the copied objects and not the account it was sent from.

How can the Architect accomplish this requirement?

  1. A

    Enable the Requester Pays feature in the source S3 bucket. The fees would be waived through Consolidated Billing since both AWS accounts are part of AWS Organizations.
  2. B

    Configure cross-account permissions in S3 by creating an IAM customer-managed policy that allows an IAM user or role to copy objects from the source bucket in one account to the destination bucket in the other account. Then attach the policy to the IAM user or role that you want to use to copy objects between accounts.
  3. C

    Set up cross-origin resource sharing (CORS) in S3 by creating a bucket policy that allows an IAM user or role to copy objects from the source bucket in one account to the destination bucket in the other account.
  4. D

    Connect the two S3 buckets from two different AWS accounts to Amazon WorkDocs. Set up cross-account access to integrate the two S3 buckets. Use the Amazon WorkDocs console to copy the objects from one account to the other with modified object ownership assigned to the destination account.
Xem giải thích

Đáp án

B — Cấu hình quyền chéo tài khoản trong S3 bằng cách tạo một IAM customer-managed policy cho phép một IAM user hoặc role sao chép object từ bucket nguồn ở tài khoản này sang bucket đích ở tài khoản kia. Gắn policy đó cho user hoặc role dùng để sao chép.

Vì sao đúng

Đề nêu một yêu cầu tinh tế: tài khoản ĐÍCH phải SỞ HỮU object đã sao chép, không phải tài khoản nguồn.

Và điều đó quyết định AI phải thực hiện thao tác sao chép:

Nguyên tắc sở hữu object trong S3:
    Ai thực hiện lệnh PutObject/CopyObject
        → tài khoản của người đó SỞ HỮU object mới

Nên cách đúng là để tài khoản ĐÍCH kéo dữ liệu về:

IAM user/role ở TÀI KHOẢN ĐÍCH
    ↓ có quyền s3:GetObject trên bucket NGUỒN
    ↓ có quyền s3:PutObject trên bucket ĐÍCH
    ↓ thực hiện CopyObject
Object mới thuộc sở hữu của TÀI KHOẢN ĐÍCH  ✓

Policy cần có cả hai vế:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DocTuBucketNguon",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::bucket-nguon",
                   "arn:aws:s3:::bucket-nguon/*"]
    },
    {
      "Sid": "GhiVaoBucketDich",
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:PutObjectAcl"],
      "Resource": "arn:aws:s3:::bucket-dich/*"
    }
  ]
}

Và bucket policy phía nguồn phải cho phép principal của tài khoản đích đọc — truy cập chéo tài khoản luôn đòi cả hai phía cùng cho phép.

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

  • **A. Bật Requester Pays trên bucket nguồn; phí được miễn qua Consolidated Billing vì cùng tổ chức — đây là phương án gần nhất về mặt cũng nói tới truy cập chéo tài khoản, nhưng nó giải quyết vấn đề CHI PHÍ, không phải QUYỀN hay QUYỀN SỞ HỮU: Requester Pays chuyển phí truyền dữ liệu sang bên yêu cầu. Nó không cấp quyền và không quyết định ai sở hữu object.
  • **C. Thiết lập CORS bằng cách tạo bucket policy cho phép sao chép chéo tài khoản — nhầm hai khái niệm hoàn toàn khác: CORS quy định trình duyệt có cho JavaScript từ origin này gọi tài nguyên ở origin khác hay không. Nó không liên quan gì tới quyền sao chép giữa các tài khoản AWS.
  • **D. Kết nối hai bucket với Amazon WorkDocs và dùng Console của WorkDocs để sao chép — sai dịch vụ: WorkDocs là nền tảng chia sẻ tài liệu cho nhân viên. Nó không tích hợp bucket S3 theo cách đó và không phải công cụ sao chép object.

Ghi nhớ

Nguyên tắc sở hữu object trong S3 — điều cốt lõi của câu hỏi này:

Tài khoản thực hiện thao tác GHI sẽ SỞ HỮU object.

Ai chạy lệnh copy Ai sở hữu object mới
Tài khoản nguồn đẩy sang (push) tài khoản NGUỒN ← không mong muốn
Tài khoản đích kéo về (pull) tài khoản ĐÍCH ✓

Vấn đề kinh điển mà nguyên tắc này gây ra:

Tài khoản A ghi object vào bucket của tài khoản B
    → A sở hữu object
    → B KHÔNG ĐỌC ĐƯỢC object trong CHÍNH BUCKET của mình

Ba cách giải quyết vấn đề sở hữu: | Cách | Chi tiết | |---|---| | Để tài khoản đích PULL | ← đáp án của câu này | | BucketOwnerEnforced | ACL TẮT hoàn toàn, chủ bucket sở hữu MỌI object — mặc định cho bucket mới | | ACL bucket-owner-full-control | cơ chế cũ, người ghi phải khai |

BucketOwnerEnforced là giải pháp hiện đại và triệt để — nó loại bỏ hẳn vấn đề, và là mặc định cho mọi bucket tạo từ năm 2023.

Ba thiết lập quyền sở hữu object: | Thiết lập | Hành vi | |---|---| | BucketOwnerEnforced | ACL tắt; chủ bucket sở hữu mọi object | | BucketOwnerPreferred | chủ bucket sở hữu nếu người ghi khai ACL | | ObjectWriter | người ghi sở hữu — cơ chế cũ, nguồn của nhiều sự cố |

Truy cập chéo tài khoản S3 — luôn cần hai phía:

① IAM policy ở tài khoản CỦA NGƯỜI GỌI
② Bucket policy ở tài khoản SỞ HỮU BUCKET
   → thiếu MỘT trong hai = từ chối

Bucket policy phía nguồn:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::TAI-KHOAN-DICH:role/role-sao-chep"},
 "Action": ["s3:GetObject", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::bucket-nguon", "arn:aws:s3:::bucket-nguon/*"]}

Ba cách sao chép object giữa các tài khoản: | Cách | Phù hợp | |---|---| | aws s3 sync hoặc CopyObject | khối lượng nhỏ tới vừa ← câu này | | S3 Batch Operations | hàng triệu object — có báo cáo và thử lại | | S3 Replication (SRR/CRR) | đồng bộ LIÊN TỤC, tự động cho object mới |

S3 Replication đáng cân nhắc nếu đây là nhu cầu thường xuyên — nó có tuỳ chọn AccessControlTranslation đặt chủ sở hữu thành tài khoản đích một cách tự động:

"Destination": {
  "Bucket": "arn:aws:s3:::bucket-dich",
  "Account": "999988887777",
  "AccessControlTranslation": {"Owner": "Destination"}}

Ba lưu ý khi sao chép chéo tài khoản: | Lưu ý | Chi tiết | |---|---| | Object mã hoá SSE-KMS cần quyền trên CẢ HAI khoá | Decrypt ở nguồn, GenerateDataKey ở đích | | Kiểm tra Block Public Access không chặn nhầm | | | Phí truyền dữ liệu chéo Region | nếu hai bucket ở Region khác nhau |

Dòng đầu là nguyên nhân phổ biến của lỗi AccessDenied khó hiểu — bucket policy đúng nhưng object mã hoá bằng CMK mà tài khoản kia không có quyền dùng.

Câu 140 Design Cost-Optimized Architectures

A company is building an automation tool for generating custom reports on its AWS usage. The company must be able to programmatically access and forecast usage costs on specific services.

Which of the following would meet the requirements with the LEAST amount of operational overhead?

  1. A

    Use the AWS Cost Explorer API with pagination to programmatically retrieve the usage cost-related data.
  2. B

    Configure AWS Budgets to send usage cost data to the company via Amazon SNS.
  3. C

    Generate AWS Budgets reports for usage cost data and deliver them via Amazon Simple Queue Service (SQS).
  4. D

    Utilize the downloadable AWS Cost Explorer report .csv files to access the cost-related data. Predict usage costs using AWS Budgets.
Xem giải thích

Đáp án

A — Dùng AWS Cost Explorer API với phân trang (pagination) để lấy dữ liệu chi phí theo cách lập trình.

Vì sao đúng

Đề nêu hai yêu cầu, và Cost Explorer API đáp ứng cả hai: | Yêu cầu | API | |---|---| | Truy cập chi phí theo cách LẬP TRÌNH | GetCostAndUsage | | DỰ BÁO chi phí cho dịch vụ cụ thể | GetCostForecast |

Vế "forecast" là điểm quyết định — chỉ Cost Explorer có khả năng này:

GetCostForecast:
    → AWS dùng dữ liệu lịch sử và mô hình học máy
    → dự báo chi phí cho khoảng thời gian tương lai
    → lọc được theo dịch vụ, tag, tài khoản, loại chi phí

import boto3
ce = boto3.client('ce')

du_bao = ce.get_cost_forecast(
    TimePeriod={'Start': '2026-09-01', 'End': '2026-10-01'},
    Metric='UNBLENDED_COST',
    Granularity='MONTHLY',
    Filter={'Dimensions': {'Key': 'SERVICE', 'Values': ['Amazon Elastic Compute Cloud - Compute']}})

Và "with pagination" là chi tiết đúng về mặt kỹ thuật:

GetCostAndUsage trả về tối đa một lượng bản ghi nhất định mỗi lần gọi
    → dùng NextPageToken để lấy trang tiếp theo
    → lặp cho tới khi không còn token

token = None
while True:
    kq = ce.get_cost_and_usage(
        TimePeriod={'Start': '2026-08-01', 'End': '2026-09-01'},
        Granularity='DAILY', Metrics=['UnblendedCost'],
        GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}],
        **({'NextPageToken': token} if token else {}))
    xu_ly(kq['ResultsByTime'])
    token = kq.get('NextPageToken')
    if not token: break

Và "LEAST operational overhead" nghiêng về API thay vì tệp CSV: không phải tải, lưu, phân tích cú pháp hay dọn dẹp tệp nào.

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

  • **D. Dùng tệp CSV tải về từ Cost Explorer để truy cập dữ liệu; dự báo bằng AWS Budgets — đây là phương án gần nhất và có dữ liệu đúng, nhưng nó nhiều công hơn hẳn: phải tải tệp thủ công hoặc tự động hoá việc tải, lưu trữ, phân tích cú pháp. Và AWS Budgets không phải công cụ dự báo — nó đặt ngưỡng và cảnh báo.
  • **B. Cấu hình AWS Budgets gửi dữ liệu chi phí qua SNS — nhầm chức năng: Budgets gửi CẢNH BÁO khi vượt ngưỡng, không phải dữ liệu chi phí chi tiết cho công cụ tạo báo cáo. Và nó không dự báo theo dịch vụ cụ thể.
  • **C. Tạo báo cáo AWS Budgets và gửi qua SQS — hai vấn đề: Budgets không tạo báo cáo chi phí chi tiết; và Budgets không gửi được vào SQS (nó gửi qua SNS hoặc email).

Ghi nhớ

Bốn công cụ quản lý chi phí của AWS: | Công cụ | Việc | |---|---| | Cost Explorer | xem, phân tích, DỰ BÁO — có API đầy đủ ← câu này | | Cost and Usage Report (CUR) | dữ liệu CHI TIẾT NHẤT, xuất ra S3 | | AWS Budgets | đặt ngân sách, CẢNH BÁO, hành động tự động | | Cost Anomaly Detection | phát hiện chi phí bất thường bằng học máy |

Câu hỏi phân biệt:

"programmatic access", "forecast" → Cost Explorer API "chi tiết từng dòng, phân tích bằng Athena" → CUR "cảnh báo khi vượt ngân sách" → Budgets

Các API chính của Cost Explorer: | API | Việc | |---|---| | GetCostAndUsage | chi phí và mức dùng theo khoảng thời gian | | GetCostForecast | dự báo chi phí tương lai | | GetUsageForecast | dự báo mức sử dụng | | GetReservationUtilization | hiệu suất dùng Reserved Instance | | GetSavingsPlansUtilization | hiệu suất Savings Plan | | GetDimensionValues | liệt kê giá trị của một chiều |

Ba chiều phân tích hay dùng trong GroupBy: | Chiều | Ví dụ | |---|---| | SERVICE | EC2, S3, RDS | | LINKED_ACCOUNT | tách theo tài khoản trong tổ chức | | TAG | theo cost allocation tag — cần kích hoạt trước | | REGION, INSTANCE_TYPE, USAGE_TYPE | |

Ba loại metric chi phí — hay bị nhầm: | Metric | Ý nghĩa | |---|---| | UnblendedCost | chi phí thực tế của từng tài khoản | | BlendedCost | chi phí trung bình trong tổ chức | | AmortizedCost | phân bổ đều chi phí trả trước (RI, Savings Plan) |

UnblendedCost là con số khớp với hoá đơn — dùng nó cho báo cáo tài chính. AmortizedCost phản ánh đúng hơn chi phí kinh tế khi có cam kết trả trước.

Ba lưu ý về Cost Explorer API: | Lưu ý | Chi tiết | |---|---| | Tính phí theo lời gọi | ~0,01 USD mỗi request phân trang | | Dữ liệu cập nhật ít nhất mỗi 24 giờ | không phải thời gian thực | | Chỉ gọi được ở us-east-1 | endpoint toàn cầu |

Dòng đầu đáng lưu ý cho công cụ tự động: gọi API liên tục cho báo cáo chi tiết có thể tốn kém — nên cache kết quả và chỉ lấy dữ liệu mới.

Và một lựa chọn thay thế cho báo cáo rất chi tiết: Cost and Usage Report xuất vào S3 rồi truy vấn bằng Athena. Nó cho dữ liệu ở mức từng dòng (từng giờ, từng tài nguyên), rẻ hơn khi phân tích khối lượng lớn, nhưng không có khả năng dự báo — nên với yêu cầu của đề, Cost Explorer API vẫn là câu trả lời đúng.