01.account

📚 AWS Accounts - Kiến thức nền tảng chi tiết¶

🎯 1. Khái niệm AWS Account (Điểm then chốt)¶

Sự khác biệt quan trọng nhất: - AWS Account ≠ User (người dùng trong account) - Nhiều người mới học thường nhầm lẫn hai khái niệm này

Hình dung AWS Account như một "ngôi nhà":

┌─────────────────────────────────────┐
│           AWS ACCOUNT               │
│  ┌─────────────┐ ┌─────────────────┐│
│  │ IDENTITIES  │ │   RESOURCES     ││
│  │ - Root User │ │ - EC2 instances ││
│  │ - IAM Users │ │ - S3 buckets    ││
│  │ - IAM Roles │ │ - RDS databases ││
│  │ - IAM Groups│ │ - Lambda funcs  ││
│  └─────────────┘ └─────────────────┘│
└─────────────────────────────────────┘

Đặc điểm của mỗi AWS Account: 1. Tên định danh duy nhất (Account ID: 12 chữ số) 2. Email duy nhất (1 email = 1 account, không thể trùng lặp) 3. Phương thức thanh toán riêng (credit card, bank account) 4. Billing boundary (ranh giới tính phí)

🔐 2. Account Root User - "Siêu quyền lực" và nguy hiểm¶

Đặc điểm của Root User: - Được tạo tự động khi bạn mở AWS Account - Email đăng ký = Username của Root User - Có quyền lực tuyệt đối, không thể bị giới hạn

Quyền hạn của Root User:

Root User CÓ THỂ:
✅ Xóa toàn bộ account
✅ Thay đổi phương thức thanh toán  
✅ Đóng account
✅ Thay đổi support plan
✅ Truy cập vào mọi service và resource
✅ Tạo/xóa bất kỳ tài nguyên nào

⚠️ RỦI RO CỰC LỚN: - Nếu thông tin Root User bị lộ → THẢM HỌA - Kẻ xấu có thể: - Xóa toàn bộ infrastructure - Tạo tài nguyên đắt tiền - Đánh cắp dữ liệu - Phá hoại hệ thống

🛡️ NGUYÊN TẮC VÀNG: 1. KHÔNG BAO GIỜ dùng Root User cho công việc hàng ngày 2. Chỉ dùng Root User cho các tác vụ chỉ Root User mới làm được 3. Bật MFA (Multi-Factor Authentication) ngay lập tức 4. Tạo password phức tạp và bảo mật tuyệt đối

🔑 3. IAM - Hệ thống quản lý truy cập an toàn¶

IAM (Identity and Access Management) là gì? - Dịch vụ miễn phí để quản lý ai có thể làm gì trong AWS Account - Thay thế Root User cho các tác vụ hàng ngày

Các loại Identity trong IAM:

IAM IDENTITIES:
├── IAM Users (Con người cụ thể)
│   ├── Developers
│   ├── Admins  
│   └── End users
│
├── IAM Groups (Nhóm users)
│   ├── Developers group
│   ├── Admins group
│   └── Marketing group
│
└── IAM Roles (Cho services/temp access)
    ├── EC2 role
    ├── Lambda role
    └── Cross-account role

🚫 Nguyên tắc "DENY BY DEFAULT": - Tất cả IAM identities mới tạo = 0 quyền - Phải explicitly grant (cấp quyền tường minh) - Ngược với Root User (có all permissions)

Ví dụ thực tế:

// IAM User mới tạo
{
  "Username": "john-developer",
  "Permissions": [],  // Rỗng!
  "CanAccess": "Nothing"
}

// Sau khi attach policy
{
  "Username": "john-developer", 
  "Permissions": ["S3:Read", "EC2:Describe"],
  "CanAccess": "Only S3 read and EC2 describe"
}

🏰 4. Account Boundary - "Bức tường pháo đài"¶

Account như một pháo đài:

    INTERNET
        │
        ▼
┌───────────────────────┐
│   ACCOUNT BOUNDARY    │  ← Bức tường bảo vệ
│  ┌─────────────────┐  │
│  │   Your AWS      │  │
│  │   Resources     │  │
│  │                 │  │
│  └─────────────────┘  │
└───────────────────────┘

Lợi ích của Account Boundary:

Blast Radius Containment:
Sự cố chỉ ảnh hưởng trong 1 account
Không lan sang account khác
Security Isolation:
Mặc định DENY mọi external access
Phải explicit allow để vào được
Billing Separation:
Mỗi account = 1 hóa đơn riêng
Dễ tracking chi phí theo team/project

🏢 5. Multi-Account Strategy¶

Tại sao doanh nghiệp dùng nhiều accounts?

Environment Separation:

COMPANY XYZ:
├── dev-account (Development)
├── test-account (Testing)  
├── staging-account (Staging)
└── prod-account (Production)

Team/Department Separation:

COMPANY ABC:
├── marketing-account
├── finance-account
├── engineering-account
└── hr-account

Product Separation:

TECH COMPANY:
├── product-a-account
├── product-b-account
└── shared-services-account

Lợi ích của Multi-Account: - ✅ Cô lập rủi ro - một team làm sai không ảnh hưởng team khác - ✅ Quản lý chi phí - biết team nào tốn bao nhiêu tiền - ✅ Compliance - đáp ứng yêu cầu bảo mật, audit - ✅ Flexibility - mỗi team tự do trong account của mình

🎓 6. Best Practices cho việc học¶

Tại sao nên tạo account mới để học?

❌ KHÔNG nên: - Dùng account công ty đang hoạt động - Dùng account cũ đã có cấu hình phức tạp - Dùng account đã có resources đắt tiền

✅ NÊN: - Tạo account hoàn toàn mới - Bắt đầu với clean slate - Học cách setup từ đầu

Trick tạo nhiều account với 1 email:

Email gốc: your-email@gmail.com

Có thể dùng:
- your-email+aws1@gmail.com
- your-email+general@gmail.com  
- your-email+production@gmail.com
- your-email+dev@gmail.com

📋 7. Roadmap thực hành¶

Theo danh sách bài học của bạn:

STEP 1: Tạo GENERAL AWS Account
STEP 2: Bảo mật account (MFA, strong password)
STEP 3: Tạo Budget để kiểm soát chi phí
STEP 4: Tạo IAM Admin User thay thế Root User
STEP 5: Setup AWS CLI với Access Keys

🔒 8. Security Checklist¶

Ngay sau khi tạo account: - [ ] Đổi password Root User thành password mạnh - [ ] Bật MFA cho Root User - [ ] Tạo IAM Admin User - [ ] Đăng xuất Root User - [ ] Chỉ dùng IAM Admin User từ giờ - [ ] Setup CloudTrail để audit - [ ] Tạo billing alerts

Tóm lại: AWS Account là nền tảng của mọi thứ. Hiểu rõ về account boundaries, Root User vs IAM, và security best practices sẽ giúp bạn xây dựng được kiến trúc AWS an toàn và scalable.

Bạn có muốn tôi đi sâu vào phần nào cụ thể không? Ví dụ như demo tạo account, setup MFA, hay IAM policies?ản mới sẽ giúp bạn học được cách cấu hình đúng chuẩn ngay từ đầu. * Trong các bài học tiếp theo, bạn sẽ được hướng dẫn cách tạo nhiều tài khoản mà chỉ cần dùng một email duy nhất.