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

Tìm thấy 2194 câu.

Câu 491 Design Cost-Optimized Architectures

Your company has a monthly big data workload, running for about 2 hours, which can be efficiently distributed across multiple servers of various sizes, with a variable number of CPUs. The solution for the workload should be able to withstand server failures.

Which is the MOST cost-optimal solution for this workload?

  1. A

    Run the workload on Dedicated Hosts
  2. B

    Run the workload on Reserved Instances (RI)
  3. C

    Run the workload on a Spot Fleet
  4. D

    Run the workload on Spot Instances
Xem giải thích

Đáp án

C — Chạy tải công việc trên Spot Fleet.

Vì sao đúng

Đề nêu ba đặc điểm, và mỗi đặc điểm dẫn tới một phần của đáp án: | Đặc điểm trong đề | Kết luận | |---|---| | Chạy 2 giờ mỗi THÁNG | không cam kết dài hạn → loại RI | | Chịu được máy chủ hỏng | → Spot phù hợp | | Phân tán trên máy chủ NHIỀU CỠ, SỐ CPU KHÁC NHAU | → Spot FLEET, không phải Spot Instances đơn thuần |

Điểm phân biệt giữa Spot Fleet và Spot Instances:

Spot Instance (đơn lẻ):
    → yêu cầu MỘT loại instance cụ thể trong MỘT AZ
    → pool đó hết máy → không có gì

Spot Fleet:
    → khai NHIỀU loại instance, NHIỀU AZ
    → khai TỔNG NĂNG LỰC mong muốn (theo vCPU hoặc bộ nhớ)
    → AWS tự chọn tổ hợp rẻ nhất hoặc dồi dào nhất

Và đề mô tả chính xác nhu cầu đó:

"efficiently distributed across multiple servers of VARIOUS SIZES,
 with a VARIABLE NUMBER OF CPUs"
    ↓
    → cần khai năng lực theo TỔNG vCPU, không theo số máy
    → đó chính là mô hình của Spot Fleet

Cấu hình Spot Fleet:

{"TargetCapacity": 500,
 "TargetCapacityUnitType": "vcpu",
 "AllocationStrategy": "capacityOptimized",
 "LaunchTemplateConfigs": [{
   "LaunchTemplateSpecification": {"LaunchTemplateName": "lt-big-data", "Version": "1"},
   "Overrides": [
     {"InstanceType": "m5.2xlarge",  "SubnetId": "subnet-a"},
     {"InstanceType": "m5.4xlarge",  "SubnetId": "subnet-b"},
     {"InstanceType": "m5a.4xlarge", "SubnetId": "subnet-c"},
     {"InstanceType": "r5.2xlarge",  "SubnetId": "subnet-a"},
     {"InstanceType": "c5.4xlarge",  "SubnetId": "subnet-b"}]}]}

TargetCapacityUnitType: vcpu cho phép khai "cần 500 vCPU" thay vì "cần 20 máy loại X" — đúng nhu cầu của đề.

Và giảm giá tới 90% so với on-demand.

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

  • **D. Chạy trên Spot Instances — đây là phương án gần nhất và cùng mô hình giá, nhưng nó kém phù hợp với yêu cầu về sự đa dạng: yêu cầu Spot Instance đơn lẻ nhắm tới một loại instance cụ thể, nên không tận dụng được khả năng "phân tán trên máy nhiều cỡ khác nhau" mà đề nêu. Và một pool hết máy là cả đợt chạy thất bại.
  • **B. Chạy trên Reserved Instances — sai mô hình cam kết: RI đòi cam kết 1 hoặc 3 năm. Tải chạy 2 giờ mỗi tháng (khoảng 24 giờ mỗi năm) sẽ lãng phí gần như toàn bộ khoản cam kết.
  • **A. Chạy trên Dedicated Hosts — đắt nhất trong mọi lựa chọn: bạn trả tiền cho cả máy chủ vật lý. Nó dành cho yêu cầu giấy phép hoặc tuân thủ, không phải cho tối ưu chi phí.

Ghi nhớ

Ba cách yêu cầu Spot — bảng phân biệt: | Cách | Khai gì | |---|---| | Spot Instance request | một loại instance, một AZ | | Spot Fleet | nhiều loại, nhiều AZ, TỔNG năng lực ← câu này | | EC2 Fleet | như Spot Fleet nhưng trộn được On-Demand, Spot, RI | | ASG với mixed instances policy | cách hiện đại nhất, tích hợp Auto Scaling |

AWS hiện khuyến nghị dùng ASG với mixed instances policy thay vì Spot Fleet cho tải cần co giãn:

{"MixedInstancesPolicy": {
   "InstancesDistribution": {
     "OnDemandBaseCapacity": 0,
     "OnDemandPercentageAboveBaseCapacity": 0,
     "SpotAllocationStrategy": "capacity-optimized"},
   "LaunchTemplate": {"Overrides": [
     {"InstanceType": "m5.4xlarge", "WeightedCapacity": "16"},
     {"InstanceType": "m5.2xlarge", "WeightedCapacity": "8"},
     {"InstanceType": "c5.4xlarge", "WeightedCapacity": "16"}]}}}

WeightedCapacity cho phép tính theo vCPU — máy lớn đóng góp nhiều hơn.

Bốn chiến lược phân bổ của Spot Fleet: | Chiến lược | Cách chọn | |---|---| | capacityOptimized | pool có NĂNG LỰC DỒI DÀO nhất — ít bị thu hồi nhất | | priceCapacityOptimized | cân bằng giá và năng lực — khuyến nghị mặc định | | lowestPrice | rẻ nhất, nhưng dễ bị thu hồi | | diversified | trải đều mọi pool |

AWS khuyến nghị priceCapacityOptimized cho hầu hết trường hợp.

Ba đặc điểm của Spot cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Báo trước 2 phút khi bị thu hồi | qua metadata và EventBridge | | Giảm tới 90% so với on-demand | | | Không đảm bảo năng lực | pool có thể hết |

Ba loại workload phù hợp với Spot: | Loại | Ví dụ | |---|---| | Xử lý lô, big data | ← câu này | | CI/CD | build và test | | Kết xuất, chuyển mã | video, đồ hoạ | | Container không trạng thái | web tier có ASG |

Ba cách tăng độ ổn định: | Cách | Chi tiết | |---|---| | Đa dạng hoá loại instance và AZ | quan trọng nhất | | Dùng capacityOptimized | | | Xử lý êm thông báo thu hồi | lưu checkpoint |

Và cách bắt thông báo thu hồi:

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 300")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/spot/instance-action

Ba dịch vụ tự quản lý Spot rất tốt: | Dịch vụ | Chi tiết | |---|---| | AWS Batch | tự quản lý hàng đợi, tự thử lại, dùng Spot mặc định | | Amazon EMR | node lõi On-Demand, node task Spot | | ECS/EKS với Fargate Spot | container |

AWS Batch là lựa chọn ít công nhất cho tình huống trong đề:

AWS Batch:
    ✓ khai job và yêu cầu tài nguyên (vCPU, bộ nhớ)
    ✓ Batch tự chọn loại instance phù hợp
    ✓ tự cấp và thu hồi năng lực
    ✓ TỰ THỬ LẠI khi job bị gián đoạn
        ↓
    Không phải tự viết logic phục hồi

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Spot Fleet không có phí riêng | chỉ trả tiền instance | | Tắt fleet khi xong việc | tải chạy 2 giờ mỗi tháng | | Xem Spot Instance Advisor | tần suất bị thu hồi của từng loại |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | FulfilledCapacity | năng lực thực sự có được | | Số lần bị thu hồi | qua EventBridge | | Thời gian hoàn thành job | so với dự kiến |

Và một lời khuyên: hãy thiết kế job có thể chia nhỏ và có checkpoint trước khi chuyển sang Spot. Với tải chạy 2 giờ, một lần bị thu hồi ở phút thứ 100 mà không có checkpoint nghĩa là làm lại từ đầu — và khoản tiết kiệm 90% không bù nổi việc phải chạy hai lần rồi vẫn không xong.

Câu 492 Design Secure Architectures

"An enterprise organization is expanding its cloud footprint and needs to centralize its security event data from various AWS accounts and services. The goal is to evaluate security posture across all environments and improve threat detection and response — without requiring significant custom code or manual integration.

Which solution will fulfill these needs with the least development effort?

  1. A

    Use Amazon Athena with predefined SQL queries to scan security logs stored in multiple S3 buckets. Visualize the findings by exporting results to an Amazon QuickSight dashboard
  2. B

    Set up a data lake using AWS Lake Formation to collect and organize security event logs. Use AWS Glue to perform ETL operations and standardize the log formats for centralized analysis
  3. C

    Deploy a custom Lambda function to aggregate security logs from multiple AWS accounts. Format the data into CSV files and upload them to a central S3 bucket for analysis
  4. D

    Use Amazon Security Lake to create a centralized data lake that automatically collects security-related logs and events from AWS services and third-party sources. Store the data in an Amazon S3 bucket managed by Security Lake
Xem giải thích

Đáp án

D — Dùng Amazon Security Lake để tạo data lake tập trung, tự động thu thập log và sự kiện bảo mật từ các dịch vụ AWS và nguồn bên thứ ba, lưu vào bucket S3 do Security Lake quản lý.

Vì sao đúng

Đề nêu ba yêu cầu, và Security Lake được thiết kế đúng cho bài toán này: | Yêu cầu | Cơ chế | |---|---| | Tập trung dữ liệu bảo mật từ NHIỀU tài khoản và dịch vụ | Security Lake tích hợp với Organizations | | Cải thiện phát hiện và ứng phó | chuẩn hoá về định dạng OCSF, truy vấn được ngay | | KHÔNG cần viết mã hay tích hợp thủ công | bật bằng cấu hình, không phải bằng mã |

Amazon Security Lake làm gì:

Bật một lần ở tài khoản quản trị viên uỷ quyền
    ↓
Security Lake TỰ ĐỘNG:
    ✓ thu thập CloudTrail, VPC Flow Logs, Route 53 Resolver logs,
      Security Hub findings, EKS audit logs
    ✓ chuẩn hoá về định dạng OCSF (Open Cybersecurity Schema Framework)
    ✓ chuyển sang Parquet, phân vùng theo thời gian
    ✓ áp lifecycle để quản lý chi phí
    ✓ trải qua mọi tài khoản trong Organization

Và OCSF là điểm mấu chốt:

Không chuẩn hoá:
    CloudTrail có lược đồ riêng
    VPC Flow Logs có lược đồ riêng
    Log của bên thứ ba có lược đồ riêng
        ↓
    Muốn truy vấn chéo phải tự viết ETL cho từng nguồn

OCSF:
    → mọi nguồn được đưa về CÙNG một lược đồ chuẩn
    → truy vấn chéo nguồn bằng một câu SQL

Bật Security Lake:

aws securitylake create-data-lake   --configurations '[{
    "region": "ap-northeast-1",
    "encryptionConfiguration": {"kmsKeyId": "S3_MANAGED_KEY"},
    "lifecycleConfiguration": {
      "transitions": [{"storageClass": "GLACIER", "days": 90}],
      "expiration": {"days": 730}}}]'   --meta-store-manager-role-arn <arn>

aws securitylake create-aws-log-source --sources '[{
  "sourceName": "CLOUD_TRAIL_MGMT", "sourceVersion": "2.0",
  "regions": ["ap-northeast-1"]}]'

Và truy vấn ngay bằng Athena — bảng đã được đăng ký trong Glue Data Catalog.

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

  • **B. Dựng data lake bằng Lake Formation, dùng Glue làm ETL và chuẩn hoá định dạng log — đây là phương án gần nhất và về nguyên tắc dựng được đúng thứ Security Lake cung cấp, nhưng nó đòi rất nhiều công phát triển: bạn phải tự viết job Glue cho từng loại log, tự định nghĩa lược đồ, tự xử lý thay đổi định dạng khi AWS cập nhật. Đề yêu cầu "least development effort".
  • **C. Viết Lambda tuỳ chỉnh tổng hợp log từ nhiều tài khoản, chuyển thành CSV, tải lên S3 — nhiều công nhất và kém nhất: mã tự viết phải bảo trì, CSV mất cấu trúc lồng nhau của log JSON, và không có chuẩn hoá nào.
  • **A. Dùng Athena với truy vấn SQL định sẵn trên log ở nhiều bucket, xuất kết quả sang QuickSight — thiếu bước tập trung và chuẩn hoá: log vẫn nằm rải rác ở nhiều bucket với nhiều lược đồ khác nhau, và truy vấn chéo chúng đòi rất nhiều công chuẩn bị.

Ghi nhớ

Các dịch vụ bảo mật của AWS — bảng cần thuộc: | Dịch vụ | Việc | |---|---| | Security Lake | TẬP TRUNG và CHUẨN HOÁ dữ liệu bảo mật (OCSF) ← câu này | | Security Hub | TỔNG HỢP finding, chấm theo chuẩn (CIS, PCI) | | GuardDuty | PHÁT HIỆN ĐE DOẠ từ log | | Inspector | QUÉT LỖ HỔNG (EC2, ECR, Lambda) | | Macie | PHÁT HIỆN DỮ LIỆU NHẠY CẢM trong S3 | | Detective | ĐIỀU TRA sâu một finding | | AWS Config | tuân thủ cấu hình | | CloudTrail | ghi lời gọi API |

Security Lake và Security Hub — phân biệt rõ: | | Security Lake | Security Hub | |---|---|---| | Dữ liệu | LOG THÔ đã chuẩn hoá | FINDING đã phân tích | | Định dạng | OCSF, Parquet trong S3 | ASFF | | Dùng để | phân tích sâu, săn tìm đe doạ, tuân thủ dài hạn | theo dõi tư thế bảo mật hằng ngày | | Lưu trữ | do bạn kiểm soát, dài hạn | ngắn hạn (90 ngày) |

Hai dịch vụ này BỔ SUNG nhau, không thay thế nhau — Security Hub cho cái nhìn tổng quan, Security Lake cho khả năng truy vấn lịch sử.

Các nguồn log mà Security Lake tự thu thập: | Nguồn | Nội dung | |---|---| | CloudTrail (management và data event) | lời gọi API | | VPC Flow Logs | lưu lượng mạng | | Route 53 Resolver query logs | truy vấn DNS | | Security Hub findings | finding tổng hợp | | EKS audit logs | hoạt động trong cụm Kubernetes | | WAF logs | request bị chặn |

Và hỗ trợ nguồn TÙY CHỈNH:

aws securitylake create-custom-log-source   --source-name log-tuong-lua-ben-thu-ba   --configuration '{"crawlerConfiguration":{"roleArn":"<arn>"},
                    "providerIdentity":{"principal":"123456789012",
                                        "externalId":"abc"}}'

Nhờ đó gộp được cả log của thiết bị bảo mật bên thứ ba vào cùng một data lake.

Ba lợi ích của định dạng OCSF: | Lợi ích | Chi tiết | |---|---| | Truy vấn chéo nguồn bằng một câu SQL | không cần biết lược đồ riêng của từng nguồn | | Công cụ SIEM đọc được ngay | Splunk, Datadog hỗ trợ OCSF | | Chuẩn mở, không khoá vào một nhà cung cấp | |

Ví dụ truy vấn chéo nguồn:

SELECT time, actor.user.name, api.operation, src_endpoint.ip
FROM amazon_security_lake_table_ap_northeast_1_cloud_trail_mgmt_2_0
WHERE eventday BETWEEN '20260801' AND '20260830'
  AND api.response.error IS NOT NULL
  AND src_endpoint.ip NOT IN (SELECT ip FROM ip_tin_cay)
ORDER BY time DESC;

Ba khái niệm của Security Lake: | Khái niệm | Chi tiết | |---|---| | Data lake administrator | tài khoản quản trị viên uỷ quyền | | Subscriber | ai được đọc dữ liệu — theo truy vấn hoặc theo dữ liệu | | Rollup Region | gộp dữ liệu từ nhiều Region về một chỗ |

Hai loại subscriber: | Loại | Cách truy cập | |---|---| | Query access | qua Athena và Lake Formation | | Data access | nhận thông báo SQS khi có dữ liệu mới, đọc thẳng S3 |

Loại thứ hai dùng cho tích hợp với SIEM bên ngoài.

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo dung lượng dữ liệu nạp vào | | | Cộng phí lưu trữ S3 | đặt lifecycle sang Glacier | | Phí truy vấn Athena | theo dữ liệu quét — Parquet giúp giảm nhiều |

Và lifecycle nên cấu hình ngay từ đầu:

{"transitions": [
   {"storageClass": "STANDARD_IA", "days": 30},
   {"storageClass": "GLACIER", "days": 90}],
 "expiration": {"days": 2555}}

Log bảo mật thường phải giữ nhiều năm vì yêu cầu tuân thủ, và không phân tầng thì chi phí lưu trữ rất lớn.

Ba việc nên làm sau khi bật: | Việc | Chi tiết | |---|---| | Bật ở MỌI Region đang dùng | kẻ tấn công chọn Region bạn không giám sát | | Chỉ định rollup Region | gộp về một chỗ để truy vấn | | Nối với SIEM hiện có | nếu tổ chức đã có |

Và một lời khuyên: hãy kiểm chứng bằng một truy vấn thật ngay sau khi bật — ví dụ tìm mọi lời gọi AccessDenied trong 24 giờ qua. Nó vừa xác nhận dữ liệu đang chảy vào, vừa cho đội bảo mật thấy ngay giá trị của việc có mọi nguồn log trong cùng một lược đồ.

Câu 493 Design Cost-Optimized Architectures

You have multiple AWS accounts within a single AWS Region managed by AWS Organizations and you would like to ensure all Amazon EC2 instances in all these accounts can communicate privately. Which of the following solutions provides the capability at the CHEAPEST cost?

  1. A

    Create a VPC peering connection between all virtual private cloud (VPCs)
  2. B

    Create an AWS Transit Gateway and link all the virtual private cloud (VPCs) in all the accounts together
  3. C

    Create a Private Link between all the Amazon EC2 instances
  4. D

    Create a virtual private cloud (VPC) in an account and share one or more of its subnets with the other accounts using Resource Access Manager
Xem giải thích

Đáp án

D — Tạo một VPC ở một tài khoản và chia sẻ một hoặc nhiều subnet của nó với các tài khoản khác qua AWS Resource Access Manager (RAM).

Vì sao đúng

Đề hỏi cách RẺ NHẤT để mọi EC2 trong nhiều tài khoản giao tiếp riêng tư — và VPC sharing thắng vì nó loại bỏ hẳn nhu cầu kết nối liên VPC.

Các cách khác: nhiều VPC → phải NỐI chúng lại
    → mỗi kết nối đều có chi phí

VPC sharing: MỘT VPC duy nhất
    → mọi instance nằm trong CÙNG mạng
    → giao tiếp qua IP riêng, KHÔNG có kết nối liên VPC nào
    → KHÔNG có phí kết nối, KHÔNG có phí xử lý dữ liệu

Cách VPC sharing hoạt động:

Tài khoản chủ VPC (owner):
    → tạo VPC và subnet
    → chia sẻ subnet qua AWS RAM

Tài khoản tham gia (participant):
    → tạo EC2 TRONG subnet được chia sẻ
    → instance có IP riêng của VPC đó
    → giao tiếp với instance của tài khoản khác như cùng một mạng

aws ram create-resource-share --name chia-se-subnet   --resource-arns arn:aws:ec2:ap-northeast-1:111122223333:subnet/subnet-abc   --principals ou-abc-12345678   --permission-arns arn:aws:ram::aws:permission/AWSRAMDefaultPermissionSubnet

Và so sánh chi phí: | Cách | Chi phí | |---|---| | VPC sharing (RAM) | RAM MIỄN PHÍ, không phí kết nối | | VPC peering | miễn phí kết nối, nhưng tính phí truyền dữ liệu chéo AZ | | Transit Gateway | ~0,05 USD/giờ mỗi attachment + 0,02 USD/GB xử lý | | PrivateLink | ~0,01 USD/giờ mỗi ENI + 0,01 USD/GB |

Với nhiều VPC, Transit Gateway đặc biệt tốn kém:

10 VPC × 0,05 USD/giờ × 730 giờ = 365 USD/tháng
    → chỉ riêng phí attachment, chưa tính phí dữ liệu

Và VPC sharing còn có ưu điểm vận hành:

✓ quản lý mạng TẬP TRUNG ở một tài khoản
✓ không phải quản lý bảng định tuyến chằng chịt
✓ tiết kiệm không gian địa chỉ IP
✓ tài nguyên vẫn thuộc sở hữu của từng tài khoản

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

  • **B. Tạo Transit Gateway nối mọi VPC — đây là phương án gần nhất và là kiến trúc chuẩn cho nhiều VPC, nhưng nó đắt nhất trong các lựa chọn: mỗi VPC attachment tính phí theo giờ, cộng phí xử lý mỗi GB. Với mục tiêu "CHEAPEST", nó thua VPC sharing rõ rệt.
  • **A. Tạo VPC peering giữa TẤT CẢ các VPC — không mở rộng được và tốn công: peering không bắc cầu, nên N VPC cần N×(N−1)/2 kết nối. Với 10 VPC là 45 kết nối phải tạo và duy trì bảng định tuyến cho từng cái.
  • **C. Tạo PrivateLink giữa tất cả các EC2 instance — sai mục đích dịch vụ: PrivateLink phơi một DỊCH VỤ (sau NLB) cho bên khác, nó không phải cơ chế nối mạng chung giữa các instance. Và nó cũng tính phí theo giờ.

Ghi nhớ

Bốn cách kết nối mạng giữa nhiều tài khoản — bảng cần thuộc: | Cách | Chi phí kết nối | Mở rộng | Chiều | |---|---|---|---| | VPC sharing (RAM) | MIỄN PHÍ | rất tốt | cùng một VPC | | VPC peering | miễn phí | ❌ không bắc cầu | hai chiều | | Transit Gateway | theo giờ + theo GB | rất tốt | hai chiều | | PrivateLink | theo giờ + theo GB | tốt | một chiều, một dịch vụ |

Từ khoá nhận diện:

"cheapest", "single VPC", "centralized network management" → VPC sharing "many VPCs, hub-and-spoke, transitive routing" → Transit Gateway "expose one service, one-way, overlapping CIDR" → PrivateLink "two VPCs only, simple" → VPC peering

Ba đặc điểm của VPC sharing: | Đặc điểm | Chi tiết | |---|---| | Chủ VPC quản lý subnet, route table, NACL, VPN, TGW | | | Tài khoản tham gia tạo và SỞ HỮU tài nguyên của mình | EC2, RDS, ALB | | Tài khoản tham gia KHÔNG sửa được cấu hình mạng | tách bạch trách nhiệm |

Đây là mô hình phân chia trách nhiệm rất rõ ràng:

Đội mạng (chủ VPC):
    → thiết kế và vận hành mạng, kết nối tại chỗ, NAT, endpoint

Đội ứng dụng (tham gia):
    → triển khai tài nguyên, quản lý security group của mình

Ba lưu ý về security group trong VPC dùng chung: | Lưu ý | Chi tiết | |---|---| | Tài khoản tham gia TỰ tạo security group của mình | | | Tham chiếu SG XUYÊN TÀI KHOẢN được | nếu chủ VPC chia sẻ | | Không thấy được SG của tài khoản khác trong console | chỉ tham chiếu bằng id |

Ba thứ KHÔNG chia sẻ được: | Không chia sẻ | Chi tiết | |---|---| | Default VPC | phải tạo VPC mới | | Default subnet | | | Một số tài nguyên đặc thù | kiểm tra tài liệu RAM |

Các tài nguyên chia sẻ được qua AWS RAM: | Tài nguyên | Việc | |---|---| | VPC subnet | ← câu này | | Transit Gateway | dùng chung TGW giữa nhiều tài khoản | | Route 53 Resolver rule | DNS lai dùng chung | | License Manager configuration | | | Aurora DB cluster | | | Capacity Reservation | |

Chia sẻ Resolver rule là mẫu rất hữu ích:

Tài khoản mạng:
    → tạo outbound endpoint và forwarding rule MỘT LẦN
    → chia sẻ qua RAM
        ↓
    Các tài khoản khác chỉ gắn rule vào VPC của mình
    → tiết kiệm phí endpoint (mỗi ENI ~0,125 USD/giờ)

Ba lưu ý về hạn mức khi dùng VPC sharing: | Lưu ý | Chi tiết | |---|---| | Hạn mức của VPC áp cho TỔNG mọi tài khoản | ENI, security group, route | | Cần lập kế hoạch CIDR đủ rộng | nhiều tài khoản dùng chung dải IP | | Số subnet chia sẻ tối đa cho một tài khoản | kiểm tra hạn mức hiện hành |

Dòng đầu quan trọng: nếu một đội dùng hết hạn mức ENI, các đội khác cũng bị ảnh hưởng.

Ba mẫu kiến trúc mạng nhiều tài khoản: | Mẫu | Phù hợp | |---|---| | VPC sharing | nhiều đội, cùng một môi trường mạng ← câu này | | Transit Gateway hub-and-spoke | mỗi đội cần VPC riêng, cách ly rõ | | Kết hợp cả hai | VPC dùng chung cho ứng dụng, TGW nối tới tại chỗ |

Và mẫu kết hợp rất phổ biến trong thực tế:

Tài khoản mạng:
    ├── VPC dùng chung (chia sẻ subnet cho các đội)
    └── Transit Gateway (nối tới trung tâm dữ liệu và VPC đặc biệt)

Ba việc cần chuẩn bị trước khi dùng VPC sharing: | Việc | Chi tiết | |---|---| | Bật chia sẻ trong Organizations | enable-sharing-with-aws-organization | | Lập kế hoạch CIDR | đủ chỗ cho mọi đội phát triển | | Thống nhất quy ước đặt tên và gắn thẻ | tài nguyên của nhiều đội nằm chung |

Và một lời khuyên: hãy gắn thẻ bắt buộc cho mọi tài nguyên trong VPC dùng chung (đội, dự án, môi trường). Khi hàng chục đội cùng triển khai vào một VPC, việc xác định ENI hay security group nào thuộc về ai trở thành công việc thường xuyên — và không có thẻ thì không ai dám dọn dẹp gì cả.

Câu 494 Design Resilient Architectures

The DevOps team at a major financial services company uses Multi-Availability Zone (Multi-AZ) deployment for its MySQL Amazon RDS database in order to automate its database replication and augment data durability. The DevOps team has scheduled a maintenance window for a database engine level upgrade for the coming weekend.

Which of the following is the correct outcome during the maintenance window?

  1. A

    Any database engine level upgrade for an Amazon RDS database instance with Multi-AZ deployment triggers the standby database instance to be upgraded which is then followed by the upgrade of the primary database instance. This does not cause any downtime for the duration of the upgrade
  2. B

    Any database engine level upgrade for an Amazon RDS database instance with Multi-AZ deployment triggers both the primary and standby database instances to be upgraded at the same time. However, this does not cause any downtime until the upgrade is complete
  3. C

    Any database engine level upgrade for an Amazon RDS database instance with Multi-AZ deployment triggers both the primary and standby database instances to be upgraded at the same time. This causes downtime until the upgrade is complete
  4. D

    Any database engine level upgrade for an Amazon RDS database instance with Multi-AZ deployment triggers the primary database instance to be upgraded which is then followed by the upgrade of the standby database instance. This does not cause any downtime for the duration of the upgrade
Xem giải thích

Đáp án

C — Nâng cấp phiên bản engine trên RDS Multi-AZ kích hoạt nâng cấp CẢ primary LẪN standby CÙNG LÚC, và điều đó GÂY THỜI GIAN NGỪNG cho tới khi hoàn tất.

Vì sao đúng

Đây là một trong những khác biệt quan trọng nhất giữa các loại bảo trì của RDS.

Bảng phân loại — nội dung cốt lõi: | Loại thay đổi | Multi-AZ có tránh được ngừng không | |---|---| | Vá lỗi hệ điều hành | ✅ — vá standby trước, chuyển đổi, rồi vá primary cũ | | Đổi cỡ instance | ✅ — tương tự | | NÂNG CẤP PHIÊN BẢN ENGINE (major/minor) | ❌ — CẢ HAI cùng lúc, CÓ ngừng |

Vì sao nâng cấp engine không tránh được ngừng:

Nâng cấp engine thay đổi ĐỊNH DẠNG DỮ LIỆU và giao thức sao chép
    ↓
    Primary phiên bản 8.0.35 không sao chép được sang standby 8.0.36
    → không thể chạy hai phiên bản khác nhau
        ↓
    → Phải nâng CẢ HAI cùng lúc
    → database không phục vụ trong thời gian đó

Còn vá lỗi hệ điều hành thì khác:

① Vá standby trước
② Chuyển đổi sang standby đã vá (gián đoạn ~60 giây)
③ Vá primary cũ (giờ là standby)
        ↓
    Chỉ gián đoạn bằng thời gian chuyển đổi

Ba cách giảm thời gian ngừng khi nâng cấp engine: | Cách | Chi tiết | |---|---| | Blue/Green Deployment của RDS | tạo môi trường xanh đã nâng cấp, cắt chuyển trong ~1 phút | | Nâng cấp trong cửa sổ bảo trì | chọn giờ ít người dùng | | Đọc release note trước | biết trước thay đổi phá vỡ tương thích |

Blue/Green Deployment là cách tốt nhất hiện nay:

aws rds create-blue-green-deployment   --blue-green-deployment-name nang-cap-mysql   --source arn:aws:rds:ap-northeast-1:123456789012:db:db-san-xuat   --target-engine-version 8.0.36

Môi trường XANH:
    → bản sao đã nâng cấp, đồng bộ liên tục với môi trường LAM
    → kiểm thử thoải mái trên xanh
    → cắt chuyển: đổi vai trò, thường DƯỚI MỘT PHÚT

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

  • **B. Cả primary và standby được nâng cấp cùng lúc, nhưng KHÔNG gây ngừng — đây là phương án gần nhất và vế đầu hoàn toàn đúng, nhưng vế sau sai: nâng cấp đồng thời chính là lý do có thời gian ngừng. Không có instance nào phục vụ trong lúc đó.
  • **D. Nâng primary trước rồi tới standby, không gây ngừng — mô tả đúng cơ chế VÁ LỖI HỆ ĐIỀU HÀNH, không phải nâng cấp engine. Và với vá lỗi thì thứ tự cũng ngược lại: standby trước.
  • **A. Nâng standby trước rồi tới primary, không gây ngừng — mô tả đúng quy trình vá lỗi hệ điều hành, nhưng câu hỏi nói về nâng cấp phiên bản engine.

Ghi nhớ

Ba loại bảo trì của RDS và tác động — bảng phải thuộc: | Loại | Multi-AZ giảm ngừng | Thời gian ngừng | |---|---|---| | Vá lỗi hệ điều hành | ✅ | ~60 giây (thời gian chuyển đổi) | | Đổi cỡ instance | ✅ | ~60 giây | | Nâng cấp engine (minor) | ❌ | vài phút | | Nâng cấp engine (major) | ❌ | có thể HÀNG CHỤC PHÚT | | Mở rộng dung lượng lưu trữ | ✅ | thường không ngừng |

Nâng cấp major có thể rất lâu — với database lớn, quá trình chuyển đổi dữ liệu nội bộ mất nhiều thời gian.

Ba cách kiểm soát thời điểm nâng cấp: | Cách | Chi tiết | |---|---| | AutoMinorVersionUpgrade | bật thì AWS tự nâng minor trong cửa sổ bảo trì | | Cửa sổ bảo trì | chọn khung giờ ít người dùng | | Nâng cấp thủ công | kiểm soát hoàn toàn thời điểm |

aws rds modify-db-instance --db-instance-identifier db-san-xuat   --preferred-maintenance-window "sun:18:00-sun:19:00"   --no-auto-minor-version-upgrade

Với database sản xuất quan trọng, nên tắt tự động nâng minor — để chủ động kiểm thử trước.

Ba bước nâng cấp an toàn:

① Tạo bản sao từ snapshot, nâng cấp trên đó, KIỂM THỬ ứng dụng
② Đọc release note tìm thay đổi phá vỡ tương thích
③ Nâng cấp sản xuất bằng Blue/Green Deployment

Ba lợi ích của RDS Blue/Green Deployment: | Lợi ích | Chi tiết | |---|---| | Cắt chuyển thường DƯỚI 1 PHÚT | thay vì vài chục phút | | Kiểm thử trên môi trường xanh trước | với dữ liệu thật đang đồng bộ | | Quay lại được | môi trường lam vẫn còn nguyên |

Lưu ý về Blue/Green: trong lúc cắt chuyển, ghi bị chặn để đảm bảo đồng bộ hoàn tất — nên vẫn có gián đoạn ngắn, chỉ là rất ngắn.

Multi-AZ giúp và KHÔNG giúp gì: | Tình huống | Multi-AZ giúp | |---|---| | Primary hỏng phần cứng | ✅ tự chuyển đổi | | AZ mất kết nối | ✅ | | Vá lỗi hệ điều hành | ✅ giảm ngừng | | Nâng cấp engine | ❌ ← câu này | | Lỗi do con người (xoá nhầm bảng) | ❌ — standby cũng bị xoá theo |

Dòng cuối rất quan trọng: Multi-AZ là cơ chế sẵn sàng, không phải sao lưu. Sai sót logic được sao chép sang standby ngay lập tức.

Ba cơ chế bảo vệ khác nhau: | Cơ chế | Chống lại | |---|---| | Multi-AZ | hỏng hạ tầng | | Automated backup + PITR | lỗi con người, khôi phục về bất kỳ giây nào trong 35 ngày | | Snapshot thủ công | giữ lâu dài, không bị xoá theo instance | | Cross-Region replica | thảm hoạ cấp Region |

Ba lưu ý về automated backup: | Lưu ý | Chi tiết | |---|---| | Giữ tối đa 35 ngày | mặc định 7 ngày | | XOÁ theo instance | xoá database là mất hết backup tự động | | Snapshot thủ công KHÔNG bị xoá | giữ tới khi bạn xoá |

Nên chụp snapshot thủ công TRƯỚC mọi lần nâng cấp:

aws rds create-db-snapshot --db-instance-identifier db-san-xuat   --db-snapshot-identifier truoc-khi-nang-cap-8036

Ba việc cần kiểm tra sau nâng cấp: | Việc | Chi tiết | |---|---| | Ứng dụng kết nối và truy vấn bình thường | | | Kế hoạch thực thi truy vấn không xấu đi | nâng cấp có thể đổi optimizer | | Không có cảnh báo trong log database | |

Dòng giữa là vấn đề thật hay gặp: phiên bản mới có thể chọn kế hoạch thực thi khác cho cùng một truy vấn, và một truy vấn vốn chạy nhanh bỗng chậm hàng chục lần.

Và một lời khuyên: hãy thu thập số liệu hiệu năng cơ sở TRƯỚC khi nâng cấp (thời gian truy vấn chính, CPU, IOPS). Không có con số trước thì sau khi nâng cấp bạn không có cách nào chứng minh hệ thống chậm đi hay chỉ là cảm giác — và với dịch vụ tài chính, đó là câu hỏi sẽ được đặt ra.

Câu 495 Design Secure Architectures

An e-commerce company operates multiple AWS accounts and has interconnected these accounts in a hub-and-spoke style using the AWS Transit Gateway. Amazon Virtual Private Cloud (Amazon VPCs) have been provisioned across these AWS accounts to facilitate network isolation.

Which of the following solutions would reduce both the administrative overhead and the costs while providing shared access to services required by workloads in each of the VPCs?

  1. A

    Use Transit VPC to reduce cost and share the resources across Amazon Virtual Private Cloud (Amazon VPCs)
  2. B

    Use Fully meshed VPC Peering connection
  3. C

    Build a shared services Amazon Virtual Private Cloud (Amazon VPC)
  4. D

    Use VPCs connected with AWS Direct Connect
Xem giải thích

Đáp án

C — Xây một VPC dịch vụ dùng chung (shared services VPC).

Vì sao đúng

Đề mô tả kiến trúc hub-and-spoke qua Transit Gateway, và hỏi cách giảm CẢ công vận hành LẪN chi phí khi nhiều VPC cần dùng chung một số dịch vụ.

Vấn đề khi mỗi VPC tự dựng dịch vụ chung:

10 VPC, mỗi VPC tự có:
    → NAT Gateway riêng        (~32 USD/tháng mỗi cái)
    → interface VPC endpoint riêng (~0,125 USD/giờ mỗi ENI)
    → Route 53 Resolver endpoint riêng
    → thư mục AD, máy chủ giám sát, kho phần mềm riêng
        ↓
    Chi phí nhân 10 lần, và 10 chỗ phải cấu hình giống nhau

Shared services VPC gom chúng lại:

                    Transit Gateway
                          │
        ┌─────────┬───────┼───────┬─────────┐
        │         │       │       │         │
     VPC ứng    VPC ứng   │    VPC ứng   VPC ứng
     dụng A     dụng B    │    dụng C    dụng D
                          │
              VPC DỊCH VỤ DÙNG CHUNG
              ├── NAT Gateway
              ├── VPC endpoint (SSM, ECR, S3...)
              ├── Route 53 Resolver endpoint
              ├── Active Directory
              └── công cụ giám sát, kho phần mềm

Và khoản tiết kiệm rất cụ thể: | Tài nguyên | 10 VPC riêng | Shared services VPC | |---|---|---| | NAT Gateway | 10 × ~32 USD = 320 USD/tháng | ~64 USD (2 AZ) | | Interface endpoint (5 dịch vụ × 2 AZ) | 10 × 10 × ~9 USD = 900 USD | ~90 USD | | Resolver endpoint | 10 × ~180 USD | ~180 USD |

Và về công vận hành:

✓ cấu hình MỘT LẦN thay vì 10 lần
✓ vá lỗi và cập nhật ở một chỗ
✓ chính sách bảo mật nhất quán
✓ Transit Gateway ĐÃ CÓ SẴN — không cần thêm kết nối nào

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

  • **A. Dùng Transit VPC để giảm chi phí và chia sẻ tài nguyên — đây là phương án gần nhất và nghe rất giống, nhưng nó là kiến trúc CŨ đã bị Transit Gateway thay thế: Transit VPC dùng thiết bị ảo (EC2) chạy phần mềm định tuyến, nghĩa là bạn phải vận hành, vá lỗi và mở rộng chúng — tăng công vận hành chứ không giảm. Và công ty đã có Transit Gateway rồi.
  • **B. Dùng VPC peering đầy đủ (fully meshed) — đi ngược mục tiêu: peering không bắc cầu nên N VPC cần N×(N−1)/2 kết nối. Với 10 VPC là 45 kết nối và 45 bộ bảng định tuyến — công vận hành tăng vọt. Và nó cũng không chia sẻ được dịch vụ chung.
  • **D. Dùng VPC nối bằng Direct Connect — sai mục đích: Direct Connect nối AWS với trung tâm dữ liệu tại chỗ, không phải nối các VPC với nhau.

Ghi nhớ

Kiến trúc mạng nhiều tài khoản — mẫu chuẩn của AWS:

Tài khoản MẠNG:
    ├── Transit Gateway (chia sẻ qua RAM)
    ├── Shared services VPC
    │     ├── NAT Gateway tập trung
    │     ├── VPC endpoint tập trung
    │     └── Route 53 Resolver endpoint
    └── Kết nối tới tại chỗ (DX, VPN)

Tài khoản ỨNG DỤNG:
    └── VPC riêng, gắn vào Transit Gateway

Ba thứ nên đặt trong shared services VPC: | Thứ | Tiết kiệm | |---|---| | NAT Gateway | ~32 USD/tháng mỗi cái, nhân với số VPC | | Interface VPC endpoint | ~9 USD/tháng mỗi ENI | | Route 53 Resolver endpoint | ~180 USD/tháng mỗi cặp | | Active Directory, kho phần mềm, công cụ giám sát | công vận hành |

Và chia sẻ Resolver rule qua RAM là mẫu quan trọng:

aws ram create-resource-share --name chia-se-resolver-rule   --resource-arns arn:aws:route53resolver:...:resolver-rule/rslvr-rr-abc   --principals ou-abc-12345678

Mỗi VPC chỉ cần gắn rule, không cần endpoint riêng.

Ba đặc điểm của Transit Gateway: | Đặc điểm | Chi tiết | |---|---| | Định tuyến BẮC CẦU | khác VPC peering | | Nối tới 5.000 VPC | mở rộng rất tốt | | Nhiều bảng định tuyến | phân đoạn mạng (segmentation) |

Nhiều route table là tính năng quan trọng để cách ly:

Route table "sản xuất":  chỉ VPC prod thấy nhau + shared services
Route table "phát triển": chỉ VPC dev thấy nhau + shared services
    ↓
    Prod và dev KHÔNG nói chuyện được với nhau
    nhưng cả hai đều dùng được dịch vụ chung

Ba lưu ý về chi phí Transit Gateway: | Khoản | Giá tham khảo | |---|---| | Attachment | ~0,05 USD/giờ mỗi VPC (~36 USD/tháng) | | Xử lý dữ liệu | ~0,02 USD/GB | | Peering giữa các TGW | tính như attachment |

Với 20 VPC, riêng phí attachment đã khoảng 720 USD/tháng — nên hợp nhất VPC khi có thể.

Ba cách giảm chi phí mạng nhiều tài khoản: | Cách | Tiết kiệm | |---|---| | Shared services VPC | ← câu này | | VPC sharing qua RAM | loại bỏ hẳn attachment cho các đội dùng chung VPC | | Gateway endpoint cho S3 và DynamoDB | MIỄN PHÍ, tránh phí NAT |

Gateway endpoint là khoản tiết kiệm dễ nhất và hay bị bỏ qua:

Không có gateway endpoint:
    EC2 → NAT Gateway → S3
    → trả ~0,045 USD/GB phí xử lý NAT

Có gateway endpoint (MIỄN PHÍ):
    EC2 → endpoint → S3
    → không phí xử lý

Lưu lượng tới S3 thường rất lớn, nên khoản này đáng kể.

Ba lưu ý khi thiết kế shared services VPC: | Lưu ý | Chi tiết | |---|---| | Phải có sẵn sàng cao | nó là điểm hỏng chung cho mọi VPC | | Trải qua ít nhất hai AZ | NAT Gateway mỗi AZ | | Lập kế hoạch CIDR không chồng lấn | với mọi VPC ứng dụng |

Dòng đầu quan trọng nhất: shared services VPC hỏng nghĩa là mọi VPC mất kết nối Internet và mất DNS lai. Thiết kế nó với mức dự phòng cao hơn VPC ứng dụng.

Ba mẫu định tuyến qua Transit Gateway: | Mẫu | Chi tiết | |---|---| | Egress tập trung | mọi lưu lượng ra Internet qua shared services VPC | | Inspection VPC | mọi lưu lượng đi qua tường lửa tập trung | | Phân đoạn theo môi trường | nhiều route table |

Inspection VPC với AWS Network Firewall:

VPC ứng dụng → TGW → Inspection VPC (Network Firewall) → Internet
    ↓
    Mọi lưu lượng được kiểm tra ở một chỗ
    Chính sách bảo mật nhất quán

Ba công cụ quản lý mạng nhiều tài khoản: | Công cụ | Việc | |---|---| | AWS RAM | chia sẻ TGW, subnet, resolver rule | | Transit Gateway Network Manager | xem toàn cảnh mạng toàn cầu | | VPC Reachability Analyzer | kiểm tra đường đi giữa hai điểm |

Và một lời khuyên: hãy tính lại chi phí mạng mỗi quý. Kiến trúc nhiều tài khoản có xu hướng tích tụ NAT Gateway và VPC endpoint thừa khi các đội tự dựng cho tiện — và một lần rà soát thường tìm ra vài trăm đô mỗi tháng chỉ nằm ở các tài nguyên mạng trùng lặp.

Câu 496 Design High-Performing Architectures

A manufacturing analytics company has a large collection of automated scripts that perform data cleanup, validation, and system integration tasks. These scripts are currently run by a local Linux cron scheduler and have an execution time of up to 30 minutes. The company wants to migrate these scripts to AWS without significant changes, and would prefer a containerized, serverless architecture that automatically scales and can respond to event-based triggers in the future. The solution must minimize infrastructure management.

Which solution will best meet these requirements with minimal refactoring and operational overhead?

  1. A

    Create a container image for each script. Use AWS Step Functions to define a workflow for all scheduled tasks. Use a Wait state to delay execution and run tasks using Step Functions’ RunTask integration with ECS Fargate
  2. B

    Convert each script into a Lambda function and package it in a zip archive. Use Amazon EventBridge Scheduler to run the functions on a fixed schedule. Use Amazon S3 to store function outputs and logs
  3. C

    Package the scripts into a container image. Use Amazon EventBridge Scheduler to define cron-based recurring schedules. Configure EventBridge Scheduler to invoke AWS Fargate tasks using Amazon ECS
  4. D

    Package the scripts into a container image. Deploy the image to AWS Batch with a managed compute environment on Amazon EC2. Define scheduling policies in AWS Batch to trigger jobs according to cron expressions
Xem giải thích

Đáp án

C — Đóng gói script thành container image; dùng EventBridge Scheduler định nghĩa lịch cron; cấu hình Scheduler gọi AWS Fargate task qua Amazon ECS.

Vì sao đúng

Đề nêu năm yêu cầu, và đáp án thoả cả năm: | Yêu cầu | Cơ chế | |---|---| | Script chạy TỚI 30 PHÚT | Fargate không giới hạn thời gian | | Container hoá | ECS task chạy container image | | Serverless, tự co giãn | Fargate — không quản lý máy chủ | | Lịch kiểu cron, sau này mở rộng sang sự kiện | EventBridge Scheduler | | Ít refactor nhất | script chạy nguyên vẹn trong container |

Vế "30 phút" là điểm loại Lambda ngay lập tức:

AWS Lambda: tối đa 15 PHÚT
Script trong đề: tới 30 PHÚT
    ↓
    Lambda KHÔNG dùng được

Và Fargate là lựa chọn đúng:

AWS Fargate:
    ✓ KHÔNG giới hạn thời gian chạy
    ✓ không có EC2 nào để cấp phát hay vá lỗi
    ✓ mỗi task có vCPU và bộ nhớ riêng
    ✓ trả tiền theo thời gian task chạy thật

EventBridge Scheduler gọi thẳng ECS RunTask:

aws scheduler create-schedule --name don-du-lieu-hang-ngay   --schedule-expression "cron(0 2 * * ? *)"   --schedule-expression-timezone "Asia/Ho_Chi_Minh"   --flexible-time-window '{"Mode":"OFF"}'   --target '{
    "Arn": "arn:aws:ecs:ap-northeast-1:123456789012:cluster/cum-script",
    "RoleArn": "<arn-role>",
    "EcsParameters": {
      "TaskDefinitionArn": "arn:aws:ecs:...:task-definition/don-du-lieu:1",
      "LaunchType": "FARGATE",
      "NetworkConfiguration": {"awsvpcConfiguration": {
        "Subnets": ["subnet-a","subnet-b"], "AssignPublicIp": "DISABLED"}}}}'

Và "ít refactor nhất" được đáp ứng:

Script bash hoặc Python hiện tại
    → đóng vào Dockerfile gần như nguyên trạng
    → không phải viết lại thành hàm Lambda
    → không phải chia nhỏ để vừa 15 phút

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

  • **A. Tạo container image cho mỗi script, dùng Step Functions với Wait state để trì hoãn, gọi ECS Fargate qua RunTask — đây là phương án gần nhất và Step Functions thực sự gọi được Fargate, nhưng nó dùng sai công cụ cho việc lập lịch: Wait state để trì hoãn trong một luồng công việc, không phải để thay cron. Bạn vẫn cần một thứ gì đó khởi động luồng đó mỗi ngày — và đó chính là EventBridge Scheduler. Phương án này thêm một tầng không cần thiết.
  • **B. Chuyển mỗi script thành Lambda function — vượt giới hạn kỹ thuật: script chạy tới 30 phút, Lambda tối đa 15 phút. Và chuyển script thành hàm Lambda là refactor đáng kể.
  • **D. Triển khai lên AWS Batch với môi trường tính toán trên EC2 — vi phạm vế serverless: môi trường managed trên EC2 vẫn có instance được cấp phát. (AWS Batch có hỗ trợ Fargate, nhưng phương án nêu rõ EC2.) Và Batch phù hợp cho hàng nghìn job song song, không phải vài script theo lịch.

Ghi nhớ

Chọn dịch vụ compute theo thời gian chạy — bảng phải thuộc: | Thời gian chạy | Dịch vụ | |---|---| | Dưới 15 phút | Lambda | | Trên 15 phút, không quản lý máy | Fargate ← câu này | | Hàng nghìn job song song | AWS Batch | | Cần GPU hoặc kiểm soát sâu | ECS/EKS trên EC2 |

Giới hạn của Lambda — nhắc lại: | Giới hạn | Giá trị | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 10 GB | | Lưu trữ /tmp | 512 MB – 10 GB | | Payload đồng bộ | 6 MB |

Ba dịch vụ lập lịch trên AWS — bảng phân biệt: | Dịch vụ | Đặc điểm | |---|---| | EventBridge Scheduler | chuyên cho lịch, hỗ trợ MÚI GIỜ, hơn 270 dịch vụ đích | | EventBridge Rule (scheduled) | lịch cơ bản, UTC | | ECS Scheduled Task | chỉ cho ECS |

EventBridge Scheduler là dịch vụ mới hơn và tốt hơn: | | Scheduler | Rule (scheduled) | |---|---|---| | Múi giờ | ✅ hỗ trợ | ❌ chỉ UTC | | Lịch một lần (one-time) | ✅ | ❌ | | Số lịch | hàng triệu | 300 rule mỗi bus | | Flexible time window | ✅ trải tải | ❌ | | Số đích hỗ trợ | hơn 270 API | hạn chế hơn |

Và hỗ trợ múi giờ là khác biệt lớn:

--schedule-expression-timezone "Asia/Ho_Chi_Minh"

Nó tự xử lý cả giờ mùa hè — không phải tự quy đổi UTC và sửa lại hai lần mỗi năm.

Ba loại biểu thức lịch: | Loại | Ví dụ | |---|---| | cron() | cron(0 2 * * ? *) — 2 giờ sáng mỗi ngày | | rate() | rate(1 hour) | | at() | at(2026-09-01T02:00:00) — chạy một lần |

Và ký tự L cho ngày cuối tháng:

cron(0 2 L * ? *)   → 2 giờ sáng ngày cuối cùng của mỗi tháng

Ba lưu ý về Fargate task theo lịch: | Lưu ý | Chi tiết | |---|---| | Task cần IAM role riêng | task role cho quyền AWS | | Cần subnet có đường ra | NAT Gateway hoặc VPC endpoint | | Ghi log ra CloudWatch Logs | qua awslogs log driver |

Task definition tối thiểu:

{"family": "don-du-lieu",
 "networkMode": "awsvpc",
 "requiresCompatibilities": ["FARGATE"],
 "cpu": "1024", "memory": "2048",
 "executionRoleArn": "<arn-execution-role>",
 "taskRoleArn": "<arn-task-role>",
 "containerDefinitions": [{
   "name": "script",
   "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/script:latest",
   "logConfiguration": {"logDriver": "awslogs",
     "options": {"awslogs-group": "/ecs/don-du-lieu",
                 "awslogs-region": "ap-northeast-1",
                 "awslogs-stream-prefix": "ecs"}}}]}

Ba khả năng mở rộng sau này mà đề nhắc tới: | Khả năng | Cơ chế | |---|---| | Kích hoạt theo sự kiện S3 | EventBridge rule → ECS RunTask | | Chuỗi nhiều bước | Step Functions điều phối nhiều task | | Thử lại và xử lý lỗi | Step Functions hoặc Scheduler retry policy |

Và đây là lý do container hoá đáng giá:

Cùng một container image dùng được cho:
    ✓ chạy theo lịch (EventBridge Scheduler)
    ✓ chạy theo sự kiện (EventBridge rule)
    ✓ chạy trong luồng công việc (Step Functions)
        ↓
    Không phải viết lại gì

Ba cấu hình xử lý lỗi của Scheduler: | Cấu hình | Việc | |---|---| | MaximumRetryAttempts | số lần thử lại | | MaximumEventAgeInSeconds | bỏ qua nếu quá cũ | | DeadLetterConfig | gửi sự kiện thất bại vào SQS |

Ba cách theo dõi: | Cách | Việc | |---|---| | CloudWatch Logs của task | đầu ra của script | | ECS task exit code | thành công hay thất bại | | EventBridge rule bắt ECS Task State Change | cảnh báo khi task thất bại |

Và cảnh báo khi task thất bại:

{"source": ["aws.ecs"],
 "detail-type": ["ECS Task State Change"],
 "detail": {"lastStatus": ["STOPPED"],
            "stoppedReason": [{"anything-but": {"prefix": "Essential container in task exited"}}],
            "containers": {"exitCode": [{"anything-but": 0}]}}}

Và một lời khuyên khi di chuyển từ cron: hãy giữ nguyên script trong container ở lần đầu, đừng cải tiến gì. Chuyển đổi hạ tầng và sửa mã cùng lúc khiến việc chẩn đoán trở nên rất khó — nếu có gì hỏng, bạn sẽ không biết là do môi trường mới hay do thay đổi trong script.

Câu 497 Design Secure Architectures

A financial institution is transitioning its critical back-office systems to AWS. These systems currently rely on Microsoft SQL Server databases hosted on on-premises infrastructure. The data is highly sensitive and subject to regulatory compliance. The organization wants to enhance security and minimize database management tasks as part of the migration.

Which solution will best meet these goals with the least operational burden?

  1. A

    Migrate the SQL Server databases to Amazon EC2 instances with encrypted EBS volumes. Use an AWS KMS customer managed key to enable encryption
  2. B

    Migrate the SQL Server databases to a Multi-AZ Amazon RDS for SQL Server deployment. Enable encryption at rest by using an AWS Key Management Service (AWS KMS) managed key
  3. C

    Move the SQL Server data into Amazon Timestream to gain time series insights. Use AWS CloudTrail to monitor access to the data
  4. D

    Export the SQL Server databases to CSV format and store them in Amazon S3 with S3 bucket policies for access control. Use AWS Backup for data protection
Xem giải thích

Đáp án

B — Chuyển database SQL Server sang Amazon RDS for SQL Server ở cấu hình Multi-AZ, bật mã hoá at rest bằng khoá do AWS KMS quản lý.

Vì sao đúng

Đề nêu ba yêu cầu, và RDS for SQL Server là lựa chọn duy nhất thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Tăng cường bảo mật | mã hoá at rest bằng KMS + Multi-AZ + trong VPC | | GIẢM THIỂU công quản lý database | RDS lo sao lưu, vá lỗi, chuyển đổi | | Dữ liệu nhạy cảm, có yêu cầu tuân thủ | RDS đủ điều kiện HIPAA, PCI-DSS, SOC |

RDS lo những việc gì:

AWS quản lý:
    ✓ cấp phát và vá lỗi hệ điều hành
    ✓ vá lỗi engine database
    ✓ sao lưu tự động và point-in-time recovery
    ✓ chuyển đổi Multi-AZ tự động
    ✓ giám sát và metric
        ↓
    Bạn chỉ lo lược đồ, truy vấn và phân quyền

Mã hoá at rest bằng KMS:

aws rds create-db-instance --db-instance-identifier db-hau-phong   --engine sqlserver-se --engine-version 15.00.4335.1.v1   --db-instance-class db.m5.2xlarge --allocated-storage 500   --multi-az --storage-encrypted   --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/abc-123   --backup-retention-period 35 --license-model license-included

Và mã hoá bao trùm mọi thứ:

--storage-encrypted mã hoá:
    ✓ dữ liệu trên đĩa
    ✓ snapshot tự động và thủ công
    ✓ read replica
    ✓ log

Multi-AZ cho sẵn sàng cao:

Standby ở AZ khác, sao chép ĐỒNG BỘ
    → tự chuyển đổi khi primary hỏng
    → RPO = 0, không mất giao dịch nào

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

  • **A. Chuyển sang EC2 với volume EBS mã hoá bằng khoá KMS do khách hàng quản lý — đây là phương án gần nhất và cũng cho mã hoá tốt (thậm chí kiểm soát khoá chặt hơn), nhưng nó vi phạm vế công vận hành: bạn phải tự cài SQL Server, tự vá lỗi hệ điều hành và engine, tự dựng cơ chế sao lưu và sẵn sàng cao. Đề yêu cầu "least operational burden".
  • **C. Chuyển dữ liệu sang Amazon Timestream — sai loại database hoàn toàn: Timestream là database chuỗi thời gian cho dữ liệu IoT và metric, không chạy được lược đồ quan hệ và truy vấn T-SQL của hệ thống hậu phòng.
  • **D. Xuất database ra CSV lưu trong S3 với bucket policy — không còn là database nữa: mất hoàn toàn khả năng truy vấn giao dịch, ràng buộc toàn vẹn, và tính nhất quán. Ứng dụng không chạy được trên CSV.

Ghi nhớ

Ba lựa chọn chạy SQL Server trên AWS — bảng cần thuộc: | Lựa chọn | Truy cập OS | Công vận hành | Sẵn sàng cao | |---|---|---|---| | RDS for SQL Server | ❌ | thấp nhất | Multi-AZ dựng sẵn ← câu này | | RDS Custom for SQL Server | ✅ | vừa | Multi-AZ dựng sẵn | | SQL Server trên EC2 | ✅ toàn quyền | cao nhất | tự dựng (Always On AG) |

Quy tắc chọn:

Không cần tuỳ chỉnh OS → RDS thường Cần cài agent hoặc sửa cấu hình OS → RDS Custom Cần Always On Availability Group nhiều node, hoặc SSIS/SSRS → EC2

Ba thứ RDS for SQL Server KHÔNG hỗ trợ: | Không hỗ trợ | Thay thế | |---|---| | SQL Server Agent (hạn chế) | EventBridge Scheduler, Lambda | | SSIS, SSRS, SSAS | có hỗ trợ hạn chế qua tuỳ chọn | | Truy cập hệ điều hành | RDS Custom hoặc EC2 |

Ba lớp mã hoá cho database: | Lớp | Cơ chế | |---|---| | At rest | --storage-encrypted với KMS | | In transit | bắt buộc TLS bằng tham số rds.force_ssl | | Trong cột (nếu cần) | Always Encrypted, hoặc mã hoá ở tầng ứng dụng |

Bắt buộc TLS bằng parameter group:

aws rds modify-db-parameter-group   --db-parameter-group-name pg-sqlserver   --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot"

Ba loại khoá KMS: | Loại | Chi tiết | |---|---| | AWS managed key (aws/rds) | miễn phí, không đổi policy được | | Customer managed key | ~1 USD/tháng, kiểm soát đầy đủ | | AWS owned key | AWS dùng nội bộ |

Với dữ liệu tài chính, customer managed key là lựa chọn đúng — nó cho phép đặt key policy riêng, xoay vòng theo lịch của bạn, và audit chi tiết trong CloudTrail.

Lưu ý quan trọng: KHÔNG bật được mã hoá cho instance đã tồn tại.

Muốn mã hoá database chưa mã hoá:
    ① Chụp snapshot
    ② Sao chép snapshot với --kms-key-id (bản sao được mã hoá)
    ③ Khôi phục instance mới từ snapshot đã mã hoá
    ④ Chuyển ứng dụng sang, xoá instance cũ

Đây là quy trình bốn bước, không phải một công tắc.

Ba mô hình giấy phép SQL Server: | Mô hình | Chi tiết | |---|---| | License Included | giá instance đã gồm giấy phép | | BYOL | dùng giấy phép sẵn có (cần Dedicated Host cho một số phiên bản) | | — | RDS chỉ hỗ trợ License Included cho hầu hết trường hợp |

Ba phiên bản SQL Server trên RDS: | Phiên bản | Đặc điểm | |---|---| | Express | miễn phí, giới hạn 10 GB | | Web | chỉ cho ứng dụng web công khai | | Standard | phổ biến nhất, hỗ trợ Multi-AZ | | Enterprise | đầy đủ tính năng, đắt nhất |

Ba biện pháp bảo mật bổ sung: | Biện pháp | Chi tiết | |---|---| | Database trong PRIVATE subnet | không gán public IP | | Security group tham chiếu SG của ứng dụng | không dùng CIDR | | Mật khẩu trong Secrets Manager, tự xoay vòng | không nhúng trong mã |

Và IAM database authentication cho SQL Server:

RDS for SQL Server hỗ trợ xác thực qua Windows Authentication
    với AWS Managed Microsoft AD
        ↓
    Không cần quản lý mật khẩu database riêng

Ba công cụ di chuyển: | Công cụ | Việc | |---|---| | AWS DMS | chuyển dữ liệu, có CDC — gián đoạn tối thiểu | | Native backup/restore qua S3 | RDS for SQL Server hỗ trợ .bak | | AWS SCT | chỉ cần khi đổi engine |

Native backup/restore là cách đơn giản nhất cho SQL Server:

EXEC msdb.dbo.rds_restore_database
  @restore_db_name='hau_phong',
  @s3_arn_to_restore='arn:aws:s3:::kho-backup/hau_phong.bak';

Ba việc cần làm sau khi di chuyển: | Việc | Chi tiết | |---|---| | Bật Enhanced Monitoring và Performance Insights | | | Đặt backup retention 35 ngày | tối đa cho PITR | | Thử chuyển đổi Multi-AZ | kiểm chứng ứng dụng xử lý được |

Và một lời khuyên cho tổ chức tài chính: hãy bật Database Activity Streams nếu dùng phiên bản hỗ trợ. Nó phát luồng hoạt động database gần thời gian thực vào Kinesis, cho phép giám sát ai truy vấn dữ liệu nhạy cảm nào — thứ mà CloudTrail không ghi lại vì nó chỉ theo dõi lời gọi API quản trị, không theo dõi truy vấn SQL.

Câu 498 Design Cost-Optimized Architectures

A company is looking at storing their less frequently accessed files on AWS that can be concurrently accessed by hundreds of Amazon EC2 instances. The company needs the most cost-effective file storage service that provides immediate access to data whenever needed.

Which of the following options represents the best solution for the given requirements?

  1. A

    Amazon Elastic Block Store (EBS)
  2. B

    Amazon Elastic File System (EFS) Standard storage class
  3. C

    Amazon S3 Standard-Infrequent Access (S3 Standard-IA) storage class
  4. D

    Amazon Elastic File System (EFS) Standard–IA storage class
Xem giải thích

Đáp án

D — Amazon EFS lớp lưu trữ Standard–Infrequent Access (Standard-IA).

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi yêu cầu loại dần các lựa chọn: | Yêu cầu | Loại gì | |---|---| | HÀNG TRĂM EC2 truy cập ĐỒNG THỜI | loại EBS (chỉ gắn một máy) | | Là dịch vụ lưu trữ TỆP (file storage) | loại S3 (kho object) | | Truy cập ÍT THƯỜNG XUYÊN, tiết kiệm nhất | loại EFS Standard, chọn Standard-IA |

Vì sao phải là EFS chứ không phải EBS:

EBS:
    → gắn với MỘT instance tại một thời điểm
    → (multi-attach chỉ tối đa 16 máy, cùng AZ, cần hệ thống tệp đặc biệt)
    → KHÔNG phục vụ hàng trăm máy được

EFS:
    → hàng NGHÌN instance mount đồng thời
    → trải nhiều AZ
    → tự co giãn dung lượng

Và vì sao Standard-IA chứ không phải Standard:

Đề nêu: "LESS FREQUENTLY ACCESSED files"
    ↓
EFS Standard:    ~0,30 USD/GB-tháng
EFS Standard-IA: ~0,025 USD/GB-tháng
        ↓
    Rẻ hơn khoảng 12 lần cho dữ liệu ít truy cập

Và vế "truy cập NGAY khi cần" được đáp ứng:

EFS Standard-IA:
    ✓ độ trễ vẫn ở mức mili giây một chữ số
    ✓ KHÔNG cần restore như Glacier
    ✓ trong suốt với ứng dụng
        ↓
    Đổi lại: có phí truy xuất mỗi GB

Cách bật:

aws efs put-lifecycle-configuration --file-system-id fs-0abc123   --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Quy tắc thứ hai đưa tệp trở lại Standard khi được đọc — tối ưu tự động.

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

  • **B. EFS Standard storage class — đây là phương án gần nhất và đáp ứng đúng mọi yêu cầu kỹ thuật, nhưng nó đắt hơn khoảng 12 lần: Standard dành cho dữ liệu truy cập thường xuyên. Đề nói rõ "less frequently accessed" và hỏi cách tiết kiệm nhất.
  • **C. S3 Standard-IA — sai loại lưu trữ: S3 là kho object truy cập qua HTTP API, không phải hệ thống tệp mount được. Ứng dụng cần đường dẫn tệp POSIX sẽ không dùng được trực tiếp.
  • **A. Amazon EBS — không chia sẻ được cho hàng trăm instance: EBS là ổ đĩa khối gắn với một máy.

Ghi nhớ

Ba loại lưu trữ trên AWS — bảng phải thuộc: | Loại | Dịch vụ | Truy cập đồng thời | |---|---|---| | Block (khối) | EBS, instance store | một instance (multi-attach hạn chế) | | File (tệp) | EFS, FSx | hàng nghìn instance | | Object | S3 | không giới hạn, qua API |

Từ khoá nhận diện:

"shared by many instances", "POSIX", "NFS", "mount" → EFS "single instance", "boot volume", "low latency block" → EBS "objects", "HTTP API", "static website" → S3 "SMB", "Windows" → FSx for Windows

Bốn lớp lưu trữ của EFS: | Lớp | Giá tham khảo | Số AZ | |---|---|---| | Standard | ~0,30 USD/GB | ≥ 3 | | Standard-IA | ~0,025 USD/GB | ≥ 3 | | One Zone | ~0,16 USD/GB | 1 | | One Zone-IA | ~0,0133 USD/GB | 1 |

Và các lớp IA có phí truy xuất:

~0,01 USD/GB mỗi lần đọc
    ↓
    Dữ liệu đọc nhiều → phí truy xuất vượt khoản tiết kiệm
    Dữ liệu đọc thưa  → tiết kiệm rất lớn

Quy tắc chọn One Zone:

Dữ liệu TÁI TẠO ĐƯỢC → One Zone hoặc One Zone-IA Dữ liệu duy nhất, không phục hồi được → Standard hoặc Standard-IA

Ba chính sách lifecycle của EFS: | Chính sách | Việc | |---|---| | TransitionToIA | sau 1, 7, 14, 30, 60, 90 ngày không truy cập | | TransitionToPrimaryStorageClass | đưa về Standard sau 1 lần truy cập | | TransitionToArchive | sang lớp Archive (rẻ nhất, độ trễ cao hơn) |

EFS Archive là lớp mới đáng biết:

EFS Archive:
    → ~0,008 USD/GB-tháng (rẻ nhất)
    → độ trễ vài chục mili giây (cao hơn IA)
    → cho dữ liệu truy cập vài lần mỗi năm

Ba chế độ thông lượng của EFS: | Chế độ | Đặc điểm | |---|---| | Elastic (mặc định mới) | tự co giãn, trả theo lượng dùng thật | | Provisioned | khai trước, tính phí dù không dùng | | Bursting | thông lượng theo dung lượng, có credit |

Elastic là lựa chọn đúng cho hầu hết trường hợp — nó bỏ được việc phải đoán trước nhu cầu thông lượng.

Hai chế độ hiệu năng: | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | độ trễ thấp nhất — dùng cho hầu hết trường hợp | | Max I/O | thông lượng cao hơn nhưng ĐỘ TRỄ CAO HƠN |

Lưu ý: AWS hiện khuyến nghị General Purpose cho gần như mọi trường hợp — với Elastic throughput, nó đã đạt được mức IOPS rất cao mà trước đây phải dùng Max I/O.

Ba lưu ý khi mount EFS từ nhiều instance: | Lưu ý | Chi tiết | |---|---| | Một mount target MỖI AZ | thiếu thì trả phí truyền chéo AZ | | Mở cổng 2049 (NFS) trong security group | | | Cài amazon-efs-utils | để dùng -t efs với TLS và IAM |

sudo mount -t efs -o tls,iam fs-0abc123:/ /du-lieu

Ba cách giảm chi phí EFS: | Cách | Tiết kiệm | |---|---| | Lifecycle sang IA | ~90% cho tệp ít truy cập ← câu này | | One Zone cho dữ liệu tái tạo được | ~47% | | Elastic throughput | không trả cho thông lượng không dùng |

Ba lớp bảo mật cho EFS: | Lớp | Cơ chế | |---|---| | Mạng | security group của mount target | | Danh tính | IAM policy + file system policy | | Hệ thống tệp | quyền POSIX + Access Point |

Và mã hoá at rest phải bật LÚC TẠO:

aws efs create-file-system --encrypted --kms-key-id <arn>

Không bật được sau — phải tạo file system mới và chuyển dữ liệu.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | StorageBytes theo lớp | bao nhiêu đã chuyển sang IA | | MeteredIOBytes | thông lượng thực tế | | ClientConnections | số máy đang mount |

Và một lời khuyên: hãy bật cả hai quy tắc lifecycle — chuyển sang IA sau 30 ngày và đưa về Standard sau một lần truy cập. Chỉ bật quy tắc đầu thì tệp bỗng được dùng nhiều sẽ nằm mãi ở IA và tích tụ phí truy xuất, có khi vượt cả khoản tiết kiệm từ giá lưu trữ.

Câu 499 Design Secure Architectures

A social media application is hosted on an Amazon EC2 fleet running behind an Application Load Balancer. The application traffic is fronted by an Amazon CloudFront distribution. The engineering team wants to decouple the user authentication process for the application, so that the application servers can just focus on the business logic.

As a Solutions Architect, which of the following solutions would you recommend to the development team so that it requires minimal development effort?

  1. A

    Use Amazon Cognito Authentication via Cognito User Pools for your Application Load Balancer
  2. B

    Use Amazon Cognito Authentication via Cognito Identity Pools for your Amazon CloudFront distribution
  3. C

    Use Amazon Cognito Authentication via Cognito Identity Pools for your Application Load Balancer
  4. D

    Use Amazon Cognito Authentication via Cognito User Pools for your Amazon CloudFront distribution
Xem giải thích

Đáp án

A — Dùng Amazon Cognito Authentication qua Cognito User Pools cho Application Load Balancer.

Vì sao đúng

Đề nêu hai yêu cầu, và đáp án ghép đúng cả hai: | Yêu cầu | Cơ chế | |---|---| | Tách xác thực khỏi máy chủ ứng dụng | ALB tự xác thực trước khi chuyển tiếp | | Ít công phát triển nhất | cấu hình một listener rule, không viết mã |

ALB có tính năng xác thực dựng sẵn:

Người dùng → ALB
    ↓ ALB kiểm tra: đã đăng nhập chưa?
    ↓ chưa → chuyển tới trang đăng nhập của Cognito
    ↓ đăng nhập xong → ALB đặt cookie phiên
    ↓ rồi mới chuyển request tới EC2
        ↓
    Máy chủ ứng dụng nhận request ĐÃ ĐƯỢC XÁC THỰC

Và ALB truyền thông tin người dùng qua header: | Header | Nội dung | |---|---| | x-amzn-oidc-identity | định danh người dùng | | x-amzn-oidc-accesstoken | access token | | x-amzn-oidc-data | JWT chứa claim của người dùng |

Ứng dụng chỉ cần đọc header, không phải xử lý đăng nhập:

import base64, json
def lay_nguoi_dung(request):
    du_lieu = request.headers['x-amzn-oidc-data']
    payload = du_lieu.split('.')[1]
    payload += '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload))

Cấu hình chỉ là một listener rule:

aws elbv2 create-rule --listener-arn <arn-listener> --priority 10   --conditions '[{"Field":"path-pattern","Values":["/*"]}]'   --actions '[
    {"Type":"authenticate-cognito","Order":1,
     "AuthenticateCognitoConfig":{
       "UserPoolArn":"<arn-user-pool>",
       "UserPoolClientId":"<client-id>",
       "UserPoolDomain":"dang-nhap-ung-dung",
       "SessionTimeout":86400,
       "OnUnauthenticatedRequest":"authenticate"}},
    {"Type":"forward","Order":2,"TargetGroupArn":"<arn-tg>"}]'

Và User Pools là thành phần đúng:

Cognito User Pools:  DANH BẠ NGƯỜI DÙNG — đăng ký, đăng nhập, MFA
Cognito Identity Pools: cấp THÔNG TIN ĐĂNG NHẬP AWS tạm thời
    ↓
    Đề cần xác thực người dùng → User Pools

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

  • **C. Dùng Cognito Identity Pools cho Application Load Balancer — đây là phương án gần nhất và có vế ALB đúng, nhưng nó sai thành phần Cognito: Identity Pools (federated identities) cấp thông tin đăng nhập AWS tạm thời để ứng dụng gọi thẳng S3 hay DynamoDB. Nó không phải cơ chế xác thực người dùng, và ALB chỉ tích hợp với User Pools.
  • **D. Dùng Cognito User Pools cho CloudFront — CloudFront không có tính năng xác thực dựng sẵn: muốn xác thực ở CloudFront phải viết Lambda@Edge hoặc CloudFront Function — đúng thứ "công phát triển" mà đề muốn tránh.
  • **B. Dùng Cognito Identity Pools cho CloudFront — kết hợp cả hai lỗi trên.

Ghi nhớ

Cognito User Pools và Identity Pools — bảng phân biệt cốt lõi: | | User Pools | Identity Pools | |---|---|---| | Việc | XÁC THỰC — danh bạ người dùng | UỶ QUYỀN — cấp thông tin đăng nhập AWS | | Trả về | JWT (id token, access token) | thông tin đăng nhập AWS tạm thời qua STS | | Dùng để | đăng nhập vào ứng dụng | gọi thẳng S3, DynamoDB từ client | | Tích hợp ALB | ✅ | ❌ |

Và hai thứ này DÙNG CHUNG được:

User Pool xác thực người dùng → trả JWT
    ↓
Identity Pool nhận JWT → cấp thông tin đăng nhập AWS
    ↓
Ứng dụng di động tải ảnh thẳng lên S3

Ba nơi tích hợp Cognito không cần viết mã: | Nơi | Cơ chế | |---|---| | Application Load Balancer | authenticate-cognito action ← câu này | | API Gateway | Cognito authorizer | | AppSync | Cognito làm nguồn xác thực |

Và CloudFront cần viết mã: | Cách | Chi tiết | |---|---| | Lambda@Edge | kiểm tra JWT ở điểm biên | | CloudFront Function | nhẹ hơn nhưng hạn chế hơn | | Signed URL / signed cookie | cho nội dung tĩnh |

Ba tuỳ chọn của authenticate-cognito: | Tuỳ chọn | Việc | |---|---| | OnUnauthenticatedRequest: authenticate | chuyển tới trang đăng nhập | | OnUnauthenticatedRequest: deny | trả về 401 (cho API) | | OnUnauthenticatedRequest: allow | cho qua, ứng dụng tự xử lý | | SessionTimeout | thời gian phiên (mặc định 7 ngày) |

Và ALB cũng hỗ trợ OIDC bất kỳ:

{"Type": "authenticate-oidc",
 "AuthenticateOidcConfig": {
   "Issuer": "https://accounts.google.com",
   "AuthorizationEndpoint": "...",
   "TokenEndpoint": "...",
   "UserInfoEndpoint": "...",
   "ClientId": "...", "ClientSecret": "..."}}

Nhờ đó dùng được Google, Okta, Entra ID mà vẫn không viết mã.

Ba tính năng của Cognito User Pools: | Tính năng | Chi tiết | |---|---| | Đăng ký, đăng nhập, quên mật khẩu dựng sẵn | có giao diện lưu trữ sẵn (hosted UI) | | MFA (SMS, TOTP) | | | Liên kết mạng xã hội và SAML | Google, Facebook, Apple, doanh nghiệp | | Advanced security | phát hiện đăng nhập bất thường, mật khẩu bị lộ |

Hosted UI là điểm quan trọng cho "ít công phát triển nhất":

Cognito cung cấp sẵn trang đăng nhập, đăng ký, quên mật khẩu
    → tuỳ chỉnh được logo và CSS
    → không phải viết giao diện nào

Ba lưu ý khi cấu hình: | Lưu ý | Chi tiết | |---|---| | Listener PHẢI là HTTPS | xác thực chỉ hoạt động trên HTTPS | | Callback URL phải khớp chính xác | https://ten-mien/oauth2/idpresponse | | ALB cần đường ra Internet tới Cognito | qua Internet Gateway hoặc NAT |

Dòng đầu là lỗi cấu hình phổ biến nhất — thử trên listener HTTP sẽ không hoạt động và thông báo lỗi không rõ ràng.

Ba lợi ích của việc tách xác thực ra ALB: | Lợi ích | Chi tiết | |---|---| | Máy chủ ứng dụng chỉ lo nghiệp vụ | ← yêu cầu của đề | | Xác thực nhất quán cho mọi dịch vụ sau ALB | | | Lỗ hổng xác thực do tự viết bị loại bỏ | AWS lo phần khó |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Cognito | miễn phí tới 10.000 người dùng hoạt động hằng tháng | | Advanced security | tính phí thêm | | ALB authentication | không có phí riêng |

Ba biện pháp bảo mật nên bật: | Biện pháp | Chi tiết | |---|---| | MFA cho tài khoản có đặc quyền | | | Advanced security features | phát hiện đăng nhập từ vị trí bất thường | | Chính sách mật khẩu mạnh | độ dài và độ phức tạp |

Và một lời khuyên: hãy kiểm chứng chữ ký của JWT trong header x-amzn-oidc-data nếu ứng dụng dựa vào nó để phân quyền. ALB ký JWT đó, và ứng dụng nên xác minh chữ ký thay vì tin tưởng mù quáng — nếu ai đó gọi được thẳng vào EC2 không qua ALB, họ có thể tự đặt header đó.

Câu 500 Design High-Performing Architectures

A global media agency is developing a cultural analysis project to explore how major sports stories have evolved over the last five years. The team has collected thousands of archived news bulletins and magazine spreads stored in PDF format. These documents are rich in unstructured text and come from various sources with differing layouts and font styles. The agency wants to better understand how public tone and narrative have shifted over time. The team has chosen to use Amazon Textract for its ability to accurately extract printed and scanned text from complex PDF layouts. They need a solution that can then analyze the emotional tone and subject matter of the extracted text with the least possible operational burden, using fully managed AWS services where possible.

Which solution will best meet these requirements?

  1. A

    Ingest the extracted data into Amazon Redshift using AWS Glue, and use Amazon Rekognition to analyze the tone of the document layouts for sentiment classification.
  2. B

    Process the extracted output with AWS Lambda to convert the text into CSV format. Query the data using Amazon Athena and visualize it using Amazon QuickSight.
  3. C

    Send the extracted text to Amazon Comprehend for entity detection and sentiment analysis. Store the results in Amazon S3 for further access or visualization.
  4. D

    Use Amazon SageMaker to train a custom sentiment analysis model. Store the model outputs in Amazon DynamoDB for structured querying by analysts
Xem giải thích

Đáp án

C — Gửi văn bản đã trích xuất sang Amazon Comprehend để nhận diện thực thể và phân tích cảm xúc; lưu kết quả vào S3 để truy cập hoặc trực quan hoá.

Vì sao đúng

Đề nêu ba yêu cầu, và Comprehend là dịch vụ đúng cho cả ba: | Yêu cầu | Cơ chế | |---|---| | Phân tích SẮC THÁI CẢM XÚC của văn bản | Comprehend sentiment analysis | | Phân tích CHỦ ĐỀ | entity detection + topic modeling | | Ít công vận hành nhất, dịch vụ được quản lý | Comprehend là dịch vụ AI được quản lý hoàn toàn |

Đường ống hoàn chỉnh:

PDF trong S3
    ↓ Amazon Textract (đề đã chọn)
Văn bản thuần
    ↓ Amazon Comprehend
    ├── DetectSentiment      → tích cực / tiêu cực / trung tính / lẫn lộn
    ├── DetectEntities       → người, tổ chức, địa điểm, sự kiện
    ├── DetectKeyPhrases     → cụm từ chính
    └── Topic modeling       → chủ đề nổi bật theo thời gian
        ↓
    Kết quả vào S3 → QuickSight hoặc Athena

Phân tích cảm xúc:

aws comprehend batch-detect-sentiment --language-code en   --text-list "file://van-ban.json"

{"Sentiment": "NEGATIVE",
 "SentimentScore": {"Positive": 0.05, "Negative": 0.87,
                    "Neutral": 0.06, "Mixed": 0.02}}

Và điểm số chi tiết cho phép đo sự dịch chuyển theo thời gian:

Gom điểm cảm xúc theo tháng qua 5 năm
    → vẽ được đường xu hướng
    → thấy được giọng điệu công chúng thay đổi thế nào
        ↓
    Đúng mục tiêu "how public tone has shifted over time"

Với hàng nghìn tài liệu, dùng job bất đồng bộ rẻ hơn:

aws comprehend start-sentiment-detection-job   --input-data-config S3Uri=s3://kho-van-ban/,InputFormat=ONE_DOC_PER_FILE   --output-data-config S3Uri=s3://kho-ket-qua/   --data-access-role-arn <arn> --language-code en

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

  • **B. Dùng Lambda chuyển văn bản thành CSV, truy vấn bằng Athena, trực quan hoá bằng QuickSight — đây là phương án gần nhất và các dịch vụ đều hợp lý cho phần trực quan hoá, nhưng nó thiếu hoàn toàn bước PHÂN TÍCH: chuyển sang CSV rồi truy vấn SQL không cho biết gì về cảm xúc hay chủ đề. Đó là phần khó nhất của bài toán và không có công cụ nào trong phương án giải quyết nó.
  • **D. Dùng SageMaker huấn luyện mô hình phân tích cảm xúc tuỳ chỉnh — vi phạm vế công vận hành: phải chuẩn bị dữ liệu gán nhãn, huấn luyện, đánh giá, triển khai và bảo trì endpoint. Comprehend làm việc đó sẵn với chất lượng tốt cho tiếng Anh thông thường.
  • **A. Nạp vào Redshift qua Glue, dùng Amazon Rekognition phân tích "sắc thái của bố cục tài liệu" — sai dịch vụ hoàn toàn: Rekognition phân tích ẢNH và VIDEO, nó không đọc văn bản để đánh giá cảm xúc. "Sắc thái của bố cục tài liệu" không phải khái niệm có thật.

Ghi nhớ

Các dịch vụ AI được quản lý của AWS — bảng phải thuộc: | Dịch vụ | Đầu vào → đầu ra | |---|---| | Textract | tài liệu quét → văn bản, bảng, biểu mẫu | | Comprehend | văn bản → cảm xúc, thực thể, chủ đề, PII, ngôn ngữ | | Comprehend Medical | văn bản y tế → PHI, thuốc, chẩn đoán | | Translate | văn bản → dịch sang ngôn ngữ khác | | Transcribe | giọng nói → văn bản | | Polly | văn bản → giọng nói | | Rekognition | ảnh, video → nhãn, khuôn mặt, văn bản trong ảnh | | Lex | hội thoại → ý định | | Kendra | câu hỏi → tài liệu liên quan | | Personalize | hành vi → gợi ý |

Từ khoá nhận diện:

"sentiment", "entities", "topics", "unstructured TEXT" → Comprehend "extract text from scanned PDF" → Textract "analyze images or video" → Rekognition "train custom model", "no managed service fits" → SageMaker

Textract và Rekognition đều "đọc" văn bản — phân biệt: | | Textract | Rekognition DetectText | |---|---|---| | Cho | tài liệu (PDF, biểu mẫu, bảng) | văn bản trong ẢNH cảnh vật | | Giữ cấu trúc | ✅ bảng, biểu mẫu, quan hệ khoá–giá trị | ❌ | | Phù hợp | hoá đơn, hợp đồng, báo chí quét ← câu này | biển hiệu, biển số xe |

Năm khả năng chính của Comprehend: | Khả năng | Trả về | |---|---| | DetectSentiment | tích cực / tiêu cực / trung tính / lẫn lộn + điểm số | | DetectEntities | người, tổ chức, địa điểm, ngày, số lượng, sự kiện | | DetectKeyPhrases | cụm từ chính | | DetectPiiEntities | thông tin cá nhân — dùng để che | | Topic modeling | chủ đề nổi bật trong một tập tài liệu | | DetectTargetedSentiment | cảm xúc ĐỐI VỚI từng thực thể cụ thể |

DetectTargetedSentiment rất phù hợp với đề:

Câu: "Đội A chơi xuất sắc nhưng trọng tài gây thất vọng"
    DetectSentiment:          MIXED (lẫn lộn)
    DetectTargetedSentiment:  Đội A → POSITIVE
                              trọng tài → NEGATIVE
        ↓
    Với phân tích văn hoá thể thao, đây là thứ cần

Hai chế độ chạy Comprehend: | Chế độ | Đặc điểm | |---|---| | Synchronous (real-time) | tối đa 5.000 byte mỗi tài liệu | | Asynchronous batch job | rẻ hơn, xử lý cả tập tài liệu ← phù hợp với đề |

Với hàng nghìn bản tin lưu trữ, batch job là lựa chọn đúng.

Ba tuỳ chỉnh của Comprehend: | Tuỳ chỉnh | Việc | |---|---| | Custom classification | phân loại tài liệu theo nhãn riêng | | Custom entity recognition | nhận diện loại thực thể riêng | | — | cả hai KHÔNG cần kỹ năng học máy |

Custom classification có thể hữu ích:

Huấn luyện phân loại bản tin theo môn thể thao, giải đấu, chủ đề
    → cung cấp vài trăm mẫu đã gán nhãn
    → Comprehend tự huấn luyện

Ba lưu ý về ngôn ngữ: | Lưu ý | Chi tiết | |---|---| | Sentiment hỗ trợ nhiều ngôn ngữ | tiếng Anh, Tây Ban Nha, Pháp, Đức, Ý, Bồ Đào Nha... | | Chất lượng tốt nhất với tiếng Anh | | | DetectDominantLanguage để phát hiện trước | với tài liệu đa ngôn ngữ |

Ba lưu ý về Textract cho tài liệu cũ: | Lưu ý | Chi tiết | |---|---| | Bản quét chất lượng thấp giảm độ chính xác | báo cũ, mực nhoè | | Kiểm tra Confidence của từng khối | lọc kết quả kém | | Bố cục nhiều cột cần xử lý cẩn thận | báo chí thường có nhiều cột |

Dòng cuối rất quan trọng với báo chí quét: Textract trả về vị trí của từng khối văn bản, và cần sắp xếp lại theo cột để câu văn không bị trộn lẫn.

Ba lưu ý về chi phí: | Dịch vụ | Cách tính | |---|---| | Textract | theo trang | | Comprehend | theo đơn vị 100 ký tự | | S3 và Athena | lưu trữ và dữ liệu quét |

Và một lời khuyên: hãy lưu cả văn bản thô lẫn kết quả phân tích vào S3 dạng Parquet, phân vùng theo năm và tháng. Dự án phân tích văn hoá sẽ muốn hỏi những câu chưa lường trước, và việc có sẵn dữ liệu đã cấu trúc trong data lake cho phép trả lời chúng bằng một truy vấn Athena thay vì chạy lại toàn bộ đường ống.