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

Đáp án

B — EC2 instance store cho hiệu năng tối đa, Amazon S3 cho lưu trữ bền vững, S3 Glacier cho lưu trữ dài hạn.

Vì sao đúng

Đề nêu ba nhu cầu với ba đặc tính khác nhau: | Nhu cầu | Dung lượng | Yêu cầu | Dịch vụ | |---|---|---|---| | Xử lý video | 5 TB | I/O TỐI ĐA | Instance store | | Lưu tệp video | 400+ TB | cực kỳ bền vững | S3 | | Lưu trữ dài hạn | 800 TB | rẻ nhất | S3 Glacier |

Instance store là lựa chọn nhanh nhất tuyệt đối:

Instance store = NVMe SSD gắn TRỰC TIẾP vào máy chủ vật lý
    → KHÔNG đi qua mạng như EBS
        ↓
    Hàng triệu IOPS, độ trễ micro giây

Và dữ liệu tạm khi xử lý video hoàn toàn phù hợp:

Instance store MẤT dữ liệu khi stop hoặc hỏng phần cứng
    → nhưng đây chỉ là không gian làm việc
    → nguồn gốc vẫn nằm ở S3
        ↓
    Rủi ro chấp nhận được, đổi lại hiệu năng cao nhất

Và S3 cho 400 TB video:

S3:
    ✓ độ bền 99,999999999% (11 số 9)
    ✓ dung lượng không giới hạn
    ✓ rẻ hơn EBS và EFS nhiều lần

Và Glacier cho 800 TB lưu trữ:

800 TB mỗi tháng:
    S3 Standard:        ~18.400 USD
    Glacier Flexible:    ~2.880 USD
    Deep Archive:          ~792 USD
        ↓
    Chênh lệch rất lớn ở quy mô này

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

• **A. EBS cho hiệu năng tối đa, S3 cho bền vững, Glacier cho lưu trữ — đây là phương án gần nhất và đúng hoàn toàn ở hai vế sau, nhưng nó sai ở vế "MAXIMUM POSSIBLE I/O performance": EBS đi qua mạng lưu trữ nên luôn chậm hơn instance store.
• **C. Instance store, EFS cho bền vững, S3 cho lưu trữ — EFS đắt hơn S3 khoảng 13 lần cho cùng dung lượng, và S3 không phải lớp lưu trữ dài hạn rẻ nhất.
• **D. EBS, EFS, Glacier — sai cả hai vế đầu: EBS không nhanh nhất, và EFS quá đắt cho 400 TB.

Ghi nhớ

Hiệu năng lưu trữ trên AWS — thứ tự từ nhanh nhất: | Lưu trữ | Độ trễ | Bền vững | |---|---|---| | Instance store (NVMe) | micro giây | ❌ MẤT khi stop | | EBS io2 Block Express | dưới mili giây | ✅ 99,999% | | EBS gp3 | mili giây một chữ số | ✅ | | EFS | mili giây | ✅ | | S3 | hàng chục mili giây | ✅ 11 số 9 | | Glacier | phút tới giờ | ✅ |

Từ khoá nhận diện:

"maximum I/O performance", "temporary", "scratch" → instance store "durable object storage", "large volumes" → S3 "long-term archival" → Glacier hoặc Deep Archive

Ba đặc điểm của instance store: | Đặc điểm | Chi tiết | |---|---| | Hiệu năng cao nhất | gắn trực tiếp máy chủ | | MẤT khi stop, terminate, hỏng phần cứng | giữ được khi REBOOT | | Dung lượng cố định theo loại instance | |

Ba họ instance có NVMe lớn: | Họ | Đặc điểm | |---|---| | i4i, i3en | tối ưu lưu trữ | | d3, d3en | HDD dung lượng rất lớn | | m6id, c6id, r6id | biến thể "d" |

Chữ "d" trong tên loại instance nghĩa là có instance store.

Các lớp lưu trữ S3 — nhắc lại: | Lớp | Giá tham khảo | Thời gian lấy | |---|---|---| | Standard | ~0,023 USD/GB | tức thì | | Standard-IA | ~0,0125 USD/GB | tức thì | | Glacier Instant | ~0,004 USD/GB | mili giây | | Glacier Flexible | ~0,0036 USD/GB | 1 phút – 12 giờ | | Deep Archive | ~0,00099 USD/GB | 12–48 giờ |

Ba lưu ý khi thiết kế quy trình với instance store: | Lưu ý | Chi tiết | |---|---| | Tải dữ liệu từ S3 lúc bắt đầu | | | Ghi kết quả lên S3 theo từng phần | không đợi tới cuối | | Quy trình phải làm lại được từ đầu | |

Dòng giữa quan trọng:

Job chuyển mã chạy 6 giờ, chỉ ghi kết quả ở phút cuối
    → máy hỏng ở giờ thứ 5 = mất tất cả

Ghi từng phần lên S3
    → chỉ mất phần đang xử lý

Ba lưu ý về khởi tạo instance store: | Lưu ý | Chi tiết | |---|---| | KHÔNG được định dạng sẵn | phải mkfs trong user data | | Tên thiết bị có thể đổi | dùng lsblk để tìm | | RAID 0 nhiều ổ để cộng dồn IOPS | |

#!/bin/bash
DEV=$(lsblk -dn -o NAME,MODEL | grep -i "Instance Storage" | head -1 | awk '{print "/dev/"$1}')
mkfs -t xfs "$DEV" && mkdir -p /scratch && mount "$DEV" /scratch

Ba lựa chọn thay thế cho không gian làm việc tốc độ cao: | Lựa chọn | Đặc điểm | |---|---| | Instance store | nhanh nhất, không chia sẻ | | FSx for Lustre | chia sẻ nhiều máy, tích hợp S3 | | EBS io2 Block Express | bền vững, tới 256.000 IOPS |

FSx for Lustre rất hợp với xử lý video nhiều máy:

Liên kết bucket S3
    → tự nạp dữ liệu khi cần (lazy loading)
    → nhiều máy cùng xử lý một kho video
    → ghi kết quả ngược lại S3

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Thời gian lưu tối thiểu tính phí | Glacier 90, Deep Archive 180 ngày | | Object dưới 128 KB không tự chuyển | | | Có phí request khi chuyển lớp | |

Ba lưu ý về chuyển mã video: | Lưu ý | Chi tiết | |---|---| | Cân nhắc AWS Elemental MediaConvert | trả theo phút, không quản hạ tầng | | Spot cho tải chịu gián đoạn | | | Băng thông mạng của instance là trần | khi tải video từ S3 |

Ba metric cần theo dõi: | Metric | Ghi chú | |---|---| | DiskReadOps, DiskWriteOps | của INSTANCE STORE | | EBSReadOps, EBSWriteOps | của EBS | | NetworkIn/Out | tải từ S3 |

Chi tiết này hay gây nhầm: metric Disk* là instance store, EBS* mới là EBS volume.

Và một lời khuyên: hãy ghi kết quả lên S3 theo từng phần thay vì đợi job xong. Instance store mất dữ liệu là hành vi bình thường chứ không phải sự cố cần phòng tránh — và cách duy nhất sống chung với nó là thiết kế quy trình sao cho mất một máy chỉ tốn vài phút làm lại.

Đáp án

B — Dựng cụm ElastiCache for Redis đệm truy vấn danh mục, cấu hình ứng dụng dùng lazy loading để nạp cache.

Vì sao đúng

Đề nêu ba dữ kiện, và cả ba dẫn tới bộ đệm: | Dữ kiện | Kết luận | |---|---| | Danh mục phim ÍT KHI cập nhật | dữ liệu ổn định → đệm rất hiệu quả | | CPU của database tăng vọt khi duyệt danh mục | cần GIẢM SỐ truy vấn | | Người dùng phàn nàn chậm | đệm cho độ trễ micro giây |

Vế đầu là điều kiện lý tưởng cho đệm:

Dữ liệu ít đổi + được đọc rất nhiều
    → tỷ lệ trúng cache rất cao
        ↓
    Phần lớn truy vấn KHÔNG chạm tới database

Mẫu lazy loading (cache-aside):

import json, redis
r = redis.Redis(host='cum-dem.abc.ng.0001.apne1.cache.amazonaws.com')

def lay_danh_muc(the_loai, trang):
    khoa = f'danh-muc:{the_loai}:{trang}'
    kq = r.get(khoa)
    if kq is None:                       # trượt cache
        kq = json.dumps(db.query(the_loai, trang))
        r.setex(khoa, 3600, kq)          # TTL 1 giờ
    return json.loads(kq)

Và lazy loading có ba ưu điểm ở đây: | Ưu điểm | Chi tiết | |---|---| | Chỉ đệm dữ liệu THỰC SỰ được xem | không lãng phí bộ nhớ | | Node cache hỏng không gây lỗi | rơi về database | | Đơn giản, không cần đồng bộ khi ghi | |

Và TTL dài hợp lý vì danh mục ít đổi:

Danh mục cập nhật vài ngày một lần
    → TTL 1 giờ hoặc lâu hơn đều chấp nhận được
        ↓
    Hoặc xoá khoá tường minh khi có cập nhật

def cap_nhat_danh_muc(the_loai):
    db.update(...)
    for k in r.scan_iter(f'danh-muc:{the_loai}:*'):
        r.delete(k)

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

• **D. Bật read replica và phân phối truy vấn danh mục qua chúng — đây là phương án gần nhất và thực sự chia được tải, nhưng nó không giảm SỐ LƯỢNG truy vấn: cùng lượng công việc chỉ được chia cho nhiều máy, và mỗi replica là một instance đầy đủ phải trả tiền. Với truy vấn LẶP LẠI trên dữ liệu ít đổi, đệm hiệu quả và rẻ hơn nhiều.
• **C. Chuyển danh mục sang DynamoDB với DAX — đòi tái kiến trúc lớn: phải chuyển dữ liệu quan hệ sang mô hình khoá, viết lại truy vấn. Quá nhiều thay đổi cho một vấn đề đệm.
• **A. Dùng Aurora Serverless và "caching dựng sẵn của Aurora" — không có tính năng đó: Aurora không có lớp đệm kết quả truy vấn dựng sẵn. (Aurora có buffer pool như mọi database, nhưng đó là chuyện khác.)

Ghi nhớ

Ba cách giảm tải đọc — theo thứ tự nên thử: | Thứ tự | Cách | Hiệu quả | |---|---|---| | ① | Tối ưu truy vấn và index | rẻ nhất | | ② | Đệm (ElastiCache) | LOẠI BỎ truy vấn | | ③ | Read replica | chia nhỏ cùng lượng tải |

Khác biệt cốt lõi giữa ② và ③:

Read replica: chia cùng lượng truy vấn cho nhiều máy
ElastiCache:  LOẠI BỎ phần lớn truy vấn
        ↓
    Với truy vấn LẶP LẠI, đệm hiệu quả hơn nhiều

Ba mẫu đệm — bảng phải thuộc: | Mẫu | Cơ chế | Đánh đổi | |---|---|---| | Lazy loading (cache-aside) | đọc trượt thì nạp | lần đọc đầu luôn trượt | | Write-through | ghi cả hai nơi | dữ liệu luôn mới, tốn ghi | | TTL | tự hết hạn | dữ liệu có thể cũ trong khoảng TTL |

Từ khoá nhận diện:

"lazy loading", "populate cache on miss" → cache-aside "data always fresh in cache" → write-through

Redis và Memcached — bảng nhắc lại: | | Redis | Memcached | |---|---|---| | Cấu trúc dữ liệu | phong phú | chỉ key-value | | Sao chép, Multi-AZ | ✅ | ❌ | | Bền vững | ✅ | ❌ | | Đa luồng | I/O threading | ✅ |

Với danh mục cần sẵn sàng cao, Redis là lựa chọn đúng.

Ba cấu hình cho ElastiCache sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Multi-AZ với automatic failover | | | Ít nhất 2 replica | | | Mã hoá at rest và in transit | |

aws elasticache create-replication-group   --replication-group-id cum-danh-muc   --replication-group-description "Dem danh muc phim"   --engine redis --cache-node-type cache.r6g.large   --num-cache-clusters 3   --automatic-failover-enabled --multi-az-enabled

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp = đệm không hiệu quả | | Evictions | cao = bộ nhớ không đủ | | EngineCPUUtilization | CPU của tiến trình Redis |

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

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

Ba nguyên tắc thiết kế khoá cache: | Nguyên tắc | Chi tiết | |---|---| | Khoá phản ánh đúng truy vấn | gồm bộ lọc và phân trang | | TTL phù hợp với độ tươi cần thiết | | | Xoá khoá khi dữ liệu đổi | hoặc dựa vào TTL |

Ba cách vô hiệu hoá cache: | Cách | Chi tiết | |---|---| | TTL hết hạn | đơn giản nhất | | Xoá khoá khi cập nhật | chính xác hơn | | Đưa phiên bản vào tiền tố khoá | v2:danh-muc:... |

Cách thứ ba rất tiện:

Đổi tiền tố phiên bản khi schema đổi
    → toàn bộ cache cũ tự bị bỏ qua
        ↓
    Không phải xoá từng khoá

Ba lưu ý về Single-AZ RDS trong đề: | Lưu ý | Chi tiết | |---|---| | Đề nói RDS đang chạy Single-AZ | không có sẵn sàng cao | | Nên bật Multi-AZ cho sản xuất | ngoài phạm vi câu hỏi | | Đệm cũng giảm rủi ro khi database quá tải | |

Ba lựa chọn đệm khác: | Lựa chọn | Đặc điểm | |---|---| | ElastiCache | ← câu này, linh hoạt nhất | | CloudFront | đệm phản hồi API ở biên | | DAX | chỉ cho DynamoDB |

CloudFront đáng cân nhắc bổ sung:

Danh mục phim là dữ liệu công khai, ít đổi
    → đệm phản hồi API ở edge
        ↓
    Request thậm chí không tới ALB

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | ElastiCache tính theo node-giờ | | | Rẻ hơn nhiều so với thêm read replica | cho cùng lượng truy vấn | | Reserved node giảm tới 55% | |

Và một lời khuyên: hãy đo tỷ lệ trúng cache sau một tuần thay vì chỉ giả định. Với danh mục phim, tỷ lệ thường rất cao vì ai cũng xem những trang đầu tiên — nhưng nếu người dùng chủ yếu tìm kiếm với từ khoá riêng, mỗi truy vấn là một khoá khác nhau và bộ đệm sẽ gần như vô dụng.

Đáp án

A — Tải chứng chỉ gốc do AWS cung cấp, dùng chứng chỉ đó khi kết nối tới RDS instance.

Vì sao đúng

Đề nêu tình huống: đã mã hoá at rest bằng KMS, nay cần mã hoá TRÊN ĐƯỜNG TRUYỀN.

RDS ĐÃ hỗ trợ TLS sẵn từ khi tạo instance
    → AWS tự cấp và quản lý chứng chỉ máy chủ
        ↓
    Không có công tắc "bật mã hoá in transit"
    → chỉ cần CLIENT dùng đúng chứng chỉ gốc để kết nối

Tải bundle chứng chỉ:

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

Và kết nối có xác minh:

jdbc:mysql://db.abc.ap-northeast-1.rds.amazonaws.com:3306/don_hang
  ?useSSL=true&requireSSL=true&verifyServerCertificate=true
  &trustCertificateKeyStoreUrl=file:///opt/certs/truststore.jks

Và nên bắt buộc TLS ở phía server:

aws rds modify-db-parameter-group --db-parameter-group-name nhom-tham-so   --parameters "ParameterName=require_secure_transport,ParameterValue=ON,ApplyMethod=immediate"

Với MySQL và MariaDB: require_secure_transport
Với PostgreSQL và SQL Server: rds.force_ssl
        ↓
    Mọi kết nối KHÔNG dùng TLS bị TỪ CHỐI

Ba mức xác minh của client — nên hiểu rõ: | Mức | Kiểm tra | |---|---| | Chỉ mã hoá | KHÔNG xác minh chứng chỉ | | Xác minh CA | chứng chỉ do CA tin cậy ký | | Xác minh đầy đủ | CA VÀ tên máy chủ — chống giả mạo |

Chỉ mã hoá là chưa đủ:

Kẻ tấn công chen giữa vẫn thiết lập được TLS
    → đọc được toàn bộ dữ liệu đơn hàng
        ↓
    Phải xác minh chứng chỉ — đó là lý do cần
      chứng chỉ gốc của AWS

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

• **B. Bật mã hoá in transit trong RDS console và lấy khoá từ KMS — đây là phương án gần nhất vì nghe giống một thao tác cấu hình bình thường, nhưng nó không tồn tại: RDS không có công tắc bật mã hoá đường truyền, và KMS quản lý khoá at rest, không liên quan tới TLS.
• **C. Chụp snapshot rồi khôi phục sang instance mới có mã hoá in transit — không cần thiết và không có thứ đó: TLS đã sẵn sàng trên instance hiện tại.
• **D. Thêm chứng chỉ tự ký vào RDS instance — không làm được: RDS tự quản lý chứng chỉ máy chủ, bạn không thay được bằng chứng chỉ riêng.

Ghi nhớ

Hai loại mã hoá — bảng phải thuộc: | Loại | Bảo vệ | Cơ chế của RDS | |---|---|---| | At rest | dữ liệu trên đĩa, snapshot, replica | KMS, bật LÚC TẠO | | In transit | dữ liệu trên mạng | TLS, SẴN CÓ |

Câu hỏi nào nói "đã mã hoá at rest, cần bảo vệ thêm" thì đáp án là TLS.

Ba tham số bắt buộc TLS theo engine: | Engine | Tham số | |---|---| | MySQL, MariaDB | require_secure_transport = ON | | PostgreSQL, SQL Server | rds.force_ssl = 1 | | Oracle | SQLNET.SSL_VERSION |

Ba chế độ xác minh của client PostgreSQL: | Chế độ | Mã hoá | Xác minh CA | Xác minh tên | |---|---|---|---| | require | ✅ | ❌ | ❌ | | verify-ca | ✅ | ✅ | ❌ | | verify-full | ✅ | ✅ | ✅ |

Ba lưu ý về chứng chỉ của RDS: | Lưu ý | Chi tiết | |---|---| | RDS tự cấp và xoay vòng | KHÔNG dùng ACM | | Chứng chỉ CÓ HẠN — phải cập nhật | | | Global bundle dùng cho mọi Region | đơn giản nhất |

Dòng giữa là sự cố hay gặp:

Chứng chỉ CA của RDS hết hạn
    → mọi kết nối xác minh đầy đủ THẤT BẠI
        ↓
    AWS báo trước rất lâu, nhưng cần theo dõi

aws rds modify-db-instance --db-instance-identifier db-don-hang   --ca-certificate-identifier rds-ca-rsa2048-g1 --apply-immediately

Ba lưu ý về mã hoá at rest của RDS: | Lưu ý | Chi tiết | |---|---| | Chỉ bật được LÚC TẠO | | | Mã hoá instance cũ: snapshot → copy có mã hoá → restore | | | Snapshot và replica kế thừa mã hoá | |

Ba lớp bảo mật cho RDS: | Lớp | Cơ chế | |---|---| | Mạng | private subnet, security group, không public | | Truyền tải | TLS bắt buộc ← câu này | | Lưu trữ | KMS | | Danh tính | IAM authentication hoặc Secrets Manager |

Ba cách xác thực tới RDS: | Cách | Đặc điểm | |---|---| | Mật khẩu | đơn giản, cần xoay vòng | | Secrets Manager với xoay vòng tự động | khuyến nghị | | IAM database authentication | token 15 phút, không mật khẩu tĩnh |

aws rds generate-db-auth-token --hostname db.abc.rds.amazonaws.com   --port 3306 --username ung_dung --region ap-northeast-1

Ba cách kiểm chứng TLS đang hoạt động: | Engine | Lệnh | |---|---| | MySQL | SHOW STATUS LIKE 'Ssl_cipher'; | | PostgreSQL | SELECT ssl FROM pg_stat_ssl WHERE pid = pg_backend_pid(); | | Từ ngoài | openssl s_client -connect db:3306 -starttls mysql |

Ba lưu ý khi bật bắt buộc TLS: | Lưu ý | Chi tiết | |---|---| | Client cũ không hỗ trợ TLS sẽ bị TỪ CHỐI | kiểm tra trước | | Cập nhật client TRƯỚC, bật bắt buộc SAU | | | PostgreSQL cần khởi động lại | tham số pending-reboot |

Ba tiêu chuẩn yêu cầu mã hoá in transit: | Tiêu chuẩn | Yêu cầu | |---|---| | PCI DSS | bắt buộc cho dữ liệu thẻ | | HIPAA | cho dữ liệu y tế | | GDPR | biện pháp kỹ thuật phù hợp |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | TLS thêm chi phí bắt tay | dùng connection pool | | Chi phí mã hoá dữ liệu không đáng kể | | | RDS Proxy giữ kết nối TLS sẵn | giảm số lần bắt tay |

Và một lời khuyên: hãy kiểm chứng bằng truy vấn trạng thái SSL sau khi cấu hình, đừng chỉ tin vào chuỗi kết nối. Nhiều driver âm thầm rơi về kết nối không mã hoá khi cấu hình TLS có vấn đề — và ứng dụng sẽ chạy hoàn toàn bình thường trong khi dữ liệu đơn hàng đi qua mạng dưới dạng bản rõ.

Đáp án

B — CloudFront và S3 cho frontend tĩnh; tái cấu trúc backend thành Lambda được gọi qua API Gateway; chuyển database sang Aurora Serverless.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án B đáp ứng cả bốn với ít công vận hành nhất: | Yêu cầu | Cơ chế | |---|---| | An toàn | CloudFront + WAF, Lambda không lộ máy chủ | | Co giãn | cả ba tầng đều tự co giãn | | Toàn cầu | CloudFront đệm ở biên | | Ít công vận hành nhất | serverless từ đầu tới cuối |

Và đề cho hai dữ kiện quan trọng:

"NON-PRODUCTION application"
"a SINGLE development team maintains all the microservices"
        ↓
    Một đội nhỏ, ứng dụng không phải sản xuất
    → càng ít thứ phải vận hành càng tốt
        ↓
    Serverless là lựa chọn đúng

Ba tầng đều không có máy chủ nào: | Tầng | Dịch vụ | Công vận hành | |---|---|---| | Frontend | S3 + CloudFront | gần như không | | Backend | API Gateway + Lambda | không quản máy | | Database | Aurora Serverless v2 | tự co giãn |

Và Aurora Serverless giữ được mô hình quan hệ:

Ứng dụng đang dùng MySQL
    → Aurora Serverless tương thích MySQL
        ↓
    KHÔNG phải viết lại truy vấn
    → khác hẳn việc chuyển sang DynamoDB

Triển khai Aurora Serverless v2:

aws rds create-db-cluster --db-cluster-identifier cum-ung-dung   --engine aurora-mysql --engine-mode provisioned   --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16   --master-username quantri --manage-master-user-password

aws rds create-db-instance --db-instance-identifier instance-1   --db-cluster-identifier cum-ung-dung --engine aurora-mysql   --db-instance-class db.serverless

Và với ứng dụng không phải sản xuất, chi phí rất thấp:

Lambda: trả theo lời gọi, gần như 0 khi không dùng
API Gateway: trả theo request
Aurora Serverless: co giãn xuống mức tối thiểu
        ↓
    Ngoài giờ làm việc, chi phí giảm mạnh

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

• **A. CloudFront + S3, backend sang ECS trên Fargate, database sang DynamoDB — đây là phương án gần nhất và cũng là kiến trúc hợp lệ, nhưng nó đòi viết lại tầng dữ liệu: chuyển từ MySQL sang DynamoDB nghĩa là thiết kế lại mô hình dữ liệu và mọi truy vấn. Và Fargate vẫn cần định nghĩa task, cluster, service.
• **C. AWS Amplify cho frontend, EKS cho backend, RDS MySQL với read replica — EKS có công vận hành cao nhất: phải quản lý cụm Kubernetes, node group, nâng cấp phiên bản.
• **D. CloudFront + Amplify, Lambda gọi qua EventBridge bus, database trên EC2 Reserved Instance — hai lỗi: EventBridge là bus sự kiện bất đồng bộ, không phù hợp cho API request-response; và database trên EC2 là bước lùi lớn nhất về công vận hành.

Ghi nhớ

Kiến trúc web serverless ba tầng — mẫu chuẩn: | Tầng | Dịch vụ | |---|---| | Frontend tĩnh | S3 + CloudFront (hoặc Amplify Hosting) | | API | API Gateway + Lambda | | Dữ liệu | Aurora Serverless hoặc DynamoDB |

Chọn database serverless: | Nhu cầu | Chọn | |---|---| | Cần SQL, JOIN, giao dịch quan hệ | Aurora Serverless v2 | | Key-value, quy mô cực lớn | DynamoDB on-demand | | Đang dùng MySQL, muốn ít sửa mã | Aurora Serverless |

Ba lựa chọn tính toán serverless: | Lựa chọn | Đặc điểm | |---|---| | Lambda | sự kiện, dưới 15 phút | | Fargate | container, không giới hạn thời gian | | App Runner | ứng dụng web container, đơn giản nhất |

Ba lựa chọn API: | Lựa chọn | Đặc điểm | |---|---| | API Gateway REST API | đầy đủ tính năng: cache, usage plan, WAF | | API Gateway HTTP API | rẻ hơn ~70%, tối giản | | Lambda Function URL | đơn giản nhất, không có API Gateway |

Ba đặc điểm của Aurora Serverless v2: | Đặc điểm | Chi tiết | |---|---| | Đo bằng ACU | 1 ACU ≈ 2 GiB bộ nhớ | | Co giãn trong VÀI GIÂY | không gián đoạn | | Hỗ trợ đầy đủ tính năng Aurora | replica, Global Database |

Ba lưu ý về Lambda kết nối database: | Lưu ý | Chi tiết | |---|---| | Dùng RDS Proxy | gộp kết nối, tránh cạn | | Đặt reserved concurrency | giới hạn áp lực lên database | | Bí mật trong Secrets Manager | |

RDS Proxy gần như bắt buộc với Lambda:

1.000 Lambda đồng thời = 1.000 kết nối database
    → cạn kết nối
        ↓
    RDS Proxy gộp và tái sử dụng

Ba lưu ý về Amplify: | Lưu ý | Chi tiết | |---|---| | Amplify Hosting = CI/CD + CDN cho frontend | dùng CloudFront bên dưới | | Tiện cho đội nhỏ | | | S3 + CloudFront linh hoạt hơn | kiểm soát chi tiết |

Ba lợi ích của CloudFront cho frontend: | Lợi ích | Chi tiết | |---|---| | Đệm toàn cầu | ← yêu cầu "globally available" | | HTTPS với chứng chỉ ACM miễn phí | | | WAF gắn được | |

Ba biện pháp bảo mật: | Biện pháp | Chi tiết | |---|---| | OAC cho bucket S3 | bucket riêng tư | | WAF trên CloudFront | lọc tấn công | | Cognito hoặc Lambda authorizer cho API | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Serverless rẻ khi tải thấp hoặc không đều | | | Có thể đắt hơn khi tải cao và ổn định | | | Với ứng dụng KHÔNG sản xuất, serverless rẻ hơn nhiều | |

Ba bước tái cấu trúc: | Bước | Chi tiết | |---|---| | ① Tách frontend tĩnh sang S3 | đơn giản nhất, hiệu quả ngay | | ② Chuyển database sang Aurora Serverless | ít sửa mã | | ③ Tái cấu trúc backend sang Lambda | tốn công nhất |

Nên làm theo thứ tự này — mỗi bước cho lợi ích ngay mà không phụ thuộc bước sau.

Ba lưu ý khi chuyển Java sang Lambda: | Lưu ý | Chi tiết | |---|---| | Cold start của Java lâu hơn | dùng SnapStart | | Giới hạn 15 phút | | | Cân nhắc Fargate nếu khó tách nhỏ | |

SnapStart giảm cold start của Java đáng kể:

aws lambda update-function-configuration --function-name api-backend   --snap-start ApplyOn=PublishedVersions

Và một lời khuyên: hãy chuyển frontend sang S3 và CloudFront trước tiên. Đó là bước ít rủi ro nhất, cho cải thiện độ trễ toàn cầu ngay lập tức, và không phụ thuộc vào việc tái cấu trúc backend — nghĩa là bạn có kết quả đo được trước khi bắt đầu phần khó.

Đáp án

B — Chuyển database sang Aurora Global Database ở chế độ tương thích MySQL, đặt read replica ở ap-southeast-2.

Vì sao đúng

Đề nêu vấn đề rõ: tầng ứng dụng đã ở Úc, nhưng database vẫn ở châu Âu.

Người dùng Úc → tầng ứng dụng ap-southeast-2 (gần) ✓
    → nhưng mỗi truy vấn phải đi tới eu-west-2
        ↓
    Độ trễ vòng lượt Sydney ↔ London ≈ 250–300 mili giây
    → một trang cần 10 truy vấn = 3 giây chỉ riêng độ trễ mạng

Aurora Global Database giải quyết triệt để:

Cluster phụ ở ap-southeast-2 có BẢN SAO ĐẦY ĐỦ
    → ứng dụng Úc đọc từ cluster ĐỊA PHƯƠNG
    → độ trễ từ 250ms xuống vài mili giây
        ↓
    Và sao chép xuyên Region thường DƯỚI MỘT GIÂY

Và cơ chế sao chép rất đặc biệt:

KHÔNG dùng binlog như MySQL thường
    → sao chép ở TẦNG LƯU TRỮ, hạ tầng riêng của AWS
        ↓
    Độ trễ điển hình dưới 1 giây
    → và KHÔNG tốn CPU của cluster chính

Triển khai:

aws rds create-global-cluster   --global-cluster-identifier cum-toan-cau   --source-db-cluster-identifier arn:aws:rds:eu-west-2:...:cluster:cum-chinh

aws rds create-db-cluster --db-cluster-identifier cum-uc   --engine aurora-mysql --region ap-southeast-2   --global-cluster-identifier cum-toan-cau

aws rds create-db-instance --db-instance-identifier reader-uc   --db-cluster-identifier cum-uc --engine aurora-mysql   --db-instance-class db.r6g.large --region ap-southeast-2

Và ứng dụng Úc dùng reader endpoint địa phương:

cum-uc.cluster-ro-xyz.ap-southeast-2.rds.amazonaws.com

⚠ Và cần biết giới hạn: chỉ MỘT writer.

Aurora Global Database có MỘT cluster ghi (eu-west-2)
    → lệnh GHI từ Úc vẫn phải đi tới châu Âu
        ↓
    Đề nói vấn đề là "slow response times to QUERIES"
    → tải ĐỌC, nên giải pháp này phù hợp

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

• **A. Chuyển sang RDS for MySQL và bật Multi-AZ ở Region Úc — đây là phương án gần nhất vì có nhắc tới Region Úc, nhưng nó hiểu sai Multi-AZ: Multi-AZ hoạt động trong một Region, và standby không phục vụ đọc. Nó không đưa dữ liệu tới gần người dùng Úc.
• **C. Chuyển sang DynamoDB với global tables — đòi tái kiến trúc lớn: chuyển từ MySQL sang NoSQL nghĩa là thiết kế lại mô hình dữ liệu và viết lại mọi truy vấn. Quá nhiều thay đổi khi vấn đề chỉ là vị trí bản sao.
• **D. Triển khai MySQL ở mỗi Region với ALB phía trước — ALB không cân bằng tải cho database: nó hoạt động ở tầng HTTP. Và "MySQL instance ở mỗi Region" không tự đồng bộ với nhau.

Ghi nhớ

Các lựa chọn database đa Region — bảng phải thuộc: | Dịch vụ | Ghi đa Region | Độ trễ sao chép | |---|---|---| | Aurora Global Database | ❌ một writer | < 1 giây | | DynamoDB global table | ✅ mọi Region | thường < 1 giây | | RDS cross-Region replica | ❌ | giây tới phút |

Quy tắc chọn:

Cần quan hệ, tải ĐỌC toàn cầu → Aurora Global Database Cần GHI ở nhiều Region, NoSQL chấp nhận được → DynamoDB global table

Ba khái niệm của Aurora Global Database: | Khái niệm | Việc | |---|---| | Global cluster | tài nguyên bao ngoài | | Primary cluster | DUY NHẤT được GHI | | Secondary cluster | chỉ đọc, sẵn sàng thăng cấp |

Ba giới hạn cần biết: | Giới hạn | Giá trị | |---|---| | Số Region phụ | tới 5 | | Replica đọc mỗi Region | tới 16 | | Độ trễ sao chép điển hình | dưới 1 giây |

Ba lợi ích của Aurora Global Database: | Lợi ích | Chi tiết | |---|---| | Đọc độ trễ thấp ở nhiều Region | ← câu này | | Khôi phục thảm hoạ RTO < 1 phút | managed failover | | Không ảnh hưởng hiệu năng cluster chính | |

Ba lưu ý về write forwarding: | Lưu ý | Chi tiết | |---|---| | Cluster phụ NHẬN được lệnh ghi | với write forwarding bật | | Nhưng nó CHUYỂN TIẾP về primary | | | Độ trễ vẫn là độ trễ xuyên Region | |

Đây là điểm hay hiểu nhầm:

Write forwarding KHÔNG biến Aurora thành multi-writer
    → chỉ tiện về mặt lập trình (một endpoint)
        ↓
    Độ trễ ghi không cải thiện

Ba loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance ghi | | Reader | cân bằng qua replica trong CÙNG cluster | | Custom | nhóm tự định nghĩa |

Ứng dụng ở mỗi Region dùng reader endpoint của cluster ĐỊA PHƯƠNG.

Ba lưu ý về nhất quán: | Lưu ý | Chi tiết | |---|---| | Cluster phụ có độ trễ dưới 1 giây | | | Đọc-sau-ghi có thể chưa thấy dữ liệu | | | Với truy vấn báo cáo thì chấp nhận được | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | AuroraGlobalDBReplicationLag | độ trễ xuyên Region | | AuroraGlobalDBRPOLag | RPO thực tế | | AuroraReplicaLag | trong cùng cluster |

Ba cách di chuyển từ MySQL trên EC2 sang Aurora: | Cách | Đặc điểm | |---|---| | Snapshot rồi restore thành Aurora | có ngừng | | AWS DMS với CDC | ngừng tối thiểu | | Percona XtraBackup lên S3 rồi restore | cho khối lượng lớn |

DMS là lựa chọn phổ biến:

aws dms create-replication-task   --replication-task-identifier mysql-sang-aurora   --source-endpoint-arn <arn-mysql-ec2>   --target-endpoint-arn <arn-aurora>   --migration-type full-load-and-cdc   --table-mappings file://anh-xa.json

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Instance ở mỗi Region tính phí đầy đủ | | | Phí sao chép ~0,20 USD mỗi triệu request I/O | | | Headless secondary rẻ hơn nhiều | chỉ lưu trữ, không instance |

Ba lưu ý về Route 53 trong kiến trúc này: | Lưu ý | Chi tiết | |---|---| | Geoproximity đã đưa người dùng tới đúng tầng ứng dụng | | | Database không cần Route 53 | ứng dụng khai endpoint địa phương | | Latency-based routing cũng dùng được | |

Ba việc nên làm sau khi triển khai: | Việc | Chi tiết | |---|---| | Xác nhận ứng dụng Úc dùng endpoint địa phương | | | Đo độ trễ truy vấn trước và sau | | | Đặt alarm cho AuroraGlobalDBReplicationLag | |

Và một lời khuyên: hãy kiểm tra tỷ lệ đọc so với ghi của ứng dụng trước khi triển khai. Aurora Global Database chỉ cải thiện phần ĐỌC — nếu người dùng Úc chủ yếu thực hiện thao tác ghi, độ trễ của họ sẽ gần như không đổi, và giải pháp đúng khi đó là một kiến trúc hoàn toàn khác.

Đáp án

A — Kết nối ứng dụng sao lưu tới AWS Storage Gateway ở chế độ iSCSI Virtual Tape Library (VTL).

Vì sao đúng

Đề nêu hai yêu cầu, và Tape Gateway đáp ứng chính xác: | Yêu cầu | Cơ chế | |---|---| | Bỏ băng từ vật lý | băng ẢO lưu trên S3 và Glacier | | Ứng dụng sao lưu HIỆN CÓ vẫn chạy | giao diện iSCSI VTL — phần mềm không biết khác biệt |

Vế thứ hai là điểm phân biệt quyết định:

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ó gửi lệnh SCSI y hệt như với thiết bị thật
        ↓
    Veeam, NetBackup, Commvault, Backup Exec dùng được NGAY
    → không đổi quy trình, không đổi lịch sao lưu

Và vòng đời 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í rất thấp cho dữ liệu giữ nhiều năm

Tạo băng ảo:

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

Ba lợi ích so với băng vật lý: | Lợi ích | Chi tiết | |---|---| | Không có băng để 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

• **D. Kết nối ứng dụng sao lưu tới Storage Gateway bằng giao thức iSCSI (không nói VTL) — đây là phương án gần nhất và chỉ khác một chữ, nhưng đó là chữ quyết định: iSCSI thuần là Volume Gateway, cung cấp volume khối chứ không phải thư viện băng. Phần mềm sao lưu dùng băng sẽ không nhận ra nó.
• **C. Tạo EFS và kết nối bằng NFS — thay đổi hoàn toàn quy trình: phần mềm sao lưu phải cấu hình lại để ghi vào thư mục thay vì băng, và nhiều phần mềm không hỗ trợ.
• **B. Tạo EFS và kết nối bằng iSCSI — EFS KHÔNG hỗ trợ iSCSI: nó chỉ xuất giao thức NFS.

Ghi nhớ

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

Từ khoá nhận diện:

"replace physical tapes", "existing backup software", "VTL" → Tape Gateway "NFS/SMB access to S3" → File Gateway "iSCSI block volumes" → Volume Gateway

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 | 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>

Đây là điểm phải tính vào quy trình khôi phục — băng archive không đọc 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 VPC endpoint |

Ba cách tối ưu chi phí: | Cách | Chi tiết | |---|---| | Archive băng cũ sang Deep Archive | rẻ nhất | | Kích thước băng ảo hợp lý | 100 GB – 5 TB | | Giới hạn băng thông 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 lên S3 | | WorkingStoragePercentUsed | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest trong S3 | SSE-S3 hoặc SSE-KMS | | Truyền qua TLS | | | Kết hợp Object Lock nếu cần WORM | |

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 | | DataSync | di chuyển tệp hàng loạt | | Direct Connect | kết nối mạng riêng |

Ba lựa chọn thay thế cho sao lưu: | Lựa chọn | Đặc điểm | |---|---| | Tape Gateway | ← câu này, giữ phần mềm cũ | | AWS Backup | quản lý tập trung, nhưng cho tài nguyên AWS | | Phần mềm sao lưu ghi thẳng lên S3 | nếu phần mềm hỗ trợ |

Cách thứ ba đáng cân nhắc:

Nhiều phần mềm sao lưu hiện đại hỗ trợ S3 làm đích
    → không cần gateway nào
        ↓
    Kiểm tra phiên bản phần mềm trước khi dựng Tape Gateway

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 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ẽ phá vỡ toàn bộ RTO đã cam kết.

Đáp án

C — Bật automated backup của RDS với thời gian giữ 35 ngày và point-in-time recovery cho 10 ngày gần nhất; dùng AWS Backup giữ thêm bản sao lưu tới 120 ngày.

Vì sao đúng

Đề nêu hai yêu cầu với hai khoảng thời gian khác nhau: | Yêu cầu | Cơ chế | |---|---| | Khôi phục về BẤT KỲ thời điểm nào trong 10 ngày | automated backup + PITR | | Giữ bản sao lưu 120 ngày | AWS Backup |

Và điểm mấu chốt: automated backup của RDS chỉ giữ TỐI ĐA 35 NGÀY.

RDS automated backup:
    → thời gian giữ 1–35 ngày
    → cho point-in-time recovery trong khoảng đó
        ↓
    KHÔNG đặt được 120 ngày
    → cần cơ chế thứ hai cho phần còn lại

AWS Backup lo phần dài hạn:

aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "luu-tru-120-ngay",
  "Rules": [{
    "RuleName": "hang-ngay",
    "TargetBackupVaultName": "vault-tuan-thu",
    "ScheduleExpression": "cron(0 3 * * ? *)",
    "Lifecycle": {"DeleteAfterDays": 120}}]}'

Và bật automated backup với PITR:

aws rds modify-db-instance --db-instance-identifier db-y-te   --backup-retention-period 35   --preferred-backup-window "17:00-18:00"   --apply-immediately

Hai cơ chế phục vụ hai mục đích khác nhau: | Cơ chế | Cho phép | |---|---| | Automated backup (PITR) | khôi phục về BẤT KỲ GIÂY nào trong 35 ngày | | AWS Backup | khôi phục về các THỜI ĐIỂM CHỤP, giữ 120 ngày |

Và đó chính là lý do cần cả hai:

Yêu cầu 1: PITR trong 10 ngày → automated backup thừa sức
Yêu cầu 2: giữ 120 ngày       → vượt trần 35 ngày của RDS
        ↓
    Một cơ chế không đáp ứng được cả hai

Và AWS Backup có Vault Lock cho yêu cầu tuân thủ:

aws backup put-backup-vault-lock-configuration   --backup-vault-name vault-tuan-thu   --min-retention-days 120 --changeable-for-days 3

Sau 3 ngày, cấu hình khoá vĩnh viễn
    → KHÔNG AI xoá backup trước 120 ngày được
        ↓
    Bằng chứng tuân thủ cho kiểm toán viên

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

• **D. Dùng AWS Backup với thời gian giữ 120 ngày và bật PITR bằng cách kết hợp AWS Backup với automated backup — đây là phương án gần nhất và về ý tưởng gần giống đáp án đúng, nhưng cách diễn đạt mơ hồ và không chính xác: AWS Backup không tự bật PITR cho RDS; PITR là tính năng của chính automated backup và phải cấu hình riêng. (AWS Backup có hỗ trợ continuous backup cho RDS với PITR tới 35 ngày, nhưng phương án không nêu điều đó.)
• **A. Manual snapshot hằng tuần + Lambda xoá snapshot cũ hơn 120 ngày — không đạt yêu cầu PITR: snapshot hằng tuần chỉ cho khôi phục về 7 thời điểm, không phải bất kỳ giây nào trong 10 ngày. Và phải tự viết mã.
• **B. S3 Lifecycle giữ bản xuất 120 ngày, dùng DMS xuất database mỗi 24 giờ — không có PITR và công vận hành cao: phải vận hành DMS, và bản xuất hằng ngày chỉ cho khôi phục về từng ngày.

Ghi nhớ

Ba cơ chế bảo vệ dữ liệu RDS — bảng phải thuộc: | Cơ chế | Thời gian giữ | PITR | |---|---|---| | Automated backup | 1–35 ngày | ✅ tới từng giây | | Manual snapshot | vô thời hạn | ❌ theo thời điểm chụp | | AWS Backup | tuỳ chính sách | continuous backup: 35 ngày |

Con số 35 ngày là trần cứng của automated backup — đây là chi tiết hay được hỏi.

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

Xoá RDS instance
    → automated backup BỊ XOÁ THEO
    → manual snapshot và AWS Backup VẪN CÒN
        ↓
    Với yêu cầu tuân thủ, phải có cơ chế độc lập với instance

Ba đặc điểm của automated backup: | Đặc điểm | Chi tiết | |---|---| | Snapshot hằng ngày + transaction log mỗi 5 phút | | | Với Multi-AZ, lấy từ STANDBY | không ảnh hưởng primary | | RPO tới 5 phút | |

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

aws rds restore-db-instance-to-point-in-time   --source-db-instance-identifier db-y-te   --target-db-instance-identifier db-khoi-phuc   --restore-time 2026-08-25T14:32:16Z

Lưu ý: tạo INSTANCE MỚI, không ghi đè instance cũ.

Ba khái niệm của AWS Backup: | Khái niệm | Việc | |---|---| | Backup plan | lịch, thời gian giữ, quy tắc sao chép | | Backup vault | nơi chứa, khoá được bằng Vault Lock | | Backup selection | tài nguyên nào được sao lưu |

Ba cách chọn tài nguyên: | Cách | Chi tiết | |---|---| | Theo ARN cụ thể | | | Theo TAG | linh hoạt nhất | | Theo loại tài nguyên | |

Ba tính năng của AWS Backup: | Tính năng | Chi tiết | |---|---| | Vault Lock | backup KHÔNG xoá được, kể cả root | | Sao chép xuyên Region | cho khôi phục thảm hoạ | | Backup Audit Manager | báo cáo tuân thủ |

Backup Audit Manager rất hữu ích với yêu cầu tuân thủ:

aws backup create-framework --framework-name khung-tuan-thu   --framework-controls '[{
    "ControlName":"BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK",
    "ControlInputParameters":[{"ParameterName":"requiredRetentionDays",
                               "ParameterValue":"120"}]}]'

Tự kiểm tra mọi tài nguyên có backup đúng chính sách chưa
    → sinh báo cáo cho kiểm toán viên

Ba lưu ý về chi phí backup: | Khoản | Chi tiết | |---|---| | Automated backup miễn phí tới dung lượng database | vượt thì tính phí | | AWS Backup tính theo GB lưu trữ | | | Cold storage rẻ hơn cho bản giữ lâu | |

AWS Backup hỗ trợ chuyển sang cold storage:

{"Lifecycle": {"MoveToColdStorageAfterDays": 30, "DeleteAfterDays": 120}}

30 ngày đầu ở warm storage (khôi phục nhanh)
    → sau đó sang cold storage (rẻ hơn)
        ↓
    Lưu ý: cold storage tối thiểu 90 ngày

Ba việc Multi-AZ KHÔNG bảo vệ: | Không bảo vệ | Cách bảo vệ | |---|---| | Lỗi con người (xoá nhầm bảng) | PITR | | Thảm hoạ Region | backup xuyên Region | | Dữ liệu hỏng do ứng dụng | PITR |

Ba yêu cầu tuân thủ y tế liên quan: | Yêu cầu | Cơ chế | |---|---| | HIPAA | ký BAA, mã hoá | | Thời gian lưu giữ | ← câu này | | Bằng chứng không bị sửa | Vault Lock |

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | THỬ khôi phục thật | hàng quý | | Kiểm tra báo cáo Backup Audit Manager | hàng tháng | | Xác nhận thời gian giữ còn đúng chính sách | |

Và một lời khuyên: hãy thực sự khôi phục một bản sao lưu 100 ngày tuổi ít nhất một lần. Bản sao lưu dài hạn thường nằm yên nhiều tháng và chỉ được dùng đúng lúc khủng hoảng — và những thứ như thiếu quyền KMS hay subnet group đã bị xoá chỉ lộ ra khi bạn thật sự bấm nút khôi phục.

Đáp án

C — Đặt password policy cho TOÀN BỘ tài khoản AWS.

Vì sao đúng

IAM có đúng một cơ chế cho việc này, và nó ở cấp tài khoản:

IAM account password policy:
    → áp cho MỌI IAM user trong tài khoản
    → khai độ dài tối thiểu, ký tự bắt buộc, thời hạn
        ↓
    Một cấu hình duy nhất, không phải làm từng người

Cấu hình:

aws iam update-account-password-policy   --minimum-password-length 14   --require-uppercase-characters   --require-lowercase-characters   --require-numbers   --require-symbols   --allow-users-to-change-password   --max-password-age 90   --password-reuse-prevention 24

Và không có cơ chế nào ở cấp thấp hơn:

KHÔNG có password policy cho từng IAM user
    → chính sách là thuộc tính của TÀI KHOẢN
        ↓
    Đây là lý do phương án B không làm được

Và IAM policy không kiểm soát được độ phức tạp mật khẩu:

IAM policy kiểm soát HÀNH ĐỘNG nào được phép
    → không kiểm soát HÌNH THỨC của mật khẩu
        ↓
    Có thể chặn iam:ChangePassword, nhưng không đặt
      được quy tắc "ít nhất 14 ký tự"

Ba tuỳ chọn của password policy: | Tuỳ chọn | Chi tiết | |---|---| | minimum-password-length | 6–128 ký tự | | require-* | hoa, thường, số, ký hiệu | | max-password-age | 1–1.095 ngày | | password-reuse-prevention | nhớ tới 24 mật khẩu cũ | | hard-expiry | khoá user khi hết hạn, cần admin gỡ |

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

• **B. Đặt password policy cho TỪNG IAM user — đây là phương án gần nhất vì nghe hợp lý về mặt cấu hình, nhưng nó không tồn tại: password policy là thuộc tính duy nhất ở cấp tài khoản.
• **A. Tạo IAM policy thực thi yêu cầu rồi gắn cho mọi user — IAM policy không diễn đạt được quy tắc về độ phức tạp mật khẩu: nó chỉ cho phép hoặc từ chối hành động trên tài nguyên.
• **D. Dùng AWS Config rule để thực thi khi tạo user — Config PHÁT HIỆN chứ không NGĂN CHẶN: nó báo tài khoản không tuân thủ sau khi sự việc đã xảy ra. (Config có rule iam-password-policy để kiểm tra chính sách đã đặt đúng chưa — hữu ích, nhưng không thay được việc đặt chính sách.)

Ghi nhớ

Ba đặc điểm của IAM password policy: | Đặc điểm | Chi tiết | |---|---| | Ở cấp TÀI KHOẢN | không có cấp user | | Chỉ áp cho IAM user | KHÔNG áp cho root | | Không áp cho IAM Identity Center | có chính sách riêng |

Dòng giữa quan trọng:

Mật khẩu root KHÔNG bị password policy ràng buộc
    → phải tự đặt mật khẩu mạnh và bật MFA
        ↓
    Root là tài khoản quyền lực nhất mà lại
      không chịu chính sách

Ba biện pháp bảo vệ tài khoản root: | Biện pháp | Chi tiết | |---|---| | Bật MFA phần cứng | | | Email là danh sách phân phối | không phụ thuộc cá nhân | | KHÔNG dùng root cho việc hằng ngày | |

Ba lớp kiểm soát danh tính — bảng phân biệt: | Lớp | Việc | |---|---| | Password policy | hình thức mật khẩu | | IAM policy | hành động được phép | | MFA | yếu tố xác thực thứ hai | | SCP | trần quyền cho cả tài khoản |

Ba cách bắt buộc MFA: | Cách | Chi tiết | |---|---| | IAM policy với aws:MultiFactorAuthPresent | | | SCP ở cấp tổ chức | | | IAM Identity Center bật MFA | |

Policy bắt buộc MFA:

{"Effect": "Deny", "NotAction": ["iam:CreateVirtualMFADevice",
   "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices",
   "sts:GetSessionToken"],
 "Resource": "*",
 "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}}

Cho phép user tự bật MFA rồi mới làm được việc khác.

Ba lý do AWS khuyến nghị BỎ IAM user cho con người: | Lý do | Chi tiết | |---|---| | Mật khẩu và access key dài hạn | dễ bị lộ | | Không có đăng nhập một lần | | | Khó quản lý ở nhiều tài khoản | |

Cách thay thế được khuyến nghị:

AWS IAM Identity Center:
    ✓ nguồn danh tính tập trung (AD, Okta, Entra ID)
    ✓ credential TẠM THỜI
    ✓ chính sách mật khẩu do IdP quản lý
        ↓
    Password policy của IAM trở nên không cần thiết

Ba công cụ rà soát danh tính: | Công cụ | Việc | |---|---| | Credential report | trạng thái mọi user: MFA, tuổi mật khẩu, access key | | IAM Access Advisor | dịch vụ nào không dùng tới | | Access Analyzer (unused access) | quyền và role không dùng |

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

Ba cột quan trọng trong credential report: | Cột | Ý nghĩa | |---|---| | mfa_active | user chưa bật MFA | | password_last_used | user không hoạt động | | access_key_1_last_rotated | khoá quá cũ |

Ba AWS Config rule liên quan: | Rule | Kiểm tra | |---|---| | iam-password-policy | chính sách đã đặt đúng chưa | | mfa-enabled-for-iam-console-access | | | access-keys-rotated | |

Ba lưu ý về hard-expiry: | Lưu ý | Chi tiết | |---|---| | Khoá user khi mật khẩu hết hạn | không tự đổi được | | Cần admin can thiệp | | | Cẩn thận: có thể khoá luôn admin | |

Ba khuyến nghị về độ dài mật khẩu: | Nguồn | Khuyến nghị | |---|---| | NIST hiện tại | ưu tiên ĐỘ DÀI hơn độ phức tạp | | Tối thiểu thực dụng | 14 ký tự | | Kết hợp MFA | quan trọng hơn cả |

Và một lời khuyên: hãy bật MFA cho mọi IAM user cùng lúc với việc đặt password policy. Một chính sách mật khẩu chặt chẽ vẫn không cứu được tài khoản khi mật khẩu bị lộ qua rò rỉ dữ liệu ở nơi khác — còn MFA thì có, và đó là biện pháp duy nhất thực sự thay đổi kết quả.

Đáp án

C — Khởi động EC2 ở nhiều Region đứng sau NLB, và dùng AWS Global Accelerator.

Vì sao đúng

Đề nêu ba yêu cầu, và Global Accelerator đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Chỉ cần cho phép 2 địa chỉ IP | Global Accelerator cho ĐÚNG 2 IP anycast tĩnh | | Định tuyến thông minh theo độ trễ thấp nhất | tự chọn Region gần nhất khoẻ mạnh | | Chuyển vùng Region NHANH | ~30 giây, không đụng DNS |

Con số "2 địa chỉ IP" chính là chữ ký của Global Accelerator:

Global Accelerator cấp ĐÚNG HAI IP anycast
    → đại diện cho MỌI endpoint ở MỌI Region
    → không đổi khi thêm bớt Region
        ↓
    Khách hàng chỉ cần cho phép hai địa chỉ đó

Và chuyển vùng nhanh vì IP không đổi:

Route 53 failover:
    → đổi bản ghi DNS
    → client phải chờ TTL hết hạn
    → nhiều trình phân giải bỏ qua TTL thấp
        ↓
    Thời gian thực tế: vài phút tới hàng chục phút

Global Accelerator:
    → IP anycast KHÔNG ĐỔI, chỉ đổi đích phía sau
        ↓
    Client không phải phân giải lại gì

Triển khai:

aws globalaccelerator create-accelerator --name ung-dung-toan-cau --enabled

aws globalaccelerator create-listener --accelerator-arn <arn>   --protocol TCP --port-ranges FromPort=443,ToPort=443

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region us-east-1   --endpoint-configurations EndpointId=<arn-nlb-1>,Weight=128   --health-check-interval-seconds 10 --threshold-count 3

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region eu-west-1   --endpoint-configurations EndpointId=<arn-nlb-2>,Weight=128

--health-check-interval-seconds 10 --threshold-count 3 cho phát hiện trong ~30 giây.

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

• **A. EC2 ở nhiều Region đứng sau NLB có IP tĩnh — đây là phương án gần nhất vì NLB thật sự có Elastic IP tĩnh, nhưng nó không hoạt động xuyên Region: một NLB chỉ phục vụ target trong Region của nó, nên bạn sẽ có nhiều IP (mỗi NLB một IP mỗi AZ, nhân với số Region) chứ không phải hai.
• **B. EC2 sau ALB và dùng CloudFront với một cặp IP tĩnh — CloudFront KHÔNG cho IP tĩnh: nó dùng tên miền và dải IP thay đổi liên tục.
• **D. EC2 sau ALB và dùng Route 53 failover routing — không cho IP tĩnh và chuyển vùng chậm: DNS phụ thuộc TTL, và ALB không có IP cố định.

Ghi nhớ

Địa chỉ IP của các dịch vụ — bảng phải thuộc: | Dịch vụ | Địa chỉ IP | |---|---| | Application Load Balancer | ĐỘNG — chỉ tên DNS | | Network Load Balancer | Elastic IP tĩnh (một mỗi AZ, mỗi Region) | | CloudFront | tên miền, dải IP thay đổi | | Global Accelerator | ĐÚNG 2 IP anycast tĩnh, TOÀN CẦU |

Từ khoá nhận diện:

"only 2 IP addresses to whitelist", "multi-Region", "fast failover" → Global Accelerator "static IP in one Region" → NLB với Elastic IP "cache content globally" → CloudFront

Global Accelerator và CloudFront — bảng phân biệt: | | Global Accelerator | CloudFront | |---|---|---| | Caching | ❌ | ✅ | | Giao thức | TCP và UDP, mọi cổng | HTTP/HTTPS | | Địa chỉ | 2 IP anycast tĩnh | tên miền | | Chuyển vùng Region | ~30 giây | theo origin |

Ba lợi ích của IP anycast tĩnh: | Lợi ích | Chi tiết | |---|---| | Đưa vào danh sách trắng tường lửa | ← câu này | | Chuyển vùng không phụ thuộc DNS | | | Thêm Region không đổi IP | |

Và bạn mang IP của mình vào được (BYOIP):

Công ty đã có dải IP công cộng riêng
    → đưa vào AWS và dùng cho Global Accelerator
        ↓
    Khách hàng không phải cập nhật danh sách trắng lần nào

Ba khái niệm của Global Accelerator: | Khái niệm | Việc | |---|---| | Accelerator | mang hai IP tĩnh | | Listener | cổng và giao thức | | Endpoint group | một Region, có traffic dial |

Ba yếu tố quyết định định tuyến: | Yếu tố | Chi tiết | |---|---| | Sức khoẻ endpoint | không gửi tới endpoint hỏng | | Traffic dial | tỷ lệ lưu lượng mỗi Region | | Vị trí client | Region gần nhất khoẻ mạnh |

Traffic dial cho triển khai dần và rút Region:

aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn> --traffic-dial-percentage 0

Đặt 0 để rút một Region ra ngay lập tức — hữu ích khi bảo trì.

Ba loại endpoint được hỗ trợ: | Endpoint | Hỗ trợ | |---|---| | ALB, NLB | ✅ | | EC2 instance | ✅ | | Elastic IP | ✅ | | S3 bucket | ❌ |

Hai loại accelerator: | Loại | Đặc điểm | |---|---| | Standard | định tuyến theo độ trễ và sức khoẻ | | Custom routing | ánh xạ cố định IP+cổng → instance |

Ba tham số health check: | Tham số | Mặc định | |---|---| | HealthCheckIntervalSeconds | 30 (đặt được 10) | | ThresholdCount | 3 | | — | thời gian phát hiện ≈ interval × threshold |

Ba lưu ý về kiến trúc đa Region: | Lưu ý | Chi tiết | |---|---| | Dữ liệu phải sao chép | Aurora Global, DynamoDB Global Tables | | AMI phải có ở mọi Region | | | Diễn tập chuyển vùng định kỳ | |

Dòng đầu là phần khó nhất:

Global Accelerator chuyển lưu lượng trong 30 giây
    → nhưng nếu database ở Region đó chưa sẵn sàng
    → ứng dụng vẫn lỗi
        ↓
    DR là bài toán của CẢ KIẾN TRÚC

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Phí cố định | ~0,025 USD/giờ (~18 USD/tháng) | | Phí truyền dữ liệu cao cấp | theo GB và khu vực | | — | không có phí request |

Ba biện pháp bảo mật đi kèm: | Biện pháp | Chi tiết | |---|---| | AWS Shield Standard tự động | chống DDoS tầng 3/4 | | WAF trên ALB phía sau | WAF KHÔNG gắn vào GA được | | Security group trên endpoint | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyEndpointCount | Region nào đang phục vụ | | NewFlowCount | kết nối mới | | ProcessedBytesIn/Out | lưu lượng |

Và một lời khuyên: hãy ghi hai địa chỉ IP tĩnh vào tài liệu vận hành và chia sẻ với khách hàng ngay từ đầu. Đó chính là giá trị lớn nhất của giải pháp — thay vì gửi cho họ một danh sách IP thay đổi liên tục kèm quy trình cập nhật, bạn gửi hai con số không bao giờ đổi.

Đáp án

A và D.

• A — Bật S3 VPC endpoint trong VPC để kết nối riêng tư giữa ứng dụng và bucket
• D — Cấu hình Cognito identity pool để cấp credential AWS tạm thời khi người dùng xác thực qua user pool

Vì sao đúng

Đề nêu hai nhóm yêu cầu, và hai đáp án giải quyết đúng từng nhóm: | Yêu cầu | Đáp án | |---|---| | Người dùng tải và lưu tài liệu an toàn | D — identity pool cấp credential tạm | | Ứng dụng ở PRIVATE subnet, kết nối riêng tư | A — S3 VPC endpoint |

D — điểm mấu chốt: user pool và identity pool khác nhau.

Cognito USER POOL:
    → XÁC THỰC người dùng (đăng nhập, đăng ký, MFA)
    → trả về JWT token
    → KHÔNG cấp quyền AWS nào

Cognito IDENTITY POOL:
    → đổi token đó lấy CREDENTIAL AWS TẠM THỜI
    → qua STS AssumeRoleWithWebIdentity
        ↓
    Chỉ identity pool mới cho phép gọi S3

Và phân quyền tới từng người dùng bằng biến chính sách:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::tai-lieu/${cognito-identity.amazonaws.com:sub}/*"}

Mỗi người dùng CHỈ truy cập thư mục của mình
    → một policy duy nhất phục vụ mọi người dùng

A — VPC endpoint giữ lưu lượng trong mạng AWS:

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

Ứng dụng ở private subnet gọi S3
    → không có endpoint: phải qua NAT Gateway → Internet
    → có gateway endpoint: đi trong mạng AWS
        ↓
    ✓ giữ kiến trúc riêng tư
    ✓ tiết kiệm phí NAT
    ✓ gateway endpoint MIỄN PHÍ

Luồng hoàn chỉnh:

Người dùng đăng nhập → Cognito User Pool → JWT
    ↓
JWT → Cognito Identity Pool → credential AWS tạm (1 giờ)
    ↓
Client gọi S3 trực tiếp bằng credential đó
    ↓
Ứng dụng backend gọi S3 qua VPC endpoint (riêng tư)

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

• **B. Cấu hình ứng dụng sinh "S3 access token" trực tiếp từ user pool — đây là phương án gần nhất và là hiểu lầm phổ biến nhất về Cognito: user pool chỉ xác thực, nó không sinh được credential AWS. Phải qua identity pool.
• **C. Gán IAM role trực tiếp vào S3 bucket — không phải cơ chế có thật: bucket dùng bucket policy (resource-based policy), không "gắn role".
• **E. Bucket policy từ chối request không có credential Cognito hợp lệ — không diễn đạt được bằng bucket policy: không có điều kiện IAM nào kiểm tra "credential có phải từ Cognito không" theo cách này. (Có thể kiểm tra ARN của role được assume, nhưng đó là cách khác và phương án không nêu.)

Ghi nhớ

Cognito User Pool và Identity Pool — bảng phải thuộc: | | User Pool | Identity Pool | |---|---|---| | Việc | XÁC THỰC — ai là ai | UỶ QUYỀN — được làm gì trên AWS | | Trả về | JWT token | credential AWS TẠM THỜI | | Gọi được S3, DynamoDB trực tiếp | ❌ | ✅ |

Quy tắc: cần gọi dịch vụ AWS từ client → BẮT BUỘC có identity pool.

Ba nguồn danh tính của identity pool: | Nguồn | Chi tiết | |---|---| | Cognito user pool | ← câu này | | Nhà cung cấp xã hội | Google, Facebook, Apple | | SAML hoặc OIDC | IdP doanh nghiệp | | Guest (unauthenticated) | quyền hạn chế |

Ba biến chính sách hữu ích: | Biến | Nghĩa | |---|---| | ${cognito-identity.amazonaws.com:sub} | định danh duy nhất của người dùng | | ${aws:userid} | định danh principal | | ${aws:PrincipalTag/...} | tag (ABAC) |

Ba cách phân quyền trong identity pool: | Cách | Chi tiết | |---|---| | Default role | authenticated và unauthenticated | | Rule-based role mapping | chọn role theo claim | | Token-based role mapping | claim cognito:roles |

Hai loại VPC endpoint — nhắc lại: | | Gateway | Interface | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ | | Chi phí | MIỄN PHÍ | ~0,01 USD/giờ mỗi AZ | | Từ on-premises | ❌ | ✅ |

Ba cách tăng cường bảo mật bucket: | Cách | Chi tiết | |---|---| | aws:SourceVpce trong bucket policy | ép đi qua endpoint | | Block Public Access ở cấp tài khoản | | | Mã hoá SSE-KMS | với Bucket Keys |

Ba mẫu tải tệp lên S3 từ client: | Mẫu | Đặc điểm | |---|---| | Credential tạm từ identity pool | client gọi trực tiếp ← câu này | | Presigned URL từ backend | backend kiểm soát hoàn toàn | | Qua API Gateway và Lambda | giới hạn kích thước |

Presigned URL có thêm khả năng giới hạn kích thước:

url = s3.generate_presigned_post(
    Bucket='tai-lieu', Key=f'{ma_nguoi_dung}/{ten_tep}',
    Conditions=[['content-length-range', 0, 10485760]],
    ExpiresIn=3600)

Ba lưu ý về credential tạm: | Lưu ý | Chi tiết | |---|---| | Mặc định hết hạn sau 1 giờ | | | SDK tự làm mới | | | Quyền theo IAM role của identity pool | |

Ba lưu ý về CORS: | Lưu ý | Chi tiết | |---|---| | Bucket phải có CORS configuration | cho tải lên từ trình duyệt | | Khai đúng origin, method, header | | | Thiếu CORS: lỗi im lặng trong trình duyệt | |

Ba biện pháp bảo mật bổ sung: | Biện pháp | Chi tiết | |---|---| | Bật MFA trong user pool | | | Giới hạn loại và kích thước tệp | | | GuardDuty Malware Protection for S3 | quét tệp tải lên |

Ba lưu ý về kiến trúc private subnet: | Lưu ý | Chi tiết | |---|---| | Gateway endpoint cho S3 và DynamoDB | miễn phí | | Interface endpoint cho dịch vụ khác | SSM, KMS | | Đánh giá xem còn cần NAT Gateway không | |

Và một lời khuyên: hãy dùng biến ${cognito-identity.amazonaws.com:sub} trong phần Resource của policy. Đó là cách duy nhất để một chính sách duy nhất phục vụ hàng nghìn người dùng mà mỗi người chỉ thấy tài liệu của mình — và nó không cần bất kỳ mã kiểm tra quyền nào ở tầng ứng dụng.