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

Đáp án

B — Cấu hình CloudFront với nhiều origin để phục vụ cả nội dung tĩnh lẫn động với độ trễ thấp cho người dùng toàn cầu.

Vì sao đúng

Đề có hai loại nội dung ở hai nơi, và người dùng trải khắp thế giới. CloudFront hỗ trợ nhiều origin trong cùng một distribution, và định tuyến giữa chúng bằng cache behavior theo path pattern:

CloudFront distribution: cdn.congty.vn
  ├─ Behavior "/static/*"  → Origin 1: S3 bucket        (TTL dài, cache mạnh)
  ├─ Behavior "/api/*"     → Origin 2: Application LB   (TTL ngắn hoặc 0)
  └─ Default behavior "*"  → Origin 2: Application LB

Ba lợi ích cùng lúc:

• Nội dung tĩnh được cache tại hơn 600 edge location — người dùng ở xa tải từ điểm gần nhất
• Nội dung động vẫn đi tới ALB, nhưng qua mạng lưng của AWS từ edge — nhanh và ổn định hơn nhiều so với đi qua Internet công cộng
• Một tên miền duy nhất cho cả hai, nên không có vấn đề CORS và không phải quản lý hai chứng chỉ

Điểm hay bị bỏ qua: CloudFront có ích cho nội dung động ngay cả khi không cache gì. Kết nối TLS được kết thúc ở edge gần người dùng, và chặng từ edge về origin đi trên mạng riêng đã được tối ưu — thường nhanh hơn 20–50%.

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

• C. "Origin Groups để gộp cả request tĩnh và động thành một" — hiểu sai chức năng. Origin group là cơ chế FAILOVER: khai một origin chính và một origin dự phòng, CloudFront chuyển sang origin thứ hai khi origin đầu trả về lỗi. Nó không "gộp request" và không dùng để định tuyến theo loại nội dung.
• A. Lambda@Edge để phục vụ dữ liệu "theo chương trình" — Lambda@Edge dùng để biến đổi request/response (viết lại URL, thêm header bảo mật, A/B testing, tuỳ biến theo thiết bị). Dùng nó làm bộ định tuyến giữa hai origin là thừa và tốn kém, khi cache behavior đã làm sẵn việc đó miễn phí.
• D. Global Accelerator "chuyển đổi giữa S3 và load balancer" — Global Accelerator tối ưu đường mạng bằng anycast IP, nhưng nó không cache gì và không hỗ trợ S3 làm endpoint. Nó hợp cho ứng dụng không phải HTTP (game, VoIP, TCP/UDP tuỳ ý) hoặc khi cần IP tĩnh.

Ghi nhớ

Mẫu kiến trúc chuẩn cho web toàn cầu: Route 53 → CloudFront (nhiều origin + WAF) → S3 (tĩnh) và ALB (động).

Đáp án

D — Định nghĩa một môi trường dev chạy single instance và một môi trường "load test" có cấu hình gần giống production.

Vì sao đúng

Elastic Beanstalk có mô hình phân cấp rõ ràng, và nó được thiết kế đúng cho tình huống này:

Application: "ung-dung-aspnet"
  ├─ Environment: "dev"        → single instance, cấu hình nhỏ, rẻ
  ├─ Environment: "load-test"  → load balanced + auto scaling, giống production
  └─ Environment: "prod"       → cấu hình production đầy đủ

Mỗi môi trường hoàn toàn độc lập: hạ tầng riêng, phiên bản ứng dụng riêng, biến môi trường riêng, cấu hình riêng. Bạn deploy phiên bản khác nhau vào từng môi trường mà không ảnh hưởng lẫn nhau.

Hai lựa chọn cấu hình khớp đúng với mục đích: | Môi trường | Kiểu | Vì sao | |---|---|---| | dev | single instance | rẻ nhất, không cần ELB, đủ cho phát triển | | load test | load balanced, giống production | kết quả kiểm thử tải chỉ có ý nghĩa khi cấu hình gần với thật |

Vế thứ hai quan trọng: kiểm thử tải trên một môi trường nhỏ hơn production sẽ cho con số vô nghĩa.

Beanstalk còn hỗ trợ .NET trên Windows Server với IIS làm nền tảng dựng sẵn — đúng công nghệ trong đề.

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

• C. "Không thể có nhiều môi trường dev trong Beanstalk, chỉ một dev và một production" — sai. Beanstalk không giới hạn số môi trường theo mục đích; bạn tạo bao nhiêu tuỳ nhu cầu (giới hạn mặc định là 200 môi trường mỗi Region, nâng được).
• A. Một môi trường duy nhất, đổi cấu hình bằng Ansible — hỏng ở nhiều mặt: không thể chạy hai phiên bản cùng lúc, mỗi lần chuyển đổi là một lần thay đổi cấu hình rủi ro, và kiểm thử tải sẽ ảnh hưởng trực tiếp tới môi trường dev. Ansible cũng đi ngược mô hình quản lý của Beanstalk.
• B. ALB định tuyến theo hostname + .ebextensions truyền tham số — phức tạp một cách không cần thiết, và không giải quyết được vấn đề gốc: hai phiên bản vẫn chạy trên cùng một tập instance với cùng cấu hình. Kiểm thử tải sẽ làm hỏng trải nghiệm phát triển.

Ghi nhớ

Hai kiểu môi trường của Elastic Beanstalk: | Kiểu | Thành phần | Hợp cho | |---|---|---| | Single instance | 1 EC2 + Elastic IP, không có ELB | dev, test, chi phí thấp | | Load balanced, Auto Scaling | ELB + ASG nhiều instance | staging, load test, production |

Và nhớ quy tắc vàng: CSDL production luôn nằm NGOÀI môi trường Beanstalk. Trong môi trường thì nó bị xoá cùng môi trường — và với nhiều môi trường như đề này, mỗi môi trường sẽ có một CSDL riêng trống rỗng.

Đáp án

C — Dùng Lambda alias trỏ tới các phiên bản khác nhau.

Vì sao đúng

Yêu cầu: quay về phiên bản cũ một cách liền mạch, với ít gánh nặng vận hành nhất.

Alias là con trỏ có tên tới một version, và đổi nó là thao tác một lệnh, hiệu lực gần như tức thì:

# Đang ở version 5, muốn quay về version 4
aws lambda update-alias --function-name xu-ly --name prod --function-version 4

Vì sao đây là cách ít gánh nặng nhất:

• ARN alias không đổi — mọi bên gọi (API Gateway, EventBridge, S3, SDK) vẫn trỏ vào ...:function:xu-ly:prod, không phải cấu hình lại gì
• Version là bất biến — mã và cấu hình của version 4 vẫn còn nguyên, không cần build lại hay deploy lại
• Rollback trong vài giây, không có bước trung gian nào

Alias còn hỗ trợ weighted routing để chuyển traffic dần thay vì chuyển hết một lúc:

aws lambda update-alias --function-name xu-ly --name prod \
  --function-version 4 --routing-config AdditionalVersionWeights={"5"=0.1}

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

• A. CodeDeploy blue/green cho Lambda — làm được và làm tốt, nhưng nhiều gánh nặng hơn: phải dựng CodeDeploy application, deployment group, AppSpec, và các hàm hook. Nó đáng khi cần rollback tự động theo CloudWatch alarm; nhưng nếu chỉ cần "quay về bản cũ" thì alias là đủ và đơn giản hơn nhiều. (Và bản thân CodeDeploy cũng dùng alias bên dưới.)
• B. Lambda layer trỏ tới các phiên bản — hiểu sai chức năng. Layer chứa thư viện và phụ thuộc dùng chung, không phải mã ứng dụng, và alias không trỏ vào layer — alias trỏ vào version của hàm.
• D. Route 53 weighted policy — Route 53 định tuyến DNS, còn Lambda được gọi qua API Invoke với ARN, không qua tên miền. Cơ chế không áp dụng được.

Ghi nhớ

Mẫu thực hành tốt:

$LATEST  ← nơi phát triển
version 1, 2, 3, 4, 5  ← các bản đã publish, bất biến
alias "dev"   → $LATEST
alias "stage" → version 5
alias "prod"  → version 4

Và với rollback tự động theo chỉ số, hãy dùng SAM DeploymentPreference với Alarms — nó gộp alias, weighted routing và CodeDeploy lại thành vài dòng cấu hình.

Đáp án

B — Bật CORS.

Vì sao đúng

Triệu chứng khoanh vùng rất chặt: truy cập URL video trực tiếp thì xem được, nhưng nhúng vào trang web ở bucket khác thì không phát được.

Vế thứ nhất chứng minh quyền truy cập đã đúng — nếu bucket policy hay IAM chặn thì URL trực tiếp cũng phải trả 403.

Vấn đề nằm ở Same-Origin Policy của trình duyệt: trang web ở bucket A, video ở bucket B — hai origin khác nhau. Trình duyệt chặn JavaScript đọc tài nguyên cross-origin trừ khi máy chủ cung cấp cho phép tường minh.

CORS phải cấu hình ở bucket CUNG CẤP tài nguyên, tức là bucket B chứa video:

[{
  "AllowedHeaders": ["*"],
  "AllowedMethods": ["GET", "HEAD"],
  "AllowedOrigins": ["https://bucket-a.s3-website-ap-southeast-1.amazonaws.com"],
  "ExposeHeaders": ["Content-Length", "Content-Range", "Accept-Ranges"],
  "MaxAgeSeconds": 3000
}]

Với video, ExposeHeaders rất quan trọng: trình phát cần Content-Range và Accept-Ranges để tua (range request). Thiếu chúng thì video có thể phát nhưng không tua được.

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

• D. Đổi bucket policy và C. Sửa IAM policy — cả hai kiểm soát quyền truy cập ở phía AWS. Nhưng URL trực tiếp đã hoạt động, chứng minh quyền không phải vấn đề. CORS là cơ chế của trình duyệt, ở tầng hoàn toàn khác.
• A. Tắt Server-Side Encryption — mã hoá phía máy chủ hoàn toàn trong suốt với client: S3 tự giải mã trước khi trả về. Nó không ảnh hưởng gì tới việc phát video hay CORS.

Ghi nhớ

Nguyên tắc vàng: CORS luôn cấu hình ở phía CUNG CẤP tài nguyên.

Mẹo chẩn đoán trong DevTools: lỗi CORS hiện rõ ở tab Console ("has been blocked by CORS policy"), và ở tab Network bạn thấy request trả về 200 nhưng tài nguyên vẫn không dùng được — đó là dấu hiệu phân biệt rõ nhất với lỗi phân quyền.

Đáp án

C — Xoá bảng rồi tạo lại.

Vì sao đúng

Yêu cầu: xoá 10 triệu bản ghi mỗi đêm, hiệu quả và chi phí thấp nhất.

Điểm mấu chốt: DeleteTable không tốn WCU nào cả. Đây là thao tác quản trị ở tầng control plane, tính phí bằng 0 cho việc xoá dữ liệu.

So sánh chi phí:

Với 10 triệu bản ghi mỗi đêm, khác biệt là giữa miễn phí và hàng trăm đô la mỗi tháng.

aws dynamodb delete-table --table-name doi-yeu-thich
aws dynamodb wait table-not-exists --table-name doi-yeu-thich
aws dynamodb create-table --table-name doi-yeu-thich \
  --attribute-definitions AttributeName=user_id,AttributeType=S \
  --key-schema AttributeName=user_id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST
aws dynamodb wait table-exists --table-name doi-yeu-thich

Vài điểm cần lưu ý khi làm thật: phải tạo lại đầy đủ GSI, LSI, stream, TTL và tag, và có khoảng thời gian bảng không tồn tại — chấp nhận được với cửa sổ 2 giờ sáng như đề mô tả.

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

• B. "Gọi PurgeTable" — API này không tồn tại trong DynamoDB. Đó là bẫy dựa trên PurgeQueue của SQS. DynamoDB không có lệnh xoá sạch bảng.
• A. Scan rồi gọi DeleteItem — tệ nhất: Scan đọc toàn bộ 10 triệu bản ghi (tốn RCU), rồi xoá từng bản ghi một (10 triệu lời gọi API, 10 triệu WCU). Rất chậm và rất đắt.
• D. Scan rồi gọi "BatchDeleteItem" — tên API sai (đúng là BatchWriteItem với request kiểu DeleteRequest), và kể cả gọi đúng thì vẫn tốn 10 triệu WCU cộng chi phí scan. Batch chỉ giảm số lời gọi API (25 mục mỗi lần), không giảm WCU.

Ghi nhớ

Cách xoá dữ liệu trong DynamoDB, theo chi phí: | Nhu cầu | Cách | |---|---| | Xoá toàn bộ bảng | DeleteTable + tạo lại — miễn phí | | Xoá theo thời gian sống | TTL — miễn phí, xoá trong nền | | Xoá một phần theo điều kiện | Query (không Scan) + BatchWriteItem | | Xoá một item | DeleteItem |

TTL đáng nhắc riêng: nếu dữ liệu có vòng đời cố định, đặt thuộc tính TTL là DynamoDB tự xoá miễn phí, không cần job đêm nào cả. Với bài toán trong đề, TTL có thể là giải pháp tốt hơn nếu bản ghi không cần biến mất đúng lúc 2 giờ sáng.

Đáp án

C — HTTPS giữa client và CloudFront, và giữa CloudFront và backend.

Vì sao đúng

CloudFront hỗ trợ mã hoá trên cả hai chặng của đường đi, và đó chính là ý nghĩa của "end-to-end HTTPS":

Client  ──HTTPS──→  CloudFront  ──HTTPS──→  Origin (S3 / ALB / máy chủ riêng)
        chặng 1                  chặng 2

Chặng 1 — Viewer Protocol Policy (client ↔ CloudFront): | Giá trị | Hành vi | |---|---| | allow-all | cho cả HTTP và HTTPS | | redirect-to-https | chuyển hướng HTTP sang HTTPS — thường dùng nhất | | https-only | từ chối HTTP |

Chặng 2 — Origin Protocol Policy (CloudFront ↔ origin): | Giá trị | Hành vi | |---|---| | http-only | luôn dùng HTTP | | https-only | luôn dùng HTTPS | | match-viewer | theo giao thức mà client đã dùng |

Đặt redirect-to-https cho chặng 1 và https-only cho chặng 2 là có mã hoá đầu cuối trọn vẹn.

Hai chi tiết quan trọng về chứng chỉ:

• Chứng chỉ cho tên miền của bạn (chặng 1) phải cấp bằng ACM ở us-east-1, bất kể ứng dụng chạy ở Region nào
• Chứng chỉ trên custom origin (chặng 2) phải do một CA công cộng được tin cậy ký, còn hạn, và có chuỗi trung gian đầy đủ — CloudFront từ chối chứng chỉ tự ký

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

• D. "Chỉ giữa client và CloudFront" — bỏ sót chặng 2. Đây là hiểu nhầm phổ biến, và nó để lại một khoảng đường không mã hoá giữa edge và origin.
• B. "Chỉ giữa CloudFront và backend" — bỏ sót chặng quan trọng nhất về mặt người dùng.
• A. "Không hỗ trợ chặng nào" — sai hoàn toàn; HTTPS là tính năng cơ bản của CloudFront.

Ghi nhớ

Cấu hình HTTPS đầu cuối cho CloudFront:

Viewer Protocol Policy : redirect-to-https
Origin Protocol Policy : https-only
Chứng chỉ viewer       : ACM tại us-east-1 (bắt buộc)
Chứng chỉ origin       : CA công cộng, còn hạn, đủ chuỗi trung gian
Minimum TLS version    : TLSv1.2_2021 trở lên

Với origin là S3, dùng Origin Access Control (OAC) — khi ấy CloudFront gọi S3 qua HTTPS bằng SigV4 và bucket đóng hoàn toàn với Internet, không cần lo chứng chỉ ở chặng 2.

Đáp án

B — Partition key được chọn không phân bố đủ đều.

Vì sao đúng

Đây là nghịch lý kinh điển của Kinesis: thông lượng tổng còn dư nhiều mà vẫn bị throttle.

Lý do: giới hạn của Kinesis áp cho TỪNG SHARD, không phải cho cả stream.

Trong đề: 10 shard cho tổng 10 MB/giây, đang gửi 3 MB/giây — nhìn thì rất thoải mái. Nhưng nếu partition key phân bố lệch:

Shard 1: 2,5 MB/giây   ← VƯỢT 1 MB/giây → ProvisionedThroughputExceededException
Shard 2: 0,3 MB/giây
Shard 3: 0,1 MB/giây
...
Shard 10: 0,05 MB/giây
────────────────────
Tổng   : 3 MB/giây (trên 10 MB có sẵn)

Kinesis băm partition key để chọn shard, nên khoá càng ít giá trị càng dồn cục.

Các partition key xấu thường gặp: | Khoá | Vì sao lệch | |---|---| | loai_su_kien | chỉ vài giá trị | | ngay | mọi bản ghi trong ngày vào một shard | | id_cua_hang với một cửa hàng lớn | một giá trị chiếm phần lớn lưu lượng |

Cách chữa: chọn khoá có độ phân tán cao (user_id, device_id, UUID), hoặc rải khoá bằng hậu tố:

partition_key = f"{ma_cua_hang}#{random.randint(0, 9)}"

(Lưu ý: rải khoá làm mất tính đảm bảo thứ tự trong nhóm khoá đó — chỉ dùng khi thứ tự không quan trọng.)

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

• A. "Có quá nhiều shard" — nhiều shard không bao giờ gây throttle; nó chỉ làm tăng chi phí. Vấn đề là phân bố, không phải số lượng.
• C. "Metric cập nhật chậm" — metric có thể trễ vài phút, nhưng ProvisionedThroughputExceededException là lỗi thật, trả về ngay tại lời gọi API.
• D. "Thời gian giữ dữ liệu quá dài" — retention period (24 giờ đến 365 ngày) ảnh hưởng tới chi phí lưu trữ, hoàn toàn không liên quan tới giới hạn ghi.

Ghi nhớ

Danh sách kiểm khi bị throttle trên Kinesis dù tổng còn dư:

1. Partition key có phân bố đều không? ← nguyên nhân số một
2. Xem metric WriteProvisionedThroughputExceeded theo từng shard để tìm shard nóng
3. Cân nhắc rải khoá hoặc đổi khoá
4. Cân nhắc on-demand mode — Kinesis tự co giãn theo shard
5. Luôn có retry với exponential backoff ở producer

Nguyên tắc chung, giống hệt DynamoDB: throughput chia theo partition/shard, nên phân bố khoá quan trọng hơn tổng dung lượng.

Đáp án

D — Cache phụ thuộc trên S3.

Vì sao đúng

Vấn đề: mỗi lần build đều tải lại hơn 100 phụ thuộc từ Ivy repository bên ngoài — chậm và lặp lại vô ích, vì phụ thuộc gần như không đổi giữa các lần build.

CodeBuild caching giải quyết bằng cách lưu lại thư mục phụ thuộc và khôi phục ở lần build sau:

# buildspec.yml
version: 0.2
phases:
  build:
    commands:
      - ant resolve
      - ant compile
cache:
  paths:
    - '/root/.ivy2/**/*'      # Ivy
    - '/root/.m2/**/*'        # Maven
    - 'node_modules/**/*'     # npm

aws codebuild update-project --name du-an \
  --cache type=S3,location=kho-cache-build/du-an

Kết quả điển hình: build đầu tiên vẫn tải đủ, các build sau khôi phục cache trong vài giây thay vì tải lại vài phút. Với hơn 100 phụ thuộc, đây thường là khoản tiết kiệm lớn nhất có thể đạt được — và cấu hình chỉ vài dòng, đúng vế "minimal effort".

CodeBuild có hai loại cache: | Loại | Đặc điểm | |---|---| | S3 cache | dùng chung giữa mọi build, bền, hơi chậm hơn khi khôi phục | | Local cache | nhanh hơn, nhưng chỉ dùng lại được trên cùng máy build — không đảm bảo |

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

• C. Đóng gói toàn bộ phụ thuộc vào mã nguồn — làm repository phình lên hàng trăm MB, mọi thao tác Git chậm đi, và cập nhật phụ thuộc trở thành một commit khổng lồ. Đây là chống chỉ định trong quản lý mã nguồn.
• B. Giảm số lượng phụ thuộc — có thể là việc đáng làm về lâu dài, nhưng nó là tái cấu trúc ứng dụng, không phải "minimal effort", và có thể không khả thi.
• A. "Dùng EC2 instance store để làm cache nội bộ" — hiểu sai kiến trúc: CodeBuild không chạy trên EC2 instance của bạn. Mỗi build chạy trong một container tạm thời do AWS quản lý; bạn không chọn được loại lưu trữ.

Ghi nhớ

Các cách tăng tốc CodeBuild, theo hiệu quả: | Cách | Hiệu quả | |---|---| | Bật cache phụ thuộc | thường lớn nhất | | Dùng custom Docker image đã cài sẵn công cụ | bỏ được thời gian cài đặt | | Tăng compute type | mỗi build nhanh hơn, tốn tiền hơn | | Batch build với build graph | chạy song song các phần độc lập |

Và nhớ: CodeBuild tự co giãn — không cần làm gì cho việc chạy nhiều build song song. Cache là để rút ngắn mỗi build, không phải để chạy được nhiều build.

Đáp án

A và E.

• A — ALB có ba loại target: Instance, IP và Lambda.
• E — Không được khai địa chỉ IP định tuyến công khai làm target của ALB.

Vì sao đúng

A — ba loại target. Đây là danh sách đầy đủ và cố định:

E — chỉ IP riêng. Với target type ip, ALB chỉ chấp nhận địa chỉ trong các dải riêng:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
100.64.0.0/10

Khai một IP công khai sẽ bị từ chối. Lý do là kiến trúc: ALB giao tiếp với target qua mạng riêng của VPC, kể cả khi target nằm ở on-premises (đi qua VPN hoặc Direct Connect).

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

• B. "Với target là instance ID, traffic được định tuyến tới bất kỳ IP riêng nào từ một hoặc nhiều network interface" — sai. Với target type instance, ALB dùng IP riêng chính (primary private IP) của network interface chính, không phải IP tuỳ ý.
• C. "Với target là IP address, traffic được định tuyến tới primary private IP" — đây là mô tả bị hoán đổi với B. Với target type ip, bạn chỉ định chính xác IP nào — và đó chính là ưu điểm của loại này: định tuyến được tới IP phụ trên nhiều network interface, thứ mà target type instance không làm được.
• D. "Ba loại target: Hostname, IP và Lambda" — không có target type hostname. Loại đầu tiên là instance.

Ghi nhớ

Khi nào phải dùng target type ip: ECS với network mode awsvpc (mỗi task có ENI riêng), target on-premises qua VPN/Direct Connect, và khi cần định tuyến tới IP phụ trên một instance.

Đáp án

D — CloudWatch Events (EventBridge) rule với Lambda làm target.

Vì sao đúng

Bài toán: một tài nguyên AWS đổi trạng thái, cần kích hoạt Lambda, nhưng dịch vụ đó không tích hợp trực tiếp với Lambda.

EventBridge là lớp trung gian phổ quát giải quyết đúng chuyện đó. Gần như mọi dịch vụ AWS đều phát sự kiện thay đổi trạng thái lên EventBridge, và Lambda là target hợp lệ:

{
  "source": ["aws.rds"],
  "detail-type": ["RDS DB Instance Event"],
  "detail": {"EventCategories": ["failover", "failure"]}
}

Và ngay cả khi dịch vụ không phát sự kiện riêng, CloudTrail vẫn ghi lại mọi lời gọi API và chuyển tiếp lên EventBridge:

{
  "source": ["aws.dynamodb"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {"eventName": ["DeleteTable"]}
}

Nhờ hai đường này, EventBridge phủ được hầu như mọi thay đổi trạng thái trên AWS — kể cả những dịch vụ không có tích hợp Lambda nào.

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

• C. Cron job định kỳ kiểm tra trạng thái dịch vụ — polling: lãng phí (chạy liên tục kể cả khi không có gì đổi), có độ trễ (bỏ lỡ thay đổi giữa hai lần kiểm tra), và phải tự lưu trạng thái trước đó để biết cái gì đã đổi. Đây là thứ mà kiến trúc hướng sự kiện sinh ra để thay thế.
• A. "AWS Lambda Custom Sources" — không tồn tại. Lambda có event source mapping cho SQS, Kinesis và DynamoDB Streams, nhưng không có khái niệm "custom source" cho phép tự đăng ký nguồn tuỳ ý.
• B. Mở support ticket với AWS — không phải giải pháp kỹ thuật, và cơ chế cần dùng đã có sẵn.

Ghi nhớ

Ba nguồn sự kiện của EventBridge: | Nguồn | Ví dụ | |---|---| | Sự kiện dịch vụ AWS | EC2 state change, S3 object created, RDS event, ECS task state change | | CloudTrail API call | mọi lời gọi API — dùng khi dịch vụ không phát sự kiện riêng | | Sự kiện tuỳ chỉnh | ứng dụng của bạn gọi PutEvents |

Và nhớ: EventBridge có hơn 20 loại target, không chỉ Lambda — SNS, SQS, Step Functions, ECS task, Kinesis, API destination (webhook ra ngoài)…

Nguyên tắc chung: có sự kiện thì bám vào sự kiện, đừng polling. Polling luôn vừa tốn hơn vừa chậm hơn.