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

Đáp án

B — Thiết lập AWS Site-to-Site VPN.

Vì sao đúng

Đề nêu ba yêu cầu, và Site-to-Site VPN đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Kết nối AN TOÀN | IPsec, mã hoá sẵn có | | KHÔNG cần băng thông cao, lưu lượng nhỏ | VPN đủ dùng | | Dựng NHANH và tiết kiệm nhất | vài giờ, ~36 USD/tháng |

So sánh trực tiếp với Direct Connect: | | Site-to-Site VPN | Direct Connect | |---|---|---| | Thời gian dựng | vài GIỜ | vài TUẦN – THÁNG | | Chi phí | ~36 USD/tháng | phí cổng + phí nhà cung cấp, cao hơn nhiều | | Mã hoá | ✅ sẵn có | ❌ mặc định | | Băng thông | ~1,25 Gbps mỗi tunnel | 1–400 Gbps ổn định |

Với lưu lượng nhỏ và cần nhanh, VPN thắng rõ trên cả ba tiêu chí.

Triển khai:

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

aws ec2 create-vpn-gateway --type ipsec.1
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-abc --vpc-id vpc-abc

aws ec2 create-vpn-connection --type ipsec.1   --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc

Và mỗi kết nối có HAI tunnel:

AWS tự tạo 2 tunnel ở 2 endpoint khác nhau
    → dư thừa sẵn có
        ↓
    Thiết bị tại chỗ phải cấu hình CẢ HAI
    → chỉ cấu hình một là mất dư thừa

Đừng quên bật route propagation:

aws ec2 enable-vgw-route-propagation   --route-table-id rtb-abc --gateway-id vgw-abc

Quên bước này là VPN lên nhưng không có lưu lượng nào đi qua — lỗi rất hay gặp.

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

• **A. Thiết lập AWS Direct Connect — đây là phương án gần nhất và là kết nối riêng tốt nhất, nhưng nó sai cả ba tiêu chí của đề: mất hàng tuần tới hàng tháng, đắt hơn nhiều, và không mã hoá theo mặc định. Nó chỉ đáng khi cần băng thông lớn và ổn định — điều mà đề nói rõ là không cần.
• **C. Dựng bastion host trên EC2 — không phải kết nối mạng giữa hai môi trường: bastion chỉ cho phép quản trị viên SSH vào một máy, không nối hai mạng.
• **D. Dựng Internet Gateway giữa trung tâm dữ liệu và AWS — hiểu sai hoàn toàn: Internet Gateway là thành phần của VPC cho phép tài nguyên ra Internet, nó không phải cầu nối tới mạng on-premises.

Ghi nhớ

Ba cách kết nối on-premises với AWS — bảng phải thuộc: | Cách | Thời gian dựng | Mã hoá | Băng thông | Chi phí | |---|---|---|---|---| | Site-to-Site VPN | vài GIỜ | ✅ | tới ~1,25 Gbps/tunnel | ~36 USD/tháng | | Direct Connect | vài TUẦN–THÁNG | ❌ | 1–400 Gbps | cao | | DX + VPN qua nó | như DX | ✅ | như DX | cao nhất |

Từ khoá nhận diện — rất hay được hỏi:

"quick turnaround", "small amount of traffic", "cost-effective", "secure" → Site-to-Site VPN "consistent high bandwidth", "low jitter", "large data transfer" → Direct Connect "private AND encrypted", "compliance" → DX + VPN

Ba thành phần của Site-to-Site VPN: | Thành phần | Việc | |---|---| | Customer Gateway | đại diện thiết bị TẠI CHỖ | | Virtual Private Gateway (VGW) | phía AWS, gắn MỘT VPC | | Transit Gateway | thay VGW khi cần nối NHIỀU VPC |

Với nhiều VPC, Transit Gateway mở rộng tốt hơn:

VGW: một VPN cho MỘT VPC → 10 VPC = 10 kết nối VPN
TGW: một VPN cho MỌI VPC gắn vào

Ba đặc điểm của Site-to-Site VPN: | Đặc điểm | Chi tiết | |---|---| | Hai tunnel mỗi kết nối | dư thừa | | Đi qua Internet công cộng | độ trễ biến động | | Hỗ trợ BGP động hoặc static route | |

Dòng giữa là hạn chế chính — nếu ứng dụng nhạy với độ trễ thì Direct Connect vẫn cần.

Ba cách tăng băng thông VPN: | Cách | Chi tiết | |---|---| | Nhiều VPN với ECMP qua Transit Gateway | | | Accelerated Site-to-Site VPN | qua mạng Global Accelerator | | Chuyển sang Direct Connect | |

Accelerated VPN đáng biết:

Lưu lượng vào mạng riêng của AWS ở edge gần nhất
    → giảm số chặng qua Internet công cộng
        ↓
    Độ trễ ổn định hơn đáng kể

Ba tham số IPsec nên khai rõ: | Tham số | Khuyến nghị | |---|---| | Mã hoá | AES256 | | Băm | SHA2-256 trở lên | | Diffie-Hellman group | 14 trở lên |

Ba lưu ý khi cấu hình thiết bị tại chỗ: | Lưu ý | Chi tiết | |---|---| | AWS cung cấp file cấu hình mẫu theo hãng | Cisco, Juniper, Fortinet... | | Cấu hình CẢ HAI tunnel | | | Kiểm tra MTU và MSS clamping | tránh phân mảnh gói |

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-abc   --query 'VpnConnections[].CustomerGatewayConfiguration' --output text

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TunnelState | 0 = DOWN, 1 = UP | | TunnelDataIn/Out | lưu lượng | | — | đặt alarm khi MỘT tunnel xuống |

Cảnh báo cho từng tunnel là quan trọng:

Một tunnel xuống → kết nối vẫn hoạt động bình thường
    → sự cố HOÀN TOÀN IM LẶNG
        ↓
    Chỉ phát hiện khi tunnel thứ hai cũng xuống
    → tức là lúc mất kết nối hoàn toàn

Ba lựa chọn khác cho kết nối từ xa: | Lựa chọn | Đối tượng | |---|---| | Site-to-Site VPN | nối cả MẠNG ← câu này | | AWS Client VPN | từng NGƯỜI DÙNG làm việc từ xa | | Session Manager | truy cập quản trị một máy |

Client VPN khác Site-to-Site:

Site-to-Site: nối trung tâm dữ liệu với VPC
Client VPN:   nhân viên cài client, kết nối cá nhân
        ↓
    Hai bài toán khác nhau

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | VPN connection | ~0,05 USD/giờ (~36 USD/tháng) | | Truyền dữ liệu ra | ~0,09 USD/GB | | Accelerated VPN | phí thêm |

Ba việc cần kiểm tra sau khi dựng: | Việc | Chi tiết | |---|---| | Cả hai tunnel ở trạng thái UP | | | Route propagation đã bật | | | Ping thử từ cả hai phía | |

Và một lời khuyên: hãy dựng Site-to-Site VPN ngay cả khi đang chờ Direct Connect. Nó lên trong vài giờ với chi phí nhỏ, cho phép bắt đầu công việc luôn, và sau này trở thành đường dự phòng cho Direct Connect — một kết nối riêng không có đường dự phòng là điểm hỏng đơn ở đúng chỗ tệ nhất.

Đáp án

C — Dùng địa chỉ IP RIÊNG của EC2 instance cho việc sao chép.

Vì sao đúng

Đề nêu vấn đề chi phí, và nguyên nhân nằm ở việc dùng IP công cộng:

Hai EC2 trong CÙNG VPC nói chuyện qua IP CÔNG CỘNG:
    → lưu lượng đi RA khỏi VPC
    → qua Internet Gateway
    → rồi quay TRỞ LẠI
        ↓
    Tính phí như truyền dữ liệu ra Internet
    → ~0,09 USD/GB (giảm dần theo bậc)

Đổi sang IP riêng:

Hai EC2 nói chuyện qua IP RIÊNG:
    → lưu lượng ở TRONG VPC
        ↓
    Cùng AZ:  MIỄN PHÍ
    Khác AZ:  ~0,01 USD/GB mỗi chiều
        ↓
    Rẻ hơn khoảng 9 lần so với IP công cộng

Phép tính với 10 TB sao chép mỗi tháng qua hai AZ:

Qua IP công cộng: 10.000 GB × 0,09 × 2 chiều ≈ 1.800 USD/tháng
Qua IP riêng:     10.000 GB × 0,01 × 2 chiều ≈ 200 USD/tháng
        ↓
    Tiết kiệm khoảng 1.600 USD mỗi tháng

Và hai instance ở public subnet vẫn dùng IP riêng được:

"Public subnet" chỉ nghĩa là route table có đường ra Internet
    → instance VẪN có IP riêng
    → và VẪN nói chuyện với nhau qua IP riêng được
        ↓
    Không cần chuyển sang private subnet

Cấu hình:

aws ec2 describe-instances --instance-ids i-0aaa i-0bbb   --query 'Reservations[].Instances[].{Id:InstanceId,
           Rieng:PrivateIpAddress,CongCong:PublicIpAddress}'

Rồi sửa cấu hình sao chép của database dùng địa chỉ riêng.

Và nên dùng tên DNS riêng thay vì IP cứng:

ip-10-0-1-5.ap-northeast-1.compute.internal
        ↓
    Hoặc tạo Route 53 private hosted zone:
        db-node-1.noibo.vidu.com → 10.0.1.5
        ↓
    Đổi IP không phải sửa cấu hình

Và security group phải cho phép theo IP riêng:

aws ec2 authorize-security-group-ingress --group-id sg-db   --protocol tcp --port 5432 --source-group sg-db

Tham chiếu chính security group đó — hai node cùng nhóm nói chuyện được với nhau.

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

• **D. Gán Elastic IP cho hai instance và dùng chúng để sao chép — đây là phương án gần nhất vì cũng là việc đổi địa chỉ, nhưng nó KHÔNG giảm chi phí: Elastic IP vẫn là địa chỉ công cộng, lưu lượng vẫn đi ra và quay lại, vẫn tính phí như cũ. (Và từ 2024, mọi IPv4 công cộng còn tính phí riêng.)
• **B. Tạo PrivateLink giữa hai EC2 instance — sai công cụ: PrivateLink dùng để expose một dịch vụ cho VPC khác qua NLB. Hai instance trong cùng VPC đã nói chuyện trực tiếp được.
• **A. Dùng Elastic Fabric Adapter (EFA) — sai mục đích: EFA là giao diện mạng cho HPC và học máy phân tán, cần đặt trong cùng placement group, và nó không giải quyết vấn đề chi phí ở đây.

Ghi nhớ

Chi phí truyền dữ liệu của AWS — bảng phải thuộc: | Chiều | Chi phí | |---|---| | VÀO AWS (ingress) | MIỄN PHÍ | | Cùng AZ, qua IP RIÊNG | MIỄN PHÍ | | Cùng AZ, qua IP CÔNG CỘNG hoặc Elastic IP | ~0,01 USD/GB mỗi chiều | | Khác AZ, cùng Region | ~0,01 USD/GB mỗi chiều | | Khác Region | ~0,02 USD/GB trở lên | | RA Internet | ~0,09 USD/GB |

Dòng thứ ba là bẫy quan trọng nhất:

Hai instance CÙNG AZ nói chuyện qua IP công cộng
    → VẪN TÍNH PHÍ
    → dù chúng ở cạnh nhau về mặt vật lý
        ↓
    Luôn dùng IP riêng trong VPC

Ba loại địa chỉ IP của EC2: | Loại | Đặc điểm | |---|---| | IP riêng | luôn có, MIỄN PHÍ trong AZ | | IPv4 công cộng tự động | thu hồi khi stop/start | | Elastic IP | tĩnh, giữ được |

Và từ tháng 2/2024:

MỌI địa chỉ IPv4 công cộng đều tính phí ~0,005 USD/giờ
    → kể cả khi đang gắn vào instance đang chạy
        ↓
    ~3,6 USD/tháng mỗi IP
    → thêm lý do bỏ IP công cộng khi không cần

Ba cách giảm chi phí truyền dữ liệu: | Cách | Tiết kiệm | |---|---| | Dùng IP riêng trong VPC | ← câu này | | VPC endpoint cho dịch vụ AWS | bỏ phí NAT | | Đặt tài nguyên liên quan cùng AZ | miễn phí hoàn toàn |

Dòng cuối đáng cân nhắc:

Sao chép ĐỒNG BỘ giữa hai AZ:
    ✓ chịu được mất một AZ
    ✗ tốn phí chéo AZ và có độ trễ

Cùng AZ:
    ✓ miễn phí, độ trễ thấp nhất
    ✗ KHÔNG chịu được mất AZ
        ↓
    Đề nói rõ mục tiêu là "survive disasters in data centers"
    → hai AZ là đúng, chấp nhận phí chéo AZ

Ba lưu ý về placement group: | Loại | Đặc điểm | |---|---| | Cluster | cùng AZ, độ trễ thấp nhất, băng thông cao nhất | | Spread | trải trên phần cứng khác nhau | | Partition | nhóm phân vùng, cho HDFS, Cassandra |

Với sao chép database cần dư thừa, Spread hoặc hai AZ là đúng.

Ba lưu ý về Elastic Fabric Adapter: | Lưu ý | Chi tiết | |---|---| | Cho HPC và học máy phân tán | MPI, NCCL | | Yêu cầu cùng placement group cluster | | | Không giảm chi phí truyền dữ liệu | |

Ba công cụ phân tích chi phí truyền dữ liệu: | Công cụ | Việc | |---|---| | Cost Explorer lọc theo usage type | DataTransfer-Out-Bytes, DataTransfer-Regional-Bytes | | VPC Flow Logs | luồng nào chiếm nhiều nhất | | Cost and Usage Report | chi tiết nhất |

Tìm luồng tốn tiền bằng Flow Logs:

SELECT srcaddr, dstaddr, SUM(bytes)/1073741824 AS gb
FROM vpc_flow_logs
WHERE day = '2026-08-30'
GROUP BY srcaddr, dstaddr
ORDER BY gb DESC LIMIT 20;

Ba lưu ý về bảo mật khi dùng IP riêng: | Lưu ý | Chi tiết | |---|---| | Security group tham chiếu SG thay vì CIDR | tự thích ứng | | Cân nhắc chuyển sang private subnet | database không cần IP công cộng | | Dùng Session Manager cho quản trị | không cần bastion |

Dòng giữa đáng làm:

Đề nói database phải "publicly available"
    → nhưng thường chỉ ỨNG DỤNG cần truy cập được
        ↓
    Đặt database ở private subnet, ứng dụng ở public
    → an toàn hơn nhiều và không mất gì

Ba lưu ý về DNS trong VPC: | Lưu ý | Chi tiết | |---|---| | Tên DNS nội bộ tự có | ip-10-0-1-5.<region>.compute.internal | | Route 53 private hosted zone cho tên thân thiện | | | Cần enableDnsHostnames và enableDnsSupport | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NetworkIn, NetworkOut | lưu lượng của instance | | Chi phí DataTransfer trong Cost Explorer | | | Độ trễ sao chép của database | |

Và một lời khuyên: hãy kiểm tra mục DataTransfer trong Cost Explorer khi rà soát chi phí. Ở nhiều tổ chức, đó là khoản lớn thứ hai hoặc thứ ba sau tính toán và lưu trữ — và phần lớn thường đến từ đúng loại lỗi này: hai tài nguyên trong cùng VPC nói chuyện qua địa chỉ công cộng vì ai đó đã cấu hình bằng IP nhìn thấy đầu tiên trong console.

Đáp án

A — Dùng AWS IAM Identity Center tích hợp với thư mục của tổ chức; định nghĩa permission set theo quyền tối thiểu cho RDS và S3; gán người dùng vào nhóm theo vai trò và ánh xạ nhóm sang permission set.

Vì sao đúng

Đề nêu bốn yêu cầu, và IAM Identity Center đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Đã dùng IAM Identity Center với thư mục doanh nghiệp | tiếp tục dùng, không đổi kiến trúc | | Phân quyền chi tiết theo vai trò | permission set riêng cho từng nhóm | | Quyền tối thiểu | policy viết theo nhu cầu thật | | Ít công quản trị nhất | gán theo NHÓM, không theo từng người |

Điểm mấu chốt: gán theo nhóm chứ không theo cá nhân.

Người mới vào đội phát triển:
    → thêm vào nhóm "phat-trien" trong thư mục
    → TỰ ĐỘNG có đúng quyền
        ↓
    Không phải tạo IAM user, không phải gắn policy nào

Và permission set là IAM role được quản lý tập trung:

Permission set định nghĩa MỘT LẦN ở tài khoản quản lý
    → triển khai thành IAM role ở MỌI tài khoản được gán
        ↓
    Sửa permission set → cập nhật đồng loạt

Tạo permission set:

aws sso-admin create-permission-set   --instance-arn <arn-instance>   --name QuyenDoiPhatTrien   --session-duration PT8H

aws sso-admin put-inline-policy-to-permission-set   --instance-arn <arn-instance> --permission-set-arn <arn-ps>   --inline-policy '{
    "Version":"2012-10-17",
    "Statement":[
      {"Effect":"Allow","Action":["rds:Describe*","rds-data:ExecuteStatement"],
       "Resource":"arn:aws:rds:*:*:cluster:phat-trien-*"},
      {"Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],
       "Resource":"arn:aws:s3:::du-lieu-y-te/phat-trien/*"}]}'

Và gán cho nhóm:

aws sso-admin create-account-assignment   --instance-arn <arn-instance>   --target-id 222222222222 --target-type AWS_ACCOUNT   --permission-set-arn <arn-ps>   --principal-type GROUP --principal-id <id-nhom-phat-trien>

Và credential là TẠM THỜI:

IAM Identity Center cấp credential có hạn (mặc định 1 giờ, tối đa 12 giờ)
    → KHÔNG có access key dài hạn nào tồn tại
        ↓
    Đây là lợi ích bảo mật lớn nhất so với IAM user

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

• **B. Tạo IAM identity provider với SAML federation, gán role THỦ CÔNG cho từng người, duy trì inline policy cho mỗi role — đây là phương án gần nhất và cũng dùng danh tính liên kết, nhưng nó nhiều công quản trị hơn hẳn: gán thủ công từng người và bảo trì inline policy riêng lẻ. IAM Identity Center làm sẵn phần đó.
• **C. Tạo IAM user cho từng người với policy theo vai trò — đi ngược khuyến nghị của AWS: access key dài hạn, không có đăng nhập một lần, và phải quản lý ở mỗi tài khoản.
• **D. Dùng SCP ở cấp OU để định nghĩa ranh giới truy cập RDS và S3 theo đội — hiểu sai vai trò của SCP: SCP chỉ GIỚI HẠN quyền tối đa, nó KHÔNG CẤP quyền nào. Người dùng vẫn cần IAM policy hoặc permission set để làm được việc.

Ghi nhớ

SCP không cấp quyền — điểm quan trọng nhất:

Quyền hiệu lực = (IAM policy hoặc permission set) GIAO (SCP)
        ↓
    SCP Allow mọi thứ + không có IAM policy = KHÔNG làm được gì
    SCP Deny + IAM Allow = BỊ TỪ CHỐI
        ↓
    SCP là TRẦN, không phải nguồn cấp quyền

Ba khái niệm của IAM Identity Center: | Khái niệm | Việc | |---|---| | Identity source | nguồn danh tính: nội bộ, AD, hoặc IdP ngoài | | Permission set | tập quyền → IAM role ở tài khoản đích | | Assignment | nhóm × permission set × tài khoản |

Ba nguồn danh tính: | Nguồn | Chi tiết | |---|---| | Identity Center directory | thư mục nội bộ | | Active Directory | Managed Microsoft AD hoặc AD Connector | | IdP ngoài qua SAML/SCIM | Okta, Entra ID, Google Workspace |

SCIM đồng bộ tự động:

IdP tạo người dùng mới hoặc đổi nhóm
    → SCIM tự đồng bộ sang Identity Center
        ↓
    Không phải tạo tay ở hai nơi

Ba lợi ích so với IAM user: | Lợi ích | Chi tiết | |---|---| | Credential TẠM THỜI | không có access key dài hạn | | Đăng nhập một lần cho mọi tài khoản | | | Quản lý tập trung | |

Ba cách người dùng truy cập: | Cách | Chi tiết | |---|---| | AWS access portal | chọn tài khoản và vai trò | | AWS CLI với SSO | aws configure sso | | SDK với profile SSO | |

aws configure sso
aws sso login --profile phat-trien
aws s3 ls --profile phat-trien

Ba nguyên tắc thiết kế permission set: | Nguyên tắc | Chi tiết | |---|---| | Một permission set cho một VAI TRÒ | không phải cho một người | | Bắt đầu ít, mở rộng dần | | | Dùng managed policy của AWS khi phù hợp | ReadOnlyAccess, PowerUserAccess |

Ba cách viết policy quyền tối thiểu: | Cách | Chi tiết | |---|---| | IAM Access Analyzer policy generation | sinh policy từ CloudTrail | | Access Advisor | dịch vụ nào không dùng tới | | Bắt đầu rộng rồi thu hẹp dần | |

Policy generation rất thực dụng:

aws accessanalyzer start-policy-generation   --policy-generation-details principalArn=<arn-role>   --cloud-trail-details file://cau-hinh.json

Phân tích những gì role ĐÃ THỰC SỰ LÀM
    → sinh policy chỉ gồm quyền đó
        ↓
    Cách thực tế nhất để đạt quyền tối thiểu

Ba lớp kiểm soát quyền — bảng cần thuộc: | Lớp | Việc | |---|---| | SCP | TRẦN quyền cho cả tài khoản | | Permission set / IAM policy | CẤP quyền | | Permission boundary | trần cho một danh tính cụ thể | | Resource policy | ai truy cập được tài nguyên |

Ba lưu ý về ABAC: | Lưu ý | Chi tiết | |---|---| | Dùng tag thay vì liệt kê tài nguyên | | | Identity Center truyền attribute làm session tag | | | Một policy phục vụ nhiều đội | |

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "arn:aws:s3:::du-lieu-y-te/${aws:PrincipalTag/doi}/*"}

Một policy duy nhất, mỗi đội chỉ thấy thư mục của mình.

Ba biện pháp bảo mật cho dữ liệu y tế: | Biện pháp | Chi tiết | |---|---| | Bắt buộc MFA ở Identity Center | | | Session duration ngắn | 1–4 giờ | | CloudTrail ghi mọi thao tác | |

Ba lưu ý về Lambda và S3 event trong đề: | Lưu ý | Chi tiết | |---|---| | Lambda dùng EXECUTION ROLE riêng | không liên quan Identity Center | | Execution role cũng theo quyền tối thiểu | | | Ghi thumbnail hoặc kết quả vào bucket khác | tránh vòng lặp |

Dòng đầu là điểm dễ nhầm:

IAM Identity Center: quyền cho CON NGƯỜI
Execution role:      quyền cho DỊCH VỤ (Lambda, EC2)
        ↓
    Hai hệ thống riêng biệt

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | Rà soát assignment | hàng quý | | Chạy unused access analyzer | hàng quý | | Kiểm tra permission set còn phù hợp | |

Và một lời khuyên: hãy thiết kế ánh xạ nhóm sang permission set trước khi bắt đầu gán. Nếu để mỗi đội tự yêu cầu quyền riêng, số permission set sẽ tăng nhanh tới mức không ai rà soát nổi — và một mô hình bốn hoặc năm nhóm rõ ràng phục vụ tốt hơn nhiều so với hai chục biến thể tuỳ chỉnh.

Đáp án

D — AWS Transit Gateway.

Vì sao đúng

Đề nêu ba yêu cầu, và Transit Gateway đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | NHIỀU VPC ở NHIỀU TÀI KHOẢN | chia sẻ TGW qua AWS RAM | | Mô hình MẠNG HÌNH SAO (star) | TGW là hub trung tâm | | Nối cả on-premises qua Direct Connect | Transit VIF + Direct Connect Gateway |

Vế thứ ba là điểm phân biệt quyết định:

Transit Gateway là dịch vụ DUY NHẤT nối được cả ba loại:
    ✓ VPC (nhiều tài khoản)
    ✓ Site-to-Site VPN
    ✓ Direct Connect (qua Transit VIF)
        ↓
    VPC peering chỉ nối VPC với VPC

Và mô hình hình sao chính là kiến trúc của Transit Gateway:

            ┌── VPC A (tài khoản 1)
            ├── VPC B (tài khoản 2)
TGW ────────┼── VPC C (tài khoản 3)
            ├── VPC D
            └── Direct Connect Gateway → on-premises

Triển khai:

aws ec2 create-transit-gateway --description "TGW trung tam"   --options AutoAcceptSharedAttachments=enable

# Chia sẻ cho các tài khoản trong tổ chức
aws ram create-resource-share --name chia-se-tgw   --resource-arns <arn-tgw>   --principals arn:aws:organizations::111111111111:organization/o-abc

# Nối Direct Connect
aws directconnect create-direct-connect-gateway --name dxgw-chinh
aws ec2 create-transit-gateway-connect ...

Và phép so sánh về số kết nối:

VPC peering full mesh với n VPC:
    n × (n − 1) ÷ 2
        ↓
    10 VPC → 45 kết nối
    20 VPC → 190 kết nối

Transit Gateway:
    n attachment
        ↓
    Tăng TUYẾN TÍNH

Và peering KHÔNG bắc cầu:

A ↔ B và A ↔ C
    → B và C KHÔNG nói chuyện được
        ↓
    Đây là hạn chế thiết kế, không phải lỗi cấu hình
    → và là lý do peering không dựng được mạng hình sao

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

• **A. VPC Peering Connection — đây là phương án gần nhất và thực sự nối được VPC, nhưng nó không bắc cầu và không nối Direct Connect: mô hình hình sao bằng peering sẽ không cho các VPC nhánh nói chuyện với nhau, và peering hoàn toàn không liên quan tới Direct Connect.
• **B. Virtual Private Gateway (VGW) — chỉ gắn được MỘT VPC: mỗi VPC cần một VGW riêng, và chúng không nối được với nhau.
• **C. AWS PrivateLink — expose MỘT DỊCH VỤ, không nối mạng: PrivateLink cho phép người tiêu dùng gọi một dịch vụ cụ thể qua endpoint, nó không tạo kết nối mạng hai chiều giữa các VPC.

Ghi nhớ

Ba cách kết nối VPC — bảng phải thuộc: | | VPC Peering | Transit Gateway | PrivateLink | |---|---|---|---| | Bắc cầu | ❌ | ✅ | — | | Số kết nối với n VPC | n(n−1)/2 | n |— | | Phạm vi | nối cả MẠNG | nối cả mạng | MỘT dịch vụ | | Chiều | hai chiều | hai chiều | một chiều | | Nối VPN và Direct Connect | ❌ | ✅ | ❌ | | CIDR chồng lấn | ❌ | ❌ | ✅ được | | Băng thông | không giới hạn | 50 Gbps mỗi attachment |— | | Chi phí | chỉ phí dữ liệu | phí attachment + dữ liệu | phí endpoint |

Từ khoá nhận diện:

"many VPCs", "star/hub-and-spoke", "connect on-premises too" → Transit Gateway "two VPCs, simple, highest bandwidth" → VPC Peering "expose one service", "SaaS", "overlapping CIDR" → PrivateLink

Bốn loại attachment của Transit Gateway: | Loại | Nối tới | |---|---| | VPC attachment | một VPC | | VPN attachment | Site-to-Site VPN | | Direct Connect Gateway | on-premises qua DX | | Peering attachment | TGW ở Region khác |

Ba loại VIF của Direct Connect — nhắc lại: | Loại | Truy cập | |---|---| | Private VIF | VPC qua VGW hoặc DX Gateway | | Public VIF | dịch vụ AWS công cộng | | Transit VIF | qua Transit Gateway tới nhiều VPC |

Với TGW, dùng Transit VIF.

Ba khái niệm định tuyến của TGW: | Khái niệm | Việc | |---|---| | Association | attachment dùng route table nào để TRA CỨU | | Propagation | attachment quảng bá CIDR vào route table nào | | Static route | khai tay |

Nhiều route table cho phép cách ly:

Route table "san-xuat":  chỉ VPC sản xuất
Route table "phat-trien": chỉ VPC phát triển
    → cả hai propagate vào route table "dung-chung"
        ↓
    Sản xuất và phát triển KHÔNG nói chuyện với nhau
    nhưng cả hai tới được dịch vụ dùng chung

Đây là mẫu kiến trúc phổ biến nhất với Transit Gateway.

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Attachment cần subnet ở mỗi AZ muốn dùng | | | Nên có subnet riêng cho TGW attachment | /28 là đủ | | CIDR các VPC KHÔNG được chồng lấn | |

Ba lưu ý về chia sẻ qua RAM: | Lưu ý | Chi tiết | |---|---| | RAM MIỄN PHÍ | | | Chia sẻ cho cả OU được | không cần liệt kê tài khoản | | AutoAcceptSharedAttachments giảm thao tác | |

Ba giới hạn của Transit Gateway: | Giới hạn | Giá trị | |---|---| | Attachment mỗi TGW | 5.000 | | Băng thông mỗi VPC attachment | 50 Gbps | | Route mỗi route table | 10.000 |

Dòng giữa là lý do đôi khi vẫn dùng peering:

VPC peering: KHÔNG giới hạn băng thông
Transit Gateway: 50 Gbps mỗi attachment
        ↓
    Với luồng dữ liệu cực lớn giữa hai VPC cụ thể,
    peering vẫn có chỗ đứng

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Attachment | ~0,05 USD/giờ mỗi cái (~36 USD/tháng) | | Dữ liệu qua TGW | ~0,02 USD/GB | | — | 20 VPC ≈ 720 USD/tháng phí attachment |

Ba công cụ giám sát: | Công cụ | Việc | |---|---| | Transit Gateway Flow Logs | lưu lượng qua TGW | | Network Manager | hình dung toàn bộ mạng toàn cầu | | CloudWatch metric | băng thông, gói rớt |

Ba lựa chọn kiến trúc mạng đa tài khoản: | Lựa chọn | Đặc điểm | |---|---| | Transit Gateway | ← câu này, linh hoạt nhất | | VPC dùng chung qua RAM | ít hạ tầng lặp lại nhất | | VPC peering | chỉ cho vài VPC |

VPC dùng chung đáng cân nhắc:

Một VPC ở tài khoản mạng, chia subnet cho các tài khoản khác
    → không cần TGW, không cần peering
    → một bộ NAT, một bộ endpoint
        ↓
    Nhưng cách ly mạng yếu hơn (cùng một VPC)

Và một lời khuyên: hãy quy hoạch dải CIDR cho toàn tổ chức trước khi tạo VPC nào. Cả Transit Gateway lẫn peering đều không xử lý được CIDR chồng lấn, và việc đổi dải địa chỉ của một VPC đang chạy nghĩa là dựng lại gần như toàn bộ hạ tầng mạng bên trong.

Đáp án

B — AWS VPN CloudHub.

Vì sao đúng

Đề mô tả đúng bài toán mà VPN CloudHub được thiết kế để giải quyết:

Nhiều chi nhánh dùng Site-to-Site VPN nối vào CÙNG một VGW
    → mặc định: mỗi chi nhánh chỉ nói chuyện với VPC
    → chi nhánh KHÔNG nói chuyện với nhau
        ↓
    VPN CloudHub: cho phép các chi nhánh
      định tuyến qua VGW để nói chuyện VỚI NHAU

Kiến trúc:

San Francisco (VPN) ─┐
                     ├─→ Virtual Private Gateway ←── Los Angeles (Direct Connect)
Miami (VPN) ─────────┘         │
                               └─→ VPC
        ↓
    Mọi bên nói chuyện được với nhau và với VPC

Cơ chế:

Mỗi chi nhánh có ASN BGP RIÊNG
    → quảng bá prefix của mình lên VGW
    → VGW quảng bá lại cho các chi nhánh khác
        ↓
    Đây là mô hình hub-and-spoke ở tầng định tuyến BGP

Điều kiện bắt buộc: | Điều kiện | Chi tiết | |---|---| | Dùng BGP động | static route KHÔNG hoạt động với CloudHub | | Mỗi site có ASN riêng | | | Prefix không chồng lấn | |

Cấu hình:

aws ec2 create-customer-gateway --type ipsec.1   --public-ip 203.0.113.20 --bgp-asn 65001   # San Francisco

aws ec2 create-customer-gateway --type ipsec.1   --public-ip 203.0.113.30 --bgp-asn 65002   # Miami

# Cả hai nối vào CÙNG một VGW
aws ec2 create-vpn-connection --type ipsec.1   --customer-gateway-id cgw-sf --vpn-gateway-id vgw-abc
aws ec2 create-vpn-connection --type ipsec.1   --customer-gateway-id cgw-miami --vpn-gateway-id vgw-abc

Và ba lợi ích: | Lợi ích | Chi tiết | |---|---| | KHÔNG cần VPN giữa từng cặp chi nhánh | | | Dùng lại hạ tầng VPN đã có | | | Kết hợp được với Direct Connect | |

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

• **D. VPC Peering connection — đây là phương án gần nhất vì cũng là cơ chế kết nối, nhưng nó chỉ nối VPC với VPC: peering không nối được mạng on-premises. Chi nhánh không phải VPC.
• **A. Software VPN — tự dựng lại thứ đã có sẵn: chạy phần mềm VPN trên EC2 nghĩa là tự quản lý, tự đảm bảo sẵn sàng cao, và tự cấu hình định tuyến. VPN CloudHub là tính năng được quản lý.
• **C. VPC Endpoint — hoàn toàn không liên quan: endpoint cho phép truy cập riêng tư tới dịch vụ AWS từ trong VPC, không nối các mạng on-premises với nhau.

Ghi nhớ

AWS VPN CloudHub — ba đặc điểm cốt lõi: | Đặc điểm | Chi tiết | |---|---| | Nhiều site nối vào MỘT Virtual Private Gateway | | | Các site nói chuyện được VỚI NHAU qua VGW | ← điểm chính | | BẮT BUỘC dùng BGP động | static route không hoạt động |

Từ khoá nhận diện:

"branch offices communicate with each other AND headquarters" → VPN CloudHub "connect many VPCs and on-premises" → Transit Gateway "two VPCs" → VPC Peering

VPN CloudHub và Transit Gateway — bảng phân biệt: | | VPN CloudHub | Transit Gateway | |---|---|---| | Nối site với site | ✅ | ✅ | | Nối nhiều VPC | ❌ (một VPC) | ✅ | | Băng thông | ~1,25 Gbps mỗi tunnel | 50 Gbps mỗi attachment | | Chi phí | chỉ phí VPN | phí attachment + dữ liệu | | Phù hợp | vài chi nhánh, một VPC | nhiều VPC, quy mô lớn |

Transit Gateway là lựa chọn hiện đại hơn nếu tổ chức có nhiều VPC — nhưng với một VPC và vài chi nhánh, CloudHub đơn giản và rẻ hơn.

Ba thành phần của Site-to-Site VPN — nhắc lại: | Thành phần | Việc | |---|---| | Customer Gateway | đại diện thiết bị tại chỗ | | Virtual Private Gateway | phía AWS | | VPN Connection | đường hầm IPsec |

Ba lưu ý về BGP với CloudHub: | Lưu ý | Chi tiết | |---|---| | Mỗi site cần ASN RIÊNG | dải riêng 64512–65534 | | Prefix không chồng lấn | | | VGW quảng bá lại prefix giữa các site | |

Ba lưu ý về Direct Connect trong kiến trúc này: | Lưu ý | Chi tiết | |---|---| | Trụ sở dùng DX với Private VIF | | | Chi nhánh dùng VPN | | | Cả hai cùng nối vào VGW hoặc DX Gateway | |

Ba giới hạn của VPN CloudHub: | Giới hạn | Chi tiết | |---|---| | Băng thông giữa các site đi qua VGW | ~1,25 Gbps mỗi tunnel | | Chỉ nối được MỘT VPC | | | Độ trễ tăng vì đi qua AWS | so với đường trực tiếp |

Dòng cuối đáng cân nhắc:

San Francisco → Miami qua VGW ở AWS
    → đi vòng qua Region của AWS
        ↓
    Nếu hai chi nhánh gần nhau, đường trực tiếp có thể nhanh hơn
    → nhưng phải tự dựng và quản lý

Ba lựa chọn nối các site với nhau: | Lựa chọn | Đặc điểm | |---|---| | VPN CloudHub | dùng hạ tầng AWS sẵn có ← câu này | | Transit Gateway | mở rộng tốt hơn, nhiều VPC | | SD-WAN của bên thứ ba | qua AWS Marketplace |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TunnelState mỗi kết nối | 0 = DOWN | | TunnelDataIn/Out | lưu lượng | | — | đặt alarm cho từng tunnel riêng |

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | Mỗi VPN có 2 tunnel | cấu hình cả hai | | Thiết bị tại chỗ nên có dự phòng | | | Kết hợp DX và VPN cho trụ sở | DX chính, VPN dự phòng |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Mỗi VPN connection | ~0,05 USD/giờ (~36 USD/tháng) | | Truyền dữ liệu ra | ~0,09 USD/GB | | — | 2 chi nhánh ≈ 72 USD/tháng |

Ba việc cần kiểm tra sau khi cấu hình: | Việc | Chi tiết | |---|---| | BGP session đã lên ở mọi kết nối | | | Route của mỗi site xuất hiện ở site khác | | | Ping thử giữa hai chi nhánh | |

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-sf   --query 'VpnConnections[].VgwTelemetry[].{IP:OutsideIpAddress,
           TrangThai:Status,SoRoute:AcceptedRouteCount}'

Ba lưu ý khi mở rộng: | Lưu ý | Chi tiết | |---|---| | Trên 5–10 site, cân nhắc Transit Gateway | | | Nhiều VPC thì chắc chắn dùng TGW | | | TGW cũng hỗ trợ mô hình hub-and-spoke tương tự | |

Và một lời khuyên: hãy xác nhận cả hai chi nhánh dùng BGP động chứ không phải static route trước khi trông chờ vào CloudHub. Với static route, VPN vẫn lên bình thường và mỗi chi nhánh vẫn tới được VPC — chỉ có phần liên lạc giữa các chi nhánh là im lặng không hoạt động, và đó là thứ khó chẩn đoán nhất.

Đáp án

D — Amazon Aurora Serverless.

Vì sao đúng

Đề nêu ba yêu cầu, và Aurora Serverless đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng OLTP (giao dịch) | Aurora là database quan hệ, hỗ trợ ACID | | Cần truy vấn QUAN HỆ | SQL đầy đủ, JOIN, transaction | | Đỉnh tải KHÔNG ĐOÁN TRƯỚC | Serverless tự co giãn |

Vế thứ hai loại bỏ DynamoDB:

"needs to support RELATIONAL QUERIES"
        ↓
    DynamoDB:
        ✗ không có JOIN
        ✗ không có SQL
        ✗ truy vấn phải thiết kế trước theo khoá
        ↓
    Dù DynamoDB on-demand co giãn tốt,
    nó KHÔNG phải database quan hệ

Và Aurora Serverless v2 co giãn rất mượt:

Đo tải theo Aurora Capacity Unit (ACU)
    → tăng giảm trong VÀI GIÂY
    → bước nhảy 0,5 ACU
        ↓
    Không có thời gian ngừng khi co giãn

Cấu hình:

aws rds create-db-cluster --db-cluster-identifier cum-oltp   --engine aurora-postgresql --engine-mode provisioned   --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=64   --master-username quantri --manage-master-user-password

aws rds create-db-instance --db-instance-identifier instance-1   --db-cluster-identifier cum-oltp --engine aurora-postgresql   --db-instance-class db.serverless

db.serverless là loại instance đặc biệt — nó co giãn thay vì cố định.

Và điểm mấu chốt về chi phí:

Aurora provisioned:
    → phải chọn cỡ instance cho ĐỈNH tải
    → trả tiền cỡ đó 24/7

Aurora Serverless v2:
    → trả theo ACU-giờ THỰC TẾ dùng
        ↓
    Với tải có đỉnh không đoán trước, tiết kiệm đáng kể

Và v2 khác v1 rất nhiều: | | Serverless v1 | Serverless v2 | |---|---|---| | Co giãn | theo bậc, có gián đoạn | liên tục, vài giây | | Xuống 0 | ✅ tạm dừng được | ❌ (tối thiểu 0 ACU từ 2024) | | Hỗ trợ replica, Global Database | ❌ | ✅ | | Trạng thái | legacy | khuyến nghị |

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

• **A. DynamoDB với On-Demand Capacity — đây là phương án gần nhất và co giãn hoàn hảo với tải không đoán trước, nhưng nó không hỗ trợ truy vấn quan hệ: không JOIN, không SQL. Đề nêu rõ yêu cầu này.
• **B. DynamoDB Provisioned với Auto Scaling — cùng vấn đề quan hệ, và còn phản ứng chậm hơn với đỉnh đột ngột vì auto scaling dựa trên CloudWatch alarm.
• **C. Amazon ElastiCache — không phải database chính: đây là lớp đệm trong bộ nhớ, không lưu bền vững và không hỗ trợ giao dịch quan hệ.

Ghi nhớ

Chọn database theo hai câu hỏi — bảng phải thuộc: | Câu hỏi | Nếu "có" | |---|---| | Cần SQL, JOIN, giao dịch ACID? | RDS hoặc Aurora | | Tải khó đoán, muốn serverless? | Aurora Serverless v2 | | Không cần quan hệ, cần quy mô cực lớn? | DynamoDB |

Từ khoá nhận diện:

"relational queries", "OLTP", "unpredictable spikes" → Aurora Serverless "NoSQL", "key-value", "unpredictable" → DynamoDB on-demand "caching layer" → ElastiCache

Ba đặc điểm của Aurora Serverless v2: | Đặc điểm | Chi tiết | |---|---| | Đo bằng ACU | 1 ACU ≈ 2 GiB bộ nhớ + CPU và mạng tương ứng | | Co giãn trong VÀI GIÂY | không gián đoạn | | Hỗ trợ đầy đủ tính năng Aurora | replica, Global Database, Multi-AZ |

Ba tham số cấu hình: | Tham số | Chi tiết | |---|---| | MinCapacity | 0 tới 256 ACU | | MaxCapacity | trần khi co giãn | | — | đặt min đủ cao cho tải nền |

Đặt min quá thấp gây vấn đề:

MinCapacity = 0,5 với tải nền thật là 4 ACU
    → mỗi đợt tải tới đều phải co giãn lên
    → có độ trễ ngắn ở mỗi lần
        ↓
    Đặt min sát tải nền để phản ứng mượt hơn

Ba lợi ích của Aurora so với RDS thường: | Lợi ích | Chi tiết | |---|---| | Lưu trữ tự co giãn tới 128 TB | 6 bản sao qua 3 AZ | | Tới 15 replica, độ trễ dưới 100ms | | | Chuyển đổi thường dưới 30 giây | |

Ba loại endpoint của Aurora — nhắc lại: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance ghi | | Reader | cân bằng qua replica | | Custom | nhóm tự định nghĩa |

Ba lựa chọn co giãn cho database quan hệ: | Lựa chọn | Đặc điểm | |---|---| | Aurora Serverless v2 | tự co giãn theo tải ← câu này | | Aurora provisioned + replica auto scaling | co giãn phần ĐỌC | | RDS với đổi cỡ thủ công | có ngừng |

Ba lưu ý về mở rộng GHI: | Lưu ý | Chi tiết | |---|---| | Aurora chỉ có MỘT writer | mở rộng theo chiều dọc | | Serverless v2 tăng ACU cho writer | tự động | | Sharding ở tầng ứng dụng nếu cần hơn nữa | phức tạp |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Serverless v2 tính theo ACU-giờ | | | Đắt hơn provisioned khi tải ỔN ĐỊNH | | | Rẻ hơn khi tải dao động mạnh | ← trường hợp trong đề |

Điểm hoà vốn:

Tải chạy ở mức cao 24/7
    → provisioned rẻ hơn
Tải có đỉnh vài giờ, còn lại thấp
    → Serverless rẻ hơn đáng kể
        ↓
    Đo mức dùng thật vài tháng rồi quyết định

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ServerlessDatabaseCapacity | ACU đang dùng | | ACUUtilization | gần 100% = chạm MaxCapacity | | DatabaseConnections | |

Ba tính năng nên bật: | Tính năng | Chi tiết | |---|---| | Multi-AZ (thêm replica ở AZ khác) | sẵn sàng cao | | Backtrack (Aurora MySQL) | quay ngược thời gian không cần restore | | Performance Insights | truy vấn nào tốn tài nguyên |

Backtrack rất hữu ích:

Quay database về thời điểm vài giây trước
    → không cần khôi phục từ backup
    → mất vài phút thay vì hàng giờ
        ↓
    Cứu vãn được lỗi xoá nhầm dữ liệu

Ba lưu ý khi dùng RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Gộp kết nối | quan trọng với Lambda | | Giữ kết nối qua chuyển đổi | giảm thời gian ngừng | | Hỗ trợ Aurora Serverless v2 | |

Ba lựa chọn database serverless của AWS: | Dịch vụ | Loại | |---|---| | Aurora Serverless v2 | quan hệ | | DynamoDB on-demand | NoSQL | | Redshift Serverless | kho dữ liệu | | Neptune Serverless | đồ thị |

Và một lời khuyên: hãy đặt MinCapacity sát với tải nền thực tế thay vì để mức thấp nhất. Serverless v2 co giãn rất nhanh nhưng không tức thì, và với ứng dụng OLTP thì vài trăm mili giây chờ co giãn ở mỗi đợt tải mới cũng đủ để người dùng cảm nhận được.

Đáp án

C — Amazon GuardDuty.

Vì sao đúng

Đề mô tả chính xác loại phát hiện mà GuardDuty làm:

"EC2 instance querying IP addresses used for CRYPTOCURRENCY MINING"
        ↓
    GuardDuty có loại phát hiện riêng cho việc này:
        CryptoCurrency:EC2/BitcoinTool.B!DNS
        CryptoCurrency:EC2/BitcoinTool.B
        ↓
    Nó phân tích DNS log và VPC Flow Logs
    → so với danh sách IP và tên miền đào tiền mã hoá đã biết

Ba nguồn dữ liệu GuardDuty phân tích: | Nguồn | Phát hiện gì | |---|---| | VPC Flow Logs | kết nối tới IP đáng ngờ | | DNS logs | truy vấn tên miền độc hại ← câu này | | CloudTrail | hành vi API bất thường | | EKS audit logs, S3 data events | tuỳ chọn bổ sung |

Bật GuardDuty:

aws guardduty create-detector --enable   --finding-publishing-frequency FIFTEEN_MINUTES

Không cần cài agent, không cần bật log nào — GuardDuty đọc trực tiếp từ hạ tầng AWS.

Và bật cho cả tổ chức:

aws guardduty enable-organization-admin-account --admin-account-id 123456789012
aws guardduty update-organization-configuration --detector-id <id>   --auto-enable-organization-members ALL

Và tự động phản ứng:

{"source": ["aws.guardduty"],
 "detail-type": ["GuardDuty Finding"],
 "detail": {"severity": [{"numeric": [">=", 7]}],
            "type": [{"prefix": "CryptoCurrency"}]}}

EventBridge bắt phát hiện nghiêm trọng
    → Lambda tự động:
        ✓ cách ly instance (đổi security group)
        ✓ chụp snapshot để điều tra
        ✓ gửi cảnh báo

Và đào tiền mã hoá thường là dấu hiệu của việc bị chiếm quyền:

Instance đào tiền mà không ai cài phần mềm đó
    → gần như chắc chắn đã bị xâm nhập
        ↓
    Phải điều tra: credential bị lộ? lỗ hổng ứng dụng?
    → không chỉ dừng tiến trình đào là xong

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

• **D. AWS Shield Advanced — đây là phương án gần nhất vì cũng là dịch vụ bảo vệ nâng cao, nhưng nó chống DDoS: bảo vệ khỏi tấn công làm quá tải tài nguyên, không phát hiện hành vi bất thường bên trong instance.
• **A. AWS WAF — lọc lưu lượng HTTP VÀO ứng dụng: nó chặn SQL injection, XSS, bot. Nó không giám sát lưu lượng ĐI RA từ EC2.
• **B. AWS Firewall Manager — là công cụ QUẢN TRỊ: nó áp chính sách WAF, Shield, security group trên nhiều tài khoản. Bản thân nó không phát hiện gì.

Ghi nhớ

Các dịch vụ bảo mật của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Amazon GuardDuty | PHÁT HIỆN đe doạ: đào tiền, credential bị lộ, quét cổng | | Amazon Inspector | lỗ hổng phần mềm và CVE | | Amazon Macie | dữ liệu nhạy cảm (PII) trong S3 | | AWS Security Hub | tổng hợp phát hiện | | AWS WAF | lọc HTTP vào ứng dụng | | AWS Shield | chống DDoS | | AWS Firewall Manager | quản trị WAF/Shield/SG tập trung | | AWS Detective | điều tra sâu sau sự cố |

Bảng này bị hỏi rất nhiều — nên thuộc lòng.

Từ khoá nhận diện:

"crypto mining", "compromised credentials", "unusual API calls", "port scanning" → GuardDuty "software vulnerabilities", "CVE" → Inspector "PII in S3" → Macie "SQL injection", "XSS" → WAF "DDoS" → Shield

Ba nhóm phát hiện của GuardDuty: | Nhóm | Ví dụ | |---|---| | EC2 | đào tiền mã hoá, giao tiếp với C2 server, quét cổng | | IAM | credential dùng từ vị trí bất thường, gọi API lạ | | S3 | truy cập từ IP đáng ngờ, tắt log | | EKS, RDS, Lambda | tuỳ chọn bổ sung |

Ba tính năng bảo vệ mở rộng: | Tính năng | Việc | |---|---| | Malware Protection for EC2 | quét EBS volume tìm mã độc | | Malware Protection for S3 | quét object mới tải lên | | RDS Protection | hành vi đăng nhập bất thường | | Runtime Monitoring | agent theo dõi tiến trình trong EC2, ECS, EKS |

Runtime Monitoring rất mạnh:

Agent theo dõi tiến trình, tệp, kết nối mạng bên trong instance
    → phát hiện tiến trình đào tiền NGAY khi nó chạy
        ↓
    Không phải chờ tới khi nó gọi ra ngoài

Ba mức nghiêm trọng của phát hiện: | Mức | Điểm | |---|---| | Low | 1,0–3,9 | | Medium | 4,0–6,9 | | High | 7,0–8,9 |

Đào tiền mã hoá thường ở mức High.

Ba việc cần làm khi có phát hiện đào tiền: | Bước | Chi tiết | |---|---| | ① CÁCH LY instance | đổi sang security group chặn hết | | ② Chụp snapshot để điều tra | KHÔNG terminate ngay | | ③ Tìm đường xâm nhập | credential lộ? lỗ hổng? |

Dòng giữa quan trọng:

Chấm dứt instance ngay
    → mất toàn bộ bằng chứng
    → không biết kẻ tấn công vào bằng cách nào
        ↓
    Và họ sẽ vào lại bằng cùng đường đó

Cách ly bằng script:

aws ec2 create-security-group --group-name sg-cach-ly   --description "Chan het" --vpc-id vpc-abc
# Không thêm quy tắc nào → chặn mọi inbound

aws ec2 modify-instance-attribute --instance-id i-0abc   --groups sg-cach-ly

Ba nguyên nhân phổ biến của việc bị chiếm quyền: | Nguyên nhân | Phòng ngừa | |---|---| | Access key bị lộ (đẩy lên GitHub) | dùng IAM role, không dùng access key | | Lỗ hổng ứng dụng chưa vá | Inspector + Patch Manager | | SSH mở ra Internet với mật khẩu yếu | Session Manager |

Ba biện pháp phòng ngừa: | Biện pháp | Chi tiết | |---|---| | Bắt buộc IMDSv2 | chống SSRF lấy credential | | Không mở SSH/RDP ra Internet | dùng Session Manager | | Quét bí mật trong mã nguồn | trước khi commit |

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-tokens required --http-put-response-hop-limit 1

Ba lưu ý về chi phí GuardDuty: | Khoản | Chi tiết | |---|---| | Theo lượng log phân tích | Flow Logs, DNS, CloudTrail | | Dùng thử 30 ngày miễn phí | | | Malware Protection và Runtime Monitoring tính riêng | |

Ba cách phản ứng tự động: | Cách | Chi tiết | |---|---| | EventBridge → Lambda | cách ly, snapshot, cảnh báo | | Security Hub → automation | | | AWS Systems Manager runbook | |

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Tổng hợp phát hiện từ GuardDuty, Inspector, Macie, Config | | | Có chuẩn kiểm tra dựng sẵn | CIS, PCI DSS, AWS Foundational | | Một chỗ để xem toàn bộ tình hình bảo mật | |

Và một lời khuyên: hãy bật GuardDuty ở MỌI Region, kể cả Region bạn không dùng. Kẻ tấn công có credential thường khởi động instance đào tiền ở Region ít ai để ý — và nếu GuardDuty chỉ bật ở Region chính, hoạt động đó sẽ chạy hàng tuần trước khi ai đó phát hiện qua hoá đơn.

Đáp án

B — Cấu hình email root của mỗi tài khoản dùng alias chuyển tới một hòm thư TẬP TRUNG do quản trị viên nền tảng theo dõi; đồng thời khai alternate contact cho từng tài khoản bằng danh sách phân phối của công ty cho billing, security và operations.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án B đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Thông báo tới đúng đội theo loại | alternate contact tách billing, security, operations | | KHÔNG phụ thuộc cá nhân | danh sách phân phối, không phải email cá nhân | | Giám sát tập trung | hòm thư chung cho email root |

Alternate contact là tính năng ít người biết nhưng giải quyết đúng bài toán:

AWS gửi thông báo theo LOẠI:
    Billing:    hoá đơn, thanh toán, thay đổi giá
    Security:   cảnh báo bảo mật, lỗ hổng
    Operations: sự cố dịch vụ, bảo trì có kế hoạch
        ↓
    Mỗi loại gửi tới alternate contact tương ứng
    → thay vì dồn hết vào email root

Cấu hình:

aws account put-alternate-contact --account-id 222222222222   --alternate-contact-type BILLING   --email-address ke-toan@vidu.com   --name "Doi ke toan" --title "Billing Team"   --phone-number "+84900000001"

aws account put-alternate-contact --account-id 222222222222   --alternate-contact-type SECURITY   --email-address bao-mat@vidu.com   --name "Doi bao mat" --title "Security Team"   --phone-number "+84900000002"

aws account put-alternate-contact --account-id 222222222222   --alternate-contact-type OPERATIONS   --email-address van-hanh@vidu.com   --name "Doi van hanh" --title "Operations Team"   --phone-number "+84900000003"

Và tài khoản quản lý đặt được cho tài khoản thành viên — không phải đăng nhập từng tài khoản.

Và email root vẫn cần được theo dõi:

Một số thông báo CHỈ gửi tới email root:
    → khôi phục tài khoản
    → thay đổi quan trọng về tài khoản
        ↓
    Nên là alias chuyển tới hòm thư chung
    → nhiều người xem được, không phụ thuộc một cá nhân

Ba nguyên tắc bảo mật với tài khoản root: | Nguyên tắc | Chi tiết | |---|---| | Email root là danh sách phân phối, không phải cá nhân | | | Bật MFA phần cứng cho root | | | KHÔNG dùng root cho công việc hằng ngày | |

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

• **C. Đổi email root thành danh sách của phòng ban và cấu hình thông báo IAM theo loại dịch vụ, không dùng alternate contact — đây là phương án gần nhất và đúng phần đổi email root, nhưng nó dựa trên một thứ không tồn tại: IAM console KHÔNG có cấu hình thông báo theo loại dịch vụ. Đó chính là việc mà alternate contact làm.
• **D. Gán email root cho MỘT CÁ NHÂN ở mỗi phòng ban và khai alternate contact cũng bằng email cá nhân đó — vi phạm nguyên tắc không phụ thuộc cá nhân: người đó nghỉ việc, đi nghỉ, hoặc đổi vai trò là thông báo lại bị bỏ lỡ.
• **A. Dựng dịch vụ chuyển tiếp email tự phân loại theo từ khoá, giữ nguyên email root — giải pháp chắp vá và không tin cậy: phân loại theo từ khoá dễ sai, phải tự vận hành, trong khi AWS đã có cơ chế phân loại chính thức.

Ghi nhớ

Ba loại alternate contact của AWS — bảng phải thuộc: | Loại | Nhận thông báo về | |---|---| | BILLING | hoá đơn, thanh toán, thay đổi giá | | SECURITY | cảnh báo bảo mật, lỗ hổng, lạm dụng | | OPERATIONS | sự cố dịch vụ, bảo trì có kế hoạch |

Và loại thứ tư là primary contact — thông tin liên hệ chính của tài khoản.

Ba nguyên tắc về tài khoản root: | Nguyên tắc | Chi tiết | |---|---| | Email là DANH SÁCH PHÂN PHỐI | không phụ thuộc cá nhân | | Bật MFA, tốt nhất là phần cứng | | | Không tạo access key cho root | |

Ba việc CHỈ root làm được: | Việc | Chi tiết | |---|---| | Đóng tài khoản AWS | | | Đổi phương thức thanh toán | | | Khôi phục quyền khi khoá nhầm chính mình | | | Bật MFA Delete cho bucket S3 | | | Đăng ký một số dịch vụ đặc biệt | |

Ba lưu ý về quản lý tài khoản root ở quy mô lớn: | Lưu ý | Chi tiết | |---|---| | SCP chặn hành động root ở tài khoản thành viên | | | Centralized root access (mới) | quản lý root từ tài khoản quản lý | | Lưu credential root trong két an toàn | |

Centralized root access đáng biết:

Từ 2024, Organizations cho phép:
    → XOÁ credential root của tài khoản thành viên
    → thực hiện tác vụ root từ tài khoản quản lý khi cần
        ↓
    Không còn credential root nằm rải rác nữa

Ba cách nhận thông báo của AWS: | Cách | Chi tiết | |---|---| | Alternate contact (email) | ← câu này | | AWS Health Dashboard + EventBridge | sự kiện dịch vụ dạng có cấu trúc | | AWS User Notifications | cấu hình kênh tập trung |

AWS Health qua EventBridge mạnh hơn email:

{"source": ["aws.health"],
 "detail-type": ["AWS Health Event"],
 "detail": {"eventTypeCategory": ["issue", "scheduledChange"]}}

Sự kiện dạng có cấu trúc
    → định tuyến tới Slack, ticket system, PagerDuty
        ↓
    Không phụ thuộc ai đó đọc email

AWS User Notifications đáng dùng:

aws notifications create-notification-configuration   --name canh-bao-van-hanh   --description "Su kien Health va Budget"   --aggregation-duration SHORT

Một chỗ cấu hình cho nhiều nguồn sự kiện
    → gửi tới email, chat, mobile push
        ↓
    Hoạt động xuyên tài khoản và Region

Ba lưu ý về danh sách phân phối: | Lưu ý | Chi tiết | |---|---| | Ít nhất 2–3 người trong mỗi danh sách | | | Rà soát thành viên khi có người nghỉ việc | | | Không dùng địa chỉ cá nhân | |

Ba loại thông báo quan trọng dễ bị bỏ lỡ: | Thông báo | Hậu quả nếu bỏ lỡ | |---|---| | Chứng chỉ sắp hết hạn | dịch vụ ngừng | | Instance sắp bị retire | mất máy đột ngột | | Cảnh báo bảo mật về credential bị lộ | bị chiếm quyền |

Ba cách bổ sung để không bỏ lỡ: | Cách | Chi tiết | |---|---| | AWS Health Dashboard theo tổ chức | xem mọi tài khoản | | EventBridge chuyển sự kiện vào hệ thống ticket | | | AWS Chatbot đưa vào Slack | |

Ba lưu ý về AWS Organizations: | Lưu ý | Chi tiết | |---|---| | Tài khoản quản lý đặt alternate contact cho thành viên | | | Cần bật "all features" | | | Control Tower tự làm nhiều việc này | |

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | Kiểm tra alternate contact còn đúng | hàng quý | | Xác nhận email root nhận được thư | gửi thử | | Rà soát ai có quyền vào hòm thư chung | |

Ba biện pháp bảo vệ email root: | Biện pháp | Chi tiết | |---|---| | Địa chỉ khó đoán | không phải aws@vidu.com | | Không dùng cho việc khác | | | Bật MFA cho chính hòm thư đó | |

Và một lời khuyên: hãy gửi một email thử tới địa chỉ root của từng tài khoản sau khi cấu hình. Đây là loại thiết lập chỉ được kiểm chứng vào đúng lúc có sự cố — và phát hiện rằng alias bị cấu hình sai ngay lúc AWS gửi cảnh báo credential bị lộ là thời điểm tệ nhất có thể.

Đáp án

C — Triển khai CloudFront distribution với S3 bucket làm origin để tăng tốc tải xuống, và bật S3 Transfer Acceleration để giảm độ trễ tải lên cho người dùng toàn cầu.

Vì sao đúng

Đề nêu vấn đề ở cả hai chiều, và phương án C giải quyết đúng từng chiều: | Chiều | Giải pháp | |---|---| | TẢI XUỐNG chậm | CloudFront đệm ảnh ở edge gần người dùng | | TẢI LÊN chậm | Transfer Acceleration qua mạng riêng AWS |

CloudFront cho việc tải xuống:

Ảnh được nhiều người xem
    → lần đầu kéo từ S3, lưu ở edge location
    → những lần sau phục vụ NGAY tại edge
        ↓
    Người dùng ở Tokyo không phải chờ dữ liệu từ Region gốc

Transfer Acceleration cho việc tải lên:

Client → edge location GẦN NHẤT
    → mạng riêng, tối ưu của AWS
    → bucket S3
        ↓
    Thay vì đi Internet công cộng suốt chặng đường

Bật cả hai:

aws s3api put-bucket-accelerate-configuration   --bucket kho-anh --accelerate-configuration Status=Enabled

aws cloudfront create-distribution --origin-domain-name kho-anh.s3.ap-northeast-1.amazonaws.com

Và tải lên qua endpoint tăng tốc:

aws s3 cp anh.jpg s3://kho-anh/   --endpoint-url https://s3-accelerate.amazonaws.com

Và "minimal development effort" được thoả:

✓ không đổi kiến trúc
✓ không di chuyển dữ liệu
✓ CloudFront: chỉ đổi tên miền trong ứng dụng
✓ Transfer Acceleration: chỉ đổi endpoint khi tải lên

Và mạng riêng của AWS hiệu quả vì lý do kỹ thuật cụ thể:

TCP giảm cửa sổ khi mất gói
    → Internet công cộng mất gói nhiều hơn
    → thông lượng thực tế thấp hơn nhiều băng thông danh nghĩa
        ↓
    Mạng riêng của AWS ít mất gói → giữ được tốc độ cao

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

• **B. Bật Global Accelerator trên S3 bucket — S3 KHÔNG phải endpoint được Global Accelerator hỗ trợ: nó chỉ nhận ALB, NLB, EC2 instance và Elastic IP. Đây là phương án gần nhất về mặt ý tưởng nhưng không thực hiện được.
• **A. Di chuyển website từ S3 sang EC2 ở nhiều Region với ALB và Global Accelerator — tái kiến trúc lớn: đề nói rõ muốn "minimal development effort" và "without redesigning the application". Và chuyển từ hosting tĩnh sang EC2 là bước lùi về chi phí lẫn công vận hành.
• **D. Tạo nhiều bucket ở nhiều Region, sao chép theo vị trí người dùng, CloudFront tải lên và xuống từ bucket gần nhất — phức tạp và CloudFront không định tuyến origin theo vị trí người dùng như vậy. (S3 Multi-Region Access Point làm được điều gần giống, nhưng đó là dịch vụ khác và phương án không nêu.)

Ghi nhớ

Ba cách tăng tốc truyền dữ liệu với S3 — bảng phải thuộc: | Cách | Chiều | Cơ chế | |---|---|---| | CloudFront | xuống (và lên) | ĐỆM ở edge | | S3 Transfer Acceleration | lên và xuống | qua edge, mạng riêng AWS | | Multipart upload | lên | chia phần, song song |

Chọn theo mẫu sử dụng: | Tình huống | Chọn | |---|---| | Nhiều người TẢI XUỐNG cùng tệp | CloudFront (đệm) | | Chủ yếu TẢI LÊN từ xa | Transfer Acceleration | | Cả hai | dùng cả hai ← câu này |

Ba đặc điểm của S3 Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Endpoint riêng | <bucket>.s3-accelerate.amazonaws.com | | Phí thêm ~0,04 USD/GB | | | Tên bucket KHÔNG được chứa dấu chấm | yêu cầu kỹ thuật |

Và AWS có công cụ đo trước khi quyết định:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
  en/accelerate-speed-comparsion.html

So tốc độ có và không có Transfer Acceleration từ vị trí của bạn
    → không nhanh hơn thì KHÔNG nên trả phí

Ba lợi ích của CloudFront với S3: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp toàn cầu | đệm ở edge | | Egress RẺ HƠN so với S3 trực tiếp | | | Bảo vệ bằng OAC, WAF, signed URL | |

Dòng giữa đáng chú ý — CloudFront vừa nhanh hơn vừa rẻ hơn cho việc tải xuống nhiều.

Ba endpoint được Global Accelerator hỗ trợ: | Endpoint | Hỗ trợ | |---|---| | ALB, NLB | ✅ | | EC2 instance | ✅ | | Elastic IP | ✅ | | S3 bucket | ❌ |

Dòng cuối là lý do phương án B sai.

Global Accelerator và CloudFront — nhắc lại: | | Global Accelerator | CloudFront | |---|---|---| | Caching | ❌ | ✅ | | Giao thức | TCP và UDP | HTTP/HTTPS | | Origin S3 | ❌ | ✅ |

Ba cấu hình CloudFront nên có: | Cấu hình | Chi tiết | |---|---| | Origin Access Control (OAC) | bucket riêng tư | | Chuyển hướng HTTP sang HTTPS | | | Nén tự động | gzip, brotli |

Ba lưu ý về cache: | Lưu ý | Chi tiết | |---|---| | Dùng cache policy CachingOptimized | cho ảnh tĩnh | | Đặt Cache-Control từ S3 | | | Đưa hash vào tên tệp thay vì invalidation | |

Cách cuối tốt hơn:

Ảnh đổi → tên tệp mới (có hash)
    → URL mới → không cần vô hiệu hoá cache
        ↓
    1.000 đường dẫn invalidation miễn phí mỗi tháng,
    sau đó tính phí

Ba cách tối ưu tải lên tệp lớn: | Cách | Chi tiết | |---|---| | Multipart upload | bắt buộc trên 5 GB | | Tăng số kết nối song song | | | Presigned URL cho tải trực tiếp | không qua máy chủ |

aws configure set default.s3.multipart_chunksize 16MB
aws configure set default.s3.max_concurrent_requests 20

Ba lựa chọn khác cho người dùng toàn cầu: | Lựa chọn | Đặc điểm | |---|---| | S3 Cross-Region Replication | bản sao ở Region gần | | S3 Multi-Region Access Point | một endpoint, tự định tuyến tới bucket gần nhất | | Storage Gateway | cho văn phòng cố định |

Multi-Region Access Point đáng biết:

Một tên miền toàn cầu cho nhiều bucket ở nhiều Region
    → tự định tuyến tới bucket có độ trễ thấp nhất
    → hỗ trợ cả đọc và ghi
        ↓
    Kết hợp lợi ích của phương án D mà không phải tự quản lý

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | OAC để bucket không công khai | | | Presigned URL cho tải lên có kiểm soát | | | CloudFront signed URL cho nội dung riêng tư | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tải LÊN S3 miễn phí | chỉ phí request | | Transfer Acceleration | ~0,04 USD/GB thêm | | CloudFront egress rẻ hơn S3 egress | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate của CloudFront | hiệu quả đệm | | Thời gian tải lên trung bình | đo trước và sau | | OriginLatency | S3 phản hồi chậm |

Và một lời khuyên: hãy chạy công cụ so tốc độ của AWS từ các khu vực người dùng chính trước khi bật Transfer Acceleration. Mức cải thiện phụ thuộc hoàn toàn vào chất lượng đường mạng ở đó — có nơi nhanh gấp đôi, có nơi gần như không đổi, và phí 0,04 USD mỗi GB chỉ đáng chi ở nhóm đầu.

Đáp án

A — Elastic Fabric Adapter (EFA).

Vì sao đúng

Đề nêu từ khoá quyết định: High Performance Computing (HPC).

Tải HPC:
    → nhiều node tính toán trao đổi dữ liệu LIÊN TỤC với nhau
    → dùng MPI (Message Passing Interface)
        ↓
    Nút thắt KHÔNG phải băng thông, mà là ĐỘ TRỄ giữa các node

EFA giải quyết đúng nút thắt đó:

EFA có cơ chế OS bypass:
    → ứng dụng nói chuyện THẲNG với phần cứng mạng
    → BỎ QUA kernel của hệ điều hành
        ↓
    Độ trễ giảm đáng kể và ỔN ĐỊNH hơn
    → đúng thứ tải phân tích bộ gen cần

Và EFA là ENA cộng thêm khả năng đó:

EFA = ENA (mọi tính năng mạng thông thường)
    + giao diện OS bypass cho MPI và NCCL
        ↓
    Nghĩa là EFA làm được MỌI việc ENA làm, và hơn thế

Gắn EFA:

aws ec2 run-instances --instance-type c6i.32xlarge   --image-id ami-0abc --count 4   --network-interfaces '[{"DeviceIndex":0,"InterfaceType":"efa",
                          "SubnetId":"subnet-a","Groups":["sg-efa"]}]'   --placement GroupName=nhom-cluster

Ba điều kiện bắt buộc để EFA hoạt động: | Điều kiện | Chi tiết | |---|---| | Cluster placement group | mọi node trong CÙNG AZ, gần nhau về vật lý | | Security group cho phép MỌI lưu lượng TỚI CHÍNH NÓ | quy tắc tự tham chiếu | | Loại instance hỗ trợ EFA | c5n, c6i, m5n, p4d, hpc6a... |

Security group tự tham chiếu là chi tiết hay bị quên:

aws ec2 authorize-security-group-ingress --group-id sg-efa   --protocol -1 --source-group sg-efa
aws ec2 authorize-security-group-egress --group-id sg-efa   --protocol -1 --source-group sg-efa

Thiếu quy tắc này thì EFA gắn được nhưng MPI không chạy — và lỗi rất khó chẩn đoán.

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

• **D. Elastic Network Adapter (ENA) — đây là phương án gần nhất và là giao diện mạng hiệu năng cao mặc định của hầu hết instance hiện đại (tới 100 Gbps), nhưng nó không có OS bypass: mọi gói tin vẫn đi qua kernel, nên độ trễ giữa các node cao hơn đáng kể so với EFA. Với HPC dùng MPI, đó là khác biệt quyết định.
• **B. Elastic Network Interface (ENI) — là giao diện mạng ảo cơ bản: mọi instance đều có, nhưng nó không mang lại hiệu năng đặc biệt nào.
• **C. Elastic IP Address (EIP) — là địa chỉ IP tĩnh, hoàn toàn không liên quan tới hiệu năng mạng nội bộ giữa các node.

Ghi nhớ

Ba loại giao diện mạng của EC2 — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | ENI | giao diện ảo cơ bản, mọi instance đều có | | ENA | hiệu năng cao, tới 100 Gbps | | EFA | ENA + OS bypass cho HPC và học máy phân tán |

Từ khoá nhận diện:

"HPC", "MPI", "tightly coupled", "distributed ML training" → EFA "high network throughput" → ENA "static public IP" → Elastic IP

Hai trường hợp dùng EFA: | Trường hợp | Thư viện | |---|---| | HPC | MPI (Message Passing Interface) | | Học máy phân tán | NCCL (NVIDIA Collective Communications Library) |

Ba loại placement group: | Loại | Đặc điểm | |---|---| | Cluster | cùng AZ, độ trễ thấp nhất, băng thông cao nhất ← cho EFA | | Spread | trải trên phần cứng khác nhau, tối đa 7 instance mỗi AZ | | Partition | nhóm phân vùng, cho HDFS, Cassandra |

Cluster placement group là bắt buộc cho EFA:

aws ec2 create-placement-group --group-name nhom-cluster --strategy cluster

Ba lưu ý về cluster placement group: | Lưu ý | Chi tiết | |---|---| | Mọi instance trong MỘT AZ | không chịu lỗi AZ | | Nên khởi động tất cả CÙNG LÚC | tránh thiếu năng lực giữa chừng | | Dùng cùng loại instance | khả năng thành công cao hơn |

Ba họ instance cho HPC: | Họ | Đặc điểm | |---|---| | hpc6a, hpc7a | tối ưu riêng cho HPC, EFA sẵn | | c5n, c6in | tính toán, mạng 100 Gbps | | p4d, p5 | GPU cho học máy, EFA sẵn |

Ba dịch vụ hỗ trợ HPC trên AWS: | Dịch vụ | Việc | |---|---| | AWS ParallelCluster | dựng cụm HPC bằng cấu hình, hỗ trợ Slurm | | AWS Batch | xử lý theo lô có hàng đợi | | FSx for Lustre | hệ thống tệp thông lượng cao cho HPC |

ParallelCluster đáng biết:

Một tệp cấu hình YAML
    → dựng head node, compute fleet, scheduler, FSx for Lustre
    → tự co giãn số node theo hàng đợi công việc
        ↓
    Đội nghiên cứu dùng Slurm như trên cụm tại chỗ

Ba thành phần điển hình của cụm HPC trên AWS: | Thành phần | Dịch vụ | |---|---| | Tính toán | EC2 với EFA trong cluster placement group | | Lưu trữ chia sẻ | FSx for Lustre (liên kết S3) | | Dữ liệu gốc và kết quả | S3 |

FSx for Lustre rất phù hợp:

Liên kết bucket S3:
    → tự nạp dữ liệu khi node đọc (lazy loading)
    → ghi kết quả ngược lại S3
        ↓
    Dựng cụm theo đợt, xoá sau khi xong
    → chỉ trả tiền trong thời gian tính toán

Ba cách kiểm chứng EFA hoạt động: | Cách | Lệnh | |---|---| | Kiểm tra thiết bị | fi_info -p efa | | Kiểm tra ENI | describe-network-interfaces xem InterfaceType | | Đo băng thông và độ trễ | osu_latency, osu_bw |

fi_info -p efa
# provider: efa
#     fabric: EFA-fe80::...

Ba lưu ý về chi phí HPC: | Lưu ý | Chi tiết | |---|---| | EFA KHÔNG tính phí thêm | chỉ trả giá instance | | Spot cho tải chịu gián đoạn | tiết kiệm tới 90% | | Dựng cụm theo đợt rồi xoá | không để chạy không |

Ba lưu ý về thư viện: | Lưu ý | Chi tiết | |---|---| | Cần cài EFA installer | gồm libfabric và Open MPI | | Dùng bản MPI hỗ trợ libfabric | | | AWS có AMI dựng sẵn cho HPC | tiết kiệm thời gian |

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

Ba lưu ý khi di chuyển HPC lên đám mây: | Lưu ý | Chi tiết | |---|---| | Đo hiệu năng thật, đừng chỉ so thông số | | | Kiểm tra giấy phép phần mềm HPC | | | Cân nhắc ParallelCluster thay vì tự dựng | |

Và một lời khuyên: hãy kiểm tra quy tắc tự tham chiếu của security group đầu tiên khi EFA gắn được mà MPI không chạy. Đó là nguyên nhân phổ biến nhất, và triệu chứng — job treo ở bước khởi tạo mà không có lỗi rõ ràng — trông giống hệt một vấn đề cấu hình MPI.