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

Đáp án

B — Cân nhắc KHÔNG dùng Multi-AZ cho database của môi trường phát triển và kiểm thử.

Vì sao đúng

Đề nêu ràng buộc rõ: giảm chi phí mà KHÔNG ảnh hưởng tới tính sẵn sàng và hiệu năng của hệ thống quan trọng.

Và Multi-AZ cho môi trường dev/test là chi phí không tương xứng:

Multi-AZ nhân ĐÔI chi phí database
    → vì bạn trả tiền cho cả instance standby
        ↓
Môi trường dev và test:
    → KHÔNG phải hệ thống quan trọng
    → ngừng vài phút không ảnh hưởng khách hàng
    → không cần sẵn sàng cao

Và việc tắt Multi-AZ ở dev/test không đụng gì tới sản xuất:

Database sản xuất  → GIỮ Multi-AZ  ✅
Database dev/test  → chuyển Single-AZ → tiết kiệm 50% cho hai môi trường

Đây chính là "giảm chi phí mà không ảnh hưởng hệ thống quan trọng".

aws rds modify-db-instance --db-instance-identifier db-phat-trien   --no-multi-az --apply-immediately

Và còn nhiều cách tiết kiệm khác cho môi trường không phải sản xuất: | Cách | Mức tiết kiệm | |---|---| | Tắt Multi-AZ | 50% chi phí database | | Dừng instance ngoài giờ làm việc | tới 65% | | Dùng instance nhỏ hơn | tuỳ mức thu nhỏ | | Giảm thời hạn giữ backup | nhỏ nhưng có |

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

• **C. Dùng Spot Instance thay Reserved Instance — đây là phương án gần nhất vì Spot thực sự rẻ nhất, nhưng nó vi phạm ràng buộc của đề: Spot bị thu hồi bất cứ lúc nào. Với hai máy chủ web sản xuất đang chạy CPU 90%, mất máy đột ngột là ảnh hưởng trực tiếp tới tính sẵn sàng.
• **A. Dùng On-Demand thay Reserved Instance — làm tăng chi phí: On-Demand đắt hơn Reserved. Và đề nói máy chạy CPU 90% ổn định — đó chính là mẫu tải lý tưởng cho Reserved Instance.
• **D. Bỏ Elastic Load Balancer — phá huỷ tính sẵn sàng: ALB là thứ phân phối tải và loại bỏ instance hỏng. Gỡ nó đi là tạo ra điểm hỏng đơn.

Ghi nhớ

Nguyên tắc tối ưu chi phí: phân biệt môi trường theo mức quan trọng. | Môi trường | Sẵn sàng cao | Chiến lược chi phí | |---|---|---| | Sản xuất | bắt buộc | Reserved Instance / Savings Plan cho mức nền | | Staging | vừa | Single-AZ, dừng ngoài giờ | | Dev/Test | không cần | Single-AZ, dừng ngoài giờ, instance nhỏ, Spot |

Multi-AZ và Read Replica — đừng nhầm khi tối ưu: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Standby phục vụ truy vấn | ❌ KHÔNG | ✅ | | Chi phí | gấp đôi | thêm theo số replica | | Bỏ đi ở dev/test | ✅ hợp lý | tuỳ nhu cầu |

Ba việc Multi-AZ mang lại mà dev/test không cần: | Lợi ích | Với dev/test | |---|---| | Failover tự động 60–120 giây | không quan trọng | | Không mất dữ liệu khi AZ sập | có thể dựng lại từ snapshot | | Bảo trì không gián đoạn | chấp nhận được vài phút ngừng |

Ba cách tự động hoá việc dừng database dev/test ngoài giờ: | Cách | Chi tiết | |---|---| | AWS Instance Scheduler | giải pháp dựng sẵn, theo thẻ | | EventBridge + Lambda | tự viết, linh hoạt | | Aurora Serverless v2 | tự co giãn, không cần lịch |

Và lưu ý về giới hạn dừng RDS:

RDS dừng được tối đa 7 NGÀY
    → sau đó AWS TỰ ĐỘNG khởi động lại để vá lỗi
    → cần tự động hoá dừng lại

Và Aurora Serverless v2 đáng cân nhắc cho dev/test:

Tự co xuống mức tối thiểu (0,5 ACU) khi không ai dùng
    → không cần lịch dừng/bật
    → không có giới hạn 7 ngày
    → đổi lại: không co về 0 nên vẫn có chi phí nền nhỏ

Ba nhóm tối ưu chi phí trên AWS: | Nhóm | Ví dụ | |---|---| | Chọn đúng mô hình mua | Savings Plan cho mức nền, Spot cho việc chịu gián đoạn | | Chọn đúng kích thước | Compute Optimizer chỉ ra instance quá lớn | | Tắt thứ không dùng | dev/test ngoài giờ, volume mồ côi, EIP rảnh |

Và với hai máy chủ web chạy CPU 90% ổn định trong đề:

CPU 90% liên tục
    → đây là mức khá cao, ít biên độ cho đột biến
    → cân nhắc THÊM máy (chứ không phải bớt)
    → hoặc chuyển sang Auto Scaling group để co giãn linh hoạt

Đây là điểm cần lưu ý về kiến trúc mà câu hỏi không hỏi tới, nhưng CPU 90% thường xuyên là dấu hiệu hệ thống đang chạy sát giới hạn.

Ba công cụ tìm cơ hội tiết kiệm: | Công cụ | Việc | |---|---| | AWS Cost Explorer | phân tích chi phí theo dịch vụ, thẻ, tài khoản | | AWS Compute Optimizer | gợi ý instance phù hợp hơn dựa trên mức dùng thật | | Trusted Advisor | phát hiện tài nguyên nhàn rỗi | | Cost Anomaly Detection | phát hiện tăng bất thường |

Và một lời khuyên: hãy gắn thẻ MoiTruong cho mọi tài nguyên và kích hoạt nó làm cost allocation tag. Khi đó Cost Explorer cho biết chính xác dev/test đang chiếm bao nhiêu phần trăm hoá đơn — thường là con số bất ngờ, và là nơi dễ cắt giảm nhất mà không ai phàn nàn.

Đáp án

C — Egress-only Internet Gateway.

Vì sao đúng

Đề cho hai dữ kiện quyết định, và chúng chỉ thẳng tới một lựa chọn: | Dữ kiện | Kết luận | |---|---| | Subnet dùng IPv6 | NAT Gateway CHỈ hỗ trợ IPv4 | | Cho phép ra Internet nhưng CHẶN lưu lượng IPv6 đi VÀO | đúng định nghĩa của egress-only IGW |

Vì sao IPv6 cần cơ chế riêng:

IPv4 dùng NAT:
    → địa chỉ riêng tư (10.x, 172.16-31.x, 192.168.x)
    → NAT đổi sang IP công khai khi ra ngoài
    → và NAT tự nhiên chặn kết nối vào

IPv6:
    → MỌI địa chỉ IPv6 đều là địa chỉ CÔNG KHAI
    → không có khái niệm "địa chỉ riêng tư"
    → không có NAT
        ↓
    → cần một cơ chế khác để chặn chiều vào

Và egress-only Internet Gateway làm đúng việc đó:

Egress-only IGW:
    ✓ cho phép instance IPv6 KHỞI TẠO kết nối ra Internet
    ✓ cho phép phản hồi quay về (STATEFUL)
    ✗ CHẶN mọi kết nối khởi tạo TỪ Internet

Và nó MIỄN PHÍ — khác hẳn NAT Gateway.

aws ec2 create-egress-only-internet-gateway --vpc-id vpc-0abc123

aws ec2 create-route --route-table-id rtb-private   --destination-ipv6-cidr-block ::/0   --egress-only-internet-gateway-id eigw-0abc123

Chú ý ::/0 — đó là ký hiệu "mọi địa chỉ IPv6", tương đương 0.0.0.0/0 của IPv4.

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

• **A. NAT Gateway — đây là phương án gần nhất và làm đúng chức năng tương đương, nhưng nó CHỈ hỗ trợ IPv4. Đề nói rõ subnet dùng IPv6.
• **B. NAT instance — cùng lý do: NAT instance cũng chỉ xử lý IPv4.
• **D. Internet Gateway — cho lưu lượng HAI CHIỀU: nó cho phép cả kết nối đi ra lẫn kết nối đi vào. Với máy chủ chứa dữ liệu tài chính, đó là điều phải tránh.

Ghi nhớ

Bốn cổng ra vào của VPC — bảng cần thuộc: | Cổng | Chiều | Giao thức | Chi phí | |---|---|---|---| | Internet Gateway | HAI chiều | IPv4, IPv6 | miễn phí | | NAT Gateway | CHỈ ĐI RA | IPv4 | ~32 USD/tháng + phí mỗi GB | | Egress-Only IGW | CHỈ ĐI RA | IPv6 | MIỄN PHÍ | | VPC Endpoint | tới dịch vụ AWS | — | gateway miễn phí, interface có phí |

Quy tắc nhận diện:

"private subnet", "outbound only", "IPv4" → NAT Gateway "private subnet", "outbound only", "IPv6" → Egress-Only Internet Gateway "two-way access" → Internet Gateway

Ba khác biệt căn bản giữa IPv4 và IPv6 trong VPC: | | IPv4 | IPv6 | |---|---|---| | Địa chỉ riêng tư | ✅ (RFC 1918) | ❌ mọi địa chỉ đều công khai | | NAT | ✅ | ❌ không có | | Chặn chiều vào | NAT tự nhiên chặn | cần egress-only IGW | | CIDR của VPC | bạn chọn | AWS cấp một khối /56 |

Và với IPv6, mỗi subnet nhận một khối /64 — con số cố định, không tuỳ chỉnh được.

Ba lưu ý khi bật IPv6 cho VPC: | Lưu ý | Chi tiết | |---|---| | Không tắt IPv4 được | VPC luôn là dual-stack, không thể chỉ IPv6 | | Phải cập nhật security group và NACL | rule IPv4 KHÔNG áp cho IPv6 | | Một số dịch vụ chưa hỗ trợ IPv6 đầy đủ | kiểm tra trước khi thiết kế |

Dòng giữa là lỗi cấu hình phổ biến:

Security group có rule: cho phép 0.0.0.0/0 cổng 443
    → CHỈ áp cho IPv4
    → lưu lượng IPv6 vẫn bị chặn
        ↓
    Phải thêm rule riêng: ::/0 cổng 443

Ký hiệu CIDR của IPv6: | Ký hiệu | Ý nghĩa | |---|---| | ::/0 | mọi địa chỉ IPv6 (tương đương 0.0.0.0/0) | | /128 | đúng một địa chỉ (tương đương /32 của IPv4) | | /64 | một subnet chuẩn | | /56 | khối AWS cấp cho một VPC |

Ba lợi ích của IPv6 trên AWS: | Lợi ích | Chi tiết | |---|---| | Không lo cạn địa chỉ | không gian gần như vô hạn | | Không cần NAT | tiết kiệm chi phí NAT Gateway | | Không lo chồng lấn CIDR | vấn đề kinh điển khi peering VPC hoặc kết nối lai |

Dòng giữa là lợi ích kinh tế thật: NAT Gateway tốn khoảng 32 USD/tháng cộng phí mỗi GB, trong khi egress-only IGW hoàn toàn miễn phí.

Và với dữ liệu tài chính như đề mô tả, hãy thêm nhiều lớp bảo vệ: | Lớp | Cấu hình | |---|---| | Private subnet | không có route tới Internet Gateway | | Egress-only IGW cho chiều ra | ← câu này | | Security group chặt | chỉ mở cổng và nguồn cần thiết | | NACL với rule IPv6 tường minh | lớp phòng thủ bổ sung ở mức subnet | | VPC endpoint cho dịch vụ AWS | lưu lượng không ra Internet chút nào |

Và cân nhắc: máy chủ này có THỰC SỰ cần ra Internet không?

Nếu chỉ cần gọi dịch vụ AWS (S3, DynamoDB, SSM):
    → dùng VPC ENDPOINT
    → không cần đường ra Internet nào
    → bề mặt tấn công nhỏ nhất

Ba công cụ chẩn đoán khi lưu lượng IPv6 không đi được: | Công cụ | Việc | |---|---| | VPC Flow Logs | ghi cả luồng IPv4 và IPv6, thấy ACCEPT/REJECT | | VPC Reachability Analyzer | kiểm tra đường đi mà không cần gửi lưu lượng thật | | Kiểm tra route table | có route ::/0 chưa |

Và một lời khuyên khi triển khai dual-stack: hãy kiểm thử cả hai giao thức riêng biệt. Rất nhiều sự cố xảy ra vì rule security group chỉ được cập nhật cho IPv4, và triệu chứng là "một số client kết nối được, một số thì không" — tuỳ vào việc client đó dùng IPv4 hay IPv6.

Đáp án

C — Amazon FSx for Lustre.

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 Lustre: | Yêu cầu | Cơ chế | |---|---| | HPC cần hệ thống tệp hiệu năng cao, mở rộng được | Lustre là hệ thống tệp song song chuẩn của HPC | | Tối ưu cho xử lý workload hiệu quả | thông lượng hàng trăm GB/giây | | Giao diện hệ thống tệp nhanh và mở rộng được | POSIX đầy đủ | | Làm việc NGUYÊN BẢN với S3, xử lý dữ liệu S3 qua giao diện POSIX | liên kết trực tiếp với S3 — đặc trưng RIÊNG của FSx for Lustre |

Vế cuối là điểm phân biệt tuyệt đối:

FSx for Lustre liên kết với S3 bucket:
    → object trong S3 xuất hiện như TỆP trong hệ thống tệp
    → đọc lần đầu → tự nạp từ S3 (lazy loading)
    → ghi kết quả → tự đẩy ngược về S3
        ↓
    "process your S3 data with a high-performance POSIX interface"
    → đây là câu quảng bá chính thức của FSx for Lustre

aws fsx create-file-system --file-system-type LUSTRE   --storage-capacity 1200 --subnet-ids subnet-0abc   --lustre-configuration     DeploymentType=PERSISTENT_2,PerUnitStorageThroughput=250,DataRepositoryConfiguration='{ImportPath=s3://kho-du-lieu-hpc/}'

Và Lustre là hệ thống tệp được dùng ở các siêu máy tính lớn nhất thế giới — nó được thiết kế cho đúng loại workload này.

Con số hiệu năng:

Thông lượng: hàng trăm GB/giây
IOPS:        hàng triệu
Độ trễ:      dưới một mili giây

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

• **A. Amazon Elastic File System (EFS) — đây là phương án gần nhất vì cũng là hệ thống tệp POSIX chia sẻ được, nhưng nó thua ở hai điểm: thông lượng thấp hơn nhiều (hàng GB/giây so với hàng trăm GB/giây), và KHÔNG liên kết nguyên bản với S3. Đề nêu rõ yêu cầu "works natively with Amazon S3".
• **B. Amazon FSx for Windows File Server — sai hệ điều hành và giao thức: nó dùng SMB cho môi trường Windows. HPC gần như luôn chạy trên Linux với POSIX.
• **D. Amazon EBS — không chia sẻ được: EBS volume gắn với một instance trong một AZ. Cụm HPC cần hàng chục tới hàng trăm node cùng đọc một tập dữ liệu.

Ghi nhớ

Bốn dịch vụ trong họ Amazon FSx — bảng cần thuộc: | Dịch vụ | Giao thức | Dùng cho | |---|---|---| | FSx for Lustre | Lustre (POSIX) | HPC, học máy — thông lượng cực cao, liên kết S3 ← câu này | | FSx for Windows File Server | SMB | ứng dụng Windows, Active Directory | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | môi trường lai có NetApp | | FSx for OpenZFS | NFS | thay thế máy chủ ZFS |

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

"HPC", "Lustre", "hundreds of GB/s", "natively with S3", "POSIX" → FSx for Lustre "SMB", "Windows", "Active Directory", "NTFS" → FSx for Windows "NFS", "shared file system", "multiple AZs" → EFS

EFS và FSx for Lustre — bảng so sánh: | | EFS | FSx for Lustre | |---|---|---| | Thông lượng | hàng GB/giây | hàng TRĂM GB/giây | | Độ trễ | mili giây thấp | dưới một mili giây | | Đa AZ | ✅ mặc định | Single-AZ (Persistent) | | Liên kết S3 | ❌ | ✅ tự nạp và ghi ngược | | Chi phí | vừa | cao hơn | | Giao thức | NFS | Lustre |

Đánh đổi rõ ràng: Lustre nhanh hơn nhiều nhưng chỉ trong một AZ.

Hai loại triển khai của FSx for Lustre: | Loại | Đặc điểm | |---|---| | Scratch | KHÔNG sao chép dữ liệu — rẻ nhất, cho việc tạm | | Persistent | có sao chép trong AZ, tự thay thành phần hỏng |

Scratch phù hợp cho công việc chạy một lần:

Nạp dữ liệu từ S3 → tính toán → ghi kết quả về S3 → xoá file system
    → dữ liệu gốc và kết quả đều an toàn ở S3
    → file system chỉ là vùng làm việc tạm

Đây là mẫu dùng phổ biến nhất và rẻ nhất cho HPC.

Ba chế độ liên kết với S3: | Chế độ | Việc | |---|---| | Import | object S3 xuất hiện như tệp, nạp khi đọc lần đầu | | Export | ghi kết quả ngược về S3 | | Auto import/export | tự đồng bộ hai chiều |

# Đẩy kết quả về S3 sau khi tính toán xong
aws fsx create-data-repository-task --type EXPORT_TO_REPOSITORY   --file-system-id fs-0abc123 --paths /ket-qua   --report Enabled=true,Path=s3://kho-du-lieu-hpc/bao-cao/

Ba cấu hình hiệu năng: | Cấu hình | Chi tiết | |---|---| | PerUnitStorageThroughput | 125, 250, 500, hoặc 1.000 MB/giây mỗi TiB | | Dung lượng | tối thiểu 1,2 TiB, tăng theo bội số | | Thông lượng tổng | dung lượng × thông lượng mỗi TiB |

Ví dụ: 4,8 TiB × 500 MB/giây = 2,4 GB/giây tổng thông lượng.

Ba lưu ý khi dùng FSx for Lustre với HPC: | Lưu ý | Chi tiết | |---|---| | Client cần cài Lustre client | có sẵn trong AWS ParallelCluster AMI | | Đặt trong CÙNG AZ với compute node | tránh phí truyền chéo AZ và độ trễ | | Kết hợp với cluster placement group | tối ưu mạng giữa các node |

Và AWS ParallelCluster tự động hoá toàn bộ:

ParallelCluster dựng sẵn:
    ✓ head node và compute node
    ✓ bộ lập lịch Slurm
    ✓ FSx for Lustre gắn sẵn
    ✓ EFA cho mạng độ trễ thấp
    ✓ tự co giãn theo hàng đợi công việc

Kiến trúc HPC hoàn chỉnh trên AWS:

S3 (kho dữ liệu chính, rẻ, bền vững)
    ↕ liên kết tự động
FSx for Lustre (vùng làm việc, thông lượng cực cao)
    ↕
Compute node (c5n hoặc hpc6a, có EFA, trong cluster placement group)

Và một lưu ý về chi phí: FSx for Lustre khá đắt tính theo GB. Mẫu tiết kiệm nhất là giữ dữ liệu ở S3 và chỉ tạo file system Lustre khi chạy công việc, rồi xoá đi sau khi đẩy kết quả về S3 — chi phí chỉ phát sinh trong thời gian tính toán thật sự.

Đáp án

D — Amazon ElastiCache for Memcached với Auto Discovery.

Vì sao đúng

Đề nêu bốn yêu cầu, và Memcached là lựa chọn khớp nhất: | Yêu cầu | Cơ chế | |---|---| | Lưu trữ phiên đăng nhập DÙNG CHUNG, mở rộng được | cả Redis lẫn Memcached đều làm được | | Hỗ trợ hiệu năng ĐA LUỒNG (multithreaded) | Memcached là ĐA LUỒNG; Redis cổ điển đơn luồng | | Tự phát hiện node hỏng | Auto Discovery cập nhật danh sách node tự động | | Độ trễ dưới một mili giây | cả hai đều đạt |

Vế "multithreaded performance" là điểm phân biệt quyết định:

Memcached:
    → kiến trúc ĐA LUỒNG
    → tận dụng được nhiều lõi CPU của một node
    → thông lượng cao hơn trên cùng phần cứng

Redis (bản cổ điển):
    → xử lý lệnh trên MỘT luồng
    → thêm lõi không tăng thông lượng xử lý lệnh

Và Auto Discovery giải quyết vế phát hiện node:

Client kết nối tới CONFIGURATION ENDPOINT
    → nhận danh sách node hiện tại
    → node bị thay hoặc thêm → danh sách tự cập nhật
    → client KHÔNG phải cấu hình lại

aws elasticache create-cache-cluster   --cache-cluster-id cum-phien-dang-nhap   --engine memcached --cache-node-type cache.r6g.large   --num-cache-nodes 3 --az-mode cross-az

Và lưu phiên trong cache là điều kiện để dùng Spot Instance:

Phiên nằm trên instance:
    → Spot bị thu hồi → người dùng bị đăng xuất

Phiên nằm trong cache dùng chung:
    → mất instance nào cũng không ảnh hưởng
    → bất kỳ máy nào cũng phục vụ được người dùng đó

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

• **B. ElastiCache for Redis Global Datastore — đây là phương án gần nhất và Redis rất mạnh cho việc lưu phiên, nhưng nó không khớp yêu cầu "multithreaded". Và Global Datastore dùng để sao chép giữa các REGION — trong khi đề chỉ cần một tầng phiên dùng chung, không phải sao chép đa Region.
• **A. Sticky session của ELB — đi ngược yêu cầu: sticky session buộc người dùng dính với một instance cụ thể. Với Spot Instance có thể bị thu hồi bất cứ lúc nào, đó là thiết kế mong manh — mất máy là mất phiên.
• **C. Amazon RDS với RDS Proxy — sai loại kho lưu trữ: cơ sở dữ liệu quan hệ có độ trễ cao hơn nhiều so với cache trong bộ nhớ, và lưu phiên trong database là mẫu kém hiệu quả.

Ghi nhớ về chất lượng câu hỏi

Sự phân biệt "Memcached đa luồng, Redis đơn luồng" đã bớt rõ ràng:

Redis 6.0+ có I/O threading (xử lý mạng đa luồng)
Valkey (bản fork của Redis mà AWS hỗ trợ) tiếp tục cải thiện
ElastiCache Serverless tự co giãn, không cần chọn node type

Nhưng lõi xử lý lệnh của Redis vẫn đơn luồng, nên nếu đề nêu đích danh "multithreaded" thì Memcached vẫn là đáp án.

Trong thực tế, Redis thường được chọn cho lưu phiên vì nó có sao chép, failover tự động, và bền vững — những thứ Memcached không có.

Ghi nhớ

Redis và Memcached — bảng phân biệt cốt lõi: | | Redis | Memcached | |---|---|---| | Đa luồng | ❌ (lõi xử lý lệnh đơn luồng) | ✅ | | Cấu trúc dữ liệu | list, set, sorted set, hash, stream | chỉ chuỗi | | Bền vững (persistence) | ✅ snapshot và AOF | ❌ | | Sao chép và failover tự động | ✅ | ❌ | | Pub/Sub | ✅ | ❌ | | Giao dịch | ✅ | ❌ | | Mã hoá và xác thực | ✅ AUTH, RBAC, TLS | hạn chế | | Phân mảnh | cluster mode | tự nhiên qua nhiều node |

Quy tắc chọn:

"multithreaded", "simple key-value cache", "scale out horizontally" → Memcached "persistence", "replication", "failover", "data structures", "pub/sub" → Redis

Ba cách lưu phiên đăng nhập trong kiến trúc phân tán: | Cách | Đặc điểm | |---|---| | ElastiCache (Redis hoặc Memcached) | nhanh nhất, độ trễ dưới mili giây ← câu này | | DynamoDB với TTL | bền vững, tự xoá phiên hết hạn, không cần quản lý cụm | | Cookie có chữ ký ở phía client | không cần lưu trữ server, nhưng giới hạn kích thước |

DynamoDB đáng cân nhắc cho phiên:

✓ Độ trễ mili giây một chữ số
✓ TTL tự xoá phiên hết hạn — MIỄN PHÍ
✓ Không quản lý cụm, tự mở rộng
✓ Bền vững qua sự cố
    → đổi lại: chậm hơn cache trong bộ nhớ một chút

Ba đặc điểm của Auto Discovery (Memcached): | Đặc điểm | Chi tiết | |---|---| | Configuration endpoint | một địa chỉ, client tự lấy danh sách node | | Tự cập nhật khi node thay đổi | thêm, bớt, hoặc thay node hỏng | | Cần client hỗ trợ | ElastiCache Cluster Client cho Java, PHP, .NET |

Và ElastiCache tự thay node hỏng:

Node hỏng → ElastiCache tự cấp node mới
    → Auto Discovery cập nhật danh sách
    → client tự chuyển sang node mới
        ↓
    NHƯNG dữ liệu trên node đó MẤT (Memcached không bền vững)
    → phiên của một phần người dùng bị mất

Đây là hạn chế thật của Memcached — với Redis có sao chép thì dữ liệu sống sót.

Ba lưu ý khi dùng Memcached cho phiên: | Lưu ý | Chi tiết | |---|---| | Không bền vững | node hỏng là mất dữ liệu trên node đó | | Không sao chép | không có bản dự phòng | | Đặt node ở nhiều AZ | --az-mode cross-az để giảm ảnh hưởng khi mất một AZ |

Ba biện pháp giảm rủi ro mất phiên: | Biện pháp | Chi tiết | |---|---| | Dùng nhiều node ở nhiều AZ | mất một node chỉ ảnh hưởng một phần người dùng | | Ứng dụng xử lý được cache miss | tạo lại phiên hoặc yêu cầu đăng nhập lại | | Cân nhắc Redis nếu mất phiên là không chấp nhận được | có sao chép và bền vững |

Và với Spot Instance như đề mô tả, hãy xử lý cảnh báo thu hồi:

r = requests.get('http://169.254.169.254/latest/meta-data/spot/instance-action')
if r.status_code == 200:
    # Rút khỏi target group êm ái trong 2 phút còn lại
    elbv2.deregister_targets(TargetGroupArn=tg, Targets=[{'Id': instance_id}])

Và một lời khuyên về kiến trúc: lưu phiên ra ngoài instance là điều kiện tiên quyết để dùng được Spot, Auto Scaling, và triển khai không gián đoạn. Nếu ứng dụng còn giữ phiên trong bộ nhớ máy chủ, đó là thứ nên sửa trước mọi tối ưu khác.

Đáp án

C — Theo mặc định, bản ghi trong Kinesis chỉ truy cập được trong 24 GIỜ kể từ khi được thêm vào stream.

Vì sao đúng

Đề cho hai con số mâu thuẫn nhau, và đó chính là nguyên nhân:

Kinesis Data Stream với CẤU HÌNH MẶC ĐỊNH
    → thời gian giữ dữ liệu: 24 GIỜ
        ↓
Ứng dụng gửi dữ liệu sang S3 mỗi 3 NGÀY
        ↓
Tới ngày thứ 3, dữ liệu của ngày 1 và ngày 2 ĐÃ BỊ XOÁ
    → chỉ còn dữ liệu trong 24 giờ gần nhất

Đó chính xác là triệu chứng mà đề mô tả: chỉ có dữ liệu của ngày cuối, không có dữ liệu của hai ngày trước.

Và đây là hành vi được thiết kế, không phải lỗi:

Kinesis KHÔNG phải kho lưu trữ dài hạn
    → nó là vùng đệm cho xử lý luồng
    → bản ghi hết hạn thì bị xoá tự động, không báo trước

Cách sửa — tăng thời gian giữ:

aws kinesis increase-stream-retention-period   --stream-name luong-cam-bien --retention-period-hours 168
# 168 giờ = 7 ngày, đủ cho chu kỳ 3 ngày với biên độ an toàn

Nhưng cách sửa TỐT HƠN là đổi kiến trúc:

Đọc từ Kinesis LIÊN TỤC (hoặc mỗi vài phút) rồi ghi vào S3
    → Kinesis chỉ là vùng đệm ngắn hạn
    → S3 là kho lưu trữ dài hạn, rẻ hơn hàng chục lần

Kinesis Data Firehose làm đúng việc đó mà không cần viết mã:

aws firehose create-delivery-stream   --delivery-stream-name giao-du-lieu-s3   --delivery-stream-type KinesisStreamAsSource   --kinesis-stream-source-configuration     KinesisStreamARN=<arn>,RoleARN=<arn-role>   --extended-s3-destination-configuration     BucketARN=arn:aws:s3:::kho-du-lieu-iot,BufferingHints='{SizeInMBs=128,IntervalInSeconds=300}'

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

• **B. Ai đó đã xoá bản ghi thủ công trong S3 — đây là phương án gần nhất vì cũng giải thích được việc dữ liệu biến mất, nhưng nó không khớp với mẫu: mất đúng phần cũ hơn 24 giờ là dấu hiệu rất rõ của hết hạn tự động, không phải xoá ngẫu nhiên. Và có thể kiểm chứng bằng CloudTrail.
• **A. S3 bị mất dữ liệu — gần như không thể xảy ra: S3 có độ bền 99,999999999% (11 số 9). Và nếu có sự cố thì nó không chọn riêng dữ liệu cũ.
• **D. Quyền truy cập của Kinesis vào S3 không đủ — triệu chứng sẽ khác: thiếu quyền thì KHÔNG có dữ liệu nào ghi được vào S3, chứ không phải chỉ mất phần cũ.

Ghi nhớ

Thời gian giữ dữ liệu của Kinesis Data Streams — bảng cần thuộc: | Mức | Giá trị | |---|---| | MẶC ĐỊNH | 24 GIỜ | | Tối đa | 365 ngày (8.760 giờ) | | Extended retention | từ 24 giờ tới 7 ngày | | Long-term retention | trên 7 ngày, tính phí thêm |

Con số 24 giờ là mặc định cần nhớ — nó là nguyên nhân của nhiều sự cố mất dữ liệu âm thầm.

Và tăng thời gian giữ tốn tiền:

Giữ 24 giờ:  đã bao gồm trong giá shard
Giữ 7 ngày:  tính thêm phí extended retention
Giữ 365 ngày: tính phí long-term retention theo GB-tháng

Mẫu kiến trúc đúng cho dữ liệu IoT:

Cảm biến → Kinesis Data Streams (giữ 24 giờ – 7 ngày)
    ├─▶ Firehose → S3 (lưu trữ dài hạn, RẺ)
    ├─▶ Lambda → DynamoDB (truy vấn nhanh, dữ liệu hiện tại)
    └─▶ Flink → cảnh báo thời gian thực

Kinesis là vùng đệm, S3 là kho lưu trữ.

Kinesis Data Streams và Data Firehose — bảng phân biệt: | | Data Streams | Data Firehose | |---|---|---| | Giữ dữ liệu | ✅ 24 giờ – 365 ngày | ❌ (đệm rồi giao ngay) | | Phát lại (replay) | ✅ | ❌ | | Nhiều consumer độc lập | ✅ | ❌ | | Bạn viết consumer | ✅ có | ❌ không cần | | Độ trễ | mili giây | tối thiểu ~60 giây | | Đích | tuỳ bạn | S3, Redshift, OpenSearch, Splunk |

Với việc chỉ cần đưa dữ liệu vào S3, Firehose là lựa chọn ít công nhất — không phải viết consumer nào.

Ba tính năng của Firehose đáng dùng cho dữ liệu IoT: | Tính năng | Việc | |---|---| | Gom thành tệp lớn | tránh hàng triệu tệp tí hon trong S3 | | Chuyển sang Parquet | giảm 80–90% dữ liệu quét khi phân tích | | Dynamic partitioning | tự chia thư mục theo ngày hoặc theo trường dữ liệu |

Cả ba giải quyết những vấn đề mà tự viết consumer thường gặp phải.

Ba metric cần đặt alarm cho Kinesis: | Metric | Cảnh báo khi | |---|---| | GetRecords.IteratorAgeMilliseconds | consumer tụt hậu — tiến gần thời gian giữ là SẮP MẤT DỮ LIỆU | | WriteProvisionedThroughputExceeded | thiếu shard | | ReadProvisionedThroughputExceeded | quá nhiều consumer standard |

IteratorAge là metric quan trọng nhất cho tình huống này:

aws cloudwatch put-metric-alarm --alarm-name consumer-tut-hau   --metric-name GetRecords.IteratorAgeMilliseconds   --namespace AWS/Kinesis --statistic Maximum   --period 300 --threshold 43200000   --comparison-operator GreaterThanThreshold   --dimensions Name=StreamName,Value=luong-cam-bien

43.200.000 mili giây = 12 giờ — cảnh báo khi đã dùng hết một nửa thời gian giữ.

Thông lượng của một shard: | Chiều | Giới hạn | |---|---| | Ghi vào | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc (standard) | 2 MB/giây chia cho mọi consumer | | Đọc (enhanced fan-out) | 2 MB/giây riêng mỗi consumer |

Bốn loại shard iterator: | Loại | Bắt đầu đọc từ | |---|---| | LATEST | bản ghi mới nhất | | TRIM_HORIZON | bản ghi cũ nhất CÒN GIỮ | | AT_TIMESTAMP | thời điểm cụ thể | | AT_SEQUENCE_NUMBER | vị trí cụ thể |

Chú ý TRIM_HORIZON: "trim" chính là chỉ việc dữ liệu cũ bị cắt bỏ — tên gọi phản ánh đúng cơ chế hết hạn.

Và một lời khuyên cho hệ thống IoT: hãy đặt thời gian giữ ít nhất gấp đôi chu kỳ xử lý dài nhất. Nếu consumer chạy mỗi 3 ngày thì giữ ít nhất 7 ngày — biên độ đó cứu bạn khi consumer gặp sự cố và phải sửa vài ngày mới xong.

Đáp án

B — Dùng Route 53 để phân phối tải tới nhiều EC2 instance ở mọi AWS Region.

Vì sao đúng

Đề nêu hai yêu cầu, và Route 53 là dịch vụ duy nhất trong bốn phương án đáp ứng được: | Yêu cầu | Cơ chế | |---|---| | Định tuyến theo ĐỘ TRỄ (latency-based) | Route 53 có latency routing policy | | Tới instance ở NHIỀU AWS REGION | Route 53 là dịch vụ TOÀN CẦU |

Và đây là điểm phân biệt cốt lõi: phạm vi của các dịch vụ cân bằng tải.

Elastic Load Balancer (ALB, NLB):
    → phạm vi MỘT REGION
    → không phân phối lưu lượng qua nhiều Region

Route 53:
    → dịch vụ DNS TOÀN CẦU
    → trả về địa chỉ khác nhau cho người dùng ở nơi khác nhau

Cách latency-based routing hoạt động:

Người dùng ở châu Âu truy vấn www.tutorialsdojo.com
    ↓
Route 53 đo độ trễ mạng từ vị trí đó tới mỗi Region
    → trả về IP của instance ở EU (Ireland)

Người dùng ở California
    → trả về IP của instance ở US West

Chú ý: nó dựa trên ĐỘ TRỄ MẠNG THỰC ĐO, không phải khoảng cách địa lý — đôi khi Region xa hơn về địa lý lại có độ trễ thấp hơn do đường truyền tốt hơn.

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"www.tutorialsdojo.com","Type":"A","TTL":60,
    "SetIdentifier":"ohio","Region":"us-east-2",
    "ResourceRecords":[{"Value":"203.0.113.10"}],
    "HealthCheckId":"abc-123"}}]}'

Và HealthCheckId rất quan trọng — nếu không có, Route 53 vẫn gửi người dùng tới Region đã sập.

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

• **C. Dùng Application Load Balancer để phân phối tới instance ở mọi Region — đây là phương án gần nhất vì ALB là dịch vụ cân bằng tải chính, nhưng nó hoạt động TRONG MỘT REGION: ALB không đăng ký được target ở Region khác, và không có khái niệm định tuyến theo độ trễ.
• **A. Dùng Network Load Balancer — cùng lý do: NLB cũng là dịch vụ trong phạm vi một Region.
• **D. Dùng AWS DataSync — sai hoàn toàn về chức năng: DataSync là dịch vụ đồng bộ TỆP giữa các hệ thống lưu trữ. Nó không cân bằng tải gì cả.

Ghi nhớ

Phạm vi hoạt động của các dịch vụ — bảng cần thuộc: | Dịch vụ | Phạm vi | |---|---| | Elastic Load Balancer (ALB, NLB) | MỘT Region (trải nhiều AZ) | | Auto Scaling group | MỘT Region | | Route 53 | TOÀN CẦU | | CloudFront | toàn cầu | | Global Accelerator | toàn cầu — IP tĩnh anycast |

Quy tắc nhận diện:

Cân bằng tải TRONG một Region → ALB hoặc NLB Định tuyến GIỮA các Region → Route 53 hoặc Global Accelerator

Bảy chính sách định tuyến của Route 53: | Chính sách | Quyết định theo | |---|---| | Simple | một bản ghi, không logic | | Weighted | tỷ lệ bạn đặt | | Latency-based | ĐỘ TRỄ MẠNG thực đo ← câu này | | Failover | health check — primary/secondary | | Geolocation | VỊ TRÍ ĐỊA LÝ của người dùng | | Geoproximity | khoảng cách, có bias điều chỉnh được | | Multivalue answer | tới 8 bản ghi lành mạnh | | IP-based | dải IP của người dùng |

Latency-based và Geolocation — đừng nhầm:

Latency-based: "Region nào phản hồi NHANH NHẤT cho người này?"
    → tối ưu HIỆU NĂNG

Geolocation:   "Người này ở nước nào?"
    → dùng cho TUÂN THỦ PHÁP LÝ, nội dung theo khu vực

Ba yêu cầu chung cho mọi chính sách nhiều bản ghi: | Yêu cầu | Chi tiết | |---|---| | Cùng tên và cùng loại bản ghi | | | SetIdentifier khác nhau | bắt buộc | | Nên có health check | Route 53 loại bản ghi hỏng khỏi câu trả lời |

Và với latency routing, phải khai Region cho từng bản ghi — Route 53 dùng nó để tra bảng độ trễ.

Ba hạn chế của việc dùng DNS để cân bằng tải: | Hạn chế | Chi tiết | |---|---| | Client CACHE kết quả DNS | thay đổi có hiệu lực chậm, phụ thuộc TTL | | Không biết tình trạng TẢI của máy | chỉ biết khoẻ hay hỏng qua health check | | Phân phối theo mỗi lần phân giải, không theo request | tỷ lệ thực tế lệch |

Vì vậy kiến trúc đa Region chuẩn kết hợp cả hai tầng:

Route 53 (latency-based)
    ├─▶ Region A: ALB → Auto Scaling group
    ├─▶ Region B: ALB → Auto Scaling group
    └─▶ Region C: ALB → Auto Scaling group
        ↓
    Route 53 chọn Region, ALB cân bằng trong Region

Và AWS Global Accelerator là lựa chọn thay thế đáng biết: | | Route 53 latency | Global Accelerator | |---|---|---| | Cơ chế | DNS | IP TĨNH ANYCAST | | Chuyển đổi khi Region hỏng | phụ thuộc TTL | trong vài GIÂY | | Lưu lượng đi qua | Internet công cộng | mạng xương sống AWS | | Hỗ trợ TCP/UDP không phải HTTP | ✅ | ✅ | | Chi phí | phí truy vấn DNS | phí giờ + phí mỗi GB |

Global Accelerator tốt hơn khi cần chuyển đổi nhanh — nó không phụ thuộc vào cache DNS của client.

Ba loại health check của Route 53: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới địa chỉ cụ thể | | Calculated | kết hợp kết quả nhiều health check khác | | CloudWatch alarm | dựa trên trạng thái một alarm |

Calculated health check hữu ích cho kiến trúc nhiều tầng: coi một Region là khoẻ chỉ khi cả web tier lẫn database tier đều khoẻ.

Ba lưu ý về TTL trong kiến trúc đa Region: | Lưu ý | Chi tiết | |---|---| | TTL thấp (60 giây) cho bản ghi failover | chuyển đổi nhanh hơn | | Hạ TTL TRƯỚC khi thay đổi lớn | vài ngày trước | | TTL thấp làm tăng số truy vấn DNS | và tăng chi phí Route 53 |

Và một lưu ý về kiến trúc đa Region: định tuyến lưu lượng là phần dễ nhất. Phần khó là đồng bộ dữ liệu giữa các Region — DynamoDB Global Tables, Aurora Global Database, hoặc S3 Cross-Region Replication. Hãy giải quyết tầng dữ liệu trước khi lo tới tầng định tuyến.

Đáp án

B — Thiếu phần Resources.

Vì sao đúng

CloudFormation template có nhiều phần, nhưng chỉ MỘT phần là bắt buộc.

Cấu trúc của một template:

{
  "AWSTemplateFormatVersion": "2010-09-09",   ← tuỳ chọn
  "Description": "...",                        ← tuỳ chọn
  "Metadata": {...},                           ← tuỳ chọn
  "Parameters": {...},                         ← tuỳ chọn
  "Mappings": {...},                           ← tuỳ chọn
  "Conditions": {...},                         ← tuỳ chọn
  "Transform": {...},                          ← tuỳ chọn
  "Resources": {...},                          ← BẮT BUỘC
  "Outputs": {...}                             ← tuỳ chọn
}

Template trong đề có Parameters và Outputs nhưng KHÔNG có Resources:

→ CloudFormation không biết phải TẠO GÌ
→ template không hợp lệ, stack không triển khai được

Và có một lỗi thứ hai kéo theo:

Outputs tham chiếu tới "manilaInstance":
    {"Ref": "manilaInstance"}
        ↓
    Nhưng tài nguyên đó KHÔNG TỒN TẠI trong template
    → tham chiếu không phân giải được

Template tối thiểu hợp lệ chỉ cần đúng một phần:

{"Resources": {
   "MayChu": {
     "Type": "AWS::EC2::Instance",
     "Properties": {"ImageId": "ami-0abc123", "InstanceType": "t3.micro"}}}}

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

• **C. Có một phần không hợp lệ tên là Parameters — đây là phương án gần nhất vì cũng chỉ vào cấu trúc template, nhưng nó sai về sự thật: Parameters là phần hoàn toàn hợp lệ và rất thường dùng để nhận đầu vào cho template.
• **A. Giá trị của AWSTemplateFormatVersion sai, phải là 2017-06-06 — sai: giá trị đúng và duy nhất là 2010-09-09. Đây là phiên bản định dạng, không phải ngày tháng bạn tự chọn.
• **D. Thiếu phần Conditions — Conditions là tuỳ chọn, dùng để tạo tài nguyên có điều kiện. Không có nó thì template vẫn chạy bình thường.

Ghi nhớ

Chín phần của CloudFormation template — chỉ MỘT bắt buộc: | Phần | Bắt buộc | Việc | |---|---|---| | Resources | ✅ DUY NHẤT bắt buộc | tài nguyên cần tạo | | AWSTemplateFormatVersion | ❌ | luôn là 2010-09-09 | | Description | ❌ | mô tả template | | Metadata | ❌ | cấu hình bổ sung, nhóm tham số trong Console | | Parameters | ❌ | đầu vào cho phép tái dùng template | | Mappings | ❌ | bảng tra — ví dụ AMI ID theo Region | | Conditions | ❌ | tạo tài nguyên có điều kiện | | Transform | ❌ | dùng macro hoặc SAM | | Outputs | ❌ | giá trị xuất ra, dùng chéo giữa các stack |

"Chỉ Resources là bắt buộc" là kiến thức hay được hỏi.

Ba hàm nội tại hay dùng nhất: | Hàm | Việc | |---|---| | Ref | tham chiếu tham số hoặc tài nguyên | | Fn::GetAtt | lấy một thuộc tính của tài nguyên | | Fn::Sub | thay biến vào chuỗi | | Fn::ImportValue | nhập giá trị Output từ stack khác | | Fn::If, Fn::Equals | dùng với Conditions |

Ví dụ đầy đủ:

Parameters:
  LoaiInstance:
    Type: String
    Default: t3.micro
    AllowedValues: [t3.micro, t3.small, t3.medium]

Resources:
  MayChu:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref LoaiInstance
      ImageId: !Ref AmiId

Outputs:
  DiaChiIP:
    Value: !GetAtt MayChu.PublicIp
    Export:
      Name: !Sub "${AWS::StackName}-DiaChiIP"

Bốn attribute điều khiển hành vi tài nguyên: | Attribute | Việc | |---|---| | DependsOn | thứ tự TẠO tài nguyên | | CreationPolicy | CHỜ tín hiệu thành công (cfn-signal) | | DeletionPolicy | Retain, Snapshot, hay Delete khi xoá stack | | UpdateReplacePolicy | làm gì với tài nguyên cũ khi bị thay thế |

DeletionPolicy: Retain là biện pháp bảo vệ quan trọng cho database và bucket dữ liệu — xoá stack nhầm không kéo theo mất dữ liệu.

Ba khái niệm quan trọng: | Khái niệm | Việc | |---|---| | Stack | tập tài nguyên quản lý cùng nhau | | Change set | XEM TRƯỚC thay đổi trước khi áp dụng | | StackSet | triển khai một template ra nhiều tài khoản và Region | | Drift detection | phát hiện tài nguyên bị sửa tay ngoài template |

Change set là thực hành bắt buộc cho môi trường sản xuất:

aws cloudformation create-change-set --stack-name ung-dung-web   --template-body file://template.json --change-set-name thay-doi-1
aws cloudformation describe-change-set --change-set-name thay-doi-1   --stack-name ung-dung-web

Nó cho biết tài nguyên nào sẽ bị THAY THẾ — rất quan trọng vì thay thế một RDS instance có thể mất dữ liệu.

Ba cách kiểm chứng template trước khi triển khai: | Cách | Chi tiết | |---|---| | aws cloudformation validate-template | kiểm tra cú pháp cơ bản | | cfn-lint | kiểm tra sâu hơn: thuộc tính sai, kiểu dữ liệu, tài nguyên không tồn tại | | cfn_nag hoặc cfn-guard | kiểm tra quy tắc bảo mật |

cfn-lint template.json
# E1001 Top level item Resources is required

cfn-lint bắt được đúng lỗi trong đề — nên đưa nó vào pipeline CI để không bao giờ merge template hỏng.

Ba công cụ IaC trên AWS: | Công cụ | Đặc điểm | |---|---| | CloudFormation | gốc của AWS, YAML/JSON, miễn phí | | AWS CDK | viết bằng TypeScript, Python, Java — sinh ra CloudFormation | | AWS SAM | phần mở rộng cho ứng dụng serverless |

CDK đáng cân nhắc cho đội đông lập trình viên — có kiểm tra kiểu, vòng lặp, và hàm; tránh được sự lặp lại dài dòng của YAML.

Và một lời khuyên về quy trình review: hãy chạy cfn-lint và create-change-set như một bước bắt buộc trong pull request. Lỗi trong đề là loại mà công cụ tự động bắt được ngay, và không nên tốn thời gian của người review.

Đáp án

A và E.

• A — Dùng Amazon Aurora với Multi-AZ Replica
• E — Nhân bản (clone) database sản xuất sang môi trường staging bằng Aurora cloning

Vì sao đúng

Đề nêu hai vấn đề, và hai đáp án giải quyết lần lượt: | Vấn đề | Giải pháp | |---|---| | Sao chép 1 TB mất HÀNG GIỜ, đội phân tích phải chờ | E — Aurora cloning: xong trong VÀI PHÚT | | Ứng dụng bị gián đoạn, cần chịu lỗi tốt | A — Aurora với replica ở nhiều AZ |

Aurora cloning nhanh nhờ cơ chế "sao chép khi ghi" (copy-on-write):

Clone KHÔNG sao chép dữ liệu vật lý
    → nó TRỎ vào cùng các trang dữ liệu của bản gốc
    → chỉ khi một bên GHI thì trang đó mới được nhân bản
        ↓
    Tạo clone 1 TB: VÀI PHÚT
    Chi phí lưu trữ ban đầu: gần như BẰNG KHÔNG

aws rds restore-db-cluster-to-point-in-time   --db-cluster-identifier cum-staging   --source-db-cluster-identifier cum-san-xuat   --restore-type copy-on-write --use-latest-restorable-time

Và clone hoàn toàn ĐỘC LẬP với bản gốc:

Đội phân tích ghi vào clone
    → không ảnh hưởng database sản xuất
    → và không ảnh hưởng hiệu năng của nó

A — và Aurora với replica giải quyết vế chịu lỗi:

Aurora Replica ở AZ khác:
    → instance chính hỏng → failover DƯỚI 30 GIÂY
    → và replica còn phục vụ truy vấn đọc

Và Aurora còn có tầng lưu trữ 6 bản qua 3 AZ — dữ liệu an toàn ngay cả khi mất 2 bản.

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

• **C. Chụp snapshot thủ công rồi khôi phục sang database staging — đây là phương án gần nhất và là cách làm phổ biến, nhưng nó vẫn mất hàng giờ với database 1 TB: khôi phục snapshot phải nạp dữ liệu thật, khác hẳn cơ chế copy-on-write của cloning.
• **D. Sao chép bằng mysqldump — chậm nhất trong các phương án: nó xuất toàn bộ dữ liệu ra tệp văn bản rồi nhập lại. Với 1 TB, quá trình này mất rất nhiều giờ và gây tải nặng lên database nguồn — đúng nguyên nhân gây gián đoạn mà đề mô tả.
• **B. Dùng Amazon RDS với Multi-AZ — giải quyết được vế chịu lỗi nhưng KHÔNG có cloning: RDS thường không hỗ trợ copy-on-write clone. Vấn đề "chờ hàng giờ" vẫn còn nguyên.

Ghi nhớ

Aurora Cloning — cơ chế và lợi ích: | Đặc điểm | Chi tiết | |---|---| | Copy-on-write | không sao chép dữ liệu, chỉ trỏ vào trang chung | | Thời gian tạo | vài phút, bất kể kích thước database | | Chi phí lưu trữ ban đầu | gần như bằng 0 | | Độc lập hoàn toàn | ghi vào clone không ảnh hưởng gốc | | Số clone | tạo được nhiều, và clone của clone |

Ba trường hợp dùng Aurora cloning: | Trường hợp | Chi tiết | |---|---| | Môi trường phân tích và kiểm thử | ← câu này | | Kiểm thử thay đổi lược đồ | thử trước khi áp lên sản xuất | | Điều tra sự cố | clone tại thời điểm xảy ra vấn đề |

Và chi phí tăng dần theo lượng ghi:

Ban đầu: gần như miễn phí
Sau đó:  chỉ tính phí cho các TRANG BỊ THAY ĐỔI
    → clone chỉ đọc gần như không tốn thêm gì

Kiến trúc lưu trữ của Aurora — nền tảng của cloning:

Tầng COMPUTE  ←→ tách rời ←→  Tầng LƯU TRỮ
                                  ↓
                    6 bản sao qua 3 AZ, tự sửa lỗi
                    tự mở rộng tới 128 TB

Chính việc tách rời này cho phép nhiều cluster cùng trỏ vào một tập trang dữ liệu.

Khả năng chịu lỗi của tầng lưu trữ Aurora: | Mất | Hậu quả | |---|---| | 2 trong 6 bản | vẫn GHI được | | 3 trong 6 bản | vẫn ĐỌC được |

Aurora và RDS — bảng phân biệt cho tình huống này: | | Aurora | RDS MySQL | |---|---|---| | Cloning copy-on-write | ✅ | ❌ | | Failover | dưới 30 giây | 60–120 giây | | Replica phục vụ đọc | ✅ tới 15, độ trễ mili giây | tới 5, độ trễ giây | | Backtrack | ✅ quay ngược tới 72 giờ | ❌ | | Lưu trữ tối đa | 128 TB | 64 TB | | Chi phí | cao hơn một chút | thấp hơn |

Ba tính năng khác của Aurora đáng dùng: | Tính năng | Việc | |---|---| | Backtrack | quay ngược cluster tới 72 giờ — chữa lỗi do người | | Aurora Serverless v2 | tự co giãn — phù hợp cho staging dùng thưa | | Global Database | sao chép đa Region, độ trễ dưới 1 giây |

Và Aurora Serverless v2 rất phù hợp cho môi trường staging:

Đội phân tích chỉ dùng vài lần mỗi tháng
    → Serverless v2 co xuống 0,5 ACU khi rảnh
    → tự bung ra khi có truy vấn
    → chi phí thấp hơn nhiều so với instance chạy liên tục

Ba bước di chuyển từ MySQL tại chỗ sang Aurora: | Bước | Công cụ | |---|---| | ① Đánh giá tương thích | Aurora MySQL tương thích MySQL 8.0 | | ② Chuyển dữ liệu ít gián đoạn | AWS DMS với CDC | | ③ Cắt chuyển | dừng ghi, chờ CDC bắt kịp, đổi chuỗi kết nối |

Và với MySQL 8.0, có cách nhanh hơn cho lần nạp đầu:

Khôi phục từ backup của MySQL vào Aurora (Percona XtraBackup)
    → nhanh hơn DMS full load rất nhiều với 1 TB
    → rồi dùng DMS CDC bắt kịp phần thay đổi

Ba lưu ý về Aurora clone: | Lưu ý | Chi tiết | |---|---| | Clone phải ở CÙNG Region | với cluster nguồn | | Tối đa 15 clone mỗi cluster gốc | | | Xoá cluster gốc không ảnh hưởng clone | dữ liệu chung được giữ lại |

Và một lời khuyên vận hành: hãy tự động hoá việc tạo và xoá clone bằng Lambda theo lịch. Đội phân tích có clone mới mỗi sáng thứ hai, và clone cũ được xoá — như vậy dữ liệu luôn tươi mới mà chi phí không tích tụ theo thời gian.

Đáp án

A và B.

• A — Bắt buộc mọi kết nối tới DB instance dùng SSL bằng cách đặt tham số rds.force_ssl = true, rồi khởi động lại instance
• B — Tải chứng chỉ Amazon RDS Root CA, nhập vào máy chủ và cấu hình ứng dụng dùng SSL

Vì sao đúng

Đề cần mã hoá dữ liệu ĐANG TRUYỀN (in-flight) giữa web server và RDS — và hai đáp án là hai nửa của cùng một giải pháp: | Vế | Việc | |---|---| | A — phía MÁY CHỦ | BẮT BUỘC mọi kết nối phải mã hoá | | B — phía CLIENT | XÁC MINH được chứng chỉ của máy chủ |

A — rds.force_ssl là biện pháp thực thi ở tầng database:

Không có tham số này:
    → SSL là TUỲ CHỌN
    → client quên khai --ssl là kết nối không mã hoá
    → và không ai biết

Đặt rds.force_ssl = 1:
    → mọi kết nối KHÔNG mã hoá bị TỪ CHỐI
    → không phụ thuộc vào việc client có nhớ hay không

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

aws rds reboot-db-instance --db-instance-identifier db-ung-dung

Tham số này là loại static — bắt buộc khởi động lại instance mới có hiệu lực, đúng như đáp án nêu.

B — và chứng chỉ CA là thứ khiến mã hoá có ý nghĩa:

Không xác minh chứng chỉ:
    → kết nối vẫn mã hoá
    → NHƯNG không biết đang nói chuyện với ai
    → dễ bị tấn công người-đứng-giữa

Có chứng chỉ CA:
    → client xác minh máy chủ đúng là RDS của AWS
    → mã hoá mới thực sự bảo vệ được

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

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

• **C. Bật Transparent Data Encryption (TDE) qua option group — đây là phương án gần nhất vì cũng là mã hoá cho SQL Server, nhưng nó bảo vệ dữ liệu AT REST (trên đĩa và trong backup), không phải dữ liệu đang truyền. Đề nói rõ "in-flight data".
• **D. Bật IAM DB Authentication — giải quyết vấn đề XÁC THỰC, không phải mã hoá: nó thay mật khẩu bằng token ngắn hạn. (Nó có bắt buộc SSL như một hệ quả, nhưng SQL Server KHÔNG hỗ trợ IAM DB authentication — chỉ MySQL, MariaDB và PostgreSQL có.)
• **E. Cấu hình security group chỉ cho phép lưu lượng cổng 443 — sai cổng và sai cơ chế: SQL Server dùng cổng 1433, không phải 443. Và security group kiểm soát ai kết nối được, nó không mã hoá gì.

Ghi nhớ

Hai loại mã hoá của RDS — đừng nhầm: | Loại | Bảo vệ | Cách bật | |---|---|---| | At rest | dữ liệu trên ĐĨA, snapshot, backup | KMS — bật LÚC TẠO instance | | In transit | dữ liệu khi TRUYỀN qua mạng | SSL/TLS với chứng chỉ CA của RDS |

Mã hoá at rest KHÔNG bật được cho instance đang chạy — phải chụp snapshot, sao chép có mã hoá, rồi khôi phục.

Tham số bắt buộc SSL theo từng engine: | Engine | Tham số | |---|---| | SQL Server | rds.force_ssl = 1 | | PostgreSQL | rds.force_ssl = 1 | | MySQL 8.0 / MariaDB | require_secure_transport = ON | | Oracle | qua option group SSL |

Ba loại tham số trong parameter group: | Loại | Áp dụng | |---|---| | dynamic | có hiệu lực ngay | | static | CẦN KHỞI ĐỘNG LẠI instance |

rds.force_ssl là tham số static — đó là lý do đáp án A nhắc tới việc reboot.

Ba chứng chỉ CA của RDS: | Chứng chỉ | Ghi chú | |---|---| | global-bundle.pem | chứa mọi CA của mọi Region — tiện nhất | | Theo Region | nhẹ hơn nhưng phải chọn đúng | | rds-ca-rsa2048-g1 / g2 | các thế hệ CA khác nhau |

Và chứng chỉ CA của RDS CÓ HẠN SỬ DỤNG:

AWS định kỳ thay CA (ví dụ rds-ca-2019 → rds-ca-rsa2048-g1)
    → phải cập nhật chứng chỉ trên client
    → và cập nhật CA của DB instance
        ↓
    Không làm → kết nối SSL thất bại vào ngày CA hết hạn

aws rds modify-db-instance --db-instance-identifier db-ung-dung   --ca-certificate-identifier rds-ca-rsa2048-g1 --apply-immediately

AWS gửi email cảnh báo trước, nhưng đây là loại việc dễ bị bỏ quên — hãy đặt nhắc nhở.

Cách kết nối có xác minh chứng chỉ theo từng ngôn ngữ:

SQL Server (.NET):  Encrypt=True;TrustServerCertificate=False
MySQL:              --ssl-ca=global-bundle.pem --ssl-mode=VERIFY_IDENTITY
PostgreSQL:         sslmode=verify-full sslrootcert=global-bundle.pem

Chú ý TrustServerCertificate=False và VERIFY_IDENTITY — đặt ngược lại nghĩa là mã hoá mà không xác minh, mất phần lớn giá trị bảo vệ.

Ba lớp bảo mật nên có cho RDS: | Lớp | Cấu hình | |---|---| | Mạng | private subnet + security group nhận từ SG của tầng ứng dụng | | Mã hoá | at rest (KMS) + in transit (SSL) | | Xác thực | Secrets Manager hoặc IAM DB auth (nếu engine hỗ trợ) |

Và TDE của SQL Server — làm rõ vì phương án C nhắc tới: | Đặc điểm | Chi tiết | |---|---| | Mã hoá dữ liệu trên đĩa và trong backup | at rest | | Chỉ có ở SQL Server Enterprise Edition | và Web Edition với RDS | | Bật qua option group | không phải parameter group |

TDE và mã hoá KMS của RDS chồng lấn nhau — nếu đã bật mã hoá KMS lúc tạo instance thì dữ liệu đã được mã hoá at rest; TDE thêm một lớp ở tầng engine, cần cho một số yêu cầu tuân thủ cụ thể.

Ba cách kiểm chứng kết nối đang dùng SSL:

-- SQL Server
SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID;
-- TRUE nghĩa là đang mã hoá

Và một lời khuyên vận hành: sau khi bật rds.force_ssl, hãy kiểm thử toàn bộ ứng dụng trước trên môi trường staging. Mọi client chưa cấu hình SSL sẽ bị từ chối ngay lập tức — và với hệ thống nhiều thành phần, thường có một dịch vụ nào đó bị bỏ sót.

Đáp án

C — Cấp phát hai EC2 instance ở hai Availability Zone khác nhau và cấu hình chúng thành một origin group.

Vì sao đúng

Đề cần tính sẵn sàng cao cho origin của CloudFront — và origin group là cơ chế của CloudFront cho việc đó.

Cách origin group hoạt động:

Origin group có:
    → MỘT primary origin
    → MỘT secondary origin
        ↓
CloudFront gọi primary
    → nhận mã lỗi trong danh sách failover (500, 502, 503, 504, 403, 404...)
    → hoặc timeout
        ↓
    → TỰ ĐỘNG chuyển sang secondary

Và đặt hai instance ở HAI AZ khác nhau cho khả năng chịu lỗi thật:

Cùng một AZ:
    → AZ đó sập → cả hai instance chết → không có gì để failover

Hai AZ khác nhau:
    → mất một AZ → CloudFront chuyển sang instance ở AZ còn lại

{"OriginGroups": {"Quantity": 1, "Items": [{
   "Id": "nhom-origin",
   "FailoverCriteria": {"StatusCodes": {
     "Quantity": 4, "Items": [500, 502, 503, 504]}},
   "Members": {"Quantity": 2, "Items": [
     {"OriginId": "may-chu-az-a"},
     {"OriginId": "may-chu-az-b"}]}}]}}

Và đề nói rõ origin phục vụ NỘI DUNG ĐỘNG — nên phải là máy chủ chạy mã, không phải S3.

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

• **B. Khởi chạy Auto Scaling group EC2 và cấu hình nó làm thành viên origin group — đây là phương án gần nhất và ASG thực sự là cách tốt để có sẵn sàng cao, nhưng nó không dựng được như mô tả: origin của CloudFront phải là một endpoint cụ thể — tên miền của ALB, tên miền của S3, hoặc tên miền của một máy chủ. Auto Scaling group tự nó không có endpoint để CloudFront trỏ tới. (Cách đúng là đặt ALB trước ASG rồi dùng ALB làm origin.)
• **A. Dùng S3 phục vụ nội dung ĐỘNG và đưa bucket vào origin group — sai bản chất S3: S3 chỉ phục vụ nội dung TĨNH. Nội dung động cần máy chủ chạy mã.
• **D. Dùng Lambda@Edge và đưa các hàm vào origin group — sai vai trò: Lambda@Edge xử lý request tại điểm biên (viết lại header, định tuyến, tuỳ biến nội dung). Nó không phải origin và không đưa vào origin group được.

Ghi nhớ

Ba loại origin của CloudFront: | Loại | Ví dụ | |---|---| | S3 origin | bucket cho nội dung tĩnh | | Custom origin | ALB, EC2, hoặc máy chủ web bất kỳ | | VPC origin | truy cập tài nguyên trong private subnet (tính năng mới) |

Origin group — điều kiện và hành vi: | Đặc điểm | Chi tiết | |---|---| | Đúng HAI origin | một primary, một secondary | | Chỉ failover với GET, HEAD, OPTIONS | POST và PUT KHÔNG failover | | Mã lỗi kích hoạt failover | 400, 403, 404, 416, 500, 502, 503, 504 | | Timeout cũng kích hoạt | theo cấu hình connection timeout |

Dòng "POST và PUT không failover" là hạn chế quan trọng — với ứng dụng động có nhiều thao tác ghi, origin group chỉ bảo vệ được phần đọc.

Và kiến trúc tốt hơn cho ứng dụng động:

CloudFront
    ↓
Application Load Balancer          ← ALB là origin
    ↓
Auto Scaling group qua nhiều AZ

Và origin group vẫn hữu ích ở tầng cao hơn:

Origin group với:
    Primary:   ALB ở Region A
    Secondary: ALB ở Region B
        ↓
    → chịu được sự cố CẢ REGION

Đây là cách dùng origin group đúng đắn nhất — dự phòng đa Region, không phải dự phòng hai instance.

Ba cấu hình CloudFront cho nội dung động: | Cấu hình | Chi tiết | |---|---| | Cache policy TTL ngắn hoặc bằng 0 | nội dung động thay đổi liên tục | | Chuyển tiếp header, cookie, query string cần thiết | chỉ những gì origin thực sự cần | | Bật compression | giảm dung lượng truyền |

Và ngay cả nội dung động cũng cache được:

Trang chủ thay đổi mỗi vài phút
    → đặt TTL 60 giây
    → 10.000 lượt xem trong phút đó chỉ tạo MỘT request tới origin
    → giảm tải 99,99%

Nhiều người chỉ cache nội dung tĩnh và bỏ lỡ phần lợi ích lớn nhất.

Ba lợi ích của CloudFront cho nội dung động: | Lợi ích | Chi tiết | |---|---| | Kết nối giữ sẵn tới origin | bỏ được bắt tay TCP và TLS cho mỗi request | | Đi trên mạng xương sống AWS | ổn định hơn Internet công cộng | | Chống DDoS với Shield Standard | miễn phí, tự động |

Dòng đầu là lợi ích thật ngay cả khi tỷ lệ cache hit bằng 0 — CloudFront giảm độ trễ nhờ kết nối persistent tới origin.

Ba tính năng bổ trợ đáng biết: | Tính năng | Việc | |---|---| | Origin Shield | lớp cache trung tâm — giảm hẳn số lần gọi origin | | Origin Access Control (OAC) | bucket S3 riêng tư, chỉ CloudFront đọc được | | CloudFront Functions / Lambda@Edge | tuỳ biến request và response tại biên |

CloudFront Functions và Lambda@Edge: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Ngôn ngữ | chỉ JavaScript | Node.js, Python | | Thời gian chạy | dưới 1 mili giây | 5–30 giây | | Truy cập mạng | ❌ | ✅ gọi được dịch vụ khác | | Chi phí | rẻ hơn ~6 lần | cao hơn |

Và một lời khuyên về sẵn sàng cao: origin group bảo vệ khỏi sự cố của cả một origin, còn ALB bảo vệ khỏi sự cố của từng instance. Kiến trúc đầy đủ nên có cả hai — ALB trong mỗi Region, và origin group giữa hai Region.