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

Đáp án

A — Amazon Kinesis Data Streams.

Vì sao đúng

Đọc kỹ hai yêu cầu ở cuối đề: nạp hàng terabyte flow log thời gian thực mỗi ngày một cách tiết kiệm, và có tính linh hoạt để định tuyến dữ liệu tới các hệ thống downstream khác.

Vế thứ hai là điểm quyết định. Kinesis Data Streams cho phép nhiều consumer độc lập cùng đọc toàn bộ luồng dữ liệu:

                       ┌→ Consumer 1: phát hiện bất thường thời gian thực
Flow logs → Stream ────┼→ Consumer 2: nạp vào S3 để phân tích lịch sử
  (giữ 24h–365 ngày)   ├→ Consumer 3: dashboard vận hành
                       └→ Consumer 4: cảnh báo bảo mật

Mỗi consumer có con trỏ đọc riêng, nên chúng không ảnh hưởng nhau và có thể tua lại trong khoảng lưu giữ. Đây chính là "flexibility to direct this data to other downstream systems".

Về chi phí: Kinesis tính theo shard-giờ và số bản ghi, rẻ hơn nhiều so với việc dựng và vận hành một cụm Kafka tự quản ở quy mô hàng terabyte mỗi ngày.

(Đây là kiến trúc thật của Netflix — họ dùng Kinesis Data Streams để nạp VPC Flow Logs cho hệ thống giám sát mạng nội bộ.)

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

• B. Kinesis Data Firehose — nạp dữ liệu vào một đích (S3, Redshift, OpenSearch) rất tốt, nhưng nó không giữ dữ liệu để phát lại và không cho nhiều consumer độc lập. Muốn thêm một hệ downstream mới thì phải đọc lại từ đích, mất tính linh hoạt. Firehose cũng gom theo lô (tối thiểu ~60 giây) nên không phải thời gian thực thật.
• D. Amazon SQS — điểm chặn: message bị xoá sau khi được xử lý. Không phát lại được, và mỗi message chỉ tới một consumer. Không thể có bốn hệ downstream cùng đọc.
• C. AWS Glue — dịch vụ ETL theo lô (và có Glue Streaming, nhưng nó tiêu thụ từ Kinesis/Kafka). Nó là bộ xử lý, không phải bộ nạp và phân phối luồng.

Ghi nhớ

Nhận dạng nhanh: đề nói "multiple downstream systems", "replay", hoặc "ordered" ⇒ Kinesis Data Streams. Nói "nạp vào S3/Redshift với ít công sức nhất" ⇒ Firehose.

Đáp án

A — AWS Step Functions.

Vì sao đúng

Đề nêu bốn yêu cầu, và Step Functions đáp ứng cả bốn:

Điểm mạnh nhất cho bài toán này là cơ chế xử lý lỗi khai báo, không phải mã:

"BienDoiDuLieu": {
  "Type": "Task",
  "Resource": "arn:aws:states:::glue:startJobRun.sync",
  "Parameters": {"JobName": "bien-doi-du-lieu"},
  "Retry": [{
    "ErrorEquals": ["States.TaskFailed"],
    "IntervalSeconds": 30, "MaxAttempts": 3, "BackoffRate": 2.0
  }],
  "Catch": [{
    "ErrorEquals": ["States.ALL"],
    "Next": "XuLyLoi"
  }],
  "Next": "NapVaoKho"
}

Thêm Map state cho việc xử lý song song nhiều nguồn, và distributed map cho quy mô rất lớn (tới hàng triệu mục).

Và quan trọng: Step Functions giữ trạng thái của cả quy trình — bạn nhìn thấy được từng lần chạy đang ở bước nào, dữ liệu vào/ra ra sao, bước nào đã thử lại mấy lần.

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

• B. AWS Glue — công cụ ETL rất mạnh cho việc biến đổi dữ liệu, và Glue có workflow riêng. Nhưng workflow của Glue chỉ điều phối các thành phần của chính Glue (crawler, job, trigger); nó không điều phối được Lambda, ECS, API bên ngoài hay bước phê duyệt. Đề nói "multi-source" và "business rules", cần phạm vi rộng hơn. (Mẫu thực tế: Step Functions điều phối, Glue thực hiện biến đổi.)
• C. Kinesis Data Streams — dịch vụ nạp luồng dữ liệu, không điều phối gì. Nó là một nguồn dữ liệu trong đường ống, không phải bộ điều phối.
• D. AWS Batch — chạy job tính toán theo lô trên hạ tầng do nó cấp. Hợp cho mô phỏng, render, xử lý nặng — nhưng nó không có logic rẽ nhánh, không có retry theo bước, không giữ trạng thái quy trình.

Ghi nhớ

Hai loại workflow: Standard (tới 1 năm, exactly-once, có lịch sử đầy đủ — hợp cho đường ống dữ liệu như đề này) và Express (dưới 5 phút, tần suất rất cao, rẻ hơn).

Đáp án

B — Dùng IAM policy với tiền tố Cognito identity để giới hạn mỗi người dùng chỉ truy cập thư mục của chính họ trong S3.

Vì sao đúng

Yêu cầu: mỗi người dùng chỉ đọc/ghi được tệp của chính mình, tệp từ 5 KB đến 500 MB, và giải pháp phải hiệu quả nhất.

Cách gọn nhất là để IAM tự thực thi ràng buộc, dùng policy variable của Cognito:

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

Biến ${cognito-identity.amazonaws.com:sub} được thay bằng identity ID duy nhất của người dùng tại thời điểm đánh giá. Một policy duy nhất, áp cho mọi người dùng, và mỗi người bị khoá vào đúng thư mục của mình:

s3://tep-nguoi-dung/ap-southeast-1:abc-123/anh1.jpg    ← chỉ user abc-123 truy cập được
s3://tep-nguoi-dung/ap-southeast-1:def-456/anh2.jpg    ← chỉ user def-456

Vì sao đây là hiệu quả nhất: client tải thẳng lên S3 bằng thông tin xác thực tạm thời từ identity pool. Không có Lambda nào chạy, không có API Gateway nào ở giữa — nên không vướng giới hạn payload, không tốn chi phí tính toán, và không có điểm nghẽn với tệp 500 MB.

Ràng buộc được thực thi ở tầng IAM, tức là không thể lách được — kể cả khi client bị sửa đổi.

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

• D. API Gateway + Lambda kiểm tra quyền — đây là bẫy phổ biến, và nó vướng giới hạn cứng: payload tối đa của API Gateway là 10 MB, của Lambda đồng bộ là 6 MB. Tệp 500 MB không đi qua được. Ngoài ra nó thêm chi phí tính toán cho việc mà IAM làm miễn phí.
• C. CloudFront Lambda@Edge để xác thực — Lambda@Edge có giới hạn còn chặt hơn (payload rất nhỏ, timeout ngắn), và CloudFront không dùng cho việc tải lên. Sai công cụ.
• A. S3 Event Notification + Lambda kiểm tra sau khi tải lên — sai về thời điểm: sự kiện chỉ phát SAU KHI object đã được ghi. Tệp trái phép đã nằm trong bucket rồi mới bị phát hiện — đó là kiểm soát phát hiện, không phải ngăn chặn. Và nó hoàn toàn không kiểm soát được việc tải xuống.

Ghi nhớ

Các policy variable hay dùng với Cognito: | Biến | Giá trị | |---|---| | ${cognito-identity.amazonaws.com:sub} | identity ID (identity pool) | | ${aws:userid} | ID duy nhất của principal | | ${aws:PrincipalTag/<key>} | tag của principal — nền tảng của ABAC |

Kiến trúc chuẩn cho ứng dụng lưu tệp theo người dùng:

Người dùng → Cognito user pool (đăng nhập, nhận JWT)
           → Cognito identity pool (đổi JWT lấy thông tin xác thực AWS)
           → tải thẳng lên/xuống S3, giới hạn bởi IAM policy variable

Đáp án

B — Bạn đang gặp hot partition.

Vì sao đúng

Phép tính trong đề chỉ thẳng vào vấn đề:

Tổng WCU cấp phát : 400
Số partition      : 4
WCU mỗi partition : 400 ÷ 4 = 100 WCU/giây
Một partition nhận: 250 WCU/giây     ← VƯỢT 100 → ProvisionedThroughputExceededException

Đây là đặc điểm cốt lõi của DynamoDB mà nhiều người bỏ qua: throughput được chia ĐỀU cho các partition, không phải gộp chung. Bảng có 400 WCU nhưng mỗi partition chỉ được 100 — dù các partition khác đang nhàn rỗi.

Hot partition xảy ra khi partition key phân bố lệch: quá nhiều bản ghi cùng đổ vào một giá trị khoá.

Các nguyên nhân điển hình: | Partition key xấu | Vì sao lệch | |---|---| | trang_thai (dang_xu_ly, xong) | chỉ vài giá trị | | ngay | mọi ghi trong ngày dồn vào một khoá | | quoc_gia | một nước chiếm đa số lưu lượng |

Cách chữa — rải khoá bằng hậu tố:

partition_key = f"{ngay}#{random.randint(0, 9)}"     # rải thành 10 partition

(Ghi chú: DynamoDB có adaptive capacity tự dồn thêm throughput cho partition nóng, nhưng nó không xử lý được lệch cực đoan và không thay thế được thiết kế khoá tốt.)

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

• A. "CloudWatch monitoring bị trễ" — metric có thể trễ vài phút, nhưng lỗi ProvisionedThroughputExceededException là lỗi thật, trả về ngay lúc gọi API. Nó không phải hiển thị sai.
• C. IAM policy cấu hình sai — thiếu quyền sẽ cho lỗi AccessDeniedException, một mã lỗi hoàn toàn khác.
• D. "WCU được áp dụng chung cho mọi bảng DynamoDB" — sai. WCU/RCU cấp phát theo TỪNG bảng (và từng GSI), không chia sẻ giữa các bảng.

Ghi nhớ

Nguyên tắc chọn partition key: | Tốt | Xấu | |---|---| | Nhiều giá trị khác nhau (user_id, order_id, UUID) | Ít giá trị (status, country, type) | | Truy cập trải đều | dồn vào vài khoá |

Ba cách xử lý hot partition:

1. Thiết kế lại partition key — cách đúng nhất
2. Rải khoá bằng hậu tố — chia một khoá nóng thành N khoá
3. Chuyển sang on-demand mode — DynamoDB tự co giãn, nhưng vẫn không cứu được lệch cực đoan

Nhớ công thức: throughput mỗi partition = tổng throughput ÷ số partition.

Đáp án

B và C.

• C — Bucket policy và IAM policy
• B — Query String Authentication và Access Control List (ACL)

Vì sao đúng

S3 có bốn cơ chế kiểm soát truy cập, và hai phương án đúng liệt kê đủ cả bốn:

Query String Authentication là tên chính thức của cơ chế đứng sau pre-signed URL — thông tin xác thực và chữ ký được đưa vào query string thay vì header:

https://bucket.s3.amazonaws.com/tep.pdf
  ?X-Amz-Algorithm=AWS4-HMAC-SHA256
  &X-Amz-Credential=...
  &X-Amz-Expires=3600
  &X-Amz-Signature=...

Nó cho phép cấp quyền truy cập tạm thời vào một object cụ thể mà không cần mở bucket ra công khai — nên hoàn toàn là một cơ chế kiểm soát truy cập hợp lệ.

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

• A và E. Permissions boundary — đây là điểm loại. Permissions boundary KHÔNG cấp quyền; nó là trần quyền tối đa cho một IAM user hoặc role. Nó chỉ giới hạn, và bản thân nó không phải cơ chế kiểm soát truy cập S3 — nó áp cho danh tính, không cho tài nguyên.
• D. IAM database authentication — cơ chế đăng nhập CSDL RDS bằng token IAM. Hoàn toàn không liên quan tới S3.

Ghi nhớ

Ba cơ chế chỉ giới hạn, không bao giờ cấp quyền — nhớ để không nhầm với cơ chế cấp quyền: | Cơ chế | Vai trò | |---|---| | SCP (Organizations) | trần quyền cho cả tài khoản | | Permissions boundary | trần quyền cho một user/role | | Session policy | thu hẹp quyền của một phiên STS |

Và khuyến nghị hiện hành của AWS cho S3:

• Dùng bucket policy và IAM policy làm cơ chế chính
• Vô hiệu hoá ACL bằng Object Ownership = Bucket owner enforced
• Bật Block Public Access cả bốn tuỳ chọn
• Dùng pre-signed URL cho truy cập tạm thời theo từng lần

Đáp án

C — Server-Side Encryption với CMK lưu trong AWS KMS (SSE-KMS).

Vì sao đúng

Đề nêu hai yêu cầu, và chúng kết hợp lại chỉ về đúng một lựa chọn: giải pháp do AWS quản lý, nhưng cho phép toàn quyền tạo, xoay vòng và xoá khoá.

SSE-KMS với customer-managed key là điểm cân bằng đó:

Đặc biệt với dịch vụ tài chính, hai điểm cuối rất quan trọng: mọi lần giải mã đều có vết trong CloudTrail (biết ai đọc dữ liệu nào, lúc nào), và key policy tách biệt với quyền S3 — nên người có quyền đọc bucket vẫn không đọc được nếu không có quyền dùng khoá.

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

• B. SSE-S3 — đây là bẫy chính. Nó do AWS quản lý và mã hoá tốt, nhưng bạn không có quyền kiểm soát nào: không tạo được khoá, không xoay vòng theo ý mình, không xoá được, và không có vết CloudTrail cho từng lần dùng khoá. Trái thẳng yêu cầu "full control".
• D. SSE-C (Customer-Provided Keys) — cho toàn quyền nhất, nhưng bạn phải tự quản lý khoá hoàn toàn: tự sinh, tự lưu, tự xoay vòng, và gửi khoá kèm mỗi request. AWS không lưu khoá, nên mất khoá là mất dữ liệu vĩnh viễn. Trái yêu cầu "AWS managed solution".
• A. "Server-Side Encryption với Secrets Manager" — không tồn tại. S3 chỉ hỗ trợ SSE-S3, SSE-KMS và SSE-C. Secrets Manager lưu bí mật ứng dụng, không phải cơ chế mã hoá của S3.

Ghi nhớ

Nhận dạng nhanh: đề nói "AWS managed" + "full control over keys" ⇒ SSE-KMS. Nói "đơn giản nhất, không cần quản lý gì" ⇒ SSE-S3.

Đáp án

C — Dùng AWS KMS với automatic key rotation.

Vì sao đúng

Yêu cầu: mã hoá dữ liệu lúc lưu trong S3, khoá xoay vòng ít nhất mỗi năm, và cách dễ nhất.

KMS có tính năng automatic key rotation làm đúng việc đó bằng một lời gọi:

aws kms enable-key-rotation --key-id <key-id>

Cách nó hoạt động — và đây là phần khiến nó "dễ nhất":

• KMS tự sinh key material mới mỗi năm
• Giữ lại toàn bộ key material cũ, nên dữ liệu mã hoá trước đó vẫn giải mã được bình thường
• Key ID và ARN không đổi, nên không phải sửa một dòng cấu hình nào — bucket policy, ứng dụng, IAM policy đều giữ nguyên
• Hoàn toàn trong suốt với ứng dụng

Đây là điểm mấu chốt: xoay vòng khoá thường là việc đau đớn vì phải mã hoá lại dữ liệu cũ. KMS bỏ hẳn vấn đề đó bằng cách giữ lại các phiên bản key material.

(Ghi chú: từ 2024, KMS còn cho phép tuỳ chỉnh chu kỳ xoay vòng từ 90 ngày tới 2.560 ngày, thay vì cố định một năm.)

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

• A. Import khoá tuỳ chỉnh vào KMS rồi tự động xoay vòng bằng Lambda — imported key material KHÔNG hỗ trợ automatic rotation; bạn phải tự import khoá mới và tự quản lý phiên bản. Đây là cách nhiều công sức nhất trong bốn phương án.
• B. "SSE-C với automatic key rotation" — SSE-C không có xoay vòng tự động. Với SSE-C, bạn tự sinh và tự gửi khoá kèm mỗi request; AWS không lưu khoá nên không thể xoay vòng giúp bạn. Xoay vòng nghĩa là tự mã hoá lại toàn bộ dữ liệu.
• D. Mã hoá dữ liệu trước khi gửi lên S3 (client-side encryption) — làm được, nhưng bạn phải tự quản lý toàn bộ vòng đời khoá: sinh, lưu, phân phối, xoay vòng, và mã hoá lại dữ liệu cũ. Trái hẳn "easiest way".

Ghi nhớ

Bảng xoay vòng khoá theo loại: | Loại khoá | Xoay vòng tự động | |---|---| | AWS managed key (aws/s3) | ✅ bắt buộc, mỗi năm | | Customer managed key (CMK) | ✅ bật được | | CMK với imported key material | ❌ phải tự làm | | SSE-C | ❌ |

Và nhớ đặc tính quan trọng nhất: xoay vòng KHÔNG mã hoá lại dữ liệu cũ. KMS giữ mọi phiên bản key material, nên object cũ vẫn giải mã được bằng phiên bản khoá đã dùng để mã hoá chúng. Không có downtime, không có việc phải làm.

Đáp án

B — Tạo CloudWatch custom metric và dựng alarm để scale Auto Scaling group.

Vì sao đúng

Yêu cầu: mở rộng ASG theo số request mỗi phút tới các CSDL MySQL tự quản trên EC2.

Vấn đề: CloudWatch không có metric nào đo được điều đó. Số request tới một MySQL tự cài là thông tin chỉ ứng dụng biết — AWS không có cách nào nhìn thấy nó.

Nên phải tự đo và tự đẩy:

# Chạy định kỳ trên instance ứng dụng
cloudwatch.put_metric_data(
    Namespace='UngDung/CSDL',
    MetricData=[{
        'MetricName': 'RequestPerMinute',
        'Dimensions': [{'Name': 'AutoScalingGroupName', 'Value': 'nhom-app'}],
        'Value': so_request_phut_qua,
        'Unit': 'Count'
    }])

Rồi dùng metric đó cho scaling policy:

aws autoscaling put-scaling-policy --auto-scaling-group-name nhom-app \
  --policy-name theo-request --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "CustomizedMetricSpecification": {
      "MetricName": "RequestPerMinute", "Namespace": "UngDung/CSDL",
      "Statistic": "Average"},
    "TargetValue": 1000.0}'

Lưu ý quan trọng về metric dùng cho target tracking: giá trị phải tỷ lệ nghịch với số instance. Nên nên đẩy số request TRUNG BÌNH MỖI INSTANCE, không phải tổng — nếu đẩy tổng, chính sách sẽ không bao giờ hội tụ.

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

• A. Bật detailed monitoring — chỉ đổi chu kỳ metric EC2 từ 5 phút xuống 1 phút. Nó không thêm metric mới nào, và chắc chắn không biết gì về số request tới MySQL.
• D. Gắn Elastic Load Balancer — đây là phương án đáng cân nhắc nhất và cần phân biệt kỹ. ALB có phát metric RequestCountPerTarget, dùng làm predefined metric cho target tracking rất tốt. Nhưng nó chỉ đếm request đi qua load balancer — trong khi đề nói các EC2 ứng dụng gọi thẳng tới CSDL, không qua ELB. Thêm ELB vào chỉ để lấy metric là thay đổi kiến trúc lớn cho một vấn đề đo lường.
• C. Gắn thêm Elastic File Storage — EFS là lưu trữ tệp chia sẻ. Không liên quan gì tới việc đo lường hay mở rộng.

Ghi nhớ

Metric dựng sẵn cho target tracking của EC2 Auto Scaling — danh sách rất ngắn: | Metric | |---| | ASGAverageCPUUtilization | | ASGAverageNetworkIn / ASGAverageNetworkOut | | ALBRequestCountPerTarget |

Mọi thứ khác — bộ nhớ, độ sâu hàng đợi, số request tới backend tự quản — đều phải là custom metric.

Và nhớ ba metric không có sẵn trên EC2: bộ nhớ, dung lượng đĩa còn trống, swap — luôn cần CloudWatch Agent.

Đáp án

C và E.

• E — Lưu bí mật dưới dạng SecureString trong SSM Parameter Store.
• C — Kiểm toán bằng CloudTrail.

Vì sao đúng

Đề nêu ba yêu cầu: bí mật được mã hoá, sự kiện giải mã phải kiểm toán được, và lời gọi API phải đơn giản.

E — SecureString. Đây là cách gọn nhất: Parameter Store tự mã hoá bằng KMS khi lưu và tự giải mã khi đọc, chỉ với một tham số:

# Lưu
aws ssm put-parameter --name /ung-dung/db-password \
  --value "mat-khau-that" --type SecureString --key-id alias/khoa-cua-toi

# Đọc — MỘT lời gọi, tự giải mã
aws ssm get-parameter --name /ung-dung/db-password --with-decryption

Đây chính là vế "API calls to be simple": một lời gọi thay vì hai (lấy ciphertext rồi gọi KMS giải mã).

C — CloudTrail. Mọi lời gọi kms:Decrypt và ssm:GetParameter đều được ghi lại kèm ai gọi, lúc nào, từ IP nào:

{"eventSource": "kms.amazonaws.com", "eventName": "Decrypt",
 "userIdentity": {"type": "AssumedRole", "arn": "...:role/ec2-app-role"},
 "requestParameters": {"encryptionContext": {"PARAMETER_ARN": "..."}}}

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

• A. Lưu bí mật dưới dạng PlainText — không mã hoá gì cả, vi phạm thẳng yêu cầu đầu tiên. Giá trị hiện nguyên văn với bất kỳ ai có quyền ssm:GetParameter.
• B. Mã hoá bằng KMS trước rồi mới lưu vào Parameter Store — hoạt động được, nhưng phức tạp hơn: bạn phải tự gọi kms:Encrypt khi lưu và kms:Decrypt khi đọc, tự quản lý ciphertext. Đó là hai lời gọi API thay vì một — trái yêu cầu "API calls to be simple". SecureString làm đúng việc đó một cách tự động.
• D. "SSM Audit Trail" — không tồn tại. SSM không có dịch vụ kiểm toán riêng; mọi lời gọi API của nó được ghi bởi CloudTrail, giống mọi dịch vụ AWS khác.

Ghi nhớ

Và nhớ hai chi tiết vận hành:

• Đọc SecureString bắt buộc phải có --with-decryption, nếu không bạn nhận về ciphertext
• Cần cả hai quyền: ssm:GetParameter và kms:Decrypt trên khoá tương ứng — thiếu quyền KMS là lỗi hay gặp nhất

So với Secrets Manager: Parameter Store SecureString miễn phí nhưng không xoay vòng tự động và không có resource-based policy.

Đáp án

D — Dùng pseudo parameter AWS::Region.

Vì sao đúng

Pseudo parameter là các biến CloudFormation tự cung cấp, không cần khai trong section Parameters và không cần ai nhập gì:

Outputs:
  RegionHienTai:
    Value: !Ref "AWS::Region"

Resources:
  KhoDuLieu:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "du-lieu-${AWS::AccountId}-${AWS::Region}"

Giá trị được phân giải tại thời điểm deploy, nên cùng một template chạy ở Region nào cũng tự đúng — không có bước thủ công nào, không có gì để quên. Đó chính là "MOST operationally efficient".

Pseudo parameter cũng rất hay dùng để dựng ARN mà không ghi cứng:

Value: !Sub "arn:${AWS::Partition}:s3:::${AWS::AccountId}-log-${AWS::Region}"

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

• B. Tạo parameter cho Region rồi để người deploy nhập — thủ công và dễ sai: người deploy phải nhớ nhập đúng Region, và nhập nhầm thì template tạo tài nguyên với tên hoặc cấu hình sai mà không có gì cảnh báo. Thừa hoàn toàn khi CloudFormation đã biết sẵn.
• C. Dựng Mappings liệt kê mọi Region — cực kỳ nhiều công sức: phải liệt kê hơn 30 Region và cập nhật mỗi khi AWS mở Region mới. Và nó vẫn cần một khoá để tra cứu — mà khoá đó lại chính là AWS::Region.
• A. Lambda-backed custom resource — dùng một hàm Lambda chỉ để trả về một giá trị CloudFormation đã có sẵn. Thêm hàm phải viết, phải cấp quyền, phải bảo trì, cộng thêm rủi ro stack treo nếu hàm quên gửi phản hồi. Nhiều công sức nhất trong bốn phương án.

Ghi nhớ

Toàn bộ pseudo parameter của CloudFormation — danh sách ngắn, nên thuộc: | Pseudo parameter | Giá trị | |---|---| | AWS::Region | Region đang deploy | | AWS::AccountId | ID tài khoản 12 chữ số | | AWS::StackName | tên stack | | AWS::StackId | ARN đầy đủ của stack | | AWS::Partition | aws, aws-cn, aws-us-gov | | AWS::URLSuffix | amazonaws.com, amazonaws.com.cn | | AWS::NoValue | xoá hẳn thuộc tính khỏi tài nguyên | | AWS::NotificationARNs | danh sách SNS topic của stack |

Dùng AWS::Partition và AWS::URLSuffix khi viết template cần chạy được ở cả Region Trung Quốc hoặc GovCloud — ghi cứng aws và amazonaws.com sẽ hỏng ở đó.