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

Đáp án

C và E.

• C — Chuyển dữ liệu sang S3 Standard-IA sau 30 ngày
• E — Phân tích dữ liệu nguội bằng Amazon Athena

Vì sao đúng

Đề nêu ba yêu cầu, và cặp S3 + Athena đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Giữ khả năng truy vấn SQL | Athena chạy SQL trực tiếp trên S3 | | Truy vấn bắt đầu NGAY | Standard-IA truy xuất TỨC THÌ | | Tiết kiệm chi phí Redshift tối đa | đưa dữ liệu nguội RA KHỎI cụm |

Vế thứ ba là mấu chốt:

Redshift tính phí theo node-giờ
    → node phải đủ lớn để chứa toàn bộ dữ liệu
    → dữ liệu nguội chiếm chỗ mà hầu như không được truy vấn
        ↓
    Đưa dữ liệu nguội sang S3
    → giảm được cỡ cụm Redshift
    → tiết kiệm lớn nhất

Và Standard-IA đúng cho mẫu truy cập này:

"rarely queried after 30 days" nhưng "queries started IMMEDIATELY"
        ↓
    Standard-IA: rẻ hơn Standard ~46%, truy xuất TỨC THÌ
    Glacier:     rẻ hơn nữa nhưng mất phút tới giờ → KHÔNG đạt

Lifecycle chuyển dữ liệu:

{"Rules": [{
  "ID": "chuyen-du-lieu-nguoi",
  "Status": "Enabled",
  "Filter": {"Prefix": "kho-du-lieu/"},
  "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}]}]}

Và Athena truy vấn được ngay:

CREATE EXTERNAL TABLE giao_dich_nguoi (
  ma_giao_dich string, ngay date, so_tien decimal(18,2))
PARTITIONED BY (nam int, thang int)
STORED AS PARQUET
LOCATION 's3://kho-du-lieu/giao-dich/';

Và mẫu kiến trúc này có tên riêng — "hot/cold data tiering":

Redshift (nóng):  30 ngày gần nhất, truy vấn nhanh nhất
S3 + Athena (nguội): dữ liệu cũ, truy vấn khi cần
        ↓
    Redshift Spectrum còn cho phép JOIN cả hai trong MỘT truy vấn

Redshift Spectrum đáng biết:

SELECT h.ma_kh, SUM(h.so_tien) + SUM(n.so_tien)
FROM giao_dich_nong h
JOIN spectrum_schema.giao_dich_nguoi n ON h.ma_kh = n.ma_kh
GROUP BY h.ma_kh;

Truy vấn dữ liệu nóng trong Redshift và dữ liệu nguội trên S3 cùng lúc.

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

• **D. Tạo cụm Redshift NHỎ HƠN cho dữ liệu nguội — đây là phương án gần nhất và có giảm chi phí, nhưng nó vẫn phải trả tiền cho một cụm chạy 24/7: với dữ liệu hiếm truy vấn, S3 + Athena rẻ hơn nhiều vì chỉ trả khi thật sự chạy truy vấn.
• **A. Chuyển dữ liệu sang Glacier Deep Archive sau 30 ngày — vi phạm yêu cầu truy vấn ngay: Deep Archive mất 12–48 giờ để lấy dữ liệu. Đề nói rõ "get the queries started immediately".
• **B. Di chuyển lưu trữ nền của Redshift sang S3 IA — không phải thao tác có thật: bạn không cấu hình được lớp lưu trữ nội bộ của Redshift. (RA3 node có managed storage tự phân tầng, nhưng đó là cơ chế của AWS, không phải thứ bạn chỉnh.)

Ghi nhớ

Ba công cụ truy vấn SQL trên AWS — bảng phải thuộc: | Công cụ | Đặc điểm | |---|---| | Amazon Redshift | kho dữ liệu, cụm chạy liên tục, nhanh nhất | | Redshift Spectrum | truy vấn S3 TỪ cụm Redshift | | Amazon Athena | serverless, trả theo dữ liệu quét |

Từ khoá nhận diện:

"cold data", "rarely queried", "save cost", "keep SQL" → S3 + Athena "join hot and cold data in one query" → Redshift Spectrum "high-performance data warehouse" → Redshift

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

Với yêu cầu "immediately", ba dòng đầu dùng được.

Glacier Instant Retrieval đáng cân nhắc:

Rẻ hơn Standard-IA (~0,004 vs ~0,0125 USD/GB)
    → mà vẫn truy xuất MILI GIÂY
        ↓
    Nhưng phí truy xuất cao hơn, và tối thiểu 90 ngày
    → đáng dùng nếu THẬT SỰ hiếm truy vấn

Ba cách giảm chi phí Athena — rất đáng nhớ: | Cách | Tiết kiệm | |---|---| | Định dạng cột (Parquet, ORC) | tới 90% | | Phân vùng theo cột hay lọc | rất nhiều | | Nén (Snappy, GZIP) | |

So sánh cụ thể:

Quét 1 TB CSV:                   ~5,00 USD
Cùng dữ liệu ở Parquet nén:      ~0,50 USD hoặc thấp hơn

Ba loại node của Redshift: | Loại | Đặc điểm | |---|---| | RA3 | tính toán và lưu trữ TÁCH RỜI, managed storage | | DC2 | lưu trữ SSD gắn liền | | DS2 | thế hệ cũ |

RA3 giải quyết một phần vấn đề trong đề:

RA3 với Redshift Managed Storage:
    → dữ liệu ít dùng tự chuyển xuống S3 phía sau
    → co giãn tính toán độc lập với dung lượng
        ↓
    Nhưng vẫn trả tiền cụm 24/7
    → S3 + Athena vẫn rẻ hơn cho dữ liệu rất hiếm truy vấn

Ba cách tối ưu chi phí Redshift: | Cách | Tiết kiệm | |---|---| | Đưa dữ liệu nguội sang S3 | ← câu này | | Reserved node | tới 75% | | Tạm dừng cụm khi không dùng | dev và test |

Redshift Serverless đáng cân nhắc:

aws redshift-serverless create-workgroup   --workgroup-name wg-phan-tich --namespace-name ns-phan-tich   --base-capacity 32

Trả theo RPU-giờ khi thật sự chạy truy vấn
    → tự tạm dừng khi nhàn rỗi
        ↓
    Phù hợp với tải phân tích không đều

Ba khái niệm đi kèm Athena: | Khái niệm | Việc | |---|---| | Glue Data Catalog | lưu định nghĩa bảng | | Glue Crawler | tự phát hiện schema | | Workgroup | giới hạn chi phí, tách người dùng |

Workgroup bảo vệ khỏi truy vấn tốn kém:

aws athena create-work-group --name phan-tich-nguoi   --configuration '{"BytesScannedCutoffPerQuery": 107374182400}'

Giới hạn 100 GB mỗi truy vấn — vượt thì huỷ.

Ba lưu ý về xuất dữ liệu từ Redshift sang S3: | Lưu ý | Chi tiết | |---|---| | UNLOAD với định dạng Parquet | | | Phân vùng khi xuất | | | Xoá khỏi Redshift sau khi xác nhận | |

UNLOAD ('SELECT * FROM giao_dich WHERE ngay < current_date - 30')
TO 's3://kho-du-lieu/giao-dich/'
IAM_ROLE 'arn:aws:iam::123456789012:role/redshift-s3'
FORMAT AS PARQUET
PARTITION BY (nam, thang);

Ba lưu ý về ràng buộc lifecycle: | Ràng buộc | Chi tiết | |---|---| | Standard-IA tối thiểu 30 ngày | | | Object dưới 128 KB không tự chuyển | | | Có phí truy xuất ~0,01 USD/GB | |

Và một lời khuyên: hãy chuyển dữ liệu sang Parquet có phân vùng trước khi đưa lên S3. Nếu xuất ra CSV, mỗi truy vấn Athena sẽ quét toàn bộ tệp và chi phí có thể vượt cả khoản tiết kiệm được từ việc thu nhỏ cụm Redshift — định dạng cột và phân vùng là thứ biến ý tưởng này từ đúng về lý thuyết thành đúng về hoá đơn.

Đáp án

C — Dùng delay queue để hoãn việc giao thông điệp mới trong vài giây.

Vì sao đúng

Đề nêu chính xác định nghĩa của delay queue:

"POSTPONE THE DELIVERY of NEW MESSAGES to the queue for a few seconds"
        ↓
    Delay queue:
        → thông điệp mới bị GIẤU trong khoảng delay
        → consumer không thấy nó cho tới khi hết thời gian

Cấu hình cho cả hàng đợi:

aws sqs set-queue-attributes --queue-url <url>   --attributes '{"DelaySeconds":"30"}'

Hoặc cho từng thông điệp:

aws sqs send-message --queue-url <url>   --message-body "noi dung" --delay-seconds 45

⚠ Lưu ý quan trọng với FIFO queue:

Standard queue: đặt delay cho TỪNG thông điệp được
FIFO queue:     CHỈ đặt được ở cấp HÀNG ĐỢI
        ↓
    `--delay-seconds` trên FIFO queue bị BỎ QUA

Và điểm phân biệt cốt lõi với visibility timeout:

Delay queue:
    → áp cho thông điệp MỚI, TRƯỚC KHI ai nhận
    → "chưa được giao lần nào"

Visibility timeout:
    → áp SAU KHI consumer đã nhận thông điệp
    → giấu nó trong lúc đang xử lý
        ↓
    Hai thời điểm khác nhau trong vòng đời thông điệp

Vòng đời một thông điệp:

send-message
    ↓ (DelaySeconds — delay queue giấu ở đây)
Visible — consumer nhận được
    ↓ receive-message
Not visible (VisibilityTimeout — giấu trong lúc xử lý)
    ↓ delete-message → biến mất
    ↓ hoặc hết timeout → quay lại Visible

Ba trường hợp dùng delay queue: | Trường hợp | Chi tiết | |---|---| | Cho hệ thống xuôi dòng kịp chuẩn bị | ← đúng đề bài | | Chờ giao dịch database commit xong | tránh đọc dữ liệu chưa có | | Giãn tải khi có đợt gửi lớn | |

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

• **D. Dùng visibility timeout để hoãn giao thông điệp mới — đây là phương án gần nhất và cũng là cơ chế giấu thông điệp, nhưng nó hoạt động ở giai đoạn KHÁC: visibility timeout chỉ có tác dụng sau khi consumer đã nhận thông điệp, không áp cho thông điệp mới chưa ai chạm tới.
• **A. Dùng FIFO queue để hoãn giao — FIFO giải quyết vấn đề THỨ TỰ, không phải độ trễ: nó đảm bảo thứ tự và xử lý đúng một lần. (FIFO queue cũng đặt được delay ở cấp hàng đợi, nhưng bản thân việc dùng FIFO không phải cơ chế hoãn.)
• **B. Dùng dead-letter queue — sai mục đích hoàn toàn: DLQ nhận thông điệp đã thất bại nhiều lần, để điều tra sau.

Ghi nhớ

Bốn cơ chế thời gian của SQS — bảng phải thuộc: | Cơ chế | Áp khi nào | Khoảng cho phép | |---|---|---| | Delay queue (DelaySeconds) | TRƯỚC khi giao lần đầu | 0–900 giây (15 phút) | | Visibility timeout | SAU khi consumer nhận | 0–43.200 giây (12 giờ) | | Message retention | tổng thời gian giữ | 60 giây – 14 ngày | | Receive wait time | long polling | 0–20 giây |

Bảng này bị hỏi rất nhiều — nên thuộc từng con số.

Ba cách đặt độ trễ: | Cách | Phạm vi | |---|---| | DelaySeconds của hàng đợi | mọi thông điệp | | --delay-seconds khi gửi | một thông điệp (chỉ Standard queue) | | — | thông điệp ghi đè cấu hình hàng đợi |

Ba lưu ý về visibility timeout: | Lưu ý | Chi tiết | |---|---| | Phải ≥ thời gian xử lý dài nhất | tránh xử lý trùng | | Gia hạn được bằng ChangeMessageVisibility | cho việc chạy lâu | | Với Lambda, khuyến nghị gấp 6 lần timeout của hàm | |

Gia hạn định kỳ cho việc chạy lâu:

while dang_xu_ly:
    sqs.change_message_visibility(
        QueueUrl=url, ReceiptHandle=rh, VisibilityTimeout=300)
    time.sleep(240)

Hai loại hàng đợi SQS — bảng nhắc lại: | | Standard | FIFO | |---|---|---| | Thứ tự | không đảm bảo | đảm bảo trong message group | | Trùng lặp | có thể | xử lý đúng một lần | | Thông lượng | gần như vô hạn | 300 hoặc 3.000 msg/giây | | — | | high throughput mode: ~70.000/giây | | Delay theo từng thông điệp | ✅ | ❌ chỉ cấp hàng đợi |

Ba khái niệm riêng của FIFO: | Khái niệm | Việc | |---|---| | MessageGroupId | thứ tự đảm bảo TRONG group | | MessageDeduplicationId | khử trùng lặp trong 5 phút | | Content-based deduplication | tự tính từ nội dung |

Ba cơ chế xử lý lỗi: | Cơ chế | Chi tiết | |---|---| | Dead-letter queue | thông điệp thất bại maxReceiveCount lần | | Redrive | đưa từ DLQ về hàng đợi chính | | Alarm cho DLQ | bắt buộc — DLQ không ai xem là vô dụng |

aws sqs set-queue-attributes --queue-url <url-chinh>   --attributes '{"RedrivePolicy":
    "{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"3\"}"}'

Ba lưu ý về long polling: | Lưu ý | Chi tiết | |---|---| | Đặt ReceiveMessageWaitTimeSeconds = 20 | khuyến nghị | | Giảm số lời gọi API rỗng | tiết kiệm chi phí | | Không tăng độ trễ | trả về ngay khi có thông điệp |

Ba giới hạn của SQS: | Giới hạn | Giá trị | |---|---| | Kích thước thông điệp | 256 KB | | Thông điệp lớn hơn | dùng Extended Client Library với S3 | | Số thông điệp trong hàng đợi | không giới hạn |

Extended Client Library cho payload lớn:

Thông điệp > 256 KB
    → lưu nội dung vào S3
    → gửi con trỏ qua SQS
        ↓
    Thư viện lo cả hai chiều

Ba mẫu kiến trúc với SQS: | Mẫu | Chi tiết | |---|---| | Tách rời producer và consumer | | | Đệm đỉnh tải | | | Fan-out với SNS + nhiều SQS | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng | | ApproximateAgeOfOldestMessage | chỉ báo trải nghiệm tốt nhất | | Số thông điệp trong DLQ | có lỗi |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Standard queue | ~0,40 USD mỗi triệu request | | FIFO queue | ~0,50 USD mỗi triệu | | — | long polling giảm số request đáng kể |

Và một lời khuyên: hãy nhớ mốc 15 phút của delay queue. Nếu cần hoãn lâu hơn — ví dụ gửi email nhắc sau 3 ngày — thì SQS không phải công cụ đúng; hãy dùng Step Functions với Wait state hoặc EventBridge Scheduler, cả hai đều hoãn được tới hàng năm.

Đáp án

B và E.

• B — Dùng Amazon Aurora Replica
• E — Dùng CloudFront đặt trước Application Load Balancer

Vì sao đúng

Đề yêu cầu chịu được đỉnh tải ĐỌC định kỳ, và hai đáp án giảm tải ở hai tầng khác nhau: | Đáp án | Giảm tải ở đâu | |---|---| | B — Aurora Replica | tầng DATABASE | | E — CloudFront | tầng ỨNG DỤNG và mạng |

B — Aurora replica chia tải đọc:

Aurora cluster:
    → tới 15 replica
    → độ trễ sao chép thường dưới 100 mili giây
    → reader endpoint tự cân bằng tải
        ↓
    Writer chỉ còn xử lý GHI
    → có đủ tài nguyên khi đỉnh đọc ập tới

aws rds create-db-instance --db-instance-identifier reader-1   --db-cluster-identifier cum-mang-xa-hoi --engine aurora-mysql   --db-instance-class db.r6g.xlarge --promotion-tier 1

Và ứng dụng phải dùng đúng endpoint:

Ghi:  cum-abc.cluster-xyz.ap-northeast-1.rds.amazonaws.com
Đọc:  cum-abc.cluster-ro-xyz.ap-northeast-1.rds.amazonaws.com
        ↓
    Dùng cluster endpoint cho cả hai = mọi tải dồn vào writer

E — CloudFront giảm tải trước cả khi request tới EC2:

Ứng dụng mạng xã hội có rất nhiều nội dung đọc lặp lại:
    → ảnh đại diện, ảnh bài đăng, JS, CSS
    → trang hồ sơ được nhiều người xem
        ↓
    CloudFront đệm ở edge
    → request không tới ALB, không tới EC2, không tới database

Và CloudFront giúp cả với nội dung động:

Nội dung động không đệm được lâu
    → nhưng vẫn hưởng mạng riêng của AWS
    → và kết thúc TLS ở biên
        ↓
    Giảm độ trễ đáng kể cho người dùng xa

Hai đáp án bổ sung nhau theo tầng:

CloudFront:      chặn phần lớn request ở BIÊN
    ↓ phần còn lại
ALB + EC2:       xử lý logic
    ↓ truy vấn
Aurora replica:  chia tải đọc
        ↓
    Mỗi tầng giảm tải cho tầng sau

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

• **C. Dùng AWS Global Accelerator — đây là phương án gần nhất vì cũng cải thiện hiệu năng mạng, nhưng nó không giảm tải đọc: Global Accelerator định tuyến lưu lượng qua mạng riêng của AWS và cho IP tĩnh, nhưng không đệm gì. Mọi request vẫn tới EC2 và database.
• **A. Dùng AWS Shield — giải quyết vấn đề khác: Shield chống tấn công DDoS. Đỉnh tải trong đề là lưu lượng hợp lệ, không phải tấn công.
• **D. Dùng AWS Direct Connect — hoàn toàn không liên quan: Direct Connect nối on-premises với AWS. Ứng dụng ở đây đã hoàn toàn trên AWS và phục vụ người dùng Internet.

Ghi nhớ

Ba tầng giảm tải đọc — bảng phải thuộc: | Tầng | Cơ chế | |---|---| | Biên (edge) | CloudFront — đệm nội dung | | Ứng dụng | ElastiCache — đệm kết quả truy vấn | | Database | read replica — chia tải đọc |

Càng chặn được request ở tầng sớm, càng tiết kiệm.

Ba cách giảm tải database — 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 (CloudFront, ElastiCache) | LOẠI BỎ truy vấn | | ③ | Read replica | chia nhỏ cùng lượng tải |

Khác biệt giữa ② và ③:

Read replica: chia cùng lượng truy vấn cho nhiều máy
Đệm:          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 đặc điểm của Aurora replica: | Đặc điểm | Chi tiết | |---|---| | Tới 15 replica | RDS MySQL chỉ 5 | | Độ trễ sao chép dưới 100 mili giây | đọc từ CÙNG bộ lưu trữ | | Vừa phục vụ đọc VỪA là mục tiêu chuyển đổi | |

Dòng cuối là ưu thế của Aurora so với RDS Multi-AZ:

RDS Multi-AZ standby:   KHÔNG phục vụ đọc
Aurora replica:         phục vụ đọc VÀ làm standby
        ↓
    Một tài nguyên, hai công dụng

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

Custom endpoint hữu ích:

Tách truy vấn báo cáo nặng khỏi truy vấn ứng dụng
    → custom endpoint trỏ tới replica riêng cho báo cáo

Ba tính năng của CloudFront giúp giảm tải: | Tính năng | Chi tiết | |---|---| | Đệm ở edge | | | Origin Shield | thêm một lớp đệm trước origin | | Nén tự động | giảm băng thông |

Origin Shield đáng biết:

Nhiều edge location cùng trượt cache
    → tất cả gọi origin cùng lúc
    → origin bị dồn tải

Origin Shield: một lớp đệm trung gian
    → gộp các request đó thành MỘT
        ↓
    Giảm tải origin đáng kể khi lưu lượng toàn cầu

Ba cách tăng tỷ lệ trúng cache: | Cách | Chi tiết | |---|---| | Chỉ đưa header và query cần thiết vào cache key | | | Đặt Cache-Control hợp lý từ origin | | | Dùng cache policy dựng sẵn | CachingOptimized |

Ba lưu ý về Aurora Auto Scaling cho replica: | Lưu ý | Chi tiết | |---|---| | Tự thêm replica theo CPU hoặc số kết nối | | | Đặt min và max hợp lý | | | Replica mới mất vài phút để sẵn sàng | |

aws application-autoscaling register-scalable-target   --service-namespace rds --scalable-dimension rds:cluster:ReadReplicaCount   --resource-id cluster:cum-mang-xa-hoi --min-capacity 2 --max-capacity 10

Ba lưu ý về độ trễ sao chép: | Lưu ý | Chi tiết | |---|---| | Đọc-sau-ghi có thể chưa thấy dữ liệu | dùng writer khi cần nhất quán | | Theo dõi AuroraReplicaLag | | | Với mạng xã hội, độ trễ nhỏ thường chấp nhận được | |

Ba lựa chọn đệm ở tầng ứng dụng: | Lựa chọn | Đặc điểm | |---|---| | ElastiCache Redis | linh hoạt nhất | | Aurora Serverless v2 | tự co giãn năng lực | | RDS Proxy | gộp kết nối |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CPUUtilization của writer | | | AuroraReplicaLag | replica tụt lại | | CacheHitRate của CloudFront | hiệu quả đệm |

Và một lời khuyên: hãy kiểm tra ứng dụng có thật sự dùng reader endpoint hay không trước khi thêm replica. Rất nhiều hệ thống thêm replica rồi không thấy cải thiện gì, đơn giản vì chuỗi kết nối vẫn trỏ tới cluster endpoint — và toàn bộ tải đọc vẫn dồn vào writer như cũ.

Đáp án

A — Amazon ElastiCache for Memcached.

Vì sao đúng

Đề nêu một yêu cầu kỹ thuật rất cụ thể: dịch vụ đệm hỗ trợ ĐA LUỒNG (multi-threading).

Memcached:
    ✓ ĐA LUỒNG từ thiết kế gốc
    ✓ tận dụng được mọi core của node
        ↓
Redis:
    → xử lý lệnh chủ yếu ĐƠN LUỒNG
    → có I/O threading từ v6, nhưng phần thực thi lệnh vẫn một luồng

Đây là điểm phân biệt kinh điển giữa hai engine.

Và bài toán trong đề phù hợp với Memcached:

"queries that perform JOINS on multiple tables — slow and expensive"
        ↓
    Cần đệm KẾT QUẢ của truy vấn
    → key = chữ ký truy vấn, value = kết quả đã serialize
        ↓
    Cấu trúc key-value đơn giản là đủ
    → không cần sorted set, GEO, hay pub/sub của Redis

Mẫu cache-aside:

import hashlib, json
from pymemcache.client.hash import HashClient

mc = HashClient([('cum-dem.abc.cfg.apne1.cache.amazonaws.com', 11211)])

def truy_van_co_dem(sql, tham_so):
    khoa = hashlib.md5(f'{sql}:{tham_so}'.encode()).hexdigest()
    kq = mc.get(khoa)
    if kq is None:
        kq = json.dumps(db.execute(sql, tham_so))
        mc.set(khoa, kq, expire=300)
    return json.loads(kq)

Và Memcached mở rộng theo chiều ngang rất tự nhiên:

Thêm node vào cụm
    → client tự phân bố key bằng consistent hashing
        ↓
    Dung lượng và thông lượng tăng tuyến tính

Ba lợi ích của đệm kết quả truy vấn JOIN: | Lợi ích | Chi tiết | |---|---| | Bỏ hẳn chi phí tính toán JOIN | tốn nhất trong truy vấn | | Giảm tải CPU của database | | | Độ trễ từ giây xuống micro giây | |

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

• **C. ElastiCache for Redis — đây là phương án gần nhất và hoàn toàn đệm được kết quả truy vấn, nhưng nó không thoả yêu cầu đa luồng: Redis xử lý lệnh đơn luồng. Đề nêu rõ "needs to use a caching service that supports MULTI-THREADING", và đó là dấu hiệu chỉ thẳng tới Memcached.
• **D. DynamoDB Accelerator (DAX) — chỉ dùng được với DynamoDB: DAX là bộ đệm chuyên biệt, không đặt trước database quan hệ được.
• **B. AWS Global Accelerator — không phải bộ đệm: đây là dịch vụ định tuyến mạng toàn cầu, không lưu trữ dữ liệu.

Ghi nhớ

Redis và Memcached — bảng phải thuộc: | | Redis / Valkey | Memcached | |---|---|---| | Đa luồng | ❌ (lệnh đơn luồng) | ✅ | | Cấu trúc dữ liệu | phong phú | chỉ key-value | | Sao chép và Multi-AZ | ✅ | ❌ | | Bền vững (snapshot) | ✅ | ❌ | | Pub/Sub, transaction, Lua | ✅ | ❌ | | Mở rộng ngang đơn giản | cluster mode | ✅ thêm node |

Từ khoá nhận diện — rất hay được hỏi:

"multi-threaded", "simple key-value", "scale horizontally" → Memcached "geospatial", "leaderboard", "pub/sub", "high availability", "persistence" → Redis "cache for DynamoDB" → DAX

Ba trường hợp chọn Memcached: | Trường hợp | Lý do | |---|---| | Đệm đơn giản, key-value | ← câu này | | Cần tận dụng nhiều core | đa luồng | | Mở rộng và thu hẹp node thường xuyên | |

Ba trường hợp chọn Redis: | Trường hợp | Lý do | |---|---| | Cần sẵn sàng cao | Memcached KHÔNG có sao chép | | Cần cấu trúc dữ liệu phức tạp | | | Cần bền vững dữ liệu | |

Hạn chế lớn nhất của Memcached:

KHÔNG có sao chép, KHÔNG có chuyển đổi tự động
    → node hỏng = MẤT phần dữ liệu trên node đó
        ↓
    Với bộ đệm thì chấp nhận được (nạp lại từ database)
    → nhưng KHÔNG dùng được làm kho dữ liệu chính

Ba mẫu đệm: | Mẫu | Cơ chế | |---|---| | Lazy loading (cache-aside) | đọc trượt thì nạp từ database ← phổ biến nhất | | Write-through | ghi cả hai nơi cùng lúc | | TTL | tự hết hạn |

Ba đánh đổi của lazy loading: | Ưu | Nhược | |---|---| | Chỉ đệm dữ liệu THỰC SỰ được dùng | lần đọc đầu luôn trượt | | Node hỏng không gây lỗi | dữ liệu có thể cũ trong khoảng TTL | | Đơn giản | |

Ba nguyên tắc thiết kế khoá cache cho truy vấn: | Nguyên tắc | Chi tiết | |---|---| | Băm câu SQL cùng tham số | khoá ổn định | | TTL phù hợp với độ tươi cần thiết | | | Xoá khoá liên quan khi dữ liệu đổi | hoặc dựa vào TTL |

Ba lưu ý về vô hiệu hoá cache: | Cách | Chi tiết | |---|---| | TTL ngắ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 khoá | v2:truy-van:abc |

Cách thứ ba rất hữu ích:

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

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 đủ | | CPUUtilization | với Memcached, phản ánh đúng vì đa luồng |

Với Memcached, CPUUtilization là metric đúng — khác Redis phải dùng EngineCPUUtilization.

Ba cách mở rộng Memcached: | Cách | Chi tiết | |---|---| | Thêm node | client tự phân bố key | | Node lớn hơn | thêm bộ nhớ và core | | Auto Discovery | client tự phát hiện node mới |

Auto Discovery là tính năng riêng của ElastiCache:

Client kết nối tới CONFIGURATION endpoint
    → tự nhận danh sách node hiện tại
        ↓
    Thêm bớt node không phải sửa cấu hình client

Ba lưu ý về consistent hashing: | Lưu ý | Chi tiết | |---|---| | Thêm node làm một phần khoá bị phân bố lại | tỷ lệ trúng giảm tạm thời | | Consistent hashing giảm thiểu việc này | | | Dùng thư viện client hỗ trợ sẵn | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo node-giờ | | | Reserved node giảm tới 55% | | | Rẻ hơn nhiều so với nâng cỡ database | |

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 truy vấn JOIN phức tạp, nếu mỗi lần gọi có tham số khác nhau thì tỷ lệ trúng sẽ rất thấp — và khi đó việc tối ưu index hoặc dựng bảng tổng hợp sẵn mang lại nhiều hơn bất kỳ bộ đệm nào.

Đáp án

C — AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD).

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ Managed Microsoft AD đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Chạy tải AD-aware trên AWS | AD THẬT do Microsoft cung cấp, chạy trong AWS | | Thiết lập quan hệ TIN CẬY với AD tại chỗ | CHỈ Managed Microsoft AD làm được |

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

Quan hệ tin cậy (trust relationship) là tính năng của Active Directory THẬT
    → cần một domain controller thật ở phía AWS
        ↓
    AD Connector: chỉ là PROXY, không có domain nào → KHÔNG tin cậy được
    Simple AD:    dựa trên Samba, KHÔNG tương thích trust với AD thật
    Managed Microsoft AD: là AD thật → tin cậy được ✓

Triển khai:

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

aws ds create-trust --directory-id d-abc123   --remote-domain-name taicho.vidu.com   --trust-password '<mat-khau-tin-cay>'   --trust-direction Two-Way --trust-type Forest   --conditional-forwarder-ip-addrs 192.168.1.10 192.168.1.11

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

Ba lợi ích của quan hệ tin cậy: | Lợi ích | Chi tiết | |---|---| | Người dùng dùng tài khoản CÔNG TY sẵn có | không nhân bản danh tính | | Không phải đồng bộ mật khẩu | | | Tải trên AWS vẫn hoạt động khi mất kết nối tại chỗ | có bản sao trong AWS |

Dòng cuối là ưu thế lớn so với AD Connector:

AD Connector: mọi lần đăng nhập phải chuyển tiếp về tại chỗ
    → mất kết nối = KHÔNG ai đăng nhập được

Managed Microsoft AD: có domain controller chạy TRONG AWS
    → vẫn xác thực được người dùng của chính nó

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

• **A. AD Connector — đây là phương án gần nhất và thật sự kết nối được với AD tại chỗ, nhưng nó KHÔNG thiết lập được quan hệ tin cậy: nó chỉ là proxy chuyển tiếp yêu cầu xác thực về AD tại chỗ, không có domain nào ở phía AWS để tin cậy.
• **D. Simple AD — không tương thích trust với AD thật: Simple AD dựa trên Samba 4, hỗ trợ một tập con tính năng và không thiết lập được quan hệ tin cậy với Microsoft AD.
• **B. AWS Transit Gateway — hoàn toàn không phải dịch vụ thư mục: đây là bộ định tuyến nối nhiều VPC và mạng on-premises.

Ghi nhớ

Ba dịch vụ thư mục của AWS — bảng phải thuộc: | Dịch vụ | Là gì | Trust với AD tại chỗ | |---|---|---| | AWS Managed Microsoft AD | AD THẬT chạy trong AWS | ✅ | | AD Connector | PROXY, không lưu gì | ❌ | | Simple AD | tương thích Samba | ❌ |

Từ khoá nhận diện:

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

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

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

Hai loại trust: | Loại | Chi tiết | |---|---| | Forest trust | giữa hai forest — phổ biến nhất | | External trust | giữa hai domain cụ thể |

Ba yêu cầu để trust hoạt động: | Yêu cầu | Chi tiết | |---|---| | Kết nối mạng ổn định | VPN hoặc Direct Connect | | Các cổng AD mở | 389, 636, 445, 88, 464, 53, 135, 49152-65535 | | Conditional forwarder cho DNS | hai chiều |

Danh sách cổng dài là lý do nên dùng Direct Connect — mở ngần đó cổng qua Internet không phải lựa chọn tốt.

Hai phiên bản của Managed Microsoft AD: | Phiên bản | Giới hạn | |---|---| | Standard | ~5.000 người dùng, 1 GB dữ liệu thư mục | | Enterprise | ~100.000 người dùng, 17 GB |

Ba đặc điểm của Managed Microsoft AD: | Đặc điểm | Chi tiết | |---|---| | Triển khai qua ít nhất 2 AZ | sẵn sàng cao dựng sẵn | | AWS lo vá lỗi, sao lưu, giám sát | | | Sao chép sang Region khác được | Enterprise edition |

Ba cách dùng AD với IAM: | Cách | Chi tiết | |---|---| | IAM Identity Center với AD làm nguồn danh tính | truy cập Console và CLI | | AWS Directory Service với IAM role | | | SAML federation | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Đặt thư mục trong PRIVATE subnet | | | Bật LDAPS (LDAP qua TLS) | | | Bật CloudWatch Logs cho sự kiện bảo mật | |

aws ds enable-ldaps --directory-id d-abc123 --type Client

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Standard edition | ~0,12 USD/giờ (~88 USD/tháng) | | Enterprise edition | ~0,40 USD/giờ | | AD Connector | rẻ hơn đáng kể |

Ba lựa chọn khác cho danh tính: | Lựa chọn | Đối tượng | |---|---| | IAM Identity Center | nhân viên truy cập AWS | | Amazon Cognito | người dùng ứng dụng (khách hàng) | | Managed Microsoft AD | tải AD-aware |

Ba việc nên làm khi triển khai: | Việc | Chi tiết | |---|---| | Kiểm tra kết nối mạng và cổng trước | | | Thiết lập conditional forwarder cả hai chiều | | | Thử join một máy EC2 Windows để xác nhận | |

Và một lời khuyên: hãy kiểm tra danh sách cổng AD trên đường VPN hoặc Direct Connect trước khi tạo trust. Quan hệ tin cậy sẽ báo "Failed" mà không nói rõ cổng nào bị chặn, và việc dò từng cổng trong danh sách hàng chục mục là phần tốn thời gian nhất của toàn bộ quy trình.

Đáp án

B — Tạo hai hàng đợi SQS Standard: một cho khách pro, một cho khách lite; cấu hình EC2 ưu tiên lấy việc từ hàng đợi pro trước hàng đợi lite.

Vì sao đúng

Đề nêu yêu cầu rõ: ảnh của khách pro phải được xử lý TRƯỚC ảnh của khách lite.

SQS KHÔNG có khái niệm độ ưu tiên trong một hàng đợi
    → không đánh dấu thông điệp là "ưu tiên cao" được
        ↓
    Cách duy nhất: TÁCH thành hai hàng đợi
    → và để consumer quyết định lấy từ đâu trước

Logic consumer:

def lay_viec():
    # Ưu tiên hàng đợi pro
    tn = sqs.receive_message(QueueUrl=URL_PRO, MaxNumberOfMessages=10,
                             WaitTimeSeconds=1)
    if tn.get('Messages'):
        return tn['Messages'], URL_PRO
    # Hàng đợi pro trống → lấy từ lite
    tn = sqs.receive_message(QueueUrl=URL_LITE, MaxNumberOfMessages=10,
                             WaitTimeSeconds=20)
    return tn.get('Messages', []), URL_LITE

WaitTimeSeconds khác nhau là chi tiết quan trọng:

Hàng đợi pro:  chờ NGẮN (1 giây)
    → trống thì chuyển sang lite ngay, không lãng phí thời gian

Hàng đợi lite: chờ DÀI (20 giây, long polling)
    → tiết kiệm chi phí API khi cả hai đều trống

Và cần tránh "bỏ đói" hàng đợi lite:

Nếu hàng đợi pro LUÔN có việc
    → consumer không bao giờ chạm tới lite
    → khách lite chờ mãi
        ↓
    Giải pháp: dành riêng một phần worker cho lite
    → hoặc cứ N vòng thì lấy một lô từ lite

Cách chia worker theo tỷ lệ:

70% worker: ưu tiên pro
30% worker: chỉ đọc lite
        ↓
    Pro được phục vụ nhanh, lite vẫn có tiến triển

Và co giãn riêng từng hàng đợi:

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

Mục tiêu thấp hơn cho hàng đợi pro — thêm máy sớm hơn khi có việc.

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

• **A. Hai hàng đợi Standard, đặt hàng đợi lite dùng short polling và hàng đợi pro dùng long polling — đây là phương án gần nhất và có tách hai hàng đợi đúng, nhưng nó hiểu sai chức năng của polling: short và long polling quyết định thời gian CHỜ khi hàng đợi trống, không quyết định độ ưu tiên. Và dùng long polling cho pro còn làm consumer chờ lâu hơn ở hàng đợi đó.
• **D. Hai hàng đợi FIFO với short/long polling — cùng lỗi về polling, và FIFO thêm giới hạn thông lượng không cần thiết.
• **C. MỘT hàng đợi, đặt visibility timeout của ảnh pro bằng 0 — hiểu sai visibility timeout: nó quyết định thời gian giấu thông điệp sau khi consumer đã nhận, không quyết định thứ tự nhận. Đặt bằng 0 còn gây xử lý trùng nghiêm trọng.

Ghi nhớ

SQS không có độ ưu tiên trong một hàng đợi — cách duy nhất là tách hàng đợi:

Hàng đợi ưu tiên cao  ─┐
                       ├─→ consumer ưu tiên đọc hàng đợi cao trước
Hàng đợi ưu tiên thấp ─┘

Ba lợi ích của việc tách hàng đợi: | Lợi ích | Chi tiết | |---|---| | Kiểm soát được thứ tự phục vụ | ← câu này | | Co giãn ĐỘC LẬP từng hạng | | | Đo được SLA riêng cho từng hạng | |

Short polling và long polling — bảng phải thuộc: | | Short polling | Long polling | |---|---|---| | Chờ khi hàng đợi trống | trả về ngay | tới 20 giây | | Số lời gọi API rỗng | nhiều | ít | | Chi phí | cao hơn | thấp hơn | | Ảnh hưởng độ ưu tiên | KHÔNG | KHÔNG |

Dòng cuối là điểm mà phương án A và D hiểu sai.

Ba mẫu ưu tiên thường dùng: | Mẫu | Chi tiết | |---|---| | Ưu tiên nghiêm ngặt | luôn đọc hàng đợi cao trước | | Chia tỷ lệ worker | tránh bỏ đói hàng đợi thấp | | Trọng số theo vòng | cứ 3 lô pro thì 1 lô lite |

Bỏ đói (starvation) là rủi ro của ưu tiên nghiêm ngặt:

Hàng đợi pro luôn có việc
    → hàng đợi lite không bao giờ được đọc
        ↓
    Khách lite chờ vô hạn
    → và không có cảnh báo nào cho tới khi họ phàn nàn

Đặt alarm cho hàng đợi ưu tiên thấp:

aws cloudwatch put-metric-alarm --alarm-name lite-cho-qua-lau   --metric-name ApproximateAgeOfOldestMessage --namespace AWS/SQS   --dimensions Name=QueueName,Value=hang-doi-lite   --statistic Maximum --period 300 --threshold 1800   --comparison-operator GreaterThanThreshold

Ba thông số SQS quan trọng: | Thông số | Việc | |---|---| | Visibility timeout | giấu thông điệp SAU KHI nhận | | DelaySeconds | hoãn giao thông điệp MỚI | | ReceiveMessageWaitTimeSeconds | long polling |

Ba metric để theo dõi từng hàng đợi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng | | ApproximateAgeOfOldestMessage | SLA của từng hạng | | NumberOfMessagesReceived | thông lượng |

Hai loại hàng đợi — nhắc lại: | | Standard | FIFO | |---|---|---| | Thông lượng | gần như vô hạn | 300/3.000 msg/giây | | Thứ tự | không đảm bảo | đảm bảo trong group | | Trùng lặp | có thể | xử lý đúng một lần |

Với xử lý ảnh không cần thứ tự, Standard là lựa chọn đúng — thông lượng cao hơn nhiều.

Ba yêu cầu với consumer: | Yêu cầu | Chi tiết | |---|---| | IDEMPOTENT | Standard giao ít nhất một lần | | Xoá thông điệp SAU KHI xử lý xong | | | DLQ cho thông điệp hỏng | |

Ba lựa chọn thay thế cho ưu tiên: | Lựa chọn | Chi tiết | |---|---| | Hai hàng đợi + consumer ưu tiên | ← câu này | | Hai ASG riêng, cỡ khác nhau | pro có nhiều worker hơn | | AWS Batch với job queue có priority | dựng sẵn cơ chế ưu tiên |

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

Job queue với priority khác nhau
    → cùng trỏ tới một compute environment
    → Batch tự lập lịch theo độ ưu tiên
        ↓
    Không phải tự viết logic chọn hàng đợi

Ba lưu ý về kiến trúc xử lý ảnh: | Lưu ý | Chi tiết | |---|---| | Ảnh ở S3, chỉ gửi khoá qua SQS | thông điệp SQS tối đa 256 KB | | Lưu kết quả vào bucket KHÁC | tránh vòng lặp sự kiện | | Đặt timeout cho việc xử lý | tránh treo |

Ba cách giảm chi phí: | Cách | Tiết kiệm | |---|---| | Spot cho worker lite | pro dùng On-Demand | | Long polling | giảm số request | | Nhận theo lô (MaxNumberOfMessages: 10) | ít lời gọi hơn |

Dòng đầu là mẫu rất hợp lý:

Khách pro: worker On-Demand, đảm bảo luôn có
Khách lite: worker Spot, rẻ hơn 90%
        ↓
    Mức dịch vụ khác nhau, chi phí khác nhau

Và một lời khuyên: hãy dành riêng một phần worker chỉ đọc hàng đợi lite. Ưu tiên nghiêm ngặt nghe hợp lý cho tới ngày khách pro đủ đông để hàng đợi của họ không bao giờ trống — và khi đó khách lite sẽ ngừng được phục vụ hoàn toàn mà hệ thống vẫn báo mọi thứ bình thường.

Đáp án

A — Chạy các script tuỳ chỉnh dưới dạng user data script trên EC2 instance.

Vì sao đúng

Đề nêu hai yêu cầu, và user data đáp ứng chính xác cả hai: | Yêu cầu | Cơ chế | |---|---| | Chạy MỘT LẦN khi khởi động instance | user data mặc định chỉ chạy ở lần boot ĐẦU TIÊN | | Ít công sức nhất | dán script vào cấu hình, không cần gì thêm |

Hành vi mặc định của user data chính là thứ đề cần:

cloud-init chạy user data ở lần khởi động ĐẦU TIÊN
    → ghi dấu vào /var/lib/cloud/instances/<id>/sem/
        ↓
    Reboot lần sau: thấy dấu → BỎ QUA
        ↓
    Không phải cấu hình gì thêm để đạt "chỉ một lần"

Ví dụ user data:

#!/bin/bash
yum update -y
yum install -y amazon-cloudwatch-agent
aws s3 cp s3://kho-cau-hinh/ung-dung.tar.gz /tmp/
tar -xzf /tmp/ung-dung.tar.gz -C /opt/ung-dung
systemctl enable --now ung-dung

Truyền vào lúc khởi động:

aws ec2 run-instances --image-id ami-0abc --instance-type t3.medium   --user-data file://khoi-tao.sh

Hoặc trong launch template để mọi máy do ASG tạo đều có:

aws ec2 create-launch-template --launch-template-name lt-ung-dung   --launch-template-data '{"ImageId":"ami-0abc",
    "UserData":"'$(base64 -w0 khoi-tao.sh)'"}'

Và nếu muốn chạy MỖI lần khởi động:

#cloud-config
cloud_final_modules:
  - [scripts-user, always]

Hoặc xoá dấu semaphore — nhưng đó là hành vi không mặc định.

Ba chi tiết cần nhớ về user data: | Chi tiết | Giá trị | |---|---| | Chạy với quyền ROOT | | | Giới hạn 16 KB | dài hơn thì tải script từ S3 | | Log ở /var/log/cloud-init-output.log | nơi gỡ lỗi đầu tiên |

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

• **D. Cập nhật cấu hình EC2 để đảm bảo user data chỉ chạy trong quá trình boot — đây là phương án gần nhất và mô tả đúng kết quả mong muốn, nhưng nó thừa: user data vốn đã chỉ chạy một lần theo mặc định. Không cần cấu hình thêm gì, và đề hỏi cách "với công sức tối thiểu".
• **B. Chạy script dưới dạng instance metadata script — không phải khái niệm có thật: instance metadata là dữ liệu để ĐỌC (ID instance, IP, IAM role), không phải nơi chứa script để chạy.
• **C. Dùng AWS CLI để chạy user data script chỉ một lần khi khởi động — hiểu sai cơ chế: user data do cloud-init trên chính instance thực thi, không phải do CLI từ bên ngoài gọi.

Ghi nhớ

User data và instance metadata — bảng phải thuộc: | | User data | Instance metadata | |---|---|---| | Là gì | script BẠN cung cấp để chạy | thông tin về instance để ĐỌC | | Truy cập | /latest/user-data | /latest/meta-data/ | | Ai chạy | cloud-init trên instance | không chạy gì | | Ví dụ | script cài đặt | instance-id, IP, IAM role |

Đọc metadata (IMDSv2):

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/instance-id

⚠ Ba lưu ý bảo mật về user data: | Lưu ý | Chi tiết | |---|---| | KHÔNG đặt bí mật trong user data | ai vào được instance đều đọc được | | Dùng Secrets Manager hoặc Parameter Store | | | Bắt buộc IMDSv2 | chống SSRF |

Đọc được user data từ chính instance:

curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/user-data

Đây là lý do không bao giờ đặt mật khẩu ở đó.

Bắt buộc IMDSv2:

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-tokens required --http-put-response-hop-limit 1

IMDSv1: gọi GET đơn giản → lỗ hổng SSRF khai thác được
IMDSv2: cần token qua PUT → chặn hầu hết SSRF
        ↓
    AWS khuyến nghị bắt buộc IMDSv2 cho mọi instance

Ba cách cấu hình instance khi khởi động: | Cách | Thời gian | Linh hoạt | |---|---|---| | Golden AMI | nhanh nhất | thấp | | User data | chậm hơn | cao | | Kết hợp cả hai | cân bằng | cân bằng ← khuyến nghị |

Nguyên tắc chia:

Vào AMI:       hệ điều hành, runtime, thư viện, agent
Vào user data: cấu hình, phiên bản mã, biến môi trường

Ba cách viết user data: | Cách | Chi tiết | |---|---| | Shell script (#!/bin/bash) | phổ biến nhất | | cloud-config (#cloud-config) | khai báo, có nhiều module | | MIME multi-part | kết hợp nhiều loại |

Ví dụ cloud-config:

#cloud-config
package_update: true
packages:
  - amazon-cloudwatch-agent
  - htop
write_files:
  - path: /etc/ung-dung/cau-hinh.yml
    content: |
      moi_truong: san-xuat
runcmd:
  - systemctl enable --now ung-dung

Ba nơi kiểm tra khi user data không chạy: | Nơi | Lệnh | |---|---| | /var/log/cloud-init-output.log | đầu ra của script | | /var/log/cloud-init.log | log của cloud-init | | Dấu semaphore | /var/lib/cloud/instances/<id>/sem/ |

Ba lỗi thường gặp: | Lỗi | Nguyên nhân | |---|---| | Thiếu dòng #!/bin/bash | cloud-init không biết cách chạy | | Vượt 16 KB | tải script từ S3 thay thế | | Script không idempotent | vấn đề khi chạy lại |

Tải script dài từ S3:

#!/bin/bash
aws s3 cp s3://kho-script/khoi-tao-day-du.sh /tmp/
chmod +x /tmp/khoi-tao-day-du.sh && /tmp/khoi-tao-day-du.sh

Ba lựa chọn thay thế cho cấu hình instance: | Lựa chọn | Đặc điểm | |---|---| | User data | ← câu này, đơn giản nhất | | Systems Manager State Manager | áp cấu hình liên tục, cả máy đang chạy | | EC2 Image Builder | dựng AMI có pipeline |

State Manager đáng biết:

Áp cấu hình theo lịch cho mọi instance có tag
    → tự sửa nếu ai đó đổi
        ↓
    Khác user data: chạy LIÊN TỤC, không chỉ lúc khởi động

Ba lưu ý khi dùng user data với ASG: | Lưu ý | Chi tiết | |---|---| | Đặt trong launch template | mọi máy mới đều có | | Script chạy lâu làm chậm việc mở rộng | | | HealthCheckGracePeriod phải đủ dài | chờ script xong |

Và một lời khuyên: hãy thêm dấu thời gian vào đầu ra của user data để đo bước nào tốn thời gian nhất. Với Auto Scaling, mỗi giây trong user data là một giây chậm hơn khi cần thêm máy — và thường chỉ một lệnh cài gói duy nhất chiếm phần lớn thời gian, mà đưa vào golden AMI là giải quyết xong.

Đáp án

A — Bật S3 Storage Lens với advanced metrics and recommendations, dùng bảng điều khiển theo bucket để lọc và xem trạng thái versioning trên mọi Region, tìm ra các bucket chưa bật versioning.

Vì sao đúng

Đề nêu ba yêu cầu, và Storage Lens đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Tìm bucket CHƯA bật versioning | advanced metrics có chỉ số versioning | | Trên MỌI Region và tài khoản | Storage Lens ở cấp TỔ CHỨC | | Ít công vận hành nhất | bật một lần, không viết mã |

Storage Lens là công cụ duy nhất cho cái nhìn toàn cảnh:

S3 Storage Lens:
    ✓ tổng hợp MỌI bucket, MỌI Region, MỌI tài khoản
    ✓ có sẵn chỉ số cấu hình bảo mật
    ✓ bảng điều khiển trực quan, xuất được ra S3
        ↓
    Không phải viết mã, không phải gọi API từng bucket

Bật ở cấp tổ chức:

aws s3control put-storage-lens-configuration   --account-id 123456789012 --config-id kiem-toan-toan-to-chuc   --storage-lens-configuration '{
    "Id":"kiem-toan-toan-to-chuc",
    "AccountLevel":{
      "ActivityMetrics":{"IsEnabled":true},
      "AdvancedCostOptimizationMetrics":{"IsEnabled":true},
      "AdvancedDataProtectionMetrics":{"IsEnabled":true},
      "BucketLevel":{
        "AdvancedDataProtectionMetrics":{"IsEnabled":true}}},
    "AwsOrg":{"Arn":"arn:aws:organizations::123456789012:organization/o-abc"},
    "IsEnabled":true,
    "DataExport":{"S3BucketDestination":{
      "Format":"CSV","OutputSchemaVersion":"V_1",
      "AccountId":"123456789012",
      "Arn":"arn:aws:s3:::bao-cao-storage-lens"}}}'

AdvancedDataProtectionMetrics là phần chứa chỉ số versioning: | Chỉ số | Ý nghĩa | |---|---| | VersioningEnabledBucketCount | số bucket ĐÃ bật versioning | | MFADeleteEnabledBucketCount | | | SSEKMSEnabledBucketCount | | | ObjectLockEnabledBucketCount | | | CrossRegionReplicationRuleCount | |

Suy ra danh sách bucket chưa bật:

Tổng số bucket − VersioningEnabledBucketCount
    → và bảng điều khiển theo bucket cho biết CỤ THỂ bucket nào

Và dữ liệu xuất ra S3 cho phép truy vấn bằng Athena:

SELECT bucket_name, aws_region
FROM storage_lens_metrics
WHERE metric_name = 'VersioningEnabledBucketCount' AND metric_value = 0;

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

• **D. CloudTrail + EventBridge bắt PutBucketVersioning rồi Lambda phân tích và sinh báo cáo — đây là phương án gần nhất và về nguyên tắc hoạt động được, nhưng nó chỉ bắt được THAY ĐỔI TỪ NAY VỀ SAU: bucket đã tồn tại từ trước và chưa bao giờ đổi cấu hình versioning sẽ không bao giờ sinh sự kiện nào. Và phải viết, triển khai, bảo trì Lambda ở mọi Region.
• **B. Bật IAM Access Analyzer ở mọi Region rồi xem báo cáo — sai công cụ: Access Analyzer phát hiện tài nguyên chia sẻ ra ngoài, nó không báo cáo trạng thái versioning.
• **C. Tạo Multi-Region Access Point rồi kiểm tra versioning bằng cách đọc metadata của object — hiểu sai cả hai thứ: MRAP là điểm truy cập dữ liệu, không phải công cụ kiểm toán cấu hình. Và versioning là thuộc tính của bucket, không nằm trong metadata object.

Ghi nhớ

Ba công cụ kiểm toán cấu hình S3 — bảng phải thuộc: | Công cụ | Việc | |---|---| | S3 Storage Lens | tổng quan MỌI bucket: dung lượng, chi phí, cấu hình bảo vệ dữ liệu | | AWS Config | quy tắc tuân thủ, có TỰ SỬA | | IAM Access Analyzer | tài nguyên chia sẻ ra ngoài | | Security Hub | tổng hợp phát hiện |

AWS Config cũng là lựa chọn tốt cho câu này:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName":"bucket-phai-bat-versioning",
  "Source":{"Owner":"AWS","SourceIdentifier":"S3_BUCKET_VERSIONING_ENABLED"}}'

Config rule dựng sẵn kiểm tra versioning
    → và có REMEDIATION tự bật
        ↓
    Mạnh hơn Storage Lens ở khả năng SỬA,
    nhưng cần bật Config ở mọi Region và tài khoản

Hai mức metric của Storage Lens: | Mức | Chi tiết | |---|---| | Free metrics | 28 chỉ số cơ bản, dung lượng và số object, MIỄN PHÍ | | Advanced metrics | thêm chỉ số hoạt động, bảo vệ dữ liệu, tối ưu chi phí — CÓ PHÍ |

Chỉ số versioning nằm ở mức advanced — đó là lý do đề nêu rõ "advanced metrics".

Bốn nhóm chỉ số của Storage Lens: | Nhóm | Ví dụ | |---|---| | Summary | dung lượng, số object | | Cost optimization | multipart dở dang, phân bố lớp lưu trữ | | Data protection | versioning, replication, mã hoá, Object Lock | | Access management | Object Ownership | | Detailed status code | lỗi 4xx, 5xx |

Ba phạm vi của Storage Lens: | Phạm vi | Chi tiết | |---|---| | Tài khoản đơn | | | TỔ CHỨC | cần delegated administrator | | Lọc theo Region, bucket, prefix | |

Chỉ định tài khoản quản trị:

aws s3control associate-access-grants-identity-center ...
# hoặc trong console Organizations, uỷ quyền cho tài khoản kiểm toán

Ba lợi ích của versioning: | Lợi ích | Chi tiết | |---|---| | Chống ghi đè và xoá nhầm | | | Điều kiện BẮT BUỘC cho replication | | | Điều kiện BẮT BUỘC cho Object Lock | |

Hai dòng cuối là lý do versioning thường là yêu cầu tuân thủ.

Ba lưu ý về versioning: | Lưu ý | Chi tiết | |---|---| | Bật rồi chỉ TẠM DỪNG được, không tắt hẳn | | | Mọi phiên bản đều tính phí lưu trữ | | | Cần lifecycle dọn phiên bản cũ | |

Lifecycle bắt buộc khi bật versioning:

{"Rules": [{"ID":"don-phien-ban-cu","Status":"Enabled","Filter":{},
  "NoncurrentVersionExpiration":{"NoncurrentDays":90},
  "Expiration":{"ExpiredObjectDeleteMarker":true}}]}

Không có quy tắc này:
    → phiên bản cũ tích tụ vô hạn
    → chi phí tăng đều mà không ai để ý

Ba cách bật versioning hàng loạt: | Cách | Chi tiết | |---|---| | Script lặp qua danh sách bucket | đơn giản | | AWS Config remediation | tự động, liên tục | | SCP bắt buộc bucket mới có versioning | phòng ngừa |

aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' |   while read b; do
    aws s3api put-bucket-versioning --bucket "$b"       --versioning-configuration Status=Enabled
  done

Ba lưu ý về chi phí Storage Lens: | Khoản | Chi tiết | |---|---| | Free metrics | miễn phí | | Advanced metrics | ~0,20 USD mỗi triệu object theo dõi | | Xuất dữ liệu ra S3 | phí lưu trữ |

Ba lưu ý về xuất dữ liệu: | Lưu ý | Chi tiết | |---|---| | Xuất hằng ngày ra S3 (CSV hoặc Parquet) | | | Truy vấn được bằng Athena | | | Giữ lịch sử để theo dõi xu hướng | |

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | Xem bảng điều khiển Storage Lens | hàng tháng | | Rà soát bucket chưa tuân thủ | hàng tháng | | Kiểm tra phiên bản cũ chiếm bao nhiêu dung lượng | hàng quý |

Và một lời khuyên: hãy kết hợp Storage Lens với một AWS Config rule. Storage Lens cho bức tranh toàn cảnh và xu hướng, còn Config rule tự phát hiện và sửa bucket mới vi phạm — dùng một mình Storage Lens nghĩa là bạn vẫn phải nhớ vào xem báo cáo, và đó chính là công vận hành mà đề muốn giảm.

Đáp án

D — Tạo read replica trong CÙNG Region với database chính và trỏ tải phân tích sang đó.

Vì sao đúng

Đề nêu vấn đề rõ: tải phân tích làm chậm ứng dụng thương mại điện tử, và yêu cầu tối ưu chi phí nhất.

Nguyên nhân: hai loại tải cạnh tranh cùng một database
    → truy vấn phân tích quét nhiều dữ liệu, chiếm CPU và I/O
    → truy vấn giao dịch bị chậm theo
        ↓
    Tách chúng ra hai instance khác nhau

Read replica giải quyết chính xác:

Master:  chỉ phục vụ ứng dụng thương mại điện tử
Replica: chỉ phục vụ tải phân tích
        ↓
    Truy vấn phân tích nặng đến mấy cũng
      không ảnh hưởng master

Và "cùng Region" là điểm tối ưu chi phí:

Read replica CÙNG Region:
    → KHÔNG tốn phí truyền dữ liệu xuyên Region
    → độ trễ sao chép thấp hơn

Read replica KHÁC Region:
    → tốn phí truyền dữ liệu liên tục (~0,02 USD/GB)
    → độ trễ sao chép cao hơn
        ↓
    Với mục tiêu chỉ là tách tải, cùng Region là đủ và rẻ hơn

Tạo replica:

aws rds create-db-instance-read-replica   --db-instance-identifier replica-phan-tich   --source-db-instance-identifier db-thuong-mai   --db-instance-class db.r6g.large

Và ứng dụng phân tích trỏ tới endpoint của replica:

postgresql://replica-phan-tich.abc.ap-northeast-1.rds.amazonaws.com:5432/phan_tich

Ba lợi ích phụ: | Lợi ích | Chi tiết | |---|---| | Cỡ replica chọn riêng | tối ưu cho truy vấn phân tích | | Tham số riêng | work_mem lớn hơn cho JOIN nặng | | Promote được nếu cần | khôi phục thảm hoạ |

Dòng giữa đáng chú ý:

aws rds create-db-parameter-group --db-parameter-group-name pg-phan-tich   --db-parameter-group-family postgres16 --description "Cho tai phan tich"

aws rds modify-db-parameter-group --db-parameter-group-name pg-phan-tich   --parameters "ParameterName=work_mem,ParameterValue=262144,ApplyMethod=immediate"

Replica có parameter group riêng — tối ưu cho phân tích mà không ảnh hưởng master.

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

• **B. Tạo read replica ở REGION KHÁC làm master và trỏ tải phân tích sang đó — đây là phương án gần nhất và cũng tách được tải, nhưng nó tốn phí truyền dữ liệu xuyên Region liên tục và có độ trễ sao chép cao hơn. Đề hỏi "MOST cost-optimal". (Và cách diễn đạt "as the Master database" cũng lẫn lộn — replica không phải master.)
• **C. Bật Multi-AZ và chạy tải phân tích trên standby — sai về mặt kỹ thuật: standby của Multi-AZ KHÔNG phục vụ bất kỳ lưu lượng nào. Nó chỉ chờ để chuyển đổi.
• **A. Chuyển ứng dụng phân tích sang AWS Lambda — không giải quyết gì: đổi nơi chạy mã không làm giảm tải trên database. Truy vấn vẫn chạm cùng một instance.

Ghi nhớ

Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Standby/replica phục vụ đọc | ❌ | ✅ | | Chuyển đổi | TỰ ĐỘNG | thủ công (promote) | | Phạm vi | cùng Region | cùng hoặc khác Region |

Dòng thứ ba là điểm mà phương án C hiểu sai.

Ba trường hợp dùng read replica: | Trường hợp | Chi tiết | |---|---| | Tách tải phân tích khỏi giao dịch | ← câu này | | Mở rộng năng lực đọc | | | Khôi phục thảm hoạ (cross-Region) | |

Ba đặc điểm của read replica: | Đặc điểm | Chi tiết | |---|---| | Sao chép BẤT ĐỒNG BỘ | có độ trễ | | CHỈ ĐỌC | không ghi được | | Promote được thành database độc lập | một chiều |

Số replica tối đa theo engine: | Engine | Số replica | |---|---| | RDS MySQL, MariaDB, PostgreSQL | 15 | | Aurora | 15 | | SQL Server | 5 (cần Enterprise Edition) | | Oracle | 5 |

Ba lưu ý về độ trễ sao chép: | Lưu ý | Chi tiết | |---|---| | Theo dõi ReplicaLag | | | Truy vấn nặng trên replica có thể làm tăng độ trễ | | | Dữ liệu trên replica có thể cũ vài giây | |

Với tải phân tích, độ trễ vài giây thường chấp nhận được.

Ba cách tối ưu replica cho phân tích: | Cách | Chi tiết | |---|---| | Parameter group riêng | work_mem, max_parallel_workers | | Cỡ instance riêng | tối ưu cho quét lớn | | Index riêng | PostgreSQL: KHÔNG tạo được trên replica |

Dòng cuối là hạn chế:

Read replica của RDS là bản sao vật lý
    → KHÔNG tạo index riêng trên replica được
        ↓
    Index phải tạo trên master và sao chép xuống

Ba lựa chọn khác cho tải phân tích: | Lựa chọn | Khi nào | |---|---| | Read replica | ← câu này, đơn giản nhất | | Amazon Redshift | phân tích quy mô lớn, truy vấn phức tạp | | S3 + Athena | dữ liệu lịch sử, truy vấn không thường xuyên |

Redshift đáng cân nhắc nếu tải phân tích lớn:

Database quan hệ tối ưu cho GIAO DỊCH (OLTP)
    → truy vấn phân tích quét hàng triệu dòng chạy chậm
        ↓
    Redshift lưu theo CỘT, nén, xử lý song song
    → nhanh hơn hàng chục lần cho cùng truy vấn

Ba cách đưa dữ liệu sang Redshift: | Cách | Chi tiết | |---|---| | AWS DMS với CDC | sao chép liên tục | | Zero-ETL integration | Aurora sang Redshift, không cần đường ống | | Xuất S3 rồi COPY | theo lô |

Zero-ETL là tính năng đáng biết:

Aurora MySQL/PostgreSQL → Redshift
    → dữ liệu tự đồng bộ gần thời gian thực
    → KHÔNG cần dựng đường ống ETL nào
        ↓
    Giải pháp hiện đại cho đúng bài toán trong đề

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicaLag | replica tụt lại bao xa | | CPUUtilization của master | xác nhận đã giảm | | ReadIOPS của replica | tải phân tích thật |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Replica tính phí như instance đầy đủ | | | Cùng Region: KHÔNG tốn phí truyền dữ liệu | ← điểm của câu này | | Khác Region: tốn phí liên tục | |

Ba việc nên làm sau khi tạo replica: | Việc | Chi tiết | |---|---| | Xác nhận ứng dụng phân tích đã đổi endpoint | | | Đo CPU của master trước và sau | | | Đặt alarm cho ReplicaLag | |

Và một lời khuyên: hãy kiểm tra CPUUtilization của master sau một tuần để xác nhận việc tách tải thật sự có hiệu quả. Nếu con số không giảm, nghĩa là ứng dụng phân tích vẫn còn kết nối nào đó trỏ về master — và đó là lỗi cấu hình rất dễ xảy ra khi một hệ thống có nhiều nơi khai chuỗi kết nối.

Đáp án

B — Dùng AWS Budgets tạo coverage budget hằng ngày riêng cho Compute Savings Plans, đặt ngưỡng độ phủ và cấu hình thông báo cho các bên liên quan.

Vì sao đúng

Đề nêu ba yêu cầu, và AWS Budgets có đúng loại ngân sách cho việc này: | Yêu cầu | Cơ chế | |---|---| | Theo dõi mức tận dụng | utilization budget | | Cảnh báo khi ĐỘ PHỦ xuống dưới ngưỡng | coverage budget | | Ít công vận hành nhất | tính năng dựng sẵn, không viết mã |

Bốn loại ngân sách của AWS Budgets: | Loại | Theo dõi | |---|---| | Cost budget | số tiền chi tiêu | | Usage budget | lượng dùng (giờ, GB) | | Savings Plans utilization | bao nhiêu phần cam kết ĐƯỢC DÙNG | | Savings Plans coverage | bao nhiêu phần chi tiêu ĐƯỢC PHỦ ← câu này |

Phân biệt utilization và coverage — rất quan trọng:

UTILIZATION (mức tận dụng):
    → phần cam kết bạn đã mua có được dùng hết không
    → thấp = đang TRẢ TIỀN THỪA cho cam kết không dùng

COVERAGE (độ phủ):
    → phần chi tiêu đủ điều kiện được cam kết phủ
    → thấp = đang trả giá On-Demand cho phần chưa phủ
        ↓
    Đề nói "coverage levels fall below a threshold" → coverage budget

Tạo coverage budget:

aws budgets create-budget --account-id 123456789012   --budget '{"BudgetName":"do-phu-savings-plans",
             "BudgetLimit":{"Amount":"80","Unit":"PERCENT"},
             "TimeUnit":"DAILY",
             "BudgetType":"SAVINGS_PLANS_COVERAGE"}'   --notifications-with-subscribers '[{
    "Notification":{"NotificationType":"ACTUAL",
      "ComparisonOperator":"LESS_THAN","Threshold":80,
      "ThresholdType":"PERCENTAGE"},
    "Subscribers":[{"SubscriptionType":"EMAIL",
                    "Address":"doi-van-hanh@vidu.com"}]}]'

ComparisonOperator: LESS_THAN là chi tiết đúng cho coverage — bạn muốn báo động khi độ phủ giảm, khác với cost budget báo khi chi phí tăng.

Và TimeUnit: DAILY cho phản ứng nhanh:

Ngân sách hằng ngày:
    → phát hiện độ phủ tụt trong vòng một ngày
        ↓
    Ngân sách hằng tháng phát hiện quá muộn

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

• **A. Tạo dashboard CloudWatch theo dõi mức dùng EC2 và Fargate, dùng metric math ước lượng độ phủ — đây là phương án gần nhất và về lý thuyết dựng được, nhưng nó là ước lượng thủ công thay cho một chỉ số có sẵn: dữ liệu Savings Plans không nằm trong CloudWatch metric, và tính lại độ phủ bằng metric math sẽ không khớp với con số thật của AWS.
• **C. Bật Compute Optimizer và cấu hình thông báo về cơ hội tối ưu và độ phủ Savings Plans — sai công cụ: Compute Optimizer khuyến nghị kích thước tài nguyên, nó không theo dõi độ phủ Savings Plans.
• **D. Viết script gọi API, đẩy vào S3, dùng QuickSight vẽ và gửi báo cáo hằng tuần — công vận hành cao nhất và phản ứng chậm nhất: phải viết và bảo trì mã, và báo cáo hằng tuần nghĩa là có thể mất cả tuần mới biết độ phủ đã tụt.

Ghi nhớ

Bốn loại ngân sách của AWS Budgets — bảng phải thuộc: | Loại | Cảnh báo khi | |---|---| | Cost | chi phí VƯỢT ngưỡng | | Usage | lượng dùng vượt ngưỡng | | RI/SP Utilization | mức tận dụng DƯỚI ngưỡng | | RI/SP Coverage | độ phủ DƯỚI ngưỡng ← câu này |

Hai loại sau dùng LESS_THAN, hai loại đầu dùng GREATER_THAN.

Utilization và Coverage — bảng phân biệt: | | Utilization | Coverage | |---|---|---| | Câu hỏi | "cam kết đã mua có dùng hết không?" | "chi tiêu có được phủ không?" | | Thấp nghĩa là | mua thừa | chưa mua đủ | | Hành động | giảm cam kết khi hết hạn | mua thêm |

Hai loại Savings Plans: | Loại | Tiết kiệm | Linh hoạt | |---|---|---| | Compute Savings Plans | tới 66% | EC2, Fargate, Lambda; mọi Region, mọi họ | | EC2 Instance Savings Plans | tới 72% | một họ instance, một Region |

Đề nói rõ công ty dùng EC2, Fargate và Lambda — Compute Savings Plans là lựa chọn đúng vì nó phủ cả ba.

Savings Plans và Reserved Instances — bảng phân biệt: | | Savings Plans | Reserved Instances | |---|---|---| | Cam kết theo | USD/giờ | loại instance cụ thể | | Linh hoạt | cao | thấp hơn | | Áp cho Lambda, Fargate | ✅ (Compute SP) | ❌ | | Bán lại trên marketplace | ❌ | ✅ (Standard RI) |

AWS khuyến nghị Savings Plans cho hầu hết trường hợp.

Ba mức cam kết: | Kỳ hạn | Trả trước | Tiết kiệm | |---|---|---| | 1 năm, không trả trước | 0% | thấp nhất | | 1 năm, trả trước một phần | ~50% | vừa | | 3 năm, trả trước toàn bộ | 100% | cao nhất |

Ba công cụ quản lý chi phí — nhắc lại: | Công cụ | Việc | |---|---| | AWS Budgets | ngưỡng, cảnh báo, hành động tự động | | Cost Explorer | phân tích và khuyến nghị mua Savings Plans | | Cost Anomaly Detection | phát hiện bất thường bằng học máy |

Cost Explorer có công cụ khuyến nghị:

aws ce get-savings-plans-purchase-recommendation   --savings-plans-type COMPUTE_SP --term-in-years ONE_YEAR   --payment-option NO_UPFRONT --lookback-period-in-days SIXTY_DAYS

Phân tích 60 ngày chi tiêu thật
    → gợi ý mức cam kết USD/giờ tối ưu
    → ước tính khoản tiết kiệm

Ba nguyên nhân độ phủ tụt: | Nguyên nhân | Chi tiết | |---|---| | Tải tăng vượt mức cam kết | cần mua thêm | | Savings Plans cũ hết hạn | đặt nhắc trước 30 ngày | | Chuyển sang dịch vụ không được phủ | |

Ba loại thông báo: | Loại | Chi tiết | |---|---| | Email | tới 10 địa chỉ | | SNS topic | tích hợp với hệ thống khác | | AWS Chatbot | vào Slack hoặc Teams |

Gửi vào Slack rất tiện:

Budget → SNS → AWS Chatbot → kênh Slack của đội vận hành
        ↓
    Cảnh báo tới đúng nơi đội đang làm việc

Ba lưu ý về budget action: | Loại | Chi tiết | |---|---| | Áp IAM policy hoặc SCP | chặn quyền | | Dừng EC2 hoặc RDS | | | — | coverage budget thường chỉ cần cảnh báo, không cần hành động |

Ba lưu ý về chi phí AWS Budgets: | Khoản | Chi tiết | |---|---| | 2 ngân sách đầu MIỄN PHÍ | | | Sau đó ~0,02 USD/ngân sách/ngày | | | Budget action | phí riêng nhỏ |

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | Xem báo cáo utilization và coverage | hàng tháng | | Chạy khuyến nghị mua từ Cost Explorer | hàng quý | | Đặt nhắc trước khi cam kết hết hạn | 30 ngày |

Và một lời khuyên: hãy tạo cả hai ngân sách — utilization và coverage — chứ không chỉ một. Chúng bắt hai lỗi ngược nhau: coverage thấp nghĩa là bạn đang trả giá On-Demand không cần thiết, còn utilization thấp nghĩa là bạn đã cam kết nhiều hơn mức dùng — và chỉ theo dõi một trong hai sẽ để lọt đúng một nửa vấn đề.