IaC & Cost ManagementIaC & Cost Management

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

Tổng quan

Trang này bàn về hai lĩnh vực mà một kỹ sư DevOps sống chung mỗi ngày: Infrastructure as Code (IaC) — định nghĩa hạ tầng cloud của bạn bằng các file được quản lý phiên bản, có thể review, và lặp lại được thay vì click quanh console — và cost management (quản lý chi phí) — giữ cho khoản chi tiêu phát sinh luôn rõ ràng, được quy trách nhiệm, và được tối ưu. Chúng đi cùng nhau vì chính những tính chất khiến hạ tầng an toàn (declarative, được gắn tag, được review, được tự động hóa) cũng chính là những gì khiến nó rẻ để vận hành và dễ để quy trách nhiệm.

Về phía IaC, AWS cung cấp một bộ công cụ native — CloudFormation (engine provisioning nền tảng), CDK (ngôn ngữ lập trình thật sự, tổng hợp ra CloudFormation), và SAM (một phần mở rộng của CloudFormation tập trung cho serverless) — trong khi thế giới rộng hơn chạy trên Terraform, tiêu chuẩn thực tế cloud-agnostic. Không có một câu trả lời đúng duy nhất: CloudFormation/CDK cho tích hợp AWS sâu nhất và drift detection mà không cần quản lý state file; Terraform cho khả năng chuyển đổi đa cloud, một hệ sinh thái module khổng lồ, và một workflow plan/apply tuyệt vời. Hầu hết các team chọn một công cụ chính và giữ tính nhất quán.

Về phía chi phí, thực tế chi phối là hóa đơn cloud là sản phẩm của các quyết định kỹ thuật, và nó chỉ kiểm soát được nếu nó rõ ràng và có thể quy trách nhiệm. Hạ tầng không gắn tag, không giám sát tạo ra một hóa đơn mà không ai giải thích được và không ai làm chủ. Nghề này là xây dựng một kỷ luật gắn tag, theo dõi chi tiêu bằng Cost Explorer, Budgets, và Anomaly Detection, và khớp các cam kết mua (Savings Plans, Reserved, Spot) với hình dạng workload. Làm tốt, cost management không phải là thắt lưng buộc bụng — mà là chi tiêu có chủ đích vào những gì quan trọng và loại bỏ lãng phí một cách tự động.

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

Tại sao lại cần IaC

Manual console	Infrastructure as Code
Không tái tạo được; các môi trường snowflake	Dev/stage/prod giống hệt nhau từ một nguồn duy nhất
Không có lịch sử; “ai đã đổi cái này?”	Lịch sử Git, review PR, blame
Không có dry-run; thay đổi áp dụng trực tiếp	plan / change set xem trước khi apply
Drift tích tụ âm thầm	Drift detection và re-apply
Onboarding = kiến thức truyền miệng	Repo chính là tài liệu

IaC biến hạ tầng thành phần mềm: được peer-review, được test, được version, và rollback như bất kỳ đoạn code nào khác. Mọi môi trường AWS nghiêm túc trong năm 2026 đều được định nghĩa theo cách này.

Họ IaC native của AWS

• CloudFormation — dịch vụ nền tảng. Bạn khai báo resource trong các template YAML/JSON; CloudFormation tạo chúng thành một stack mà nó theo dõi và quản lý, xử lý thứ tự phụ thuộc, rollback khi thất bại, và xóa. Không có state file để lưu trữ — AWS giữ state. Nó là engine mà CDK và SAM biên dịch xuống.
• CDK (Cloud Development Kit) — viết hạ tầng bằng TypeScript, Python, Java, Go, hoặc C#. Các construct cấp cao đóng gói các mặc định theo best-practice (một dịch vụ Fargate có load-balancer trong hơn chục dòng), và cdk synth phát ra một template CloudFormation. Lý tưởng khi bạn muốn vòng lặp, điều kiện, unit test, và hỗ trợ IDE thay vì YAML.
• SAM (Serverless Application Model) — một macro/phần mở rộng của CloudFormation với cú pháp ngắn gọn cho Lambda, API Gateway, DynamoDB, và Step Functions, cùng một CLI để test cục bộ (sam local invoke) và deploy nhanh. Con đường nhẹ nhàng nhất cho các ứng dụng serverless.

Cơ chế cốt lõi của CloudFormation

• Stack — một instance đã deploy của một template; đơn vị của create/update/delete. Xóa một stack và (theo mặc định) mọi resource nó tạo ra đều bị hủy.
• Change set — một bản xem trước những gì một cập nhật sẽ làm (add/modify/replace/remove) trước khi bạn thực thi nó. Cờ “replace” rất quan trọng: một số thay đổi property buộc phải tạo lại resource (và gây downtime / mất dữ liệu).
• StackSets — deploy cùng một stack trên nhiều account và region từ một thao tác duy nhất, được điều khiển bởi AWS Organizations. Đây là cách bạn triển khai các guardrail toàn tổ chức (một bucket logging, một Config conformance pack, một IAM baseline) tới mọi account một cách nhất quán.
• Drift detection — so sánh các resource đang chạy với template và báo cáo các thay đổi ngoài luồng mà ai đó đã thực hiện bằng tay.
• Nested stacks / modules — phân rã các template lớn thành các thành phần tái sử dụng được.

Khái niệm chính

CDK vs. CloudFormation vs. Terraform

Tiêu chí	CloudFormation	CDK	Terraform
Ngôn ngữ	YAML/JSON	TS/Python/Java/Go/C#	HCL
Phạm vi cloud	Chỉ AWS	Chỉ AWS (chủ yếu)	Đa cloud + 3000 provider
State	Do AWS quản lý	Do AWS quản lý (qua CFN)	Bạn quản lý (S3 backend)
Xem trước	Change sets	cdk diff → change sets	terraform plan
Hệ sinh thái	Do AWS xuất bản	Construct Hub	Terraform Registry (khổng lồ)
Drift	Detection tích hợp sẵn	Tích hợp sẵn (qua CFN)	plan hiển thị drift khi refresh
Phù hợp nhất cho	Thuần AWS, không state ngoài	Thuần AWS với code thật	Đa cloud, tái sử dụng module lớn nhất

Cách chọn: dốc toàn lực vào AWS với một team không thích quản lý state → CloudFormation hoặc CDK (CDK nếu bạn muốn tính năng ngôn ngữ thật sự). Đa cloud, hoặc bạn coi trọng workflow plan và hệ sinh thái module của Terraform, hoặc bạn đã có sẵn chuyên môn Terraform → Terraform. Ứng dụng serverless-first → SAM. Không có câu trả lời sai; tính nhất quán trong một team thắng những lợi thế biên nhỏ của bất kỳ công cụ nào.

Terraform trên AWS: provider và remote state

Terraform mô tả AWS bằng provider aws và lưu ánh xạ giữa config của bạn với các resource thật trong một state file. Nơi state đó nằm là quyết định vận hành quan trọng nhất: state cục bộ trên một laptop là công thức cho thảm họa (mất file = hạ tầng mồ côi, không có locking = hai kỹ sư làm hỏng apply của nhau). Câu trả lời tiêu chuẩn là một remote backend trong S3 với một bảng lock DynamoDB.

Ví dụ thực tế — Terraform S3 backend với DynamoDB locking:

# backend.tf
terraform {
  required_version = ">= 1.6"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket         = "acme-terraform-state-prod"   # versioned, encrypted, private
    key            = "networking/terraform.tfstate" # path per component
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"              # state-lock table (LockID hash key)
    encrypt        = true                            # SSE on the state object
  }
}

provider "aws" {
  region = "us-east-1"
  default_tags {
    tags = {
      Environment = "prod"
      ManagedBy   = "terraform"
      CostCenter  = "platform"
      Owner       = "platform-team"
    }
  }
}

Vì sao mỗi phần lại quan trọng:

• S3 bucket — bền, versioned (để bạn có thể rollback một state bị hỏng), được mã hóa, với public access bị chặn. State có thể chứa secret ở dạng plaintext, nên hãy đối xử với bucket như tài sản nhạy cảm.
• key — một state file cho mỗi thành phần logic (networking, data, app) để blast radius và thời gian apply luôn nhỏ; một state đơn khối duy nhất thì chậm và nguy hiểm.
• Bảng lock DynamoDB — một bảng đơn giản với partition key LockID (String). Terraform lấy một lock ở đây trước mỗi lần apply để hai người (hoặc hai lần chạy CI) không thể biến đổi state đồng thời. Lưu ý: các phiên bản Terraform mới hơn cũng cung cấp locking native trên S3 (use_lockfile), giảm nhu cầu dùng DynamoDB, nhưng pattern DynamoDB vẫn là cái được triển khai rộng rãi nhất.
• default_tags — mọi resource mà provider này tạo ra đều tự động kế thừa các tag này. Đây là xương sống của việc quy trách nhiệm chi phí (xem bên dưới) — đặt một lần và không bao giờ quên một tag nào nữa.

Lưu ý về bootstrap: bucket state và bảng lock bản thân chúng không thể nằm trong state mà chúng làm nền, nên hãy tạo chúng một lần bằng tay hoặc trong một cấu hình “bootstrap” nhỏ riêng biệt.

SAM cho serverless

SAM tỏa sáng cho các ứng dụng lấy Lambda làm trung tâm. Một template.yaml dùng các loại resource AWS::Serverless::* được mở rộng thành CloudFormation đầy đủ:

Transform: AWS::Serverless-2016-10-31
Resources:
  CheckoutFn:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: python3.13
      MemorySize: 512
      Timeout: 10
      Events:
        Api:
          Type: HttpApi
          Properties: { Path: /checkout, Method: post }
      Policies:
        - DynamoDBCrudPolicy: { TableName: !Ref OrdersTable }

sam local invoke chạy function trong một container đối với một test event, sam local start-api dựng API cục bộ, và sam deploy --guided đóng gói và ship nó. Giá trị nằm ở sự ngắn gọn (cú pháp rút gọn Policies đó tạo ra một IAM role có phạm vi hẹp) và vòng phản hồi cục bộ nhanh.

Bộ công cụ quản lý chi phí

Công cụ	Mục đích	Nhịp độ
Cost Explorer	Trực quan hóa và phân tích chi tiêu theo service/tag/account; dự báo	Ad hoc / review hàng tuần
AWS Budgets	Đặt ngưỡng; cảnh báo (hoặc hành động) khi chi tiêu/sử dụng vượt qua chúng	Liên tục, có cảnh báo
Cost Anomaly Detection	ML phát hiện các đợt tăng chi tiêu bất thường và cảnh báo	Liên tục, tự động
Cost Allocation Tags	Quy chi phí cho team/env/product qua tag	Nền tảng, liên tục
Compute Optimizer	Khuyến nghị right-sizing cho EC2/EBS/Lambda/ASG	Review định kỳ
Cost & Usage Report (CUR)	Dữ liệu billing thô, theo từng dòng (tới S3 / Athena / QuickSight)	Cho phân tích sâu / FinOps

Chiến lược gắn tag

Tag là nền tảng của mọi thứ liên quan đến chi phí — bạn không thể phân bổ, lập ngân sách, hay tối ưu khoản chi tiêu mà bạn không thể quy trách nhiệm. Một bộ tag bắt buộc tối thiểu:

Tag	Ví dụ	Mục đích
Environment	prod / staging / dev	Chia chi tiêu theo giai đoạn; tìm lãng phí ở dev
CostCenter / Team	platform / checkout	Charge-back / show-back cho các chủ sở hữu
Owner	platform-team	Hỏi ai; ai dọn dẹp
Application / Service	checkout-api	Chi phí theo từng product
ManagedBy	terraform	Phân biệt resource IaC với resource thủ công (drift)

Áp đặt tag bằng Tag Policies (Organizations), Service Control Policies (từ chối tạo resource nếu thiếu tag bắt buộc), hoặc default_tags của IaC. Sau đó kích hoạt chúng thành cost allocation tags trong Billing console để chúng xuất hiện trong Cost Explorer và CUR — một tag chỉ trở thành một chiều chi phí sau khi bạn kích hoạt nó, và chỉ từ thời điểm đó trở đi. Lưu ý giá trị tag phân biệt hoa thường (Prod ≠ prod), nên hãy chuẩn hóa cách viết hoa.

Các mô hình mua: Savings Plans vs. Reserved vs. Spot

Mô hình	Chiết khấu	Cam kết	Linh hoạt	Có thể gián đoạn	Dùng cho
On-Demand	baseline	không	toàn phần	không	Đột biến, ngắn hạn, không đoán trước
Spot	tới ~90%	không	bất kỳ capacity dư nào	Có (báo trước 2 phút)	Batch chịu lỗi, CI, fleet stateless
Reserved Instances	tới ~72%	1 hoặc 3 năm	khóa theo family/region (Standard)	không	Cũ; các instance ổn định cụ thể
Compute Savings Plans	tới ~66%	1 hoặc 3 năm ($/giờ)	bất kỳ region/family/EC2/Fargate/Lambda	không	Chi tiêu baseline ổn định (mặc định hiện đại)
EC2 Instance Savings Plans	tới ~72%	1 hoặc 3 năm ($/giờ)	trong một family/region	không	Chi tiêu ổn định trên một family đã biết

Luồng quyết định: đo lường baseline ổn định của bạn (lượng compute bạn chạy 24/7 mỗi tháng) và phủ nó bằng Compute Savings Plans (linh hoạt) hoặc EC2 Instance Savings Plans (chiết khấu sâu hơn nếu family ổn định). Chạy công việc có thể gián đoạn, stateless (CI runner, batch, big-data, dev fleet) trên Spot để giảm tới 90%. Để phần đột biến, không đoán trước ở đỉnh trên On-Demand. Cách tiếp cận phân tầng này — Savings Plans cho phần sàn, Spot cho phần đàn hồi ở giữa, On-Demand cho các đỉnh — là cấu trúc chi phí FinOps tiêu chuẩn. Reserved Instances phần lớn đã bị Savings Plans thay thế cho compute, dù RI vẫn áp dụng cho RDS, ElastiCache, Redshift, và OpenSearch.

Budgets và anomaly detection trong thực tế

Một Budget đặt một giới hạn chi phí/sử dụng hàng tháng (hoặc tùy chỉnh) và thông báo qua SNS tại các ngưỡng có thể cấu hình (ví dụ 80% thực tế, 100% thực tế, 100% dự báo). Budget Actions có thể đi xa hơn và áp dụng một SCP hoặc IAM policy để tự động kìm hãm chi tiêu khi một ngưỡng bị chạm. Cost Anomaly Detection bổ sung cho budget: thay vì một ngưỡng cố định, nó học chi tiêu bình thường của mỗi service và cảnh báo về các đợt tăng bất thường về mặt thống kê — bắt được, chẳng hạn, một NAT gateway chạy mất kiểm soát hoặc một S3 bucket vô tình public đang tích lũy request, nhiều ngày trước khi cảnh báo budget hàng tháng kịp báo.

Một lưu ý thực tế về budget + tagging: tạo budget theo từng chiều cost-allocation (theo tag team, theo môi trường) thay vì một budget toàn account, để một cảnh báo rơi vào team đã gây ra nó. Một budget toàn account nói cho bạn biết “chúng ta vượt rồi” nhưng không biết “ai” — các budget theo tag làm cho cảnh báo có thể hành động được và tự động định tuyến trách nhiệm.

Best Practices

1. Định nghĩa toàn bộ hạ tầng bằng code; cấm resource production tạo từ console. Lý do: resource thủ công là các snowflake không tái tạo được, không lịch sử hay review, và chúng drift; repo phải là nguồn sự thật duy nhất.
2. Luôn xem trước trước khi apply (terraform plan / change sets). Lý do: thay đổi hạ tầng có thể thay thế resource và gây downtime hoặc mất dữ liệu; bản xem trước bắt các thay đổi phá hủy trước khi chúng thực thi.
3. Lưu trữ Terraform state từ xa trong S3 versioned, được mã hóa với locking. Lý do: state cục bộ dễ mất hoặc hỏng, và không có locking thì các apply đồng thời phá hủy state của nhau; S3 versioning cho phép bạn rollback một state xấu.
4. Chia state theo thành phần, không phải một khối đơn khối. Lý do: một state file khổng lồ duy nhất khiến mọi apply chậm và biến bất kỳ sai lầm nào thành blast radius toàn môi trường; state theo từng thành phần giữ thay đổi nhỏ và an toàn.
5. Đặt default tags ở cấp provider (hoặc Tag Policies) để không gì bị thiếu tag. Lý do: resource không có tag là vô hình đối với cost allocation và tự động dọn dẹp; áp đặt tag lúc tạo là cách duy nhất giữ cho việc quy trách nhiệm được đầy đủ.
6. Kích hoạt cost allocation tags sớm và chuẩn hóa cách viết hoa của chúng. Lý do: tag chỉ trở thành chiều chi phí sau khi kích hoạt và chỉ áp dụng về sau, và Prod≠prod làm phân mảnh báo cáo của bạn — hãy đặt quy ước trước khi chi tiêu tích lũy.
7. Phủ baseline ổn định bằng Savings Plans, không phải On-Demand. Lý do: trả On-Demand cho workload 24/7 để lại tới ~66% trên bàn; một Compute Savings Plan 1 năm rủi ro thấp và linh hoạt qua family và region.
8. Chạy workload có thể gián đoạn, stateless trên Spot. Lý do: CI, batch, và fleet stateless chịu được việc thu hồi trong 2 phút và được giảm tới 90% — đòn bẩy lớn nhất trên chi phí compute biến đổi.
9. Tạo budget theo tag cho từng team/môi trường, không phải một budget toàn account. Lý do: một cảnh báo theo phạm vi định tuyến tới chủ sở hữu đã gây ra khoản vượt và có thể hành động được; một cảnh báo toàn account chỉ nói “chúng ta vượt rồi” mà không có trách nhiệm cụ thể.
10. Bật Cost Anomaly Detection trên nền của budget. Lý do: budget bắt một ngưỡng vào cuối tháng; anomaly detection bắt một resource chạy mất kiểm soát trong vòng một ngày, trước khi nó trở thành một hóa đơn bất ngờ lớn.
11. Review Compute Optimizer và right-size thường xuyên. Lý do: hầu hết các fleet đều được cấp phát dư; hành động theo khuyến nghị right-sizing và Graviton đáng tin cậy cắt giảm hàng chục phần trăm mà không tốn chi phí về độ tin cậy.
12. Giữ secret ra khỏi state và template; tham chiếu Secrets Manager/SSM lúc deploy. Lý do: Terraform state và các parameter CloudFormation có thể để lộ secret plaintext; lấy chúng lúc runtime giữ chúng ra khỏi bucket state và version control.
13. Dùng StackSets / Terraform module để áp đặt guardrail toàn tổ chức một cách nhất quán. Lý do: triển khai cùng một baseline (logging, Config pack, IAM) tới mọi account bằng tay đảm bảo drift; triển khai đa account tập trung giữ trạng thái đồng nhất.
14. Chạy IaC qua CI với plan-on-PR và apply-on-merge. Lý do: các plan được peer-review bắt sai lầm trước khi chúng đến production và tạo lịch sử thay đổi có thể audit, hệt như review code ứng dụng.
15. Ghim phiên bản provider và module. Lý do: phiên bản không ghim âm thầm kéo về các thay đổi phá vỡ trong lần apply tiếp theo; ghim làm cho build tái tạo được và nâng cấp có chủ đích.
16. Gắn tag cho resource để tự động hóa vòng đời (TTL/hết hạn trên dev) và xóa hạ tầng nhàn rỗi. Lý do: các môi trường dev bị lãng quên và volume/snapshot/IP mồ côi là lãng phí thuần túy; tự động hóa dọn dẹp theo tag thu hồi chi tiêu liên tục mà không cần con người giám sát.

Tài liệu tham khảo

• AWS CloudFormation User Guide
• CloudFormation StackSets
• AWS CDK Developer Guide
• AWS SAM Developer Guide
• Terraform AWS Provider
• Terraform S3 backend
• AWS Cost Explorer
• AWS Budgets
• AWS Cost Anomaly Detection
• Cost allocation tags
• AWS Savings Plans
• Amazon EC2 Spot Instances
• AWS Compute Optimizer
• AWS Well-Architected — Cost Optimization Pillar

# backend.tf
terraform {
  required_version = ">= 1.6"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket         = "acme-terraform-state-prod"   # versioned, encrypted, private
    key            = "networking/terraform.tfstate" # path per component
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"              # state-lock table (LockID hash key)
    encrypt        = true                            # SSE on the state object
  }
}

provider "aws" {
  region = "us-east-1"
  default_tags {
    tags = {
      Environment = "prod"
      ManagedBy   = "terraform"
      CostCenter  = "platform"
      Owner       = "platform-team"
    }
  }
}

Transform: AWS::Serverless-2016-10-31
Resources:
  CheckoutFn:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: python3.13
      MemorySize: 512
      Timeout: 10
      Events:
        Api:
          Type: HttpApi
          Properties: { Path: /checkout, Method: post }
      Policies:
        - DynamoDBCrudPolicy: { TableName: !Ref OrdersTable }