Ngân hàng đề — AWS Certified Solutions Architect Associate

Đáp án

C — Tạo một gateway VPC endpoint và thêm một entry vào bảng định tuyến.

Vì sao đúng

Đề nêu ba yêu cầu, và gateway endpoint thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng ở subnet riêng tư truy vấn DynamoDB | endpoint cho đường đi riêng tư | | KHÔNG dùng endpoint công khai của DynamoDB | không qua Internet | | HIỆU QUẢ NHẤT và an toàn | gateway endpoint MIỄN PHÍ |

⚠ "Most EFFICIENT" là từ phân biệt C với D: | Loại endpoint | Dịch vụ | Phí | |---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | MIỄN PHÍ | | Interface endpoint | hầu hết dịch vụ | theo giờ + GB |

Cả hai đều đáp ứng yêu cầu riêng tư
    → nhưng gateway endpoint không tính phí gì
        ↓
    Với DynamoDB, gateway endpoint là lựa chọn hiển nhiên

Gateway endpoint hoạt động thế nào:

Nó thêm một route vào bảng định tuyến:
    đích = prefix list của DynamoDB (pl-xxxxx)
    next hop = vpce-xxxxx
        ↓
    Gói tin tới DynamoDB rẽ vào endpoint
    → không đi qua Internet Gateway hay NAT

Tạo endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.dynamodb \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-rieng-tu-a rtb-rieng-tu-b

⚠ Tham số --route-table-ids là bước quyết định:

Tạo endpoint mà quên chọn route table
    → không có route nào được thêm
    → lưu lượng vẫn đi qua NAT như cũ
        ↓
    Mọi thứ VẪN CHẠY — không có lỗi nào
    → chỉ là vẫn qua Internet và vẫn tốn phí NAT

Kiểm tra route đã có:

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu-a \
  --query "RouteTables[0].Routes[?VpcEndpointId!=null]" --output table

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | MIỄN PHÍ hoàn toàn | | | Không đi qua Internet | | | Tiết kiệm phí xử lý dữ liệu của NAT | |

Và nên siết thêm bằng endpoint policy:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["dynamodb:GetItem","dynamodb:Query","dynamodb:PutItem"],
  "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/BangUngDung"}]}

Endpoint chỉ cho phép truy cập bảng của ứng dụng
    → mã độc trong EC2 không đọc bảng khác

Vì sao các phương án khác sai

• **D. Tạo interface VPC endpoint với ENI — đây là phương án gần nhất và hoàn toàn đáp ứng yêu cầu riêng tư, nhưng nó tính phí theo giờ mỗi AZ cộng phí theo GB, trong khi gateway endpoint cho DynamoDB là miễn phí. Đề hỏi "MOST EFFICIENT". (Interface endpoint cho DynamoDB chỉ cần khi truy cập từ tại chỗ qua DX/VPN.)
• **A. Tạo "private DynamoDB endpoint" và kết nối qua VPN — không có khái niệm này; VPN nối mạng tại chỗ với VPC, không nối tới một dịch vụ AWS.
• **B. Tạo software VPN giữa DynamoDB và ứng dụng — DynamoDB không phải một mạng để dựng VPN tới. Đây là mô tả một thứ không tồn tại.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Cơ chế | route trong route table | ENI có IP riêng | | Phí | MIỄN PHÍ | theo giờ + GB | | Từ tại chỗ (DX/VPN) | ❌ | ✅ | | Security group | ❌ | ✅ | | DNS riêng | ❌ | ✅ |

Từ khoá nhận diện:

"S3 or DynamoDB privately" + "efficient/cost-effective" → gateway endpoint "access from on-premises privately" → interface endpoint "other AWS services privately" → interface endpoint

⚠ Ba đặc điểm của gateway endpoint: | Đặc điểm | Chi tiết | |---|---| | Miễn phí hoàn toàn | | | CHỈ dùng được TỪ TRONG VPC | | | Phải gắn vào BẢNG ĐỊNH TUYẾN | |

Ba lớp bảo vệ nên có cùng nhau: | Lớp | Việc | |---|---| | VPC endpoint | đường đi riêng tư | | Endpoint policy | giới hạn bảng được truy cập | | IAM policy trên role của EC2 | ai làm được gì |

⚠ Ba khoá điều kiện IAM liên quan: | Khoá | Nghĩa | |---|---| | aws:SourceVpce | một endpoint cụ thể | | aws:SourceVpc | mọi endpoint trong VPC | | aws:PrincipalOrgID | tài khoản trong tổ chức |

Chính sách trên bảng DynamoDB (resource-based policy):

{"Effect": "Deny", "Principal": "*", "Action": "dynamodb:*",
 "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/BangUngDung",
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

⚠ Cách giảm chi phí NAT hiệu quả nhất:

Dùng VPC endpoint cho các dịch vụ AWS
    → S3 và DynamoDB: gateway endpoint MIỄN PHÍ
    → dịch vụ khác: interface endpoint
        ↓
    Lưu lượng tới dịch vụ AWS không qua NAT
    → tiết kiệm phí xử lý GB đáng kể

Ba dịch vụ hay cần interface endpoint: | Dịch vụ | Vì sao | |---|---| | Secrets Manager | lấy credential | | SSM, SSMMessages, EC2Messages | Session Manager | | ECR api và dkr | kéo ảnh container |

⚠ Kéo ảnh ECR cần CẢ gateway endpoint cho S3:

Lớp ảnh container nằm trong S3
    → có endpoint ECR nhưng thiếu S3 gateway endpoint
    → xác thực thành công, tải lớp ảnh thất bại

Ba lưu ý về prefix list: | Lưu ý | Chi tiết | |---|---| | Route dùng prefix list ID | AWS tự cập nhật dải IP | | Dùng được trong security group rule | | | Xem bằng describe-prefix-lists | |

aws ec2 describe-prefix-lists \
  --filters "Name=prefix-list-name,Values=com.amazonaws.ap-southeast-1.dynamodb"

Ba lưu ý về DynamoDB Streams: | Lưu ý | Chi tiết | |---|---| | Streams có endpoint RIÊNG | dynamodb.streams | | Cần interface endpoint cho Streams | gateway không phủ | | Kiểm tra nếu ứng dụng đọc stream | |

Ba cách chẩn đoán khi không kết nối được: | Cách | Công cụ | |---|---| | Kiểm tra route table | | | VPC Reachability Analyzer | | | VPC Flow Logs | xem gói bị REJECT |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Endpoint không giới hạn băng thông | | | Độ trễ thấp hơn đi qua NAT | | | Không có điểm hỏng đơn lẻ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra route đã thêm chưa | | | Thử aws dynamodb list-tables từ EC2 | | | Xem Flow Logs không còn lưu lượng ra IGW | |

Và một lời khuyên: hãy tạo gateway endpoint cho cả S3 và DynamoDB ở mọi VPC ngay khi dựng. Chúng miễn phí, giảm độ trễ, tăng bảo mật, và cắt bớt một khoản phí NAT mà hầu như không ai để ý cho tới khi đọc kỹ hoá đơn.

Đáp án

B — Dùng Amazon CloudFront phục vụ ứng dụng và từ chối truy cập từ các quốc gia bị chặn.

Vì sao đúng

Đề nêu hai yêu cầu, và geo restriction của CloudFront là cách đơn giản nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Chặn truy cập theo QUỐC GIA | CloudFront geo restriction | | Cách DỄ NHẤT | một cấu hình, không cần danh sách IP |

⚠ Vì sao chặn theo IP là không khả thi:

Một quốc gia có hàng nghìn dải IP
    → danh sách thay đổi liên tục
    → phải tự duy trì
        ↓
    NACL giới hạn 20 quy tắc (tối đa 40)
    → không đủ chỗ cho một quốc gia

Đây là lý do loại phương án A.

CloudFront geo restriction:

aws cloudfront update-distribution --id E123ABC \
  --distribution-config '{
    "Restrictions": {"GeoRestriction": {
      "RestrictionType": "blacklist",
      "Quantity": 3,
      "Items": ["CN", "RU", "IR"]}},
    ...}'

Hai kiểu hạn chế: | Kiểu | Nghĩa | |---|---| | blacklist | chặn các quốc gia liệt kê ← đề cần | | whitelist | chỉ cho các quốc gia liệt kê |

Cách CloudFront xác định quốc gia:

CloudFront tra IP của người dùng trong cơ sở dữ liệu địa lý
    → xác định mã quốc gia ISO 3166 hai chữ
        ↓
    Chặn ở EDGE — request không tới ALB
    → không tốn tài nguyên nào phía sau

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn ngay ở edge, gần người dùng nhất | | | AWS duy trì cơ sở dữ liệu địa lý | | | Trả về 403 tuỳ chỉnh được | |

Trang lỗi tuỳ chỉnh cho vùng bị chặn:

{"CustomErrorResponses": {"Quantity": 1, "Items": [
  {"ErrorCode": 403, "ResponsePagePath": "/khong-kha-dung.html",
   "ResponseCode": "403", "ErrorCachingMinTTL": 300}]}}

Vì sao các phương án khác sai

• **A. Dùng network ACL chặn dải IP của các quốc gia — đây là phương án gần nhất vì NACL đúng là công cụ duy nhất ngoài WAF có quy tắc Deny theo IP, nhưng nó bất khả thi trên thực tế: phải tự duy trì hàng nghìn dải IP, và NACL chỉ chứa được 20-40 quy tắc.
• **C. Sửa security group của EC2 để từ chối lưu lượng từ quốc gia bị chặn — sai hai lần: security group không có quy tắc Deny, và EC2 nằm sau ALB nên chỉ thấy IP của ALB.
• **D. Sửa security group của ALB để từ chối — cùng vấn đề: security group chỉ có Allow, và không hiểu khái niệm quốc gia.

Ghi nhớ

⚠ Ba cách chặn theo quốc gia trên AWS — bảng phải thuộc: | Cách | Ở đâu | Đặc điểm | |---|---|---| | CloudFront geo restriction | edge | đơn giản nhất ← câu này | | AWS WAF geo match rule | CloudFront, ALB, API Gateway | linh hoạt hơn, kết hợp điều kiện khác | | Route 53 geolocation routing | DNS | định tuyến, không phải chặn |

⚠ WAF geo match linh hoạt hơn khi cần logic phức tạp:

{"Name":"ChanQuocGia","Priority":0,
 "Statement":{"GeoMatchStatement":{"CountryCodes":["CN","RU","IR"]}},
 "Action":{"Block":{}},
 "VisibilityConfig":{"SampledRequestsEnabled":true,
   "CloudWatchMetricsEnabled":true,"MetricName":"ChanQuocGia"}}

WAF cho phép kết hợp:
    → chặn quốc gia X TRỪ KHI có header đặc biệt
    → hoặc chỉ chặn trên một đường dẫn nhất định
        ↓
    Geo restriction của CloudFront là chặn cứng toàn bộ

Từ khoá nhận diện:

"block specific countries" + "easiest" → CloudFront geo restriction "block countries with additional conditions" → WAF geo match "route users by country" → Route 53 geolocation "block a specific IP" → WAF IP set

⚠ Bốn công cụ lọc — bảng chọn nhanh: | Công cụ | Hiểu quốc gia | Có Deny | |---|---|---| | CloudFront geo restriction | ✅ | ✅ | | AWS WAF | ✅ | ✅ | | Network ACL | ❌ chỉ IP | ✅ | | Security Group | ❌ | ❌ chỉ Allow |

Ba lưu ý về độ chính xác địa lý: | Lưu ý | Chi tiết | |---|---| | Dựa trên cơ sở dữ liệu IP → quốc gia | | | VPN và proxy làm sai lệch | | | Không tuyệt đối 100% | |

⚠ Vế thứ hai đáng nói với yêu cầu bản quyền:

Geo restriction chặn được đa số
    → nhưng người dùng dùng VPN vẫn vào được
        ↓
    Với yêu cầu pháp lý nghiêm ngặt,
    cần thêm xác thực và kiểm tra tài khoản

Ba lưu ý khi đặt CloudFront trước ALB: | Lưu ý | Chi tiết | |---|---| | Alias record trỏ tới distribution | | | Chứng chỉ ACM phải ở us-east-1 | | | Giới hạn ALB chỉ nhận từ CloudFront | |

Chặn đường vào thẳng ALB:

CloudFront thêm custom header bí mật
    → ALB listener rule chỉ chấp nhận request có header đó
        ↓
    Không ai bỏ qua CloudFront để vào thẳng ALB
    → và do đó không lách được geo restriction

aws elbv2 create-rule --listener-arn <arn-listener> --priority 1 \
  --conditions '[{"Field":"http-header",
    "HttpHeaderConfig":{"HttpHeaderName":"X-Origin-Secret",
      "Values":["<chuoi-bi-mat>"]}}]' \
  --actions Type=forward,TargetGroupArn=<arn-tg>

⚠ Đây là bước bắt buộc, không phải tuỳ chọn:

Không chặn đường vào thẳng ALB
    → ALB vẫn có tên miền công khai
    → ai biết tên đó đi thẳng, bỏ qua geo restriction
        ↓
    Toàn bộ cơ chế chặn quốc gia trở nên vô nghĩa

Ba mã quốc gia hay dùng (ISO 3166-1 alpha-2): | Mã | Quốc gia | |---|---| | VN | Việt Nam | | US | Hoa Kỳ | | JP | Nhật Bản |

Ba lưu ý về CloudFront với nội dung động: | Lưu ý | Chi tiết | |---|---| | CloudFront vẫn tăng tốc nội dung động | TLS ở edge, mạng AWS | | Dùng CachingDisabled cho đường dẫn động | | | Cache riêng cho nội dung tĩnh | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Request bị chặn KHÔNG tính phí truyền dữ liệu | | | Vẫn tính phí request | | | Chọn price class hợp phân bố khách | |

Ba lưu ý về theo dõi: | Cách | Chi tiết | |---|---| | CloudFront standard log ghi mã quốc gia | | | Metric 403 error rate | | | Kiểm tra không chặn nhầm khách hợp lệ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử truy cập bằng VPN từ quốc gia bị chặn | phải nhận 403 | | Thử từ quốc gia hợp lệ | phải vào được | | Thử vào thẳng ALB | phải bị từ chối |

Và một lời khuyên: hãy chặn đường vào thẳng ALB cùng lúc với việc bật geo restriction. Một hạn chế địa lý hoàn hảo ở CloudFront vẫn vô dụng nếu tên miền của ALB còn công khai — và đó là điều mà bất kỳ ai đọc bản ghi DNS cũng tìm ra trong vài phút.

Đáp án

B và D.

• B — Tạo subnet công khai và riêng tư mới trong cùng VPC, mỗi cái ở một AZ MỚI, và chuyển CSDL sang RDS Multi-AZ
• D — Tạo EC2 Auto Scaling group và Application Load Balancer trải qua NHIỀU AZ

Vì sao đúng

Đề mô tả một kiến trúc có hai điểm hỏng đơn lẻ, và phải sửa cả hai: | Tầng | Hiện trạng | Sửa bằng | |---|---|---| | Tầng web ở subnet công khai | một AZ | D: ASG + ALB đa AZ | | Tầng CSDL trên EC2 ở subnet riêng tư | một AZ, tự quản | B: RDS Multi-AZ |

Sửa một tầng là chưa đủ:

Chỉ làm D:  web đa AZ, CSDL vẫn ở AZ-a
            → AZ-a hỏng → mất CSDL → ứng dụng chết
                ↓
        Web sống nhưng không có dữ liệu = vẫn ngừng dịch vụ

Chỉ làm B:  CSDL đa AZ, web vẫn ở AZ-a
            → AZ-a hỏng → không còn máy web nào

⚠ Và B còn tạo điều kiện tiên quyết cho D:

ALB và ASG cần SUBNET ở mỗi AZ mà chúng chạy
    → subnet gắn với đúng MỘT AZ
        ↓
    Phải tạo subnet ở AZ thứ hai trước
    → đó chính là nửa đầu của phương án B

Tạo subnet mới:

aws ec2 create-subnet --vpc-id vpc-abc \
  --cidr-block 10.0.10.0/24 --availability-zone ap-southeast-1b
aws ec2 create-subnet --vpc-id vpc-abc \
  --cidr-block 10.0.11.0/24 --availability-zone ap-southeast-1b

Chuyển CSDL sang RDS Multi-AZ:

aws rds create-db-subnet-group --db-subnet-group-name nhom-rieng-tu \
  --db-subnet-group-description "Subnet rieng tu hai AZ" \
  --subnet-ids subnet-rieng-a subnet-rieng-b

aws rds create-db-instance --db-instance-identifier csdl-ung-dung \
  --engine mysql --db-instance-class db.m6g.large \
  --allocated-storage 100 --multi-az \
  --db-subnet-group-name nhom-rieng-tu \
  --no-publicly-accessible --storage-encrypted

Và ASG + ALB đa AZ:

aws elbv2 create-load-balancer --name alb-web --type application \
  --scheme internet-facing --subnets subnet-cong-khai-a subnet-cong-khai-b

aws autoscaling create-auto-scaling-group --auto-scaling-group-name asg-web \
  --launch-template LaunchTemplateName=mau-web,Version='$Latest' \
  --min-size 2 --max-size 10 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-cong-khai-a,subnet-cong-khai-b" \
  --target-group-arns <arn-tg> --health-check-type ELB

Kiến trúc kết quả:

        Internet
            │
        ┌───▼───┐
        │  ALB  │  (subnet công khai AZ-a + AZ-b)
        └───┬───┘
      ┌─────┴─────┐
   [EC2 AZ-a]  [EC2 AZ-b]     ← ASG trải hai AZ
      └─────┬─────┘
    ┌───────▼────────┐
    │ RDS primary a  │◀──sync──▶│ RDS standby b │
    └────────────────┘   (subnet riêng tư)

Ba lợi ích của việc chuyển sang RDS: | Lợi ích | Chi tiết | |---|---| | Chuyển đổi dự phòng TỰ ĐỘNG | không cần script | | Sao lưu tự động, khôi phục theo thời điểm | | | AWS lo vá lỗi và nâng cấp | |

Vì sao các phương án khác sai

• **C. Tạo subnet mới ở AZ mới, tạo CSDL bằng EC2 trong một AZ — đây là phương án gần nhất vì nửa đầu đúng, nhưng nửa sau giữ nguyên vấn đề: CSDL tự quản trên EC2 trong một AZ vẫn là điểm hỏng đơn lẻ.
• **A. Đưa các máy web hiện có vào ASG sau ALB — thiếu vế "trải qua nhiều AZ", và không đụng gì tới tầng CSDL. Một ASG trong một AZ vẫn chết cùng AZ đó.
• **E. Tạo subnet công khai và riêng tư mới trong CÙNG AZ — không giúp gì: subnet mới ở cùng AZ nghĩa là cùng hạ tầng vật lý, AZ hỏng thì cả hai cùng chết.

Ghi nhớ

⚠ Nguyên tắc gốc:

Tính sẵn sàng cao của một hệ thống = tầng YẾU NHẤT. Phải kiểm tra MỌI tầng, không chỉ tầng đầu.

Từ khoá nhận diện:

"single AZ" + "high availability" + "Select TWO" → một câu cho tầng web, một cho tầng CSDL "database on EC2" + "high availability" → chuyển sang RDS Multi-AZ "new subnets in the SAME AZ" → luôn sai

⚠ Phân biệt subnet và AZ: | Khái niệm | Quan hệ | |---|---| | Availability Zone | trung tâm dữ liệu riêng biệt | | Subnet | thuộc ĐÚNG MỘT AZ | | Một AZ | có thể chứa nhiều subnet |

"Subnet mới" KHÔNG đảm bảo "AZ mới"
    → phải khai rõ --availability-zone

⚠ Ba lựa chọn dự phòng cho CSDL: | Lựa chọn | Chuyển đổi | Đọc từ bản phụ | |---|---|---| | RDS Multi-AZ (standby) | tự động 1-2 phút | ❌ KHÔNG phục vụ đọc | | RDS Multi-AZ DB cluster | tự động < 35 giây | ✅ 2 bản đọc được | | Read replica | THỦ CÔNG | ✅ |

⚠ "Standby không phục vụ đọc" là hiểu nhầm phổ biến nhất về RDS.

Multi-AZ và Read Replica — bảng phân biệt: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | tính sẵn sàng | hiệu năng đọc | | Sao chép | đồng bộ | bất đồng bộ | | Chuyển đổi | tự động | thủ công (promote) | | Vị trí | AZ khác cùng vùng | cả vùng khác |

Ba yêu cầu mạng cho RDS Multi-AZ: | Yêu cầu | Chi tiết | |---|---| | DB subnet group có subnet ở ≥ 2 AZ | | | Cả hai subnet đều RIÊNG TƯ | | | Security group cho phép từ tầng web | |

⚠ Dòng đầu là lỗi hay gặp khi bật Multi-AZ:

DB subnet group chỉ có subnet ở một AZ
    → không bật được --multi-az
    → lỗi "DB Subnet Group doesn't meet availability zone coverage"

Ba lưu ý khi chuyển CSDL từ EC2 sang RDS: | Lưu ý | Chi tiết | |---|---| | Dùng DMS để chuyển gần như không ngừng | | | Kiểm tra phiên bản engine tương thích | | | RDS không cho truy cập SSH vào máy | |

Ba loại health check của ASG: | Loại | Kiểm tra | |---|---| | EC2 (mặc định) | chỉ trạng thái máy | | ELB | ứng dụng có trả lời không | | Custom | qua API |

⚠ NAT Gateway cũng phải đa AZ:

NAT Gateway chỉ ở AZ-a
    → AZ-a hỏng → máy ở AZ-b mất đường ra Internet
        ↓
    Đặt một NAT Gateway ở MỖI AZ
    → và mỗi AZ một route table riêng

Ba lưu ý về ứng dụng khi failover: | Lưu ý | Chi tiết | |---|---| | Kết nối đang mở BỊ NGẮT | ứng dụng phải thử lại | | Endpoint DNS giữ nguyên | | | Connection pool phải xử lý được | |

Ba lưu ý về trạng thái tầng web: | Lưu ý | Chi tiết | |---|---| | Session trong bộ nhớ sẽ mất khi chuyển máy | | | Chuyển sang ElastiCache hoặc DynamoDB | | | Hoặc bật sticky session (tạm) | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | describe-subnets xác nhận đúng hai AZ | | | Tắt hết máy một AZ, xem còn phục vụ không | | | Ép failover RDS | reboot-db-instance --force-failover |

Và một lời khuyên: hãy ép một lần chuyển đổi dự phòng RDS vào giờ thấp điểm ngay sau khi bật Multi-AZ. Đó là cách duy nhất để biết ứng dụng có xử lý được việc mất kết nối hay không — và biết điều đó vào một buổi tối bạn chọn thì tốt hơn nhiều so với vào lúc AWS chọn giúp bạn.

Đáp án

B — Lưu thông tin đăng nhập trong Systems Manager Parameter Store, và cập nhật mã hàm cùng execution role.

Vì sao đúng

Đề nêu ba yêu cầu, và Parameter Store thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Lambda cần credential để nối Aurora MySQL | lấy từ Parameter Store lúc chạy | | KHÔNG được để credential trong mã hàm | chỉ lưu tên tham số trong mã | | Lưu an toàn | SecureString mã hoá bằng KMS |

Lưu credential:

aws ssm put-parameter --name /ung-dung/csdl/mat-khau \
  --value 'MatKhauRatDaiVaKho123!' --type SecureString \
  --key-id alias/khoa-bi-mat

Lambda đọc lúc chạy:

import boto3, os
ssm = boto3.client('ssm')

# Đọc NGOÀI handler để tái dùng giữa các lần gọi
tham_so = ssm.get_parameter(
    Name='/ung-dung/csdl/mat-khau', WithDecryption=True)
mat_khau = tham_so['Parameter']['Value']

def handler(event, context):
    ket_noi = pymysql.connect(
        host=os.environ['DB_HOST'], user='ungdung',
        password=mat_khau, database='ungdung')
    ...

⚠ Execution role cần HAI quyền:

{"Version": "2012-10-17",
 "Statement": [
   {"Effect": "Allow",
    "Action": ["ssm:GetParameter", "ssm:GetParameters"],
    "Resource": "arn:aws:ssm:ap-southeast-1:123456789012:parameter/ung-dung/csdl/*"},
   {"Effect": "Allow",
    "Action": "kms:Decrypt",
    "Resource": "arn:aws:kms:ap-southeast-1:123456789012:key/abc-123"}]}

⚠ Quên kms:Decrypt là lỗi rất hay gặp:

Cấp ssm:GetParameter nhưng quên kms:Decrypt
    → AccessDeniedException nhắc tới KMS
    → dễ tưởng là lỗi của Parameter Store

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Credential không nằm trong mã hay biến môi trường | | | Mã hoá bằng KMS, có audit trong CloudTrail | | | Đổi mật khẩu không phải triển khai lại hàm | |

Vế thứ ba đáng nhấn mạnh:

Đặt mật khẩu trong biến môi trường của Lambda
    → đổi mật khẩu phải cập nhật cấu hình hàm
        ↓
    Parameter Store: đổi giá trị tham số là xong
    → hàm tự lấy bản mới ở lần gọi sau

⚠ Và nên cache trong bộ nhớ để giảm số lần gọi API:

Đọc tham số ở phạm vi module (ngoài handler)
    → chỉ gọi một lần cho mỗi container Lambda
    → tái dùng cho nhiều lần gọi
        ↓
    Giảm độ trễ và tránh chạm giới hạn tần suất

Vì sao các phương án khác sai

• **C. Dùng AWSAuthenticationPlugin và gán một IAM user trong CSDL MySQL — đây là phương án gần nhất vì mô tả đúng cơ chế IAM database authentication, và thực ra đó là cách an toàn hơn cả (không có mật khẩu nào). Nhưng cách diễn đạt nhắc tới "IAM user account", trong khi Lambda dùng role; và đề hỏi cách lưu trữ credential, còn phương án này thì bỏ hẳn credential.
• **A. Lưu credential trong AWS KMS và trỏ biến môi trường tới KMS — KMS không lưu trữ bí mật: nó là dịch vụ quản lý khoá mã hoá, dùng để mã hoá dữ liệu chứ không chứa dữ liệu.
• **D. Tạo IAM policy và lưu credential TRONG policy — vi phạm nghiêm trọng về bảo mật: IAM policy là tài liệu công khai với bất kỳ ai đọc được cấu hình IAM, hoàn toàn không phải nơi cất mật khẩu.

Ghi nhớ

⚠ Ba nơi lưu bí mật trên AWS — bảng phải thuộc: | Dịch vụ | Xoay tự động | Giá | |---|---|---| | Secrets Manager | ✅ có sẵn cho RDS | ~0,40 USD/secret/tháng | | Parameter Store (SecureString) | ❌ tự viết | Standard MIỄN PHÍ | | KMS | không lưu bí mật | quản lý khoá |

⚠ Secrets Manager và Parameter Store — bảng phân biệt: | | Secrets Manager | Parameter Store | |---|---|---| | Xoay tự động | ✅ | ❌ | | Giá | trả phí | miễn phí (Standard) | | Chia sẻ chéo tài khoản | ✅ | Advanced | | Nhân bản đa vùng | ✅ | ❌ | | Kích thước tối đa | 64 KB | 4 KB / 8 KB |

Cần xoay tự động → Secrets Manager
Chỉ cần lưu an toàn, tiết kiệm → Parameter Store

Từ khoá nhận diện:

"store credentials securely, not in code" → Parameter Store hoặc Secrets Manager "rotate credentials automatically" → Secrets Manager "no credentials at all" → IAM database authentication "connection pooling for Lambda" → RDS Proxy

⚠ IAM database authentication đáng biết — an toàn hơn cả:

import boto3
token = boto3.client('rds').generate_db_auth_token(
    DBHostname=HOST, Port=3306, DBUsername='app_user')

ket_noi = pymysql.connect(host=HOST, user='app_user',
                          password=token, ssl={'ca': '/opt/rds-ca.pem'})

Token sinh từ IAM, hạn 15 phút
    → KHÔNG có mật khẩu nào để lưu, để xoay, để rò rỉ
        ↓
    Nhưng có giới hạn số kết nối mỗi giây

Bật IAM auth trên Aurora:

aws rds modify-db-cluster --db-cluster-identifier cum-aurora \
  --enable-iam-database-authentication --apply-immediately

CREATE USER app_user IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
GRANT SELECT, INSERT, UPDATE ON ungdung.* TO app_user;

⚠ AWSAuthenticationPlugin chính là thứ phương án C nhắc tới — nó có thật và là cách hiện đại, chỉ khác là dùng với role chứ không phải IAM user.

Ba loại tham số của Parameter Store: | Loại | Đặc điểm | |---|---| | String | văn bản thường | | StringList | danh sách phân cách bằng dấu phẩy | | SecureString | mã hoá bằng KMS |

Hai tier của Parameter Store: | Tier | Đặc điểm | |---|---| | Standard | miễn phí, 10.000 tham số, 4 KB | | Advanced | trả phí, 100.000 tham số, 8 KB, có policy |

⚠ Advanced tier có parameter policy hữu ích:

aws ssm put-parameter --name /ung-dung/csdl/mat-khau \
  --value '...' --type SecureString --tier Advanced \
  --policies '[{"Type":"Expiration","Version":"1.0",
    "Attributes":{"Timestamp":"2026-12-31T00:00:00.000Z"}},
   {"Type":"NoChangeNotification","Version":"1.0",
    "Attributes":{"After":"90","Unit":"Days"}}]'

Cảnh báo nếu tham số không đổi quá 90 ngày
    → nhắc xoay mật khẩu

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Đọc NGOÀI handler để tái dùng | | | Dùng Parameters and Secrets Lambda Extension | có cache sẵn | | GetParameters lấy nhiều tham số một lần | |

Lambda extension có cache:

import urllib.request, os, json
url = ('http://localhost:2773/systemsmanager/parameters/get'
       '?name=/ung-dung/csdl/mat-khau&withDecryption=true')
req = urllib.request.Request(url)
req.add_header('X-Aws-Parameters-Secrets-Token',
               os.environ['AWS_SESSION_TOKEN'])
gia_tri = json.loads(urllib.request.urlopen(req).read())

⚠ Ba vấn đề khi Lambda nối CSDL quan hệ: | Vấn đề | Cách chữa | |---|---| | Bùng nổ số kết nối | RDS Proxy | | Khởi động lạnh trong VPC | provisioned concurrency | | Credential trong mã | Parameter Store / Secrets Manager |

RDS Proxy giải quyết vấn đề đầu:

aws rds create-db-proxy --db-proxy-name proxy-aurora \
  --engine-family MYSQL --role-arn <arn-role> \
  --auth '[{"AuthScheme":"SECRETS","SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]' \
  --vpc-subnet-ids subnet-a subnet-b

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Lambda trong VPC cần VPC endpoint cho SSM | | | Và endpoint cho KMS | | | Hoặc đi qua NAT Gateway | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra mã hàm không chứa mật khẩu | | | Xem CloudTrail ghi lần đọc tham số | | | Đổi mật khẩu và xác nhận hàm vẫn chạy | |

Và một lời khuyên: hãy cân nhắc IAM database authentication trước khi chọn nơi lưu mật khẩu. Câu hỏi "cất mật khẩu ở đâu cho an toàn" luôn có câu trả lời tốt hơn là "không có mật khẩu nào cả" — và với Aurora MySQL thì lựa chọn đó đã sẵn sàng.

Đáp án

C — Cấu hình một Application Load Balancer phía trước một Auto Scaling group triển khai instance qua nhiều Availability Zone.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này thoả cả ba với công ít nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng chạy trên EC2 | | | Cần TÍNH SẴN SÀNG CAO | trải qua nhiều AZ | | CO GIÃN ĐỘNG theo nhu cầu, tiết kiệm | Auto Scaling group |

Vì sao đa AZ là đủ cho "high availability":

Tính sẵn sàng cao = chịu được hỏng một trung tâm dữ liệu
    → đó chính là ranh giới của một Availability Zone
        ↓
    Đa VÙNG là cho khôi phục THẢM HOẠ (DR)
    → phức tạp và tốn kém hơn nhiều

Đây là lý do loại cả A và D.

Cấu hình:

aws elbv2 create-load-balancer --name alb-ung-dung --type application \
  --scheme internet-facing --subnets subnet-az-a subnet-az-b subnet-az-c

aws autoscaling create-auto-scaling-group --auto-scaling-group-name asg-ung-dung \
  --launch-template LaunchTemplateName=mau-ung-dung,Version='$Latest' \
  --min-size 2 --max-size 20 --desired-capacity 3 \
  --vpc-zone-identifier "subnet-az-a,subnet-az-b,subnet-az-c" \
  --target-group-arns <arn-tg> --health-check-type ELB \
  --health-check-grace-period 300

Chính sách co giãn:

aws autoscaling put-scaling-policy --auto-scaling-group-name asg-ung-dung \
  --policy-name theo-request --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{"TargetValue":1000.0,
    "PredefinedMetricSpecification":{
      "PredefinedMetricType":"ALBRequestCountPerTarget",
      "ResourceLabel":"app/alb-ung-dung/abc/targetgroup/tg-ung-dung/xyz"}}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mất một AZ vẫn phục vụ | | | Tự thêm máy khi tải tăng | | | Tự bớt máy khi tải giảm | tiết kiệm |

Và ba AZ tốt hơn hai: | Số AZ | Mất 1 AZ còn | Dự phòng cần | |---|---|---| | 2 AZ | 50% | +100% | | 3 AZ | 67% | +50% |

Vì sao các phương án khác sai

• **A. ALB phía trước ASG triển khai instance qua nhiều VÙNG — đây là phương án gần nhất vì cũng dùng đúng ALB và ASG, nhưng nó bất khả thi: một ASG và một ALB đều chỉ hoạt động trong MỘT vùng. Muốn đa vùng phải dựng hai bộ hạ tầng riêng cộng Route 53.
• **D. CloudFront phía trước ASG triển khai qua nhiều vùng — cùng vấn đề đa vùng, và CloudFront là CDN, không phải load balancer cho EC2 trong một vùng.
• **B. API Gateway phía trước ASG qua nhiều AZ — API Gateway là cổng API, không phân phối tải tới EC2 theo cách của một load balancer. (Có thể tích hợp qua VPC Link tới NLB, nhưng đó là kiến trúc khác và phức tạp hơn.)

Ghi nhớ

⚠ Ba tầng dự phòng — bảng phải thuộc: | Tầng | Bảo vệ khỏi | Công | |---|---|---| | Nhiều AZ trong một Region | hỏng một trung tâm dữ liệu | thấp ← câu này | | Nhiều Region | thảm hoạ cả vùng | cao | | Nhiều tài khoản | sự cố quản trị | cao |

⚠ Ba khái niệm dễ lẫn: | Khái niệm | Nghĩa | |---|---| | Tính sẵn sàng cao (HA) | tự chịu được hỏng, KHÔNG gián đoạn | | Khôi phục thảm hoạ (DR) | phục hồi sau sự cố lớn, có RTO/RPO | | Khả năng chịu lỗi (FT) | hoạt động bình thường dù có lỗi |

"Highly available" → đa AZ là đủ
"Region-wide outage" → mới cần đa vùng

Từ khoá nhận diện:

"highly available" + "dynamically scale" + EC2 → ALB + ASG đa AZ "Region-wide outage" → đa vùng + Route 53 "cache static content globally" → CloudFront "REST API with authorization" → API Gateway

⚠ Ba dịch vụ và phạm vi của chúng: | Dịch vụ | Phạm vi | |---|---| | Auto Scaling group | MỘT vùng, nhiều AZ | | Application Load Balancer | MỘT vùng, nhiều AZ | | CloudFront, Route 53, Global Accelerator | TOÀN CẦU |

Ba loại Elastic Load Balancer: | Loại | Tầng | Giao thức | |---|---|---| | Application Load Balancer | 7 | HTTP, HTTPS, gRPC | | Network Load Balancer | 4 | TCP, UDP, TLS | | Gateway Load Balancer | 3/4 | thiết bị bảo mật |

Bốn kiểu chính sách co giãn: | Kiểu | Khi nào | |---|---| | Target tracking | mặc định nên dùng | | Step scaling | cần kiểm soát chi tiết | | Simple scaling | kiểu cũ | | Scheduled | tải biết trước |

Ba metric dựng sẵn: | Metric | Phù hợp khi | |---|---| | ASGAverageCPUUtilization | tải nặng CPU | | ALBRequestCountPerTarget | phản ứng nhanh hơn CPU | | ASGAverageNetworkIn/Out | tải nặng mạng |

⚠ Ba loại health check của ASG: | Loại | Kiểm tra | |---|---| | EC2 (mặc định) | chỉ trạng thái máy | | ELB | ứng dụng có trả lời không | | Custom | qua API |

Kiểu EC2: ứng dụng treo mà máy vẫn "running"
    → ASG không thay máy
    → ALB vẫn gửi request → lỗi 5xx tiếp tục

Ba yêu cầu để ASG đa AZ chạy đúng: | Yêu cầu | Chi tiết | |---|---| | Mỗi AZ có subnet riêng | | | ALB bật ở cùng các AZ | | | Ứng dụng không giữ trạng thái cục bộ | |

⚠ Vế thứ ba là chỗ hay gãy:

Session lưu trong bộ nhớ máy
    → người dùng bị chuyển máy → mất đăng nhập
        ↓
    Chuyển session sang ElastiCache hoặc DynamoDB
    → hoặc bật sticky session (giải pháp tạm)

Ba tham số dung lượng: | Tham số | Lưu ý | |---|---| | min-size | đủ chịu tải nền VÀ dự phòng AZ | | max-size | trần chi phí | | desired-capacity | co giãn thay đổi con số này |

⚠ Tính min-size cho dự phòng AZ:

Cần 4 máy để chịu tải, trải 2 AZ
    → mất một AZ còn 2 máy → không đủ
        ↓
    Đặt min = 4 với 3 AZ, hoặc min = 6 với 2 AZ

Ba cách giảm chi phí: | Cách | Chi tiết | |---|---| | Mixed instance policy với Spot | | | Savings Plans cho tải nền | | | Right-size bằng Compute Optimizer | |

Ba tầng cần kiểm tra, không chỉ tầng web: | Tầng | Cách làm đa AZ | |---|---| | Web / ứng dụng | ASG + ALB | | CSDL | RDS Multi-AZ hoặc Aurora | | NAT Gateway | một cái mỗi AZ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem phân bố instance theo AZ | | | Tắt hết máy một AZ | | | Thử tải để xem có co giãn không | |

Và một lời khuyên: hãy tính min-size sao cho mất một AZ vẫn đủ máy phục vụ. Một ASG trải ba AZ với min bằng 2 vẫn có thể tụt xuống một máy khi một AZ hỏng — kiến trúc trông đúng trên sơ đồ nhưng năng lực thực tế lại không chịu nổi.

Đáp án

C — Pilot light.

Vì sao đúng

Đề mô tả chính xác định nghĩa của Pilot Light: | Dữ kiện | Khớp với | |---|---| | MỘT TẬP GIỚI HẠN dịch vụ lõi được nhân bản sang site DR | "pilot light" — ngọn lửa mồi | | Sẵn sàng tiếp quản khi có thảm hoạ | dữ liệu sao chép liên tục | | **Mọi dịch vụ khác đều TẮT | đây là điểm phân biệt |

⚠ "All other services will be switched off" là từ khoá quyết định:

Pilot Light:   dịch vụ lõi (thường là CSDL) chạy
               → tầng ứng dụng TẮT hoàn toàn
        ↓
Warm Standby:  MỌI tầng đều CHẠY, chỉ ở quy mô nhỏ

Nguồn gốc tên gọi:

"Pilot light" = ngọn lửa mồi trong bếp gas
    → luôn cháy nhỏ, sẵn sàng bùng lên
        ↓
    Phần tối thiểu luôn chạy để giữ dữ liệu đồng bộ
    → phần còn lại bật lên khi cần

Kiến trúc điển hình:

Bình thường:
    → Aurora global database sao chép liên tục (CHẠY)
    → ALB đã dựng sẵn (CHẠY, rẻ)
    → Auto Scaling group với desired = 0 (TẮT)
    → AMI và ảnh container đã nhân bản

Khi thảm hoạ:
    1. Tăng ASG desired capacity      (~5 phút)
    2. Promote CSDL vùng phụ          (~1 phút)
    3. Route 53 chuyển traffic        (~1-2 phút)
        ↓
    RTO thường 10-30 phút

Cấu hình ASG ở trạng thái "tắt":

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-dr --region us-west-2 \
  --min-size 0 --max-size 0 --desired-capacity 0

Và bật lên khi cần:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-dr --region us-west-2 \
  --min-size 4 --max-size 20 --desired-capacity 8

Ba đặc điểm của Pilot Light: | Đặc điểm | Chi tiết | |---|---| | RTO: chục phút | | | RPO: phút tới giây | tuỳ cơ chế sao chép | | Chi phí: thấp | không trả phí compute |

Vì sao các phương án khác sai

• **A. Warm standby — đây là phương án gần nhất và chỉ khác một điểm: warm standby giữ MỌI tầng đang CHẠY ở quy mô thu nhỏ. Đề nói rõ "all other services will be switched OFF", nên đó là Pilot Light.
• **D. Multi-site (active-active) — cả hai site cùng phục vụ lưu lượng thật, không có site nào "chờ tiếp quản". RTO gần bằng 0 nhưng chi phí cao nhất.
• **B. Backup and restore — không có gì được nhân bản sẵn: chỉ có bản sao lưu, phải dựng lại toàn bộ hạ tầng khi có sự cố. RTO tính bằng giờ tới ngày.

Ghi nhớ

⚠ Bốn chiến lược DR — bảng phải thuộc: | Chiến lược | RTO | RPO | Chi phí | Tầng ứng dụng ở DR | |---|---|---|---|---| | Backup & Restore | giờ - ngày | giờ | thấp nhất | không có gì | | Pilot Light | chục phút | phút - giây | thấp | TẮT | | Warm Standby | phút | giây | trung bình | CHẠY quy mô nhỏ | | Multi-Site Active-Active | gần 0 | gần 0 | cao nhất | CHẠY đầy đủ |

⚠ Cách phân biệt nhanh nhất — nhìn vào tầng ứng dụng:

Không có gì dựng sẵn        → Backup & Restore
Dữ liệu sao chép, app TẮT   → Pilot Light
App CHẠY nhỏ                → Warm Standby
App CHẠY và PHỤC VỤ         → Multi-Site

Hai định nghĩa phải thuộc: | Chỉ số | Nghĩa | |---|---| | RTO (Recovery Time Objective) | bao lâu để KHÔI PHỤC dịch vụ | | RPO (Recovery Point Objective) | được phép MẤT bao nhiêu dữ liệu |

Từ khoá nhận diện: | Cụm từ trong đề | Chiến lược | |---|---| | "core services replicated, others switched off" | Pilot Light | | "scaled-down but fully functional copy" | Warm Standby | | "both Regions serve traffic" | Multi-Site | | "restore from backups when needed" | Backup & Restore |

⚠ Ba thứ thường được giữ chạy trong Pilot Light: | Thứ | Vì sao | |---|---| | CSDL (Aurora global database, read replica) | giữ dữ liệu đồng bộ | | ALB đã dựng | rẻ, và dựng lại tốn thời gian | | AMI, ảnh container, chứng chỉ | tầng ứng dụng cần để khởi động |

⚠ Ba thứ hay bị quên chuẩn bị ở vùng DR: | Thứ | Hậu quả nếu quên | |---|---| | AMI và launch template | ASG không khởi động nổi máy nào | | Chứng chỉ ACM | ACM theo vùng, không tự nhân bản | | Hạn ngạch tài khoản | vùng chưa dùng thường quota rất thấp |

Chuyển đổi thành công ở tầng dữ liệu
    → nhưng ASG chạm quota, chỉ khởi động được 5/20 máy
        ↓
    RTO thực tế bị quyết định bởi tầng chậm nhất

Ba cơ chế sao chép dữ liệu cho DR: | Cơ chế | RPO | |---|---| | Aurora Global Database | ~1 giây | | DynamoDB Global Tables | dưới 1 giây, active-active | | S3 Cross-Region Replication | phút (RTC cam kết 15 phút) | | RDS cross-region read replica | giây - phút |

Ba cách kích hoạt chuyển đổi: | Cách | Chi tiết | |---|---| | Route 53 health check + failover record | tự động | | EventBridge + Lambda | logic tuỳ chỉnh | | Runbook thủ công | chậm nhất |

⚠ Route 53 TTL ảnh hưởng trực tiếp tới RTO:

Health check phát hiện trong 90 giây
    → TTL 300 giây → client vẫn dùng IP cũ thêm 5 phút
        ↓
    Đặt TTL 60 giây cho bản ghi failover

Ba lưu ý về chi phí Pilot Light: | Khoản | Chi tiết | |---|---| | ALB tính phí kể cả không có target | ~16 USD/tháng | | CSDL vùng phụ tính phí instance | | | Phí truyền dữ liệu giữa vùng | |

Ba việc phải làm định kỳ: | Việc | Tần suất | |---|---| | Diễn tập chuyển đổi thật | ít nhất 2 lần/năm | | Kiểm tra AMI vùng DR còn mới | mỗi lần phát hành | | Đo RTO thực tế | mỗi lần diễn tập |

⚠ Aurora cho phép diễn tập không mất dữ liệu:

aws rds failover-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --target-db-cluster-identifier <arn-cum-dr>

Managed planned failover
    → chuyển sang vùng DR, chạy một lúc, rồi chuyển về
        ↓
    Cách diễn tập DR an toàn nhất

Ba lưu ý về tự động hoá: | Lưu ý | Chi tiết | |---|---| | Viết runbook thành Systems Manager Automation | | | Hoặc Step Functions | | | Mỗi bước thủ công là một chỗ để sai | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy diễn tập đầy đủ | | | Đo thời gian từng bước | | | Kiểm tra hạn ngạch vùng DR | |

Và một lời khuyên: hãy diễn tập chuyển đổi ít nhất hai lần mỗi năm và ghi lại thời gian từng bước. RTO trên tài liệu là một con số ước tính; RTO đo được trong buổi diễn tập là con số thật — và khoảng cách giữa hai con số đó thường lớn hơn nhiều so với người ta nghĩ.

Đáp án

D — Dùng AWS Batch triển khai một multi-node parallel job.

Vì sao đúng

Đề nêu bốn yêu cầu, và AWS Batch multi-node parallel job là lựa chọn đúng: | Yêu cầu | Cách đáp ứng | |---|---| | **Tải HPC GẮN KẾT CHẶT dùng MPI | multi-node parallel job hỗ trợ MPI | | Chạy trên NHIỀU NODE | Batch điều phối cả nhóm node | | **Cần TRIỂN KHAI ĐƯỢC QUẢN LÝ | Batch tự cấp và thu hồi máy | | Tối thiểu công vận hành | không tự dựng cụm |

⚠ "Service-managed deployment" là từ khoá quyết định:

CloudFormation dựng cluster placement group
    → bạn vẫn phải TỰ quản lý vòng đời máy
    → tự khởi động, tự tắt, tự xử lý lỗi
        ↓
AWS Batch: dịch vụ điều phối job
    → tự cấp máy khi có job, tự thu hồi khi xong

Multi-node parallel job làm gì:

Batch cấp một NHÓM node cùng lúc
    → gán một node làm MAIN, còn lại làm CHILD
    → thiết lập biến môi trường để MPI biết topology
    → chạy job trên toàn nhóm
        ↓
    Đây chính là thứ tải MPI cần

Định nghĩa job đa node:

aws batch register-job-definition \
  --job-definition-name mo-phong-cfd \
  --type multinode \
  --node-properties '{
    "numNodes": 16,
    "mainNode": 0,
    "nodeRangeProperties": [{
      "targetNodes": "0:15",
      "container": {
        "image": "123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/cfd:latest",
        "vcpus": 96, "memory": 180000,
        "instanceType": "hpc7a.96xlarge"}}]}'

Gửi job:

aws batch submit-job --job-name chay-mo-phong-001 \
  --job-queue hang-doi-hpc --job-definition mo-phong-cfd

⚠ Batch tự lo cả placement group:

Multi-node parallel job
    → Batch tự đặt các node vào cluster placement group
    → đảm bảo độ trễ mạng thấp nhất
        ↓
    Không phải cấu hình bằng tay

Compute environment:

aws batch create-compute-environment \
  --compute-environment-name moi-truong-hpc \
  --type MANAGED --state ENABLED \
  --compute-resources '{
    "type":"EC2","minvCpus":0,"maxvCpus":2048,
    "instanceTypes":["hpc7a.96xlarge"],
    "subnets":["subnet-hpc"],
    "securityGroupIds":["sg-hpc"],
    "instanceRole":"ecsInstanceRole",
    "placementGroup":"cum-hpc"}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | minvCpus: 0 — không job thì không máy | không trả tiền lúc rảnh | | Hàng đợi có ưu tiên | | | Tự thử lại khi lỗi | |

Vì sao các phương án khác sai

• **A. Dùng CloudFormation triển khai một Cluster Placement Group trên EC2 — đây là phương án gần nhất vì cluster placement group đúng là thứ tải MPI cần, nhưng CloudFormation chỉ dựng hạ tầng: bạn vẫn tự quản lý vòng đời job, tự khởi động và tắt máy, tự xử lý lỗi. Đề đòi "service-managed deployment".
• **C. Dùng EC2 Auto Scaling triển khai instance qua nhiều subnet — sai hai lần: ASG co giãn từng máy độc lập, không điều phối một nhóm node chạy cùng nhau; và trải qua nhiều subnet (nhiều AZ) làm tăng độ trễ giữa node.
• **B. Dùng Elastic Beanstalk — nền tảng cho ứng dụng web và worker, không hỗ trợ mô hình job đa node của HPC.

Ghi nhớ

⚠ Ba cách chạy HPC trên AWS — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | AWS Batch (multi-node parallel) | dịch vụ quản lý job, tự cấp máy | | AWS ParallelCluster | dựng cụm HPC với Slurm | | EC2 + placement group tự quản | kiểm soát tối đa, công cao nhất |

⚠ AWS Batch và ParallelCluster — khi nào dùng cái nào: | | AWS Batch | AWS ParallelCluster | |---|---|---| | Mô hình | gửi job vào hàng đợi | cụm HPC truyền thống với scheduler | | Scheduler | Batch tự lo | Slurm | | Quen thuộc với | đội DevOps | đội HPC truyền thống | | Công vận hành | thấp nhất | trung bình |

Từ khoá nhận diện:

"tightly-coupled, MPI, service-managed" → AWS Batch multi-node parallel job "HPC cluster with Slurm" → ParallelCluster "low latency between nodes" → cluster placement group + EFA "loosely-coupled, independent tasks" → Batch array job

⚠ Hai loại job của AWS Batch: | Loại | Dùng cho | |---|---| | Array job | nhiều tác vụ ĐỘC LẬP (loosely-coupled) | | Multi-node parallel job | một tác vụ chạy trên NHIỀU NODE (tightly-coupled) |

Render 1.000 frame độc lập  → array job
Mô phỏng CFD chia lưới      → multi-node parallel job

Ba thành phần của AWS Batch: | Thành phần | Việc | |---|---| | Compute environment | máy chạy job | | Job queue | hàng đợi có ưu tiên | | Job definition | ảnh container, vCPU, RAM, node |

⚠ Ba thứ cần cho HPC gắn kết chặt: | Thứ | Việc | |---|---| | Cluster placement group | đặt máy gần nhau về vật lý | | Elastic Fabric Adapter (EFA) | OS-bypass, độ trễ thấp | | Cùng một subnet, cùng AZ | |

Bật EFA trong job definition:

{"container": {
  "image": "...", "vcpus": 96, "memory": 180000,
  "linuxParameters": {"devices": [{"hostPath": "/dev/infiniband/uverbs0"}]},
  "ulimits": [{"name": "memlock", "hardLimit": -1, "softLimit": -1}]}}

⚠ Security group cho EFA phải tự tham chiếu:

aws ec2 authorize-security-group-ingress --group-id sg-hpc \
  --protocol -1 --source-group sg-hpc

EFA cần lưu lượng tự do giữa các node
    → thiếu quy tắc này thì MPI không chạy

Ba placement group: | Kiểu | Mục tiêu | |---|---| | Cluster | hiệu năng mạng tối đa — một AZ | | Partition | cô lập lỗi theo nhóm | | Spread | cô lập từng máy |

Ba họ instance cho HPC: | Họ | Đặc điểm | |---|---| | hpc7a, hpc6a | thiết kế riêng cho HPC | | c6in, c7gn | mạng tới 200 Gbps | | p5, p4d | GPU |

⚠ Ba lưu ý về năng lực: | Lưu ý | Chi tiết | |---|---| | Multi-node job cần TẤT CẢ node cùng lúc | | | Thiếu một node là job không chạy | | | Đặt trước bằng Capacity Reservation | |

Cluster placement group đòi AWS tìm đủ chỗ
trong cùng một lô mạng
    → với vài chục máy lớn, "InsufficientInstanceCapacity"
      là thông báo bạn sẽ gặp

Ba lưu ý về hệ thống tệp: | Lưu ý | Chi tiết | |---|---| | FSx for Lustre cho dữ liệu chung | | | Liên kết S3 để lưu bền | | | Cùng AZ với node tính toán | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | minvCpus: 0 để không trả khi rảnh | | | Spot cho job chịu được gián đoạn | | | Đặt maxvCpus làm trần | |

⚠ Spot với multi-node parallel job — cân nhắc:

Một node bị thu hồi → cả job thất bại
    → với job MPI chạy nhiều giờ, rủi ro cao
        ↓
    Dùng On-Demand cho job dài,
    Spot cho job ngắn có checkpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | fi_info -p efa trên node | EFA đã nhận chưa | | Chạy OSU benchmark đo độ trễ | | | So thời gian chạy với hệ thống cũ | |

Và một lời khuyên: hãy đặt trước năng lực bằng On-Demand Capacity Reservation cho job HPC lớn. Multi-node parallel job cần toàn bộ node có mặt cùng lúc trong cùng một placement group — thiếu một máy là job không khởi động, và bạn sẽ mất cả cửa sổ thời gian đã lên lịch.

Đáp án

A — Bật DynamoDB Streams, cấu hình một AWS Lambda đọc stream và ghi dữ liệu item đã thay đổi vào một S3 bucket.

Vì sao đúng

Đề nêu hai yêu cầu, và DynamoDB Streams là cơ chế gốc cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Mỗi lần item bị SỬA phải giữ lại một bản ghi | Streams bắt MỌI thay đổi item | | HIỆU QUẢ NHẤT | không tiêu read capacity của bảng |

⚠ Vì sao Streams hiệu quả hơn mọi cách khác:

DynamoDB Streams là bản ghi thay đổi ĐỘC LẬP
    → đọc từ stream KHÔNG tiêu tốn read capacity của bảng
    → không ảnh hưởng hiệu năng ứng dụng
        ↓
    Và nó bắt được MỌI thay đổi, không bỏ sót

Bật Streams:

aws dynamodb update-table --table-name BangDuLieu \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

⚠ NEW_AND_OLD_IMAGES là lựa chọn đúng cho tuân thủ: | Giá trị | Nội dung | |---|---| | KEYS_ONLY | chỉ khoá | | NEW_IMAGE | item sau khi đổi | | OLD_IMAGE | item trước khi đổi | | NEW_AND_OLD_IMAGES | cả hai — biết đổi TỪ GÌ SANG GÌ |

Yêu cầu tuân thủ thường cần biết giá trị TRƯỚC và SAU
    → NEW_AND_OLD_IMAGES là lựa chọn an toàn

Lambda ghi vào S3:

import json, boto3, os
from datetime import datetime
s3 = boto3.client('s3')

def handler(event, context):
    dong = []
    for ban_ghi in event['Records']:
        dong.append(json.dumps({
            'loai': ban_ghi['eventName'],
            'thoi_gian': ban_ghi['dynamodb'].get('ApproximateCreationDateTime'),
            'khoa': ban_ghi['dynamodb']['Keys'],
            'truoc': ban_ghi['dynamodb'].get('OldImage'),
            'sau': ban_ghi['dynamodb'].get('NewImage')}, default=str))

    ngay = datetime.utcnow()
    s3.put_object(
        Bucket=os.environ['BUCKET'],
        Key=f"kiem-toan/nam={ngay:%Y}/thang={ngay:%m}/ngay={ngay:%d}/"
            f"{context.aws_request_id}.json",
        Body='\n'.join(dong).encode())

Nối Lambda vào stream:

aws lambda create-event-source-mapping \
  --function-name ghi-kiem-toan \
  --event-source-arn <arn-stream> \
  --starting-position LATEST --batch-size 100 \
  --maximum-batching-window-in-seconds 10

⚠ Gộp lô làm giảm số object trong S3:

batch-size 100 + batching window 10 giây
    → một lần gọi Lambda ghi tới 100 thay đổi
    → thành MỘT object S3
        ↓
    Thay vì mỗi thay đổi một object

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không ảnh hưởng hiệu năng bảng | | | S3 rẻ và bền cho lưu trữ dài hạn | | | Truy vấn bằng Athena khi cần kiểm toán | |

Vì sao các phương án khác sai

• **C. Bật DynamoDB Global Tables, bật Streams trên bảng đa vùng và lưu đầu ra thẳng vào S3 — đây là phương án gần nhất vì cũng dùng Streams, nhưng nó sai hai chỗ: Global Tables là để nhân bản đa vùng, không liên quan tới kiểm toán; và Streams không ghi thẳng vào S3 được — phải có Lambda hoặc EventBridge Pipes ở giữa.
• **D. Bật CloudTrail và dùng EC2 giám sát log — CloudTrail ghi management event mặc định, không ghi thao tác trên dữ liệu. Bật data event cho DynamoDB thì có, nhưng tốn kém hơn và một EC2 giám sát log là công vận hành cao.
• **B. Bật CloudWatch Logs và Lambda giám sát tệp log — DynamoDB không tự ghi thay đổi item vào CloudWatch Logs. Đây là mô tả một cơ chế không tồn tại.

Ghi nhớ

⚠ Ba đặc điểm của DynamoDB Streams — bảng phải thuộc: | Đặc điểm | Chi tiết | |---|---| | Ghi mọi thay đổi item theo thứ tự | trong một partition | | Giữ 24 GIỜ | | | KHÔNG tiêu read capacity của bảng | |

⚠ Vế thứ hai là giới hạn quan trọng:

Streams chỉ giữ 24 giờ
    → phải có consumer đọc và lưu đi nơi khác
        ↓
    Nếu Lambda chết quá 24 giờ → MẤT dữ liệu kiểm toán
    → đặt alarm trên IteratorAge

Ba loại eventName: | Loại | Nghĩa | |---|---| | INSERT | item mới | | MODIFY | item bị sửa ← đề cần | | REMOVE | item bị xoá (kể cả do TTL) |

Lọc ngay ở event source mapping:

aws lambda create-event-source-mapping --function-name ghi-kiem-toan \
  --event-source-arn <arn-stream> --starting-position LATEST \
  --filter-criteria '{"Filters":[{"Pattern":"{\"eventName\":[\"MODIFY\"]}"}]}'

Từ khoá nhận diện:

"record every change to a DynamoDB item" → DynamoDB Streams + Lambda "who called which AWS API" → CloudTrail "replicate to another Region" → Global Tables "react to S3 object creation" → S3 Event Notification

⚠ EventBridge Pipes — cách ít việc hơn:

aws pipes create-pipe --name ong-kiem-toan \
  --source <arn-stream> --target <arn-firehose> \
  --role-arn <arn-role> \
  --source-parameters '{"DynamoDBStreamParameters":{"StartingPosition":"LATEST"}}'

Nối Streams → Firehose → S3 mà KHÔNG viết Lambda nào
    → Firehose tự gộp lô và ghi vào S3
        ↓
    Công vận hành thấp hơn nữa

⚠ Ba lưu ý về Lambda đọc Streams: | Lưu ý | Chi tiết | |---|---| | Một Lambda mỗi shard | | | Lỗi một bản ghi CHẶN cả shard | | | Dùng BisectBatchOnFunctionError và DLQ | |

aws lambda update-event-source-mapping --uuid <uuid> \
  --maximum-retry-attempts 3 --bisect-batch-on-function-error \
  --destination-config '{"OnFailure":{"Destination":"<arn-sqs-dlq>"}}'

⚠ Vế thứ hai là bẫy vận hành lớn:

Một bản ghi gây lỗi Lambda
    → Lambda thử lại mãi
    → shard đó KHÔNG tiến lên
        ↓
    Dữ liệu kiểm toán ngừng được ghi
    → và stream chỉ giữ 24 giờ

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAge | stream bị tụt lại bao xa | | Lambda Errors | | | Số bản ghi trong DLQ | |

⚠ IteratorAge là metric quan trọng nhất:

IteratorAge tăng dần → consumer không theo kịp
    → chạm 24 giờ là MẤT DỮ LIỆU
        ↓
    Đặt alarm khi vượt vài giờ

Ba lưu ý về lưu trữ trong S3: | Lưu ý | Chi tiết | |---|---| | Phân vùng theo ngày | nam=/thang=/ngay= | | Gộp lô thành tệp lớn | tránh hàng triệu object nhỏ | | Nén và dùng Parquet nếu truy vấn nhiều | |

⚠ Ba biện pháp bảo vệ dữ liệu kiểm toán: | Biện pháp | Việc | |---|---| | S3 Object Lock chế độ compliance | không ai xoá được | | Bucket ở tài khoản riêng | | | Lifecycle chuyển sang Glacier | giữ lâu, rẻ |

aws s3api put-object-lock-configuration --bucket kho-kiem-toan \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}'

Ba cách truy vấn dữ liệu kiểm toán: | Cách | Việc | |---|---| | Amazon Athena | SQL trực tiếp trên S3 | | Amazon OpenSearch | tìm kiếm và dashboard | | Glue + QuickSight | báo cáo |

Ba lựa chọn thay thế: | Lựa chọn | Khi nào | |---|---| | DynamoDB Streams + Lambda → S3 | ← câu này | | EventBridge Pipes → Firehose → S3 | ít việc hơn | | Kinesis Data Streams for DynamoDB | cần giữ lâu hơn 24 giờ |

⚠ Kinesis Data Streams for DynamoDB đáng biết:

aws dynamodb enable-kinesis-streaming-destination \
  --table-name BangDuLieu --stream-arn <arn-kinesis>

Giữ tới 365 ngày thay vì 24 giờ
    → và nhiều consumer đọc độc lập được
        ↓
    Với yêu cầu tuân thủ nghiêm ngặt, đây là lựa chọn bền hơn

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Streams tính theo số lần đọc bản ghi | | | Lambda tính theo GB-giây | | | Gộp lô giảm cả hai | |

Và một lời khuyên: hãy đặt alarm trên IteratorAge ngay khi bật Streams. Dữ liệu trong stream chỉ sống 24 giờ, và nếu consumer bị kẹt vì một bản ghi lỗi thì bạn có đúng một ngày để phát hiện trước khi bằng chứng kiểm toán biến mất vĩnh viễn.

Đáp án

B — Lưu dữ liệu trong S3 Standard-IA trong 3 tháng, rồi chuyển sang S3 Glacier.

Vì sao đúng

Đề nêu ba giai đoạn, và phương án này khớp từng cái: | Giai đoạn | Yêu cầu | Lớp lưu trữ | |---|---|---| | 0-3 tháng | truy cập KHÔNG THƯỜNG XUYÊN | Standard-IA | | Sau 3 tháng - 7 năm | có được trong 10 PHÚT nếu cần | Glacier | | Tối thiểu chi phí | | |

⚠ Vế "infrequently accessed for the first three months" là điểm phân biệt B với C:

Đề KHÔNG nói dữ liệu được truy cập nhiều lúc đầu
    → nó nói NGAY TỪ ĐẦU đã ít truy cập
        ↓
    Vậy không cần trả giá S3 Standard trong 3 tháng đó
    → tải thẳng vào Standard-IA

⚠ Và tải thẳng vào Standard-IA là hợp lệ:

Giới hạn "30 ngày ở Standard trước khi chuyển sang IA"
chỉ áp cho LIFECYCLE TRANSITION
        ↓
    Tải lên (PUT) thẳng với --storage-class STANDARD_IA
    thì không có ràng buộc đó

aws s3 cp ho-so.pdf s3://kho-nhan-su/ --storage-class STANDARD_IA

Lifecycle chuyển sang Glacier sau 3 tháng:

{"Rules": [{
  "ID": "luu-tru-7-nam", "Status": "Enabled", "Filter": {},
  "Transitions": [{"Days": 90, "StorageClass": "GLACIER"}],
  "Expiration": {"Days": 2555}}]}

2.555 ngày ≈ 7 năm.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không trả giá Standard cho dữ liệu ít đọc | | | Glacier rẻ hơn Standard-IA khoảng 3 lần | | | Tự động, không cần script | |

Vì sao các phương án khác sai

• **C. Lưu trong S3 Standard 3 tháng rồi chuyển sang Glacier — đây là phương án gần nhất và hoàn toàn hoạt động, nhưng nó đắt hơn: trả giá S3 Standard cho dữ liệu mà đề nói là "accessed infrequently" ngay từ đầu.
• **D. Standard 3 tháng rồi chuyển sang Standard-IA — đắt hơn nữa: sau 3 tháng dữ liệu gần như không đụng tới, mà Standard-IA đắt hơn Glacier khoảng 3 lần.
• **A. Intelligent-Tiering 3 tháng rồi chuyển sang Standard-IA — Intelligent-Tiering có phí giám sát mỗi object, và sau 3 tháng thì Standard-IA vẫn đắt hơn Glacier nhiều.

Ghi nhớ về chất lượng câu hỏi

Đáp án B đúng theo khoá, nhưng cụm "available within 10 minutes" cần được nói rõ:

⚠ S3 Glacier Flexible Retrieval có ba tuỳ chọn lấy dữ liệu: | Tuỳ chọn | Thời gian | Giá | |---|---|---| | Expedited | 1-5 phút | đắt nhất | | Standard | 3-5 GIỜ | trung bình | | Bulk | 5-12 giờ | rẻ nhất |

"Available within 10 minutes"
    → CHỈ đạt được với EXPEDITED retrieval
        ↓
    Nếu dùng Standard retrieval thì mất 3-5 giờ
    → không đáp ứng yêu cầu

Và có một lựa chọn sạch hơn nhiều đã ra đời sau câu hỏi này:

⚠ S3 Glacier Instant Retrieval (ra mắt 11/2021): | Đặc điểm | Chi tiết | |---|---| | Truy cập TỨC THÌ (mili giây) | không cần khôi phục | | Rẻ hơn Standard-IA khoảng 2 lần | | | Lưu tối thiểu 90 ngày | |

Với yêu cầu "available within 10 minutes",
Glacier Instant Retrieval đáp ứng dư sức
    → và không cần lo về tuỳ chọn khôi phục
        ↓
    Nếu đề có phương án đó thì nó sẽ là đáp án tốt hơn

Ghi nhớ

⚠ Bảng lớp lưu trữ S3 — phải thuộc: | Lớp | Truy cập | Lưu tối thiểu | Giá tương đối | |---|---|---|---| | Standard | tức thì | — | 1,0× | | Intelligent-Tiering | tức thì | — | ~1,0× + phí giám sát | | Standard-IA | tức thì | 30 ngày | ~0,55× | | One Zone-IA | tức thì | 30 ngày | ~0,44× | | Glacier Instant Retrieval | tức thì | 90 ngày | ~0,2× | | Glacier Flexible Retrieval | phút - giờ | 90 ngày | ~0,16× | | Deep Archive | 12-48 giờ | 180 ngày | ~0,04× |

Từ khoá nhận diện:

"infrequent from the start" → tải thẳng vào Standard-IA "available in milliseconds, archive price" → Glacier Instant Retrieval "retrieval in minutes to hours acceptable" → Glacier Flexible Retrieval "7+ years, rarely accessed" → Deep Archive |

⚠ Ba giới hạn lifecycle phải nhớ: | Giới hạn | Chi tiết | |---|---| | Standard → Standard-IA / One Zone-IA | tối thiểu 30 ngày | | Object < 128 KB | không chuyển sang IA | | Tải lên TRỰC TIẾP vào IA | không có ràng buộc 30 ngày |

Ba tuỳ chọn khôi phục Deep Archive: | Tuỳ chọn | Thời gian | |---|---| | Standard | 12 giờ | | Bulk | 48 giờ |

Khôi phục object từ Glacier:

aws s3api restore-object --bucket kho-nhan-su \
  --key ho-so/nv001.pdf \
  --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Expedited"}}'

⚠ Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | Bản khôi phục là BẢN SAO TẠM | object gốc vẫn ở Glacier | | Days quyết định bản sao sống bao lâu | | | Tính phí cho cả bản sao tạm | |

Ba lưu ý về phí lưu tối thiểu: | Lưu ý | Chi tiết | |---|---| | Xoá sớm vẫn tính đủ thời gian tối thiểu | | | Standard-IA: 30 ngày | | | Glacier: 90 ngày, Deep Archive: 180 ngày | |

⚠ Ba lưu ý về kích thước tối thiểu tính phí: | Lớp | Ngưỡng | |---|---| | Standard-IA, One Zone-IA, Glacier IR | 128 KB | | Glacier Flexible, Deep Archive | 40 KB | | Standard, Intelligent-Tiering | không có |

Hồ sơ nhân sự thường là PDF vài trăm KB
    → vượt ngưỡng, không bị phạt
        ↓
    Nhưng với tệp rất nhỏ thì phải tính lại

Ba quy tắc lifecycle nên có: | Quy tắc | Việc | |---|---| | Transitions theo tuổi | giảm chi phí | | Expiration khi hết hạn lưu trữ | | | AbortIncompleteMultipartUpload | dọn phần tải lên dở |

⚠ Ba lưu ý cho dữ liệu tuân thủ: | Lưu ý | Chi tiết | |---|---| | Bật S3 Object Lock nếu cần bất biến | | | Bật versioning | | | CloudTrail data event ghi mọi truy cập | |

Object Lock giữ 7 năm:

aws s3api put-object-lock-configuration --bucket kho-nhan-su \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}'

⚠ Object Lock hoạt động cùng lifecycle:

Lifecycle chuyển sang Glacier: ĐƯỢC
Lifecycle xoá object đang bị khoá: KHÔNG
        ↓
    Object vẫn được bảo vệ, chỉ chuyển sang lớp rẻ hơn

Ba công cụ phân tích: | Công cụ | Việc | |---|---| | S3 Storage Lens | phân bố tuổi và kích thước | | S3 Storage Class Analysis | gợi ý thời điểm chuyển | | Cost Explorer | chi phí theo lớp |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra object đã ở đúng lớp | head-object | | Thử khôi phục một object từ Glacier | đo thời gian | | Theo dõi chi phí theo lớp hằng tháng | |

Và một lời khuyên: hãy kiểm tra tuỳ chọn khôi phục mà quy trình của bạn thực sự dùng, đừng chỉ nhìn tên lớp lưu trữ. Glacier Flexible Retrieval đáp ứng "trong 10 phút" chỉ khi dùng Expedited — và nếu script khôi phục của bạn để mặc định là Standard, thời gian thật sẽ là 3-5 giờ.

Đáp án

C — Hibernate instance ngoài giờ làm việc, và khởi động lại khi cần.

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ hibernate thoả cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Không dùng ngoài giờ làm việc để tiết kiệm | hibernate ngừng tính phí compute | | NỘI DUNG BỘ NHỚ phải được GIỮ LẠI | hibernate ghi RAM xuống EBS |

⚠ Vế thứ hai là điểm phân biệt duy nhất giữa C và D:

Stop:      RAM bị XOÁ SẠCH
           → khởi động lại là một lần boot mới
        ↓
Hibernate: nội dung RAM được GHI XUỐNG ổ EBS gốc
           → khởi động lại khôi phục đúng trạng thái cũ
           → tiến trình đang chạy tiếp tục từ chỗ dừng

Hibernate hoạt động thế nào:

Gọi stop-instances --hibernate
    → hệ điều hành ghi toàn bộ RAM vào ổ EBS gốc
    → instance dừng
        ↓
    Start lại: đọc RAM từ EBS trở lại bộ nhớ
    → ứng dụng tiếp tục như chưa từng dừng

Thực hiện:

aws ec2 stop-instances --instance-ids i-abc123 --hibernate

aws ec2 start-instances --instance-ids i-abc123

⚠ Ba điều kiện bắt buộc để hibernate được: | Điều kiện | Chi tiết | |---|---| | Bật hibernation LÚC KHỞI CHẠY | không bật sau được | | Ổ gốc là EBS, ĐÃ MÃ HOÁ | | | Dung lượng ổ gốc ≥ RAM + không gian dùng | |

Bật khi khởi chạy:

aws ec2 run-instances --image-id ami-abc --instance-type m6i.large \
  --hibernation-options Configured=true \
  --block-device-mappings '[{"DeviceName":"/dev/xvda",
    "Ebs":{"VolumeSize":64,"Encrypted":true,"VolumeType":"gp3"}}]'

⚠ Và ba giới hạn nữa cần biết: | Giới hạn | Chi tiết | |---|---| | RAM tối đa 150 GB | | | Không hibernate quá 60 ngày liên tục | | | Không dùng được với instance store | |

Ba khoản phí khi hibernate: | Khoản | Có tính phí | |---|---| | Compute (giờ instance) | ❌ không tính | | EBS volume | ✅ vẫn tính | | Elastic IP chưa gắn | ✅ tính |

Vì sao các phương án khác sai

• **D. Stop instance ngoài giờ và start lại — đây là phương án gần nhất và là cách tiết kiệm chuẩn cho hầu hết trường hợp, nhưng nó xoá sạch nội dung RAM. Đề nêu rõ yêu cầu giữ lại bộ nhớ.
• **A. Terminate rồi khôi phục lại khi cần — terminate xoá luôn cả instance; muốn có lại phải khởi chạy máy mới từ AMI. Mất cả RAM lẫn trạng thái ổ đĩa (nếu DeleteOnTermination bật).
• **B. Dùng Auto Scaling giảm quy mô ngoài giờ — ASG chấm dứt instance khi scale in, không giữ gì cả. Và ASG dành cho nhóm máy giống nhau, không phải một máy cụ thể.

Ghi nhớ

⚠ Bốn trạng thái vòng đời EC2 — bảng phải thuộc: | Trạng thái | RAM | Ổ EBS gốc | Phí compute | |---|---|---|---| | Running | giữ | giữ | ✅ | | Stopped | XOÁ | giữ | ❌ | | Stopped (hibernated) | GHI VÀO EBS | giữ | ❌ | | Terminated | xoá | xoá (mặc định) | ❌ |

Từ khoá nhận diện:

"preserve memory contents" + "save costs" → hibernate "save costs" (không nói gì về RAM) → stop "scale down a fleet" → Auto Scaling "instance no longer needed at all" → terminate

⚠ Ba thứ KHÔNG đổi khi stop rồi start: | Thứ | Chi tiết | |---|---| | Instance ID | | | Dữ liệu trên EBS | | | Elastic IP (nếu đã gắn) | |

⚠ Ba thứ ĐỔI khi stop rồi start: | Thứ | Chi tiết | |---|---| | IP riêng công khai (public IPv4 tự động) | mất, cấp lại IP mới | | Dữ liệu instance store | MẤT | | Máy chủ vật lý bên dưới | có thể khác |

Muốn giữ IP công khai qua các lần stop
    → dùng Elastic IP

Ba cách tự động hoá lịch bật tắt: | Cách | Chi tiết | |---|---| | EventBridge Scheduler + Lambda | linh hoạt nhất | | Systems Manager Automation | có sẵn runbook | | AWS Instance Scheduler solution | giải pháp dựng sẵn của AWS |

EventBridge Scheduler:

aws scheduler create-schedule --name tat-ngoai-gio \
  --schedule-expression "cron(0 18 ? * MON-FRI *)" \
  --schedule-expression-timezone "Asia/Ho_Chi_Minh" \
  --flex-time-window Mode=OFF \
  --target '{"Arn":"arn:aws:scheduler:::aws-sdk:ec2:stopInstances",
    "RoleArn":"<arn-role>",
    "Input":"{\"InstanceIds\":[\"i-abc123\"],\"Hibernate\":true}"}'

⚠ Luôn khai --schedule-expression-timezone:

Không khai → hiểu là UTC
    → "0 18" thành 1 giờ sáng giờ Việt Nam

Ba lưu ý khi dùng hibernate: | Lưu ý | Chi tiết | |---|---| | Thời gian hibernate và resume lâu hơn stop/start | phải ghi và đọc RAM | | Ổ gốc phải đủ lớn | RAM + dữ liệu | | Kiểm tra hệ điều hành có hỗ trợ | |

Ba hệ điều hành hỗ trợ hibernate: | Hệ điều hành | Hỗ trợ | |---|---| | Amazon Linux 2, Amazon Linux 2023 | ✅ | | Ubuntu, RHEL (phiên bản mới) | ✅ | | Windows Server | ✅ |

Ba trường hợp hibernate hữu ích: | Trường hợp | Chi tiết | |---|---| | Ứng dụng khởi động rất lâu | nạp dữ liệu vào RAM | | Máy trạm phát triển | giữ nguyên môi trường | | Cache lớn trong bộ nhớ | |

Ba cách tiết kiệm khác cho EC2: | Cách | Chi tiết | |---|---| | Savings Plans cho tải chạy liên tục | | | Spot cho tải chịu gián đoạn | | | Right-size bằng Compute Optimizer | |

Ba lưu ý về chi phí EBS khi máy dừng: | Lưu ý | Chi tiết | |---|---| | Volume vẫn tính phí đầy đủ | | | Snapshot rồi xoá volume nếu dừng lâu | | | Hibernate cần volume LỚN HƠN | chứa RAM |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra HibernationOptions đã bật | | | Hibernate và start, xác nhận tiến trình còn chạy | | | Đo thời gian resume | |

aws ec2 describe-instances --instance-ids i-abc123 \
  --query "Reservations[0].Instances[0].HibernationOptions"

Và một lời khuyên: hãy quyết định bật hibernation ngay lúc khởi chạy instance. Đây là một trong số ít thuộc tính không thể bật sau — nếu máy đã chạy mà bạn mới nhận ra cần hibernate, phải chụp AMI và khởi chạy lại một máy mới hoàn toàn.