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

Đáp án

D — Bật mã hoá cho EBS volume và RDS database bằng khoá AWS KMS.

Vì sao đúng

Đề nêu một yêu cầu duy nhất và rất rõ: mã hoá dữ liệu nhạy cảm KHI LƯU TRỮ (at rest). | Nơi dữ liệu nằm | Cách mã hoá | |---|---| | EBS volume (lưu tạm khi xử lý) | bật mã hoá EBS bằng KMS key | | RDS database (lưu kết quả) | bật mã hoá RDS bằng KMS key |

Vì sao phải làm cả hai chỗ:

Chỉ mã hoá RDS:  dữ liệu nhạy cảm nằm TRẦN trên EBS trong lúc xử lý
    → ai chụp snapshot volume đó là đọc được
        ↓
    Đề nói rõ "stores data TEMPORARILY on EBS during processing"
    → đó là một câu nhắc rằng EBS cũng phải mã hoá

Bật mã hoá EBS:

aws ec2 create-volume --size 100 --volume-type gp3   --availability-zone ap-southeast-1a   --encrypted --kms-key-id alias/khoa-ung-dung

Và bật mặc định cho cả tài khoản — đây là việc nên làm:

aws ec2 enable-ebs-encryption-by-default
aws ec2 modify-ebs-default-kms-key-id --kms-key-id alias/khoa-ung-dung

Bật mã hoá RDS:

aws rds create-db-instance --db-instance-identifier db-ket-qua   --engine postgres --db-instance-class db.m6g.large   --storage-encrypted --kms-key-id alias/khoa-ung-dung

Mã hoá bao gồm những gì: | Thành phần | EBS | RDS | |---|---|---| | Dữ liệu trên volume/storage | ✅ | ✅ | | Snapshot / bản sao lưu | ✅ tự động | ✅ tự động | | Read replica | — | ✅ | | Dữ liệu truyền giữa instance và volume | ✅ | — |

Vế "snapshot tự mã hoá" rất quan trọng:

Snapshot từ volume đã mã hoá → LUÔN được mã hoá
    → không thể vô tình tạo bản sao trần
        ↓
    Đây là bảo vệ chống lỗi con người

Và mã hoá gần như không tốn hiệu năng:

Mã hoá thực hiện ở tầng hạ tầng lưu trữ
    → ứng dụng không cần biết gì
    → ảnh hưởng IOPS và độ trễ không đáng kể
        ↓
    Không có lý do kỹ thuật nào để không bật

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

• **A. Cấu hình SSL/TLS bằng KMS CMK để mã hoá volume CSDL — đây là phương án gần nhất vì có nhắc tới KMS, nhưng nó lẫn lộn hai loại mã hoá: SSL/TLS bảo vệ dữ liệu đang truyền (in transit), không bảo vệ dữ liệu đang lưu (at rest). Và KMS không phải công cụ để cấu hình TLS.
• **B. Dùng ACM sinh chứng chỉ mã hoá kết nối giữa EC2 và RDS — cùng nhầm lẫn: đây là mã hoá đường truyền. Việc này nên làm, nhưng nó không đáp ứng yêu cầu at rest mà đội bảo mật đưa ra.
• **C. Dùng Data Lifecycle Manager mã hoá dữ liệu khi ghi — sai vai trò dịch vụ: DLM dùng để tự động tạo và xoá snapshot EBS theo lịch. Nó không mã hoá gì trong lúc ghi, và không đụng gì tới RDS.

Ghi nhớ

Hai loại mã hoá — bảng phải thuộc: | Loại | Bảo vệ | Công cụ | |---|---|---| | At rest | dữ liệu đang LƯU trên đĩa | KMS, SSE-S3, SSE-KMS | | In transit | dữ liệu đang TRUYỀN qua mạng | TLS/SSL, ACM, VPN |

Từ khoá nhận diện:

"encrypted at rest" → KMS cho EBS, RDS, S3 "encrypted in transit", "in flight" → TLS, ACM "data must never be readable by AWS" → client-side encryption hoặc CloudHSM

Ba loại khoá KMS: | Loại | Kiểm soát | Xoay khoá | |---|---|---| | AWS managed key (aws/ebs) | AWS quản lý | tự động hằng năm | | Customer managed key (CMK) | bạn quản lý | bật/tắt được, đặt chính sách | | AWS owned key | AWS hoàn toàn | không thấy được |

Với dữ liệu "highly sensitive" nên dùng customer managed key: | Lợi ích | Chi tiết | |---|---| | Đặt key policy riêng | ai được dùng khoá | | Bật xoay khoá tự động | | | Vô hiệu hoá khoá = khoá sạch dữ liệu | | | Ghi log mọi lần dùng vào CloudTrail | |

Vế thứ ba là công cụ mạnh cho tình huống khẩn cấp:

aws kms disable-key --key-id <id>

Vô hiệu hoá khoá → mọi volume và CSDL dùng khoá đó
    không giải mã được nữa
        ↓
    Cách "phá huỷ mật mã" nhanh khi nghi bị xâm nhập
    → nhưng cũng làm hệ thống ngừng ngay lập tức

⚠ Mã hoá EBS phải bật LÚC TẠO volume:

Volume chưa mã hoá KHÔNG bật mã hoá sau được
    → phải: snapshot → copy snapshot có --encrypted → tạo volume mới

aws ec2 copy-snapshot --source-snapshot-id snap-abc   --source-region ap-southeast-1 --encrypted --kms-key-id alias/khoa-ung-dung

⚠ Với RDS thì còn khó hơn:

Instance RDS chưa mã hoá KHÔNG bật mã hoá sau được
    → phải: snapshot → copy snapshot có mã hoá → RESTORE thành instance MỚI
    → rồi chuyển ứng dụng sang
        ↓
    Có thời gian ngừng — nên bật NGAY từ đầu

Ba đặc điểm của mã hoá RDS: | Đặc điểm | Chi tiết | |---|---| | Bao gồm storage, snapshot, log, read replica | | | Read replica phải cùng khoá với primary | trong cùng vùng | | Không đổi khoá của instance đang chạy | phải tạo lại |

Ba khái niệm KMS cần biết: | Khái niệm | Nghĩa | |---|---| | Envelope encryption | khoá dữ liệu mã hoá dữ liệu, KMS mã hoá khoá dữ liệu | | Key policy | chính sách gắn TRÊN khoá — nguồn quyền chính | | Grant | uỷ quyền tạm thời, hay dùng cho dịch vụ AWS |

Envelope encryption là lý do KMS không bị nghẽn:

KMS không mã hoá từng byte dữ liệu
    → nó sinh và bảo vệ DATA KEY
    → EBS dùng data key mã hoá dữ liệu tại chỗ
        ↓
    Nên mã hoá 1 TB cũng chỉ tốn vài lần gọi KMS

Ba lưu ý về key policy: | Lưu ý | Chi tiết | |---|---| | Key policy là nguồn quyền CHÍNH | IAM policy một mình không đủ | | Phải cho tài khoản root quyền quản lý | không thì khoá thành mồ côi | | Cho dịch vụ dùng qua kms:ViaService | |

Dòng thứ hai là lỗi không sửa được:

Key policy không cho ai quyền kms:PutKeyPolicy
    → không ai sửa được chính sách đó nữa
    → khoá và mọi dữ liệu dùng nó bị khoá vĩnh viễn
        ↓
    AWS Support cũng không gỡ được

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Customer managed key: ~1 USD/tháng mỗi khoá | | | Phí theo số lần gọi API | | | Mã hoá EBS và RDS: KHÔNG tính phí thêm | |

Ba việc kiểm chứng tuân thủ: | Việc | Công cụ | |---|---| | Quy tắc AWS Config encrypted-volumes | tìm volume chưa mã hoá | | rds-storage-encrypted | tìm CSDL chưa mã hoá | | SCP chặn tạo volume không mã hoá | ngăn từ đầu |

{"Effect": "Deny", "Action": "ec2:CreateVolume", "Resource": "*",
 "Condition": {"Bool": {"ec2:Encrypted": "false"}}}

Ba lớp mã hoá nên có cho ứng dụng nhạy cảm: | Lớp | Công cụ | |---|---| | At rest | KMS cho EBS, RDS, S3 ← đề hỏi | | In transit | TLS giữa EC2 và RDS | | Cấp ứng dụng | mã hoá trường nhạy cảm trước khi ghi |

Và một lời khuyên: hãy bật ebs-encryption-by-default cho toàn tài khoản ngay hôm nay. Mã hoá không bật được sau khi tạo volume, nên mọi volume ai đó lỡ tạo mà quên bật sẽ phải chép lại toàn bộ mới sửa được — một cờ ở cấp tài khoản loại bỏ hẳn khả năng quên.

Đáp án

D — Dựng hạ tầng DR ở vùng thứ hai gồm ALB và Auto Scaling group với desired và maximum capacity = 0, chuyển cụm Aurora PostgreSQL thành Aurora global database, và dùng Route 53 active-passive failover.

Vì sao đúng

Đề nêu bốn ràng buộc, và chỉ phương án này thoả hết: | Ràng buộc | Cách đáp ứng | |---|---| | Chịu được sự cố CẢ VÙNG | hạ tầng ở vùng thứ hai | | RTO 30 phút | hạ tầng đã dựng sẵn, chỉ cần bật lên | | Hạ tầng DR KHÔNG cần chạy khi bình thường | ASG capacity = 0 | | Dữ liệu phải có ở vùng DR | Aurora global database |

Đây chính là mẫu Pilot Light:

Bình thường:  ALB có sẵn (rẻ), ASG = 0 máy (KHÔNG tốn tiền compute)
              Aurora global database sao chép liên tục (chỉ đọc)
                  ↓
Khi vùng chính chết:
              1. Tăng ASG desired capacity  (~5 phút)
              2. Promote Aurora secondary   (~1 phút)
              3. Route 53 chuyển traffic    (~1-2 phút)
                  ↓
              Tổng dưới 30 phút ✓

Vì sao ASG = 0 là chi tiết hay:

ASG và launch template đã cấu hình đúng, đã thử nghiệm
    → chỉ là không có máy nào đang chạy
        ↓
    Không trả phí EC2 nào
    → nhưng khi cần chỉ mất một lệnh

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-dr --region us-west-2   --desired-capacity 10 --max-size 20

Vì sao Aurora global database chứ không phải read replica: | | Aurora Global Database | Cross-Region Read Replica | |---|---|---| | Độ trễ sao chép | thường < 1 giây | vài giây tới phút | | Cơ chế | tầng lưu trữ chuyên dụng | qua binlog | | Promote | < 1 phút (managed planned failover) | vài phút | | RPO | ~1 giây | cao hơn | | Ảnh hưởng writer | gần như không | có tải binlog |

Chuyển sang global database:

aws rds create-global-cluster --global-cluster-identifier cum-toan-cau   --source-db-cluster-identifier arn:aws:rds:ap-southeast-1:...:cluster:cum-chinh

aws rds create-db-cluster --db-cluster-identifier cum-dr   --global-cluster-identifier cum-toan-cau --engine aurora-postgresql   --region us-west-2

Route 53 active-passive failover:

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[{"Action":"CREATE","ResourceRecordSet":{
    "Name":"shop.example.com","Type":"A","SetIdentifier":"chinh",
    "Failover":"PRIMARY","HealthCheckId":"hc-chinh",
    "AliasTarget":{"HostedZoneId":"Z1","DNSName":"alb-chinh...","EvaluateTargetHealth":true}}}]}'

Vì sao active-passive chứ không active-active:

Đề nói rõ: "DR infrastructure does not need to be operational
            unless the primary Region becomes unavailable"
        ↓
    Active-active nghĩa là CẢ HAI cùng phục vụ
    → phải giữ máy chạy ở vùng DR → tốn tiền
    → mâu thuẫn với yêu cầu

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

• **C. Dựng hạ tầng DR đầy đủ với Aurora Cross-Region Replication và CloudWatch alarm tăng ASG — đây là phương án gần nhất và cơ chế kích hoạt cũng hợp lý, nhưng nó thiếu cơ chế chuyển lưu lượng: không có Route 53 failover thì DNS vẫn trỏ về vùng đã chết. Và CloudWatch alarm ở vùng chính có thể không hoạt động khi chính vùng đó đang có sự cố.
• **A. Dựng vùng thứ hai với ASG ở mức tối thiểu, cross-region read replica, Route 53 active-active — active-active nghĩa là luôn phải giữ máy chạy, ngược với yêu cầu "không cần hoạt động khi bình thường". Và "RDS Cross-Region Read Replicas" cho Aurora là cách gọi không chính xác — Aurora dùng global database.
• **B. Dùng AWS Backup rồi dựng hạ tầng bằng CloudFormation khi có sự cố — đây là mẫu Backup & Restore, RTO tính bằng giờ: phải dựng VPC, ALB, ASG, khôi phục CSDL từ bản sao lưu. Không đạt được RTO 30 phút, và RPO cũng kém vì chỉ có bản sao lưu định kỳ.

Ghi nhớ

Bốn chiến lược DR — bảng phải thuộc: | Chiến lược | RTO | RPO | Chi phí | |---|---|---|---| | Backup & Restore | giờ tới ngày | giờ | thấp nhất | | Pilot Light | chục phút | phút tới giây | thấp ← câu này | | Warm Standby | phút | giây | trung bình | | Multi-Site Active-Active | gần bằng 0 | gần 0 | cao nhất |

Từ khoá nhận diện:

"RTO 30 minutes" + "DR not operational unless failure" → Pilot Light "scaled-down but RUNNING copy" → Warm Standby "zero downtime", "both Regions serve traffic" → Active-Active "RTO hours", "lowest cost" → Backup & Restore

Phân biệt Pilot Light và Warm Standby — chỗ hay lẫn nhất: | | Pilot Light | Warm Standby | |---|---|---| | Tầng compute | TẮT (capacity 0) | CHẠY ở quy mô nhỏ | | CSDL | sao chép liên tục | sao chép liên tục | | Kiểm chứng sẵn sàng | phải chủ động thử | luôn thấy nó chạy | | Chi phí | thấp hơn | cao hơn |

Hai định nghĩa phải thuộc: | Chỉ số | Nghĩa | |---|---| | RTO (Recovery Time Objective) | bao lâu để KHÔI PHỤC dịch vụ | | RPO (Recovery Point Objective) | được phép MẤT bao nhiêu dữ liệu |

Ba đặc điểm của Aurora Global Database: | Đặc điểm | Chi tiết | |---|---| | Tới 5 vùng phụ | | | Độ trễ sao chép thường < 1 giây | | | RTO khi promote thường < 1 phút | |

Hai kiểu chuyển đổi: | Kiểu | Khi nào | |---|---| | Managed planned failover | vùng chính còn sống — không mất dữ liệu | | Failover (unplanned) / detach and promote | vùng chính đã chết |

aws rds failover-global-cluster --global-cluster-identifier cum-toan-cau   --target-db-cluster-identifier arn:aws:rds:us-west-2:...:cluster:cum-dr

Ba chính sách định tuyến Route 53 liên quan tới DR: | Chính sách | Hành vi | |---|---| | Failover | primary, chuyển sang secondary khi health check hỏng | | Latency-based | gửi tới vùng nhanh nhất | | Weighted | chia tỷ lệ |

⚠ Health check của Route 53 là thứ quyết định thời gian chuyển: | Tham số | Ảnh hưởng | |---|---| | RequestInterval | 30 giây (hoặc 10 giây fast) | | FailureThreshold | số lần hỏng liên tiếp | | TTL của record | client cache DNS bao lâu |

TTL là chỗ dễ bị bỏ qua nhất:

TTL 300 giây → client vẫn dùng IP cũ tới 5 phút sau khi chuyển
    → RTO thực tế cộng thêm 5 phút
        ↓
    Đặt TTL 60 giây cho record failover

Ba thứ phải nhân bản sang vùng DR TRƯỚC: | Thứ | Cách | |---|---| | AMI và launch template | copy AMI sang vùng | | Ảnh container trong ECR | bật cross-region replication | | Object S3 (ảnh sản phẩm) | S3 Cross-Region Replication |

Đây là danh sách hay bị thiếu nhất:

Dựng ALB và ASG ở vùng DR nhưng AMI chỉ có ở vùng chính
    → tăng capacity → không khởi động được máy nào
        ↓
    Và điều này chỉ lộ ra vào đúng lúc thảm hoạ

Ba thứ khác cần chuẩn bị: | Thứ | Chi tiết | |---|---| | Chứng chỉ ACM ở vùng DR | ACM theo vùng | | Secrets Manager replication | | | Hạn ngạch tài khoản ở vùng DR | |

Dòng cuối rất quan trọng:

Hạn ngạch EC2 ở vùng DR thường thấp vì chưa dùng bao giờ
    → tăng ASG lên 10 máy → chạm quota → chỉ khởi động được 5
        ↓
    Xin tăng hạn ngạch TRƯỚC, không phải trong lúc sự cố

Ba lưu ý về chi phí Pilot Light: | Khoản | Chi tiết | |---|---| | ALB tính phí kể cả khi không có target | ~16 USD/tháng | | Aurora secondary cluster tính phí instance | | | Phí truyền dữ liệu giữa vùng | |

Ba việc phải làm định kỳ: | Việc | Tần suất | |---|---| | Diễn tập chuyển đổi thật | ít nhất 2 lần/năm | | Kiểm tra AMI ở vùng DR còn mới | mỗi lần phát hành | | Đo RTO thực tế | mỗi lần diễn tập |

Dùng managed planned failover để diễn tập:

Aurora cho phép chuyển đổi có kế hoạch mà KHÔNG mất dữ liệu
    → chuyển sang vùng DR, chạy một lúc, rồi chuyển về
        ↓
    Đây là cách diễn tập DR an toàn nhất

Và một lời khuyên: hãy tự động hoá các bước khôi phục thành một runbook chạy được (Systems Manager Automation hoặc Step Functions). RTO 30 phút nghe rộng rãi cho tới khi bạn phải thực hiện nó lúc 3 giờ sáng dưới áp lực — và mỗi bước làm bằng tay là một chỗ để quên hoặc làm sai thứ tự.

Đáp án

D — Thiết lập kết nối Direct Connect tại NHIỀU DX location.

Vì sao đúng

Đề hỏi cấu hình có khả năng phục hồi CAO NHẤT, và câu trả lời nằm ở việc loại bỏ điểm hỏng nào: | Cấu hình | Loại bỏ được điểm hỏng | |---|---| | Một kết nối DX | không gì cả | | Hai kết nối cùng một DX location | hỏng thiết bị, hỏng cáp | | Kết nối tại NHIỀU DX location | hỏng cả CƠ SỞ DX ← cao nhất |

Vì sao nhiều VIF không giúp gì:

VIF (Virtual Interface) là giao diện LOGIC
    → chạy TRÊN một kết nối vật lý
        ↓
    Cáp đứt → mọi VIF trên đó chết cùng lúc
    → thêm VIF không thêm dự phòng

Đây là điểm loại cả B và C.

Bốn mức phục hồi của Direct Connect — theo tài liệu AWS: | Mức | Cấu hình | Chống được | |---|---|---| | Development / Test | 1 kết nối, 1 location | không gì | | High Resiliency | 2 kết nối, 2 DX location riêng | hỏng cả một cơ sở | | Maximum Resiliency | 2 kết nối ở MỖI location, 2 location | hỏng thiết bị + hỏng cơ sở | | — | + VPN dự phòng | thêm một lớp |

Dựng kiến trúc:

Trung tâm dữ liệu
    ├── Router A ──▶ DX location 1 ──▶ AWS Region
    └── Router B ──▶ DX location 2 ──▶ AWS Region
        ↓
    Cơ sở DX 1 mất điện → lưu lượng đi qua cơ sở 2
    → BGP tự động chuyển

Vì sao BGP là phần quan trọng:

# Ưu tiên đường chính bằng AS path prepending
# Đường phụ quảng bá với AS path dài hơn
    → BGP chọn đường ngắn hơn khi cả hai còn sống
    → đường chính chết → tự dùng đường phụ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chống hỏng cả một cơ sở DX | | | Chống đứt cáp trên một tuyến | | | Chuyển đổi tự động qua BGP | |

Và một lưu ý về đường vật lý:

Hai kết nối tới hai DX location khác nhau
    → nhưng nếu chúng đi qua CÙNG một sợi cáp của nhà mạng
    → máy xúc vẫn cắt đứt cả hai
        ↓
    Phải xác nhận với nhà cung cấp về ĐƯỜNG ĐI VẬT LÝ khác nhau

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

• **A. Cấu hình DX kèm VPN mã hoá bên trên — đây là phương án gần nhất về mặt "thêm một lớp", nhưng VPN chạy TRÊN chính kết nối DX đó: cáp đứt thì cả DX lẫn VPN cùng chết. Đây là giải pháp cho mã hoá (DX không mã hoá mặc định), không phải cho khả năng phục hồi.
• **C. Cấu hình nhiều private VIF trên một kết nối DX — VIF là cấu trúc logic, không thêm đường vật lý nào. Nhiều private VIF dùng để nối tới nhiều VPC, không phải để dự phòng.
• **B. Cấu hình nhiều public VIF trên một kết nối DX — cùng vấn đề, và public VIF còn phục vụ mục đích khác hẳn: truy cập các dịch vụ AWS công khai (S3, DynamoDB) qua DX.

Ghi nhớ

Bốn mức phục hồi DX — bảng phải thuộc: | Mức | Kết nối | Location | SLA | |---|---|---|---| | Development/Test | 1 | 1 | không | | High Resiliency | 2 | 2 | 99,9% | | Maximum Resiliency | 4 (2 mỗi nơi) | 2 | 99,99% |

Từ khoá nhận diện:

"HIGHEST resiliency" → nhiều kết nối ở NHIỀU DX location "encrypt Direct Connect traffic" → VPN qua DX, hoặc MACsec "backup for DX" → Site-to-Site VPN dự phòng

Ba loại Virtual Interface: | Loại | Nối tới | |---|---| | Private VIF | VPC (qua VGW hoặc Direct Connect Gateway) | | Public VIF | dịch vụ AWS công khai (S3, DynamoDB) | | Transit VIF | Transit Gateway |

Ba đặc điểm của Direct Connect: | Đặc điểm | Chi tiết | |---|---| | Băng thông ổn định, độ trễ thấp | | | KHÔNG mã hoá mặc định | | | Thời gian cung cấp: hàng tuần tới hàng tháng | |

Vế thứ hai là điều đáng nhớ:

DX là đường riêng nhưng KHÔNG mã hoá
    → dữ liệu nhạy cảm cần thêm lớp mã hoá
        ↓
    Hai cách:
    → VPN qua public VIF (IPsec)
    → MACsec (mã hoá lớp 2, chỉ trên cổng chuyên dụng)

Vế thứ ba định hình kế hoạch:

DX mất hàng tuần đến hàng tháng để cung cấp
    → dự án cần kết nối ngay thì dùng VPN trước
    → chuyển sang DX khi sẵn sàng

Hai loại kết nối DX: | Loại | Băng thông | Chia sẻ | |---|---|---| | Dedicated | 1, 10, 100, 400 Gbps | cổng riêng | | Hosted | 50 Mbps - 25 Gbps | qua đối tác |

Ba mẫu dự phòng cho kết nối lai: | Mẫu | Chống được | Chi phí | |---|---|---| | DX + VPN dự phòng | hỏng DX | thấp | | DX ở 2 location | hỏng cơ sở | trung bình | | DX ở 2 location, 2 kết nối mỗi nơi | tối đa | cao |

DX + VPN dự phòng là lựa chọn thực tế nhất cho nhiều tổ chức:

VPN qua Internet rẻ, dựng nhanh
    → băng thông thấp hơn và độ trễ cao hơn
    → nhưng vẫn hơn hẳn mất kết nối hoàn toàn
        ↓
    BGP tự chuyển sang VPN khi DX hỏng

⚠ Cấu hình BGP cho dự phòng: | Cấu hình | Tác dụng | |---|---| | AS path prepending trên đường phụ | đường chính được ưu tiên | | Local preference cao hơn cho DX | | | BFD bật để phát hiện hỏng nhanh | |

BFD là chi tiết hay bị bỏ qua:

Không có BFD:  BGP mất tới 90 giây mới nhận ra đường chết
Có BFD:        phát hiện trong dưới 1 giây
        ↓
    Với hạ tầng quan trọng thì đây là khác biệt lớn

Ba lưu ý về Direct Connect Gateway: | Lưu ý | Chi tiết | |---|---| | Nối một DX tới VPC ở NHIỀU vùng | | | Không cho VPC nói chuyện với nhau qua nó | | | Toàn cầu, không thuộc vùng nào | |

Vế thứ hai hay gây bất ngờ — muốn VPC nói chuyện với nhau thì dùng Transit Gateway hoặc peering.

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | AWS Direct Connect Resiliency Toolkit | hướng dẫn dựng theo mức mong muốn | | Failover testing | AWS chủ động ngắt để thử | | CloudWatch metric của DX | trạng thái kết nối |

Failover testing là tính năng đáng dùng:

aws directconnect start-bgp-failover-test   --virtual-interface-id dxvif-abc123 --test-duration-in-minutes 30

AWS tạm ngắt BGP session của một VIF
    → xem lưu lượng có tự chuyển sang đường phụ không
        ↓
    Thử trong cửa sổ bảo trì, không phải chờ sự cố thật

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ConnectionState | up/down | | ConnectionBpsEgress/Ingress | có dùng cân bằng không | | ConnectionErrorCount | lỗi vật lý |

Metric thứ hai kiểm chứng dự phòng thật sự:

Cả hai kết nối đều có lưu lượng → cả hai đang hoạt động
Một kết nối im lặng hoàn toàn → có thể nó chưa bao giờ được cấu hình đúng
        ↓
    Đường dự phòng chưa từng chở lưu lượng là đường chưa được kiểm chứng

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cổng theo giờ | nhân đôi khi có hai kết nối | | Phí truyền dữ liệu ra rẻ hơn Internet | | | Phí chéo với nhà cung cấp cáp | |

Và một lời khuyên: hãy hỏi nhà cung cấp mạng về đường đi vật lý của hai tuyến cáp, bằng văn bản. Hai kết nối tới hai DX location trông rất dự phòng trên sơ đồ mạng, nhưng nếu cả hai cùng đi qua một ống cáp dưới một con phố thì bạn chỉ có một đường — và bạn sẽ biết điều đó vào đúng ngày có người đào đường ở đó.

Đáp án

B — Cấu hình DataSync chuyển tệp thẳng vào S3 Standard-IA, rồi dùng lifecycle chuyển sang S3 Glacier Deep Archive sau 1 năm, giữ 7 năm.

Vì sao đúng

Đề nêu bốn dữ kiện, và mỗi cái loại bớt một phương án: | Dữ kiện | Ý nghĩa | |---|---| | Năm đầu: truy cập 1-2 lần, phải CÓ NGAY | cần lớp truy cập tức thì | | Sau 1 năm: lưu trữ ít nhất 7 năm | lớp rẻ nhất, chấp nhận chờ | | Hàng triệu tệp, trung bình 10 KB | | | Tiết kiệm chi phí nhất | |

Vì sao Standard-IA cho năm đầu:

Truy cập 1-2 lần trong cả năm = rất ít
    → S3 Standard quá đắt cho tần suất đó
    → Standard-IA rẻ hơn ~45% tiền lưu trữ
    → có phí lấy dữ liệu, nhưng 1-2 lần thì không đáng kể
        ↓
    Và Standard-IA truy cập TỨC THÌ
    → thoả "must be immediately available"

Vì sao Deep Archive cho 7 năm sau: | Lớp | Giá lưu trữ tương đối | Thời gian lấy | |---|---|---| | S3 Standard | 1,0× | tức thì | | Standard-IA | ~0,55× | tức thì | | Glacier Instant Retrieval | ~0,2× | tức thì | | Glacier Flexible Retrieval | ~0,16× | phút tới giờ | | Deep Archive | ~0,04× | 12-48 giờ |

Lưu trữ 7 năm mà không cần truy cập nhanh
    → Deep Archive rẻ hơn Glacier Instant Retrieval khoảng 5 lần
        ↓
    Với 7 năm, khác biệt này rất lớn

Cấu hình DataSync ghi thẳng vào Standard-IA:

aws datasync create-location-s3   --s3-bucket-arn arn:aws:s3:::kho-tep   --s3-storage-class STANDARD_IA   --s3-config BucketAccessRoleArn=<arn-role>

Lifecycle:

{"Rules": [{
  "ID": "luu-tru-7-nam", "Status": "Enabled", "Filter": {},
  "Transitions": [{"Days": 365, "StorageClass": "DEEP_ARCHIVE"}],
  "Expiration": {"Days": 2920}}]}

2.920 ngày = 8 năm (1 năm Standard-IA + 7 năm Deep Archive).

Vì sao không gom tệp thành gói lớn:

Gom hàng triệu tệp thành vài gói lớn
    → RẺ HƠN nhiều về phí tối thiểu và phí request
    → NHƯNG mất khả năng truy cập từng tệp riêng lẻ
        ↓
    Đề nói "files must be IMMEDIATELY AVAILABLE"
    → phải giải nén cả gói mới lấy được một tệp
    → không còn "immediately available"

Đây là điểm loại cả A và D.

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

• **A. Gom tệp thành gói lớn, DataSync vào Standard-IA, lifecycle sang Glacier Instant Retrieval sau 1 năm — đây là phương án gần nhất và về mặt chi phí thuần tuý có thể còn rẻ hơn, nhưng nó sai ở hai điểm: gom gói phá vỡ yêu cầu truy cập ngay từng tệp, và Glacier Instant Retrieval đắt hơn Deep Archive khoảng 5 lần cho giai đoạn lưu trữ 7 năm mà không cần lấy nhanh.
• **D. Gom gói + Glacier Instant Retrieval năm đầu + Deep Archive sau đó — cùng vấn đề gom gói, và Glacier IR cho năm đầu có thời gian lưu tối thiểu 90 ngày cùng phí lấy dữ liệu cao hơn Standard-IA.
• **C. Đích là Glacier Instant Retrieval, sau 1 năm sang Glacier Flexible Retrieval — Flexible Retrieval đắt hơn Deep Archive khoảng 4 lần mà đề không cần lấy nhanh trong giai đoạn lưu trữ. Không phải lựa chọn tiết kiệm nhất.

Ghi nhớ

Bảng lớp lưu trữ S3 — phải thuộc: | Lớp | Truy cập | Lưu tối thiểu | Đối tượng tối thiểu | |---|---|---|---| | Standard | tức thì | — | — | | Intelligent-Tiering | tức thì | — | — | | Standard-IA | tức thì | 30 ngày | 128 KB | | One Zone-IA | tức thì | 30 ngày | 128 KB | | Glacier Instant Retrieval | tức thì | 90 ngày | 128 KB | | Glacier Flexible Retrieval | phút - giờ | 90 ngày | 40 KB | | Deep Archive | 12-48 giờ | 180 ngày | 40 KB |

Từ khoá nhận diện:

"immediately available" + "accessed once or twice" → Standard-IA hoặc Glacier IR "archive for years", "rarely if ever accessed" → Deep Archive "unpredictable access pattern" → Intelligent-Tiering "milliseconds retrieval" + archive giá → Glacier Instant Retrieval

Ba tuỳ chọn lấy dữ liệu Glacier Flexible Retrieval: | Tuỳ chọn | Thời gian | |---|---| | Expedited | 1-5 phút | | Standard | 3-5 giờ | | Bulk | 5-12 giờ (rẻ nhất) |

Và Deep Archive: | Tuỳ chọn | Thời gian | |---|---| | Standard | 12 giờ | | Bulk | 48 giờ |

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

Đáp án B đúng theo yêu cầu của đề, nhưng có một chi phí ẩn mà đề không nói tới và người học nên biết:

Standard-IA có kích thước đối tượng tối thiểu tính phí là 128 KB.

Tệp trung bình 10 KB, lưu trong Standard-IA
    → bị tính phí như thể nó nặng 128 KB
    → tức là trả gấp gần 13 LẦN dung lượng thật
        ↓
    Với hàng triệu tệp, đây là con số rất lớn

Tính thử với 10 triệu tệp: | | Dung lượng thật | Dung lượng tính phí | |---|---|---| | 10 triệu × 10 KB | ~95 GB | ~1.220 GB |

Đây chính là lý do phương án A và D đề xuất gom tệp thành gói lớn — về mặt chi phí thuần tuý, đó là cách làm đúng. Chúng bị loại vì ràng buộc "files must be immediately available", chứ không phải vì tính toán chi phí sai.

Nói cách khác: đề đặt ra hai yêu cầu mâu thuẫn nhau — vừa muốn rẻ nhất, vừa muốn từng tệp truy cập được ngay — và B là câu trả lời tôn trọng ràng buộc thứ hai.

Trong thực tế, đây là ba hướng đáng cân nhắc: | Hướng | Đánh đổi | |---|---| | Giữ ở S3 Standard năm đầu | không có phí tối thiểu 128 KB — với tệp rất nhỏ có thể RẺ HƠN Standard-IA | | Gom gói và chấp nhận độ trễ giải nén | rẻ nhất, mất truy cập tức thì | | S3 Intelligent-Tiering | không có phí tối thiểu đối tượng, tự chuyển lớp |

Hướng thứ nhất đáng tính lại bằng số thật: với tệp 10 KB, giá Standard cho 10 KB thật có thể thấp hơn giá Standard-IA cho 128 KB tính phí.

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Mỗi lần chuyển lớp tính phí theo SỐ ĐỐI TƯỢNG | hàng triệu tệp = phí đáng kể | | Không chuyển ngược lên lớp nóng bằng lifecycle | phải copy | | Lưu tối thiểu vẫn tính dù đã xoá | |

Dòng đầu là chi phí một lần nữa hay bị bỏ qua:

Chuyển 10 triệu đối tượng sang Deep Archive
    → phí chuyển tính theo số đối tượng
        ↓
    Cộng vào bài toán trước khi quyết định gom gói hay không

Ba lưu ý về DataSync: | Lưu ý | Chi tiết | |---|---| | Đặt lớp lưu trữ đích ngay khi tạo location | không cần lifecycle cho ngày 0 | | Có kiểm tra toàn vẹn dữ liệu | | | Đặt giới hạn băng thông | |

Ba công cụ phân tích chi phí: | Công cụ | Việc | |---|---| | S3 Storage Lens | phân bố kích thước đối tượng | | S3 Storage Class Analysis | mẫu truy cập theo lớp | | Cost Explorer | chi phí theo lớp |

S3 Storage Lens là công cụ đúng để phát hiện vấn đề 128 KB — nó cho biết bao nhiêu phần trăm đối tượng nhỏ hơn ngưỡng tính phí tối thiểu.

Và một lời khuyên: hãy tính chi phí bằng con số thật trước khi chọn lớp cho tệp nhỏ. Quy tắc "ít truy cập thì dùng IA" đúng với tệp lớn, nhưng với hàng triệu tệp 10 KB, ngưỡng tính phí tối thiểu có thể lật ngược hoàn toàn kết luận — và hoá đơn tháng đầu tiên là nơi rất tốn kém để phát hiện điều đó.

Đáp án

C — Đặt 10 thiết bị AWS Snowball, chọn một S3 bucket làm đích, rồi dùng lifecycle chuyển object sang S3 Glacier.

Vì sao đúng

Đề nêu bốn ràng buộc, và cả bốn dẫn về cùng một hướng: | Ràng buộc | Cách đáp ứng | |---|---| | 750 TB dữ liệu | quá lớn để truyền qua mạng | | Đường Internet chi nhánh KÉM | không dùng đường mạng | | KHÔNG được làm nghẽn đường truyền | chuyển bằng thiết bị vật lý | | Đích cuối là S3 Glacier, rẻ nhất | Snowball vào S3 rồi lifecycle |

Tính thử vì sao không truyền qua mạng được:

Giả sử đường 100 Mbps DÙNG TOÀN BỘ băng thông:
    750 TB = 750.000 GB = 6.000.000 Gb
    6.000.000 Gb / 0,1 Gbps = 60.000.000 giây
        ↓
    ≈ 694 NGÀY
    → và đó là khi chiếm hết đường, vi phạm ràng buộc thứ ba

Vì sao 10 thiết bị:

Snowball Edge Storage Optimized: ~80 TB dung lượng dùng được
    750 TB / 80 TB ≈ 10 thiết bị
        ↓
    Con số trong đề khớp

Quy trình:

1. Đặt hàng 10 thiết bị qua console
2. AWS gửi thiết bị tới chi nhánh
3. Nối vào mạng NỘI BỘ, chép dữ liệu (không đụng Internet)
4. Gửi trả AWS
5. AWS nạp dữ liệu vào S3 bucket
6. Lifecycle chuyển sang Glacier

Đặt hàng:

aws snowball create-job --job-type IMPORT   --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::kho-chi-nhanh"}]}'   --address-id ADID123 --snowball-type EDGE_S   --shipping-option SECOND_DAY

Lifecycle chuyển sang Glacier:

{"Rules": [{"ID":"sang-glacier","Status":"Enabled","Filter":{},
  "Transitions":[{"Days":0,"StorageClass":"GLACIER"}]}]}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không dùng băng thông Internet nào | | | Mã hoá 256-bit, khoá quản lý bằng KMS | | | Rẻ hơn nhiều so với nâng cấp đường truyền | |

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

• **D. Đặt 10 Snowball và trỏ chúng thẳng vào một S3 Glacier vault — đây là phương án gần nhất và chỉ sai một chi tiết kỹ thuật quan trọng: Snowball không nhập trực tiếp vào Glacier vault được. Đích của job import luôn là một S3 bucket; muốn vào Glacier thì phải qua lifecycle. Đây chính là điều làm C đúng còn D sai.
• **A. Chép trực tiếp qua mạng vào S3 rồi lifecycle — vi phạm cả hai ràng buộc về mạng: mất gần hai năm và làm nghẽn đường truyền của chi nhánh suốt thời gian đó.
• **B. Tạo Site-to-Site VPN thẳng tới một S3 bucket — mô tả một thứ không tồn tại: VPN nối tới VPC, không nối tới S3 bucket. Và dù có làm được thì vẫn đi qua chính đường Internet kém đó.

Ghi nhớ

Ba thiết bị họ Snow — bảng phải thuộc: | Thiết bị | Dung lượng | Đặc điểm | |---|---|---| | Snowcone | 8-14 TB | nhỏ nhất, xách tay | | Snowball Edge Storage Optimized | ~80 TB dùng được | phổ biến nhất ← câu này | | Snowball Edge Compute Optimized | ~28 TB + GPU | xử lý tại chỗ | | Snowmobile | tới 100 PB | xe container |

Từ khoá nhận diện:

"petabytes", "poor connection", "don't saturate" → Snow family "exabyte scale" → Snowmobile "ongoing transfer over network" → DataSync

Quy tắc ước lượng nhanh:

Thời gian truyền (ngày) ≈ Dung lượng (TB) × 8.000 / (Băng thông Mbps × 86.400 / 1.000)

Đơn giản hơn: nếu mất hơn MỘT TUẦN → cân nhắc Snowball
              nếu mất hơn MỘT THÁNG → chắc chắn Snowball

Ba lựa chọn di chuyển dữ liệu: | Lựa chọn | Khi nào | |---|---| | Snow family | lượng lớn, mạng kém, một lần ← câu này | | DataSync | định kỳ, mạng đủ tốt | | Storage Gateway | truy cập liên tục, có cache |

Ba đặc điểm bảo mật của Snowball: | Đặc điểm | Chi tiết | |---|---| | Mã hoá AES-256, khoá trong KMS | | | Khoá KHÔNG lưu trên thiết bị | | | Vỏ chống phá, có TPM | |

Vế thứ hai đáng nhớ:

Thiết bị bị mất trên đường vận chuyển
    → không ai đọc được dữ liệu
    → khoá giải mã nằm trong KMS của bạn

Ba lưu ý khi lập kế hoạch: | Lưu ý | Chi tiết | |---|---| | Tính cả thời gian vận chuyển hai chiều | thường 1-2 tuần trọn chu trình | | Dữ liệu thay đổi trong lúc đó phải đồng bộ sau | | | Cần máy chạy Snowball Client hoặc S3 Adapter | |

Vế thứ hai là chi tiết vận hành quan trọng:

Chép 750 TB mất nhiều ngày
    → dữ liệu mới sinh ra trong thời gian đó chưa nằm trên thiết bị
        ↓
    Kế hoạch: sau khi Snowball nạp xong,
    dùng DataSync đồng bộ phần chênh lệch qua mạng
    → phần này nhỏ nên mạng kém vẫn kham được

Ba cách chép dữ liệu lên thiết bị: | Cách | Đặc điểm | |---|---| | AWS OpsHub | giao diện đồ hoạ, dễ nhất | | Snowball Client (CLI) | | | S3 Adapter | dùng lệnh aws s3 cp quen thuộc |

Ba lưu ý để chép nhanh: | Lưu ý | Chi tiết | |---|---| | Chép song song nhiều luồng | | | Nối cổng 10 GbE hoặc 25 GbE | | | Tệp nhỏ chậm hơn nhiều — gom lại nếu được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí thuê thiết bị theo ngày | có số ngày miễn phí | | Phí vận chuyển | | | KHÔNG tính phí data transfer IN vào AWS | |

Dòng cuối đáng nhớ: nạp dữ liệu vào AWS luôn miễn phí, dù qua mạng hay qua Snowball.

Ba lưu ý về Glacier là đích cuối: | Lưu ý | Chi tiết | |---|---| | Lifecycle với Days: 0 chuyển ngay | | | Phí chuyển tính theo SỐ đối tượng | | | Cân nhắc Deep Archive nếu 7+ năm | |

Ba lưu ý về S3 Glacier hiện nay: | Khái niệm | Chi tiết | |---|---| | "S3 Glacier" giờ là LỚP LƯU TRỮ của S3 | không phải dịch vụ riêng | | Ba lớp: Instant, Flexible, Deep Archive | | | Glacier vault (dịch vụ cũ) vẫn tồn tại nhưng AWS khuyến nghị dùng lớp S3 | |

Đây chính là nền của việc D sai — Snowball làm việc với S3 bucket, còn "Glacier vault" thuộc dịch vụ Glacier đời cũ.

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

Hai chi tiết trong đề đã lỗi thời so với hiện tại:

"AWS Snowball" (bản gốc, không có Edge) đã ngừng. Dòng sản phẩm hiện tại là Snowball Edge — Storage Optimized hoặc Compute Optimized. Thiết bị Snowball đời đầu 50/80 TB không còn đặt được nữa. Con số "10 thiết bị cho 750 TB" vẫn đúng với Snowball Edge Storage Optimized (~80 TB dùng được mỗi cái).

"Amazon S3 Glacier" trong đề nên hiểu là lớp lưu trữ, không phải dịch vụ vault. AWS đã hợp nhất Glacier vào S3 dưới dạng ba lớp lưu trữ, và tài liệu hiện nay khuyến nghị dùng lớp S3 chứ không dùng Glacier vault. Điều này làm phương án D càng sai rõ hơn: cách nhập dữ liệu duy nhất mà Snowball hỗ trợ là vào một S3 bucket.

Đáp án

B — Triển khai trên Amazon Aurora Serverless v2, để dung lượng CSDL tự co giãn theo mức dùng thật.

Vì sao đúng

Đề nêu năm dữ kiện, và Aurora Serverless v2 khớp từng cái: | Dữ kiện | Cách đáp ứng | |---|---| | CSDL QUAN HỆ | Aurora là quan hệ (MySQL/PostgreSQL) | | Số bệnh nhân tăng đều | tự co giãn dung lượng | | Tải BIẾN ĐỘNG | co giãn theo giây, không cần đoán trước | | Nặng đọc, thỉnh thoảng ghi | thêm reader tự co giãn | | Tối ưu chi phí | trả theo ACU thực dùng |

Vì sao "biến động" là từ khoá quyết định:

Tải biến động + instance cố định:
    → chọn size lớn → lãng phí lúc thấp điểm
    → chọn size nhỏ → chậm lúc cao điểm
        ↓
Aurora Serverless v2:
    → co giãn từ 0,5 ACU tới 256 ACU
    → thay đổi trong VÀI GIÂY
    → trả tiền theo mức đang dùng

ACU là gì:

1 ACU ≈ 2 GB RAM + CPU và mạng tương ứng
    → tăng giảm theo bước 0,5 ACU
    → mượt, không có bước nhảy lớn

Cấu hình:

aws rds create-db-cluster --db-cluster-identifier ho-so-benh-nhan   --engine aurora-postgresql --engine-mode provisioned   --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16   --storage-encrypted --kms-key-id alias/khoa-y-te

aws rds create-db-instance --db-instance-identifier writer-1   --db-cluster-identifier ho-so-benh-nhan   --db-instance-class db.serverless --engine aurora-postgresql

Và thêm reader cho tải nặng đọc:

aws rds create-db-instance --db-instance-identifier reader-1   --db-cluster-identifier ho-so-benh-nhan   --db-instance-class db.serverless --engine aurora-postgresql

Reader cũng co giãn độc lập:

Đợt truy vấn báo cáo → reader tự lên 8 ACU
Lúc bình thường      → tụt về 0,5 ACU
        ↓
    Writer không bị ảnh hưởng

Ba lợi ích khác: | Lợi ích | Chi tiết | |---|---| | Lưu trữ tự tăng tới 128 TB | không phải cấp phát trước | | Sao lưu liên tục, khôi phục theo thời điểm | | | Có đủ tính năng Aurora (global database, clone) | |

Vế thứ nhất hợp với "số bệnh nhân tăng đều" — không phải theo dõi và mở rộng đĩa bằng tay.

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

• **D. RDS với gp3 và một read replica — đây là phương án gần nhất và hoàn toàn chạy được, nhưng nó không tối ưu chi phí cho tải biến động: instance có kích thước cố định, trả tiền 24/7 cho mức năng lực cao nhất mà bạn dự phòng, kể cả những giờ gần như không ai dùng.
• **A. Dùng DynamoDB on-demand — sai loại CSDL: đề nói rõ "relational database", và dữ liệu hồ sơ bệnh nhân với cấu hình hệ thống thường cần join, giao dịch và truy vấn linh hoạt. Chuyển sang NoSQL là viết lại toàn bộ tầng dữ liệu.
• **C. RDS với magnetic storage và Multi-AZ — magnetic là loại lưu trữ đời cũ, hiệu năng thấp nhất và AWS không còn khuyến nghị cho tải mới. Nó hoàn toàn không phù hợp với tải "nặng đọc".

Ghi nhớ

Ba lựa chọn CSDL quan hệ trên AWS — bảng phải thuộc: | Lựa chọn | Khi nào | |---|---| | RDS (provisioned) | tải ỔN ĐỊNH, dự đoán được | | Aurora (provisioned) | tải ổn định, cần hiệu năng và tính năng Aurora | | Aurora Serverless v2 | tải BIẾN ĐỘNG, không đoán được ← câu này |

Từ khoá nhận diện:

"variable workload" + "cost-optimize" → Aurora Serverless v2 "relational" → loại DynamoDB ngay "read-heavy" → thêm read replica hoặc reader "steady, predictable" → RDS provisioned + Reserved Instance

Serverless v1 và v2 — bảng phân biệt: | | v1 | v2 | |---|---|---| | Co giãn | theo bước nhân đôi | theo bước 0,5 ACU | | Thời gian co giãn | chục giây tới phút | vài giây | | Về 0 khi rảnh | ✅ tạm dừng được | ❌ tối thiểu 0,5 ACU (hoặc 0 với cấu hình mới) | | Read replica | ❌ | ✅ | | Multi-AZ | hạn chế | ✅ | | Global database | ❌ | ✅ |

⚠ Điểm khác biệt quan trọng nhất:

v1 tạm dừng hoàn toàn khi không dùng → chi phí bằng 0
    → nhưng lần kết nối đầu sau đó mất 30+ giây để "thức dậy"
        ↓
v2 luôn giữ tối thiểu (thường 0,5 ACU)
    → không có độ trễ khởi động lạnh
    → nhưng luôn có chi phí nền

Với ứng dụng y tế phục vụ người dùng thật, v2 là lựa chọn đúng — không ai muốn chờ 30 giây để mở hồ sơ bệnh nhân.

Ba tham số cần đặt đúng: | Tham số | Lưu ý | |---|---| | MinCapacity | đủ để giữ cache nóng, đừng quá thấp | | MaxCapacity | trần chi phí và trần hiệu năng | | Số reader | theo tải đọc |

MinCapacity quá thấp là bẫy hiệu năng:

Min = 0,5 ACU → chỉ ~1 GB RAM cho buffer pool
    → truy vấn phải đọc từ đĩa nhiều
    → co giãn lên mất vài giây, trong lúc đó vẫn chậm
        ↓
    Đặt min đủ để giữ tập dữ liệu nóng trong bộ nhớ

Ba yếu tố kích hoạt co giãn: | Yếu tố | Chi tiết | |---|---| | Sử dụng CPU | | | Áp lực bộ nhớ | | | Số kết nối | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | ACU tính theo GIÂY | | | Lưu trữ và I/O tính riêng | | | Cân nhắc Aurora I/O-Optimized | nếu I/O chiếm > 25% hoá đơn |

Aurora I/O-Optimized đáng biết:

Cấu hình mặc định: trả riêng cho mỗi I/O request
I/O-Optimized:     giá ACU và lưu trữ cao hơn, KHÔNG tính phí I/O
        ↓
    Với tải nặng đọc, I/O-Optimized thường rẻ hơn
    → đổi qua lại được mỗi 30 ngày

Ba lưu ý cho ứng dụng y tế: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá at rest bằng KMS | HIPAA yêu cầu | | Aurora nằm trong danh sách dịch vụ đủ điều kiện HIPAA | cần ký BAA | | Bật audit log (Database Activity Streams) | |

Ba cách tối ưu tải nặng đọc: | Cách | Chi tiết | |---|---| | Reader instance + reader endpoint | | | RDS Proxy gộp kết nối | | | ElastiCache cho dữ liệu hay đọc | |

RDS Proxy đặc biệt hợp với serverless:

Ứng dụng mở nhiều kết nối ngắn
    → mỗi kết nối tốn tài nguyên CSDL
    → đẩy ACU lên cao không cần thiết
        ↓
    RDS Proxy gộp lại → ACU thấp hơn → rẻ hơn

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ServerlessDatabaseCapacity | ACU đang dùng | | ACUUtilization | có chạm trần max không | | DatabaseConnections | |

Metric thứ hai là tín hiệu phải tăng MaxCapacity:

ACUUtilization chạm 100% thường xuyên
    → đã đụng trần, truy vấn bắt đầu chậm
    → tăng MaxCapacity

Ba việc nên làm sau khi triển khai: | Việc | Chi tiết | |---|---| | Quan sát ACU thật một tháng | rồi điều chỉnh min/max | | Bật Performance Insights | tìm truy vấn nặng | | So chi phí với RDS provisioned tương đương | |

Và một lời khuyên: hãy theo dõi ServerlessDatabaseCapacity trong một tháng rồi so với chi phí một instance provisioned cùng cỡ. Serverless v2 tiết kiệm khi tải thật sự biến động; nếu đồ thị ACU gần như phẳng thì một instance provisioned kèm Reserved Instance sẽ rẻ hơn đáng kể — và bạn chỉ biết điều đó sau khi có dữ liệu thật.

Đáp án

A — Dùng mã hoá phía client (client-side encryption) với master key lưu trong AWS KMS.

Vì sao đúng

Đề nêu một yêu cầu rất rõ và rất hẹp: dữ liệu phải được mã hoá TRƯỚC KHI tải lên. | Yêu cầu | Ý nghĩa | |---|---| | "encrypted BEFORE it is uploaded" | mã hoá xảy ra trên máy khách | | Master key trong KMS | không tự quản lý khoá gốc |

Vế đầu loại sạch mọi phương án server-side:

Server-side encryption (SSE):
    dữ liệu đi TRẦN tới S3 (trong đường TLS)
    → S3 nhận rồi mới mã hoá khi GHI xuống đĩa
        ↓
    Tại thời điểm S3 nhận, dữ liệu chưa được mã hoá
    → không thoả "encrypted before upload"

Client-side encryption:
    dữ liệu được mã hoá TRÊN MÁY BẠN
    → S3 nhận về một khối byte vô nghĩa
        ↓
    Đúng yêu cầu

Cách hoạt động (envelope encryption):

1. Client gọi KMS: GenerateDataKey
2. KMS trả về: data key dạng THÔ + dạng ĐÃ MÃ HOÁ
3. Client dùng data key thô mã hoá dữ liệu
4. Client xoá data key thô khỏi bộ nhớ
5. Client tải lên S3: dữ liệu đã mã hoá + data key đã mã hoá (trong metadata)
        ↓
    Khi đọc: gửi data key đã mã hoá cho KMS giải mã, rồi giải mã dữ liệu

Dùng SDK:

import boto3
from aws_encryption_sdk import EncryptionSDKClient, StrictAwsKmsMasterKeyProvider

client = EncryptionSDKClient()
kp = StrictAwsKmsMasterKeyProvider(key_ids=['arn:aws:kms:...:key/abc-123'])

with open('ho-so.pdf', 'rb') as f:
    du_lieu_ma_hoa, header = client.encrypt(source=f.read(), key_provider=kp)

boto3.client('s3').put_object(
    Bucket='kho-nhay-cam', Key='ho-so.pdf', Body=du_lieu_ma_hoa)

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AWS KHÔNG BAO GIỜ thấy dữ liệu trần | | | Kiểm soát khoá qua key policy của KMS | | | Vẫn có audit đầy đủ trong CloudTrail | |

Vế đầu là lý do duy nhất người ta chọn client-side encryption — nó là câu trả lời cho yêu cầu tuân thủ "nhà cung cấp đám mây không được có khả năng đọc dữ liệu".

Vì sao dùng KMS chứ không tự giữ khoá: | Lợi ích | Chi tiết | |---|---| | Không phải tự lưu và xoay khoá gốc | | | Phân quyền dùng khoá bằng key policy | | | Mọi lần dùng khoá ghi vào CloudTrail | |

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

• **C. Server-side encryption với khoá trong KMS (SSE-KMS) — đây là phương án gần nhất và là lựa chọn tốt nhất cho hầu hết trường hợp thực tế, nhưng nó mã hoá sau khi S3 nhận dữ liệu, không phải trước khi tải lên. Đề nêu ràng buộc rất cụ thể ở chỗ này.
• **B. Server-side encryption với khoá do khách cung cấp (SSE-C) — vẫn là server-side: bạn gửi khoá kèm request, S3 dùng nó để mã hoá sau khi nhận. Và bạn phải tự quản lý khoá, gửi nó theo mỗi request.
• **D. Client-side encryption với khoá do Amazon S3 quản lý — mô tả một thứ không tồn tại: "S3-managed keys" (SSE-S3) chỉ có ở phía máy chủ. Không có cơ chế nào để S3 quản lý khoá mà mã hoá lại diễn ra ở phía client.

Ghi nhớ

Bốn lựa chọn mã hoá cho S3 — bảng phải thuộc: | Lựa chọn | Mã hoá ở đâu | Ai giữ khoá | |---|---|---| | SSE-S3 | máy chủ S3 | AWS hoàn toàn | | SSE-KMS | máy chủ S3 | KMS, bạn kiểm soát policy | | SSE-C | máy chủ S3 | bạn — gửi theo mỗi request | | CSE (client-side) | MÁY CLIENT | bạn (qua KMS hoặc tự giữ) |

Từ khoá nhận diện:

"encrypted BEFORE upload", "AWS must never see plaintext" → client-side encryption "audit key usage", "control key policy" → SSE-KMS "simplest", "default" → SSE-S3 "provide our own key per request" → SSE-C

⚠ SSE-S3 giờ là MẶC ĐỊNH:

Từ 01/2023, mọi object mới trong mọi bucket
    tự động được mã hoá bằng SSE-S3
        ↓
    Câu "bật mã hoá cho bucket" không còn cần thiết
    → chỉ cần quyết định có nâng lên SSE-KMS hay CSE không

Ba đặc điểm của SSE-KMS: | Đặc điểm | Chi tiết | |---|---| | Ghi log mọi lần dùng khoá vào CloudTrail | | | Key policy kiểm soát ai giải mã được | | | Có giới hạn tần suất gọi KMS | |

Vế thứ ba là vấn đề thực tế với tải lớn:

Mỗi lần đọc/ghi object gọi KMS một lần
    → tải lớn có thể chạm giới hạn tần suất → ThrottlingException
        ↓
    Bật S3 Bucket Keys → giảm gọi KMS tới 99%

aws s3api put-bucket-encryption --bucket kho-nhay-cam   --server-side-encryption-configuration '{
    "Rules":[{"ApplyServerSideEncryptionByDefault":{
      "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/khoa-s3"},
      "BucketKeyEnabled":true}]}'

Ba nhược điểm của client-side encryption — phải cân nhắc thật: | Nhược điểm | Chi tiết | |---|---| | Mất khả năng dùng dịch vụ AWS xử lý dữ liệu | Athena, Glue, Macie không đọc được | | Phải quản lý thư viện mã hoá ở mọi client | | | Tự lo tương thích khi đổi cách mã hoá | |

Dòng đầu là cái giá lớn nhất:

Dữ liệu mã hoá phía client trong S3
    → Athena không truy vấn được
    → Macie không quét được dữ liệu nhạy cảm
    → S3 Select không dùng được
        ↓
    S3 chỉ còn là nơi cất khối byte

Ba đặc điểm của SSE-C: | Đặc điểm | Chi tiết | |---|---| | Gửi khoá theo MỖI request | header x-amz-server-side-encryption-customer-key | | BẮT BUỘC dùng HTTPS | | | AWS KHÔNG lưu khoá — mất khoá là mất dữ liệu | |

Ba khái niệm KMS cần biết: | Khái niệm | Nghĩa | |---|---| | Envelope encryption | data key mã hoá dữ liệu, KMS mã hoá data key | | GenerateDataKey | API trả về data key thô + đã mã hoá | | Key policy | nguồn quyền chính trên khoá |

Vì sao dùng envelope encryption:

Không gửi dữ liệu lớn qua KMS (giới hạn 4 KB mỗi lần gọi)
    → KMS chỉ xử lý data key nhỏ
    → dữ liệu lớn được mã hoá tại chỗ bằng data key
        ↓
    Nhanh, rẻ, và không giới hạn kích thước

Ba lưu ý về key policy: | Lưu ý | Chi tiết | |---|---| | Key policy là nguồn quyền CHÍNH | IAM một mình không đủ | | Client cần kms:GenerateDataKey và kms:Decrypt | | | Dùng kms:ViaService giới hạn phạm vi | |

Ba thư viện hỗ trợ: | Thư viện | Đặc điểm | |---|---| | AWS Encryption SDK | đa ngôn ngữ, có định dạng thông điệp chuẩn | | Amazon S3 Encryption Client | tích hợp sẵn với S3 | | DynamoDB Encryption Client | cho DynamoDB |

Ba lưu ý khi vận hành: | Lưu ý | Chi tiết | |---|---| | Bật xoay khoá tự động cho CMK | | | Ghi tài liệu khoá nào dùng cho dữ liệu nào | | | Đặt alarm trên kms:Decrypt bất thường | |

Dòng thứ hai quan trọng hơn nhiều người nghĩ:

Mã hoá phía client, một năm sau không ai nhớ khoá nào cho dữ liệu nào
    → và người viết mã đã nghỉ việc
        ↓
    Ghi tài liệu ánh xạ khoá là một phần của giải pháp,
    không phải việc làm thêm

Và một lời khuyên: hãy hỏi lại đội bảo mật xem SSE-KMS có đủ không trước khi chọn client-side encryption. Rất nhiều yêu cầu "phải mã hoá trước khi lên đám mây" thực chất được thoả bằng SSE-KMS với khoá do bạn kiểm soát — và cái giá của client-side encryption là mất hẳn mọi công cụ phân tích và quét dữ liệu của AWS, một cái giá dễ trả nhầm.

Đáp án

D — Dùng AWS Storage Gateway Volume Gateway ở chế độ cached, cấu hình cached volume làm iSCSI target, lưu bộ dữ liệu chính trên AWS và giữ ảnh hay dùng trong cache cục bộ.

Vì sao đúng

Đề nêu bốn dữ kiện, và mỗi cái loại bớt lựa chọn: | Dữ kiện | Ý nghĩa | |---|---| | Ảnh nằm trên hệ thống lưu trữ KHỐI (block) nối với thiết bị y tế | cần giao diện iSCSI, không phải NFS/SMB | | Dung lượng cục bộ hạn chế, cần đẩy lên đám mây | cached mode: dữ liệu chính ở AWS | | Ứng dụng phân tích tại chỗ cần ĐỘ TRỄ THẤP với ảnh hay dùng | cache cục bộ | | Tích hợp với hệ thống hiện có, ít công vận hành | không phải sửa ứng dụng |

Vế đầu là điểm quyết định của câu này:

Đề nói rõ: "stored on on-premises BLOCK STORAGE systems
            connected to medical devices"
        ↓
    Thiết bị y tế và phần mềm xử lý ảnh thường ghi vào
    ổ đĩa dạng KHỐI, không phải file share
    → giao diện phải là iSCSI
    → Volume Gateway, không phải File Gateway

Vì sao chế độ cached chứ không phải stored: | Chế độ | Dữ liệu CHÍNH ở đâu | Cache | |---|---|---| | Cached volume | AWS (S3) | dữ liệu nóng tại chỗ ← đề cần | | Stored volume | TẠI CHỖ (toàn bộ) | snapshot lên AWS |

Đề nói: "Due to LIMITED LOCAL STORAGE CAPACITY,
         needs to offload data to the cloud"
        ↓
    Stored mode giữ TOÀN BỘ dữ liệu tại chỗ
    → không giải quyết được vấn đề dung lượng
    → phải là cached mode

Cấu hình:

aws storagegateway create-cached-iscsi-volume   --gateway-arn <arn-gateway>   --volume-size-in-bytes 32000000000000   --target-name anh-y-te   --network-interface-id 10.0.1.50   --client-token $(uuidgen) --kms-encrypted --kms-key <arn-khoa>

Máy phân tích nối vào như ổ đĩa bình thường:

iscsiadm --mode discovery --type sendtargets --portal 10.0.1.50:3260
iscsiadm --mode node --targetname iqn.1997-05...:anh-y-te --login

Sau bước này, hệ điều hành thấy một ổ đĩa mới
    → ứng dụng phân tích dùng như ổ cục bộ
    → KHÔNG phải sửa mã
        ↓
    Đây là nghĩa của "integrates with existing setup"

Cơ chế cache:

Đọc ảnh mới chụp (trong cache)   → tốc độ ổ cục bộ
Đọc ảnh cũ (không trong cache)   → tải từ S3, chậm hơn, rồi vào cache
Ghi ảnh mới                       → vào upload buffer → đẩy lên S3
        ↓
    Dung lượng "nhìn thấy" tới 32 TB mỗi volume
    → mà đĩa cục bộ chỉ cần vài TB

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dung lượng gần như không giới hạn | 32 TB × 32 volume | | Snapshot EBS tự động theo lịch | dùng cho DR | | Không đụng tới ứng dụng phân tích | |

Snapshot theo lịch:

aws storagegateway update-snapshot-schedule   --volume-arn <arn-volume> --start-at 2 --recurrence-in-hours 24   --description "Sao luu anh y te hang ngay"

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

• **B. Dùng S3 File Gateway mount NFS/SMB cho máy phân tích — đây là phương án gần nhất và cũng có cache cục bộ, nhưng nó sai giao diện: đề nói rõ dữ liệu nằm trên block storage nối với thiết bị y tế. Chuyển sang file share nghĩa là phải cấu hình lại thiết bị và có thể sửa ứng dụng — ngược với yêu cầu "tích hợp với hệ thống hiện có".
• **A. Dùng Tape Gateway lưu băng ảo trong Glacier Instant Retrieval — Tape Gateway dành cho sao lưu, không phải lưu trữ chính đang dùng. Lấy dữ liệu từ băng ảo là quy trình khôi phục, không phải truy cập độ trễ thấp.
• **C. Dùng Snowball Edge chuyển dữ liệu định kỳ + S3 Transfer Acceleration — Snowball là công cụ di chuyển một lần, không phải cơ chế lưu trữ liên tục. Và Transfer Acceleration chỉ tăng tốc tải lên qua Internet, không cho truy cập độ trễ thấp tại chỗ.

Ghi nhớ

Bốn chế độ Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Dùng cho | |---|---|---| | S3 File Gateway | NFS, SMB | tệp lên S3 | | FSx File Gateway | SMB | truy cập FSx for Windows | | Volume Gateway | iSCSI (KHỐI) | ổ đĩa ← câu này | | Tape Gateway | iSCSI VTL | thay băng từ vật lý |

Từ khoá nhận diện:

"block storage", "iSCSI" → Volume Gateway "limited local capacity" + "low latency for frequent data" → CACHED mode "keep all data on-premises, backup to AWS" → STORED mode "NFS/SMB file share" → File Gateway

Hai chế độ Volume Gateway — bảng phân biệt: | | Cached | Stored | |---|---|---| | Dữ liệu chính | S3 (AWS) | tại chỗ | | Cache cục bộ | dữ liệu nóng | — | | Giải quyết thiếu dung lượng | ✅ | ❌ | | Kích thước volume tối đa | 32 TB | 16 TB | | Số volume tối đa | 32 | 32 | | Dung lượng tối đa mỗi gateway | 1 PB | 512 TB |

Ba loại đĩa cục bộ cần cấp cho Volume Gateway: | Đĩa | Việc | |---|---| | Cache storage | giữ dữ liệu đọc nóng | | Upload buffer | đệm dữ liệu ghi chờ lên S3 | | (Stored mode: đĩa dữ liệu chính) | |

⚠ Upload buffer là chỗ hay gây sự cố nhất:

Upload buffer đầy
    → gateway KHÔNG nhận thêm ghi
    → ứng dụng bị chặn
        ↓
    Xảy ra khi băng thông lên AWS chậm hơn tốc độ ghi
    → theo dõi UploadBufferPercentUsed
    → tăng đĩa buffer hoặc tăng băng thông

Ba metric bắt buộc theo dõi: | Metric | Ngưỡng cảnh báo | |---|---| | UploadBufferPercentUsed | > 80% là nguy hiểm | | CachePercentUsed | cache đầy làm tỷ lệ trúng giảm | | CacheHitPercent | thấp = ứng dụng chậm |

CacheHitPercent là số quyết định trải nghiệm ở bài này:

Ảnh y tế rất lớn (CT, MRI có thể hàng GB)
    → cache nhỏ → tỷ lệ trúng thấp
    → mỗi lần mở ảnh phải tải từ S3
        ↓
    Yêu cầu "low latency" không đạt trên thực tế
    → cấp đĩa cache đủ lớn cho dữ liệu vài tuần gần nhất

Ba yêu cầu tài nguyên cho Volume Gateway: | Yêu cầu | Con số tối thiểu | |---|---| | vCPU | 4 | | RAM | 16 GB | | Đĩa cache + buffer | mỗi loại ≥ 150 GB |

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Snapshot lưu thành EBS snapshot | | | Tạo được EBS volume từ snapshot | dùng cho DR trên EC2 | | Đặt lịch tự động | |

Vế thứ hai là giá trị DR lớn nhất của Volume Gateway:

Trung tâm dữ liệu gặp sự cố
    → tạo EBS volume từ snapshot mới nhất
    → gắn vào EC2 → ứng dụng phân tích chạy trên AWS
        ↓
    Không cần chép lại dữ liệu

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Đặt giới hạn tải lên theo lịch | | | Đồng bộ ban đầu tốn nhiều băng thông | | | Ảnh y tế rất lớn — tính kỹ | |

Ba lưu ý về bảo mật cho dữ liệu y tế: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest bằng KMS | --kms-encrypted | | Truyền qua TLS | | | Storage Gateway đủ điều kiện HIPAA | cần ký BAA với AWS |

Ba lưu ý về hiệu năng iSCSI: | Lưu ý | Chi tiết | |---|---| | Dùng mạng riêng cho iSCSI nếu được | | | Bật jumbo frames (MTU 9000) | | | Multipath I/O cho tính sẵn sàng | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ volume trên AWS | | | Snapshot tính theo dung lượng thay đổi | | | Phí lấy dữ liệu khi cache miss | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi ảnh mới, xem nó lên AWS chưa | | | Đọc ảnh cũ, đo thời gian | | | Thử tạo EBS volume từ snapshot | |

Và một lời khuyên: hãy tính kích thước cache theo lượng ảnh sinh ra trong khoảng thời gian mà bác sĩ thường xem lại, chứ đừng theo một tỷ lệ phần trăm chung chung. Với ảnh y tế, mẫu truy cập rất rõ — ảnh của tuần này được mở liên tục, ảnh của năm ngoái gần như không ai đụng — và cache đúng bằng cửa sổ đó cho tỷ lệ trúng cao nhất với chi phí thấp nhất.

Đáp án

C — Đặt retention của RDS automated backup thành 30 ngày, và dùng một script tìm rồi xoá các manual snapshot cũ hơn 30 ngày.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này là cách đơn giản nhất thoả cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Giữ bản sao lưu 30 ngày để tuân thủ | retention period = 30 | | Có CẢ automated VÀ manual backup | hai cơ chế xử lý riêng | | Bản trong 30 ngày phải được giữ | retention giữ tự động, script chỉ xoá bản cũ | | Tiết kiệm và ít công vận hành nhất | dùng tính năng có sẵn, không thêm dịch vụ |

Vì sao phải xử lý riêng hai loại:

Automated backup:
    → RDS TỰ xoá theo retention period
    → đặt 30 là xong, không cần làm gì thêm

Manual snapshot:
    → KHÔNG bao giờ tự hết hạn
    → tồn tại cho tới khi có người xoá
    → kể cả sau khi XOÁ instance CSDL
        ↓
    Đây là điểm mấu chốt của câu hỏi

Đặt retention:

aws rds modify-db-instance --db-instance-identifier don-hang   --backup-retention-period 30 --apply-immediately

Script dọn manual snapshot:

NGUONG=$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)
aws rds describe-db-snapshots --snapshot-type manual   --query "DBSnapshots[?SnapshotCreateTime<'$NGUONG'].DBSnapshotIdentifier"   --output text | tr '\t' '\n' | while read s; do
    aws rds delete-db-snapshot --db-snapshot-identifier "$s"
done

Chạy theo lịch bằng EventBridge Scheduler:

cron(0 3 * * ? *)  → mỗi ngày 3 giờ sáng
    → gọi Lambda chạy đoạn trên

Ba lý do đây là phương án tiết kiệm nhất: | Lý do | Chi tiết | |---|---| | RDS automated backup MIỄN PHÍ | trong phạm vi dung lượng CSDL | | Không phải trả phí AWS Backup | | | Không nhân đôi bản sao lưu | |

Vế đầu là chi tiết chi phí quan trọng:

AWS cho phép lưu trữ backup MIỄN PHÍ
    bằng đúng dung lượng lưu trữ đã cấp phát của CSDL
        ↓
    Vượt quá mới tính phí
    → dùng automated backup rẻ hơn tạo hệ thống sao lưu song song

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

• **A. Dùng AWS Backup ép retention cho automated backup, và Lambda xoá manual snapshot cũ — đây là phương án gần nhất và hoàn toàn khả thi, nhưng nó thêm một dịch vụ không cần thiết: AWS Backup có phí riêng, và RDS đã có sẵn cơ chế retention làm đúng việc đó. Công vận hành cao hơn mà không được lợi ích gì thêm ở bài này.
• **B. Tắt RDS automated backup và dùng AWS Backup tạo bản sao lưu hằng ngày — mất tính năng quan trọng nhất: tắt automated backup là mất point-in-time recovery, tức là chỉ khôi phục về các mốc hằng ngày thay vì bất kỳ giây nào trong 30 ngày. Với hệ thống xử lý đơn hàng, đó là mất mát lớn.
• **D. Giữ nguyên cấu hình và dùng CloudWatch Events + Lambda xoá cả hai loại — không xoá được automated backup bằng API: RDS quản lý chúng theo retention period, không có lệnh xoá từng bản. Viết Lambda để làm việc đó là viết mã cho một thao tác không tồn tại.

Ghi nhớ

Hai loại sao lưu RDS — bảng phải thuộc: | | Automated backup | Manual snapshot | |---|---|---| | Ai tạo | RDS tự động hằng ngày | bạn | | Hết hạn | theo retention (0-35 ngày) | KHÔNG BAO GIỜ | | Point-in-time recovery | ✅ | ❌ chỉ về đúng mốc đó | | Khi xoá instance | bị xoá theo (trừ khi giữ) | VẪN CÒN | | Chép sang vùng khác | không trực tiếp | ✅ |

Từ khoá nhận diện:

"retention policy" + "automated and manual" → retention period + script cho manual "restore to any point in time" → automated backup bắt buộc "keep beyond 35 days" → manual snapshot hoặc AWS Backup

⚠ Giới hạn 35 ngày là con số phải nhớ:

Retention period tối đa của RDS automated backup = 35 NGÀY
    → yêu cầu 30 ngày vừa khít
    → nếu đề hỏi 90 ngày hay 7 năm thì automated backup KHÔNG đủ
    → lúc đó mới cần AWS Backup hoặc manual snapshot theo lịch

Ba đặc điểm của automated backup: | Đặc điểm | Chi tiết | |---|---| | Chụp toàn bộ hằng ngày + lưu transaction log liên tục | | | Cho phép khôi phục về BẤT KỲ GIÂY nào trong khoảng giữ | | | Đặt retention = 0 là TẮT | |

Vế thứ hai là giá trị lớn nhất:

Ai đó chạy nhầm DELETE lúc 14:37
    → khôi phục về 14:36:59
        ↓
    Manual snapshot chỉ về được mốc lúc chụp

Khôi phục theo thời điểm:

aws rds restore-db-instance-to-point-in-time   --source-db-instance-identifier don-hang   --target-db-instance-identifier don-hang-khoi-phuc   --restore-time 2026-08-20T14:36:59Z

Ba lưu ý về manual snapshot: | Lưu ý | Chi tiết | |---|---| | Tồn tại vĩnh viễn cho tới khi xoá | nguồn chi phí ẩn phổ biến | | Còn lại sau khi xoá instance | | | Copy sang vùng khác được | dùng cho DR |

Dòng đầu là bài học chi phí kinh điển:

Đội phát triển chụp snapshot trước mỗi lần triển khai
    → sau hai năm có hàng trăm snapshot không ai nhớ
    → hoá đơn lưu trữ tăng dần mà không ai để ý
        ↓
    Chính là lý do câu hỏi này tồn tại

Ba cách tránh: | Cách | Chi tiết | |---|---| | Gắn tag cho snapshot khi tạo | ghi rõ mục đích và hạn | | Script dọn theo tag và tuổi | | | AWS Config rule cảnh báo snapshot quá cũ | |

Ba đặc điểm của AWS Backup: | Đặc điểm | Chi tiết | |---|---| | Quản lý tập trung nhiều dịch vụ | RDS, EBS, EFS, DynamoDB, FSx | | Backup vault có Vault Lock (WORM) | | | Lifecycle chuyển sang lớp lạnh | |

AWS Backup đáng dùng khi nào:

Cần sao lưu NHIỀU loại tài nguyên với chính sách thống nhất
    → hoặc cần giữ QUÁ 35 ngày
    → hoặc cần Vault Lock để không ai xoá được (tuân thủ nghiêm ngặt)
        ↓
    Ở bài này chỉ có RDS và đúng 30 ngày
    → tính năng sẵn có của RDS là đủ

Vault Lock đáng biết cho yêu cầu tuân thủ:

Bật Vault Lock ở chế độ compliance
    → KHÔNG AI xoá được bản sao lưu trước hạn
    → kể cả tài khoản root
        ↓
    Nhưng cũng KHÔNG GỠ ĐƯỢC sau khi qua thời gian cooling-off
    → cân nhắc rất kỹ trước khi bật

Ba lưu ý về backup window: | Lưu ý | Chi tiết | |---|---| | Đặt vào giờ thấp điểm | | | Single-AZ có thể có độ trễ I/O ngắn | | | Multi-AZ chụp từ standby — không ảnh hưởng | |

Vế thứ ba là một lợi ích ít người biết của Multi-AZ.

Ba lưu ý về chi phí sao lưu: | Khoản | Chi tiết | |---|---| | Miễn phí tới bằng dung lượng CSDL đã cấp phát | | | Vượt quá tính theo GB-tháng | | | Snapshot chép sang vùng khác tính phí truyền | |

Ba việc kiểm chứng định kỳ: | Việc | Tần suất | |---|---| | Thử khôi phục thật | quý | | Kiểm kê snapshot còn tồn | tháng | | Xem chi phí lưu trữ backup | tháng |

Việc đầu là quan trọng nhất:

Một chính sách sao lưu chưa từng được khôi phục thử
    là một giả thuyết, không phải một bảo đảm

Và một lời khuyên: hãy gắn tag het-han với ngày cụ thể vào mọi manual snapshot ngay lúc tạo, rồi để script dọn theo tag đó thay vì theo tuổi. Snapshot chụp trước một lần nâng cấp lớn có thể cần giữ lâu hơn 30 ngày một cách hợp lý — và một script chỉ nhìn ngày tạo sẽ xoá mất đúng bản mà bạn cần nhất.

Đáp án

C — Đặt IAM permissions boundary trên role của lập trình viên, từ chối tường minh việc gắn chính sách administrator.

Vì sao đúng

Đề nêu một mâu thuẫn kinh điển, và permissions boundary sinh ra đúng để giải quyết nó: | Yêu cầu | Ràng buộc | |---|---| | Lập trình viên được gắn policy vào role | giữ tốc độ thử nghiệm | | Nhưng KHÔNG được gắn AdministratorAccess | giữ hàng rào bảo mật |

Permissions boundary hoạt động thế nào:

Permissions boundary KHÔNG cấp quyền
    → nó đặt TRẦN cho quyền tối đa mà một danh tính có thể có
        ↓
    Quyền thật = GIAO của (identity policy) và (permissions boundary)

Vì sao điều đó chặn được việc leo thang đặc quyền:

Lập trình viên gắn AdministratorAccess vào role
    → role đó CÓ chính sách admin
    → nhưng permissions boundary vẫn chặn
        ↓
    Quyền hiệu lực vẫn nằm trong trần đã đặt
    → gắn được nhưng KHÔNG dùng được

Boundary policy:

{"Version": "2012-10-17",
 "Statement": [
   {"Effect": "Allow", "Action": ["ec2:*","s3:*","lambda:*","logs:*"],
    "Resource": "*"},
   {"Effect": "Deny", "Action": "iam:*", "Resource": "*",
    "Condition": {"StringNotEquals":
      {"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/RanhGioiDev"}}}]}

Câu Deny thứ hai là phần quan trọng nhất:

Nó buộc: mọi role mà lập trình viên tạo ra
         cũng PHẢI mang chính boundary này
        ↓
    Không có nó, lập trình viên tạo role mới không boundary
    rồi gắn admin vào role đó → lách được hoàn toàn

Gắn boundary:

aws iam put-role-permissions-boundary --role-name RoleLapTrinhVien   --permissions-boundary arn:aws:iam::123456789012:policy/RanhGioiDev

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lập trình viên vẫn tự gắn policy được | giữ tốc độ | | Trần quyền không vượt được | | | Uỷ quyền an toàn cho IAM | |

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

• **A. Dùng SCP tắt hoạt động IAM trên toàn OU — đây là phương án gần nhất về mặt cũng dùng cơ chế giới hạn, nhưng nó quá tay: tắt IAM là lập trình viên không tạo được role cho Lambda, không gắn được policy nào cả. Mất hẳn mục tiêu "thử nghiệm nhanh" mà đề nêu ở câu đầu.
• **B. Cấm lập trình viên gắn policy, chuyển hết việc IAM cho đội bảo mật — giải quyết được rủi ro nhưng phá huỷ chính điều đề muốn giữ: mỗi thay đổi quyền phải qua một hàng đợi yêu cầu, và đội bảo mật thành nút thắt cổ chai.
• **D. Tạo SNS topic gửi cảnh báo mỗi khi có policy mới — đây là phát hiện SAU khi việc đã xảy ra, không phải ngăn chặn. Quyền admin đã được cấp và có thể đã bị dùng trước khi ai đó đọc email.

Ghi nhớ

Ba cơ chế giới hạn quyền — bảng phải thuộc: | Cơ chế | Phạm vi | Cấp quyền? | |---|---|---| | Service Control Policy (SCP) | cả tài khoản / OU | ❌ chỉ giới hạn | | Permissions boundary | một IAM user hoặc role | ❌ chỉ giới hạn | | Identity policy | user, group, role | ✅ cấp quyền |

Công thức quyền hiệu lực:

Quyền thật = SCP ∩ Permissions Boundary ∩ Identity Policy ∩ (Resource Policy)
        ↓
    Một Deny ở BẤT KỲ tầng nào cũng thắng

Từ khoá nhận diện:

"developers can attach policies but must not escalate" → permissions boundary "restrict entire account or OU" → SCP "delegate IAM safely" → permissions boundary

Ba trường hợp dùng permissions boundary: | Trường hợp | Chi tiết | |---|---| | Uỷ quyền tạo role cho lập trình viên | ← câu này | | Giới hạn quyền của CI/CD pipeline | | | Sandbox cho môi trường thử nghiệm | |

⚠ Ba điều permissions boundary KHÔNG làm: | Điều | Chi tiết | |---|---| | Không cấp quyền | chỉ giới hạn | | Không áp cho resource-based policy | S3 bucket policy vẫn cấp được | | Không áp cho service-linked role | |

Vế thứ hai là lỗ hổng ít người biết:

Boundary chặn quyền s3:* của role
    → nhưng bucket policy cấp thẳng quyền cho role đó
    → truy cập vẫn thành công
        ↓
    Vì resource-based policy được đánh giá độc lập

Ba phần của một boundary tốt: | Phần | Việc | |---|---| | Allow danh sách dịch vụ cho phép | trần quyền | | Deny thao tác IAM nguy hiểm | | | Bắt buộc role mới cũng mang boundary | chống lách |

Ba thao tác IAM cần chặn để chống leo thang: | Thao tác | Vì sao | |---|---| | iam:PutRolePolicy không kèm boundary | tạo role admin mới | | iam:DeleteRolePermissionsBoundary | tự gỡ boundary của mình | | iam:CreateUser / AttachUserPolicy | tạo danh tính vượt trần |

Vế thứ hai là chỗ hay quên nhất:

{"Effect": "Deny",
 "Action": ["iam:DeleteRolePermissionsBoundary",
            "iam:DeleteUserPermissionsBoundary"],
 "Resource": "*"}

Không chặn dòng này
    → lập trình viên gỡ chính boundary của mình
    → toàn bộ cơ chế vô hiệu

Ba cách kiểm chứng: | Cách | Công cụ | |---|---| | IAM Policy Simulator | thử trước | | IAM Access Analyzer | tìm quyền dư | | CloudTrail | xem thao tác bị từ chối |

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Thử ở tài khoản dev trước | | | Ghi tài liệu vì sao chặn từng thứ | | | Có quy trình xin nới trần | |

Vế cuối quan trọng hơn nhiều người nghĩ:

Boundary quá chặt mà không có đường xin nới
    → lập trình viên tìm cách lách
    → hoặc dùng tài khoản cá nhân
        ↓
    Bảo mật thất bại theo cách tệ nhất

Ba tầng nên dùng cùng nhau: | Tầng | Việc | |---|---| | SCP | trần cho cả tài khoản | | Permissions boundary | trần cho từng role | | Identity policy | quyền thực tế |

Ba dấu hiệu leo thang đặc quyền cần theo dõi: | Dấu hiệu | Chi tiết | |---|---| | Gắn AdministratorAccess | | | Tạo access key cho user khác | | | Sửa trust policy của role | |

Và một lời khuyên: hãy luôn kèm điều kiện iam:PermissionsBoundary vào chính boundary. Không có nó, cơ chế chỉ chặn được người dùng hiện tại — bất kỳ ai tạo được một role mới không boundary đều đi vòng qua toàn bộ hàng rào chỉ bằng hai lệnh CLI.