Cloud Infrastructure & Architecture — Sống Sót Giữa Rừng AWS/GCP

"There is no cloud, it's just someone else's computer." Câu này đúng một nửa. Nửa kia là: "It's someone else's computer, with a massive API surface, opaque billing, and 200 services with weird names."

Khi bạn lên level Senior/Staff, "biết code" không còn đủ. Bạn phải biết code của bạn chạy trên cái gì, làm sao để nó scale, làm sao để nó secure, và làm sao để không khiến công ty phá sản vì cloud bill.

1. Bản Đồ Thế Giới Cloud (AWS vs GCP)

Đừng cố học thuộc lòng 200 services. Hãy map chúng vào các "mental buckets" cốt lõi. Nếu bạn hiểu concept, chuyển từ AWS sang GCP chỉ tốn vài tuần học từ vựng mới.

2. VPC & Network Architecture — Fundamental

Rất nhiều Dev sợ Network. Nhưng thiết kế VPC sai từ đầu = ác mộng security và migration sau này.

2.1 Standard 3-Tier VPC Architecture

Internet 🌐
  │
  ▼ [Internet Gateway (IGW)]
───────────────────────────────────────────────────────── VPC (10.0.0.0/16)
  │
  ├─ Public Subnet (10.0.1.0/24)
  │   ├── Application Load Balancer (ALB)
  │   └── NAT Gateway (cho private subnet ra Internet)
  │   (Chỉ những thứ cần expose ra Internet mới ở đây)
  │
  ├─ Private Subnet - App Tier (10.0.2.0/24)
  │   ├── EKS Nodes / EC2 Instances
  │   ├── ECS Tasks (Fargate)
  │   └── Internal Load Balancers
  │   (Không có public IP, an toàn)
  │
  └─ Private Subnet - Data Tier (10.0.3.0/24)
      ├── RDS (Database)
      ├── ElastiCache (Redis)
      └── (Cực kỳ strict Security Groups, chỉ nhận traffic từ App Tier)

2.2 Quy tắc vàng của Cloud Networking

1. VPC CIDR Sizing: Chọn CIDR lớn từ đầu (vd: /16). Hết IP trong VPC là thảm họa vì bạn không thể đổi CIDR sau khi tạo.
2. Không bao giờ cho Database nằm ở Public Subnet.
3. Dùng VPC Endpoints (AWS) hoặc Private Google Access (GCP): Để các services trong VPC nói chuyện với S3/GCS mà traffic không phải vòng ra Internet (vừa bảo mật, vừa đỡ tốn tiền data transfer qua NAT Gateway).

3. High Availability (HA) & Disaster Recovery (DR)

3.1 Region vs Availability Zone (AZ)

• Region: Một khu vực địa lý (vd: ap-southeast-1 ở Singapore). Nếu Region sập, thường là thảm họa tự nhiên cấp quốc gia.
• Availability Zone (AZ): Một cụm Data Center trong Region. Các AZ cách nhau đủ xa để không sập cùng lúc (cháy nổ, lụt), nhưng đủ gần để ping < 1ms. (vd: ap-southeast-1a, 1b, 1c).

3.2 Design for HA (Trong cùng 1 Region)

Multi-AZ Architecture:
  → ALB route traffic đến EC2/EKS nằm ở 3 AZs khác nhau.
  → RDS có Primary ở AZ-a, Standby Replica ở AZ-b.
  → Khi AZ-a sập do cháy data center:
    1. ALB tự động dồn traffic sang AZ-b và AZ-c.
    2. RDS tự động failover, Standby ở AZ-b lên làm Primary (mất ~60s downtime).

Lưu ý: Cross-AZ data transfer tính phí ($0.01/GB ở AWS). Đừng để 2 services nói chuyện chéo AZ quá nhiều nếu không cần thiết.

3.3 Multi-Region (Disaster Recovery)

"Công ty em có nên chạy Active-Active Multi-Region không anh?" Trả lời: 99% là không. Cost nhân đôi, complexity nhân 10, data replication latency đau đầu.

Trừ khi bạn là Netflix hay Stripe, hãy dùng các pattern rẻ hơn:

1. Backup & Restore: Backup data ra cross-region. Sập thì dựng lại infra từ đầu. (RTO: 24h, RPO: 24h)
2. Pilot Light: Dựng DB replica nhỏ xíu ở region 2. App tier không chạy. Khi sập mới spin up app tier. (RTO: vài chục phút).
3. Warm Standby: Chạy 1 bản copy nhỏ gọn của toàn bộ hệ thống ở region 2. (RTO: vài phút).

(RTO: Thời gian tối đa để khôi phục. RPO: Lượng data tối đa chấp nhận mất).

4. Managed Services vs Self-Hosted — Bài Toán Trade-offs

Bạn có giỏi cài đặt Kafka không? Có. Bạn có NÊN tự host Kafka trên EC2 không? Chưa chắc.

4.1 Tại sao Managed Services (PaaS/DBaaS) đáng tiền?

• Undifferentiated Heavy Lifting: Cài patch OS, upgrade version DB, cấu hình backup tự động... những việc này không tạo ra giá trị khác biệt cho business của bạn.
• Outsource the Pager: RDS sập lúc 3h sáng? AWS auto-failover cho bạn. Tự host MySQL trên EC2 sập? Chúc bạn vui vẻ login SSH fix lỗi.

4.2 Khi nào nên Self-Host?

• Scale quá lớn khiến Managed Service quá đắt (Cost optimization).
• Cần custom plugin hoặc config mà Managed DB không hỗ trợ (vd: một số extension lạ của PostgreSQL).
• Cloud agnostic requirement (Sợ lock-in).

Staff Engineer Mindset: Luôn default to Managed Service (RDS, MSK, ElastiCache). Chỉ self-host khi có data chứng minh lợi ích (Cost savings vượt quá Engineering cost để duy trì).

5. Infrastructure as Code (IaC) — Không Bao Giờ Click Chuột (ClickOps)

Nếu hạ tầng của bạn được tạo ra bằng cách click chuột trên AWS Console, hệ thống của bạn là một "Snowflake" — độc nhất, mỏng manh, và không thể tái tạo.

5.1 Tại sao dùng Terraform / Pulumi?

• Reproducibility: Dựng môi trường Staging y hệt Production trong 10 phút.
• Auditability: Mọi thay đổi hạ tầng đều là Pull Request. Ai mở port 22 ra Internet? git blame sẽ nói cho bạn biết.
• Disaster Recovery: Region sập? Chạy Terraform apply sang Region mới.

5.2 Terraform Best Practices

# 1. KHÔNG dùng hardcode, DÙNG variables & data sources
data "aws_vpc" "main" {
  tags = { Name = "prod-vpc" }
}

# 2. Phân chia State File
# ĐỪNG bỏ cả công ty vào 1 file state (tfstate)
# Chia theo môi trường và domain:
# - prod/network/
# - prod/database/
# - prod/app/

# 3. Remote State Locking
# Luôn dùng S3 backend + DynamoDB lock để tránh 2 người apply cùng lúc làm hỏng state.
terraform {
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "prod/db/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-locks"
  }
}

6. The Multi-Cloud Trap

Hỏi: "Chúng ta nên design hệ thống chạy được trên cả AWS và GCP để không bị vendor lock-in, lỡ AWS tăng giá thì mình dọn nhà?"

Sự thật phũ phàng:

1. Chi phí để xây dựng và duy trì hệ thống Cloud Agnostic (dùng K8s thuần, tự host DB thay vì dùng DynamoDB/Spanner) đắt gấp 10 lần việc AWS có thể tăng giá.
2. Lúc bạn dọn nhà sang GCP, Data Transfer Egress Cost (phí rút data ra khỏi AWS) sẽ làm bạn choáng váng.
3. Thay vì dùng The Best of AWS (S3, DynamoDB, SQS), bạn bị ép dùng "The Least Common Denominator" (Mẫu số chung nhỏ nhất) giữa các cloud.

Lời khuyên: Hãy chấp nhận ôm lấy 1 Cloud Vendor (Vendor Lock-in là một feature, không phải bug). Tận dụng tối đa managed services của họ để đi nhanh nhất có thể.

7. Cloud Security Core Principles (IAM)

Lỗi bảo mật Cloud lớn nhất hiếm khi do hacker siêu đẳng, mà do lộ Access Key hoặc S3 bucket public.

7.1 IAM (Identity and Access Management)

• Nguyên tắc Least Privilege: Chỉ cấp QUYỀN ĐỦ DÙNG. Đừng bao giờ gán policy AdministratorAccess cho EC2/EKS worker node.
• ĐỪNG dùng Access Keys (Static Credentials). Thay vào đó hãy dùng Roles (Temporary Credentials).
  • EC2 instance profile / EKS IRSA (IAM Roles for Service Accounts) / GCP Workload Identity. App của bạn tự lấy token tạm thời từ Cloud, không có key nào bị lưu trong file config.

7.2 Zero Trust Network

• Security Groups (Firewalls): Default deny all.
• Database SG: Chỉ cho phép INBOUND port 5432 từ Application SG. Bất cứ ai ngoài Application SG dù có password cũng không kết nối được.

8. Tóm tắt — Cloud Architecture cho Staff Engineer

□ Default to Managed Services: Tập trung vào business logic, outsource hạ tầng cho AWS/GCP.
□ IaC is Mandatory: Terraform/Pulumi mọi thứ. Không ClickOps.
□ Design for Failure: AZs có thể sập. Instances có thể bị terminate. Hệ thống phải auto-recover.
□ Least Privilege: Thắt chặt IAM. Không dùng static credentials.
□ Beware the Network Costs: Kiến trúc xịn nhưng data transfer cross-AZ làm cạn tiền công ty = Failed Architecture.
□ Tránh xa Multi-Cloud: Trừ khi có yêu cầu cực kỳ đặc thù từ Enterprise. Ôm lấy vendor của bạn.

Tài liệu tham khảo

• AWS Well-Architected Framework — Kinh thánh của Cloud architecture.
• Google Cloud Architecture Framework
• Sách: Terraform: Up & Running — Yevgeniy Brikman.
• Sách: Architecting for Scale — Lee Atchison.

💡 Remember: Hạ tầng xịn không phải là hạ tầng phức tạp nhất với đủ thứ buzzwords (K8s, Istio, Multi-Cloud). Hạ tầng xịn là hạ tầng buồn tẻ (boring) — nó chạy âm thầm, scale tự động, tốn ít tiền, và bạn có thể ngủ ngon vào cuối tuần. ☁️