Containers trên AWS – ECS, EKS, Fargate, ECR

1. Docker là gì?

Docker là một nền tảng phát triển phần mềm dùng để triển khai ứng dụng. Ứng dụng được đóng gói vào các container (khối chứa) và container đó có thể chạy trên bất kỳ hệ điều hành nào. Ý tưởng cốt lõi rất đơn giản nhưng cực kỳ mạnh: ứng dụng chạy giống hệt nhau bất kể nó được chạy ở đâu.

Điều đó mang lại một loạt lợi ích trực tiếp cho người vận hành:

Chạy được trên bất kỳ máy nào (any machine).
Không gặp vấn đề tương thích (no compatibility issues).
Hành vi dự đoán được (predictable behavior).
Ít việc phải làm hơn (less work).
Dễ bảo trì và dễ triển khai hơn.
Hoạt động với bất kỳ ngôn ngữ, bất kỳ hệ điều hành, bất kỳ công nghệ nào.

Hai use case kinh điển của Docker: kiến trúc microservices, và lift-and-shift (bốc nguyên ứng dụng từ on-premises đưa lên AWS cloud mà gần như không sửa code).

Về cách bố trí, Docker chạy trên một server — ví dụ một EC2 instance — và trên server đó có nhiều container cùng tồn tại song song.

Docker image được lưu ở đâu?

Docker image (ảnh đóng gói ứng dụng) được lưu trong các Docker Repositories. Có hai nơi cần biết:

Docker Hub (https://hub.docker.com) — repository công khai (public), nơi bạn tìm được base image cho rất nhiều công nghệ hoặc hệ điều hành (ví dụ Ubuntu, MySQL…).
Amazon ECR (Amazon Elastic Container Registry) — repository riêng tư (private) của bạn trên AWS, và cũng có cả phần công khai qua Amazon ECR Public Gallery (https://gallery.ecr.aws).

Docker so với Virtual Machine

Docker “hơi giống” công nghệ ảo hóa nhưng không hoàn toàn như vậy. Khác biệt nằm ở chỗ: với Docker, tài nguyên được chia sẻ với host, nhờ đó một server có thể chạy rất nhiều container.

Kiểu	Các tầng xếp từ dưới lên
Virtual Machine	Infrastructure → Host OS → Hypervisor → nhiều Guest OS (VM), mỗi VM có Apps riêng
Docker	Infrastructure → Host OS (EC2 Instance) → Docker Daemon → các container Apps chia sẻ chung host

Điểm mấu chốt: máy ảo phải cõng theo cả một Guest OS đầy đủ cho mỗi ứng dụng, còn Docker thì không — nên container nhẹ hơn và xếp được nhiều hơn trên cùng một máy.

Vòng đời cơ bản

Quy trình làm việc với Docker rất ngắn gọn: bạn viết một Dockerfile, build nó thành một image, rồi run image đó thành một container. Image có thể được push lên Docker Repository (ví dụ Amazon ECR) và sau đó được pull về bất cứ nơi nào cần chạy.

Dockerfile --build--> image --run--> container
image --push--> Docker Repository (Amazon ECR) --pull--> nơi cần chạy

2. Các dịch vụ quản lý container trên AWS

AWS có bốn dịch vụ bạn phải phân biệt được rành mạch khi đi thi:

Amazon Elastic Container Service (Amazon ECS) — nền tảng container của riêng Amazon.
Amazon Elastic Kubernetes Service (Amazon EKS) — Kubernetes (mã nguồn mở) được AWS quản lý.
AWS Fargate — nền tảng container serverless của riêng Amazon; hoạt động được với cả ECS và EKS.
Amazon ECR — nơi lưu container image.

3. Amazon ECS – EC2 Launch Type

ECS = Elastic Container Service. Trên ECS, việc “chạy Docker container trên AWS” được diễn đạt lại thành “chạy các ECS Task trên các ECS Cluster”.

Với EC2 Launch Type, bạn phải tự cấp phát và tự bảo trì hạ tầng — cụ thể là các EC2 instance nằm trong cluster. Mỗi EC2 instance phải chạy một ECS Agent để tự đăng ký (register) vào ECS Cluster. Sau khi đăng ký xong, phần việc còn lại — khởi động / dừng container — do AWS lo.

Nói cách khác: bạn chịu trách nhiệm về tầng máy, AWS chịu trách nhiệm về tầng container đặt lên đó.

4. Amazon ECS – Fargate Launch Type

Fargate Launch Type cũng chạy Docker container trên AWS, nhưng đảo ngược mô hình trách nhiệm ở trên: bạn không cấp phát hạ tầng — không có EC2 instance nào để quản lý. Tất cả đều Serverless.

Cách làm việc với Fargate:

Bạn chỉ cần tạo các task definition (định nghĩa task).
AWS chạy các ECS Task cho bạn, dựa trên lượng CPU / RAM bạn khai báo cần dùng.
Muốn scale thì chỉ cần tăng số lượng task. Đơn giản — không còn phải nghĩ về EC2 instance nữa.

5. IAM Roles cho ECS

Đây là chỗ rất dễ chọn sai đáp án, vì ECS có hai loại role hoàn toàn khác nhau ở hai tầng khác nhau.

EC2 Instance Profile (chỉ có ở EC2 Launch Type) được ECS Agent dùng, để:

Gọi API tới dịch vụ ECS.
Gửi container log tới CloudWatch Logs.
Pull Docker image từ ECR.
Tham chiếu dữ liệu nhạy cảm trong Secrets Manager hoặc SSM Parameter Store.

ECS Task Role thì ở tầng task:

Cho phép mỗi task có một role riêng biệt.
Dùng role khác nhau cho các ECS Service khác nhau mà bạn chạy — ví dụ Task A có role truy cập S3, Task B có role truy cập DynamoDB.
Task Role được định nghĩa trong task definition.

6. Tích hợp Load Balancer

ECS Task đứng sau load balancer để nhận traffic từ người dùng qua cổng 80/443. Cả ba loại load balancer đều dùng được, nhưng mức độ khuyến nghị rất khác nhau:

Loại Load Balancer	Trạng thái với ECS
Application Load Balancer	Được hỗ trợ, và phù hợp cho phần lớn use case
Network Load Balancer	Chỉ khuyến nghị cho use case throughput cao / hiệu năng cao, hoặc khi cần ghép với AWS PrivateLink
Classic Load Balancer	Được hỗ trợ nhưng không khuyến nghị — không có tính năng nâng cao, không dùng được với Fargate

7. Data Volumes với EFS

Container vốn không lưu dữ liệu bền, nên khi cần lưu trữ lâu dài và chia sẻ giữa nhiều task, bạn mount hệ thống file EFS vào ECS task.

Hoạt động với cả hai launch type — EC2 và Fargate.
Task chạy ở bất kỳ AZ nào cũng chia sẻ chung dữ liệu trong file system EFS đó.
Fargate + EFS = Serverless — cả tầng compute lẫn tầng lưu trữ đều không cần quản lý máy.
Use case: lưu trữ bền, chia sẻ, multi-AZ cho container của bạn.

8. ECS Service Auto Scaling

ECS Service Auto Scaling tự động tăng/giảm số lượng task mong muốn (desired number of ECS tasks). Nó dùng AWS Application Auto Scaling ở bên dưới.

Các metric dùng để scale:

ECS Service Average CPU Utilization — scale theo CPU.
ECS Service Average Memory Utilization — scale theo RAM.
ALB Request Count Per Target — metric đến từ ALB, tức số request trên mỗi target.

Các kiểu scaling:

Target Tracking — scale dựa trên một giá trị mục tiêu của một CloudWatch metric cụ thể.
Step Scaling — scale dựa trên một CloudWatch Alarm cụ thể.
Scheduled Scaling — scale theo ngày/giờ định trước, dành cho các biến động dự đoán được.

Luồng hoạt động thực tế theo ví dụ scale theo CPU: CPU của Service A tăng → CloudWatch Metric (ECS Service CPU Usage) ghi nhận → CloudWatch Alarm được trigger → Auto Scaling tạo thêm Task 3 (mới); nếu cần, ECS Capacity Providers cũng scale thêm hạ tầng bên dưới (bước này là tùy chọn).

Auto Scaling các EC2 instance bên dưới (EC2 Launch Type)

Với EC2 Launch Type, scale task thôi là không đủ — bạn phải thêm EC2 instance bên dưới để có chỗ đặt task. Có hai cách:

Auto Scaling Group Scaling — scale ASG dựa trên CPU Utilization, thêm EC2 instance dần theo thời gian.
ECS Cluster Capacity Provider — dùng để tự động cấp phát và scale hạ tầng cho các ECS Task của bạn. Capacity Provider được ghép với một Auto Scaling Group, và sẽ thêm EC2 instance khi thiếu capacity (CPU, RAM…).

9. Các mẫu tích hợp ECS thường gặp

ECS ít khi đứng một mình — nó thường được kích hoạt hoặc điều phối bởi các dịch vụ khác. Slide đưa ra bốn mẫu kiến trúc đáng nhớ.

ECS task được gọi bởi EventBridge

Client upload object lên S3 Bucket → S3 phát event → Amazon EventBridge khớp với một Rule: Run ECS Task → một Fargate Task (mới) được chạy trong ECS Cluster (trong VPC) → task dùng ECS Task Role (có quyền truy cập S3 và DynamoDB) để get object từ S3, xử lý, rồi save result vào Amazon DynamoDB.

ECS task được gọi theo lịch của EventBridge

Amazon EventBridge với một Rule: Run ECS Task chạy mỗi 1 giờ → khởi động một Fargate Task (mới) để làm batch processing trên Amazon S3, dùng ECS Task Role có quyền truy cập S3. Đây là cách làm cron job cho container.

ECS với SQS Queue

Message được đẩy vào một SQS Queue; các task (Task 1, Task 2, Task 3) của Service A poll for messages từ queue, và ECS Service Auto Scaling điều chỉnh số task theo lượng việc.

Bắt task bị stop bằng EventBridge

Khi container trong ECS Task exit, một EventBridge event được phát ra; bạn khai báo một Event Pattern để khớp đúng loại sự kiện này, rồi trigger SNS để gửi email cho administrator. Đây là cách dựng cảnh báo khi task chết bất thường.

10. Amazon ECR

ECR = Elastic Container Registry, dùng để lưu và quản lý Docker image trên AWS.

Có repository riêng tư và công khai (public qua Amazon ECR Public Gallery, https://gallery.ecr.aws).
Tích hợp trọn vẹn với ECS, và được hỗ trợ bởi Amazon S3 ở bên dưới.
Quyền truy cập được kiểm soát qua IAM — nên lỗi permission thì hãy soi lại policy.
Hỗ trợ quét lỗ hổng image (image vulnerability scanning), versioning, image tag, image lifecycle…

Trong kiến trúc điển hình, EC2 Instance trong ECS Cluster dùng một IAM Role để pull Docker Image A / Docker Image B từ ECR Repository.

11. Amazon EKS

Amazon EKS = Amazon Elastic Kubernetes Service — cách để chạy các Kubernetes cluster được quản lý trên AWS. Kubernetes là một hệ thống mã nguồn mở dùng để tự động triển khai, scale và quản lý ứng dụng đã được container hóa (thường là Docker).

EKS là giải pháp thay thế cho ECS: mục tiêu tương tự nhưng API khác nhau. Những điểm cần nhớ:

EKS hỗ trợ EC2 nếu bạn muốn triển khai worker node, hoặc Fargate nếu muốn container serverless.
Use case tiêu biểu: công ty đã dùng Kubernetes ở on-premises hoặc trên một cloud khác và muốn di chuyển sang AWS mà vẫn dùng Kubernetes.
Kubernetes là cloud-agnostic — dùng được trên bất kỳ cloud nào (Azure, GCP…).
Với nhiều region, hãy triển khai một EKS cluster cho mỗi region.
Thu thập log và metric bằng CloudWatch Container Insights.

Về cấu trúc mạng, một kiến trúc EKS điển hình trải trên 3 Availability Zone trong một VPC: mỗi AZ có một public subnet (chứa NAT Gateway và ELB) và một private subnet chứa các EKS node (mỗi node chạy các EKS Pod), toàn bộ worker node nằm trong một Auto Scaling Group. Các ELB đóng vai trò EKS Public Service LB (traffic từ ngoài) và EKS Private Service LB (traffic nội bộ).

Các loại node của EKS

Loại node	Đặc điểm
Managed Node Groups	EKS tạo và quản lý node (EC2 instance) cho bạn; node nằm trong một ASG do EKS quản lý; hỗ trợ On-Demand hoặc Spot Instances
Self-Managed Nodes	Bạn tự tạo node rồi đăng ký vào EKS cluster, được quản lý bởi một ASG; có thể dùng AMI dựng sẵn — Amazon EKS Optimized AMI; hỗ trợ On-Demand hoặc Spot Instances
AWS Fargate	Không cần bảo trì gì, không có node nào để quản lý

Data Volumes cho EKS

Muốn dùng lưu trữ bền trong EKS, bạn phải khai báo một StorageClass manifest trên EKS cluster, và nó hoạt động thông qua một driver tuân thủ Container Storage Interface (CSI). Các loại lưu trữ được hỗ trợ:

Amazon EBS
Amazon EFS (dùng được với Fargate)
Amazon FSx for Lustre
Amazon FSx for NetApp ONTAP

12. AWS App Runner

AWS App Runner là dịch vụ được quản lý hoàn toàn, giúp triển khai web application và API ở quy mô lớn một cách dễ dàng — không cần kinh nghiệm về hạ tầng.

Bạn bắt đầu từ source code hoặc từ một container image.
App Runner tự động build và deploy web app.
Có sẵn auto scaling, high availability, load balancer, encryption.
Hỗ trợ truy cập VPC — kết nối được tới database, cache, và các dịch vụ message queue.
Use case: web app, API, microservices, các trường hợp cần đưa lên production nhanh.

Luồng dùng App Runner rất gọn: chọn nguồn (Source Code hoặc Container Image (Docker)) → Configure Settings (vCPU, RAM, Auto Scaling, Health Check) → Create & Deploy → truy cập bằng một URL.

13. AWS App2Container (A2C)

AWS App2Container (A2C) là một công cụ CLI dùng để di chuyển và hiện đại hóa các web app viết bằng Java và .NET thành Docker Container.

Lift-and-shift ứng dụng đang chạy trên bare metal on-premises, trên máy ảo, hoặc trên bất kỳ cloud nào sang AWS.
Tăng tốc quá trình hiện đại hóa, không cần sửa code, di chuyển được cả ứng dụng legacy.
Sinh ra CloudFormation template (compute, network…).
Đăng ký container Docker đã sinh ra vào ECR.
Deploy tới ECS, EKS, hoặc App Runner.
Hỗ trợ CI/CD pipeline dựng sẵn.

Bốn bước của A2C:

Bước	Việc làm
Discover & Analyze	Lập danh mục ứng dụng (app inventory) và phân tích các phụ thuộc lúc chạy (runtime dependencies)
Extract & Containerize	Trích xuất ứng dụng cùng các phụ thuộc và tạo ra một Docker image
Create Deployment Artifacts	Sinh ra ECS Task và EKS Pod definition, tạo CI/CD pipeline và các hạ tầng khác (CloudFormation Template)
Deploy to AWS	Lưu Docker image vào Amazon ECR, rồi deploy tới ECS, EKS, hoặc App Runner

Tóm tắt nhanh

Chủ đề	Phải nhớ
Docker	Đóng gói app vào container, chạy giống nhau ở mọi nơi; chia sẻ tài nguyên với host nên nhẹ hơn VM (VM cần Hypervisor + Guest OS riêng)
Image registry	Docker Hub (public) · Amazon ECR (private + public gallery), backed by S3, quyền qua IAM, có vulnerability scanning
ECS EC2 Launch Type	Bạn tự cấp phát & bảo trì EC2 instance; mỗi instance chạy ECS Agent để register vào cluster; AWS lo start/stop container
ECS Fargate Launch Type	Không có EC2 để quản lý, Serverless; chỉ tạo task definition, khai CPU/RAM; scale = tăng số task
IAM cho ECS	EC2 Instance Profile cho ECS Agent (ECS API, CloudWatch Logs, pull ECR, Secrets Manager/SSM) · ECS Task Role cho từng task, khai trong task definition
Load balancer	ALB cho phần lớn use case · NLB cho throughput/hiệu năng cao hoặc PrivateLink · CLB không khuyến nghị và không dùng với Fargate
Storage cho ECS	Mount EFS cho cả hai launch type, chia sẻ dữ liệu multi-AZ; S3 không mount được như file system
ECS Service Auto Scaling	Scale số task (khác EC2 Auto Scaling scale instance); metric CPU, Memory, ALB Request Count Per Target; kiểu Target Tracking / Step / Scheduled
Capacity Provider	Ghép với ASG để tự thêm EC2 instance khi thiếu CPU/RAM cho task (chỉ cần với EC2 launch type)
Amazon EKS	Kubernetes được quản lý, API khác ECS, cloud-agnostic; node: Managed Node Groups / Self-Managed Nodes / Fargate; volume qua CSI (EBS, EFS, FSx for Lustre, FSx for NetApp ONTAP); một cluster mỗi region; log/metric bằng CloudWatch Container Insights
App Runner	Fully managed, từ source code hoặc container image tới URL, tự build + deploy, auto scaling + LB + encryption, hỗ trợ VPC access
App2Container	CLI migrate app Java/.NET thành container, không sửa code, sinh CloudFormation, push ECR, deploy ECS/EKS/App Runner