ComputeCompute

Part of the Cloud knowledge base — AWS deep dive. Complements DevOps Roadmap.

Tổng quan

Compute là nơi code của bạn thực sự chạy, và AWS cung cấp một phổ các lựa chọn đánh đổi giữa mức độ kiểm soát và sự tiện lợi. Ở một đầu là EC2 — các máy ảo thô nơi bạn sở hữu OS, runtime và việc scaling. Ở đầu kia là Lambda — các function thuần túy nơi bạn không sở hữu gì ngoài code còn AWS lo mọi server. Ở giữa là containers (ECS, EKS, App Runner) và các nền tảng ứng dụng được quản lý (Elastic Beanstalk). Nghệ thuật của compute trên AWS không nằm ở việc biết mọi service — mà nằm ở việc khớp hình dạng của workload (chạy dài hạn vs bùng nổ ngắn hạn, có trạng thái vs không trạng thái, ổn định vs biến động mạnh) với mô hình tốn ít công vận hành nhất cho mức độ tin cậy mà bạn cần.

Trang này đi dọc theo phổ đó, từ VM lên tới function. Nó bao gồm EC2 (họ instance, AMI, các phương án mua, user data), Auto Scaling (Launch Template và Auto Scaling Group biến một instance thành một fleet co giãn), ngăn xếp container (ECS với EC2 vs Fargate, EKS cho Kubernetes, ECR cho image, App Runner cho trường hợp đơn giản), Lambda (event source, concurrency, layer, cold start), và Batch cho các job batch quy mô lớn. Nó kết thúc bằng hướng dẫn ra quyết định — khi nào tôi nên chọn một VM, một container, hay một function? — bởi vì lựa chọn đầu tiên đó định hình mọi thứ phía sau.

Một cách nhìn hữu ích: mọi compute service đều trả lời cùng ba câu hỏi theo cách khác nhau — ai vá OS, ai quyết định chạy bao nhiêu bản sao, và ai trả tiền cho thời gian nhàn rỗi? Trên EC2 câu trả lời cho cả ba là “bạn”. Trên Fargate bạn ngừng vá host. Trên Lambda bạn ngừng trả tiền cho thời gian nhàn rỗi hoàn toàn. Chỉ leo lên nấc thang đúng bằng mức mà workload cho phép, không hơn.

Tại sao lựa chọn compute lại quan trọng

Quyết định về compute là quyết định bạn xem lại ít nhất mà trả giá nhiều nhất. Một workload được xây như một monolith trên EC2 tự quản lý sẽ tích lũy công vá lỗi, scaling và trực on-call mỗi ngày; cũng workload đó dưới dạng một service Fargate hoặc một Lambda sẽ trút bỏ phần lớn gánh nặng ấy. Nhưng leo nấc thang không miễn phí — Lambda áp trần 15 phút và độ trễ cold-start, container áp một đường cong học tập về orchestration, và serverless có thể tốn nhiều hơn một VM reserved ở mức tải cao ổn định. Chọn đúng nghĩa là thành thật về hình dạng thực của workload thay vì theo phản xạ chọn mô hình mới nhất.

Kiến thức nền tảng

EC2 — Elastic Compute Cloud

EC2 cung cấp các máy ảo có thể thay đổi kích thước (“instances”) được khởi chạy từ một image (AMI) lên một loại instance đã chọn, bên trong một VPC subnet, kèm storage gắn vào và một security group. Đây là compute service lâu đời và linh hoạt nhất của AWS và là nền tảng bên dưới nhiều service khác (EKS node, ECS on EC2, EMR, và nhiều hơn nữa đều chạy trên nó).

Họ instance nhóm phần cứng theo hồ sơ workload. Tên mã hóa họ, thế hệ và kích thước — ví dụ m7g.xlarge là họ m, thế hệ 7, biến thể g (Graviton/ARM), ở kích thước xlarge.

Họ	Tối ưu cho	Ví dụ	Trường hợp dùng điển hình
T (burstable)	CPU nền + tín dụng burst	t3, t4g	Máy dev, web ít lưu lượng, microservice có thời gian nhàn rỗi
M (general)	Cân bằng CPU:bộ nhớ (≈1:4)	m6i, m7g	Web/app server, database nhỏ, hầu hết workload
C (compute)	CPU cao so với bộ nhớ	c6i, c7g	Batch, encoding, HPC, game server, API thông lượng cao
R (memory)	Bộ nhớ cao (≈1:8)	r6i, r7g	Cache in-memory, database lớn, analytics
X / u (bộ nhớ lớn)	Bộ nhớ cực lớn (hàng TB)	x2idn, u-6tb1	SAP HANA, DB in-memory khổng lồ
I / D (storage)	Thông lượng NVMe/HDD cục bộ	i4i, d3	NoSQL, data warehouse, hệ thống file phân tán
P / G / Inf / Trn (tăng tốc)	GPU / bộ tăng tốc ML	p5, g5, inf2, trn1	Training, inference, đồ họa, ML

Graviton (ARM): các instance có hậu tố g (m7g, c7g, t4g) chạy chip ARM của chính AWS và thường mang lại hiệu năng/giá tốt hơn ~20–40% so với các bản x86 tương đương. Nếu ngăn xếp của bạn build sạch cho ARM (hầu hết các ngôn ngữ thông dịch/JIT và các ngôn ngữ biên dịch hiện đại đều được), Graviton thường là lợi ích dễ dàng.

AMI (Amazon Machine Images) là template mà instance boot từ đó — một snapshot của root volume cộng với metadata (kiến trúc, loại ảo hóa, block-device mapping). Chúng đến dưới dạng do AWS cung cấp (Amazon Linux 2023, Ubuntu, Windows), Marketplace, hoặc golden image của riêng bạn được “nướng” sẵn bằng các công cụ như Packer. Nướng các phụ thuộc vào một AMI (“hạ tầng bất biến”) giúp việc khởi chạy nhanh và tất định; giải pháp thay thế là provisioning lúc boot (xem user data).

User data là một script (shell hoặc cloud-init) được truyền vào lúc khởi chạy và chạy một lần khi boot lần đầu — hook bootstrapping để cài package, kéo config, hoặc đăng ký với một cluster. Giữ nó nhỏ và idempotent; script user-data nặng làm chậm việc khởi chạy và là nguồn phổ biến của các lỗi kiểu “chạy được khi relaunch, hỏng khi scale-out”. Thay vào đó hãy nướng phần cài đặt nặng vào AMI.

Instance metadata service (IMDS): mọi instance có thể truy vấn http://169.254.169.254/ để lấy metadata của chính nó (instance ID, region, credential của IAM role). Luôn yêu cầu IMDSv2 (dựa trên token) — IMDSv1 là vector trong nhiều vụ vi phạm SSRF-đến-đánh-cắp-credential nổi tiếng.

Các phương án mua (cũng được đề cập ở trang Tổng quan):

Phương án	Chiết khấu	Cam kết	Dùng cho
On-Demand	0% (mốc cơ sở)	Không	Biến động, ngắn hạn, khó dự đoán
Savings Plans	tới ~72%	1/3 năm $/giờ	Compute nền ổn định
Reserved Instances	tới ~72%	1/3 năm, loại cụ thể	Sử dụng ổn định, dễ dự đoán
Spot	tới ~90%	Không (thông báo thu hồi 2 phút)	Chịu lỗi, có thể gián đoạn
Dedicated Hosts	phụ phí	Tùy chọn	Cấp phép BYOL, cách ly vật lý

Auto Scaling Groups và Launch Templates

Một instance đơn lẻ là một thú cưng với một điểm lỗi duy nhất. Một Auto Scaling Group (ASG) biến nó thành đàn gia súc: một fleet được quản lý duy trì số lượng mục tiêu, thay thế các instance không khỏe, và phình ra hay co lại theo nhu cầu trên nhiều AZ.

• Launch Template — công thức cho một instance: AMI, (các) loại instance, key pair, security group, IAM instance profile, user data, block device. Template có phiên bản (Launch Configuration, dạng cũ hơn, thì không — luôn dùng template).
• Desired / min / max capacity — ASG giữ desired instance chạy, không bao giờ ít hơn min hoặc nhiều hơn max.
• Health check — EC2 status check và/hoặc ELB health check; một instance lỗi bị chấm dứt và thay thế tự động.
• Scaling policy — target tracking (giữ CPU trung bình ở 50%), step scaling (thêm N khi một CloudWatch alarm kích hoạt), scheduled (scale lên trước giờ làm việc), hoặc predictive (dự báo nhu cầu bằng ML).
• Multi-AZ — cung cấp subnet ở ≥2 AZ và ASG cân bằng instance giữa chúng, để một AZ hỏng chỉ mất một phần dung lượng.

ASG kết hợp với một Application Load Balancer (ALB) hoặc Network Load Balancer (NLB): ASG đăng ký instance mới với một target group, LB ngừng định tuyến tới các instance đang draining, và việc thay thế cuốn chiếu diễn ra không downtime. Đây là mẫu web-tier chịu lỗi kinh điển.

Elastic Beanstalk

Elastic Beanstalk là một lớp PaaS trên EC2, ASG, ELB và CloudWatch: bạn đưa cho nó code (một JAR, một container, một zip) cộng với một nền tảng (Java, Node, Python, .NET, Docker) và nó provisioning cùng quản lý ngăn xếp bên dưới cho bạn, bao gồm rolling deploy và dashboard sức khỏe. Đây là đường vào nhanh cho các đội muốn “chỉ cần deploy app của tôi” mà không phải tự nối dây các primitive — nhưng bạn vẫn giữ quyền truy cập vào các tài nguyên mà nó tạo ra. Trong thực hành hiện đại nó phần lớn đã bị thay thế bởi container (ECS/App Runner) và IaC, nhưng nó vẫn là lựa chọn hợp lý cho các web app đơn giản và cho việc đưa một app legacy lên AWS với tối thiểu công sửa lại.

Khái niệm chính

Containers trên AWS

Container đóng gói một app cùng các phụ thuộc của nó vào một image di động. AWS cung cấp một ngăn xếp đầy đủ quanh chúng:

ECR — Elastic Container Registry là registry image riêng tư được quản lý. Push image bằng docker push, quét chúng tìm CVE khi push, áp lifecycle policy để hết hạn các tag cũ, và pull chúng vào ECS/EKS/Lambda. Đây là nơi mặc định cho image của bạn.

ECS — Elastic Container Service là orchestrator container của chính AWS — đơn giản hơn Kubernetes, tích hợp sâu với AWS. Bạn định nghĩa một task definition (container, CPU/bộ nhớ, IAM role, port, env) và chạy nó dưới dạng một service (chạy dài hạn, có load-balance, tự động scale) hoặc một task (chạy một lần/batch). ECS chạy trên hai launch type:

	ECS on EC2	ECS on Fargate
Bạn quản lý	Fleet host EC2 (vá, scaling, dung lượng)	Không gì bên dưới task
Tính phí	Theo instance EC2 (trả cho cả host)	Theo vCPU/GB-giây của task
Tốt nhất cho	Mật độ cao, ổn định; instance GPU/đặc biệt; bin-packing để tiết kiệm	Tải biến động, đội nhỏ, không muốn lo vận hành
Đánh đổi	Rẻ hơn khi tận dụng cao ổn định; nhiều vận hành hơn	Không vận hành host; có thể tốn hơn ở quy mô ổn định cao

Nguyên tắc kinh nghiệm: bắt đầu trên Fargate (không server nào phải quản lý), và chỉ chuyển sang ECS-on-EC2 khi bạn có đủ workload ổn định, dày đặc để việc sở hữu host rõ ràng có lợi, hoặc bạn cần các tính năng instance mà Fargate thiếu (GPU, loại instance cụ thể, chế độ privileged).

EKS — Elastic Kubernetes Service là Kubernetes upstream được quản lý. AWS chạy control plane (tính sẵn sàng cao, được vá); bạn chạy workload trên managed node group (EC2), Fargate profile (pod serverless), hoặc Karpenter (autoscaling node nhanh, linh hoạt). Chọn EKS khi bạn muốn hệ sinh thái Kubernetes (Helm, operator, tính di động giữa các cloud, nguồn nhân lực dồi dào) và có thể hấp thụ sự phức tạp vận hành của nó. Chọn ECS khi bạn muốn con đường đơn giản nhất và hài lòng với việc gắn với AWS. EKS mạnh hơn và di động hơn; ECS đơn giản hơn và rẻ hơn để vận hành.

App Runner là service “chỉ cần chạy container/web app của tôi”: trỏ nó vào một image trong ECR hoặc một source repo, và nó build, deploy, load-balance, kết thúc TLS, và autoscale (xuống tận zero) một web service — không có VPC, LB hay cluster nào phải cấu hình. Đây là con đường nhanh nhất từ container tới một URL HTTPS công khai, lý tưởng cho các web app và API không trạng thái nơi bạn không muốn phải nghĩ về hạ tầng. Đánh đổi là ít kiểm soát và ít núm điều chỉnh hơn ECS/EKS.

Ra quyết định trong nhóm container: App Runner cho web service đơn giản nhất → ECS/Fargate cho workload container tổng quát trên AWS → EKS khi bạn cần Kubernetes cụ thể → ECS-on-EC2 khi chi phí/kiểm soát ở mức host biện minh cho công vận hành.

Lambda — serverless functions

Lambda chạy code của bạn để phản hồi các event mà không có server nào phải quản lý, scaling tự động, và tính phí theo lượt gọi (làm tròn tới mili-giây, tính giá theo bộ nhớ×thời lượng). Bạn upload một function (zip hoặc container image tới 10 GB), chọn một runtime (Node, Python, Java, Go, .NET, Ruby, hoặc tùy chỉnh), đặt bộ nhớ (128 MB–10 GB; CPU scale theo bộ nhớ), và AWS chạy nó theo yêu cầu.

Event source — sức mạnh của Lambda nằm ở bề rộng các thứ có thể kích hoạt nó:

Nguồn	Mẫu	Ví dụ
API Gateway / Function URL	Request/response đồng bộ	REST/HTTP API, webhook
S3	Bất đồng bộ theo event object	Resize ảnh khi upload
SQS / SNS / EventBridge	Queue/pub-sub/event bus	Xử lý bất đồng bộ tách rời
DynamoDB / Kinesis Streams	Stream (dựa trên poll)	Change-data-capture, ETL thời gian thực
CloudWatch Events / Scheduler	Cron	Job theo lịch

Concurrency là mô hình scaling và chi phí cốt lõi. Mỗi lượt gọi đồng thời là một instance function; Lambda scale theo chiều ngang bằng cách thêm instance tới giới hạn tài khoản của bạn (mặc định 1.000, có thể nâng).

• Reserved concurrency giới hạn số instance tối đa của một function (bảo vệ các database phía sau khỏi bị quá tải, và đảm bảo một mức sàn cho các function quan trọng).
• Provisioned concurrency giữ N instance ấm và đã khởi tạo sẵn — cách khắc phục độ trễ nhạy với cold-start, có tính phí.

Cold start: lượt gọi đầu tiên trên một instance mới phải trả chi phí khởi tạo (tải code, khởi động runtime, chạy init). Thường là hàng chục đến hàng trăm ms; tệ hơn với các deployment lớn, function gắn VPC (trong lịch sử), và runtime nặng (JVM/.NET). Giảm nhẹ: giữ package nhỏ, dùng provisioned concurrency cho các đường nhạy độ trễ, chọn runtime nhẹ hơn, và lazy-load các phụ thuộc nặng. Hầu hết workload bất đồng bộ đơn giản là không quan tâm tới cold start.

Layer đóng gói các phụ thuộc hoặc runtime chung tách khỏi code function — một .zip được mount vào /opt lúc runtime. Chúng giữ package function nhỏ và chia sẻ thư viện chung giữa các function, dù nhiều đội giờ ưa dùng container image cho các bộ phụ thuộc phức tạp.

Lambda là trái tim của serverless trên AWS — xem trang serverless của DevOps và tài liệu serverless của AWS để có bức tranh rộng hơn (Step Functions, EventBridge, SAM, kiến trúc hướng sự kiện).

Batch

AWS Batch chạy các job điện toán batch quy mô lớn: bạn nộp job vào các queue, định nghĩa compute environment (fleet EC2/Fargate/Spot được quản lý, scale từ zero), và Batch lên lịch, đặt chỗ và scale các container để chạy chúng, thử lại và báo cáo trong quá trình. Nó tỏa sáng cho công việc song song hồn nhiên (embarrassingly parallel) — genomics, rendering, mô phỏng Monte-Carlo, ETL — nơi bạn muốn hàng nghìn container tạm thời trên dung lượng Spot giá rẻ mà không phải tự xây scheduler. Hãy hình dung nó như “cron/queue + fleet container tự động scale, được quản lý”. Với các pipeline nặng về orchestration, hãy ghép nó với Step Functions.

Chọn compute: VM vs container vs serverless

Không có người thắng phổ quát; hãy khớp mô hình với workload.

Chiều	EC2 (VM)	Containers (ECS/EKS)	Lambda (serverless)
Đơn vị	Cả máy	Container/pod	Function
Bạn quản lý	OS + runtime + scaling	Container + (có thể) host	Chỉ code
Scaling	ASG (phút)	Autoscaling task/pod (giây)	Tự động (ms), tới zero
Chi phí nhàn rỗi	Trả khi đang chạy	Trả khi đang chạy	Bằng zero khi nhàn rỗi
Runtime tối đa	Không giới hạn	Không giới hạn	15 phút
Trạng thái	Bất kỳ	Bất kỳ (với volume)	Không trạng thái (tạm thời)
Tốt nhất cho	Legacy, có license, phần cứng đặc biệt, kiểm soát toàn phần	Microservice, workload di động, service ổn định	Hướng sự kiện, biến động, keo dán, API có thời gian nhàn rỗi

Đường ra quyết định thực tế:

1. Hướng sự kiện, ngắn, biến động, hoặc code keo dán? → Lambda. Chi phí nhàn rỗi bằng zero và không vận hành thắng áp đảo.
2. Service chạy dài hạn, cần hệ sinh thái container hoặc lưu lượng ổn định? → Containers. Fargate trước; EKS nếu bạn cần Kubernetes; ECS-on-EC2 nếu mật độ/chi phí biện minh cho việc sở hữu host.
3. App legacy, nhu cầu OS/kernel đặc biệt, phần mềm có license, GPU/HPC, hoặc kiểm soát toàn phần? → EC2.
4. Job batch song song ồ ạt? → Batch (trên Spot).

Cạm bẫy phổ biến: ép một job dài hơn 15 phút vào Lambda (dùng Batch/container), chạy một API ít lưu lượng biến động trên EC2 luôn-bật (lãng phí — dùng Lambda/App Runner), hoặc dùng EKS cho ba microservice (chi phí Kubernetes mà không có lợi ích — dùng ECS/Fargate).

Ví dụ thực hành: Launch Template + Auto Scaling Group

Một web tier chịu lỗi, tự chữa lành trong Terraform — một launch template cấp cho một ASG trải khắp các AZ đằng sau một target group, scale theo CPU.

# Launch template: the recipe for each instance
resource "aws_launch_template" "web" {
  name_prefix   = "web-"
  image_id      = data.aws_ami.al2023.id      # latest Amazon Linux 2023
  instance_type = "t3.micro"

  iam_instance_profile { name = aws_iam_instance_profile.web.name }
  vpc_security_group_ids = [aws_security_group.web.id]

  # Require IMDSv2 — never leave IMDSv1 open
  metadata_options {
    http_tokens   = "required"
    http_endpoint = "enabled"
  }

  # Bootstrap on first boot; keep it minimal — bake the rest into the AMI
  user_data = base64encode(<<-EOF
    #!/bin/bash
    dnf install -y nginx
    systemctl enable --now nginx
  EOF
  )

  tag_specifications {
    resource_type = "instance"
    tags = { Name = "web", Environment = "prod" }
  }
}

# Auto Scaling Group: maintain a fleet across 2+ AZs, register with the LB
resource "aws_autoscaling_group" "web" {
  name                = "web-asg"
  min_size            = 2
  max_size            = 6
  desired_capacity    = 2
  vpc_zone_identifier = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  target_group_arns   = [aws_lb_target_group.web.arn]
  health_check_type   = "ELB"          # replace instances the LB deems unhealthy

  launch_template {
    id      = aws_launch_template.web.id
    version = "$Latest"
  }

  # Rolling replacement on template change — no downtime
  instance_refresh {
    strategy = "Rolling"
    preferences { min_healthy_percentage = 90 }
  }

  tag {
    key                 = "Name"
    value               = "web"
    propagate_at_launch = true
  }
}

# Target-tracking policy: hold average CPU at 50%
resource "aws_autoscaling_policy" "cpu" {
  name                   = "cpu-target-50"
  autoscaling_group_name = aws_autoscaling_group.web.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification { predefined_metric_type = "ASGAverageCPUUtilization" }
    target_value = 50.0
  }
}

Điều này mang lại cho bạn: nếu một instance chết hoặc một AZ hỏng, ASG thay thế dung lượng và ALB chỉ định tuyến tới các target khỏe mạnh — không cần con người can thiệp. Khi CPU trung bình vượt 50%, nhóm scale ra (tới 6); khi tải giảm, nó scale trở lại vào (xuống 2). Thay đổi launch template kích hoạt một lần refresh cuốn chiếu giữ 90% khỏe mạnh trong suốt quá trình. Đây là web tier “gia súc chứ không phải thú cưng” mẫu mực.

Best Practices

1. Ưu tiên instance Graviton (ARM) nơi ngăn xếp của bạn hỗ trợ — t4g/m7g/c7g thường mang lại hiệu năng/giá tốt hơn 20–40% so với x86. Test build của bạn trên ARM (hầu hết ngôn ngữ chạy được ngay) và mặc định dùng Graviton cho workload mới; chiết khấu về cơ bản là miễn phí.
2. Right-size không ngừng với Compute Optimizer — mục chi lớn nhất trong hầu hết hóa đơn là compute quá cỡ, tận dụng thấp. Xem xét đề xuất hằng tháng và giảm cỡ; một instance chạy ở 8% CPU là lớn hơn vài cỡ.
3. Dùng Auto Scaling Group, không bao giờ dùng instance đơn lẻ, cho bất cứ thứ gì quan trọng — một instance đơn lẻ là một điểm lỗi duy nhất. Một ASG với min ≥ 2 trên ≥2 AZ tự chữa lành và sống sót qua một sự cố AZ; đó là khả năng chịu lỗi rẻ nhất bạn có thể mua.
4. Luôn dùng Launch Template thay vì Launch Configuration — template có phiên bản, hỗ trợ các tính năng mới nhất (mixed instances, Spot, ép buộc IMDSv2), và tích hợp với instance refresh. Launch Configuration đã bị deprecated.
5. Yêu cầu IMDSv2 trên mọi instance (http_tokens = required) — IMDSv1 đã tạo điều kiện cho nhiều vụ vi phạm SSRF-đến-đánh-cắp-credential nổi tiếng. Ép buộc nó trong launch template và trên toàn tổ chức.
6. Gắn IAM role vào instance, không bao giờ nhúng credential — dùng một instance profile để app nhận credential ngắn hạn, được xoay vòng từ IMDS. Key dài hạn được nướng vào user data hoặc config là bí mật bị rò rỉ kinh điển.
7. Nướng golden AMI; giữ user data mỏng và idempotent — provisioning nặng lúc boot làm chậm scale-out và hỏng thất thường dưới tải. Nướng sẵn các phụ thuộc bằng Packer và để dành user data cho cấu hình chặng cuối; coi AMI là bất biến và roll forward.
8. Pha Spot cho dung lượng chịu lỗi — chạy batch có thể gián đoạn, CI, và web không trạng thái trên Spot (giảm tới 90%) qua chính sách mixed-instances của ASG với nhiều loại instance để có một hồ dung lượng sâu. Luôn xử lý thông báo gián đoạn 2 phút (drain/checkpoint).
9. Mặc định dùng Fargate cho container; chỉ chuyển sang EC2 khi mật độ có lợi — Fargate loại bỏ việc vá host và quản lý dung lượng. Chỉ sở hữu host khi bạn có workload ổn định, dày đặc nơi bin-packing rõ ràng tiết kiệm tiền, hoặc cần các tính năng instance mà Fargate thiếu.
10. Chọn ECS cho sự đơn giản gắn với AWS, EKS chỉ khi bạn thực sự cần Kubernetes — EKS đem lại chi phí vận hành thực (nâng cấp, add-on, mạng). Chọn nó vì hệ sinh thái, tính di động và nguồn nhân lực; nếu không ECS/Fargate mang lại cùng kết quả với ít phức tạp hơn nhiều.
11. Quét mọi image trong ECR và ép buộc lifecycle policy — bật scan-on-push để bắt CVE trước khi deploy, và cho hết hạn các image chưa gắn tag/cũ để registry không tích lũy rác dễ tổn thương, tốn kém.
12. Chọn Lambda khi workload hướng sự kiện và bùng nổ — chi phí nhàn rỗi bằng zero và không vận hành khiến nó là mặc định cho keo dán, webhook và API biến động. Nhưng tôn trọng các giới hạn của nó: trần 15 phút, tính không trạng thái, và cold start loại nó khỏi các workload dài hoặc độ trễ phẳng.
13. Thuần hóa cold start và concurrency của Lambda một cách có chủ đích — dùng provisioned concurrency cho các đường đồng bộ nhạy độ trễ, giữ package nhỏ, chọn runtime nhẹ, và đặt reserved concurrency để bảo vệ các database phía sau khỏi một cơn scaling ồ ạt.
14. Khớp mô hình mua với hình dạng sử dụng — on-demand cho biến động/chưa biết, Savings Plans cho phần nền ổn định (sau 2–3 tháng dữ liệu), Spot cho phần có thể gián đoạn, Reserved cho các instance cụ thể ổn định. Đừng bao giờ cam kết một mức nền mà bạn chưa đo.
15. Diệt compute nhàn rỗi và bị bỏ quên — instance đã stopped vẫn tính phí cho EBS volume của chúng, load balancer rỗng và NAT Gateway nhàn rỗi tính phí theo giờ, và các máy dev bị quên chạy suốt cuối tuần. Tự động hóa dọn dẹp và lên lịch cho non-prod dừng sau giờ làm.
16. Định nghĩa mọi compute bằng Infrastructure as Code — launch template, ASG, task definition và Lambda function thuộc về Terraform/CloudFormation/CDK. Compute bấm-tay-trên-console là không thể tái lập và không thể xây lại sau một sự cố.

Tài liệu tham khảo

• roadmap.sh — DevOps Roadmap
• Amazon EC2 Documentation
• EC2 Instance Types
• AWS Graviton Processor
• Amazon Machine Images (AMIs)
• Instance Metadata Service (IMDSv2)
• Amazon EC2 Auto Scaling
• Launch Templates
• AWS Elastic Beanstalk
• Amazon ECS Documentation
• AWS Fargate
• Amazon EKS Documentation
• Amazon ECR Documentation
• AWS App Runner
• AWS Lambda Documentation
• Lambda Concurrency
• AWS Batch Documentation
• Compute Services Overview

# Launch template: the recipe for each instance
resource "aws_launch_template" "web" {
  name_prefix   = "web-"
  image_id      = data.aws_ami.al2023.id      # latest Amazon Linux 2023
  instance_type = "t3.micro"

  iam_instance_profile { name = aws_iam_instance_profile.web.name }
  vpc_security_group_ids = [aws_security_group.web.id]

  # Require IMDSv2 — never leave IMDSv1 open
  metadata_options {
    http_tokens   = "required"
    http_endpoint = "enabled"
  }

  # Bootstrap on first boot; keep it minimal — bake the rest into the AMI
  user_data = base64encode(<<-EOF
    #!/bin/bash
    dnf install -y nginx
    systemctl enable --now nginx
  EOF
  )

  tag_specifications {
    resource_type = "instance"
    tags = { Name = "web", Environment = "prod" }
  }
}

# Auto Scaling Group: maintain a fleet across 2+ AZs, register with the LB
resource "aws_autoscaling_group" "web" {
  name                = "web-asg"
  min_size            = 2
  max_size            = 6
  desired_capacity    = 2
  vpc_zone_identifier = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  target_group_arns   = [aws_lb_target_group.web.arn]
  health_check_type   = "ELB"          # replace instances the LB deems unhealthy

  launch_template {
    id      = aws_launch_template.web.id
    version = "$Latest"
  }

  # Rolling replacement on template change — no downtime
  instance_refresh {
    strategy = "Rolling"
    preferences { min_healthy_percentage = 90 }
  }

  tag {
    key                 = "Name"
    value               = "web"
    propagate_at_launch = true
  }
}

# Target-tracking policy: hold average CPU at 50%
resource "aws_autoscaling_policy" "cpu" {
  name                   = "cpu-target-50"
  autoscaling_group_name = aws_autoscaling_group.web.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification { predefined_metric_type = "ASGAverageCPUUtilization" }
    target_value = 50.0
  }
}