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

Đáp án

A — Cấu hình security group của tầng CSDL cho phép lưu lượng CHỈ TỪ security group của tầng ứng dụng.

Vì sao đúng

Đề nêu một vấn đề rất cụ thể, và tham chiếu security group là cách duy nhất giải được: | Vấn đề | Cách giải | |---|---| | Instance tầng ứng dụng liên tục được tạo và huỷ | IP thay đổi liên tục | | Cần giới hạn CSDL chỉ nhận từ tầng ứng dụng | tham chiếu SECURITY GROUP thay vì IP |

⚠ Đây là ưu thế lớn nhất của security group so với NACL:

Security group cho phép nguồn là MỘT SECURITY GROUP KHÁC
    → không phải IP hay CIDR
        ↓
    Máy mới do Auto Scaling tạo ra tự động có sg-ungdung
    → tự động được phép vào CSDL
    → không phải cập nhật quy tắc nào

Cấu hình:

aws ec2 authorize-security-group-ingress --group-id sg-csdl \
  --protocol tcp --port 3306 --source-group sg-ungdung

So sánh với cách dùng CIDR:

Cho phép 10.0.1.0/24 vào cổng 3306
    → dải đó có thể chứa cả máy KHÔNG phải tầng ứng dụng
    → và nếu subnet đổi thì phải sửa quy tắc
        ↓
    Tham chiếu security group: chỉ đúng những máy có sg đó

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tự động áp dụng cho máy mới | | | Chặt hơn CIDR | chỉ máy có sg đó | | Không phải bảo trì danh sách IP | |

⚠ Và vì sao chỉ mở cổng 3306:

MySQL dùng cổng 3306
    → mở đúng cổng cần, theo nguyên tắc đặc quyền tối thiểu

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

• **D. Cấu hình security group của CSDL cho phép lưu lượng chỉ từ cổng 3306 — đây là phương án gần nhất và chỉ thiếu một nửa: nó giới hạn cổng nhưng không giới hạn nguồn. Nghĩa là bất kỳ ai cũng vào được cổng 3306, chỉ cần tới được mạng.
• **C. Cấu hình NACL trên subnet CSDL cho phép mọi lưu lượng từ subnet ứng dụng — NACL chỉ lọc theo CIDR, và "mọi lưu lượng" là quá rộng. Nó cũng không tự thích ứng nếu có máy khác trong cùng subnet.
• **B. Cấu hình NACL từ chối mọi lưu lượng tới cổng khác 3306 — NACL là stateless nên phải mở cả cổng ephemeral cho phản hồi; và nó vẫn không giới hạn được ai kết nối.

Ghi nhớ

⚠ Security Group và NACL — bảng phải thuộc: | | Security Group | Network ACL | |---|---|---| | Cấp | ENI (instance) | subnet | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | chỉ Allow | Allow và Deny | | Nguồn | CIDR hoặc SECURITY GROUP | chỉ CIDR | | Đánh giá | mọi quy tắc (OR) | theo số thứ tự |

⚠ Dòng "nguồn là security group" là điểm quyết định của câu này.

Từ khoá nhận diện:

"instances constantly launched and terminated" → tham chiếu security group "deny a specific IP" → NACL (security group không có Deny) "block at subnet level" → NACL "block malicious HTTP requests" → AWS WAF

⚠ Mẫu chuẩn ba tầng:

sg-alb:  inbound 443 từ 0.0.0.0/0
sg-app:  inbound 8080 từ sg-alb        ← không mở ra Internet
sg-db:   inbound 3306 từ sg-app        ← không mở ra Internet
        ↓
    Mỗi tầng chỉ nhận từ tầng ngay trên nó

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | Mặc định: chặn hết inbound, cho hết outbound | | | Chỉ có Allow, KHÔNG có Deny | | | Mọi quy tắc được hợp lại (OR) | |

⚠ Stateful nghĩa là gì:

Kết nối vào được → phản hồi ra TỰ ĐỘNG được
    → không cần quy tắc outbound cho phản hồi
        ↓
    NACL stateless thì phải mở CẢ hai chiều
    → và chiều ra phải mở dải cổng ephemeral 1024-65535

Bảng cổng phải thuộc: | Dịch vụ | Cổng | |---|---| | MySQL / MariaDB / Aurora MySQL | 3306 | | PostgreSQL | 5432 | | Microsoft SQL Server | 1433 | | Oracle | 1521 | | HTTP / HTTPS | 80 / 443 | | SSH / RDP | 22 / 3389 | | NFS (EFS) | 2049 | | Redis / Memcached | 6379 / 11211 |

⚠ Ba giới hạn cần biết: | Giới hạn | Con số mặc định | |---|---| | Security group mỗi ENI | 5 (tăng tới 16) | | Quy tắc mỗi security group | 60 inbound, 60 outbound | | Security group mỗi VPC | 2.500 |

⚠ Tham chiếu security group có giới hạn về phạm vi: | Trường hợp | Tham chiếu được | |---|---| | Cùng VPC | ✅ | | VPC peering CÙNG vùng | ✅ | | VPC peering KHÁC vùng | ❌ phải dùng CIDR |

Đây là chi tiết hay bị bỏ qua khi thiết kế đa vùng

Ba lưu ý về outbound: | Lưu ý | Chi tiết | |---|---| | Mặc định mở hết | | | Siết lại khi cần bảo mật cao | | | Nhớ mở 443 cho cập nhật và API AWS | |

Siết outbound của tầng ứng dụng:

aws ec2 revoke-security-group-egress --group-id sg-ungdung \
  --protocol -1 --port -1 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-egress --group-id sg-ungdung \
  --protocol tcp --port 3306 --source-group sg-csdl

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | tìm xem chặn ở đâu | | VPC Flow Logs | xem gói bị REJECT | | Network Access Analyzer | tìm đường đi ngoài ý muốn |

aws ec2 create-network-insights-path --source i-ungdung \
  --destination i-csdl --destination-port 3306 --protocol tcp

Ba lưu ý cho tầng CSDL: | Lưu ý | Chi tiết | |---|---| | Đặt ở subnet RIÊNG TƯ | | | Không gán IP công khai | | | Cân nhắc RDS thay vì tự quản trên EC2 | |

Ba lưu ý về RDS security group: | Lưu ý | Chi tiết | |---|---| | RDS cũng dùng security group như EC2 | | | --no-publicly-accessible | | | Bắt buộc TLS bằng parameter group | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử kết nối từ máy tầng ứng dụng | phải thành công | | Thử từ máy khác trong VPC | phải bị từ chối | | Chấm dứt một máy và tạo máy mới | vẫn kết nối được |

Và một lời khuyên: hãy dùng tham chiếu security group cho mọi kết nối giữa các tầng, không bao giờ dùng CIDR. Nó vừa chặt hơn vừa không cần bảo trì — và nó là lý do duy nhất khiến một kiến trúc có Auto Scaling không sinh ra một danh sách IP phải cập nhật liên tục.

Đáp án

B — Dựng một IPsec VPN và dùng cùng BGP prefix với Direct Connect.

Vì sao đúng

Đề nêu ba yêu cầu, và VPN dự phòng là lựa chọn duy nhất thoả hết: | Yêu cầu | Cách đáp ứng | |---|---| | Thêm khả năng phục hồi cho Direct Connect | đường thứ hai độc lập | | CHI PHÍ THẤP | VPN rẻ hơn DX nhiều lần | | NGẮN HẠN | VPN dựng trong vài giờ |

⚠ "Cùng BGP prefix" là chi tiết kỹ thuật quan trọng:

Cả DX và VPN quảng bá CÙNG dải mạng
    → AWS ưu tiên DX (đường có AS path ngắn hơn,
      hoặc theo thứ tự ưu tiên của AWS)
        ↓
    DX chết → BGP rút route → lưu lượng TỰ chuyển sang VPN
    → không cần can thiệp

Dựng VPN dự phòng:

aws ec2 create-customer-gateway --type ipsec.1 \
  --public-ip 203.0.113.10 --bgp-asn 65000

aws ec2 create-vpn-connection --type ipsec.1 \
  --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc \
  --options '{"StaticRoutesOnly":false}'

⚠ Thứ tự ưu tiên đường đi của AWS:

1. Route cụ thể hơn (longest prefix match)
2. Direct Connect
3. VPN
        ↓
    Cùng prefix → DX luôn được ưu tiên
    → VPN chỉ nhận lưu lượng khi DX chết

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dựng trong vài giờ | DX mất hàng tuần | | Chi phí thấp | ~0,05 USD/giờ | | Chuyển đổi tự động qua BGP | |

⚠ Và một đánh đổi phải biết:

VPN giới hạn ~1,25 Gbps mỗi tunnel
    → nếu DX là 10 Gbps thì khi chuyển sang VPN
      băng thông giảm rất nhiều
        ↓
    Chấp nhận được cho giải pháp NGẮN HẠN
    → dài hạn thì dựng DX thứ hai

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

• **A. Cấu hình IPsec VPN CHẠY TRÊN chính đường Direct Connect — đây là phương án gần nhất và là cách đúng để MÃ HOÁ lưu lượng DX, nhưng nó không tạo ra dự phòng nào: VPN đó chạy trên chính đường DX, cáp đứt thì cả hai cùng chết.
• **C. Dựng Direct Connect thứ hai — đây là giải pháp tốt nhất về lâu dài, nhưng đề nói rõ cần chi phí thấp và ngắn hạn. DX mất hàng tuần tới hàng tháng và có phí cổng riêng.
• **D. Cấu hình Transit Gateway với VPN dự phòng — Transit Gateway hữu ích khi có nhiều VPC, nhưng ở đây nó thêm một lớp và thêm chi phí mà không cần thiết cho việc chỉ dự phòng một kết nối.

Ghi nhớ

⚠ Ba mẫu dự phòng cho kết nối lai — bảng phải thuộc: | Mẫu | Chống được | Chi phí | |---|---|---| | DX + VPN dự phòng | hỏng DX | thấp nhất ← câu này | | DX ở hai location | hỏng cả một cơ sở | trung bình | | DX ở hai location, hai kết nối mỗi nơi | tối đa | cao |

⚠ Bốn mức phục hồi của Direct Connect: | Mức | Cấu hình | SLA | |---|---|---| | Development/Test | 1 kết nối, 1 location | không | | High Resiliency | 2 kết nối, 2 DX location | 99,9% | | Maximum Resiliency | 2 kết nối ở mỗi trong 2 location | 99,99% |

Từ khoá nhận diện:

"low-cost, short-term backup for DX" → VPN dự phòng cùng BGP prefix "encrypt DX traffic" → VPN chạy TRÊN DX (khác mục đích) "highest resiliency" → nhiều DX ở nhiều location "many VPCs share the DX" → Transit Gateway

⚠ Direct Connect KHÔNG mã hoá — nhắc lại:

DX là đường riêng, không qua Internet
    → nhưng dữ liệu KHÔNG được mã hoá
        ↓
    Muốn mã hoá: VPN IPsec chạy TRÊN DX (public VIF),
    hoặc MACsec (cổng chuyên dụng)

⚠ Hai mục đích khác nhau của "VPN over DX": | Mục đích | Cấu hình | |---|---| | MÃ HOÁ lưu lượng DX | VPN chạy TRÊN chính DX | | DỰ PHÒNG cho DX | VPN qua Internet, đường ĐỘC LẬP |

Phương án A là cái đầu, đề hỏi cái thứ hai

Ba thành phần của Site-to-Site VPN: | Thành phần | Ở đâu | |---|---| | Customer Gateway (CGW) | phía bạn | | Virtual Private Gateway hoặc Transit Gateway | phía AWS | | VPN Connection | hai tunnel IPsec |

⚠ Dự phòng phía AWS đã có sẵn:

Mỗi VPN connection có HAI tunnel ở hai AZ
    → AWS lo phần đó
        ↓
    Điểm hỏng còn lại là THIẾT BỊ CGW phía bạn
    → dùng hai thiết bị nếu cần dự phòng đầy đủ

Ba tham số BGP để điều khiển đường đi: | Tham số | Việc | |---|---| | AS path prepending | làm đường phụ "dài" hơn | | Local preference | ưu tiên đường ra | | BFD | phát hiện đường chết dưới 1 giây |

⚠ BFD là chi tiết đáng nhớ:

Không có BFD: BGP mất tới 90 giây mới nhận ra đường chết
Có BFD:       phát hiện dưới 1 giây
        ↓
    Với hạ tầng quan trọng, đây là khác biệt lớn

Ba loại VIF của Direct Connect: | Loại | Nối tới | |---|---| | Private VIF | VPC qua VGW | | Transit VIF | Transit Gateway (cần DX ≥ 1 Gbps) | | Public VIF | dịch vụ AWS công khai, và endpoint VPN |

Ba lưu ý về băng thông khi chuyển sang VPN: | Lưu ý | Chi tiết | |---|---| | Mỗi tunnel tối đa ~1,25 Gbps | | | VGW KHÔNG hỗ trợ ECMP | | | Transit Gateway hỗ trợ ECMP | gộp nhiều tunnel |

⚠ Muốn băng thông cao hơn khi chạy VPN:

Transit Gateway với ECMP
    → gộp nhiều tunnel song song
        ↓
    Đây là lý do duy nhất phương án D có giá trị
    → nhưng đề chỉ cần dự phòng ngắn hạn, chi phí thấp

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | VPN: ~0,05 USD/giờ mỗi connection | | | Cộng phí truyền dữ liệu ra | | | DX: phí cổng theo giờ + phí chéo nhà mạng | |

Ba lưu ý về kiểm chứng dự phòng: | Việc | Cách | |---|---| | Kiểm tra cả hai tunnel VPN UP | | | Dùng DX failover testing | AWS chủ động ngắt để thử | | Đo thời gian chuyển đường | |

aws directconnect start-bgp-failover-test \
  --virtual-interface-id dxvif-abc --test-duration-in-minutes 30

⚠ Failover testing là tính năng đáng dùng:

AWS tạm ngắt BGP session của một VIF
    → xem lưu lượng có tự chuyển sang VPN không
        ↓
    Thử trong cửa sổ bảo trì, không phải chờ sự cố thật

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TunnelState của VPN | UP hay DOWN | | ConnectionState của DX | | | TunnelDataIn/Out | đường dự phòng có chở lưu lượng không |

⚠ Metric thứ ba đáng chú ý:

Đường dự phòng CHƯA BAO GIỜ chở lưu lượng
    → là đường CHƯA ĐƯỢC KIỂM CHỨNG
        ↓
    Chủ động chuyển qua lại định kỳ

Ba lưu ý về CIDR: | Lưu ý | Chi tiết | |---|---| | Cả DX và VPN quảng bá cùng prefix | | | CIDR tại chỗ không trùng CIDR VPC | | | Bật route propagation trên route table | |

Và một lời khuyên: hãy dùng tính năng BGP failover testing của Direct Connect để kiểm chứng đường VPN dự phòng. Một đường dự phòng đã cấu hình nhưng chưa từng chở lưu lượng thật là một giả thuyết — và ngày nó được kiểm chứng lần đầu không nên là ngày cáp DX bị đứt.

Đáp án

C — Tạo một CloudWatch Events rule (EventBridge) kích hoạt một SNS topic.

Vì sao đúng

Đề nêu hai yêu cầu, và cặp EventBridge + SNS là cơ chế chuẩn: | Yêu cầu | Cách đáp ứng | |---|---| | GuardDuty phát hiện sự kiện | GuardDuty tự gửi finding vào EventBridge | | Thông báo qua EMAIL cho mức trung bình tới cao | rule lọc theo severity → SNS gửi email |

⚠ GuardDuty tích hợp sẵn với EventBridge:

Mỗi finding của GuardDuty tự động thành một sự kiện EventBridge
    → không cần viết mã lấy finding
        ↓
    Chỉ cần tạo rule lọc và gắn đích

Tạo rule lọc theo severity:

aws events put-rule --name guardduty-nghiem-trong \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {"severity": [{"numeric": [">=", 4]}]}}'

aws events put-targets --rule guardduty-nghiem-trong \
  --targets '[{"Id":"1","Arn":"arn:aws:sns:ap-southeast-1:123456789012:canh-bao-bao-mat"}]'

⚠ Thang severity của GuardDuty: | Mức | Điểm | |---|---| | Low | 1,0 - 3,9 | | Medium | 4,0 - 6,9 | | High | 7,0 - 8,9 | | Critical | 9,0 - 10,0 |

"Medium to high" → lọc severity >= 4

Đăng ký email vào SNS:

aws sns create-topic --name canh-bao-bao-mat

aws sns subscribe --topic-arn <arn-topic> \
  --protocol email --notification-endpoint bao-mat@vidu.com

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không viết mã nào | | | Lọc chính xác theo mức nghiêm trọng | | | Thêm người nhận chỉ là một subscription | |

⚠ Và có thể làm đẹp nội dung email bằng input transformer:

{"InputPathsMap": {
   "severity": "$.detail.severity",
   "type": "$.detail.type",
   "account": "$.detail.accountId"},
 "InputTemplate": "\"GuardDuty: <type> (muc do <severity>) o tai khoan <account>\""}

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

• **A. Cấu hình CloudWatch alarm dựa trên metric của GuardDuty — đây là phương án gần nhất vì CloudWatch alarm cũng gửi được SNS, nhưng GuardDuty không phát hành metric theo severity để đặt alarm. Finding của nó là sự kiện, không phải chuỗi số liệu.
• **B. Tạo CloudWatch Logs rule kích hoạt Lambda — GuardDuty không ghi finding vào CloudWatch Logs mặc định. Và dùng Lambda là công thừa khi SNS gửi email trực tiếp được.
• **D. Cấu hình CloudTrail alarm dựa trên hoạt động API của GuardDuty — CloudTrail ghi lời gọi API quản trị (ai bật/tắt GuardDuty), không ghi các finding mà GuardDuty phát hiện.

Ghi nhớ

⚠ Ba dịch vụ định tuyến sự kiện — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Amazon EventBridge (CloudWatch Events) | định tuyến SỰ KIỆN theo mẫu | | CloudWatch Alarms | theo dõi METRIC vượt ngưỡng | | CloudWatch Logs | tìm kiếm nội dung LOG |

⚠ Ba loại dữ liệu quan sát — phân biệt:

Sự kiện (event): GuardDuty finding, thay đổi trạng thái EC2
    → EventBridge

Số liệu (metric): CPU, số request
    → CloudWatch Alarms

Log: dòng văn bản ứng dụng ghi ra
    → CloudWatch Logs Insights

Từ khoá nhận diện:

"notify on GuardDuty findings" → EventBridge rule + SNS "CPU exceeds 80%" → CloudWatch alarm "search log content" → Logs Insights "who called an API" → CloudTrail

Ba dịch vụ bảo mật hay đi cùng: | Dịch vụ | Việc | |---|---| | Amazon GuardDuty | PHÁT HIỆN mối đe doạ | | AWS Security Hub | TỔNG HỢP finding, chấm điểm tuân thủ | | Amazon Detective | ĐIỀU TRA nguyên nhân gốc |

⚠ Security Hub là cách gọn hơn khi có nhiều nguồn:

GuardDuty, Inspector, Macie, Config
    → tất cả gửi finding vào Security Hub
        ↓
    Một EventBridge rule trên Security Hub
    → thay vì mỗi dịch vụ một rule

aws events put-rule --name security-hub-nghiem-trong \
  --event-pattern '{
    "source": ["aws.securityhub"],
    "detail-type": ["Security Hub Findings - Imported"],
    "detail": {"findings": {"Severity": {"Label": ["HIGH","CRITICAL"]}}}}'

Ba nguồn dữ liệu của GuardDuty: | Nguồn | Phát hiện | |---|---| | CloudTrail event | hành vi API bất thường | | VPC Flow Logs | lưu lượng tới IP xấu | | DNS logs | truy vấn tên miền độc hại | | S3 data events, EKS audit, RDS login (tuỳ chọn) | |

Ba loại finding phổ biến: | Loại | Ý nghĩa | |---|---| | UnauthorizedAccess:EC2/SSHBruteForce | dò mật khẩu SSH | | CryptoCurrency:EC2/BitcoinTool.B | máy bị chiếm để đào coin | | Recon:EC2/PortProbeUnprotectedPort | quét cổng |

⚠ Ba lưu ý về mẫu sự kiện EventBridge: | Lưu ý | Chi tiết | |---|---| | source và detail-type là bắt buộc | | | Toán tử numeric để lọc theo số | | | Thử bằng test-event-pattern | |

aws events test-event-pattern \
  --event-pattern file://mau.json --event file://su-kien-mau.json

Sáu giao thức SNS hỗ trợ: | Giao thức | Dùng cho | |---|---| | Email / Email-JSON | ← câu này | | SQS | hệ thống khác xử lý | | Lambda | tự động phản ứng | | HTTPS, SMS | |

⚠ Ba đích EventBridge hữu ích cho bảo mật: | Đích | Việc | |---|---| | SNS | thông báo người | | Lambda | tự động khắc phục | | Systems Manager Automation | chạy runbook | | Step Functions | quy trình nhiều bước |

Tự động khắc phục — ví dụ cô lập instance bị nhiễm:

def handler(event, context):
    ma_may = event['detail']['resource']['instanceDetails']['instanceId']
    ec2 = boto3.client('ec2')
    ec2.modify_instance_attribute(
        InstanceId=ma_may, Groups=['sg-co-lap'])

Ba lưu ý về triển khai đa tài khoản: | Lưu ý | Chi tiết | |---|---| | Uỷ quyền quản trị GuardDuty cho tài khoản bảo mật | | | Bật tự động cho tài khoản mới | | | Gom finding về một nơi | |

aws guardduty enable-organization-admin-account \
  --admin-account-id 444455556666

Ba lưu ý về chi phí GuardDuty: | Khoản | Chi tiết | |---|---| | Tính theo lượng CloudTrail event phân tích | | | Cộng lượng VPC Flow Logs và DNS log | | | Nguồn tuỳ chọn (S3, EKS, Malware) tính riêng | |

Ba lưu ý về email từ SNS: | Lưu ý | Chi tiết | |---|---| | Người nhận phải XÁC NHẬN đăng ký | | | 1.000 thư đầu miễn phí mỗi tháng | | | Cân nhắc gửi vào Slack hoặc hệ thống ticket | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo finding mẫu | create-sample-findings | | Kiểm tra email nhận được | | | Xác nhận finding mức thấp KHÔNG gửi | |

aws guardduty create-sample-findings --detector-id <id> \
  --finding-types "UnauthorizedAccess:EC2/SSHBruteForce"

Và một lời khuyên: hãy dùng create-sample-findings để kiểm chứng toàn bộ chuỗi cảnh báo ngay sau khi cấu hình. Đó là cách duy nhất biết rằng email thật sự tới nơi mà không phải chờ một sự cố bảo mật thật để phát hiện ra rule lọc sai.

Đáp án

D và E.

• D — Copy một AMI của EC2 instance và chỉ định vùng thứ hai làm đích
• E — Khởi chạy EC2 instance mới từ AMI đó ở vùng thứ hai

Vì sao đúng

Đề hỏi cách chuẩn bị để triển khai lại tài nguyên ở vùng thứ hai, và AMI là cơ chế đúng: | Bước | Việc | |---|---| | D: copy AMI sang vùng thứ hai | chuẩn bị "khuôn" máy ở vùng DR | | E: khởi chạy instance từ AMI đó | dựng lại khi cần |

⚠ AMI là gói đầy đủ để tái tạo một instance:

AMI gồm:
    → snapshot của ổ gốc (hệ điều hành, ứng dụng, cấu hình)
    → block device mapping
    → quyền khởi chạy
        ↓
    Copy AMI sang vùng khác = có đủ để dựng lại máy y hệt

Copy AMI:

aws ec2 copy-image --source-region ap-southeast-1 \
  --source-image-id ami-abc123 \
  --name "ung-dung-dr" --region us-west-2 \
  --encrypted --kms-key-id <arn-khoa-us-west-2>

Khởi chạy ở vùng đích:

aws ec2 run-instances --region us-west-2 \
  --image-id ami-moi-o-us-west-2 --instance-type m6i.large \
  --subnet-id subnet-dr --security-group-ids sg-dr

⚠ Vì sao ba phương án kia đều sai về mặt kỹ thuật:

"Copy an EBS volume TO/FROM Amazon S3"
    → KHÔNG có thao tác nào như vậy
        ↓
    EBS snapshot ĐƯỢC LƯU trong S3 do AWS quản lý,
    nhưng bạn KHÔNG truy cập chúng như object S3
    → không copy volume vào bucket của mình được

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

Cách đúng để chuyển EBS sang vùng khác:

aws ec2 create-snapshot --volume-id vol-abc --description "Snapshot DR"

aws ec2 copy-snapshot --source-region ap-southeast-1 \
  --source-snapshot-id snap-abc --region us-west-2 \
  --encrypted --kms-key-id <arn-khoa>

Ba lợi ích của cách dùng AMI: | Lợi ích | Chi tiết | |---|---| | Giữ nguyên toàn bộ môi trường | không phải cài lại | | Copy tự động hoá được | | | Dùng ngay trong launch template của ASG | |

⚠ Và nên tự động hoá việc copy AMI:

aws dlm create-lifecycle-policy \
  --description "Copy AMI sang vung DR" \
  --state ENABLED --execution-role-arn <arn-role> \
  --policy-details '{
    "PolicyType":"IMAGE_MANAGEMENT",
    "ResourceTypes":["INSTANCE"],
    "TargetTags":[{"Key":"dr","Value":"co"}],
    "Schedules":[{"Name":"hang-ngay",
      "CreateRule":{"Interval":24,"IntervalUnit":"HOURS"},
      "RetainRule":{"Count":7},
      "CrossRegionCopyRules":[{"TargetRegion":"us-west-2",
        "Encrypted":true,"RetainRule":{"Interval":7,"IntervalUnit":"DAYS"}}]}]}'

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

• **C. Copy một EBS volume TỪ S3 và khởi chạy EC2 ở vùng thứ hai bằng volume đó — đây là phương án gần nhất vì có nhắc tới EBS volume và vùng thứ hai, nhưng không có thao tác "copy volume từ S3": EBS snapshot lưu trong S3 do AWS quản lý, không phải bucket của bạn.
• **B. Gỡ một volume và copy nó vào S3 bucket ở vùng thứ hai — cùng lý do: không có API nào copy EBS volume vào một bucket.
• **A. Khởi chạy EC2 mới ở vùng thứ hai và copy volume từ S3 sang máy đó — cùng lỗi khái niệm.

Ghi nhớ

⚠ Ba cách chuyển tài nguyên EC2 sang vùng khác — bảng phải thuộc: | Cách | Việc | |---|---| | Copy AMI | toàn bộ máy (OS + ứng dụng + cấu hình) | | Copy EBS snapshot | một volume dữ liệu | | AWS Backup cross-Region copy | tự động hoá cả hai |

⚠ Quan hệ giữa AMI, snapshot và S3:

AMI  → trỏ tới một hoặc nhiều EBS SNAPSHOT
Snapshot → lưu trong S3 DO AWS QUẢN LÝ
        ↓
    Bạn KHÔNG thấy chúng trong bucket của mình
    → không copy bằng lệnh s3 được

Từ khoá nhận diện:

"deploy resources to a second Region" → copy AMI + launch "copy volume to S3" → luôn sai "automate cross-Region backup" → AWS Backup "replicate running instances continuously" → AWS Elastic Disaster Recovery (DRS)

⚠ Ba lưu ý khi copy AMI sang vùng khác: | Lưu ý | Chi tiết | |---|---| | AMI mới có ID KHÁC ở vùng đích | | | Snapshot mã hoá cần khoá KMS Ở VÙNG ĐÍCH | | | Copy AMI chưa mã hoá có thể mã hoá luôn | |

Launch template ở vùng DR phải trỏ tới AMI ID của VÙNG ĐÓ
    → không dùng chung ID được
        ↓
    Đây là lý do phải tự động hoá việc cập nhật

Ba thứ khác cần chuẩn bị ở vùng DR: | Thứ | Vì sao | |---|---| | VPC, subnet, security group | AMI không mang theo mạng | | Chứng chỉ ACM | ACM theo vùng | | Hạn ngạch tài khoản | vùng chưa dùng thường quota thấp |

⚠ Ba dịch vụ nhân bản cho DR: | Dịch vụ | Việc | |---|---| | AWS Backup | sao lưu và copy xuyên vùng theo lịch | | AWS Elastic Disaster Recovery (DRS) | nhân bản LIÊN TỤC, RPO giây | | Data Lifecycle Manager | snapshot và AMI theo lịch |

⚠ DRS cho RPO thấp nhất:

AWS Backup: sao lưu theo lịch → RPO là khoảng cách giữa hai lần
DRS:        nhân bản liên tục  → RPO tính bằng giây
        ↓
    Nhưng DRS đắt hơn và phức tạp hơn

Bốn chiến lược DR: | Chiến lược | RTO | RPO | |---|---|---| | Backup & Restore | giờ - ngày | giờ | | Pilot Light | chục phút | phút - giây | | Warm Standby | phút | giây | | Multi-Site Active-Active | gần 0 | gần 0 |

Copy AMI + khởi chạy khi cần = Backup & Restore
    → RTO tính bằng chục phút tới giờ

Ba lưu ý về AWS Backup: | Lưu ý | Chi tiết | |---|---| | Quản lý tập trung nhiều dịch vụ | EC2, EBS, RDS, EFS, DynamoDB | | Copy xuyên vùng và xuyên tài khoản | | | Vault Lock cho bản sao lưu bất biến | |

aws backup put-backup-plan --backup-plan '{
  "BackupPlanName":"ke-hoach-dr",
  "Rules":[{"RuleName":"hang-ngay",
    "TargetBackupVaultName":"Default",
    "ScheduleExpression":"cron(0 2 * * ? *)",
    "Lifecycle":{"DeleteAfterDays":30},
    "CopyActions":[{"DestinationBackupVaultArn":
      "arn:aws:backup:us-west-2:123456789012:backup-vault:Default",
      "Lifecycle":{"DeleteAfterDays":30}}]}]}'

Ba lưu ý về dữ liệu: | Lưu ý | Chi tiết | |---|---| | AMI chỉ có dữ liệu tại thời điểm chụp | | | CSDL cần cơ chế sao chép riêng | RDS cross-region replica | | S3 dùng Cross-Region Replication | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Snapshot ở vùng đích tính phí lưu trữ | | | Phí truyền dữ liệu giữa vùng khi copy | | | Đặt retention để không tích tụ | |

Ba việc phải làm định kỳ: | Việc | Tần suất | |---|---| | Copy AMI mới sau mỗi lần phát hành | | | Diễn tập khởi chạy từ AMI ở vùng DR | ít nhất 2 lần/năm | | Kiểm tra hạn ngạch vùng DR | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khởi chạy thử một instance từ AMI đã copy | | | Kiểm tra ứng dụng chạy được | | | Đo thời gian từ lúc quyết định tới lúc phục vụ | |

Và một lời khuyên: hãy tự động hoá việc copy AMI bằng Data Lifecycle Manager hoặc AWS Backup. Một AMI copy thủ công sẽ nhanh chóng lỗi thời so với bản đang chạy — và trong một sự cố thật, khởi chạy từ AMI của sáu tháng trước còn tệ hơn là không có gì, vì bạn sẽ mất thời gian tìm hiểu vì sao ứng dụng không chạy.

Đáp án

A — Tạo một read replica dưới dạng Multi-AZ DB instance.

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ phương án này thoả cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Mở rộng hiệu năng ĐỌC | read replica phục vụ truy vấn đọc | | Giải pháp phải có TÍNH SẴN SÀNG CAO | chính replica đó cũng Multi-AZ |

⚠ Điểm mấu chốt: read replica có thể TỰ NÓ là Multi-AZ:

Read replica thường: một instance ở một AZ
    → AZ đó hỏng → mất luôn khả năng đọc
        ↓
Read replica Multi-AZ: replica có standby riêng
    → AZ hỏng → replica tự chuyển đổi
    → khả năng đọc vẫn còn

Tạo replica Multi-AZ:

aws rds create-db-instance-read-replica \
  --db-instance-identifier replica-doc \
  --source-db-instance-identifier csdl-chinh \
  --db-instance-class db.m6g.large \
  --multi-az

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

AZ-a: master ──sync──▶ AZ-b: standby của master
  │
  └─async──▶ AZ-a: replica ──sync──▶ AZ-b: standby của replica
        ↓
    Cả tầng ghi lẫn tầng đọc đều chịu được mất một AZ

Vì sao đây là "cost-effective" nhất trong bốn phương án:

Một replica Multi-AZ = 2 instance
    → đủ để vừa mở rộng đọc vừa sẵn sàng cao
        ↓
    Hai replica thường ở hai AZ cũng là 2 instance
    → nhưng phải tự lo chuyển đổi khi một cái chết

Ứng dụng trỏ đọc vào replica:

ket_noi_ghi = psycopg2.connect(host=ENDPOINT_MASTER, ...)
ket_noi_doc = psycopg2.connect(host=ENDPOINT_REPLICA, ...)

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tách tải đọc khỏi tải ghi | | | Replica tự chuyển đổi khi AZ hỏng | | | Master vẫn Multi-AZ độc lập | |

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

• **B. Triển khai read replica ở AZ KHÁC với master — đây là phương án gần nhất vì đặt replica ở AZ khác thật sự tốt hơn cùng AZ, nhưng bản thân replica đó không có tính sẵn sàng cao: AZ chứa nó hỏng là mất khả năng đọc, và phải dựng lại bằng tay.
• **D. Triển khai read replica CÙNG AZ với master — tệ hơn nữa: mất một AZ là mất cả master lẫn replica (dù master còn standby ở AZ khác, replica thì mất hẳn).
• **C. Triển khai "read replica bằng ElastiCache" — nhầm khái niệm: ElastiCache là bộ nhớ đệm, không phải read replica. Nó giảm số truy vấn nhưng không phải bản sao của CSDL.

Ghi nhớ

⚠ Read Replica và Multi-AZ — bảng phải thuộc: | | Read Replica | Multi-AZ | |---|---|---| | Mục đích | hiệu năng ĐỌC | tính SẴN SÀNG | | Sao chép | bất đồng bộ | đồng bộ | | Phục vụ đọc | ✅ | ❌ standby nằm chờ | | Chuyển đổi | thủ công (promote) | tự động | | Vị trí | cùng vùng hoặc vùng khác | AZ khác cùng vùng |

⚠ Và chúng KẾT HỢP được — đó là điểm của câu này:

Một read replica có thể tự nó là Multi-AZ
    → vừa mở rộng đọc vừa sẵn sàng cao
        ↓
    Đây là tính năng nhiều người không biết

Từ khoá nhận diện:

"scale read performance" + "highly available" → read replica Multi-AZ "scale reads" (không nói HA) → read replica thường "high availability" (không nói đọc) → Multi-AZ "same query repeated" → ElastiCache

⚠ Ba lựa chọn giảm tải đọc — phân biệt: | Cách | Giảm gì | |---|---| | Read replica | phân tán truy vấn sang máy khác | | ElastiCache | SỐ LƯỢNG truy vấn | | RDS Proxy | số kết nối |

Ba đặc điểm của read replica: | Đặc điểm | Chi tiết | |---|---| | Tối đa 5 replica (RDS), 15 (Aurora) | | | Có replica lag | dữ liệu trễ vài giây | | Promote thành CSDL độc lập được | |

⚠ Replica lag là điều phải nói rõ với ứng dụng:

Sao chép BẤT ĐỒNG BỘ
    → ghi vào master, đọc ngay từ replica
    → có thể chưa thấy dữ liệu vừa ghi
        ↓
    Thao tác cần đọc-sau-ghi: đọc từ master

Ba nguyên nhân replica lag cao: | Nguyên nhân | Chi tiết | |---|---| | Ghi nhiều ở master | | | Replica cấu hình yếu hơn | | | Truy vấn dài chặn việc áp thay đổi | PostgreSQL |

Điều chỉnh cho PostgreSQL:

max_standby_streaming_delay = 30s
hot_standby_feedback = on

⚠ Aurora khác RDS ở điểm căn bản: | | Aurora | RDS | |---|---|---| | Cơ chế replica | chia sẻ tầng lưu trữ | binlog | | Độ trễ | < 100 ms | giây | | Dung lượng thêm | không | nhân đôi | | Multi-AZ | replica ĐỌC ĐƯỢC | standby KHÔNG đọc được |

Với Aurora Multi-AZ, replica đã sẵn sàng để đọc
    → không cần tạo thêm gì

Ba lưu ý về Multi-AZ DB cluster (RDS): | Lưu ý | Chi tiết | |---|---| | Ba instance: 1 writer + 2 reader | | | Hai reader ĐỌC ĐƯỢC | khác Multi-AZ instance | | Chuyển đổi dưới 35 giây | |

aws rds create-db-cluster --db-cluster-identifier cum-multi-az \
  --engine postgres --db-cluster-instance-class db.m6gd.large \
  --storage-type io1 --allocated-storage 100 --iops 3000

⚠ Đây là lựa chọn hiện đại đáng cân nhắc:

Multi-AZ DB cluster cho RDS
    → vừa sẵn sàng cao vừa có 2 bản đọc được
    → chuyển đổi nhanh hơn Multi-AZ instance
        ↓
    Nhưng chỉ hỗ trợ MySQL và PostgreSQL

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Replica tính phí instance đầy đủ | | | Multi-AZ nhân đôi phí instance | | | Replica Multi-AZ = 2 instance | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicaLag | độ trễ dữ liệu | | CPUUtilization của replica | có đủ sức không | | DatabaseConnections | |

Ba lưu ý khi chuyển ứng dụng sang dùng replica: | Lưu ý | Chi tiết | |---|---| | Tách rõ đường ghi và đường đọc | | | Đặt statement_timeout cho tài khoản đọc | | | Ghi tài liệu về replica lag | |

Ba lưu ý về promote: | Lưu ý | Chi tiết | |---|---| | Promote biến replica thành CSDL ĐỘC LẬP | | | Không quay lại làm replica được | | | Dùng cho DR hoặc tách môi trường | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra tải đọc đã chuyển sang replica | | | Ép failover replica | reboot-db-instance --force-failover | | Đo replica lag dưới tải thật | |

Và một lời khuyên: hãy kiểm tra xem CSDL của bạn có dùng được Multi-AZ DB cluster không trước khi chọn replica Multi-AZ. Với MySQL và PostgreSQL, cụm ba node cho hai bản đọc được và thời gian chuyển đổi nhanh hơn — thường là lựa chọn tốt hơn với chi phí tương đương.

Đáp án

A — Dùng AWS License Manager để quản lý giấy phép phần mềm.

Vì sao đúng

Đề nêu ba yêu cầu, và License Manager là dịch vụ được thiết kế chính xác cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Đang gặp khó khi QUẢN LÝ GIẤY PHÉP phần mềm | License Manager theo dõi việc sử dụng | | Muốn thấy toàn cảnh hạ tầng tại chỗ | tích hợp với Systems Manager phát hiện máy chủ | | Duy trì mô hình LAI — giấy phép ở cả hai nơi | quản lý cả AWS lẫn tại chỗ |

⚠ License Manager giải quyết vấn đề gì:

Giấy phép thương mại thường tính theo:
    → số core vật lý, số socket, số vCPU, số máy chủ
        ↓
    Vượt số đã mua → vi phạm hợp đồng, phạt nặng
    → License Manager THEO DÕI và CHẶN trước khi vượt

Tạo license configuration:

aws license-manager create-license-configuration \
  --name "SQL-Server-Enterprise" \
  --license-counting-type Core \
  --license-count 128 \
  --license-count-hard-limit \
  --license-rules "#minimumCores=4,#maximumCores=64"

⚠ --license-count-hard-limit là tính năng quan trọng nhất:

Bật hard limit
    → AWS TỪ CHỐI khởi chạy instance khi vượt số giấy phép
        ↓
    Ngăn vi phạm TRƯỚC khi xảy ra
    → thay vì phát hiện khi bị kiểm toán

Ba kiểu đếm giấy phép: | Kiểu | Đếm theo | |---|---| | vCPU | số vCPU | | Core | số core vật lý | | Socket | số socket | | Instance | số máy |

Gắn vào AMI hoặc launch template:

aws license-manager update-license-specifications-for-resource \
  --resource-arn arn:aws:ec2:ap-southeast-1::image/ami-abc \
  --add-license-specifications \
    LicenseConfigurationArn=<arn-cau-hinh>

⚠ Phát hiện máy chủ tại chỗ qua Systems Manager:

Cài SSM Agent trên máy tại chỗ (hybrid activation)
    → License Manager thấy được chúng
        ↓
    Theo dõi giấy phép ở CẢ HAI môi trường
    → đúng yêu cầu "hybrid cloud setup"

aws ssm create-activation --iam-role SSMServiceRole \
  --registration-limit 100 --default-instance-name may-chu-tai-cho

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bảng điều khiển tập trung cho mọi giấy phép | | | Cảnh báo khi sắp vượt | | | Chặn khởi chạy khi vượt hạn mức | |

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

• **C. Dùng AWS Secrets Manager lưu giấy phép dưới dạng secret — đây là phương án gần nhất vì cũng là nơi lưu trữ an toàn, nhưng nó chỉ CẤT khoá giấy phép. Nó không theo dõi việc sử dụng, không đếm core, không chặn khi vượt hạn mức — đó mới là vấn đề đề nêu.
• **B. Dùng AWS KMS giữ khoá giấy phép an toàn — KMS quản lý khoá mã hoá, không lưu trữ dữ liệu và không liên quan tới giấy phép phần mềm.
• **D. Dùng S3 với governance lock — S3 là kho lưu trữ tệp; Object Lock ngăn xoá nhưng không quản lý việc sử dụng giấy phép.

Ghi nhớ

⚠ Ba dịch vụ dễ lẫn với "license" — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS License Manager | THEO DÕI và THỰC THI giấy phép phần mềm | | AWS Secrets Manager | lưu bí mật (mật khẩu, khoá API) | | AWS KMS | quản lý khoá mã hoá |

Từ khoá nhận diện:

"manage software licenses", "license compliance", "BYOL" → License Manager "store credentials securely, rotate" → Secrets Manager "encryption keys" → KMS "inventory of on-premises servers" → Systems Manager / Migration Hub

⚠ Ba trường hợp dùng License Manager: | Trường hợp | Chi tiết | |---|---| | BYOL (Bring Your Own License) | Windows, SQL Server, Oracle, SAP | | Theo dõi tuân thủ giấy phép | tránh phạt khi kiểm toán | | Quản lý giấy phép trong môi trường lai | ← câu này |

⚠ Ba mô hình giấy phép trên AWS: | Mô hình | Chi tiết | |---|---| | License Included | giá instance đã gồm giấy phép | | BYOL | mang giấy phép của mình | | License Manager + Dedicated Host | cho giấy phép tính theo core vật lý |

⚠ Dedicated Host là bắt buộc với một số giấy phép:

Giấy phép tính theo SOCKET hoặc CORE VẬT LÝ
    → cần thấy được phần cứng bên dưới
        ↓
    Dedicated Host cho bạn cả máy chủ vật lý
    → và License Manager theo dõi việc gán host

aws license-manager create-license-configuration \
  --name "Oracle-DB" --license-counting-type Socket \
  --license-count 4 \
  --license-rules "#allowedTenancy=EC2-DedicatedHost"

Ba tính năng chính của License Manager: | Tính năng | Việc | |---|---| | License configuration | định nghĩa quy tắc và hạn mức | | Tự động phát hiện | qua Systems Manager Inventory | | Báo cáo và cảnh báo | |

Ba nguồn License Manager theo dõi: | Nguồn | Chi tiết | |---|---| | EC2 instance | qua AMI hoặc launch template | | Máy chủ tại chỗ | qua SSM hybrid activation | | AWS Marketplace | giấy phép mua trên Marketplace |

⚠ Ba lưu ý về Systems Manager hybrid: | Lưu ý | Chi tiết | |---|---| | Cài SSM Agent trên máy tại chỗ | | | Tạo hybrid activation lấy mã đăng ký | | | Máy tại chỗ hiện với tiền tố mi- | |

# Trên máy tại chỗ
sudo amazon-ssm-agent -register \
  -code "<activation-code>" -id "<activation-id>" -region ap-southeast-1

Ba dịch vụ hỗ trợ khảo sát hạ tầng tại chỗ: | Dịch vụ | Việc | |---|---| | AWS Application Discovery Service | khảo sát máy chủ và phụ thuộc | | AWS Migration Hub | theo dõi tiến độ di chuyển | | Systems Manager Inventory | kiểm kê phần mềm đã cài |

⚠ Application Discovery Service đáng biết:

Đề nói "gain insight into their total on-premises footprint"
    → đó là việc của Application Discovery Service
        ↓
    Nhưng câu hỏi tập trung vào QUẢN LÝ GIẤY PHÉP
    → License Manager là đáp án

Ba lưu ý về thực thi hạn mức: | Lưu ý | Chi tiết | |---|---| | Hard limit CHẶN khởi chạy khi vượt | | | Soft limit chỉ cảnh báo | | | Thử ở môi trường dev trước | |

⚠ Hard limit có thể gây sự cố nếu đặt sai:

Đặt hard limit thấp hơn nhu cầu thật
    → Auto Scaling không khởi động được máy mới
    → ứng dụng thiếu năng lực
        ↓
    Bắt đầu bằng soft limit, quan sát rồi mới siết

Ba lưu ý về báo cáo: | Lưu ý | Chi tiết | |---|---| | Tạo báo cáo tuân thủ định kỳ | | | Xuất ra S3 để lưu trữ | | | Dùng khi bị nhà cung cấp kiểm toán | |

aws license-manager create-license-manager-report-generator \
  --report-generator-name bao-cao-thang \
  --type LicenseConfigurationSummaryReport \
  --report-context licenseConfigurationArns=<arn> \
  --report-frequency period=MONTH,value=1 \
  --client-token $(uuidgen)

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | License Manager KHÔNG tính phí | | | Chỉ trả cho tài nguyên bên dưới | | | Dedicated Host đắt hơn instance thường | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra máy tại chỗ đã hiện trong danh sách | | | Thử khởi chạy vượt hạn mức | phải bị từ chối | | Xem báo cáo tuân thủ | |

Và một lời khuyên: hãy bắt đầu bằng soft limit và quan sát ít nhất một tháng trước khi bật hard limit. Số giấy phép thực sự đang dùng thường khác xa con số trên giấy tờ — và bật chặn cứng trước khi biết con số thật là cách nhanh nhất để chặn đứng một quy trình Auto Scaling đang chạy tốt.

Đáp án

A — Amazon S3 Standard.

Vì sao đúng

Đề nêu ba dữ kiện, và S3 Standard là lựa chọn rẻ nhất cho tình huống này: | Dữ kiện | Ý nghĩa | |---|---| | Chạy job phân tích MỖI NGÀY trên log | dữ liệu được ĐỌC thường xuyên | | Kích thước và số lượng KHÔNG BIẾT | | | **Dữ liệu chỉ tồn tại 24 GIỜ | vòng đời rất ngắn |

⚠ "24 giờ" là con số quyết định:

Mọi lớp IA và Glacier đều có THỜI GIAN LƯU TỐI THIỂU:
    → Standard-IA, One Zone-IA: 30 ngày
    → Glacier: 90 ngày
    → Deep Archive: 180 ngày
        ↓
    Xoá sau 24 giờ vẫn bị tính đủ thời gian tối thiểu
    → trả tiền 30 ngày cho dữ liệu sống 1 ngày

Tính thử với Standard-IA:

Dữ liệu sống 1 ngày nhưng bị tính 30 ngày
    → đắt gấp 30 lần so với thời gian thật
        ↓
    Dù giá mỗi GB-tháng thấp hơn Standard ~45%,
    tổng chi phí vẫn cao hơn nhiều

⚠ Và S3 Standard không có phí lấy dữ liệu:

Job phân tích chạy mỗi ngày → đọc toàn bộ log
    → Standard-IA tính phí lấy dữ liệu mỗi GB
        ↓
    Đọc thường xuyên + lớp IA = cộng thêm chi phí

Cấu hình lifecycle xoá sau 1 ngày:

{"Rules": [{
  "ID": "xoa-log-sau-1-ngay",
  "Status": "Enabled",
  "Filter": {},
  "Expiration": {"Days": 1},
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 1}}]}

Ba lợi ích của S3 Standard ở đây: | Lợi ích | Chi tiết | |---|---| | KHÔNG có thời gian lưu tối thiểu | | | KHÔNG có phí lấy dữ liệu | | | Truy cập tức thì cho job phân tích | |

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

• **C. S3 Intelligent-Tiering — đây là phương án gần nhất vì cũng không có phí lấy dữ liệu và không có thời gian lưu tối thiểu, nhưng nó có phí GIÁM SÁT mỗi object mỗi tháng. Với dữ liệu chỉ sống 24 giờ, object không bao giờ kịp chuyển sang tầng rẻ hơn (cần 30 ngày) — nên bạn trả thêm phí giám sát mà không được lợi ích nào.
• **D. S3 One Zone-IA — có thời gian lưu tối thiểu 30 ngày và phí lấy dữ liệu. Rẻ hơn về giá mỗi GB nhưng đắt hơn nhiều về tổng chi phí với vòng đời 1 ngày.
• **B. S3 Glacier Deep Archive — thời gian lưu tối thiểu 180 ngày và cần 12-48 giờ để khôi phục. Hoàn toàn không dùng được cho job chạy hằng ngày.

Ghi nhớ

⚠ Bảng thời gian lưu tối thiểu — phải thuộc: | Lớp | Lưu tối thiểu | Phí lấy dữ liệu | |---|---|---| | Standard | KHÔNG | KHÔNG | | Intelligent-Tiering | KHÔNG | KHÔNG (có phí giám sát) | | Standard-IA | 30 ngày | có | | One Zone-IA | 30 ngày | có | | Glacier Instant Retrieval | 90 ngày | có | | Glacier Flexible Retrieval | 90 ngày | có | | Deep Archive | 180 ngày | có |

⚠ Quy tắc chọn lớp theo vòng đời:

Dữ liệu sống DƯỚI 30 ngày  → S3 Standard (không có lựa chọn nào rẻ hơn)
Sống 30-90 ngày, ít đọc     → Standard-IA
Sống trên 90 ngày, hiếm đọc → Glacier
Sống nhiều năm, gần như không đọc → Deep Archive

Từ khoá nhận diện:

"data persists for 24 hours only" → S3 Standard "unknown access pattern, long-lived" → Intelligent-Tiering "accessed monthly" → Standard-IA "archive for years" → Glacier / Deep Archive

⚠ Ba thành phần chi phí S3 — đừng chỉ nhìn giá lưu trữ: | Thành phần | Chi tiết | |---|---| | Lưu trữ (GB-tháng) | | | Request (PUT, GET, LIST) | | | Lấy dữ liệu (chỉ lớp IA và Glacier) | | | Truyền dữ liệu ra | |

Ba lỗi thiết kế khi ghi log lên S3: | Lỗi | Hậu quả | |---|---| | Mỗi dòng log một object | phí request rất lớn | | Không nén | tốn gấp 5-10 lần | | Không phân vùng theo ngày | truy vấn quét toàn bộ |

Cách ghi log đúng:

aws s3 cp log-gop.json.gz \
  s3://kho-log/nam=2026/thang=08/ngay=30/lo-001.json.gz

⚠ Với dữ liệu sống 24 giờ, phân vùng theo ngày là tự nhiên:

Mỗi ngày một tiền tố
    → lifecycle xoá tiền tố cũ
    → job phân tích chỉ đọc tiền tố hôm nay
        ↓
    Vừa gọn vừa rẻ khi truy vấn bằng Athena

Ba quy tắc lifecycle nên có: | Quy tắc | Việc | |---|---| | Expiration | xoá sau N ngày | | AbortIncompleteMultipartUpload | dọn phần tải lên dở | | NoncurrentVersionExpiration | nếu bật versioning |

⚠ Quy tắc thứ hai là chi phí ẩn phổ biến nhất:

Multipart upload thất bại giữa chừng
    → các phần đã tải lên VẪN TÍNH PHÍ
    → KHÔNG hiện trong danh sách object
        ↓
    Với log ghi liên tục, đây tích tụ rất nhanh

Ba lưu ý về Intelligent-Tiering: | Lưu ý | Chi tiết | |---|---| | Phí giám sát mỗi object mỗi tháng | | | Object < 128 KB không tính phí giám sát | và không chuyển tầng | | Cần ít nhất 30 ngày mới chuyển tầng | |

Dữ liệu sống 24 giờ
    → không bao giờ chuyển tầng
    → chỉ trả thêm phí giám sát

Ba lựa chọn thay thế cho log tạm: | Lựa chọn | Khi nào | |---|---| | S3 Standard + lifecycle 1 ngày | ← câu này | | CloudWatch Logs với retention 1 ngày | nếu cần tìm kiếm | | Kinesis Data Firehose → S3 | gộp lô tự động |

Ba công cụ phân tích log trên S3: | Công cụ | Việc | |---|---| | Amazon Athena | SQL trực tiếp | | AWS Glue | ETL | | Amazon EMR | xử lý lớn |

⚠ Ba cách giảm chi phí truy vấn Athena: | Cách | Mức giảm | |---|---| | Định dạng cột (Parquet, ORC) | thường 90%+ | | Phân vùng theo ngày | rất lớn | | Nén | |

Ba lưu ý về S3 Storage Lens: | Lưu ý | Chi tiết | |---|---| | Cho biết phân bố kích thước object | | | Phát hiện phần tải lên dở | | | Cho biết dữ liệu chưa từng được đọc | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra lifecycle đã xoá đúng hạn | | | Đọc Cost Explorer tách theo usage type | | | Xác nhận không có object cũ tích tụ | |

Và một lời khuyên: hãy nhớ rằng thời gian lưu tối thiểu áp dụng ngay cả khi bạn xoá object sớm. Đó là chi tiết khiến "lớp lưu trữ rẻ hơn" trở thành lựa chọn đắt hơn với dữ liệu vòng đời ngắn — và phép tính chỉ hiện ra trên hoá đơn tháng sau.

Đáp án

D — Dùng S3 Access Points để cấp chính sách truy cập khác nhau cho từng đội, và kiểm soát access point bằng Service Control Policy trong AWS Organizations.

Vì sao đúng

Đề nêu bốn dữ kiện, và S3 Access Points sinh ra đúng cho bài toán này: | Dữ kiện | Cách đáp ứng | |---|---| | MỘT bucket với hàng nghìn bản ghi tài chính | giữ nguyên một bucket | | 20 đội, mỗi đội quyền KHÁC NHAU | mỗi đội một access point | | 20 tài khoản trong AWS Organizations | access point cấp cho từng tài khoản | | ĐƠN GIẢN NHẤT, đặc quyền tối thiểu | không phải nhồi 20 câu lệnh vào một bucket policy |

⚠ Vấn đề mà Access Points giải quyết:

Không có access point:
    → MỘT bucket policy chứa quy tắc cho 20 đội
    → bucket policy giới hạn 20 KB
    → sửa một đội có rủi ro ảnh hưởng 19 đội kia
        ↓
Có access point:
    → mỗi đội một điểm vào riêng, một policy riêng
    → sửa độc lập, không đụng nhau

Tạo access point cho một đội:

aws s3control create-access-point --account-id 111122223333 \
  --name ap-doi-tin-dung --bucket kho-tai-chinh \
  --policy '{"Version":"2012-10-17","Statement":[{
    "Effect":"Allow",
    "Principal":{"AWS":"arn:aws:iam::222233334444:root"},
    "Action":["s3:GetObject"],
    "Resource":"arn:aws:s3:ap-southeast-1:111122223333:accesspoint/ap-doi-tin-dung/object/tin-dung/*"}]}'

⚠ Access point có ARN riêng, đội dùng nó thay vì tên bucket:

aws s3api get-object \
  --bucket arn:aws:s3:ap-southeast-1:111122223333:accesspoint/ap-doi-tin-dung \
  --key tin-dung/bao-cao-q3.pdf bao-cao.pdf

Và bucket policy uỷ quyền cho access point:

{"Effect": "Allow",
 "Principal": {"AWS": "*"},
 "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-tai-chinh",
              "arn:aws:s3:::kho-tai-chinh/*"],
 "Condition": {"StringEquals":
   {"s3:DataAccessPointAccount": "111122223333"}}}

Bucket policy chỉ cần MỘT câu lệnh
    → uỷ quyền toàn bộ việc phân quyền cho access point
        ↓
    Đây là điểm làm giải pháp này "simplest"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi đội một policy độc lập | | | Bucket policy ngắn gọn | không chạm giới hạn 20 KB | | Giới hạn theo tiền tố dễ dàng | |

⚠ Và SCP thêm một lớp bảo vệ ở cấp tổ chức:

SCP chặn tài khoản truy cập bucket TRỰC TIẾP
    → buộc mọi truy cập phải qua access point
        ↓
    Không ai lách được cơ chế phân quyền

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

• **A. Tạo bucket ở một tài khoản riêng, cấu hình IAM role cho TỪNG NGƯỜI DÙNG để truy cập chéo tài khoản — đây là phương án gần nhất vì cross-account role là cơ chế hợp lệ, nhưng nó nhiều việc hơn hẳn: phải tạo và duy trì role cho từng người dùng ở 20 tài khoản, và mọi quy tắc vẫn dồn vào một bucket policy.
• **C. Chép dữ liệu ra 20 bucket riêng — nhân bản dữ liệu 20 lần: tốn chi phí lưu trữ, phải đồng bộ khi dữ liệu đổi, và tạo ra 20 nguồn sự thật cho cùng một tập tài liệu tài chính.
• **B. Tạo một AWS Organizations MỚI và gán mỗi đội một OU — công ty đã có Organizations; tạo tổ chức mới là không cần thiết. Và OU không cấp quyền truy cập S3 — SCP chỉ giới hạn, không cấp.

Ghi nhớ

⚠ Ba cách phân quyền truy cập S3 — bảng phải thuộc: | Cách | Khi nào | |---|---| | Bucket policy | ít bên truy cập, quy tắc đơn giản | | S3 Access Points | NHIỀU bên, mỗi bên quyền khác nhau | | IAM policy trên danh tính | kiểm soát từ phía người dùng |

⚠ Ba đặc điểm của S3 Access Point: | Đặc điểm | Chi tiết | |---|---| | Mỗi access point có tên DNS và policy RIÊNG | | | Có thể giới hạn theo tiền tố | | | Có thể giới hạn chỉ truy cập từ một VPC | |

Giới hạn access point chỉ dùng trong VPC:

aws s3control create-access-point --account-id 111122223333 \
  --name ap-noi-bo --bucket kho-tai-chinh \
  --vpc-configuration VpcId=vpc-abc123

Access point kiểu VPC KHÔNG truy cập được từ Internet
    → thêm một lớp cách ly

Từ khoá nhận diện:

"many teams, different permissions, one bucket" → S3 Access Points "restrict to accounts in my organization" → aws:PrincipalOrgID "one bucket policy for everything" → chạm giới hạn 20 KB "transform data as read" → S3 Object Lambda Access Point

⚠ Ba giới hạn của bucket policy: | Giới hạn | Con số | |---|---| | Kích thước bucket policy | 20 KB | | Số access point mỗi bucket | 10.000 | | Số bucket mỗi tài khoản | 10.000 (mặc định 100) |

20 đội × quy tắc phức tạp
    → dễ chạm giới hạn 20 KB
        ↓
    Access point giải quyết hẳn vấn đề này

Ba loại access point: | Loại | Việc | |---|---| | S3 Access Point | phân quyền theo bên truy cập ← câu này | | Multi-Region Access Point | định tuyến toàn cầu | | Object Lambda Access Point | biến đổi dữ liệu khi đọc |

⚠ Ba khoá điều kiện hữu ích cho tổ chức: | Khoá | Nghĩa | |---|---| | aws:PrincipalOrgID | chỉ tài khoản trong tổ chức | | aws:PrincipalOrgPaths | chỉ một OU cụ thể | | s3:DataAccessPointAccount | request đến qua access point |

Chặn truy cập ngoài tổ chức:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-tai-chinh",
              "arn:aws:s3:::kho-tai-chinh/*"],
 "Condition": {"StringNotEquals":
   {"aws:PrincipalOrgID": "o-abc123"}}}

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | SCP KHÔNG cấp quyền, chỉ giới hạn | | | Áp cho mọi principal, kể cả root tài khoản thành viên | | | Không áp cho tài khoản quản lý | |

⚠ SCP buộc dùng access point:

{"Effect": "Deny", "Action": "s3:*",
 "Resource": "arn:aws:s3:::kho-tai-chinh/*",
 "Condition": {"Null": {"s3:DataAccessPointArn": "true"}}}

Từ chối mọi request KHÔNG đi qua access point
    → không ai truy cập bucket trực tiếp được

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Giới hạn Action tới đúng thao tác cần | | | Giới hạn Resource tới đúng tiền tố | | | Rà soát định kỳ bằng Access Analyzer | |

⚠ Quyền cấp bucket và cấp object khác nhau:

s3:ListBucket → Resource là access point ARN (không có /object/*)
s3:GetObject  → Resource là .../object/tien-to/*
        ↓
    Nhầm chỗ này là lỗi AccessDenied khó hiểu nhất

Ba lưu ý về bảo mật dữ liệu tài chính: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá SSE-KMS với customer managed key | | | Bật versioning và Object Lock nếu cần | | | CloudTrail data event ghi mọi truy cập | |

Ba công cụ rà soát: | Công cụ | Việc | |---|---| | IAM Access Analyzer for S3 | tìm bucket/access point mở ra ngoài | | Amazon Macie | tìm dữ liệu nhạy cảm | | CloudTrail | ai truy cập gì |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi đội thử truy cập tiền tố của mình | phải được | | Thử truy cập tiền tố của đội khác | phải bị từ chối | | Thử truy cập bucket trực tiếp | phải bị SCP chặn |

Và một lời khuyên: hãy dùng S3 Access Points ngay khi số bên truy cập vượt quá vài đơn vị. Một bucket policy với hai mươi câu lệnh vừa chạm giới hạn kích thước vừa biến mỗi lần sửa quyền cho một đội thành một thay đổi có rủi ro cho mười chín đội còn lại.

Đáp án

B và E.

• B — Dùng On-Demand Capacity Reservation cho môi trường phát triển
• E — Dùng Reserved Instance cho môi trường production

Vì sao đúng

Đề nêu hai mẫu tải khác nhau, và mỗi mẫu cần một mô hình: | Môi trường | Mẫu chạy | Mô hình | |---|---|---| | Production | 24/7 liên tục | Reserved Instance — giảm giá cao nhất | | Development | 9-17 giờ, thứ Hai tới thứ Sáu | Capacity Reservation — đảm bảo có máy |

⚠ Đề đòi HAI thứ: "optimize cost" VÀ "ensure capacity is available":

Production 24/7 → RI cho mức giảm tối đa
    → và RI zonal cũng đảm bảo năng lực

Development 40 giờ/tuần → RI không hoà vốn
    → nhưng vẫn cần đảm bảo có máy khi bật
        ↓
    Capacity Reservation giữ chỗ mà không cần cam kết dài hạn

Tính thử tỷ lệ sử dụng của môi trường dev:

8 giờ × 5 ngày = 40 giờ mỗi tuần
    → 40 / 168 ≈ 24% thời gian
        ↓
    RI cam kết 24/7 → trả tiền cho 76% không dùng

Mua RI cho production:

aws ec2 describe-reserved-instances-offerings \
  --instance-type m6i.xlarge --product-description "Linux/UNIX" \
  --offering-class standard --offering-type "All Upfront" \
  --min-duration 31536000 --max-duration 31536000

aws ec2 purchase-reserved-instances-offering \
  --reserved-instances-offering-id <id> --instance-count 10

Capacity Reservation cho dev:

aws ec2 create-capacity-reservation \
  --instance-type m6i.large --instance-platform Linux/UNIX \
  --availability-zone ap-southeast-1a --instance-count 5 \
  --instance-match-criteria targeted

⚠ Và huỷ ngoài giờ để tiết kiệm:

Capacity Reservation tính tiền LIÊN TỤC
    → tạo lúc 8h45, huỷ lúc 17h15 các ngày làm việc
        ↓
    Tự động bằng EventBridge Scheduler
    → chỉ trả cho khoảng thời gian giữ chỗ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Production hưởng mức giảm cao nhất | | | Dev đảm bảo có máy mà không cam kết dài hạn | | | Không bị gián đoạn ở cả hai môi trường | |

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

• **C. Dùng Reserved Instance cho môi trường phát triển — đây là phương án gần nhất vì RI thật sự giảm giá, nhưng dev chỉ chạy 24% thời gian: RI cam kết 24/7 nên trả tiền cho phần lớn thời gian không dùng.
• **A. Dùng Spot cho môi trường phát triển — Spot rẻ nhất nhưng không đảm bảo có máy, vi phạm yêu cầu "ensure capacity is available". (Với dev chịu được gián đoạn thì Spot là lựa chọn tốt, nhưng đề nêu rõ yêu cầu năng lực.)
• **D. Dùng On-Demand cho production — production chạy 24/7 là trường hợp lý tưởng nhất để cam kết; dùng On-Demand là bỏ qua mức giảm tới 72%.

Ghi nhớ

⚠ Bảng đảm bảo năng lực — thuộc bảng này là làm được cả nhóm câu: | Lựa chọn | Giảm giá | Đảm bảo năng lực | |---|---|---| | On-Demand Capacity Reservation | ❌ | ✅ | | Zonal Reserved Instance | ✅ | ✅ | | Regional Reserved Instance | ✅ | ❌ | | Savings Plans | ✅ | ❌ | | On-Demand | ❌ | ❌ | | Spot | ✅✅ | ❌ |

⚠ Quy tắc ước lượng theo tỷ lệ sử dụng:

Dưới ~25% thời gian  → On-Demand (+ Capacity Reservation nếu cần)
25-70%               → cân nhắc Savings Plans
Trên ~70%            → RI hoặc Savings Plans chắc chắn có lợi

Từ khoá nhận diện:

"24/7 production" → RI hoặc Savings Plans "business hours only" + "ensure capacity" → Capacity Reservation "fault-tolerant, can be interrupted" → Spot "need to change instance family" → Convertible RI hoặc Compute SP

Hai loại Reserved Instance: | Loại | Giảm | Linh hoạt | Đảm bảo năng lực | |---|---|---|---| | Standard RI | tới ~72% | thấp | zonal: ✅ | | Convertible RI | tới ~54% | cao — đổi họ, OS | zonal: ✅ |

⚠ Zonal RI và Regional RI: | | Zonal RI | Regional RI | |---|---|---| | Đảm bảo năng lực | ✅ | ❌ | | Linh hoạt AZ | ❌ khoá một AZ | ✅ |

Nếu production cũng cần đảm bảo năng lực
    → mua ZONAL RI, không phải regional

Ba tuỳ chọn thanh toán RI: | Tuỳ chọn | Mức giảm | |---|---| | All Upfront | cao nhất | | Partial Upfront | trung bình | | No Upfront | thấp nhất |

⚠ Savings Plans thường tốt hơn RI cho thiết kế mới: | | Reserved Instance | Savings Plans | |---|---|---| | Cam kết | loại instance cụ thể | số tiền mỗi giờ | | Linh hoạt | thấp (Standard) | cao | | Áp cho Fargate và Lambda | ❌ | ✅ (Compute SP) | | Mức giảm tối đa | ~72% | ~72% |

Ba cách tối ưu cho môi trường dev: | Cách | Chi tiết | |---|---| | Tự động tắt ngoài giờ | tiết kiệm ~76% | | Spot nếu chịu được gián đoạn | rẻ nhất | | Instance nhỏ hơn production | |

Tự động tắt bằng ASG scheduled action:

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name asg-dev \
  --scheduled-action-name bat-sang \
  --recurrence "0 9 * * MON-FRI" --desired-capacity 5 \
  --time-zone "Asia/Ho_Chi_Minh"

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name asg-dev \
  --scheduled-action-name tat-chieu \
  --recurrence "0 17 * * MON-FRI" --desired-capacity 0 \
  --time-zone "Asia/Ho_Chi_Minh"

⚠ Luôn khai --time-zone:

Không khai → hiểu là UTC
    → "0 9" thành 16 giờ chiều giờ Việt Nam

Ba đặc điểm của Capacity Reservation: | Đặc điểm | Chi tiết | |---|---| | Gắn với MỘT AZ cụ thể | | | Tạo và huỷ bất cứ lúc nào | không cam kết thời hạn | | Trả tiền dù dùng hay không | |

Hai chế độ khớp: | Chế độ | Hành vi | |---|---| | open | mọi instance khớp thuộc tính tự dùng chỗ | | targeted | chỉ instance khai rõ ARN |

⚠ Capacity Reservation áp chồng với Savings Plans:

Capacity Reservation: đảm bảo CÓ MÁY (không giảm giá)
Savings Plans:        GIẢM GIÁ (không đảm bảo)
        ↓
    Dùng cả hai để vừa chắc vừa rẻ

Ba công cụ phân tích chi phí: | Công cụ | Việc | |---|---| | Cost Explorer RI/SP recommendations | gợi ý mua bao nhiêu | | Compute Optimizer | đúng cỡ máy | | Trusted Advisor | tài nguyên nhàn rỗi |

⚠ Đúng cỡ máy TRƯỚC khi mua cam kết:

Mua RI 3 năm cho instance quá lớn
    → khoá luôn cả sự lãng phí trong 3 năm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra RI đã áp đúng instance | Cost Explorer RI utilization | | Xem tỷ lệ dùng Capacity Reservation | | | Xác nhận dev thật sự tắt ngoài giờ | |

Và một lời khuyên: hãy tự động hoá việc tạo và huỷ Capacity Reservation cho môi trường dev. Nó tính tiền như một instance đang chạy, nên giữ nó suốt tuần cho 40 giờ sử dụng là trả tiền cho 76% thời gian không dùng — đúng vấn đề mà bạn đang cố tránh khi không mua RI.

Đáp án

A — Triển khai một Landing Zone bằng AWS Control Tower, cho quản trị viên từng phòng ban dùng Landing Zone tạo tài khoản thành viên và mạng, rồi cấp quyền power user trên các tài khoản đó.

Vì sao đúng

Đề nêu bốn yêu cầu, và Control Tower là dịch vụ được thiết kế chính xác cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Mỗi phòng ban một tài khoản AWS riêng | Account Factory tạo tài khoản theo mẫu | | Cấu hình sẵn, truy cập GIỚI HẠN | guardrail áp tự động | | Chỉ dịch vụ được phép | SCP dựng sẵn | | Theo đặc quyền tối thiểu | permission set của IAM Identity Center |

⚠ Landing Zone là khái niệm, Control Tower là dịch vụ triển khai nó:

"Landing Zone" = môi trường AWS đa tài khoản
                 đã dựng sẵn theo thực hành tốt
        ↓
    AWS Control Tower là dịch vụ TỰ ĐỘNG dựng landing zone
    → AWS Organizations chỉ là một THÀNH PHẦN bên trong

Đây là điểm phân biệt A với C.

Control Tower dựng sẵn những gì: | Thành phần | Chi tiết | |---|---| | AWS Organizations với OU chuẩn | Security, Sandbox | | Tài khoản Log Archive | gom CloudTrail và Config | | Tài khoản Audit | truy cập chéo để kiểm toán | | IAM Identity Center | truy cập tập trung | | Guardrail (SCP + Config rule) | |

Account Factory tạo tài khoản mới:

Quản trị viên phòng ban vào Service Catalog
    → chọn sản phẩm "AWS Control Tower Account Factory"
    → điền tên, email, OU
        ↓
    Tài khoản mới tự động:
    → vào đúng OU, chịu đúng guardrail
    → có VPC dựng sẵn theo mẫu
    → gắn vào IAM Identity Center

Ba loại guardrail: | Loại | Cơ chế | |---|---| | Preventive | SCP — CHẶN hành động | | Detective | AWS Config rule — PHÁT HIỆN vi phạm | | Proactive | CloudFormation hook — chặn trước khi triển khai |

⚠ Guardrail có ba mức bắt buộc: | Mức | Nghĩa | |---|---| | Mandatory | luôn bật, không tắt được | | Strongly recommended | nên bật | | Elective | tuỳ chọn |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tài khoản mới tự động tuân thủ | | | Không phải tự viết SCP từ đầu | | | Có bảng điều khiển tuân thủ | |

⚠ Và cấp quyền power user chứ không phải admin:

Power user: dùng được hầu hết dịch vụ
    → NHƯNG không quản lý IAM và tổ chức
        ↓
    Kết hợp với SCP của Control Tower
    → phòng ban tự chủ trong ranh giới đã định

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

• **C. Triển khai "Landing Zone trong AWS Organizations" — đây là phương án gần nhất và chỉ khác một từ, nhưng đó là từ quyết định: AWS Organizations không có tính năng Landing Zone. Nó cung cấp cấu trúc tài khoản và SCP, còn Landing Zone là thứ Control Tower dựng.
• **D. Cấu hình Organizations với SCP và dùng CloudFormation cấu hình mạng — làm được nhưng nhiều việc hơn hẳn: phải tự viết mọi SCP, tự dựng tài khoản log và audit, tự tích hợp Identity Center. Control Tower làm sẵn tất cả.
• **B. Dùng CloudFormation tạo tài khoản và mạng, dùng IAM role cấp quyền — cùng vấn đề tự làm mọi thứ, và thiếu hẳn phần guardrail cùng bảng điều khiển tuân thủ.

Ghi nhớ

⚠ Ba dịch vụ quản trị đa tài khoản — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS Control Tower | dựng và vận hành LANDING ZONE | | AWS Organizations | cấu trúc tài khoản, OU, SCP | | IAM Identity Center | truy cập tập trung cho nhân viên |

⚠ Quan hệ giữa chúng:

Control Tower
    ├── dùng AWS Organizations (tạo OU, áp SCP)
    ├── dùng IAM Identity Center (truy cập)
    ├── dùng AWS Config (guardrail phát hiện)
    └── dùng Service Catalog (Account Factory)
        ↓
    Control Tower là lớp ĐIỀU PHỐI trên các dịch vụ đó

Từ khoá nhận diện:

"landing zone", "preconfigured accounts", "guardrails" → AWS Control Tower "SCP to restrict services" → Organizations (thành phần của Control Tower) "employees access many accounts" → IAM Identity Center "create accounts programmatically with full control" → CloudFormation + Organizations API

Ba thành phần cốt lõi của Control Tower: | Thành phần | Việc | |---|---| | Landing Zone | môi trường đa tài khoản dựng sẵn | | Account Factory | tạo tài khoản theo mẫu | | Guardrails (controls) | quy tắc tuân thủ |

⚠ Ba tài khoản Control Tower tạo ra: | Tài khoản | Việc | |---|---| | Management | quản lý tổ chức | | Log Archive | gom CloudTrail và Config log | | Audit | truy cập chéo để kiểm toán |

Ba OU mặc định: | OU | Chứa | |---|---| | Security | Log Archive, Audit | | Sandbox | tài khoản thử nghiệm | | Tuỳ chỉnh | theo phòng ban |

⚠ Customizations for Control Tower (CfCT):

Muốn thêm cấu hình riêng cho mọi tài khoản mới?
    → dùng CfCT: pipeline CloudFormation StackSets
    → tự động áp cho tài khoản khi tạo
        ↓
    Ví dụ: VPC theo chuẩn công ty, IAM role riêng

Ba lưu ý về Account Factory: | Lưu ý | Chi tiết | |---|---| | Mỗi tài khoản cần EMAIL DUY NHẤT | | | Tạo tài khoản mất vài phút | | | Uỷ quyền qua Service Catalog | |

⚠ Email duy nhất là ràng buộc thực tế:

Dùng subaddressing: aws+phong-ke-toan@congty.com
    → hoặc tạo alias trong hệ thống mail
        ↓
    Lên kế hoạch đặt tên TRƯỚC khi tạo hàng loạt

Ba lưu ý về guardrail: | Lưu ý | Chi tiết | |---|---| | Mandatory guardrail không tắt được | | | Preventive dùng SCP | chặn hành động | | Detective dùng Config rule | phát hiện, không chặn |

Ba guardrail quan trọng nhất: | Guardrail | Việc | |---|---| | Chặn xoá CloudTrail | bảo vệ audit | | Chặn thay đổi cấu hình log archive | | | Chặn truy cập public vào S3 | |

⚠ Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Permission set thay vì IAM user | credential tạm | | Gán cho NHÓM, không gán cho từng người | | | PowerUserAccess thay vì AdministratorAccess | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Control Tower KHÔNG tính phí riêng | | | Trả cho dịch vụ bên dưới | CloudTrail, Config, S3 | | Config rule ở nhiều tài khoản cộng lại đáng kể | |

⚠ AWS Config là khoản chi phí hay bị bất ngờ:

Guardrail phát hiện dùng Config rule
    → tính phí theo số đánh giá cấu hình
        ↓
    Với hàng chục tài khoản, khoản này không nhỏ
    → xem lại danh sách guardrail elective

Ba lưu ý khi mở rộng: | Lưu ý | Chi tiết | |---|---| | Có OU sandbox nới lỏng cho thử nghiệm | | | Ghi tài liệu vì sao chặn từng thứ | | | Có quy trình xin ngoại lệ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo thử một tài khoản qua Account Factory | | | Kiểm tra guardrail đã áp | bảng điều khiển Control Tower | | Thử hành động bị chặn từ tài khoản mới | |

Và một lời khuyên: hãy dựng landing zone bằng Control Tower trước khi có nhiều tài khoản, không phải sau. Chuyển hàng chục tài khoản đã tồn tại vào Control Tower là việc làm được nhưng phải xử lý từng trường hợp — còn bắt đầu bằng Control Tower thì mọi tài khoản sinh ra đã đúng chuẩn từ đầu.