AWS cho Developer: Hiểu đúng từ đầu để không phải khóc sau

Mình nhớ lần đầu tiên được giao task "deploy cái app này lên AWS đi", cảm giác lúc đó là mở console lên rồi... đứng hình. Có cả trăm service hiện ra, không biết bắt đầu từ đâu. EC2? S3? RDS? Cái nào dùng trước? Cái nào liên quan nhau?

Nếu bạn đang ở trạng thái đó, bài này viết đúng cho bạn. Mình sẽ không đi theo kiểu liệt kê service cho có mà sẽ giải thích theo cách mà mình ước gì có người nói với mình từ đầu.

AWS không phải là một cái gì đó nó là một hệ sinh thái

AWS (Amazon Web Services) hiện có hơn 200 service. Nhưng thực tế, phần lớn các project từ startup đến enterprise chỉ xoay quanh khoảng 15-20 service cốt lõi. Vấn đề là nếu không hiểu cách chúng liên kết với nhau, bạn sẽ dùng từng cái một cách rời rạc và rất dễ tạo ra kiến trúc vừa tốn tiền vừa không secure.

Lý do developer cần biết AWS dù bạn không phải DevOps là vì ranh giới giữa dev và ops ngày càng mờ. Bạn cần hiểu app của mình đang chạy ở đâu, như thế nào, và tại sao nó lại fail lúc 2 giờ sáng. Không ai muốn bị gọi dậy mà không biết mình đang nhìn vào cái gì.

Infrastructure toàn cầu: Region, AZ và Edge Location

AWS chia hạ tầng theo 3 tầng:

• Region: Một vùng địa lý (ví dụ ap-southeast-1 là Singapore). Mỗi Region hoàn toàn độc lập với nhau.
• Availability Zone (AZ): Trong mỗi Region có nhiều AZ thực chất là các data center riêng biệt, cách nhau vài chục km, có điện và network độc lập. Singapore có 3 AZ: ap-southeast-1a, 1b, 1c.
• Edge Location: Các điểm phân phối nội dung (CDN) của CloudFront, gần người dùng cuối hơn Region.

Tại sao quan trọng? Vì khi deploy production, bạn phải spread app ra nhiều AZ. Nếu một AZ die (thiên tai, mất điện), app vẫn chạy ở AZ còn lại. Đây là nền tảng của high availability không phải magic, chỉ là redundancy có tổ chức.

Với team Việt Nam, Singapore (ap-southeast-1) thường là lựa chọn đầu tiên vì latency thấp. Một số project lớn hơn sẽ dùng thêm Tokyo hoặc Mumbai tùy user base.

Core services: Bức tranh toàn cảnh

Thay vì liệt kê, mình sẽ nhóm theo vai trò trong một app thực tế:

Một full-stack app điển hình sẽ dùng: EC2 hoặc ECS để chạy backend, RDS cho database, S3 cho static files, ALB để load balance, Route 53 cho DNS, và CloudFront nếu cần CDN. Đó là bộ combo cơ bản nhất.

IAM: Phần mà hầu hết mọi người setup sai

IAM (Identity and Access Management) là hệ thống phân quyền của AWS. Nghe có vẻ boring nhưng đây là thứ mà nếu bạn setup sai, hậu quả có thể rất nặng từ data leak đến bill AWS tăng đột biến vì ai đó dùng credentials của bạn để mine crypto.

Có 4 khái niệm cần nắm:

• User: Tài khoản cho người (hoặc CI/CD system). Nên bật MFA bắt buộc.
• Group: Nhóm user, gán policy cho group thay vì từng user.
• Role: Danh tính tạm thời, dành cho service (EC2 cần đọc S3, Lambda cần ghi DynamoDB...). Đây là cách đúng để grant permission cho AWS service.
• Policy: Document JSON định nghĩa permission cụ thể.

Nguyên tắc Least Privilege chỉ cấp đúng quyền cần thiết, không hơn. Theo kinh nghiệm của mình, lỗi phổ biến nhất là attach AdministratorAccess cho mọi thứ cho nhanh. Làm vậy ở local thì thôi, nhưng lên production mà còn vậy là đang tạo time bomb.

Một ví dụ policy đúng chuẩn cho Lambda chỉ được đọc một S3 bucket cụ thể:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": [
7        "s3:GetObject",
8        "s3:ListBucket"
9      ],
10      "Resource": [
11        "arn:aws:s3:::my-specific-bucket",
12        "arn:aws:s3:::my-specific-bucket/*"
13      ]
14    }
15  ]
16}

Chú ý: không dùng * cho Resource nếu không thực sự cần. Và tuyệt đối không hardcode Access Key vào code dùng IAM Role cho EC2/Lambda, dùng environment variable hoặc Secrets Manager cho trường hợp còn lại.

VPC: Mạng riêng của bạn trên cloud

VPC (Virtual Private Cloud) là network layer của bạn trên AWS. Mọi resource đều nằm trong một VPC nào đó. Nếu không tạo, AWS sẽ dùng Default VPC nhưng production thì đừng dùng Default VPC, tạo riêng đi.

Cấu trúc cơ bản của một VPC production-ready:

1VPC: 10.0.0.0/16
2├── Public Subnet (10.0.1.0/24)  → ALB, NAT Gateway, Bastion
3├── Private Subnet (10.0.2.0/24) → EC2, ECS tasks, RDS
4└── Database Subnet (10.0.3.0/24) → RDS, ElastiCache

• Public Subnet: Có route ra Internet Gateway, resource ở đây có thể nhận traffic từ internet.
• Private Subnet: Không có direct internet access. App server nằm ở đây bên ngoài không reach được trực tiếp.
• NAT Gateway: Đặt ở public subnet, cho phép resource ở private subnet gọi ra internet (để pull package, gọi external API) nhưng không cho phép chiều ngược lại.

Anh em lưu ý: RDS và internal service luôn nên nằm ở private subnet. Mình đã thấy nhiều case database bị expose ra public subnet vì "tiện config" đó là rủi ro bảo mật rất lớn.

Kiến trúc reference cho full-stack app

Đây là pattern mình hay dùng cho các project web app thông thường:

1User → Route 53 → CloudFront → ALB
2                                 ↓
3                          ECS (API containers)
4                                 ↓
5                    RDS (PostgreSQL) + ElastiCache (Redis)
6
7S3 ← Static assets (React build)
8CloudFront ← serve static từ S3

Flow cụ thể:

1. User gõ domain → Route 53 resolve → CloudFront
2. Static assets (React/Next.js) serve thẳng từ S3 qua CloudFront
3. API calls đi qua ALB → ECS tasks chạy trong private subnet
4. ECS tasks kết nối RDS và Redis trong database subnet
5. ECS tasks dùng IAM Role để access S3, Secrets Manager không cần hardcode credential

Kiến trúc này scale tốt, cost predictable, và security layer rõ ràng. Với traffic thấp có thể simplify xuống EC2 thay ECS, nhưng pattern network thì giữ nguyên.

Well-Architected Framework: 6 trụ cột AWS đúc kết

AWS có một framework gọi là Well-Architected với 6 pillars đây là bộ câu hỏi để tự review kiến trúc của mình:

Mình thấy cái này hay ở chỗ nó không phải checklist cứng mà là mindset. Khi design một feature mới, chạy qua 6 câu hỏi này sẽ bắt được rất nhiều vấn đề tiềm ẩn trước khi ship.

Setup AWS CLI làm một lần, dùng mãi

Thay vì click mãi trên console, setup CLI để làm việc nhanh hơn nhiều:

1# Cài AWS CLI v2
2# macOS
3brew install awscli
4
5# Linux
6curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
7unzip awscliv2.zip && sudo ./aws/install
8
9# Kiểm tra
10aws --version

Config credentials:

1aws configure
2# AWS Access Key ID: [your key]
3# AWS Secret Access Key: [your secret]
4# Default region name: ap-southeast-1
5# Default output format: json

Nếu bạn làm việc với nhiều AWS account (dev, staging, prod), dùng named profiles:

1aws configure --profile myproject-dev
2aws configure --profile myproject-prod
3
4# Dùng profile cụ thể
5aws s3 ls --profile myproject-dev
6
7# Hoặc set default cho session
8export AWS_PROFILE=myproject-dev

File config sẽ được lưu ở ~/.aws/credentials và ~/.aws/config. Mình khuyên dùng profile thay vì switch key thủ công tránh nhầm lẫn giữa các environment, đặc biệt là lỡ tay chạy command xóa resource ở prod thay vì dev.

Một số lệnh CLI hay dùng hàng ngày:

1# List EC2 instances
2aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,State.Name,Tags[?Key==`Name`].Value|[0]]' --output table
3
4# Copy file lên S3
5aws s3 cp ./build s3://my-bucket/build --recursive
6
7# Xem logs từ CloudWatch
8aws logs tail /aws/lambda/my-function --follow
9
10# Get secret từ Secrets Manager
11aws secretsmanager get-secret-value --secret-id my-db-password --query SecretString --output text

Bắt đầu từ đâu nếu bạn mới hoàn toàn?

Theo kinh nghiệm của mình, thứ tự học hiệu quả nhất là: IAM → VPC → EC2 → S3 → RDS → Load Balancer. Nắm chắc 6 cái này là bạn đã có thể deploy được một app production tử tế.

Đừng cố học hết 200 service cùng lúc. Hãy lấy một project thực tế dù nhỏ rồi deploy nó lên AWS theo đúng kiến trúc. Bạn sẽ học được nhiều hơn gấp 10 lần so với đọc docs thuần túy.

AWS Free Tier cho phép dùng nhiều service miễn phí trong 12 tháng đầu EC2 t2.micro, S3 5GB, RDS db.t2.micro... Đủ để bạn thực hành mà không tốn tiền. Nhưng nhớ set billing alert từ đầu mình đã thấy người bị bill vài trăm đô vì quên tắt resource sau khi test.

Bài tiếp theo trong series:  IAM Deep Dive — Identity, Policies & Security Best Practices

IAM là service đầu tiên bạn cần master trước khi chạm vào bất kỳ resource nào khác trên AWS. Mình sẽ đi sâu vào cách thiết kế policy đúng chuẩn least privilege, phân biệt Users vs Roles vs Groups, setup OIDC federation cho GitHub Actions (không cần access key dài hạn), và MFA enforcement cho toàn team. Nếu bạn từng bối rối với IAM permissions bài tiếp theo sẽ clear mọi thứ.

Nếu có câu hỏi gì về phần này, cứ comment xuống dưới nhé.