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

Đáp án

C — Không cần làm gì. Amazon S3 tự động quản lý hiệu năng ở quy mô này.

Vì sao đúng

Đề cho hai con số cụ thể, và cả hai đều nằm trong giới hạn mặc định của S3:

Đề yêu cầu: 2.000 PUT/giây và 3.500 GET/giây

Giới hạn của S3 (cho MỖI PREFIX):
    3.500 PUT / COPY / POST / DELETE mỗi giây
    5.500 GET / HEAD mỗi giây
        ↓
    2.000 < 3.500  ✅
    3.500 < 5.500  ✅

Nên S3 phục vụ được ngay mà không cần tối ưu gì.

Và quan trọng hơn: lời khuyên "thêm tiền tố ngẫu nhiên" đã LỖI THỜI từ tháng 7/2018.

TRƯỚC 2018:
    S3 phân vùng theo tiền tố tên khoá
    → khoá tuần tự (log-0001, log-0002...) dồn vào một phân vùng
    → cần thêm hash ngẫu nhiên vào đầu tên để phân tán

TỪ 2018:
    S3 TỰ ĐỘNG mở rộng phân vùng
    → không còn cần tiền tố ngẫu nhiên
    → AWS đã cập nhật tài liệu và khuyến nghị bỏ cách làm này

Và tiền tố ngẫu nhiên còn có hại:

Tên khoá ngẫu nhiên:
    ✗ khó liệt kê theo nhóm
    ✗ khó dùng lifecycle rule theo prefix
    ✗ khó gỡ lỗi và vận hành

Nếu thực sự cần vượt giới hạn, cách đúng là dùng NHIỀU PREFIX có ý nghĩa:

s3://kho/nam=2026/thang=08/ngay=30/
s3://kho/nam=2026/thang=08/ngay=31/
    → mỗi prefix có giới hạn RIÊNG
    → 10 prefix → 35.000 PUT/giây, 55.000 GET/giây

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

• **B. Thêm tiền tố ngẫu nhiên vào tên khoá — đây là phương án gần nhất và từng là lời khuyên chính thức của AWS, nhưng nó đã lỗi thời từ 2018. Với mức tải trong đề, nó hoàn toàn không cần thiết và còn làm việc vận hành khó hơn.
• **D. Dùng quy ước đặt tên dự đoán được như số thứ tự hoặc chuỗi ngày giờ — đây từng là điều bị KHUYẾN CÁO TRÁNH (trước 2018) vì gây dồn phân vùng. Hiện nay nó vô hại, nhưng cũng không phải "biện pháp tối ưu hiệu năng" nào.
• **A. Dùng Byte-Range Fetch để lấy nhiều dải dữ liệu mỗi request — giải quyết vấn đề khác: byte-range fetch tăng tốc việc tải một object LỚN bằng cách lấy song song nhiều phần. Nó không liên quan tới việc xử lý nhiều request đồng thời.

Ghi nhớ

Giới hạn hiệu năng của S3 — bảng cần thuộc: | Thao tác | Giới hạn mỗi PREFIX mỗi giây | |---|---| | PUT / COPY / POST / DELETE | 3.500 | | GET / HEAD | 5.500 |

Điểm mấu chốt: giới hạn tính theo PREFIX, không phải theo bucket.

Số prefix KHÔNG giới hạn
    → chia dữ liệu thành nhiều prefix
    → thông lượng nhân theo số prefix

Và "prefix" nghĩa là gì:

s3://kho/du-lieu/2026/08/tep.json
        └───── prefix ─────┘
    → mọi phần đường dẫn trước tên tệp

Cấu trúc prefix tốt cho khối lượng lớn:

s3://kho/loai=clickstream/nam=2026/thang=08/ngay=30/
    → vừa phân tán tải
    → vừa dùng được cho phân vùng Athena
    → vừa dễ áp lifecycle rule

Ba kỹ thuật tối ưu hiệu năng S3 — mỗi cái cho một vấn đề: | Kỹ thuật | Giải quyết | |---|---| | Nhiều prefix | vượt giới hạn request mỗi giây | | Multipart upload | tải LÊN tệp lớn nhanh hơn, bắt buộc nếu trên 5 GB | | Byte-range fetch | tải XUỐNG tệp lớn nhanh hơn (song song) | | S3 Transfer Acceleration | người dùng ở xa Region của bucket | | CloudFront | nội dung được đọc lặp lại |

Ba giới hạn kích thước của S3: | Giới hạn | Giá trị | |---|---| | Object tối đa | 5 TB | | Một lần PUT | 5 GB | | Số phần multipart | 1–10.000 |

Và với tài sản tĩnh của ứng dụng web như đề mô tả, CloudFront là cải thiện lớn hơn nhiều:

CloudFront trước S3:
    ✓ cache tại hơn 600 điểm biên → độ trễ thấp hơn nhiều
    ✓ giảm hẳn số request tới S3
    ✓ S3 → CloudFront MIỄN PHÍ (S3 → Internet ~0,09 USD/GB)
    ✓ có HTTPS, WAF, chống DDoS

Với 3.500 GET/giây cho tài sản tĩnh, tỷ lệ cache hit sẽ rất cao — S3 chỉ nhận một phần nhỏ số request đó.

Ba lưu ý về mô hình nhất quán của S3: | Lưu ý | Chi tiết | |---|---| | Từ 12/2020, S3 nhất quán MẠNH (strong consistency) | ghi xong đọc ngay thấy dữ liệu mới | | Không cần cấu hình gì | tự động, không tính phí thêm | | Áp cho mọi thao tác | PUT, DELETE, LIST |

Trước 2020, S3 chỉ nhất quán cuối cùng cho thao tác ghi đè và xoá — nhiều tài liệu cũ vẫn nhắc tới hạn chế này, nhưng nó không còn đúng.

Ba thực hành tốt khi thiết kế tên khoá: | Thực hành | Lý do | |---|---| | Dùng prefix có Ý NGHĨA | dễ vận hành, dễ áp lifecycle, dễ phân vùng | | Tránh ký tự đặc biệt | một số ký tự cần mã hoá URL | | Nhất quán về cấu trúc | giúp tự động hoá và phân tích |

Ba lưu ý về giới hạn khác: | Giới hạn | Giá trị | |---|---| | Số bucket mỗi tài khoản | 100 (tăng được tới 1.000) | | Số object mỗi bucket | KHÔNG giới hạn | | Kích thước tên khoá | tối đa 1.024 byte |

Nếu vẫn cần thêm thông lượng, hai hướng: | Hướng | Chi tiết | |---|---| | Thêm prefix | mỗi prefix một bộ giới hạn riêng | | Yêu cầu tăng hạn mức | AWS hỗ trợ mức cao hơn cho trường hợp đặc biệt |

Và cách theo dõi xem có chạm giới hạn không:

CloudWatch metric của S3:
    5xxErrors → mã 503 SlowDown nghĩa là đang bị giới hạn

Nếu thấy 503 SlowDown, đó là lúc cần chia prefix — không phải trước đó.

Và một lời khuyên chung: đừng tối ưu trước khi đo. Rất nhiều kiến trúc S3 phức tạp hoá tên khoá vì lời khuyên lỗi thời từ trước 2018, rồi phải sống chung với cấu trúc dữ liệu khó vận hành mà chẳng được lợi gì.

Đáp án

A — Amazon FSx for Windows File Server.

Vì sao đúng

Đề liệt kê bốn yêu cầu, và cả bốn đều là đặc điểm riêng của FSx for Windows: | Yêu cầu | FSx for Windows | |---|---| | Hỗ trợ đầy đủ giao thức SMB | ✅ SMB 2.0 tới 3.1.1 | | Windows NTFS | ✅ hệ thống tệp NTFS thật | | Tích hợp Active Directory | ✅ join domain, quyền theo AD | | Distributed File System (DFS) | ✅ hỗ trợ DFS Namespace và DFS Replication |

Và đây không phải mô phỏng — FSx for Windows chạy trên Windows Server thật:

Được xây trên Windows Server
    → tương thích hoàn toàn với ứng dụng Windows
    → giữ nguyên ACL của NTFS
    → hỗ trợ shadow copy (Previous Versions)
    → hỗ trợ user quota

Ba yêu cầu trong đề đều là thứ mà chỉ Windows mới có:

NTFS  → hệ thống tệp riêng của Windows
AD    → dịch vụ thư mục của Microsoft
DFS   → tính năng của Windows Server

Không dịch vụ nào khác của AWS cung cấp cả ba.

Và nó là dịch vụ được quản lý hoàn toàn:

AWS lo: vá lỗi, sao lưu tự động hằng ngày, chịu lỗi Multi-AZ
Bạn lo: quyền truy cập và dữ liệu

Cấu hình Multi-AZ cho sẵn sàng cao:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 300 --storage-type SSD   --subnet-ids subnet-1a subnet-1b   --windows-configuration     DeploymentType=MULTI_AZ_1,ThroughputCapacity=32,ActiveDirectoryId=d-1234567890

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

• **D. Amazon FSx for Lustre — đây là phương án gần nhất vì cũng là FSx và cũng dành cho HPC, nhưng nó sai giao thức và hệ điều hành: Lustre là hệ thống tệp song song cho Linux, dùng giao thức Lustre (POSIX). Nó không hỗ trợ SMB, NTFS, AD hay DFS.
• **C. AWS DataSync — là công cụ DI CHUYỂN dữ liệu, không phải hệ thống tệp: nó đồng bộ tệp giữa các kho lưu trữ. Không có gì để mount cả.
• **B. S3 Glacier Deep Archive — là lớp lưu trữ dài hạn: thời gian truy xuất 12–48 giờ, không phải hệ thống tệp, không hỗ trợ SMB.

Ghi nhớ

Bốn dịch vụ trong họ Amazon FSx — bảng cần thuộc: | Dịch vụ | Giao thức | Hệ điều hành | Dùng cho | |---|---|---|---| | FSx for Windows File Server | SMB | Windows | ứng dụng Windows, AD, chia sẻ tệp ← câu này | | FSx for Lustre | Lustre (POSIX) | Linux | HPC, học máy — thông lượng cực cao | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | cả hai | môi trường lai có NetApp | | FSx for OpenZFS | NFS | Linux | thay thế máy chủ ZFS |

Từ khoá nhận diện trong đề thi:

"SMB", "NTFS", "Active Directory", "DFS", "Windows" → FSx for Windows "Lustre", "HPC", "machine learning", "hundreds of GB/s" → FSx for Lustre "NFS", "Linux", "POSIX", "shared file system" → EFS "multi-protocol", "NetApp", "snapshot, clone" → FSx for NetApp ONTAP

Các dịch vụ lưu trữ tệp của AWS: | Dịch vụ | Giao thức | Đa AZ | |---|---|---| | Amazon EFS | NFS | ✅ mặc định | | FSx for Windows | SMB | ✅ (Multi-AZ deployment) | | FSx for Lustre | Lustre | Single-AZ (có tuỳ chọn persistent) | | EBS | khối (không phải tệp) | ❌ |

Ba tính năng đáng chú ý của FSx for Windows: | Tính năng | Chi tiết | |---|---| | Data deduplication | giảm tới 50–60% dung lượng với dữ liệu văn phòng | | Shadow copy | người dùng tự khôi phục phiên bản cũ qua "Previous Versions" | | User quota | giới hạn dung lượng theo người dùng | | Sao lưu tự động hằng ngày | giữ 0–90 ngày |

Data deduplication đặc biệt hiệu quả với chia sẻ tệp của người dùng — rất nhiều bản sao của cùng tài liệu:

Enable-FSxDedup -FileSystemId fs-0abc123

Hai loại triển khai: | Loại | Đặc điểm | |---|---| | Single-AZ | rẻ hơn, phù hợp dev/test | | Multi-AZ | standby ở AZ khác, tự failover — cho sản xuất |

Hai loại lưu trữ: | Loại | Phù hợp | |---|---| | SSD | độ trễ thấp, IOPS cao — ứng dụng chính | | HDD | rẻ hơn nhiều — chia sẻ tệp thông thường |

Ba lựa chọn tích hợp Active Directory: | Lựa chọn | Chi tiết | |---|---| | AWS Managed Microsoft AD | AD thật trên AWS | | AD tự quản lý | AD của bạn trên EC2 hoặc tại chỗ | | — | FSx BẮT BUỘC phải join một AD |

Dòng cuối là điều kiện tiên quyết — không có AD thì không tạo được FSx for Windows.

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | ThroughputCapacity khai riêng với dung lượng | 8–2.048 MB/giây | | Có thể tăng sau khi tạo | không cần dừng | | Cache trong bộ nhớ cho dữ liệu nóng | tự động |

Và với HPC trên Windows như đề mô tả, hãy chọn throughput capacity đủ lớn — nghẽn I/O thường là nút thắt của mô phỏng, chứ không phải CPU.

Ba cách di chuyển dữ liệu vào FSx: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh, tự động, có xác minh | | Robocopy | công cụ quen thuộc của Windows | | AWS Snowball | khối lượng rất lớn |

Và một tính năng đáng biết: FSx File Gateway.

Truy cập FSx for Windows từ trung tâm dữ liệu tại chỗ
    → có cache cục bộ
    → giảm độ trễ cho người dùng ở xa

Và một lời khuyên về chi phí: FSx for Windows tính phí theo dung lượng, throughput capacity, và sao lưu. Với chia sẻ tệp thông thường, chọn HDD và bật data deduplication thường giảm chi phí rất đáng kể — chỉ dùng SSD cho phần dữ liệu thực sự cần độ trễ thấp.

Đáp án

B và D.

• B — Dùng Application Load Balancer với Weighted Target Group chia lưu lượng 50/50
• D — Dùng Route 53 với Weighted routing policy chia lưu lượng 50/50

Vì sao đúng

Đề cần chia chính xác 50% lưu lượng cho mỗi bên trong quá trình di chuyển — và có đúng hai cách làm điều đó.

D — Route 53 weighted routing, ở tầng DNS:

Hai bản ghi cùng tên, mỗi bản một trọng số:
    Bản ghi 1 → ALB trên AWS        weight 50
    Bản ghi 2 → IP hệ thống tại chỗ  weight 50
        ↓
Route 53 trả về từng bản ghi theo tỷ lệ

B — ALB weighted target group, ở tầng ứng dụng:

Một ALB, một listener rule, HAI target group:
    Target group A → EC2 instance trên AWS       weight 50
    Target group B → IP máy chủ tại chỗ          weight 50
        ↓
ALB chia lưu lượng theo TỪNG REQUEST

Và điểm mấu chốt khiến B khả thi: ALB hỗ trợ target kiểu IP.

Target type = ip
    → target có thể là địa chỉ IP RIÊNG bất kỳ mà ALB vươn tới được
    → bao gồm máy chủ tại chỗ qua DIRECT CONNECT
        ↓
Đề nói rõ: "VPC is connected to on-premises via AWS Direct Connect"
    → điều kiện này đã được đáp ứng

aws elbv2 create-target-group --name tg-tai-cho   --protocol HTTP --port 80 --vpc-id vpc-0abc123 --target-type ip

aws elbv2 register-targets --target-group-arn <arn-tg-tai-cho>   --targets Id=10.10.1.50,AvailabilityZone=all

aws elbv2 modify-listener --listener-arn <arn>   --default-actions '[{"Type":"forward","ForwardConfig":{
    "TargetGroups":[
      {"TargetGroupArn":"<arn-tg-aws>","Weight":50},
      {"TargetGroupArn":"<arn-tg-tai-cho>","Weight":50}]}}]'

Chú ý AvailabilityZone=all — bắt buộc khi đăng ký IP nằm ngoài VPC.

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

• **C. Dùng Route 53 với Failover routing policy để chia tỷ lệ — đây là phương án gần nhất và cũng là chính sách Route 53, nhưng nó không chia tỷ lệ được: failover là mô hình primary/secondary — toàn bộ lưu lượng đi tới primary, secondary chỉ nhận khi primary hỏng. Đó là active-passive.
• **A. Dùng Network Load Balancer với Weighted Target Group — NLB KHÔNG hỗ trợ weighted target group: tính năng chia trọng số giữa nhiều target group chỉ có ở ALB. NLB chuyển tiếp tới một target group duy nhất mỗi listener.
• **E. Dùng Global Accelerator với "địa chỉ AnyCast tĩnh trên mạng tại chỗ" — mô tả sai cách hoạt động: Global Accelerator cấp hai IP anycast của AWS cho endpoint của bạn; mạng tại chỗ không "có" địa chỉ anycast. (Global Accelerator có hỗ trợ endpoint là IP tại chỗ và có chia trọng số, nhưng cách mô tả trong phương án là không chính xác.)

Ghi nhớ

Hai tầng chia lưu lượng — bảng phân biệt cốt lõi: | | Route 53 weighted (DNS) | ALB weighted target group | |---|---|---| | Tầng | DNS | ứng dụng (tầng 7) | | Chia theo | mỗi lần phân giải DNS | TỪNG REQUEST | | Độ chính xác của tỷ lệ | lệch do cache DNS | chính xác | | Thay đổi có hiệu lực | phụ thuộc TTL | NGAY LẬP TỨC | | Health check | có, nhưng chậm hơn | liên tục, chính xác | | Phạm vi | xuyên Region, xuyên nhà cung cấp | trong tầm với của ALB |

ALB chính xác hơn nhiều cho việc chuyển đổi dần:

Route 53: một client phân giải một lần rồi dính với kết quả đó suốt TTL
    → tỷ lệ thực tế lệch, và muốn đổi tỷ lệ phải chờ TTL

ALB: mỗi request được chia lại
    → 50/50 là chính xác 50/50
    → đổi sang 90/10 có hiệu lực NGAY

Nhưng Route 53 có phạm vi rộng hơn — nó chia được lưu lượng tới bất cứ đâu, kể cả hệ thống không nằm sau ALB.

Ba loại target type của ALB: | Loại | Target là | |---|---| | instance | EC2 instance ID | | ip | địa chỉ IP — kể cả máy TẠI CHỖ qua DX hoặc VPN ← chìa khoá của phương án B | | lambda | Lambda function |

Điều kiện để dùng target kiểu IP cho máy tại chỗ:

① VPC kết nối với mạng tại chỗ (Direct Connect hoặc VPN)
② IP nằm trong dải RFC 1918 (10.x, 172.16–31.x, 192.168.x)
③ Đăng ký với AvailabilityZone = all
④ Security group của ALB cho phép ra tới dải IP đó

Và mẫu này rất hữu ích cho di chuyển lên đám mây:

Giai đoạn 1: 100% tại chỗ, 0% AWS      → kiểm chứng kết nối
Giai đoạn 2: 90% tại chỗ, 10% AWS      → canary
Giai đoạn 3: 50/50                     → đề này
Giai đoạn 4: 10% tại chỗ, 90% AWS
Giai đoạn 5: 0% tại chỗ, 100% AWS      → hoàn tất

Mỗi bước quan sát metric trước khi tiến tiếp, và quay lui được ngay nếu có vấn đề.

Bảy chính sách định tuyến của Route 53: | Chính sách | Việc | |---|---| | Weighted | chia theo tỷ lệ ← câu này | | Failover | primary / secondary | | Latency-based | tới Region độ trễ thấp nhất | | Geolocation | theo vị trí người dùng | | Geoproximity | theo khoảng cách, có bias | | Multivalue answer | tới 8 bản ghi lành mạnh | | Simple | một bản ghi |

Và geoproximity với bias cũng là công cụ chuyển đổi dần — bạn tăng bias của endpoint AWS để nó "kéo" thêm lưu lượng từ vùng lân cận.

Ba lưu ý khi chia lưu lượng trong lúc di chuyển: | Lưu ý | Chi tiết | |---|---| | Trạng thái phiên phải DÙNG CHUNG | nếu không, người dùng bị đăng xuất khi chuyển bên | | Cơ sở dữ liệu phải nhất quán | hai bên đọc ghi cùng nguồn, hoặc đồng bộ hai chiều | | Giám sát cả hai bên | so sánh tỷ lệ lỗi và độ trễ |

Dòng đầu là vấn đề thực tế lớn nhất:

Phiên đăng nhập lưu trong bộ nhớ máy chủ
    → người dùng lần đầu vào máy tại chỗ, lần sau vào AWS
    → mất phiên, phải đăng nhập lại
        ↓
Giải pháp: đưa phiên ra kho dùng chung
    → ElastiCache, DynamoDB, hoặc cookie có chữ ký

Và với TTL của Route 53, hãy hạ xuống 60 giây TRƯỚC khi bắt đầu chuyển đổi:

Nếu TTL đang là 3600 giây và bạn đổi trọng số
    → một số người dùng vẫn dùng bản ghi cũ trong một giờ
    → khó kiểm soát và khó quay lui

Ba metric cần so sánh giữa hai bên: | Metric | Ý nghĩa | |---|---| | Tỷ lệ lỗi 5xx | bên AWS có ổn định như bên cũ không | | Độ trễ p95, p99 | trung bình che giấu vấn đề, phân vị thì không | | Tỷ lệ hoàn tất giao dịch | chỉ báo nghiệp vụ quan trọng nhất |

Và một lời khuyên về thứ tự: hãy bắt đầu với tỷ lệ rất nhỏ (5% hoặc 10%) thay vì nhảy thẳng vào 50/50. Với 5%, một vấn đề nghiêm trọng chỉ ảnh hưởng một phần nhỏ người dùng — và bạn vẫn phát hiện được nó qua metric. Đề yêu cầu 50/50, nhưng trong thực tế đó nên là bước thứ ba chứ không phải bước đầu.

Đáp án

B — Dùng IAM DB Authentication và tạo tài khoản database bằng plugin AWSAuthenticationPlugin trong MySQL.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: mỗi IAM user dùng token xác thực NGẮN HẠN để kết nối database — và IAM DB Authentication là cơ chế cho đúng việc đó.

Cách hoạt động:

Ứng dụng gọi API sinh token:
    aws rds generate-db-auth-token
        ↓
    Token có hiệu lực 15 PHÚT
        ↓
Dùng token đó thay cho mật khẩu khi kết nối MySQL
        ↓
MySQL xác minh qua plugin AWSAuthenticationPlugin

Tạo tài khoản database dùng IAM:

CREATE USER 'nguoi_dung_ung_dung' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
GRANT SELECT, INSERT, UPDATE ON kho_du_lieu.* TO 'nguoi_dung_ung_dung';

Và cấp quyền IAM tương ứng:

{"Effect": "Allow",
 "Action": ["rds-db:connect"],
 "Resource": "arn:aws:rds-db:ap-southeast-1:123456789012:dbuser:db-ABCDEFG/nguoi_dung_ung_dung"}

Sinh token và kết nối:

TOKEN=$(aws rds generate-db-auth-token   --hostname db-ung-dung.abc.ap-southeast-1.rds.amazonaws.com   --port 3306 --username nguoi_dung_ung_dung)

mysql --host=... --user=nguoi_dung_ung_dung --password="$TOKEN"       --ssl-ca=global-bundle.pem

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không còn mật khẩu dài hạn | token tự hết hạn sau 15 phút | | Quản lý quyền tập trung bằng IAM | thu hồi quyền ở một chỗ | | BẮT BUỘC dùng SSL/TLS | IAM DB auth chỉ hoạt động qua kết nối mã hoá |

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

• **C. Dùng AWS Secrets Manager sinh và lưu token ngắn hạn — đây là phương án gần nhất và Secrets Manager thực sự quản lý thông tin đăng nhập database rất tốt, nhưng nó lưu MẬT KHẨU và xoay vòng chúng, không sinh token ngắn hạn cho từng IAM user. Mật khẩu do Secrets Manager quản lý vẫn là mật khẩu dài hạn (đổi theo lịch, ví dụ 30 ngày), không phải token 15 phút.
• **A. Dùng IAM Identity Center để truy cập RDS — sai đối tượng: Identity Center quản lý truy cập của con người vào tài khoản AWS thông qua permission set. Nó không cấp thông tin đăng nhập vào bên trong engine database.
• **D. Dùng MFA token để kết nối database — MySQL không hỗ trợ MFA của AWS: MFA áp cho việc xác thực vào AWS API và Console, không phải cho kết nối tới engine cơ sở dữ liệu.

Ghi nhớ

Ba cách xác thực vào RDS — bảng cần thuộc: | Cách | Đặc điểm | |---|---| | Mật khẩu tĩnh | đơn giản nhất, rủi ro nhất | | Secrets Manager | mật khẩu được lưu an toàn và XOAY VÒNG TỰ ĐỘNG | | IAM DB Authentication | token 15 PHÚT, không có mật khẩu nào để rò rỉ ← câu này |

Quy tắc nhận diện trong đề thi:

"short-lived token", "IAM user", "no password" → IAM DB Authentication "rotate credentials automatically", "store database password" → Secrets Manager

Ba giới hạn của IAM DB Authentication: | Giới hạn | Chi tiết | |---|---| | Chỉ MySQL, MariaDB, PostgreSQL | không có với Oracle và SQL Server | | Giới hạn số kết nối mới mỗi giây | khoảng 200/giây với MySQL — không hợp cho ứng dụng mở kết nối liên tục | | Token hết hạn sau 15 phút | ứng dụng phải tự sinh lại |

Dòng giữa là hạn chế thực tế quan trọng: IAM DB auth phù hợp cho ứng dụng dùng connection pool (mở ít kết nối, giữ lâu), không phù hợp cho ứng dụng mở kết nối mới cho mỗi request.

Và RDS Proxy giải quyết được vấn đề đó:

RDS Proxy:
    ✓ gộp và tái dùng kết nối
    ✓ hỗ trợ IAM authentication
    ✓ lấy mật khẩu từ Secrets Manager
    ✓ giữ kết nối trong lúc failover
        ↓
    Ứng dụng dùng IAM để nói chuyện với Proxy
    Proxy dùng mật khẩu từ Secrets Manager để nói chuyện với database

Đây là kiến trúc kết hợp tốt nhất cho ứng dụng có nhiều kết nối.

Ba đặc điểm của Secrets Manager với RDS: | Đặc điểm | Chi tiết | |---|---| | Xoay vòng tự động | tích hợp sẵn với RDS — đổi cả ở database lẫn trong secret | | Chi phí | ~0,40 USD mỗi secret mỗi tháng | | Chia sẻ xuyên tài khoản | qua resource policy |

Và Parameter Store là lựa chọn rẻ hơn nếu không cần xoay vòng: | | Parameter Store | Secrets Manager | |---|---|---| | Chi phí | miễn phí (Standard) | ~0,40 USD/secret/tháng | | Xoay vòng tự động | ❌ | ✅ | | Sinh mật khẩu ngẫu nhiên | ❌ | ✅ |

Ba biện pháp bảo mật khác cho RDS: | Biện pháp | Chi tiết | |---|---| | Đặt trong PRIVATE subnet | không có IP công khai | | Security group chỉ nhận từ SG của tầng ứng dụng | không dùng CIDR | | Bắt buộc SSL | tham số require_secure_transport = ON |

Bắt buộc SSL ở mức parameter group:

aws rds modify-db-parameter-group --db-parameter-group-name pg-ung-dung   --parameters "ParameterName=require_secure_transport,ParameterValue=ON,ApplyMethod=immediate"

Sau đó mọi kết nối không dùng TLS đều bị từ chối — không phụ thuộc vào việc client có nhớ khai --ssl-ca hay không.

Và một lưu ý khi triển khai: hãy tải chứng chỉ CA của RDS và khai trong chuỗi kết nối. Không xác minh chứng chỉ nghĩa là kết nối vẫn mã hoá nhưng không chống được tấn công người-đứng-giữa:

wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

Đáp án

B — Dùng AWS Storage Gateway HARDWARE APPLIANCE; cấu hình File Gateway để lưu dữ liệu ứng dụng và tạo một S3 bucket để lưu bản sao lưu.

Vì sao đúng

Đề cho hai dữ kiện quyết định, và mỗi cái loại bớt một nửa số phương án: | Dữ kiện | Kết luận | |---|---| | Máy chủ vật lý chuyên dụng, KHÔNG dùng ảo hoá | phải dùng HARDWARE APPLIANCE, không phải máy ảo | | Lưu trữ dùng giao thức NFS | phải là FILE GATEWAY |

Vì sao phải là hardware appliance:

Storage Gateway triển khai được ba cách:
    ① Máy ảo (VMware, Hyper-V, KVM)  → CẦN nền tảng ảo hoá
    ② EC2 instance                    → chạy trên AWS
    ③ HARDWARE APPLIANCE              → thiết bị vật lý AWS gửi tới
        ↓
Đề nói "dedicated physical server that DOESN'T USE VIRTUALIZATION"
    → không có hypervisor để chạy máy ảo
    → chỉ còn hardware appliance

Và vì sao phải là File Gateway: | Loại gateway | Giao thức | |---|---| | File Gateway | NFS và SMB ← đề yêu cầu NFS | | Volume Gateway | iSCSI (giao thức khối) | | Tape Gateway | iSCSI VTL |

Và File Gateway lưu mỗi tệp thành một object trong S3:

Máy chủ mount thư mục qua NFS
    → ghi tệp như ổ đĩa mạng bình thường
        ↓
File Gateway đồng bộ lên S3
    → mỗi tệp = một object
    → giữ nguyên cấu trúc thư mục
    → cache cục bộ giữ dữ liệu hay dùng

Và bản sao lưu bổ sung trong S3 cho vế "prevent data loss":

Bật VERSIONING trên bucket → giữ mọi phiên bản, chống ghi đè nhầm
Bật CRR sang Region khác   → chịu được sự cố cả Region
Lifecycle rule sang Glacier → lưu trữ dài hạn giá rẻ

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

• **C. Hardware appliance + Volume Gateway + S3 bucket sao lưu — đây là phương án gần nhất và phần hardware appliance đúng, nhưng nó sai giao thức: Volume Gateway dùng iSCSI (giao thức khối), không phải NFS. Đề nói rõ ứng dụng dùng NFS.
• **A. Hardware appliance + Volume Gateway cho cả dữ liệu lẫn sao lưu — cùng lỗi giao thức, và không có bản sao độc lập.
• **D. Máy ảo gateway (gateway VM appliance) + File Gateway — phần File Gateway đúng nhưng phần triển khai sai: máy chủ không có ảo hoá thì không chạy được máy ảo. Đây chính là điểm mà dữ kiện "doesn't use virtualization" nhắm tới.

Ghi nhớ

Ba loại Storage Gateway — bảng cần thuộc: | Loại | Giao thức | Đích | Dùng cho | |---|---|---|---| | File Gateway | NFS, SMB | S3 | chia sẻ tệp, kho dữ liệu ← câu này | | Volume Gateway | iSCSI | S3 dạng EBS snapshot | ổ đĩa khối cho ứng dụng | | Tape Gateway | iSCSI VTL | S3 Glacier | thay thư viện băng từ |

Từ khoá nhận diện:

"NFS", "SMB", "file share" → File Gateway "iSCSI", "block volume" → Volume Gateway "tape", "backup software", "VTL" → Tape Gateway

Ba cách triển khai Storage Gateway: | Cách | Yêu cầu | |---|---| | Máy ảo | VMware ESXi, Hyper-V, KVM, hoặc Linux KVM | | Hardware appliance | thiết bị vật lý AWS gửi tới — cho nơi KHÔNG có ảo hoá | | EC2 instance | chạy trên AWS, cho việc kiểm thử hoặc gateway trong đám mây |

Hardware appliance đáng biết: | Đặc điểm | Chi tiết | |---|---| | Thiết bị 1U đặt trong tủ rack | AWS gửi tới địa chỉ của bạn | | Đã cài sẵn phần mềm gateway | chỉ cần cắm điện, cắm mạng, kích hoạt | | Chạy được mọi loại gateway | file, volume, hoặc tape | | Có sẵn tài nguyên tính toán và lưu trữ | dùng luôn làm cache |

Hai chế độ của File Gateway: | Chế độ | Đích | |---|---| | S3 File Gateway | S3 — mỗi tệp một object | | FSx File Gateway | FSx for Windows File Server |

Ba đặc điểm quan trọng của S3 File Gateway: | Đặc điểm | Chi tiết | |---|---| | Mỗi tệp = một object S3 | truy cập được bằng CẢ NFS/SMB LẪN S3 API | | Cache cục bộ | dữ liệu hay dùng đọc nhanh | | Tích hợp lifecycle của S3 | tự chuyển sang Glacier |

Dòng đầu là lợi ích lớn nhất: dữ liệu vừa dùng được như tệp thông thường tại chỗ, vừa xử lý được bằng dịch vụ AWS (Athena, Glue, Lambda) mà không cần bước chuyển đổi nào.

Ba yêu cầu khi triển khai gateway: | Yêu cầu | Chi tiết | |---|---| | Đĩa cho cache | kích thước quyết định trải nghiệm đọc | | Đĩa cho upload buffer | vùng đệm dữ liệu chờ đẩy lên S3 | | Băng thông tới AWS | đặt giới hạn theo lịch nếu cần |

Và ba biện pháp bảo vệ dữ liệu trên bucket đích: | Biện pháp | Chống lại | |---|---| | Versioning | ghi đè nhầm, xoá nhầm | | Cross-Region Replication | sự cố cả Region | | Object Lock | xoá cố ý, ransomware |

Lifecycle rule cho dữ liệu sao lưu:

{"Rules": [{
  "Status": "Enabled", "Filter": {},
  "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"},
                  {"Days": 90, "StorageClass": "GLACIER"}],
  "NoncurrentVersionExpiration": {"NoncurrentDays": 365}}]}

Các dịch vụ lưu trữ lai — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | Storage Gateway | truy cập LIÊN TỤC — tại chỗ dùng, dữ liệu ở AWS | | DataSync | di chuyển hoặc đồng bộ định kỳ | | Snow Family | khối lượng rất lớn, băng thông kém |

Và một lưu ý về thời gian: đặt hàng hardware appliance mất vài ngày tới vài tuần để giao. Nếu cần triển khai gấp và máy chủ có thể cài hypervisor nhẹ, máy ảo gateway là lựa chọn nhanh hơn — nhưng đề đã loại trừ khả năng đó.

Đáp án

B — Amazon FSx for Windows File Server.

Vì sao đúng

Đề nêu bốn yêu cầu, và cả bốn đều là đặc điểm riêng của FSx for Windows: | Yêu cầu | FSx for Windows | |---|---| | Hệ thống tệp CHIA SẺ | ✅ nhiều instance mount cùng lúc | | Cho ứng dụng .NET trên EC2 Windows | ✅ SMB, NTFS — môi trường Windows gốc | | Thông lượng và IOPS cao | ✅ cấu hình được tới 2.048 MB/giây | | Tích hợp Microsoft Active Directory | ✅ join domain, quyền theo AD |

Vế Active Directory là điều kiện loại bỏ mọi lựa chọn khác:

Ứng dụng .NET trên Windows dùng quyền NTFS theo tài khoản AD
    → cần hệ thống tệp HIỂU được ACL của Windows
    → chỉ FSx for Windows làm được

Và nó chạy trên Windows Server thật, không phải mô phỏng:

✓ SMB 2.0 tới 3.1.1
✓ NTFS với ACL đầy đủ
✓ DFS Namespace và DFS Replication
✓ Shadow copy (Previous Versions)
✓ User quota

Cấu hình Multi-AZ cho sẵn sàng cao:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 300 --storage-type SSD   --subnet-ids subnet-1a subnet-1b   --windows-configuration     DeploymentType=MULTI_AZ_1,ThroughputCapacity=64,ActiveDirectoryId=d-1234567890

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

• **C. Amazon Elastic File System (EFS) — đây là phương án gần nhất vì cũng là hệ thống tệp chia sẻ được quản lý, nhưng nó dùng NFS cho LINUX: EFS không hỗ trợ SMB, không hiểu NTFS ACL, và không tích hợp Active Directory. Windows không mount EFS một cách tự nhiên.
• **A. EBS Provisioned IOPS SSD — không phải hệ thống tệp CHIA SẺ: EBS volume gắn với một instance (multi-attach chỉ tối đa 16 instance trong cùng AZ, và cần hệ thống tệp hỗ trợ truy cập đồng thời). Nó cũng không tích hợp AD.
• **D. AWS Storage Gateway — File Gateway — sai ngữ cảnh: File Gateway phục vụ truy cập từ trung tâm dữ liệu TẠI CHỖ tới dữ liệu trong AWS. Ứng dụng ở đây đã chạy trên EC2 trong AWS, không cần gateway.

Ghi nhớ

Các dịch vụ lưu trữ tệp của AWS — bảng cần thuộc: | Dịch vụ | Giao thức | Hệ điều hành | AD | |---|---|---|---| | Amazon EFS | NFS | Linux | ❌ | | FSx for Windows File Server | SMB | Windows | ✅ | | FSx for Lustre | Lustre (POSIX) | Linux | ❌ | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | cả hai | ✅ | | FSx for OpenZFS | NFS | Linux | ❌ |

Từ khoá nhận diện trong đề thi:

"SMB", "NTFS", "Active Directory", "Windows", ".NET" → FSx for Windows "NFS", "Linux", "POSIX" → EFS "HPC", "machine learning", "Lustre" → FSx for Lustre "multi-protocol", "NetApp", "snapshot và clone" → FSx for ONTAP

Ba tính năng của FSx for Windows đáng dùng: | Tính năng | Chi tiết | |---|---| | Data deduplication | giảm 50–60% dung lượng với dữ liệu văn phòng | | Shadow copy | người dùng tự khôi phục phiên bản cũ qua "Previous Versions" | | User quota | giới hạn theo người dùng | | Sao lưu tự động hằng ngày | giữ 0–90 ngày |

Enable-FSxDedup -FileSystemId fs-0abc123

Hai loại triển khai: | Loại | Đặc điểm | |---|---| | Single-AZ | rẻ hơn, cho dev/test | | Multi-AZ | standby ở AZ khác, tự failover — cho sản xuất |

Hai loại lưu trữ: | Loại | Phù hợp | |---|---| | SSD | độ trễ thấp, IOPS cao — ứng dụng chính ← đề yêu cầu | | HDD | rẻ hơn nhiều — chia sẻ tệp thông thường |

Ba lựa chọn tích hợp Active Directory: | Lựa chọn | Đặc điểm | |---|---| | AWS Managed Microsoft AD | AD thật trên AWS | | AD tự quản lý | AD của bạn trên EC2 hoặc tại chỗ | | — | FSx BẮT BUỘC phải join một AD |

Dòng cuối là điều kiện tiên quyết — không có AD thì không tạo được FSx for Windows.

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | ThroughputCapacity khai RIÊNG với dung lượng | 8–2.048 MB/giây | | Tăng được sau khi tạo | không cần dừng | | Cache trong bộ nhớ | tự động cho dữ liệu nóng |

Đây là khác biệt so với EFS: EFS ở chế độ Bursting gắn thông lượng với dung lượng lưu trữ, còn FSx cho khai độc lập — nên với dữ liệu ít mà cần thông lượng cao, FSx linh hoạt hơn.

Ba cách di chuyển dữ liệu vào FSx: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh, tự động, có xác minh | | Robocopy | công cụ quen thuộc của Windows | | AWS Snowball | khối lượng rất lớn |

Và một tính năng đáng biết: FSx File Gateway — cho phép truy cập FSx for Windows từ trung tâm dữ liệu tại chỗ với cache cục bộ, hữu ích trong kiến trúc lai.

Và một lưu ý về chi phí: FSx tính phí theo dung lượng, throughput capacity, và sao lưu. ThroughputCapacity là khoản dễ đặt thừa — hãy bắt đầu ở mức vừa phải rồi tăng khi đo được nhu cầu thật, vì tăng thì dễ mà giảm thì phải tạo file system mới.

Đáp án

C — Tạo step scaling policy và cấu hình điều kiện instance warm-up time.

Vì sao đúng

Đề nêu hai vấn đề, và step scaling kèm warm-up giải quyết cả hai: | Vấn đề | Cơ chế | |---|---| | Đợt tăng tải đột ngột mỗi sáng | step scaling phản ứng mạnh khi vượt ngưỡng nhiều | | Instance mất 1 PHÚT để khởi động | warm-up time ngăn ASG mở rộng quá mức |

Vì sao warm-up time là chi tiết quan trọng nhất:

KHÔNG có warm-up:
    ASG thêm instance
        → instance đang boot, CHƯA phục vụ được
        → nhưng ASG ĐÃ TÍNH nó vào metric trung bình
        → metric vẫn cao → ASG thêm tiếp
        → MỞ RỘNG QUÁ MỨC, rồi thu hẹp ồ ạt

CÓ warm-up = 60 giây:
    ASG thêm instance
        → BỎ QUA nó trong tính toán metric suốt 60 giây
        → chờ nó thực sự sẵn sàng rồi mới đánh giá lại
        → mở rộng đúng mức cần

Và step scaling phù hợp với "burst of traffic":

Bậc theo mức vượt ngưỡng:
    CPU 60–70%  → thêm 2 instance
    CPU 70–85%  → thêm 4 instance
    CPU trên 85% → thêm 8 instance
        ↓
    Đợt tăng vọt buổi sáng → phản ứng MẠNH ngay

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-ung-dung   --policy-name mo-rong-theo-bac --policy-type StepScaling   --adjustment-type ChangeInCapacity   --estimated-instance-warmup 60   --step-adjustments     MetricIntervalLowerBound=0,MetricIntervalUpperBound=10,ScalingAdjustment=2     MetricIntervalLowerBound=10,MetricIntervalUpperBound=25,ScalingAdjustment=4     MetricIntervalLowerBound=25,ScalingAdjustment=8

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

• **D. Tạo CloudFront distribution với EC2 làm origin — đây là phương án gần nhất và thực sự giảm tải cho origin, nhưng nó chỉ giúp với nội dung CACHE ĐƯỢC: request động vẫn đi tới EC2. Và nó không giải quyết vấn đề gốc là ASG phản ứng chậm với đợt tăng tải.
• **B. Tạo launch template mới với instance lớn hơn — tốn tiền và không giải quyết đúng vấn đề: máy lớn hơn chịu được nhiều hơn nhưng vẫn có giới hạn, và bạn trả tiền cho công suất thừa suốt 23 giờ còn lại trong ngày.
• **A. Tạo Network Load Balancer với slow-start mode — hai lỗi: slow-start là tính năng của ALB, KHÔNG có ở NLB. Và slow-start chỉ điều tiết lưu lượng gửi tới target mới, nó không làm ASG mở rộng nhanh hơn.

Ghi nhớ

Năm loại scaling policy — bảng cần thuộc: | Loại | Đặc điểm | |---|---| | Target tracking | giữ metric ở một giá trị — đơn giản nhất | | Step scaling | nhiều bậc theo mức vượt ngưỡng ← câu này | | Simple scaling | một hành động, chờ cooldown — cũ | | Scheduled scaling | theo giờ định trước — hợp với "mỗi sáng" | | Predictive scaling | học từ lịch sử, mở rộng TRƯỚC |

Và với "burst of traffic EVERY MORNING", hai lựa chọn khác cũng rất phù hợp:

Scheduled scaling:
    → biết chính xác 8 giờ sáng tải tăng
    → đặt lịch tăng DesiredCapacity lúc 7h45
    → máy sẵn sàng trước khi người dùng tới

Predictive scaling:
    → tự học mẫu từ 14 ngày dữ liệu
    → tự mở rộng trước, không cần đặt lịch tay

(Step scaling kèm warm-up là đáp án đúng theo bộ đề và giải quyết được vấn đề; nhưng với mẫu tải lặp lại hằng ngày, mở rộng TRƯỚC hiệu quả hơn phản ứng SAU.)

Ba cấu hình thời gian của Auto Scaling — đừng nhầm: | Cấu hình | Việc | Áp cho | |---|---|---| | EstimatedInstanceWarmup | bỏ qua instance mới trong tính toán metric | step và target tracking | | Cooldown period | thời gian chờ giữa hai hoạt động co giãn | simple scaling | | Health check grace period | bỏ qua health check cho instance mới | mọi loại |

Và grace period cũng quan trọng với instance khởi động lâu:

Grace period quá ngắn:
    → ASG coi instance mới là hỏng → chấm dứt
    → khởi chạy máy khác → lại chấm dứt
    → VÒNG LẶP vô tận

Ba cách rút ngắn thời gian khởi động — giải quyết tận gốc: | Cách | Lợi ích | |---|---| | AMI nướng sẵn ứng dụng và cấu hình | không cài đặt lúc khởi chạy | | Warm pool | giữ sẵn instance ở trạng thái Stopped hoặc Hibernated | | Giảm việc trong user data | mọi lệnh đều thêm thời gian |

Warm pool đáng biết cho tình huống này:

aws autoscaling put-warm-pool   --auto-scaling-group-name asg-ung-dung   --min-size 10 --pool-state Stopped

Instance ở trạng thái Stopped trong warm pool KHÔNG tính phí compute — chỉ trả phí EBS. Khi cần, chúng chuyển sang InService nhanh hơn nhiều so với khởi chạy từ đầu.

Ba loại adjustment-type của step scaling: | Loại | Ý nghĩa | |---|---| | ChangeInCapacity | thêm hoặc bớt số lượng cụ thể | | PercentChangeInCapacity | theo phần trăm — hợp với đội máy lớn | | ExactCapacity | đặt về một con số cố định |

Ba metric nên cân nhắc cho ứng dụng web: | Metric | Phù hợp | |---|---| | ASGAverageCPUUtilization | ứng dụng nặng tính toán | | ALBRequestCountPerTarget | phản ánh tải thật tốt hơn CPU, phản ứng nhanh hơn | | TargetResponseTime | trực tiếp phản ánh trải nghiệm người dùng |

ALBRequestCountPerTarget thường tốt hơn CPU cho đợt tăng đột ngột — số request tăng ngay lập tức, còn CPU cần thời gian mới lên theo.

Và một lời khuyên về việc chẩn đoán: xem Activity history của Auto Scaling group để biết ASG đã phản ứng lúc nào và bao nhiêu. Nếu thấy nó thêm rồi bớt liên tục trong đợt tăng tải, đó là dấu hiệu thiếu warm-up — đúng vấn đề mà đáp án này giải quyết.

Đáp án

C — Tạo AMI của instance backend, dùng nó dựng Auto Scaling group và cấu hình target tracking scaling policy dựa trên metric ApproximateAgeOfOldestMessage.

Vì sao đúng

Đề nêu ba dữ kiện, và metric ApproximateAgeOfOldestMessage khớp trực tiếp với cả ba: | Dữ kiện | Vì sao metric này đúng | |---|---| | SLA đo THỜI GIAN từ khi nhận thông điệp tới khi phản hồi | metric này chính là thời gian thông điệp nằm chờ | | Xử lý nặng về I/O, không phải CPU | CPU KHÔNG phản ánh được tình trạng quá tải | | Số thông điệp tăng liên tục | metric tăng theo khi consumer không theo kịp |

Điểm mấu chốt: workload I/O-intensive khiến metric CPU vô dụng.

Tác vụ nặng I/O:
    → phần lớn thời gian CHỜ đĩa hoặc mạng
    → CPU nhàn rỗi
        ↓
    Hàng đợi tích tụ hàng nghìn thông điệp
    NHƯNG CPU chỉ 20%
        → scaling theo CPU KHÔNG BAO GIỜ kích hoạt

Trong khi ApproximateAgeOfOldestMessage đo đúng thứ SLA quan tâm:

Metric này = số GIÂY mà thông điệp cũ nhất đã nằm trong hàng đợi
    → SLA nói "không quá 300 giây"
    → đặt mục tiêu 200 giây làm ngưỡng
    → hàng đợi chậm lại → metric tăng → ASG thêm máy

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-backend   --policy-name giu-tuoi-thong-diep --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 200.0,
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateAgeOfOldestMessage",
      "Namespace": "AWS/SQS",
      "Dimensions": [{"Name": "QueueName", "Value": "hang-doi-xu-ly"}],
      "Statistic": "Maximum"}}'

Và ASG giải quyết luôn vế "load management" — đội máy tự lớn khi hàng đợi dài, tự co khi vắng.

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

• **A. ASG với target tracking dựa trên CPUUtilization mục tiêu 80% — đây là phương án gần nhất và có cấu trúc giải pháp hoàn toàn đúng, nhưng nó chọn sai metric: workload nặng I/O thì CPU thấp dù hàng đợi đang tích tụ. Chính sách này sẽ không bao giờ kích hoạt.
• **B. Thay bằng instance lớn hơn — chỉ hoãn vấn đề: đề nói số thông điệp tăng liên tục, nên một máy lớn hơn cũng sẽ quá tải sau một thời gian. Và nó không có khả năng co giãn.
• **D. Khởi chạy vào cluster placement group — giải quyết vấn đề khác: cluster placement group tối ưu độ trễ mạng giữa các instance cho HPC. Nó không tăng khả năng xử lý hàng đợi.

Ghi nhớ

Ba metric của SQS dùng cho Auto Scaling — chọn đúng: | Metric | Đo gì | Phù hợp khi | |---|---|---| | ApproximateAgeOfOldestMessage | số GIÂY thông điệp cũ nhất chờ | có SLA về THỜI GIAN ← câu này | | ApproximateNumberOfMessagesVisible | số thông điệp đang chờ | quan tâm tới độ sâu hàng đợi | | NumberOfMessagesSent | tốc độ nạp vào | dự báo tải |

Quy tắc chọn:

SLA đo bằng THỜI GIAN → ApproximateAgeOfOldestMessage Muốn giữ số thông điệp mỗi máy ở mức nhất định → backlog per instance

Và có một metric tuỳ chỉnh rất được khuyến nghị: backlog mỗi instance.

Backlog per instance = ApproximateNumberOfMessagesVisible / số instance đang chạy
    → target tracking giữ tỷ lệ này ở một mức
    → ví dụ mỗi máy xử lý được 100 thông điệp → đặt mục tiêu 100

AWS khuyến nghị cách này vì nó tính đến cả số máy hiện có, không chỉ độ sâu hàng đợi.

Vì sao CPU là metric kém cho ứng dụng I/O: | Loại workload | Metric phù hợp | |---|---| | Nặng CPU (mã hoá, nén, tính toán) | CPUUtilization | | Nặng I/O (đọc ghi đĩa, gọi mạng, database) | độ sâu hoặc tuổi hàng đợi | | Web | ALBRequestCountPerTarget | | Nặng bộ nhớ | metric tuỳ chỉnh (cần CloudWatch agent) |

Ba cách cải thiện thời gian xử lý ngoài việc thêm máy: | Cách | Chi tiết | |---|---| | Xử lý theo LÔ | MaxNumberOfMessages = 10 — một request lấy 10 thông điệp | | Tăng số luồng xử lý mỗi instance | với workload I/O, một máy chạy được nhiều luồng | | Bật long polling | giảm request rỗng, giảm chi phí |

Dòng giữa đáng chú ý cho workload I/O: vì tiến trình chủ yếu chờ, một instance chạy 50 luồng song song vẫn không hết CPU — tăng số luồng thường hiệu quả hơn thêm máy, và rẻ hơn nhiều.

Và có một lựa chọn kiến trúc khác đáng cân nhắc: Lambda. | | EC2 + ASG | Lambda event source mapping | |---|---|---| | Co giãn | theo metric, có độ trễ | gần như tức thì theo số thông điệp | | Chi phí khi rảnh | vẫn trả tiền instance | 0 đồng | | Thời gian xử lý tối đa | không giới hạn | 15 phút | | Công vận hành | quản lý AMI, vá lỗi | không có |

Với tải biến động và tác vụ dưới 15 phút, Lambda thường đáp ứng SLA tốt hơn vì nó mở rộng gần như tức thì thay vì chờ instance boot.

Ba cấu hình SQS cần khớp với thời gian xử lý: | Cấu hình | Chi tiết | |---|---| | VisibilityTimeout | PHẢI ≥ thời gian xử lý dài nhất | | MessageRetentionPeriod | đủ dài để không mất thông điệp khi hệ thống chậm | | Dead-letter queue | tách thông điệp hỏng ra |

Ba alarm nên đặt cho hệ thống có SLA: | Alarm | Ngưỡng | |---|---| | ApproximateAgeOfOldestMessage | báo trước khi chạm SLA | | ApproximateNumberOfMessagesVisible | tích tụ bất thường | | Thông điệp vào DLQ | có lỗi xử lý |

Và một lời khuyên: hãy đặt ngưỡng target thấp hơn SLA đáng kể (ví dụ SLA 300 giây thì đặt mục tiêu 150–200 giây). ASG cần thời gian để phát hiện, khởi chạy và làm nóng instance mới — nếu đặt ngưỡng sát SLA, đến lúc máy mới sẵn sàng thì đã vi phạm cam kết rồi.

Đáp án

A và C.

• A — Thiết lập VPC peering connection giữa hai VPC
• C — Cấu hình lại route table của subnet chứa các instance

Vì sao đúng

Đề cần truyền dữ liệu giữa hai VPC ở hai Region khác nhau mà không đi qua Internet công cộng — và VPC peering làm được điều đó.

Inter-Region VPC peering là tính năng có thật của AWS:

VPC ở Ohio (us-east-2)  ◀──peering──▶  VPC ở N.Virginia (us-east-1)
    → lưu lượng đi trên MẠNG XƯƠNG SỐNG của AWS
    → được MÃ HOÁ tự động
    → KHÔNG qua Internet công cộng
    → không phụ thuộc vào một điểm hỏng đơn hay nút thắt băng thông

Và bước C là bước bắt buộc mà nhiều người quên:

Tạo peering connection XONG không có nghĩa là lưu lượng đi được
    ↓
Phải thêm ROUTE ở CẢ HAI VPC:
    Route table VPC A:  <CIDR của VPC B> → pcx-xxxxx
    Route table VPC B:  <CIDR của VPC A> → pcx-xxxxx

# Tạo peering (từ VPC ở Ohio sang N.Virginia)
aws ec2 create-vpc-peering-connection --vpc-id vpc-ohio   --peer-vpc-id vpc-virginia --peer-region us-east-1

# Chấp nhận ở phía kia
aws ec2 accept-vpc-peering-connection   --vpc-peering-connection-id pcx-0abc123 --region us-east-1

# Thêm route ở CẢ HAI bên
aws ec2 create-route --route-table-id rtb-ohio   --destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id pcx-0abc123
aws ec2 create-route --route-table-id rtb-virginia --region us-east-1   --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id pcx-0abc123

Và đừng quên security group — chúng phải cho phép lưu lượng từ CIDR của VPC đối tác.

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

• **E. Triển khai VPC endpoint ở mỗi Region để tạo kết nối riêng tư — đây là phương án gần nhất vì VPC endpoint cũng cho kết nối riêng tư, nhưng nó phục vụ mục đích khác: endpoint dùng để truy cập DỊCH VỤ AWS (S3, DynamoDB) hoặc dịch vụ được phơi qua PrivateLink. Nó không nối hai VPC với nhau để instance nói chuyện trực tiếp.
• **D. Khởi chạy NAT Gateway trong public subnet của mỗi VPC — đi ngược yêu cầu: NAT gateway cho instance ra Internet công cộng. Đề nói rõ không được đi qua Internet.
• **B. Tạo Egress-only Internet Gateway — sai cả mục đích lẫn giao thức: nó cho phép instance IPv6 ra Internet một chiều. Vẫn là Internet, và chỉ dành cho IPv6.

Ghi nhớ

Ba cách kết nối các VPC — bảng cần thuộc: | Cách | Bắc cầu | Xuyên Region | Chi phí | |---|---|---|---| | VPC Peering | ❌ KHÔNG | ✅ | không phí giờ, chỉ phí truyền dữ liệu | | Transit Gateway | ✅ | ✅ (qua TGW peering) | phí attachment + phí mỗi GB | | PrivateLink | — (chỉ phơi một dịch vụ) | ✅ | phí endpoint + phí mỗi GB |

Quy tắc chọn:

2–3 VPC, kết nối đơn giản → peering ← câu này Nhiều VPC, nhiều tài khoản, cần bắc cầu → Transit Gateway Chỉ cần gọi một dịch vụ, không nối toàn mạng → PrivateLink

Hạn chế lớn nhất của peering: KHÔNG bắc cầu.

A ◀peering▶ B ◀peering▶ C
    → A KHÔNG tới được C
    → muốn A nói với C thì phải tạo peering A–C riêng
        ↓
    N VPC cần N×(N−1)/2 kết nối
    10 VPC → 45 kết nối

Đó là lý do Transit Gateway tồn tại.

Bốn bước bắt buộc để peering hoạt động:

① Tạo peering connection
② Bên kia CHẤP NHẬN
③ Thêm ROUTE ở CẢ HAI route table       ← bước hay quên nhất
④ Cập nhật SECURITY GROUP cho phép CIDR đối tác

Ba yêu cầu và hạn chế của VPC peering: | Yêu cầu | Chi tiết | |---|---| | CIDR KHÔNG được chồng lấn | điều kiện tuyệt đối — không có cách khắc phục | | Không hỗ trợ định tuyến bắc cầu | ← nêu ở trên | | Không dùng chung gateway endpoint | VPC A không dùng được S3 endpoint của VPC B |

Dòng đầu là lý do phải quy hoạch CIDR ngay từ đầu: nếu hai VPC đều dùng 10.0.0.0/16, không peering được, và cách sửa duy nhất là dựng lại một trong hai.

Ba đặc điểm của inter-Region peering: | Đặc điểm | Chi tiết | |---|---| | Lưu lượng MÃ HOÁ tự động | đi trên mạng xương sống AWS | | Không có nút thắt băng thông đơn | khác VPN site-to-site | | Có phí truyền dữ liệu xuyên Region | ~0,02 USD/GB |

Ba tính năng KHÔNG hỗ trợ với inter-Region peering:

✗ IPv6 (chỉ hỗ trợ trong cùng Region)
✗ Tham chiếu security group của VPC đối tác
✗ Phân giải DNS riêng tư qua peering (phải bật tường minh)

Bật phân giải DNS qua peering nếu cần gọi nhau bằng tên:

aws ec2 modify-vpc-peering-connection-options   --vpc-peering-connection-id pcx-0abc123   --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

Và với inter-Region, security group KHÔNG tham chiếu chéo được:

Trong cùng Region:  Source = sg-xxxxx của VPC đối tác  ✅
Xuyên Region:       phải dùng CIDR                      ← ràng buộc

Ba cách kiểm chứng kết nối: | Cách | Chi tiết | |---|---| | VPC Reachability Analyzer | kiểm tra đường đi mà không cần gửi lưu lượng thật | | VPC Flow Logs | xem ACCEPT/REJECT của từng luồng | | ping hoặc telnet | kiểm tra thực tế (nhớ mở ICMP nếu dùng ping) |

Và một lời khuyên khi quy hoạch mạng đa Region: hãy đặt sơ đồ CIDR ngay từ đầu — ví dụ 10.0.x.x cho Region A, 10.1.x.x cho Region B, 10.2.x.x cho tại chỗ. Chồng lấn CIDR là loại vấn đề mà càng phát hiện muộn càng đắt để sửa.

Đáp án

A — Gắn các VPC vào một Transit Gateway bật Equal Cost Multipath Routing (ECMP) và thêm các tunnel VPN bổ sung.

Vì sao đúng

Đề cần tăng thông lượng của kết nối VPN — và ECMP trên Transit Gateway là cách duy nhất trong bốn phương án làm được.

Giới hạn cơ bản của VPN:

Mỗi tunnel VPN của AWS: tối đa khoảng 1,25 Gbps
    → đây là giới hạn CỨNG cho MỘT tunnel
    → không cấu hình cao hơn được

ECMP phá vỡ giới hạn đó bằng cách gộp nhiều tunnel:

Equal Cost Multipath Routing:
    → nhiều tunnel VPN cùng dẫn tới một đích
    → BGP quảng bá cùng một tuyến với cùng chi phí
    → Transit Gateway phân phối lưu lượng ĐỀU qua tất cả
        ↓
    4 tunnel × 1,25 Gbps = 5 Gbps
    8 tunnel × 1,25 Gbps = 10 Gbps

Và điểm mấu chốt: ECMP CHỈ có ở Transit Gateway.

Virtual private gateway (VGW):
    ✗ KHÔNG hỗ trợ ECMP
    → mỗi kết nối VPN có 2 tunnel, nhưng chỉ 1 hoạt động (active/standby)
    → thông lượng vẫn giới hạn ở 1,25 Gbps

Transit Gateway:
    ✓ HỖ TRỢ ECMP
    → mọi tunnel cùng hoạt động
    → thông lượng cộng dồn

aws ec2 create-transit-gateway   --options AmazonSideAsn=64512,VpnEcmpSupport=enable

aws ec2 create-vpn-connection   --type ipsec.1 --transit-gateway-id tgw-0abc123   --customer-gateway-id cgw-0abc123   --options TunnelOptions='[{},{}]'

Yêu cầu bắt buộc: phải dùng ĐỊNH TUYẾN ĐỘNG (BGP) — ECMP không hoạt động với static routing.

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

• **C. Sửa cấu hình VPN bằng cách tăng số tunnel để mở rộng thông lượng — đây là phương án gần nhất và về ý tưởng là đúng, nhưng nó thiếu điều kiện quyết định: mỗi kết nối VPN luôn có đúng 2 tunnel (không thêm được), và nếu không có Transit Gateway với ECMP thì các tunnel không cộng dồn băng thông — chúng chỉ là active/standby.
• **B. Thêm virtual private gateway vào VPC và bật ECMP — sai hai chỗ: mỗi VPC chỉ gắn được MỘT virtual private gateway, và VGW KHÔNG hỗ trợ ECMP.
• **D. Định tuyến lại một số kết nối VPN sang customer gateway thứ hai ở phía mạng từ xa — chỉ phân tán tải, không tăng tổng thông lượng cho một luồng: nó giúp nếu nút thắt nằm ở thiết bị phía khách hàng, nhưng không giải quyết giới hạn 1,25 Gbps mỗi tunnel cho từng luồng dữ liệu.

Ghi nhớ

Giới hạn băng thông của các loại kết nối: | Loại | Băng thông | |---|---| | Một tunnel VPN | ~1,25 Gbps | | VPN + Transit Gateway ECMP | cộng dồn theo số tunnel | | Direct Connect | 50 Mbps – 100 Gbps | | Direct Connect LAG | gộp nhiều kết nối DX |

Virtual Private Gateway và Transit Gateway — bảng phân biệt: | | Virtual Private Gateway | Transit Gateway | |---|---|---| | Số lượng mỗi VPC | 1 | gắn được nhiều VPC vào một TGW | | ECMP | ❌ KHÔNG | ✅ CÓ | | Nhiều VPC dùng chung | ❌ | ✅ | | Bắc cầu giữa các VPC | ❌ | ✅ | | Multicast | ❌ | ✅ | | Chi phí | miễn phí | phí attachment + phí mỗi GB |

Cấu trúc một kết nối VPN của AWS:

Mỗi VPN connection = 2 TUNNEL (để dự phòng)
    → hai tunnel tới hai endpoint ở hai AZ khác nhau
    → với VGW: 1 active, 1 standby
    → với TGW + ECMP: CẢ HAI cùng hoạt động

Ba yêu cầu để ECMP hoạt động: | Yêu cầu | Chi tiết | |---|---| | Transit Gateway với VpnEcmpSupport=enable | bật lúc tạo hoặc sửa sau | | Định tuyến ĐỘNG bằng BGP | static route KHÔNG dùng được ECMP | | Thiết bị phía khách hàng hỗ trợ BGP và nhiều tunnel | |

Và ECMP phân phối theo LUỒNG, không theo gói tin:

Một luồng TCP đơn lẻ vẫn đi qua MỘT tunnel
    → vẫn giới hạn 1,25 Gbps cho luồng đó
    → ECMP tăng TỔNG thông lượng khi có NHIỀU luồng

Đây là chi tiết quan trọng: nếu vấn đề là một lần truyền tệp lớn duy nhất, ECMP không giúp gì — nó giúp khi có nhiều người dùng đồng thời, đúng như tình huống của đề.

Ba lựa chọn khi VPN không đủ: | Lựa chọn | Đặc điểm | |---|---| | Thêm tunnel với ECMP | nhanh triển khai, rẻ ← câu này | | AWS Direct Connect | băng thông cao và ổn định, nhưng mất hàng TUẦN để lắp đặt | | Accelerated Site-to-Site VPN | dùng Global Accelerator — độ trễ ổn định hơn |

Accelerated VPN đáng biết: nó định tuyến lưu lượng VPN qua điểm biên AWS gần nhất rồi đi trên mạng xương sống — cải thiện đáng kể độ trễ và ổn định khi mạng Internet công cộng không tốt.

Ba giới hạn của Transit Gateway cần biết: | Giới hạn | Giá trị | |---|---| | Băng thông mỗi VPC attachment | 50 Gbps | | Băng thông mỗi VPN attachment | 1,25 Gbps mỗi tunnel | | Số attachment mỗi TGW | 5.000 |

Ba lưu ý về chi phí Transit Gateway: | Khoản | Chi tiết | |---|---| | Phí mỗi attachment mỗi giờ | tích luỹ theo số VPC và VPN | | Phí xử lý dữ liệu mỗi GB | thường lớn hơn phí attachment | | Phí VPN connection | tính riêng |

Và một lời khuyên dài hạn: nếu nghẽn băng thông là vấn đề thường xuyên, Direct Connect là giải pháp căn bản hơn — nó cho băng thông cam kết và độ trễ ổn định. Kết hợp DX làm đường chính với VPN làm dự phòng là kiến trúc được AWS khuyến nghị.

Và một lưu ý khi triển khai ECMP: hãy kiểm tra thiết bị phía khách hàng có hỗ trợ nhiều tunnel BGP đồng thời không, và có đủ năng lực xử lý không. Nút thắt thường chuyển sang thiết bị đó sau khi đã gỡ được giới hạn ở phía AWS.