Ngôn ngữ hiển thị:
ChatBot AINgôn ngữ hiển thị:
ChatBot AIHồi mới học AWS, mình cũng như đa số mọi người — mở Management Console lên, nhìn giao diện đẹp, click vào tạo EC2 instance, thấy "ồ dễ quá". Nhưng đến lần thứ 10 phải tạo lại cùng một cấu hình cho môi trường staging khác, mình mới nhận ra mình đang làm việc của một cái máy. Rồi một hôm đọc job description DevOps, thấy yêu cầu "thành thạo Terraform/Ansible/CDK" — thế là cuống. AWS không chỉ có Console. Và việc chọn đúng công cụ, đúng thời điểm, ảnh hưởng trực tiếp đến năng suất làm việc của bạn.
Hãy tưởng tượng AWS là một tòa nhà văn phòng khổng lồ. Management Console là khi bạn đi thang máy lên từng tầng, mở cửa từng phòng bằng tay — trực quan, dễ nhìn, nhưng chậm nếu bạn cần vào 100 phòng cùng lúc. AWS CLI là chiếc điều khiển từ xa — bạn gõ lệnh, hệ thống thực thi ngay, nhanh hơn nhiều. Infrastructure as Code (IaC) là khi bạn viết một bản thiết kế tòa nhà: chỉ cần "chạy bản thiết kế", toàn bộ tòa nhà được dựng lên tự động, đúng y chang mỗi lần.
Ba cách này không thay thế nhau hoàn toàn — chúng bổ sung cho nhau tùy ngữ cảnh. Theo khảo sát của Stack Overflow Developer Survey 2025, hơn 62% kỹ sư cloud sử dụng cả ba công cụ trong workflow hàng ngày. Vấn đề là biết dùng cái nào lúc nào.
Mỗi công cụ phù hợp với một nhóm người dùng và tình huống khác nhau. Đây là 3 scenario điển hình nhất:
aws s3 sync ./build s3://my-bucket --delete
trong CI/CD pipeline nhanh hơn click Console hàng chục lần. CLI còn cho phép kết hợp với bash script để tạo automation đơn giản mà không cần học Terraform ngay.
main.tf
mô tả toàn bộ hạ tầng, commit lên Git, review như code thường, deploy nhất quán ở bất kỳ đâu. Đây là lý do Terraform được 77% công ty Fortune 500 sử dụng theo HashiCorp State of Cloud 2025.
Để không bị "lý thuyết suông", đây là cách thực sự bắt đầu với từng công cụ theo từng giai đoạn học:
Management Console — Tuần 1-2: Đăng nhập vào console.aws.amazon.com. Thực hành tạo một EC2 instance (chọn t2.micro Free Tier), tạo S3 bucket, và tạo IAM user với quyền hạn chế. Mục tiêu: quen mặt các service cơ bản và hiểu cấu trúc phân quyền. Lưu ý quan trọng: luôn bật MFA cho root account và đặt billing alert $5 ngay từ đầu để tránh hóa đơn sốc.
AWS CLI — Tuần 3-4:
Cài AWS CLI v2:
brew install awscli
(macOS) hoặc download installer (Windows). Chạy
aws configure,
nhập Access Key ID và Secret Access Key của IAM user (không dùng root!).
Thực hành các lệnh cơ bản:
aws s3 ls
aws ec2 describe-instances
aws iam list-users
aws s3 ls — list buckets
aws ec2 describe-instances — xem tất cả instances
aws iam list-users — list users trong account
Khi đã quen, thử viết một bash script nhỏ tự động backup database lên S3 mỗi ngày. Đây là bước chuyển từ "học" sang "dùng thật".
IaC với Terraform — Tháng 2-3:
Cài Terraform:
brew install terraform.
Tạo file
main.tf
đầu tiên:
provider "aws" {
region = "ap-southeast-1"
}
resource "aws_s3_bucket" "my_bucket" {
bucket = "my-learning-bucket-2026"
}
Chạy
terraform init
→
terraform plan
→
terraform apply.
Bucket được tạo. Chỉnh sửa config, chạy lại — Terraform chỉ thay đổi phần khác. Chạy
terraform destroy
— xóa sạch, không tốn tiền. Đây là "vòng lặp học" an toàn và hiệu quả nhất.
Mẹo: Dùng
terraform planTRƯỚC KHI apply trong production. Lệnh này hiển thị chính xác những gì sẽ thay đổi — tương đương "git diff" nhưng cho hạ tầng. Nhiều kỹ sư lâu năm vẫn không bỏ bước này, kể cả khi "chắc chắn" mình đúng.
Dưới đây là 3 sai lầm phổ biến nhất mình thấy người mới hay mắc:
1. Dùng Console cho tất cả mọi thứ, kể cả production: Click tay để tạo hạ tầng production là công thức của thảm họa. Một ngày xấu trời cần rebuild lại môi trường sau incident, bạn không nhớ mình đã config gì, click ở đâu. Không có audit trail. Không reproduce được. Mình từng thấy team mất 2 ngày để dựng lại môi trường staging vì toàn bộ config chỉ tồn tại "trong Console" và "trong đầu Senior Dev".
2. Lưu Access Key trực tiếp trong code: Đây là sai lầm nguy hiểm nhất. Secret bị commit lên GitHub → bot scan thấy → trong vòng vài phút bạn nhận email từ AWS cảnh báo account bị compromise. Luôn dùng environment variables hoặc AWS Secrets Manager. Và dùng IAM Roles cho EC2/Lambda thay vì hardcode key.
3. Không học IaC vì "phức tạp quá": Nhiều bạn dừng lại ở CLI và nghĩ vậy là đủ. Thực tế thị trường tuyển dụng 2025-2026 tại Việt Nam, hầu hết JD DevOps/Cloud Engineer đều yêu cầu tối thiểu biết Terraform hoặc CloudFormation. Bắt đầu từ một resource đơn giản, đừng cố học toàn bộ Terraform trong một tuần.
Q: Tôi chỉ cần biết Console là đủ để xin việc DevOps chưa?A: Thẳng thắn mà nói — chưa đủ. Với vị trí junior DevOps hoặc Cloud Support, biết Console tốt là điểm cộng, nhưng hầu hết công ty sẽ hỏi về CLI và ít nhất một IaC tool. Nếu bạn đang target vị trí Cloud Engineer hoặc DevOps Engineer thực sự, Terraform hoặc AWS CDK là gần như bắt buộc.
Q: Terraform hay AWS CDK — học cái nào trước?A: Nếu bạn là developer quen Python/TypeScript, CDK sẽ tự nhiên hơn vì bạn viết code thật thay vì HCL. Nếu bạn muốn multi-cloud (không chỉ AWS), Terraform là lựa chọn tốt hơn vì hỗ trợ GCP, Azure, k8s cùng một tool. Mình recommend: học Terraform trước vì cộng đồng lớn hơn, tài liệu nhiều hơn, và dễ tìm việc hơn.
Q: IaC có làm hạ tầng phức tạp và khó debug hơn không?A: Ban đầu có, đặc biệt khi gặp lỗi dependency giữa các resource. Nhưng về dài hạn, IaC giảm complexity đi rất nhiều vì mọi thứ được version control, có lịch sử thay đổi rõ ràng, và dễ rollback. Terraform state file đôi khi gây đau đầu (đặc biệt khi làm việc nhóm), nhưng dùng remote state trên S3 + DynamoDB lock là giải pháp chuẩn mà team nào cũng nên setup từ đầu.
Console, CLI, IaC — không phải "chọn một, bỏ hai". Đây là hành trình tiến hóa của bất kỳ kỹ sư cloud nào: bắt đầu với Console để hiểu, chuyển sang CLI để làm nhanh hơn, rồi IaC để làm đúng và làm mãi được. Mỗi công cụ có vị trí của nó, và kỹ sư giỏi là người biết dùng đúng công cụ vào đúng lúc — không phải người biết nhiều nhất, mà là người chọn thông minh nhất. Bài tiếp theo chúng ta sẽ đi sâu vào AWS CloudWatch — cách thiết lập monitoring và cảnh báo tự động để bạn ngủ ngon mà không sợ server "chết lúc 3 giờ sáng".
