Ngân hàng đề — AWS Certified Solutions Architect Professional
Tìm thấy 1221 câu.
A print media company has a popular web application hosted on their on-premises network which allows anyone around the globe to search its back catalog and retrieve individual newspaper pages on their web portal. They scanned the old newspapers into PNG image format and used Optical Character Recognition (OCR) software to automatically convert images to a text file. The license of their OCR software will expire soon, and the news organization decided to move to AWS and produce a scalable, durable, and highly available architecture.
Which is the best option to achieve this requirement?
-
A
Create a new S3 bucket to store and serve the scanned image files using a CloudFront web distribution. Launch a new Elastic Beanstalk environment to host the website across multiple Availability Zones and set up a CloudSearch for query processing, which the website can use. Use Amazon Textract to detect and recognize text from the scanned old newspapers.
-
B
Store the images in an S3 bucket and prepare a separate bucket to host the static website. Utilize Amazon Kendra to intelligently search and select the images stored in S3. Set up a lifecycle policy to move the selected images to Glacier after 3 months and if needed, use Glacier Select to query the archives.
- C Create a new CloudFormation template which has EBS-backed EC2 instances with an Application Load Balancer in front. Install and run an NGINX web server and an open source search application. Store the images to EBS volumes with Amazon Data Lifecycle Manager configured, and which automatically attach new volumes to the EC2 instances as required.
-
D
Use S3 Intelligent-Tiering storage class to store and serve the scanned files. Migrate the on-premises web application as well as the Optical Character Recognition (OCR) software to an Auto Scaling group of Spot EC2 Instances across multiple Availability Zones with an Application Load Balancer to balance the incoming load. Use Amazon Rekognition to detect and recognize text from the scanned old newspapers.
Xem giải thích
Đáp án
A — Tạo bucket S3 lưu và phục vụ ảnh quét qua CloudFront; dựng môi trường Elastic Beanstalk đa AZ cho website; dùng CloudSearch xử lý truy vấn; dùng Amazon Textract nhận dạng văn bản từ ảnh quét.
Vì sao đúng
Đề nêu bốn yêu cầu, và phương án này giải quyết từng cái bằng dịch vụ được quản lý: | Yêu cầu | Dịch vụ | |---|---| | Giấy phép OCR sắp hết hạn | Textract — OCR do AWS quản lý | | Phục vụ ảnh cho người dùng toàn cầu | S3 + CloudFront | | Tìm kiếm trong kho báo cũ | dịch vụ tìm kiếm được quản lý | | Co giãn, bền, sẵn sàng cao | Beanstalk đa AZ |
⚠ Textract thay thế trực tiếp phần mềm OCR sắp hết hạn:
Textract không chỉ đọc chữ
→ còn nhận diện bảng, biểu mẫu, cấu trúc
↓
Với báo cũ nhiều cột, đây là lợi thế thật
→ và không có giấy phép nào để gia hạn
Xử lý bất đồng bộ cho tài liệu nhiều trang:
aws textract start-document-text-detection \
--document-location '{"S3Object":{
"Bucket":"kho-bao-cu","Name":"quet/1985/thang-03.pdf"}}' \
--notification-channel 'SNSTopicArn=<arn-sns>,
RoleArn=<arn-role>' \
--output-config '{"S3Bucket":"ket-qua-ocr","S3Prefix":"van-ban/"}'
⚠ Textract có hai bộ API: | Bộ | Dùng cho | |---|---| | Đồng bộ (detect-document-text) | một trang, trả kết quả ngay | | Bất đồng bộ (start-document-text-detection) | nhiều trang, thông báo qua SNS |
Kiến trúc xử lý hàng loạt:
Ảnh quét vào S3
→ S3 event → Lambda
→ Lambda gọi Textract bất đồng bộ
↓
Textract xong → SNS
→ Lambda thứ hai lấy kết quả
→ nạp vào chỉ mục tìm kiếm
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không còn giấy phép phần mềm nào | | | Trả tiền theo số trang xử lý | | | CloudFront phục vụ ảnh toàn cầu | |
⚠ Vì sao S3 + CloudFront hợp cho ảnh báo:
Ảnh trang báo: bất biến, đọc nhiều, không đổi
→ cache ở edge rất hiệu quả
↓
Tỷ lệ trúng cache rất cao
→ origin gần như không chịu tải
Lifecycle cho ảnh ít truy cập:
aws s3api put-bucket-lifecycle-configuration \
--bucket kho-bao-cu \
--lifecycle-configuration '{
"Rules":[{"ID":"nguoi-dan","Status":"Enabled",
"Filter":{"Prefix":"quet/"},
"Transitions":[
{"Days":90,"StorageClass":"INTELLIGENT_TIERING"}]}]}'
Ghi nhớ về chất lượng câu hỏi
⚠ Amazon CloudSearch là dịch vụ CŨ, AWS không còn khuyến nghị.
| Dịch vụ | Trạng thái |
|---|---|
| CloudSearch | cũ — không phát triển thêm |
| OpenSearch Service | thay thế cho tìm kiếm toàn văn |
| Amazon Kendra | tìm kiếm ngữ nghĩa bằng học máy |
Với thiết kế mới ngày nay:
→ OpenSearch cho tìm kiếm toàn văn có xếp hạng
→ Kendra nếu muốn hỏi bằng ngôn ngữ tự nhiên
↓
CloudSearch vẫn chạy, vẫn là câu trả lời
đúng nhất trong bốn phương án
→ nhưng đừng chọn nó cho hệ thống mới
Và một lưu ý nữa về phương án B:
Phương án B dùng Kendra — dịch vụ HIỆN ĐẠI HƠN
→ nhưng nó sai ở chỗ khác:
chuyển ảnh sang Glacier sau 3 tháng
rồi "dùng Glacier Select để truy vấn"
↓
Glacier Select đọc dữ liệu có cấu trúc (CSV, JSON),
KHÔNG tìm kiếm ảnh
→ và Glacier cần hàng giờ để lấy dữ liệu
Nói rõ điều này vì gặp bài toán tương tự ngoài đời, hãy dùng OpenSearch hoặc Kendra, và giữ ảnh ở S3 Intelligent-Tiering thay vì Glacier nếu người dùng cần xem ngay.
Vì sao các phương án khác sai
- **B. S3 + Kendra + chuyển ảnh sang Glacier sau 3 tháng — đây là phương án gần nhất và dùng dịch vụ tìm kiếm hiện đại hơn, nhưng chuyển ảnh sang Glacier khiến người đọc phải chờ hàng giờ mới xem được trang báo; và Glacier Select không dùng để tìm kiếm ảnh.
- **D. S3 Intelligent-Tiering + tự chạy phần mềm OCR trên Spot EC2 + Rekognition — không giải quyết vấn đề giấy phép (vẫn dùng phần mềm cũ); và Rekognition phát hiện văn bản trong ảnh cảnh vật, không phải OCR tài liệu.
- **C. EC2 với EBS và tự cài NGINX cùng công cụ tìm kiếm mã nguồn mở — công vận hành cao nhất; và EBS không phù hợp để phục vụ hàng triệu ảnh cho người dùng toàn cầu.
Ghi nhớ
⚠ Textract vs Rekognition — bảng phải thuộc: | Dịch vụ | Đầu vào | Việc | |---|---|---| | Textract | tài liệu quét, PDF | OCR có cấu trúc: chữ, bảng, biểu mẫu | | Rekognition | ảnh, video | nhãn, khuôn mặt, vật thể; phát hiện chữ trong CẢNH |
⚠ Cả hai đều "đọc chữ" nhưng cho hai mục đích khác nhau:
Rekognition DetectText: chữ trong ảnh chụp
→ biển số xe, biển hiệu cửa hàng
↓
Textract: tài liệu
→ giữ được cấu trúc dòng, đoạn, bảng
→ đúng cho báo cũ
Từ khoá nhận diện:
"OCR scanned documents" → Textract "text in photos and scenes" → Rekognition "full-text search with ranking" → OpenSearch "natural language question answering" → Kendra "legacy managed search" → CloudSearch (không dùng cho mới)
Ba năng lực của Textract: | Năng lực | API | |---|---| | Phát hiện văn bản thô | DetectDocumentText | | Phân tích biểu mẫu và bảng | AnalyzeDocument | | Trích dữ liệu hoá đơn, ID | AnalyzeExpense, AnalyzeID |
Ba lưu ý về chi phí Textract: | Khoản | Giá tham khảo | |---|---| | Phát hiện văn bản | ~1,50 USD mỗi 1000 trang | | Phân tích bảng và biểu mẫu | đắt hơn nhiều | | Xử lý một lần cho kho lịch sử | tính trước tổng số trang |
⚠ Kho báo lâu năm có thể là hàng triệu trang:
1 triệu trang × 1,50 USD/1000 = 1.500 USD
→ chi phí một lần, chấp nhận được
↓
Nhưng nếu dùng AnalyzeDocument cho bảng
→ đắt hơn nhiều lần
→ chỉ dùng khi thật sự cần cấu trúc
Ba lưu ý về OpenSearch (lựa chọn hiện đại): | Lưu ý | Chi tiết | |---|---| | Tìm kiếm toàn văn có xếp hạng | | | UltraWarm cho chỉ mục ít truy vấn | | | Serverless nếu tải thất thường | |
⚠ OpenSearch Serverless bỏ việc quản lý cụm:
aws opensearchserverless create-collection \
--name tim-kiem-bao --type SEARCH
Ba lưu ý về Elastic Beanstalk: | Lưu ý | Chi tiết | |---|---| | Dựng sẵn ASG, ALB, health check | | | Cấu hình đa AZ trong tuỳ chọn môi trường | | | Vẫn là EC2 bên dưới — vẫn phải vá qua platform update | |
Ba lưu ý về CloudFront cho ảnh: | Lưu ý | Chi tiết | |---|---| | Dùng OAC, giữ bucket riêng tư | | | Cache policy CachingOptimized | | | Bật nén cho metadata, không cho ảnh | |
Ba lưu ý về lưu trữ ảnh: | Lớp | Khi nào | |---|---| | Standard | ảnh hay xem | | Intelligent-Tiering | mẫu truy cập không đoán trước | | Glacier IR | ít xem nhưng cần ngay |
⚠ Đừng dùng Glacier Flexible/Deep Archive cho nội dung người dùng xem:
Người đọc bấm vào một trang báo năm 1970
→ phải chờ 3-12 giờ
↓
Glacier Instant Retrieval nếu cần rẻ mà vẫn nhanh
Ba lưu ý về xử lý hàng loạt: | Lưu ý | Chi tiết | |---|---| | Dùng SQS điều tiết nhịp gọi Textract | | | Textract có hạn ngạch tần suất | | | Xử lý dần thay vì đổ hết một lúc | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy Textract trên vài trang mẫu, kiểm chất lượng | | | Đo tỷ lệ trúng cache CloudFront | | | Thử tìm kiếm với từ khoá thật | |
Và một lời khuyên: hãy chạy Textract trên một mẫu đại diện trước khi xử lý cả kho. Báo cũ có chất lượng quét rất khác nhau, và tỷ lệ nhận dạng đúng trên vài trăm trang mẫu là con số duy nhất cho biết dự án có khả thi hay không — trước khi bạn tiêu tiền cho hàng triệu trang.
A telecommunications company is planning to host a WordPress website on an Amazon ECS Cluster which uses the Fargate launch type. For security purposes, the database credentials should be provided to the WordPress image by using environment variables. Your manager instructed you to ensure that the credentials are secure when passed to the image and that they cannot be viewed on the cluster itself. The credentials must be kept in a dedicated storage with lifecycle management and key rotation.
Which of the following is the most suitable solution in this scenario that you can implement with the least effort?
-
A
Migrate the container cluster to Amazon Elastic Kubernetes Service (EKS). Create manifest files for deployment and use the Kubernetes Secrets objects to store the database credentials. Reference the secrets on the manifest file using the
secretKeyRefto use them a environment variables. Configure EKS to rotate the secret values automatically. -
B
In the ECS task definition file of the ECS Cluster, store the database credentials and encrypt with KMS. Store the task definition JSON file in a private S3 bucket and ensure that HTTPS is enabled on the bucket to encrypt the data in-flight. Create an IAM role to the ECS task definiton script that allows access to the specific S3 bucket and then pass the
--cli-input-jsonparameter when calling the ECS register-task-definition. Reference the task definition JSON file in the S3 bucket which contains the database credentials. -
C
Store the database credentials using the AWS Systems Manager Parameter Store and then encrypt them using AWS KMS. Create an IAM Role for your Amazon ECS task execution role and reference it with your task definition, which allows access to both KMS and the Parameter Store. Within your container definition, specify secrets with the name of the environment variable to set in the container and the full ARN of the Systems Manager Parameter Store parameter containing the sensitive data to present to the container.
-
D
Store the database credentials using the AWS Secrets Manager and then encrypt them using AWS KMS. Create an IAM Role for your Amazon ECS task execution role and reference it with your task definition which allows access to both KMS and AWS Secrets Manager. Within your container definition, specify secrets with the name of the environment variable to set in the container and the full ARN of the Secrets Manager secret which contains the sensitive data, to present to the container.
Xem giải thích
Đáp án
D — Lưu thông tin đăng nhập CSDL trong AWS Secrets Manager, mã hoá bằng KMS; tạo task execution role cho ECS tham chiếu trong task definition, cho phép truy cập cả KMS lẫn Secrets Manager; trong container definition khai secrets với tên biến môi trường và ARN của secret.
Vì sao đúng
Đề nêu bốn yêu cầu, và chi tiết quyết định nằm ở yêu cầu cuối: | Yêu cầu | Cách đáp ứng | |---|---| | Truyền credential qua biến môi trường | secrets trong container definition | | An toàn khi truyền | ECS lấy giá trị lúc khởi động task | | Không xem được trên cụm | giá trị không nằm trong task definition | | Kho chuyên dụng có VÒNG ĐỜI và XOAY KHOÁ | chỉ Secrets Manager có xoay tự động |
⚠ "Key rotation" là từ khoá phân biệt Secrets Manager với Parameter Store: | Tiêu chí | Secrets Manager | Parameter Store | |---|---|---| | Xoay TỰ ĐỘNG | ✅ tích hợp sẵn | ❌ phải tự viết | | Quản lý vòng đời | ✅ | hạn chế | | Chi phí | ~0,40 USD/secret/tháng | Standard MIỄN PHÍ | | Tích hợp RDS | ✅ Lambda xoay dựng sẵn | ❌ |
Đề nói rõ: "dedicated storage with LIFECYCLE
MANAGEMENT and KEY ROTATION"
↓
Đây là mô tả chính xác Secrets Manager
Khai trong task definition:
{"containerDefinitions": [{
"name": "wordpress",
"image": "wordpress:latest",
"secrets": [
{"name": "WORDPRESS_DB_PASSWORD",
"valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:wp/csdl-AbCdEf:password::"},
{"name": "WORDPRESS_DB_USER",
"valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:wp/csdl-AbCdEf:username::"}]}],
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"}
⚠ Cú pháp :secret-name:json-key:version-stage:version-id cho phép lấy MỘT trường:
`...:secret:wp/csdl-AbCdEf:password::`
→ chỉ lấy trường `password` trong JSON
↓
Không phải nạp cả khối JSON vào biến
⚠ Điểm quan trọng nhất — giá trị KHÔNG nằm trong task definition:
Dùng `environment` thường:
→ giá trị nằm NGUYÊN VĂN trong task definition
→ ai xem được ECS console cũng đọc được
↓
Dùng `secrets`:
→ chỉ có ARN trong task definition
→ ECS agent lấy giá trị lúc khởi động
→ không hiện ở đâu cả
Execution role cần hai quyền:
{"Version": "2012-10-17",
"Statement": [
{"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:wp/*"},
{"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "<arn-khoa>"}]}
⚠ Phải là EXECUTION role, không phải TASK role: | Vai trò | Dùng khi nào | |---|---| | Execution role | ECS agent kéo image và LẤY SECRET | | Task role | mã trong container gọi API AWS |
Nhầm hai vai trò này
→ task không khởi động được
→ lỗi "unable to retrieve secret"
Bật xoay tự động:
aws secretsmanager rotate-secret \
--secret-id wp/csdl \
--rotation-lambda-arn <arn-lambda-xoay> \
--rotation-rules AutomaticallyAfterDays=30
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Xoay tự động không cần viết mã | | | Không ai thấy mật khẩu, kể cả người vận hành | | | CloudTrail ghi mọi lần lấy secret | |
Vì sao các phương án khác sai
- **C. Dùng Systems Manager Parameter Store với KMS — đây là phương án gần nhất và cách khai
secretshoàn toàn giống nhau, nhưng Parameter Store không có xoay tự động; đề nói rõ cần "key rotation". (Nếu bỏ yêu cầu đó thì Parameter Store rẻ hơn và là lựa chọn tốt.) - **B. Lưu credential trong task definition mã hoá bằng KMS, đặt file JSON trong S3 — task definition là siêu dữ liệu hiện ra trong console và API; và tự quản lý file JSON là công vận hành mà đề nói muốn tránh.
- **A. Chuyển sang EKS và dùng Kubernetes Secrets — đổi cả nền tảng điều phối là thay đổi lớn; và Kubernetes Secret mặc định chỉ mã hoá base64 (không phải mã hoá thật) trừ khi bật KMS encryption riêng.
Ghi nhớ
⚠ Secrets Manager vs Parameter Store — bảng phải thuộc: | Tiêu chí | Secrets Manager | Parameter Store | |---|---|---| | Xoay tự động | ✅ | ❌ | | Giá | ~0,40 USD/secret/tháng | Standard miễn phí | | Kích thước tối đa | 64 KB | 4 KB (Standard) / 8 KB (Advanced) | | Sinh mật khẩu ngẫu nhiên | ✅ | ❌ | | Nhân bản xuyên Region | ✅ | ❌ |
⚠ Quy tắc chọn:
Cần xoay tự động, hoặc là credential CSDL → Secrets Manager
Chỉ là cấu hình hoặc chuỗi kết nối tĩnh → Parameter Store
↓
Parameter Store Standard MIỄN PHÍ
→ đừng trả tiền cho thứ không cần xoay
Từ khoá nhận diện:
"rotation, lifecycle management" → Secrets Manager "configuration values, free" → Parameter Store "pass secret to container as env var" →
secretstrong container definition "database credentials without any password" → IAM database authentication
⚠ Lựa chọn tốt nhất là không có mật khẩu nào cả:
RDS IAM database authentication
→ ứng dụng sinh token 15 phút từ vai trò IAM
↓
Không có mật khẩu để lưu, để xoay, để rò rỉ
→ nhưng WordPress không hỗ trợ sẵn
Ba chiến lược xoay của Secrets Manager: | Chiến lược | Chi tiết | |---|---| | Single user | đổi mật khẩu của chính user đó | | Alternating users | hai user luân phiên — KHÔNG gián đoạn | | Tuỳ chỉnh | tự viết Lambda |
⚠ Alternating users tránh gián đoạn khi xoay:
Single user: đổi mật khẩu
→ kết nối đang dùng mật khẩu cũ có thể lỗi
↓
Alternating: user A đang dùng, xoay user B
→ chuyển sang B, lần sau xoay A
→ luôn có một user hợp lệ
Ba lưu ý về --manage-master-user-password của RDS: | Lưu ý | Chi tiết | |---|---| | RDS tự tạo secret và tự xoay | | | Không ai nhìn thấy mật khẩu gốc | | | Ít việc nhất trong mọi cách | |
aws rds create-db-instance \
--db-instance-identifier csdl-wp \
--engine mysql --manage-master-user-password
Ba lưu ý về Fargate: | Lưu ý | Chi tiết | |---|---| | Platform version 1.3 trở lên cho secrets | | | Cần đường ra tới endpoint Secrets Manager | | | VPC endpoint nếu ở subnet riêng tư | |
⚠ Thiếu đường ra là lỗi khởi động task hay gặp:
Task ở subnet riêng tư không có NAT
→ không gọi được Secrets Manager
↓
Task kẹt ở PROVISIONING rồi thất bại
→ tạo interface endpoint cho secretsmanager và kms
Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | ~0,40 USD mỗi secret mỗi tháng | | | ~0,05 USD mỗi 10.000 lời gọi API | | | Gộp nhiều trường vào MỘT secret JSON | |
⚠ Gộp trường tiết kiệm đáng kể:
Mỗi trường một secret: 5 secret = 2 USD/tháng
↓
Một secret JSON chứa cả 5 trường: 0,40 USD
→ và cú pháp `:json-key:` lấy riêng từng trường
Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Resource policy giới hạn ai đọc secret | | | CloudTrail ghi mọi GetSecretValue | | | Cảnh báo khi có truy cập bất thường | |
Ba lưu ý về nhân bản: | Lưu ý | Chi tiết | |---|---| | Nhân bản secret sang Region khác | | | Cần cho kiến trúc đa Region | | | Xoay ở Region chính lan sang bản sao | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem task definition — không được có mật khẩu | | | describe-tasks xác nhận biến được nạp | | | Kích hoạt xoay thủ công, xem ứng dụng còn chạy | |
aws secretsmanager rotate-secret --secret-id wp/csdl
Và một lời khuyên: hãy kiểm chứng bằng cách kích hoạt xoay thủ công một lần ở môi trường thử. Xoay tự động chỉ đáng tin khi đã được chứng kiến — và thời điểm phát hiện ứng dụng không đọc lại secret sau khi xoay phải là buổi kiểm thử, chứ không phải ba mươi ngày sau khi lên sản xuất.
A company is planning to build its new customer relationship management (CRM) portal in AWS. The application architecture will be using a containerized microservices hosted on an Amazon ECS cluster. A Solutions Architect has been tasked to set up the architecture and comply with the AWS security best practice of granting the least privilege. The architecture should also support the use of security groups and standard network monitoring tools at the container level to comply with the company’s strict IT security policies.
Which of the following provides the MOST secure configuration for the CRM portal?
-
A
Use AWS App Runner to run the containerized application instead to improve security and reduce operational overhead. Select VPC and security groups accordingly for deployment. Add IAM credentials to the environment variables when launching the service.
-
B
Use the
awsvpcnetwork mode in the task definition in your Amazon ECS Cluster. Attach security groups to the ECS tasks then pass IAM credentials into the container at launch time to access other AWS resources. -
C
Use the
bridgenetwork mode in the task definition in your Amazon ECS Cluster. Attach security groups to Amazon EC2 instances then use IAM roles for EC2 instances to access other resources. -
D
Use the
awsvpcnetwork mode in the task definition in your Amazon ECS Cluster. Attach security groups to the ECS tasks then use IAM roles for tasks to access other resources.
Xem giải thích
Đáp án
D — Dùng network mode awsvpc trong task definition của cụm ECS; gắn security group cho từng ECS task; và dùng IAM roles for tasks để truy cập tài nguyên khác.
Vì sao đúng
Đề nêu ba yêu cầu, và phương án này là phương án duy nhất thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Quyền tối thiểu | IAM role riêng cho từng task | | Security group ở CẤP CONTAINER | awsvpc cho mỗi task một ENI | | Công cụ giám sát mạng chuẩn ở cấp container | awsvpc — task có IP riêng, có Flow Logs |
⚠ awsvpc cho mỗi task một ENI riêng — đây là điều làm nên tất cả:
Network mode `bridge`: mọi container dùng chung
ENI của máy chủ EC2
→ security group áp cho CẢ MÁY
→ Flow Logs chỉ thấy IP của máy
↓
`awsvpc`: mỗi task có ENI và IP riêng trong VPC
→ security group riêng cho từng task
→ Flow Logs thấy từng task
Task definition:
{"family": "crm-dich-vu",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "1024", "memory": "2048",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"taskRoleArn": "arn:aws:iam::123456789012:role/VaiTroDichVuCRM",
"containerDefinitions": [{
"name": "crm",
"image": "<id>.dkr.ecr.ap-southeast-1.amazonaws.com/crm:1.0",
"portMappings": [{"containerPort": 8080}]}]}
⚠ Hai vai trò khác nhau — phải phân biệt: | Vai trò | Ai dùng | Việc | |---|---|---| | executionRoleArn | ECS agent | kéo image, lấy secret, ghi log | | taskRoleArn | mã trong container | gọi API AWS |
⚠ IAM roles for tasks là vế "quyền tối thiểu" của đề:
Dùng IAM role của EC2 instance:
→ MỌI container trên máy đó có CÙNG quyền
→ một microservice bị chiếm = truy cập được
mọi thứ mà máy được phép
↓
IAM role for tasks:
→ mỗi microservice một vai trò riêng
→ dịch vụ A không dùng được quyền của dịch vụ B
Ví dụ task role hẹp:
{"Effect": "Allow",
"Action": ["dynamodb:GetItem", "dynamodb:Query"],
"Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/KhachHang"}
⚠ Vì sao KHÔNG BAO GIỜ truyền IAM credential vào container:
Credential trong biến môi trường:
→ ai `docker inspect` cũng đọc được
→ nằm trong log, trong core dump
→ không tự hết hạn
↓
IAM role: credential tạm, tự xoay,
lấy qua endpoint metadata của task
Đây là lý do phương án B sai dù nó dùng đúng awsvpc.
Chạy service với security group riêng:
aws ecs create-service --cluster cum-crm \
--service-name dich-vu-crm \
--task-definition crm-dich-vu:1 --desired-count 3 \
--launch-type FARGATE \
--network-configuration 'awsvpcConfiguration={
subnets=[subnet-rieng-tu-a,subnet-rieng-tu-b],
securityGroups=[sg-crm],
assignPublicIp=DISABLED}'
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phân tách mạng tới từng dịch vụ | | | Phân quyền IAM tới từng dịch vụ | | | VPC Flow Logs thấy từng task | |
⚠ Và awsvpc là điều kiện bắt buộc của Fargate:
Fargate CHỈ hỗ trợ network mode `awsvpc`
→ không có lựa chọn nào khác
↓
Đây cũng là lý do Fargate an toàn hơn
ECS trên EC2 theo mặc định
Vì sao các phương án khác sai
- **B.
awsvpc+ security group cho task nhưng truyền IAM credential vào container — đây là phương án gần nhất và đúng ở vế mạng, nhưng nhúng credential là vi phạm nghiêm trọng nguyên tắc bảo mật: chúng không hết hạn, đọc được bằng nhiều cách, và không truy vết được ai dùng. - **C. Network mode
bridgevới security group gắn vào EC2 instance và IAM role cho EC2 — không đáp ứng yêu cầu "security group ở cấp container"; mọi container trên máy dùng chung cả security group lẫn quyền IAM. - **A. Dùng App Runner và thêm IAM credential vào biến môi trường — App Runner giảm công vận hành nhưng không cho kiểm soát security group ở cấp task như đề yêu cầu; và vẫn mắc lỗi nhúng credential.
Ghi nhớ
⚠ Bốn network mode của ECS — bảng phải thuộc: | Mode | IP riêng cho task | Security group riêng | Dùng với | |---|---|---|---| | awsvpc | ✅ | ✅ | Fargate (bắt buộc), EC2 | | bridge | ❌ dùng chung máy | ❌ | EC2 | | host | ❌ dùng mạng máy | ❌ | EC2 | | none | không có mạng | — | tác vụ cô lập |
⚠ awsvpc là mặc định đúng cho mọi thiết kế mới.
Từ khoá nhận diện:
"security groups at container level" →
awsvpc"least privilege for containers" → IAM roles for tasks "pull image, fetch secrets" → execution role "container calls DynamoDB/S3" → task role
Ba lưu ý về giới hạn ENI: | Lưu ý | Chi tiết | |---|---| | awsvpc trên EC2 tốn một ENI mỗi task | | | Mỗi loại instance có giới hạn ENI | | | Bật ENI trunking để tăng mật độ task | |
aws ecs put-account-setting --name awsvpcTrunking --value enabled
⚠ Không bật trunking thì mật độ task rất thấp:
m5.large: tối đa 3 ENI
→ trừ ENI của máy → chỉ 2 task
↓
Bật trunking → tới 10 task
Ba lưu ý về task role: | Lưu ý | Chi tiết | |---|---| | Credential lấy qua endpoint metadata của task | | | 169.254.170.2/v2/credentials/... | | | Tự động xoay, không cần làm gì | |
⚠ Chặn container truy cập metadata của INSTANCE:
Trên ECS EC2 với bridge mode
→ container gọi được 169.254.169.254
→ lấy được credential của INSTANCE
↓
`awsvpc` cô lập điều này
→ hoặc đặt hop limit = 1 cho IMDSv2
aws ec2 modify-instance-metadata-options \
--instance-id i-abc --http-tokens required \
--http-put-response-hop-limit 1
Ba lưu ý về security group cho task: | Lưu ý | Chi tiết | |---|---| | Tham chiếu SG của ALB cho chiều vào | | | Siết chiều ra chỉ tới thứ cần | | | Mỗi microservice một SG riêng | |
Ba lưu ý về giám sát mạng: | Công cụ | Việc | |---|---| | VPC Flow Logs | thấy IP của từng task | | Container Insights | metric CPU, bộ nhớ, mạng | | Service Connect / App Mesh | truy vết giữa dịch vụ |
⚠ Đây chính là "công cụ giám sát mạng chuẩn" mà đề nói:
Với bridge mode: Flow Logs chỉ thấy IP máy chủ
→ không biết container nào gây lưu lượng
↓
Với awsvpc: mỗi task một IP
→ công cụ mạng thông thường dùng được
Ba lưu ý về bảo mật container: | Lưu ý | Chi tiết | |---|---| | Không chạy container bằng root | | | Quét image bằng ECR scanning | | | Dùng image nền tối giản | |
{"user": "1000:1000",
"readonlyRootFilesystem": true,
"linuxParameters": {"capabilities": {"drop": ["ALL"]}}}
Ba lưu ý về secret: | Lưu ý | Chi tiết | |---|---| | Dùng secrets chứ không environment | | | Secrets Manager nếu cần xoay | | | Parameter Store nếu chỉ là cấu hình | |
Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Target type ip với awsvpc | | | Health check nhẹ, không chạm CSDL | | | Deregistration delay đủ dài | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | describe-tasks xem task có ENI riêng | | | Thử gọi API ngoài phạm vi task role | phải bị từ chối | | Xem Flow Logs có IP của task | |
aws ecs describe-tasks --cluster cum-crm --tasks <id> \
--query "tasks[0].attachments[0].details"
Và một lời khuyên: hãy cấp cho mỗi microservice một task role riêng ngay từ đầu. Dùng chung một vai trò cho cả cụm là quyết định rất khó đảo ngược khi số dịch vụ đã lớn, và nó biến mọi lỗ hổng ở một dịch vụ thành lối vào tới quyền của tất cả những dịch vụ còn lại.
A company is migrating an interactive car registration web system hosted on its on-premises network to AWS Cloud. The current architecture of the system consists of a single NGINX web server and a MySQL database running on a Fedora server, which both reside in their on-premises data center. For the new cloud architecture, a load balancer must be used to evenly distribute the incoming traffic to the application servers. Route 53 must be used for both domain registration and domain management.
In this scenario, what would be the most efficient way to transfer the web application to AWS?
-
A
1. Launch two NGINX EC2 instances in two Availability Zones.
2. Copy the web files from the on-premises web server to each Amazon EC2 web server, using Amazon S3 as the repository.
3. Migrate the database using the AWS Database Migration Service.
4. Create an ELB to front your web servers.
5. Use Route 53 and create an alias A record pointing to the ELB.
-
B
1. Use the AWS Application Migration Service (MGN) to create an EC2 AMI of the NGINX web server.
2. Configure auto-scaling to launch in two Availability Zones.
3. Launch a multi-AZ MySQL Amazon RDS instance in one availability zone only.
4. Import the data into Amazon RDS from the latest MySQL backup.
5. Create an ELB to front your web servers
6. Use Amazon Route 53 and create an A record pointing to the elastic load balancer.
-
C
1. Export web files to an Amazon S3 bucket in one Availability Zone using AWS Migration Hub.
2. Run the website directly out of Amazon S3.
3. Migrate the database using the AWS Database Migration Service and AWS Schema Conversion Tool (AWS SCT).
4. Use Route 53 and create an alias record pointing to the ELB.
-
D
1. Use the AWS Application Discovery Service to migrate the NGINX web server.
2. Configure Auto Scaling to launch two web servers in two Availability Zones.
3. Launch a Multi-AZ MySQL Amazon Relational Database Service (RDS) instance in one Availability Zone only.
4. Import the data into Amazon RDS from the latest MySQL backup.
5. Use Amazon Route 53 to create a private hosted zone and point a non-alias A record to the ELB.
Xem giải thích
Đáp án
A — Khởi chạy hai máy NGINX ở hai Availability Zone; chép tệp web từ máy chủ tại chỗ sang từng máy qua S3 làm kho trung gian; di chuyển CSDL bằng AWS DMS; tạo ELB trước các máy web; dùng Route 53 với bản ghi alias A trỏ tới ELB.
Vì sao đúng
Đề nêu ba yêu cầu, và phương án này thoả từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Load balancer phân phối đều lưu lượng | ELB trước hai máy NGINX | | Route 53 quản lý tên miền | bản ghi ALIAS A trỏ tới ELB | | Sẵn sàng cao | hai AZ cho cả web lẫn CSDL |
⚠ Bản ghi ALIAS là chi tiết quyết định:
Tên miền gốc (apex) như vidu.com
→ chuẩn DNS KHÔNG cho phép CNAME ở apex
↓
Route 53 giải quyết bằng ALIAS record
→ trỏ được tới ELB, CloudFront, S3 website
→ và MIỄN PHÍ truy vấn
Đây là lý do phương án B sai (dùng bản ghi A thường tới ELB — không làm được vì IP của ELB thay đổi) và D sai (dùng non-alias A trong private hosted zone).
Tạo bản ghi alias:
aws route53 change-resource-record-sets --hosted-zone-id <id> \
--change-batch '{"Changes":[{
"Action":"UPSERT",
"ResourceRecordSet":{
"Name":"dangky-xe.vidu.com","Type":"A",
"AliasTarget":{
"HostedZoneId":"<id-hosted-zone-cua-elb>",
"DNSName":"alb-web.ap-southeast-1.elb.amazonaws.com",
"EvaluateTargetHealth":true}}}]}'
⚠ Vì sao KHÔNG dùng bản ghi A thường tới ELB:
ELB có địa chỉ IP THAY ĐỔI
→ AWS thêm bớt node theo tải
↓
Bản ghi A cứng IP sẽ trỏ vào node đã biến mất
→ alias tự theo dõi thay đổi đó
Chuyển CSDL bằng DMS:
aws dms create-replication-task \
--replication-task-identifier chuyen-mysql \
--source-endpoint-arn <arn-mysql-tai-cho> \
--target-endpoint-arn <arn-rds> \
--replication-instance-arn <arn-may> \
--migration-type full-load-and-cdc \
--table-mappings file://anh-xa.json
⚠ full-load-and-cdc giảm thời gian ngừng xuống vài phút:
Full load: chép dữ liệu nền, ứng dụng vẫn chạy
↓
CDC: theo dõi thay đổi liên tục
↓
Cắt chuyển khi độ trễ về 0
Dùng S3 làm kho trung gian cho tệp web:
# Từ máy chủ tại chỗ
aws s3 sync /var/www/html s3://kho-tep-web/
# Trên mỗi máy EC2 (user data)
aws s3 sync s3://kho-tep-web/ /usr/share/nginx/html/
⚠ Vì sao qua S3 thay vì chép trực tiếp:
Chép trực tiếp: phải mở đường mạng giữa
tại chỗ và từng máy EC2
↓
Qua S3: một nơi đẩy lên, nhiều nơi kéo xuống
→ và máy mới do ASG tạo cũng lấy được
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hai AZ cho tầng web và tầng CSDL | | | Alias record miễn phí và tự theo ELB | | | DMS chuyển dữ liệu với ít gián đoạn | |
Ghi nhớ về chất lượng câu hỏi
⚠ Phương án B nhắc tới AWS Application Migration Service (MGN) — công cụ ĐÚNG cho việc di chuyển máy chủ.
MGN nhân bản toàn bộ máy chủ tại chỗ
→ dựng lại thành EC2 giống hệt
↓
Đây là cách chuẩn hiện nay để "lift and shift"
Nhưng B vẫn sai vì hai lỗi khác: | Lỗi trong B | Chi tiết | |---|---| | "Multi-AZ RDS in ONE availability zone only" | mâu thuẫn tự thân — Multi-AZ nghĩa là hai AZ | | Dùng bản ghi A (non-alias) tới ELB | không trỏ được vì IP của ELB thay đổi |
Cùng lỗi "Multi-AZ ở một AZ" xuất hiện ở cả B và D
→ đây là mô tả không tồn tại
Và cần nói rõ về "hiệu quả nhất":
Phương án A chép tệp THỦ CÔNG qua S3
→ với một máy chủ web đơn giản thì chấp nhận được
↓
Nhưng với hệ thống phức tạp, MGN tự động hơn nhiều
→ nếu gặp bài tương tự ngoài đời, cân nhắc MGN
cho tầng ứng dụng và DMS cho tầng dữ liệu
Vì sao các phương án khác sai
- **B. Dùng MGN tạo AMI, ASG hai AZ, nhưng "Multi-AZ RDS ở MỘT AZ" và bản ghi A thường tới ELB — xem phần trên: hai lỗi kỹ thuật rõ ràng.
- **D. Dùng Application Discovery Service để migrate — ADS chỉ khảo sát và lập danh mục hệ thống tại chỗ, nó không di chuyển gì; và dùng private hosted zone cho website công khai là sai.
- **C. Chạy website trực tiếp từ S3 — website này là ứng dụng động (đăng ký xe, tương tác); S3 chỉ phục vụ nội dung tĩnh. Và phương án tự mâu thuẫn: trỏ alias tới ELB trong khi không có ELB nào.
Ghi nhớ
⚠ Alias record vs CNAME vs A record — bảng phải thuộc: | Loại | Ở apex domain | Trỏ tới AWS service | Phí truy vấn | |---|---|---|---| | Alias | ✅ | ✅ tự theo IP | miễn phí | | CNAME | ❌ | ✅ | có phí | | A (thường) | ✅ | ❌ IP cố định | có phí |
⚠ Quy tắc: trỏ tới dịch vụ AWS thì LUÔN dùng alias.
Từ khoá nhận diện:
"domain apex pointing to ELB/CloudFront" → alias record "migrate servers to AWS" → Application Migration Service (MGN) "discover and inventory on-premises" → Application Discovery Service "migrate database" → DMS (+ SCT nếu đổi engine)
⚠ Bốn dịch vụ migrate hay bị lẫn: | Dịch vụ | Việc | |---|---| | Application Discovery Service | KHẢO SÁT, không di chuyển | | Application Migration Service (MGN) | DI CHUYỂN máy chủ | | Database Migration Service (DMS) | DI CHUYỂN CSDL | | DataSync | DI CHUYỂN dữ liệu tệp |
AWS Server Migration Service (SMS) đã NGỪNG
→ thay bằng MGN
→ đề cũ còn nhắc SMS, biết để nhận ra
Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Multi-AZ theo định nghĩa là NHIỀU AZ | | | "Multi-AZ ở một AZ" là mô tả vô nghĩa | | | Standby của RDS không phục vụ đọc | |
Ba lưu ý về ELB: | Lưu ý | Chi tiết | |---|---| | Cần subnet ở ít nhất 2 AZ | | | IP thay đổi — luôn dùng tên DNS | | | NLB có thể gán Elastic IP tĩnh | |
⚠ Nếu thật sự cần IP tĩnh:
ALB: KHÔNG có IP tĩnh
NLB: gán được Elastic IP cho mỗi AZ
Global Accelerator: 2 IP anycast tĩnh
Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | Cùng engine thì không cần SCT | | | Không chép index, khoá ngoại, trigger | | | Bật validation để so dữ liệu | |
Ba lưu ý về chuyển đổi cuối: | Bước | Chi tiết | |---|---| | Chờ độ trễ CDC về 0 | | | Dừng ghi ở nguồn | | | Đổi DNS, kiểm tra, mở lại ghi | |
⚠ Giảm TTL trước ngày chuyển:
TTL 3600 giây
→ client giữ IP cũ tới một giờ
↓
Giảm xuống 60 giây vài ngày trước
→ chuyển đổi nhanh hơn nhiều
Ba lưu ý về máy web: | Lưu ý | Chi tiết | |---|---| | Đưa vào ASG để tự phục hồi | | | User data kéo tệp từ S3 lúc khởi động | | | Hoặc dựng AMI đã có sẵn tệp | |
Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Hosted zone công khai cho tên miền Internet | | | Private hosted zone chỉ phân giải trong VPC | | | EvaluateTargetHealth cho alias | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig xác nhận trỏ đúng ELB | | | Tắt một AZ, xem còn phục vụ | | | So số dòng CSDL hai bên | |
Và một lời khuyên: hãy giảm TTL của bản ghi DNS xuống 60 giây vài ngày trước khi chuyển đổi. Đây là bước chuẩn bị rẻ nhất và có tác động lớn nhất tới thời gian gián đoạn — còn nếu quên, một phần khách hàng sẽ vẫn tới hệ thống cũ suốt cả giờ sau khi bạn đã cắt chuyển.
A company wants to implement a multi-account strategy that will be distributed across its several research facilities. There will be approximately 50 teams in total that will need their own AWS accounts. A solution is needed to simplify the DNS management as there is only one team that manages all the domains and subdomains for the whole organization. This means that the solution should allow private DNS to be shared among virtual private clouds (VPCs) in different AWS accounts.
Which of the following solutions has the LEAST complex DNS architecture and allows all VPCs to resolve the needed domain names?
-
A
Set up Direct Connect connections among the VPCs of each account using private virtual interfaces. Ensure that each VPC has the attributes
enableDnsHostnamesandenableDnsSupportset to “FALSE”. On Amazon Route 53, create a private hosted zone associated with the central account’s VPC. Manage all domains and subdomains on this hosted zone. Programmatically associate the VPCs from other accounts with this hosted zone. -
B
On AWS Resource Access Manager (RAM), set up a shared services VPC on your central account. Set up VPC peering from this VPC to each VPC on the other accounts. On Amazon Route 53, create a private hosted zone associated with the shared services VPC. Manage all domains and subdomains on this zone. Programmatically associate the VPCs from other accounts with this hosted zone.
-
C
Set up a VPC peering connection among the VPC of each account. Ensure that the each VPC has the attributes
enableDnsHostnamesandenableDnsSupportset to “TRUE”. On Amazon Route 53, create a private hosted zone associated with the central account’s VPC. Manage all domains and subdomains on this hosted zone. On each of the other AWS Accounts, create a Route 53 private hosted zone and configure the Name Server entry to use the DNS of the central account. -
D
On AWS Resource Access Manager (RAM), set up a shared services VPC on your central account. Create a peering from this VPC to each VPC on the other accounts. On Amazon Route 53, create a private hosted zone associated with the shared services VPC. Manage all domains and subdomains on this hosted zone. On each of the other AWS Accounts, create a Route 53 private hosted zone and configure the Name Server entry to use the DNS of the central account.
Xem giải thích
Đáp án
B — Dùng AWS RAM dựng một shared services VPC ở tài khoản trung tâm; peering từ VPC đó tới VPC của mỗi tài khoản; tạo private hosted zone gắn với shared services VPC và quản lý mọi tên miền ở đó; gắn (associate) VPC của các tài khoản khác vào hosted zone đó bằng chương trình.
Vì sao đúng
Đề nêu ba yêu cầu, và chi tiết quyết định nằm ở cách phân giải DNS: | Yêu cầu | Cách đáp ứng | |---|---| | ~50 tài khoản, mỗi đội một tài khoản | kiến trúc hình sao quanh VPC trung tâm | | MỘT đội quản lý toàn bộ DNS | một private hosted zone duy nhất | | KIẾN TRÚC DNS ÍT PHỨC TẠP NHẤT | gắn nhiều VPC vào cùng một hosted zone |
⚠ Private hosted zone gắn được với NHIỀU VPC, kể cả xuyên tài khoản:
Một hosted zone
→ associate VPC của tài khoản 1, 2, 3... 50
↓
Mọi VPC phân giải được cùng bộ tên miền
→ KHÔNG cần forwarder, KHÔNG cần Resolver rule
→ đây là kiến trúc DNS đơn giản nhất có thể
Đây chính là lý do B thắng — nó bỏ hẳn tầng chuyển tiếp DNS.
Gắn VPC xuyên tài khoản — quy trình hai bước:
# Bước 1: ở tài khoản SỞ HỮU hosted zone — tạo uỷ quyền
aws route53 create-vpc-association-authorization \
--hosted-zone-id <id-zone> \
--vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-doi-a
# Bước 2: ở tài khoản SỞ HỮU VPC — chấp nhận
aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id <id-zone> \
--vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-doi-a
⚠ Hai bước ở HAI tài khoản khác nhau — đây là chi tiết hay vấp:
Chỉ làm bước 1: chưa có tác dụng
Chỉ làm bước 2: bị từ chối vì chưa được uỷ quyền
↓
Với 50 tài khoản, viết script tự động hoá
→ đúng nghĩa "programmatically associate"
Rồi xoá uỷ quyền sau khi xong:
aws route53 delete-vpc-association-authorization \
--hosted-zone-id <id-zone> \
--vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-doi-a
⚠ Điều kiện bắt buộc để private hosted zone hoạt động: | Thuộc tính VPC | Giá trị | |---|---| | enableDnsHostnames | true | | enableDnsSupport | true |
Đặt `false` như phương án A đề xuất
→ VPC KHÔNG dùng được Route 53 Resolver
→ private hosted zone hoàn toàn vô dụng
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nơi quản lý mọi tên miền nội bộ | | | Không có forwarder hay Resolver rule nào | | | Thêm tài khoản mới chỉ là một lần associate | |
⚠ Vì sao "ít phức tạp nhất":
Cách khác: mỗi VPC một hosted zone riêng
+ Resolver rule chuyển tiếp qua lại
↓
50 tài khoản = 50 hosted zone + hàng trăm rule
→ không ai quản nổi
↓
Một hosted zone gắn 50 VPC: một nơi duy nhất
Vì sao các phương án khác sai
- **D. RAM + shared services VPC + peering + private hosted zone, nhưng ở mỗi tài khoản khác tạo Resolver rule chuyển tiếp — đây là phương án gần nhất và về kỹ thuật cũng chạy được, nhưng nó thêm hẳn một tầng: 50 Resolver endpoint và 50 rule phải quản lý, trong khi việc associate VPC bỏ được tất cả.
- **C. VPC peering và mỗi tài khoản tạo hosted zone riêng — nhiều hosted zone cho cùng một tên miền là nguồn sai lệch: đội DNS trung tâm không kiểm soát được, và bản ghi ở các nơi sẽ lệch nhau theo thời gian.
- **A. Direct Connect giữa các VPC và đặt
enableDnsHostnamescùngenableDnsSupportthànhFALSE— sai hai lần: Direct Connect nối tại chỗ với AWS, không nối VPC với VPC; và tắt hai thuộc tính DNS làm private hosted zone không hoạt động.
Ghi nhớ
⚠ Ba cách phân giải DNS riêng tư xuyên tài khoản — bảng phải thuộc: | Cách | Độ phức tạp | |---|---| | Associate nhiều VPC vào MỘT private hosted zone | thấp nhất | | Route 53 Resolver rule chia sẻ qua RAM | trung bình | | Mỗi VPC một hosted zone + forwarder | cao nhất |
⚠ Khi nào cần Resolver rule thay vì associate:
Associate VPC: dùng khi hosted zone nằm TRONG AWS
↓
Resolver rule: dùng khi cần chuyển tiếp tới
DNS server TẠI CHỖ
→ hoặc khi VPC ở Region khác cần
quy tắc chuyển tiếp phức tạp
Từ khoá nhận diện:
"share private DNS across accounts, least complex" → associate VPC vào private hosted zone "resolve on-premises names from VPC" → Resolver outbound endpoint + rule "resolve VPC names from on-premises" → Resolver inbound endpoint "share subnets across accounts" → RAM + VPC sharing
⚠ Hai loại Resolver endpoint: | Loại | Chiều | |---|---| | Inbound | tại chỗ → truy vấn vào VPC | | Outbound | VPC → truy vấn ra tại chỗ |
Ba lưu ý về private hosted zone: | Lưu ý | Chi tiết | |---|---| | Gắn được nhiều VPC, nhiều Region | | | VPC phải bật cả hai thuộc tính DNS | | | Một VPC gắn được nhiều hosted zone | |
⚠ Nhưng cẩn thận với tên miền chồng lấn:
VPC gắn hai hosted zone cùng tên miền
→ Route 53 chọn bản ghi CỤ THỂ NHẤT
↓
Dễ gây kết quả bất ngờ
→ giữ mỗi tên miền một hosted zone duy nhất
Ba lưu ý về VPC sharing (lựa chọn thay thế): | Lưu ý | Chi tiết | |---|---| | RAM chia sẻ SUBNET, không phải cả VPC | | | Mọi tài khoản chạy máy trong CÙNG VPC | | | Không cần peering, không cần DNS phức tạp | |
⚠ VPC sharing đơn giản hơn nữa nếu chấp nhận được:
aws ram create-resource-share \
--name chia-se-subnet \
--resource-arns arn:aws:ec2:ap-southeast-1:111111111111:subnet/subnet-abc \
--principals o-abc123def4
Mọi tài khoản dùng chung subnet
→ cùng một VPC → DNS tự nhiên hoạt động
↓
Đổi lại: ít cô lập mạng hơn
Ba lưu ý về peering ở quy mô 50 VPC: | Lưu ý | Chi tiết | |---|---| | Hình sao: 50 kết nối, không phải mesh | | | Peering KHÔNG bắc cầu | | | Cân nhắc Transit Gateway nếu cần bắc cầu | |
⚠ Với 50 VPC, Transit Gateway thường tốt hơn peering:
50 peering tới VPC trung tâm
→ 50 kết nối phải quản lý
→ và các đội không nói chuyện được với nhau
↓
Transit Gateway: 51 attachment, một bảng định tuyến
→ và bắc cầu được nếu cần
Ba lưu ý về CIDR: | Lưu ý | Chi tiết | |---|---| | 50 VPC phải KHÔNG chồng lấn | | | Lập kế hoạch dải IP toàn tổ chức từ đầu | | | AWS IPAM quản lý tập trung | |
aws ec2 create-ipam --operating-regions RegionName=ap-southeast-1
Ba lưu ý về tự động hoá: | Lưu ý | Chi tiết | |---|---| | Viết script cho quy trình associate hai bước | | | Đưa vào pipeline tạo tài khoản mới | | | CloudFormation hỗ trợ association | |
Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | VPC gắn mỗi hosted zone | 300 (tăng được) | | Bản ghi mỗi hosted zone | 10.000 | | Hosted zone mỗi tài khoản | 500 |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | nslookup từ máy trong VPC của đội | | | Kiểm tra danh sách VPC đã gắn | | | Xác nhận hai thuộc tính DNS đều true | |
aws route53 get-hosted-zone --id <id-zone> \
--query "VPCs[].[VPCId,VPCRegion]" --output table
Và một lời khuyên: hãy kiểm tra enableDnsSupport và enableDnsHostnames đều bật trước khi đi tìm nguyên nhân nào khác. Private hosted zone hoàn toàn im lặng khi hai thuộc tính này tắt — không có lỗi, không có cảnh báo, chỉ là mọi truy vấn trả về NXDOMAIN như thể bản ghi chưa từng tồn tại.
A company has recently adopted a hybrid cloud architecture which requires them to migrate their databases from their on-premises data center to AWS. One of their applications requires a heterogeneous database migration in which they need to transform their on-premises Oracle database to PostgreSQL. A schema and code transformation should be done first in order to successfully migrate the data.
Which of the following options is the most suitable approach to migrate the database in AWS?
-
A
Use the AWS Serverless Application Model (SAM) service to transform your database to PostgreSQL using AWS Lambda functions. Migrate the database to RDS using the AWS Database Migration Service (DMS).
-
B
Use a combination of AWS Data Pipeline service and CodeCommit to convert the source schema and code to match that of the target PostgreSQL database in RDS. Use AWS Batch with Spot EC2 instances to cost-effectively migrate the data from the source database to the target database in a batch process.
-
C
Migrate the database from your on-premises data center using the AWS Server Migration Service (SMS). Afterward, use the AWS Database Migration Service to convert and migrate your data to Amazon RDS for PostgreSQL database.
-
D
Use the AWS Schema Conversion Tool (SCT) to convert the source schema to match that of the target database. Migrate the data using the AWS Database Migration Service (DMS) from the source database to an Amazon RDS for PostgreSQL database.
Xem giải thích
Đáp án
D — Dùng AWS Schema Conversion Tool (SCT) chuyển lược đồ nguồn sang định dạng của CSDL đích, rồi dùng AWS DMS di chuyển dữ liệu sang Amazon RDS for PostgreSQL.
Vì sao đúng
Đề nêu một dữ kiện quyết định: di chuyển KHÔNG ĐỒNG NHẤT (heterogeneous) — Oracle sang PostgreSQL.
| Loại di chuyển | Công cụ cần |
|---|---|
| Đồng nhất (cùng engine) | chỉ DMS |
| KHÔNG đồng nhất (đổi engine) | SCT + DMS |
⚠ Đề nói rõ "schema and code transformation should be done FIRST":
Oracle và PostgreSQL khác nhau về:
→ kiểu dữ liệu (NUMBER vs NUMERIC)
→ cú pháp (PL/SQL vs PL/pgSQL)
→ hàm dựng sẵn (SYSDATE vs NOW())
→ sequence, trigger, package
↓
Phải chuyển đổi TRƯỚC khi chép dữ liệu
Chạy đánh giá trước:
SCT → New Project → chọn Oracle làm nguồn,
PostgreSQL làm đích
→ Assessment Report
↓
Báo cáo cho biết:
→ bao nhiêu % tự động chuyển được
→ đối tượng nào phải viết lại bằng tay
⚠ Đây là bước đầu tiên phải làm trong mọi dự án đổi engine:
Báo cáo đánh giá là dữ liệu để ước lượng công sức
→ package PL/SQL phức tạp thường không tự chuyển được
↓
Biết trước 20% phải viết tay thì lập kế hoạch được
→ không biết thì dự án trượt tiến độ
Chuyển dữ liệu bằng DMS:
aws dms create-replication-task \
--replication-task-identifier chuyen-oracle-pg \
--source-endpoint-arn <arn-oracle> \
--target-endpoint-arn <arn-postgres> \
--replication-instance-arn <arn-may> \
--migration-type full-load-and-cdc \
--table-mappings file://anh-xa.json
⚠ full-load-and-cdc giữ hai bên đồng bộ tới lúc cắt chuyển:
Full load: chép dữ liệu nền
↓
CDC: theo dõi thay đổi liên tục
↓
Cắt chuyển khi độ trễ về 0
→ thời gian ngừng chỉ vài phút
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | SCT tự chuyển phần lớn lược đồ và mã | | | DMS chép dữ liệu mà không cần dừng nguồn lâu | | | Bỏ được giấy phép Oracle | |
⚠ Điều kiện cho CDC với Oracle:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER TABLE ten_bang ADD SUPPLEMENTAL LOG DATA
(ALL) COLUMNS;
Không bật supplemental logging
→ DMS không đọc được thay đổi
→ CDC không hoạt động
Vì sao các phương án khác sai
- **C. Dùng Server Migration Service rồi DMS "chuyển đổi và di chuyển" — đây là phương án gần nhất về mặt cũng dùng DMS, nhưng SMS di chuyển MÁY ẢO, không phải CSDL (và SMS đã ngừng, thay bằng MGN); và DMS không chuyển đổi lược đồ — đó là việc của SCT.
- **A. Dùng SAM và Lambda để chuyển đổi CSDL — SAM là framework triển khai ứng dụng serverless; viết Lambda tự chuyển đổi lược đồ Oracle sang PostgreSQL là dựng lại SCT từ đầu.
- **B. Dùng Data Pipeline và CodeCommit chuyển đổi lược đồ, AWS Batch với Spot chép dữ liệu — CodeCommit là kho mã nguồn, không chuyển đổi gì; Data Pipeline đã ngừng nhận khách hàng mới; và tự viết job chép dữ liệu là bỏ qua DMS.
Ghi nhớ
⚠ SCT vs DMS — bảng phải thuộc: | Công cụ | Chuyển gì | |---|---| | SCT | LƯỢC ĐỒ, mã, thủ tục — khi ĐỔI ENGINE | | DMS | DỮ LIỆU — full load và CDC |
⚠ Quy tắc một câu:
Đổi engine → SCT + DMS
Cùng engine → chỉ DMS
Từ khoá nhận diện:
"heterogeneous migration, Oracle to PostgreSQL" → SCT + DMS "homogeneous, MySQL to RDS MySQL" → chỉ DMS "migrate servers/VMs" → MGN "discover on-premises inventory" → Application Discovery Service
Ba thứ DMS KHÔNG chép: | Thứ | Phải tự làm | |---|---| | Index phụ | tạo SAU khi full load | | Khoá ngoại, trigger | | | Stored procedure, view, package | SCT lo phần này |
⚠ Tạo index SAU full load là mẹo tăng tốc lớn:
Có index sẵn: mỗi dòng chèn phải cập nhật index
→ full load chậm nhiều lần
↓
Chép dữ liệu trước, tạo index sau
Ba loại đối tượng SCT xử lý: | Loại | Mức tự động | |---|---| | Bảng, kiểu dữ liệu | gần như 100% | | View, function đơn giản | cao | | Package PL/SQL phức tạp | thường phải viết tay |
⚠ Oracle-specific là chỗ khó nhất:
Package, autonomous transaction, DBMS_* built-in
→ PostgreSQL không có tương đương trực tiếp
↓
SCT gợi ý cách thay thế
→ nhưng người phải quyết định và kiểm thử
Ba lưu ý về Babelfish (lựa chọn khác cho SQL Server): | Lưu ý | Chi tiết | |---|---| | Aurora PostgreSQL hiểu T-SQL | | | Ứng dụng SQL Server chạy gần như không sửa | | | Chỉ cho SQL Server, không cho Oracle | |
Ba lưu ý về replication instance: | Lưu ý | Chi tiết | |---|---| | Quá nhỏ = nút thắt cổ chai | | | CDC cần bộ nhớ giữ giao dịch mở | | | Multi-AZ cho task chạy dài | |
Ba lưu ý về giám sát DMS: | Metric | Ý nghĩa | |---|---| | CDCLatencySource | đọc từ nguồn chậm bao lâu | | CDCLatencyTarget | ghi vào đích chậm bao lâu | | FullLoadThroughputRowsTarget | tốc độ chép |
⚠ Theo dõi cả dung lượng đĩa của Oracle nguồn:
DMS đọc archive log để lấy thay đổi
→ task dừng thì log không được dọn
↓
Đĩa nguồn đầy → CSDL SẢN XUẤT ngừng
Ba lưu ý về validation: | Lưu ý | Chi tiết | |---|---| | Bật EnableValidation trong task settings | | | DMS tự so từng dòng | | | Báo cáo dòng nào lệch | |
{"ValidationSettings": {
"EnableValidation": true,
"ValidationMode": "ROW_LEVEL",
"ThreadCount": 5}}
Ba lưu ý về kiểm thử ứng dụng: | Lưu ý | Chi tiết | |---|---| | SQL của ứng dụng cũng phải sửa | | | Hàm và cú pháp khác nhau | | | Chạy song song hai CSDL để so kết quả | |
⚠ Chuyển lược đồ chỉ là một nửa công việc:
SCT chuyển CSDL
→ nhưng câu SQL trong MÃ ỨNG DỤNG thì không
↓
ROWNUM, CONNECT BY, NVL, DECODE...
→ phải rà và sửa trong ứng dụng
Ba lưu ý về cắt chuyển: | Bước | Chi tiết | |---|---| | Chờ độ trễ CDC về 0 | | | Dừng ghi ở nguồn | | | Kiểm chứng rồi mới mở lại ghi ở đích | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy Assessment Report của SCT | | | So số dòng từng bảng | | | Chạy bộ test hồi quy của ứng dụng | |
Và một lời khuyên: hãy chạy Assessment Report của SCT trước khi cam kết tiến độ với bất kỳ ai. Nó cho biết chính xác bao nhiêu phần trăm lược đồ tự chuyển được và bao nhiêu phải viết tay — và con số đó thường là thứ quyết định dự án mất một tháng hay sáu tháng.
A fintech startup has developed a cloud-based payment processing system that accepts credit card payments as well as cryptocurrencies such as Bitcoin, Ripple, and the likes. The system is deployed in AWS which uses EC2, DynamoDB, S3, and CloudFront to process the payments. Since they are accepting credit card information from the users, they are required to be compliant with the Payment Card Industry Data Security Standard (PCI DSS). On the recent 3rd-party audit, it was found that the credit card numbers are not properly encrypted and hence, their system failed the PCI DSS compliance test. You were hired by the fintech startup to solve this issue so they can release the product in the market as soon as possible. In addition, you also have to improve performance by increasing the proportion of your viewer requests that are served from CloudFront edge caches instead of going to your origin servers for content.
In this scenario, what is the best option to protect and encrypt the sensitive credit card information of the users and to improve the cache hit ratio of your CloudFront distribution?
-
A
Add a custom SSL in the CloudFront distribution. Configure your origin to add
User-AgentandHostheaders to your objects to increase your cache hit ratio. -
B
Create an origin access control (OAC) and add it to the CloudFront distribution. Configure your origin to add
User-AgentandHostheaders to your objects to increase your cache hit ratio. -
C
Configure the CloudFront distribution to use Signed URLs. Configure your origin to add a
Cache-Control max-agedirective to your objects, and specify the longest practical value formax-ageto increase your cache hit ratio. -
D
Configure the CloudFront distribution to enforce secure end-to-end connections to origin servers by using HTTPS and field-level encryption. Configure your origin to add a
Cache-Control max-agedirective to your objects, and specify the longest practical value formax-ageto increase your cache hit ratio.
Xem giải thích
Đáp án
D — Cấu hình CloudFront ép kết nối HTTPS end-to-end tới origin và bật field-level encryption; cấu hình origin thêm chỉ thị Cache-Control max-age với giá trị dài nhất có thể để tăng tỷ lệ trúng cache.
Vì sao đúng
Đề nêu hai yêu cầu tách bạch, và phương án này giải quyết cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Mã hoá số thẻ tín dụng cho PCI DSS | field-level encryption | | Tăng tỷ lệ trúng cache | Cache-Control max-age dài |
⚠ Field-level encryption là tính năng sinh ra đúng cho bài toán này:
HTTPS mã hoá dữ liệu TRÊN ĐƯỜNG TRUYỀN
→ CloudFront giải mã ở edge
→ gửi tiếp tới origin
↓
Số thẻ nằm dạng THÔ ở mọi tầng sau edge:
load balancer, log ứng dụng, máy chủ web
↓
Field-level encryption: mã hoá RIÊNG trường nhạy cảm
→ bằng khoá công khai của bạn
→ chỉ ứng dụng có khoá riêng mới giải được
Cấu hình:
aws cloudfront create-public-key --public-key-config '{
"CallerReference":"khoa-the-2026",
"Name":"khoa-ma-hoa-truong",
"EncodedKey":"-----BEGIN PUBLIC KEY-----\n..."}'
aws cloudfront create-field-level-encryption-profile \
--field-level-encryption-profile-config '{
"Name":"ho-so-the-tin-dung",
"CallerReference":"hs-2026",
"EncryptionEntities":{"Quantity":1,"Items":[{
"PublicKeyId":"<id-khoa>",
"ProviderId":"nha-cung-cap-thanh-toan",
"FieldPatterns":{"Quantity":2,
"Items":["so-the","cvv"]}}]}}'
⚠ Chuỗi bảo vệ đầy đủ:
Trình duyệt gửi form có trường `so-the`
→ CloudFront edge MÃ HOÁ trường đó
bằng khoá công khai
↓
ALB, máy chủ web, log ứng dụng
→ chỉ thấy chuỗi đã mã hoá
↓
Chỉ dịch vụ thanh toán có khoá riêng
mới giải mã được
⚠ Đây chính là điều PCI DSS đòi hỏi:
Giảm phạm vi PCI: càng ít hệ thống chạm
dữ liệu thẻ thô thì càng ít hệ thống
phải chứng nhận
↓
Field-level encryption thu hẹp phạm vi
xuống đúng thành phần có khoá riêng
Vế thứ hai — tăng tỷ lệ trúng cache:
# Origin trả về header
Cache-Control: public, max-age=31536000, immutable
⚠ Vì sao Cache-Control ở ORIGIN hiệu quả hơn đặt TTL ở CloudFront:
TTL của CloudFront: áp cho mọi object cùng behavior
↓
Cache-Control từ origin: đặt riêng cho từng object
→ tệp có hash trong tên → max-age một năm
→ HTML → max-age ngắn
↓
Kiểm soát chi tiết hơn nhiều
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dữ liệu thẻ mã hoá suốt chặng sau edge | | | Giảm phạm vi tuân thủ PCI | | | Tỷ lệ trúng cache cao, origin nhẹ tải | |
Vì sao các phương án khác sai
- **C. Dùng signed URL và đặt
Cache-Control max-agedài — đây là phương án gần nhất và vế cache hoàn toàn đúng, nhưng signed URL kiểm soát AI được truy cập nội dung, nó không mã hoá dữ liệu người dùng gửi lên; số thẻ vẫn tới origin dạng thô. - **B. Dùng OAC và thêm header
User-AgentvàHostvào cache key — OAC chặn truy cập thẳng vào S3, không liên quan tới mã hoá trường; và thêm header vào cache key LÀM GIẢM tỷ lệ trúng cache vì mỗi biến thể header thành một bản cache riêng. - **A. Thêm SSL tuỳ chỉnh và thêm
User-Agent,Hostvào object — SSL chỉ mã hoá đường truyền, không bảo vệ dữ liệu ở origin; và vế cache lại làm giảm hiệu quả.
Ghi nhớ
⚠ Bốn cơ chế bảo mật của CloudFront — bảng phải thuộc: | Cơ chế | Bảo vệ gì | |---|---| | HTTPS / TLS | dữ liệu TRÊN ĐƯỜNG TRUYỀN | | Field-level encryption | trường nhạy cảm SAU khi tới edge | | Signed URL / cookie | AI được TRUY CẬP nội dung | | OAC | chặn truy cập thẳng vào origin |
⚠ Bốn cái này giải bốn bài toán khác nhau — đừng nhầm.
Từ khoá nhận diện:
"protect credit card data through the stack, PCI" → field-level encryption "restrict who can view content" → signed URL/cookie "prevent direct S3 access" → OAC "increase cache hit ratio" →
Cache-Control max-agedài
⚠ Ba yếu tố quyết định tỷ lệ trúng cache: | Yếu tố | Ảnh hưởng | |---|---| | max-age dài | tăng mạnh | | Cache key ÍT thành phần | tăng mạnh | | Header, cookie, query string trong cache key | GIẢM mạnh |
⚠ Đây là chỗ phương án A và B sai:
Thêm `User-Agent` vào cache key
→ mỗi trình duyệt, mỗi phiên bản
= một bản cache riêng
↓
Hàng nghìn biến thể cho cùng một object
→ tỷ lệ trúng cache sụp đổ
Ba cách tăng tỷ lệ trúng cache: | Cách | Chi tiết | |---|---| | Bỏ header không cần khỏi cache key | | | Chuẩn hoá query string | | | Dùng CachingOptimized policy | |
aws cloudfront create-cache-policy --cache-policy-config '{
"Name":"cache-toi-uu",
"DefaultTTL":86400,"MaxTTL":31536000,"MinTTL":1,
"ParametersInCacheKeyAndForwardedToOrigin":{
"EnableAcceptEncodingGzip":true,
"HeadersConfig":{"HeaderBehavior":"none"},
"CookiesConfig":{"CookieBehavior":"none"},
"QueryStringsConfig":{"QueryStringBehavior":"none"}}}'
⚠ Nhưng cẩn thận: bỏ hết cookie có thể làm hỏng ứng dụng:
Tách cache behavior theo đường dẫn
→ /tinh/* : không forward gì, cache dài
→ /api/* : forward đủ, không cache
Ba lưu ý về field-level encryption: | Lưu ý | Chi tiết | |---|---| | Chỉ áp cho POST và PUT có application/x-www-form-urlencoded | | | Tối đa 10 trường mỗi profile | | | Dùng RSA-OAEP 2048-bit | |
⚠ Giới hạn về content type là ràng buộc thật:
Form gửi JSON
→ field-level encryption KHÔNG áp dụng
↓
Phải mã hoá ở phía client
→ hoặc dùng CloudFront Functions/Lambda@Edge
Ba lưu ý về quản lý khoá: | Lưu ý | Chi tiết | |---|---| | Khoá công khai nạp vào CloudFront | | | Khoá riêng lưu ở Secrets Manager hoặc KMS | | | Xoay khoá định kỳ | |
Ba lưu ý về giảm phạm vi PCI: | Cách | Chi tiết | |---|---| | Field-level encryption | | | Tokenization ở cổng thanh toán | | | Không bao giờ lưu số thẻ | |
⚠ Cách an toàn nhất là không chạm vào số thẻ:
Dùng iframe hoặc SDK của cổng thanh toán
→ số thẻ đi thẳng từ trình duyệt tới họ
↓
Hệ thống của bạn chỉ nhận token
→ phạm vi PCI gần như bằng không
Ba lưu ý về log: | Lưu ý | Chi tiết | |---|---| | Log ứng dụng KHÔNG được chứa số thẻ | | | Che PII trong CloudFront access log | | | Rà log định kỳ tìm dữ liệu lọt ra | |
Ba lưu ý về mã hoá tới origin: | Lưu ý | Chi tiết | |---|---| | OriginProtocolPolicy: https-only | | | ViewerProtocolPolicy: redirect-to-https | | | Chứng chỉ origin phải hợp lệ | |
Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | CacheHitRate | mục tiêu trên 90% cho nội dung tĩnh | | OriginLatency | | | 4xxErrorRate | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi form thử, kiểm origin nhận chuỗi mã hoá | | | Đo CacheHitRate trước và sau | | | Kiểm tra header Cache-Control từ origin | |
Và một lời khuyên: hãy rà lại cache key trước khi tìm cách khác để tăng tỷ lệ trúng cache. Một header thừa trong cache key có thể nhân số bản cache lên hàng nghìn lần, và đó gần như luôn là nguyên nhân thật khi tỷ lệ trúng cache thấp một cách khó hiểu.
A logistics company plans to host its web application on AWS to allow customers to track their shipping worldwide. The web application will have a multi-tier setup – Amazon EC2 instances for running the web and application layer, Amazon S3 bucket for hosting the static content, and a NoSQL database. The company plans to provision the resources in the us-east-1 region. The company also wants to have a second site hosted on us-west-1 region for disaster recovery. The second site must have the same copy of data from the primary site and the failover should be as quick as possible when the primary region becomes unavailable. Failing back to the primary region should be done automatically once it becomes available again.
Which of the following solutions should the Solutions Architect implement to meet the company requirements?
-
A
Create the same resources of Auto Scaling group of EC2 instances for web and application tiers on both regions using AWS CloudFormation StackSets. Enable Amazon S3 cross-Region on the S3 bucket to asynchronously replicate the contents to the secondary region. Create Amazon Route 53 DNS zone entries with a failover routing policy and set the us-west-1 region as the secondary site. For the database tier, create a DynamoDB global table spanning both regions.
-
B
Provision the same Auto Scaling group of EC2 instances for web and application tiers in both regions using AWS Service Catalog. Enable Amazon S3 cross-Region on the S3 bucket to asynchronously replicate the contents to the secondary region. Ensure that Amazon Route 53 health check is enabled on the primary region and update the public DNS zone entry with the secondary region in case of an outage. For the database tier, create an Amazon RDS for MySQL and enable cross-region replication to create a read-replica on the secondary region.
-
C
Create the same resources of Auto Scaling group of EC2 instances for web and application tiers on both regions using AWS CloudFormation StackSets. Enable Amazon S3 cross-Region on the S3 bucket to asynchronously replicate the contents to the secondary region. Create Amazon Route 53 DNS zone entries with a failover routing policy and set the us-west-1 region as the secondary site. For the database tier, create an Amazon Aurora global database spanning the two regions.
-
D
Create the same resources of Auto Scaling group of EC2 instances for web and application tiers on both regions using AWS CloudFormation StackSets. Enable Amazon S3 cross-Region on the S3 bucket to asynchronously replicate the contents to the secondary region. Create an Amazon CloudFront distribution. Set the S3 bucket as the origin for static files and multi-origins for the web and application tiers. For the database tier, create an Amazon DynamoDB table in each region and regularly backup to an Amazon S3 bucket.
Xem giải thích
Đáp án
A — Dựng cùng bộ tài nguyên (ASG cho tầng web và tầng ứng dụng) ở cả hai Region bằng CloudFormation StackSets; bật S3 Cross-Region Replication; tạo bản ghi Route 53 với failover routing, đặt us-west-1 là site phụ; và cho tầng dữ liệu dùng DynamoDB Global Table trải cả hai Region.
Vì sao đúng
Đề nêu bốn yêu cầu, và chi tiết quyết định nằm ở loại CSDL: | Yêu cầu | Cách đáp ứng | |---|---| | Dùng CSDL NoSQL | DynamoDB — đề nói rõ "a NoSQL database" | | Site phụ có cùng dữ liệu | Global Table nhân bản liên tục | | Chuyển vùng NHANH NHẤT | Global Table active-active, không cần promote | | TỰ ĐỘNG chuyển về khi vùng chính hồi phục | failover routing + health check |
⚠ "NoSQL database" loại ngay phương án C (Aurora):
Aurora là CSDL QUAN HỆ
→ đề nói rõ tầng dữ liệu là NoSQL
↓
Và Aurora Global Database có MỘT writer
→ phải promote thủ công khi chuyển vùng
→ chậm hơn Global Table
⚠ Vì sao Global Table cho chuyển vùng nhanh nhất:
Aurora Global: vùng phụ CHỈ ĐỌC
→ phải promote mới ghi được
→ thêm một bước trong quy trình chuyển vùng
↓
DynamoDB Global Table: MỌI Region đều GHI được
→ chuyển lưu lượng sang là dùng được ngay
→ không có bước nào phải làm
Và tự động chuyển về (failback):
Vùng chính hồi phục
→ health check của Route 53 thấy khoẻ lại
→ tự chuyển lưu lượng về bản ghi PRIMARY
↓
Dữ liệu ghi ở vùng phụ trong lúc sự cố
đã được nhân bản ngược lại
→ không mất gì, không phải làm gì
⚠ Đây là điều Aurora Global KHÔNG làm tự động được:
Sau khi promote vùng phụ thành writer
→ vùng cũ phải được dựng lại làm phụ
↓
Quy trình thủ công, không tự động
Dựng bằng StackSets:
aws cloudformation create-stack-set \
--stack-set-name ha-tang-ung-dung \
--template-body file://mau.yaml \
--capabilities CAPABILITY_IAM
aws cloudformation create-stack-instances \
--stack-set-name ha-tang-ung-dung \
--accounts 123456789012 \
--regions us-east-1 us-west-1
Global Table:
aws dynamodb update-table --table-name TheoDoiVanChuyen \
--replica-updates '[{"Create":{"RegionName":"us-west-1"}}]' \
--region us-east-1
Failover routing:
aws route53 change-resource-record-sets --hosted-zone-id <id> \
--change-batch '{"Changes":[
{"Action":"UPSERT","ResourceRecordSet":{
"Name":"theo-doi.vidu.com","Type":"A",
"SetIdentifier":"chinh","Failover":"PRIMARY",
"HealthCheckId":"<id-health-check>",
"AliasTarget":{"HostedZoneId":"<id-alb-dong>",
"DNSName":"alb-dong.us-east-1.elb.amazonaws.com",
"EvaluateTargetHealth":true}}},
{"Action":"UPSERT","ResourceRecordSet":{
"Name":"theo-doi.vidu.com","Type":"A",
"SetIdentifier":"phu","Failover":"SECONDARY",
"AliasTarget":{"HostedZoneId":"<id-alb-tay>",
"DNSName":"alb-tay.us-west-1.elb.amazonaws.com",
"EvaluateTargetHealth":true}}}]}'
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RPO gần bằng 0 với Global Table | | | Chuyển vùng và chuyển về đều tự động | | | StackSets giữ hai Region giống nhau | |
Vì sao các phương án khác sai
- **C. StackSets + S3 CRR + failover routing nhưng dùng Aurora Global Database — đây là phương án gần nhất và chỉ khác đúng một chi tiết, nhưng đề nói rõ tầng dữ liệu là NoSQL; và Aurora Global cần promote thủ công nên chuyển vùng chậm hơn, chuyển về càng phức tạp hơn.
- **B. Dùng Service Catalog để cấp phát và cập nhật bản ghi DNS thủ công khi có sự cố — cập nhật thủ công là ngược với "failover nhanh nhất có thể"; và RDS MySQL read replica xuyên vùng cũng phải promote thủ công.
- **D. StackSets + CloudFront với nhiều origin và DynamoDB riêng mỗi Region sao lưu định kỳ sang S3 — hai bảng DynamoDB độc lập không đồng bộ dữ liệu; sao lưu định kỳ ra S3 cho RPO tính bằng giờ, không phải "cùng bản sao dữ liệu".
Ghi nhớ
⚠ Nhân bản dữ liệu xuyên Region — bảng phải thuộc: | Dịch vụ | Ghi ở nhiều Region | Chuyển vùng | |---|---|---| | DynamoDB Global Tables | ✅ active-active | không cần làm gì | | Aurora Global Database | ❌ một writer | phải promote | | S3 CRR | ✅ hai chiều được | không áp dụng | | RDS cross-region replica | ❌ | phải promote |
⚠ Đây là bảng quyết định cho mọi câu hỏi đa Region.
Từ khoá nhận diện:
"NoSQL, fastest failover, automatic failback" → DynamoDB Global Tables "relational, multi-Region DR" → Aurora Global Database "deploy same stack to many Regions/accounts" → CloudFormation StackSets "replicate S3 objects" → Cross-Region Replication
Ba lưu ý về failover routing: | Lưu ý | Chi tiết | |---|---| | Cần health check cho bản ghi PRIMARY | | | EvaluateTargetHealth cho alias | | | Tự chuyển về khi primary khoẻ lại | |
⚠ Chuyển về tự động là đặc tính của failover routing:
Health check của primary xanh trở lại
→ Route 53 tự trả về bản ghi primary
↓
Đây chính là "failing back automatically"
mà đề yêu cầu
Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp = chuyển nhanh hơn | | | 60 giây là mức thường dùng | | | TTL cao làm RTO thực tế dài hơn | |
Ba lưu ý về CloudFormation StackSets: | Lưu ý | Chi tiết | |---|---| | Triển khai cùng mẫu tới nhiều Region/tài khoản | | | Tham số hoá thứ khác nhau (AMI ID, CIDR) | | | Cập nhật đồng loạt hoặc theo đợt | |
⚠ AMI ID khác nhau giữa các Region — phải map:
Mappings:
AmiTheoVung:
us-east-1: {Ami: ami-abc}
us-west-1: {Ami: ami-def}
Resources:
MauKhoiChay:
Properties:
ImageId: !FindInMap [AmiTheoVung, !Ref "AWS::Region", Ami]
Ba lưu ý về Global Tables: | Lưu ý | Chi tiết | |---|---| | Cần bật Streams NEW_AND_OLD_IMAGES | | | Giải quyết xung đột "last writer wins" | | | Ghi tính bằng rWCU — đắt hơn | |
⚠ Thiết kế khoá để tránh xung đột:
Nhúng mã Region vào khoá chính
→ hai Region không bao giờ ghi cùng một item
↓
Không có xung đột để giải quyết
Ba lưu ý về S3 CRR: | Lưu ý | Chi tiết | |---|---| | Versioning bật ở CẢ HAI bucket | | | Chỉ nhân bản object MỚI | | | Batch Replication cho object cũ | |
Ba thứ phải chuẩn bị ở Region phụ: | Thứ | Hậu quả nếu quên | |---|---| | AMI đã copy | ASG không khởi động nổi | | Chứng chỉ ACM | HTTPS hỏng | | Hạn ngạch tài khoản | không mở rộng đủ |
⚠ Và kiểm tra Region phụ gánh nổi 100% tải:
Region phụ chạy ở quy mô nhỏ để tiết kiệm
→ khi chuyển vùng phải gánh toàn bộ
↓
ASG phải mở rộng kịp
→ và quota phải đủ
Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Rút Region chính khỏi lưu lượng định kỳ | | | Đo RTO thật của toàn kiến trúc | | | Kiểm tra chuyển về hoạt động | |
Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Hạ tầng đầy đủ ở cả hai Region | | | rWCU của Global Table | | | Phí truyền dữ liệu xuyên Region | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi ở Region A, đọc ở Region B | | | Tắt health check, xem chuyển vùng | | | Bật lại, xem chuyển về tự động | |
Và một lời khuyên: hãy đọc kỹ loại cơ sở dữ liệu mà đề mô tả. Hai phương án chỉ khác nhau ở chỗ dùng DynamoDB hay Aurora, và từ "NoSQL" trong một câu duy nhất của đề là toàn bộ căn cứ để phân biệt — cũng như trong thực tế, nó quyết định bạn có phải promote thủ công khi sự cố xảy ra hay không.
Four large banks in the country have collaborated to create a secure, simple-to-use, mobile payment app that enables users to easily transfer money and pay bills without much hassle. With the new mobile payment app, anyone can easily pay another person, split the bill with their friends, or pay for their coffee in an instant with just a few taps in the app. The payment app is available on both Android and iOS devices, including a web portal that is deployed in AWS using OpsWorks Stacks and EC2 instances. It was a big success with over 5 million users nationwide and has over 1000 transactions every hour. After one year, a new feature that will enable the users to store their credit card information in the app is ready to be added to the existing web portal. However, due to PCI-DSS compliance, the new version of the APIs and web portal cannot be deployed to the existing application stack.
How would the solutions architect deploy the new web portal for the mobile app without having any impact on 5 million users?
- A Deploy the new web portal using a Blue/Green deployment strategy with AWS CodeDeploy and Lambda in which the green environment represents the current web portal version serving production traffic while the blue environment is staged in running a different version of the web portal.
- B Create a new stack that contains the latest version of the web portal. Using Route 53 service, direct all the incoming traffic to the new stack at once so that all the customers get to access new features.
- C Deploy a new OpsWorks stack that contains a new layer with the latest web portal version. Shift traffic between existing stack and new stack, running different versions of the web portal using Blue/Green deployment strategy by using Route53. Route only a small portion of incoming production traffic to use the new application stack while maintaining the old application stack. Check the features of the new portal; once it's 100% validated, slowly increase incoming production traffic to the new stack. If there are issues on the new stack, change Route53 to revert to old stack.
- D Forcibly upgrade the existing application stack in Production to be PCI-DSS compliant. Once done, deploy the new version of the web portal on the existing application stack.
Xem giải thích
Đáp án
C — Triển khai một OpsWorks stack MỚI chứa layer với phiên bản web portal mới; chuyển dần lưu lượng giữa stack cũ và stack mới theo chiến lược blue/green bằng Route 53, ban đầu chỉ định tuyến một phần nhỏ lưu lượng sản xuất sang stack mới.
Vì sao đúng
Đề nêu ba ràng buộc, và phương án này thoả cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | PCI-DSS: KHÔNG triển khai lên stack hiện có | stack hoàn toàn mới, tách biệt | | 5 triệu người dùng không bị ảnh hưởng | chuyển dần từng phần nhỏ | | Có đường lùi | stack cũ vẫn chạy nguyên |
⚠ Yêu cầu PCI-DSS là ràng buộc CỨNG, không phải khuyến nghị:
Tính năng lưu số thẻ đưa hệ thống vào
phạm vi PCI-DSS
↓
Stack hiện tại chưa được chứng nhận
→ KHÔNG được triển khai mã xử lý thẻ lên đó
↓
Phải có môi trường mới, được chứng nhận riêng
Blue/green bằng Route 53 weighted routing:
aws route53 change-resource-record-sets --hosted-zone-id <id> \
--change-batch '{"Changes":[
{"Action":"UPSERT","ResourceRecordSet":{
"Name":"cong.vidu.com","Type":"A",
"SetIdentifier":"stack-cu","Weight":95,
"AliasTarget":{"HostedZoneId":"<id-elb-cu>",
"DNSName":"elb-cu.ap-southeast-1.elb.amazonaws.com",
"EvaluateTargetHealth":true}}},
{"Action":"UPSERT","ResourceRecordSet":{
"Name":"cong.vidu.com","Type":"A",
"SetIdentifier":"stack-moi","Weight":5,
"AliasTarget":{"HostedZoneId":"<id-elb-moi>",
"DNSName":"elb-moi.ap-southeast-1.elb.amazonaws.com",
"EvaluateTargetHealth":true}}}]}'
⚠ Tăng dần trọng số theo dõi kết quả:
5% → theo dõi lỗi và độ trễ vài giờ
→ 25% → 50% → 100%
↓
Có vấn đề: đặt trọng số stack mới về 0
→ quay lui trong một lệnh
⚠ Và quay lui nhanh là lý do chọn blue/green thay vì triển khai tại chỗ:
Triển khai tại chỗ: quay lui = triển khai lại bản cũ
→ mất thời gian, và có thể không sạch
↓
Blue/green: stack cũ VẪN ĐANG CHẠY
→ quay lui = đổi một con số trong DNS
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hai môi trường tách biệt hoàn toàn | | | Phạm vi PCI chỉ gồm stack mới | | | Quay lui gần như tức thì | |
⚠ Nhược điểm phải biết — DNS phụ thuộc TTL:
Đổi trọng số DNS
→ client đã cache bản ghi cũ vẫn giữ trong TTL
↓
Giảm TTL xuống 60 giây trước khi bắt đầu
→ và chấp nhận rằng chuyển đổi không tức thì
Ghi nhớ về chất lượng câu hỏi
⚠ AWS OpsWorks Stacks đã KẾT THÚC VÒNG ĐỜI (26/05/2024).
| Dịch vụ | Trạng thái |
|---|---|
| OpsWorks Stacks | đã ngừng |
| OpsWorks for Chef Automate | đã ngừng |
| OpsWorks for Puppet Enterprise | đã ngừng |
Câu hỏi này viết khi OpsWorks còn hoạt động
→ nguyên tắc blue/green vẫn hoàn toàn đúng
↓
Nhưng nếu gặp bài toán này hôm nay:
→ ECS/EKS với CodeDeploy blue/green
→ hoặc Elastic Beanstalk swap URL
→ hoặc ASG với hai target group
Cách làm hiện đại tương đương:
# CodeDeploy blue/green cho ECS
aws deploy create-deployment \
--application-name ung-dung-cong \
--deployment-group-name nhom-blue-green \
--revision file://appspec.json
CodeDeploy dựng task set mới
→ chuyển target group của ALB sang
→ quay lui bằng cách chuyển ngược
↓
Nhanh hơn DNS vì không phụ thuộc TTL
⚠ Và cách hiện đại nhất cho tình huống PCI:
Tách hẳn dịch vụ xử lý thẻ thành microservice riêng
→ chạy trong tài khoản AWS RIÊNG
→ chỉ tài khoản đó nằm trong phạm vi PCI
↓
Phần còn lại của hệ thống không phải chứng nhận
Vì sao các phương án khác sai
- **A. Blue/green bằng CodeDeploy và Lambda, trong đó "green là bản đang chạy sản xuất" — đây là phương án gần nhất và dùng đúng khái niệm blue/green, nhưng nó đảo ngược quy ước: theo chuẩn, blue là môi trường đang phục vụ, green là môi trường mới. Và ứng dụng chạy trên OpsWorks/EC2, không phải Lambda.
- **B. Tạo stack mới rồi chuyển TOÀN BỘ lưu lượng một lúc — 5 triệu người dùng chuyển sang phiên bản chưa được kiểm chứng trong sản xuất là rủi ro không cần thiết; đề nói rõ phải "không có tác động".
- **D. Nâng cấp cưỡng bức stack sản xuất hiện tại cho tuân thủ PCI-DSS rồi triển khai lên đó — vi phạm thẳng ràng buộc của đề: không được triển khai lên stack hiện có.
Ghi nhớ
⚠ Bốn chiến lược triển khai — bảng phải thuộc: | Chiến lược | Cách hoạt động | Quay lui | |---|---|---| | Blue/Green | hai môi trường, chuyển toàn bộ | tức thì | | Canary | tỷ lệ nhỏ trước, tăng dần | tức thì | | Rolling | thay thế từng đợt máy | chậm | | All-at-once | thay hết ngay | phải triển khai lại |
⚠ Đề mô tả một biến thể lai:
Hai môi trường tách biệt (blue/green)
+ chuyển dần theo tỷ lệ (canary)
↓
Đây là cách làm phổ biến nhất trong thực tế
Từ khoá nhận diện:
"cannot deploy to existing stack, no user impact" → blue/green với chuyển dần "gradual rollout by percentage" → canary hoặc weighted routing "instant rollback" → blue/green "replace instances in batches" → rolling
Ba cách chuyển lưu lượng: | Cách | Độ chính xác | Tốc độ chuyển | |---|---|---| | Route 53 weighted | phụ thuộc TTL | phút | | ALB weighted target group | chính xác | tức thì | | CodeDeploy blue/green | chính xác | tức thì |
⚠ ALB weighted target group chính xác hơn DNS:
aws elbv2 modify-listener --listener-arn <arn> \
--default-actions '[{"Type":"forward",
"ForwardConfig":{"TargetGroups":[
{"TargetGroupArn":"<arn-cu>","Weight":95},
{"TargetGroupArn":"<arn-moi>","Weight":5}]}}]'
Không phụ thuộc TTL, không phụ thuộc cache DNS
→ tỷ lệ thật đúng con số bạn đặt
Ba lưu ý về PCI-DSS: | Lưu ý | Chi tiết | |---|---| | Thu hẹp phạm vi là chiến lược quan trọng nhất | | | Tokenization bỏ hẳn việc lưu số thẻ | | | AWS chịu trách nhiệm phần hạ tầng | |
⚠ Mô hình trách nhiệm chung với PCI:
AWS: chứng nhận hạ tầng (Level 1 Service Provider)
↓
Bạn: chứng nhận ứng dụng, cấu hình, quy trình
→ dùng AWS Artifact tải báo cáo tuân thủ của AWS
Ba lưu ý về TTL khi chuyển bằng DNS: | Lưu ý | Chi tiết | |---|---| | Giảm TTL vài ngày TRƯỚC khi bắt đầu | | | 60 giây là mức thường dùng | | | Một số resolver bỏ qua TTL rất thấp | |
Ba lưu ý về theo dõi trong lúc chuyển: | Metric | Ý nghĩa | |---|---| | Tỷ lệ lỗi 5xx của từng môi trường | | | Độ trễ p99 của từng môi trường | | | Metric nghiệp vụ (giao dịch thành công) | |
⚠ Metric nghiệp vụ quan trọng hơn metric kỹ thuật:
Hệ thống không lỗi nhưng tỷ lệ thanh toán
thành công giảm 20%
↓
Đó mới là dấu hiệu phải quay lui
→ lỗi 5xx bằng 0 không có nghĩa là ổn
Ba lưu ý về dữ liệu dùng chung: | Lưu ý | Chi tiết | |---|---| | Hai môi trường thường dùng CHUNG CSDL | | | Thay đổi lược đồ phải tương thích ngược | | | Nếu không thì blue/green không dùng được | |
⚠ Đây là ràng buộc lớn nhất của blue/green:
Phiên bản mới đổi lược đồ CSDL
→ phiên bản cũ không đọc được nữa
↓
Phải làm hai bước: thêm cột mới (tương thích)
→ triển khai mã mới → rồi mới bỏ cột cũ
Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Chạy hai môi trường = chi phí gấp đôi tạm thời | | | Chỉ trong thời gian chuyển đổi | | | Xoá stack cũ sau khi ổn định | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Theo dõi metric hai môi trường song song | | | Thử quay lui khi mới ở 5% | | | Xác nhận stack cũ vẫn chạy được | |
Và một lời khuyên: hãy thử quay lui một lần khi mới chuyển 5% lưu lượng. Đường lùi chỉ đáng tin khi đã được dùng thật, và thời điểm phát hiện nó không hoạt động phải là lúc chỉ 5% người dùng bị ảnh hưởng, chứ không phải khi đã chuyển hết.
A global financial company is launching its new trading platform in AWS which allows people to buy and sell their bitcoin, ethereum, ripple, and other cryptocurrencies, as well as access to various financial reports. To meet the anti-money laundering and counter-terrorist financing (AML/CFT) measures compliance, all report files of the trading platform must not be accessible in certain countries which are listed in the Financial Action Task Force (FATF) list of non-cooperative countries or territories. You were given a task to ensure that the company complies with this requirement to avoid hefty monetary penalties.
In this scenario, what is the best way to satisfy this security requirement in AWS while still delivering content to users around the globe with lower latency?
- A Use Route53 with a Geolocation routing policy that blocks all traffic from the blacklisted countries.
-
B
Create a CloudFront distribution with Geo-Restriction enabled to block all of the blacklisted countries from accessing the trading platform.
- C Use Route53 with a Geoproximity routing policy that blocks all traffic from the blacklisted countries.
- D Deploy the trading platform using Elastic Beanstalk and deny all incoming traffic from the IP addresses of the blacklisted countries in the Network Access Control List (ACL) of the VPC.
Xem giải thích
Đáp án
B — Tạo CloudFront distribution có bật Geo-Restriction để chặn mọi quốc gia trong danh sách đen truy cập nền tảng giao dịch.
Vì sao đúng
Đề nêu hai yêu cầu, và geo restriction đáp ứng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | CHẶN người dùng ở các quốc gia FATF | deny list theo mã quốc gia | | Vẫn phục vụ toàn cầu với độ trễ thấp | CloudFront edge toàn cầu |
⚠ Chỉ CloudFront geo restriction thật sự CHẶN:
Route 53 geolocation: trả về câu trả lời DNS KHÁC
→ không chặn gì
→ người biết IP vẫn truy cập thẳng được
↓
CloudFront geo restriction: TỪ CHỐI phục vụ
→ trả 403 ở edge
Đây là lý do phương án A và C sai.
Cấu hình:
aws cloudfront update-distribution --id E1ABCDEF \
--distribution-config '{
"Restrictions": {
"GeoRestriction": {
"RestrictionType": "blacklist",
"Quantity": 3,
"Items": ["IR", "KP", "MM"]}},
...}'
⚠ Mã quốc gia dùng chuẩn ISO 3166-1 alpha-2 — hai chữ cái.
Chặn ở edge là chặn ở nơi tốt nhất:
Người dùng ở quốc gia bị chặn
→ CloudFront edge từ chối NGAY
↓
Không chạm tới origin
→ không tốn tài nguyên, không tốn phí truyền
→ và không có dữ liệu nào rời khỏi hệ thống
Trang thông báo tuỳ chỉnh:
{"CustomErrorResponses": {"Quantity": 1, "Items": [{
"ErrorCode": 403,
"ResponsePagePath": "/khong-phuc-vu.html",
"ResponseCode": "403",
"ErrorCachingMinTTL": 300}]}}
⚠ Trang lỗi phải nằm ở nơi KHÔNG bị chặn:
Đặt trang lỗi trong chính distribution bị chặn
→ người bị chặn cũng không lấy được nó
↓
Dùng CloudFront Function trả nội dung trực tiếp
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | MIỄN PHÍ — nằm sẵn trong CloudFront | | | Chặn ở edge, không tốn tài nguyên gốc | | | Thay đổi danh sách bằng một lệnh | |
⚠ Giới hạn phải nói rõ với bên tuân thủ:
Dựa trên cơ sở dữ liệu địa lý IP
→ không chính xác tuyệt đối
→ VPN và proxy vượt qua được
↓
Đáp ứng yêu cầu "nỗ lực hợp lý"
→ nhưng cần thêm lớp: xác minh danh tính,
kiểm tra phương thức thanh toán
Vì sao các phương án khác sai
- **A. Route 53 geolocation routing chặn lưu lượng từ các nước bị cấm — đây là phương án gần nhất và cũng dựa trên vị trí địa lý, nhưng geolocation routing là cơ chế ĐỊNH TUYẾN: nó trả về câu trả lời DNS khác nhau, không từ chối phục vụ. Ai biết địa chỉ IP vẫn truy cập được.
- **C. Route 53 geoproximity routing — cùng vấn đề, và geoproximity còn dựa trên khoảng cách tới tài nguyên chứ không phải vị trí người dùng.
- **D. Triển khai bằng Elastic Beanstalk và chặn IP trong NACL của VPC — không có danh sách IP theo quốc gia nào bền vững; NACL giới hạn ~20-40 quy tắc; và duy trì danh sách đó là công việc vô tận.
Ghi nhớ
⚠ Ba cách kiểm soát theo địa lý — bảng phải thuộc: | Cách | Bản chất | Phí | |---|---|---| | CloudFront geo restriction | CHẶN ở edge | miễn phí | | AWS WAF geo match rule | CHẶN, kết hợp điều kiện khác | có phí | | Route 53 geolocation | ĐỊNH TUYẾN, không chặn | phí truy vấn |
⚠ Phân biệt "chặn" và "định tuyến" là bẫy kinh điển:
Route 53 geolocation dùng để phục vụ
NỘI DUNG KHÁC NHAU theo vùng
→ tiếng Việt cho người Việt, tiếng Anh cho người khác
↓
KHÔNG phải cơ chế bảo mật
Từ khoá nhận diện:
"block users from specific countries" → CloudFront geo restriction "block by country AND rate limit AND SQLi" → WAF "serve different content by region" → Route 53 geolocation "comply with sanctions/licensing" → geo restriction hoặc WAF
⚠ Khi nào WAF đáng dùng thay geo restriction: | Tình huống | Vì sao WAF | |---|---| | Chặn quốc gia CHỈ ở một số đường dẫn | geo restriction áp cả distribution | | Kết hợp nhiều điều kiện | quốc gia + IP + tần suất | | Cần log chi tiết yêu cầu bị chặn | | | Áp cho ALB hoặc API Gateway | geo restriction chỉ có ở CloudFront |
{"Name": "ChanQuocGiaFATF", "Priority": 1,
"Statement": {"GeoMatchStatement":
{"CountryCodes": ["IR","KP","MM"]}},
"Action": {"Block": {"CustomResponse":
{"ResponseCode": 403}}},
"VisibilityConfig": {"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true, "MetricName": "ChanFATF"}}
Ba lưu ý về danh sách chặn và cho phép: | Kiểu | Khi nào | |---|---| | blacklist (deny list) | chặn vài nước, phục vụ phần còn lại | | whitelist (allow list) | chỉ phục vụ vài nước |
⚠ Với tuân thủ AML/CFT, allow list an toàn hơn:
Deny list: nước mới bị đưa vào danh sách FATF
→ phải nhớ cập nhật
↓
Allow list: chỉ những nước đã được duyệt
→ nước mới mặc định bị chặn
→ an toàn hơn về mặt tuân thủ
Ba lưu ý về CloudFront-Viewer-Country: | Lưu ý | Chi tiết | |---|---| | CloudFront thêm header mã quốc gia | | | Ứng dụng đọc được để tuỳ biến | | | Phải bật trong origin request policy | |
Ba lưu ý về CloudFront Functions: | Lưu ý | Chi tiết | |---|---| | Logic chặn phức tạp hơn geo restriction | | | Chạy ở mọi edge, độ trễ dưới 1 ms | | | Trả nội dung trực tiếp được | |
function handler(event) {
var quocGia = event.viewer.country;
var chan = ['IR','KP','MM'];
if (chan.indexOf(quocGia) !== -1) {
return {statusCode: 403, statusDescription: 'Forbidden',
body: 'Dich vu khong phuc vu khu vuc cua ban'};
}
return event.request;
}
Ba lưu ý về áp dụng thay đổi: | Lưu ý | Chi tiết | |---|---| | Cập nhật distribution mất vài phút lan ra edge | | | Trạng thái InProgress → Deployed | | | Không cần invalidation | |
Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Ghi tài liệu vì sao chặn nước nào | | | Rà lại danh sách FATF định kỳ | | | Lưu bằng chứng đã áp dụng | |
⚠ Danh sách FATF thay đổi vài lần mỗi năm:
FATF cập nhật danh sách trong các phiên họp toàn thể
→ phải có quy trình rà soát định kỳ
↓
Tự động hoá bằng cách lưu danh sách trong
Parameter Store và cập nhật distribution
Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Access log có trường quốc gia | | | Theo dõi tỷ lệ 403 | | | Báo cáo cho bộ phận tuân thủ | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử qua VPN đặt ở nước bị chặn | | | Kiểm tra trang thông báo hiện đúng | | | Xem access log ghi nhận đúng quốc gia | |
Và một lời khuyên: hãy cân nhắc dùng allow list thay vì deny list cho yêu cầu tuân thủ AML/CFT. Danh sách FATF thay đổi vài lần mỗi năm, và một quốc gia mới được thêm vào sẽ tiếp tục truy cập được cho tới khi có ai đó nhớ cập nhật cấu hình — với allow list thì rủi ro đó không tồn tại.