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

Đáp án

B — Dùng AWS Storage Gateway ở chế độ Tape Gateway (Virtual Tape Library).

Vì sao đúng

Đề nêu ba dữ kiện, và Tape Gateway được thiết kế đúng cho tình huống này: | Dữ kiện | Cơ chế | |---|---| | Đang dùng băng từ vật lý | Tape Gateway giả lập THƯ VIỆN BĂNG | | Muốn giữ phần mềm sao lưu hiện có | giao diện iSCSI VTL — phần mềm không biết khác biệt | | Chi phí thấp cho lưu trữ dài hạn | băng ảo lưu trong Glacier / Deep Archive |

Vì sao phần mềm sao lưu không phải thay:

Tape Gateway xuất hiện như một thư viện băng qua iSCSI
    → phần mềm sao lưu thấy: máy đổi băng, ổ băng, các cuộn băng
    → nó ghi lệnh SCSI y hệt như với thiết bị thật
        ↓
    Veeam, NetBackup, Commvault, Backup Exec dùng được ngay

Và vòng đời của băng ảo:

Ghi băng    → lưu trong S3 (qua gateway)
Eject băng  → chuyển sang S3 Glacier Flexible Retrieval
Archive sâu → S3 Glacier Deep Archive
        ↓
    Chi phí lưu trữ rất thấp cho dữ liệu giữ nhiều năm

Triển khai:

aws storagegateway create-tapes --gateway-arn <arn>   --tape-size-in-bytes 107374182400   --num-tapes-to-create 10   --tape-barcode-prefix BK

Và ba lợi ích so với băng vật lý: | Lợi ích | Chi tiết | |---|---| | Không có băng vật lý để mất hay hỏng | | | Không cần kho lưu trữ ngoài | | | Độ bền 99,999999999% của S3 | |

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

• **A. Dùng File Gateway — đây là phương án gần nhất vì cũng là Storage Gateway, nhưng nó sai chế độ: File Gateway cung cấp giao diện NFS/SMB cho tệp, không phải thư viện băng. Phần mềm sao lưu dùng băng sẽ phải cấu hình lại hoàn toàn.
• **C. Dùng Volume Gateway — cũng sai chế độ: Volume Gateway cung cấp volume khối qua iSCSI, dùng cho ổ đĩa chứ không phải thư viện băng.
• **D. Dùng AWS Direct Connect — giải quyết vấn đề khác: Direct Connect là kết nối mạng riêng tới AWS. Nó không cung cấp giao diện lưu trữ nào.

Ghi nhớ

Ba chế độ của AWS Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Dùng cho | |---|---|---| | File Gateway (S3) | NFS, SMB | tệp lưu vào S3 | | Volume Gateway | iSCSI (khối) | ổ đĩa, snapshot EBS | | Tape Gateway | iSCSI VTL | thay băng từ vật lý ← câu này | | FSx File Gateway | SMB | truy cập FSx for Windows tại chỗ |

Từ khoá nhận diện:

"replace physical tape", "tape backup software", "VTL" → Tape Gateway "NFS/SMB share backed by S3" → File Gateway "iSCSI block volume", "on-premises applications" → Volume Gateway

Hai chế độ của Volume Gateway: | Chế độ | Đặc điểm | |---|---| | Cached volumes | dữ liệu chính ở S3, cache nóng tại chỗ | | Stored volumes | dữ liệu chính TẠI CHỖ, snapshot bất đồng bộ lên S3 |

Ba thành phần của Tape Gateway: | Thành phần | Việc | |---|---| | Virtual tape library (VTL) | băng đang dùng, lưu ở S3 | | Virtual tape shelf (VTS) | băng đã archive, lưu ở Glacier | | Gateway appliance | máy ảo tại chỗ hoặc phần cứng |

Ba cách triển khai gateway: | Cách | Chi tiết | |---|---| | Máy ảo (VMware, Hyper-V, KVM) | phổ biến nhất | | Amazon EC2 | cho tải chạy trên AWS | | Phần cứng chuyên dụng | Storage Gateway Hardware Appliance |

Ba lưu ý về thời gian lấy băng đã archive: | Lớp | Thời gian | |---|---| | Glacier Flexible Retrieval | 3–5 giờ | | Glacier Deep Archive | 12 giờ | | — | phải retrieve-tape trước khi đọc |

aws storagegateway retrieve-tape-archive   --tape-arn <arn-bang> --gateway-arn <arn-gateway>

Quy trình khôi phục phải tính tới độ trễ này — không đọc băng archive ngay được.

Ba yêu cầu về hạ tầng: | Yêu cầu | Chi tiết | |---|---| | Đủ dung lượng đĩa cho cache | tối thiểu 150 GB | | Băng thông ổn định | dữ liệu đi lên S3 | | Cổng 443 ra AWS | hoặc qua VPC endpoint |

Ba cách tối ưu chi phí: | Cách | Tiết kiệm | |---|---| | Archive băng cũ sang Deep Archive | rẻ nhất | | Đặt băng ảo kích thước hợp lý | 100 GB – 5 TB mỗi băng | | Giới hạn băng thông upload theo giờ | tránh nghẽn giờ làm việc |

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

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CachePercentUsed | cache đầy làm chậm hẳn | | CloudBytesUploaded | lượng dữ liệu lên S3 | | WorkingStoragePercentUsed | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Dữ liệu mã hoá at rest trong S3 | SSE-S3 hoặc SSE-KMS | | Truyền qua TLS | | | Kết hợp Object Lock cho tuân thủ WORM | nếu cần bất biến |

Ba giải pháp kết nối tại chỗ với AWS: | Giải pháp | Việc | |---|---| | Storage Gateway | giao diện lưu trữ lai ← câu này | | DataSync | di chuyển tệp hàng loạt, nhanh | | Direct Connect | kết nối mạng riêng | | Snowball | vận chuyển vật lý cho petabyte |

DataSync và Storage Gateway hay bị nhầm: | | DataSync | Storage Gateway | |---|---|---| | Mục đích | DI CHUYỂN dữ liệu một lần hoặc theo lịch | truy cập LIÊN TỤC | | Sau khi chạy | dữ liệu ở AWS | tại chỗ vẫn dùng như bình thường |

Ba bước chuyển từ băng vật lý: | Bước | Chi tiết | |---|---| | Triển khai gateway và tạo băng ảo | | | Cấu hình phần mềm sao lưu trỏ tới VTL | | | Chạy song song một thời gian | xác nhận trước khi bỏ băng thật |

Và một lời khuyên: hãy thử khôi phục từ một băng đã archive trước khi ngừng dùng băng vật lý. Thời gian lấy từ Deep Archive là 12 giờ, và nếu quy trình khôi phục thảm hoạ của bạn giả định băng có sẵn ngay, con số đó sẽ làm hỏng toàn bộ RTO — tốt nhất là biết điều đó trước khi cần đến nó thật.

Đáp án

D và E.

• D — Dùng Spot Instances cho tải xử lý
• E — Dùng Amazon SQS để tách rời và đệm công việc

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba đều dẫn tới cặp Spot + SQS: | Đặc điểm | Kết luận | |---|---| | Tải tăng giảm THẤT THƯỜNG | SQS đệm để không mất việc | | Chịu được GIÁN ĐOẠN | Spot Instances dùng được | | Cần TIẾT KIỆM CHI PHÍ nhất | Spot rẻ tới 90% |

D — Spot Instances tiết kiệm nhiều nhất:

Spot Instances:
    → dùng năng lực dư của AWS
    → RẺ HƠN On-Demand tới 90%
    → có thể bị thu hồi với thông báo 2 phút
        ↓
    Đề nói "tolerant to interruptions" → Spot là lựa chọn đúng

E — SQS làm cho việc bị gián đoạn không mất:

Không có hàng đợi:
    Spot bị thu hồi giữa chừng → công việc MẤT

Có SQS:
    → công việc nằm trong hàng đợi
    → instance nhận việc, xử lý, rồi mới XOÁ thông điệp
    → bị thu hồi giữa chừng → visibility timeout hết
      → thông điệp QUAY LẠI hàng đợi
        ↓
    Instance khác nhận và làm lại — KHÔNG mất việc nào

Hai đáp án phối hợp chặt chẽ — đó là điểm mấu chốt:

SQS làm cho Spot AN TOÀN
    → không có SQS, Spot bị thu hồi là mất dữ liệu
    → có SQS, thu hồi chỉ là chậm hơn một chút

Và SQS còn giải quyết tải thất thường:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-xu-ly   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 10,
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS", "Statistic": "Average",
      "Dimensions": [{"Name":"QueueName","Value":"hang-doi-xu-ly"}]}}'

Co giãn theo độ dài hàng đợi — phản ánh tải thật chính xác hơn CPU.

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

• **B. Dùng Reserved Instances — đây là phương án gần nhất vì cũng tiết kiệm chi phí, nhưng nó sai loại tải: Reserved Instance cam kết 1–3 năm cho năng lực NỀN ỔN ĐỊNH. Với tải thất thường, bạn sẽ trả tiền cho lúc không dùng, và vẫn phải trả On-Demand cho phần đỉnh.
• **A. Dùng On-Demand Instances — đắt nhất trong các lựa chọn: không có ưu đãi nào, và đề hỏi "MOST cost-optimal".
• **C. Dùng Dedicated Hosts — đắt nhất tuyệt đối: dành cho yêu cầu tuân thủ về phần cứng riêng biệt hoặc giấy phép BYOL, không liên quan gì tới tối ưu chi phí ở đây.

Ghi nhớ

Các mô hình mua EC2 — bảng phải thuộc: | Mô hình | Tiết kiệm | Cam kết | Phù hợp | |---|---|---|---| | On-Demand | 0% | không | tải ngắn, khó đoán, không gián đoạn được | | Savings Plans | tới 72% | 1–3 năm theo USD/giờ | linh hoạt nhất | | Reserved Instances | tới 72% | 1–3 năm theo loại instance | tải nền ổn định | | Spot | tới 90% | không | chịu được gián đoạn ← câu này | | Dedicated Host | — | — | tuân thủ, BYOL |

Từ khoá nhận diện:

"fault-tolerant", "can be interrupted", "batch processing", "most cost-optimal" → Spot "steady-state", "predictable", "1-3 years" → Savings Plans hoặc RI "licensing tied to physical cores" → Dedicated Host

Ba trường hợp phù hợp với Spot: | Trường hợp | Chi tiết | |---|---| | Xử lý theo lô | ← câu này | | Xử lý dữ liệu lớn | EMR, Spark | | CI/CD và kiểm thử | | | Render đồ hoạ | |

Ba trường hợp KHÔNG dùng Spot: | Trường hợp | Lý do | |---|---| | Database sản xuất | mất dữ liệu khi bị thu hồi | | Ứng dụng có trạng thái trong bộ nhớ | | | Tải cần chạy liên tục không đứt | |

Ba cơ chế xử lý việc thu hồi Spot: | Cơ chế | Chi tiết | |---|---| | Thông báo trước 2 phút | qua metadata hoặc EventBridge | | Rebalance recommendation | cảnh báo SỚM HƠN 2 phút | | Capacity Rebalancing của ASG | tự thay máy trước khi bị thu hồi |

Đọc thông báo thu hồi:

curl -s http://169.254.169.254/latest/meta-data/spot/instance-action

Trả về 404 nếu chưa bị thu hồi
Trả về JSON có thời điểm nếu đã có thông báo
        ↓
    Kiểm tra mỗi 5 giây để kịp dọn dẹp

Ba đặc điểm của SQS bảo vệ công việc: | Đặc điểm | Chi tiết | |---|---| | Visibility timeout | thông điệp ẩn khi đang xử lý, hiện lại nếu không xoá | | Chỉ xoá SAU KHI xử lý xong | đảm bảo ít nhất một lần | | Dead letter queue | thông điệp thất bại nhiều lần |

Visibility timeout phải đặt đúng:

Quá NGẮN:  thông điệp hiện lại khi vẫn đang xử lý → xử lý TRÙNG
Quá DÀI:   Spot bị thu hồi → chờ lâu mới có máy khác nhận
        ↓
    Đặt bằng thời gian xử lý P99 rồi cộng biên

Hai loại hàng đợi SQS: | Loại | Đặc điểm | |---|---| | Standard | thông lượng gần như vô hạn, thứ tự KHÔNG đảm bảo, có thể trùng | | FIFO | giữ thứ tự, xử lý đúng một lần |

Ba chiến lược tăng khả năng có Spot: | Chiến lược | Chi tiết | |---|---| | Khai NHIỀU loại instance | quan trọng nhất | | Trải nhiều AZ | nhiều nguồn năng lực | | Dùng allocation strategy price-capacity-optimized | cân bằng giá và ổn định |

Mixed instances policy trong ASG:

{"MixedInstancesPolicy": {
  "LaunchTemplate": {"Overrides": [
    {"InstanceType": "m5.large"}, {"InstanceType": "m5a.large"},
    {"InstanceType": "m6i.large"}, {"InstanceType": "c5.large"}]},
  "InstancesDistribution": {
    "OnDemandBaseCapacity": 2,
    "OnDemandPercentageAboveBaseCapacity": 0,
    "SpotAllocationStrategy": "price-capacity-optimized"}}}

2 máy On-Demand làm nền đảm bảo
    + phần còn lại toàn Spot
        ↓
    Cân bằng giữa chi phí và độ tin cậy

Ba lựa chọn khác cho xử lý theo lô: | Lựa chọn | Đặc điểm | |---|---| | AWS Batch | tự quản lý hàng đợi công việc và năng lực, hỗ trợ Spot | | Lambda | không quản lý máy, giới hạn 15 phút | | Fargate Spot | container, rẻ hơn ~70% |

AWS Batch đáng cân nhắc:

AWS Batch:
    ✓ tự quản lý hàng đợi công việc
    ✓ tự chọn loại instance
    ✓ tích hợp Spot sẵn
        ↓
    Ít việc phải tự dựng hơn so với SQS + ASG

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng — dùng để co giãn | | ApproximateAgeOfOldestMessage | việc nằm chờ quá lâu | | Tỷ lệ instance bị thu hồi | đánh giá lựa chọn loại instance |

Ba cách giảm chi phí thêm: | Cách | Tiết kiệm | |---|---| | Graviton (ARM) | rẻ hơn ~20% cho cùng hiệu năng | | Kích thước instance đúng nhu cầu | | | Tắt tài nguyên không dùng | |

Và một lời khuyên: hãy khai ít nhất bốn loại instance trong mixed instances policy. Đó là yếu tố ảnh hưởng lớn nhất tới tỷ lệ bị thu hồi — với một loại duy nhất, một đợt thiếu năng lực trong AZ đó là mất toàn bộ đội máy cùng lúc, còn với nhiều loại thì ASG chỉ đơn giản chuyển sang loại khác.

Đáp án

D — Cấu hình ElastiCache for Redis ở chế độ Multi-AZ có chuyển đổi tự động (automatic failover).

Vì sao đúng

Đề nêu vấn đề rõ: node hỏng làm ngừng dịch vụ hàng giờ, và cần chuyển đổi tự động ít công vận hành nhất.

Multi-AZ với automatic failover:
    → replica ở AZ KHÁC
    → ElastiCache PHÁT HIỆN primary hỏng
    → TỰ ĐỘNG nâng replica lên làm primary
    → cập nhật DNS của endpoint
        ↓
    Ứng dụng chỉ cần KẾT NỐI LẠI, không sửa gì

Thời gian chuyển đổi:

Thường dưới 1 phút
    → so với "several hours of downtime" hiện tại
        ↓
    Cải thiện rất lớn, và hoàn toàn tự động

Bật Multi-AZ:

aws elasticache create-replication-group   --replication-group-id cum-phien   --replication-group-description "Luu phien nguoi dung"   --engine redis --cache-node-type cache.r6g.large   --num-cache-clusters 3   --automatic-failover-enabled   --multi-az-enabled   --preferred-cache-cluster-a-zs ap-northeast-1a ap-northeast-1c ap-northeast-1d

Và ứng dụng dùng endpoint chính:

Primary endpoint:
    cum-phien.abc.ng.0001.apne1.cache.amazonaws.com:6379
        ↓
    Sau chuyển đổi, endpoint TRỎ SANG node mới
    → chuỗi kết nối không đổi

Ba điều kiện để Multi-AZ hoạt động: | Điều kiện | Chi tiết | |---|---| | Ít nhất một replica | không có replica thì không chuyển đổi được | | Replica ở AZ KHÁC primary | | | automatic-failover-enabled | phải bật tường minh |

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

• **B. Thêm read replica trong CÙNG AZ và chuyển thủ công khi có sự cố — đây là phương án gần nhất vì có replica, nhưng nó có hai vấn đề: replica cùng AZ không bảo vệ được khi cả AZ hỏng, và chuyển thủ công vẫn để lại thời gian ngừng đáng kể — đúng điều đề muốn tránh.
• **A. Viết Lambda theo dõi và tự tạo lại node khi hỏng — tự dựng lại thứ đã có sẵn: phải viết, kiểm thử và bảo trì mã, mà kết quả kém tin cậy hơn cơ chế dựng sẵn. Và tạo lại node nghĩa là mất toàn bộ dữ liệu trong bộ nhớ.
• **C. Chuyển sang Memcached với nhiều node — Memcached KHÔNG có sao chép hay chuyển đổi: node hỏng là mất phần dữ liệu trên node đó. Nó chỉ chia dữ liệu chứ không nhân bản.

Ghi nhớ

Redis và Memcached — bảng phải thuộc: | | Redis / Valkey | Memcached | |---|---|---| | Sao chép | ✅ | ❌ | | Multi-AZ và automatic failover | ✅ | ❌ | | Bền vững (snapshot, AOF) | ✅ | ❌ | | Cấu trúc dữ liệu phong phú | ✅ | chỉ key-value | | Pub/sub, transaction, Lua | ✅ | ❌ | | Đa luồng | có I/O threading | ✅ từ đầu |

Quy tắc: cần sẵn sàng cao thì phải dùng Redis, không có ngoại lệ.

Ba chế độ triển khai ElastiCache Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, tới 5 replica | | Cluster mode enabled | tới 500 shard, mỗi shard có replica | | Serverless | tự co giãn, Multi-AZ mặc định |

Ba tình huống kích hoạt chuyển đổi: | Tình huống | Chi tiết | |---|---| | Primary node hỏng | | | AZ chứa primary mất kết nối | | | Bảo trì có kế hoạch | vá lỗi engine |

Ba đặc điểm của chuyển đổi: | Đặc điểm | Chi tiết | |---|---| | Thường dưới 1 phút | | | Endpoint KHÔNG đổi | DNS trỏ sang node mới | | Có thể mất một ít dữ liệu chưa sao chép | sao chép là BẤT ĐỒNG BỘ |

Dòng cuối là đánh đổi cần biết:

Redis sao chép BẤT ĐỒNG BỘ
    → ghi vừa xong có thể chưa tới replica
    → chuyển đổi có thể mất vài ghi cuối
        ↓
    Với bộ đệm: chấp nhận được
    Với dữ liệu KHÔNG THỂ MẤT: dùng MemoryDB

ElastiCache và MemoryDB — bảng phân biệt: | | ElastiCache Redis | MemoryDB for Redis | |---|---|---| | Vai trò | bộ ĐỆM | DATABASE CHÍNH | | Bền vững | snapshot định kỳ | transaction log đa AZ | | Mất dữ liệu khi chuyển đổi | có thể | KHÔNG | | Giá | thấp hơn | cao hơn |

Nếu Redis là nguồn dữ liệu duy nhất (phiên người dùng chẳng hạn), MemoryDB an toàn hơn.

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

Ba lưu ý về ứng dụng phía client: | Lưu ý | Chi tiết | |---|---| | Phải xử lý lỗi kết nối tạm thời | có thử lại | | KHÔNG cache DNS quá lâu | endpoint đổi khi chuyển đổi | | Dùng primary endpoint, không dùng IP | |

Dòng giữa là nguyên nhân sự cố kéo dài:

JVM mặc định cache DNS VĨNH VIỄN với một số cấu hình
    → sau chuyển đổi, client vẫn gọi node CŨ
    → lỗi kéo dài dù ElastiCache đã chuyển đổi xong
        ↓
    Đặt networkaddress.cache.ttl = 60 hoặc thấp hơn

Ba loại endpoint của ElastiCache Redis: | Endpoint | Trỏ tới | |---|---| | Primary | node ghi hiện tại | | Reader | cân bằng tải qua các replica | | Configuration | với cluster mode enabled |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | EngineCPUUtilization | CPU của tiến trình Redis | | DatabaseMemoryUsagePercentage | gần đầy thì có eviction | | ReplicationLag | replica tụt lại bao xa |

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Chụp từ REPLICA để không ảnh hưởng primary | | | Giữ tới 35 ngày | | | Xuất sang S3 được | |

Ba lưu ý về nâng cấp và bảo trì: | Lưu ý | Chi tiết | |---|---| | Đặt maintenance window vào giờ thấp điểm | | | Multi-AZ giảm ảnh hưởng của bảo trì | vá replica trước | | THỬ chuyển đổi để xác nhận ứng dụng chịu được | |

Thử chuyển đổi có chủ đích:

aws elasticache test-failover   --replication-group-id cum-phien --node-group-id 0001

Đây là cách duy nhất biết chắc ứng dụng xử lý được chuyển đổi.

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Mỗi replica tính phí như một node đầy đủ | | | Multi-AZ tăng chi phí tương ứng số replica | | | Reserved node giảm tới 55% | |

Và một lời khuyên: hãy chạy test-failover trong giờ thấp điểm ngay sau khi bật Multi-AZ. Cơ chế chuyển đổi của AWS hoạt động đáng tin cậy, nhưng phía ứng dụng thì không chắc — và việc cache DNS hoặc thiếu logic thử lại chỉ lộ ra đúng vào lúc chuyển đổi thật, tức là lúc bạn ít muốn phát hiện nó nhất.

Đáp án

C — Dùng AWS IAM Identity Center kết hợp AWS Managed Microsoft AD với quan hệ tin cậy HAI CHIỀU tới Active Directory tại chỗ.

Vì sao đúng

Đề nêu ba yêu cầu, và kết hợp này đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Dùng thông tin đăng nhập AD hiện có | quan hệ tin cậy tới AD tại chỗ | | Truy cập nhiều tài khoản AWS | IAM Identity Center gán quyền theo tài khoản | | Ít công vận hành nhất | dịch vụ được quản lý, không viết mã |

Kiến trúc:

AD tại chỗ (nguồn danh tính gốc)
    ↕ quan hệ tin cậy HAI CHIỀU
AWS Managed Microsoft AD (trong VPC)
    ↓ làm nguồn danh tính
IAM Identity Center
    ↓ gán permission set cho từng tài khoản
Nhiều tài khoản AWS trong Organizations

Và vì sao cần tin cậy HAI CHIỀU:

Một chiều (AWS tin AD tại chỗ):
    → AWS xác thực được người dùng của AD tại chỗ
    → nhưng một số thao tác cần chiều ngược lại

Hai chiều:
    → cả hai miền đều xác thực được người dùng của nhau
    → hỗ trợ đầy đủ mọi kịch bản, kể cả tài nguyên lai

Triển khai:

aws ds create-microsoft-ad --name corp.example.com   --password '<mat-khau>' --edition Standard   --vpc-settings VpcId=vpc-abc,SubnetIds=subnet-a,subnet-b

aws ds create-trust --directory-id d-abc123   --remote-domain-name onprem.example.com   --trust-password '<mat-khau-tin-cay>'   --trust-direction Two-Way --trust-type Forest

Rồi trỏ IAM Identity Center vào thư mục đó:

IAM Identity Center → Settings → Identity source → Active Directory
    → chọn AWS Managed Microsoft AD
        ↓
    Người dùng đăng nhập bằng tài khoản AD của công ty

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

• **D. Dùng AD Connector cùng IAM Identity Center — đây là phương án gần nhất và thực sự là cách kết nối AD nhẹ nhất (không sao chép danh tính, chỉ chuyển tiếp xác thực), nhưng nó không phải lựa chọn được khuyến nghị cho kịch bản đa tài khoản có tài nguyên trong VPC: AD Connector chỉ là proxy, không lưu gì, nên mọi lần xác thực đều phụ thuộc kết nối tới AD tại chỗ — mất kết nối là mất đăng nhập. AWS Managed Microsoft AD có bản sao chạy trong AWS.
• **B. Tạo IAM user riêng ở mỗi tài khoản rồi đồng bộ mật khẩu — công vận hành cao nhất và rủi ro bảo mật: nhân bản danh tính ra nhiều nơi, mật khẩu đồng bộ thủ công, không có đăng nhập một lần.
• **A. Dùng Amazon Cognito user pool — sai đối tượng: Cognito dành cho người dùng ứng dụng (khách hàng), không phải cho nhân viên truy cập Console AWS.

Ghi nhớ

Ba cách kết nối Active Directory với AWS — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | AWS Managed Microsoft AD | AD THẬT chạy trong AWS, tin cậy được với AD tại chỗ | | AD Connector | PROXY — chuyển tiếp xác thực, KHÔNG lưu gì | | Simple AD | tương thích Samba, KHÔNG tin cậy được với AD thật |

Từ khoá nhận diện:

"trust relationship with on-premises AD", "AD-aware workloads in AWS" → AWS Managed Microsoft AD "just proxy authentication, no directory in AWS" → AD Connector "standalone, low cost, no on-premises AD" → Simple AD

AWS Managed Microsoft AD và AD Connector — bảng phân biệt: | | Managed Microsoft AD | AD Connector | |---|---|---| | Lưu danh tính trong AWS | ✅ | ❌ | | Hoạt động khi mất kết nối tại chỗ | ✅ | ❌ | | Quan hệ tin cậy | ✅ | ❌ | | Hỗ trợ tải AD-aware (RDS SQL Server, FSx) | ✅ | hạn chế | | Chi phí | cao hơn | thấp hơn |

Ba chiều của quan hệ tin cậy: | Chiều | Nghĩa | |---|---| | One-way incoming | AD tại chỗ tin AWS | | One-way outgoing | AWS tin AD tại chỗ | | Two-way | cả hai tin nhau ← câu này |

Ba khái niệm của IAM Identity Center: | Khái niệm | Việc | |---|---| | Identity source | nguồn danh tính: nội bộ, AD, hoặc IdP ngoài | | Permission set | tập quyền, ánh xạ thành IAM role ở tài khoản đích | | Assignment | gán nhóm × permission set × tài khoản |

Ba nguồn danh tính của IAM Identity Center: | Nguồn | Chi tiết | |---|---| | Identity Center directory | thư mục nội bộ, đơn giản nhất | | Active Directory | ← câu này | | IdP ngoài qua SAML/SCIM | Okta, Entra ID, Google Workspace |

Ba lợi ích của IAM Identity Center so với IAM user: | Lợi ích | Chi tiết | |---|---| | Credential TẠM THỜI | không có access key dài hạn | | Quản lý tập trung nhiều tài khoản | | | Một cổng đăng nhập cho mọi tài khoản | |

Đây là lý do AWS khuyến nghị bỏ hẳn IAM user cho con người.

Ba cách người dùng truy cập: | Cách | Chi tiết | |---|---| | Cổng AWS access portal | chọn tài khoản và vai trò | | AWS CLI với SSO | aws configure sso | | Ứng dụng SAML tích hợp | |

aws configure sso
aws sso login --profile prod

Ba lưu ý về AWS Managed Microsoft AD: | Lưu ý | Chi tiết | |---|---| | Hai phiên bản: Standard và Enterprise | khác nhau ở số đối tượng | | Triển khai qua ít nhất 2 AZ | sẵn sàng cao dựng sẵn | | Cần kết nối mạng tới AD tại chỗ | Direct Connect hoặc VPN |

Dòng cuối là điều kiện bắt buộc:

Quan hệ tin cậy cần kết nối mạng ổn định:
    → Site-to-Site VPN, hoặc
    → Direct Connect (tin cậy hơn)
        ↓
    Và các cổng của AD phải mở (389, 445, 88, 464, 53...)

Ba tải AWS dùng được AD: | Tải | Chi tiết | |---|---| | RDS for SQL Server | xác thực Windows | | FSx for Windows File Server | quyền NTFS theo AD | | WorkSpaces, AppStream | đăng nhập bằng tài khoản công ty | | EC2 Windows | join domain |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Permission set theo quyền tối thiểu | | | Bật MFA ở IAM Identity Center | | | Rà soát assignment định kỳ | |

Ba việc nên làm khi triển khai: | Việc | Chi tiết | |---|---| | Thiết kế nhóm AD ánh xạ sang permission set | | | Bắt đầu với ít permission set | mở rộng dần | | Ghi log truy cập bằng CloudTrail | |

Và một lời khuyên: hãy thiết kế ánh xạ nhóm AD sang permission set trước khi triển khai. Nếu để mỗi đội tự yêu cầu quyền riêng, số permission set sẽ tăng nhanh tới mức không ai rà soát nổi — và một mô hình bốn hoặc năm nhóm rõ ràng sẽ phục vụ tốt hơn nhiều so với hai chục biến thể tuỳ chỉnh.

Đáp án

C — Dùng AWS Cost Optimization Hub cùng AWS Compute Optimizer để phát hiện tài nguyên cấp thừa và tài nguyên nhàn rỗi, rồi hành động theo khuyến nghị.

Vì sao đúng

Đề nêu yêu cầu: giảm chi phí mà không ảnh hưởng hiệu năng, ở nhiều tài khoản.

Cost Optimization Hub:
    → tập hợp MỌI khuyến nghị tiết kiệm ở MỘT chỗ
    → cho cả tổ chức AWS Organizations
    → xếp theo số tiền tiết kiệm được
        ↓
    Biết ngay nên làm gì trước

Và Compute Optimizer đưa ra khuyến nghị dựa trên đo đạc:

Compute Optimizer phân tích metric CloudWatch 14 ngày:
    → EC2 instance: loại nào phù hợp hơn
    → EBS volume: IOPS cấp thừa
    → Lambda: cấu hình bộ nhớ
    → ECS trên Fargate, Auto Scaling group
        ↓
    Khuyến nghị dựa trên MỨC DÙNG THẬT, không đoán

Và đây chính là điểm "không ảnh hưởng hiệu năng":

Compute Optimizer phân loại khuyến nghị:
    Over-provisioned  → giảm được, an toàn
    Under-provisioned → đang THIẾU, nên tăng
    Optimized         → đã phù hợp
        ↓
    Nó cảnh báo cả trường hợp thu nhỏ sẽ GÂY HẠI

Bật cả hai:

aws compute-optimizer update-enrollment-status --status Active   --include-member-accounts

aws cost-optimization-hub update-enrollment-status --status Active

Xem khuyến nghị:

aws cost-optimization-hub list-recommendations   --filter '{"actionTypes":["Rightsize","Stop","Delete"]}'   --order-by '{"dimension":"EstimatedMonthlySavings","order":"Desc"}'

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

• **B. Dùng Cost Explorer phân tích chi tiêu và tự xác định tài nguyên cần thu nhỏ — đây là phương án gần nhất và là công cụ đúng để hiểu chi tiêu, nhưng nó cho biết TIÊU TIỀN Ở ĐÂU, không cho biết CÓ THỂ THU NHỎ ĐƯỢC KHÔNG: Cost Explorer không phân tích metric hiệu năng, nên tự suy ra sẽ có nguy cơ ảnh hưởng hiệu năng — đúng điều đề muốn tránh. (Cost Explorer có tính năng rightsizing recommendation, nhưng nó chính là dữ liệu từ Compute Optimizer.)
• **A. Mua Reserved Instance cho mọi tài nguyên đang chạy — có thể làm tệ hơn: cam kết 1–3 năm cho tài nguyên đang cấp thừa nghĩa là khoá luôn khoản lãng phí. Phải thu nhỏ trước, rồi mới mua cam kết.
• **D. Bật AWS Budgets với cảnh báo — chỉ THÔNG BÁO, không tối ưu gì: Budgets cho biết khi chi tiêu vượt ngưỡng, nhưng không nói tài nguyên nào cấp thừa.

Ghi nhớ

Các công cụ tối ưu chi phí của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | Cost Explorer | PHÂN TÍCH chi tiêu theo thời gian, dịch vụ, tag | | AWS Budgets | CẢNH BÁO khi vượt ngưỡng | | Compute Optimizer | KHUYẾN NGHỊ kích thước dựa trên metric | | Cost Optimization Hub | TẬP HỢP mọi khuyến nghị, xếp theo tiền tiết kiệm | | Trusted Advisor | kiểm tra tổng quát, có mục chi phí | | Cost and Usage Report | dữ liệu thô chi tiết nhất |

Từ khoá nhận diện:

"rightsize without impacting performance" → Compute Optimizer "consolidated savings opportunities across accounts" → Cost Optimization Hub "where is my money going" → Cost Explorer "alert when spending exceeds" → Budgets

Ba loại tài nguyên Compute Optimizer phân tích: | Tài nguyên | Khuyến nghị | |---|---| | EC2 instance | loại và kích thước phù hợp | | EBS volume | loại volume và IOPS | | Lambda function | cấu hình bộ nhớ | | Auto Scaling group | loại instance | | ECS trên Fargate | CPU và bộ nhớ | | RDS (mới) | loại instance |

Ba phân loại khuyến nghị: | Phân loại | Nghĩa | |---|---| | Over-provisioned | cấp thừa — giảm được | | Under-provisioned | đang THIẾU — nên tăng | | Optimized | phù hợp rồi |

Phân loại thứ hai quan trọng ngang phân loại thứ nhất — nó ngăn bạn thu nhỏ nhầm thứ đang chật vật.

Ba mức độ tin cậy của khuyến nghị: | Mức | Ý nghĩa | |---|---| | Cần ít nhất 14 ngày metric | ít hơn thì không đủ dữ liệu | | Bật enhanced infrastructure metrics | dùng 3 tháng dữ liệu, chính xác hơn | | Có performanceRisk cho mỗi khuyến nghị | 0–4, càng thấp càng an toàn |

Bảy hướng tối ưu chi phí trên AWS: | Hướng | Chi tiết | |---|---| | ① Thu nhỏ tài nguyên cấp thừa | ← câu này | | ② Xoá tài nguyên nhàn rỗi | EIP không gắn, volume mồ côi, snapshot cũ | | ③ Mua Savings Plans / RI cho phần nền | SAU KHI đã thu nhỏ | | ④ Dùng Spot cho tải chịu gián đoạn | | | ⑤ Chuyển sang Graviton | rẻ hơn ~20% | | ⑥ Lifecycle cho S3 và EBS snapshot | | | ⑦ Tắt tài nguyên ngoài giờ làm việc | môi trường dev |

Thứ tự rất quan trọng:

Thu nhỏ TRƯỚC, mua cam kết SAU
    → mua RI cho instance cấp thừa = khoá lãng phí 1–3 năm
        ↓
    Đây là lý do phương án A sai

Ba nguồn lãng phí phổ biến nhất: | Nguồn | Chi tiết | |---|---| | Instance cấp thừa | thường 30–50% tài nguyên | | EBS volume không gắn vào đâu | tính phí đầy đủ | | Snapshot cũ tích tụ | không ai dọn | | Elastic IP không gắn | ~0,005 USD/giờ mỗi cái | | NAT Gateway ở môi trường dev | ~32 USD/tháng mỗi cái |

Tìm volume mồ côi:

aws ec2 describe-volumes --filters Name=status,Values=available   --query 'Volumes[].{Id:VolumeId,Size:Size,Created:CreateTime}' --output table

Ba tính năng của Cost Optimization Hub: | Tính năng | Chi tiết | |---|---| | Tập hợp khuyến nghị từ nhiều nguồn | Compute Optimizer, Cost Explorer, Trusted Advisor | | Khử trùng lặp | không đếm hai lần cùng một khoản | | Xem theo toàn tổ chức | từ tài khoản quản lý |

Ba lưu ý khi thực hiện khuyến nghị: | Lưu ý | Chi tiết | |---|---| | Bắt đầu với môi trường không sản xuất | | | Thay đổi từng đợt nhỏ | dễ quay lại | | Theo dõi metric sau khi đổi | xác nhận hiệu năng không giảm |

Ba metric cần theo dõi sau khi thu nhỏ: | Metric | Ngưỡng cảnh báo | |---|---| | CPU utilization | thường xuyên trên 80% | | Memory (cần CloudWatch agent) | | | Độ trễ ứng dụng | chỉ số quan trọng nhất |

Ba lưu ý về tag: | Lưu ý | Chi tiết | |---|---| | Tag cho phép quy chi phí về đội, môi trường | | | Bật cost allocation tag trong Billing | | | Dùng tag policy để ép nhất quán | |

Không có tag thì không biết ai đang tiêu tiền — và đó là rào cản lớn nhất cho việc tối ưu ở tổ chức nhiều tài khoản.

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | Xem Cost Optimization Hub | hàng tháng | | Dọn tài nguyên mồ côi | hàng tháng | | Rà soát mức phủ Savings Plans | hàng quý |

Và một lời khuyên: hãy bật enhanced infrastructure metrics cho Compute Optimizer. Với 14 ngày dữ liệu mặc định, một tải có chu kỳ theo tháng (chốt sổ cuối tháng chẳng hạn) có thể bị đánh giá là cấp thừa — và thu nhỏ đúng trước kỳ chốt sổ là cách nhanh nhất để biến một dự án tiết kiệm chi phí thành một sự cố.

Đáp án

C — Dùng S3 multipart upload để chia tệp thành nhiều phần và tải song song.

Vì sao đúng

Đề cho một con số quyết định: tệp 1 TB.

Giới hạn của S3:
    PutObject một lần:  TỐI ĐA 5 GB
    Multipart upload:   TỐI ĐA 5 TB
        ↓
    Tệp 1 TB BẮT BUỘC phải dùng multipart

Và AWS khuyến nghị dùng multipart cho tệp trên 100 MB.

Ba lợi ích của multipart upload: | Lợi ích | Chi tiết | |---|---| | Tải SONG SONG nhiều phần | nhanh hơn nhiều | | Thử lại chỉ phần LỖI | không phải tải lại từ đầu | | Tạm dừng và tiếp tục được | |

Vế thứ hai là lợi ích lớn nhất với tệp 1 TB:

Tải một lần, hỏng ở 90%:
    → mất toàn bộ, phải làm lại từ đầu

Multipart, một phần hỏng:
    → chỉ tải lại phần đó (ví dụ 100 MB)
        ↓
    Với tệp rất lớn, khác biệt này quyết định việc có tải xong được hay không

AWS CLI tự dùng multipart:

aws configure set default.s3.multipart_threshold 100MB
aws configure set default.s3.multipart_chunksize 100MB
aws configure set default.s3.max_concurrent_requests 20

aws s3 cp du-lieu-1tb.dat s3://kho-du-lieu/

aws s3 cp tự chia phần — không phải gọi API thủ công.

Và nhớ dọn phần dở dang:

{"Rules": [{"ID": "don-phan-do-dang", "Status": "Enabled", "Filter": {},
            "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Phần đã tải nhưng chưa hoàn tất:
    → KHÔNG hiện trong danh sách object
    → nhưng VẪN TÍNH PHÍ lưu trữ
        ↓
    Với tệp 1 TB, một lần tải hỏng để lại khoản phí đáng kể

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

• **A. Dùng S3 Transfer Acceleration — đây là phương án gần nhất và thực sự tăng tốc độ tải lên (qua edge location của CloudFront), nhưng nó không giải quyết giới hạn 5 GB: Transfer Acceleration tối ưu đường truyền, còn multipart giải quyết kích thước. Tệp 1 TB vẫn cần multipart dù có bật Transfer Acceleration hay không. (Hai thứ này dùng CÙNG nhau được và thường nên dùng cùng.)
• **B. Dùng AWS Snowball — quá nặng cho một tệp: Snowball dùng khi có hàng chục terabyte trở lên và băng thông không đủ. Cho một tệp 1 TB, chờ thiết bị vận chuyển lâu hơn nhiều so với tải trực tiếp.
• **D. Nén tệp trước khi tải — không giải quyết vấn đề: tệp nén vẫn có thể vượt 5 GB, và với dữ liệu đã nén hoặc dữ liệu nhị phân, tỷ lệ nén rất thấp.

Ghi nhớ

Giới hạn kích thước của S3 — bảng phải thuộc: | Giới hạn | Giá trị | |---|---| | Object tối đa | 5 TB | | PutObject một lần | 5 GB | | Mỗi part của multipart | 5 MB – 5 GB (part cuối được nhỏ hơn) | | Số part tối đa | 10.000 |

Suy ra kích thước part tối thiểu cho tệp lớn:

Tệp 1 TB ÷ 10.000 part = ~107 MB mỗi part (tối thiểu)
        ↓
    Dùng part 100 MB thì cần ~10.500 part → VƯỢT giới hạn
    → phải dùng part lớn hơn, ví dụ 200 MB

Đây là phép tính hay bị bỏ qua và gây lỗi giữa chừng.

Ba giai đoạn của multipart upload: | Giai đoạn | API | |---|---| | Khởi tạo | CreateMultipartUpload → nhận UploadId | | Tải từng phần | UploadPart → nhận ETag mỗi phần | | Hoàn tất | CompleteMultipartUpload với danh sách ETag |

Hoặc huỷ:

aws s3api abort-multipart-upload --bucket kho-du-lieu   --key du-lieu-1tb.dat --upload-id <upload-id>

Tìm phần dở dang:

aws s3api list-multipart-uploads --bucket kho-du-lieu

Ba công cụ tăng tốc tải lên S3: | Công cụ | Việc | |---|---| | Multipart upload | chia phần, tải song song ← câu này | | S3 Transfer Acceleration | qua edge location, tốt cho khoảng cách xa | | AWS DataSync | di chuyển hàng loạt có lịch |

Ba thứ này bổ sung nhau.

Ba lưu ý về Transfer Acceleration: | Lưu ý | Chi tiết | |---|---| | Dùng endpoint riêng | <bucket>.s3-accelerate.amazonaws.com | | Có PHÍ THÊM | ~0,04 USD/GB | | Chỉ đáng khi khoảng cách xa | |

Kiểm tra có đáng dùng không:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html

AWS có công cụ đo so sánh trực tiếp — nếu không nhanh hơn thì không nên trả thêm phí.

Ba cách chuyển dữ liệu lớn lên AWS: | Cách | Quy mô phù hợp | |---|---| | Tải trực tiếp (multipart) | tới vài TB ← câu này | | DataSync | TB tới PB, có lịch | | Snowball Edge | hàng chục TB tới PB | | Snowmobile | exabyte |

Quy tắc ước lượng thời gian:

Thời gian (giờ) = Dung lượng (TB) × 1000 × 8 ÷ (Băng thông Mbps × 3600) × 1000
        ↓
    1 TB qua đường 1 Gbps ≈ 2,5 giờ (lý tưởng)
    1 TB qua đường 100 Mbps ≈ 25 giờ

So con số này với thời gian chờ Snowball (khoảng một tuần) để quyết định.

Ba lưu ý về hiệu năng multipart: | Lưu ý | Chi tiết | |---|---| | Tăng max_concurrent_requests | mặc định 10, tăng lên 20–50 | | Kích thước part hợp lý | 100–500 MB cho tệp rất lớn | | Chạy từ EC2 trong cùng Region nếu nguồn ở AWS | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tải LÊN S3 MIỄN PHÍ | chỉ tính phí request | | Phần dở dang VẪN TÍNH PHÍ | ← lifecycle dọn | | Transfer Acceleration có phí riêng | |

Ba lưu ý về tính toàn vẹn: | Lưu ý | Chi tiết | |---|---| | S3 kiểm tra checksum mỗi part | | | Dùng --checksum-algorithm cho kiểm tra đầu cuối | SHA256, CRC32 | | ETag của object multipart KHÔNG phải MD5 của toàn tệp | |

Dòng cuối hay gây nhầm:

Object tải một lần:    ETag = MD5 của nội dung
Object multipart:       ETag = <hash của các hash>-<số part>
        ↓
    So ETag với MD5 cục bộ sẽ KHÔNG khớp
    → dùng checksum của S3 thay vì ETag

Ba trường hợp nên dùng multipart: | Trường hợp | Lý do | |---|---| | Tệp trên 100 MB | khuyến nghị của AWS | | Tệp trên 5 GB | BẮT BUỘC | | Đường truyền không ổn định | thử lại từng phần |

Và một lời khuyên: hãy thêm quy tắc AbortIncompleteMultipartUpload vào mọi bucket ngay hôm nay. Phần tải dở dang không xuất hiện ở bất kỳ danh sách object nào, nên khoản phí này tích tụ hoàn toàn vô hình — và với tệp cỡ terabyte, chỉ vài lần tải thất bại là đủ tạo ra một khoản chi phí đáng kể mà không có gì trong console giải thích nó từ đâu ra.

Đáp án

D — Gộp nhiều bản ghi thành lô trong mỗi request để giảm số lời gọi API tới stream.

Vì sao đúng

Đề nêu lỗi cụ thể: ProvisionedThroughputExceededException, và yêu cầu chi phí thấp nhất.

ProvisionedThroughputExceededException xảy ra khi vượt:
    → 1.000 BẢN GHI mỗi giây, hoặc
    → 1 MB dữ liệu mỗi giây
    trên MỘT SHARD

Và với dữ liệu cảm biến, giới hạn bị chạm thường là SỐ BẢN GHI:

Cảm biến gửi bản ghi rất nhỏ (vài trăm byte)
    → 1.000 bản ghi/giây × 300 byte = 300 KB/giây
    → còn xa giới hạn 1 MB/giây
        ↓
    Chạm trần SỐ BẢN GHI trước, chứ không phải dung lượng

Gộp lô giải quyết chính xác vấn đề đó:

Trước: 5.000 bản ghi/giây = 5.000 lời gọi PutRecord
    → cần 5 shard

Sau: gộp 10 bản ghi vào một PutRecords
    → 500 lời gọi/giây, 1,5 MB/giây
    → cần 2 shard
        ↓
    Giảm số shard = giảm chi phí

Hai cách gộp:

# Cách 1: PutRecords — nhiều bản ghi trong một request API
kinesis.put_records(
    StreamName='du-lieu-cam-bien',
    Records=[{'Data': d, 'PartitionKey': k} for d, k in cac_ban_ghi])

PutRecords: tối đa 500 bản ghi hoặc 5 MB mỗi request
    → giảm số REQUEST API
    → nhưng mỗi bản ghi vẫn tính riêng vào giới hạn 1.000/giây

# Cách 2: Aggregation của KPL — gộp thành MỘT bản ghi Kinesis
# Nhiều bản ghi người dùng → một bản ghi Kinesis

Aggregation của Kinesis Producer Library:
    → nhiều bản ghi ứng dụng đóng gói thành MỘT bản ghi Kinesis
    → giảm được cả giới hạn 1.000 bản ghi/giây
        ↓
    Đây là cách hiệu quả nhất cho bản ghi nhỏ

Và vì sao đây là lựa chọn rẻ nhất:

Thêm shard:  tăng chi phí tuyến tính
Gộp lô:      KHÔNG tốn thêm gì, chỉ sửa phía producer

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

• **C. Tăng số shard của stream — đây là phương án gần nhất và chắc chắn giải quyết được lỗi, nhưng nó tốn tiền: mỗi shard tính phí theo giờ, và với bản ghi nhỏ thì phần lớn dung lượng shard bị lãng phí. Đề hỏi "at MINIMUM cost".
• **A. Chuyển sang Kinesis Data Firehose — thay đổi kiến trúc và mất tính năng: Firehose không giữ dữ liệu, không cho nhiều consumer đọc lại, và có độ trễ tối thiểu khoảng 60 giây. Nếu ứng dụng cần xử lý thời gian thực thì đây là bước lùi.
• **B. Bật enhanced fan-out — giải quyết vấn đề PHÍA ĐỌC: enhanced fan-out cho mỗi consumer 2 MB/giây riêng. Lỗi trong đề là ở phía GHI, và enhanced fan-out còn tốn thêm phí.

Ghi nhớ

Giới hạn của một shard Kinesis — bảng phải thuộc: | Chiều | Giới hạn | |---|---| | Ghi | 1.000 bản ghi/giây HOẶC 1 MB/giây | | Đọc (chia sẻ) | 2 MB/giây, tối đa 5 lời gọi GetRecords/giây | | Đọc (enhanced fan-out) | 2 MB/giây RIÊNG mỗi consumer |

Điểm mấu chốt: giới hạn ghi có HAI vế — chạm vế nào cũng bị throttle.

Ba cách xử lý ProvisionedThroughputExceededException: | Cách | Chi phí | |---|---| | Gộp lô (batching, aggregation) | miễn phí ← câu này | | Thêm shard | tăng tuyến tính | | Chuyển sang on-demand | tự co giãn, đắt hơn khi tải cao ổn định | | Thử lại có backoff | giảm nhẹ, không giải quyết gốc |

Hai chế độ dung lượng của Kinesis Data Streams: | Chế độ | Đặc điểm | |---|---| | Provisioned | khai số shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn tới 200 MB/giây, không quản shard |

On-demand đáng cân nhắc nếu tải khó đoán:

aws kinesis update-stream-mode --stream-arn <arn>   --stream-mode-details StreamMode=ON_DEMAND

On-demand tự thích ứng tới GẤP ĐÔI đỉnh 30 ngày trước
    → không phải tính shard
    → nhưng đắt hơn provisioned khi tải cao và ổn định

Ba API ghi vào Kinesis: | API | Đặc điểm | |---|---| | PutRecord | một bản ghi mỗi lời gọi | | PutRecords | tới 500 bản ghi hoặc 5 MB mỗi lời gọi | | KPL với aggregation | gộp thành một bản ghi Kinesis |

Và PutRecords có thể thành công MỘT PHẦN:

kq = kinesis.put_records(StreamName='du-lieu-cam-bien', Records=cac_ban_ghi)
if kq['FailedRecordCount'] > 0:
    that_bai = [cac_ban_ghi[i] for i, r in enumerate(kq['Records'])
                if 'ErrorCode' in r]
    # thử lại RIÊNG những bản ghi này

Không kiểm tra FailedRecordCount là mất dữ liệu âm thầm — đây là lỗi rất phổ biến.

Ba lưu ý về partition key: | Lưu ý | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | băm MD5 của key | | Phân bố ĐỀU để tránh hot shard | | | Cùng key = cùng shard = giữ THỨ TỰ | |

Hot shard là nguyên nhân ẩn của throttle:

Stream có 10 shard, tổng dung lượng thừa sức
    → nhưng 80% bản ghi dùng cùng một partition key
    → dồn vào MỘT shard → shard đó bị throttle
        ↓
    CloudWatch metric ở cấp stream trông vẫn bình thường
    → phải bật metric cấp SHARD mới thấy

aws kinesis enable-enhanced-monitoring --stream-name du-lieu-cam-bien   --shard-level-metrics IncomingRecords IncomingBytes WriteProvisionedThroughputExceeded

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | WriteProvisionedThroughputExceeded | bị throttle phía ghi ← lỗi trong đề | | ReadProvisionedThroughputExceeded | throttle phía đọc | | IteratorAgeMilliseconds | consumer tụt lại bao xa |

Ba thao tác quản lý shard: | Thao tác | Việc | |---|---| | UpdateShardCount | đổi số shard, tối đa gấp đôi mỗi lần | | Split shard | tách một shard thành hai | | Merge shard | gộp hai shard liền kề |

aws kinesis update-shard-count --stream-name du-lieu-cam-bien   --target-shard-count 4 --scaling-type UNIFORM_SCALING

Ba lưu ý về chi phí Kinesis: | Khoản | Chi tiết | |---|---| | Shard-giờ | ~0,015 USD/giờ mỗi shard | | PUT payload unit | tính theo đơn vị 25 KB | | Enhanced fan-out | phí riêng mỗi consumer-shard-giờ |

"PUT payload unit" là chi tiết đáng biết:

Mỗi bản ghi tính tối thiểu MỘT đơn vị 25 KB
    → bản ghi 500 byte vẫn tính như 25 KB
        ↓
    Gộp lô cũng TIẾT KIỆM khoản này
    → gộp 50 bản ghi 500 byte = 1 đơn vị thay vì 50

Đây là lý do thứ hai khiến gộp lô là giải pháp rẻ nhất.

Ba lựa chọn thay thế Kinesis Data Streams: | Lựa chọn | Khi nào | |---|---| | Firehose | chỉ cần nạp vào S3/Redshift, chấp nhận độ trễ | | Amazon MSK | đã dùng Kafka | | IoT Core | thiết bị IoT với MQTT |

Ba lưu ý cho dữ liệu cảm biến: | Lưu ý | Chi tiết | |---|---| | Gộp ở phía thiết bị nếu được | giảm cả băng thông | | Nén dữ liệu | giảm PUT payload unit | | Cân nhắc IoT Core cho hàng nghìn thiết bị | |

Và một lời khuyên: hãy bật shard-level metrics trước khi thêm shard. Nếu nguyên nhân là hot shard chứ không phải thiếu dung lượng, thêm shard sẽ tốn tiền mà lỗi vẫn còn nguyên — và metric ở cấp stream sẽ tiếp tục trông hoàn toàn bình thường suốt thời gian đó.

Đáp án

D — Cấu hình tác vụ sao chép của AWS DMS Serverless để đồng bộ dữ liệu hiện có và thay đổi liên tục giữa Oracle tại chỗ và Amazon RDS for Oracle.

Vì sao đúng

Đề nêu ba yêu cầu, và DMS Serverless đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Sao chép dữ liệu HIỆN CÓ và thay đổi LIÊN TỤC | full-load + CDC | | Lượng dữ liệu DAO ĐỘNG trong ngày | DMS Serverless tự co giãn | | Tự cấp phát năng lực theo nhu cầu thật | không chọn cỡ replication instance |

Vế thứ hai và ba là điểm phân biệt:

DMS truyền thống:
    → phải chọn cỡ replication instance
    → cấp cho đỉnh tải → trả tiền thừa lúc thấp điểm
    → cấp cho mức trung bình → chậm lúc cao điểm

DMS Serverless:
    → tự co giãn giữa MinCapacityUnits và MaxCapacityUnits
    → trả theo lượng dùng thật
        ↓
    Đúng "automatically provision compute based on actual requirements"

Cấu hình:

aws dms create-replication-config   --replication-config-identifier oracle-sang-rds   --source-endpoint-arn <arn-oracle-tai-cho>   --target-endpoint-arn <arn-rds-oracle>   --replication-type full-load-and-cdc   --compute-config '{"MinCapacityUnits":2,"MaxCapacityUnits":32,
                     "MultiAZ":true,
                     "ReplicationSubnetGroupId":"nhom-subnet"}'   --table-mappings file://anh-xa.json

Và full-load-and-cdc xử lý cả hai vế của đề:

Giai đoạn ①: full load — chuyển toàn bộ dữ liệu hiện có
Giai đoạn ②: CDC — bắt thay đổi liên tục từ redo log
        ↓
    Chuyển liền mạch, không phải dừng nguồn

Và Oracle sang Oracle không cần chuyển đổi schema:

Cùng engine → không cần AWS Schema Conversion Tool
    → chỉ cần DMS

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

• **A. Triển khai replication instance của DMS trên EC2 với script tự theo dõi CPU và đổi kích thước bằng EC2 Auto Scaling — đây là phương án gần nhất vì cũng dùng DMS, nhưng nó hiểu sai kiến trúc: replication instance của DMS là tài nguyên do AWS quản lý, không phải EC2 bạn tự dựng. Và tự viết script co giãn là đúng thứ DMS Serverless đã làm sẵn.
• **B. Dùng AWS Glue trích xuất rồi ghi vào RDS, chạy theo yêu cầu khi phát hiện thay đổi — không có CDC thật: Glue không đọc redo log của Oracle, nên "phát hiện thay đổi" phải tự dựng, thường bằng cách quét bảng — chậm và bỏ sót bản ghi bị xoá.
• **C. Dùng Lambda bắt thay đổi từ Oracle tại chỗ rồi ghi vào RDS — phải tự viết toàn bộ cơ chế CDC: đọc redo log của Oracle là việc phức tạp, và Lambda có giới hạn 15 phút mỗi lần chạy.

Ghi nhớ

Ba thành phần của AWS DMS truyền thống: | Thành phần | Việc | |---|---| | Replication instance | máy chạy việc sao chép | | Endpoint | nguồn và đích | | Task | ánh xạ bảng và quy tắc chuyển đổi |

DMS Serverless bỏ thành phần đầu.

DMS và DMS Serverless — bảng phân biệt: | | DMS truyền thống | DMS Serverless | |---|---|---| | Chọn cỡ instance | ✅ phải chọn | ❌ | | Tự co giãn | ❌ | ✅ | | Tính phí | theo instance-giờ | theo capacity unit dùng thật | | Phù hợp | tải ổn định, biết trước | tải dao động ← câu này |

Ba loại tác vụ di chuyển: | Loại | Việc | |---|---| | full-load | dữ liệu hiện có, một lần | | cdc | chỉ thay đổi | | full-load-and-cdc | cả hai — gián đoạn tối thiểu ← câu này |

Ba yêu cầu để CDC hoạt động với Oracle: | Yêu cầu | Chi tiết | |---|---| | Bật ARCHIVELOG mode | | | Bật supplemental logging | ở cấp database và bảng | | User DMS có quyền đọc redo log | |

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER TABLE don_hang ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Thiếu bước này thì full load chạy được nhưng CDC không bắt được thay đổi — và lỗi không hiện ra ngay.

Hai cách DMS đọc redo log của Oracle: | Cách | Đặc điểm | |---|---| | Oracle LogMiner | mặc định, dùng tài nguyên của database nguồn | | Binary Reader | nhanh hơn, ít ảnh hưởng nguồn hơn |

Với khối lượng thay đổi lớn, Binary Reader là lựa chọn tốt hơn.

Ba công cụ di chuyển database của AWS: | Công cụ | Việc | |---|---| | AWS DMS | di chuyển dữ liệu, có CDC | | AWS SCT | chuyển đổi SCHEMA khi ĐỔI engine | | AWS DMS Fleet Advisor | khảo sát môi trường nguồn |

Oracle sang Oracle KHÔNG cần SCT — chỉ cần khi đổi engine (Oracle sang PostgreSQL chẳng hạn).

Ba lựa chọn chạy Oracle trên AWS: | Lựa chọn | Truy cập OS | |---|---| | RDS for Oracle | ❌, ít công vận hành nhất | | RDS Custom for Oracle | ✅, cho ứng dụng cần tuỳ chỉnh | | Oracle trên EC2 | ✅ toàn quyền |

Ba lưu ý về giấy phép Oracle trên RDS: | Mô hình | Chi tiết | |---|---| | License Included | chỉ cho Standard Edition Two | | BYOL | cho Enterprise Edition | | — | kiểm tra điều khoản giấy phép trước khi chuyển |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CDCLatencySource | độ trễ đọc từ nguồn | | CDCLatencyTarget | độ trễ ghi vào đích | | CDCIncomingChanges | lượng thay đổi đang chờ |

Hai metric đầu phân biệt được nút thắt nằm ở đâu:

CDCLatencySource cao:  nguồn tạo thay đổi nhanh hơn DMS đọc được
CDCLatencyTarget cao:  đích ghi không kịp
        ↓
    Hai nguyên nhân, hai cách xử lý khác nhau

Ba việc cần kiểm tra sau khi di chuyển: | Việc | Chi tiết | |---|---| | Validation của DMS | so sánh dữ liệu nguồn và đích | | Đếm số dòng từng bảng | | | Kiểm tra ràng buộc và index | DMS KHÔNG tự tạo index phụ |

aws dms create-replication-task --enable-task-assessment   --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}'

Dòng cuối là điểm hay bị quên:

DMS chuyển DỮ LIỆU, không chuyển đầy đủ:
    ✗ index phụ
    ✗ sequence
    ✗ trigger, procedure, function
        ↓
    Phải tạo riêng ở đích sau khi full load xong

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Tắt index và ràng buộc ở đích trong lúc full load | nhanh hơn nhiều | | Bật lại sau khi xong | | | Dùng nhiều task song song cho bảng lớn | |

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Cần kết nối từ AWS tới Oracle tại chỗ | VPN hoặc Direct Connect | | Băng thông ảnh hưởng trực tiếp tốc độ full load | | | Direct Connect ổn định hơn cho khối lượng lớn | |

Và một lời khuyên: hãy bật validation của DMS ngay từ đầu. Nó so từng dòng giữa nguồn và đích trong lúc sao chép chạy, và phát hiện chênh lệch sớm — còn nếu đợi tới lúc chuyển đổi rồi mới kiểm tra, bạn sẽ phải chọn giữa việc lùi lại hoặc chấp nhận một cơ sở dữ liệu mà bạn không chắc là đầy đủ.

Đáp án

C — Bật S3 Bucket Keys cho mã hoá SSE-KMS, để object mới dùng khoá cấp bucket thay vì gọi KMS cho từng object.

Vì sao đúng

Đề nêu chính xác vấn đề: chi phí request KMS tăng mạnh do tần suất tải lên và truy cập cao, và cần giữ nguyên phương pháp mã hoá.

SSE-KMS không có Bucket Keys:
    → MỖI thao tác PUT gọi kms:GenerateDataKey
    → MỖI thao tác GET gọi kms:Decrypt
        ↓
    Hàng triệu object = hàng triệu lời gọi KMS

S3 Bucket Keys giải quyết triệt để:

Bật Bucket Keys:
    → S3 lấy MỘT bucket-level key từ KMS
    → dùng nó tạo khoá dữ liệu cho NHIỀU object
    → bucket key có hiệu lực trong một khoảng thời gian ngắn
        ↓
    GIẢM TỚI 99% số lời gọi KMS

Và điểm quan trọng: phương pháp mã hoá KHÔNG đổi.

✓ vẫn là SSE-KMS
✓ vẫn dùng cùng khoá KMS đó
✓ vẫn kiểm soát bằng key policy
✓ chỉ giảm SỐ LƯỢNG lời gọi API
        ↓
    Đúng "maintain the same encryption method"

Bật cho bucket:

aws s3api put-bucket-encryption --bucket kho-tai-nguyen   --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "<arn-khoa>"},
      "BucketKeyEnabled": true}]}'

Và tiết kiệm rất lớn:

10 triệu request/tháng với SSE-KMS:
    Không Bucket Keys: 10.000.000 lời gọi × 0,03 USD/10.000 = 30 USD
    Có Bucket Keys:    ~100.000 lời gọi = 0,3 USD
        ↓
    Và con số này nhân lên theo quy mô

Đánh đổi cần biết:

Bucket Keys giảm số lời gọi KMS
    → log CloudTrail cũng ÍT CHI TIẾT hơn
    → không còn một bản ghi cho mỗi object
        ↓
    Với yêu cầu audit từng object, đây là điều cần cân nhắc

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

• **A. Chuyển sang SSE-S3 để bỏ hẳn phí KMS — đây là phương án gần nhất và loại bỏ chi phí KMS hoàn toàn (SSE-S3 miễn phí), nhưng nó thay đổi phương pháp mã hoá, trái yêu cầu của đề. Và mệnh đề "maintaining the same level of encryption CONTROL" trong phương án là sai: SSE-S3 không có key policy, không có audit qua CloudTrail, không kiểm soát được ai dùng khoá.
• **B. Cấu hình VPC endpoint cho S3 và giới hạn truy cập qua đó — giải quyết vấn đề khác: VPC endpoint tiết kiệm phí NAT Gateway và truyền dữ liệu, hoàn toàn không ảnh hưởng số lời gọi KMS.
• **D. Mã hoá phía client rồi tải khoá đối xứng lên S3 cùng metadata của object — lỗi bảo mật nghiêm trọng: lưu khoá cạnh dữ liệu đã mã hoá làm việc mã hoá trở nên vô nghĩa. Ai đọc được object thì cũng đọc được khoá.

Ghi nhớ

Cơ chế của S3 Bucket Keys — sơ đồ cần hiểu:

KHÔNG có Bucket Keys:
    PUT object → GenerateDataKey → KMS  (mỗi object một lời gọi)
    GET object → Decrypt        → KMS  (mỗi object một lời gọi)

CÓ Bucket Keys:
    S3 lấy MỘT bucket key từ KMS
        → dùng nó sinh khoá dữ liệu cho NHIỀU object
        → chỉ gọi lại KMS khi bucket key hết hiệu lực

Ba đặc điểm của S3 Bucket Keys: | Đặc điểm | Chi tiết | |---|---| | Giảm tới 99% lời gọi KMS | | | Chỉ áp cho object MỚI | object cũ phải sao chép lại | | MIỄN PHÍ | không có phí riêng |

Dòng giữa quan trọng:

# Áp Bucket Keys cho object đã có
aws s3 cp s3://kho-tai-nguyen/ s3://kho-tai-nguyen/ --recursive   --sse aws:kms --sse-kms-key-id <arn> --bucket-key-enabled   --metadata-directive REPLACE

Hoặc dùng S3 Batch Operations cho khối lượng lớn.

Năm cách mã hoá S3 — bảng phải thuộc: | Cách | Ai giữ khoá | Audit | Phí KMS | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | ❌ | không | | SSE-KMS | KMS, bạn kiểm soát | ✅ | có | | SSE-KMS + Bucket Keys | như trên | ít chi tiết hơn | giảm 99% | | DSSE-KMS | mã hoá hai lớp | ✅ | cao hơn | | SSE-C | bạn gửi mỗi request | ❌ | không |

Ba khoản chi phí của KMS: | Khoản | Giá tham khảo | |---|---| | Lưu khoá | ~1 USD/khoá/tháng | | Lời gọi API | ~0,03 USD mỗi 10.000 | | Mỗi phiên bản do xoay vòng | ~1 USD/tháng |

Ba cách giảm chi phí KMS: | Cách | Tiết kiệm | |---|---| | S3 Bucket Keys | tới 99% cho S3 ← câu này | | Đệm khoá dữ liệu ở phía ứng dụng | với SDK mã hoá | | Dùng SSE-S3 cho dữ liệu ít nhạy cảm | miễn phí hoàn toàn |

Ba lưu ý khi chọn giữa SSE-S3 và SSE-KMS: | Yếu tố | SSE-S3 | SSE-KMS | |---|---|---| | Cần audit ai dùng khoá | ❌ | ✅ | | Cần key policy riêng | ❌ | ✅ | | Cần chia sẻ xuyên tài khoản có kiểm soát | ❌ | ✅ | | Chi phí | miễn phí | có phí |

Quy tắc: dữ liệu nhạy cảm hoặc có yêu cầu tuân thủ → SSE-KMS; còn lại → SSE-S3.

Ba lưu ý về CloudTrail với Bucket Keys: | Lưu ý | Chi tiết | |---|---| | Bản ghi KMS ít đi đáng kể | một bản ghi cho nhiều object | | resourceARN là bucket, không phải object | | | Data event của S3 vẫn ghi đủ | bật riêng nếu cần audit từng object |

aws cloudtrail put-event-selectors --trail-name audit-s3   --advanced-event-selectors '[{"Name":"S3 data events",
    "FieldSelectors":[{"Field":"eventCategory","Equals":["Data"]},
                      {"Field":"resources.type","Equals":["AWS::S3::Object"]}]}]'

Ba lưu ý về hạn mức request của KMS: | Lưu ý | Chi tiết | |---|---| | Hạn mức mặc định vài chục nghìn request/giây | tuỳ Region | | Vượt hạn mức gây ThrottlingException | request S3 THẤT BẠI | | Bucket Keys giảm rủi ro này đáng kể | |

Dòng giữa là hậu quả nghiêm trọng hơn cả tiền:

KMS bị throttle
    → S3 không lấy được khoá
    → GET và PUT THẤT BẠI
        ↓
    Đây là lý do thứ hai (và quan trọng hơn) để bật Bucket Keys

Ba cách theo dõi: | Cách | Việc | |---|---| | CloudWatch metric của KMS | số request | | Cost Explorer lọc theo KMS | chi phí | | CloudTrail | ai gọi |

Ba lưu ý khi bật Bucket Keys: | Lưu ý | Chi tiết | |---|---| | Không đổi cách ứng dụng gọi S3 | hoàn toàn trong suốt | | Kiểm tra chi phí KMS sau một tuần | xác nhận đã giảm | | Cân nhắc tác động lên audit | |

Và một lời khuyên: hãy bật Bucket Keys cho mọi bucket dùng SSE-KMS, kể cả bucket lưu lượng thấp. Nó miễn phí, trong suốt với ứng dụng, và ngoài việc tiết kiệm tiền còn giảm hẳn nguy cơ bị KMS throttle — một loại sự cố có triệu chứng rất khó hiểu vì lỗi hiện ra ở S3 chứ không phải ở KMS.

Đáp án

B — Auto Scaling group với dung lượng tối thiểu 4 (2 instance ở mỗi AZ trong HAI AZ khác nhau), dung lượng tối đa 6.

Vì sao đúng

Đề nêu hai dữ kiện quyết định: | Dữ kiện | Kết luận | |---|---| | Tải bình thường cần 2 instance | phải luôn có 2 máy PHỤC VỤ ĐƯỢC | | Ứng dụng phải TIN CẬY (xe cứu thương, bệnh nhân nguy kịch) | mất một AZ vẫn phải đủ 2 máy |

Phép tính:

Yêu cầu: sau khi mất MỘT AZ vẫn còn 2 máy phục vụ
    ↓
Với 2 AZ, mỗi AZ phải có 2 máy
    → tổng tối thiểu = 4
        ↓
    Mất AZ-A: còn 2 máy ở AZ-B ✓
    Mất AZ-B: còn 2 máy ở AZ-A ✓

Và vì sao min = 2 (phương án A) là không đủ:

Min 2, mỗi AZ 1 máy:
    → mất một AZ → CHỈ CÒN 1 MÁY
    → không đủ tải bình thường
        ↓
    ASG sẽ khởi động máy thay thế, nhưng mất vài phút
    → với ứng dụng cứu thương, vài phút là quá lâu

Đây là công thức N+1 theo AZ:

Số máy mỗi AZ = (số máy cần phục vụ) ÷ (số AZ − 1)
    = 2 ÷ (2 − 1) = 2 máy mỗi AZ
        ↓
    Tổng = 2 AZ × 2 máy = 4

Cấu hình:

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-cuu-thuong   --launch-template LaunchTemplateId=lt-abc,Version='$Latest'   --min-size 4 --desired-capacity 4 --max-size 6   --vpc-zone-identifier "subnet-az-a,subnet-az-c"   --health-check-type ELB --health-check-grace-period 300

Và ASG tự cân bằng giữa các AZ:

AZ rebalancing:
    → ASG cố giữ số máy đều giữa các AZ
    → khởi động vào AZ có ít máy nhất
    → chấm dứt từ AZ có nhiều máy nhất
        ↓
    Không phải quản lý phân bố thủ công

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

• **A. Min = 2 (một máy mỗi AZ trong hai AZ), max = 6 — đây là phương án gần nhất và có trải qua hai AZ, nhưng nó không chịu được mất một AZ: còn lại một máy, không đủ tải bình thường. Với ứng dụng y tế khẩn cấp, đó là mức rủi ro không chấp nhận được.
• **D. Min = 4 (2 máy ở mỗi REGION trong hai Region), max = 6 — ASG KHÔNG trải qua Region được: Auto Scaling group là tài nguyên theo Region, chỉ trải qua các AZ trong cùng Region.
• **C. Min = 2, max = 6 trong MỘT AZ duy nhất — không chịu lỗi: AZ đó hỏng là mất toàn bộ ứng dụng.

Ghi nhớ

Công thức N+1 theo AZ — nên thuộc:

Số máy mỗi AZ = (số máy cần phục vụ) ÷ (số AZ − 1)
Tổng tối thiểu = số AZ × số máy mỗi AZ

Bảng tính nhanh cho tải cần 2 máy: | Số AZ | Máy mỗi AZ | Tổng | Máy dư thừa | |---|---|---|---| | 1 | 2 | 2 | 0 — không chịu lỗi | | 2 | 2 | 4 | 2 (100% dư) | | 3 | 1 | 3 | 1 (50% dư) |

Ba AZ tiết kiệm hơn hai AZ cho cùng mức chịu lỗi — đây là chi tiết đáng nhớ:

2 AZ: cần 4 máy để chịu mất 1 AZ
3 AZ: cần 3 máy để chịu mất 1 AZ
        ↓
    Ít máy hơn mà chịu lỗi tương đương

Ba tham số dung lượng của ASG: | Tham số | Nghĩa | |---|---| | MinSize | KHÔNG BAO GIỜ xuống dưới — sàn chịu lỗi | | DesiredCapacity | số máy hiện tại mong muốn | | MaxSize | trần khi mở rộng |

MinSize là tham số đảm bảo chịu lỗi — nó quyết định số máy tối thiểu luôn có.

Ba cơ chế ASG duy trì phân bố đều: | Cơ chế | Chi tiết | |---|---| | AZ rebalancing | tự cân bằng khi lệch | | Khởi động vào AZ có ít máy nhất | | | Chấm dứt từ AZ có nhiều máy nhất | chính sách mặc định |

Ba cấu hình health check quan trọng: | Cấu hình | Chi tiết | |---|---| | HealthCheckType = ELB | thay máy mà ỨNG DỤNG hỏng, không chỉ EC2 hỏng | | HealthCheckGracePeriod | đủ dài cho thời gian khởi động | | Health check của target group | kiểm tra đường đi thật |

HealthCheckType = EC2 (mặc định) là chưa đủ:

EC2 health check chỉ kiểm tra máy có chạy không
    → ứng dụng treo mà máy vẫn chạy → ASG KHÔNG thay
        ↓
    Với ứng dụng quan trọng, luôn dùng ELB

Ba loại scaling policy phù hợp: | Loại | Khi nào | |---|---| | Target tracking | đơn giản nhất, giữ metric ở mức mục tiêu | | Step scaling | kiểm soát chi tiết | | Scheduled scaling | tải biết trước theo giờ |

Ba lưu ý về MaxSize: | Lưu ý | Chi tiết | |---|---| | Chạm trần thì KHÔNG mở rộng thêm | không có lỗi rõ ràng | | Đặt cao hơn đỉnh dự kiến | có biên an toàn | | Đặt alarm khi chạm trần | |

Ba lưu ý về AZ: | Lưu ý | Chi tiết | |---|---| | AZ là trung tâm dữ liệu độc lập | điện, mạng, làm mát riêng | | Cách nhau đủ xa để không cùng hỏng | | | Đủ gần để độ trễ dưới 2 mili giây | |

Ba lớp cần dư thừa cho ứng dụng quan trọng: | Lớp | Cơ chế | |---|---| | Tính toán | ASG đa AZ ← câu này | | Cân bằng tải | ALB tự dư thừa qua các AZ | | Dữ liệu | RDS Multi-AZ, hoặc DynamoDB |

Dư thừa ở tầng tính toán mà database chỉ có một AZ là chưa đủ — điểm hỏng đơn chỉ chuyển sang chỗ khác.

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Min 4 nghĩa là luôn trả tiền cho 4 máy | | | Savings Plans cho phần nền | tiết kiệm tới 72% | | Đây là chi phí của độ tin cậy | với ứng dụng y tế, xứng đáng |

Ba việc nên làm để xác nhận thiết kế: | Việc | Chi tiết | |---|---| | Thử tắt hết máy trong một AZ | xác nhận ứng dụng vẫn phục vụ | | Dùng AWS Fault Injection Service | mô phỏng mất AZ có kiểm soát | | Đo thời gian ASG thay máy | |

aws fis create-experiment-template --cli-input-json file://thu-nghiem-mat-az.json

Và một lời khuyên: hãy thực sự thử mất một AZ thay vì chỉ tin vào phép tính. Với MinSize = 4, lý thuyết nói bạn còn 2 máy — nhưng nếu tầng database chỉ có một AZ, hoặc ứng dụng giữ trạng thái trong bộ nhớ của từng máy, kết quả thực tế sẽ khác hẳn con số trên giấy.