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

Đáp án

C — Dùng AWS Config để rà soát cấu hình tài nguyên theo hướng dẫn tuân thủ và lưu lịch sử thay đổi cấu hình.

Vì sao đúng

Đề nêu hai yêu cầu, và AWS Config được thiết kế đúng cho cả hai: | Yêu cầu | Cơ chế | |---|---| | Rà soát cấu hình theo hướng dẫn TUÂN THỦ | Config rule đánh giá liên tục | | Xem LỊCH SỬ cấu hình tài nguyên | Config ghi lại mọi thay đổi theo thời gian |

AWS Config làm gì:

Config LIÊN TỤC ghi lại:
    ✓ cấu hình hiện tại của mọi tài nguyên được hỗ trợ
    ✓ MỌI thay đổi cấu hình theo thời gian
    ✓ quan hệ giữa các tài nguyên
        ↓
    Và đánh giá chúng theo các RULE bạn định nghĩa

Bật Config:

aws configservice put-configuration-recorder   --configuration-recorder name=ghi-cau-hinh,roleARN=<arn-role>   --recording-group allSupported=true,includeGlobalResourceTypes=true

aws configservice put-delivery-channel   --delivery-channel name=kenh-giao,s3BucketName=kho-config

aws configservice start-configuration-recorder   --configuration-recorder-name ghi-cau-hinh

Và thêm managed rule:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "s3-phai-ma-hoa",
  "Source": {"Owner":"AWS",
             "SourceIdentifier":"S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"}}'

Và xem lịch sử cấu hình — đây là khả năng riêng của Config:

aws configservice get-resource-config-history   --resource-type AWS::EC2::SecurityGroup   --resource-id sg-0abc123

Trả về:
    ✓ mọi phiên bản cấu hình của security group đó
    ✓ thời điểm mỗi thay đổi
    ✓ nội dung thay đổi cụ thể

Và AWS có hơn 300 managed rule sẵn — không phải viết mã cho các kiểm tra phổ biến.

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

• **B. Dùng AWS CloudTrail để rà soát cấu hình và lưu lịch sử — đây là phương án gần nhất và CloudTrail thực sự ghi lại thay đổi, nhưng nó ghi loại thông tin khác: CloudTrail ghi AI đã gọi API NÀO, LÚC NÀO — nó không cho biết trạng thái cấu hình tại một thời điểm hay đánh giá tuân thủ. Muốn biết "security group này lúc 10 giờ sáng thứ Ba trông thế nào", CloudTrail không trả lời được.
• **D. Dùng AWS Systems Manager — sai phạm vi: SSM quản lý instance (vá lỗi, chạy lệnh, kiểm kê phần mềm), nó không đánh giá cấu hình của mọi loại tài nguyên AWS.
• **A. Dùng Amazon CloudWatch — sai loại dữ liệu: CloudWatch theo dõi metric và log vận hành (CPU, độ trễ, lỗi), không phải cấu hình tài nguyên.

Ghi nhớ

Ba dịch vụ ghi lại hoạt động — bảng phải thuộc: | Dịch vụ | Ghi gì | |---|---| | AWS Config | TRẠNG THÁI CẤU HÌNH và lịch sử thay đổi + đánh giá tuân thủ | | AWS CloudTrail | AI GỌI API NÀO, lúc nào, từ đâu | | Amazon CloudWatch | METRIC và LOG vận hành |

Ba câu hỏi và dịch vụ trả lời:

"Ai đã sửa security group này?"          → CloudTrail
"Security group này trông thế nào tuần trước?" → Config
"CPU của instance lúc đó bao nhiêu?"      → CloudWatch

Ba khả năng của AWS Config: | Khả năng | Chi tiết | |---|---| | Configuration recorder | ghi trạng thái mọi tài nguyên liên tục | | Config rules | đánh giá tuân thủ tự động | | Configuration timeline | xem lịch sử của một tài nguyên | | Remediation | tự sửa vi phạm |

Ba loại Config rule: | Loại | Chi tiết | |---|---| | AWS managed rule | hơn 300 rule viết sẵn | | Custom rule (Lambda) | logic tuỳ ý | | Custom rule (Guard) | dùng ngôn ngữ CloudFormation Guard |

Managed rule hay dùng: | Rule | Kiểm tra | |---|---| | S3_BUCKET_PUBLIC_READ_PROHIBITED | bucket không công khai | | RDS_STORAGE_ENCRYPTED | database được mã hoá | | INCOMING_SSH_DISABLED | không mở SSH ra Internet | | ACM_CERTIFICATE_EXPIRATION_CHECK | chứng chỉ sắp hết hạn | | IAM_USER_MFA_ENABLED | user có MFA |

Hai chế độ kích hoạt rule: | Chế độ | Khi nào chạy | |---|---| | Configuration change | ngay khi tài nguyên thay đổi | | Periodic | theo chu kỳ (1, 3, 6, 12, 24 giờ) |

Ba cách khắc phục vi phạm: | Cách | Chi tiết | |---|---| | Auto remediation với SSM Automation | tự sửa | | EventBridge → Lambda | logic tuỳ chỉnh | | Chỉ thông báo | cho con người xử lý |

Auto remediation:

aws configservice put-remediation-configurations   --remediation-configurations '[{
    "ConfigRuleName": "s3-phai-ma-hoa",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-EnableS3BucketEncryption",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3}]'

Ba khái niệm nâng cao: | Khái niệm | Việc | |---|---| | Conformance pack | gói nhiều rule theo một chuẩn (PCI, HIPAA, CIS) | | Aggregator | gộp dữ liệu từ nhiều tài khoản và Region | | Advanced query | truy vấn SQL trên cấu hình tài nguyên |

Advanced query rất mạnh:

SELECT resourceId, resourceType, configuration.instanceType
WHERE resourceType = 'AWS::EC2::Instance'
  AND configuration.instanceType = 'm4.large'

Tìm mọi instance thế hệ cũ trong toàn tổ chức bằng một câu truy vấn.

Ba lưu ý cho tổ chức nhiều tài khoản: | Lưu ý | Chi tiết | |---|---| | Dùng Aggregator | gộp về một chỗ xem | | Bật Config ở MỌI Region | kể cả Region không dùng | | Conformance pack triển khai qua StackSets | nhất quán |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Configuration item được ghi | ~0,003 USD mỗi item | | Đánh giá rule | ~0,001 USD mỗi lần | | Conformance pack | tính theo số đánh giá |

Chi phí có thể lớn với tài khoản nhiều tài nguyên thay đổi liên tục:

Giảm chi phí bằng cách:
    ✓ chỉ ghi các loại tài nguyên quan trọng
    ✓ dùng periodic thay vì change-triggered cho rule ít quan trọng

Ba dịch vụ bổ sung cho tuân thủ: | Dịch vụ | Việc | |---|---| | AWS Config | cấu hình và lịch sử ← câu này | | Security Hub | tổng hợp finding theo chuẩn | | AWS Audit Manager | thu thập bằng chứng cho kiểm toán |

Audit Manager đáng biết với dịch vụ tài chính:

Audit Manager tự thu thập bằng chứng từ Config, CloudTrail, Security Hub
    → ánh xạ vào khung tuân thủ (SOC 2, PCI DSS, ISO 27001)
    → sinh báo cáo cho kiểm toán viên

Và một lời khuyên: hãy bật Config cho MỌI Region ngay cả những Region không dùng. Kẻ tấn công thường tạo tài nguyên ở Region ít ai nhìn tới — và Config ở đó vừa phát hiện được, vừa cho bạn lịch sử đầy đủ khi cần điều tra.

Đáp án

C — Chọn cluster placement group khi khởi động EC2 instance.

Vì sao đúng

Đề nêu từ khoá quyết định: "tightly coupled node-to-node communications" trong tải HPC.

Ứng dụng HPC ghép chặt:
    → các node TRAO ĐỔI DỮ LIỆU LIÊN TỤC với nhau
    → thường dùng MPI (Message Passing Interface)
    → mỗi bước tính toán cần đồng bộ giữa mọi node
        ↓
    ĐỘ TRỄ MẠNG giữa các node là yếu tố quyết định hiệu năng

Và cluster placement group tối ưu đúng điều đó:

Cluster placement group:
    → đặt instance RẤT GẦN NHAU về mặt vật lý
    → cùng một rack hoặc các rack liền kề trong MỘT AZ
        ↓
    ✓ độ trễ mạng THẤP NHẤT
    ✓ băng thông tới 100 Gbps giữa các instance
    ✓ tỷ lệ mất gói gần như bằng 0

Và đề nêu rõ instance đang dùng "default options":

Mặc định KHÔNG có placement group
    → instance được đặt rải rác trong AZ
    → độ trễ giữa các node không tối ưu
        ↓
    Đây chính là điểm cần cải thiện

aws ec2 create-placement-group --group-name cum-hpc --strategy cluster

aws ec2 run-instances --image-id ami-0abc --instance-type hpc7a.96xlarge   --count 16 --placement GroupName=cum-hpc   --network-interfaces '[{"DeviceIndex":0,"InterfaceType":"efa","SubnetId":"subnet-a"}]'

Và InterfaceType: efa là bổ sung quan trọng:

Elastic Fabric Adapter (EFA):
    → ứng dụng MPI nói chuyện TRỰC TIẾP với phần cứng mạng
    → bỏ qua kernel của hệ điều hành
    → độ trễ dưới 20 micro giây

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

• **B. Chọn dedicated instance tenancy — đây là phương án gần nhất vì nó cũng liên quan tới cách đặt instance trên phần cứng, nhưng nó giải quyết vấn đề khác: dedicated tenancy đảm bảo phần cứng không chia sẻ với khách hàng khác — đó là yêu cầu tuân thủ, không phải tối ưu độ trễ mạng.
• **A. Chọn capacity reservation phù hợp — đảm bảo có năng lực, không cải thiện hiệu năng: nó giữ chỗ để chắc chắn khởi động được instance, nhưng không đặt chúng gần nhau.
• **D. Chọn Elastic Inference accelerator — sai loại tải: Elastic Inference tăng tốc suy luận học máy bằng cách gắn thêm năng lực GPU phân đoạn. Nó không liên quan tới hiệu năng mạng. (Dịch vụ này cũng đã ngừng nhận khách hàng mới.)

Ghi nhớ

Ba loại placement group — bảng phải thuộc: | Loại | Mục tiêu | Phạm vi | Giới hạn | |---|---|---|---| | Cluster | độ trễ thấp, thông lượng cao | MỘT AZ | nên dùng cùng loại instance | | Spread | tối đa hoá cách ly lỗi | nhiều AZ | 7 instance mỗi AZ | | Partition | giới hạn phạm vi ảnh hưởng | nhiều AZ | 7 phân vùng mỗi AZ |

Từ khoá nhận diện:

"HPC", "MPI", "tightly coupled", "low latency between nodes" → cluster "critical instances must not share hardware" → spread "HDFS", "Cassandra", "Kafka", "large distributed workload" → partition

Ba đặc điểm của cluster placement group: | Đặc điểm | Chi tiết | |---|---| | Một AZ duy nhất | đánh đổi: AZ hỏng là mất cả cụm | | Nên dùng CÙNG loại instance | giảm nguy cơ thiếu năng lực | | Khởi động HẾT trong MỘT lời gọi API | |

Dòng cuối là lời khuyên vận hành quan trọng:

Khởi động từng máy một:
    → có thể hết năng lực giữa chừng
    → nhận lỗi InsufficientInstanceCapacity
        ↓
Khởi động cả 16 máy trong MỘT lời gọi:
    → AWS tìm đủ chỗ trước khi bắt đầu

ENA và EFA — bảng phân biệt: | | ENA | EFA | |---|---|---| | Băng thông | tới 100+ Gbps | tương đương | | Bỏ qua kernel (OS bypass) | ❌ | ✅ | | Độ trễ | vài chục micro giây | dưới 20 micro giây | | Hỗ trợ MPI và NCCL | ❌ | ✅ | | Hệ điều hành | mọi loại | CHỈ LINUX |

EFA là lựa chọn chuẩn cho HPC — nhưng chỉ chạy trên Linux.

Ba nhóm instance cho HPC: | Nhóm | Tối ưu | |---|---| | hpc6a, hpc7a, hpc7g | thiết kế riêng cho HPC, giá theo lõi tốt nhất | | c6in, c7gn | mạng băng thông rất cao | | p5, p4d | GPU cho học máy |

Họ hpc* đáng biết: giá theo hiệu năng tốt hơn và không tính phí truyền dữ liệu giữa các instance trong cùng placement group.

Ba thành phần của cụm HPC hoàn chỉnh: | Thành phần | Lựa chọn | |---|---| | Tính toán | EC2 trong cluster placement group + EFA | | Lưu trữ chia sẻ | FSx for Lustre | | Bộ lập lịch | AWS ParallelCluster (Slurm) hoặc AWS Batch |

AWS ParallelCluster đáng biết:

ParallelCluster:
    ✓ dựng cụm HPC hoàn chỉnh từ một tệp cấu hình
    ✓ TỰ cấu hình placement group, EFA và FSx for Lustre
    ✓ tích hợp Slurm — quen thuộc với giới nghiên cứu
    ✓ tự co giãn node theo hàng đợi công việc

Ba lưu ý khi dùng placement group: | Lưu ý | Chi tiết | |---|---| | Có thể gặp InsufficientInstanceCapacity | cụm càng lớn càng dễ | | Chuyển instance đang chạy vào group phải STOP trước | | | Không trộn nhiều loại instance | tăng nguy cơ thiếu chỗ |

Và Capacity Reservation kết hợp được với placement group:

aws ec2 create-capacity-reservation --instance-type hpc7a.96xlarge   --instance-platform Linux/UNIX --availability-zone ap-northeast-1a   --instance-count 16 --placement-group-arn <arn-placement-group>

Với cụm lớn chạy vào thời điểm cố định, đặt trước năng lực tránh thất bại vào đúng lúc cần.

Ba lưu ý về chi phí HPC: | Lưu ý | Chi tiết | |---|---| | Spot rất phù hợp nếu có checkpoint | giảm tới 90% | | Truyền dữ liệu trong placement group | thường miễn phí với họ hpc* | | Tắt cụm khi không chạy | HPC là tải theo đợt |

Ba cách kiểm chứng cải thiện: | Cách | Chi tiết | |---|---| | Đo độ trễ bằng ping hoặc bài kiểm tra MPI | trước và sau | | Đo thông lượng bằng iperf | | | Đo thời gian hoàn thành công việc thật | chỉ số cuối cùng |

Ba metric mạng cần theo dõi: | Metric | Ý nghĩa | |---|---| | NetworkPacketsIn/Out | lưu lượng | | NetworkIn/Out | băng thông | | Metric ở tầng ứng dụng | thời gian đồng bộ giữa các node |

Và một lời khuyên: hãy thêm EFA cùng lúc với cluster placement group. Placement group đặt máy gần nhau về mặt vật lý, nhưng nếu ứng dụng MPI vẫn đi qua ngăn xếp mạng của kernel thì phần lớn lợi ích bị mất — hai thứ này bổ sung nhau và thường được cấu hình cùng nhau.

Đáp án

D — Dùng VPC peering connection.

Vì sao đúng

Đề mô tả tình huống đơn giản: 5 VPC trong CÙNG một tài khoản cần nói chuyện với nhau, và hỏi cách tiết kiệm nhất.

VPC peering:
    ✓ MIỄN PHÍ tạo kết nối
    ✓ chỉ trả phí truyền dữ liệu chéo AZ (nếu có)
    ✓ độ trễ thấp, băng thông cao
        ↓
    Không có phí theo giờ như Transit Gateway

So sánh chi phí: | Cách | Chi phí | |---|---| | VPC peering | MIỄN PHÍ kết nối | | Transit Gateway | ~0,05 USD/giờ mỗi attachment (~36 USD/tháng) | | PrivateLink | ~0,01 USD/giờ mỗi ENI + phí dữ liệu |

Với 5 VPC dùng Transit Gateway:

5 attachment × 36 USD = 180 USD/tháng
    → chỉ riêng phí attachment

Còn peering thì miễn phí:

aws ec2 create-vpc-peering-connection   --vpc-id vpc-billing --peer-vpc-id vpc-operations

aws ec2 accept-vpc-peering-connection   --vpc-peering-connection-id pcx-0abc

aws ec2 create-route --route-table-id rtb-billing   --destination-cidr-block 10.1.0.0/16   --vpc-peering-connection-id pcx-0abc

Và với quy mô 5 VPC, hạn chế "không bắc cầu" của peering vẫn quản lý được:

5 VPC full-mesh = 5×4/2 = 10 kết nối peering
    → quản lý được, dù hơi thủ công
        ↓
    Nhưng nếu tăng lên 20 VPC:
    20×19/2 = 190 kết nối → Transit Gateway đáng giá hơn

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

• **B. Dùng AWS Direct Connect — đây là phương án gần nhất vì nó cũng là một dịch vụ kết nối mạng, nhưng nó sai mục đích hoàn toàn: Direct Connect nối AWS với trung tâm dữ liệu TẠI CHỖ, không nối các VPC với nhau. Và nó là lựa chọn đắt nhất, mất hàng tuần để lắp đặt.
• **A. Dùng NAT gateway — sai chức năng: NAT gateway cho instance ở private subnet đi ra Internet, nó không kết nối hai VPC.
• **C. Dùng Internet Gateway — sai chức năng và không riêng tư: IGW cho lưu lượng ra vào Internet. Cho các VPC nói chuyện qua Internet công cộng vừa kém an toàn vừa tốn phí truyền dữ liệu.

Ghi nhớ

Bốn cách kết nối VPC — bảng phải thuộc: | Cách | Chi phí kết nối | Bắc cầu | Phù hợp | |---|---|---|---| | VPC peering | MIỄN PHÍ | ❌ KHÔNG | ít VPC ← câu này | | Transit Gateway | theo giờ + theo GB | ✅ | nhiều VPC | | VPC sharing (RAM) | MIỄN PHÍ | cùng một VPC | nhiều đội, một tài khoản mạng | | PrivateLink | theo giờ + theo GB | một chiều | phơi một dịch vụ |

Từ khoá nhận diện:

"cheapest", "few VPCs", "same account" → VPC peering "many VPCs", "hub-and-spoke", "transitive" → Transit Gateway "expose one service one-way" → PrivateLink

Hạn chế "không bắc cầu" của peering:

VPC-A ⟷ VPC-B (peering)
VPC-B ⟷ VPC-C (peering)
        ↓
    A KHÔNG nói chuyện được với C
    → phải thêm peering A ⟷ C
        ↓
    N VPC cần N×(N−1)/2 kết nối

Bảng số kết nối theo số VPC: | Số VPC | Số kết nối peering | |---|---| | 3 | 3 | | 5 | 10 ← câu này | | 10 | 45 | | 20 | 190 |

Điểm chuyển đổi thường là khoảng 5–10 VPC — trên đó thì Transit Gateway đáng giá hơn dù có phí.

Ba đặc điểm của VPC peering: | Đặc điểm | Chi tiết | |---|---| | CIDR KHÔNG được chồng lấn | ràng buộc cứng | | Không bắc cầu | | | Xuyên Region và xuyên tài khoản được | |

Ba bước thiết lập peering:

① Bên yêu cầu tạo peering connection
② Bên kia CHẤP NHẬN
③ CẢ HAI bên thêm route vào bảng định tuyến

Bước ba hay bị quên — peering ở trạng thái active nhưng không có route thì không có lưu lượng nào đi qua.

Ba lưu ý về chi phí peering: | Khoản | Chi tiết | |---|---| | Tạo kết nối | MIỄN PHÍ | | Truyền dữ liệu trong CÙNG AZ | miễn phí | | Truyền dữ liệu CHÉO AZ | ~0,01 USD/GB mỗi chiều | | Truyền xuyên Region | ~0,02 USD/GB |

Ba hạn chế khác của peering: | Hạn chế | Chi tiết | |---|---| | Không dùng chung Internet Gateway hay NAT | mỗi VPC tự lo | | Không dùng chung VPC endpoint | | | DNS resolution phải bật tường minh | |

Bật DNS resolution qua peering:

aws ec2 modify-vpc-peering-connection-options   --vpc-peering-connection-id pcx-0abc   --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true   --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

Không bật thì tên miền private hosted zone không phân giải qua peering được.

Ba lựa chọn khi số VPC tăng: | Lựa chọn | Chi tiết | |---|---| | Transit Gateway | hub-and-spoke, bắc cầu | | VPC sharing | hợp nhất về ít VPC hơn | | Giữ peering | nếu số VPC vẫn ít |

VPC sharing đáng cân nhắc cho tình huống này:

5 nhân viên, mỗi người một VPC:
    → thực ra có cần 5 VPC không?
        ↓
    VPC sharing: MỘT VPC, chia subnet cho từng người
    → không cần kết nối gì
    → tiết kiệm NAT gateway và VPC endpoint

Ba lưu ý về CIDR: | Lưu ý | Chi tiết | |---|---| | KHÔNG được chồng lấn | cả với peering lẫn Transit Gateway | | Lập kế hoạch từ đầu | đổi CIDR sau rất khó | | Ghi tài liệu bản đồ CIDR | |

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | kiểm tra đường đi giữa hai VPC | | VPC Flow Logs | thấy lưu lượng bị từ chối | | Route table | kiểm tra route đã thêm chưa |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Security group tham chiếu SG xuyên VPC được | nếu cùng Region và cùng tài khoản | | Chỉ thêm route cho dải cần thiết | không mở toàn bộ CIDR | | NACL vẫn áp dụng | |

Và một lời khuyên cho công ty nhỏ: hãy cân nhắc hợp nhất 5 VPC thành một với các subnet riêng cho từng ứng dụng. Với 5 nhân viên trong cùng một tài khoản, việc tách VPC thường không mang lại lợi ích bảo mật thật sự mà lại nhân năm chi phí NAT gateway và VPC endpoint — và security group đã đủ để cách ly giữa các ứng dụng.

Đáp án

B và C.

• B — Dùng S3 Batch Replication để sao chép object sang bucket ở Region khác qua console, rồi xoá cấu hình replication
• C — Sao chép dữ liệu bằng lệnh aws s3 sync

Vì sao đúng

Đề nêu ba ràng buộc, và hai đáp án là hai cách khả thi: | Ràng buộc | Ảnh hưởng | |---|---| | 1 PB dữ liệu | cần công cụ xử lý được khối lượng lớn | | Sao chép MỘT LẦN | không cần cơ chế đồng bộ liên tục | | KHÔNG dùng được Snowball | loại mọi giải pháp vật lý |

B — S3 Batch Replication cho dữ liệu ĐÃ CÓ:

S3 Replication thông thường CHỈ áp cho object MỚI
    → object đã có trong bucket KHÔNG được sao chép
        ↓
S3 Batch Replication:
    → sao chép object ĐÃ TỒN TẠI
    → dùng chính cấu hình replication
    → xử lý được hàng tỷ object

aws s3control create-job --account-id 123456789012   --operation '{"S3ReplicateObject":{}}'   --manifest-generator '{"S3JobManifestGenerator":{
    "SourceBucket":"arn:aws:s3:::kho-west",
    "EnableManifestOutput":false,
    "Filter":{"ObjectReplicationStatuses":["NONE"]}}}'   --priority 10 --role-arn <arn> --no-confirmation-required

Xong việc thì xoá cấu hình replication — vì đây là sao chép một lần.

C — aws s3 sync là cách đơn giản và hiệu quả:

aws s3 sync s3://kho-west-1/ s3://kho-east-1/   --source-region us-west-1 --region us-east-1

Lợi ích:
    ✓ chạy song song nhiều luồng
    ✓ tự bỏ qua object đã có
    ✓ chạy lại được nếu bị gián đoạn
    ✓ sao chép SERVER-SIDE — dữ liệu không đi qua máy của bạn

Điểm cuối rất quan trọng với 1 PB:

aws s3 sync giữa hai bucket:
    → S3 sao chép TRỰC TIẾP giữa hai Region
    → dữ liệu KHÔNG tải về máy chạy lệnh
        ↓
    Chỉ tốn phí truyền xuyên Region, không tốn băng thông của bạn

Và tăng tốc bằng cách chỉnh tham số:

aws configure set default.s3.max_concurrent_requests 100
aws configure set default.s3.max_queue_size 10000

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

• **E. Sao chép từ bucket nguồn sang bucket đích bằng console S3 — đây là phương án gần nhất và về mặt kỹ thuật là sao chép được, nhưng nó không khả thi với 1 PB: console phù hợp cho vài chục hoặc vài trăm object, không phải hàng triệu. Không có cơ chế tiếp tục khi gián đoạn, không chạy song song, và trình duyệt sẽ không chịu nổi.
• **D. Dùng S3 Transfer Acceleration để sao chép giữa các bucket qua console — sai mục đích: S3TA tăng tốc việc tải lên từ client ở xa vào S3, nó không phải cơ chế sao chép giữa hai bucket.
• **A. Dùng Snowball Edge để sao chép giữa hai Region — đề đã loại trừ: trung tâm dữ liệu không cho dùng Snowball. Và Snowball dùng để chuyển dữ liệu giữa tại chỗ và AWS, không phải giữa hai Region của AWS.

Ghi nhớ

Ba cách sao chép dữ liệu giữa hai bucket S3: | Cách | Phù hợp | |---|---| | S3 Replication (CRR/SRR) | object MỚI, liên tục | | S3 Batch Replication | object ĐÃ CÓ, một lần ← câu này | | aws s3 sync hoặc S3 Batch Operations Copy | linh hoạt, một lần ← câu này |

Điểm mấu chốt: Replication chỉ áp cho object MỚI.

Bật replication:
    → chỉ object được ghi SAU đó mới được sao chép
    → object cũ nằm im
        ↓
    Phải dùng Batch Replication hoặc sync cho dữ liệu cũ

Ba yêu cầu của S3 Replication: | Yêu cầu | Chi tiết | |---|---| | Versioning BẬT ở CẢ HAI bucket | bắt buộc | | IAM role có quyền đọc nguồn và ghi đích | | | Với SSE-KMS: cần quyền KMS ở cả hai Region | hay bị quên |

Ba loại replication: | Loại | Chi tiết | |---|---| | Cross-Region Replication (CRR) | khác Region ← câu này | | Same-Region Replication (SRR) | cùng Region, khác bucket hoặc tài khoản | | Replication Time Control (RTC) | cam kết 99,99% object sao chép trong 15 phút |

Ba lựa chọn của S3 Batch Operations: | Thao tác | Việc | |---|---| | S3ReplicateObject | dùng cấu hình replication | | S3PutObjectCopy | sao chép trực tiếp, tuỳ chỉnh lớp lưu trữ | | S3PutObjectTagging, S3PutObjectAcl | gắn thẻ, đổi ACL | | LambdaInvoke | xử lý tuỳ chỉnh từng object |

S3PutObjectCopy linh hoạt hơn:

aws s3control create-job --account-id 123456789012   --operation '{"S3PutObjectCopy":{
    "TargetResource":"arn:aws:s3:::kho-east-1",
    "StorageClass":"GLACIER_IR"}}'   --manifest '{"Spec":{"Format":"S3InventoryReport_CSV_20161130"},
               "Location":{"ObjectArn":"<arn-inventory>","ETag":"..."}}'   --priority 10 --role-arn <arn> --report ... --no-confirmation-required

Cho phép đổi lớp lưu trữ ngay khi sao chép — hữu ích nếu bản sao dùng để lưu trữ.

Ba cách tạo manifest cho Batch Operations: | Cách | Chi tiết | |---|---| | S3 Inventory report | tự sinh, phù hợp cho hàng tỷ object | | Tệp CSV tự tạo | kiểm soát danh sách chính xác | | Manifest generator | lọc theo trạng thái replication |

S3 Inventory rất hữu ích với 1 PB:

aws s3api put-bucket-inventory-configuration --bucket kho-west-1   --id kiem-ke --inventory-configuration '{
    "Destination":{"S3BucketDestination":{
      "Bucket":"arn:aws:s3:::kho-bao-cao","Format":"CSV"}},
    "IsEnabled":true,"IncludedObjectVersions":"Current",
    "Schedule":{"Frequency":"Daily"}}'

Ba lưu ý về aws s3 sync: | Lưu ý | Chi tiết | |---|---| | Sao chép SERVER-SIDE | dữ liệu không qua máy chạy lệnh | | Chạy lại được | bỏ qua object đã có | | Chạy trên EC2 cùng Region để nhanh hơn | giảm độ trễ lời gọi API |

Chạy sync từ EC2 là mẹo quan trọng với khối lượng lớn:

Chạy từ máy trạm ở Việt Nam:
    → mỗi lời gọi API phải đi rất xa
    → độ trễ cao, thông lượng thấp

Chạy từ EC2 ở us-west-1:
    → lời gọi API rất nhanh
    → sao chép nhanh hơn nhiều lần

Ba lưu ý về chi phí với 1 PB: | Khoản | Ước tính | |---|---| | Truyền xuyên Region | 1.000.000 GB × 0,02 USD = ~20.000 USD | | Request PUT | theo số object | | Lưu trữ ở Region đích | ~23.000 USD/tháng (Standard) |

Khoản truyền dữ liệu là con số lớn — nên cân nhắc kỹ có thực sự cần bản sao đầy đủ không.

Ba cách giảm chi phí: | Cách | Chi tiết | |---|---| | Chỉ sao chép dữ liệu THỰC SỰ cần | dùng filter theo prefix hoặc thẻ | | Sao chép thẳng vào lớp lưu trữ rẻ | Glacier IR hoặc Deep Archive | | Nén trước nếu chưa nén | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Tiến độ Batch Operations job | số object đã xử lý | | ReplicationLatency | với replication liên tục | | OperationsFailedReplication | object không sao chép được |

Và một lời khuyên: hãy chạy aws s3 sync từ EC2 ở Region nguồn với nhiều luồng song song, và chia công việc theo prefix để chạy nhiều tiến trình cùng lúc. Với 1 PB, một tiến trình đơn lẻ sẽ mất rất lâu — còn chia theo prefix cho phép chạy hàng chục tiến trình song song và theo dõi tiến độ từng phần.

Đáp án

A và B.

• A — Gắn IAM role vào Lambda function
• B — Dùng IAM authentication từ Lambda tới Amazon RDS PostgreSQL

Vì sao đúng

Đề nêu yêu cầu rõ: cải thiện bảo mật ở tầng xác thực bằng THÔNG TIN ĐĂNG NHẬP NGẮN HẠN.

Hiện tại: Lambda dùng TÊN NGƯỜI DÙNG và MẬT KHẨU
    → mật khẩu dài hạn, nằm đâu đó trong cấu hình
    → không tự hết hạn, không tự xoay vòng
        ↓
IAM database authentication:
    → sinh TOKEN xác thực có hiệu lực 15 PHÚT
    → không có mật khẩu nào lưu ở đâu cả

Cách IAM database authentication hoạt động:

Lambda (có IAM role)
    ↓ gọi API sinh token
RDS trả về token xác thực (hiệu lực 15 phút)
    ↓ dùng token làm "mật khẩu" khi kết nối
RDS PostgreSQL xác thực qua IAM

Và cần cả hai đáp án vì chúng phụ thuộc nhau:

B (IAM authentication) cần A (IAM role)
    → Lambda phải có role với quyền rds-db:connect
    → không có role thì không sinh được token

Ba bước triển khai:

# ① Bật IAM authentication trên RDS
aws rds modify-db-instance --db-instance-identifier db-hen-ho   --enable-iam-database-authentication --apply-immediately

# ② Cấp quyền cho execution role của Lambda
aws iam put-role-policy --role-name vai-tro-lambda   --policy-name ket-noi-rds --policy-document '{
    "Version":"2012-10-17","Statement":[{
      "Effect":"Allow","Action":"rds-db:connect",
      "Resource":"arn:aws:rds-db:ap-northeast-1:123456789012:dbuser:db-ABCDEF/ung_dung"}]}'

-- ③ Tạo user trong PostgreSQL và cấp vai trò IAM
CREATE USER ung_dung;
GRANT rds_iam TO ung_dung;

Và trong mã Lambda:

import boto3, psycopg2
rds = boto3.client('rds')
token = rds.generate_db_auth_token(
    DBHostname=host, Port=5432, DBUsername='ung_dung')
conn = psycopg2.connect(host=host, user='ung_dung', password=token,
                        dbname='hen_ho', sslmode='require')

sslmode='require' là bắt buộc — IAM authentication chỉ hoạt động qua SSL.

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

• **C. Nhúng logic xoay vòng thông tin đăng nhập trong Lambda, lấy từ SSM Parameter Store — đây là phương án gần nhất và thực sự cải thiện bảo mật, nhưng nó vẫn dùng mật khẩu DÀI HẠN: xoay vòng làm giảm rủi ro nhưng giữa hai lần xoay vòng mật khẩu vẫn tồn tại. Đề yêu cầu "short-lived credentials" — token 15 phút của IAM authentication mới đúng.
• **D. Giới hạn security group của RDS chỉ nhận từ security group của Lambda — là biện pháp mạng, không phải tầng xác thực: đề nói rõ "improve the security at the AUTHENTICATION level".
• **E. Triển khai Lambda trong VPC — cũng là biện pháp mạng. Nó cần thiết để Lambda kết nối tới RDS ở private subnet, nhưng không liên quan tới xác thực.

Ghi nhớ

Ba cách xác thực Lambda tới RDS — bảng so sánh: | Cách | Loại thông tin đăng nhập | |---|---| | Mật khẩu trong biến môi trường | dài hạn, tệ nhất | | Mật khẩu trong Secrets Manager có xoay vòng | dài hạn nhưng tự xoay vòng | | IAM database authentication | NGẮN HẠN (15 phút) ← câu này |

Ba lợi ích của IAM database authentication: | Lợi ích | Chi tiết | |---|---| | Không có mật khẩu nào tồn tại | không có gì để rò rỉ | | Token tự hết hạn sau 15 phút | | | Phân quyền bằng IAM | thu hồi tức thì bằng cách sửa policy | | Bắt buộc SSL | mã hoá đường truyền |

Ba hạn chế cần biết: | Hạn chế | Chi tiết | |---|---| | Giới hạn số kết nối mới mỗi giây | ~200/giây cho MySQL, cao hơn cho PostgreSQL | | Token hết hạn sau 15 phút | kết nối đã mở vẫn giữ được | | Không hỗ trợ mọi engine | MySQL, PostgreSQL, MariaDB, Aurora |

Dòng đầu quan trọng với Lambda:

Hàng nghìn lượt Lambda đồng thời, mỗi lượt mở kết nối mới
    → chạm giới hạn số kết nối mới mỗi giây
        ↓
    → Dùng RDS Proxy để gom kết nối

RDS Proxy kết hợp rất tốt với IAM authentication:

aws rds create-db-proxy --db-proxy-name proxy-hen-ho   --engine-family POSTGRESQL   --auth '[{"SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]'   --role-arn <arn-role> --vpc-subnet-ids subnet-a subnet-b

RDS Proxy:
    ✓ gom kết nối — hàng nghìn Lambda → ít kết nối database
    ✓ hỗ trợ IAM authentication
    ✓ rút ngắn thời gian chuyển đổi tới 66%

Ba lớp bảo mật cho Lambda và RDS: | Lớp | Cơ chế | |---|---| | Xác thực | IAM database authentication ← câu này | | Mạng | Lambda trong VPC + security group | | Mã hoá | SSL in transit, KMS at rest |

Ba lưu ý về Lambda trong VPC: | Lưu ý | Chi tiết | |---|---| | Cần cho phép truy cập RDS ở private subnet | | | Execution role cần quyền ENI | AWSLambdaVPCAccessExecutionRole | | Cần VPC endpoint hoặc NAT để gọi dịch vụ AWS | ví dụ để sinh token |

Dòng cuối là chi tiết vận hành:

Lambda trong VPC không có Internet mặc định
    → gọi API RDS để sinh token cũng cần đường ra
        ↓
    Tạo interface endpoint cho rds, hoặc dùng NAT Gateway

Ba cách quản lý bí mật cho Lambda: | Cách | Đặc điểm | |---|---| | IAM database authentication | không có bí mật nào | | Secrets Manager | tự xoay vòng, có audit | | Parameter Store SecureString | rẻ hơn, không tự xoay vòng |

Secrets Manager với tự xoay vòng:

aws secretsmanager rotate-secret --secret-id prod/rds/mat-khau   --rotation-lambda-arn <arn>   --rotation-rules AutomaticallyAfterDays=30

Ba nguyên tắc đặc quyền tối thiểu: | Nguyên tắc | Chi tiết | |---|---| | Giới hạn rds-db:connect tới ĐÚNG user | không dùng * | | Cấp quyền SQL tối thiểu trong database | chỉ bảng và thao tác cần | | Role riêng cho mỗi Lambda function | không dùng chung |

ARN của rds-db:connect có định dạng đặc biệt:

arn:aws:rds-db:<region>:<account>:dbuser:<resource-id>/<db-username>

resource-id là DbiResourceId của instance, không phải tên instance:

aws rds describe-db-instances --db-instance-identifier db-hen-ho   --query 'DBInstances[].DbiResourceId'

Ba lưu ý về SSL: | Lưu ý | Chi tiết | |---|---| | IAM authentication BẮT BUỘC SSL | | | Tải chứng chỉ CA của AWS | để xác minh máy chủ | | Dùng sslmode=verify-full cho bảo mật cao nhất | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | DatabaseConnections | gần trần thì cần RDS Proxy | | Lambda Errors | lỗi kết nối | | Lambda Duration | sinh token thêm thời gian nhỏ |

Và một lời khuyên: hãy cache token trong phạm vi môi trường thực thi của Lambda. Token có hiệu lực 15 phút, và sinh lại cho mỗi lượt gọi vừa tốn thời gian vừa dễ chạm giới hạn tần suất — khởi tạo ngoài handler và tái dùng là cách đơn giản để tránh cả hai vấn đề.

Đáp án

B — Time To Live (TTL) vẫn còn hiệu lực.

Vì sao đúng

Đây là hành vi căn bản của DNS: bản ghi được CACHE theo giá trị TTL.

Đội ngũ sửa bản ghi Route 53 trỏ sang load balancer mới
    ↓
    Nhưng client, trình duyệt và DNS resolver
    ĐÃ CACHE giá trị cũ
        ↓
    Chúng dùng giá trị cũ cho tới khi hết TTL

Ví dụ với TTL 300 giây:

10:00:00 — client tra DNS, nhận IP của load balancer CŨ, cache 300 giây
10:01:00 — đội ngũ sửa bản ghi sang load balancer MỚI
10:01:00–10:05:00 — client vẫn dùng load balancer CŨ
10:05:00 — cache hết hạn, client tra lại, nhận giá trị MỚI

Và với TTL mặc định lớn hơn thì thời gian chờ còn dài hơn: | TTL | Thời gian tối đa client dùng giá trị cũ | |---|---| | 60 giây | 1 phút | | 300 giây | 5 phút | | 3600 giây | 1 giờ | | 86400 giây | 24 giờ |

Cách xử lý:

# Kiểm tra TTL hiện tại
dig myapp.mydomain.com

# Giảm TTL TRƯỚC khi thay đổi (làm trước vài giờ)
aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"myapp.mydomain.com","Type":"CNAME","TTL":60,
    "ResourceRecords":[{"Value":"lb-cu.elb.amazonaws.com"}]}}]}'

Quy trình đúng khi đổi bản ghi DNS:

① Giảm TTL xuống 60 giây
② CHỜ ít nhất bằng TTL CŨ (để mọi cache hết hạn)
③ Đổi bản ghi sang giá trị mới
④ Sau khi ổn định, tăng TTL trở lại

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

• **D. Health check đang thất bại — đây là phương án gần nhất và cũng là nguyên nhân khiến người dùng không tới được đích mới, nhưng đề nói rõ dùng simple record: simple routing policy không hỗ trợ health check. Health check chỉ áp cho failover, weighted, latency và multivalue routing.
• **A. Alias record cấu hình sai — đề nói dùng simple record trỏ tới load balancer, và câu hỏi hỏi vì sao thay đổi chưa có hiệu lực. Nếu cấu hình sai thì sẽ có lỗi rõ ràng, không phải "vẫn tới load balancer cũ".
• **C. CNAME record cấu hình sai — cùng lý do: cấu hình sai sẽ gây lỗi phân giải, không phải trả về giá trị cũ.

Ghi nhớ

Ba tầng cache DNS — bảng cần thuộc: | Tầng | Chi tiết | |---|---| | Trình duyệt | có cache riêng, đôi khi bỏ qua TTL | | Hệ điều hành | cache của resolver cục bộ | | DNS resolver của ISP | cache lâu nhất, ảnh hưởng nhiều người dùng |

Và một số client BỎ QUA TTL hoàn toàn:

Java mặc định cache DNS VĨNH VIỄN
    networkaddress.cache.ttl = -1
        ↓
    → Đặt về 60 giây cho ứng dụng Java trên AWS

Ba lựa chọn TTL: | TTL | Đánh đổi | |---|---| | Ngắn (60 giây) | thay đổi nhanh, nhiều truy vấn hơn | | Dài (86400 giây) | ít truy vấn, thay đổi rất chậm | | Alias record | Route 53 dùng TTL của tài nguyên đích |

Alias record đáng biết:

Alias trỏ tới ALB:
    → Route 53 tự dùng TTL 60 giây của ALB
    → và truy vấn MIỄN PHÍ
        ↓
    Nên dùng alias thay CNAME khi trỏ tới tài nguyên AWS

CNAME và Alias — bảng phân biệt: | | CNAME | Alias | |---|---|---| | Dùng ở ĐỈNH tên miền | ❌ | ✅ | | Trỏ tới tài nguyên AWS | ✅ | ✅ và MIỄN PHÍ | | Trỏ tới tên miền bên ngoài | ✅ | ❌ | | Khai TTL | ✅ | ❌ dùng TTL của đích |

Bảy loại routing policy của Route 53: | Policy | Hỗ trợ health check | |---|---| | Simple | ❌ KHÔNG ← câu này | | Weighted | ✅ | | Latency-based | ✅ | | Failover | ✅ bắt buộc | | Geolocation | ✅ | | Geoproximity | ✅ | | Multivalue answer | ✅ |

Dòng đầu là lý do phương án D sai.

Ba cách chuyển đổi KHÔNG phụ thuộc DNS: | Cách | Đặc điểm | |---|---| | AWS Global Accelerator | hai IP anycast TĨNH, chuyển đích ở tầng mạng | | ALB với target group weighted | chuyển trong một Region | | Route 53 weighted với TTL thấp | vẫn phụ thuộc cache |

Global Accelerator giải quyết triệt để vấn đề bộ đệm DNS:

IP KHÔNG BAO GIỜ đổi
    → client cache IP đó cũng không sao
    → AWS đổi ĐÍCH phía sau IP
        ↓
    Chuyển đổi có hiệu lực trong ~30 giây cho MỌI người dùng

Ba lệnh kiểm tra DNS:

dig myapp.mydomain.com            # xem giá trị và TTL
dig @8.8.8.8 myapp.mydomain.com   # hỏi resolver công cộng
dig +trace myapp.mydomain.com     # theo dõi toàn bộ chuỗi phân giải

Ba cách xoá cache DNS cục bộ:

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches
# macOS
sudo dscacheutil -flushcache
# Windows
ipconfig /flushdns

Nhưng không xoá được cache của ISP hay của client khác.

Ba lưu ý khi lập kế hoạch đổi DNS: | Lưu ý | Chi tiết | |---|---| | Giảm TTL TRƯỚC vài giờ | ← quan trọng nhất | | Giữ đích cũ chạy song song | cho tới khi mọi cache hết hạn | | Theo dõi lưu lượng tới đích cũ | biết khi nào an toàn để tắt |

Dòng giữa rất quan trọng:

Tắt load balancer cũ ngay sau khi đổi DNS
    → người dùng còn cache giá trị cũ nhận LỖI
        ↓
    Giữ nó chạy ít nhất bằng TTL cũ

Ba metric để biết khi nào an toàn: | Metric | Ý nghĩa | |---|---| | RequestCount của load balancer CŨ | về 0 nghĩa là mọi cache đã hết hạn | | RequestCount của load balancer MỚI | lưu lượng đã chuyển sang | | Route 53 query log | ai đang tra bản ghi nào |

Và một lời khuyên: hãy giảm TTL xuống 60 giây ít nhất một ngày trước mọi thay đổi DNS có kế hoạch. Đó là thao tác một dòng, không ảnh hưởng gì tới người dùng, và nó biến một cuộc chuyển đổi có thể kéo dài hàng giờ thành vài phút — thứ khác biệt rất lớn khi đang trong cửa sổ bảo trì.

Đáp án

B — Dùng AWS CloudFormation để quản lý database RDS.

Vì sao đúng

Đề nêu yêu cầu rõ: đưa thực hành tốt vào một TEMPLATE HẠ TẦNG DÙNG LẠI ĐƯỢC cho mọi người dùng.

"reusable infrastructure template to be used by all your AWS users"
        ↓
    Đó chính là định nghĩa của CloudFormation template

CloudFormation giải quyết vấn đề gốc:

Trước: mỗi người tự tạo RDS qua console
    → mỗi người cấu hình theo hiểu biết riêng
    → người mới cấu hình sai → sự cố

Sau: mọi người dùng CÙNG một template
    → Multi-AZ đã bật sẵn
    → mã hoá đã bật sẵn
    → backup retention đã đặt đúng
    → deletion protection đã bật
        ↓
    Thực hành tốt được NƯỚNG SẴN vào template

Template mẫu:

Resources:
  DatabaseSanXuat:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Snapshot
    Properties:
      Engine: postgres
      DBInstanceClass: !Ref CoInstance
      MultiAZ: true                          # ← bắt buộc
      StorageEncrypted: true                 # ← bắt buộc
      KmsKeyId: !Ref KhoaKMS
      BackupRetentionPeriod: 35              # ← tối đa
      DeletionProtection: true               # ← chống xoá nhầm
      EnablePerformanceInsights: true
      PubliclyAccessible: false              # ← không phơi ra Internet
      VPCSecurityGroups: [!Ref SGDatabase]
      DBSubnetGroupName: !Ref NhomSubnetRieng

Và ba lợi ích khác: | Lợi ích | Chi tiết | |---|---| | Có thể rà soát template như mã nguồn | pull request, code review | | Phiên bản hoá | biết ai đổi gì, khi nào | | Lặp lại chính xác | mọi môi trường giống nhau |

Và giới hạn thứ người dùng được chỉnh bằng Parameters có ràng buộc:

Parameters:
  CoInstance:
    Type: String
    AllowedValues: [db.t3.medium, db.r6g.large, db.r6g.xlarge]
    Default: db.t3.medium

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

• **D. Tạo Lambda function gửi email khi phát hiện RDS cấu hình sai — đây là phương án gần nhất và thực sự phát hiện được vấn đề, nhưng nó chỉ chữa triệu chứng SAU KHI sự cố đã có thể xảy ra: database đã được tạo sai, và có thể đã gây sự cố trước khi ai đó đọc email. Phòng ngừa tốt hơn phát hiện.
• **A. Lưu khuyến nghị trong custom AWS Trusted Advisor rule — không có tính năng như vậy: Trusted Advisor có bộ kiểm tra do AWS định nghĩa, người dùng không tạo được rule tuỳ chỉnh.
• **C. Gắn IAM policy chặn thực tập sinh tạo RDS — giải quyết bằng cách chặn hoàn toàn: nó ngăn sự cố nhưng cũng ngăn người ta làm việc, và không giúp gì cho những người được phép tạo database.

Ghi nhớ

Ba tầng đảm bảo cấu hình đúng — bảng phải thuộc: | Tầng | Cơ chế | Thời điểm | |---|---|---| | Phòng ngừa bằng template | CloudFormation, CDK, Terraform | trước khi tạo ← câu này | | Phòng ngừa bằng chính sách | SCP, IAM condition | lúc gọi API | | Phát hiện | AWS Config rule, Security Hub | sau khi tạo |

Ba tầng này bổ sung nhau — template hướng dẫn, SCP chặn, Config phát hiện.

Ba thành phần của CloudFormation template: | Thành phần | Việc | |---|---| | Parameters | giá trị người dùng khai, có ràng buộc | | Resources | tài nguyên được tạo | | Outputs | giá trị trả về (endpoint, ARN) | | Conditions, Mappings | logic và bảng tra cứu |

Ba thuộc tính RDS nên đặt cứng trong template: | Thuộc tính | Giá trị | |---|---| | MultiAZ | true cho sản xuất | | StorageEncrypted | true — không bật được sau | | DeletionProtection | true | | BackupRetentionPeriod | 7–35 ngày | | PubliclyAccessible | false |

Dòng StorageEncrypted đặc biệt quan trọng:

Mã hoá KHÔNG bật được cho instance đã tồn tại
    → phải chụp snapshot, sao chép có mã hoá, khôi phục
        ↓
    Bắt buộc đúng NGAY TỪ ĐẦU

Ba DeletionPolicy của CloudFormation: | Chính sách | Việc khi xoá stack | |---|---| | Delete (mặc định) | xoá tài nguyên | | Retain | giữ lại tài nguyên | | Snapshot | chụp snapshot rồi mới xoá — cho RDS và EBS |

DeletionPolicy: Snapshot là lưới an toàn quan trọng cho database.

Ba công cụ hạ tầng dạng mã: | Công cụ | Đặc điểm | |---|---| | CloudFormation | của AWS, không cần công cụ ngoài | | AWS CDK | định nghĩa bằng ngôn ngữ lập trình, sinh CloudFormation | | Terraform | đa đám mây, cộng đồng lớn |

CDK đáng cân nhắc cho việc chuẩn hoá:

class DatabaseChuan(Construct):
    def __init__(self, scope, id, vpc):
        super().__init__(scope, id)
        rds.DatabaseInstance(self, "DB",
            engine=rds.DatabaseInstanceEngine.postgres(...),
            vpc=vpc,
            multi_az=True,              # nướng sẵn
            storage_encrypted=True,     # nướng sẵn
            deletion_protection=True,
            backup_retention=Duration.days(35))

Đóng gói thực hành tốt thành một construct dùng lại — người dùng chỉ cần gọi nó.

Ba cách triển khai template cho mọi người: | Cách | Chi tiết | |---|---| | AWS Service Catalog | cung cấp sản phẩm đã duyệt cho người dùng tự phục vụ | | CloudFormation StackSets | triển khai nhiều tài khoản và Region | | Kho git dùng chung | đơn giản nhất |

Service Catalog rất phù hợp với tình huống trong đề:

Service Catalog:
    ✓ quản trị viên định nghĩa "sản phẩm" (template đã duyệt)
    ✓ người dùng chọn từ danh mục và tự triển khai
    ✓ KHÔNG cần quyền tạo tài nguyên trực tiếp
        ↓
    Vừa tự phục vụ, vừa đảm bảo tuân thủ

Ba biện pháp bổ sung: | Biện pháp | Chi tiết | |---|---| | SCP chặn tạo RDS không mã hoá | phòng ngừa ở tầng API | | Config rule phát hiện vi phạm | lưới an toàn | | CloudFormation Guard | kiểm tra template TRƯỚC khi triển khai |

SCP chặn RDS không mã hoá:

{"Effect": "Deny", "Action": "rds:CreateDBInstance", "Resource": "*",
 "Condition": {"Bool": {"rds:StorageEncrypted": "false"}}}

Và CloudFormation Guard kiểm tra template trong CI/CD:

Rule: mọi AWS::RDS::DBInstance phải có
      StorageEncrypted == true
      MultiAZ == true
        ↓
    Template vi phạm bị chặn ở pull request

Ba lưu ý khi dùng CloudFormation cho RDS: | Lưu ý | Chi tiết | |---|---| | Một số thay đổi gây THAY THẾ tài nguyên | đọc kỹ change set trước khi áp | | Dùng DeletionPolicy: Snapshot | | | Mật khẩu qua Secrets Manager, không đặt trong template | |

Mật khẩu đúng cách:

MatKhau:
  Type: AWS::SecretsManager::Secret
  Properties:
    GenerateSecretString:
      SecretStringTemplate: '{"username": "quantri"}'
      GenerateStringKey: "password"
      PasswordLength: 32

Và một lời khuyên: hãy luôn xem change set trước khi cập nhật stack chứa database. Một số thuộc tính của RDS khi thay đổi sẽ khiến CloudFormation tạo instance mới và xoá instance cũ — và change set là nơi duy nhất cảnh báo bạn điều đó trước khi nó xảy ra với database sản xuất.

Đáp án

A — Instance có launch template hoặc launch configuration CŨ NHẤT sẽ bị chấm dứt trong AZ-B.

Vì sao đúng

Chính sách chấm dứt mặc định của Auto Scaling xét theo thứ tự, và hai bước đầu quyết định đáp án:

① Chọn AZ có NHIỀU instance nhất
     AZ-A có 3, AZ-B có 4
     → chọn AZ-B

② Trong AZ đó, chọn instance dùng launch template
   hoặc launch configuration CŨ NHẤT
     → đó là instance bị chấm dứt

Thứ tự đầy đủ của chính sách mặc định:

① AZ có NHIỀU instance nhất
② Instance dùng LAUNCH CONFIGURATION (trước launch template)
③ Trong đó, cái CŨ NHẤT
④ Instance gần mốc TÍNH TIỀN THEO GIỜ tiếp theo
⑤ Chọn ngẫu nhiên

Vì sao bước một chọn AZ-B:

Mục tiêu: giữ số instance CÂN BẰNG giữa các AZ
    ↓
AZ-A: 3 instance
AZ-B: 4 instance
    → chấm dứt ở AZ-B để về 3–3

Và bước hai không chọn ngẫu nhiên:

Trong AZ-B có 4 instance
    → ASG không bốc ngẫu nhiên
    → nó chọn theo tiêu chí: cấu hình CŨ NHẤT
        ↓
    Giúp fleet dần dần đồng nhất về phiên bản mới

Xem chính sách hiện tại:

aws autoscaling describe-auto-scaling-groups   --auto-scaling-group-names asg-ung-dung   --query 'AutoScalingGroups[0].TerminationPolicies'

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

• **D. Một instance NGẪU NHIÊN trong AZ-B bị chấm dứt — đây là phương án gần nhất và chọn đúng AZ, nhưng nó bỏ qua bước hai và ba: ASG chỉ chọn ngẫu nhiên ở bước cuối cùng, sau khi các tiêu chí trước không phân định được.
• **B. Một instance ngẫu nhiên trong AZ-A bị chấm dứt — sai AZ: chính sách mặc định chấm dứt ở AZ có nhiều instance nhất, tức là AZ-B.
• **C. Một instance được TẠO ở AZ-A — sai chiều hành động: đây là sự kiện scale-in (thu hẹp), ASG đang giảm số instance chứ không tăng.

Ghi nhớ

Chính sách chấm dứt mặc định — thứ tự phải thuộc:

① AZ có NHIỀU instance nhất
② Instance dùng LAUNCH CONFIGURATION (trước launch template)
③ Trong đó, cái CŨ NHẤT
④ Instance gần mốc TÍNH TIỀN THEO GIỜ
⑤ Ngẫu nhiên

Các chính sách chấm dứt tuỳ chọn: | Chính sách | Chấm dứt | |---|---| | Default | theo thứ tự trên | | OldestInstance | instance cũ nhất — hữu ích khi nâng cấp loại máy | | NewestInstance | mới nhất — hữu ích khi rollback | | OldestLaunchTemplate | template cũ nhất | | OldestLaunchConfiguration | configuration cũ nhất | | ClosestToNextInstanceHour | tối ưu chi phí | | AllocationStrategy | cân bằng lại theo chiến lược Spot |

Kết hợp nhiều chính sách theo thứ tự:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --termination-policies "OldestLaunchTemplate" "OldestInstance" "Default"

Hai thứ tự hành động của ASG — bảng cần thuộc: | Tình huống | Thứ tự | |---|---| | Thay instance KHÔNG khoẻ mạnh | chấm dứt → khởi động | | Cân bằng lại giữa AZ | khởi động → chấm dứt |

Nguyên tắc: máy còn phục vụ được thì không bao giờ bỏ trước.

Ba cơ chế bảo vệ instance khỏi bị chấm dứt: | Cơ chế | Chi tiết | |---|---| | Scale-in protection | ASG không chấm dứt instance này khi thu hẹp | | Standby state | tạm gỡ khỏi ASG để bảo trì | | Instance termination protection (EC2) | KHÔNG ngăn được ASG |

Dòng cuối là điểm hay nhầm: disableApiTermination ngăn TerminateInstances thủ công nhưng không ngăn ASG.

Bật scale-in protection:

aws autoscaling set-instance-protection --instance-ids i-0abc   --auto-scaling-group-name asg-ung-dung --protected-from-scale-in

Hữu ích cho instance đang xử lý công việc dài không được gián đoạn.

Ba lưu ý về sticky session và scale-in: | Lưu ý | Chi tiết | |---|---| | Người dùng đang gắn với instance bị chấm dứt sẽ mất phiên | | | Dùng connection draining (deregistration delay) | hoàn tất request đang xử lý | | Lưu trạng thái phiên ở NGOÀI instance | ElastiCache hoặc DynamoDB |

Dòng cuối là giải pháp căn bản:

Sticky session chỉ là giải pháp tạm
    → instance bị thay là mất phiên
        ↓
    Đưa trạng thái phiên ra ElastiCache
    → mọi instance đều phục vụ được mọi người dùng

Cấu hình deregistration delay:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=deregistration_delay.timeout_seconds,Value=60

ALB ngừng gửi request mới nhưng chờ request đang xử lý hoàn tất.

Ba lifecycle hook đáng dùng: | Hook | Việc | |---|---| | EC2_INSTANCE_LAUNCHING | cài đặt trước khi phục vụ | | EC2_INSTANCE_TERMINATING | đẩy log ra ngoài, hoàn tất công việc dở | | Cả hai | thông báo qua SNS hoặc EventBridge |

Hook chấm dứt rất quan trọng:

Không có hook:
    Instance bị chấm dứt ngay
    → log cục bộ và công việc đang xử lý MẤT

Có hook:
    → instance vào Terminating:Wait, có tối đa 1 giờ
    → script hoàn tất rồi gọi CompleteLifecycleAction

Launch template và Launch configuration: | | Launch template | Launch configuration | |---|---|---| | Trạng thái | được KHUYẾN NGHỊ | CŨ | | Phiên bản hoá | ✅ | ❌ | | Trộn loại instance và mua | ✅ | ❌ | | Tính năng EC2 mới | ✅ | ❌ |

AWS đã ngừng cho tài khoản mới tạo launch configuration — nên chuyển sang launch template.

Ba cách thay toàn bộ fleet an toàn: | Cách | Chi tiết | |---|---| | Instance refresh | ASG tự thay dần theo MinHealthyPercentage | | Đặt OldestLaunchTemplate rồi tăng giảm desired | thủ công hơn | | Blue/green với ASG mới | kiểm soát nhiều nhất |

aws autoscaling start-instance-refresh   --auto-scaling-group-name asg-ung-dung   --preferences '{"MinHealthyPercentage":90,"InstanceWarmup":300}'

Ba nơi chẩn đoán: | Nơi | Thông tin | |---|---| | Activity history của ASG | lý do cụ thể của mỗi lần chấm dứt | | CloudTrail | lời gọi API | | EventBridge | sự kiện lifecycle |

Và một lời khuyên: hãy đưa trạng thái phiên ra khỏi instance thay vì dựa vào sticky session. Với ASG thu hẹp theo chính sách mặc định, bạn không kiểm soát được instance nào bị chấm dứt — và người dùng đang gắn với nó sẽ mất phiên vào đúng lúc hệ thống đang tự động tối ưu chi phí.

Đáp án

A — Geoproximity routing.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: thay đổi ĐỘNG kích thước vùng địa lý mà lưu lượng được định tuyến tới một tài nguyên.

"dynamically ALTER THE SIZE of a geographic area
 from which traffic is routed to a specific server resource"
        ↓
    Đó chính xác là chức năng của BIAS trong geoproximity routing

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

Route 53 tính khoảng cách từ người dùng tới mỗi tài nguyên
    → gửi tới tài nguyên GẦN NHẤT
        ↓
    Và BIAS cho phép mở rộng hoặc thu hẹp vùng phục vụ

Bias là tham số quyết định: | Bias | Tác dụng | |---|---| | Dương (1 tới 99) | MỞ RỘNG vùng phục vụ của tài nguyên đó | | Âm (−1 tới −99) | THU HẸP vùng phục vụ | | 0 | vùng theo khoảng cách thực tế |

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[{"Action":"CREATE","ResourceRecordSet":{
    "Name":"app.congty.com","Type":"A","SetIdentifier":"tokyo",
    "GeoProximityLocation":{"AWSRegion":"ap-northeast-1","Bias":50},
    "AliasTarget":{"HostedZoneId":"Z123","DNSName":"alb-tokyo...",
                   "EvaluateTargetHealth":true}}}]}'

Ví dụ ứng dụng thực tế:

Region Tokyo đang quá tải:
    → giảm bias xuống −30
    → vùng phục vụ THU HẸP
    → người dùng ở rìa được chuyển sang Region khác

Region Singapore vừa mở rộng năng lực:
    → tăng bias lên +40
    → vùng phục vụ MỞ RỘNG
    → nhận thêm người dùng từ vùng lân cận

Và đó là "dynamically alter the size of a geographic area" đúng nghĩa.

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

• **B. Geolocation routing — đây là phương án gần nhất và cũng định tuyến theo địa lý, nhưng nó KHÔNG thay đổi được kích thước vùng: geolocation định tuyến theo biên giới hành chính cố định (châu lục, quốc gia, bang của Mỹ). Bạn chọn quốc gia nào tới đâu, nhưng không "mở rộng" hay "thu hẹp" vùng được.
• **C. Latency-based routing — định tuyến theo độ trễ mạng đo được, hoàn toàn tự động và không điều chỉnh được.
• **D. Weighted routing — chia lưu lượng theo tỷ lệ phần trăm, không có khái niệm địa lý.

Ghi nhớ

Bảy loại routing policy của Route 53 — bảng phải thuộc: | Policy | Định tuyến theo | Điều chỉnh được | |---|---|---| | Simple | không điều kiện | — | | Weighted | tỷ lệ phần trăm | ✅ trọng số | | Latency-based | độ trễ mạng thật | ❌ | | Failover | sức khoẻ endpoint | ❌ | | Geolocation | biên giới hành chính | ❌ cố định | | Geoproximity | khoảng cách + BIAS | ✅ bias ← câu này | | Multivalue answer | tới 8 bản ghi khoẻ mạnh | — | | IP-based | khối CIDR của người dùng | ✅ |

Geolocation và Geoproximity — bảng phân biệt cốt lõi: | | Geolocation | Geoproximity | |---|---|---| | Dựa trên | vị trí NGƯỜI DÙNG theo biên giới | KHOẢNG CÁCH tới tài nguyên | | Điều chỉnh vùng | ❌ | ✅ qua bias | | Cần bản ghi mặc định | ✅ BẮT BUỘC | không | | Dùng cho | tuân thủ, bản quyền, ngôn ngữ | cân bằng tải theo vùng |

Từ khoá nhận diện:

"dynamically alter size of geographic area", "bias", "shift traffic between regions" → geoproximity "comply with regulations", "block a country", "content licensing" → geolocation "lowest latency", "best performance" → latency-based "A/B testing", "gradual rollout" → weighted

Ba yêu cầu của geoproximity routing: | Yêu cầu | Chi tiết | |---|---| | PHẢI dùng traffic flow (traffic policy) | không cấu hình được bằng bản ghi đơn giản | | Khai vị trí bằng AWS Region hoặc toạ độ | cho tài nguyên ngoài AWS | | Bias từ −99 tới +99 | |

Dòng đầu là ràng buộc vận hành quan trọng:

Geoproximity chỉ dùng được qua Route 53 Traffic Flow
    → giao diện trực quan để dựng chính sách định tuyến
    → có phí thêm (~50 USD/tháng mỗi traffic policy record)

Ba cách khai vị trí tài nguyên: | Cách | Dùng cho | |---|---| | AWSRegion | tài nguyên trong AWS | | Coordinates (vĩ độ, kinh độ) | tài nguyên ngoài AWS hoặc tại chỗ | | LocalZoneGroup | AWS Local Zones |

Ba trường hợp dùng geoproximity: | Trường hợp | Chi tiết | |---|---| | Cân bằng tải giữa các Region | ← câu này | | Chuyển dần lưu lượng khi mở Region mới | tăng bias từ từ | | Giảm tải Region đang quá tải | giảm bias |

Ba lưu ý về bias: | Lưu ý | Chi tiết | |---|---| | Bias KHÔNG phải phần trăm lưu lượng | nó điều chỉnh KHOẢNG CÁCH tính toán | | Tác động phi tuyến | thử nghiệm để tìm giá trị phù hợp | | Thay đổi có hiệu lực sau khi cập nhật traffic policy | |

Ba lựa chọn khác để chuyển lưu lượng giữa Region: | Lựa chọn | Đặc điểm | |---|---| | Geoproximity với bias | theo địa lý, điều chỉnh được ← câu này | | Weighted routing | theo tỷ lệ phần trăm chính xác | | Global Accelerator traffic dial | ở tầng mạng, không phụ thuộc DNS |

Global Accelerator đáng cân nhắc:

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

Lợi ích so với DNS:
    ✓ có hiệu lực trong VÀI GIÂY
    ✓ không phụ thuộc bộ đệm DNS
    ✓ IP tĩnh

Ba lưu ý về bộ đệm DNS: | Lưu ý | Chi tiết | |---|---| | Thay đổi bias mất thời gian lan truyền | phụ thuộc TTL | | Đặt TTL thấp nếu cần điều chỉnh thường xuyên | | | Một số client bỏ qua TTL | |

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Geoproximity hỗ trợ health check | qua EvaluateTargetHealth | | Endpoint hỏng thì không được định tuyến tới | | | Nên bật cho mọi endpoint | tránh gửi người dùng tới nơi đã hỏng |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Hosted zone | 0,50 USD/tháng | | Traffic policy record | ~50 USD/tháng mỗi bản ghi | | Truy vấn | ~0,40 USD/triệu (geoproximity tính giá cao hơn) |

Traffic Flow khá đắt — với nhu cầu đơn giản, weighted routing rẻ hơn nhiều.

Ba công cụ kiểm chứng:

# Xem chính sách hiện tại
aws route53 list-traffic-policies

# Thử phân giải từ một vị trí giả định
aws route53 test-dns-answer --hosted-zone-id Z123   --record-name app.congty.com --record-type A   --resolver-ip 203.0.113.1

Và một lời khuyên: hãy cân nhắc Global Accelerator nếu mục tiêu chính là chuyển tải giữa các Region. Traffic dial cho kiểm soát chính xác theo phần trăm, có hiệu lực trong vài giây, và không phụ thuộc bộ đệm DNS — trong khi bias của geoproximity có tác động phi tuyến và khó dự đoán chính xác lưu lượng sẽ dịch chuyển bao nhiêu.

Đáp án

C — Dùng AWS Transit Gateway để kết nối các VPC với mạng tại chỗ.

Vì sao đúng

Đề nêu hai yêu cầu, và Transit Gateway đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Kết nối VPC và mạng tại chỗ qua một HUB TRUNG TÂM | TGW là hub theo đúng thiết kế | | ÍT công vận hành nhất | định tuyến bắc cầu, route propagation tự động |

Transit Gateway là kiến trúc hub-and-spoke đúng nghĩa:

                Transit Gateway (hub)
                        │
    ┌───────┬───────────┼───────────┬────────┐
    │       │           │           │        │
  VPC-A   VPC-B      VPC-C       VPN/DX   VPC-D
        ↓
    Mọi thứ nói chuyện với mọi thứ qua MỘT điểm

Và định tuyến BẮC CẦU là khác biệt cốt lõi:

VPC peering: KHÔNG bắc cầu
    A ⟷ B, B ⟷ C
    → A KHÔNG nói chuyện được với C

Transit Gateway: BẮC CẦU
    A → TGW → C  ✓

Cấu hình:

aws ec2 create-transit-gateway --description "TGW trung tam"   --options '{"DefaultRouteTableAssociation":"enable",
              "DefaultRouteTablePropagation":"enable"}'

aws ec2 create-transit-gateway-vpc-attachment   --transit-gateway-id tgw-0abc --vpc-id vpc-0001   --subnet-ids subnet-a subnet-b

# Nối tới tại chỗ
aws ec2 create-vpn-connection --type ipsec.1   --transit-gateway-id tgw-0abc --customer-gateway-id cgw-0abc

Và route propagation giảm công vận hành:

Không có propagation:
    → phải thêm route thủ công cho mỗi VPC
    → N VPC × nhiều route table

Có propagation:
    → TGW tự học CIDR của mỗi attachment
    → tự cập nhật khi VPC thay đổi

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

• **A. Dùng Transit VPC Solution — đây là phương án gần nhất và là kiến trúc hub-and-spoke đúng ý tưởng, nhưng nó là giải pháp CŨ đã bị Transit Gateway thay thế: Transit VPC dùng thiết bị ảo chạy trên EC2 làm hub, nghĩa là bạn phải vận hành, vá lỗi, mở rộng và đảm bảo sẵn sàng cao cho chúng — tăng công vận hành chứ không giảm.
• **B. Partially meshed VPC peering — không kết nối được tới tại chỗ, và peering không bắc cầu nên "partial mesh" nghĩa là một số VPC không nói chuyện được với nhau.
• **D. Fully meshed VPC peering — cũng không nối được tại chỗ, và số kết nối tăng theo N×(N−1)/2 — công vận hành rất lớn.

Ghi nhớ

Bốn cách kết nối mạng — bảng phải thuộc: | Cách | Bắc cầu | Nối tại chỗ | Công vận hành | |---|---|---|---| | Transit Gateway | ✅ | ✅ | thấp ← câu này | | VPC peering | ❌ | ❌ | cao khi nhiều VPC | | Transit VPC (cũ) | ✅ | ✅ | rất cao — tự vận hành EC2 | | PrivateLink | — | — | một chiều, một dịch vụ |

Từ khoá nhận diện:

"central hub", "connect VPCs and on-premises", "least operational overhead" → Transit Gateway "two VPCs only, cheapest" → VPC peering "expose one service one-way" → PrivateLink

Ba đặc điểm của Transit Gateway: | Đặc điểm | Chi tiết | |---|---| | Định tuyến BẮC CẦU | khác VPC peering | | Nối tới 5.000 VPC | mở rộng rất tốt | | Nhiều bảng định tuyến | phân đoạn mạng (segmentation) |

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

Route table "sản xuất":  chỉ VPC prod thấy nhau + tại chỗ
Route table "phát triển": chỉ VPC dev thấy nhau
        ↓
    Prod và dev KHÔNG nói chuyện được
    nhưng cả hai đều tới được tại chỗ

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 attachment | qua transit VIF | | Peering attachment | TGW khác (kể cả Region khác) |

Ba khái niệm cần phân biệt: | Khái niệm | Việc | |---|---| | Association | attachment dùng ROUTE TABLE nào | | Propagation | route của attachment được đưa vào route table nào | | Route | đường đi cụ thể |

Association và propagation là hai thứ khác nhau:

Attachment của VPC-A:
    → associate với route table "prod" (A dùng bảng này để định tuyến)
    → propagate vào route table "prod" và "shared"
      (các attachment dùng hai bảng đó biết đường tới A)

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) | | Xử lý dữ liệu | ~0,02 USD/GB | | Peering giữa TGW | tính như attachment |

Với 20 VPC: khoảng 720 USD/tháng chỉ riêng phí attachment — nên cân nhắc hợp nhất VPC hoặc dùng VPC sharing.

Ba mẫu kiến trúc với Transit Gateway: | Mẫu | Chi tiết | |---|---| | Egress tập trung | mọi lưu lượng ra Internet qua một VPC | | Inspection VPC | mọi lưu lượng qua tường lửa tập trung | | Shared services VPC | NAT, endpoint, DNS dùng chung |

Inspection VPC với AWS Network Firewall:

VPC ứng dụng → TGW → Inspection VPC (Network Firewall) → Internet
        ↓
    Mọi lưu lượng được kiểm tra ở một chỗ
    Chính sách bảo mật nhất quán

Ba lưu ý khi thiết lập: | Lưu ý | Chi tiết | |---|---| | CIDR các VPC KHÔNG được chồng lấn | ràng buộc cứng | | Attachment cần subnet ở mỗi AZ dùng tới | | | Chia sẻ TGW qua AWS RAM | cho kiến trúc nhiều tài khoản |

Chia sẻ TGW qua RAM:

aws ram create-resource-share --name chia-se-tgw   --resource-arns arn:aws:ec2:ap-northeast-1:111122223333:transit-gateway/tgw-0abc   --principals ou-abc-12345678

Một TGW phục vụ mọi tài khoản trong Organization.

Ba công cụ quản lý: | Công cụ | Việc | |---|---| | Transit Gateway Network Manager | xem toàn cảnh mạng toàn cầu | | VPC Reachability Analyzer | kiểm tra đường đi | | Transit Gateway Flow Logs | thấy lưu lượng qua TGW |

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | TGW tự dư thừa trong Region | AWS quản lý | | Attachment nên có subnet ở nhiều AZ | | | VPN nên có hai đường hầm | và cân nhắc ECMP |

Và ECMP tăng thông lượng VPN:

aws ec2 modify-transit-gateway --transit-gateway-id tgw-0abc   --options VpnEcmpSupport=enable

Nhiều VPN connection + ECMP
    → lưu lượng chia đều qua các đường hầm
    → thông lượng nhân lên theo số kết nối

Và một lời khuyên: hãy dùng nhiều route table của Transit Gateway để phân đoạn mạng ngay từ đầu. Mặc định mọi attachment đều thấy nhau, và với công ty dược phẩm có yêu cầu tuân thủ, việc tách môi trường sản xuất khỏi phát triển ở tầng định tuyến dễ hơn nhiều so với việc gỡ ra sau khi mọi thứ đã kết nối.