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

Tìm thấy 2194 câu.

Câu 171 Chọn nhiều đáp án Design High-Performing Architectures

Due to the large volume of query requests, the database performance of an online reporting application significantly slowed down. The Solutions Architect is trying to convince her client to use Amazon RDS Read Replica for their application instead of setting up a Multi-AZ Deployments configuration.

What are two benefits of using Read Replicas over Multi-AZ that the Architect should point out? (Select TWO.)

A
It elastically scales out beyond the capacity constraints of a single DB instance for read-heavy database workloads.
B Allows both read and write operations on the read replica to complement the primary database.
C
Provides asynchronous replication and improves the performance of the primary database by taking read-heavy database workloads from it.
D
Provides synchronous replication and automatic failover in the case of Availability Zone service failures.
E
It enhances the read performance of your primary database by increasing its IOPS and accelerates its query processing via AWS Global Accelerator.

Xem giải thích

Đáp án

A và C.

A — Mở rộng theo chiều ngang vượt giới hạn của một DB instance cho workload nặng về đọc
C — Sao chép BẤT ĐỒNG BỘ và cải thiện hiệu năng của database chính bằng cách gánh bớt tải đọc

Vì sao đúng

Đề mô tả vấn đề rõ: lượng truy vấn lớn làm database chậm — và đó là bài toán mà read replica sinh ra để giải.

A — read replica mở rộng khả năng ĐỌC:

Một DB instance có giới hạn CPU, bộ nhớ, IOPS
    ↓
Thêm read replica (tối đa 5 với RDS, 15 với Aurora)
    → mỗi replica phục vụ truy vấn đọc riêng
    → tổng khả năng đọc TĂNG THEO SỐ REPLICA
    → vượt được giới hạn của một instance đơn

C — và cơ chế sao chép là bất đồng bộ, khác hẳn Multi-AZ:

Read replica:
    Primary ghi xong → TRẢ LỜI CLIENT NGAY
                    → sao chép sang replica ở nền
    → primary KHÔNG PHẢI CHỜ replica
    → không làm chậm ghi

Multi-AZ:
    Primary ghi → CHỜ standby xác nhận → mới trả lời client
    → có độ trễ ghi cao hơn

Và việc chuyển tải đọc sang replica giải phóng tài nguyên cho primary — đó chính là "improves the performance of the primary database" trong phương án C.

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

**D. Cung cấp sao chép ĐỒNG BỘ và tự động failover khi AZ gặp sự cố — đây là phương án gần nhất và là mô tả CHÍNH XÁC của Multi-AZ, không phải của read replica. Đề hỏi lợi ích của read replica so với Multi-AZ, nên đây là câu trả lời ngược.
**B. Cho phép CẢ đọc lẫn GHI trên read replica — sai về mặt kỹ thuật: read replica chỉ đọc. (Aurora có chế độ multi-master và Aurora Global Database có write forwarding, nhưng đó là tính năng riêng, không phải bản chất của read replica.)
**E. Tăng IOPS của primary và tăng tốc truy vấn qua AWS Global Accelerator — hai lỗi: read replica không tăng IOPS của primary. Và Global Accelerator tối ưu đường mạng cho lưu lượng TCP/UDP, nó không liên quan gì tới xử lý truy vấn cơ sở dữ liệu.

Ghi nhớ

Read replica và Multi-AZ — bảng phân biệt cốt lõi: | | Read replica | Multi-AZ | |---|---|---| | Mục đích | MỞ RỘNG khả năng đọc | SẴN SÀNG CAO | | Sao chép | BẤT ĐỒNG BỘ | ĐỒNG BỘ | | Instance dự phòng | PHỤC VỤ truy vấn đọc | KHÔNG phục vụ gì — chỉ chờ | | Failover | thủ công (promote) | TỰ ĐỘNG | | Vị trí | cùng AZ, khác AZ, hoặc khác REGION | AZ khác trong cùng Region | | Số lượng | tới 5 (RDS) / 15 (Aurora) | 1 standby | | Độ trễ dữ liệu | có thể tụt hậu vài giây | không — luôn đồng bộ |

Và chúng KHÔNG loại trừ nhau — kiến trúc sản xuất điển hình dùng cả hai:

Primary (Multi-AZ)  ──đồng bộ──▶  Standby   (sẵn sàng cao)
      │
      └──bất đồng bộ──▶  Read replica × N   (mở rộng đọc)

Bốn công dụng của read replica: | Công dụng | Chi tiết | |---|---| | Gánh tải đọc | ← câu này | | Chạy báo cáo và phân tích | không ảnh hưởng ứng dụng sản xuất | | Read replica xuyên Region | phục hồi thảm hoạ + giảm độ trễ cho người dùng ở xa | | Nâng cấp phiên bản có kiểm soát | promote replica đã nâng cấp |

Ba lưu ý quan trọng khi dùng read replica: | Lưu ý | Chi tiết | |---|---| | Độ trễ sao chép (replica lag) | ứng dụng có thể đọc được dữ liệu CŨ | | Ứng dụng phải tự tách endpoint đọc và ghi | không tự động | | Promote là thao tác MỘT CHIỀU | replica thành instance độc lập, không quay lại được |

Dòng đầu là cạm bẫy thực tế lớn nhất: người dùng vừa cập nhật hồ sơ rồi tải lại trang, truy vấn đi vào replica chưa kịp đồng bộ và thấy dữ liệu cũ. Giải pháp: đọc-sau-ghi phải trỏ vào primary, chỉ truy vấn không nhạy cảm về độ mới mới dùng replica.

Metric cần đặt alarm: ReplicaLag (RDS) hoặc AuroraReplicaLag (Aurora). Độ trễ tăng đột biến thường do primary ghi quá nhiều hoặc replica thiếu tài nguyên.

Aurora có ưu thế rõ rệt ở khoản này: | | RDS read replica | Aurora replica | |---|---|---| | Cơ chế | sao chép qua log của engine | CHIA SẺ chung tầng lưu trữ | | Độ trễ | giây | mili giây | | Số lượng | tối đa 5 | tối đa 15 | | Failover | thủ công | tự động, dưới 30 giây | | Reader endpoint | không có sẵn | ✅ tự cân bằng tải giữa các replica |

Reader endpoint của Aurora là tiện ích đáng giá: ứng dụng chỉ cần một địa chỉ, Aurora tự phân phối truy vấn đọc giữa các replica — không phải tự viết logic cân bằng tải.

Và một lựa chọn thay thế đáng cân nhắc trước khi thêm replica: thêm tầng cache. Với ứng dụng báo cáo có nhiều truy vấn lặp lại, ElastiCache thường cắt được phần lớn tải đọc với chi phí thấp hơn một replica, và độ trễ tính bằng micro giây thay vì mili giây.

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

A company is using Amazon VPC that has a CIDR block of 10.31.0.0/27 that is connected to the on-premises data center. There was a requirement to create a Lambda function that will process massive amounts of cryptocurrency transactions every minute and then store the results to EFS. After setting up the serverless architecture and connecting the Lambda function to the VPC, the Solutions Architect noticed an increase in invocation errors with EC2 error types such as EC2ThrottledException at certain times of the day.

Which of the following are the possible causes of this issue? (Select TWO.)

A
Your Lambda function exceeds the VPC quota for Elastic Network Interfaces (ENIs) or available IP addresses in the subnet.
B
Your VPC does not have a NAT gateway.
C
The Lambda function is placed in a VPC subnet with limited IP address capacity.
D
The associated security group of your function does not allow outbound connections.
E
The attached IAM execution role of your function does not have the necessary permissions to access the resources of your VPC.

Xem giải thích

Đáp án

A và C.

A — Lambda function vượt hạn mức ENI của VPC hoặc hết địa chỉ IP khả dụng trong subnet
C — Lambda function được đặt trong subnet có dung lượng địa chỉ IP hạn chế

Vì sao đúng

Đề cho một con số quyết định: CIDR của VPC là 10.31.0.0/27.

Tính ra số địa chỉ khả dụng:

/27 → 32 địa chỉ IP tổng cộng
AWS giữ 5 địa chỉ trong MỖI subnet:
    .0   địa chỉ mạng
    .1   router của VPC
    .2   máy chủ DNS
    .3   dành riêng cho tương lai
    .31  địa chỉ broadcast
        ↓
CÒN LẠI: 27 địa chỉ dùng được cho CẢ VPC

Và đó là con số cực kỳ nhỏ cho một Lambda xử lý "khối lượng khổng lồ giao dịch mỗi phút":

Lambda gắn vào VPC cần ENI (elastic network interface)
    → mỗi ENI chiếm MỘT địa chỉ IP trong subnet
    → nhiều lời gọi đồng thời → cần nhiều ENI
    → hết IP → EC2ThrottledException

Và triệu chứng "xảy ra vào một số thời điểm nhất định trong ngày" khớp chính xác:

Giờ thấp điểm  → ít lời gọi đồng thời → đủ IP → chạy bình thường
Giờ cao điểm   → nhiều lời gọi đồng thời → HẾT IP → lỗi

EC2ThrottledException là mã lỗi Lambda trả về khi không cấp được ENI — nguyên nhân gần như luôn là hết IP hoặc chạm hạn mức ENI của Region.

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

**B. VPC không có NAT gateway — gây lỗi khác: thiếu NAT gateway khiến Lambda trong private subnet không gọi được dịch vụ trên Internet, và lỗi sẽ là timeout khi gọi ra ngoài, không phải EC2ThrottledException lúc khởi tạo.
**D. Security group của function không cho phép kết nối RA — cũng gây timeout khi gọi tới EFS hay dịch vụ khác, không phải lỗi cấp phát ENI. Lambda vẫn khởi tạo được bình thường.
**E. IAM execution role thiếu quyền truy cập tài nguyên VPC — thiếu quyền gây lỗi ngay và LIÊN TỤC, không phải "vào một số thời điểm nhất định". Nếu role thiếu ec2:CreateNetworkInterface, function hỏng mọi lúc.

(Ghi chú: A và C mô tả cùng một nguyên nhân gốc ở hai mức diễn đạt — hết địa chỉ IP. Bộ đề tách thành hai phương án cho khớp yêu cầu "chọn hai", nên nếu bạn thấy chúng trùng ý thì cảm nhận đó là đúng.)

Ghi nhớ

Số IP bị AWS giữ trong mỗi subnet: 5. Bảng dung lượng thực tế: | CIDR | Tổng IP | Dùng được | |---|---|---| | /28 | 16 | 11 (nhỏ nhất cho phép) | | /27 | 32 | 27 ← câu này | | /26 | 64 | 59 | | /24 | 256 | 251 | | /16 | 65.536 | 65.531 (lớn nhất cho phép) |

VPC cho phép từ /16 tới /28 — nhưng chọn /27 cho một VPC sản xuất là quá nhỏ, gần như chắc chắn sẽ gặp vấn đề.

Cách Lambda hoạt động trong VPC — đã thay đổi lớn: | | Trước 2019 | Hiện nay (Hyperplane ENI) | |---|---|---| | Số ENI | một ENI cho MỖI môi trường thực thi đồng thời | ENI DÙNG CHUNG theo (subnet + security group) | | Cold start | rất chậm (~10 giây tạo ENI) | nhanh — ENI tạo sẵn | | Tiêu thụ IP | rất nhiều | ít hơn HẲN |

Nhờ thay đổi này, việc hết IP vì Lambda hiếm gặp hơn xưa nhiều — nhưng với subnet /27 và mức đồng thời cao thì vẫn xảy ra được. Câu hỏi phản ánh cả hai thời kỳ.

Ba cách khắc phục lỗi hết IP: | Cách | Chi tiết | |---|---| | Dùng subnet LỚN HƠN | /24 trở lên cho subnet chứa Lambda | | Thêm subnet ở nhiều AZ | Lambda phân bổ ENI qua các subnet đã khai | | Đặt reserved concurrency | giới hạn mức đồng thời tối đa | | Xem lại xem có CẦN gắn VPC không | ← quan trọng nhất |

Dòng cuối đáng suy nghĩ: Lambda chỉ nên gắn vào VPC khi cần truy cập tài nguyên riêng tư (RDS, ElastiCache, EFS, endpoint nội bộ). Gọi S3, DynamoDB, SQS thì không cần VPC — và bỏ gắn VPC loại bỏ hoàn toàn lớp vấn đề này.

(Trong đề, Lambda ghi kết quả vào EFS — nên nó bắt buộc phải ở trong VPC. Cách sửa đúng ở đây là mở rộng CIDR.)

Và VPC có thể thêm CIDR block phụ:

aws ec2 associate-vpc-cidr-block --vpc-id vpc-0abc123   --cidr-block 10.31.64.0/18

Không đổi được CIDR chính, nhưng thêm được dải mới rồi tạo subnet lớn hơn trong đó — cách sửa không cần dựng lại VPC.

Ba metric cần giám sát cho Lambda trong VPC: | Metric | Cảnh báo khi | |---|---| | Errors kèm EC2ThrottledException | hết IP hoặc chạm hạn mức ENI | | ConcurrentExecutions | tiến gần hạn mức tài khoản (mặc định 1.000) | | IP khả dụng của subnet | theo dõi qua AWS Config hoặc script định kỳ |

Và một lưu ý về EFS làm đích ghi: với "khối lượng khổng lồ giao dịch mỗi phút", hãy kiểm tra chế độ throughput của EFS. Chế độ Bursting tích luỹ tín dụng theo dung lượng lưu trữ; file system nhỏ mà ghi liên tục sẽ cạn tín dụng và tụt xuống mức cơ sở rất thấp. Elastic throughput tránh được điều đó.

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

An aerospace engineering company recently adopted a hybrid cloud infrastructure with AWS. One of the Solutions Architect’s tasks is to launch a VPC with both public and private subnets for their EC2 instances as well as their database instances.

Which of the following statements are true regarding Amazon VPC subnets? (Select TWO.)

A EC2 instances in a private subnet can communicate with the Internet only if they have an Elastic IP.
B Each subnet maps to a single Availability Zone.
C
The allowed block size in VPC is between a /16 netmask (65,536 IP addresses) and /27 netmask (32 IP addresses).
D Every subnet that you create is automatically associated with the main route table for the VPC.
E Each subnet spans to 2 Availability Zones.

Xem giải thích

Đáp án

B và D.

B — Mỗi subnet ánh xạ tới MỘT Availability Zone
D — Mọi subnet bạn tạo đều tự động gắn với main route table của VPC

Vì sao đúng

B — subnet là khái niệm gắn với đúng một AZ:

VPC          → phạm vi REGION (trải khắp mọi AZ)
Subnet       → phạm vi MỘT AZ duy nhất

Đó là lý do kiến trúc sẵn sàng cao luôn cần ít nhất hai subnet ở hai AZ khác nhau — một subnet không thể tự trải qua nhiều AZ.

D — main route table là mặc định cho mọi subnet mới:

Tạo VPC → AWS tự tạo MAIN ROUTE TABLE
    ↓
Tạo subnet mới → TỰ ĐỘNG gắn với main route table
    ↓
Muốn khác → tạo custom route table rồi gắn tường minh

Và đây là nguồn gốc của một lỗi cấu hình rất phổ biến:

Thêm route ra Internet Gateway vào MAIN route table
    → MỌI subnet chưa gắn bảng riêng đều thành PUBLIC
    → kể cả subnet bạn định làm private

Thực hành tốt: giữ main route table KHÔNG có đường ra Internet, và tạo custom route table riêng cho public subnet.

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

**C. Kích thước block cho phép trong VPC là từ /16 tới /27 — đây là phương án gần nhất và gần đúng, nhưng sai con số: giới hạn nhỏ nhất là /28 (16 địa chỉ), không phải /27. Giới hạn lớn nhất /16 thì đúng.
**A. EC2 trong private subnet chỉ ra Internet được nếu có Elastic IP — sai về mặt định nghĩa: private subnet là subnet không có đường ra Internet Gateway. Gắn Elastic IP vào instance ở đó không giúp gì — thiếu route thì gói tin không đi đâu được. Ra Internet từ private subnet phải qua NAT gateway.
**E. Mỗi subnet trải qua 2 Availability Zone — sai, mâu thuẫn trực tiếp với B.

Ghi nhớ

Phạm vi của các thành phần mạng trong AWS: | Thành phần | Phạm vi | |---|---| | VPC | REGION | | Subnet | MỘT Availability Zone | | Route table | VPC (gắn với nhiều subnet) | | Internet Gateway | VPC (một cái mỗi VPC) | | NAT Gateway | MỘT AZ — cần một cái mỗi AZ để chịu lỗi | | Security group | VPC | | Network ACL | VPC (gắn với subnet) |

Dòng NAT Gateway là chi tiết thiết kế quan trọng: đặt một NAT gateway duy nhất rồi cho mọi private subnet dùng chung nghĩa là AZ chứa nó sập thì mọi subnet mất đường ra Internet. Kiến trúc chịu lỗi cần một NAT gateway mỗi AZ.

Giới hạn kích thước CIDR: | Loại | Nhỏ nhất | Lớn nhất | |---|---|---| | VPC | /28 (16 IP) | /16 (65.536 IP) | | Subnet | /28 (16 IP) | tuỳ CIDR của VPC |

AWS giữ 5 địa chỉ trong mỗi subnet:

.0   địa chỉ mạng
.1   router của VPC
.2   máy chủ DNS
.3   dành riêng cho tương lai
.255 (địa chỉ cuối) broadcast

→ subnet /28 chỉ còn 11 địa chỉ dùng được.

Public subnet và private subnet — khác biệt duy nhất: | | Public subnet | Private subnet | |---|---|---| | Route tới Internet Gateway | CÓ | KHÔNG | | Ra Internet | trực tiếp | qua NAT gateway | | Vào từ Internet | được (nếu SG cho phép) | không | | Cần IP công khai | có | không |

Không có công tắc "public/private" nào cả — nó hoàn toàn do route table quyết định.

Ba thành phần mà mọi VPC tự có khi tạo: | Thành phần | Đặc điểm | |---|---| | Main route table | subnet mới tự gắn vào đây ← đáp án D | | Default security group | cho phép mọi lưu lượng giữa các thành viên cùng nhóm | | Default network ACL | cho phép MỌI lưu lượng vào và ra |

Lưu ý về NACL: bảng mặc định của VPC cho phép hết, nhưng NACL bạn TỰ TẠO thì CHẶN hết — khác biệt này gây rất nhiều sự cố khó chẩn đoán.

Ba lời khuyên khi thiết kế CIDR cho VPC: | Lời khuyên | Lý do | |---|---| | Chọn dải RỘNG ngay từ đầu | CIDR chính không đổi được sau khi tạo | | Không trùng với dải của trung tâm dữ liệu tại chỗ | trùng thì không kết nối lai được | | Chừa chỗ cho subnet mới | kiến trúc luôn phát triển |

Nếu lỡ chọn dải quá nhỏ, vẫn cứu được bằng CIDR phụ:

aws ec2 associate-vpc-cidr-block --vpc-id vpc-0abc123   --cidr-block 10.2.0.0/16

Mỗi VPC gắn thêm được tới 4 CIDR block phụ.

Và một lưu ý cho kiến trúc lai như đề mô tả: khi VPC kết nối với trung tâm dữ liệu qua Direct Connect hoặc VPN, dải IP của VPC không được chồng lấn với dải tại chỗ. Đây là quyết định phải đúng ngay từ đầu — sửa sau nghĩa là dựng lại toàn bộ VPC.

Câu 174 Design Secure Architectures

A company that is rapidly growing in recent months has been in the process of setting up IAM users on its single AWS Account. A solutions architect has been tasked to handle the user management, which includes granting read-only access to users and denying permissions whenever an IAM user has no MFA setup. New users will be added frequently based on their respective departments.

Which of the following action is the MOST secure way to grant permissions to the new users?

A
Launch an IAM Group for each department. Create an IAM Policy that enforces MFA authentication with the least privilege permission. Attach the IAM Policy to each IAM Group.
B
Create a Service Control Policy (SCP) that enforces MFA authentication for each department. Add a trust relationship to every SCP and attach it to each IAM User.
C
Create an IAM Role that enforces MFA authentication with the least privilege permission. Set up a corresponding IAM Group for each department. Attach the IAM Role to the IAM Groups.
D
Set up IAM roles for each IAM user and associate a permissions boundary that defines the maximum permissions.

Xem giải thích

Đáp án

A — Tạo một IAM Group cho mỗi phòng ban; tạo IAM Policy bắt buộc xác thực MFA với quyền tối thiểu; gắn policy vào từng group.

Vì sao đúng

Đề nêu ba yêu cầu, và mô hình group + policy đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Cấp quyền chỉ đọc | policy với quyền tối thiểu | | TỪ CHỐI quyền khi user chưa thiết lập MFA | điều kiện aws:MultiFactorAuthPresent | | User mới thêm THƯỜNG XUYÊN theo phòng ban | thêm user vào group là xong — không phải gắn policy từng người |

Group là cách quản lý quyền có khả năng mở rộng:

KHÔNG dùng group:
    100 user × gắn policy thủ công
        → sửa quyền phải sửa 100 chỗ
        → chắc chắn có chỗ bị bỏ sót

Dùng group:
    Policy gắn vào GROUP
        → thêm user = thêm vào group
        → sửa quyền = sửa policy MỘT LẦN, áp cho cả group

Và điều kiện MFA viết trong policy:

{
  "Effect": "Deny",
  "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice",
                "iam:ListMFADevices", "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice", "sts:GetSessionToken"],
  "Resource": "*",
  "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
}

Hai chi tiết quan trọng trong đoạn trên: | Chi tiết | Lý do | |---|---| | NotAction chừa các thao tác IAM về MFA | không chừa thì user chưa có MFA KHÔNG THỂ tự thiết lập MFA — khoá chết | | BoolIfExists chứ không phải Bool | xử lý đúng trường hợp khoá điều kiện không tồn tại |

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

**C. Tạo một IAM Role bắt buộc MFA; tạo group cho mỗi phòng ban; gắn ROLE vào GROUP — đây là phương án gần nhất và có ý tưởng nhóm theo phòng ban đúng, nhưng nó sai về mặt kỹ thuật: KHÔNG gắn IAM role vào IAM group được. Role được đảm nhận (assume), không phải gắn. Group chỉ nhận policy.
**B. Tạo Service Control Policy (SCP) cho mỗi phòng ban; thêm trust relationship và gắn SCP vào từng IAM User — hai lỗi: SCP thuộc về AWS Organizations và gắn vào tài khoản hoặc OU, không gắn vào IAM user. Và đề nói rõ đây là một tài khoản AWS duy nhất — SCP không áp dụng.
**D. Thiết lập IAM role cho mỗi IAM user kèm permissions boundary — không mở rộng được: mỗi user một role nghĩa là quản lý thủ công từng người, đúng vấn đề mà đề muốn tránh. Permissions boundary là công cụ tốt nhưng nó giới hạn quyền tối đa, không tự cấp quyền.

Ghi nhớ

Bốn loại thực thể IAM và cách chúng kết hợp: | Thực thể | Nhận policy | Ghi chú | |---|---|---| | User | ✅ | người hoặc ứng dụng cụ thể | | Group | ✅ | TẬP HỢP user — không đăng nhập được | | Role | ✅ | được ĐẢM NHẬN tạm thời, có thông tin đăng nhập ngắn hạn | | Policy | — | tài liệu JSON mô tả quyền |

Quy tắc kết hợp — hay bị hỏi:

✅ Gắn policy vào user
✅ Gắn policy vào group
✅ Gắn policy vào role
✅ Thêm user vào group
❌ Thêm GROUP vào group          (không lồng group được)
❌ Gắn ROLE vào group            ← điểm sai của phương án C
❌ Thêm role vào group

Ba loại policy hay nhầm lẫn: | Loại | Gắn vào | Việc | |---|---|---| | Identity-based policy | user, group, role | CẤP quyền | | Resource-based policy | S3 bucket, SQS queue, KMS key | cấp quyền cho principal từ ngoài | | Service Control Policy (SCP) | tài khoản hoặc OU trong Organizations | GIỚI HẠN quyền tối đa — KHÔNG cấp quyền | | Permissions boundary | user hoặc role | giới hạn quyền tối đa của thực thể đó |

SCP và permissions boundary đều là "trần quyền", không phải "nguồn quyền" — chúng chỉ giới hạn những gì identity-based policy đã cấp.

Ba khoá điều kiện liên quan tới MFA: | Khoá | Ý nghĩa | |---|---| | aws:MultiFactorAuthPresent | phiên hiện tại có xác thực MFA không | | aws:MultiFactorAuthAge | bao nhiêu giây kể từ lúc xác thực MFA | | aws:SecureTransport | request có qua HTTPS không |

aws:MultiFactorAuthAge hữu ích cho thao tác nhạy cảm: yêu cầu MFA phải mới trong vòng 15 phút cho các hành động như xoá tài nguyên.

Năm thực hành tốt về IAM: | Thực hành | Lý do | |---|---| | Quyền tối thiểu | cấp đúng thứ cần, mở rộng khi có nhu cầu thật | | Dùng group thay vì gắn policy từng user | ← câu này | | Bắt buộc MFA cho mọi người dùng | chặn phần lớn tấn công chiếm tài khoản | | Dùng role thay vì access key dài hạn | thông tin đăng nhập tự hết hạn | | Không dùng tài khoản root cho việc hằng ngày | bật MFA cho root rồi cất đi |

Và với công ty đang phát triển nhanh như đề mô tả, hãy cân nhắc IAM Identity Center (trước đây là AWS SSO) thay vì IAM user:

Kết nối với nhà cung cấp danh tính sẵn có (AD, Okta, Entra ID)
    → không tạo IAM user thủ công cho từng người
    → nhân viên nghỉ việc → xoá ở một chỗ, mất quyền mọi nơi
    → MFA và permission set quản lý tập trung

Đây là hướng đi AWS khuyến nghị hiện nay, đặc biệt khi số lượng người dùng tăng nhanh.

Và một công cụ hữu ích để kiểm chứng nguyên tắc quyền tối thiểu: IAM Access Analyzer có tính năng sinh policy từ hoạt động thực tế trong CloudTrail — thay vì đoán xem user cần quyền gì, bạn cấp rộng trong môi trường thử, đo xem họ thật sự dùng gì, rồi sinh policy khớp chính xác.

Câu 175 Design Resilient Architectures

A major TV network has a web application running on eight Amazon T3 EC2 instances behind an application load balancer. The number of requests that the application processes are consistent and do not experience spikes. A Solutions Architect must configure an Auto Scaling group for the instances to ensure that the application is running at all times.

Which of the following options can satisfy the given requirements?

A
Deploy eight EC2 instances with Auto Scaling in one Availability Zone behind an Amazon Elastic Load Balancer.
B
Deploy four EC2 instances with Auto Scaling in one region and four in another region behind an Amazon Elastic Load Balancer.
C
Deploy four EC2 instances with Auto Scaling in one Availability Zone and four in another availability zone in the same region behind an Amazon Elastic Load Balancer.
D
Deploy two EC2 instances with Auto Scaling in four regions behind an Amazon Elastic Load Balancer.

Xem giải thích

Đáp án

C — Triển khai 4 EC2 instance với Auto Scaling ở một AZ và 4 ở AZ khác trong CÙNG Region, sau một Elastic Load Balancer.

Vì sao đúng

Đề nêu ba dữ kiện, và cấu hình này đáp ứng chính xác: | Dữ kiện | Cơ chế | |---|---| | Cần 8 instance, tải ỔN ĐỊNH không có đột biến | giữ đủ 8 máy, không cần mở rộng phức tạp | | Ứng dụng phải chạy MỌI LÚC | trải qua 2 AZ — một AZ sập vẫn còn 4 máy | | Dùng Auto Scaling và ELB | ASG tự thay instance hỏng, ELB phân phối tải |

Vì sao phải chia đôi qua hai AZ:

Tất cả 8 máy trong MỘT AZ:
    AZ đó gặp sự cố → mất TOÀN BỘ dịch vụ

Chia 4 + 4 qua HAI AZ:
    Một AZ sập → còn 4 máy phục vụ
    → ASG tự khởi chạy máy bù ở AZ còn lại
    → dịch vụ KHÔNG gián đoạn

Và vì sao trong CÙNG một Region:

Elastic Load Balancer hoạt động trong PHẠM VI MỘT REGION
    → nó KHÔNG phân phối lưu lượng qua nhiều Region
    → muốn đa Region phải dùng Route 53 hoặc Global Accelerator

Đây là điểm loại bỏ hai phương án đa Region.

Auto Scaling ở đây phục vụ SẴN SÀNG chứ không phải mở rộng:

Đặt Min = Desired = Max = 8
    → tải ổn định nên không cần co giãn
    → nhưng ASG vẫn TỰ THAY instance hỏng
    → và tự cân bằng lại giữa các AZ

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

**A. Triển khai 8 instance với Auto Scaling trong MỘT Availability Zone — đây là phương án gần nhất về số lượng máy, nhưng nó không chịu được sự cố AZ: một AZ gặp vấn đề là mất toàn bộ ứng dụng. Yêu cầu "running at all times" không được đáp ứng.
**B. 4 instance ở một Region và 4 ở Region khác sau một ELB — sai về mặt kỹ thuật: một ELB không trải qua nhiều Region. Kiến trúc này không dựng được như mô tả.
**D. 2 instance ở bốn Region khác nhau sau một ELB — cùng lỗi và nghiêm trọng hơn: ELB không đa Region, và chia nhỏ thành 2 máy mỗi nơi khiến mỗi Region rất mong manh.

Ghi nhớ

Phạm vi hoạt động của các thành phần — bảng cần thuộc: | Thành phần | Phạm vi | |---|---| | Elastic Load Balancer | MỘT Region (trải qua nhiều AZ) | | Auto Scaling group | MỘT Region (trải qua nhiều AZ) | | Subnet | MỘT AZ | | Route 53 | TOÀN CẦU — dùng để định tuyến đa Region | | CloudFront | toàn cầu | | Global Accelerator | toàn cầu — IP tĩnh, định tuyến qua mạng AWS |

Quy tắc nhận diện:

Sẵn sàng cao TRONG một Region → nhiều AZ + ELB + ASG Chịu được sự cố CẢ REGION → Route 53 hoặc Global Accelerator + hạ tầng ở mỗi Region

Ba nguyên tắc thiết kế sẵn sàng cao trên AWS: | Nguyên tắc | Cách làm | |---|---| | Trải qua ít nhất HAI AZ | yêu cầu tối thiểu cho mọi hệ thống sản xuất | | Đủ dung lượng khi mất một AZ | N+1 — mỗi AZ chịu được phần tải của AZ kia | | Không có điểm hỏng đơn | ELB, ASG, RDS Multi-AZ |

Dòng giữa là tính toán dung lượng đáng lưu ý cho tình huống này: chia 4+4 nghĩa là khi mất một AZ, còn 4 máy phải gánh tải vốn dành cho 8. Nếu ứng dụng thực sự cần đủ 8 máy để phục vụ, cấu hình an toàn hơn là triển khai 4+4 nhưng mỗi AZ đủ sức chạy toàn bộ tải, hoặc trải qua ba AZ với tỷ lệ dự phòng thấp hơn.

Vì sao ba AZ thường hiệu quả hơn hai:

2 AZ, cần 8 máy phục vụ:  phải dựng 8+8 = 16 máy để chịu mất 1 AZ
3 AZ, cần 8 máy phục vụ:  dựng 4+4+4 = 12 máy là đủ
    → mất 1 AZ → còn 8 máy → vừa đủ
    → tiết kiệm 25% chi phí với cùng mức chịu lỗi

Ba cấu hình Auto Scaling group cho tải ổn định: | Cấu hình | Giá trị đề xuất | |---|---| | Min | 8 — đảm bảo luôn có đủ máy | | Desired | 8 | | Max | cao hơn một chút để chịu tăng đột biến bất ngờ |

Đặt Max = Min = 8 cũng chạy được, nhưng chừa biên độ giúp hệ thống sống sót qua một đợt tăng tải không lường trước.

Ba tính năng của ASG phục vụ sẵn sàng cao: | Tính năng | Việc | |---|---| | Health check tích hợp ELB | thay instance mà ELB đánh giá là hỏng, không chỉ instance chết hẳn | | AZ Rebalancing | tự cân bằng lại số instance giữa các AZ | | Instance refresh | thay toàn bộ đội máy khi đổi AMI |

Dòng đầu là cấu hình nên bật: mặc định ASG chỉ dùng EC2 status check — instance treo ở tầng ứng dụng nhưng máy vẫn "khoẻ" sẽ không bị thay. Bật HealthCheckType=ELB mới bắt được tình huống đó:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-web   --health-check-type ELB --health-check-grace-period 300

Và một lưu ý về lựa chọn instance: đề nói dùng T3, loại có cơ chế tín dụng CPU. Với tải ổn định và liên tục, T3 ở chế độ mặc định có thể cạn tín dụng rồi bị giới hạn hiệu năng. Cân nhắc T3 Unlimited (trả thêm khi vượt mức cơ sở) hoặc chuyển sang họ M nếu mức sử dụng CPU cao đều đặn.

Câu 176 Chọn nhiều đáp án Design Cost-Optimized Architectures

In Amazon EC2, you can manage your instances from the moment you launch them up to their termination. You can flexibly control your computing costs by changing the EC2 instance state. Which of the following statements is true regarding EC2 billing? (Select TWO.)

A
You will be billed when your On-Demand instance is in pending state.
B
You will be billed when your Spot instance is preparing to stop with a stopping state.
C
You will be billed when your On-Demand instance is preparing to hibernate with a stopping state.
D
You will be billed when your Reserved instance is in terminated state.
E
You will not be billed for any instance usage while an instance is not in the running state.

Xem giải thích

Đáp án

C và D.

C — Bạn BỊ TÍNH PHÍ khi instance On-Demand đang ở trạng thái stopping để chuẩn bị HIBERNATE
D — Bạn BỊ TÍNH PHÍ khi Reserved Instance ở trạng thái terminated

Vì sao đúng

C — hibernate khác stop ở khoản tính phí:

STOP thông thường:
    trạng thái stopping → KHÔNG tính phí

HIBERNATE:
    trạng thái stopping → ĐANG GHI NỘI DUNG RAM XUỐNG ĐĨA
        → instance vẫn dùng tài nguyên vật lý
        → VẪN TÍNH PHÍ cho tới khi vào trạng thái stopped

Lý do rất hợp lý: hibernate phải sao chép toàn bộ RAM (có thể hàng chục GB) xuống EBS, và trong lúc đó máy chủ vật lý vẫn đang phục vụ instance này.

D — Reserved Instance tính phí theo CAM KẾT, không theo việc dùng:

Reserved Instance = cam kết TRẢ TIỀN trong 1 hoặc 3 năm
    → chấm dứt instance KHÔNG huỷ được cam kết
    → vẫn trả tiền tới hết kỳ hạn

Đây chính là bản chất của RI: bạn mua quyền được giảm giá kèm nghĩa vụ thanh toán, không phải mua một cỗ máy cụ thể.

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

**E. Bạn KHÔNG bị tính phí cho bất kỳ instance nào khi không ở trạng thái running — đây là phương án gần nhất và là quy tắc chung mà nhiều người thuộc lòng, nhưng nó có ngoại lệ — chính là C và D. Câu hỏi kiểm tra đúng những ngoại lệ đó.
**A. Bị tính phí khi instance On-Demand ở trạng thái pending — sai: pending là lúc instance đang được khởi chạy, chưa tính phí. Đồng hồ bắt đầu chạy khi vào trạng thái running.
**B. Bị tính phí khi Spot instance ở trạng thái stopping — sai: với Spot, trạng thái stopping không tính phí. (Ngoại lệ hibernate ở phương án C áp cho instance On-Demand.)

Ghi nhớ

Bảng tính phí theo trạng thái instance — nội dung cốt lõi của câu này: | Trạng thái | Tính phí instance | Tính phí EBS | |---|---|---| | pending | ❌ | ✅ | | running | ✅ | ✅ | | stopping (stop thường) | ❌ | ✅ | | stopping (chuẩn bị HIBERNATE) | ✅ | ✅ | | stopped | ❌ | ✅ — volume vẫn tính tiền | | shutting-down | ❌ | ✅ | | terminated | ❌ (trừ Reserved Instance — vẫn trả theo cam kết) | tuỳ DeleteOnTermination |

Hai ngoại lệ cần nhớ: hibernate đang stopping, và Reserved Instance.

Và một điều dễ bị bỏ sót: EBS volume tính phí ngay cả khi instance đã dừng.

Instance stopped 6 tháng
    → 0 đồng phí compute
    → NHƯNG vẫn trả tiền EBS volume mỗi tháng
    → và Elastic IP nếu có gắn (EIP không gắn vào máy đang chạy thì tính phí)

Ba mô hình mua và cách chúng phản ứng khi ngừng dùng: | Mô hình | Chấm dứt instance thì sao | |---|---| | On-Demand | ngừng tính phí ngay | | Reserved Instance | VẪN trả tới hết kỳ hạn ← đáp án D | | Savings Plan | vẫn trả cam kết USD/giờ tới hết kỳ hạn | | Spot | ngừng tính phí ngay |

Cách thoát khỏi Reserved Instance không còn dùng: | Cách | Điều kiện | |---|---| | Bán trên Reserved Instance Marketplace | chỉ Standard RI, cần tài khoản ngân hàng Mỹ, đã giữ ít nhất 30 ngày | | Đổi sang cấu hình khác | chỉ Convertible RI | | Dùng cho instance khác cùng họ | RI khu vực áp linh hoạt trong Region |

Standard RI và Convertible RI: | | Standard | Convertible | |---|---|---| | Giảm giá | cao hơn (tới 72%) | thấp hơn (tới 66%) | | Đổi loại instance | ❌ | ✅ đổi họ, hệ điều hành, tenancy | | Bán lại trên Marketplace | ✅ | ❌ |

Ba cách tối ưu chi phí EC2 theo trạng thái: | Cách | Tiết kiệm | |---|---| | Dừng instance ngoài giờ làm việc | tới ~65% cho môi trường dev/test | | Xoá EBS volume không còn dùng | volume available vẫn tính tiền | | Giải phóng Elastic IP không gắn vào đâu | EIP rảnh rỗi bị tính phí |

AWS Instance Scheduler tự động hoá dòng đầu — dừng và bật instance theo lịch dựa trên tag, thay vì tự viết Lambda.

Và một lời khuyên về chiến lược mua: với tải chưa rõ ràng, hãy chạy On-Demand vài tháng trước để đo mức sử dụng thật, rồi mới mua Savings Plan cho phần nền ổn định. Savings Plan linh hoạt hơn Reserved Instance (áp cho cả Fargate và Lambda, không ràng buộc loại instance cụ thể), và mua thiếu thì bổ sung được — còn mua thừa thì kẹt cả kỳ hạn.

Câu 177 Design Secure Architectures

A large financial firm needs to set up a Linux bastion host to allow access to the Amazon EC2 instances running in their VPC. For security purposes, only the clients connecting from the corporate external public IP address 175.45.116.100 should have SSH access to the host.

Which is the best option that can meet the customer's requirement?

A Security Group Inbound Rule: Protocol – TCP. Port Range – 22, Source 175.45.116.100/32
B Security Group Inbound Rule: Protocol – UDP, Port Range – 22, Source 175.45.116.100/32
C Network ACL Inbound Rule: Protocol – UDP, Port Range – 22, Source 175.45.116.100/32
D Network ACL Inbound Rule: Protocol – TCP, Port Range-22, Source 175.45.116.100/0

Xem giải thích

Đáp án

A — Security Group Inbound Rule: Protocol TCP, Port Range 22, Source 175.45.116.100/32.

Vì sao đúng

Đề cần cho phép SSH chỉ từ một địa chỉ IP duy nhất — và ba thành phần của rule đều phải đúng: | Thành phần | Giá trị đúng | Lý do | |---|---|---| | Giao thức | TCP | SSH chạy trên TCP | | Cổng | 22 | cổng chuẩn của SSH | | Nguồn | 175.45.116.100/32 | /32 = ĐÚNG MỘT địa chỉ |

Ý nghĩa của /32 — chi tiết quyết định của câu hỏi:

175.45.116.100/32  → 1 địa chỉ    (chỉ đúng máy đó)
175.45.116.100/24  → 256 địa chỉ  (cả dải 175.45.116.x)
175.45.116.100/0   → MỌI địa chỉ  (tương đương 0.0.0.0/0 — mở toang!)

/0 nghĩa là bỏ qua hoàn toàn phần địa chỉ — nó khớp với mọi IP trên Internet, hoàn toàn ngược với yêu cầu bảo mật của đề.

Và vì sao dùng security group chứ không phải NACL:

Security group:
    ✓ áp trực tiếp cho INSTANCE bastion
    ✓ STATEFUL — phản hồi tự động được phép, chỉ cần một rule
    ✓ chính xác về phạm vi: chỉ máy này, không ảnh hưởng máy khác

NACL:
    - áp cho CẢ SUBNET
    - STATELESS — phải thêm rule outbound cho cổng tạm
    - dễ ảnh hưởng ngoài ý muốn tới tài nguyên khác cùng subnet

aws ec2 authorize-security-group-ingress --group-id sg-bastion   --protocol tcp --port 22 --cidr 175.45.116.100/32

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

**D. Network ACL Inbound: TCP, cổng 22, Source 175.45.116.100/0 — đây là phương án gần nhất về giao thức và cổng, nhưng /0 mở cho toàn bộ Internet. Nó phá huỷ chính yêu cầu bảo mật mà đề đặt ra.
**B. Security Group: UDP, cổng 22 — sai giao thức: SSH dùng TCP. Rule UDP cổng 22 không cho phép kết nối SSH nào.
**C. Network ACL: UDP, cổng 22 — cùng lỗi giao thức, và thêm nhược điểm của NACL đã nêu.

Ghi nhớ

Ký hiệu CIDR — bảng cần thuộc: | Ký hiệu | Số địa chỉ | Dùng khi | |---|---|---| | /32 | 1 | cho phép ĐÚNG một máy | | /24 | 256 | một mạng con nhỏ | | /16 | 65.536 | một VPC lớn | | /0 | TẤT CẢ | tương đương 0.0.0.0/0 — mở toàn Internet |

Quy tắc nhanh: số càng LỚN thì phạm vi càng HẸP.

Và một lỗi bảo mật kinh điển:

✗ Cổng 22, Source 0.0.0.0/0
    → SSH phơi ra toàn Internet
    → bot quét cổng 22 liên tục, thử mật khẩu và khoá
    → đây là một trong những nguyên nhân xâm nhập phổ biến nhất

AWS Trusted Advisor và Security Hub đều có kiểm tra riêng cho tình huống này.

Kiến trúc bastion host chuẩn:

Internet
   │ SSH chỉ từ IP công ty (/32)
   ▼
Bastion host  (PUBLIC subnet, Elastic IP)
   │ SSH — security group cho phép nguồn là SG của bastion
   ▼
Instance ứng dụng  (PRIVATE subnet, không có IP công khai)

Mẹo quan trọng: security group của instance private nên nhận nguồn là SECURITY GROUP của bastion, không phải IP.

aws ec2 authorize-security-group-ingress --group-id sg-ung-dung   --protocol tcp --port 22 --source-group sg-bastion

Lợi ích: bastion đổi IP hay được thay bằng máy khác thì rule vẫn đúng — không phải cập nhật gì.

Năm biện pháp tăng cường cho bastion host: | Biện pháp | Lợi ích | |---|---| | Chỉ mở cổng 22 cho IP công ty (/32) | ← câu này | | Dùng khoá SSH, tắt xác thực mật khẩu | chặn tấn công dò mật khẩu | | Ghi log mọi phiên làm việc | phục vụ kiểm toán | | Đặt trong Auto Scaling group kích thước 1 | tự phục hồi khi máy hỏng | | Cập nhật bản vá thường xuyên | bastion là bề mặt tấn công trực tiếp |

Và một lựa chọn tốt hơn hẳn bastion host: AWS Systems Manager Session Manager.

Không cần bastion host          → bớt một máy phải vá và trả tiền
Không cần mở cổng 22 nào        → bề mặt tấn công bằng 0
Không cần IP công khai          → instance ở private subnet là đủ
Phân quyền bằng IAM             → không quản lý khoá SSH
Ghi log phiên vào S3/CloudWatch → kiểm toán đầy đủ

aws ssm start-session --target i-0abc123def456

Yêu cầu: instance có SSM Agent (AMI Amazon Linux và Ubuntu gần đây đã cài sẵn), IAM role AmazonSSMManagedInstanceCore, và VPC endpoint cho ssm, ssmmessages, ec2messages nếu ở private subnet không có NAT.

Với ngân hàng hay tổ chức tài chính như đề mô tả, Session Manager thường được ưa chuộng hơn vì nó cho kiểm toán viên bản ghi đầy đủ ai đã vào máy nào, gõ lệnh gì — thứ mà SSH truyền thống phải tự dựng thêm mới có.

Và một lưu ý thực tế về việc khoá theo IP /32: nếu văn phòng dùng IP động, rule sẽ ngừng hoạt động khi nhà mạng đổi địa chỉ. Khi đó dùng dải IP tĩnh do nhà mạng cấp, hoặc kết nối qua VPN của công ty rồi mở cho IP của cổng VPN.

Câu 178 Design Secure Architectures

A travel company has a suite of web applications hosted in an Auto Scaling group of On-Demand EC2 instances behind an Application Load Balancer that handles traffic from various web domains such as i-love-manila.com, i-love-boracay.com, i-love-cebu.com and many others. To improve security and lessen the overall cost, you are instructed to secure the system by allowing multiple domains to serve SSL traffic without the need to reauthenticate and reprovision your certificate everytime you add a new domain. This migration from HTTP to HTTPS will help improve their SEO and Google search ranking.

Which of the following is the most cost-effective solution to meet the above requirement?

A
Use a wildcard certificate to handle multiple sub-domains and different domains.
B
Add a Subject Alternative Name (SAN) for each additional domain to your certificate.
C
Create a new CloudFront web distribution and configure it to serve HTTPS requests using dedicated IP addresses in order to associate your alternate domain names with a dedicated IP address in each CloudFront edge location.
D
Upload all SSL certificates of the domains in the ALB using the console and bind multiple certificates to the same secure listener on your load balancer. ALB will automatically choose the optimal TLS certificate for each client using Server Name Indication (SNI).

Xem giải thích

Đáp án

D — Tải mọi chứng chỉ SSL của các tên miền lên ALB và gắn nhiều chứng chỉ vào cùng một listener bảo mật. ALB tự chọn chứng chỉ phù hợp cho từng client bằng Server Name Indication (SNI).

Vì sao đúng

Đề nêu yêu cầu mấu chốt: thêm tên miền mới mà KHÔNG phải cấp lại và xác thực lại chứng chỉ — và SNI làm được đúng điều đó.

Cách SNI hoạt động:

Client mở kết nối TLS
    → gửi kèm TÊN MIỀN muốn truy cập trong thông điệp ClientHello
    ↓
ALB đọc tên miền đó
    → chọn đúng chứng chỉ trong danh sách đã gắn
    → hoàn tất bắt tay TLS

Nhờ vậy MỘT listener trên cổng 443 phục vụ được nhiều tên miền hoàn toàn khác nhau:

Listener 443:
    ├── i-love-manila.com    → chứng chỉ A
    ├── i-love-boracay.com   → chứng chỉ B
    ├── i-love-cebu.com      → chứng chỉ C
    └── ... tới 25 chứng chỉ mỗi listener

Và điểm quyết định so với các cách khác: thêm tên miền = thêm MỘT chứng chỉ mới, KHÔNG đụng tới chứng chỉ đang có.

aws elbv2 add-listener-certificates --listener-arn <arn>   --certificates CertificateArn=<arn-chung-chi-moi>

Và nó miễn phí: SNI không tính thêm phí, còn chứng chỉ do AWS Certificate Manager cấp cho tài nguyên AWS cũng miễn phí — đúng yêu cầu "most cost-effective".

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

**B. Thêm Subject Alternative Name (SAN) cho mỗi tên miền mới vào chứng chỉ — đây là phương án gần nhất và về mặt kỹ thuật cũng phục vụ nhiều tên miền được, nhưng nó vi phạm chính yêu cầu của đề: thêm SAN nghĩa là cấp lại chứng chỉ và xác thực lại toàn bộ mỗi lần thêm tên miền — đúng thứ mà đề muốn tránh.
**A. Dùng wildcard certificate — không bao được nhiều tên miền KHÁC NHAU: *.example.com chỉ phủ các tên miền con của example.com. Nó không phủ được i-love-manila.com và i-love-cebu.com cùng lúc vì đó là hai tên miền gốc riêng biệt.
**C. Tạo CloudFront distribution phục vụ HTTPS bằng địa chỉ IP chuyên dụng — đắt và không cần thiết: tuỳ chọn dedicated IP của CloudFront tốn khoảng 600 USD mỗi tháng cho mỗi chứng chỉ. Nó chỉ dành cho việc hỗ trợ trình duyệt rất cũ không biết SNI.

Ghi nhớ

Ba cách phục vụ nhiều tên miền qua HTTPS: | Cách | Phạm vi | Thêm tên miền mới | |---|---|---| | Wildcard (*.example.com) | tên miền CON của MỘT tên miền | không cần làm gì (nếu là subdomain) | | SAN (nhiều tên trong 1 chứng chỉ) | nhiều tên miền khác nhau | phải CẤP LẠI chứng chỉ | | SNI (nhiều chứng chỉ, 1 listener) | nhiều tên miền khác nhau | chỉ thêm chứng chỉ mới ← câu này |

Quy tắc chọn:

Nhiều subdomain của một tên miền → wildcard Vài tên miền cố định, ít thay đổi → SAN Nhiều tên miền, THÊM THƯỜNG XUYÊN → SNI

Ba giới hạn và đặc điểm của SNI trên ALB: | Đặc điểm | Chi tiết | |---|---| | Tối đa 25 chứng chỉ mỗi listener | tăng được qua yêu cầu hạn mức | | Có một chứng chỉ MẶC ĐỊNH | dùng khi client không gửi SNI | | Miễn phí | không tính thêm phí | | Hỗ trợ trình duyệt | mọi trình duyệt hiện đại; chỉ IE trên Windows XP và Android 2.x là không |

Bốn lợi ích của AWS Certificate Manager: | Lợi ích | Chi tiết | |---|---| | Chứng chỉ công khai MIỄN PHÍ | cho tài nguyên AWS | | Tự động gia hạn | không bao giờ hết hạn bất ngờ | | Tích hợp sẵn | ALB, CloudFront, API Gateway | | Xác thực bằng DNS | thêm bản ghi CNAME một lần, gia hạn tự động vĩnh viễn |

Xác thực bằng DNS tốt hơn xác thực bằng email: bản ghi CNAME nằm đó vĩnh viễn nên ACM tự gia hạn được mãi mãi; xác thực email đòi ai đó bấm vào liên kết mỗi lần gia hạn.

Và một giới hạn quan trọng của ACM: chứng chỉ mang tính Region. | Dùng cho | Cấp chứng chỉ ở | |---|---| | ALB, API Gateway (regional) | cùng Region với tài nguyên | | CloudFront | BẮT BUỘC us-east-1 |

Dòng thứ hai là lỗi rất hay gặp: cấp chứng chỉ ở Region của ứng dụng rồi không thấy nó trong danh sách chọn của CloudFront.

Ba cấu hình HTTPS nên có cho ALB: | Cấu hình | Lý do | |---|---| | Chuyển hướng HTTP → HTTPS | redirect action trên listener cổng 80 | | Chính sách bảo mật TLS hiện đại | ELBSecurityPolicy-TLS13-1-2-2021-06 | | Bật HSTS ở tầng ứng dụng | trình duyệt tự dùng HTTPS ở lần sau |

Chuyển hướng cấu hình ngay trên ALB, không cần đụng ứng dụng:

aws elbv2 modify-listener --listener-arn <arn-listener-80>   --default-actions '[{"Type":"redirect","RedirectConfig":
    {"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Và một lưu ý về SEO như đề đề cập: chuyển sang HTTPS thực sự là yếu tố xếp hạng của Google, nhưng để giữ được thứ hạng cũ thì phải dùng chuyển hướng 301 (vĩnh viễn) chứ không phải 302 — 301 truyền lại giá trị liên kết cho URL mới, còn 302 thì không.

Câu 179 Chọn nhiều đáp án Design High-Performing Architectures

A large financial firm in the country has an AWS environment that contains several Reserved EC2 instances hosting a web application that has been decommissioned last week. To save costs, you need to stop incurring charges for the Reserved instances as soon as possible.

What cost-effective steps will you take in this circumstance? (Select TWO.)

A
Stop the Reserved instances as soon as possible.
B
Contact AWS to cancel your AWS subscription.
C
Go to the AWS Reserved Instance Marketplace and sell the Reserved instances.
D
Terminate the Reserved instances as soon as possible to avoid getting billed at the on-demand price when it expires.
E
Go to the Amazon.com online shopping website and sell the Reserved instances.

Xem giải thích

Đáp án

C và D.

C — Vào AWS Reserved Instance Marketplace và BÁN các Reserved Instance
D — Chấm dứt (terminate) các instance càng sớm càng tốt để không bị tính giá On-Demand khi reservation hết hạn

Vì sao đúng

Đề mô tả tình huống: ứng dụng đã ngừng hoạt động, còn lại các Reserved Instance đang tốn tiền.

C — bán lại là cách duy nhất thực sự thoát khỏi cam kết:

Reserved Instance = cam kết trả tiền 1 hoặc 3 năm
    → dừng hay chấm dứt instance KHÔNG huỷ được cam kết
    → cách duy nhất thu hồi giá trị: BÁN trên Marketplace

Người mua tiếp nhận phần thời hạn còn lại, bạn nhận tiền và hết nghĩa vụ.

D — và chấm dứt instance ngăn khoản chi phát sinh sau này:

Reservation hết hạn
    → instance KHÔNG tự tắt
    → nó tiếp tục chạy và bị tính GIÁ ON-DEMAND ĐẦY ĐỦ
    → hoá đơn tăng vọt mà không ai để ý

Đây là cạm bẫy chi phí rất thật: nhiều tổ chức phát hiện ra khi nhìn hoá đơn tháng sau ngày RI hết hạn.

Hai việc này bổ sung nhau: bán RI thu hồi giá trị còn lại, chấm dứt instance chặn chi phí tương lai.

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

**A. Dừng (stop) các Reserved Instance càng sớm càng tốt — đây là phương án gần nhất và là phản xạ tự nhiên, nhưng nó không tiết kiệm được gì: RI tính phí theo cam kết, không theo việc instance có chạy hay không. Dừng máy vẫn trả đủ tiền reservation, mà còn tốn thêm phí EBS.
**B. Liên hệ AWS để huỷ đăng ký AWS — biện pháp cực đoan và không giải quyết đúng vấn đề: công ty vẫn dùng AWS cho việc khác. Và huỷ tài khoản không xoá nghĩa vụ thanh toán đã cam kết.
**E. Vào Amazon.com để bán Reserved Instance — nhầm nền tảng: Amazon.com là trang thương mại điện tử bán lẻ. Reserved Instance chỉ bán được trên AWS Reserved Instance Marketplace trong AWS Console.

Ghi nhớ

Reserved Instance tính phí theo CAM KẾT, không theo mức sử dụng. | Thao tác | Có ngừng tính phí RI không | |---|---| | Dừng instance | ❌ vẫn trả đủ | | Chấm dứt instance | ❌ vẫn trả đủ tới hết kỳ hạn | | BÁN trên Marketplace | ✅ cách duy nhất | | Đổi cấu hình (chỉ Convertible RI) | ✅ chuyển giá trị sang cấu hình khác |

Điều kiện để bán Reserved Instance trên Marketplace: | Điều kiện | Chi tiết | |---|---| | Chỉ Standard RI | Convertible RI KHÔNG bán được | | Đã sở hữu ít nhất 30 ngày | tính từ ngày mua | | Cần tài khoản ngân hàng Mỹ | yêu cầu bắt buộc của AWS | | Còn ít nhất 1 tháng kỳ hạn | RI sắp hết hạn không bán được | | Đã thanh toán xong phần trả trước | với RI trả trước một phần hoặc toàn phần |

Yêu cầu tài khoản ngân hàng Mỹ là rào cản thực tế lớn nhất cho tổ chức ngoài nước Mỹ — nhiều công ty không bán được RI chỉ vì điều kiện này.

Standard RI và Convertible RI: | | Standard | Convertible | |---|---|---| | Giảm giá tối đa | 72% | 66% | | Bán trên Marketplace | ✅ | ❌ | | Đổi loại instance, hệ điều hành | ❌ | ✅ | | Phù hợp | tải rất ổn định, chắc chắn | nhu cầu có thể thay đổi |

Bài học rút ra cho tình huống của đề: nếu không chắc ứng dụng sẽ chạy đủ kỳ hạn, hãy mua Convertible RI hoặc Savings Plan thay vì Standard RI.

Savings Plan — lựa chọn linh hoạt hơn RI: | | Reserved Instance | Savings Plan | |---|---|---| | Cam kết theo | cấu hình instance cụ thể | số USD/giờ | | Áp cho Fargate và Lambda | ❌ | ✅ (Compute Savings Plan) | | Tự áp cho tài nguyên phù hợp | cần khớp cấu hình | ✅ tự động | | Bán lại | ✅ (Standard) | ❌ |

Compute Savings Plan là lựa chọn mặc định tốt cho hầu hết tổ chức hiện nay: nó tự áp cho EC2 ở mọi Region, mọi loại instance, cộng cả Fargate và Lambda — nên rủi ro "mua nhầm cấu hình" gần như biến mất.

Ba việc nên làm khi ngừng một ứng dụng trên AWS: | Việc | Lý do | |---|---| | Chấm dứt instance, xoá EBS volume | volume available vẫn tính tiền | | Giải phóng Elastic IP | EIP không gắn vào máy đang chạy bị tính phí | | Xoá snapshot, AMI, load balancer, NAT gateway không dùng | NAT gateway là khoản tốn kém âm thầm phổ biến nhất | | Xem lại RI và Savings Plan còn hiệu lực | bán hoặc chuyển sang workload khác |

AWS Cost Explorer có báo cáo "RI Utilization" và "RI Coverage" — chúng cho biết reservation nào đang không được dùng, đúng thứ cần xem trong tình huống này:

Cost Explorer → Reservations → Utilization report
    → RI dưới 100% utilization = đang trả tiền cho phần không dùng

Và một lời khuyên về quy trình: đặt AWS Budgets với cảnh báo trước ngày RI hết hạn — thông báo trước 30 ngày cho phép quyết định gia hạn, chuyển sang Savings Plan, hay tắt hẳn tài nguyên, thay vì phát hiện qua hoá đơn tăng đột ngột.

Câu 180 Chọn nhiều đáp án Design Secure Architectures

A company has clients all across the globe that access product files stored in several Amazon S3 buckets, which are behind each of the respective Amazon CloudFront web distributions. The company currently wants to deliver content to a specific client, ensuring that only that client can access the data. At present, all clients can access the S3 buckets directly using an S3 URL or through the CloudFront distribution. The Solutions Architect must serve the private content via CloudFront only, to secure the distribution of files.

Which combination of actions should the Architect implement to meet the above requirements? (Select TWO.)

A
Create a custom CloudFront function to check and ensure that only their clients can access the files.
B
Enable the Origin Shield feature of the CloudFront distribution to protect the files from unauthorized access.
C
Use S3 pre-signed URLs to ensure that only their client can access the files. Remove permission to use S3 URLs to read the files for anyone else.
D
Restrict access to files in the origin by creating an origin access control (OAC) and giving it permission to read the files in the bucket.
E
Require the users to access the private content by using special CloudFront signed URLs or signed cookies.

Xem giải thích

Đáp án

D và E.

D — Hạn chế truy cập tại origin bằng Origin Access Control (OAC) và cấp cho nó quyền đọc bucket
E — Bắt người dùng truy cập nội dung riêng tư qua CloudFront signed URL hoặc signed cookie

Vì sao đúng

Đề nêu hai vấn đề riêng biệt, và mỗi đáp án giải một vấn đề: | Vấn đề | Giải pháp | |---|---| | Hiện tại ai cũng vào thẳng S3 bằng URL của S3 | D — OAC: chỉ CloudFront đọc được bucket | | Chỉ MỘT khách hàng cụ thể được xem nội dung | E — signed URL/cookie: kiểm soát ai được xem |

D — OAC bịt đường đi vòng:

TRƯỚC:
    Người dùng → CloudFront → S3   (đường mong muốn)
    Người dùng ─────────────→ S3   (đường VÒNG, bỏ qua mọi kiểm soát)

SAU khi bật OAC + Block Public Access:
    Người dùng → CloudFront → S3   ✅
    Người dùng ─────────────→ S3   ❌ 403 Access Denied

Không có OAC thì signed URL vô nghĩa — ai cũng lấy URL S3 trực tiếp mà tải.

Bucket policy tương ứng:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho-san-pham/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1ABC"}}}

E — signed URL kiểm soát ai được xem và trong bao lâu:

CloudFront signed URL chứa chữ ký mã hoá và chính sách:
    → thời điểm hết hạn
    → dải IP được phép (tuỳ chọn)
    → thời điểm bắt đầu có hiệu lực (tuỳ chọn)
→ chỉ khách hàng nhận được URL mới xem được, và chỉ trong thời hạn đó

Hai cơ chế này phải đi cùng nhau — đó là lý do câu hỏi yêu cầu chọn hai.

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

**C. Dùng S3 pre-signed URL và gỡ quyền đọc bằng URL S3 của mọi người khác — đây là phương án gần nhất và cũng là cơ chế cấp quyền tạm thời, nhưng nó đi ngược yêu cầu của đề: pre-signed URL trỏ thẳng vào S3, BỎ QUA CloudFront. Đề nói rõ "must serve the private content via CloudFront only".
**B. Bật Origin Shield để bảo vệ tệp khỏi truy cập trái phép — nhầm chức năng: Origin Shield là một lớp cache trung tâm giúp giảm tải cho origin và tăng tỷ lệ cache hit. Nó không phải cơ chế bảo mật.
**A. Tạo CloudFront Function để kiểm tra và đảm bảo chỉ khách hàng đó truy cập được — tự dựng lại thứ đã có sẵn: CloudFront Function chạy được logic kiểm tra, nhưng signed URL/cookie là cơ chế dựng sẵn, đã được kiểm chứng, có ký mã hoá. Tự viết logic xác thực là thêm bề mặt lỗi không cần thiết.

Ghi nhớ

Ba lớp bảo vệ nội dung riêng tư qua CloudFront — cần đủ cả ba: | Lớp | Cơ chế | |---|---| | ① Chặn truy cập trực tiếp vào S3 | Block Public Access + OAC | | ② Kiểm soát ai xem được qua CloudFront | signed URL hoặc signed cookie | | ③ Hạn chế theo địa lý nếu cần | geo restriction |

Thiếu lớp ① thì lớp ② vô dụng — đó là bài học chính của câu hỏi.

CloudFront signed URL và signed cookie: | | Signed URL | Signed cookie | |---|---|---| | Phạm vi | MỘT tệp | NHIỀU tệp theo mẫu đường dẫn | | URL thay đổi | ✅ | ❌ giữ nguyên URL gốc | | Phù hợp | tải một tệp, link chia sẻ | thư viện nội dung, video streaming | | Client hỗ trợ cookie | không cần | bắt buộc |

Với "product files" của một khách hàng, signed cookie thường tiện hơn — cấp một lần rồi khách truy cập được cả bộ tài liệu mà không phải ký từng URL.

OAC và OAI: | | OAC (Origin Access Control) | OAI (Origin Access Identity) | |---|---|---| | Trạng thái | hiện hành, được khuyến nghị | cũ, chỉ giữ để tương thích | | SSE-KMS | ✅ hỗ trợ | ❌ không | | Origin không phải S3 | ✅ (Lambda URL, MediaStore...) | ❌ | | Phương thức HTTP | hỗ trợ đủ PUT, POST, DELETE | chỉ GET, HEAD |

Nếu bucket dùng SSE-KMS thì bắt buộc phải dùng OAC — OAI không ký được request tới KMS.

S3 pre-signed URL và CloudFront signed URL — phân biệt: | | S3 pre-signed | CloudFront signed | |---|---|---| | Trỏ tới | THẲNG vào S3 | qua CloudFront | | Ký bằng | thông tin đăng nhập IAM | cặp khoá riêng của CloudFront | | Tận dụng cache biên | ❌ | ✅ | | Hạn chế theo IP | ❌ | ✅ (custom policy) | | Phù hợp | tải lên, tải xuống nội bộ | phân phối nội dung cho người dùng cuối |

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

"via CloudFront only", "private content", "restrict access" → OAC + CloudFront signed URL "upload directly to S3", "temporary access to a bucket" → S3 pre-signed URL

Ba bước thiết lập signed URL:

① Tạo cặp khoá và tải public key lên CloudFront
② Tạo key group chứa public key đó
③ Bật "Restrict viewer access" trên cache behavior, chọn key group

from botocore.signers import CloudFrontSigner
signer = CloudFrontSigner(key_id, rsa_signer)
url = signer.generate_presigned_url(
    'https://d111.cloudfront.net/tai-lieu/bao-cao.pdf',
    date_less_than=datetime(2026, 9, 1))

Và một lưu ý về cache khi dùng signed URL: nếu nhiều khách hàng cùng xem một tệp, hãy chắc chắn rằng cache key không bao gồm tham số chữ ký — nếu không, mỗi chữ ký tạo ra một mục cache riêng, tỷ lệ cache hit sụp xuống và origin bị gọi liên tục. CloudFront mặc định bỏ qua các tham số Signature, Key-Pair-Id, Expires khi tính cache key, nhưng cấu hình cache policy tuỳ chỉnh có thể phá vỡ điều đó.

Trang 18 / 220 — tổng 2194 câu hỏi