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

Đáp án

D — Tạo một service control policy ở organizational unit gốc để từ chối truy cập các dịch vụ hoặc hành động đó.

Vì sao đúng

Đề nêu ba yêu cầu, và SCP là công cụ duy nhất thoả hết: | Yêu cầu | Cách đáp ứng | |---|---| | Giới hạn truy cập ở MỌI tài khoản trong tổ chức | SCP áp cho cả cây tổ chức | | Có khả năng mở rộng | tài khoản mới tự chịu chính sách | | MỘT ĐIỂM duy nhất để duy trì quyền | gắn ở OU gốc, sửa một chỗ |

Vì sao SCP là "single point":

Gắn SCP ở ROOT của tổ chức
    → áp cho MỌI tài khoản, MỌI OU bên dưới
    → tài khoản mới tạo tự động chịu chính sách
        ↓
    Sửa một chỗ → có hiệu lực ở mọi nơi

SCP chặn dịch vụ:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChanDichVuKhongDuyet",
   "Effect": "Deny",
   "Action": ["iot:*", "sagemaker:*", "braket:*"],
   "Resource": "*"}]}

Gắn vào root:

aws organizations create-policy --name chan-dich-vu \
  --type SERVICE_CONTROL_POLICY --content file://scp.json

aws organizations attach-policy --policy-id p-abc123 --target-id r-abc1

⚠ Quy tắc vàng về SCP:

SCP KHÔNG cấp quyền, chỉ giới hạn quyền TỐI ĐA. Quyền thật = GIAO của SCP và IAM policy.

Ba đặc điểm áp dụng: | Đặc điểm | Chi tiết | |---|---| | Áp cho MỌI principal, kể cả root của tài khoản thành viên | | | KHÔNG áp cho tài khoản QUẢN LÝ | kể cả gắn ở root | | KHÔNG áp cho service-linked role | |

Vế thứ hai là chỗ hay gây nhầm khi kiểm thử:

Thử SCP từ tài khoản quản lý → không thấy bị chặn
    → tưởng chính sách hỏng
        ↓
    Phải thử từ một tài khoản THÀNH VIÊN

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không ai lách được, kể cả root | | | Tài khoản mới tự chịu chính sách | | | Một nơi quản lý cho cả tổ chức | |

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

• **C. Tạo cross-account role trong từng tài khoản để từ chối truy cập — đây là phương án gần nhất vì cũng kiểm soát quyền, nhưng nó không phải một điểm duy nhất: phải tạo và duy trì role ở từng tài khoản, và tài khoản mới phải nhớ làm lại. Đề đòi "single point where permissions can be maintained".
• **A. Tạo security group cho phép tài khoản và gắn vào user group — nhầm hoàn toàn hai khái niệm: security group là tường lửa ảo cho tài nguyên mạng, không liên quan tới quyền IAM hay tài khoản.
• **B. Tạo ACL để cấp quyền cho các dịch vụ — ACL trong AWS là cơ chế kiểm soát truy cập ở tầng mạng (NACL) hoặc trên object S3 (đã lỗi thời). Không có ACL nào giới hạn được dịch vụ trên nhiều tài khoản.

Ghi nhớ

⚠ Bốn cơ chế quản trị của AWS Organizations — bảng phải thuộc: | Cơ chế | Việc | |---|---| | Service Control Policy (SCP) | giới hạn quyền TỐI ĐA — chỉ Deny | | Tag policy | chuẩn hoá tag | | Backup policy | kế hoạch sao lưu tập trung | | AI services opt-out | từ chối dùng dữ liệu |

Từ khoá nhận diện:

"restrict services across ALL accounts" + "single point" → SCP "limit what a role can do" → permissions boundary "grant permissions" → IAM policy (SCP không cấp quyền)

⚠ Ba cơ chế giới hạn quyền — bảng phân biệt: | Cơ chế | Phạm vi | Cấp quyền? | |---|---|---| | SCP | cả tài khoản / OU | ❌ | | Permissions boundary | một user hoặc role | ❌ | | Identity policy | user, group, role | ✅ |

Bảng hai cách viết SCP: | Cách | Hành vi | Rủi ro | |---|---|---| | Deny list (mặc định) | cấm vài thứ, còn lại cho | thấp ← nên dùng | | Allow list | chỉ cho vài thứ | rất cao |

⚠ Allow list rất dễ gây sự cố:

SCP mặc định của tổ chức là FullAWSAccess (Allow *)
    → gắn thêm SCP chỉ Allow vài hành động
    → GIAO của hai cái → chỉ còn vài hành động đó
        ↓
    MỌI dịch vụ khác bị chặn hết

Ba cấp gắn SCP: | Cấp | Ảnh hưởng | |---|---| | Root của tổ chức | mọi tài khoản ← câu này | | OU | mọi tài khoản trong OU | | Tài khoản | một tài khoản |

SCP là GIAO qua mọi cấp — bị Deny ở bất kỳ cấp nào là bị chặn.

Ba điều kiện tiên quyết: | Điều kiện | Chi tiết | |---|---| | Bật "all features" trong Organizations | | | Bật loại chính sách SCP | | | Thao tác từ tài khoản quản lý | |

aws organizations enable-policy-type \
  --root-id r-abc1 --policy-type SERVICE_CONTROL_POLICY

⚠ Ba giới hạn kỹ thuật: | Giới hạn | Con số | |---|---| | Kích thước một SCP | 5.120 ký tự | | Số SCP gắn cho một mục tiêu | 5 | | Độ sâu OU | 5 cấp |

Ba SCP nên có ở hầu hết tổ chức: | SCP | Việc | |---|---| | Chặn vùng không dùng tới | giảm bề mặt tấn công | | Chặn tắt CloudTrail và Config | bảo vệ audit | | Chặn xoá bản sao lưu | |

Chặn theo vùng:

{"Effect": "Deny",
 "NotAction": ["iam:*","cloudfront:*","route53:*","support:*","organizations:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals": {
   "aws:RequestedRegion": ["ap-southeast-1", "us-east-1"]}}}

⚠ Phải loại trừ dịch vụ TOÀN CẦU:

IAM, CloudFront, Route 53 "chạy ở" us-east-1
    → không loại trừ là chặn luôn việc quản lý IAM
        ↓
    Có thể tự khoá mình ra ngoài

Ba lời khuyên khi triển khai: | Lời khuyên | Chi tiết | |---|---| | Thử ở OU thử nghiệm trước | | | Có OU "sandbox" nới lỏng hơn | | | Ghi tài liệu vì sao chặn | |

Ba công cụ hỗ trợ: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử trước | | CloudTrail | xem lệnh bị từ chối | | AWS Control Tower | guardrail dựng sẵn |

⚠ Control Tower đáng biết:

Control Tower dựng sẵn một bộ guardrail
    → gồm cả SCP và AWS Config rule
    → theo thực hành tốt của AWS
        ↓
    Nếu chưa có tổ chức, dựng bằng Control Tower
    thường tốt hơn tự viết SCP từ đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử hành động bị chặn từ tài khoản THÀNH VIÊN | | | Kiểm tra tài khoản mới cũng bị chặn | | | Xem CloudTrail ghi lại việc từ chối | |

Và một lời khuyên: hãy luôn thử SCP mới trên một OU thử nghiệm trước khi gắn vào root. Một SCP viết sai ở cấp root có thể khoá tất cả mọi người ra khỏi chính công cụ cần dùng để sửa nó — và lúc đó chỉ còn cách vào tài khoản quản lý để gỡ chính sách.

Đáp án

A và B.

• A — Cấu hình Auto Scaling group tự thêm bớt instance ở nhiều Availability Zone
• B — Đặt một Network Load Balancer trước các EC2 instance

Vì sao đúng

Đề nêu ba dữ kiện, và hai hành động này giải quyết đủ: | Dữ kiện | Vấn đề | Giải bằng | |---|---|---| | EC2 trong MỘT Availability Zone | điểm hỏng đơn lẻ | A: ASG đa AZ | | **Người chơi kết nối qua TẦNG 4 | cần LB tầng 4 | B: NLB | | Cần tính sẵn sàng cao VÀ tiết kiệm hơn | | A: bớt máy khi vắng |

⚠ "Layer 4" là gợi ý trực tiếp nhất:

Tầng 4 = TCP/UDP
    → ALB hoạt động ở TẦNG 7 (HTTP)
    → NLB hoạt động ở TẦNG 4
        ↓
    Đây là lý do loại phương án E

Và ASG đa AZ giải quyết cả hai mục tiêu cùng lúc:

Tính sẵn sàng: mất một AZ vẫn còn máy ở AZ kia
Tiết kiệm:      ít người chơi → tự bớt máy
        ↓
    Một hành động, hai lợi ích

Cấu hình:

aws elbv2 create-load-balancer --name nlb-game --type network \
  --scheme internet-facing --subnets subnet-az-a subnet-az-b

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-game \
  --vpc-zone-identifier "subnet-az-a,subnet-az-b" \
  --min-size 2 --max-size 20 --desired-capacity 4 \
  --health-check-type ELB --health-check-grace-period 300

Ba lợi ích của NLB cho game: | Lợi ích | Chi tiết | |---|---| | Độ trễ rất thấp | xử lý ở tầng 4 | | Giữ IP nguồn của client | với target kiểu instance | | Gán Elastic IP tĩnh mỗi AZ | dễ cho client cấu hình |

Co giãn theo số kết nối:

aws autoscaling put-scaling-policy --auto-scaling-group-name asg-game \
  --policy-name theo-ket-noi --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{"TargetValue":500.0,
    "CustomizedMetricSpecification":{
      "MetricName":"ActiveFlowCount","Namespace":"AWS/NetworkELB",
      "Dimensions":[{"Name":"LoadBalancer","Value":"net/nlb-game/abc"}],
      "Statistic":"Average"}}'

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

• **C. Cấu hình ASG thêm bớt instance trong CÙNG Availability Zone — đây là phương án gần nhất và giải quyết được vế tiết kiệm, nhưng nó giữ nguyên điểm hỏng đơn lẻ: mất AZ đó là mất toàn bộ. Chỉ khác phương án A đúng một từ, nhưng đó là từ quyết định.
• **E. Đặt Application Load Balancer trước EC2 — ALB hoạt động ở tầng 7, chỉ hiểu HTTP/HTTPS. Đề nói rõ người chơi kết nối qua tầng 4.
• **D. Tăng số instance và dùng loại instance nhỏ hơn — có thể tiết kiệm chút ít, nhưng không tự động và không cải thiện tính sẵn sàng nếu vẫn ở một AZ.

Ghi nhớ

⚠ Ba loại Elastic Load Balancer — bảng phải thuộc: | 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 |

Từ khoá nhận diện:

"Layer 4", "TCP", "UDP", "gaming" → NLB "Layer 7", "HTTP path routing" → ALB "single AZ" + "highly available" → trải nhiều AZ "more cost-effective" + tải biến động → Auto Scaling

⚠ Phân biệt subnet và AZ — bẫy hay gặp: | 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 |

"Nhiều subnet" KHÔNG đảm bảo "nhiều AZ"
    → kiểm tra bằng describe-subnets

aws ec2 describe-subnets \
  --query "Subnets[].[SubnetId,AvailabilityZone,CidrBlock]" --output table

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 | | | Load balancer bật ở cùng các AZ | | | Ứng dụng không giữ trạng thái cục bộ | |

⚠ Vế thứ ba đặc biệt quan trọng với game:

Game giữ trạng thái trận đấu trong bộ nhớ máy
    → người chơi bị chuyển máy → mất trận
        ↓
    Bật sticky session của NLB (theo source IP)
    → hoặc lưu trạng thái ở ElastiCache

aws elbv2 modify-target-group-attributes --target-group-arn <arn> \
  --attributes Key=stickiness.enabled,Value=true \
               Key=stickiness.type,Value=source_ip

⚠ Ba khác biệt quan trọng giữa ALB và NLB: | | ALB | NLB | |---|---|---| | IP nguồn ở target | IP của ALB | IP THẬT của client | | Cross-zone mặc định | BẬT, miễn phí | TẮT, có phí | | Elastic IP tĩnh | ❌ | ✅ |

Cross-zone tắt mặc định gây phân bố lệch:

Mỗi node NLB chỉ gửi tới target trong CÙNG AZ
    → AZ có ít target hơn → mỗi máy nặng hơn
        ↓
    Giữ số target cân bằng, hoặc bật cross-zone

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 |

⚠ Phải đổi sang ELB:

Kiểu EC2: ứng dụng treo mà máy vẫn "running"
    → ASG không thay máy
    → LB vẫn gửi kết nối tới máy hỏng

Ba metric của NLB dùng để co giãn: | Metric | Ý nghĩa | |---|---| | ActiveFlowCount | số kết nối đang mở | | NewFlowCount | kết nối mới mỗi giây | | ProcessedBytes | lưu lượng |

Ba lưu ý về scale in với game: | Lưu ý | Chi tiết | |---|---| | Instance protection cho máy đang có trận | | | Lifecycle hook để chờ trận kết thúc | | | Deregistration delay đủ dài | |

aws autoscaling set-instance-protection --instance-ids i-abc \
  --auto-scaling-group-name asg-game --protected-from-scale-in

Ba cách tiết kiệm thêm: | Cách | Chi tiết | |---|---| | Mixed instance policy với Spot | cho phần tăng thêm | | Savings Plans cho tải nền | | | Right-size bằng Compute Optimizer | |

Ba lựa chọn chuyên biệt cho game: | Lựa chọn | Việc | |---|---| | Amazon GameLift | dịch vụ chuyên cho máy chủ game | | Global Accelerator | nhiều vùng, IP tĩnh, UDP | | NLB + ASG | ← câu này |

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, xem còn phục vụ không | | | Thử tải để xem có co giãn không | |

Và một lời khuyên: hãy kiểm tra describe-subnets để xác nhận thật sự đang ở nhiều AZ. Rất nhiều VPC dựng nhanh có vài subnet đều nằm trong cùng một AZ — sơ đồ kiến trúc trông hoàn toàn đúng, và điều đó chỉ lộ ra vào ngày AZ đó gặp sự cố.

Đáp án

A và D.

• A — Chuyển hai địa chỉ IP công khai hiện có sang AWS Global Accelerator (Bring Your Own IP)
• D — Tạo một AWS Global Accelerator và gắn endpoint ở mỗi vùng AWS

Vì sao đúng

Đề nêu bốn dữ kiện, và Global Accelerator với BYOIP là lời giải duy nhất: | Dữ kiện | Cách đáp ứng | |---|---| | Nhiều triển khai ở các vùng khác nhau, sau NLB | D: gắn NLB làm endpoint mỗi vùng | | Đang quảng bá hai IP công khai từ hai dải /24 | | | KHÔNG muốn đổi hai IP đó | A: BYOIP — mang IP của mình vào AWS | | Người dùng tới endpoint gần nhất | anycast của Global Accelerator |

⚠ BYOIP (Bring Your Own IP) là tính năng ít người biết:

Global Accelerator mặc định cấp cho bạn HAI IP tĩnh của AWS
    → nhưng bạn cũng MANG IP CỦA MÌNH vào được
        ↓
    Điều kiện: dải phải là /24 trở lên (tối thiểu 256 địa chỉ)
    → và bạn phải chứng minh quyền sở hữu

Đề nói rõ "two public IP addresses from separate /24 address ranges" — đúng điều kiện của BYOIP.

Quy trình BYOIP:

# 1. Tạo ROA (Route Origin Authorization) tại RIR của bạn
#    cho phép AWS quảng bá dải đó

# 2. Ký chứng minh quyền sở hữu
aws ec2 provision-byoip-cidr --cidr 203.0.113.0/24 \
  --cidr-authorization-context \
    Message="<thông-điệp>",Signature="<chữ-ký>"

# 3. Quảng bá dải
aws ec2 advertise-byoip-cidr --cidr 203.0.113.0/24

# 4. Tạo accelerator dùng IP của mình
aws globalaccelerator create-accelerator --name tang-toc \
  --ip-addresses 203.0.113.10 198.51.100.10 --enabled

Gắn endpoint ở mỗi vùng:

aws globalaccelerator create-listener --accelerator-arn <arn> \
  --protocol TCP --port-ranges FromPort=443,ToPort=443

aws globalaccelerator create-endpoint-group \
  --listener-arn <arn-listener> --endpoint-group-region ap-southeast-1 \
  --endpoint-configurations EndpointId=<arn-nlb-sg>,Weight=100

aws globalaccelerator create-endpoint-group \
  --listener-arn <arn-listener> --endpoint-group-region eu-west-1 \
  --endpoint-configurations EndpointId=<arn-nlb-ie>,Weight=100

Cách anycast đưa người dùng tới endpoint gần nhất:

Cùng một IP được quảng bá từ MỌI edge của AWS
    → mạng tự chọn edge gần nhất cho từng người dùng
    → từ edge, đi trên MẠNG XƯƠNG SỐNG AWS
      tới endpoint khoẻ mạnh và gần nhất
        ↓
    Không phụ thuộc DNS — định tuyến tất định

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giữ nguyên IP đã công bố | khách hàng không phải sửa gì | | Chuyển vùng nhanh, không qua DNS | | | Hiệu năng ổn định hơn Internet công cộng | |

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

• **E. Gán IP anycast tĩnh MỚI và sửa mọi con trỏ hiện có — đây là phương án gần nhất vì cũng dùng Global Accelerator, nhưng nó vi phạm trực tiếp yêu cầu: công ty nói rõ "would prefer not to change these" về hai IP đang dùng.
• **B. Tạo Route 53 geolocation routing policy — định tuyến theo quốc gia, không theo hiệu năng; và nó là DNS nên không giữ được IP cố định như đề yêu cầu.
• **C. Tạo PTR record ánh xạ IP công khai sang Alias — PTR là bản ghi phân giải ngược (IP → tên), dùng cho việc xác minh email và chẩn đoán. Nó không định tuyến lưu lượng.

Ghi nhớ

⚠ Ba dịch vụ định tuyến toàn cầu — bảng phải thuộc: | Dịch vụ | Cơ chế | IP | |---|---|---| | Global Accelerator | anycast IP | 2 IP TĨNH (hoặc BYOIP) | | Route 53 | DNS | IP của endpoint | | CloudFront | cache ở edge | IP thay đổi |

Từ khoá nhận diện:

"keep existing public IPs" + đa vùng → Global Accelerator với BYOIP "static IP addresses" → Global Accelerator hoặc NLB Elastic IP "cache static content" → CloudFront "route by country" → Route 53 geolocation

⚠ Ba điều kiện của BYOIP: | Điều kiện | Chi tiết | |---|---| | Dải phải /24 trở lên (IPv4) | không mang một IP lẻ vào được | | Phải có ROA tại RIR | chứng minh quyền sở hữu | | Ký bằng khoá riêng | |

⚠ BYOIP dùng được cho ba dịch vụ: | Dịch vụ | Hỗ trợ BYOIP | |---|---| | Elastic IP cho EC2 | ✅ | | Global Accelerator | ✅ | | Network Load Balancer | qua Elastic IP |

Ba đặc điểm của Global Accelerator: | Đặc điểm | Chi tiết | |---|---| | Hai IP tĩnh từ hai network zone | | | Hỗ trợ ALB, NLB, EC2, Elastic IP | KHÔNG hỗ trợ S3 | | Health check chủ động | |

Ba tham số điều khiển lưu lượng: | Tham số | Việc | |---|---| | Traffic dial (0-100%) | rút lưu lượng khỏi một vùng | | Endpoint weight | tỷ lệ trong nhóm | | Client affinity | giữ client ở cùng endpoint |

Traffic dial cho triển khai an toàn:

aws globalaccelerator update-endpoint-group \
  --endpoint-group-arn <arn> --traffic-dial-percentage 10

⚠ Global Accelerator và CloudFront — bảng phân biệt: | | Global Accelerator | CloudFront | |---|---|---| | Có cache | ❌ | ✅ | | Giao thức | TCP, UDP | HTTP/HTTPS | | IP | tĩnh anycast | thay đổi | | Failover | rất nhanh | qua origin group |

Hai loại accelerator: | Loại | Dùng cho | |---|---| | Standard | định tuyến tới endpoint tối ưu | | Custom routing | ánh xạ cổng tới instance cụ thể |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cố định theo giờ | ~0,025 USD/giờ | | Phí truyền dữ liệu cao cấp theo GB | | | BYOIP không tính phí thêm | |

Ba lưu ý khi chuyển sang BYOIP: | Lưu ý | Chi tiết | |---|---| | Quá trình xác minh mất vài ngày | | | Phải ngừng quảng bá ở nhà cung cấp cũ | | | Lên kế hoạch chuyển đổi cẩn thận | |

⚠ Vế thứ hai là chỗ dễ gây gián đoạn:

Hai nơi cùng quảng bá một dải IP
    → định tuyến BGP không xác định
    → lưu lượng đi lung tung
        ↓
    Phối hợp thời điểm chuyển với nhà cung cấp cũ

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyEndpointCount | endpoint nào còn sống | | NewFlowCount | lượng kết nối mới | | ProcessedBytesIn/Out | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra IP đã được AWS quảng bá | describe-byoip-cidrs | | Đo độ trễ từ nhiều khu vực | | | Tắt một vùng, đo thời gian chuyển | |

aws ec2 describe-byoip-cidrs --max-results 10 \
  --query "ByoipCidrs[].[Cidr,State,StatusMessage]" --output table

Và một lời khuyên: hãy bắt đầu quy trình BYOIP sớm hơn nhiều so với ngày cần dùng. Việc tạo ROA tại RIR và AWS xác minh quyền sở hữu mất vài ngày tới vài tuần, và đó là phần duy nhất trong kế hoạch mà bạn không kiểm soát được tốc độ.

Đáp án

D — Sửa cấu hình AWS WAF để thêm một IP match condition chặn địa chỉ IP độc hại.

Vì sao đúng

Đề mô tả một kiến trúc đã có sẵn WAF, và việc cần làm chỉ là thêm một luật: | Dữ kiện | Cách đáp ứng | |---|---| | CloudFront đứng trước ALB, đã có WAF | WAF là nơi lọc lưu lượng đi vào | | Cần chặn MỘT IP độc hại cụ thể | IP set rule của WAF |

Vì sao WAF là nơi đúng để chặn:

Lưu lượng đi vào theo thứ tự:
    Người dùng → CloudFront (+ WAF) → ALB → EC2
        ↓
    Chặn ở WAF = chặn ở điểm ĐẦU TIÊN
    → request không tiêu tốn tài nguyên nào phía sau

Tạo IP set và luật chặn:

aws wafv2 create-ip-set --name danh-sach-ip-xau --scope CLOUDFRONT \
  --region us-east-1 --ip-address-version IPV4 \
  --addresses "203.0.113.45/32"

aws wafv2 update-web-acl --name bao-ve-website --scope CLOUDFRONT \
  --region us-east-1 --id <id> --lock-token <token> \
  --default-action Allow={} \
  --rules '[{"Name":"ChanIPXau","Priority":0,
    "Statement":{"IPSetReferenceStatement":{"ARN":"<arn-ip-set>"}},
    "Action":{"Block":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"ChanIPXau"}}]' \
  --visibility-config SampledRequestsEnabled=true,\
CloudWatchMetricsEnabled=true,MetricName=baoVeWebsite

⚠ Web ACL cho CloudFront phải tạo ở us-east-1 với --scope CLOUDFRONT.

Vì sao ba phương án kia không hoạt động:

CloudFront đứng trước ALB
    → mọi request tới ALB đều mang IP của CLOUDFRONT
    → IP thật của kẻ tấn công nằm trong header X-Forwarded-For
        ↓
    Security group và NACL lọc theo IP GÓI TIN
    → chúng chỉ thấy IP của CloudFront
    → chặn IP độc hại ở đó là VÔ NGHĨA

Đây là điểm loại cả B và C.

Ba lợi ích của việc chặn ở WAF: | Lợi ích | Chi tiết | |---|---| | Chặn ở edge, gần kẻ tấn công nhất | | | Không tốn tài nguyên của ALB và EC2 | | | IP set chứa tới 10.000 địa chỉ | |

Và cập nhật IP set không cần triển khai lại:

aws wafv2 update-ip-set --name danh-sach-ip-xau --scope CLOUDFRONT \
  --region us-east-1 --id <id> --lock-token <token> \
  --addresses "203.0.113.45/32" "198.51.100.77/32"

Thêm IP mới có hiệu lực trong vòng một phút
    → phù hợp cho phản ứng nhanh

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

• **C. Sửa network ACL của các EC2 sau ALB để từ chối IP độc hại — đâ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ó không thấy IP thật: EC2 chỉ nhận kết nối từ ALB, và ALB chỉ nhận từ CloudFront.
• **B. Sửa security group của EC2 để từ chối IP độc hại — sai hai lần: security group không có quy tắc Deny (chỉ Allow), và cũng không thấy IP thật của client.
• **A. Sửa network ACL trên CloudFront distribution — CloudFront không có network ACL. Nó là dịch vụ toàn cầu nằm ngoài VPC, không có subnet để gắn NACL.

Ghi nhớ

⚠ Bốn công cụ lọc lưu lượng — bảng phải thuộc: | Công cụ | Tầng | Có Deny | Thấy IP thật sau CDN | |---|---|---|---| | AWS WAF | 7 (HTTP) | ✅ | ✅ | | Security Group | 3/4 | ❌ chỉ Allow | ❌ | | Network ACL | 3/4 | ✅ | ❌ | | AWS Network Firewall | 3-7 | ✅ | trong VPC |

Từ khoá nhận diện:

"block a malicious IP" + có CloudFront hoặc ALB → AWS WAF IP set "deny an IP at subnet level" (không có CDN) → NACL "allow traffic from a security group" → security group "block by domain name outbound" → Network Firewall

⚠ Vì sao IP thật bị che sau CloudFront:

Người dùng (203.0.113.45)
    → CloudFront (IP của AWS)
        → ALB (thấy IP của CloudFront)
            → EC2 (thấy IP của ALB)
        ↓
    IP thật chỉ còn trong header X-Forwarded-For
    → chỉ tầng 7 (WAF, ứng dụng) đọc được

Sáu tài nguyên gắn được WAF: | Tài nguyên | Scope | |---|---| | CloudFront | CLOUDFRONT (us-east-1) | | Application Load Balancer | REGIONAL | | API Gateway | REGIONAL | | AppSync, Cognito user pool | REGIONAL | | App Runner, Verified Access | REGIONAL |

⚠ S3 và NLB KHÔNG gắn WAF được.

Ba loại rule của WAF: | Loại | Việc | |---|---| | IP set rule | chặn/cho phép theo IP ← câu này | | Managed rule group | OWASP, IP xấu, bot | | Rate-based rule | chặn IP vượt ngưỡng request |

Rate-based rule chống lạm dụng:

{"Name":"GioiHanTanSuat","Priority":1,
 "Statement":{"RateBasedStatement":{"Limit":2000,"AggregateKeyType":"IP"}},
 "Action":{"Block":{}}}

Tự chặn IP gửi hơn 2.000 request trong 5 phút
    → tự động, không cần ai thêm IP bằng tay

Ba managed rule group nên bật: | Nhóm | Bảo vệ | |---|---| | AWSManagedRulesCommonRuleSet | XSS, path traversal | | AWSManagedRulesSQLiRuleSet | SQL injection ← đề đã có | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu |

⚠ Nhóm thứ ba tự động chặn IP xấu đã biết — đáng bật để không phải thêm từng IP bằng tay.

Ba lưu ý về IP set: | Lưu ý | Chi tiết | |---|---| | Chứa tới 10.000 CIDR | | | Hỗ trợ IPv4 và IPv6 (hai set riêng) | | | Cập nhật có hiệu lực trong ~1 phút | |

Ba lưu ý về thứ tự luật: | Lưu ý | Chi tiết | |---|---| | Đánh giá theo Priority TĂNG DẦN | | | Dừng ở luật khớp đầu tiên có Block/Allow | | | Đặt IP block ở priority thấp nhất | chặn sớm |

Ba lưu ý khi bật WAF lần đầu: | Lưu ý | Chi tiết | |---|---| | Bật ở chế độ COUNT trước | xem có chặn nhầm không | | Đọc sampled request | | | Rồi mới chuyển sang BLOCK | |

Ba cách theo dõi: | Cách | Chi tiết | |---|---| | WAF logging ra S3, CloudWatch hoặc Firehose | | | Sampled requests trong console | | | CloudWatch metric theo từng luật | |

aws wafv2 put-logging-configuration --logging-configuration '{
  "ResourceArn":"<arn-web-acl>",
  "LogDestinationConfigs":["arn:aws:s3:::aws-waf-logs-website"]}'

Ba lưu ý về bảo vệ nhiều lớp: | Lớp | Việc | |---|---| | AWS Shield Standard | DDoS tầng 3/4, miễn phí, tự động | | AWS WAF | tầng 7 | | Shield Advanced | DDoS lớn, có đội hỗ trợ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử gọi từ IP bị chặn | phải nhận 403 | | Kiểm tra WAF log ghi lại | | | Xác nhận người dùng thật không bị ảnh hưởng | |

Và một lời khuyên: hãy bật AWSManagedRulesAmazonIpReputationList thay vì thêm từng IP xấu bằng tay. Chặn một IP là phản ứng với một sự cố đã xảy ra; danh sách do AWS duy trì chặn hàng loạt IP đã có tiếng xấu trước khi chúng chạm tới bạn.

Đáp án

C — On-Demand Instances.

Vì sao đúng

Đề cho đủ số liệu để tính, và phép tính loại hết các lựa chọn khác: | Dữ kiện | Con số | |---|---| | Chạy mỗi QUÝ một lần | 4 lần/năm | | Mỗi lần 5 NGÀY | | | Mỗi ngày 5 GIỜ | | | 15 EC2 instance | | | KHÔNG được gián đoạn | loại Spot |

Tính tổng thời gian chạy mỗi năm:

5 giờ × 5 ngày × 4 quý = 100 giờ mỗi năm mỗi máy
        ↓
    Một năm có 8.760 giờ
    → tỷ lệ sử dụng: 100 / 8.760 ≈ 1,1%

⚠ Vì sao Reserved Instance không có lợi:

RI là cam kết trả tiền cho 1 hoặc 3 NĂM LIÊN TỤC
    → dù bạn có chạy máy hay không
        ↓
    Trả tiền cho 8.760 giờ để dùng 100 giờ
    → đắt hơn On-Demand rất nhiều lần

Điểm hoà vốn của RI thường vào khoảng:

RI 1 năm All Upfront giảm ~40%
    → hoà vốn khi dùng khoảng 60-70% thời gian
        ↓
    1,1% thì không có cửa nào

⚠ Và vì sao Spot không dùng được:

"The processing must run UNINTERRUPTED for 5 hours per day"
    → Spot bị thu hồi với 2 phút báo trước
        ↓
    Đề nói rõ không được gián đoạn → loại

Chạy job bằng On-Demand:

aws ec2 run-instances --image-id ami-abc --count 15 \
  --instance-type c6i.4xlarge --subnet-id subnet-a \
  --instance-initiated-shutdown-behavior terminate

Và tắt máy ngay khi xong để không trả thừa:

# Trong user data, tắt máy khi job hoàn tất
#!/bin/bash
/opt/chay-job.sh
shutdown -h now

Ba lợi ích của On-Demand ở đây: | Lợi ích | Chi tiết | |---|---| | Không cam kết gì | | | Không bị gián đoạn | | | Chỉ trả cho giờ thực chạy | |

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

• **A. Reserved Instances — đây là phương án gần nhất vì RI đúng là cách giảm giá cho EC2, nhưng nó đòi cam kết 1-3 năm liên tục. Với tỷ lệ sử dụng 1,1%, bạn sẽ trả tiền cho hàng nghìn giờ không dùng.
• **D. Spot Instances — rẻ nhất (tới 90%) nhưng bị thu hồi với 2 phút báo trước, vi phạm trực tiếp yêu cầu "must run uninterrupted".
• **B. Dedicated Instances — phần cứng chuyên dụng cho một khách hàng, đắt hơn On-Demand thường. Dùng khi có yêu cầu tuân thủ về cách ly phần cứng, không phải để tiết kiệm.

Ghi nhớ

⚠ Bốn mô hình thanh toán EC2 — bảng phải thuộc: | Mô hình | Giảm giá | Gián đoạn | Cam kết | |---|---|---|---| | On-Demand | 0% | ❌ | không | | Savings Plans | tới ~72% | ❌ | số tiền/giờ, 1-3 năm | | Reserved Instance | tới ~72% | ❌ | loại máy, 1-3 năm | | Spot | tới ~90% | ✅ 2 phút báo trước | không |

Từ khoá nhận diện:

"short, infrequent, cannot be interrupted" → On-Demand "steady 24/7" → Savings Plans hoặc RI "fault-tolerant, flexible timing" → Spot "compliance requires dedicated hardware" → Dedicated Host/Instance

⚠ Quy tắc ước lượng nhanh:

Tỷ lệ sử dụng trong năm:
    → dưới ~25%   → On-Demand
    → 25-70%      → cân nhắc Savings Plans
    → trên ~70%   → RI hoặc Savings Plans chắc chắn có lợi

Ba loại Savings Plans: | Loại | Giảm | Linh hoạt | |---|---|---| | Compute Savings Plans | tới ~66% | mọi vùng, mọi họ, cả Fargate và Lambda | | EC2 Instance Savings Plans | tới ~72% | cố định họ và vùng | | SageMaker | | cho ML |

⚠ Dedicated Instance và Dedicated Host — phân biệt: | | Dedicated Instance | Dedicated Host | |---|---|---| | Cách ly | phần cứng riêng | cả máy chủ vật lý riêng | | Thấy được socket, core | ❌ | ✅ | | Dùng cho | tuân thủ cơ bản | giấy phép BYOL theo core |

Dedicated Host cần khi giấy phép phần mềm
tính theo số socket hoặc core vật lý
    → ví dụ Windows Server, SQL Server, Oracle

Ba đặc điểm của Spot: | Đặc điểm | Chi tiết | |---|---| | Rẻ tới 90% | | | Bị thu hồi với 2 PHÚT báo trước | | | "Spot blocks" đã NGỪNG từ 12/2021 | |

⚠ Vế thứ ba đáng nhớ:

Trước đây có "defined duration Spot" (Spot block)
    → chạy 1-6 giờ không bị thu hồi
        ↓
    AWS đã ngừng tính năng này
    → giờ không có cách nào dùng Spot mà chắc chắn không bị cắt

Ba cách tối ưu cho job theo lô: | Cách | Chi tiết | |---|---| | AWS Batch | tự cấp và thu hồi máy | | Spot nếu job chịu được gián đoạn | | | Tắt máy ngay khi xong | |

AWS Batch đáng cân nhắc:

aws batch create-compute-environment \
  --compute-environment-name moi-truong-quy \
  --type MANAGED --state ENABLED \
  --compute-resources '{"type":"EC2","minvCpus":0,"maxvCpus":256,
    "instanceTypes":["c6i"],"subnets":["subnet-a"],
    "securityGroupIds":["sg-batch"],"instanceRole":"ecsInstanceRole"}'

minvCpus = 0 → không có job thì không có máy nào
    → tự cấp máy khi có job, tự thu hồi khi xong
        ↓
    Không phải nhớ tắt máy bằng tay

Ba lưu ý khi tính chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo giờ THỰC CHẠY | | | EBS vẫn tính phí khi máy dừng | | | Xoá volume khi terminate nếu không cần | |

⚠ EBS là chi phí hay bị quên:

Dừng (stop) 15 máy sau khi chạy xong
    → không trả phí compute nữa
    → NHƯNG vẫn trả phí EBS volume
        ↓
    Với job chạy mỗi quý, nên TERMINATE và chụp AMI

Ba công cụ phân tích chi phí: | Công cụ | Việc | |---|---| | Cost Explorer | chi phí theo thời gian và dịch vụ | | AWS Pricing Calculator | ước tính trước khi chạy | | Compute Optimizer | đúng cỡ máy |

Ba lưu ý về đúng cỡ máy: | Lưu ý | Chi tiết | |---|---| | Job xử lý theo lô thường nặng CPU | dùng họ C | | Ít máy to có thể rẻ hơn nhiều máy nhỏ | | | Graviton rẻ hơn ~20% nếu ứng dụng chạy được | |

Và một lời khuyên: hãy làm phép tính tỷ lệ sử dụng trước khi cân nhắc bất kỳ cam kết dài hạn nào. Reserved Instance và Savings Plans là công cụ tuyệt vời cho tải chạy liên tục, nhưng với một job chạy 100 giờ mỗi năm thì chúng chỉ biến một khoản chi nhỏ thành một khoản cam kết lớn.

Đáp án

D — AWS AppSync.

Vì sao đúng

Đề nêu ba yêu cầu, và AppSync là dịch vụ duy nhất khớp: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng SERVERLESS, kiến trúc microservice | AppSync không có máy chủ nào | | **Cần API GraphQL | AppSync là dịch vụ GraphQL được quản lý của AWS | | Một điểm vào duy nhất cho ứng dụng | GraphQL gộp nhiều nguồn thành một endpoint |

⚠ "GraphQL" là từ khoá quyết định — chỉ có một dịch vụ AWS:

API Gateway → REST và WebSocket
AppSync     → GraphQL (và pub/sub thời gian thực)
        ↓
    Không có lựa chọn nào khác

Vì sao GraphQL hợp với microservice:

REST: mỗi microservice một endpoint
    → client phải gọi nhiều lần rồi tự ghép dữ liệu

GraphQL: MỘT endpoint, một truy vấn
    → AppSync gọi nhiều data source rồi ghép lại
        ↓
    Đây chính là "single entry point" mà đề nói

Ví dụ một truy vấn gộp nhiều nguồn:

query LayThongTinDonHang {
  donHang(id: "123") {
    ma
    tongTien
    khachHang {      # từ một Lambda khác
      ten
      email
    }
    sanPham {        # từ một bảng DynamoDB khác
      ten
      gia
    }
  }
}

Client gọi MỘT lần
    → AppSync tự gọi ba nguồn và ghép kết quả

Tạo API:

aws appsync create-graphql-api --name api-ung-dung \
  --authentication-type AMAZON_COGNITO_USER_POOLS \
  --user-pool-config userPoolId=<id>,awsRegion=ap-southeast-1,\
defaultAction=ALLOW

aws appsync create-data-source --api-id <id> --name nguon-dynamodb \
  --type AMAZON_DYNAMODB --service-role-arn <arn-role> \
  --dynamodb-config tableName=DonHang,awsRegion=ap-southeast-1

Ba lợi ích của AppSync: | Lợi ích | Chi tiết | |---|---| | Client lấy ĐÚNG dữ liệu cần | không thừa, không thiếu | | Có subscription thời gian thực | qua WebSocket | | Nối được nhiều loại data source | |

⚠ Vế thứ hai là tính năng nổi bật:

GraphQL subscription = đẩy dữ liệu khi có thay đổi
    → AppSync quản lý WebSocket tự động
        ↓
    Với REST phải tự dựng WebSocket API

Sáu loại data source AppSync hỗ trợ: | Nguồn | Việc | |---|---| | Amazon DynamoDB | phổ biến nhất | | AWS Lambda | logic tuỳ ý | | Amazon Aurora Serverless (Data API) | CSDL quan hệ | | Amazon OpenSearch | tìm kiếm | | HTTP endpoint | API bên ngoài | | EventBridge | |

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

• **C. API Gateway — đây là phương án gần nhất và là dịch vụ API được quản lý của AWS, nhưng nó hỗ trợ REST, HTTP và WebSocket, không phải GraphQL. Bạn có thể chạy một GraphQL server trong Lambda sau API Gateway, nhưng đó là tự dựng chứ không phải dịch vụ được quản lý.
• **A. AWS Lambda — là tầng tính toán, không phải dịch vụ API. Nó có thể là data source của AppSync, nhưng bản thân nó không cung cấp endpoint GraphQL.
• **B. Amazon Athena — dịch vụ truy vấn SQL trên S3, hoàn toàn không liên quan tới API cho ứng dụng web.

Ghi nhớ

⚠ Ba dịch vụ API của AWS — bảng phải thuộc: | Dịch vụ | Kiểu API | |---|---| | Amazon API Gateway | REST, HTTP, WebSocket | | AWS AppSync | GraphQL | | Lambda Function URL | HTTPS đơn giản |

Từ khoá nhận diện:

"GraphQL" → AppSync (không có lựa chọn nào khác) "REST API" → API Gateway "real-time subscriptions, offline sync" → AppSync "WebSocket for chat" → API Gateway WebSocket hoặc AppSync

⚠ REST và GraphQL — bảng phân biệt: | | REST | GraphQL | |---|---|---| | Endpoint | nhiều, mỗi tài nguyên một cái | MỘT | | Dữ liệu trả về | cố định theo endpoint | client chọn trường | | Over-fetching | thường có | không | | Nhiều lần gọi để ghép dữ liệu | thường có | không | | Cache HTTP | dễ | khó hơn |

Ba khái niệm của AppSync: | Khái niệm | Nghĩa | |---|---| | Schema | định nghĩa kiểu dữ liệu và thao tác | | Data source | nơi lấy dữ liệu | | Resolver | nối một trường với một data source |

Ba loại thao tác GraphQL: | Thao tác | Việc | |---|---| | Query | đọc dữ liệu | | Mutation | ghi dữ liệu | | Subscription | nhận cập nhật thời gian thực |

Ba cách viết resolver: | Cách | Đặc điểm | |---|---| | VTL template | cách cũ, cú pháp khó | | JavaScript resolver (APPSYNC_JS) | cách mới, dễ hơn nhiều | | Lambda resolver | logic phức tạp |

JavaScript resolver:

export function request(ctx) {
  return {
    operation: 'GetItem',
    key: util.dynamodb.toMapValues({ id: ctx.args.id })
  };
}

export function response(ctx) {
  return ctx.result;
}

Năm cách xác thực của AppSync: | Cách | Dùng cho | |---|---| | API key | thử nghiệm, KHÔNG dùng cho production | | Amazon Cognito user pool | người dùng ứng dụng | | IAM | dịch vụ nội bộ | | OpenID Connect | IdP bên ngoài | | Lambda authorizer | logic tuỳ chỉnh |

⚠ Có thể dùng NHIỀU cách cùng lúc:

Truy vấn công khai → API key
Mutation cần đăng nhập → Cognito
        ↓
    Khai @aws_api_key và @aws_cognito_user_pools
      trên từng trường trong schema

Ba tính năng nâng cao: | Tính năng | Việc | |---|---| | Caching | giảm gọi data source | | Offline sync (Amplify DataStore) | ứng dụng di động | | Pipeline resolver | gọi nhiều nguồn tuần tự |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Vấn đề N+1 query | một truy vấn lồng sinh nhiều lần gọi | | Dùng batch resolver để gộp | | | Bật caching cho dữ liệu ít đổi | |

⚠ N+1 là vấn đề kinh điển của GraphQL:

Truy vấn 100 đơn hàng, mỗi đơn có khách hàng
    → resolver ngây thơ gọi DynamoDB 101 lần
        ↓
    Dùng BatchGetItem resolver → 2 lần gọi

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Phân quyền theo trường (@aws_auth) | | | Giới hạn độ sâu truy vấn | chống truy vấn lồng vô hạn | | Gắn AWS WAF vào AppSync | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo số thao tác query/mutation | | | Subscription tính theo phút kết nối | | | Cache tính riêng theo giờ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử truy vấn trong console AppSync | | | Kiểm tra CloudWatch log của resolver | | | Đo số lần gọi data source | tìm N+1 |

Và một lời khuyên: hãy giới hạn độ sâu và độ phức tạp của truy vấn ngay từ đầu. GraphQL cho client tự chọn dữ liệu — điều đó rất tiện, nhưng cũng nghĩa là một truy vấn lồng nhiều tầng có thể vô tình biến một request thành hàng nghìn lần gọi xuống tầng dữ liệu.

Đáp án

D và E.

• D — Bật versioning trên bucket
• E — Bật MFA Delete trên bucket

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Ngăn XOÁ NHẦM tài liệu | MFA Delete + versioning | | Mọi PHIÊN BẢN tài liệu phải còn | versioning | | Người dùng vẫn tải lên và sửa được | cả hai đều không chặn ghi |

Versioning làm gì:

Ghi đè một object → tạo PHIÊN BẢN MỚI
    → phiên bản cũ VẪN CÒN
Xoá một object    → tạo DELETE MARKER
    → dữ liệu vẫn còn phía dưới
        ↓
    Đáp ứng "all versions must be available"

MFA Delete thêm lớp gì:

Bật MFA Delete:
    → xoá VĨNH VIỄN một phiên bản cần mã MFA
    → tắt versioning cũng cần mã MFA
        ↓
    Không ai xoá vĩnh viễn bằng một lệnh vô ý

Bật versioning:

aws s3api put-bucket-versioning --bucket kho-tai-lieu \
  --versioning-configuration Status=Enabled

Bật MFA Delete:

aws s3api put-bucket-versioning --bucket kho-tai-lieu \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

⚠ Ba ràng buộc của MFA Delete — phải nhớ: | Ràng buộc | Chi tiết | |---|---| | CHỈ tài khoản ROOT bật được | không phải IAM user | | CHỈ bật được qua CLI hoặc API | console không làm được | | Bucket phải bật versioning | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Người dùng vẫn tải lên và sửa bình thường | | | Xoá nhầm khôi phục được | | | Xoá vĩnh viễn cần MFA | |

Khôi phục object bị xoá nhầm:

# Tìm delete marker
aws s3api list-object-versions --bucket kho-tai-lieu \
  --prefix bai-nop/hs001.pdf \
  --query "DeleteMarkers[].[Key,VersionId]" --output table

# Xoá delete marker → object hiện lại
aws s3api delete-object --bucket kho-tai-lieu \
  --key bai-nop/hs001.pdf --version-id <id-delete-marker>

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

• **A. Gắn một IAM policy vào bucket — cách diễn đạt không chính xác (gắn vào bucket là bucket policy), và dù có thì một chính sách từ chối xoá cũng chặn luôn việc dọn dẹp hợp lệ, và không giữ được các phiên bản.
• **C. Đặt quyền chỉ đọc trên bucket — vi phạm trực tiếp yêu cầu: đề nói người dùng phải tải lên và sửa tài liệu được.
• **B. Mã hoá bucket bằng SSE-S3 — mã hoá bảo vệ dữ liệu khi lưu trữ, hoàn toàn không liên quan tới việc chống xoá nhầm hay giữ phiên bản.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ dữ liệu S3 — bảng phải thuộc: | Cơ chế | Bảo vệ khỏi | Ai gỡ được | |---|---|---| | Versioning | ghi đè và xoá | xoá phiên bản được | | MFA Delete | xoá vĩnh viễn | chỉ root có MFA | | Object Lock — Governance | xoá nhầm | có quyền bypass | | Object Lock — Compliance | xoá cố ý | KHÔNG AI |

Từ khoá nhận diện:

"prevent accidental deletion" + "all versions available" + "users can modify" → versioning + MFA Delete "cannot be deleted for a fixed period, regulatory" → Object Lock compliance "recover deleted EBS snapshots" → Recycle Bin

⚠ MFA Delete và Object Lock — khi nào dùng cái nào: | | MFA Delete | Object Lock | |---|---|---| | Bật bởi | chỉ root | bất kỳ ai có quyền | | Bật lúc nào | bất cứ lúc nào | PHẢI lúc TẠO bucket | | Chặn | xoá vĩnh viễn | cả ghi đè trong thời hạn | | Ngoại lệ | root có MFA | compliance: không ai |

Ba trạng thái versioning: | Trạng thái | Nghĩa | |---|---| | Unversioned | mặc định, chưa bao giờ bật | | Enabled | đang bật | | Suspended | tạm dừng — phiên bản CŨ vẫn còn |

⚠ Không tắt hẳn versioning được:

Đã bật rồi thì chỉ SUSPEND được, không quay về unversioned
    → phiên bản cũ vẫn tồn tại và vẫn tính phí
        ↓
    Muốn dọn: dùng NoncurrentVersionExpiration

⚠ Ba bẫy chi phí với versioning: | Bẫy | Chi tiết | |---|---| | Mỗi phiên bản tính phí ĐẦY ĐỦ | không phải chỉ phần khác biệt | | Xoá object chỉ tạo delete marker | dung lượng KHÔNG giảm | | Multipart upload dở dang tích tụ | |

Lifecycle dọn phiên bản cũ:

{"Rules": [{
  "ID": "don-phien-ban-cu", "Status": "Enabled", "Filter": {},
  "NoncurrentVersionTransitions": [
    {"NoncurrentDays": 30, "StorageClass": "STANDARD_IA"}],
  "NoncurrentVersionExpiration": {"NoncurrentDays": 365},
  "Expiration": {"ExpiredObjectDeleteMarker": true},
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

⚠ Bốn quy tắc trên nên có ở mọi bucket bật versioning:

NoncurrentVersionTransitions  → chuyển bản cũ sang lớp rẻ
NoncurrentVersionExpiration   → xoá bản quá cũ
ExpiredObjectDeleteMarker     → dọn delete marker mồ côi
AbortIncompleteMultipartUpload → dọn phần tải lên dở

⚠ MFA Delete xung đột với lifecycle:

Bật MFA Delete
    → lifecycle KHÔNG xoá được phiên bản cũ
        ↓
    Phải cân nhắc: bảo vệ chặt hay tự dọn được
    → nhiều tổ chức chọn Object Lock governance thay thế

Ba lệnh làm việc với phiên bản: | Lệnh | Việc | |---|---| | list-object-versions | xem mọi phiên bản | | get-object --version-id | lấy một phiên bản cụ thể | | delete-object --version-id | xoá VĨNH VIỄN một phiên bản |

Ba lưu ý về delete marker: | Lưu ý | Chi tiết | |---|---| | GET không có version-id → trả 404 | | | Object vẫn còn phía dưới | | | Xoá delete marker → object hiện lại | |

Ba biện pháp bổ sung: | Biện pháp | Việc | |---|---| | Bật S3 Replication sang bucket khác | chống mất cả bucket | | Bucket policy chặn s3:DeleteObjectVersion | | | CloudTrail data event ghi mọi thao tác | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi đè một tệp, kiểm tra phiên bản cũ còn không | | | Xoá một tệp, khôi phục lại | | | Thử xoá vĩnh viễn không có MFA | phải bị từ chối |

Và một lời khuyên: hãy cân nhắc kỹ trước khi bật MFA Delete. Nó bảo vệ rất chắc, nhưng cũng nghĩa là mọi việc dọn dẹp phải làm bằng tay với thiết bị MFA của tài khoản root — và lifecycle tự động sẽ không dọn được gì, nên dung lượng bucket chỉ có tăng.

Đáp án

C — Lưu ảnh trong Amazon S3 sau một CloudFront distribution, và dùng S3 Object Lambda để biến đổi ảnh mỗi khi có request GET.

Vì sao đúng

Đề nêu bốn yêu cầu, và S3 Object Lambda là tính năng sinh ra đúng cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu ảnh cho website nhiều người xem | S3 — bền, rẻ, không giới hạn | | **Biến đổi ảnh KHI ĐANG LẤY RA | S3 Object Lambda chạy lúc GET | | Dùng dịch vụ được quản lý | cả ba đều được quản lý | | Toàn cầu, độ trễ thấp | CloudFront cache ở edge |

⚠ S3 Object Lambda hoạt động thế nào:

Client gọi GET qua Object Lambda Access Point
    → S3 lấy object gốc
    → CHUYỂN qua một Lambda function
    → Lambda biến đổi rồi trả về
        ↓
    Object GỐC trong S3 KHÔNG đổi
    → mỗi client có thể nhận một biến thể khác nhau

Đây chính là "transformed as they are being retrieved".

Dựng:

# 1. Access point thường
aws s3control create-access-point --account-id 123456789012 \
  --name ap-anh --bucket kho-anh

# 2. Object Lambda access point
aws s3control create-access-point-for-object-lambda \
  --account-id 123456789012 --name olap-anh \
  --configuration '{
    "SupportingAccessPoint":"arn:aws:s3:ap-southeast-1:123456789012:accesspoint/ap-anh",
    "TransformationConfigurations":[{
      "Actions":["GetObject"],
      "ContentTransformation":{
        "AwsLambda":{"FunctionArn":"arn:aws:lambda:...:function:bien-doi-anh"}}}]}'

Lambda biến đổi:

import boto3, requests
from PIL import Image
from io import BytesIO

s3 = boto3.client('s3')

def handler(event, context):
    ctx = event['getObjectContext']
    anh_goc = requests.get(ctx['inputS3Url']).content

    # Đọc tham số từ query string
    tham_so = event['userRequest']['url']
    img = Image.open(BytesIO(anh_goc))
    img.thumbnail((800, 800))

    buf = BytesIO()
    img.save(buf, format='WEBP', quality=85)

    s3.write_get_object_response(
        Body=buf.getvalue(),
        RequestRoute=ctx['outputRoute'],
        RequestToken=ctx['outputToken'])

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ lưu MỘT bản gốc | không sinh hàng chục biến thể | | CloudFront cache kết quả đã biến đổi | Lambda chỉ chạy lần đầu | | Thêm biến thể mới không phải xử lý lại kho ảnh | |

Vế thứ hai rất quan trọng về chi phí:

Không có CloudFront: mỗi request gọi Lambda
    → phí Lambda tăng theo lưu lượng
        ↓
Có CloudFront: kết quả được cache ở edge
    → Lambda chỉ chạy khi cache miss
    → hàng nghìn người xem chỉ tốn vài lần gọi

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

• **D. S3 sau CloudFront, dùng S3 Event Notification gọi Lambda khi có request GET — đây là phương án gần nhất và chỉ sai một chi tiết cốt lõi: S3 Event Notification chỉ kích hoạt khi object được TẠO, XOÁ hoặc THAY ĐỔI, không kích hoạt khi có request GET. Không có sự kiện nào cho việc đọc.
• **A. Lưu ảnh trong DynamoDB với Global Tables — sai loại kho lưu trữ: DynamoDB giới hạn 400 KB mỗi item, không phù hợp cho ảnh. Và "xử lý dữ liệu khi rời khỏi bảng" không phải cơ chế có thật.
• **B. Lưu ảnh trong DynamoDB với DAX và EventBridge — cùng vấn đề kích thước item, và DAX là cache cho DynamoDB chứ không phục vụ ảnh qua HTTP.

Ghi nhớ

⚠ Ba cách biến đổi ảnh trên AWS — bảng phải thuộc: | Cách | Khi nào biến đổi | |---|---| | S3 Object Lambda | LÚC ĐỌC (GET) ← câu này | | S3 Event → Lambda | LÚC GHI (object được tạo) | | CloudFront Functions / Lambda@Edge | ở edge, trên đường đi |

⚠ Ba loại sự kiện S3 Event Notification: | Loại | Kích hoạt khi | |---|---| | s3:ObjectCreated:* | object được tạo | | s3:ObjectRemoved:* | object bị xoá | | s3:ObjectRestore:* | khôi phục từ Glacier |

KHÔNG có sự kiện nào cho GetObject
    → đây là lý do phương án D sai

Từ khoá nhận diện:

"transform as they are retrieved" → S3 Object Lambda "process when uploaded" → S3 Event Notification → Lambda "modify request/response at edge" → CloudFront Functions / Lambda@Edge "low latency globally" → CloudFront

Ba trường hợp dùng S3 Object Lambda: | Trường hợp | Chi tiết | |---|---| | Đổi kích thước, đổi định dạng ảnh | ← câu này | | Che dữ liệu nhạy cảm theo người dùng | | | Đổi định dạng dữ liệu (XML → JSON) | |

⚠ Ba giới hạn của S3 Object Lambda: | Giới hạn | Chi tiết | |---|---| | Lambda tối đa 60 giây cho Object Lambda | | | Kích thước phản hồi tối đa 1 GB | | | Chỉ hỗ trợ GetObject, HeadObject, ListObjects | |

Ba cách so sánh với biến đổi lúc ghi: | | Lúc ĐỌC (Object Lambda) | Lúc GHI (Event Notification) | |---|---|---| | Số bản lưu | 1 bản gốc | nhiều biến thể | | Chi phí lưu trữ | thấp | cao hơn | | Chi phí tính toán | mỗi lần cache miss | một lần khi tải lên | | Thêm biến thể mới | ngay lập tức | phải xử lý lại toàn kho |

Ít biến thể, lưu lượng rất lớn → biến đổi lúc GHI rẻ hơn
Nhiều biến thể, hay đổi        → biến đổi lúc ĐỌC linh hoạt hơn

⚠ CloudFront Functions và Lambda@Edge — phân biệt: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Thời gian chạy | dưới 1 ms | tới 5-30 giây | | Ngôn ngữ | JavaScript hạn chế | Node.js, Python | | Truy cập mạng | ❌ | ✅ | | Chi phí | rẻ hơn ~6 lần | | | Dùng cho | sửa header, redirect | logic phức tạp |

Ba lưu ý về cache với ảnh biến đổi: | Lưu ý | Chi tiết | |---|---| | Đưa tham số biến đổi vào cache key | ?w=800&f=webp | | TTL dài — ảnh không đổi | | | Bật nén | |

Cache policy đưa query string vào khoá:

aws cloudfront create-cache-policy --cache-policy-config '{
  "Name":"cache-anh-theo-tham-so",
  "DefaultTTL":86400,"MaxTTL":31536000,"MinTTL":1,
  "ParametersInCacheKeyAndForwardedToOrigin":{
    "QueryStringsConfig":{"QueryStringBehavior":"whitelist",
      "QueryStrings":{"Quantity":2,"Items":["w","f"]}},
    "HeadersConfig":{"HeaderBehavior":"none"},
    "CookiesConfig":{"CookieBehavior":"none"},
    "EnableAcceptEncodingGzip":true,
    "EnableAcceptEncodingBrotli":true}}'

⚠ Chỉ đưa tham số CẦN THIẾT vào cache key:

Forward mọi query string
    → ?utm_source=facebook tạo một bản cache riêng
    → tỷ lệ trúng cache tụt thảm hại

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Dùng OAC để bucket riêng tư | | | Giới hạn tham số biến đổi hợp lệ | tránh tấn công tài nguyên | | Đặt trần kích thước ảnh đầu ra | |

Vế thứ hai đáng lưu ý:

Không giới hạn tham số
    → kẻ tấn công gọi ?w=1&w=2&w=3... hàng nghìn lần
    → mỗi lần một cache key mới, một lần gọi Lambda
        ↓
    Chỉ chấp nhận vài kích thước cố định

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lambda tính theo GB-giây | | | S3 Object Lambda có phí riêng theo GB xử lý | | | CloudFront cache giảm mạnh cả hai | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi qua Object Lambda access point | | | Kiểm tra header X-Cache của CloudFront | | | Đo tỷ lệ cache hit sau vài ngày | |

Và một lời khuyên: hãy chỉ chấp nhận một danh sách cố định các kích thước ảnh. Cho phép client truyền tham số tuỳ ý nghe rất linh hoạt, nhưng nó biến mỗi giá trị khác nhau thành một cache key mới và một lần gọi Lambda — và đó là cách để một trang web bình thường tạo ra hoá đơn của một hệ thống xử lý ảnh.

Đáp án

C — Elastic Fabric Adapter (EFA).

Vì sao đúng

Đề nêu hai dữ kiện, và cả hai chỉ về EFA: | Dữ kiện | Ý nghĩa | |---|---| | **Tải HPC GẮN KẾT CHẶT (tightly-coupled) | các node phải trao đổi liên tục với nhau | | Di chuyển lên AWS | cần adapter mạng phù hợp |

⚠ "Tightly-coupled" là từ khoá quyết định:

Tightly-coupled HPC = các node phụ thuộc nhau từng bước tính toán
    → thường dùng MPI (Message Passing Interface)
    → độ trễ giữa node quyết định hiệu năng tổng
        ↓
    Đây chính là bài toán EFA sinh ra để giải

EFA làm gì mà ENA không làm được:

ENA (adapter thường):
    dữ liệu đi qua KERNEL của hệ điều hành
    → mỗi lần gửi/nhận tốn thời gian chuyển ngữ cảnh

EFA:
    OS-BYPASS — ứng dụng nói THẲNG với phần cứng mạng
    → bỏ qua kernel hoàn toàn
        ↓
    Độ trễ thấp hơn nhiều, ổn định hơn nhiều

Cài EFA:

curl -O https://efa-installer.amazonaws.com/aws-efa-installer-latest.tar.gz
tar -xf aws-efa-installer-latest.tar.gz && cd aws-efa-installer
sudo ./efa_installer.sh -y

# Kiểm tra
fi_info -p efa

Khởi động instance có EFA:

aws ec2 run-instances --image-id ami-hpc --count 16 \
  --instance-type c6in.24xlarge \
  --placement GroupName=cum-hpc \
  --network-interfaces '[{"DeviceIndex":0,"InterfaceType":"efa",
    "SubnetId":"subnet-hpc","Groups":["sg-hpc"]}]'

⚠ Security group phải cho phép CHÍNH NÓ:

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 thành viên
    → thiếu quy tắc self-referencing này thì MPI không chạy

Ba lợi ích của EFA: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp và ỔN ĐỊNH | quan trọng hơn cả băng thông | | Hỗ trợ libfabric, MPI, NCCL | | | Không tính phí thêm | |

Và phải dùng cùng cluster placement group:

EFA làm ĐƯỜNG TRUYỀN nhanh
Cluster placement group đặt máy GẦN NHAU về vật lý
        ↓
    Cần cả hai để đạt độ trễ thấp nhất

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

• **A. Elastic Network Adapter (ENA) — đây là phương án gần nhất và là adapter mặc định cho mọi instance đời mới, cho băng thông rất cao (tới 200 Gbps). Nhưng nó vẫn đi qua kernel, nên độ trễ cao hơn EFA — điều quyết định với tải tightly-coupled.
• **B. Elastic Network Interface (ENI) — là giao diện mạng ảo cơ bản của mọi instance (có IP, security group, MAC). Nó không phải một loại adapter hiệu năng cao.
• **D. Elastic IP Address — là địa chỉ IPv4 công khai tĩnh, hoàn toàn không liên quan tới hiệu năng mạng giữa các node.

Ghi nhớ

⚠ Ba khái niệm mạng EC2 dễ lẫn — bảng phải thuộc: | Khái niệm | Là gì | |---|---| | ENI (Elastic Network Interface) | giao diện mạng ảo cơ bản | | ENA (Elastic Network Adapter) | enhanced networking — băng thông cao | | EFA (Elastic Fabric Adapter) | ENA + OS-bypass cho HPC |

EFA là một ENI ĐẶC BIỆT
    → có mọi khả năng của ENA
    → CỘNG thêm giao diện OS-bypass

Từ khoá nhận diện:

"tightly-coupled HPC", "MPI", "low latency between nodes" → EFA "high bandwidth, general purpose" → ENA "static public IP" → Elastic IP "place instances close together" → cluster placement group

⚠ Hai loại tải HPC — phân biệt: | Loại | Đặc điểm | Cần | |---|---|---| | Tightly-coupled | node phụ thuộc nhau từng bước | EFA + cluster placement group | | Loosely-coupled | node độc lập, chia việc | ENA thường là đủ |

Tightly-coupled: mô phỏng CFD, dự báo thời tiết, phân tử động lực học
Loosely-coupled: render frame, xử lý ảnh hàng loạt, Monte Carlo

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 yêu cầu để dùng EFA: | Yêu cầu | Chi tiết | |---|---| | Loại instance hỗ trợ EFA | c6in, hpc7a, p5... | | Cài EFA installer | driver + libfabric | | Security group self-referencing | |

⚠ EFA chỉ hoạt động TRONG một subnet:

Lưu lượng OS-bypass không định tuyến qua router
    → mọi node phải cùng subnet, cùng AZ
        ↓
    Đây là hạn chế cố hữu, không phải cấu hình sai

Ba họ instance hay dùng 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 cho ML |

Ba dịch vụ điều phối HPC: | Dịch vụ | Việc | |---|---| | AWS ParallelCluster | dựng cụm HPC với Slurm | | AWS Batch | multi-node parallel job | | Amazon FSx for Lustre | hệ thống tệp song song |

ParallelCluster tự lo cả EFA và placement group:

Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: tinh-toan
      Networking:
        SubnetIds: [subnet-hpc]
        PlacementGroup:
          Enabled: true
      ComputeResources:
        - Name: hpc7a
          InstanceType: hpc7a.96xlarge
          Efa:
            Enabled: true

Ba thư viện dùng EFA: | Thư viện | Dùng cho | |---|---| | Open MPI, Intel MPI | HPC truyền thống | | NCCL | huấn luyện mô hình phân tán trên GPU | | libfabric | tầng dưới |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Khởi động HẾT máy cùng lúc | tránh thiếu năng lực | | Đặt trước bằng Capacity Reservation | | | Đo bằng OSU benchmark | |

Ba lưu ý về kiểm chứng: | Việc | Cách | |---|---| | fi_info -p efa | EFA đã nhận chưa | | Chạy benchmark độ trễ MPI | | | So sánh thời gian chạy với và không có EFA | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | EFA KHÔNG tính phí thêm | | | Placement group cũng miễn phí | | | Chi phí nằm ở loại instance | |

Và một lời khuyên: hãy kiểm tra quy tắc security group tự tham chiếu ngay khi MPI không chạy. Đó là nguyên nhân phổ biến nhất khi EFA đã cài đúng, fi_info báo bình thường, mà job vẫn treo ở bước khởi tạo — và thông báo lỗi của MPI không hề nhắc tới security group.

Đáp án

C — Di chuyển tài khoản bằng console của AWS Organizations.

Vì sao đúng

Đề mô tả một tình huống rất cụ thể, và AWS có sẵn quy trình cho nó: | Dữ kiện | Cách đáp ứng | |---|---| | Đã bán một đơn vị kinh doanh | | | Cần chuyển tài khoản AWS của đơn vị đó sang tổ chức khác | rời tổ chức cũ, tham gia tổ chức mới |

Quy trình gồm hai bước:

Bước 1: RỜI tổ chức hiện tại
    → tài khoản trở thành tài khoản độc lập (standalone)

Bước 2: CHẤP NHẬN lời mời từ tổ chức mới
    → tài khoản gia nhập tổ chức đích
        ↓
    Toàn bộ tài nguyên, dữ liệu, cấu hình GIỮ NGUYÊN

Bước 1 — rời tổ chức cũ:

# Từ tài khoản quản lý của tổ chức CŨ
aws organizations remove-account-from-organization --account-id 111122223333

# Hoặc từ chính tài khoản đó
aws organizations leave-organization

Bước 2 — tham gia tổ chức mới:

# Từ tài khoản quản lý của tổ chức MỚI
aws organizations invite-account-to-organization \
  --target Id=111122223333,Type=ACCOUNT

# Từ tài khoản được mời
aws organizations accept-handshake --handshake-id h-abc123

⚠ Điều kiện để rời tổ chức — đây là phần hay bị vướng: | Điều kiện | Chi tiết | |---|---| | Tài khoản phải có thông tin liên hệ đầy đủ | | | Phải có phương thức thanh toán hợp lệ | | | Phải đồng ý AWS Customer Agreement | | | Phải xác minh số điện thoại | |

Tài khoản tạo bằng Organizations thường THIẾU những thứ này
    → phải bổ sung trước khi rời
        ↓
    Đây là bước tốn thời gian nhất

Ba lợi ích của cách này: | Lợi ích | Chi tiết | |---|---| | Giữ nguyên MỌI tài nguyên và dữ liệu | không phải di chuyển gì | | Giữ nguyên account ID | ARN không đổi | | Không có thời gian ngừng | |

Vế thứ hai rất quan trọng:

Account ID không đổi
    → mọi ARN, mọi trust policy, mọi tham chiếu vẫn đúng
        ↓
    Tạo tài khoản mới rồi chép sang thì mọi thứ đó đều gãy

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

• **D. Tạo tài khoản mới ở tổ chức đích rồi di chuyển tài nguyên — đây là phương án gần nhất vì cũng đạt được kết quả, nhưng nó tốn công gấp bội: phải chuyển từng dịch vụ, mỗi dịch vụ một cách khác nhau, account ID đổi làm mọi ARN gãy, và gần như chắc chắn có thời gian ngừng.
• **A. Tạo tài khoản mới và chia sẻ tài nguyên gốc qua AWS RAM — RAM chỉ chia sẻ được vài loại tài nguyên (subnet, Transit Gateway, license), không chia sẻ được EC2 instance, S3 bucket, CSDL. Và tài nguyên vẫn thuộc tổ chức cũ.
• **B. Di chuyển tài khoản bằng CloudFormation — CloudFormation triển khai tài nguyên, không di chuyển tài khoản. Không có resource type nào làm việc này.

Ghi nhớ

⚠ Ba thao tác với tài khoản trong Organizations — bảng phải thuộc: | Thao tác | API | |---|---| | Tạo tài khoản mới | CreateAccount | | Mời tài khoản có sẵn | InviteAccountToOrganization | | Gỡ tài khoản khỏi tổ chức | RemoveAccountFromOrganization |

Từ khoá nhận diện:

"move an existing AWS account to another organization" → rời rồi tham gia lại "create many accounts automatically" → CloudFormation + StackSets hoặc Control Tower "share resources across accounts" → AWS RAM

⚠ Ba loại tài nguyên RAM chia sẻ được: | Tài nguyên | Ghi chú | |---|---| | Subnet của VPC | VPC dùng chung | | Transit Gateway | | | License Manager, Route 53 Resolver rule | | | Aurora DB cluster (snapshot) | |

RAM KHÔNG chia sẻ được: EC2 instance, S3 bucket,
CSDL đang chạy, IAM role
    → nó chia sẻ HẠ TẦNG, không phải mọi thứ

Ba thứ cần kiểm tra TRƯỚC khi rời tổ chức: | Thứ | Vì sao | |---|---| | Thanh toán | tài khoản sẽ tự trả hoá đơn của mình | | SCP đang áp | mất SCP có thể mở quyền ngoài ý muốn | | Dịch vụ tập trung | CloudTrail, Config, Security Hub |

⚠ Vế thứ ba là chỗ hay bị bỏ sót:

Tổ chức cũ có CloudTrail tổ chức, Config aggregator,
GuardDuty tập trung
    → tài khoản rời đi sẽ MẤT những thứ đó
        ↓
    Phải dựng lại ở tổ chức mới
    → và có khoảng trống audit giữa hai thời điểm

Ba thứ KHÔNG đổi khi chuyển tổ chức: | Thứ | Chi tiết | |---|---| | Account ID | | | Mọi tài nguyên và dữ liệu | | | IAM user, role, policy | |

Ba thứ ĐỔI: | Thứ | Chi tiết | |---|---| | SCP áp dụng | theo tổ chức mới | | Hoá đơn hợp nhất | chuyển sang tổ chức mới | | Quyền truy cập của tài khoản quản lý cũ | mất |

⚠ Vế thứ ba đáng chú ý về bảo mật:

Tài khoản quản lý cũ thường có role
OrganizationAccountAccessRole trong tài khoản thành viên
        ↓
    Sau khi rời, role đó VẪN CÒN
    → tổ chức cũ vẫn assume được nếu không xoá
        ↓
    Kiểm tra và xoá trust policy trỏ về tài khoản cũ

aws iam get-role --role-name OrganizationAccountAccessRole \
  --query "Role.AssumeRolePolicyDocument"

Ba lưu ý về thanh toán: | Lưu ý | Chi tiết | |---|---| | Chi phí trước ngày rời thuộc tổ chức cũ | | | Reserved Instance và Savings Plans KHÔNG chuyển theo | | | Có thể mất mức chiết khấu theo khối lượng | |

⚠ Vế thứ hai có ảnh hưởng tài chính lớn:

RI và Savings Plans mua ở tài khoản quản lý cũ
    → chúng ở lại tổ chức cũ
    → tài khoản chuyển đi mất quyền hưởng
        ↓
    Phải tính lại chi phí sau khi tách

Ba bước nên làm sau khi gia nhập tổ chức mới: | Bước | Chi tiết | |---|---| | Đưa vào đúng OU | để nhận SCP phù hợp | | Dựng lại CloudTrail, Config, GuardDuty | | | Rà soát IAM role và trust policy cũ | |

Ba công cụ hỗ trợ quản trị đa tài khoản: | Công cụ | Việc | |---|---| | AWS Control Tower | landing zone có guardrail | | AWS Organizations | cấu trúc và SCP | | IAM Identity Center | truy cập tập trung |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | describe-organization từ tài khoản đó | thuộc tổ chức nào | | Kiểm tra SCP mới đã áp | | | Xác nhận hoá đơn chuyển đúng | |

aws organizations describe-organization \
  --query "Organization.[Id,MasterAccountId]"

Và một lời khuyên: hãy hoàn tất thông tin liên hệ và phương thức thanh toán của tài khoản trước khi bắt đầu quy trình rời tổ chức. Đó là bước duy nhất có thể chặn cả kế hoạch, và nó thường chỉ lộ ra khi bạn bấm nút rời và nhận được thông báo từ chối.