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

Đáp án

**B — Dùng AWS Storage Gateway kiểu File Gateway đặt tại chỗ, để ứng dụng tiếp tục ghi qua NFS/SMB trong khi dữ liệu được lưu vào Amazon S3.

Vì sao đúng

Đề nêu ràng buộc quyết định:

Ứng dụng tại chỗ ghi tệp qua
  giao thức chia sẻ tệp
        ↓
    KHÔNG sửa được ứng dụng
        ↓
    Nhưng cần dữ liệu nằm trên
      đám mây

⚠ File Gateway là cầu nối chính xác cho việc này:

Ứng dụng ghi vào NFS/SMB
    → File Gateway nhận
        ↓
    Gateway ghi lên S3 dưới dạng
      OBJECT
        ↓
    Mỗi tệp = một object, đọc được
      trực tiếp bằng API S3

⚠ Điểm mấu chốt: tệp trở thành object gốc, không phải khối nhị phân: | Kiểu gateway | Dữ liệu trên S3 | |---|---| | File Gateway | object đọc được bằng S3 API | | Volume Gateway | snapshot EBS, KHÔNG đọc trực tiếp | | Tape Gateway | băng ảo trong Glacier |

Cần phân tích dữ liệu bằng Athena
  hoặc Glue
        ↓
    Chỉ File Gateway cho phép
    → Volume và Tape Gateway lưu
      định dạng riêng

Tạo file share:

aws storagegateway create-nfs-file-share \
  --client-token $(uuidgen) \
  --gateway-arn <arn-gateway> \
  --location-arn arn:aws:s3:::du-lieu-ung-dung \
  --role arn:aws:iam::111122223333:role/StorageGatewayS3 \
  --client-list 10.0.0.0/16 \
  --default-storage-class S3_STANDARD_IA

⚠ Và gateway có cache cục bộ — đây là lý do hiệu năng chấp nhận được:

Gateway giữ cache trên đĩa cục bộ
    → dữ liệu vừa ghi/vừa đọc
      nằm ở cache
        ↓
    Truy cập nóng: nhanh như đĩa
      cục bộ
        ↓
    Truy cập nguội: kéo từ S3
    → chậm hơn

⚠ Kích thước cache là thông số phải tính đúng:

Cache nhỏ hơn tập dữ liệu nóng
    → gateway liên tục kéo từ S3
        ↓
    Hiệu năng sụt thảm hại
    → AWS khuyến nghị cache tối
      thiểu 150 GB

⚠ Và DataSync (phương án A) là công cụ khác hẳn: | Tiêu chí | DataSync | File Gateway | |---|---|---| | Kiểu hoạt động | đồng bộ theo lô, theo lịch | truy cập liên tục | | Ứng dụng thấy gì | thư mục cục bộ như cũ | share NFS/SMB do gateway phục vụ | | Dùng khi | di trú một lần, sao lưu định kỳ | mở rộng lưu trữ liên tục |

DataSync: chép dữ liệu lên S3
    → nhưng ứng dụng vẫn ghi vào
      đĩa cục bộ
    → đĩa vẫn đầy

⚠ Và đây là điểm phân biệt quan trọng nhất trong câu này:

Vấn đề của đề: hết dung lượng
  tại chỗ
        ↓
    DataSync sao chép, không giải
      phóng chỗ
    → File Gateway biến S3 thành
      dung lượng gần như vô hạn

⚠ Và Volume Gateway (phương án C) không cho ứng dụng dùng NFS:

Volume Gateway phục vụ iSCSI
    → là thiết bị KHỐI, không
      phải chia sẻ tệp
        ↓
    Ứng dụng ghi qua NFS/SMB
    → phải định dạng và mount
      thủ công

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ứng dụng không cần sửa gì | | | Dung lượng gần như vô hạn | | | Dữ liệu là object S3, dùng được ngay trên đám mây | |

⚠ Và vòng đời S3 giảm chi phí lưu trữ dài hạn:

{"Rules": [{
  "Status": "Enabled",
  "Transitions": [
    {"Days": 30, "StorageClass": "STANDARD_IA"},
    {"Days": 90, "StorageClass": "GLACIER_IR"}]}]}

⚠ Nhưng phải cẩn thận với lớp lưu trữ lạnh:

Tệp chuyển sang Glacier
    → gateway KHÔNG đọc được
      ngay lập tức
        ↓
    Ứng dụng đọc tệp cũ
    → lỗi hoặc treo
        ↓
    Glacier Instant Retrieval thì
      đọc được ngay

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

• **A. Dùng AWS DataSync đồng bộ dữ liệu lên S3 — đây là phương án gần nhất và thật sự đưa dữ liệu lên đám mây hiệu quả, nhưng nó sao chép theo lô; ứng dụng vẫn ghi vào đĩa cục bộ nên vấn đề hết dung lượng không được giải quyết.
• **C. Dùng Volume Gateway — phục vụ qua iSCSI (thiết bị khối), không phải NFS/SMB; và dữ liệu trên S3 ở dạng snapshot EBS, không đọc trực tiếp được.
• **D. Sửa ứng dụng để ghi thẳng vào S3 bằng API — đề nói rõ không sửa được ứng dụng.

Ghi nhớ

⚠ Bốn kiểu Storage Gateway — bảng phải thuộc: | Kiểu | Giao thức | Đích trên AWS | |---|---|---| | S3 File Gateway | NFS, SMB | object S3 | | FSx File Gateway | SMB | Amazon FSx for Windows | | Volume Gateway | iSCSI | snapshot EBS | | Tape Gateway | iSCSI VTL | S3 Glacier |

Từ khoá nhận diện:

"application writes to NFS/SMB, keep it unchanged" → File Gateway "one-time migration of file data" → DataSync "backup software writing to tape" → Tape Gateway "block storage with cloud backup" → Volume Gateway "low-latency access to Windows file share" → FSx File Gateway

⚠ Volume Gateway có hai chế độ: | Chế độ | Dữ liệu chính nằm ở | |---|---| | Cached | S3, cache cục bộ cho phần nóng | | Stored | đĩa cục bộ, sao lưu không đồng bộ lên S3 |

Cached: dung lượng gần vô hạn
    → độ trễ cao hơn khi cache miss
        ↓
    Stored: nhanh như đĩa cục bộ
    → nhưng giới hạn bằng đĩa

Ba lưu ý về File Gateway: | Lưu ý | Chi tiết | |---|---| | Cache tối thiểu 150 GB | | | Mỗi tệp là một object riêng | | | Đổi object trên S3 cần RefreshCache | |

⚠ RefreshCache là điểm hay bị bỏ sót:

aws storagegateway refresh-cache \
  --file-share-arn <arn-share> --recursive

Ghi object thẳng vào S3 từ nơi khác
    → gateway KHÔNG tự biết
        ↓
    Client NFS không thấy tệp mới
    → phải gọi RefreshCache

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Băng thông lên AWS là nút thắt | | | Direct Connect ổn định hơn Internet | | | Nhiều tệp nhỏ chậm hơn ít tệp lớn | |

Ba lưu ý về vòng đời: | Lưu ý | Chi tiết | |---|---| | Glacier Flexible/Deep: gateway KHÔNG đọc được | | | Glacier Instant Retrieval: đọc được ngay | | | Intelligent-Tiering tự chuyển tầng an toàn | |

Ba lưu ý về triển khai gateway: | Lưu ý | Chi tiết | |---|---| | Chạy trên VMware, Hyper-V, KVM, hoặc thiết bị phần cứng | | | Cần đĩa riêng cho cache và cho upload buffer | | | Chạy được cả trên EC2 (cho kiến trúc lai) | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá khi truyền (TLS) mặc định | | | SSE-S3 hoặc SSE-KMS trên bucket | | | Giới hạn client-list theo CIDR | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | CachePercentUsed | cache sắp đầy chưa | | CachePercentDirty | bao nhiêu chưa đẩy lên S3 | | CloudBytesUploaded | lượng đã lên đám mây |

⚠ CachePercentDirty cao là dấu hiệu nguy hiểm:

Dữ liệu đã ghi nhưng chưa lên S3
    → gateway hỏng lúc này là
      MẤT dữ liệu đó
        ↓
    Thường do băng thông lên
      không đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một tệp, xem có xuất hiện trong S3 | | | Đo tốc độ ghi qua share | | | Kiểm CachePercentDirty khi tải cao | |

Và một lời khuyên: hãy theo dõi CachePercentDirty chứ đừng chỉ nhìn CachePercentUsed. Cache còn nhiều chỗ trống mà tỷ lệ dirty cao nghĩa là dữ liệu đang ứ lại ở gateway chưa kịp lên S3 — và đó chính là phần dữ liệu sẽ mất nếu thiết bị hỏng.

Đáp án

**A — Tăng dung lượng của volume EBS gp2 để nâng số IOPS cơ sở lên mức cần thiết.

Vì sao đúng

Đề mô tả một ứng dụng bị nghẽn I/O trên volume gp2, và cách tính IOPS của gp2 là chìa khoá:

gp2 cấp 3 IOPS cho mỗi GiB
        ↓
    100 GiB → 300 IOPS
    1.000 GiB → 3.000 IOPS
    5.334 GiB → 16.000 IOPS (trần)

⚠ Và có một sàn tối thiểu: | Dung lượng | IOPS cơ sở | |---|---| | 1-33 GiB | 100 (sàn) | | 100 GiB | 300 | | 334 GiB | 1.000 | | 1.000 GiB | 3.000 | | 5.334 GiB trở lên | 16.000 (trần) |

⚠ Và cơ chế tín dụng bùng nổ là chỗ gây bất ngờ:

Volume dưới 1.000 GiB tích luỹ
  tín dụng I/O khi rảnh
        ↓
    Bùng nổ tới 3.000 IOPS khi cần
        ↓
    Hết tín dụng → tụt về IOPS
      cơ sở
    → hiệu năng sụt đột ngột

Ứng dụng chạy tốt vài giờ đầu
    → rồi bỗng chậm hẳn
        ↓
    Đây là dấu hiệu kinh điển của
      việc cạn tín dụng bùng nổ

Theo dõi tín dụng:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-abc \
  --statistics Average --period 300 \
  --start-time 2026-08-31T00:00:00Z \
  --end-time 2026-08-31T06:00:00Z

⚠ BurstBalance về 0 là bằng chứng rõ ràng nhất:

BurstBalance 100% → còn đầy tín dụng
    → giảm dần → 0%
        ↓
    Từ lúc đó volume bị giới hạn
      ở IOPS cơ sở

Tăng dung lượng:

aws ec2 modify-volume --volume-id vol-abc --size 1000

# rồi mở rộng hệ thống tệp
sudo growpart /dev/nvme0n1 1
sudo xfs_growfs -d /

⚠ Tăng dung lượng EBS KHÔNG tự mở rộng hệ thống tệp:

`modify-volume` xong
    → `lsblk` thấy đĩa to hơn
        ↓
    `df -h` vẫn thấy dung lượng cũ
    → phải `growpart` rồi `resize2fs`
      hoặc `xfs_growfs`

⚠ Và thay đổi này thực hiện được khi volume đang chạy:

Không cần tháo volume
    → không cần dừng instance
        ↓
    Nhưng phải chờ trạng thái
      "optimizing" xong
    → có thể mất vài giờ với
      volume lớn

⚠ Và có giới hạn: sửa xong phải chờ 6 giờ mới sửa tiếp:

`modify-volume` lần hai trong
  vòng 6 giờ
    → lỗi
        ↓
    Nên tính đủ dung lượng ngay
      lần đầu

⚠ Và IOPS còn bị giới hạn bởi chính instance: | Yếu tố | Giới hạn | |---|---| | Volume gp2 1.000 GiB | 3.000 IOPS | | Instance t3.medium | ~11.800 IOPS (bùng nổ) | | Instance m5.large | ~18.750 IOPS |

Volume cấp 16.000 IOPS
    → instance chỉ chịu được 8.000
        ↓
    Thực tế đạt 8.000
    → phải nâng cả cỡ instance

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Sửa được ngay, không dừng máy | | | Không đổi kiến trúc gì | | | Thêm dung lượng lưu trữ luôn | |

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

⚠ gp3 là câu trả lời đúng hơn, và nó không có trong danh sách.

gp3 ra mắt tháng 12/2020, sau khi câu này được viết: | Tiêu chí | gp2 | gp3 | |---|---|---| | IOPS cơ sở | 3 IOPS/GiB | 3.000 ở MỌI dung lượng | | IOPS tối đa | 16.000 (cần 5.334 GiB) | 16.000 (không cần dung lượng lớn) | | Thông lượng | theo dung lượng | 125 MB/s cơ sở, tới 1.000 MB/s | | Tách IOPS khỏi dung lượng | KHÔNG | CÓ | | Giá lưu trữ | 0,10 USD/GB-tháng | 0,08 USD/GB-tháng (rẻ hơn 20%) |

Cần 3.000 IOPS trên 100 GiB dữ liệu
        ↓
    gp2: phải mua 1.000 GiB
    → trả tiền cho 900 GiB không dùng
        ↓
    gp3: 100 GiB, 3.000 IOPS miễn phí
    → rẻ hơn nhiều lần

Chuyển sang gp3 không cần dừng máy:

aws ec2 modify-volume --volume-id vol-abc \
  --volume-type gp3 --iops 6000 --throughput 250

Với kiến thức hiện tại, việc "tăng dung lượng gp2 để có thêm IOPS" là mẫu chống lãng phí cần tránh, chứ không phải giải pháp nên chọn.

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

• **B. Chuyển sang volume io1/io2 Provisioned IOPS — đây là phương án gần nhất và thật sự cấp được IOPS cao, nhưng đắt hơn đáng kể; chỉ nên dùng khi cần trên 16.000 IOPS hoặc cần độ bền 99,999% của io2.
• **C. Thêm RAM cho instance — cache của hệ điều hành giúp phần nào nhưng không giải quyết được nghẽn I/O thật sự.
• **D. Dùng instance store — dữ liệu mất khi dừng instance, không dùng cho dữ liệu cần bền vững.

Ghi nhớ

⚠ Năm loại volume EBS — bảng phải thuộc: | Loại | IOPS tối đa | Hợp với | |---|---|---| | gp3 | 16.000 | mặc định cho hầu hết | | gp2 | 16.000 (theo dung lượng) | thế hệ cũ | | io2 Block Express | 256.000 | CSDL đòi hỏi cao nhất | | st1 | 500 (thông lượng cao) | log, dữ liệu lớn tuần tự | | sc1 | 250 | lưu trữ lạnh, rẻ nhất |

Từ khoá nhận diện:

"need more IOPS, general purpose" → gp3 "over 16,000 IOPS" → io2 Block Express "sequential throughput, big files" → st1 "burst balance depleted" → gp2 hết tín dụng, chuyển gp3 "sub-millisecond, ephemeral" → instance store

⚠ st1 và gp3 khác nhau ở kiểu truy cập:

st1 tối ưu cho ĐỌC TUẦN TỰ
    → thông lượng cao, IOPS thấp
        ↓
    Truy cập ngẫu nhiên trên st1
    → hiệu năng rất tệ
        ↓
    Log, big data, data warehouse
      → st1

Ba lưu ý về gp3: | Lưu ý | Chi tiết | |---|---| | 3.000 IOPS và 125 MB/s miễn phí | | | Trả thêm cho phần vượt | | | Rẻ hơn gp2 20% cùng dung lượng | |

Ba lưu ý về sửa volume: | Lưu ý | Chi tiết | |---|---| | Sửa được khi đang chạy | | | Phải mở rộng hệ thống tệp thủ công | | | Chờ 6 giờ mới sửa lại được | |

Ba lưu ý về giới hạn instance: | Lưu ý | Chi tiết | |---|---| | Mỗi kiểu instance có trần EBS riêng | | | Instance nhỏ có tín dụng EBS như gp2 | | | Kiểm bảng "EBS optimized" trong tài liệu | |

⚠ Instance nhỏ cũng có cơ chế bùng nổ EBS:

t3, t4g và một số m5 nhỏ
    → băng thông EBS cũng theo
      tín dụng
        ↓
    Chạy tải I/O liên tục
    → cả instance lẫn volume
      đều cạn tín dụng

Ba chỉ số cần theo dõi: | Chỉ số | Ý nghĩa | |---|---| | BurstBalance | tín dụng gp2 còn bao nhiêu | | VolumeQueueLength | yêu cầu I/O đang xếp hàng | | VolumeReadOps/WriteOps | IOPS thực tế |

⚠ VolumeQueueLength cao là dấu hiệu nghẽn:

Hàng đợi dài liên tục
    → volume không kịp phục vụ
        ↓
    Với SSD, hàng đợi nên dưới 1
      cho mỗi 500 IOPS đã cấp

Ba lưu ý về RAID: | Lưu ý | Chi tiết | |---|---| | RAID 0 nhiều volume cộng IOPS | | | Nhưng một volume hỏng là mất hết | | | Thường không cần với gp3 và io2 | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo IOPS thực tế bằng iostat hoặc fio | | | So với IOPS đã cấp trong console | | | Kiểm giới hạn EBS của kiểu instance | |

Và một lời khuyên: hãy chuyển sang gp3 thay vì tăng dung lượng gp2. Mua thêm terabyte chỉ để lấy IOPS là trả tiền cho không gian bạn không bao giờ dùng — gp3 tách hai thứ đó ra và thường vừa nhanh hơn vừa rẻ hơn cho cùng một khối lượng công việc.

Đáp án

**A và E — Thêm Read Replica cho RDS ở mỗi Availability Zone, và dựng lớp cache bằng ElastiCache ở mỗi Availability Zone.

Vì sao đúng

Đề khoanh vùng vấn đề rất rõ:

Nội dung tĩnh (ảnh, video) tải nhanh
    → tầng web KHÔNG có vấn đề
        ↓
    Thông tin khách hàng lấy từ CSDL
      thì chậm
    → nghẽn nằm ở TẦNG CSDL

Đây là lý do phương án F (CloudFront) sai — CloudFront tăng tốc nội dung tĩnh, mà nội dung tĩnh vốn đã nhanh.

⚠ Và hai đáp án tấn công cùng vấn đề theo hai hướng bổ trợ nhau: | Cách | Giảm gì | |---|---| | Read replica | chia tải đọc ra nhiều instance | | ElastiCache | loại bỏ hẳn lượt truy vấn tới CSDL |

⚠ ElastiCache mạnh hơn ở chỗ nó chặn truy vấn từ gốc:

Read replica: 100.000 truy vấn
  vẫn tới CSDL, chỉ chia ra
  nhiều máy
        ↓
    Cache: truy vấn lặp lại trả từ
      bộ nhớ
    → CSDL chỉ nhận phần cache miss
        ↓
    Với 100.000 yêu cầu đồng thời,
      cache là thứ tạo khác biệt
      lớn nhất

Mẫu cache-aside:

import json, redis, pymysql
cache = redis.Redis(host='cum-cache.abc.cache.amazonaws.com')

def lay_khach_hang(ma):
    khoa = f'kh:{ma}'
    if (dl := cache.get(khoa)):
        return json.loads(dl)
    with ket_noi.cursor() as cur:
        cur.execute('SELECT * FROM khach_hang WHERE ma=%s', (ma,))
        kq = cur.fetchone()
    cache.setex(khoa, 300, json.dumps(kq))
    return kq

⚠ setex với thời hạn là chi tiết bắt buộc:

`set` không hạn: dữ liệu cũ nằm
  trong cache mãi mãi
        ↓
    Khách sửa thông tin
    → website vẫn hiện bản cũ
        ↓
    TTL buộc cache làm mới định kỳ

Tạo read replica:

aws rds create-db-instance-read-replica \
  --db-instance-identifier replica-1a \
  --source-db-instance-identifier csdl-chinh \
  --availability-zone ap-southeast-1a

⚠ Và ứng dụng phải chủ động gửi truy vấn đọc sang replica:

Tạo replica xong không tự có
  tác dụng
        ↓
    Mỗi replica có endpoint RIÊNG
    → ứng dụng phải tách kết nối
      đọc và ghi
        ↓
    Đây là việc phải sửa mã

⚠ Và replica có độ trễ sao chép — phải chấp nhận được:

Sao chép KHÔNG đồng bộ
    → ghi vào chính rồi đọc từ
      replica ngay
    → có thể chưa thấy
        ↓
    Với thông tin khách hàng
      đọc nhiều ghi ít
    → chấp nhận được

⚠ Và Multi-AZ standby không giúp gì cho việc đọc:

Đề nói CSDL đã là Multi-AZ
        ↓
    Standby CHỈ để chuyển đổi khi hỏng
    → không phục vụ truy vấn
        ↓
    Đây là nhầm lẫn rất phổ biến

⚠ Và phương án C (nâng cỡ instance) là mở rộng ĐỨNG:

Máy to hơn giúp được một quãng
    → rồi chạm trần kiểu instance
      lớn nhất
        ↓
    Và tốn tiền cả 24/7 dù chỉ
      cao điểm lúc ra mắt
    → không hiệu quả chi phí

⚠ Và sharding (phương án B) là thay đổi kiến trúc rất lớn:

Chia dữ liệu ra nhiều instance
    → ứng dụng phải biết dữ liệu
      nào ở đâu
        ↓
    Truy vấn liên shard rất khó
    → và không quay lui được
        ↓
    Không phải giải pháp "hiệu quả
      chi phí" cho một đợt ra mắt

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cache chặn phần lớn truy vấn lặp lại | | | Replica chia phần còn lại ra nhiều máy | | | Cả hai gỡ bỏ được sau đợt cao điểm | |

⚠ Và điểm cuối là lý do hiệu quả chi phí:

Đợt ra mắt kéo dài vài ngày
    → thêm replica và cache trước
        ↓
    Xong thì xoá bớt
    → chỉ trả tiền đúng lúc cần

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

• **C. Nâng cỡ instance RDS và tăng IOPS đã cấp — đây là phương án gần nhất và thật sự cải thiện được hiệu năng, nhưng mở rộng đứng có trần, và phải trả tiền cỡ lớn liên tục dù cao điểm chỉ vài ngày.
• **B. Chia shard tầng CSDL ra nhiều instance MySQL — thay đổi kiến trúc rất lớn, đòi sửa nhiều ở ứng dụng, không hợp với việc chuẩn bị gấp cho một đợt ra mắt.
• **D. Chuyển sang Amazon Keyspaces — đó là dịch vụ tương thích Cassandra, mô hình dữ liệu hoàn toàn khác MySQL; viết lại toàn bộ tầng dữ liệu.
• **F. Dựng CloudFront — nội dung tĩnh đã nhanh sẵn; nghẽn nằm ở truy vấn CSDL.

Ghi nhớ

⚠ Bốn cách mở rộng tầng đọc — bảng phải thuộc: | Cách | Giảm tải kiểu gì | |---|---| | ElastiCache | loại bỏ truy vấn | | Read replica | chia truy vấn ra nhiều máy | | Nâng cỡ instance | mỗi máy làm nhiều hơn | | Sharding | chia dữ liệu ra nhiều máy |

Từ khoá nhận diện:

"database slow, static content fine" → cache + read replica "repeated identical queries" → ElastiCache "read-heavy workload" → read replica "static content slow globally" → CloudFront "write throughput limit" → sharding hoặc Aurora

⚠ Redis và Memcached — bảng phải thuộc: | Tiêu chí | Redis | Memcached | |---|---|---| | Cấu trúc dữ liệu | list, set, sorted set, hash | chỉ chuỗi | | Bền vững | CÓ (snapshot, AOF) | KHÔNG | | Sao chép | CÓ | KHÔNG | | Đa luồng | hạn chế | CÓ | | Pub/Sub | CÓ | KHÔNG |

Cần sẵn sàng cao và nhiều kiểu
  dữ liệu → Redis
        ↓
    Chỉ cần cache đơn giản, nhiều
      lõi CPU → Memcached

Ba chiến lược cache: | Chiến lược | Cách làm | |---|---| | Cache-aside (lazy) | ứng dụng đọc cache, miss thì đọc CSDL rồi ghi cache | | Write-through | ghi vào cache và CSDL cùng lúc | | Write-behind | ghi cache trước, đẩy xuống CSDL sau |

⚠ Cache-aside là mặc định an toàn:

Cache chết → ứng dụng vẫn chạy,
  chỉ chậm hơn
        ↓
    Write-through: cache luôn mới
    → nhưng ghi chậm hơn
        ↓
    Write-behind: nhanh nhất
    → nhưng mất dữ liệu nếu cache
      chết trước khi đẩy xuống

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 replica (RDS), 15 (Aurora) | | | Nâng cấp thành standalone được | | | Aurora có reader endpoint tự cân bằng | |

⚠ Aurora reader endpoint là ưu thế lớn:

RDS: mỗi replica một endpoint
    → ứng dụng phải tự chia tải
        ↓
    Aurora: MỘT reader endpoint
    → tự phân phối tới mọi replica
    → thêm replica không cần sửa mã

Ba lưu ý về vô hiệu hoá cache: | Lưu ý | Chi tiết | |---|---| | Luôn đặt TTL | | | Xoá khoá khi dữ liệu đổi | | | Cache stampede khi nhiều khoá hết hạn cùng lúc | |

⚠ Cache stampede là sự cố thật:

1.000 khoá hết hạn cùng lúc
    → 1.000 truy vấn đồng loạt
      xuống CSDL
        ↓
    CSDL sập đúng lúc đông khách
        ↓
    Thêm nhiễu ngẫu nhiên vào TTL
    → 300 + random(0, 60) giây

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Standby KHÔNG phục vụ đọc (kiểu instance) | | | Multi-AZ DB cluster thì reader đọc được | | | Đó là sẵn sàng cao, không phải mở rộng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo tỷ lệ cache hit (CacheHitRate) | | | Xem ReplicaLag có tăng không | | | Chạy thử tải trước ngày ra mắt | |

Và một lời khuyên: hãy chạy thử tải với đúng lượng đồng thời dự kiến trước ngày ra mắt. Cache và replica giải quyết đúng vấn đề, nhưng tỷ lệ cache hit thực tế chỉ đo được bằng lưu lượng thật — và một tỷ lệ hit 40% thay vì 95% nghĩa là CSDL vẫn nhận gấp mười lần lượng truy vấn bạn tính toán.

Đáp án

**A — Nhập chứng chỉ do một CA bên thứ ba đáng tin cậy ký vào ACM rồi gắn vào ALB; đặt Viewer Protocol Policy là HTTPS Only trên CloudFront và dùng chứng chỉ SSL/TLS từ CA bên thứ ba đã nhập vào ACM hoặc kho chứng chỉ IAM.

Vì sao đúng

Đề hỏi cách dựng HTTPS đầu cuối, tức là mã hoá trên cả hai chặng:

Người xem ←HTTPS→ CloudFront
        ↓
CloudFront ←HTTPS→ ALB (origin)

⚠ Hai chặng cần hai chứng chỉ khác nhau, ở hai nơi khác nhau: | Chặng | Chứng chỉ ở đâu | Yêu cầu | |---|---|---| | Người xem ↔ CloudFront | ACM ở us-east-1, hoặc IAM store | CA công cộng tin cậy | | CloudFront ↔ ALB | ACM cùng Region với ALB | CA công cộng, KHÔNG tự ký |

⚠ Đây là lý do phương án C sai — chứng chỉ tự ký:

CloudFront BẮT BUỘC origin dùng
  chứng chỉ do CA công cộng ký
        ↓
    Tự ký → CloudFront từ chối kết nối
    → lỗi 502
        ↓
    Khác với ALB, nơi tự ký vẫn
      dùng được (chỉ trình duyệt
      cảnh báo)

⚠ Và đây là lý do phương án D sai — Match Viewer:

Match Viewer: người xem gửi HTTP
    → CloudFront cũng gọi origin
      bằng HTTP
        ↓
    Chặng đó KHÔNG mã hoá
    → không còn là HTTPS đầu cuối

⚠ Và đây là lý do phương án B sai — nhập vào S3:

S3 là kho lưu trữ object
    → KHÔNG phải kho chứng chỉ
        ↓
    Chỉ ACM và kho chứng chỉ IAM
      giữ được chứng chỉ dùng cho
      CloudFront

⚠ Và ràng buộc Region của ACM là điều phải nhớ:

Chứng chỉ cho CloudFront
    → BẮT BUỘC ở us-east-1
        ↓
    Chứng chỉ cho ALB
    → ở CHÍNH Region của ALB
        ↓
    Cùng một tên miền thường phải
      cấp hai lần, ở hai Region

Nhập chứng chỉ:

aws acm import-certificate --region us-east-1 \
  --certificate fileb://chung-chi.pem \
  --private-key fileb://khoa-rieng.pem \
  --certificate-chain fileb://chuoi-ca.pem

Cấu hình giao thức tới origin:

{"CustomOriginConfig": {
   "HTTPPort": 80, "HTTPSPort": 443,
   "OriginProtocolPolicy": "https-only",
   "OriginSslProtocols": {"Quantity": 2,
     "Items": ["TLSv1.2", "TLSv1.3"]}}}

⚠ OriginProtocolPolicy: https-only là vế thứ hai, đừng quên:

Đặt Viewer Protocol Policy
  HTTPS Only
        ↓
    Chỉ bảo đảm chặng NGƯỜI XEM
        ↓
    Chặng tới origin do
      OriginProtocolPolicy quyết định
    → thiếu nó là chỉ mã hoá
      nửa đường

⚠ Và tên trong chứng chỉ của ALB phải khớp tên miền origin:

CloudFront gọi origin bằng
  DNS name của ALB
        ↓
    Chứng chỉ cấp cho
      www.cua-hang.vn
    → không khớp tên ALB
    → lỗi xác thực
        ↓
    Giải: trỏ một bản ghi DNS riêng
      (origin.cua-hang.vn) tới ALB
      và cấp chứng chỉ cho tên đó

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mã hoá suốt đường đi | | | HTTPS Only chặn hẳn kết nối không mã hoá | | | ACM tự gia hạn nếu là chứng chỉ do ACM cấp | |

⚠ Nhưng chứng chỉ NHẬP vào thì ACM KHÔNG tự gia hạn:

Chứng chỉ ACM tự cấp (miễn phí)
    → tự gia hạn
        ↓
    Chứng chỉ nhập từ CA bên ngoài
    → PHẢI tự nhập lại trước khi
      hết hạn
        ↓
    ACM gửi thông báo, nhưng nhiều
      sự cố sản xuất bắt nguồn từ
      việc bỏ qua nó

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

⚠ Kho chứng chỉ IAM là cơ chế cũ, chỉ còn để tương thích ngược.

aws iam upload-server-certificate \
  --server-certificate-name chung-chi-cu \
  --certificate-body file://cc.pem --private-key file://khoa.pem

AWS chỉ còn khuyến nghị kho IAM
  cho Region mà ACM chưa có mặt
        ↓
    Với mọi trường hợp khác: ACM

Câu hỏi liệt kê hai lựa chọn như thể ngang nhau, nhưng trong thực tế hiện nay chỉ nên dùng ACM.

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

• **D. Dùng chứng chỉ CA bên thứ ba nhập vào ACM cho ALB, đặt Viewer Protocol Policy Match Viewer — đây là phương án gần nhất và chứng chỉ hai đầu đều đúng, nhưng Match Viewer cho phép chặng HTTP đi qua, phá vỡ yêu cầu mã hoá đầu cuối.
• **C. Tải chứng chỉ tự ký lên ALB — CloudFront từ chối origin dùng chứng chỉ tự ký; kết nối trả 502.
• **B. Nhập chứng chỉ cho CloudFront vào S3 — S3 không phải kho chứng chỉ; CloudFront chỉ đọc từ ACM (us-east-1) hoặc kho chứng chỉ IAM.

Ghi nhớ

⚠ Bốn nơi đặt chứng chỉ TLS trên AWS — bảng phải thuộc: | Dịch vụ | Chứng chỉ ở đâu | |---|---| | CloudFront | ACM us-east-1, hoặc IAM store | | ALB/NLB | ACM cùng Region | | API Gateway edge-optimized | ACM us-east-1 | | API Gateway regional | ACM cùng Region |

Từ khoá nhận diện:

"end-to-end HTTPS" → HTTPS Only + origin protocol https-only "certificate for CloudFront" → ACM ở us-east-1 "self-signed certificate as CloudFront origin" → KHÔNG được "free auto-renewing certificate" → ACM tự cấp

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ACM cấp: miễn phí, tự gia hạn | | | Chứng chỉ nhập vào: tự quản lý gia hạn | | | Xác thực bằng DNS tiện hơn email | |

⚠ Xác thực DNS tự gia hạn được, email thì không:

Xác thực DNS: thêm một bản ghi
  CNAME, để đó
        ↓
    ACM kiểm lại khi gia hạn
    → tự động hoàn toàn
        ↓
    Xác thực email: phải bấm link
      mỗi lần gia hạn

Ba lưu ý về CloudFront và HTTPS: | Lưu ý | Chi tiết | |---|---| | SNI miễn phí, IP riêng ~600 USD/tháng | | | Đặt Minimum Protocol Version TLSv1.2 trở lên | | | Origin dùng cổng tuỳ ý được, khai trong OriginConfig | |

Ba lưu ý về ALB và HTTPS: | Lưu ý | Chi tiết | |---|---| | Gắn nhiều chứng chỉ, chọn theo SNI | | | Chính sách bảo mật quyết định bộ mã | | | Chuyển hướng HTTP→HTTPS ngay ở listener | |

⚠ Chuyển hướng ngay ở ALB:

aws elbv2 create-listener --protocol HTTP --port 80 \
  --default-actions '[{"Type":"redirect","RedirectConfig":
    {"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Ba lưu ý về bảo vệ origin: | Lưu ý | Chi tiết | |---|---| | Header bí mật tuỳ chỉnh từ CloudFront | | | Security group ALB chỉ nhận prefix list CloudFront | | | WAF trên CloudFront chặn trước khi tới ALB | |

⚠ Prefix list là cách sạch nhất:

aws ec2 authorize-security-group-ingress \
  --group-id sg-alb --ip-permissions \
  'IpProtocol=tcp,FromPort=443,ToPort=443,
   PrefixListIds=[{PrefixListId=pl-cloudfront}]'

ALB chỉ nhận lưu lượng từ
  CloudFront
        ↓
    Không ai bỏ qua CDN để gọi
      thẳng ALB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl -v https://ten-mien xem chuỗi chứng chỉ | | | Gọi HTTP — phải bị từ chối hoặc chuyển hướng | | | Bắt gói giữa CloudFront và ALB (qua log) xác nhận HTTPS | |

Và một lời khuyên: hãy đặt lịch nhắc gia hạn cho chứng chỉ nhập từ CA bên ngoài. ACM tự gia hạn chứng chỉ do chính nó cấp, nhưng với chứng chỉ nhập vào thì nó chỉ gửi email cảnh báo — và một chứng chỉ hết hạn lúc nửa đêm sẽ làm cả website ngừng phục vụ mà không có cách nào khắc phục nhanh.

Đáp án

**C, E và F — Cho vai trò mgmt_reviewer quyền đọc bucket S3 và giải mã bằng khoá KMS tuỳ chỉnh; sửa chính sách khoá KMS ở tài khoản Marketing để cấp quyền giải mã cho chính vai trò mgmt_reviewer; và thêm bucket policy cho quyền đọc với Principal là ID tài khoản Management.

Vì sao đúng

Truy cập liên tài khoản vào một bucket được mã hoá bằng khoá KMS tuỳ chỉnh cần ba lớp cho phép, thiếu một là Access Denied: | Lớp | Ở tài khoản | Cho phép gì | |---|---|---| | Chính sách IAM của vai trò | Management | s3:GetObject + kms:Decrypt | | Bucket policy | Marketing | tài khoản Management đọc | | Chính sách khoá KMS | Marketing | vai trò kia giải mã |

⚠ Nguyên tắc liên tài khoản: cả HAI bên phải đồng ý:

Tài khoản A cấp quyền cho vai trò
  của mình
    → chưa đủ
        ↓
    Tài khoản B phải cho phép
      A truy cập tài nguyên
        ↓
    Quyền hiệu lực = GIAO của
      hai bên

⚠ Và khoá KMS là lớp thứ ba mà nhiều người quên:

Bucket policy cho đọc → OK
    → IAM role có s3:GetObject → OK
        ↓
    Object mã hoá bằng SSE-KMS
    → S3 gọi KMS thay mặt người dùng
        ↓
    Chính sách khoá không cho phép
    → AccessDenied
        ↓
    Và thông báo lỗi chỉ nói
      "Access Denied", không nói KMS

Chính sách IAM của vai trò (tài khoản Management):

{"Version": "2012-10-17", "Statement": [
  {"Effect": "Allow",
   "Action": ["s3:GetObject", "s3:ListBucket"],
   "Resource": ["arn:aws:s3:::anh-marketing",
                "arn:aws:s3:::anh-marketing/*"]},
  {"Effect": "Allow",
   "Action": ["kms:Decrypt"],
   "Resource": "arn:aws:kms:ap-southeast-1:111111111111:key/abc"}]}

Bucket policy (tài khoản Marketing):

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::222222222222:root"},
 "Action": ["s3:GetObject", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::anh-marketing",
              "arn:aws:s3:::anh-marketing/*"]}

⚠ Principal phải là tài khoản NHẬN quyền, không phải tài khoản sở hữu:

Phương án B đặt Principal là
  ID tài khoản MARKETING
        ↓
    Marketing đã sở hữu bucket rồi
    → cấp quyền cho chính mình là
      vô nghĩa
        ↓
    Management vẫn bị từ chối

Chính sách khoá KMS (tài khoản Marketing):

{"Sid": "ChoPhepManagementGiaiMa",
 "Effect": "Allow",
 "Principal": {"AWS":
   "arn:aws:iam::222222222222:role/mgmt_reviewer"},
 "Action": ["kms:Decrypt", "kms:DescribeKey"],
 "Resource": "*"}

⚠ Vì sao chọn E (vai trò cụ thể) chứ không D (cả tài khoản):

Đề yêu cầu QUYỀN TỐI THIỂU
        ↓
    D cấp cho toàn bộ tài khoản
      Management
    → mọi danh tính trong đó đều
      giải mã được
        ↓
    E chỉ cấp cho đúng vai trò
      mgmt_reviewer
    → phạm vi hẹp nhất

⚠ Và vì sao chọn F (cả tài khoản) chứ không hẹp hơn ở bucket policy:

Bucket policy không có phương án
  nào trỏ tới vai trò cụ thể
        ↓
    F là lựa chọn duy nhất đúng
      hướng
        ↓
    Và mẫu chuẩn là: bucket policy
      cấp cho TÀI KHOẢN, IAM policy
      bên kia thu hẹp lại

⚠ Đây là mẫu uỷ quyền hai tầng của AWS:

Chủ tài nguyên cho phép tài khoản
  bạn "có thể" truy cập
        ↓
    Quản trị viên tài khoản bạn
      quyết định AI trong đó thật
      sự được truy cập
        ↓
    Không phải quản lý danh sách
      vai trò của tài khoản khác

⚠ Và vì sao loại phương án A:

A cấp "full permissions" cho
  vai trò
        ↓
    Đề nói rõ "quyền tối thiểu
      cần thiết"
    → chỉ cần đọc
        ↓
    Full permissions gồm cả xoá
      và ghi đè

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ đúng vai trò đó giải mã được | | | Chỉ quyền đọc, không sửa được dữ liệu | | | Marketing kiểm soát được toàn bộ ở phía mình | |

⚠ Và quyền sở hữu object là bẫy riêng:

Nếu Management GHI object vào
  bucket của Marketing
        ↓
    Object thuộc về Management
    → Marketing không đọc được
      chính bucket của mình
        ↓
    Bucket Owner Enforced (mặc định
      từ 2023) chấm dứt chuyện này

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

• **D. Sửa chính sách khoá KMS cho phép giải mã với ID tài khoản Management — đây là phương án gần nhất và thật sự làm cho việc truy cập chạy được, nhưng nó cấp quyền cho mọi danh tính trong tài khoản đó, rộng hơn mức tối thiểu cần thiết.
• **B. Bucket policy với Principal là ID tài khoản Marketing — Marketing đã sở hữu bucket; cấp cho chính mình không giúp Management truy cập.
• **A. Cấp cho vai trò toàn quyền trên bucket kèm quyền giải mã — vi phạm nguyên tắc quyền tối thiểu.

Ghi nhớ

⚠ Ba lớp phải kiểm khi gặp AccessDenied liên tài khoản: | Lớp | Câu hỏi | |---|---| | IAM policy | danh tính có được phép không | | Resource policy | tài nguyên có cho phép không | | KMS key policy | khoá có cho giải mã không |

⚠ Và còn hai lớp nữa có thể chặn: | Lớp | Ghi chú | |---|---| | SCP | chặn ở cấp tổ chức | | VPC endpoint policy | chặn nếu đi qua endpoint | | Permissions boundary | giới hạn trần của vai trò |

Từ khoá nhận diện:

"cross-account S3 with KMS" → ba lớp: IAM + bucket + key policy "minimum required permissions" → cấp cho VAI TRÒ, không cho cả tài khoản "Access Denied but policies look right" → kiểm KMS key policy "bucket owner can't read object" → quyền sở hữu object

Ba lưu ý về chính sách khoá KMS: | Lưu ý | Chi tiết | |---|---| | Khoá KMS LUÔN cần chính sách khoá | | | IAM policy một mình KHÔNG đủ | | | Chính sách khoá là nguồn quyền chính | |

⚠ Điểm thứ hai khác hẳn S3:

S3: IAM policy một mình đủ
  (trong cùng tài khoản)
        ↓
    KMS: chính sách khoá phải
      cho phép, dù cùng tài khoản
    → thường bằng câu
      "cho phép IAM policy quyết định"

{"Sid": "ChoPhepIAM", "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::111111111111:root"},
 "Action": "kms:*", "Resource": "*"}

Ba hành động KMS thường cần: | Hành động | Khi nào | |---|---| | kms:Decrypt | đọc object đã mã hoá | | kms:GenerateDataKey | ghi object mới | | kms:DescribeKey | S3 hỏi thông tin khoá |

⚠ Chỉ cấp Decrypt thì ghi sẽ hỏng:

Người dùng chỉ đọc → Decrypt đủ
        ↓
    Cần ghi → phải thêm
      GenerateDataKey
    → thiếu nó, PutObject lỗi

Ba lưu ý về S3 Bucket Keys: | Lưu ý | Chi tiết | |---|---| | Giảm tới 99% lời gọi KMS | | | Giảm chi phí KMS đáng kể | | | Bật ở cấp bucket, trong suốt với ứng dụng | |

Ba lưu ý về ghi log: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lời gọi KMS | | | S3 data event phải bật riêng | | | kms:ViaService giới hạn khoá chỉ dùng qua S3 | |

⚠ kms:ViaService là điều kiện đáng dùng:

"Condition": {"StringEquals": {
  "kms:ViaService": "s3.ap-southeast-1.amazonaws.com"}}

Vai trò chỉ giải mã được khi
  đi qua S3
        ↓
    Không gọi thẳng KMS để giải mã
      dữ liệu khác

Ba lưu ý về công cụ chẩn đoán: | Công cụ | Dùng để | |---|---| | IAM Policy Simulator | thử một hành động cụ thể | | CloudTrail | xem lời gọi nào bị từ chối | | IAM Access Analyzer | tìm tài nguyên chia sẻ ra ngoài |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giả nhận vai trò rồi aws s3 cp thử | | | Xem CloudTrail có kms:Decrypt bị từ chối không | | | Thử ghi — phải bị từ chối (chỉ quyền đọc) | |

Và một lời khuyên: hãy kiểm chính sách khoá KMS trước tiên khi gặp Access Denied mà chính sách S3 trông đã đúng. Thông báo lỗi của S3 không phân biệt được "không được đọc object" với "không được giải mã nó" — và phần lớn thời gian gỡ lỗi bị tiêu vào việc soi lại hai chính sách vốn đã đúng.

Đáp án

**B — Sao lưu cơ sở dữ liệu mỗi giờ và lưu vào bucket S3 có bật Cross-Region Replication; lưu transaction log vào cùng bucket đó mỗi 5 phút.

Vì sao đúng

Đề cho hai con số mục tiêu, và cách phục hồi phải khớp cả hai: | Chỉ tiêu | Mục tiêu | Nghĩa | |---|---|---| | RTO | dưới 2 giờ | mất bao lâu để hoạt động lại | | RPO | 10 phút | mất nhiều nhất bao nhiêu dữ liệu |

⚠ Sự cố thực tế cho thấy RPO đang là 1,5 giờ:

Sự cố lúc 12:00
    → không phục hồi được giao dịch
      từ 10:30
        ↓
    Mất 90 phút dữ liệu
    → mục tiêu là 10 phút
        ↓
    Vượt gấp 9 lần

⚠ Chìa khoá: transaction log quyết định RPO, không phải backup:

Backup mỗi giờ
    → tự nó cho RPO = 60 phút
        ↓
    Nhưng có transaction log
      mỗi 5 phút
    → phục hồi = backup gần nhất
      + phát lại log
        ↓
    RPO thật = 5 phút

Đây là kỹ thuật point-in-time recovery:

Backup lúc 11:00
        ↓
    Log 11:05, 11:10, ..., 11:55
        ↓
    Sự cố 12:00
        ↓
    Phục hồi backup 11:00
    → phát lại log tới 11:55
    → mất tối đa 5 phút

Sao lưu và đẩy log:

# mỗi giờ
mysqldump --single-transaction --master-data=2 ung_dung \
  | gzip > /sao-luu/csdl-$(date +%Y%m%d%H).sql.gz
aws s3 cp /sao-luu/csdl-$(date +%Y%m%d%H).sql.gz \
  s3://sao-luu-csdl/day-du/

# mỗi 5 phút
mysqlbinlog --read-from-remote-server --raw \
  --stop-never-slave-server-id=99 binlog.000123 &
aws s3 sync /var/log/mysql/ s3://sao-luu-csdl/nhat-ky/

Bật sao chép liên Region:

aws s3api put-bucket-replication --bucket sao-luu-csdl \
  --replication-configuration '{
    "Role": "arn:aws:iam::111122223333:role/S3Replication",
    "Rules": [{"Status": "Enabled", "Priority": 1,
      "Filter": {}, "DeleteMarkerReplication": {"Status": "Disabled"},
      "Destination": {"Bucket": "arn:aws:s3:::sao-luu-csdl-dr",
                      "StorageClass": "STANDARD"}}]}'

⚠ CRR cần bật versioning ở CẢ HAI bucket:

Thiếu versioning → không bật
  được replication
        ↓
    Và versioning chống luôn việc
      xoá nhầm bản sao lưu

⚠ Và vì sao phương án C (log lên S3, backup lên EBS) sai:

Backup nằm trên EBS volume
    → EBS gắn với MỘT Availability Zone
        ↓
    Sự cố cấp Region hoặc AZ
    → không lấy được backup
        ↓
    Có log mà không có backup nền
    → không phục hồi được

⚠ Và vì sao phương án D (Glacier) sai — đây là vấn đề RTO: | Lớp | Thời gian lấy ra | |---|---| | S3 Standard | tức thì | | Glacier Instant Retrieval | tức thì | | Glacier Flexible Retrieval | 1-5 phút (nhanh) tới 5-12 giờ (khối) | | Glacier Deep Archive | 12-48 giờ |

Glacier Flexible chế độ tiêu chuẩn:
  3-5 giờ
        ↓
    RTO mục tiêu là 2 giờ
    → chưa lấy được backup đã
      quá hạn

⚠ Và vì sao phương án A (sao chép đồng bộ hai AZ) không đủ:

Multi-AZ sao chép đồng bộ
    → RPO = 0 cho lỗi HẠ TẦNG
        ↓
    Nhưng đề nói "sự cố ở CSDL
      chính"
    → dữ liệu hỏng, xoá nhầm,
      lỗi ứng dụng
        ↓
    Sao chép đồng bộ chép luôn
      cái hỏng sang standby
    → không cứu được

⚠ Đây là phân biệt căn bản phải nhớ: | Loại sự cố | Sao chép cứu được | Backup cứu được | |---|---|---| | Hỏng phần cứng, mất AZ | CÓ | có, chậm hơn | | Xoá nhầm dữ liệu | KHÔNG | CÓ | | Dữ liệu bị hỏng logic | KHÔNG | CÓ | | Mã độc mã hoá dữ liệu | KHÔNG | CÓ |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RPO 5 phút, dưới mục tiêu 10 phút | | | Backup nằm ở Region khác, sống sót thảm hoạ vùng | | | S3 Standard lấy ra ngay, đáp ứng RTO | |

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

Câu này cùng một mẫu với một câu khác trong bộ đề (mã #10439, cũng hỏi RPO/RTO với backup và transaction log). Cùng một kiến thức, hai bối cảnh.

⚠ Và với RDS thì toàn bộ việc này là tự động.

aws rds modify-db-instance --db-instance-identifier csdl \
  --backup-retention-period 7 --apply-immediately

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier csdl \
  --target-db-instance-identifier csdl-phuc-hoi \
  --restore-time 2026-08-31T11:55:00Z

RDS tự sao lưu và đẩy transaction
  log lên S3 mỗi 5 phút
        ↓
    Phục hồi tới bất kỳ giây nào
      trong khoảng lưu giữ
    → RPO 5 phút mà không viết
      script nào

Đề nói CSDL tự quản trên EC2, nên câu trả lời phải tự dựng — nhưng trong thực tế, chuyển sang RDS là cách đúng để đạt cùng mục tiêu.

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

• **A. Dựng sao chép đồng bộ giữa hai AZ — đây là phương án gần nhất và thật sự cho RPO gần 0 khi hạ tầng hỏng, nhưng sự cố ở đây là hỏng dữ liệu, và sao chép đồng bộ chép luôn cái hỏng sang bản dự phòng.
• **C. Backup mỗi giờ lên EBS, log lên S3 có CRR — EBS gắn với một AZ; mất AZ đó là mất luôn backup nền.
• **D. Backup lên Glacier để lưu trữ — thời gian lấy ra vượt quá RTO 2 giờ.

Ghi nhớ

⚠ RTO và RPO — bảng phải thuộc: | Chỉ tiêu | Đo gì | Quyết định bởi | |---|---|---| | RTO | thời gian khôi phục | tốc độ lấy backup và dựng lại | | RPO | lượng dữ liệu mất | tần suất sao lưu/log |

Từ khoá nhận diện:

"RPO of X minutes" → transaction log mỗi X phút hoặc ít hơn "RTO of X hours" → backup phải lấy ra được trong dưới X giờ "data corruption" → backup, KHÔNG phải replication "region-wide disaster" → CRR hoặc backup liên Region

Bốn chiến lược khôi phục thảm hoạ: | Chiến lược | RTO | RPO | Chi phí | |---|---|---|---| | Backup & restore | giờ | giờ | thấp nhất | | Pilot light | chục phút | phút | thấp | | Warm standby | phút | giây | trung bình | | Multi-site active/active | gần 0 | gần 0 | cao nhất |

Ba lưu ý về CRR: | Lưu ý | Chi tiết | |---|---| | Cần versioning ở cả hai bucket | | | Chỉ sao chép object MỚI sau khi bật | | | Batch Replication cho object cũ | |

⚠ Điểm thứ hai là bẫy hay gặp:

Bật CRR hôm nay
    → backup của tuần trước
      KHÔNG được sao chép
        ↓
    Phải chạy S3 Batch Replication
      cho dữ liệu cũ

Ba lưu ý về RTC: | Lưu ý | Chi tiết | |---|---| | Replication Time Control: 99,99% trong 15 phút | | | Có SLA và chỉ số CloudWatch | | | Tính phí thêm | |

Ba lưu ý về AWS Backup: | Lưu ý | Chi tiết | |---|---| | Quản lý sao lưu tập trung nhiều dịch vụ | | | Sao chép liên Region tự động | | | Vault Lock chống xoá (WORM) | |

⚠ Vault Lock là lớp chống mã độc:

Kẻ tấn công chiếm được quyền admin
    → xoá luôn mọi bản sao lưu
        ↓
    Vault Lock ở chế độ compliance
    → KHÔNG AI xoá được, kể cả
      tài khoản gốc
    → cho tới hết thời hạn giữ

Ba lưu ý về kiểm thử phục hồi: | Lưu ý | Chi tiết | |---|---| | Bản sao lưu chưa phục hồi thử là chưa chắc dùng được | | | Đo thời gian phục hồi thật để biết RTO thật | | | Diễn tập định kỳ, có kịch bản viết sẵn | |

Ba lưu ý về transaction log: | Lưu ý | Chi tiết | |---|---| | Phải phát lại theo đúng thứ tự | | | Đứt một tệp là dừng ở đó | | | Kiểm tra tính liên tục của chuỗi log | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phục hồi thật vào môi trường tách biệt | | | Bấm giờ toàn bộ quá trình | | | So dữ liệu sau phục hồi với thời điểm mục tiêu | |

Và một lời khuyên: hãy phục hồi thử ít nhất mỗi quý và bấm giờ. RTO trên tài liệu là con số ai đó ước lượng; RTO thật chỉ biết được khi đã làm một lần — và lần đầu luôn lâu hơn dự tính vì có những bước không ai ghi lại.

Đáp án

**D — Chuyển cơ sở dữ liệu MySQL tự quản trên EC2 sang Amazon RDS for MySQL, và thêm read replica vào cụm trong những ngày cuối tháng để chịu đỉnh tải.

Vì sao đúng

Đề nêu một mẫu tải rất đặc trưng:

Bình thường: chịu được
        ↓
    Bốn ngày cuối tháng: chậm hẳn
    → vì nhiều người chạy BÁO CÁO
      cuối tháng cùng lúc
        ↓
    Báo cáo = truy vấn ĐỌC nặng

⚠ Và ràng buộc "ít ảnh hưởng tới tính sẵn sàng nhất" loại bỏ ba phương án còn lại: | Phương án | Cần gián đoạn | |---|---| | A. Lambda đổi cỡ instance và IOPS | DỪNG máy để đổi cỡ | | B. Thay volume EBS mỗi tháng | tháo/gắn volume, dừng máy | | C. Nâng cỡ instance | DỪNG máy | | D. Thêm read replica | KHÔNG gián đoạn gì |

⚠ Thêm replica là thao tác cộng thêm, không đụng vào cái đang chạy:

Tạo replica mới
    → CSDL chính vẫn phục vụ
      bình thường
        ↓
    Xong thì trỏ truy vấn báo cáo
      sang đó
        ↓
    Hết tháng thì xoá replica
    → cũng không gián đoạn

Thêm replica trước kỳ cao điểm:

for i in 1 2 3; do
  aws rds create-db-instance-read-replica \
    --db-instance-identifier replica-bao-cao-$i \
    --source-db-instance-identifier csdl-chinh \
    --db-instance-class db.r6g.2xlarge
done

Xoá sau kỳ cao điểm:

for i in 1 2 3; do
  aws rds delete-db-instance \
    --db-instance-identifier replica-bao-cao-$i \
    --skip-final-snapshot
done

⚠ Và tách truy vấn báo cáo sang replica là điểm mấu chốt:

Báo cáo chạy trên CSDL chính
    → khoá bảng, chiếm I/O
        ↓
    Giao dịch của người dùng
      thường bị chậm theo
        ↓
    Đẩy báo cáo sang replica
    → hai loại tải không đụng nhau

⚠ Và chuyển sang RDS gỡ bỏ nhiều gánh nặng vận hành: | Việc | Tự quản trên EC2 | RDS | |---|---|---| | Vá hệ điều hành và MySQL | bạn | AWS | | Sao lưu và PITR | tự viết script | có sẵn | | Chuyển đổi khi hỏng | tự dựng | Multi-AZ | | Thêm replica | cấu hình thủ công | một lệnh |

⚠ Và phương án A tự động hoá đúng thứ không nên tự động hoá:

Lambda đổi cỡ instance khi CPU cao
    → đổi cỡ EC2 phải DỪNG máy
        ↓
    Tức là tự động gây gián đoạn
      đúng lúc đang tải cao
        ↓
    Đây là điều tệ nhất có thể làm

⚠ Và phương án B có một vấn đề kỹ thuật nữa:

"Chụp snapshot rồi thay bằng
  volume Provisioned IOPS"
        ↓
    EBS đổi kiểu volume TẠI CHỖ
      từ 2017
    → không cần snapshot, không
      cần thay
        ↓
    Mô tả này lỗi thời

aws ec2 modify-volume --volume-id vol-abc \
  --volume-type io2 --iops 20000

⚠ Và phương án C sai ở chi tiết "chuyển sang GP2":

GP2 là thế hệ CŨ hơn
    → đề không nói volume hiện tại
      là gì
        ↓
    Nếu đang là io1, chuyển sang
      gp2 là GIẢM hiệu năng
        ↓
    Và "pre-warm ALB" là khái niệm
      đã lỗi thời — ALB tự co giãn

⚠ "Pre-warming" load balancer là chuyện của Classic Load Balancer:

Ngày xưa phải mở ticket nhờ AWS
  làm nóng CLB trước đợt tải lớn
        ↓
    ALB và NLB tự co giãn
    → không còn khái niệm này

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không gián đoạn khi thêm hay bớt replica | | | Báo cáo không ảnh hưởng giao dịch | | | Chỉ trả tiền replica trong 4 ngày cao điểm | |

⚠ Và Aurora Auto Scaling làm việc này tự động:

aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --resource-id cluster:cum-aurora \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --min-capacity 1 --max-capacity 8

Aurora tự thêm replica khi CPU
  hoặc số kết nối cao
        ↓
    Tự bớt khi hết cao điểm
    → không cần nhớ lịch cuối tháng

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

• **B. Chụp snapshot volume EBS và thay bằng Provisioned IOPS vào cuối tháng, rồi đổi lại sau — đây là phương án gần nhất và thật sự nhắm đúng vấn đề I/O, nhưng thao tác này cần dừng máy, và EBS đã đổi kiểu volume tại chỗ được từ lâu nên mô tả đã lỗi thời.
• **A. Dùng CloudWatch kích hoạt Lambda đổi cỡ instance và IOPS — đổi cỡ EC2 buộc phải dừng máy, tức là tự động gây gián đoạn ngay giữa lúc tải cao.
• **C. Đổi mọi volume sang GP2, nâng cỡ instance, pre-warm ALB — nâng cỡ cần dừng máy; GP2 là thế hệ cũ; pre-warm ALB là khái niệm không còn tồn tại.

Ghi nhớ

⚠ Bốn cách xử lý tải đọc theo chu kỳ — bảng phải thuộc: | Cách | Gián đoạn | |---|---| | Thêm read replica | KHÔNG | | Thêm cache | KHÔNG | | Nâng cỡ instance | CÓ (trừ Aurora Serverless) | | Đổi kiểu volume EBS | không (nhưng có giai đoạn tối ưu) |

Từ khoá nhận diện:

"least impact on availability" → thêm tài nguyên, đừng sửa cái đang chạy "predictable monthly spike" → thêm replica theo lịch "reporting queries slow down transactions" → tách sang replica "self-managed database on EC2" → cân nhắc chuyển sang RDS

Ba lưu ý về read replica RDS: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 (RDS), 15 (Aurora) | | | Sao chép không đồng bộ, có độ trễ | | | Mỗi replica có endpoint riêng (RDS) | |

⚠ Độ trễ sao chép ảnh hưởng báo cáo:

Replica trễ vài giây
    → báo cáo có thể thiếu vài
      giao dịch cuối
        ↓
    Với báo cáo cuối tháng
    → thường chấp nhận được
        ↓
    Cần chính xác tuyệt đối
    → chạy trên chính hoặc chờ
      độ trễ về 0

Ba lưu ý về chuyển sang RDS: | Lưu ý | Chi tiết | |---|---| | DMS full load + CDC, ngừng rất ngắn | | | Kiểm plugin và cấu hình MySQL có được hỗ trợ | | | Không có quyền SUPER trên RDS | |

⚠ Điểm cuối làm hỏng một số ứng dụng:

Ứng dụng tự gọi lệnh cần SUPER
    → RDS không cấp quyền đó
        ↓
    Phải dùng stored procedure của
      RDS (`rds_kill`, `rds_set_...`)

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | Reader endpoint tự cân bằng tải | | | Auto Scaling số replica theo chỉ số | | | Serverless v2 co giãn cả CPU/RAM | |

⚠ Aurora Serverless v2 hợp nhất với mẫu tải này:

Co giãn từ 0,5 tới 128 ACU
    → tăng trong vài giây
        ↓
    Bốn ngày cuối tháng tự lên
    → còn lại tự xuống
    → không cần lịch, không cần
      thao tác

Ba lưu ý về tách tải: | Lưu ý | Chi tiết | |---|---| | Ứng dụng phải có hai chuỗi kết nối | | | ProxySQL hoặc RDS Proxy chia tải được | | | Đánh dấu truy vấn báo cáo riêng | |

Ba lưu ý về RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Gộp kết nối, giảm tải cho CSDL | | | Giữ kết nối khi CSDL chuyển đổi | | | Rất hợp khi client là Lambda | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo ReplicaLag khi báo cáo chạy | | | So thời gian chạy báo cáo trước và sau | | | Kiểm CPU của CSDL chính có giảm không | |

Và một lời khuyên: hãy tạo replica vài ngày TRƯỚC kỳ cao điểm chứ đừng tạo đúng hôm bắt đầu. Replica mới phải sao chép toàn bộ dữ liệu rồi mới bắt kịp, và với một CSDL lớn thì quá trình đó có thể kéo dài hàng giờ — đúng lúc bạn cần nó phục vụ.

Đáp án

**A, B và F — Tạo quy tắc EventBridge khớp lời gọi CloudTrail có eventName là CreateUser; gửi thông điệp tới một SNS topic để đội bảo mật đăng ký nhận; và dùng EventBridge kích hoạt một Step Functions state machine để gỡ quyền của IAM user vừa tạo.

Vì sao đúng

Đề nêu ba việc phải xảy ra khi có ai tạo IAM user, và ba đáp án phủ đúng ba việc: | Việc | Thành phần | |---|---| | Phát hiện việc tạo user | EventBridge khớp CreateUser | | Gỡ toàn bộ quyền tự động | Step Functions | | Báo cho đội bảo mật | SNS |

⚠ Điểm mấu chốt: CloudTrail không tự kích hoạt gì cả:

CloudTrail GHI LẠI lời gọi API
    → nó không có cơ chế "khi thấy
      X thì làm Y"
        ↓
    CloudTrail phát sự kiện vào
      EventBridge
    → EventBridge mới là nơi khớp
      mẫu và kích hoạt hành động

Đây là lý do phương án D sai — CloudTrail không có "event filter" gửi thẳng tới SNS.

Quy tắc EventBridge:

{"source": ["aws.iam"],
 "detail-type": ["AWS API Call via CloudTrail"],
 "detail": {"eventSource": ["iam.amazonaws.com"],
            "eventName": ["CreateUser"]}}

aws events put-rule --name bat-tao-iam-user \
  --event-pattern file://mau-su-kien.json

aws events put-targets --rule bat-tao-iam-user --targets \
  'Id=1,Arn=arn:aws:states:...:stateMachine:GoQuyen,RoleArn=...' \
  'Id=2,Arn=arn:aws:sns:...:canh-bao-bao-mat'

⚠ Một quy tắc có nhiều target — đây là lý do A + B + F ăn khớp:

Không cần hai quy tắc
    → một quy tắc, hai đích
        ↓
    Step Functions gỡ quyền
    → SNS báo cho người

⚠ Và IAM là dịch vụ TOÀN CẦU — sự kiện chỉ tới us-east-1:

Mọi lời gọi IAM ghi vào CloudTrail
  ở us-east-1
        ↓
    Quy tắc EventBridge phải đặt
      ở us-east-1
        ↓
    Đặt ở Region khác: quy tắc đúng,
      không bao giờ khớp
    → và không có lỗi nào báo

Đề nói trail đã bật multi-region, chính là điều kiện cần cho việc này.

⚠ Và vì sao Step Functions (F) hơn Fargate (E): | Tiêu chí | Step Functions | Fargate | |---|---|---| | Khởi động | tức thì | vài chục giây kéo image | | Vận hành | không có gì | image, registry, task definition | | Thử lại và xử lý lỗi | khai báo sẵn | tự viết | | Chi phí cho việc vài giây | rất nhỏ | cao hơn nhiều |

Việc cần làm: gọi vài API IAM
        ↓
    Fargate: dựng container để gọi
      ba lời gọi API
    → dùng búa tạ đập ruồi

⚠ Và Step Functions gọi thẳng API IAM được, không cần Lambda:

{"GoChinhSachGanTiep": {
  "Type": "Task",
  "Resource": "arn:aws:states:::aws-sdk:iam:detachUserPolicy",
  "Parameters": {"UserName.$": "$.detail.requestParameters.userName",
                 "PolicyArn.$": "$.chinhSach"},
  "Next": "GoNhom"}}

Tích hợp SDK của Step Functions
  gọi hơn 200 dịch vụ AWS
        ↓
    Không cần viết Lambda
    → ít mã hơn, ít thứ phải vá hơn

⚠ Và "gỡ toàn bộ quyền" gồm nhiều thứ, đây là lý do cần state machine:

1. Liệt kê và gỡ chính sách gắn kèm
        ↓
2. Xoá chính sách nội tuyến
        ↓
3. Gỡ khỏi mọi nhóm
        ↓
4. Vô hiệu access key nếu có
        ↓
    Bốn bước có thứ tự, có thể lỗi
      từng bước
    → Step Functions quản lý luồng
      này rất hợp

Cách chắc chắn hơn — gắn policy chặn hết:

{"Version": "2012-10-17",
 "Statement": [{"Effect": "Deny", "Action": "*", "Resource": "*"}]}

Gỡ từng thứ có thể sót
    → gắn một chính sách Deny toàn bộ
    → deny luôn thắng allow
        ↓
    Chắc chắn hơn, và dễ gỡ khi
      đội bảo mật duyệt

⚠ Và vì sao Audit Manager (C) sai:

Audit Manager thu thập bằng chứng
  cho việc kiểm toán tuân thủ
        ↓
    Sinh báo cáo theo khung
      (SOC 2, PCI, HIPAA)
        ↓
    Không phát hiện thời gian thực,
      không hành động

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phản ứng trong vài giây | | | Không có gì phải vận hành | | | Luồng nhiều bước có thử lại và xử lý lỗi | |

⚠ Nhưng đây là kiểm soát PHÁT HIỆN, không phải ngăn chặn:

User được tạo, rồi mới bị gỡ quyền
    → có một khoảng thời gian
      user tồn tại với quyền đầy đủ
        ↓
    Cách ngăn chặn thật là SCP

{"Effect": "Deny", "Action": "iam:CreateUser", "Resource": "*",
 "Condition": {"ArnNotEquals": {
   "aws:PrincipalArn": "arn:aws:iam::*:role/QuanTriBaoMat"}}}

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

⚠ Phương án E (Fargate) và F (Step Functions) đều làm được việc; đề buộc phải chọn cái hợp hơn.

Cả hai đều gỡ được quyền. Step Functions thắng vì: khởi động tức thì, không có image để vá, không có cụm để quản, và có sẵn cơ chế thử lại. Nhưng đây là so sánh về mức độ phù hợp chứ không phải đúng/sai tuyệt đối.

Và cách đơn giản nhất — một Lambda — lại không có trong danh sách. Với một việc chạy vài giây và gọi vài API, Lambda là lựa chọn tự nhiên nhất; Step Functions chỉ hơn khi luồng có nhiều bước cần điều phối.

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

• **E. Dùng EventBridge kích hoạt một tác vụ AWS Fargate để gỡ quyền — đây là phương án gần nhất và thật sự thực hiện được việc, nhưng nó nặng nề hơn hẳn cho một tác vụ vài giây: phải dựng image, quản registry, và chịu độ trễ khởi động container.
• **D. Cấu hình event filter trong CloudTrail cho sự kiện CreateUser và gửi tới SNS — CloudTrail không có cơ chế lọc và gửi thông báo như vậy; phải qua EventBridge.
• **C. Dùng AWS Audit Manager — công cụ thu thập bằng chứng kiểm toán tuân thủ, không phát hiện thời gian thực và không hành động.

Ghi nhớ

⚠ Bốn cách phản ứng sự kiện bảo mật — bảng phải thuộc: | Cách | Thời điểm | |---|---| | SCP | chặn TRƯỚC | | EventBridge + hành động | phản ứng trong vài giây | | Config rule + remediation | phản ứng trong vài phút | | Audit Manager | báo cáo định kỳ |

Từ khoá nhận diện:

"when an API call happens, do X" → EventBridge từ CloudTrail "prevent it from happening" → SCP "detect misconfigured resources" → Config rules "multi-step automated response" → Step Functions "collect evidence for audit" → Audit Manager

Ba lưu ý về EventBridge với CloudTrail: | Lưu ý | Chi tiết | |---|---| | Sự kiện IAM chỉ tới us-east-1 | | | Data event cần bật riêng trong trail | | | detail-type là "AWS API Call via CloudTrail" | |

⚠ Data event là chỗ hay nhầm:

`s3:GetObject`, `lambda:Invoke`
  là DATA event
        ↓
    Không ghi mặc định, phải bật
      và tính phí riêng
        ↓
    Không bật → EventBridge không
      bao giờ thấy

Ba lưu ý về Step Functions: | Lưu ý | Chi tiết | |---|---| | Standard: tới 1 năm, chính xác một lần | | | Express: dưới 5 phút, tần suất cao | | | Tích hợp SDK gọi thẳng API AWS | |

Ba lưu ý về xử lý lỗi trong Step Functions: | Cơ chế | Dùng để | |---|---| | Retry | thử lại với backoff | | Catch | rẽ nhánh khi lỗi | | Parallel | chạy nhiều nhánh cùng lúc |

Ba lưu ý về SNS: | Lưu ý | Chi tiết | |---|---| | Fan-out tới nhiều đăng ký | | | Email, SMS, Lambda, SQS, HTTP | | | FIFO topic nếu cần thứ tự | |

Ba lưu ý về gỡ quyền IAM: | Bước | Lệnh | |---|---| | Gỡ chính sách gắn kèm | detach-user-policy | | Xoá chính sách nội tuyến | delete-user-policy | | Gỡ khỏi nhóm | remove-user-from-group |

⚠ Và đừng quên access key:

aws iam update-access-key --user-name <ten> \
  --access-key-id <id> --status Inactive

Gỡ hết chính sách mà quên key
    → key vẫn tồn tại
        ↓
    Đội bảo mật duyệt xong, cấp
      quyền lại
    → key cũ lại hoạt động

Ba lưu ý về thực hành IAM hiện đại: | Lưu ý | Chi tiết | |---|---| | IAM Identity Center thay cho IAM user | | | Vai trò và credential tạm thay access key | | | SCP cấm tạo IAM user hoàn toàn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo thử một IAM user, đo thời gian tới lúc bị gỡ quyền | | | Xem lịch sử thực thi Step Functions | | | Kiểm đội bảo mật có nhận được thư | |

Và một lời khuyên: hãy gắn một chính sách Deny toàn bộ thay vì gỡ từng quyền một. Gỡ từng thứ dễ sót một nhóm hoặc một chính sách nội tuyến nào đó, còn một câu deny duy nhất thì luôn thắng mọi allow — và gỡ nó ra cũng chỉ mất một thao tác khi đội bảo mật đã duyệt.

Đáp án

**C — Đồng bộ dữ liệu tại chỗ lên S3 bằng lệnh aws s3 sync từ một tuần trước lịch di trú; chạy lần đồng bộ cuối vào tối thứ Sáu sau giờ làm; rồi cho ứng dụng trên EC2 dùng bucket S3 đó.

Vì sao đúng

Đề cho những con số cần ghép lại:

1 TB dữ liệu, đường truyền 50 Mbps
        ↓
    48 giờ để chuyển hết
        ↓
    Cuối tuần chỉ có ~48 giờ
    → vừa khít, không có biên
      an toàn

⚠ Nhưng dữ kiện quan trọng nhất là: chỉ 10% tệp đổi mỗi ngày:

Chuyển hết 1 TB từ TRƯỚC một tuần
    → tới thứ Sáu chỉ còn phần
      thay đổi
        ↓
    10% của 1 TB = ~100 GB
    → ở 50 Mbps mất khoảng 4,5 giờ
        ↓
    Thừa sức xong trong đêm thứ Sáu

⚠ Và aws s3 sync chỉ chuyển phần khác biệt — đây là chìa khoá:

aws s3 sync /du-lieu-hang-khong s3://du-lieu-ky-thuat/ \
  --storage-class STANDARD

`sync` so kích thước và thời gian
  sửa đổi
        ↓
    Tệp không đổi → bỏ qua
        ↓
    Chạy lại nhiều lần rất rẻ

⚠ Và đây là lý do phương án A thất bại:

A chỉ đồng bộ trong cuối tuần
    → phải chuyển đủ 1 TB
        ↓
    48 giờ là con số TỐI THIỂU
      lý thuyết
    → thực tế chậm hơn (overhead,
      chia sẻ băng thông)
        ↓
    Nhiều khả năng không kịp

⚠ Và Snowball Edge (phương án B) không hợp về thời gian lẫn chi phí:

Đặt thiết bị → AWS gửi tới →
  chép → gửi trả → AWS nạp vào S3
        ↓
    Toàn bộ chu trình mất
      khoảng một tuần
        ↓
    B nói bắt đầu chép tối thứ Sáu
      và xong Chủ nhật
    → không thể

⚠ Và có một điểm sai kỹ thuật nữa trong B:

Snowball nạp dữ liệu vào S3
    → KHÔNG nạp thẳng vào EBS
        ↓
    "Chép từ Snowball sang nhiều
      EBS volume" là bước thủ công
      rất tốn thời gian

⚠ Và Snowball chỉ đáng dùng khi đường truyền quá chậm: | Dung lượng | Băng thông | Nên dùng | |---|---|---| | 1 TB | 50 Mbps | mạng (48 giờ) | | 10 TB | 50 Mbps | Snowball | | 100 TB | 1 Gbps | Snowball | | 1 PB | 10 Gbps | Snowmobile hoặc nhiều Snowball |

Quy tắc thô: nếu chuyển qua mạng
  mất trên một tuần
    → cân nhắc Snowball

⚠ Và Volume Gateway (phương án D) lưu dữ liệu ở dạng snapshot EBS:

Dữ liệu trên S3 dưới dạng snapshot
    → KHÔNG đọc trực tiếp bằng
      S3 API
        ↓
    Phải khôi phục thành EBS volume
      rồi gắn vào EC2
        ↓
    Nhiều bước, và mất tính linh
      hoạt của object storage

⚠ Và "Gateway-Stored" còn có một ràng buộc riêng:

Chế độ stored: dữ liệu CHÍNH nằm
  ở đĩa cục bộ
        ↓
    Cần 1 TB đĩa cục bộ nữa
    → không giải quyết được gì
      về dung lượng

Kịch bản triển khai:

# Một tuần trước — chuyển toàn bộ
aws s3 sync /du-lieu s3://du-lieu-ky-thuat/ \
  --exclude "*.tmp" --only-show-errors

# Chạy lại hằng đêm để thu hẹp khoảng cách
0 22 * * * aws s3 sync /du-lieu s3://du-lieu-ky-thuat/

# Tối thứ Sáu — lần cuối, sau khi khoá ghi
aws s3 sync /du-lieu s3://du-lieu-ky-thuat/ --delete

⚠ --delete chỉ dùng ở lần cuối:

Không có `--delete`: tệp đã xoá
  tại chỗ vẫn còn trên S3
        ↓
    Có: S3 khớp chính xác nguồn
        ↓
    Nhưng dùng sớm quá thì mất
      dữ liệu nếu nguồn có sự cố

⚠ Và nên khoá ghi trước lần đồng bộ cuối:

Người dùng vẫn sửa tệp trong lúc
  đồng bộ cuối
        ↓
    Tệp sửa sau khi `sync` đi qua
      thư mục đó
    → không được chuyển
        ↓
    Chuyển sang chế độ chỉ đọc
      trước khi chạy lần cuối

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải đợi thiết bị vật lý | | | Cửa sổ cuối tuần chỉ cần chuyển 10% | | | Dữ liệu là object S3, dùng được ngay | |

⚠ Và DataSync làm việc này tốt hơn s3 sync với dữ liệu lớn:

aws datasync create-task \
  --source-location-arn <arn-nfs> \
  --destination-location-arn <arn-s3> \
  --options VerifyMode=ONLY_FILES_TRANSFERRED,\
TransferMode=CHANGED

DataSync: đa luồng, có kiểm tra
  toàn vẹn, có giới hạn băng thông
        ↓
    Nhanh hơn `s3 sync` nhiều lần
      với tập tệp lớn
    → và có lịch chạy sẵn

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

• **A. Đồng bộ bằng multipart upload từ sáng thứ Bảy tới tối Chủ nhật — đây là phương án gần nhất và multipart thật sự cần cho tệp nhiều GB, nhưng nó phải chuyển đủ 1 TB trong đúng cửa sổ 48 giờ vốn đã là ước lượng tối thiểu, không còn biên an toàn.
• **B. Dùng Snowball Edge bắt đầu tối thứ Sáu — chu trình gửi và nhận thiết bị mất khoảng một tuần; và Snowball nạp vào S3 chứ không nạp thẳng vào EBS.
• **D. Dựng Gateway-Stored Volume Gateway, tạo snapshot rồi khôi phục thành EBS — nhiều bước, dữ liệu ở dạng snapshot không dùng trực tiếp được, và chế độ stored vẫn cần 1 TB đĩa cục bộ.

Ghi nhớ

⚠ Bốn cách di trú dữ liệu — bảng phải thuộc: | Cách | Hợp với | |---|---| | aws s3 sync / DataSync | có băng thông, cần đồng bộ nhiều lần | | Snowball Edge | hàng chục TB, băng thông kém | | Snowmobile | hàng chục PB | | Storage Gateway | truy cập lai liên tục, không phải di trú |

Từ khoá nhận diện:

"only a small percentage changes daily" → đồng bộ trước, đồng bộ lại lần cuối "transfer would take weeks" → Snowball "keep on-premises access after migration" → Storage Gateway "one-time file migration with verification" → DataSync

⚠ Cách tính thời gian truyền — phải nhớ:

1 TB = 8.000.000 Mb (thô)
        ↓
    Ở 50 Mbps: 160.000 giây
    ≈ 44 giờ (lý thuyết)
        ↓
    Thực tế 60-70% hiệu suất
    → khoảng 65 giờ

Ba lưu ý về s3 sync: | Lưu ý | Chi tiết | |---|---| | So kích thước và thời gian sửa | | | --delete xoá tệp thừa ở đích | | | --exclude/--include lọc theo mẫu | |

⚠ s3 sync KHÔNG so nội dung:

Tệp đổi nội dung mà giữ nguyên
  kích thước và mtime
        ↓
    `sync` bỏ qua
        ↓
    DataSync có chế độ so checksum
    → chắc chắn hơn

Ba lưu ý về DataSync: | Lưu ý | Chi tiết | |---|---| | Cần agent tại chỗ (hoặc chạy trên EC2) | | | Kiểm tra toàn vẹn sau khi chuyển | | | Giới hạn băng thông để không nghẽn đường truyền | |

⚠ Giới hạn băng thông là tính năng quan trọng:

--options BytesPerSecond=6250000

Không giới hạn: DataSync chiếm
  hết 50 Mbps
        ↓
    Nhân viên không dùng được
      Internet
    → đặt trần ở 50-70%

Ba lưu ý về Snowball Edge: | Loại | Dung lượng | |---|---| | Storage Optimized | 80 TB | | Compute Optimized | 28 TB + tính toán | | Thời gian chu trình | ~1-2 tuần |

Ba lưu ý về multipart upload: | Lưu ý | Chi tiết | |---|---| | Bắt buộc cho tệp trên 5 GB | | | Tải song song, nhanh hơn | | | Phần dở dang vẫn tính tiền — đặt luật vòng đời dọn | |

⚠ Phần dở dang là khoản chi phí ẩn:

{"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}

Tải lên hỏng giữa chừng
    → các phần đã tải nằm lại
      trong bucket
        ↓
    Không thấy khi liệt kê object
    → nhưng vẫn tính tiền lưu trữ

Ba lưu ý về cửa sổ chuyển đổi: | Lưu ý | Chi tiết | |---|---| | Khoá ghi trước lần đồng bộ cuối | | | Đếm số tệp và tổng dung lượng hai bên | | | Có kế hoạch quay lui | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | aws s3 ls --recursive --summarize đếm object | | | So checksum vài tệp mẫu | | | Chạy ứng dụng thử trên dữ liệu ở S3 | |

Và một lời khuyên: hãy bắt đầu đồng bộ sớm hơn nhiều so với mức bạn nghĩ là cần. Lần chuyển đầu tiên luôn phát hiện những thứ không lường trước — tệp bị khoá, đường dẫn quá dài, ký tự lạ trong tên — và phát hiện chúng vào tối thứ Sáu thì không còn thời gian để xử lý.

Đáp án

**C — IAM user trong tài khoản thành viên không có chính sách IAM cấp quyền tường minh cho các hành động EC2 hoặc S3.

Vì sao đúng

Đây là hiểu lầm phổ biến nhất về SCP:

SCP KHÔNG CẤP quyền
    → nó chỉ đặt TRẦN quyền
      tối đa
        ↓
    Quyền hiệu lực = GIAO của
      SCP và chính sách IAM
        ↓
    IAM không cấp → không có gì
      để giao
    → bị từ chối

⚠ Bảng chân trị phải thuộc: | SCP | IAM policy | Kết quả | |---|---|---| | Allow | Allow | CHO PHÉP | | Allow | không có | TỪ CHỐI | | không có (implicit deny) | Allow | TỪ CHỐI | | Deny | Allow | TỪ CHỐI |

SCP trong đề cho phép EC2:* và S3:*
        ↓
    Nghĩa là: tài khoản này ĐƯỢC PHÉP
      dùng EC2 và S3 (nếu IAM cũng cho)
        ↓
    Không nghĩa là mọi user tự động
      có quyền đó

Chính sách IAM cần thêm cho user:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Action": ["s3:CreateBucket", "s3:ListAllMyBuckets"],
  "Resource": "*"}]}

⚠ Và có một điểm nữa trong SCP của đề đáng chú ý:

"Action": ["EC2:*", "S3:*"]
        ↓
    Tiền tố dịch vụ trong IAM viết
      thường: "ec2:*", "s3:*"
        ↓
    IAM không phân biệt hoa thường
      ở TÊN DỊCH VỤ
    → nên vẫn hoạt động

⚠ Nhưng SCP này cũng chặn mọi dịch vụ khác:

Allow chỉ EC2 và S3
    → mọi dịch vụ khác nằm ngoài
      trần
        ↓
    IAM, CloudWatch, STS đều bị chặn
    → tài khoản gần như không dùng
      được cho việc gì khác
        ↓
    Kể cả `iam:CreateUser` cũng
      không làm được

⚠ Và vì sao phương án A sai:

SCP gắn vào OU
    → MỌI tài khoản trong OU
      tự thừa hưởng
        ↓
    Kể cả tài khoản mới chuyển vào
      sau này
    → không phải gắn thủ công

⚠ Và vì sao phương án B sai — user root cũng bị SCP chặn:

SCP áp cho MỌI danh tính trong
  tài khoản thành viên
        ↓
    Kể cả user root của tài khoản đó
        ↓
    Ngoại lệ duy nhất: tài khoản
      QUẢN LÝ của tổ chức

Trong tình huống này root vẫn tạo được bucket (vì SCP cho phép S3 và root có quyền đầy đủ), nhưng dùng root cho công việc hằng ngày là sai thực hành nghiêm trọng.

⚠ Và vì sao phương án D sai:

Không gắn được IAM policy vào OU
        ↓
    OU chỉ nhận SCP, tag policy,
      backup policy, AI opt-out policy
        ↓
    IAM policy gắn vào user, group,
      role — trong từng tài khoản

Sáu lớp kiểm tra khi bị từ chối:

1. SCP có cho phép không
        ↓
2. Resource policy có cho phép không
        ↓
3. Permissions boundary có chặn không
        ↓
4. Session policy có chặn không
        ↓
5. IAM identity policy có cho phép không
        ↓
6. Có Deny tường minh nào ở đâu không

⚠ Deny tường minh luôn thắng, ở bất kỳ lớp nào.

Ba lợi ích của mô hình này: | Lợi ích | Chi tiết | |---|---| | Tài khoản không vượt được trần tổ chức đặt | | | Quản trị viên tài khoản vẫn tự quản chi tiết | | | Hai tầng phân quyền, phòng thủ theo lớp | |

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

• **A. Tài khoản trong OU không tự thừa hưởng SCP, phải gắn thủ công vào từng tài khoản — đây là phương án gần nhất và nghe rất hợp lý với người chưa dùng Organizations, nhưng SCP gắn vào OU tự áp cho mọi tài khoản trong đó, kể cả tài khoản chuyển vào sau.
• **B. Phải dùng user root mới tạo được bucket — SCP áp cho cả root của tài khoản thành viên; và dùng root cho việc hằng ngày là sai thực hành.
• **D. Nên gắn IAM policy vào OU thay vì SCP — OU không nhận IAM policy; IAM policy chỉ gắn được vào user, group hoặc role.

Ghi nhớ

⚠ Bốn loại chính sách gắn được vào OU — bảng phải thuộc: | Loại | Tác dụng | |---|---| | SCP | trần quyền cho danh tính | | RCP | trần quyền cho tài nguyên | | Tag policy | chuẩn hoá thẻ | | Backup policy | áp kế hoạch sao lưu |

Từ khoá nhận diện:

"SCP allows but user denied" → thiếu IAM policy "SCP does not grant permissions" → luôn đúng "management account not affected" → luôn đúng với SCP "explicit deny wins" → luôn đúng

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | KHÔNG áp cho tài khoản quản lý | | | KHÔNG áp cho service-linked role | | | Thừa hưởng theo cây, GIAO nhau | |

⚠ Service-linked role là ngoại lệ dễ quên:

SCP không chặn được
  service-linked role
        ↓
    Ví dụ role của Auto Scaling
      vẫn gọi được `ec2:RunInstances`
        ↓
    Thiết kế có chủ đích, để dịch vụ
      AWS không bị hỏng

Ba chiến lược SCP: | Chiến lược | Cách làm | |---|---| | Deny list | FullAWSAccess + Deny những gì cấm | | Allow list | chỉ Allow những gì cho phép | | Hỗn hợp | Allow rộng ở root, Deny hẹp ở OU |

⚠ Deny list dễ vận hành hơn nhiều:

Allow list: mỗi lần dùng dịch vụ mới
  phải sửa SCP
        ↓
    Và dễ quên dịch vụ phụ thuộc
    → như SCP trong đề, chặn luôn
      cả IAM và STS
        ↓
    Deny list: giữ FullAWSAccess,
      chỉ cấm những gì thật sự cấm

Ba lưu ý về chẩn đoán AccessDenied: | Công cụ | Dùng để | |---|---| | CloudTrail | xem lời gọi bị từ chối, và bởi lớp nào | | IAM Policy Simulator | thử trước khi triển khai | | Access Analyzer policy validation | tìm lỗi trong chính sách |

⚠ CloudTrail có nói rõ lý do từ chối:

"errorCode": "AccessDenied",
"errorMessage": "... with an explicit deny in a
  service control policy"

Thông báo này phân biệt được
    → SCP chặn
    → hay IAM thiếu quyền

Ba lưu ý về Organizations: | Lưu ý | Chi tiết | |---|---| | Bật all-features mới dùng được SCP | | | Cây OU nên phản ánh ranh giới chính sách | | | Đừng chạy workload ở tài khoản quản lý | |

Ba lưu ý về permissions boundary: | Lưu ý | Chi tiết | |---|---| | Trần quyền cho MỘT danh tính | | | Cho phép uỷ quyền tạo role an toàn | | | Cũng không CẤP quyền, chỉ giới hạn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử hành động bằng Policy Simulator | | | Đọc errorMessage trong CloudTrail | | | Xem SCP hiệu lực trong console Organizations | |

Và một lời khuyên: hãy nhớ rằng SCP chưa bao giờ cấp quyền cho ai. Mỗi khi thấy "SCP đã allow rồi mà vẫn bị từ chối", câu trả lời gần như luôn là danh tính đó chưa có chính sách IAM nào cho phép hành động ấy.