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

Đáp án

B và C.

• B — Tạo AWS Transit Gateway và gắn cả 25 VPC vào đó; bật route propagation cho mỗi attachment
• C — Tạo transit virtual interface (transit VIF) từ kết nối Direct Connect và liên kết nó với transit gateway

Vì sao đúng

Đề nêu bốn yêu cầu, và hai đáp án giải quyết hai nửa của bài toán: | Yêu cầu | Giải pháp | |---|---| | Kết nối full-mesh giữa 25 VPC | Transit Gateway — định tuyến BẮC CẦU | | Kết nối tới tại chỗ | transit VIF gắn vào TGW | | Mở rộng hiệu quả | TGW nối tới 5.000 VPC | | Bỏ việc duy trì private VIF riêng cho từng VPC | một transit VIF thay cho 25 private VIF |

B — Transit Gateway giải quyết bài toán full-mesh:

VPC peering (cách cũ):
    25 VPC cần 25×24/2 = 300 kết nối peering
    → 300 bộ bảng định tuyến phải duy trì
    → và peering KHÔNG bắc cầu

Transit Gateway:
    25 attachment tới MỘT hub
    → định tuyến BẮC CẦU: mọi VPC nói chuyện với nhau
    → route propagation tự quản lý bảng định tuyến

aws ec2 create-transit-gateway --description "TGW trung tam"   --options '{"DefaultRouteTableAssociation":"enable",
              "DefaultRouteTablePropagation":"enable",
              "AutoAcceptSharedAttachments":"enable"}'

aws ec2 create-transit-gateway-vpc-attachment   --transit-gateway-id tgw-0abc --vpc-id vpc-0001   --subnet-ids subnet-a subnet-b

C — transit VIF thay thế 25 private VIF:

Private VIF:
    → mỗi VIF nối tới MỘT virtual private gateway (một VPC)
    → 25 VPC cần 25 private VIF
    → và có giới hạn số VIF mỗi kết nối Direct Connect

Transit VIF:
    → nối tới Direct Connect gateway
    → DX gateway liên kết với TRANSIT GATEWAY
    → MỘT VIF phục vụ TẤT CẢ VPC gắn vào TGW

aws directconnect create-transit-virtual-interface   --connection-id dxcon-abc   --new-transit-virtual-interface     'virtualInterfaceName=transit-vif,vlan=100,asn=65000,addressFamily=ipv4,
     directConnectGatewayId=<id-dx-gateway>'

aws directconnect create-direct-connect-gateway-association   --direct-connect-gateway-id <id> --gateway-id tgw-0abc

Kiến trúc kết quả:

Trung tâm dữ liệu
    │ Direct Connect
    │   └── transit VIF
    ▼
Direct Connect Gateway
    │
Transit Gateway ──┬── VPC 1
                  ├── VPC 2
                  ├── ...
                  └── VPC 25

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

• **D. Chuyển mỗi private VIF thành liên kết Direct Connect gateway bằng cách gắn virtual private gateway (VGW) vào từng VPC, rồi cấu hình định tuyến giữa các VGW thủ công — đây là phương án gần nhất và Direct Connect gateway với VGW là kiến trúc có thật, nhưng nó KHÔNG cho kết nối giữa các VPC: DX gateway cho phép tại chỗ nói chuyện với nhiều VPC, nhưng các VPC KHÔNG nói chuyện được với nhau qua nó. Và "cấu hình định tuyến giữa các VGW thủ công" không phải cơ chế tồn tại.
• **A. Dùng PrivateLink endpoint tới một service VPC trung tâm — sai mô hình: PrivateLink phơi MỘT DỊCH VỤ theo chiều một hướng, nó không tạo kết nối mạng full-mesh giữa các VPC.
• **E. Tạo Site-to-Site VPN riêng cho từng VPC — đi ngược mục tiêu: 25 kết nối VPN phải quản lý, và VPN chậm hơn cùng kém ổn định hơn Direct Connect. Công ty đã có DX rồi.

Ghi nhớ

Ba loại virtual interface của Direct Connect — bảng phải thuộc: | Loại | Nối tới | Phục vụ | |---|---|---| | Private VIF | virtual private gateway (VGW) | MỘT VPC | | Transit VIF | Direct Connect gateway → TRANSIT GATEWAY | NHIỀU VPC ← câu này | | Public VIF | endpoint công khai của AWS | S3, DynamoDB qua IP công cộng |

Quy tắc: nhiều VPC cần nói chuyện với nhau và với tại chỗ → transit VIF + Transit Gateway.

Ba cách nối tại chỗ với nhiều VPC: | Cách | Kết nối VPC ⟷ VPC | |---|---| | Nhiều private VIF | ❌ VPC không nói chuyện với nhau | | DX gateway + nhiều VGW | ❌ vẫn không | | Transit VIF + Transit Gateway | ✅ CÓ ← câu này |

Đây là điểm phân biệt quan trọng nhất của câu hỏi.

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

Nhiều route table cho phép cách ly:

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

Ba khái niệm của Transit Gateway: | Khái niệm | Việc | |---|---| | Attachment | kết nối tới VPC, VPN, DX gateway, hoặc TGW khác | | Route table | quyết định attachment nào tới được attachment nào | | Association | attachment dùng route table nào | | Propagation | tự đưa route của attachment vào route table |

Route propagation là thứ giảm công vận hành:

Không có propagation:
    → phải thêm route thủ công cho mỗi VPC
    → 25 VPC = 25 route × nhiều route table

Có propagation:
    → TGW tự học CIDR của mỗi VPC
    → tự cập nhật khi VPC thay đổi

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

Với 25 VPC:

25 × 36 USD = 900 USD/tháng chỉ riêng phí attachment
    ↓
    → Cân nhắc hợp nhất VPC hoặc dùng VPC sharing
      cho các đội không cần cách ly mạng

Ba yêu cầu của transit VIF: | Yêu cầu | Chi tiết | |---|---| | Kết nối DX phải là DEDICATED hoặc HOSTED phù hợp | kiểm tra loại kết nối | | Một kết nối DX chỉ có MỘT transit VIF | | | Cần Direct Connect gateway | không gắn thẳng vào TGW |

Ba lưu ý về Direct Connect gateway: | Lưu ý | Chi tiết | |---|---| | Là tài nguyên TOÀN CẦU | dùng cho mọi Region | | Liên kết được với VGW hoặc TGW | không trộn cả hai trong cùng DX gateway | | Không cho VPC nói chuyện với nhau | khi dùng với VGW |

Ba biện pháp cho sẵn sàng cao của Direct Connect: | Biện pháp | Chi tiết | |---|---| | Hai kết nối DX ở hai vị trí khác nhau | chống hỏng một điểm | | VPN dự phòng qua Internet | rẻ, tự chuyển đổi qua BGP | | Direct Connect SLA | phụ thuộc cấu hình dư thừa |

Ba lưu ý về CIDR: | Lưu ý | Chi tiết | |---|---| | CIDR các VPC KHÔNG được chồng lấn | ← đề đã đảm bảo | | Lập kế hoạch dải IP từ đầu | mở rộng sau rất khó | | Ghi tài liệu bản đồ CIDR | 25 VPC là nhiều để nhớ |

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

Và một lời khuyên về lộ trình chuyển đổi: hãy dựng Transit Gateway và transit VIF song song với private VIF hiện có, chuyển từng VPC một, rồi mới gỡ private VIF cũ. Chuyển cả 25 VPC cùng lúc là rủi ro không cần thiết — và với logistics quốc gia, một sự cố mạng ảnh hưởng tới việc giao hàng thật.

Đáp án

B — Dùng AWS DataSync để tự động hoá và tăng tốc việc truyền dữ liệu trực tuyến tới các dịch vụ lưu trữ đó.

Vì sao đúng

Đề nêu ba đích và bốn yêu cầu, và DataSync là dịch vụ được thiết kế đúng cho bài toán này: | Yêu cầu | Cơ chế | |---|---| | Chuyển tới S3, EFS VÀ FSx for Windows | DataSync hỗ trợ CẢ BA | | DỄ và NHANH | nhanh hơn công cụ mã nguồn mở tới 10 lần | | TRỰC TUYẾN (online) | qua Direct Connect hoặc Internet | | Tiết kiệm chi phí | trả theo GB chuyển |

Vì sao DataSync là câu trả lời:

AWS DataSync:
    ✓ tối ưu giao thức truyền, nén, song song hoá
    ✓ TỰ KIỂM TRA TÍNH TOÀN VẸN dữ liệu
    ✓ lên lịch, báo cáo, tự thử lại
    ✓ GIỮ metadata (quyền, timestamp, ACL của NTFS)
        ↓
    Không phải viết script nào

Các nguồn và đích DataSync hỗ trợ: | Nguồn | Đích | |---|---| | NFS, SMB tại chỗ | S3 | | HDFS | EFS | | Object storage tự quản lý | FSx (Windows, Lustre, ONTAP, OpenZFS) | | Dịch vụ AWS | dịch vụ AWS khác |

Ba bước triển khai:

# ① Cài agent (máy ảo tại chỗ hoặc EC2)
# ② Tạo vị trí nguồn và đích
aws datasync create-location-smb   --server-hostname 10.100.0.50 --subdirectory /du-lieu   --user quan-tri --password '<mat-khau>' --domain congty.local   --agent-arns <arn-agent>

aws datasync create-location-fsx-windows   --fsx-filesystem-arn <arn-fsx> --security-group-arns <arn-sg>   --user quan-tri --password '<mat-khau>' --domain congty.local

# ③ Tạo task có lịch
aws datasync create-task   --source-location-arn <arn-smb> --destination-location-arn <arn-fsx>   --schedule ScheduleExpression="cron(0 2 * * ? *)"   --options VerifyMode=ONLY_FILES_TRANSFERRED,PreserveDeletedFiles=PRESERVE

Và giữ được metadata là điểm quan trọng với dữ liệu dược phẩm:

Sao chép bằng công cụ thường:
    → mất ACL, mất timestamp gốc
    → mất khả năng chứng minh tính toàn vẹn

DataSync:
    → giữ nguyên quyền POSIX hoặc ACL của NTFS
    → giữ timestamp
    → so checksum nguồn và đích

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

• **A. Dùng AWS Transfer Family — đây là phương án gần nhất vì cũng là dịch vụ truyền tệp được quản lý, nhưng nó phục vụ chiều ngược lại: Transfer Family phơi ra endpoint SFTP, FTPS, FTP để bên ngoài ĐẨY tệp vào AWS. Nó không phải công cụ để bạn CHỦ ĐỘNG KÉO khối lượng lớn dữ liệu từ trung tâm dữ liệu của mình lên.
• **C. Dùng File Gateway — sai mục đích: File Gateway phục vụ truy cập LIÊN TỤC từ tại chỗ tới dữ liệu ở S3 với cache cục bộ. Nó không phải công cụ di chuyển dữ liệu, và chỉ hỗ trợ S3 làm đích.
• **D. Dùng Snowball Edge Storage Optimized — không phải "trực tuyến": Snowball là thiết bị vật lý được vận chuyển. Đề hỏi rõ giải pháp online data transfer.

Ghi nhớ

Bốn công cụ di chuyển dữ liệu — bảng phải thuộc: | Công cụ | Việc | Trực tuyến | |---|---|---| | AWS DataSync | DI CHUYỂN và đồng bộ định kỳ | ✅ ← câu này | | Storage Gateway | truy cập LIÊN TỤC từ tại chỗ | ✅ | | AWS Transfer Family | endpoint SFTP/FTPS cho bên ngoài đẩy vào | ✅ | | Snow Family | khối lượng rất lớn, băng thông kém | ❌ vật lý |

Từ khoá nhận diện:

"migrate", "sync", "automate and accelerate online transfer" → DataSync "continuous access with local cache" → Storage Gateway "vendors upload via SFTP" → Transfer Family "petabytes, limited bandwidth" → Snow Family

Ba lợi ích của DataSync: | Lợi ích | Chi tiết | |---|---| | Nhanh hơn công cụ mã nguồn mở tới 10 lần | giao thức tối ưu | | Tự KIỂM TRA TÍNH TOÀN VẸN | so checksum | | Lên lịch, báo cáo, tự thử lại | không phải viết script |

Ba tuỳ chọn quan trọng của task: | Tuỳ chọn | Việc | |---|---| | VerifyMode | ONLY_FILES_TRANSFERRED (nhanh) hoặc POINT_IN_TIME_CONSISTENT (kỹ) | | PreserveDeletedFiles | giữ hay xoá tệp đã bị xoá ở nguồn | | TransferMode | CHANGED (chỉ tệp đổi) hoặc ALL | | BytesPerSecond | giới hạn băng thông |

Giới hạn băng thông rất quan trọng:

--options BytesPerSecond=104857600   # 100 MB/giây

Không giới hạn:
    → DataSync chiếm hết đường truyền
    → ảnh hưởng ứng dụng khác trong giờ làm việc

Ba lưu ý về DataSync agent: | Lưu ý | Chi tiết | |---|---| | Chạy dưới dạng máy ảo tại chỗ | VMware, Hyper-V, KVM, hoặc EC2 | | Cần tối thiểu 4 vCPU, 32 GB RAM | | | KHÔNG cần agent khi chuyển giữa hai dịch vụ AWS | |

Dòng cuối đáng biết: chuyển từ S3 sang EFS trong cùng tài khoản không cần agent nào.

Ba lựa chọn kết nối cho DataSync: | Kết nối | Chi tiết | |---|---| | Internet công cộng | đơn giản, dùng TLS | | Direct Connect với public VIF | băng thông ổn định | | Direct Connect với private VIF + interface endpoint | riêng tư hoàn toàn |

Ba cách theo dõi: | Cách | Việc | |---|---| | CloudWatch metric | BytesTransferred, FilesTransferred | | Task execution report | liệt kê tệp bị bỏ qua và lý do | | EventBridge event | cảnh báo khi task thất bại |

aws datasync describe-task-execution --task-execution-arn <arn>

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | DataSync | ~0,0125 USD/GB chuyển | | Truyền dữ liệu vào AWS | MIỄN PHÍ | | Lưu trữ ở đích | theo dịch vụ |

Ba lưu ý khi chuyển tới FSx for Windows: | Lưu ý | Chi tiết | |---|---| | DataSync GIỮ ACL của NTFS | quan trọng nhất | | Cần thông tin đăng nhập AD | cho cả nguồn và đích | | Security group cho phép SMB (445) | |

Ba bước kiểm chứng trước khi cắt chuyển: | Bước | Chi tiết | |---|---| | Chạy với VerifyMode kỹ một lần | xác nhận dữ liệu khớp | | So số tệp và tổng dung lượng | nguồn và đích | | Rút ngắn chu kỳ đồng bộ trước ngày cắt | giảm khoảng lệch |

Và với khối lượng rất lớn, kết hợp Snow Family và DataSync:

① Snowball chuyển khối lượng ban đầu (hàng trăm TB)
② DataSync đồng bộ phần thay đổi cho tới ngày cắt chuyển
        ↓
    Nhanh hơn nhiều so với chỉ dùng một trong hai

Ba yêu cầu tuân thủ cho dữ liệu dược phẩm: | Yêu cầu | Chi tiết | |---|---| | Mã hoá in transit | DataSync dùng TLS mặc định | | Mã hoá at rest ở đích | KMS | | Nhật ký đầy đủ | CloudWatch Logs và task report |

Và một lời khuyên: hãy bật task execution report ghi ra S3. Nó liệt kê từng tệp được chuyển, bị bỏ qua hay thất bại — và với dữ liệu dược phẩm cần chứng minh tính đầy đủ trước cơ quan quản lý, báo cáo đó là bằng chứng duy nhất bạn có.

Đáp án

B — Dùng Volume Gateway ở chế độ CACHED để giữ các log truy cập thường xuyên ở địa phương cho độ trễ thấp, trong khi toàn bộ volume với mọi log được lưu trong S3.

Vì sao đúng

Đề mô tả chính xác định nghĩa của cached volume:

"only the MOST FREQUENTLY ACCESSED logs available as CACHED data locally
 while BACKING UP ALL logs on Amazon S3"
    ↓
    Dữ liệu CHÍNH ở S3
    Cache cục bộ chỉ giữ phần NÓNG
        ↓
    Đó chính là chế độ CACHED

Hai chế độ của Volume Gateway — bảng phân biệt cốt lõi: | | Cached volume | Stored volume | |---|---|---| | Dữ liệu ĐẦY ĐỦ nằm ở | S3 | TẠI CHỖ | | Tại chỗ giữ gì | CHỈ cache dữ liệu nóng | toàn bộ dữ liệu | | S3 giữ gì | toàn bộ | bản sao lưu (EBS snapshot) | | Dung lượng tối đa | 1 PB | 512 TB | | Phù hợp | mở rộng dung lượng vô hạn | độ trễ thấp cho mọi dữ liệu |

Và đề mô tả đúng vế của cached:

Cached volume:
    → đĩa tại chỗ chỉ cần đủ chứa dữ liệu NÓNG
    → log cũ nằm ở S3, đọc khi cần
        ↓
    Tiết kiệm dung lượng tại chỗ rất nhiều
    Log lưu trữ tăng vô hạn mà không phải mua đĩa

Cấu hình:

aws storagegateway create-cachedi-scsi-volume   --gateway-arn <arn-gateway>   --volume-size-in-bytes 5497558138880   --target-name log-truy-cap   --network-interface-id 10.100.0.50   --client-token $(uuidgen)

Và máy chủ tại chỗ gắn volume qua iSCSI như ổ đĩa bình thường.

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

• **A. Dùng Volume Gateway ở chế độ STORED — đây là phương án gần nhất và là bẫy chính: stored volume giữ TOÀN BỘ dữ liệu tại chỗ và chỉ sao lưu lên S3. Đề nói rõ chỉ muốn giữ phần truy cập thường xuyên ở địa phương — đó là cached, không phải stored.
• **C. Dùng AWS Direct Connect để giữ log ở địa phương — sai loại dịch vụ: Direct Connect là kết nối mạng chuyên dụng, nó không lưu trữ hay đệm dữ liệu gì.
• **D. Dùng Snowball Edge Storage Optimized — sai mục đích: Snowball là thiết bị vận chuyển dữ liệu một lần, không phải giải pháp lưu trữ lai chạy liên tục.

Ghi nhớ

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

Từ khoá nhận diện:

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

Hai chế độ Volume Gateway — nhắc lại vì đây là điểm của câu hỏi:

CACHED:
    Dữ liệu chính ở S3, cache nóng tại chỗ
    → dung lượng "vô hạn", đĩa tại chỗ nhỏ
    → độ trễ thấp cho dữ liệu nóng

STORED:
    Dữ liệu chính TẠI CHỖ, sao lưu lên S3
    → độ trễ thấp cho MỌI dữ liệu
    → nhưng phải có đủ đĩa tại chỗ

Quy tắc chọn:

Muốn mở rộng dung lượng vượt đĩa tại chỗ → cached Cần độ trễ thấp cho MỌI dữ liệu, đã có đủ đĩa → stored Khôi phục thảm hoạ (dữ liệu chính ở tại chỗ) → stored

Ba thành phần cần cấu hình cho Volume Gateway: | Thành phần | Việc | |---|---| | Đĩa CACHE | giữ dữ liệu nóng — kích thước quyết định trải nghiệm | | Upload buffer | vùng đệm chờ đẩy lên S3 | | Volume | dung lượng logic mà ứng dụng thấy |

Kích thước cache là yếu tố quyết định:

Cache nhỏ hơn tập dữ liệu nóng
    → mọi lần đọc phải lấy từ S3
    → độ trễ cao, mất hết lợi ích của mô hình
        ↓
    AWS khuyến nghị cache ít nhất bằng 20% dung lượng volume

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitPercent | thấp nghĩa là cache quá nhỏ | | CachePercentUsed | gần đầy thì cần mở rộng | | UploadBufferPercentUsed | đầy sẽ CHẶN việc ghi |

Dòng cuối là sự cố nghiêm trọng:

Upload buffer đầy:
    → gateway không nhận ghi mới
    → ứng dụng bị treo
        ↓
    Nguyên nhân thường là băng thông lên AWS không đủ

Ba đặc điểm của Volume Gateway: | Đặc điểm | Chi tiết | |---|---| | Sao lưu dạng EBS snapshot | khôi phục thành EBS volume trên AWS được | | Lên lịch snapshot tự động | | | Volume tối đa 32 TB (cached) hoặc 16 TB (stored) | |

Và khả năng khôi phục thành EBS volume rất hữu ích:

Trung tâm dữ liệu gặp sự cố
    → khôi phục snapshot thành EBS volume trên AWS
    → gắn vào EC2 và chạy tiếp
        ↓
    Volume Gateway vừa là lưu trữ vừa là cơ chế khôi phục thảm hoạ

Ba yêu cầu triển khai: | Yêu cầu | Chi tiết | |---|---| | Nền tảng chạy gateway | VMware, Hyper-V, KVM, EC2, hoặc thiết bị phần cứng | | Đĩa cho cache và upload buffer | | | Băng thông ổn định lên AWS | |

Ba cách tối ưu băng thông: | Cách | Chi tiết | |---|---| | Giới hạn băng thông theo lịch | không nghẽn giờ làm việc | | Direct Connect | băng thông ổn định | | Nén dữ liệu trước khi ghi | ít byte hơn |

aws storagegateway update-bandwidth-rate-limit   --gateway-arn <arn>   --average-upload-rate-limit-in-bits-per-sec 100000000

Ba lựa chọn lưu trữ lai — chọn đúng: | Nhu cầu | Dịch vụ | |---|---| | Ổ đĩa KHỐI với cache | Volume Gateway ← câu này | | Chia sẻ TỆP với cache | File Gateway | | Di chuyển dữ liệu một lần hoặc định kỳ | DataSync |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ S3 | theo GB thực tế | | Snapshot | tăng dần, chỉ lưu khối đã đổi | | Truyền dữ liệu ra AWS | miễn phí chiều vào |

Và lifecycle rule cho snapshot:

aws dlm create-lifecycle-policy --description "Don snapshot cu"   --state ENABLED --execution-role-arn <arn>   --policy-details file://chinh-sach.json

Ba lưu ý về sẵn sàng: | Lưu ý | Chi tiết | |---|---| | Gateway là điểm hỏng duy nhất | cân nhắc dư thừa | | Chạy trên VMware HA nếu có | | | Giám sát trạng thái gateway | CloudWatch alarm |

Và một lời khuyên: hãy đặt alarm cho CacheHitPercent dưới 80%. Với kho log truy cập, mẫu truy cập thay đổi theo thời gian — và khi tỷ lệ trúng cache tụt xuống, đó là tín hiệu cần mở rộng đĩa cache trước khi người dùng bắt đầu phàn nàn về độ trễ.

Đáp án

C — Dùng SQS long polling để nhận thông điệp từ hàng đợi.

Vì sao đúng

Đề hỏi cách giảm chi phí SQS, và long polling giải quyết đúng nguồn lãng phí lớn nhất.

SQS tính phí theo SỐ REQUEST, không theo số thông điệp
    ↓
Short polling (mặc định):
    → consumer hỏi liên tục
    → phần lớn lần hỏi trả về RỖNG
    → mỗi lần hỏi rỗng VẪN TÍNH TIỀN
        ↓
    Hàng đợi ít thông điệp → gần như toàn request lãng phí

Long polling loại bỏ điều đó:

Long polling:
    → consumer hỏi và CHỜ tới 20 giây
    → SQS chỉ trả lời khi CÓ thông điệp, hoặc khi hết thời gian chờ
        ↓
    Một request "che" được 20 giây thay vì trả về rỗng ngay
    → giảm số request tới hàng chục lần

Ước lượng cho một consumer:

Short polling, hỏi mỗi 100ms:
    → 10 request/giây × 86.400 giây = 864.000 request/ngày

Long polling 20 giây, hàng đợi rỗng:
    → 3 request/phút × 1.440 phút = 4.320 request/ngày
        ↓
    Giảm khoảng 200 lần

Bật long polling ở mức hàng đợi:

aws sqs set-queue-attributes --queue-url <url>   --attributes ReceiveMessageWaitTimeSeconds=20

Hoặc ở từng lời gọi:

sqs.receive_message(QueueUrl=url, WaitTimeSeconds=20, MaxNumberOfMessages=10)

Và long polling còn giảm ĐỘ TRỄ:

Short polling: thông điệp đến ngay sau khi hỏi
    → phải chờ tới lần hỏi tiếp theo

Long polling: consumer đang CHỜ SẴN
    → thông điệp đến là nhận ngay

Vừa rẻ hơn vừa nhanh hơn — đó là lý do AWS khuyến nghị bật cho mọi hàng đợi.

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

• **A. Dùng SQS short polling — đây là phương án gần nhất và là chế độ MẶC ĐỊNH, nhưng nó đi ngược mục tiêu: short polling sinh nhiều request rỗng, làm tăng chi phí. Đề hỏi cách giảm chi phí.
• **B. Dùng visibility timeout để nhận thông điệp — nhầm chức năng: visibility timeout quyết định bao lâu một thông điệp bị ẩn sau khi được nhận, để consumer khác không xử lý trùng. Nó không liên quan tới việc nhận thông điệp hay chi phí.
• **D. Dùng message timer để nhận thông điệp — cũng nhầm chức năng: message timer (DelaySeconds) trì hoãn thời điểm thông điệp hiện ra trong hàng đợi. Không liên quan tới chi phí polling.

Ghi nhớ

Short polling và long polling — bảng phải thuộc: | | Short polling | Long polling | |---|---|---| | WaitTimeSeconds | 0 (mặc định) | 1–20 | | Trả về khi rỗng | NGAY | chờ tới hết thời gian | | Số request | rất nhiều | ít hơn hàng chục lần | | Chi phí | cao | thấp | | Độ trễ | phụ thuộc chu kỳ hỏi | thấp hơn |

AWS khuyến nghị BẬT long polling cho mọi hàng đợi.

Ba tham số dễ nhầm của SQS: | Tham số | Việc | |---|---| | ReceiveMessageWaitTimeSeconds | long polling — chờ bao lâu khi hàng đợi rỗng | | VisibilityTimeout | thông điệp bị ẩn bao lâu sau khi được nhận | | DelaySeconds | thông điệp bị trì hoãn bao lâu TRƯỚC KHI hiện ra | | MessageRetentionPeriod | giữ thông điệp bao lâu (1 phút – 14 ngày) |

Ba tham số này là ba giai đoạn khác nhau của vòng đời thông điệp:

Gửi → [DelaySeconds] → hiện trong hàng đợi
    → consumer nhận → [VisibilityTimeout] ẩn với consumer khác
    → xử lý xong → xoá

[ReceiveMessageWaitTimeSeconds] áp cho lúc consumer HỎI

Ba nguồn chi phí của SQS: | Nguồn | Chi tiết | |---|---| | Số REQUEST | ~0,40 USD/triệu (Standard), ~0,50 USD/triệu (FIFO) | | Truyền dữ liệu ra Internet | nếu consumer ngoài AWS | | — | KHÔNG tính phí lưu trữ thông điệp |

Ba cách giảm chi phí SQS: | Cách | Tiết kiệm | |---|---| | Long polling | giảm request rỗng — lớn nhất ← câu này | | Gom lô (batch) | 1 request gửi/nhận/xoá tới 10 thông điệp | | Giảm số consumer nhàn rỗi | ít consumer hơn khi hàng đợi rỗng |

Gom lô cũng rất hiệu quả:

sqs.send_message_batch(QueueUrl=url, Entries=[...])   # tối đa 10
sqs.receive_message(QueueUrl=url, MaxNumberOfMessages=10, WaitTimeSeconds=20)
sqs.delete_message_batch(QueueUrl=url, Entries=[...])  # tối đa 10

Không gom lô: 100 thông điệp = 300 request (gửi + nhận + xoá)
Gom lô 10:    100 thông điệp = 30 request
        ↓
    Giảm 10 lần

Ba lưu ý về visibility timeout: | Lưu ý | Chi tiết | |---|---| | Phải DÀI HƠN thời gian xử lý | nếu không sẽ xử lý hai lần | | Mặc định 30 giây | tối đa 12 giờ | | Gia hạn được khi đang xử lý | ChangeMessageVisibility |

Với Lambda, AWS khuyến nghị visibility timeout ≥ 6 lần timeout của hàm.

Ba trường hợp dùng DelaySeconds: | Trường hợp | Chi tiết | |---|---| | Chờ hệ thống khác sẵn sàng | ví dụ chờ replica đồng bộ | | Thử lại sau một khoảng | backoff | | Lên lịch xử lý muộn | tối đa 15 phút |

SQS Standard và FIFO: | | Standard | FIFO | |---|---|---| | Thông lượng | gần như không giới hạn | 300/giây (3.000 gom lô), high-throughput tới 70.000 | | Thứ tự | không đảm bảo | ✅ trong message group | | Trùng lặp | có thể | không | | Giá | rẻ hơn | đắt hơn ~25% |

Ba cấu hình nên có cho mọi hàng đợi: | Cấu hình | Giá trị | |---|---| | ReceiveMessageWaitTimeSeconds | 20 | | Dead-letter queue | sau 3–5 lần thử | | VisibilityTimeout | dài hơn thời gian xử lý |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | tăng dần = xử lý không kịp | | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | NumberOfEmptyReceives | cao nghĩa là chưa bật long polling |

Metric cuối là chỉ báo trực tiếp cho vấn đề của câu này — nó đếm số lần polling trả về rỗng.

Ba lưu ý khi dùng Lambda với SQS: | Lưu ý | Chi tiết | |---|---| | Lambda tự quản lý polling | không phải cấu hình long polling thủ công | | Không tính phí request polling của Lambda | AWS lo phần đó | | Đặt BatchSize và MaximumBatchingWindowInSeconds | gom lô để giảm số lần gọi |

Với Lambda event source mapping, phần lớn tối ưu polling đã được AWS xử lý — vấn đề của câu này áp cho consumer tự viết (EC2, ECS, ứng dụng tại chỗ).

Và một lời khuyên: hãy xem metric NumberOfEmptyReceives để biết mình đang lãng phí bao nhiêu. Với hệ thống ngân hàng có nhiều hàng đợi ít lưu lượng, con số đó thường cho thấy phần lớn hoá đơn SQS đến từ việc hỏi những hàng đợi trống rỗng — và bật long polling là thay đổi một dòng cấu hình.

Đáp án

C — Dùng target tracking scaling policy dựa trên một metric tuỳ chỉnh của hàng đợi SQS.

Vì sao đúng

Đề mô tả vấn đề: đỉnh đơn hàng đột ngột làm hiệu năng giảm, và giải pháp phải co giãn theo độ sâu hàng đợi chứ không theo CPU.

Co giãn theo CPU:
    → CPU chỉ tăng SAU KHI đơn hàng đã tồn đọng
    → phản ứng muộn

Co giãn theo hàng đợi:
    → thấy ngay đơn hàng đang chờ
    → phản ứng đúng lúc

Và vì sao target tracking chứ không phải các loại khác: | Loại policy | Bạn khai gì | |---|---| | Target tracking | MỘT giá trị mục tiêu — AWS tự lo phần còn lại | | Step scaling | ngưỡng + nhiều bậc điều chỉnh | | Simple scaling | ngưỡng + một hành động, có cooldown | | Scheduled scaling | thời điểm cố định |

Metric tuỳ chỉnh nên dùng là "backlog mỗi instance":

Backlog mỗi instance = ApproximateNumberOfMessagesVisible ÷ số instance đang chạy
    ↓
    Đây là con số ỔN ĐỊNH để đặt mục tiêu

Vì sao không dùng thẳng số thông điệp:

ApproximateNumberOfMessagesVisible = 10.000
    → với 10 instance thì mỗi máy gánh 1.000 — quá tải
    → với 100 instance thì mỗi máy gánh 100 — bình thường
        ↓
    Con số tuyệt đối KHÔNG cho biết có cần thêm máy không
    → phải chia cho số instance

Cách tính giá trị mục tiêu:

Chấp nhận đơn hàng chờ tối đa 5 phút
Mỗi instance xử lý 10 đơn/phút
    ↓
    Backlog mỗi instance mục tiêu = 5 × 10 = 50

Đẩy metric tuỳ chỉnh:

aws cloudwatch put-metric-data --namespace ThuongMai   --metric-name BacklogMoiInstance --value 47

Và tạo policy:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-xu-ly-don   --policy-name giu-backlog-50 --policy-type TargetTrackingScaling   --estimated-instance-warmup 300   --target-tracking-configuration '{
    "TargetValue": 50.0,
    "CustomizedMetricSpecification": {
      "MetricName": "BacklogMoiInstance",
      "Namespace": "ThuongMai", "Statistic": "Average"}}'

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

• **A. Dùng step scaling policy dựa trên metric tuỳ chỉnh của SQS — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó đòi nhiều cấu hình hơn: bạn phải tự định nghĩa các ngưỡng và bậc điều chỉnh (vượt 100 thì thêm 2 máy, vượt 500 thì thêm 5 máy...). Target tracking chỉ cần một con số và AWS tự tính toán, đồng thời có cơ chế chống dao động dựng sẵn.
• **B. Dùng simple scaling policy — loại policy CŨ: nó chỉ có một hành động và phải chờ hết cooldown trước khi phản ứng tiếp, nên rất chậm với đỉnh tải đột ngột.
• **D. Dùng scheduled scaling policy — sai loại tải: scheduled dành cho tải biết trước thời điểm. Đề nói "sudden spike in orders" — đột ngột và không đoán trước.

Ghi nhớ

Năm loại scaling policy — bảng phải thuộc: | Loại | Bạn khai gì | Đặc điểm | |---|---|---| | Target tracking | MỘT giá trị mục tiêu | đơn giản nhất, chống dao động sẵn ← câu này | | Step scaling | ngưỡng + các bậc | kiểm soát chi tiết | | Simple scaling | ngưỡng + một hành động | cũ, chậm vì cooldown | | Scheduled scaling | thời điểm và dung lượng | tải biết trước theo giờ | | Predictive scaling | metric để dự báo | học máy, mở rộng TRƯỚC |

Từ khoá nhận diện:

"maintain metric at target value", "sudden spike", "simplest" → target tracking "set of adjustments", "different actions at different thresholds" → step scaling "at a specific time" → scheduled scaling "recurring daily pattern, forecast" → predictive scaling

Ba metric để co giãn theo hàng đợi: | Metric | Đặc điểm | |---|---| | Backlog mỗi instance (tuỳ chỉnh) | chuẩn xác nhất cho target tracking | | ApproximateNumberOfMessagesVisible | con số tuyệt đối, dùng cho step scaling | | ApproximateAgeOfOldestMessage | cảnh báo khi xử lý không kịp |

Công thức backlog mỗi instance — nên thuộc:

Backlog mỗi instance = số thông điệp chờ ÷ số instance InService

Giá trị mục tiêu = (thời gian chờ chấp nhận được) × (tốc độ xử lý mỗi instance)

Và cách đẩy metric tự động:

EventBridge Scheduler (mỗi phút)
    → Lambda:
        ① lấy ApproximateNumberOfMessagesVisible từ SQS
        ② lấy số instance InService từ ASG
        ③ chia và đẩy metric tuỳ chỉnh lên CloudWatch

Ba tham số quan trọng của target tracking: | Tham số | Việc | |---|---| | EstimatedInstanceWarmup | bỏ qua instance mới khi tính metric cho tới khi sẵn sàng | | DisableScaleIn | chỉ mở rộng, không thu hẹp | | TargetValue | giá trị cần giữ |

EstimatedInstanceWarmup là tham số quan trọng nhất:

Không đặt hoặc quá ngắn:
    → instance mới chưa xử lý được đã bị tính vào metric
    → backlog mỗi instance vẫn cao → ASG thêm tiếp
    → MỞ RỘNG QUÁ MỨC rồi thu hẹp ồ ạt

Ba hành vi dựng sẵn của target tracking: | Hành vi | Chi tiết | |---|---| | Mở rộng NHANH, thu hẹp THẬN TRỌNG | tránh cắt năng lực quá tay | | Tự tạo và quản lý CloudWatch alarm | không phải làm thủ công | | Chống dao động | không thêm bớt liên tục quanh ngưỡng |

Ba cấu hình ASG khác cần đúng: | Cấu hình | Giá trị nên dùng | |---|---| | HealthCheckType | ELB nếu có load balancer | | MinSize | đủ chịu tải nền | | Trải nhiều AZ | chịu lỗi |

Ba cách bổ sung để xử lý đỉnh tải: | Cách | Chi tiết | |---|---| | Warm pool | giữ sẵn máy đã cấu hình ở trạng thái Stopped | | AMI dựng sẵn | rút ngắn thời gian khởi động | | Scheduled scaling cho sự kiện biết trước | ví dụ đợt khuyến mãi |

Warm pool rất phù hợp với thương mại điện tử:

aws autoscaling put-warm-pool --auto-scaling-group-name asg-xu-ly-don   --min-size 5 --pool-state Stopped

Máy trong warm pool đã cấu hình xong
    → chuyển sang InService trong vài chục giây
    → thay vì vài phút khởi động từ đầu

Ba metric cần đặt alarm: | Metric | Ngưỡng | |---|---| | ApproximateAgeOfOldestMessage | vượt SLA xử lý đơn hàng | | Số thông điệp trong DLQ | > 0 | | GroupInServiceInstances | chạm MaxSize |

Dòng cuối quan trọng: nếu ASG chạm MaxSize mà backlog vẫn tăng, target tracking không giúp được gì thêm — cần nâng trần.

Ba lưu ý khi thiết kế hệ thống xử lý đơn hàng: | Lưu ý | Chi tiết | |---|---| | Visibility timeout dài hơn thời gian xử lý | tránh xử lý trùng | | Idempotency ở tầng nghiệp vụ | khoá UNIQUE trên mã đơn hàng | | Dead-letter queue | đơn hỏng không kẹt mãi |

Dòng giữa rất quan trọng với đơn hàng — xử lý trùng nghĩa là tính tiền khách hàng hai lần.

Và một lời khuyên: hãy đặt alarm cho ApproximateAgeOfOldestMessage song song với việc co giãn. Target tracking giữ backlog ở mức mục tiêu, nhưng nếu tốc độ đơn hàng vượt xa khả năng mở rộng, tuổi thông điệp cũ nhất là chỉ báo trực tiếp cho biết khách hàng đang phải chờ bao lâu.

Đáp án

A — Tạo virtual private gateway (VGW) ở phía AWS và Customer Gateway ở phía tại chỗ của VPN.

Vì sao đúng

Đây là cấu hình chuẩn và duy nhất đúng của AWS Site-to-Site VPN:

Phía AWS:      Virtual Private Gateway (VGW)
                   │
                   │ hai đường hầm IPsec qua Internet
                   │
Phía tại chỗ:  Customer Gateway (CGW)

Hai thành phần và vai trò: | Thành phần | Là gì | Ở đâu | |---|---|---| | Virtual Private Gateway (VGW) | tài nguyên AWS, gắn vào VPC | phía AWS | | Customer Gateway (CGW) | đại diện cho thiết bị VPN của bạn | phía tại chỗ |

Lưu ý về Customer Gateway:

CGW trong AWS là một ĐỐI TƯỢNG CẤU HÌNH
    → nó mô tả thiết bị VPN thật của bạn (IP công cộng, BGP ASN)
    → thiết bị VPN THẬT nằm ở trung tâm dữ liệu của bạn
        ↓
    "Tạo CGW ở phía tại chỗ" nghĩa là khai báo thiết bị đó

Ba bước thiết lập:

# ① Tạo VGW và gắn vào VPC
aws ec2 create-vpn-gateway --type ipsec.1 --amazon-side-asn 64512
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-0abc --vpc-id vpc-0abc

# ② Khai báo thiết bị VPN tại chỗ
aws ec2 create-customer-gateway --type ipsec.1   --public-ip 203.0.113.10 --bgp-asn 65000

# ③ Tạo kết nối VPN
aws ec2 create-vpn-connection --type ipsec.1   --customer-gateway-id cgw-0abc --vpn-gateway-id vgw-0abc   --options '{"StaticRoutesOnly":false}'

Và AWS tạo HAI đường hầm cho mỗi kết nối VPN:

Mỗi VPN connection = 2 IPsec tunnel
    → hai endpoint khác nhau ở phía AWS
    → cho dư thừa khi AWS bảo trì một endpoint
        ↓
    Nên cấu hình CẢ HAI trên thiết bị tại chỗ

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

• **B. VGW ở phía tại chỗ và Customer Gateway ở phía AWS — đây là phương án gần nhất và là bẫy chính: nó nêu đúng hai thành phần nhưng đảo ngược vị trí. VGW là tài nguyên AWS gắn vào VPC; CGW đại diện cho thiết bị của khách hàng.
• **C. VGW ở CẢ HAI phía — không đúng: VGW chỉ tồn tại ở phía AWS.
• **D. Customer Gateway ở CẢ HAI phía — cùng lỗi ở chiều ngược lại.

Ghi nhớ

Ba thành phần của AWS Site-to-Site VPN: | Thành phần | Vai trò | |---|---| | Virtual Private Gateway (VGW) | endpoint VPN phía AWS, gắn vào MỘT VPC | | Transit Gateway | thay VGW khi cần nối NHIỀU VPC | | Customer Gateway (CGW) | khai báo thiết bị VPN tại chỗ | | VPN connection | hai đường hầm IPsec giữa hai bên |

VGW và Transit Gateway — chọn cái nào: | | VGW | Transit Gateway | |---|---|---| | Số VPC | MỘT | nhiều (tới 5.000) | | Định tuyến bắc cầu | ❌ | ✅ | | Chi phí | miễn phí (chỉ trả VPN connection) | theo giờ mỗi attachment | | Phù hợp | một VPC | kiến trúc nhiều VPC |

Hai chế độ định tuyến: | Chế độ | Chi tiết | |---|---| | Static routing | khai tay dải IP của mỗi bên | | Dynamic routing (BGP) | tự học route, tự chuyển đổi — khuyến nghị |

BGP là lựa chọn tốt hơn:

BGP:
    ✓ tự học dải IP mới ở hai bên
    ✓ tự chuyển sang đường hầm còn lại khi một cái hỏng
    ✓ cần thiết cho cấu hình dư thừa

Ba yêu cầu để bật route propagation:

aws ec2 enable-vgw-route-propagation   --route-table-id rtb-0abc --gateway-id vgw-0abc

Không bật thì phải thêm route thủ công vào bảng định tuyến của VPC.

Ba thông tin cần cho Customer Gateway: | Thông tin | Chi tiết | |---|---| | IP công cộng TĨNH của thiết bị VPN | hoặc tên miền | | BGP ASN | nếu dùng định tuyến động | | Loại thiết bị | để AWS sinh tệp cấu hình mẫu |

Và AWS sinh sẵn tệp cấu hình cho thiết bị của bạn:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0abc   --query 'VpnConnections[].CustomerGatewayConfiguration' --output text

Nó chứa khoá chia sẻ trước, IP endpoint, tham số IPsec — chỉ cần áp vào thiết bị.

Ba đặc điểm của Site-to-Site VPN: | Đặc điểm | Chi tiết | |---|---| | Hai đường hầm IPsec | dư thừa ở phía AWS | | Băng thông ~1,25 Gbps mỗi đường hầm | | | Chạy qua Internet công cộng | băng thông và độ trễ không đảm bảo |

VPN và Direct Connect — bảng phân biệt: | | Site-to-Site VPN | Direct Connect | |---|---|---| | Đường truyền | Internet công cộng | đường riêng chuyên dụng | | Băng thông | ~1,25 Gbps mỗi tunnel | 50 Mbps – 100 Gbps | | Độ trễ | biến động | ổn định | | Thời gian triển khai | vài phút | vài tuần tới vài tháng | | Chi phí | thấp | cao | | Mã hoá | IPsec dựng sẵn | không mặc định (cần MACsec hoặc VPN chồng lên) |

Mẫu kết hợp phổ biến:

Direct Connect làm đường chính
    + Site-to-Site VPN làm dự phòng
        ↓
    BGP tự chuyển sang VPN khi DX hỏng

Ba cách tăng băng thông VPN: | Cách | Chi tiết | |---|---| | Nhiều VPN connection với ECMP | cần Transit Gateway | | Accelerated Site-to-Site VPN | dùng Global Accelerator, ổn định hơn | | Chuyển sang Direct Connect | băng thông cao nhất |

Accelerated VPN đáng biết:

aws ec2 create-vpn-connection --type ipsec.1   --transit-gateway-id tgw-0abc --customer-gateway-id cgw-0abc   --options '{"EnableAcceleration":true}'

Lưu lượng vào mạng AWS ở điểm biên gần nhất
    → ít chặng Internet công cộng hơn
    → độ trễ và jitter ổn định hơn

Ba lưu ý về cấu hình đường hầm: | Lưu ý | Chi tiết | |---|---| | Cấu hình CẢ HAI đường hầm | chỉ một là mất dư thừa | | Bật DPD (Dead Peer Detection) | phát hiện đứt kết nối nhanh | | Đặt MTU phù hợp | tránh phân mảnh gói |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TunnelState | 0 = down, 1 = up | | TunnelDataIn/Out | lưu lượng | | Alarm khi cả hai tunnel down | mất kết nối hoàn toàn |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | VPN connection | ~0,05 USD/giờ (~36 USD/tháng) | | Truyền dữ liệu ra | theo giá thông thường | | VGW | miễn phí |

Và một lời khuyên: hãy đặt alarm khi bất kỳ đường hầm nào down, không chỉ khi cả hai down. Chạy một đường hầm nghĩa là bạn đã mất dư thừa mà không biết — và sự cố tiếp theo sẽ làm đứt hoàn toàn kết nối tới trung tâm dữ liệu.

Đáp án

D và E.

• D — Dùng ElastiCache để cải thiện độ trễ và thông lượng cho tải NẶNG ĐỌC
• E — Dùng ElastiCache để cải thiện hiệu năng của tải nặng tính toán (compute-intensive)

Vì sao đúng

Hai đáp án là hai trường hợp dùng chính thức mà AWS nêu cho ElastiCache:

D — tải nặng đọc:

Bảng xếp hạng được HÀNG TRIỆU người xem đồng thời
    → phần lớn là ĐỌC
    → cùng một dữ liệu được đọc lặp lại rất nhiều
        ↓
    Đệm trong bộ nhớ loại bỏ hầu hết truy vấn tới database
    → độ trễ từ mili giây xuống MICRO GIÂY

E — tải nặng tính toán:

Đề nêu: "complex PROPRIETARY ALGORITHM based on performance metrics"
    → mỗi lần tính lại thứ hạng là một phép tính tốn kém
        ↓
    ElastiCache lưu KẾT QUẢ đã tính
    → không phải tính lại cho mỗi lần xem
    → đây chính là "improve performance of compute-intensive workloads"

Và Redis có kiểu dữ liệu sinh ra cho bảng xếp hạng:

ZADD bang-xep-hang 1250 "nguoi-choi-A"
ZINCRBY bang-xep-hang 50 "nguoi-choi-A"    # cộng điểm
ZREVRANGE bang-xep-hang 0 9 WITHSCORES      # top 10
ZREVRANK bang-xep-hang "nguoi-choi-A"       # thứ hạng của một người

Sorted set tự giữ thứ tự, lấy top N là thao tác O(log N) — không phải sắp xếp lại toàn bộ.

Ba yêu cầu của đề và cách Redis đáp ứng: | Yêu cầu | Cơ chế | |---|---| | Đàn hồi cao | cluster mode chia shard, hoặc Serverless | | Độ trễ thấp | trong bộ nhớ, micro giây | | Xử lý thời gian thực | ZINCRBY cập nhật tức thì |

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

• **C. Dùng ElastiCache để cải thiện độ trễ và thông lượng cho tải NẶNG GHI — đây là phương án gần nhất và là bẫy chính: ElastiCache tối ưu cho ĐỌC, không phải ghi. Bộ đệm giúp khi cùng một dữ liệu được đọc nhiều lần; với tải nặng ghi, dữ liệu vẫn phải xuống kho bền vững và bộ đệm không giảm được gì.
• **B. Dùng ElastiCache để chạy truy vấn JOIN phức tạp — sai khả năng: Redis và Memcached là kho key-value, không có công cụ truy vấn quan hệ. Không có JOIN.
• **A. Dùng ElastiCache để cải thiện hiệu năng tải ETL — sai loại tải: ETL là xử lý lô, đọc ghi khối lượng lớn tuần tự. Công cụ phù hợp là Glue, EMR hoặc Redshift.

Ghi nhớ

Ba trường hợp dùng chính của ElastiCache: | Trường hợp | Chi tiết | |---|---| | Tải nặng ĐỌC | đệm kết quả truy vấn lặp lại ← câu này | | Tải nặng TÍNH TOÁN | lưu kết quả đã tính, không tính lại ← câu này | | Lưu trạng thái phiên | session store cho ứng dụng nhiều máy |

Và ba thứ ElastiCache KHÔNG làm:

❌ Tăng tốc tải nặng GHI
❌ Chạy truy vấn quan hệ (JOIN, GROUP BY phức tạp)
❌ Thay thế database bền vững (trừ MemoryDB)

Redis và Memcached — bảng phân biệt: | | Redis / Valkey | Memcached | |---|---|---| | Cấu trúc dữ liệu | phong phú: sorted set, list, hash, stream | chỉ chuỗi key-value | | Bền vững | có (snapshot, AOF) | ❌ | | Sao chép và Multi-AZ | ✅ | ❌ | | Pub/Sub, transaction, Lua | ✅ | ❌ | | Đa luồng | có I/O threading từ v6 | ✅ từ đầu |

Quy tắc: cần bất cứ thứ gì ngoài key-value đơn giản → Redis.

Ba kiểu dữ liệu Redis hay dùng: | Kiểu | Dùng cho | |---|---| | Sorted set (ZADD, ZREVRANGE) | bảng xếp hạng ← câu này | | Hash (HSET, HGETALL) | hồ sơ đối tượng | | String với TTL (SETEX) | phiên đăng nhập, đệm kết quả | | Stream | hàng đợi sự kiện | | HyperLogLog | đếm số lượng duy nhất xấp xỉ, tốn rất ít bộ nhớ |

Ba dịch vụ in-memory của AWS: | Dịch vụ | Đặc điểm | |---|---| | ElastiCache | bộ ĐỆM — mất dữ liệu chấp nhận được | | MemoryDB for Redis | DATABASE CHÍNH — bền vững nhờ transaction log đa AZ | | DynamoDB + DAX | bộ đệm chuyên cho DynamoDB |

MemoryDB đáng cân nhắc cho bảng xếp hạng:

Nếu bảng xếp hạng là NGUỒN DỮ LIỆU DUY NHẤT:
    → ElastiCache mất dữ liệu khi node hỏng
    → MemoryDB bền vững, độ trễ đọc micro giây
        ↓
    An toàn hơn cho dữ liệu không dựng lại được

Ba chế độ triển khai ElastiCache Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, có replica | | Cluster mode enabled | chia dữ liệu qua nhiều shard — mở rộng ngang | | Serverless | tự co giãn, trả theo lượng dùng |

ElastiCache Serverless phù hợp với đề:

"high elasticity" + "millions of users simultaneously"
    → tải khó đoán
    → Serverless tự co giãn, không phải chọn cỡ node

Ba mẫu đệm phổ biến: | Mẫu | Cơ chế | |---|---| | Lazy loading (cache-aside) | đọc trượt thì nạp từ database | | Write-through | ghi vào cache và database cùng lúc | | TTL | tự hết hạn tránh dữ liệu cũ |

Lazy loading là mẫu phổ biến nhất:

def lay_du_lieu(ma):
    ket_qua = cache.get(ma)
    if ket_qua is None:              # trượt cache
        ket_qua = database.query(ma)
        cache.setex(ma, 300, ket_qua)  # lưu với TTL 300 giây
    return ket_qua

Ba cấu hình cho sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Multi-AZ với automatic failover | replica ở AZ khác | | Ít nhất 2 replica | chịu được mất một node | | Bật snapshot tự động | khôi phục khi cần |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp nghĩa là đệm không hiệu quả | | Evictions | cao nghĩa là bộ nhớ không đủ | | CPUUtilization | với Redis, chú ý EngineCPUUtilization |

Evictions là chỉ báo quan trọng:

Evictions tăng:
    → Redis phải xoá key để lấy chỗ
    → tỷ lệ trúng cache giảm
        ↓
    → Cần node lớn hơn hoặc thêm shard

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo node-giờ | như EC2 | | Reserved node giảm tới 55% | cho tải ổn định | | Serverless trả theo lượng dùng | phù hợp tải biến động |

Ba biện pháp bảo mật: | Biện pháp | Chi tiết | |---|---| | Mã hoá at rest và in transit | bật lúc tạo | | Redis AUTH hoặc RBAC | xác thực client | | Security group giới hạn nguồn | chỉ tầng ứng dụng |

Và một lời khuyên cho bảng xếp hạng thời gian thực: hãy giữ bảng xếp hạng trong Redis nhưng ghi bản sao bền vững vào DynamoDB ở nền. Redis cho tốc độ và phép tính thứ hạng, DynamoDB đảm bảo dữ liệu không mất nếu cụm gặp sự cố — và với thành tích của hàng triệu người chơi, mất là không dựng lại được.

Đáp án

D — Cấu hình NAT gateway trong public subnet của VPC.

Vì sao đúng

Đề nêu ba yêu cầu, và NAT gateway đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Database ở PRIVATE subnet cần tải bản vá từ Internet | NAT cho phép kết nối ĐI RA | | Chỉ dùng IPv4 | NAT gateway phục vụ IPv4 | | Dịch vụ ĐƯỢC QUẢN LÝ HOÀN TOÀN | AWS lo sẵn sàng cao, băng thông, vá lỗi |

Cách NAT gateway hoạt động:

Database ở private subnet
    ↓ route 0.0.0.0/0 → NAT gateway
NAT gateway ở PUBLIC subnet (có Elastic IP)
    ↓ route 0.0.0.0/0 → Internet Gateway
Internet
        ↓
    Kết nối chỉ đi được MỘT CHIỀU (từ trong ra)
    → Internet KHÔNG kết nối vào database được

Cấu hình:

aws ec2 allocate-address --domain vpc
aws ec2 create-nat-gateway --subnet-id subnet-public-a   --allocation-id eipalloc-0abc

aws ec2 create-route --route-table-id rtb-private   --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0abc

Và vì sao NAT gateway hơn NAT instance: | | NAT gateway | NAT instance | |---|---|---| | Quản lý | AWS hoàn toàn | bạn quản lý | | Sẵn sàng cao | dựng sẵn trong AZ | tự dựng | | Băng thông | 5–100 Gbps tự co giãn | theo loại instance | | Vá lỗi | AWS lo | bạn lo |

Đề hỏi rõ "fully managed service" — đó là NAT gateway.

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

• **C. Cấu hình NAT instance trong public subnet — đây là phương án gần nhất và về chức năng hoàn toàn tương đương, nhưng nó KHÔNG phải dịch vụ được quản lý: bạn phải chọn loại instance, cài AMI, vá lỗi, giám sát, và tự dựng cơ chế chuyển đổi khi nó hỏng. Đề yêu cầu rõ "fully managed service".
• **A. Cấu hình Egress-only internet gateway — sai họ địa chỉ: egress-only internet gateway chỉ phục vụ IPv6. Đề nói rõ công ty chỉ dùng IPv4.
• **B. Cho private subnet dùng Internet Gateway bằng cách đổi route table — phá vỡ tính riêng tư: subnet có route tới IGW thì theo định nghĩa nó trở thành public subnet. Và database sẽ cần IP công cộng để hoạt động, phơi nó ra Internet.

Ghi nhớ

Ba cổng ra Internet của VPC — bảng phải thuộc: | Cổng | Họ địa chỉ | Chiều | |---|---|---| | Internet Gateway | IPv4 và IPv6 | HAI CHIỀU | | NAT gateway | CHỈ IPv4 | CHỈ ĐI RA ← câu này | | Egress-only internet gateway | CHỈ IPv6 | CHỈ ĐI RA, MIỄN PHÍ |

Định nghĩa public và private subnet:

Public subnet:  route table CÓ route tới Internet Gateway
Private subnet: route table KHÔNG có route tới IGW
        ↓
    Đây là khác biệt DUY NHẤT — không có công tắc "public/private"

Đây chính là điểm mà phương án B hiểu sai: thêm route tới IGW biến private subnet thành public subnet.

Ba đặc điểm của NAT gateway: | Đặc điểm | Chi tiết | |---|---| | Phải đặt ở PUBLIC subnet | cần đường ra IGW | | Cần Elastic IP | | | KHÔNG gắn security group được | kiểm soát bằng NACL của subnet |

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | NAT gateway dư thừa TRONG một AZ | nhưng KHÔNG trải nhiều AZ | | Mỗi AZ nên có NAT gateway RIÊNG | AZ hỏng không kéo theo AZ khác | | Route table riêng cho mỗi AZ | trỏ vào NAT cùng AZ |

Cấu hình đúng cho sản xuất:

Private subnet AZ-a → NAT gateway ở public subnet AZ-a
Private subnet AZ-c → NAT gateway ở public subnet AZ-c
        ↓
    Vừa chịu lỗi, vừa tránh phí truyền chéo AZ

Ba khoản chi phí của NAT gateway: | Khoản | Giá tham khảo | |---|---| | Theo giờ | ~0,045 USD/giờ (~33 USD/tháng) | | Xử lý dữ liệu | ~0,045 USD/GB | | Truyền chéo AZ nếu đặt sai | thêm phí |

Ba cách giảm chi phí NAT gateway: | Cách | Tiết kiệm | |---|---| | Gateway VPC endpoint cho S3 và DynamoDB | MIỄN PHÍ, tránh hẳn phí NAT | | Interface endpoint cho dịch vụ hay dùng | ECR, SSM, CloudWatch Logs | | NAT tập trung ở shared services VPC | ít NAT gateway hơn |

Gateway endpoint là khoản tiết kiệm dễ nhất:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.s3   --route-table-ids rtb-private

Hoàn toàn miễn phí, và lưu lượng tới S3 thường rất lớn.

Ba cách khác để database tải bản vá: | Cách | Chi tiết | |---|---| | NAT gateway | ← câu này, đơn giản nhất | | AWS Systems Manager Patch Manager với VPC endpoint | không cần Internet chút nào | | Kho phần mềm nội bộ trong VPC | kiểm soát chặt nhất |

Systems Manager với VPC endpoint là lựa chọn an toàn hơn:

Tạo interface endpoint cho:
    com.amazonaws.<region>.ssm
    com.amazonaws.<region>.ssmmessages
    com.amazonaws.<region>.ec2messages
    + gateway endpoint cho S3 (patch baseline lưu ở S3)
        ↓
    Vá lỗi hoàn toàn không cần đường ra Internet

Ba lưu ý về NACL với NAT gateway: | Lưu ý | Chi tiết | |---|---| | NACL là stateless | phải mở CẢ hai chiều | | Mở dải cổng tạm thời 1024–65535 | cho lưu lượng trả về | | Đây là cơ chế lọc DUY NHẤT | NAT gateway không có security group |

Ba lưu ý nếu buộc phải dùng NAT instance: | Lưu ý | Chi tiết | |---|---| | PHẢI tắt source/destination check | nếu không, NAT không hoạt động | | Là điểm hỏng duy nhất | cần script chuyển đổi | | Băng thông giới hạn theo loại instance | |

aws ec2 modify-instance-attribute --instance-id i-0nat --no-source-dest-check

Ba lưu ý về IPv6: | Lưu ý | Chi tiết | |---|---| | IPv6 không cần NAT | mọi địa chỉ IPv6 đều định tuyến toàn cầu | | Egress-only IGW cho chiều ra | tương đương NAT nhưng cho IPv6 | | Egress-only IGW MIỄN PHÍ | khác NAT gateway |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BytesOutToDestination | lưu lượng ra Internet | | ErrorPortAllocation | cạn cổng — cần thêm NAT gateway | | PacketsDropCount | gói bị bỏ |

ErrorPortAllocation đáng chú ý: một NAT gateway hỗ trợ khoảng 55.000 kết nối đồng thời tới cùng một đích — vượt qua thì phải chia tải sang nhiều NAT gateway.

Và một lời khuyên: hãy tạo gateway endpoint cho S3 và DynamoDB ở mọi VPC, ngay cả khi chưa dùng tới. Chúng hoàn toàn miễn phí, và khi ứng dụng bắt đầu đọc ghi S3 nhiều, bạn đã tránh được khoản phí xử lý dữ liệu của NAT gateway mà không phải làm gì thêm.

Đáp án

A — Cấu hình CloudWatch alarm kích hoạt khôi phục EC2 instance khi instance hỏng; instance chỉ được cấu hình với EBS volume.

Vì sao đúng

Đề nêu ba yêu cầu, và EC2 auto-recovery đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Phục hồi TỰ ĐỘNG | CloudWatch alarm với hành động recover | | Chấp nhận ngừng tối đa 10 phút | khôi phục thường mất vài phút | | Tiết kiệm, KHÔNG dựng ASG hay chiến lược phức tạp | một alarm, không thêm tài nguyên |

Cách EC2 auto-recovery hoạt động:

Status check của hệ thống thất bại
    (lỗi phần cứng, mất điện, mất kết nối mạng của máy chủ vật lý)
        ↓
CloudWatch alarm kích hoạt hành động recover
        ↓
Instance được KHỞI ĐỘNG LẠI TRÊN PHẦN CỨNG KHÁC
    ✓ GIỮ NGUYÊN instance ID
    ✓ GIỮ NGUYÊN IP riêng và Elastic IP
    ✓ GIỮ NGUYÊN EBS volume và dữ liệu
    ✓ GIỮ NGUYÊN metadata

Và vế "chỉ EBS volume" là ràng buộc kỹ thuật cứng:

Auto-recovery YÊU CẦU instance chỉ dùng EBS
    → instance store là đĩa VẬT LÝ trên máy chủ
    → chuyển sang máy chủ khác thì dữ liệu đó MẤT
        ↓
    AWS không cho khôi phục instance có instance store

Cấu hình alarm:

aws cloudwatch put-metric-alarm --alarm-name khoi-phuc-instance   --metric-name StatusCheckFailed_System --namespace AWS/EC2   --dimensions Name=InstanceId,Value=i-0abc   --statistic Maximum --period 60 --threshold 1   --comparison-operator GreaterThanOrEqualToThreshold   --evaluation-periods 2   --alarm-actions arn:aws:automate:ap-northeast-1:ec2:recover

Lưu ý: metric là StatusCheckFailed_System, không phải StatusCheckFailed_Instance.

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

• **D. CloudWatch alarm kích hoạt khôi phục, instance có thể dùng EBS HOẶC instance store — đây là phương án gần nhất và là bẫy chính: nó đúng về cơ chế nhưng sai về ràng buộc. Auto-recovery KHÔNG hỗ trợ instance có instance store volume.
• **C. Cấu hình EventBridge để kích hoạt khôi phục khi instance hoặc ứng dụng hỏng — hai vấn đề: cơ chế khôi phục dựng sẵn là CloudWatch alarm action, không phải EventBridge. Và auto-recovery không phát hiện được lỗi ỨNG DỤNG — nó chỉ phản ứng với status check của hệ thống.
• **B. Dùng Trusted Advisor giám sát health check và tự khắc phục — sai chức năng: Trusted Advisor đưa ra khuyến nghị về chi phí, bảo mật và hiệu năng. Nó không giám sát thời gian thực và không thực hiện hành động khắc phục nào.

Ghi nhớ

Hai status check của EC2 — bảng phải thuộc: | Check | Kiểm tra gì | Ai chịu trách nhiệm | |---|---|---| | StatusCheckFailed_System | phần cứng, mạng, nguồn điện của MÁY CHỦ VẬT LÝ | AWS | | StatusCheckFailed_Instance | hệ điều hành, cấu hình mạng, đĩa đầy | BẠN | | StatusCheckFailed_AttachedEBS | tình trạng volume gắn kèm | AWS |

Và cách xử lý khác nhau:

System check thất bại:
    → STOP rồi START (chuyển sang phần cứng khác)
    → hoặc auto-recovery
    → REBOOT KHÔNG giúp gì

Instance check thất bại:
    → thường do OS — xem log, reboot có thể giúp
    → auto-recovery KHÔNG xử lý được

Auto-recovery CHỈ phản ứng với system check — đây là giới hạn quan trọng nhất.

Ba điều kiện của EC2 auto-recovery: | Điều kiện | Chi tiết | |---|---| | CHỈ dùng EBS volume | không có instance store ← câu này | | Loại instance được hỗ trợ | hầu hết thế hệ hiện hành | | Không phải Dedicated Host hoặc Spot | |

Ba thứ được giữ nguyên khi khôi phục: | Giữ nguyên | Chi tiết | |---|---| | Instance ID | không đổi | | IP riêng và Elastic IP | không phải cấu hình lại DNS | | EBS volume và dữ liệu | | | Metadata và placement group | |

Và một thứ KHÔNG giữ:

Dữ liệu trong RAM MẤT
    → instance khởi động lại như sau khi stop/start
    → ứng dụng phải chịu được việc khởi động lại

Lưu ý quan trọng: AWS đã bật auto-recovery MẶC ĐỊNH.

Từ tháng 3 năm 2022, "simplified automatic recovery"
    → bật MẶC ĐỊNH cho hầu hết loại instance đủ điều kiện
    → không cần tạo alarm thủ công
        ↓
    Kiểm tra bằng:

aws ec2 describe-instances --instance-ids i-0abc   --query 'Reservations[].Instances[].MaintenanceOptions.AutoRecovery'

Giá trị default nghĩa là đã bật. (Alarm thủ công vẫn hữu ích khi cần tuỳ chỉnh ngưỡng hoặc thêm thông báo.)

Ba hành động của CloudWatch alarm cho EC2: | Hành động | ARN | |---|---| | Recover | arn:aws:automate:<region>:ec2:recover | | Stop | arn:aws:automate:<region>:ec2:stop | | Terminate | arn:aws:automate:<region>:ec2:terminate | | Reboot | arn:aws:automate:<region>:ec2:reboot |

Và nên thêm thông báo SNS song song:

--alarm-actions arn:aws:automate:ap-northeast-1:ec2:recover                 arn:aws:sns:ap-northeast-1:123456789012:canh-bao

Để biết đã có sự cố, không chỉ để nó tự khắc phục im lặng.

Ba cơ chế phục hồi — theo mức độ: | Cơ chế | Phục hồi được gì | Công dựng | |---|---|---| | EC2 auto-recovery | lỗi phần cứng của máy chủ | rất ít ← câu này | | Auto Scaling group (min=max=1) | lỗi phần cứng VÀ lỗi ứng dụng | vừa | | ASG nhiều máy + ALB | mọi thứ, không gián đoạn | nhiều |

ASG với một instance đáng biết:

ASG với MinSize = MaxSize = 1:
    ✓ thay instance khi hỏng
    ✓ với HealthCheckType = ELB, phát hiện cả lỗi ỨNG DỤNG
    ✗ instance MỚI có instance ID và IP khác
    ✗ dữ liệu trên EBS gốc không tự theo

Đây là lý do auto-recovery phù hợp hơn với ứng dụng đơn lẻ có trạng thái trên EBS.

Ba lưu ý về thời gian khôi phục: | Lưu ý | Chi tiết | |---|---| | Thường vài phút | trong ngưỡng 10 phút của đề | | Phụ thuộc thời gian khởi động OS và ứng dụng | | | Alarm cần vài chu kỳ đánh giá | evaluation-periods × period |

Ba việc nên làm cho ứng dụng đơn lẻ: | Việc | Chi tiết | |---|---| | Bật auto-recovery | ← câu này | | Chụp snapshot EBS định kỳ | Data Lifecycle Manager | | Đảm bảo ứng dụng tự khởi động cùng OS | systemctl enable |

Dòng cuối rất quan trọng: khôi phục instance mà ứng dụng không tự chạy lại thì máy lên nhưng dịch vụ vẫn ngừng.

Ba metric nên đặt alarm: | Metric | Ý nghĩa | |---|---| | StatusCheckFailed_System | kích hoạt khôi phục | | StatusCheckFailed_Instance | cảnh báo lỗi OS | | Metric ứng dụng tuỳ chỉnh | phát hiện lỗi mức ứng dụng |

Và một lời khuyên cho startup: hãy chụp snapshot EBS hằng ngày bằng Data Lifecycle Manager. Auto-recovery bảo vệ khỏi hỏng phần cứng, nhưng không bảo vệ khỏi việc ai đó xoá nhầm dữ liệu hay ứng dụng ghi hỏng — và với một máy duy nhất, snapshot là bản sao lưu duy nhất bạn có.

Đáp án

D, E và F.

• D — SCP ảnh hưởng mọi user và role trong tài khoản thành viên, KỂ CẢ tài khoản root
• E — Nếu IAM policy cho phép một hành động mà SCP không cho phép hoặc từ chối rõ ràng, thì user hoặc role KHÔNG thực hiện được
• F — SCP KHÔNG ảnh hưởng service-linked role

Vì sao đúng

Ba đáp án mô tả ba đặc điểm cốt lõi của Service Control Policy:

D — SCP áp cho CẢ tài khoản root:

IAM policy KHÔNG giới hạn được root
    → root có toàn quyền tuyệt đối trong tài khoản

SCP thì KHÁC:
    → áp ở cấp AWS Organizations, NẰM TRÊN tài khoản
    → mọi principal trong tài khoản thành viên đều bị giới hạn
    → KỂ CẢ root
        ↓
    Đây là cơ chế DUY NHẤT giới hạn được root

E — SCP là TRẦN quyền, không phải nguồn cấp quyền:

Quyền hiệu lực = SCP ∩ identity policy
    ↓
    IAM policy Allow + SCP không cho phép → TỪ CHỐI
    IAM policy Allow + SCP Allow          → cho phép
    IAM policy không có + SCP Allow       → TỪ CHỐI (SCP không cấp quyền)

F — service-linked role là ngoại lệ:

Service-linked role là role mà DỊCH VỤ AWS dùng để hoạt động
    → ví dụ AWSServiceRoleForAutoScaling
    → AWS cần chúng để dịch vụ chạy được
        ↓
    SCP KHÔNG áp cho chúng
    → nếu áp, nhiều dịch vụ AWS sẽ ngừng hoạt động

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

• **B. SCP ảnh hưởng mọi user và role trong tài khoản thành viên, TRỪ root — đây là phương án gần nhất và là bẫy chính: nó đúng phần lớn nhưng loại trừ sai. SCP CÓ áp cho root của tài khoản thành viên — đó chính là điều làm nó khác IAM policy.
• **A. IAM policy Allow mà SCP không cho phép thì user VẪN thực hiện được — đảo ngược E.
• **C. SCP CÓ ảnh hưởng service-linked role — đảo ngược F.

Ghi nhớ

Bốn cơ chế giới hạn quyền — bảng phải thuộc: | Cơ chế | Áp cho | Ảnh hưởng root | |---|---|---| | Identity policy | user, group, role | ❌ | | Permissions boundary | một user hoặc role | ❌ | | Service Control Policy | tài khoản hoặc OU | ✅ | | Session policy | phiên AssumeRole | — |

SCP là cơ chế DUY NHẤT giới hạn được root — nội dung cần nhớ nhất.

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

Quyền = SCP ∩ identity policy ∩ permissions boundary ∩ session policy
        và KHÔNG có explicit Deny nào ở bất kỳ tầng nào

Ba ngoại lệ quan trọng của SCP: | Ngoại lệ | Chi tiết | |---|---| | Tài khoản QUẢN LÝ (management account) | SCP KHÔNG áp — đừng chạy tải công việc ở đó | | Service-linked role | ← đáp án F | | Một số hành động toàn cầu | ví dụ liên quan tới Organizations |

Ngoại lệ đầu tiên là điểm thiết kế quan trọng:

Tài khoản quản lý KHÔNG bị SCP giới hạn
    → nếu chạy tài nguyên ở đó, chúng không được bảo vệ
        ↓
    → Chỉ dùng tài khoản quản lý cho việc quản lý Organizations
    → mọi tải công việc đặt ở tài khoản thành viên

Hai chiến lược viết SCP: | Chiến lược | Cách | |---|---| | Deny list (phổ biến) | giữ FullAWSAccess, thêm SCP Deny các hành động cấm | | Allow list | gỡ FullAWSAccess, chỉ liệt kê hành động cho phép |

Deny list dễ quản lý hơn nhiều — allow list phải liệt kê từng hành động và rất dễ chặn nhầm.

Năm SCP nên có cho mọi Organization: | SCP | Chặn gì | |---|---| | Chặn tắt CloudTrail | bảo vệ nhật ký kiểm toán | | Chặn tắt GuardDuty, Config, Security Hub | bảo vệ công cụ giám sát | | Giới hạn Region được dùng | tuân thủ và kiểm soát chi phí | | Chặn xoá bucket log kiểm toán | | | Chặn tạo IAM user | ép dùng Identity Center |

Ví dụ chặn tắt CloudTrail:

{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
            "cloudtrail:UpdateTrail"],
 "Resource": "*"}

Ví dụ giới hạn Region:

{"Effect": "Deny", "NotAction": [
   "iam:*", "organizations:*", "route53:*", "cloudfront:*",
   "waf:*", "wafv2:*", "shield:*", "support:*", "budgets:*", "sts:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]}}}

NotAction liệt kê dịch vụ TOÀN CẦU — thiếu một cái là dịch vụ đó ngừng hoạt động.

Ba đặc điểm khác của SCP: | Đặc điểm | Chi tiết | |---|---| | KHÔNG cấp quyền, chỉ GIỚI HẠN | phải có identity policy song song | | Kế thừa xuống OU con | SCP ở OU cha áp cho mọi tài khoản bên dưới | | Giao của mọi SCP trên đường kế thừa | càng sâu càng hẹp |

Kế thừa hoạt động như giao (intersection):

Root SCP:      cho phép A, B, C
OU cha SCP:    cho phép A, B
OU con SCP:    cho phép B, C
        ↓
    Quyền hiệu lực = A,B,C ∩ A,B ∩ B,C = chỉ B

Ba loại chính sách của AWS Organizations: | Loại | Việc | |---|---| | Service Control Policy (SCP) | giới hạn quyền tối đa ← câu này | | Tag policy | chuẩn hoá thẻ | | Backup policy | quản lý sao lưu tập trung | | Resource control policy (RCP) | giới hạn ai truy cập được TÀI NGUYÊN của bạn |

RCP là loại mới đáng biết:

SCP: giới hạn PRINCIPAL trong tổ chức làm được gì
RCP: giới hạn ai (kể cả từ ngoài) truy cập TÀI NGUYÊN của tổ chức
        ↓
    Hai chiều bổ sung nhau

Ba lưu ý khi triển khai SCP: | Lưu ý | Chi tiết | |---|---| | Thử trên OU thử nghiệm trước | SCP sai có thể khoá cả tài khoản | | Kiểm tra ảnh hưởng tới service-linked role | | | Ghi tài liệu rõ vì sao chặn | người sau sẽ hỏi |

Ba công cụ hỗ trợ: | Công cụ | Việc | |---|---| | AWS Control Tower | guardrail dựng sẵn, dựa trên SCP | | IAM Access Analyzer | phân tích quyền hiệu lực | | CloudTrail | xem lời gọi bị SCP chặn |

Ba loại guardrail của Control Tower: | Loại | Cơ chế | |---|---| | Preventive | SCP — CHẶN hành động | | Detective | AWS Config rule — phát hiện vi phạm | | Proactive | CloudFormation hook |

Và một lời khuyên: hãy kiểm chứng SCP bằng cách thử hành động bị cấm từ chính tài khoản root của một tài khoản thành viên thử nghiệm. Đó là cách duy nhất xác nhận đặc điểm quan trọng nhất của SCP — nó thực sự chặn được root, thứ mà không cơ chế IAM nào làm được.