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

Đáp án theo nguồn

B — Dùng tính năng on-demand backup của DynamoDB để ghi ra Amazon S3 rồi tải về — đây là phương án KHÔNG khả thi.

Vì sao đúng

Câu hỏi tìm phương án không làm được, và điểm mấu chốt nằm ở cách on-demand backup hoạt động:

DynamoDB on-demand backup lưu bản sao lưu BÊN TRONG chính dịch vụ DynamoDB. Nó:

• Không ghi ra bucket S3 nào mà bạn truy cập được
• Không tải xuống được
• Chỉ dùng để khôi phục lại thành một bảng DynamoDB mới (RestoreTableFromBackup)

Bạn thấy được danh sách backup trong console và trả tiền lưu trữ, nhưng không có object nào để aws s3 cp về máy. Đó là lý do phương án B không khả thi cho yêu cầu "download the S3 backup locally".

Vì sao các phương án khác khả thi

• A. Hive trên Amazon EMR — cách cổ điển: dựng cụm EMR, dùng EXTERNAL TABLE với DynamoDBStorageHandler để đọc bảng rồi ghi ra S3. Nặng nề nhưng làm được.
• C. AWS Glue — Glue có connector cho DynamoDB; job đọc bảng và ghi ra S3 dưới dạng Parquet, JSON hoặc CSV. Serverless, không cần dựng cụm.
• D. AWS Data Pipeline — có sẵn template "Export DynamoDB table to S3", và ghi được sang bucket ở tài khoản bạn chọn. Đây từng là cách được khuyến nghị chính thức.

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

Câu này đã lỗi thời một phần. Từ cuối 2020, DynamoDB có tính năng riêng tên Export to S3 — hoàn toàn khác với on-demand backup:

aws dynamodb export-table-to-point-in-time \
  --table-arn arn:aws:dynamodb:...:table/xet-nghiem \
  --s3-bucket kho-backup --export-format DYNAMODB_JSON

Nên ngày nay câu trả lời đúng cho yêu cầu trong đề là Export to S3 — gọn hơn hẳn EMR, Glue hay Data Pipeline. Phương án B vẫn "không khả thi" đúng như khoá đáp án, nhưng chỉ vì nó nói on-demand backup; nếu đề viết "DynamoDB export to S3" thì nó lại thành phương án tốt nhất. Hãy phân biệt hai tính năng có tên rất giống nhau này.

(Ghi chú thêm: AWS Data Pipeline cũng đã ngừng nhận khách hàng mới.)

Đáp án

C — 200 GiB với 15.000 IOPS là cấu hình KHÔNG hợp lệ.

Vì sao đúng

EBS loại io1 có một ràng buộc cứng về tỷ lệ giữa IOPS và dung lượng:

io1: tối đa 50 IOPS cho mỗi GiB dung lượng.

Áp vào đề:

Dung lượng : 200 GiB
IOPS tối đa: 200 × 50 = 10.000 IOPS

Kiểm từng phương án: | Cấu hình | Tỷ lệ IOPS/GiB | Hợp lệ? | |---|---|---| | D. 200 GiB, 2.000 IOPS | 10:1 | ✅ | | A. 200 GiB, 5.000 IOPS | 25:1 | ✅ | | B. 200 GiB, 10.000 IOPS | 50:1 — đúng giới hạn | ✅ | | C. 200 GiB, 15.000 IOPS | 75:1 — VƯỢT | ❌ |

Muốn đạt 15.000 IOPS trên io1 thì volume phải có ít nhất 300 GiB (15.000 ÷ 50).

Lý do tồn tại ràng buộc này: IOPS cần phần cứng lưu trữ tương ứng để phục vụ, nên AWS ràng buộc chúng đi cùng nhau.

Vì sao các phương án khác sai (tức là chúng đều hợp lệ)

Ba phương án còn lại đều nằm trong hoặc đúng bằng tỷ lệ 50:1, nên đều tạo được.

Ghi nhớ

Bảng giới hạn của các loại EBS — rất hay bị hỏi: | Loại | IOPS tối đa | Tỷ lệ IOPS/GiB | Dung lượng | |---|---|---|---| | io1 | 64.000 | 50:1 | 4 GiB – 16 TiB | | io2 | 64.000 (256.000 với Block Express) | 500:1 | 4 GiB – 16 TiB | | gp2 | 16.000 | 3:1 (cơ sở), burst 3.000 | 1 GiB – 16 TiB | | gp3 | 16.000 | 500:1 — 3.000 IOPS miễn phí | 1 GiB – 16 TiB |

Hai điểm đáng nhớ ngoài con số: io2 có tỷ lệ 500:1, gấp mười lần io1 với cùng giá — nên io2 gần như luôn tốt hơn io1. Và gp3 tách rời IOPS khỏi dung lượng, cho 3.000 IOPS ngay cả với volume nhỏ nhất — khác hẳn gp2 vốn buộc phải mua dung lượng lớn chỉ để có IOPS.

Đáp án

D — Dùng Application Auto Scaling để quản lý provisioned concurrency của Lambda theo lịch.

Vì sao đúng

Đề nêu ba yếu tố, và cả ba cùng chỉ về một giải pháp:

• Lo ngại latency bottleneck ⇒ vấn đề là cold start
• Đợt bán hàng Thanksgiving ⇒ thời điểm biết trước
• Cần chuẩn bị trước, không phản ứng sau

Provisioned concurrency là cơ chế duy nhất của Lambda loại bỏ cold start: AWS khởi tạo sẵn số môi trường thực thi bạn yêu cầu, chạy xong phần init (nạp runtime, mã ngoài handler, mở kết nối), rồi giữ chúng ấm.

Ghép với scheduled scaling thì năng lực có mặt trước khi traffic tới, và tự thu lại sau:

aws application-autoscaling put-scheduled-action \
  --service-namespace lambda \
  --resource-id function:xu-ly-don:prod \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --scheduled-action-name tang-truoc-black-friday \
  --schedule "cron(0 20 24 11 ? 2026)" \
  --scalable-target-action MinCapacity=200,MaxCapacity=1000

Đây là điểm mạnh so với mọi cách phản ứng: với tải đã biết trước theo lịch, chuẩn bị luôn tốt hơn phản ứng.

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

• A. Reserved concurrency theo lịch — đây là bẫy trung tâm. Reserved concurrency chỉ ĐẶT TRẦN số lần chạy đồng thời; nó không giữ môi trường nào ấm và không giúp gì cho cold start. Ngoài ra Application Auto Scaling không nhận reserved concurrency làm scalable target.
• B. "Không cần làm gì vì Lambda tự co giãn" — nửa đúng nhưng bỏ qua vấn đề thật. Lambda có tự co giãn, nhưng mỗi môi trường mới đều phải qua cold start (từ vài trăm mili giây tới vài giây, tuỳ runtime và kích thước gói). Với spike lớn, hàng loạt cold start xảy ra cùng lúc — chính là "latency bottleneck" mà đề lo. Lambda còn có burst concurrency limit, nên vượt qua đó là bị throttle.
• C. Đặt ALB trước Lambda — ALB có nhận Lambda làm target, nhưng nó chỉ định tuyến. Nó không giảm cold start và không tăng năng lực đồng thời.

Ghi nhớ

Câu thần chú: thấy "cold start" ⇒ provisioned concurrency; thấy "giới hạn/bảo vệ downstream" ⇒ reserved concurrency. Hai tên rất giống nhau, tác dụng hoàn toàn khác.

Đáp án

A — Dùng lệnh sam sync của AWS SAM để triển khai các thay đổi tăng dần.

Vì sao đúng

Yêu cầu: triển khai thay đổi nhỏ để kiểm thử mà không phải deploy lại toàn bộ ứng dụng ở mỗi lần commit, với thời gian triển khai tối thiểu.

sam sync sinh ra đúng cho vòng lặp phát triển nhanh:

sam sync --stack-name ung-dung --watch

Điểm khác biệt cốt lõi với sam deploy:

sam sync đủ thông minh để phân biệt: đổi mã hàm thì gọi thẳng Lambda API (vài giây); đổi hạ tầng trong template thì mới rơi về CloudFormation.

Còn có sam sync --code để chỉ đồng bộ mã, bỏ qua hoàn toàn phần hạ tầng — nhanh nhất có thể.

Cảnh báo quan trọng: sam sync chỉ dùng cho môi trường phát triển. Vì nó đi tắt qua CloudFormation, stack sẽ drift so với template. AWS ghi rõ điều này và khuyến nghị dùng sam deploy cho production.

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

• C. sam deploy — cách chuẩn và đúng cho production, nhưng chậm: mỗi lần đều tạo changeset, chờ CloudFormation xử lý toàn bộ stack. Trái tiêu chí "minimizing deployment time" và "without deploying the entire application".
• B. cdk diff — chỉ so sánh template hiện tại với stack đang chạy và in ra khác biệt. Nó không triển khai gì cả. Sai chức năng hoàn toàn.
• D. cdk deploy — triển khai được, nhưng cũng đi qua CloudFormation đầy đủ như sam deploy, nên không nhanh hơn. (CDK có cdk watch với hot-swap — tương đương sam sync --watch — nhưng đó không phải phương án được nêu.)

Ghi nhớ

Vòng lặp phát triển serverless nhanh: | Lệnh | Dùng khi | |---|---| | sam local invoke / sam local start-api | kiểm thử ngay trên máy, không cần AWS | | sam sync --watch | phát triển trên AWS, đồng bộ liên tục | | sam deploy | production — qua CloudFormation, có changeset |

Nguyên tắc: sync cho vòng lặp phát triển, deploy cho môi trường thật. Đừng bao giờ đảo ngược.

Đáp án

D — Chia sẻ pre-signed URL với những người cần truy cập.

Vì sao đúng

Hai yêu cầu: bucket phải riêng tư, và truy cập object phải có ràng buộc thời gian.

Pre-signed URL đáp ứng cả hai một cách gọn gàng nhất:

url = s3.generate_presigned_url(
    'get_object',
    Params={'Bucket': 'du-lieu-rieng', 'Key': 'bao-cao.pdf'},
    ExpiresIn=3600)          # hết hạn sau 1 giờ

Cách nó hoạt động: URL mang chữ ký được tạo từ thông tin xác thực của người sinh ra nó, cộng với thời điểm hết hạn nằm ngay trong chữ ký. S3 xác minh chữ ký, kiểm hạn, rồi mới cho tải.

Thời hạn tối đa: 7 ngày với SigV4, và ngắn hơn nếu dùng thông tin xác thực tạm thời từ IAM role (URL hết hiệu lực khi phiên đó hết hạn).

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

• C. Dùng bucket policy để chặn truy cập ngoài ý muốn — bucket policy kiểm soát được ai truy cập, và có thể đặt điều kiện aws:CurrentTime. Nhưng nó là chính sách tĩnh ở mức bucket: mỗi lần muốn cho một người truy cập trong một khoảng thời gian là phải sửa policy, rồi nhớ gỡ ra. Không mở rộng được, và rất dễ quên. Pre-signed URL là công cụ đúng tầm cho việc cấp quyền tạm thời theo từng lần.
• B. "Dùng routing policy để chuyển hướng truy cập ngoài ý muốn" — routing policy là khái niệm của Route 53 (DNS). Nó không kiểm soát quyền truy cập object trong S3 chút nào.
• A. "Không thể áp đặt ràng buộc thời gian lên truy cập S3" — sai dứt khoát: pre-signed URL chính là cơ chế đó, và nó là một trong những tính năng được dùng nhiều nhất của S3.

Ghi nhớ

Các cơ chế kiểm soát truy cập S3, theo phạm vi: | Cơ chế | Phạm vi | Thời hạn | |---|---|---| | Pre-signed URL | một object, một người | có, tối đa 7 ngày | | Bucket policy | cả bucket hoặc prefix | tĩnh | | IAM policy | theo danh tính | tĩnh | | CloudFront signed URL/cookie | qua CDN | có, kèm giới hạn IP | | Block Public Access | chặn cứng mọi cấu hình public | — |

Khác biệt đáng nhớ giữa hai loại signed URL: S3 pre-signed URL dùng thông tin xác thực IAM và tối đa 7 ngày; CloudFront signed URL dùng cặp khoá riêng, không giới hạn thời hạn, và đặt được ràng buộc dải IP.

Đáp án

C — 5,3 TiB.

Vì sao đúng

Volume gp2 có hai đặc tính quyết định:

Phép tính rất thẳng:

16.000 IOPS ÷ 3 IOPS/GiB = 5.334 GiB
5.334 GiB ÷ 1.024 ≈ 5,2 TiB  →  làm tròn: 5,3 TiB

Từ mốc đó trở lên, tăng dung lượng không tăng thêm IOPS nữa — volume 16 TiB cũng chỉ đạt 16.000 IOPS như volume 5,3 TiB, trong khi đắt hơn ba lần cho phần dung lượng thừa.

Một chi tiết liên quan đáng nhớ: volume gp2 từ 1 TiB trở lên không còn dùng cơ chế burst credit nữa (vì IOPS cơ sở đã là 3.000, bằng mức burst tối đa). Dưới 1 TiB thì vẫn tích luỹ và tiêu credit.

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

• B. 2,7 TiB — cho 2.700 × 1.024 × 3 ≈ 8.294 IOPS, chưa chạm trần.
• D. 10,6 TiB và A. 16 TiB — đều vượt qua điểm bão hoà. IOPS vẫn dừng ở 16.000, nên đây là lãng phí tiền dung lượng mà không được thêm hiệu năng nào.

Ghi nhớ

So sánh gp2 và gp3 — và lý do gp3 gần như luôn tốt hơn: | | gp2 | gp3 | |---|---|---| | IOPS | 3 IOPS/GiB, trần 16.000 | 3.000 miễn phí, mua thêm tới 16.000 | | Thông lượng | tăng theo dung lượng, trần 250 MB/s | 125 MB/s miễn phí, tới 1.000 MB/s | | IOPS tách rời dung lượng | ❌ | ✅ | | Giá lưu trữ | — | rẻ hơn ~20% |

Hệ quả thực tế: với gp2, muốn có 3.000 IOPS bạn phải mua 1 TiB dù chỉ cần 100 GiB dữ liệu. Với gp3, volume 100 GiB đã có sẵn 3.000 IOPS. Đây là lý do AWS khuyến nghị chuyển gp2 sang gp3 — thao tác thực hiện được ngay trên volume đang chạy, không cần dừng.

Đáp án

D — Deploy lại API vào một stage đang có hoặc vào một stage mới.

Vì sao đúng

Đây là đặc điểm cơ bản nhất của API Gateway, và cũng là chỗ vấp đầu tiên của mọi người mới dùng:

Thay đổi cấu hình API không tự động có hiệu lực. Chúng chỉ được áp dụng khi bạn tạo một deployment.

Cần phân biệt hai khái niệm:

Nên luồng đúng là: sửa API → tạo deployment → gán deployment đó cho stage.

aws apigateway create-deployment --rest-api-id abc123 --stage-name dev \
  --description "them endpoint /don-hang"

Đây thực ra là một tính năng, không phải phiền toái: nó cho phép nhiều người sửa API cùng lúc mà không ảnh hưởng gì tới môi trường đang chạy, và cho phép rollback tức thì bằng cách trỏ stage về deployment cũ.

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

• A. "Cần quyền IAM trên thành phần API execution" — thiếu quyền thì lời gọi API trả 403 Forbidden, một lỗi rõ ràng. Triệu chứng trong đề khác hẳn: API hoạt động bình thường, chỉ là trả về hành vi cũ.
• B. Dùng stage variable — stage variable là cặp khoá–giá trị cấu hình theo từng stage (trỏ tới alias Lambda khác nhau, endpoint khác nhau). Nó không làm thay đổi API có hiệu lực; đổi stage variable cũng vẫn cần deploy lại.
• C. Bật Lambda authorizer — cơ chế uỷ quyền, quyết định ai được gọi API. Hoàn toàn không liên quan tới việc thay đổi có được áp dụng hay không.

Ghi nhớ

Ba khái niệm của API Gateway, theo thứ tự:

API definition (bản nháp)  →  Deployment (ảnh chụp)  →  Stage (con trỏ)
   sửa thoải mái              tạo khi muốn áp dụng      dev / test / prod

Vài mẹo thực dụng:

• Trong CI/CD, luôn có bước tạo deployment sau khi cập nhật API
• Với CloudFormation/SAM, dùng AWS::ApiGateway::Deployment và nhớ đổi tên logic hoặc thêm Description động — nếu không CloudFormation coi là không có thay đổi và bỏ qua
• Rollback = trỏ stage về deploymentId cũ, có hiệu lực tức thì

Đáp án

D — Dùng Cognito Identity Pools để cho phép người dùng đã được bên thứ ba xác thực truy cập DynamoDB.

Vì sao đúng

Đọc kỹ đề: người dùng đã được bên thứ ba xác thực (trusted third-party authenticated users), và họ cần truy cập trực tiếp DynamoDB. Nghĩa là vấn đề không phải xác thực — mà là cấp quyền AWS cho một danh tính đã có.

Đó chính xác là việc của identity pool: nhận một danh tính đã được xác thực ở nơi khác, rồi đổi lấy thông tin xác thực AWS tạm thời qua STS.

Người dùng nhà cung cấp → IdP của họ → token
                        → Cognito Identity Pool
                        → STS AssumeRoleWithWebIdentity
                        → access key tạm thời → DynamoDB

Identity pool nhận nhiều loại nguồn: SAML, OIDC, developer-authenticated identities, Google, Facebook, Apple, và cả Cognito user pool.

Điểm mạnh về bảo mật, và cũng là lý do nó thắng các phương án IAM: thông tin xác thực tạm thời, tự hết hạn, và có thể thu hẹp quyền tới từng người bằng policy variable:

{
  "Effect": "Allow",
  "Action": ["dynamodb:PutItem", "dynamodb:UpdateItem"],
  "Resource": "arn:aws:dynamodb:*:*:table/DonHang",
  "Condition": {
    "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
    }
  }
}

Điều kiện dynamodb:LeadingKeys giới hạn mỗi người chỉ đụng được vào những item có partition key bằng chính ID của họ.

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

• A. Cognito User Pools — là thư mục người dùng (đăng ký, đăng nhập, phát JWT). Nhưng người dùng ở đây đã được xác thực bởi bên thứ ba rồi — không cần thư mục nữa. Và user pool không cấp quyền AWS; nó chỉ phát JWT.
• C. Tạo IAM user cho từng người dùng bên thứ ba — không mở rộng được và không an toàn: giới hạn cứng 5.000 IAM user mỗi tài khoản, phải quản lý vòng đời (tạo, khoá, xoá) cho người không thuộc tổ chức mình, và mỗi người có access key dài hạn không tự hết hạn.
• B. Tạo IAM group cho từng người dùng — sai khái niệm: group không phải danh tính, không đăng nhập được và không có thông tin xác thực. Group chỉ là cách gom user để gắn policy chung.

Ghi nhớ

Nguyên tắc lớn hơn: đừng bao giờ tạo IAM user cho người dùng cuối. IAM user dành cho nhân sự vận hành và hệ thống; người dùng ứng dụng luôn đi qua liên kết danh tính (Cognito, SAML, OIDC).

Đáp án

C — Dùng kỹ thuật exponential backoff để giãn dần thời gian trước mỗi lần thử lại.

Vì sao đúng

Lỗi Throttling – Maximum sending rate exceeded nghĩa là đang gửi nhanh hơn hạn mức gửi mỗi giây của tài khoản SES. Nó mang tính tạm thời — không có gì hỏng, chỉ là gửi quá nhanh trong khoảnh khắc đó.

Exponential backoff là cách xử lý chuẩn cho mọi lỗi throttling trên AWS: thử lại với khoảng chờ tăng theo cấp số nhân, cộng thêm một chút ngẫu nhiên (jitter) để nhiều client không cùng thử lại một lúc:

for lan in range(5):
    try:
        ses.send_email(...)
        break
    except ClientError as e:
        if e.response['Error']['Code'] == 'Throttling':
            cho = (2 ** lan) + random.uniform(0, 1)   # 1s, 2s, 4s, 8s, 16s + jitter
            time.sleep(cho)
        else:
            raise

Vì sao jitter quan trọng: không có nó, hàng loạt client bị throttle cùng lúc sẽ cùng thử lại sau đúng 2 giây, tạo ra một đợt dội mới và lại bị throttle — hiện tượng gọi là thundering herd.

AWS SDK đã bật sẵn cơ chế này (chế độ adaptive hoặc standard), nhưng với gửi email hàng loạt thường nên tự kiểm soát tốc độ ở tầng ứng dụng để không chạm trần ngay từ đầu.

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

• D. Xin AWS nâng hạn mức throttling — đây là phương án hợp lý trong thực tế và nên làm song song, nhưng nó không phải cách sửa lỗi ngay: yêu cầu nâng hạn mức mất thời gian xét duyệt, và dù hạn mức bao nhiêu thì vẫn có trần — nên retry với backoff vẫn là điều bắt buộc phải có trong mã.
• B. "Retry cho mọi lỗi 4xx" — sai và nguy hiểm. Lỗi 4xx phần lớn là lỗi của client và thử lại sẽ luôn thất bại y hệt: địa chỉ email sai định dạng, thiếu quyền, chưa xác minh tên miền. Chỉ nên retry các lỗi có thể phục hồi: Throttling, ServiceUnavailable, RequestTimeout và các lỗi 5xx.
• A. Cấu hình timeout cho mỗi request — timeout xử lý trường hợp không nhận được phản hồi. Ở đây SES có phản hồi, và phản hồi đó nói rõ là bị throttle. Timeout không liên quan.

Ghi nhớ

Hai hạn mức chính của SES, đừng nhầm: | Hạn mức | Nghĩa | |---|---| | Sending rate | số email mỗi giây — vượt thì Throttling | | Sending quota | số email mỗi 24 giờ — vượt thì Daily message quota exceeded |

Và bảng phân loại lỗi để retry cho đúng: | Loại | Có nên retry? | |---|---| | Throttling, TooManyRequests, 5xx | ✅ có, với exponential backoff | | AccessDenied, ValidationError, MessageRejected | ❌ không — sửa mã hoặc cấu hình |

Đáp án

D — Auto Scaling group sẽ huỷ (terminate) instance đó.

Vì sao đúng

Auto Scaling có một mô hình xử lý rất đơn giản và dứt khoát:

Instance bị đánh dấu Unhealthy thì bị huỷ, rồi một instance mới được tạo thay thế.

Quy trình đầy đủ:

1. Health check phát hiện instance không lành
2. ASG đánh dấu Unhealthy
3. ASG HUỶ instance đó
4. ASG tạo instance MỚI từ launch template để giữ desired capacity = 10

Với các con số trong đề (min 5, max 20, desired 10), sau khi huỷ thì còn 9 — thấp hơn desired, nên ASG tạo ngay một máy mới để về lại 10.

Vì sao huỷ chứ không sửa. Đây là triết lý hạ tầng bất biến (immutable infrastructure): instance được coi là thay thế được, không phải sửa chữa được. Máy mới dựng từ AMI chuẩn nên chắc chắn ở trạng thái tốt đã biết; còn sửa một máy hỏng thì không bao giờ chắc đã sạch hoàn toàn.

Nếu cần giữ lại instance hỏng để gỡ lỗi, có hai cách: đặt lifecycle hook cho hành động terminate (instance dừng ở Terminating:Wait), hoặc chuyển nó sang trạng thái Standby trước.

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

• A. "Gỡ instance khỏi nhóm và để nó tiếp tục chạy" — đây là hành vi của lệnh detach-instances với --no-should-decrement-desired-capacity, một thao tác thủ công. ASG không tự làm điều này khi phát hiện instance không lành.
• B. "Giữ instance chạy và khởi động lại ứng dụng" — ASG không biết gì về ứng dụng bên trong và không có cơ chế chạy lệnh trên instance. Muốn khởi động lại một tiến trình thì phải dùng SSM Run Command, không phải Auto Scaling.
• C. "Format ổ EBS gốc rồi chạy lại User Data" — không có thao tác nào như vậy. ASG huỷ hẳn instance, kể cả EBS volume gốc (nếu DeleteOnTermination = true), rồi tạo máy hoàn toàn mới.

Ghi nhớ

Hai loại health check của Auto Scaling — chi tiết quan trọng và hay bị bỏ quên: | Loại | Kiểm tra | Mặc định | |---|---|---| | EC2 | status check của EC2 — máy có chạy không | ✅ mặc định | | ELB | health check của load balancer — ứng dụng có phục vụ không | phải bật thủ công |

Với health check mặc định (EC2), ứng dụng chết mà máy vẫn bật thì ASG coi là hoàn toàn khoẻ mạnh. Muốn ASG biết ứng dụng hỏng thì phải đổi sang ELB:

aws autoscaling update-auto-scaling-group --auto-scaling-group-name nhom-web \
  --health-check-type ELB --health-check-grace-period 300