Ngày 1: Cloud fundamentals & truy cập AWS CLI an toàn

Bản đồ bài học

Cloud không đơn giản là “thuê máy chủ của người khác”. Đây là mô hình trong đó bạn có thể cấp phát tài nguyên theo nhu cầu qua giao diện hoặc API, còn nhà cung cấp chịu trách nhiệm cho phần lớn hạ tầng vật lý bên dưới. Vì vậy, bài hôm nay có hai đầu ra rõ ràng:

1. Nhìn được lợi ích kinh doanh của cloud, đặc biệt là đổi chi phí đầu tư trước thành chi phí vận hành linh hoạt.
2. Có một quy trình truy cập AWS có thể kiểm chứng, không dùng Root user cho công việc hằng ngày và không làm lộ secret.

Quy tắc an toàn: Không dán access key thật vào bài học, chat, issue, Git repository hoặc ảnh chụp màn hình. Nếu credential bị lộ, hãy vô hiệu hóa/xóa ngay trong IAM và kiểm tra CloudTrail, chi phí, cùng các tài nguyên bất thường.

1. Cloud giải quyết bài toán gì?

Giả sử một cửa hàng trực tuyến có 500 người dùng vào ngày thường nhưng tăng lên 20.000 người vào dịp khuyến mãi. Với data center riêng, đội vận hành phải mua đủ máy chủ trước nhiều tháng. Nếu mua thiếu, hệ thống chậm hoặc ngừng phục vụ; nếu mua thừa, phần công suất nhàn rỗi vẫn tiêu tốn tiền điện, chỗ đặt máy và nhân sự.

Cloud cho phép đội ngũ bắt đầu nhỏ, mở rộng khi nhu cầu tăng và thu nhỏ sau khi nhu cầu giảm. Lợi ích không nằm ở việc “AWS luôn rẻ hơn mua máy chủ”, mà ở khả năng đưa công suất vào sử dụng nhanh hơn, đo lường được và không phải sở hữu toàn bộ hạ tầng vật lý.

CapEx và OpEx

Góc nhìn	Data center tự sở hữu	Cloud pay-as-you-go
Khoản chi chính	CapEx: mua máy chủ, mạng, lưu trữ	OpEx: trả theo tài nguyên và dịch vụ dùng
Công suất	Phải dự đoán trước	Có thể tăng/giảm theo nhu cầu
Thời gian cấp phát	Mua sắm, lắp đặt, cấu hình	Cấp phát qua Console, CLI hoặc API
Trách nhiệm vật lý	Doanh nghiệp tự vận hành	AWS vận hành data center và phần hạ tầng cloud

Cloud không loại bỏ mọi chi phí. Bạn vẫn phải thiết kế, bảo mật, giám sát và tối ưu tài nguyên. Đây là điểm phân biệt giữa một câu trả lời đúng trong đề thi và một khẩu hiệu marketing.

Từ nhu cầu kinh doanh đến hành động kỹ thuật

flowchart LR
  Need[Business need - traffic / speed / cost] --> Model[Cloud model - shared infrastructure]
  Model --> Provision[Provision by Console / CLI / API]
  Provision --> Scale[Scale up or down when demand changes]
  Scale --> Observe[Observe usage - security / cost / health]
  Observe --> Decide[Adjust design - policy / capacity / region]
  Decide --> Provision

Sơ đồ này giúp nối các từ khóa thường bị học rời rạc. Pay-as-you-go chỉ có ý nghĩa khi có khả năng đo usage; elasticity chỉ an toàn khi có monitoring và policy; còn “cấp phát nhanh” không đồng nghĩa “được phép cấp phát bừa”. Trong một hệ thống thật, mỗi lần tăng capacity đều phải đi kèm giới hạn chi phí, quyền IAM và tín hiệu giám sát.

2. Những khái niệm cần ghi nhớ

Elasticity khác scalability

• Scalability là khả năng tăng năng lực hệ thống khi tải tăng, có thể là tăng máy (horizontal) hoặc tăng cấu hình (vertical).
• Elasticity nhấn mạnh việc tự động hoặc nhanh chóng tăng và giảm tài nguyên theo nhu cầu.
• High availability là thiết kế để dịch vụ tiếp tục hoạt động khi một thành phần gặp lỗi; nó không đồng nghĩa với “không bao giờ có downtime”.

Ví dụ: tăng loại máy từ t3.small lên t3.large là vertical scaling; thêm hai instance phía sau load balancer là horizontal scaling. Nếu hệ thống tự thêm instance lúc request tăng và giảm instance sau khi traffic hạ, đó mới là elasticity. Nếu thêm máy nhưng database vẫn là một điểm nghẽn duy nhất, ta đã scale một lớp chứ chưa giải quyết capacity end-to-end.

Mô hình trách nhiệm chia sẻ bắt đầu từ ngày 1

AWS chịu trách nhiệm về security of the cloud: data center, phần cứng, mạng vật lý và lớp ảo hóa mà AWS vận hành. Khách hàng chịu trách nhiệm về security in the cloud theo dịch vụ đang dùng: danh tính, dữ liệu, cấu hình mạng và phần mềm mà mình kiểm soát.

Đây là mô hình động. Trên EC2, khách hàng thường phải quản lý Guest OS; với dịch vụ managed như S3, AWS quản lý nhiều lớp vận hành hơn nhưng bucket policy, quyền truy cập và dữ liệu vẫn cần được cấu hình đúng.

3. Thiết lập truy cập an toàn trước khi dùng CLI

Bước 1 — Bảo vệ Root user

Trong Console, đăng nhập Root user chỉ để làm các công việc thật sự yêu cầu Root. Hãy bật MFA, kiểm tra không có Root access key và không dùng Root để chạy lab hằng ngày. Sau đó tạo một phương thức truy cập cho người vận hành hằng ngày bằng IAM Identity Center với quyền phù hợp.

Nếu đây là tài khoản học tập cá nhân, hãy đặt Billing alarm/Budget trước khi tạo tài nguyên. Free Tier không có nghĩa mọi thao tác đều miễn phí và điều kiện Free Tier có thể thay đổi theo thời điểm.

Bước 2 — Cài AWS CLI và chọn phương thức đăng nhập

Kiểm tra CLI:

aws --version

Ưu tiên đăng nhập bằng IAM Identity Center nếu tài khoản của bạn đã cấu hình phương thức này:

aws configure sso --profile study
aws sso login --profile study

Nếu môi trường học tập bắt buộc dùng access key của một IAM user, chỉ tạo key cho user có quyền tối thiểu, lưu qua trình hướng dẫn cấu hình của CLI và tuyệt đối không gửi nội dung file credential lên Git:

aws configure --profile study
aws configure list-profiles
aws configure list --profile study

Khi CLI hỏi secret, nhập trực tiếp vào prompt. Không thay YOUR_SECRET bằng secret thật trong tài liệu hoặc script chia sẻ. File credential thường nằm ở ~/.aws/credentials; file config thường nằm ở ~/.aws/config. Hai file này phải được bảo vệ như mật khẩu.

Bước 3 — Kiểm tra danh tính trước mọi thao tác

aws sts get-caller-identity --profile study
aws configure list --profile study
aws ec2 describe-regions --profile study --query 'Regions[0:3].RegionName' --output table

Lệnh đầu tiên là checkpoint quan trọng nhất. Output cần có Account đúng tài khoản, và Arn đúng user/role bạn dự định sử dụng. Nếu thấy Root ARN, dừng lại và đổi phương thức truy cập trước khi tiếp tục.

4. Quy trình làm lab không gây bất ngờ

Trước một lệnh có thể tạo tài nguyên, hãy đi theo chuỗi kiểm tra này:

1. Who am I? — chạy aws sts get-caller-identity với đúng profile.
2. Where am I? — xác nhận account và region.
3. What will it cost? — xem giá, Free Tier và Budget; không giả định một dịch vụ là miễn phí.
4. Can I undo it? — biết cách xóa tài nguyên, dữ liệu và log sau khi thực hành.
5. Did it work? — kiểm tra trạng thái thực tế thay vì chỉ tin vào exit code.

Nếu gặp AccessDenied, đừng giải quyết bằng cách gán AdministratorAccess ngay lập tức. Hãy đọc action bị từ chối, xác định resource/condition liên quan và mở rộng quyền ở mức nhỏ nhất cần thiết.

5. Case study có hướng dẫn: cửa hàng tăng tải theo chiến dịch

Hãy xem một scenario hoàn chỉnh thay vì học từng định nghĩa riêng lẻ.

Bối cảnh: cửa hàng có 500 phiên truy cập đồng thời vào ngày thường và 20.000 phiên trong 30 phút mở bán. Team chỉ có ngân sách nhỏ, cần đưa một môi trường kiểm thử lên trong ngày và không muốn nhân viên dùng chung credential.

Bước 1 — Chuyển yêu cầu thành tín hiệu kỹ thuật

Tín hiệu trong scenario	Cách hiểu	Quyết định / khái niệm liên quan
Nhu cầu tăng đột biến rồi giảm	Capacity không ổn định	Elasticity, autoscaling, không mua dư công suất cố định
Cần môi trường trong ngày	Time-to-market quan trọng	Provision qua API/CLI, không chờ mua phần cứng
Nhân viên có nhiều vai trò	Không nên dùng credential chung	IAM principal, role, least privilege
Dữ liệu khách hàng cần bảo vệ	Có boundary và ownership	Shared Responsibility, encryption/access control
Finance cần biết chi phí	Pay-as-you-go vẫn phải kiểm soát	Budget, tag, monitoring và cleanup

Điểm quan trọng: cloud giải quyết tốc độ cấp phát và khả năng điều chỉnh capacity; cloud không tự thiết kế autoscaling, không tự phân quyền đúng và không tự xóa tài nguyên thử nghiệm.

Bước 2 — Vẽ boundary và luồng ra quyết định

flowchart TD
  User[User / team member] --> Identity[SSO or temporary role]
  Identity --> CLI[AWS CLI profile study]
  CLI --> STS[STS GetCallerIdentity checkpoint]
  STS --> Read[Read-only inspection]
  Read --> Decision{Account / region / cost safe?}
  Decision -->|No| Stop[Stop and fix context]
  Decision -->|Yes| Change[Smallest permitted change]
  Change --> Verify[State, logs, cost and cleanup evidence]

Sơ đồ này mô tả thứ tự an toàn, không phải một thủ tục mang tính hình thức. Nếu bỏ qua bước STS, bạn có thể chạy đúng câu lệnh nhưng trên sai account. Nếu bỏ qua bước đọc trạng thái, bạn có thể tạo trùng resource. Nếu bỏ qua cleanup, một lab ngắn có thể trở thành chi phí kéo dài.

Bước 3 — Đọc output mẫu

Output có thể được che bớt thông tin khi ghi vào notes, nhưng khi chạy thật cần đối chiếu đủ account và ARN:

{
  "UserId": "AROA...:study-session",
  "Account": "123456789012",
  "Arn": "arn:aws:sts::123456789012:assumed-role/LabReadOnly/study-session"
}

Output này cho biết request đang dùng role tạm thời trong đúng account. Nếu ARN có dạng arn:aws:iam::...:root, hoặc Account không đúng sandbox, phải dừng trước khi chạy bất kỳ lệnh tạo/sửa/xóa nào. Không dùng việc “thử một lệnh rẻ” để kiểm tra account; checkpoint STS đã đủ cho mục đích đó.

6. Lab thực hành read-only và failure drill

Phần A — Xác nhận môi trường

aws --version
aws configure list-profiles
aws sts get-caller-identity --profile study
aws configure list --profile study

Expected state:

• CLI chạy được và profile study tồn tại.
• Account đúng tài khoản lab; Arn không phải Root.
• configure list chỉ ra nguồn credential/profile/region phù hợp; secret không được in ra.

Phần B — Cố ý kiểm tra lỗi nhưng không tạo resource

1. Chạy aws sts get-caller-identity --profile does-not-exist và ghi nhận lỗi profile không tồn tại. Đây là lỗi local configuration, không phải lý do để xin quyền admin.
2. Chạy lại với study; so sánh hai command và xác định biến context nào đã thay đổi.
3. Dùng aws ec2 describe-regions --profile study --query 'Regions[0:3].RegionName' --output table để kiểm tra request read-only tới AWS.
4. Nếu lệnh thứ ba bị AccessDenied, ghi principal/action và dừng; không đổi policy chỉ để làm bài pass.

Phần C — Viết decision record

Ghi một record ngắn gồm: target account, profile, region, credential source, command đã chạy, expected state, actual state, safety decision. Một record đạt chuẩn phải cho người khác biết bạn đã kiểm tra gì mà không cần nhìn secret.

7. Những lỗi người mới thường gặp

Triệu chứng	Nguyên nhân có khả năng	Cách xử lý an toàn
Unable to locate credentials	Profile chưa có credential hoặc SSO session hết hạn	Kiểm tra configure list, đăng nhập lại SSO; không dán key vào source
Account trả về không đúng	Đang dùng default hoặc profile khác	Luôn truyền --profile study, chạy lại STS
AccessDenied	Policy không cho action/resource đó	Đọc action/resource/condition, thu hẹp request; không gán admin
CLI gọi sai Region	Region trong profile hoặc biến môi trường sai	Kiểm tra configure list, truyền --region rõ ràng khi cần
Secret xuất hiện trong log/Git	Credential bị ghi vào file/script	Revoke/rotate ngay, xóa khỏi artifact và kiểm tra lịch sử commit

Phân loại lỗi trước khi sửa là kỹ năng quan trọng hơn việc nhớ một câu lệnh. Lỗi credential, lỗi authorization, lỗi region và lỗi resource state có evidence khác nhau; sửa nhầm lớp có thể làm rủi ro lớn hơn.

8. Góc nhìn CLF-C02

Trong câu hỏi scenario, hãy nhận diện tín hiệu thay vì học thuộc một câu khẩu hiệu:

• “Reduce upfront investment”, “avoid purchasing hardware” → lợi ích của cloud và chuyển CapEx sang OpEx.
• “Scale up and down as demand changes” → elasticity.
• “Deploy globally in minutes” → tốc độ và phạm vi triển khai của cloud infrastructure.
• “AWS manages physical facilities” → phần thuộc security of the cloud.

CLF-C02 kiểm tra kiến thức tổng quát và khả năng chọn đáp án phù hợp với bối cảnh; bài thi không yêu cầu bạn triển khai một hệ thống hoàn chỉnh hay viết code. Vì vậy, hãy hiểu “vì sao chọn” thay vì ghi nhớ tên lệnh một cách máy móc.

9. Sau bài này bạn phải làm được gì?

Bạn hoàn thành bài khi có thể tự nói thành tiếng: “Cloud giúp tôi cấp phát và co giãn tài nguyên theo nhu cầu; tôi không dùng Root cho công việc hằng ngày; trước mọi lệnh AWS CLI, tôi kiểm tra danh tính bằng STS và biết credential đang đến từ profile nào.” Nếu chưa nói được câu này, hãy lặp lại phần CapEx/OpEx và checkpoint CLI trước khi sang Ngày 2.

aws --version
aws configure list-profiles
aws sts get-caller-identity --profile study
aws configure list --profile study
aws ec2 describe-regions --profile study --query 'Regions[0:3].RegionName' --output table