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

Tìm thấy 2194 câu.

Câu 101 Design Secure Architectures

An application is hosted in AWS Fargate and uses RDS database in Multi-AZ Deployments configuration with several Read Replicas. A Solutions Architect was instructed to ensure that all of their database credentials, API keys, and other secrets are encrypted and rotated on a regular basis to improve data security. The application should also use the latest version of the encrypted credentials when connecting to the RDS database.

Which of the following is the MOST appropriate solution to secure the credentials?

  1. A

    Store the database credentials, API keys, and other secrets to Systems Manager Parameter Store each with a SecureString data type. The credentials are automatically rotated by default.
  2. B

    Use AWS Secrets Manager to store and encrypt the database credentials, API keys, and other secrets. Enable automatic rotation for all of the credentials.
  3. C

    Store the database credentials, API keys, and other secrets to AWS ACM.
  4. D

    Store the database credentials, API keys, and other secrets in AWS KMS.
Xem giải thích

Đáp án

B — Dùng AWS Secrets Manager để lưu và mã hoá thông tin đăng nhập cơ sở dữ liệu, API key và các bí mật khác. Bật xoay vòng tự động cho tất cả.

Vì sao đúng

Đề nêu ba yêu cầu, và Secrets Manager là dịch vụ duy nhất đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Mã hoá bí mật | tự động mã hoá bằng KMS | | XOAY VÒNG định kỳ | rotation tự động dựng sẵn | | Ứng dụng luôn dùng phiên bản MỚI NHẤT | staging label AWSCURRENT |

Vế "xoay vòng tự động" là điểm phân biệt quyết định với Parameter Store:

Secrets Manager:
    → có cơ chế rotation TÍCH HỢP
    → với RDS, Redshift, DocumentDB: rotation ĐƯỢC QUẢN LÝ, không cần viết mã
    → với bí mật khác: Lambda rotation tuỳ chỉnh

SSM Parameter Store (SecureString):
    → mã hoá được
    → NHƯNG KHÔNG có cơ chế xoay vòng nào
    → phải tự viết toàn bộ

Cách rotation hoạt động — và vì sao ứng dụng không gián đoạn:

Secrets Manager giữ nhiều phiên bản với nhãn:
    AWSCURRENT  → phiên bản đang dùng
    AWSPENDING  → phiên bản mới đang được tạo
    AWSPREVIOUS → phiên bản trước đó

Quy trình rotation bốn bước:
    ① createSecret  → sinh mật khẩu mới, gắn nhãn AWSPENDING
    ② setSecret     → đặt mật khẩu mới trong cơ sở dữ liệu
    ③ testSecret    → thử kết nối bằng mật khẩu mới
    ④ finishSecret  → chuyển nhãn AWSCURRENT sang phiên bản mới

Ứng dụng luôn lấy AWSCURRENT, nên nó tự nhận mật khẩu mới mà không cần triển khai lại:

kq = boto3.client('secretsmanager').get_secret_value(
    SecretId='csdl-san-xuat')   # mặc định lấy AWSCURRENT

Và với kiến trúc của đề (RDS Multi-AZ có read replica), rotation được quản lý là lựa chọn đúng — Secrets Manager tự xử lý việc cập nhật mật khẩu trên cụm.

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

  • **A. Lưu bí mật vào Systems Manager Parameter Store với kiểu SecureString; thông tin đăng nhập tự động được xoay vòng theo mặc định — đây là phương án gần nhất và Parameter Store SecureString thật sự mã hoá bằng KMS, nhưng vế cuối sai hoàn toàn: Parameter Store KHÔNG có cơ chế xoay vòng nào, càng không phải "mặc định".
  • **D. Lưu bí mật trong AWS KMS — nhầm vai trò của KMS: nó quản lý KHOÁ MÃ HOÁ, không phải kho lưu bí mật. KMS mã hoá được tối đa 4 KB dữ liệu, nhưng nó không lưu trữ, không có phiên bản, không xoay vòng nội dung.
  • **C. Lưu bí mật trong AWS Certificate Manager (ACM) — sai dịch vụ: ACM quản lý chứng chỉ TLS/SSL. Nó không lưu mật khẩu hay API key.

Ghi nhớ

Secrets Manager và Parameter Store — bảng so sánh cốt lõi: | | Secrets Manager | Parameter Store (SecureString) | |---|---|---| | Mã hoá bằng KMS | ✅ | ✅ | | Xoay vòng tự động | ✅ TÍCH HỢP | ❌ phải tự viết | | Rotation được quản lý cho RDS | ✅ không cần mã | ❌ | | Phiên bản và staging label | ✅ | phiên bản đơn giản | | Chia sẻ chéo tài khoản | ✅ resource policy | ❌ (standard tier) | | Chi phí | ~0,40 USD/bí mật/tháng | MIỄN PHÍ (standard tier) |

Quy tắc chọn:

Cần xoay vòng tự động, hoặc chia sẻ chéo tài khoản → Secrets Manager Chỉ cần lưu cấu hình mã hoá, ngân sách chặt → Parameter Store

Ba loại rotation của Secrets Manager: | Loại | Đặc điểm | |---|---| | Managed rotation | RDS, Aurora, Redshift, DocumentDB — KHÔNG cần viết mã | | Lambda rotation dựng sẵn | template cho các cơ sở dữ liệu phổ biến | | Lambda rotation tuỳ chỉnh | API key bên thứ ba — tự viết bốn bước |

Hai chiến lược rotation: | Chiến lược | Cách làm | |---|---| | Single user | đổi mật khẩu của CHÍNH tài khoản đang dùng | | Alternating users | hai tài khoản luân phiên — KHÔNG có khoảng gián đoạn nào |

Alternating users an toàn hơn cho ứng dụng có lưu lượng cao: luôn có một tài khoản hoạt động trong khi tài khoản kia được đổi mật khẩu.

Ba thực hành khi dùng Secrets Manager với ứng dụng: | Thực hành | Lý do | |---|---| | Cache giá trị, đừng gọi API mỗi request | tính phí theo lời gọi, và thêm độ trễ | | Dùng Secrets Manager Agent hoặc thư viện caching | có sẵn cho Java, Python, .NET, Go | | Xử lý lỗi kết nối bằng cách lấy lại bí mật | rotation có thể vừa xảy ra |

Dòng cuối là mẫu quan trọng: khi kết nối cơ sở dữ liệu thất bại vì xác thực, ứng dụng nên lấy lại bí mật và thử lại thay vì báo lỗi ngay — vì có thể mật khẩu vừa được xoay vòng.

Ba cách lấy bí mật trong container trên Fargate: | Cách | Đặc điểm | |---|---| | secrets trong task definition | ECS tự lấy và đưa vào biến môi trường | | Gọi API từ trong mã | linh hoạt hơn, cache được | | Secrets Manager Agent (sidecar) | cache tập trung |

Cách đầu tiện nhất cho Fargate:

"secrets": [{
  "name": "MAT_KHAU_DB",
  "valueFrom": "arn:aws:secretsmanager:...:secret:csdl-san-xuat:password::"
}]

Nhưng lưu ý: giá trị được nạp lúc khởi động task — nên sau khi rotation, task đang chạy vẫn giữ giá trị cũ cho tới khi được thay thế. Với ứng dụng cần nhận mật khẩu mới ngay, hãy gọi API từ trong mã.

Và một lựa chọn thay thế đáng cân nhắc cho chính RDS: IAM database authentication loại bỏ hoàn toàn mật khẩu — ứng dụng sinh token 15 phút bằng IAM role. Khi đó không còn bí mật nào để xoay vòng cả.

Câu 102 Design Secure Architectures

An insurance company utilizes SAP HANA for its day-to-day ERP operations. Since they can’t migrate this database due to customer preferences, they need to integrate it with the current AWS workload in the VPC in which they are required to establish a site-to-site VPN connection.

What needs to be configured outside of the VPC for them to have a successful site-to-site VPN connection?

  1. A A dedicated NAT instance in a public subnet
  2. B

    An Internet-routable IP address (static) of the customer gateway's external interface for the on-premises network
  3. C The main route table in your VPC to route traffic through a NAT instance
  4. D An EIP to the Virtual Private Gateway
Xem giải thích

Đáp án

B — Một địa chỉ IP tĩnh, định tuyến được trên Internet của giao diện ngoài của customer gateway phía mạng tại chỗ.

Vì sao đúng

Đề hỏi cái gì phải được cấu hình BÊN NGOÀI VPC để có kết nối Site-to-Site VPN thành công — và đó là phía thiết bị của bạn.

Kiến trúc Site-to-Site VPN có hai đầu:

PHÍA AWS (trong VPC):
    Virtual Private Gateway (VGW) hoặc Transit Gateway
        → AWS cấp và quản lý

PHÍA BẠN (ngoài VPC):
    Customer Gateway (CGW) — thiết bị VPN vật lý hoặc phần mềm
        → BẠN cấu hình
        → PHẢI có IP công khai TĨNH   ← câu trả lời

Vì sao IP phải TĨNH và CÔNG KHAI: | Lý do | Chi tiết | |---|---| | AWS cần biết địa chỉ để thiết lập tunnel | bạn khai IP đó khi tạo CGW resource | | IPsec tunnel gắn với địa chỉ đầu cuối | IP đổi là tunnel đứt | | Không có NAT ở giữa (hoặc phải cấu hình đặc biệt) | |

aws ec2 create-customer-gateway   --type ipsec.1   --public-ip 203.0.113.10   --bgp-asn 65000

Và đây đúng là thứ "outside of the VPC" — mọi thành phần khác (VGW, route table, subnet) đều nằm trong VPC.

(Với thiết bị dùng IP động, AWS hỗ trợ khai bằng certificate-based authentication thay cho IP tĩnh — nhưng IP tĩnh là cách thông thường và là điều kiện mà câu hỏi nhắm tới.)

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

  • **D. Gán một Elastic IP cho Virtual Private Gateway — đây là phương án gần nhất về mặt cũng nói về địa chỉ IP, nhưng VGW không nhận Elastic IP: AWS tự cấp địa chỉ đầu cuối cho hai tunnel và bạn không kiểm soát chúng. Và VGW nằm TRONG VPC, không phải "outside".
  • **A. Một NAT instance chuyên dụng trong public subnet — không liên quan: NAT cho phép instance trong private subnet đi ra Internet. Nó không tham gia vào việc thiết lập VPN.
  • **C. Route table chính trong VPC định tuyến lưu lượng qua NAT instance — sai cả vị trí lẫn cơ chế: route table nằm trong VPC (trái yêu cầu "outside"), và lưu lượng VPN phải định tuyến qua Virtual Private Gateway, không qua NAT.

Ghi nhớ

Bốn thành phần của Site-to-Site VPN: | Thành phần | Ở đâu | Ai cấu hình | |---|---|---| | Virtual Private Gateway (VGW) | trong VPC | AWS cấp | | Customer Gateway (CGW) resource | trong AWS | bạn khai IP của thiết bị | | Thiết bị customer gateway | TẠI CHỖ, ngoài VPC | bạn — cần IP TĨNH ← câu này | | VPN connection | trong AWS | nối VGW với CGW |

Ba bước cấu hình phía AWS:

① Tạo Virtual Private Gateway và gắn vào VPC
② Tạo Customer Gateway resource (khai IP tĩnh của thiết bị)
③ Tạo VPN Connection nối hai cái trên
④ Cập nhật ROUTE TABLE trỏ CIDR tại chỗ qua VGW

Bước ④ hay bị quên — VPN thiết lập xong nhưng lưu lượng không đi đâu cả, và triệu chứng là timeout không có thông báo lỗi rõ ràng.

Đặc điểm của Site-to-Site VPN: | Đặc điểm | Chi tiết | |---|---| | HAI tunnel IPsec cho mỗi kết nối | dự phòng — nên cấu hình cả hai | | Băng thông ~1,25 Gbps mỗi tunnel | | | Mã hoá IPsec | khác Direct Connect vốn không mã hoá | | Đi qua Internet công cộng | độ trễ biến động |

Dòng đầu là chi tiết hay bị bỏ sót: AWS luôn tạo hai tunnel, nhưng nhiều tổ chức chỉ cấu hình một. Cấu hình cả hai để chịu được bảo trì phía AWS.

Hai chế độ định tuyến: | Chế độ | Đặc điểm | |---|---| | Static routing | khai tay các CIDR — đơn giản | | Dynamic (BGP) | tự trao đổi tuyến, chuyển đổi tunnel tự động |

BGP được khuyến nghị: nó phát hiện tunnel hỏng và chuyển sang tunnel còn lại tự động, trong khi static routing cần can thiệp thủ công.

Ba cách kết nối mạng tại chỗ với AWS: | Cách | Mã hoá | Độ trễ | Chi phí | |---|---|---|---| | Site-to-Site VPN | ✅ IPsec | biến động | thấp | | Direct Connect | ❌ KHÔNG mã hoá | thấp và ổn định | cao | | DX + VPN | ✅ | thấp và ổn định | cao nhất |

Dòng giữa đáng nhớ: Direct Connect không mã hoá — cần mã hoá thì chạy IPsec VPN bên trong nó.

Ba lỗi thường gặp khi thiết lập VPN: | Lỗi | Triệu chứng | |---|---| | Quên cập nhật route table | tunnel UP nhưng không thông | | Security group hoặc NACL chặn | một số lưu lượng qua, một số không | | Cấu hình IKE/IPsec không khớp | tunnel không lên được |

Và với SAP HANA như đề mô tả — một hệ thống nhạy cảm với độ trễ — cân nhắc Direct Connect thay vì VPN. VPN đi qua Internet công cộng nên độ trễ biến động; với ERP xử lý giao dịch liên tục, đó có thể là vấn đề thật. Nếu ngân sách cho phép, DX với VPN làm dự phòng là cấu hình phù hợp hơn.

Câu 103 Design High-Performing Architectures

A company is running a multi-tier web application farm in a virtual private cloud (VPC) that is not connected to their corporate network. They are connecting to the VPC over the Internet to manage the fleet of Amazon EC2 instances running in both the public and private subnets. The Solutions Architect has added a bastion host with Microsoft Remote Desktop Protocol (RDP) access to the application instance security groups, but the company wants to further limit administrative access to all of the instances in the VPC.

Which of the following bastion host deployment options will meet this requirement?

  1. A Deploy a Windows Bastion host on the corporate network that has RDP access to all EC2 instances in the VPC.
  2. B Deploy a Windows Bastion host with an Elastic IP address in the private subnet, and restrict RDP access to the bastion from only the corporate public IP addresses.
  3. C Deploy a Windows Bastion host with an Elastic IP address in the public subnet and allow SSH access to the bastion from anywhere.
  4. D Deploy a Windows Bastion host with an Elastic IP address in the public subnet and allow RDP access to bastion only from the corporate IP addresses.
Xem giải thích

Đáp án

D — Triển khai một Windows Bastion host có Elastic IP trong PUBLIC subnet và chỉ cho phép RDP từ dải IP của công ty.

Vì sao đúng

Đề nêu hai yêu cầu, và D là phương án duy nhất thoả cả hai: | Yêu cầu | Cơ chế | |---|---| | Bastion truy cập được từ Internet (VPC không nối mạng công ty) | public subnet + Elastic IP | | Hạn chế hơn nữa quyền truy cập quản trị | chỉ cho RDP từ IP công ty |

Vì sao bastion phải ở PUBLIC subnet:

Đề nói: VPC KHÔNG kết nối với mạng công ty
        → truy cập qua INTERNET
        → bastion phải có đường vào từ Internet
        → tức là public subnet + Elastic IP

Bastion trong PRIVATE subnet:
        → không có đường vào từ Internet
        → không ai kết nối tới được  ← phương án B vô nghĩa

Và "chỉ từ IP công ty" là cách siết chặt mà đề yêu cầu:

Security group của bastion:
    Type: RDP    Protocol: TCP    Port: 3389
    Source: 203.0.113.0/24        ← CHỈ dải IP văn phòng

Thay vì 0.0.0.0/0 — nó thu hẹp bề mặt tấn công từ toàn Internet xuống một dải địa chỉ cụ thể.

Kiến trúc đầy đủ:

Người quản trị ở văn phòng (203.0.113.x)
    ↓ RDP:3389 — chỉ IP này được phép
Bastion host (public subnet, Elastic IP)
    ↓ RDP:3389 — nguồn là sg-bastion
EC2 instance trong private subnet

Security group của instance ứng dụng nên tham chiếu security group của bastion, không phải IP — nên bastion được thay thế mà rule không cần sửa.

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

  • **C. Triển khai bastion có Elastic IP trong public subnet và cho phép SSH từ bất kỳ đâu — đây là phương án gần nhất về mặt vị trí, nhưng sai ở hai điểm: SSH (cổng 22) dành cho Linux, còn đề nói Windows bastion dùng RDP (3389); và "từ bất kỳ đâu" là mở rộng, trái thẳng yêu cầu siết chặt.
  • **B. Triển khai bastion có Elastic IP trong PRIVATE subnet, chỉ cho RDP từ IP công ty — mâu thuẫn nội tại: private subnet không có đường vào từ Internet, nên Elastic IP vô dụng và không ai kết nối tới bastion được.
  • **A. Triển khai bastion trên mạng công ty có quyền RDP tới mọi EC2 trong VPC — không thực hiện được: đề nói rõ VPC KHÔNG kết nối với mạng công ty. Máy trên mạng công ty không có đường tới private subnet.

Ghi nhớ

Ba nguyên tắc thiết kế bastion host: | Nguyên tắc | Chi tiết | |---|---| | Đặt trong public subnet, có IP công khai | để truy cập được từ Internet | | Giới hạn nguồn tới dải IP cụ thể | KHÔNG BAO GIỜ dùng 0.0.0.0/0 | | Instance đích chỉ nhận kết nối TỪ SECURITY GROUP của bastion | không tham chiếu IP |

Các cổng quản trị: | Cổng | Giao thức | Hệ điều hành | |---|---|---| | 22 | SSH | Linux | | 3389 | RDP | Windows |

Và giải pháp tốt hơn hẳn bastion host — đáng nói vì đây là hướng AWS khuyến nghị: | Cách | Ưu điểm | |---|---| | Systems Manager Session Manager | KHÔNG cần cổng inbound, KHÔNG cần bastion, KHÔNG cần key | | EC2 Instance Connect Endpoint | không cần cổng inbound, vẫn dùng SSH/RDP | | Bastion host truyền thống | cách cũ, vẫn phải mở cổng |

Session Manager hỗ trợ cả Linux lẫn Windows và loại bỏ toàn bộ nhóm rủi ro:

Instance khởi tạo kết nối RA (443) tới dịch vụ SSM
    → security group KHÔNG cần rule inbound nào
    → không có bastion để vá và giám sát
    → kiểm soát bằng IAM, ghi log toàn bộ phiên

Ba yêu cầu để dùng Session Manager:

① SSM Agent cài và đang chạy (có sẵn trên AMI Windows và Amazon Linux)
② IAM instance profile có AmazonSSMManagedInstanceCore
③ Đường mạng tới endpoint SSM (VPC endpoint hoặc NAT)

Ba biện pháp siết chặt nếu vẫn dùng bastion: | Biện pháp | Lợi ích | |---|---| | Chỉ bật bastion khi cần | tắt ngoài giờ làm việc | | Bật CloudWatch Logs cho phiên | ghi lại hoạt động | | Yêu cầu MFA để assume role vận hành bastion | thêm một lớp |

Ba lưu ý về Elastic IP: | Lưu ý | Chi tiết | |---|---| | Địa chỉ IPv4 công khai TĨNH | không đổi khi instance khởi động lại | | Tính phí khi KHÔNG gắn vào instance đang chạy | nhớ giải phóng khi không dùng | | Giới hạn 5 EIP mỗi Region | tăng được nếu cần |

Và một điểm về việc "further limit administrative access" mà đề yêu cầu: ngoài việc giới hạn IP, hãy giới hạn AI được phép kết nối tới bastion bằng IAM — nếu dùng Session Manager thì điều kiện ssm:resourceTag cho phép phân quyền theo tag của instance, thứ mà security group không làm được.

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

For data privacy, a healthcare company has been asked to comply with the Health Insurance Portability and Accountability Act (HIPAA). The company stores all its backups on an Amazon S3 bucket. It is required that data stored on the S3 bucket must be encrypted.

What is the best option to do this? (Select TWO.)

  1. A Before sending the data to Amazon S3 over HTTPS, encrypt the data locally first using your own encryption keys.
  2. B Store the data on EBS volumes with encryption enabled instead of using Amazon S3.
  3. C Store the data in encrypted EBS snapshots.
  4. D Enable Server-Side Encryption on an S3 bucket to make use of AES-256 encryption.
  5. E Enable Server-Side Encryption on an S3 bucket to make use of AES-128 encryption.
Xem giải thích

Đáp án

A và D.

  • D — Bật Server-Side Encryption trên S3 bucket để dùng mã hoá AES-256
  • A — Mã hoá dữ liệu cục bộ bằng khoá của chính bạn trước khi gửi lên S3 qua HTTPS

Vì sao đúng

Đề yêu cầu dữ liệu trên S3 phải được mã hoá để tuân thủ HIPAA — và hai đáp án là hai cách hợp lệ để đạt điều đó: | Cách | Ai mã hoá | |---|---| | D — Server-side encryption | S3 mã hoá sau khi nhận | | A — Client-side encryption | bạn mã hoá TRƯỚC khi gửi |

D — SSE-S3 dùng AES-256, và đó là con số đúng:

S3 sinh một data key duy nhất cho MỖI object
    ↓ mã hoá object bằng AES-256
    ↓ mã hoá data key bằng root key của S3
Lưu bản mã cùng object
Đặc điểm Chi tiết
Thuật toán AES-256
Khoá riêng cho mỗi object tự động
Công sức bật một cờ trên bucket

A — client-side encryption cho mức bảo vệ cao nhất:

Ứng dụng mã hoá dữ liệu bằng khoá của bạn
    ↓ chỉ BẢN MÃ được gửi lên
S3 không bao giờ thấy dữ liệu rõ
    → AWS bị buộc giao nộp cũng chỉ có bản mã

Với dữ liệu y tế theo HIPAA, cả hai đều được chấp nhận — client-side cho mức bảo vệ cao hơn nhưng nhiều công hơn.

Và vế "over HTTPS" trong phương án A là chi tiết đúng: mã hoá khi lưu và mã hoá khi truyền là hai lớp khác nhau, cần cả hai.

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

  • **E. Bật Server-Side Encryption để dùng mã hoá AES-128 — đây là phương án gần nhất và chỉ sai một con số: SSE-S3 dùng AES-256, không phải AES-128. AWS không cung cấp tuỳ chọn AES-128 cho SSE.
  • **B. Lưu dữ liệu trên EBS volume có mã hoá thay vì dùng S3 — thay đổi kiến trúc thay vì trả lời câu hỏi: đề nói rõ công ty lưu bản sao lưu trên S3. Và EBS gắn với một AZ, không phù hợp cho bản sao lưu cần độ bền cao.
  • **C. Lưu dữ liệu trong EBS snapshot có mã hoá — cùng vấn đề: nó thay S3 bằng một dịch vụ khác thay vì mã hoá dữ liệu trên S3 như yêu cầu.

Ghi nhớ

Bốn kiểu mã hoá dữ liệu trên S3: | Kiểu | Ai mã hoá | Ai giữ khoá | AWS thấy dữ liệu rõ? | |---|---|---|---| | SSE-S3 | S3 | AWS hoàn toàn | ✅ | | SSE-KMS | S3 | bạn qua KMS | ✅ | | SSE-C | S3 | bạn — gửi kèm mỗi request | ✅ | | Client-side | ứng dụng của bạn | bạn hoàn toàn | ❌ |

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

"Đơn giản nhất, chỉ cần mã hoá" → SSE-S3 "Cần kiểm toán từng lần dùng khoá, kiểm soát bằng key policy" → SSE-KMS "Dữ liệu rõ KHÔNG được tới AWS" → client-side

Lưu ý về mặc định hiện nay: S3 tự động mã hoá mọi object mới bằng SSE-S3 kể từ năm 2023 — nên "bật SSE" giờ chủ yếu là xác nhận và có thể nâng lên SSE-KMS nếu cần kiểm toán.

Ba lớp bảo vệ cho dữ liệu y tế trên S3: | Lớp | Cơ chế | |---|---| | Mã hoá khi lưu | SSE-S3, SSE-KMS, hoặc client-side ← câu này | | Mã hoá khi truyền | HTTPS — bắt buộc bằng bucket policy | | Kiểm soát truy cập | IAM, bucket policy, Block Public Access |

Bucket policy bắt buộc HTTPS — nên có cho mọi bucket chứa dữ liệu nhạy cảm:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::du-lieu-y-te", "arn:aws:s3:::du-lieu-y-te/*"],
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Bucket policy bắt buộc mã hoá khi ghi:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::du-lieu-y-te/*",
 "Condition": {"StringNotEquals": {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Ba yêu cầu bổ sung của HIPAA mà đề không nhắc tới nhưng cần biết: | Yêu cầu | Cơ chế trên AWS | |---|---| | Ký Business Associate Agreement (BAA) | qua AWS Artifact — BẮT BUỘC trước khi xử lý PHI | | Chỉ dùng dịch vụ đủ điều kiện HIPAA | AWS công bố danh sách | | Ghi log kiểm toán đầy đủ | CloudTrail data event cho S3 |

Dòng đầu là bước pháp lý thường bị bỏ sót: không có BAA đã ký thì việc lưu dữ liệu sức khoẻ trên AWS không tuân thủ, dù kỹ thuật có hoàn hảo tới đâu.

Ba lưu ý về client-side encryption: | Lưu ý | Chi tiết | |---|---| | Mất khoá = mất dữ liệu VĨNH VIỄN | AWS không cứu được | | Dịch vụ phân tích không đọc được | Athena, Macie, S3 Select đều vô dụng với bản mã | | Dùng AWS Encryption SDK | đừng tự viết mã hoá |

Dòng giữa là đánh đổi lớn: dữ liệu mã hoá phía client là khối byte vô nghĩa với AWS — nên Macie không quét được PHI trong đó, và bạn mất một công cụ tuân thủ hữu ích.

Và với bản sao lưu y tế, cân nhắc thêm S3 Object Lock chế độ COMPLIANCE: nhiều quy định về hồ sơ y tế yêu cầu lưu trữ bất biến trong nhiều năm, và Object Lock là cách chứng minh điều đó với cơ quan kiểm toán.

Câu 105 Design Resilient Architectures

An e-commerce company is receiving a large volume of sales data files in .csv format from its external partners on a daily basis. These data files are then stored in an Amazon S3 Bucket for processing and reporting purposes.

The company wants to create an automated solution to convert these .csv files into Apache Parquet format and store the output of the processed files in a new S3 bucket called “tutorialsdojo-data-transformed”. This new solution is meant to enhance the company’s data processing and analytics workloads while keeping its operating costs low.

Which of the following options must be implemented to meet these requirements with the LEAST operational overhead?

  1. A

    Integrate Amazon EMR File System (EMRFS) with the source S3 bucket to automatically discover the new data files. Use an Amazon EMR Serverless with Apache Spark to convert the .csv files to the Apache Parquet format and then store the output in the "tutorialsdojo-data-transformed" bucket.
  2. B

    Utilize an AWS Batch job definition with Bash syntax to convert the .csv files to the Apache Parquet format. Configure the job definition to run automatically whenever a new .csv file is uploaded to the source bucket.
  3. C

    Use Amazon S3 event notifications to trigger an AWS Lambda function that converts .csv files to Apache Parquet format using Apache Spark on an Amazon EMR cluster. Save the processed files to the “tutorialsdojo-data-transformed" bucket.
  4. D

    Use AWS Glue crawler to automatically discover the raw data file in S3 as well as check its corresponding schema. Create a scheduled ETL job in AWS Glue that will convert .csv files to Apache Parquet format and store the output of the processed files in the “tutorialsdojo-data-transformed" bucket.
Xem giải thích

Đáp án

D — Dùng AWS Glue crawler tự động phát hiện tệp dữ liệu thô trên S3 và kiểm tra lược đồ tương ứng. Tạo một ETL job theo lịch trong AWS Glue chuyển .csv sang Apache Parquet và lưu kết quả vào bucket tutorialsdojo-data-transformed.

Vì sao đúng

Đề nêu ba yêu cầu, và Glue đáp ứng cả ba với công vận hành thấp nhất: | Yêu cầu | Cơ chế | |---|---| | Tự động chuyển .csv sang Parquet | Glue ETL job | | Cải thiện xử lý và phân tích dữ liệu | Parquet giảm mạnh dữ liệu quét | | Chi phí vận hành thấp | không máy chủ nào phải quản lý |

Glue là Apache Spark được quản lý:

Không dựng cụm, không vá lỗi, không mở rộng thủ công
    → hỗ trợ sẵn CSV, JSON, Parquet, ORC, Avro
    → tính phí theo DPU-giờ, chỉ khi job chạy

Và crawler đảm nhận việc phát hiện lược đồ:

Crawler quét bucket nguồn
    ↓ suy ra kiểu dữ liệu của từng cột
    ↓ ghi metadata vào Glue Data Catalog
ETL job đọc lược đồ từ Catalog
    → không phải khai tay cấu trúc tệp
    → tệp thêm cột mới thì crawler tự cập nhật

Vì sao Parquet đáng chuyển đổi: | Định dạng | Đặc điểm | |---|---| | CSV | theo DÒNG — đọc một cột phải quét cả tệp | | Parquet | theo CỘT, có nén và metadata thống kê |

Kết quả đo được: truy vấn Athena trên Parquet thường quét ít hơn 30–90% dữ liệu — và Athena tính phí theo dữ liệu quét, nên đó là khoản tiết kiệm trực tiếp.

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

  • **A. Tích hợp EMRFS với bucket nguồn để tự phát hiện tệp mới; dùng EMR Serverless với Spark chuyển đổi — đây là phương án gần nhất và EMR Serverless thật sự là dịch vụ không máy chủ, nhưng nó nhiều công hơn Glue: bạn phải tự viết và bảo trì mã Spark, tự quản lý ứng dụng EMR. Và EMRFS không "tự động phát hiện tệp mới" — nó chỉ là lớp truy cập S3 cho Hadoop.
  • **C. Dùng S3 event notification kích hoạt Lambda chuyển đổi bằng Spark trên một cụm EMR — kiến trúc chắp vá: nếu đã có cụm EMR thì cần gì Lambda; và duy trì một cụm EMR chạy liên tục trái yêu cầu chi phí thấp.
  • **B. Dùng AWS Batch job definition với cú pháp Bash để chuyển đổi — công cụ không phù hợp: chuyển CSV sang Parquet bằng script Bash là việc rất vụng về, và AWS Batch đòi bạn tự quản lý compute environment và container image.

Ghi nhớ

Bốn thành phần của AWS Glue: | Thành phần | Việc | |---|---| | ETL job | chuyển đổi dữ liệu — Spark hoặc Python shell | | Crawler | phát hiện lược đồ, cập nhật Data Catalog | | Data Catalog | kho metadata — Athena, Redshift Spectrum, EMR dùng chung | | Trigger / Workflow | điều phối chuỗi job |

Phân biệt job và crawler:

Crawler PHÁT HIỆN dữ liệu có gì. ETL job BIẾN ĐỔI dữ liệu.

Ba cách kích hoạt Glue job: | Cách | Đặc điểm | |---|---| | Theo lịch (cron) | định kỳ ← câu này | | EventBridge event | theo sự kiện, ví dụ khi có tệp mới | | Job trước hoàn tất | chuỗi phụ thuộc |

Chọn lịch hay sự kiện tuỳ vào yêu cầu:

"Chuyển đổi PHẢI chạy NGAY khi có tệp mới"  → event-driven
"Tự động chuyển đổi" (không nói thời điểm)   → theo lịch là đủ và rẻ hơn

(Câu #8136 ở lô trước đặt cùng bài toán CSV → Parquet nhưng yêu cầu "automatically initiated each time a new file is uploaded" — nên đáp án ở đó là cơ chế theo sự kiện. Ở câu này đề chỉ nói "automated solution", nên lịch chạy định kỳ đáp ứng đủ và ít công hơn. Đọc kỹ vế thời điểm là điểm phân biệt hai câu.)

Ba tối ưu khi ghi Parquet: | Tối ưu | Lợi ích | |---|---| | Phân vùng theo ngày | truy vấn một ngày chỉ quét một phân vùng | | Nén Snappy | cân bằng tốc độ và tỷ lệ nén | | Gộp tệp nhỏ | hàng nghìn tệp nhỏ làm truy vấn chậm hẳn |

Dòng cuối đáng lưu ý với dữ liệu đến hằng ngày từ nhiều đối tác — dễ sinh ra rất nhiều tệp nhỏ. Glue có tính năng grouping để gộp chúng.

Ba lựa chọn thay thế cho Glue — theo quy mô: | Lựa chọn | Phù hợp | |---|---| | Glue ETL | được quản lý, ít công nhất ← câu này | | Athena CTAS | chuyển đổi bằng SQL thuần — rất gọn | | EMR Serverless | cần kiểm soát Spark chi tiết |

Athena CTAS đáng biết — nó làm được việc này bằng một câu SQL:

CREATE TABLE du_lieu_parquet
WITH (format = 'PARQUET', partitioned_by = ARRAY['ngay'],
      external_location = 's3://tutorialsdojo-data-transformed/')
AS SELECT *, date(thoi_gian) AS ngay FROM du_lieu_csv;

Ba lưu ý về chi phí Glue: | Lưu ý | Chi tiết | |---|---| | Tính phí theo DPU-giờ | tối thiểu 1 phút mỗi lần chạy | | Glue 3.0 trở lên khởi động nhanh hơn | giảm chi phí cho job ngắn | | Dùng Python shell job cho việc nhẹ | rẻ hơn Spark job đáng kể |

Và một lưu ý về Data Catalog: nó dùng chung với Athena, Redshift Spectrum và EMR — nên sau khi crawler chạy, bạn truy vấn được dữ liệu bằng SQL ngay mà không cần khai bảng thủ công ở từng dịch vụ.

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

A start-up company has an EC2 instance that is hosting a web application. The volume of users is expected to grow in the coming months, and hence, you need to add more elasticity and scalability in your AWS architecture to cope with the demand.

Which of the following options can satisfy the above requirement for the given scenario? (Select TWO.)

  1. A

    Set up two EC2 instances and then put them behind an Elastic Load balancer (ELB).
  2. B

    Set up an S3 Cache in front of the EC2 instance.
  3. C

    Set up two EC2 instances and use Route 53 to route traffic based on a Weighted Routing Policy.
  4. D

    Set up an AWS WAF behind your EC2 Instance.
  5. E

    Set up two EC2 instances deployed using Launch Templates and integrated with AWS Glue.
Xem giải thích

Đáp án

A và C.

  • A — Dựng hai EC2 instance đặt sau một Elastic Load Balancer (ELB)
  • C — Dựng hai EC2 instance và dùng Route 53 với Weighted Routing Policy để phân phối lưu lượng

Vì sao đúng

Đề cần thêm tính đàn hồi và khả năng mở rộng cho một ứng dụng đang chạy trên một instance duy nhất — và cả hai đáp án đều là cách phân phối tải qua nhiều máy.

A — ELB là cách chuẩn và tốt nhất:

Người dùng → Elastic Load Balancer
                ├─ EC2 instance 1
                └─ EC2 instance 2
Lợi ích Chi tiết
Phân phối tải tự động thuật toán round-robin hoặc least outstanding requests
Health check tự ngừng gửi lưu lượng tới instance hỏng
Một endpoint duy nhất client không cần biết có bao nhiêu máy
Tích hợp Auto Scaling nền tảng cho mở rộng tự động

C — Route 53 weighted routing phân phối ở tầng DNS:

Truy vấn DNS cho ung-dung.congty.vn
    → 50% trả về IP của instance 1
    → 50% trả về IP của instance 2

Nó hoạt động và là một cách phân phối tải hợp lệ — dù kém tinh vi hơn ELB.

Vì sao ELB tốt hơn Route 53 cho mục đích này: | | ELB | Route 53 weighted | |---|---|---| | Phát hiện instance hỏng | ngay lập tức | phụ thuộc health check + TTL DNS | | Client cache | không có vấn đề | trình phân giải cache IP theo TTL | | Phân phối chính xác | theo từng request | theo truy vấn DNS | | Tích hợp Auto Scaling | ✅ | ❌ |

Cả hai đều đúng theo câu hỏi, nhưng trong thực tế ELB (kết hợp Auto Scaling) là kiến trúc nên chọn.

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

  • **B. Đặt một S3 Cache trước EC2 instance — không tồn tại khái niệm này: S3 là kho lưu trữ đối tượng, không phải cache. Dịch vụ cache của AWS là ElastiCache (trong bộ nhớ) hoặc CloudFront (ở biên).
  • **D. Đặt AWS WAF PHÍA SAU EC2 instance — sai vị trí và sai mục đích: WAF đứng TRƯỚC tài nguyên (gắn vào CloudFront, ALB, API Gateway), không phải phía sau. Và nó lọc request độc hại, không phân phối tải.
  • **E. Dựng hai EC2 instance bằng Launch Template và tích hợp với AWS Glue — nhầm dịch vụ: Glue là dịch vụ ETL cho dữ liệu, hoàn toàn không liên quan tới việc phân phối lưu lượng web. (Launch template thì đúng là thành phần của Auto Scaling, nhưng vế Glue làm cả phương án sai.)

Ghi nhớ

Ba loại Elastic Load Balancer: | Loại | Tầng | Đặc điểm | |---|---|---| | Application Load Balancer (ALB) | 7 (HTTP/HTTPS) | path-based, host-based routing, WAF, gRPC | | Network Load Balancer (NLB) | 4 (TCP/UDP/TLS) | độ trễ cực thấp, IP tĩnh, giữ IP nguồn client | | Gateway Load Balancer (GWLB) | 3 | thiết bị bảo mật của bên thứ ba |

ALB là lựa chọn mặc định cho ứng dụng web.

Kiến trúc mở rộng đầy đủ — điều mà đề đang hướng tới:

Route 53
    ↓
Application Load Balancer (nhiều AZ)
    ↓
Auto Scaling Group
    ├─ EC2 ở AZ-a
    └─ EC2 ở AZ-b
    ↓
RDS Multi-AZ

Auto Scaling là mảnh ghép còn thiếu trong cả hai đáp án — nó biến "hai instance cố định" thành "số instance tự điều chỉnh theo tải", tức là đàn hồi thật sự.

Các chính sách định tuyến của Route 53: | Chính sách | Dùng cho | |---|---| | Weighted | chia tỷ lệ — A/B testing, triển khai dần ← câu này | | Failover | primary khi khoẻ, secondary khi hỏng | | Latency | Region cho độ trễ thấp nhất | | Geolocation | theo vị trí người dùng | | Multivalue answer | trả nhiều IP có health check |

Weighted routing đáng dùng nhất cho canary deployment — đưa 10% lưu lượng sang phiên bản mới, quan sát, rồi tăng dần.

Ba khái niệm hay bị nhầm — phân biệt rõ: | Khái niệm | Nghĩa | |---|---| | Scalability (khả năng mở rộng) | xử lý được nhiều tải hơn khi thêm tài nguyên | | Elasticity (tính đàn hồi) | TỰ ĐỘNG thêm và bớt tài nguyên theo tải | | High availability | chịu được sự cố mà vẫn phục vụ |

Đề nhắc cả "elasticity" lẫn "scalability" — và đàn hồi thật sự cần Auto Scaling, không chỉ hai máy cố định.

Ba cách mở rộng: | Cách | Chi tiết | |---|---| | Vertical (scale up) | máy to hơn — có trần, cần khởi động lại | | Horizontal (scale out) | thêm máy — gần như không giới hạn ← câu này | | Caching | giảm tải thay vì thêm dung lượng |

Mở rộng ngang là mô hình của cloud — và nó đòi ứng dụng không lưu trạng thái trên máy (session phải nằm ở ElastiCache hoặc DynamoDB, tệp phải nằm ở S3 hoặc EFS).

Và một bước chuẩn bị quan trọng khi chuyển từ một instance sang nhiều: kiểm tra ứng dụng có lưu gì cục bộ không. Session lưu trong bộ nhớ, tệp tải lên lưu trên đĩa, cache lưu trên máy — cả ba đều hỏng khi có nhiều instance, và đó thường là công việc thật sự của việc "thêm tính mở rộng".

Câu 107 Design Resilient Architectures

An accounting application uses an RDS database configured with Multi-AZ deployments to improve availability. What would happen to RDS if the primary database instance fails?

  1. A The IP address of the primary DB instance is switched to the standby DB instance.
  2. B The primary database instance will reboot.
  3. C A new database instance is created in the standby Availability Zone.
  4. D The canonical name record (CNAME) is switched from the primary to standby instance.
Xem giải thích

Đáp án

D — Bản ghi CNAME được chuyển từ instance chính sang instance dự phòng (standby).

Vì sao đúng

Đề hỏi chuyện gì xảy ra với RDS khi instance chính hỏng trong cấu hình Multi-AZ — và cơ chế nằm ở tầng DNS.

Endpoint của RDS là một bản ghi CNAME:

csdl.abc123.ap-northeast-1.rds.amazonaws.com
    ↓ CNAME trỏ tới tên máy chủ của instance ĐANG LÀ PRIMARY

Primary hỏng
    ↓ RDS phát hiện
    ↓ CẬP NHẬT CNAME trỏ sang standby
Standby trở thành primary mới

Điểm mấu chốt: tên endpoint KHÔNG ĐỔI, chỉ địa chỉ phía sau đổi. | | Trước chuyển đổi | Sau chuyển đổi | |---|---|---| | Endpoint | csdl.abc123...rds.amazonaws.com | giống hệt | | Địa chỉ IP | IP của instance ở AZ-a | IP của instance ở AZ-b |

Đây là lý do ứng dụng không cần sửa chuỗi kết nối — nó vẫn dùng đúng tên đó, và DNS đưa nó tới máy mới.

Toàn bộ quá trình mất 60–120 giây, và trong khoảng đó ứng dụng sẽ gặp lỗi kết nối — nên cần logic thử lại.

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

  • **A. Địa chỉ IP của instance chính được chuyển sang instance dự phòng — đây là phương án gần nhất và kết quả cuối nghe tương tự, nhưng cơ chế sai: RDS không di chuyển IP giữa hai máy. Hai instance nằm ở hai AZ khác nhau, tức là hai subnet khác nhau — địa chỉ IP không chuyển qua lại được.
  • **C. Một instance cơ sở dữ liệu MỚI được tạo ở Availability Zone dự phòng — hiểu sai bản chất Multi-AZ: standby đã tồn tại và đang được đồng bộ liên tục từ trước. Không có gì phải tạo mới — đó chính là lý do chuyển đổi chỉ mất 1–2 phút thay vì hàng chục phút.
  • **B. Instance chính sẽ khởi động lại — không phải cơ chế chuyển đổi: nếu chỉ khởi động lại primary thì dịch vụ vẫn gián đoạn cho tới khi nó lên, và nếu cả AZ sập thì nó không lên được.

Ghi nhớ

Cơ chế Multi-AZ của RDS:

Primary (AZ-a)  ──SAO CHÉP ĐỒNG BỘ──>  Standby (AZ-b)
    → mọi giao dịch ghi phải được standby xác nhận
    → RPO = 0, không mất dữ liệu
    → standby KHÔNG phục vụ truy vấn đọc

Các sự kiện kích hoạt chuyển đổi tự động: | Sự kiện | |---| | Mất khả dụng cả một AZ | | Hỏng instance primary | | Hỏng ổ lưu trữ của primary | | Thay đổi loại instance của primary | | Vá lỗi hệ điều hành của primary | | Chuyển đổi thủ công (reboot --force-failover) |

Sự cố ở STANDBY không kích hoạt gì — nó không phục vụ lưu lượng nào, nên AWS chỉ lặng lẽ dựng lại một standby mới.

Ba việc ứng dụng cần làm để tận dụng chuyển đổi tự động: | Việc | Lý do | |---|---| | Luôn dùng ENDPOINT, không hard-code IP | IP thay đổi | | Đặt TTL cache DNS thấp | JVM cache DNS VĨNH VIỄN theo mặc định | | Có logic thử lại kết nối | có 60–120 giây gián đoạn |

Dòng giữa là bẫy kinh điển với ứng dụng Java:

Trong java.security:  networkaddress.cache.ttl=5

Không đặt giá trị này, JVM giữ mãi kết quả phân giải DNS đầu tiên và tiếp tục cố kết nối tới IP cũ sau khi chuyển đổi — ứng dụng không bao giờ tự phục hồi.

Multi-AZ và Read Replica — bảng phân biệt: | | Multi-AZ | Read Replica | |---|---|---| | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Mục đích | SẴN SÀNG CAO | mở rộng đọc | | Phục vụ đọc | ❌ | ✅ | | Chuyển đổi | tự động | thủ công | | Endpoint | giữ nguyên | khác |

Hai chế độ Multi-AZ: | Chế độ | Thời gian chuyển đổi | |---|---| | Multi-AZ instance deployment | 60–120 giây | | Multi-AZ DB cluster | dưới 35 giây, và replica CÓ phục vụ đọc |

Chế độ thứ hai (MySQL và PostgreSQL) đáng cân nhắc cho triển khai mới — nhanh hơn và không lãng phí bản standby.

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chi phí gần gấp đôi | trả tiền cho cả standby | | Bảo trì gần như không gián đoạn | AWS vá standby trước rồi chuyển đổi | | KHÔNG thay thế cho sao lưu | xoá nhầm dữ liệu thì standby cũng xoá theo |

Và một cách kiểm chứng đáng làm định kỳ: chủ động kích hoạt chuyển đổi bằng aws rds reboot-db-instance --force-failover. Nó cho biết ứng dụng thực sự chịu được bao lâu gián đoạn — thay vì phát hiện điều đó lần đầu trong một sự cố thật lúc nửa đêm.

Câu 108 Design Secure Architectures

A company plans to conduct a network security audit. The web application is hosted on an Auto Scaling group of EC2 Instances with an Application Load Balancer in front to evenly distribute the incoming traffic. A Solutions Architect has been tasked to enhance the security posture of the company’s cloud infrastructure and minimize the impact of DDoS attacks on its resources.

Which of the following is the most effective solution that should be implemented?

  1. A

    Configure Amazon CloudFront distribution and set Application Load Balancer as the origin. Create a rate-based web ACL rule using AWS WAF and associate it with Amazon CloudFront.
  2. B

    Configure Amazon CloudFront distribution and set a Network Load Balancer as the origin. Use VPC Flow Logs to monitor abnormal traffic patterns. Set up a custom AWS Lambda function that processes the flow logs and invokes Amazon SNS for notification.
  3. C

    Configure Amazon CloudFront distribution and set an Application Load Balancer as the origin. Create a security group rule and deny all the suspicious addresses. Use Amazon SNS for notification.
  4. D

    Configure Amazon CloudFront distribution and set a Network Load Balancer as the origin. Use Amazon GuardDuty to block suspicious hosts based on its security findings. Set up a custom AWS Lambda function that processes the security logs and invokes Amazon SNS for notification.
Xem giải thích

Đáp án

A — Cấu hình CloudFront distribution với Application Load Balancer làm origin. Tạo một rate-based web ACL rule bằng AWS WAF và gắn nó vào CloudFront.

Vì sao đúng

Đề nêu hai yêu cầu, và A đáp ứng cả hai với đúng công cụ: | Yêu cầu | Cơ chế | |---|---| | Nâng cao tư thế bảo mật | CloudFront + WAF ở tầng biên | | Giảm thiểu tác động của tấn công DDoS | rate-based rule + hấp thụ ở edge |

CloudFront là lớp phòng thủ DDoS đầu tiên và hiệu quả nhất:

KHÔNG có CloudFront:
    Tấn công → thẳng vào ALB và đội EC2
             → tài nguyên hữu hạn, dễ quá tải

CÓ CloudFront:
    Tấn công → phân tán trên HƠN 600 điểm biên toàn cầu
             → hạ tầng của AWS hấp thụ
             → origin gần như không bị chạm tới
             → Shield Standard tự động bảo vệ tầng 3/4

Và rate-based rule chống tấn công tầng 7 — thứ mà CloudFront một mình không lọc được:

{
  "Name": "GioiHanTanSuat",
  "Statement": {"RateBasedStatement": {"Limit": 2000, "AggregateKeyType": "IP"}},
  "Action": {"Block": {}}
}
Đặc điểm Chi tiết
Chặn theo HÀNH VI, không theo danh tính IP đổi liên tục cũng bị chặn khi vượt ngưỡng
Cửa sổ trượt 5 phút
Tự động gỡ chặn khi tần suất giảm

Và ALB là origin đúng cho ứng dụng web — nó ở tầng 7, xử lý HTTP, và WAF gắn được vào cả CloudFront lẫn ALB.

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

  • **C. CloudFront với ALB làm origin; tạo security group rule từ chối các địa chỉ đáng ngờ; dùng SNS thông báo — đây là phương án gần nhất về mặt kiến trúc CloudFront + ALB, nhưng security group KHÔNG CÓ rule deny: nó chỉ có rule Allow. Và chặn cứng theo IP không đối phó được với tấn công phân tán từ hàng nghìn địa chỉ.
  • **B. CloudFront với Network Load Balancer làm origin; dùng VPC Flow Logs giám sát; Lambda xử lý flow log và gọi SNS — hai vấn đề: NLB ở tầng 4, không phù hợp làm origin cho ứng dụng web cần WAF; và Flow Logs chỉ giám sát sau khi việc đã xảy ra — nó không giảm thiểu gì.
  • **D. CloudFront với NLB làm origin; dùng GuardDuty chặn host đáng ngờ dựa trên finding — GuardDuty KHÔNG CHẶN gì cả: nó phát hiện mối đe doạ và sinh finding. Việc chặn phải do WAF, security group hoặc NACL thực hiện.

Ghi nhớ

Ba lớp phòng thủ DDoS trên AWS: | Lớp | Chống | Chi phí | |---|---|---| | Shield Standard | tầng 3/4 phổ biến | MIỄN PHÍ, tự động cho mọi khách hàng | | AWS WAF | tầng 7 theo quy tắc | tính phí | | Shield Advanced | tầng 3/4/7 nâng cao + SRT + bảo vệ chi phí | 3.000 USD/tháng |

Tấn công tầng 3/4 và tầng 7: | | Tầng 3/4 | Tầng 7 | |---|---|---| | Ví dụ | SYN flood, UDP reflection | HTTP flood, slowloris | | Đặc điểm | khối lượng lớn, gói dị thường | request HỢP LỆ, khó phân biệt | | Chống bằng | Shield (tự động) | WAF (cần quy tắc) |

Bốn nguyên tắc kiến trúc chống DDoS: | Nguyên tắc | Cách làm | |---|---| | Đẩy ra biên | CloudFront, Route 53 hấp thụ ở hơn 600 điểm | | Giảm diện tích phơi ra | origin chỉ nhận từ CloudFront | | Chuẩn bị mở rộng | ASG (nhưng cân nhắc chi phí) | | Biết khi bị tấn công | alarm trên DDoSDetected (cần Shield Advanced) |

Dòng thứ hai hay bị quên nhất và làm hỏng cả thiết kế: đặt CloudFront phía trước nhưng vẫn để ALB nhận từ 0.0.0.0/0 thì kẻ tấn công tìm ra IP của ALB và bỏ qua toàn bộ lớp bảo vệ.

Bịt bằng AWS-managed prefix list:

Security group của ALB:
    Nguồn: com.amazonaws.global.cloudfront.origin-facing

Hoặc dùng custom header bí mật mà chỉ CloudFront gửi, và ALB listener rule kiểm tra nó.

Bốn hành động của WAF rule: | Hành động | Kết quả | |---|---| | Count | chỉ đếm — CHẾ ĐỘ THỬ NGHIỆM | | Allow / Block | cho qua / chặn | | CAPTCHA / Challenge | phân biệt người và bot, giảm rủi ro chặn nhầm |

Quy trình triển khai an toàn:

① Đặt rule ở Count
② Bật log WAF, quan sát vài ngày
③ Kiểm tra có request hợp lệ nào vượt ngưỡng không
④ Điều chỉnh ngưỡng rồi chuyển sang Block hoặc Challenge

Các bộ managed rule nên bật kèm: | Bộ | Bảo vệ | |---|---| | AWSManagedRulesCommonRuleSet | OWASP phổ biến | | AWSManagedRulesKnownBadInputsRuleSet | mẫu khai thác đã biết | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesBotControlRuleSet | nhận diện bot |

Lưu ý về phạm vi WAF cho CloudFront: Web ACL phải được tạo ở us-east-1 với scope CLOUDFRONT. Tạo ở Region khác thì không gắn được — lỗi hay gặp khi triển khai lần đầu.

Và với ngữ cảnh "network security audit" của đề, hãy cân nhắc thêm Shield Advanced nếu ứng dụng quan trọng: nó cho metric DDoSDetected để biết khi nào đang bị tấn công, đội SRT hỗ trợ 24/7, và bảo vệ chi phí hoàn lại khoản scale do tấn công gây ra.

Câu 109 Design Resilient Architectures

A DevOps Engineer is required to design a cloud architecture in AWS. The Engineer is planning to develop a highly available and fault-tolerant architecture consisting of an Elastic Load Balancer and an Auto Scaling group of EC2 instances deployed across multiple Availability Zones. This will be used by an online accounting application that requires path-based routing, host-based routing, and bi-directional streaming using Remote Procedure Call (gRPC).

Which configuration will satisfy the given requirement?

  1. A

    Configure an Application Load Balancer in front of the auto-scaling group. Select gRPC as the protocol version.
  2. B

    Configure a Network Load Balancer in front of the auto-scaling group. Use a UDP listener for routing.
  3. C

    Configure a Gateway Load Balancer in front of the auto-scaling group. Ensure that the IP Listener Routing uses the GENEVE protocol on port 6081 to allow gRPC response traffic.
  4. D

    Configure a Network Load Balancer in front of the auto-scaling group. Create an AWS Global Accelerator accelerator and set the load balancer as an endpoint.
Xem giải thích

Đáp án

A — Cấu hình một Application Load Balancer trước Auto Scaling group. Chọn gRPC làm phiên bản giao thức.

Vì sao đúng

Đề nêu ba yêu cầu kỹ thuật, và cả ba đều chỉ tới ALB: | Yêu cầu | Cơ chế | |---|---| | Path-based routing | ALB — định tuyến theo đường dẫn URL | | Host-based routing | ALB — định tuyến theo tên miền | | Luồng hai chiều bằng gRPC | ALB hỗ trợ gRPC làm protocol version |

Ba yêu cầu này đều thuộc tầng 7 — và chỉ ALB hoạt động ở tầng đó:

Path-based:  /api/*     → target group A
             /admin/*   → target group B

Host-based:  api.congty.vn    → target group A
             admin.congty.vn  → target group B

    → cả hai đòi ĐỌC ĐƯỢC nội dung HTTP request
    → NLB ở tầng 4 KHÔNG nhìn thấy gì trong đó

Và hỗ trợ gRPC là tính năng riêng của ALB:

gRPC chạy trên HTTP/2
    → ALB hỗ trợ HTTP/2 và có protocol version "gRPC" riêng
    → định tuyến được theo tên service và method của gRPC
    → health check bằng chính giao thức gRPC

aws elbv2 create-target-group   --name tg-grpc --protocol HTTP --protocol-version GRPC   --port 50051 --vpc-id vpc-0abc   --health-check-protocol HTTP --matcher GrpcCode=0

GrpcCode=0 là mã trạng thái OK của gRPC — khác với mã HTTP 200 thông thường.

Và "bi-directional streaming" là một chế độ của gRPC mà HTTP/2 hỗ trợ tự nhiên nhờ khả năng multiplexing.

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

  • **D. Network Load Balancer trước Auto Scaling group; tạo Global Accelerator và đặt NLB làm endpoint — đây là phương án gần nhất về mặt NLB có hỗ trợ TCP nên gRPC chạy được qua đó, nhưng nó không đáp ứng hai yêu cầu chính: NLB ở tầng 4 nên không làm được path-based và host-based routing.
  • **B. Network Load Balancer với UDP listener — sai giao thức: gRPC chạy trên HTTP/2 qua TCP, không phải UDP. Và NLB vẫn không định tuyến theo nội dung được.
  • **C. Gateway Load Balancer với IP Listener Routing dùng giao thức GENEVE trên cổng 6081 — sai loại load balancer hoàn toàn: GWLB dành cho việc chèn thiết bị bảo mật của bên thứ ba (tường lửa ảo, IDS/IPS) vào đường đi của lưu lượng. GENEVE là giao thức đóng gói mà nó dùng, không liên quan tới gRPC.

Ghi nhớ

Ba loại Elastic Load Balancer — bảng cần thuộc: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP/HTTPS/gRPC) | 4 (TCP/UDP/TLS) | 3 (GENEVE) | | Path-based routing | ✅ | ❌ | ❌ | | Host-based routing | ✅ | ❌ | ❌ | | gRPC | ✅ | qua TCP, không định tuyến được | ❌ | | WebSocket | ✅ | ✅ | ❌ | | IP tĩnh | ❌ | ✅ | — | | Giữ IP nguồn client | qua X-Forwarded-For | ✅ nguyên bản | ✅ | | Độ trễ | cao hơn | cực thấp | — | | Tích hợp WAF | ✅ | ❌ | ❌ |

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

"path-based", "host-based", "HTTP header", "gRPC", "WAF" → ALB "static IP", "extreme performance", "TCP/UDP", "millions of requests" → NLB "third-party firewall", "IDS/IPS appliance" → GWLB

Ba loại điều kiện định tuyến của ALB: | Điều kiện | Ví dụ | |---|---| | Path pattern | /api/*, /images/* | | Host header | api.congty.vn | | HTTP header, method, query string, source IP | linh hoạt hơn nữa |

Ba ProtocolVersion của ALB target group: | Giá trị | Dùng cho | |---|---| | HTTP1 | mặc định | | HTTP2 | hiệu năng cao hơn | | GRPC | gRPC service ← câu này |

Ba đặc điểm của gRPC: | Đặc điểm | Chi tiết | |---|---| | Chạy trên HTTP/2 | multiplexing, nén header | | Dùng Protocol Buffers | nhị phân, nhỏ và nhanh hơn JSON | | Bốn chế độ gọi | unary, server streaming, client streaming, bidirectional streaming |

Chế độ thứ tư là thứ đề nhắc tới — và nó cần hạ tầng hỗ trợ giữ kết nối HTTP/2 mở lâu dài.

Ba lưu ý khi triển khai gRPC sau ALB: | Lưu ý | Chi tiết | |---|---| | Bắt buộc TLS | gRPC qua ALB yêu cầu HTTPS listener | | Health check dùng GrpcCode | không phải mã HTTP | | idle_timeout đủ dài | streaming hai chiều giữ kết nối lâu — mặc định 60 giây có thể quá ngắn |

Dòng cuối là cấu hình hay gây lỗi khó hiểu: kết nối streaming bị ngắt giữa chừng mà không rõ lý do, thực ra là ALB đóng vì hết thời gian nhàn rỗi. Tăng idle_timeout lên tới 4.000 giây nếu cần.

Và một lưu ý về kiến trúc sẵn sàng cao mà đề yêu cầu: ALB phải được cấu hình ở ít nhất hai AZ, và Auto Scaling group cũng vậy. Bật cross-zone load balancing (mặc định bật cho ALB) để lưu lượng phân bố đều kể cả khi số instance ở các AZ không bằng nhau.

Câu 110 Design Cost-Optimized Architectures

A start-up company that offers an intuitive financial data analytics service has consulted you about their AWS architecture. They have a fleet of Amazon EC2 worker instances that process financial data and then outputs reports which are used by their clients. You must store the generated report files in a durable storage. The number of files to be stored can grow over time as the start-up company is expanding rapidly overseas and hence, they also need a way to distribute the reports faster to clients located across the globe. 

Which of the following is a cost-efficient and scalable storage option that you should use for this scenario?

  1. A

    Use Amazon Redshift as the data storage and CloudFront as the CDN.
  2. B

    Use Amazon Glacier as the data storage and ElastiCache as the CDN.
  3. C

    Use Amazon S3 as the data storage and CloudFront as the CDN.
  4. D

    Use multiple EC2 instance stores for data storage and ElastiCache as the CDN.
Xem giải thích

Đáp án

C — Dùng Amazon S3 làm nơi lưu trữ dữ liệu và CloudFront làm CDN.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp S3 + CloudFront đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Lưu trữ BỀN VỮNG cho tệp báo cáo | S3 — độ bền 11 số 9, dữ liệu trên nhiều AZ | | Số lượng tệp tăng theo thời gian | S3 tự mở rộng, không giới hạn dung lượng | | Phân phối nhanh tới khách hàng toàn cầu | CloudFront — hơn 600 điểm biên |

Vì sao S3 phù hợp cho "cost-efficient and scalable":

Không khai dung lượng trước
    → trả tiền theo GB thực dùng
    → từ vài MB tới hàng petabyte, không phải làm gì
    → không có máy chủ nào chạy nhàn rỗi

Và CloudFront giải quyết vế "distribute the reports faster to clients across the globe": | Lợi ích | Chi tiết | |---|---| | Cache ở biên gần khách hàng | độ trễ thấp trên toàn cầu | | Phí truyền dữ liệu rẻ hơn S3 trực tiếp | tiết kiệm thật với lưu lượng lớn | | Giảm request tới origin | ít lời gọi S3 hơn | | Signed URL | kiểm soát ai tải được báo cáo nào |

Dòng cuối đáng chú ý cho tình huống của đề: báo cáo tài chính là dữ liệu riêng của từng khách hàng — signed URL cho phép cấp quyền truy cập có thời hạn cho đúng người, mà không cần bucket công khai.

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

  • **A. Dùng Amazon Redshift làm nơi lưu trữ dữ liệu và CloudFront làm CDN — đây là phương án gần nhất về mặt có CloudFront đúng, nhưng Redshift là KHO DỮ LIỆU PHÂN TÍCH (OLAP), không phải nơi lưu trữ tệp. Nó lưu dữ liệu dạng bảng để chạy truy vấn SQL, và nó là cụm chạy liên tục — trái yêu cầu tiết kiệm.
  • **B. Dùng Amazon Glacier làm nơi lưu trữ và ElastiCache làm CDN — sai cả hai: Glacier là lớp lưu trữ dài hạn với thời gian truy xuất hàng giờ — không phục vụ được khách hàng tải báo cáo. Và ElastiCache là cache trong bộ nhớ nằm trong VPC, hoàn toàn không phải CDN.
  • **D. Dùng nhiều EC2 instance store làm nơi lưu trữ và ElastiCache làm CDN — instance store KHÔNG BỀN VỮNG: dữ liệu mất khi instance dừng. Đó là điều tệ nhất có thể xảy ra với báo cáo của khách hàng.

Ghi nhớ

Ba loại lưu trữ trên AWS: | Loại | Dịch vụ | Dùng cho | |---|---|---| | Đối tượng | S3, Glacier | tệp, ảnh, video, sao lưu ← câu này | | Khối | EBS, instance store | ổ đĩa cho instance | | Tệp | EFS, FSx | hệ thống tệp chia sẻ |

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

"tệp", "báo cáo", "ảnh", "durable", "unlimited" → S3 "ổ đĩa cho một máy" → EBS "nhiều máy dùng chung hệ thống tệp" → EFS hoặc FSx

Ba dịch vụ hay bị gọi nhầm là CDN: | Dịch vụ | Thực sự là gì | |---|---| | CloudFront | CDN THẬT — cache ở biên toàn cầu | | ElastiCache | cache TRONG BỘ NHỚ, nằm trong VPC | | Global Accelerator | định tuyến qua mạng AWS — KHÔNG cache |

Các lớp lưu trữ S3 và mục đích: | Lớp | Truy xuất | Dùng cho | |---|---|---| | Standard | mili giây | báo cáo mới, hay tải | | Intelligent-Tiering | mili giây | mẫu truy cập không đoán được | | Standard-IA | mili giây + phí truy xuất | báo cáo cũ, ít tải | | Glacier Deep Archive | 12–48 giờ | lưu trữ tuân thủ nhiều năm |

Với báo cáo tài chính, một lifecycle rule hợp lý:

{"Rules": [{
  "Status": "Enabled",
  "Transitions": [
    {"Days": 90,  "StorageClass": "STANDARD_IA"},
    {"Days": 365, "StorageClass": "GLACIER_IR"}
  ]}]}

Báo cáo mới hay được tải, báo cáo cũ hiếm khi ai xem — chuyển tầng theo tuổi tiết kiệm đáng kể.

Ba cách kiểm soát truy cập báo cáo: | Cách | Đặc điểm | |---|---| | Signed URL của CloudFront | một tệp, có thời hạn | | Signed cookie | nhiều tệp theo mẫu đường dẫn | | Pre-signed URL của S3 | tương tự nhưng không qua CDN |

Với báo cáo riêng cho từng khách hàng, signed URL là mẫu chuẩn: ứng dụng xác thực người dùng, rồi sinh một URL có hạn dùng 15 phút cho đúng tệp của họ.

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

EC2 worker sinh báo cáo
    ↓ ghi vào S3
S3 bucket RIÊNG TƯ
    ↓ OAC
CloudFront (cache, signed URL)
    ↓
Khách hàng toàn cầu

Và bước bảo mật bắt buộc: bucket phải riêng tư với OAC. Nếu để công khai, ai có URL là tải được — kể cả người không phải khách hàng, và signed URL trở nên vô nghĩa.

Và một tối ưu chi phí đáng cân nhắc: nếu khách hàng tập trung ở vài khu vực, chọn price class phù hợp (PriceClass_100 hoặc PriceClass_200) thay vì PriceClass_All — nó giới hạn số edge location được dùng và giảm chi phí đáng kể.