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

Đáp án

C — Dùng CloudWatch Event Rules (EventBridge).

Vì sao đúng

CodeCommit phát sự kiện lên EventBridge ở mỗi lần có thay đổi, và đó là cơ chế chuẩn để phản ứng với chúng:

{
  "source": ["aws.codecommit"],
  "detail-type": ["CodeCommit Repository State Change"],
  "resources": ["arn:aws:codecommit:ap-southeast-1:123456789012:du-an"],
  "detail": {
    "event": ["referenceCreated", "referenceUpdated"],
    "referenceType": ["branch"],
    "referenceName": ["main"]
  }
}

Đây cũng chính là cơ chế mặc định mà CodePipeline dùng để phát hiện thay đổi từ CodeCommit. Khi bạn tạo pipeline qua Console hoặc CloudFormation, một EventBridge rule như trên được sinh tự động — và nó là một tài nguyên riêng biệt, có thể bị xoá nhầm.

Các sự kiện CodeCommit phát ra: | Sự kiện | Khi nào | |---|---| | referenceCreated | tạo nhánh hoặc tag mới | | referenceUpdated | push commit lên nhánh | | referenceDeleted | xoá nhánh hoặc tag | | pullRequestCreated, pullRequestMergeStatusUpdated | sự kiện pull request | | commentOnCommitCreated | bình luận |

EventBridge có hơn 20 loại target: Lambda, SNS, SQS, Step Functions, CodePipeline, CodeBuild, ECS task…

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

• B. "CloudTrail Event rules với SES" — CloudTrail ghi log, nó không có "event rule". Sự kiện CloudTrail có chảy vào EventBridge, nhưng khi ấy bạn vẫn đang dùng EventBridge rule — tức là quay về đáp án C. Và SES là dịch vụ gửi email, không phải cơ chế định tuyến.
• A. "Lambda Event Rules" — không tồn tại. Lambda có event source mapping cho SQS, Kinesis, DynamoDB Streams, MSK — nhưng CodeCommit không nằm trong danh sách đó.
• D. Lambda function với SNS — làm được nếu bạn cấu hình CodeCommit notification rule gửi tới SNS rồi SNS gọi Lambda. Nhưng đó là đường vòng: EventBridge gọi thẳng target và có lọc mạnh hơn nhiều (lọc theo nhánh, theo loại sự kiện, ngay ở tầng rule).

Ghi nhớ

Ba cách nhận thông báo từ CodeCommit: | Cách | Đặc điểm | |---|---| | EventBridge rule | linh hoạt nhất, hơn 20 loại target, lọc mạnh | | Notification rule | dựng sẵn cho SNS và AWS Chatbot (Slack/Chime) | | Trigger | gọi Lambda hoặc SNS — cơ chế cũ, ít linh hoạt |

Và nguyên tắc chung: dịch vụ AWS phát sự kiện ⇒ EventBridge là lớp định tuyến phổ quát. Đừng dựng cron hay polling khi đã có sự kiện.

(Ghi chú: AWS đã ngừng nhận khách hàng mới cho CodeCommit từ giữa 2024; tài khoản đang dùng vẫn hoạt động.)

Đáp án

C — Amazon EC2 Reserved Instances.

Vì sao đúng

Đề nêu ba đặc điểm, và chúng cùng nhau chỉ về Reserved Instance:

Traffic ổn định là điểm quyết định. RI chỉ đáng khi bạn chắc chắn sẽ dùng tài nguyên đó liên tục — vì bạn trả tiền cho cam kết dù có chạy hay không. Với tải đều đặn suốt ngày, đó chính xác là điều kiện tối ưu.

Ba tuỳ chọn thanh toán, mức giảm giá tăng dần: | Tuỳ chọn | Giảm giá | |---|---| | No Upfront | thấp nhất | | Partial Upfront | trung bình | | All Upfront | cao nhất |

Và hai loại RI: | Loại | Đặc điểm | |---|---| | Standard | giảm giá nhiều nhất, ít linh hoạt | | Convertible | đổi được sang họ instance khác, giảm giá ít hơn |

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

• A. On-Demand Instances — linh hoạt nhất nhưng đắt nhất. Với tải ổn định biết trước cả năm, trả giá On-Demand là lãng phí đáng kể — trái tiêu chí "cost-optimal".
• B. Spot Instances — rẻ nhất (giảm tới 90%), nhưng AWS có thể thu hồi bất cứ lúc nào với thông báo trước 2 phút. Đề nói rõ "no down-time or access issues" — Spot loại ngay.
• D. "On-premise EC2 instance" — không tồn tại. EC2 là dịch vụ đám mây. (Thứ gần nhất là AWS Outposts — hạ tầng AWS đặt tại chỗ — nhưng nó rất đắt và hoàn toàn không phù hợp cho một startup.)

Ghi nhớ

Bảng chọn mô hình mua theo tình huống: | Mô hình | Cam kết | Giảm giá | Hợp cho | |---|---|---|---| | On-Demand | không | 0% | tải bất định, ngắn hạn | | Reserved Instance | 1 hoặc 3 năm | tới 72% | tải ổn định, dự đoán được | | Savings Plans | 1 hoặc 3 năm | tới 72% | linh hoạt hơn RI | | Spot | không | tới 90% | job chịu được gián đoạn | | Dedicated Host | tuỳ | — | yêu cầu tuân thủ, BYOL |

Ghi chú thời sự: Savings Plans thường được ưa dùng hơn RI ngày nay — cùng mức giảm giá nhưng linh hoạt hơn nhiều (cam kết theo mức chi tiêu $/giờ thay vì theo cấu hình instance cụ thể, và áp được cho cả Fargate và Lambda). Với hệ thống mới, đó là lựa chọn đáng cân nhắc trước.

Đáp án

A — Load balancer có tính sẵn sàng cao và IP công khai của nó CÓ THỂ THAY ĐỔI; chỉ tên DNS là cố định.

Vì sao đúng

Đây là một trong những hiểu nhầm phổ biến nhất về ELB, và hậu quả đúng như đề mô tả: ứng dụng chạy tốt rồi đột ngột hỏng mà không ai đổi gì.

Nguyên nhân: ELB không phải một máy chủ — nó là một dịch vụ phân tán, tự co giãn:

Nên client ghi nhớ IP sẽ hoạt động cho tới lần ELB co giãn tiếp theo — có thể vài giờ, có thể vài ngày, hoàn toàn không đoán trước được.

Cách đúng: luôn dùng tên DNS, và để resolver phân giải lại theo TTL (ELB đặt TTL 60 giây cho chính lý do này):

myDns-1234567890.us-east-1.elb.amazonaws.com   ← CỐ ĐỊNH, dùng cái này

Với client tự viết, cần đảm bảo không cache DNS quá TTL. Một số runtime (đặc biệt là JVM) mặc định cache DNS vĩnh viễn — phải đặt networkaddress.cache.ttl=60.

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

• B. "Cần bật stickiness" — sticky session ghim một client vào một target. Nó không liên quan gì tới việc IP của load balancer thay đổi.
• C. "Security group không ổn định" — security group là quy tắc lọc tĩnh; chúng không tự đổi. Và nếu security group sai thì lỗi sẽ xuất hiện ngay từ đầu, không phải sau một thời gian chạy tốt.
• D. "Tắt triển khai multi-AZ" — sai hướng hoàn toàn: multi-AZ là thứ mang lại tính sẵn sàng cao. Tắt nó làm hệ thống kém tin cậy hơn, và cũng không làm IP cố định.

Ghi nhớ

IP tĩnh theo loại load balancer: | Loại | IP | |---|---| | ALB | thay đổi — chỉ có tên DNS | | NLB | IP tĩnh mỗi AZ, gán được Elastic IP | | Gateway LB | qua endpoint | | Global Accelerator | 2 anycast IP tĩnh cho toàn cầu |

Nên khi thực sự cần IP tĩnh (firewall của đối tác chỉ cho phép danh sách IP, thiết bị cũ không phân giải DNS được), câu trả lời là NLB hoặc Global Accelerator, không phải ALB.

Và quy tắc chung cho mọi dịch vụ AWS: luôn dùng tên DNS, không bao giờ ghi cứng IP. RDS endpoint, ElastiCache endpoint, ALB DNS name — tất cả đều có thể đổi IP bên dưới.

Đáp án

D — Đặt reserved concurrency cho hàm B để nó bị throttle khi vượt một ngưỡng nhất định.

Vì sao đúng

Vấn đề: hàm B ngốn hết concurrency của cả tài khoản, khiến hàm A không còn chỗ để chạy.

Mọi tài khoản AWS có hạn mức concurrency chung (mặc định 1.000 mỗi Region). Mọi hàm Lambda chia nhau hạn mức đó — nên một hàm chạy loạn có thể bỏ đói tất cả hàm còn lại.

Reserved concurrency giải quyết bằng cách đặt trần cho hàm B:

aws lambda put-function-concurrency \
  --function-name ham-B --reserved-concurrent-executions 100

Nó có tác dụng kép, và đó là điểm hay: | Tác dụng | Chi tiết | |---|---| | Đặt trần | hàm B không bao giờ vượt 100 — bị throttle nếu cố | | Dành riêng | 100 slot đó chỉ của hàm B, hàm khác không dùng được |

Nhờ vế thứ nhất, phần concurrency còn lại (900) được bảo vệ cho hàm A và các hàm khác.

Reserved concurrency miễn phí — nó chỉ là một con số giới hạn, không phải tài nguyên phải trả tiền giữ sẵn.

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

• C. Đặt provisioned concurrency cho hàm B — đây là bẫy trung tâm, và hai tên rất giống nhau nhưng tác dụng ngược nhau. Provisioned concurrency KHỞI TẠO SẴN môi trường ấm để loại bỏ cold start; nó không đặt trần và không throttle gì cả. Dùng nó ở đây còn làm hàm B chiếm chỗ chắc chắn hơn.
• B. Đổi ALB sang API Gateway cho hàm A — đổi cửa ngõ, không đổi hạn mức concurrency. Hàm A vẫn không có slot để chạy.
• A. Dùng CloudFront thay ALB — CloudFront là CDN; nó không gọi Lambda làm origin theo kiểu này (Lambda@Edge là cơ chế khác hẳn), và cũng không giải quyết vấn đề concurrency.

Ghi nhớ

Câu thần chú: "bảo vệ / giới hạn / throttle" ⇒ reserved. "Cold start / độ trễ khởi động" ⇒ provisioned.

Và nhớ một tác dụng phụ nguy hiểm: đặt reserved concurrency = 0 sẽ tắt hoàn toàn hàm đó — đôi khi hữu ích để dừng khẩn cấp một hàm đang chạy loạn.

Đáp án

B — 4 KB.

Vì sao đúng

kms:Encrypt có giới hạn cứng 4.096 byte (4 KB) cho dữ liệu truyền vào. Vượt qua đó thì lời gọi bị từ chối.

Lý do là thiết kế: CMK không bao giờ rời khỏi KMS, nên dữ liệu phải đi qua mạng tới KMS để được mã hoá. Truyền dữ liệu lớn qua đường đó sẽ vừa chậm vừa tốn kém.

Với payload XML lớn như trong đề, cách đúng là envelope encryption:

1. GenerateDataKey  →  KMS trả về: data key bản rõ + data key bản mã
2. Mã hoá payload bằng data key bản rõ (AES-256, NGAY TẠI CHỖ)
3. XOÁ data key bản rõ khỏi bộ nhớ
4. Lưu: payload đã mã hoá + data key bản mã
5. Khi cần đọc: kms:Decrypt data key rồi giải mã payload tại chỗ

Payload lớn không bao giờ đi qua mạng tới KMS — chỉ có khoá 256-bit đi qua. Đó là toàn bộ ý nghĩa của envelope encryption.

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

• A. 16 KB, D. 1 MB, C. 10 MB — không con số nào là giới hạn của KMS. Chúng là các giá trị nghe hợp lý nhưng thuộc dịch vụ khác: 1 MB là giới hạn bản ghi của Kinesis, 10 MB là payload của API Gateway.

Ghi nhớ

Nhận dạng nhanh trong đề: thấy "large data", "large payload" kèm KMS ⇒ GenerateDataKey và envelope encryption.

(Ghi chú: SDK của S3, EBS, RDS và nhiều dịch vụ AWS đã tự làm envelope encryption bên dưới — bạn chỉ chỉ định CMK và không phải viết đoạn mã đó.)

Đáp án

B — Viết Lambda authorizer tham chiếu dữ liệu xác thực trong bảng DynamoDB.

Vì sao đúng

Yêu cầu rất đặc thù: xác thực bằng header HTTP tuỳ chỉnh (client ID và user ID), đối chiếu với bảng DynamoDB của riêng công ty.

Đó là logic tuỳ ý, và Lambda authorizer là điểm mở rộng duy nhất của API Gateway cho việc đó:

def handler(event, context):
    client_id = event['headers'].get('client-id')
    user_id   = event['headers'].get('user-id')

    item = table.get_item(Key={'client_id': client_id, 'user_id': user_id}).get('Item')
    if not item:
        raise Exception('Unauthorized')          # → 401

    return {
        'principalId': user_id,
        'policyDocument': {
            'Version': '2012-10-17',
            'Statement': [{'Action': 'execute-api:Invoke',
                           'Effect': 'Allow', 'Resource': event['methodArn']}]},
        'context': {'vaiTro': item['role']}      # truyền tiếp xuống backend
    }

Vì đề nói xác thực dựa trên nhiều header, phải dùng authorizer kiểu REQUEST (nhận toàn bộ header, query string, path), không phải kiểu TOKEN (chỉ nhận một header).

Kết quả được cache (mặc định 300 giây), nên không phải gọi hàm và truy vấn DynamoDB ở mọi request.

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

• C. Dùng Cognito tham chiếu bảng DynamoDB — Cognito không đọc bảng DynamoDB của bạn để xác thực. Nó có thư mục người dùng riêng; dùng Cognito nghĩa là di trú toàn bộ dữ liệu người dùng sang đó, không phải đọc từ bảng có sẵn.
• A. Dùng API Gateway Model yêu cầu credential — hiểu sai chức năng: Model là JSON Schema mô tả cấu trúc request/response, dùng để kiểm tra tính hợp lệ của payload và sinh SDK. Nó không xác thực gì cả.
• D. Sửa integration request để yêu cầu credential rồi cấp cho API Gateway quyền vào DynamoDB — integration request chỉ biến đổi và chuyển tiếp request tới backend. Nó không có logic so sánh hay quyết định cho phép/từ chối.

Ghi nhớ

Bốn cơ chế uỷ quyền của API Gateway: | Cơ chế | Dùng khi | |---|---| | Lambda authorizer | logic tuỳ ý — header riêng, CSDL riêng, IdP bên thứ ba | | Cognito user pool | dùng thư mục người dùng của AWS | | IAM (SigV4) | client có danh tính AWS | | JWT authorizer (HTTP API) | OIDC/OAuth2 chuẩn |

Hai kiểu Lambda authorizer: | Kiểu | Đầu vào | |---|---| | TOKEN | một header (thường là Authorization) | | REQUEST | toàn bộ header, query, path, stage variable |

Nhận dạng nhanh: đề nêu nhiều header tuỳ chỉnh hoặc nguồn dữ liệu xác thực của riêng bạn ⇒ Lambda authorizer kiểu REQUEST.

Đáp án

C — Dùng awslogs log driver, cấu hình container trong task gửi log lên CloudWatch Logs, khai tham số logConfiguration trong task definition.

Vì sao đúng

Với Fargate, bạn không có quyền truy cập host — không cài được agent, không đụng được vào máy bên dưới. Nên việc thu log phải khai trong task definition:

"containerDefinitions": [{
  "name": "ung-dung",
  "image": "...ecr.../app:v1",
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/ung-dung",
      "awslogs-region": "ap-southeast-1",
      "awslogs-stream-prefix": "ecs",
      "awslogs-create-group": "true"
    }
  }
}]

Với awslogs driver, mọi thứ container ghi ra stdout/stderr đều tự động chảy vào CloudWatch Logs — không phải sửa mã ứng dụng.

Điều kiện bắt buộc: task execution role phải có quyền ghi log:

{"Effect": "Allow",
 "Action": ["logs:CreateLogStream", "logs:PutLogEvents", "logs:CreateLogGroup"],
 "Resource": "*"}

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

• A. "…container instance cần ít nhất phiên bản 1.9 của ECS agent" — câu này nói về ECS trên EC2, nơi có container instance và ECS agent. Fargate không có container instance — AWS quản lý toàn bộ hạ tầng, và không có phiên bản agent nào để bạn kiểm tra.
• D. Cài unified CloudWatch agent trên ECS instance — cùng vấn đề: Fargate không cho truy cập instance để cài bất cứ thứ gì.
• B. Nói về metric CPU và bộ nhớ tự động gửi lên CloudWatch — đúng về mặt sự thật (Fargate có phát metric), nhưng đề hỏi về log, không phải metric. Sai đối tượng.

Ghi nhớ

Các log driver của ECS: | Driver | Fargate | EC2 | |---|---|---| | awslogs | ✅ | ✅ | | awsfirelens | ✅ | ✅ | | json-file, syslog, journald, gelf, fluentd, splunk | ❌ | ✅ |

FireLens đáng biết cho nhu cầu phức tạp hơn: nó dùng Fluent Bit hoặc Fluentd làm sidecar, cho phép lọc, biến đổi, và gửi tới nhiều đích (CloudWatch, S3, OpenSearch, Datadog, Splunk) cùng lúc.

Và phân biệt hai role của ECS — bị nhầm rất thường xuyên: | Role | Ai dùng | Để làm gì | |---|---|---| | Task execution role | ECS agent | kéo image từ ECR, ghi log | | Task role | mã trong container | gọi S3, DynamoDB… |

Quyền ghi log thuộc về execution role, không phải task role — đây là chỗ hay cấu hình nhầm.

Đáp án

C — Kinesis Data Firehose để nạp dữ liệu, Kinesis Data Analytics để tính điểm bảng xếp hạng và phân tích chuỗi thời gian.

Vì sao đúng

Đề nêu ba tiêu chí, và tiêu chí thứ ba là điểm phân biệt:

1. Phân tích gần thời gian thực
2. Được quản lý hoàn toàn
3. Chi phí thấp nhất

Firehose cho vế nạp dữ liệu, và nó rẻ hơn Data Streams vì mô hình tính tiền khác hẳn:

Với "near-real-time" (gần thời gian thực, không phải thời gian thực tuyệt đối), độ trễ ~60 giây của Firehose là chấp nhận được — và đổi lại là không phải nuôi shard nào.

Kinesis Data Analytics cho vế phân tích: chạy SQL hoặc Apache Flink trực tiếp trên luồng đang chảy, với các hàm cửa sổ thời gian dựng sẵn:

CREATE OR REPLACE STREAM "bang_xep_hang" AS
SELECT STREAM ma_co_phieu, COUNT(*) AS so_giao_dich
FROM "nguon_001"
GROUP BY ma_co_phieu,
  STEP("nguon_001".ROWTIME BY INTERVAL '1' MINUTE);

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

• A. Data Streams + Data Analytics — chạy được và độ trễ thấp hơn, nhưng đắt hơn: phải trả tiền shard-giờ liên tục và tự quản số shard. Trượt tiêu chí "least cost".
• B. Data Streams + KCL tự viết — vừa đắt (shard-giờ) vừa không phải giải pháp được quản lý: bạn phải tự viết ứng dụng consumer, tự triển khai, tự vận hành. Trái cả hai tiêu chí.
• D. Firehose + Athena — Athena truy vấn dữ liệu đã nằm yên trên S3, theo lô. Nó không phải phân tích luồng, nên không cho được "near-real-time" — bạn phải chờ Firehose ghi xong rồi mới chạy truy vấn.

Ghi nhớ

Cách chọn nhanh:

• Cần dưới giây, nhiều consumer, phát lại ⇒ Data Streams
• Chỉ nạp vào đích, gần thời gian thực, rẻ ⇒ Firehose
• Phân tích liên tục trên luồng ⇒ Data Analytics
• Phân tích dữ liệu đã lưu ⇒ Athena

Đáp án

B và D.

• D — Dùng eventually consistent read thay cho strongly consistent read khi có thể.
• B — Cân nhắc Global Tables nếu người dùng phân tán toàn cầu.

Vì sao đúng

D — giảm độ trễ và chi phí cùng lúc. Đây là cách chỉnh đơn giản nhất:

Vì đọc được từ bất kỳ bản sao nào, DynamoDB chọn được đường nhanh nhất — nên độ trễ giảm, và chi phí cũng chỉ bằng một nửa.

Đây cũng là mặc định của DynamoDB; nhiều ứng dụng bật ConsistentRead=True mà không thực sự cần.

B — Global Tables cho người dùng toàn cầu. Nếu độ trễ đến từ khoảng cách địa lý (người dùng ở châu Âu gọi bảng ở Singapore), thì mọi tối ưu trong Region đều vô ích. Global Tables tạo bản sao ghi được ở mỗi Region, nên người dùng luôn nói chuyện với bản gần mình nhất.

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

• C. Dùng DAX cho workload ghi nhiều — sai chiều dứt khoát. DAX là cache ĐỌC; nó không tăng tốc ghi chút nào (ghi vẫn đi thẳng xuống DynamoDB). DAX chỉ có ích với workload đọc nhiều.
• A. Giảm connection pooling — hiểu ngược: connection pool giúp giảm độ trễ bằng cách tái sử dụng kết nối đã mở, tránh bắt tay TLS ở mỗi request. Giảm nó sẽ làm chậm hơn.
• E. Tăng request timeout — chỉ cho phép chờ lâu hơn trước khi bỏ cuộc. Nó không làm request nhanh hơn; thực tế còn che mất vấn đề thật.

Ghi nhớ

Danh sách kiểm khi DynamoDB có độ trễ cao: | Nguyên nhân | Cách chữa | |---|---| | Dùng strongly consistent không cần thiết | chuyển sang eventually consistent | | Người dùng ở xa Region | Global Tables | | Đọc lặp lại cùng dữ liệu | DAX | | Hot partition | thiết kế lại partition key, hoặc rải khoá | | Item quá lớn | tách item, hoặc để dữ liệu lớn trên S3 | | Dùng Scan thay Query | thiết kế khoá / thêm GSI |

Và nhớ hai giới hạn liên quan: item tối đa 400 KB, và Scan luôn đắt và chậm hơn Query — nếu ứng dụng đang scan nhiều thì đó thường là nguyên nhân gốc.

Đáp án

A và C.

• A — $(aws ecr get-login --no-include-email) — đăng nhập vào ECR.
• C — docker pull 1234567890.dkr.ecr.eu-west-1.amazonaws.com/demo:latest — kéo image về.

Vì sao đúng

Kéo image từ ECR luôn có hai bước, vì ECR là registry riêng tư đòi xác thực:

Bước 1 — đăng nhập. ECR không nhận thông tin xác thực AWS trực tiếp; nó cần một token có hạn 12 giờ đổi từ IAM:

# Cú pháp cũ (vẫn dùng được trong AWS CLI v1)
$(aws ecr get-login --no-include-email)

# Cú pháp hiện hành (AWS CLI v2)
aws ecr get-login-password --region eu-west-1 | \
  docker login --username AWS --password-stdin 1234567890.dkr.ecr.eu-west-1.amazonaws.com

Dấu $(...) ở phương án A là command substitution của shell: aws ecr get-login in ra một lệnh docker login hoàn chỉnh, và $(...) thực thi nó.

Bước 2 — kéo image bằng lệnh Docker thông thường, với URI đầy đủ của ECR:

<account-id>.dkr.ecr.<region>.amazonaws.com/<repository>:<tag>

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

• B. aws docker push ... — không có lệnh aws docker. Docker là công cụ riêng; AWS CLI chỉ lo phần xác thực. Và đề yêu cầu kéo (pull), không phải đẩy (push).
• D. docker build -t ... — dựng image từ Dockerfile tại chỗ, không kéo gì từ ECR cả. Sai thao tác hoàn toàn.
• E. docker login -u $AWS_ACCESS_KEY_ID -p $AWS_SECRET_ACCESS_KEY — ECR không nhận access key làm mật khẩu Docker. Nó chỉ nhận token tạm thời lấy từ get-login-password. Đây là bẫy hợp lý nhất trong các phương án sai.

Ghi nhớ

Quy trình đầy đủ với ECR:

# 1. Đăng nhập (token sống 12 giờ)
aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin $ECR_URI

# 2. Kéo về
docker pull $ECR_URI/demo:latest

# 3. Hoặc đẩy lên
docker tag app:latest $ECR_URI/demo:v1
docker push $ECR_URI/demo:v1

Quyền IAM cần cho từng thao tác: | Thao tác | Quyền | |---|---| | Đăng nhập | ecr:GetAuthorizationToken (bắt buộc Resource: "*") | | Kéo | BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability | | Đẩy | thêm InitiateLayerUpload, UploadLayerPart, CompleteLayerUpload, PutImage |

ecr:GetAuthorizationToken là quyền bị bỏ sót nhiều nhất — thiếu nó thì ngay bước docker login đã thất bại.