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

Đáp án

C — Dùng CloudFormation stack chứa Auto Scaling group trải nhiều AZ sau ALB; dựng cụm Aurora MySQL Multi-AZ với deletion policy retain; tạo bản ghi Route 53 cho tên miền công ty.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này thoả từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng .NET | EC2 chạy được .NET — container hoá là việc lớn | | CSDL MySQL | Aurora MySQL tương thích hoàn toàn | | 300.000 người dùng đỉnh | ASG + Aurora replica | | Sẵn sàng cao và tiết kiệm | đa AZ, và Aurora rẻ hơn phải cấp thừa |

⚠ Aurora hơn RDS MySQL ở đúng bài toán này: | Tiêu chí | Aurora | RDS MySQL | |---|---|---| | Hiệu năng | ~5 lần MySQL tiêu chuẩn | tiêu chuẩn | | Lưu trữ | tự mở rộng tới 128 TB | cấp trước | | Replica | đọc được VÀ là mục tiêu failover | standby không đọc được | | Failover | dưới 30 giây | 60-120 giây |

300.000 người dùng đỉnh
    → cần mở rộng đọc mạnh
        ↓
    Aurora Replica vừa phục vụ đọc
      vừa là dự phòng
    → một instance, hai vai trò

Dựng bằng CloudFormation:

Resources:
  CumAurora:
    Type: AWS::RDS::DBCluster
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      Engine: aurora-mysql
      EngineVersion: 8.0.mysql_aurora.3.05.2
      MasterUsername: quantri
      ManageMasterUserPassword: true
      StorageEncrypted: true
      BackupRetentionPeriod: 30

  NhomTuDong:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: 4
      MaxSize: 40
      VPCZoneIdentifier: [!Ref SubnetA, !Ref SubnetB, !Ref SubnetC]
      TargetGroupARNs: [!Ref NhomDich]
      HealthCheckType: ELB
      HealthCheckGracePeriod: 300

⚠ DeletionPolicy: Retain cho CSDL sản xuất:

Đây là cụm CSDL của trang sản phẩm chủ lực
    → xoá stack nhầm = mất toàn bộ dữ liệu
        ↓
    Retain giữ cụm lại
    → khác với môi trường tạm thời dùng Snapshot

⚠ Và nhớ UpdateReplacePolicy:

DeletionPolicy: áp khi XOÁ stack
UpdateReplacePolicy: áp khi cập nhật buộc THAY THẾ
        ↓
    Đổi một thuộc tính bất biến của cụm
    → CloudFormation tạo mới, xoá cũ
    → không có UpdateReplacePolicy là mất dữ liệu

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hạ tầng bằng mã, tái tạo được | | | Aurora tự mở rộng lưu trữ | | | Dữ liệu được bảo vệ khỏi xoá stack | |

⚠ Vì sao ALB chứ không phải NLB (phương án B):

Ứng dụng web .NET → HTTP/HTTPS
    → ALB cho định tuyến theo đường dẫn,
      sticky session, kết thúc TLS, gắn WAF
        ↓
    NLB ở tầng 4, không có những thứ đó

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

• **A. ECS cluster trên Spot Instance với ALB và RDS MySQL Multi-AZ — đây là phương án gần nhất về mặt cũng đa AZ và có ALB, nhưng nó đòi container hoá ứng dụng .NET (việc lớn, đề không nói có thời gian); và dùng toàn Spot cho tầng web sản xuất là rủi ro cho một trang sản phẩm chủ lực.
• **B. Elastic Beanstalk với ASG sau Network Load Balancer — NLB không phù hợp cho ứng dụng web cần tính năng tầng 7; và Beanstalk giới hạn khả năng tuỳ chỉnh hạ tầng.
• **D. Beanstalk với ASG trải hai Region và Aurora cross-region read replica — kiến trúc đa Region là bội chi lớn cho yêu cầu chỉ nói "highly available and scalable"; đề nhấn mạnh "cost-effective".

Ghi nhớ

⚠ Ba giá trị của DeletionPolicy — bảng phải thuộc: | Giá trị | Hành vi | |---|---| | Delete | mặc định — xoá tài nguyên | | Retain | giữ lại, bỏ khỏi quản lý stack | | Snapshot | chụp ảnh rồi xoá — chỉ vài loại |

⚠ Chọn giữa Retain và Snapshot:

Môi trường SẢN XUẤT chạy liên tục → Retain
    → CSDL vẫn chạy, ứng dụng không gián đoạn
        ↓
Môi trường TẠM THỜI, xoá xong không dùng → Snapshot
    → không trả tiền instance, chỉ trả tiền snapshot

Từ khoá nhận diện:

".NET app, MySQL, HA, scalable, cost-effective" → EC2 ASG + ALB + Aurora "protect data when stack is deleted" → DeletionPolicy "HTTP routing, sticky sessions, WAF" → ALB "TCP/UDP, static IP, extreme performance" → NLB

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | Tới 15 Aurora Replica | | | Reader endpoint cân bằng tự động | | | Auto scaling cho replica được | |

aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --resource-id cluster:cum-aurora \
  --min-capacity 1 --max-capacity 8

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | min-size ít nhất bằng số AZ | | | Target tracking là mặc định tốt | | | Health check type ELB | |

⚠ Ứng dụng phải không trạng thái:

Session trong bộ nhớ máy
    → ASG thay máy = người dùng đăng xuất
        ↓
    Đưa session vào ElastiCache
    → hoặc bật sticky session của ALB (kém hơn)

Ba lưu ý về chuẩn bị cho đỉnh tải: | Cách | Chi tiết | |---|---| | Scheduled scaling nếu biết trước giờ | | | Predictive scaling nếu có mẫu lặp | | | Warm pool nếu máy khởi động chậm | |

⚠ Ra mắt sản phẩm là sự kiện ĐOÁN TRƯỚC được:

Biết ngày giờ ra mắt
    → scheduled scaling nâng sàn trước
        ↓
    Đừng để target tracking phản ứng
      sau khi người dùng đã đổ vào

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | Đặt trước ALB giảm tải rất nhiều | | | Cache tài sản tĩnh của trang sản phẩm | | | Gắn WAF ở CloudFront | |

Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Bản ghi ALIAS cho apex domain | | | Alias miễn phí truy vấn | | | EvaluateTargetHealth cho failover | |

Ba lưu ý về chi phí: | Cách | Chi tiết | |---|---| | Savings Plans cho năng lực nền | | | Spot cho phần đỉnh (nếu chịu được) | | | Aurora I/O-Optimized nếu I/O nặng | |

Ba lưu ý về CloudFormation: | Lưu ý | Chi tiết | |---|---| | Termination protection cho stack sản xuất | | | Stack policy chặn thay thế tài nguyên quan trọng | | | Change set xem trước trước khi cập nhật | |

aws cloudformation update-termination-protection \
  --stack-name stack-san-pham --enable-termination-protection

Ba lưu ý về kiểm thử tải: | Việc | Chi tiết | |---|---| | Chạy tải giả ở mức 300.000 người dùng | | | Đo xem ASG mở rộng kịp không | | | Kiểm tra CSDL có phải nút thắt không | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử failover Aurora có kế hoạch | | | Tắt một AZ, xem còn phục vụ | | | Xoá stack ở môi trường thử, kiểm CSDL còn nguyên | |

Và một lời khuyên: hãy dùng scheduled scaling để nâng sàn trước giờ ra mắt sản phẩm. Đề mô tả một sự cố do lưu lượng tăng đột ngột, và target tracking dù tốt đến đâu cũng chỉ phản ứng sau khi người dùng đầu tiên đã chịu chậm — với một sự kiện biết trước ngày giờ thì đó là rủi ro không cần chấp nhận.

Đáp án

D — Ở MỖI Region mới, yêu cầu chứng chỉ SSL/TLS bằng AWS Certificate Manager cho từng FQDN, rồi gắn chứng chỉ mới vào Application Load Balancer của chính Region đó.

Vì sao đúng

Đề nêu một ràng buộc kỹ thuật không thể vòng qua: chứng chỉ ACM là tài nguyên theo REGION.

⚠ ACM certificate KHÔNG dùng chung giữa các Region:

Chứng chỉ tạo ở us-west-1
    → CHỈ gắn được vào ALB ở us-west-1
        ↓
    ALB ở ap-southeast-2 cần chứng chỉ
      tạo trong ap-southeast-2

Đây là lý do phương án B sai.

Yêu cầu chứng chỉ ở từng Region:

for vung in ap-southeast-2 ca-central-1 eu-west-3; do
  aws acm request-certificate --region $vung \
    --domain-name ung-dung.vidu.com \
    --subject-alternative-names "*.vidu.com" \
    --validation-method DNS
done

⚠ Xác thực bằng DNS chỉ cần MỘT bản ghi cho tất cả:

ACM ở mỗi Region sinh bản ghi CNAME xác thực
    → nhưng nếu cùng tên miền, bản ghi GIỐNG NHAU
        ↓
    Thêm một lần vào hosted zone
    → cả ba Region cùng xác thực được

⚠ Và xác thực DNS cho tự gia hạn vĩnh viễn:

Xác thực bằng email: phải xác nhận lại mỗi lần gia hạn
        ↓
    Xác thực bằng DNS: bản ghi CNAME nằm mãi
    → ACM tự gia hạn, không ai phải nhớ

Gắn vào ALB:

aws elbv2 create-listener --region ap-southeast-2 \
  --load-balancer-arn <arn-alb> \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=<arn-cert-cua-region-do> \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=<arn-tg>

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | ACM miễn phí cho ALB và CloudFront | | | Tự gia hạn — không bao giờ hết hạn bất ngờ | | | Không phải quản lý khoá riêng | |

⚠ Chứng chỉ hết hạn là sự cố hoàn toàn tránh được:

Chứng chỉ mua ngoài: phải nhớ gia hạn thủ công
    → quên = mọi khách hàng thấy cảnh báo bảo mật
        ↓
    ACM + xác thực DNS: không bao giờ xảy ra

⚠ Và ACM KHÔNG cho xuất khoá riêng:

Chỉ dùng được với dịch vụ AWS tích hợp
    → ALB, CloudFront, API Gateway, NLB...
        ↓
    Cần chứng chỉ cho EC2 tự quản lý
    → dùng ACM Private CA, hoặc mua ngoài

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

• **B. Dùng ACM ở us-west-1 cấp chứng chỉ rồi gắn cho ALB ở mọi Region mới — đây là phương án gần nhất và dùng đúng dịch vụ, nhưng vi phạm ràng buộc cơ bản: chứng chỉ ACM chỉ gắn được vào tài nguyên cùng Region.
• **A và C. Dùng AWS KMS để yêu cầu chứng chỉ SSL/TLS — KMS không cấp chứng chỉ; nó quản lý khoá mã hoã. Dịch vụ cấp chứng chỉ là ACM.

Ghi nhớ

⚠ Phạm vi của chứng chỉ ACM — bảng phải thuộc: | Dùng cho | Chứng chỉ phải ở đâu | |---|---| | ALB, NLB, API Gateway (regional) | CÙNG Region với tài nguyên | | CloudFront | BẮT BUỘC us-east-1 | | API Gateway edge-optimized | BẮT BUỘC us-east-1 |

⚠ Ngoại lệ us-east-1 cho CloudFront là bẫy hay gặp:

CloudFront là dịch vụ toàn cầu
    → nhưng chứng chỉ của nó phải ở us-east-1
        ↓
    Tạo ở Region khác thì không chọn được
    trong danh sách của CloudFront

Từ khoá nhận diện:

"multi-Region ALB with HTTPS" → chứng chỉ ACM ở TỪNG Region "CloudFront HTTPS" → chứng chỉ ở us-east-1 "certificate for EC2 or on-premises" → ACM Private CA hoặc mua ngoài "manage encryption keys" → KMS (không phải chứng chỉ)

Ba dịch vụ hay bị lẫn: | Dịch vụ | Việc | |---|---| | ACM | cấp và quản lý CHỨNG CHỈ TLS | | KMS | quản lý KHOÁ mã hoá | | CloudHSM | HSM chuyên dụng | | Secrets Manager | lưu và xoay BÍ MẬT |

Ba cách xác thực chứng chỉ ACM: | Cách | Đặc điểm | |---|---| | DNS validation | tự gia hạn vĩnh viễn — khuyến nghị | | Email validation | phải xác nhận lại khi gia hạn | | Import chứng chỉ ngoài | KHÔNG tự gia hạn |

⚠ Chứng chỉ import phải tự theo dõi hạn:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName":"kiem-han-chung-chi",
  "Source":{"Owner":"AWS",
    "SourceIdentifier":"ACM_CERTIFICATE_EXPIRATION_CHECK"},
  "InputParameters":"{\"daysToExpiration\":\"45\"}"}'

Ba lưu ý về wildcard certificate: | Lưu ý | Chi tiết | |---|---| | *.vidu.com phủ mọi tên miền con MỘT cấp | | | KHÔNG phủ vidu.com — phải thêm riêng | | | KHÔNG phủ a.b.vidu.com | |

aws acm request-certificate \
  --domain-name vidu.com \
  --subject-alternative-names "*.vidu.com" \
  --validation-method DNS

⚠ Đây là lỗi cấu hình rất phổ biến:

Chỉ xin `*.vidu.com`
    → https://vidu.com báo lỗi chứng chỉ
        ↓
    Phải khai cả apex trong SAN

Ba lưu ý về SNI: | Lưu ý | Chi tiết | |---|---| | ALB gắn được nhiều chứng chỉ qua SNI | | | Tới 25 chứng chỉ mỗi listener (tăng được) | | | Client cũ không hỗ trợ SNI | |

Ba lưu ý về security policy: | Lưu ý | Chi tiết | |---|---| | Chọn policy TLS hiện đại | | | ELBSecurityPolicy-TLS13-1-2-2021-06 | | | Policy cũ cho phép giao thức yếu | |

Ba lưu ý về kiến trúc đa Region: | Thứ | Phạm vi | |---|---| | Chứng chỉ ACM | Region | | AMI | Region — phải copy | | Auto Scaling group | Region | | Route 53 hosted zone | toàn cầu | | IAM role | toàn cầu |

⚠ Dùng CloudFormation StackSets để triển khai đồng bộ:

aws cloudformation create-stack-instances \
  --stack-set-name ha-tang-ung-dung \
  --accounts 123456789012 \
  --regions ap-southeast-2 ca-central-1 eu-west-3

Ba lưu ý về định tuyến đa Region: | Kiểu | Khi nào | |---|---| | Latency-based routing | gửi tới Region nhanh nhất | | Geolocation | theo vị trí, cho yêu cầu pháp lý | | Global Accelerator | IP tĩnh, chuyển vùng nhanh hơn |

Ba lưu ý về giám sát: | Việc | Cách | |---|---| | Config rule kiểm hạn chứng chỉ | | | EventBridge bắt sự kiện ACM gia hạn | | | Cảnh báo khi gia hạn thất bại | |

⚠ Gia hạn tự động vẫn có thể thất bại:

{"source": ["aws.acm"],
 "detail-type": ["ACM Certificate Approaching Expiration"]}

Bản ghi CNAME xác thực bị xoá
    → ACM không gia hạn được
        ↓
    Sự kiện này báo trước 45 ngày

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy cập HTTPS ở từng Region | | | Kiểm tra chứng chỉ ở trạng thái ISSUED | | | Xác nhận bản ghi CNAME xác thực còn tồn tại | |

aws acm list-certificates --region ap-southeast-2 \
  --query "CertificateSummaryList[].[DomainName,Status]" --output table

Và một lời khuyên: hãy giữ nguyên bản ghi CNAME xác thực của ACM sau khi chứng chỉ đã cấp. Chúng trông như rác trong hosted zone và rất hay bị dọn nhầm — nhưng chính chúng là thứ cho phép ACM tự gia hạn, và mất chúng nghĩa là chứng chỉ sẽ hết hạn sau một năm mà không ai nhận ra.

Đáp án

D — Re-platform lên AWS: chạy container trên Amazon ECS, kiểm thử container OpenJDK mới rồi đẩy lên Amazon ECR, và di chuyển CSDL MySQL sang Amazon RDS bằng AWS DMS.

Vì sao đúng

Đề nêu ba yêu cầu, và "re-platform" là chiến lược khớp chính xác: | Yêu cầu | Cách đáp ứng | |---|---| | Bỏ license Oracle Java, dùng OpenJDK | đổi base image của container | | KHÔNG thay đổi lớn ở ứng dụng | container vẫn là container, MySQL vẫn là MySQL | | Tận dụng tính linh hoạt của đám mây | ECS quản lý, RDS quản lý |

⚠ Re-platform là "lift and TINKER" — đổi vài thứ, giữ kiến trúc:

Re-host: chuyển y nguyên, không đổi gì
    → không bỏ được license Oracle Java
        ↓
Re-platform: đổi thành phần được quản lý
    → Docker tự chạy → ECS
    → MySQL tự quản → RDS
    → Oracle JDK → OpenJDK
    → nhưng MÃ ỨNG DỤNG không đổi
        ↓
Re-factor: viết lại kiến trúc — quá lớn ở đây

Đổi base image sang OpenJDK:

# Trước
FROM oracle/serverjre:8

# Sau
FROM amazoncorretto:17

⚠ Amazon Corretto là bản OpenJDK do AWS phân phối:

Miễn phí, có hỗ trợ dài hạn
    → tương thích chuẩn Java SE
        ↓
    Thay Oracle JDK thường chỉ cần đổi base image
    → và chạy lại bộ test

Đẩy lên ECR:

aws ecr create-repository --repository-name ung-dung-web \
  --image-scanning-configuration scanOnPush=true

aws ecr get-login-password --region ap-southeast-1 \
  | docker login --username AWS --password-stdin \
    <id>.dkr.ecr.ap-southeast-1.amazonaws.com

docker push <id>.dkr.ecr.ap-southeast-1.amazonaws.com/ung-dung-web:1.0

Di chuyển CSDL bằng DMS:

aws dms create-replication-task \
  --replication-task-identifier chuyen-mysql \
  --source-endpoint-arn <arn-mysql-tai-cho> \
  --target-endpoint-arn <arn-rds> \
  --replication-instance-arn <arn-may> \
  --migration-type full-load-and-cdc \
  --table-mappings file://anh-xa.json

⚠ MySQL sang RDS MySQL là di chuyển ĐỒNG NHẤT — không cần SCT:

Cùng engine → chỉ DMS
Đổi engine → SCT + DMS
        ↓
    Đây là lý do phương án A và B sai:
      chúng dùng SCT để chuyển sang DynamoDB

⚠ Và chuyển MySQL sang DynamoDB là RE-FACTOR, không phải re-platform:

Quan hệ → NoSQL
    → phải viết lại toàn bộ mô hình dữ liệu
      và mọi truy vấn
        ↓
    Đề nói rõ "without major changes"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bỏ được chi phí license hàng nghìn USD | | | RDS lo vá, sao lưu, Multi-AZ | | | ECS lo điều phối container | |

⚠ Setup "source-replica" của MySQL được thay bằng Multi-AZ:

Tự dựng source-replica: phải tự lo failover
        ↓
    RDS Multi-AZ: nhân bản đồng bộ,
      failover tự động, endpoint không đổi

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

• **B. Re-platform bằng cách chạy container trên AWS App Runner và chuyển MySQL sang DynamoDB — đây là phương án gần nhất và cũng là re-platform ở vế container, nhưng chuyển sang DynamoDB là re-factor (viết lại mô hình dữ liệu), vi phạm "without major changes". App Runner cũng hạn chế hơn ECS về mạng và cấu hình.
• **C. Re-host bằng cách dựng EC2 giống hệt máy hiện tại — re-host không dùng dịch vụ được quản lý; vẫn phải tự vá máy, tự dựng HA cho MySQL, tự quản lý Docker.
• **A. Re-factor sang Lambda và DynamoDB — thay đổi lớn nhất trong bốn phương án; chuyển container thành hàm Lambda và CSDL quan hệ thành NoSQL là viết lại ứng dụng.

Ghi nhớ

⚠ Bảy chiến lược di chuyển (7R) — bảng phải thuộc: | Chiến lược | Nghĩa | |---|---| | Rehost | "lift and shift" — không đổi gì | | Replatform | "lift and tinker" — đổi thành phần, giữ kiến trúc | | Refactor | viết lại kiến trúc | | Repurchase | đổi sang sản phẩm SaaS | | Retire | bỏ hẳn | | Retain | giữ tại chỗ | | Relocate | chuyển VMware sang VMware Cloud on AWS |

⚠ Cách phân biệt ba chiến lược đầu:

Mã ứng dụng KHÔNG đổi, hạ tầng KHÔNG đổi → Rehost
Mã ứng dụng KHÔNG đổi, hạ tầng ĐỔI       → Replatform
Mã ứng dụng ĐỔI                          → Refactor

Từ khoá nhận diện:

"use managed services without major app changes" → Replatform "lift and shift as-is" → Rehost (MGN) "rewrite as serverless/microservices" → Refactor "replace with SaaS" → Repurchase

Ba ví dụ re-platform điển hình: | Từ | Sang | |---|---| | MySQL tự quản | RDS MySQL | | Docker tự chạy | ECS hoặc EKS | | Oracle JDK | Amazon Corretto | | Tomcat trên VM | Elastic Beanstalk |

Ba lưu ý về Amazon Corretto: | Lưu ý | Chi tiết | |---|---| | Bản OpenJDK do AWS phân phối và hỗ trợ | | | Miễn phí, kể cả dùng thương mại | | | Có hỗ trợ dài hạn cho các phiên bản LTS | |

Ba lưu ý về ECS: | Lưu ý | Chi tiết | |---|---| | Fargate nếu không muốn quản lý máy | | | EC2 launch type nếu cần kiểm soát máy | | | Không có phí control plane như EKS | |

⚠ ECS vs EKS cho re-platform:

Đang chạy Docker thuần, không dùng Kubernetes
    → ECS đơn giản hơn nhiều
        ↓
    EKS đáng chọn khi đã có kỹ năng Kubernetes
      hoặc cần chuẩn đa đám mây

Ba lưu ý về ECR: | Lưu ý | Chi tiết | |---|---| | Bật scanOnPush quét lỗ hổng | | | Lifecycle policy dọn image cũ | | | Pull-through cache cho image công khai | |

{"rules": [{
  "rulePriority": 1,
  "description": "Giu 10 image moi nhat",
  "selection": {"tagStatus": "any", "countType": "imageCountMoreThan",
                "countNumber": 10},
  "action": {"type": "expire"}}]}

Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | full-load-and-cdc giảm gián đoạn | | | Không chép index, khoá ngoại, trigger | | | Bật validation để so dữ liệu | |

⚠ Tạo index SAU khi full load là mẹo tăng tốc:

Có index sẵn: mỗi dòng chèn phải cập nhật index
    → chậm nhiều lần
        ↓
    Chép dữ liệu trước, tạo index sau

Ba lưu ý về kiểm thử: | Việc | Chi tiết | |---|---| | Chạy bộ test đầy đủ với OpenJDK | | | So hiệu năng trước và sau | | | Kiểm tra thư viện phụ thuộc tương thích | |

⚠ Đổi JDK có thể lộ ra khác biệt tinh tế:

Oracle JDK và OpenJDK gần như giống hệt
    → nhưng có khác biệt ở font, mã hoá,
      và vài thư viện thương mại
        ↓
    Chạy bộ test đầy đủ trước khi lên sản xuất

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Bỏ license Oracle Java | tiết kiệm chính | | Fargate Spot giảm tới 70% | | | RDS Reserved Instance giảm tới 72% | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So số dòng CSDL trước và sau | | | Chạy ứng dụng với image OpenJDK | | | Đo thời gian phản hồi | |

Và một lời khuyên: hãy chạy toàn bộ bộ test hồi quy với OpenJDK trước khi lên kế hoạch cắt chuyển. Đổi base image là thay đổi một dòng trong Dockerfile, nhưng những khác biệt giữa Oracle JDK và OpenJDK — nếu có — chỉ lộ ra khi ứng dụng chạy thật, và phát hiện chúng vào ngày di chuyển là điều đắt nhất có thể xảy ra.

Đáp án

B — Gắn tag cho mỗi máy theo môi trường VÀ hệ điều hành; tạo một patch baseline cho từng môi trường trong Patch Manager; phân nhóm máy theo tag bằng Patch Group và áp bản vá của baseline tương ứng cho từng nhóm.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này là phương án duy nhất thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Vá MỌI môi trường TRỪ sản xuất | tag theo MÔI TRƯỜNG để tách được | | Mỗi môi trường có baseline KHÁC NHAU | một baseline cho mỗi môi trường | | ÍT CÔNG SỨC NHẤT | Patch Manager làm sẵn, không viết script |

⚠ Tag theo MÔI TRƯỜNG là chi tiết quyết định — đây là lý do A sai:

Chỉ tag theo hệ điều hành
    → không phân biệt được dev, test, prod
        ↓
    Vá theo baseline của OS
    → sản xuất cũng bị vá cùng lúc
    → vi phạm yêu cầu chính của đề

Gắn tag:

aws ec2 create-tags --resources i-abc i-def \
  --tags 'Key=Patch Group,Value=dev-ubuntu' \
         'Key=MoiTruong,Value=dev'

aws ec2 create-tags --resources i-ghi \
  --tags 'Key=Patch Group,Value=prod-ubuntu' \
         'Key=MoiTruong,Value=prod'

⚠ Tên tag là Patch Group — CÓ DẤU CÁCH và phân biệt hoa thường:

Viết `PatchGroup` (không dấu cách)
    → Patch Manager KHÔNG nhận ra
    → và không báo lỗi gì
        ↓
    Máy đơn giản là không được vá

Baseline riêng cho từng môi trường:

# Dev và test: vá ngay
aws ssm create-patch-baseline --name baseline-dev \
  --operating-system UBUNTU \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=PRIORITY,Values=[Required,Important]}]},
    ApproveAfterDays=0,ComplianceLevel=CRITICAL}]'

# Sản xuất: chờ 7 ngày sau khi đã kiểm chứng
aws ssm create-patch-baseline --name baseline-prod \
  --operating-system UBUNTU \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=PRIORITY,Values=[Required]}]},
    ApproveAfterDays=7,ComplianceLevel=CRITICAL}]'

⚠ ApproveAfterDays=0 cho dev, =7 cho sản xuất — đây chính là yêu cầu của đề:

"Các bản vá chưa chắc không có lỗi"
    → dev và test vá ngay để KIỂM CHỨNG
    → sản xuất chỉ vá sau khi đã yên tâm
        ↓
    Hai baseline khác nhau diễn đạt đúng điều đó

Gắn baseline cho patch group:

aws ssm register-patch-baseline-for-patch-group \
  --baseline-id <id-baseline-dev> --patch-group dev-ubuntu

aws ssm register-patch-baseline-for-patch-group \
  --baseline-id <id-baseline-prod> --patch-group prod-ubuntu

Chạy vá cho môi trường không phải sản xuất:

aws ssm send-command \
  --document-name "AWS-RunPatchBaseline" \
  --targets 'Key=tag:MoiTruong,Values=dev,test' \
  --parameters 'Operation=Install,RebootOption=RebootIfNeeded' \
  --max-concurrency "25%" --max-errors "10%"

⚠ Lọc theo tag MoiTruong loại sản xuất ra khỏi đợt vá này — đúng yêu cầu.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi môi trường có luật vá riêng | | | Sản xuất được bảo vệ khỏi bản vá chưa kiểm chứng | | | Không viết dòng script nào | |

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

• **A. Tag CHỈ theo hệ điều hành, tạo baseline cho từng môi trường — đây là phương án gần nhất và có ý tưởng đúng về baseline, nhưng tag chỉ theo OS thì không phân nhóm được theo môi trường; không tách được sản xuất ra.
• **D. Tag theo môi trường và OS nhưng viết shell script cho từng môi trường và chạy bằng Run Command — tự viết script là bỏ qua toàn bộ Patch Manager: mất baseline, mất báo cáo tuân thủ, mất khả năng quét. Đề nói "least amount of effort".
• **C. Lập Maintenance Window cho từng môi trường và để Systems Manager "chạy cron job" — Maintenance Window là cơ chế lập lịch, nó không định nghĩa bản vá nào được duyệt; và "chạy cron job" không phải cách Systems Manager hoạt động.

Ghi nhớ

⚠ Bốn khái niệm của Patch Manager — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | Patch baseline | quy tắc bản vá nào được duyệt | | Patch group | nhóm máy dùng chung baseline (tag Patch Group) | | Maintenance window | khi nào chạy | | Patch policy | áp baseline theo lịch cho nhiều tài khoản |

⚠ Baseline định nghĩa CÁI GÌ, maintenance window định nghĩa KHI NÀO:

Cần vá khác nhau giữa môi trường → nhiều BASELINE
Cần vá vào giờ khác nhau        → nhiều MAINTENANCE WINDOW
        ↓
    Hai thứ độc lập, kết hợp được

Từ khoá nhận diện:

"different patch baselines per environment" → nhiều patch baseline + patch group "don't reboot all at once" → nhiều patch group + cửa sổ tách biệt "install arbitrary software" → Run Command / Distributor "keep config applied" → State Manager

⚠ ApproveAfterDays là cơ chế bảo vệ khỏi bản vá hỏng: | Giá trị | Ý nghĩa | |---|---| | 0 | vá ngay khi phát hành | | 7 | chờ một tuần | | ApprovedPatches tường minh | chỉ vá những bản đã liệt kê |

⚠ Với sản xuất, danh sách duyệt tường minh còn chặt hơn:

aws ssm update-patch-baseline --baseline-id <id> \
  --approved-patches "USN-6789-1" "USN-6790-2" \
  --approved-patches-compliance-level CRITICAL

Chỉ vá đúng những bản đã kiểm chứng ở dev
    → không phụ thuộc thời gian chờ

Ba tham số Operation: | Giá trị | Việc | |---|---| | Scan | chỉ kiểm tra, không cài | | Install | cài bản vá | | RebootOption | RebootIfNeeded hoặc NoReboot |

⚠ Luôn Scan trước để biết phạm vi:

aws ssm send-command --document-name "AWS-RunPatchBaseline" \
  --targets 'Key=tag:MoiTruong,Values=prod' \
  --parameters 'Operation=Scan'

Biết trước bao nhiêu máy sẽ được vá,
bao nhiêu bản vá sẽ cài, bao nhiêu máy reboot

Ba lưu ý về max-concurrency: | Lưu ý | Chi tiết | |---|---| | Đặt "10%" hoặc "25%" thay vì để mặc định | | | Tránh mọi máy reboot cùng lúc | | | max-errors để không dừng vì vài máy hỏng | |

Ba điều kiện tiên quyết: | Điều kiện | Chi tiết | |---|---| | SSM Agent đang chạy | | | Instance profile có AmazonSSMManagedInstanceCore | | | Tới được endpoint SSM | NAT hoặc VPC endpoint |

Ba lưu ý về báo cáo tuân thủ: | Việc | Cách | |---|---| | list-compliance-summaries | | | Đưa vào Security Hub | | | Config rule kiểm tra | |

aws ssm describe-instance-patch-states-for-patch-group \
  --patch-group dev-ubuntu \
  --query "InstancePatchStates[].[InstanceId,InstalledCount,
    MissingCount,OperationEndTime]" --output table

Ba lưu ý về quy trình kiểm chứng: | Bước | Chi tiết | |---|---| | Vá dev trước, chạy bộ test | | | Vá test, chạy kiểm thử tích hợp | | | Chỉ vá sản xuất sau khi hai bước trên xanh | |

⚠ Đây chính là quy trình đề đang mô tả:

"Sản xuất chỉ vá sau khi đã kiểm chứng
 bản vá hoạt động hiệu quả"
        ↓
    Hai baseline khác nhau thực thi quy tắc đó
      ở tầng cấu hình, không phụ thuộc ai nhớ

Ba lưu ý về hạ tầng bất biến (lựa chọn khác): | Cách | Chi tiết | |---|---| | EC2 Image Builder dựng AMI đã vá | | | Thay máy thay vì vá tại chỗ | | | Instance refresh của ASG | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy Scan sau khi vá | phải sạch | | Kiểm tra sản xuất KHÔNG bị vá | | | Xem báo cáo tuân thủ từng nhóm | |

Và một lời khuyên: hãy kiểm tra tag Patch Group được viết đúng với dấu cách trước khi tin rằng việc vá đã chạy. Đây là một trong số rất ít chỗ AWS dùng tên tag có khoảng trắng, và viết liền sẽ khiến cả một nhóm máy nằm ngoài mọi chu kỳ vá — không lỗi, không cảnh báo, chỉ là im lặng.

Đáp án

D — Dùng Direct Connect Gateway cho truy cập VPC xuyên Region; tạo virtual private gateway ở mỗi VPC, rồi tạo private virtual interface cho mỗi kết nối Direct Connect tới Direct Connect gateway.

Vì sao đúng

Đề nêu bốn yêu cầu, và Direct Connect Gateway đáp ứng cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Nhiều VPC ở NHIỀU Region | DX gateway là tài nguyên TOÀN CẦU | | Mạng RIÊNG, không qua Internet | Direct Connect | | Hiệu năng truyền dữ liệu ĐOÁN TRƯỚC được | băng thông cam kết của DX | | Ít công quản lý | một DX gateway cho mọi Region |

⚠ Direct Connect Gateway là tài nguyên TOÀN CẦU — đây là điều làm nên tất cả:

Kết nối DX vật lý nằm ở MỘT địa điểm
    → DX gateway cho phép nó phục vụ VPC
      ở BẤT KỲ Region nào
        ↓
    Đây chính là lý do dịch vụ này tồn tại

Dựng:

aws directconnect create-direct-connect-gateway \
  --direct-connect-gateway-name dxgw-trung-tam \
  --amazon-side-asn 64512

aws directconnect create-private-virtual-interface \
  --connection-id dxcon-abc \
  --new-private-virtual-interface '{
    "virtualInterfaceName":"vif-rieng-tu",
    "vlan":101,"asn":65000,
    "directConnectGatewayId":"<id-dxgw>"}'

aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id <id-dxgw> \
  --gateway-id vgw-vung-a \
  --add-allowed-prefixes-to-direct-connect-gateway cidr=10.1.0.0/16

⚠ Private VIF là loại đúng vì đích là IP RIÊNG TƯ trong VPC: | Loại VIF | Tới đâu | |---|---| | Private VIF | VPC qua VGW hoặc DX gateway | | Public VIF | endpoint công khai của AWS | | Transit VIF | Transit Gateway |

⚠ Đề nói "dedicated to each region" — DX gateway cho phép điều đó:

Một DX gateway liên kết với VGW của
tối đa 10 VPC ở BẤT KỲ Region nào
        ↓
    Mỗi VPC có đường riêng của mình
    → và tất cả dùng chung kết nối vật lý

Giới hạn phải nhớ: | Giới hạn | Giá trị | |---|---| | VGW liên kết mỗi DX gateway | 10 | | Transit Gateway liên kết | 3 | | CIDR không được chồng lấn | |

⚠ Và giới hạn quan trọng nhất — KHÔNG có định tuyến giữa các VPC:

VPC A và VPC B cùng liên kết DX gateway
    → cả hai tới được văn phòng
    → nhưng KHÔNG nói chuyện được VỚI NHAU
        ↓
    Đề chỉ cần các VPC tới văn phòng trung tâm
    → DX gateway đủ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một kết nối vật lý phục vụ mọi Region | | | DX gateway MIỄN PHÍ | | | Không phải quản lý mạng lưới peering | |

⚠ Nhưng một kết nối DX là điểm hỏng duy nhất:

Đề nói "highly available and durable"
    → nên có ít nhất hai kết nối DX
      ở hai địa điểm khác nhau
        ↓
    Hoặc DX chính + VPN dự phòng

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

• **C. Tạo LAG để gộp nhiều kết nối, dùng DX Gateway và VGW — đây là phương án gần nhất và hầu như đúng, nhưng LAG gộp nhiều kết nối tại CÙNG MỘT địa điểm DX: nó tăng băng thông chứ không tăng tính sẵn sàng trước sự cố của cả địa điểm đó. Và phần còn lại trùng với D nhưng phức tạp hơn không cần thiết.
• **A. Transit Gateway ở mỗi Region với Site-to-Site VPN tới tại chỗ — VPN đi qua Internet công cộng, vi phạm yêu cầu "private network" và "predictable data transfer performance".
• **B. Inter-region VPC peering — peering nối VPC với VPC, nó không nối tới trung tâm dữ liệu tại chỗ; đề cần kết nối tới văn phòng ở Washington.

Ghi nhớ

⚠ Ba thành phần của Direct Connect — bảng phải thuộc: | Thành phần | Việc | |---|---| | Connection | đường vật lý tại địa điểm DX | | Virtual Interface (VIF) | kênh logic trên đường đó | | Direct Connect Gateway | nối VIF với VPC ở NHIỀU Region |

⚠ LAG vs nhiều kết nối ở nhiều địa điểm: | Cách | Tăng gì | |---|---| | LAG | BĂNG THÔNG (cùng địa điểm) | | Nhiều DX ở nhiều địa điểm | TÍNH SẴN SÀNG |

LAG: 4 × 10 Gbps = 40 Gbps ở một địa điểm
    → địa điểm đó mất điện = mất hết
        ↓
    Hai kết nối ở hai địa điểm
    → mất một vẫn còn một

Từ khoá nhận diện:

"multiple VPCs in multiple Regions over DX" → DX Gateway + private VIF + VGW "VPCs must also talk to each other" → Transit Gateway + transit VIF "reach S3 over DX privately" → public VIF "encrypt traffic over DX" → public VIF + VPN over DX

⚠ Khi nào dùng Transit VIF thay vì Private VIF:

Private VIF + VGW: tới VPC, KHÔNG bắc cầu
        ↓
Transit VIF + Transit Gateway:
    → tới VPC VÀ các VPC nói chuyện được với nhau
    → nhưng chỉ 3 TGW mỗi DX gateway

Ba lưu ý về tính sẵn sàng: | Mức | Cấu hình | |---|---| | Phát triển | một kết nối | | Sản xuất | hai kết nối, hai địa điểm | | Tối đa | hai kết nối, hai địa điểm, hai router |

⚠ AWS có "resiliency toolkit" đánh giá mức này:

Maximum Resiliency: 2 kết nối ở 2 địa điểm
High Resiliency:    2 kết nối ở 2 địa điểm (một router mỗi bên)
Development:        1 kết nối

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | BGP động được khuyến nghị | | | AS_PATH prepending ưu tiên đường | | | Local preference điều khiển chiều ra | |

⚠ Bật route propagation — bước hay quên:

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

Không bật: BGP nhận tuyến nhưng route table trống
    → "DX đã lên" mà vẫn không thông

Ba lưu ý về allowed-prefixes: | Lưu ý | Chi tiết | |---|---| | Kiểm soát dải nào được quảng bá ra tại chỗ | | | Chủ DX gateway quyết định | | | Tối đa 200 prefix | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | DX KHÔNG mã hoá theo mặc định | | | Chồng VPN lên DX nếu cần | | | Hoặc MACsec trên đường 10/100 Gbps | |

⚠ "Đường riêng" không có nghĩa là "được mã hoá":

DX là kênh riêng nhưng dữ liệu đi dạng THÔ
    → yêu cầu tuân thủ về mã hoá đường truyền
      cần thêm IPsec hoặc MACsec

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cổng theo giờ | | | Phí truyền dữ liệu RA rẻ hơn Internet | | | DX Gateway MIỄN PHÍ | |

Ba lưu ý về xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | DX gateway liên kết được VGW của tài khoản khác | | | Quy trình đề xuất và chấp nhận hai bước | | | Chủ DX gateway kiểm soát prefix | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra trạng thái liên kết | | | Ping từ VPC tới văn phòng | | | Xem tuyến BGP đã nhận | |

aws directconnect describe-direct-connect-gateway-associations \
  --direct-connect-gateway-id <id-dxgw> \
  --query "directConnectGatewayAssociations[].
    [associatedGateway.id,associationState]" --output table

Và một lời khuyên: hãy dựng hai kết nối Direct Connect ở hai địa điểm khác nhau cho môi trường sản xuất. Đề yêu cầu "highly available and durable", và một LAG gộp bốn đường tại cùng một toà nhà vẫn chỉ là một điểm hỏng duy nhất — chỉ có địa điểm thứ hai mới thật sự loại bỏ nó.

Đáp án

A — Dựng đường hầm VPN từ trung tâm dữ liệu tới mỗi VPC trong số 10 VPC, kết thúc mỗi đường hầm ở virtual private gateway (VGW) của VPC tương ứng, và cấu hình BGP để quản lý định tuyến.

Vì sao đúng

Đề nêu ba yêu cầu, và VPN là cách rẻ nhất để loại bỏ điểm hỏng duy nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Loại bỏ điểm hỏng duy nhất của một DX | VPN đi đường Internet — hoàn toàn độc lập | | TIẾT KIỆM NHẤT | VPN ~0,05 USD/giờ, không cần cổng DX thứ hai | | Tự động chuyển khi DX hỏng | BGP ưu tiên DX, tự chuyển sang VPN |

⚠ VPN qua Internet là đường dự phòng ĐỘC LẬP hoàn toàn:

Kết nối DX thứ hai: vẫn là hạ tầng cáp quang
    → có thể cùng đường cáp, cùng nhà cung cấp
        ↓
    VPN qua Internet: đường đi hoàn toàn khác
    → và rẻ hơn nhiều lần

Dựng VPN cho từng VPC:

for vgw in vgw-1 vgw-2 vgw-3; do
  aws ec2 create-vpn-connection --type ipsec.1 \
    --customer-gateway-id cgw-abc \
    --vpn-gateway-id $vgw \
    --options '{"StaticRoutesOnly": false}'
done

⚠ BGP tự ưu tiên DX khi cả hai cùng lên — đây là cơ chế then chốt:

DX và VPN cùng quảng bá cùng prefix
    → BGP chọn DX (AS path ngắn hơn)
        ↓
    DX đứt → BGP tự chuyển sang VPN
    → không ai phải làm gì

Tăng độ ưu tiên của DX bằng AS_PATH prepending:

Trên router tại chỗ, với tuyến quảng bá qua VPN:
    → prepend AS number vài lần
        ↓
    Làm đường VPN "dài hơn" trong mắt BGP
    → bảo đảm DX luôn được chọn khi còn sống

⚠ Chi phí so sánh: | Cách | Chi phí tháng (ước tính) | |---|---| | 10 VPN connection | ~360 USD (0,05 USD/giờ × 10) | | Kết nối DX 1 Gbps thứ hai | hàng nghìn USD + phí cross-connect |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đường dự phòng độc lập với DX | | | Chuyển đổi tự động qua BGP | | | Rẻ hơn nhiều so với DX thứ hai | |

⚠ Đánh đổi phải chấp nhận:

Khi chạy trên VPN dự phòng:
    → băng thông giảm (~1,25 Gbps mỗi đường hầm)
    → độ trễ cao hơn và biến động
        ↓
    Chấp nhận được cho giai đoạn sự cố
    → không chấp nhận được làm đường chính

⚠ Và mỗi VPN connection có SẴN hai đường hầm:

AWS luôn tạo hai đường hầm tới hai endpoint khác nhau
    → cấu hình CẢ HAI ở thiết bị của bạn
        ↓
    Chỉ cấu hình một = mất kết nối khi AWS
      bảo trì endpoint đó

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

• **B. Dựng kết nối DX thứ hai với public VIF rồi chạy VPN qua đó — đây là phương án gần nhất và là kiến trúc hợp lệ để mã hoá, nhưng nó vẫn đòi một cổng DX thứ hai (khoản chi lớn nhất); và nếu VPN chạy trên chính hạ tầng DX thì nó không phải đường dự phòng độc lập.
• **C. Dựng kết nối DX thứ hai với private VIF cho cả 10 VPC — đây là cách bền nhất về hiệu năng nhưng đắt nhất; đề nói rõ "MOST cost-effective".
• **D. Dựng kết nối MPLS point-to-point tới 10 VPC — MPLS là dịch vụ của nhà mạng, không kết nối trực tiếp vào VPC được; VPC chỉ nhận DX hoặc VPN.

Ghi nhớ

⚠ Bốn mức dự phòng cho kết nối lai — bảng phải thuộc: | Mức | Cấu hình | Chi phí | |---|---|---| | Không dự phòng | một DX | thấp | | DX + VPN backup | rẻ nhất có dự phòng | thấp | | Hai DX, một địa điểm (LAG) | tăng băng thông | trung bình | | Hai DX, hai địa điểm | bền nhất | cao nhất |

⚠ LAG KHÔNG phải giải pháp dự phòng:

LAG gộp nhiều kết nối tại CÙNG địa điểm
    → tăng băng thông
        ↓
    Địa điểm đó mất điện = mất hết
    → không loại bỏ được điểm hỏng

Từ khoá nhận diện:

"DX single point of failure, most cost-effective" → VPN backup "maximum resiliency" → hai DX, hai địa điểm "increase bandwidth same location" → LAG "encrypt DX traffic" → public VIF + VPN over DX

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | BGP động bắt buộc cho chuyển đổi tự động | | | Tuyến tĩnh không tự chuyển được | | | AS_PATH prepending điều khiển ưu tiên | |

⚠ Với tuyến tĩnh thì không có chuyển đổi tự động:

Static route: tuyến luôn tồn tại trong bảng
    → DX chết nhưng tuyến vẫn còn
    → gói tin đi vào hố đen
        ↓
    BGP: tuyến biến mất khi phiên BGP đứt
    → chuyển sang đường còn lại

Ba lưu ý về băng thông VPN: | Lưu ý | Chi tiết | |---|---| | ~1,25 Gbps mỗi đường hầm | | | Giới hạn là mỗi LUỒNG, không phải tổng | | | ECMP với Transit Gateway gộp nhiều hầm | |

⚠ Transit Gateway đơn giản hoá kiến trúc 10 VPC:

10 VPN connection tới 10 VGW
    → 10 thứ phải quản lý
        ↓
    Transit Gateway: MỘT VPN tới TGW
    → 10 VPC gắn vào TGW
    → và ECMP tăng băng thông

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

⚠ EnableAcceleration cho Accelerated Site-to-Site VPN:

Lưu lượng vào edge AWS gần nhất
    → rồi đi trên mạng riêng của AWS
        ↓
    Độ trễ ổn định hơn VPN thường
    → thu hẹp khoảng cách với DX

Ba lưu ý về MTU: | Lưu ý | Chi tiết | |---|---| | IPsec thêm overhead, giảm MSS hiệu dụng | | | Bật MSS clamping trên thiết bị | | | Không làm thì tải tệp lớn treo | |

⚠ Đây là lỗi rất khó chẩn đoán:

Ping được, SSH được, nhưng tải tệp lớn treo
    → gói lớn bị rơi do MTU
        ↓
    Triệu chứng "một phần hoạt động"
      luôn đáng nghi MTU

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | TunnelState | cả hai hầm phải lên | | ConnectionState của DX | | | BGP session state | |

aws cloudwatch put-metric-alarm --alarm-name vpn-ham-down \
  --namespace AWS/VPN --metric-name TunnelState \
  --dimensions Name=VpnId,Value=vpn-abc \
  --statistic Minimum --period 300 --evaluation-periods 1 \
  --threshold 1 --comparison-operator LessThanThreshold \
  --alarm-actions <arn-sns>

Ba lưu ý về diễn tập: | Việc | Chi tiết | |---|---| | Tắt phiên BGP của DX để thử chuyển đổi | | | Đo thời gian chuyển và băng thông sau đó | | | Kiểm tra ứng dụng chịu được băng thông thấp hơn | |

⚠ Diễn tập là bước không được bỏ:

Đường dự phòng chưa từng dùng
    → không biết nó có thật sự hoạt động
        ↓
    Và không biết ứng dụng chịu được
      băng thông giảm hay không

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | VPN ~0,05 USD/giờ mỗi kết nối | | | Phí truyền dữ liệu ra tính riêng | | | Rẻ hơn DX thứ hai nhiều lần | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra cả hai hầm của mỗi VPN lên | | | Xem tuyến BGP ưu tiên DX | | | Diễn tập chuyển đổi | |

Và một lời khuyên: hãy cân nhắc gộp 10 VPC vào một Transit Gateway trước khi dựng 10 kết nối VPN riêng lẻ. Cách trong đáp án hoạt động, nhưng mười đường hầm VPN cần mười lần cấu hình, mười lần giám sát và mười cơ hội để một cái lặng lẽ hỏng mà không ai biết.

Đáp án

A — Bucket S3 không có quyền đọc công khai, nên khách truy cập không xem được nội dung.

Vì sao đúng

Đề mô tả một cấu hình S3 static website hosting đã làm gần đủ mọi bước, nhưng thiếu bước quan trọng nhất.

⚠ S3 Block Public Access BẬT MẶC ĐỊNH cho mọi bucket mới:

Từ tháng 4/2023, AWS bật sẵn cả bốn cờ
Block Public Access cho bucket mới
        ↓
    Bật static website hosting: được
    Tải tệp lên: được
    Tạo bản ghi Route 53: được
        ↓
    Nhưng khách truy cập nhận 403 Forbidden
    → vì bucket vẫn riêng tư

Hai bước phải làm để website công khai chạy:

# 1. Tắt Block Public Access cho bucket này
aws s3api put-public-access-block \
  --bucket www.tutorialsdojo.com \
  --public-access-block-configuration \
    BlockPublicAcls=false,IgnorePublicAcls=false,\
BlockPublicPolicy=false,RestrictPublicBuckets=false

# 2. Thêm bucket policy cho phép đọc công khai
aws s3api put-bucket-policy --bucket www.tutorialsdojo.com \
  --policy '{"Version":"2012-10-17","Statement":[{
    "Sid":"ChoPhepDocCongKhai","Effect":"Allow",
    "Principal":"*","Action":"s3:GetObject",
    "Resource":"arn:aws:s3:::www.tutorialsdojo.com/*"}]}'

⚠ Thiếu bước 1 thì bước 2 bị TỪ CHỐI:

`BlockPublicPolicy=true` chặn việc GẮN
bucket policy công khai
        ↓
    Cố gắn sẽ nhận lỗi
    → phải tắt cờ trước

Vì sao các phương án khác không phải nguyên nhân:

Error document: TUỲ CHỌN, không bắt buộc
DNS propagation: alias record của Route 53
                 có hiệu lực trong vài phút
URL không có tên tệp: index document đã khai
                      → S3 tự phục vụ index.html

Ba lợi ích của việc hiểu đúng nguyên nhân: | Lợi ích | Chi tiết | |---|---| | Sửa trong một lệnh | | | Không chờ đợi vô ích | | | Không đổi kiến trúc | |

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

⚠ Đề còn một vấn đề nữa mà đáp án không nhắc: tên miền gốc chưa có bucket.

Đề nói cả `tutorialsdojo.com` và
`www.tutorialsdojo.com` đều không chạy
        ↓
    Nhưng chỉ tạo MỘT bucket tên
      `www.tutorialsdojo.com`
        ↓
    Apex domain KHÔNG có bucket nào
    → sửa quyền công khai chỉ chữa được
      một nửa vấn đề

Cách chuẩn cho apex domain:

aws s3 mb s3://tutorialsdojo.com

aws s3api put-bucket-website --bucket tutorialsdojo.com \
  --website-configuration '{"RedirectAllRequestsTo":{
    "HostName":"www.tutorialsdojo.com","Protocol":"https"}}'

Bucket apex chỉ CHUYỂN HƯỚNG sang www
    → tên bucket phải TRÙNG tên miền
    → đây là ràng buộc của S3 website hosting

⚠ Và với thiết kế mới, đừng dùng S3 website endpoint công khai: | Vấn đề | Chi tiết | |---|---| | Chỉ HTTP, KHÔNG có HTTPS | | | Bucket phải công khai | | | Không có WAF, không geo restriction | |

Cách khuyến nghị hiện nay:
    S3 riêng tư + CloudFront + OAC
        ↓
    HTTPS miễn phí qua ACM
    → và bucket không bao giờ công khai

aws cloudfront create-origin-access-control \
  --origin-access-control-config '{
    "Name":"oac-trang-web",
    "OriginAccessControlOriginType":"s3",
    "SigningBehavior":"always","SigningProtocol":"sigv4"}'

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

• **B. Chưa đặt error document — đây là phương án gần nhất và error document thật sự là một mục cấu hình, nhưng nó TUỲ CHỌN; thiếu nó chỉ khiến lỗi 404 hiện trang mặc định của S3, không chặn trang chủ.
• **C. Route 53 chưa lan truyền xong, chờ 12 giờ — bản ghi alias của Route 53 có hiệu lực trong vài phút; và triệu chứng của DNS chưa lan truyền là không phân giải được tên, không phải không thấy nội dung.
• **D. URL cần có tên tệp ở cuối — đã khai index.html làm index document, nên S3 tự phục vụ nó khi truy cập thư mục gốc.

Ghi nhớ

⚠ Bốn cờ của S3 Block Public Access — bảng phải thuộc: | Cờ | Chặn gì | |---|---| | BlockPublicAcls | tạo ACL công khai MỚI | | IgnorePublicAcls | bỏ qua ACL công khai ĐÃ CÓ | | BlockPublicPolicy | gắn bucket policy công khai MỚI | | RestrictPublicBuckets | chặn truy cập qua policy công khai đã có |

⚠ Nên bật cả bốn ở CẤP TÀI KHOẢN:

aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

Áp cho MỌI bucket, kể cả bucket tạo sau
    → và dùng CloudFront + OAC cho nội dung công khai
    → không cần bucket công khai nào

Từ khoá nhận diện:

"S3 static website returns 403" → Block Public Access hoặc thiếu bucket policy "HTTPS for static site" → CloudFront + ACM "apex domain to S3" → bucket trùng tên + redirect, hoặc CloudFront "SPA deep link returns 404" → error document trỏ về index.html

Ba yêu cầu của S3 static website hosting: | Yêu cầu | Chi tiết | |---|---| | Bật website hosting | khai index document | | Tắt Block Public Access | | | Bucket policy cho s3:GetObject | |

⚠ Tên bucket phải TRÙNG tên miền:

Muốn phục vụ www.tutorialsdojo.com
    → bucket phải tên đúng www.tutorialsdojo.com
        ↓
    Đây là ràng buộc của S3 website endpoint
    → không áp dụng khi dùng CloudFront

Ba lưu ý về endpoint của S3: | Endpoint | Đặc điểm | |---|---| | REST API endpoint | bucket.s3.region.amazonaws.com — hỗ trợ HTTPS | | Website endpoint | bucket.s3-website-region.amazonaws.com — chỉ HTTP | | Khác nhau về hành vi | website endpoint có index/error document |

⚠ Dùng nhầm endpoint là lỗi phổ biến:

Trỏ alias tới REST endpoint
    → không có index document
    → truy cập thư mục gốc trả về danh sách XML
        ↓
    Phải trỏ tới WEBSITE endpoint

Ba lưu ý về SPA: | Lưu ý | Chi tiết | |---|---| | Đường dẫn client-side trả 404 từ S3 | | | Trỏ error document về index.html | | | Với CloudFront, dùng custom error response mã 200 | |

{"CustomErrorResponses": {"Quantity": 1, "Items": [{
  "ErrorCode": 404,
  "ResponsePagePath": "/index.html",
  "ResponseCode": "200",
  "ErrorCachingMinTTL": 0}]}}

Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Bản ghi ALIAS cho apex domain | | | Alias miễn phí truy vấn | | | Trỏ tới S3 website endpoint hoặc CloudFront | |

Ba lưu ý về cache: | Loại tệp | TTL | |---|---| | index.html | ngắn hoặc 0 | | JS/CSS có hash trong tên | rất dài | | Ảnh | dài |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | S3 lưu trữ ~0,023 USD/GB-tháng | | | GET request rất rẻ | | | CloudFront giảm phí truyền so với S3 trực tiếp | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bucket công khai là bề mặt tấn công | | | CloudFront + OAC là cách hiện đại | | | Bật S3 server access log để theo dõi | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl -I website endpoint | xem mã trả về | | Kiểm tra Block Public Access | | | Kiểm tra bucket policy | |

curl -sI http://www.tutorialsdojo.com.s3-website-us-west-2.amazonaws.com \
  | head -1
aws s3api get-public-access-block --bucket www.tutorialsdojo.com

Và một lời khuyên: hãy dùng CloudFront với OAC thay vì S3 website endpoint công khai. Nó cho HTTPS miễn phí, giữ bucket hoàn toàn riêng tư, và loại bỏ luôn cả loại lỗi cấu hình mà câu hỏi này đang mô tả — không còn quyền công khai nào để quên bật hay bật nhầm.

Đáp án

B — Cập nhật task definition của Fargate, đặt auto-assign public IP là DISABLED; dựng NAT gateway ở subnet CÔNG KHAI của VPC và cập nhật route table của subnet riêng tư để định tuyến yêu cầu ra Internet.

Vì sao đúng

Đề cho một thông báo lỗi rất rõ, và nó chỉ thẳng vào nguyên nhân:

CannotPullContainerError: ... request canceled
while waiting for connection
        ↓
    Task KHÔNG kết nối được tới ECR
    → vì subnet riêng tư không có đường ra

⚠ Fargate cần đường ra để kéo image — luôn luôn:

Task khởi động
    → ECS agent kéo image từ ECR
        ↓
    Subnet riêng tư, không NAT, không endpoint
    → không tới được ECR
    → task không bao giờ khởi động

Dựng NAT gateway:

eip=$(aws ec2 allocate-address --domain vpc \
      --query AllocationId --output text)

nat=$(aws ec2 create-nat-gateway \
      --subnet-id subnet-cong-khai-a \
      --allocation-id $eip \
      --query NatGateway.NatGatewayId --output text)

aws ec2 create-route --route-table-id rtb-rieng-tu-a \
  --destination-cidr-block 0.0.0.0/0 --nat-gateway-id $nat

⚠ NAT gateway phải đặt trong subnet CÔNG KHAI:

Đặt trong subnet riêng tư
    → nó cũng phải đi qua chính nó để ra ngoài
        ↓
    Vòng lặp — không bao giờ ra được

Đây là lý do phương án C sai.

⚠ Và assign_public_ip phải DISABLED vì task ở subnet riêng tư:

Đặt ENABLED trong subnet riêng tư
    → Fargate cố gán IP công khai
    → nhưng subnet không có route tới internet gateway
        ↓
    IP công khai vô dụng — vẫn không ra được

⚠ Lựa chọn thay thế: VPC endpoint thay cho NAT gateway:

# Interface endpoint cho ECR
for dv in ecr.api ecr.dkr; do
  aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
    --vpc-endpoint-type Interface \
    --service-name com.amazonaws.us-east-1.$dv \
    --subnet-ids subnet-rieng-tu-a subnet-rieng-tu-b \
    --security-group-ids sg-endpoint --private-dns-enabled
done

# Gateway endpoint cho S3 — MIỄN PHÍ
aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-rieng-tu-a rtb-rieng-tu-b

⚠ Thiếu S3 endpoint là lỗi phổ biến nhất khi dùng endpoint thay NAT:

ECR chỉ giữ SIÊU DỮ LIỆU của image
    → các LAYER thật nằm trong S3
        ↓
    Có endpoint ECR mà thiếu S3
    → `docker pull` treo ở phần tải layer

Ba endpoint cần cho Fargate ở subnet riêng tư hoàn toàn: | Endpoint | Việc | |---|---| | ecr.api | gọi ECR API | | ecr.dkr | kéo image | | s3 (Gateway) | tải layer image | | logs | ghi log CloudWatch |

Ba lợi ích của NAT gateway: | Lợi ích | Chi tiết | |---|---| | Một cấu hình cho mọi lưu lượng ra | | | AWS quản lý, tự mở rộng | | | Không phải liệt kê từng dịch vụ | |

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

• **C. Đặt public IP DISABLED và dựng NAT gateway trong subnet RIÊNG TƯ — đây là phương án gần nhất và chỉ sai một từ, nhưng NAT gateway trong subnet riêng tư không có đường ra Internet nên hoàn toàn vô dụng.
• **A. Đặt public IP ENABLED và tạo gateway VPC endpoint cho ECR — sai hai lần: ECR không có gateway endpoint (chỉ có interface endpoint), và bật IP công khai trong subnet riêng tư không giúp gì.
• **D. Cho rằng đây là giới hạn của network mode awsvpc và đổi sang bridge — Fargate CHỈ hỗ trợ awsvpc, không đổi được; và network mode không phải nguyên nhân.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ | Phí | |---|---|---| | Gateway | CHỈ S3 và DynamoDB | MIỄN PHÍ | | Interface (PrivateLink) | hầu hết dịch vụ còn lại, gồm ECR | có phí |

⚠ ECR chỉ có INTERFACE endpoint — đây là chi tiết phân biệt phương án A.

Từ khoá nhận diện:

"CannotPullContainerError in private subnet" → thiếu NAT gateway hoặc VPC endpoint "Fargate network mode" → luôn là awsvpc "private subnet needs outbound internet" → NAT gateway ở subnet CÔNG KHAI "avoid NAT cost" → VPC endpoint

⚠ NAT gateway vs VPC endpoint — chọn theo chi phí: | Cách | Chi phí | |---|---| | NAT gateway | 0,045 USD/giờ + 0,045 USD/GB | | Interface endpoint | 0,01 USD/giờ/AZ + 0,01 USD/GB | | Gateway endpoint (S3) | MIỄN PHÍ |

Kéo image lớn thường xuyên
    → phí xử lý dữ liệu NAT rất lớn
        ↓
    Endpoint ECR + S3 rẻ hơn nhiều

Ba lưu ý về Fargate networking: | Lưu ý | Chi tiết | |---|---| | BẮT BUỘC network mode awsvpc | | | Mỗi task có ENI và IP riêng | | | Gắn security group cho từng task | |

Ba trường hợp assign_public_ip: | Subnet | Giá trị | Kết quả | |---|---|---| | Công khai | ENABLED | ra Internet trực tiếp | | Riêng tư | DISABLED + NAT | ra qua NAT | | Riêng tư | DISABLED + endpoint | ra qua PrivateLink |

⚠ Đặt ENABLED trong subnet công khai là cách rẻ nhất cho môi trường thử:

Không cần NAT gateway
    → tiết kiệm ~32 USD/tháng
        ↓
    Nhưng task phơi ra Internet
    → chỉ dùng cho dev, không dùng cho sản xuất

Ba lưu ý về NAT gateway: | Lưu ý | Chi tiết | |---|---| | Đặt trong subnet CÔNG KHAI | | | Một cái MỖI AZ cho sẵn sàng cao | | | Không gắn security group được | |

Ba lưu ý về interface endpoint: | Lưu ý | Chi tiết | |---|---| | Bật --private-dns-enabled | | | Security group phải cho phép cổng 443 từ task | | | Tạo ở mọi AZ task có thể chạy | |

⚠ Quên --private-dns-enabled là lỗi im lặng:

Không bật: tên dịch vụ phân giải thành IP CÔNG KHAI
    → gói tin đi ra Internet → không có đường
        ↓
    Triệu chứng giống hệt như chưa tạo endpoint

Ba lưu ý về execution role: | Lưu ý | Chi tiết | |---|---| | Cần AmazonECSTaskExecutionRolePolicy | | | Kéo image và ghi log là việc của execution role | | | Khác với task role của mã ứng dụng | |

Ba lưu ý về gỡ lỗi task không khởi động: | Bước | Cách | |---|---| | Đọc stoppedReason của task | | | Kiểm tra route table của subnet | | | Kiểm tra security group cho phép ra 443 | |

aws ecs describe-tasks --cluster cum-ung-dung --tasks <id> \
  --query "tasks[0].[lastStatus,stoppedReason]"

Ba lưu ý về ECR: | Lưu ý | Chi tiết | |---|---| | Pull-through cache cho image công khai | | | Bật scanOnPush quét lỗ hổng | | | Lifecycle policy dọn image cũ | |

Ba lưu ý về siết chiều ra: | Lưu ý | Chi tiết | |---|---| | Security group của task nên giới hạn chiều ra | | | Chỉ cho tới endpoint và dịch vụ cần thiết | | | Giảm thiệt hại nếu container bị chiếm | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra route table có tuyến 0.0.0.0/0 | | | Xác nhận NAT gateway ở subnet công khai | | | Chạy lại task và xem trạng thái | |

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu-a \
  --query "RouteTables[0].Routes[?DestinationCidrBlock=='0.0.0.0/0']"

Và một lời khuyên: hãy tạo S3 Gateway endpoint ngay cả khi đã có NAT gateway. Layer image của ECR nằm trong S3 và thường chiếm phần lớn lưu lượng kéo image — endpoint đó miễn phí và cắt được khoản phí xử lý dữ liệu NAT lớn nhất mà không đánh đổi gì.

Đáp án

C — Dùng AWS Serverless Application Model (SAM) và dựng CI/CD bằng CodeBuild, CodeDeploy và CodePipeline.

Vì sao đúng

Đề nêu ba yêu cầu, và bộ công cụ này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Kiến trúc serverless: Lambda, API Gateway, DynamoDB | SAM là framework chuyên cho serverless | | CI/CD tự động hoá quá trình build | CodeBuild + CodePipeline | | Hỗ trợ TRIỂN KHAI DẦN DẦN | CodeDeploy — canary và linear cho Lambda |

⚠ "Gradual deployments" là từ khoá chỉ thẳng vào CodeDeploy:

CodeDeploy có sẵn các cấu hình triển khai dần cho Lambda
    → Canary10Percent5Minutes
    → Linear10PercentEvery1Minute
        ↓
    Và tự quay lui khi CloudWatch alarm kêu

SAM template với triển khai dần:

Transform: AWS::Serverless-2016-10-31
Resources:
  HamApi:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      Handler: app.handler
      AutoPublishAlias: prod
      DeploymentPreference:
        Type: Canary10Percent5Minutes
        Alarms:
          - !Ref CanhBaoLoi
        Hooks:
          PreTraffic: !Ref HamKiemTraTruoc
          PostTraffic: !Ref HamKiemTraSau
      Events:
        Api:
          Type: HttpApi
          Properties: {Path: /{proxy+}, Method: ANY}

  BangDuLieu:
    Type: AWS::Serverless::SimpleTable

⚠ AutoPublishAlias là điều kiện để triển khai dần hoạt động:

Không có alias: Lambda chỉ có $LATEST
    → không chia được lưu lượng theo tỷ lệ
        ↓
    AutoPublishAlias tạo version mới mỗi lần deploy
    → và alias trỏ theo tỷ lệ giữa version cũ và mới

⚠ Alarms cho quay lui TỰ ĐỘNG — đây là phần quan trọng nhất:

Trong lúc canary đang chạy
    → alarm kêu vì tỷ lệ lỗi tăng
        ↓
    CodeDeploy tự chuyển 100% lưu lượng
      về version cũ
    → không cần ai bấm nút

Vì sao SAM hơn CloudFormation thuần:

SAM là phần mở rộng của CloudFormation
    → `AWS::Serverless::Function` gọn hơn nhiều
      so với khai Lambda + IAM role + permission
      + log group bằng tay
        ↓
    Và có `sam local` để chạy thử ngay trên máy

sam build
sam local invoke HamApi -e su-kien.json
sam local start-api
sam deploy --guided

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ít dòng cấu hình hơn CloudFormation thuần | | | Kiểm thử cục bộ trước khi triển khai | | | Triển khai dần và quay lui tự động | |

⚠ Bốn cấu hình triển khai của CodeDeploy cho Lambda: | Cấu hình | Cách chia | |---|---| | AllAtOnce | chuyển hết ngay | | Canary10Percent5Minutes | 10% trong 5 phút rồi 100% | | Canary10Percent30Minutes | 10% trong 30 phút | | Linear10PercentEvery1Minute | tăng 10% mỗi phút |

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

• **D. Dựng CI/CD bằng CodeCommit, CodeBuild, CodeDeploy, CodePipeline rồi dùng Systems Manager Automation để tự động hoá build và triển khai dần — đây là phương án gần nhất và bộ CI/CD hoàn toàn đúng, nhưng Systems Manager Automation dành cho vận hành hạ tầng (vá máy, khởi động lại dịch vụ), không phải cơ chế triển khai dần cho Lambda; CodeDeploy đã làm việc đó.
• **B. Dùng Serverless Application Repository — SAR là kho chia sẻ ứng dụng serverless đóng gói sẵn, không phải công cụ CI/CD; nó dùng để phân phối ứng dụng cho người khác cài.
• **A. Dùng CloudFormation và OpsWorks — OpsWorks quản lý cấu hình cho máy chủ bằng Chef/Puppet, không liên quan tới serverless; và nó đã kết thúc vòng đời tháng 5/2024.

Ghi nhớ

⚠ Bốn dịch vụ Code — bảng phải thuộc:* | Dịch vụ | Việc | |---|---| | CodeCommit | kho mã Git | | CodeBuild | biên dịch, chạy test, đóng gói | | CodeDeploy | triển khai, có canary và rollback | | CodePipeline | điều phối các bước |

⚠ CodeCommit không nhận khách hàng mới từ tháng 7/2024:

Dự án mới nên dùng GitHub, GitLab, hoặc Bitbucket
    → CodePipeline kết nối được với cả ba
        ↓
    Khách hàng đang dùng CodeCommit vẫn tiếp tục được

Từ khoá nhận diện:

"serverless + CI/CD + gradual deployment" → SAM + CodeDeploy "infrastructure as code, general purpose" → CloudFormation / CDK "share packaged serverless app" → Serverless Application Repository "patch and operate instances" → Systems Manager

⚠ SAM vs CDK vs CloudFormation: | Công cụ | Đặc điểm | |---|---| | SAM | YAML gọn, chuyên serverless, có sam local | | CDK | viết bằng ngôn ngữ lập trình, mọi loại tài nguyên | | CloudFormation | YAML/JSON thuần, đầy đủ nhất |

SAM và CDK đều SINH RA CloudFormation
    → nên đều thừa hưởng change set,
      drift detection, rollback

Ba lưu ý về hook của CodeDeploy: | Hook | Khi nào chạy | |---|---| | PreTraffic | trước khi chuyển lưu lượng | | PostTraffic | sau khi chuyển xong | | Hook thất bại | huỷ triển khai |

⚠ PreTraffic hook là nơi chạy kiểm thử tự động:

import boto3
cd = boto3.client('codedeploy')

def handler(su_kien, ngu_canh):
    trang_thai = 'Succeeded' if kiem_thu_qua() else 'Failed'
    cd.put_lifecycle_event_hook_execution_status(
        deploymentId=su_kien['DeploymentId'],
        lifecycleEventHookExecutionId=su_kien['LifecycleEventHookExecutionId'],
        status=trang_thai)

Ba lưu ý về alarm cho quay lui: | Metric | Ý nghĩa | |---|---| | Lambda Errors | lỗi hàm | | API Gateway 5XXError | lỗi phía máy chủ | | Metric nghiệp vụ | quan trọng nhất |

⚠ Metric nghiệp vụ bắt được thứ metric kỹ thuật bỏ sót:

Không có lỗi 5xx nào
    → nhưng tỷ lệ giao dịch thành công giảm 30%
        ↓
    Đó mới là dấu hiệu phải quay lui

Ba lưu ý về CodePipeline: | Lưu ý | Chi tiết | |---|---| | Nhiều stage: Source, Build, Test, Deploy | | | Manual approval trước khi lên sản xuất | | | Chạy song song nhiều action trong một stage | |

Ba lưu ý về CodeBuild: | Lưu ý | Chi tiết | |---|---| | buildspec.yml định nghĩa các bước | | | Cache dependency để build nhanh hơn | | | Chạy được trong VPC nếu cần | |

version: 0.2
phases:
  install:
    runtime-versions: {python: 3.12}
  build:
    commands:
      - pip install -r requirements.txt -t .
      - python -m pytest
      - sam build
artifacts:
  files: [.aws-sam/**/*]
cache:
  paths: ['/root/.cache/pip/**/*']

Ba lưu ý về DynamoDB trong SAM: | Lưu ý | Chi tiết | |---|---| | AWS::Serverless::SimpleTable cho bảng đơn giản | | | Dùng AWS::DynamoDB::Table nếu cần GSI | | | DeletionPolicy: Retain cho bảng sản xuất | |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | SAM có policy template sẵn | | | DynamoDBCrudPolicy, S3ReadPolicy... | | | Gọn hơn viết IAM policy tay | |

Policies:
  - DynamoDBCrudPolicy:
      TableName: !Ref BangDuLieu

Ba lưu ý về môi trường: | Lưu ý | Chi tiết | |---|---| | Mỗi môi trường một stack riêng | | | Tham số hoá theo môi trường | | | Pipeline có stage cho từng môi trường | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Triển khai thử và xem canary chia lưu lượng | | | Cố tình gây lỗi, xem có quay lui không | | | Kiểm tra sam local chạy được | |

aws deploy list-deployments --application-name <ten> \
  --query "deployments" --output table

Và một lời khuyên: hãy khai Alarms trong DeploymentPreference ngay từ lần triển khai đầu tiên. Canary chia lưu lượng theo tỷ lệ là để giới hạn thiệt hại, nhưng nếu phải chờ ai đó nhìn thấy đồ thị rồi bấm nút quay lui thì phần lưu lượng đó vẫn chịu lỗi suốt khoảng thời gian ấy.

Đáp án

A và B — Ở Tài khoản A, tạo authorization để gắn private hosted zone với VPC mới ở Tài khoản B; ở Tài khoản B, thực hiện associate VPC với hosted zone của Tài khoản A, rồi xoá authorization sau khi gắn xong.

Vì sao đúng

Đề mô tả đúng triệu chứng của private hosted zone chưa được gắn với VPC:

Bản ghi CNAME đã tạo đúng ở Tài khoản A
    → nhưng VPC ở Tài khoản B chưa gắn với hosted zone
        ↓
    Máy trong VPC đó không thấy hosted zone
    → tên miền không phân giải được

⚠ Gắn VPC xuyên tài khoản là quy trình HAI BƯỚC ở HAI tài khoản:

# Bước 1 — ở tài khoản SỞ HỮU hosted zone (A)
aws route53 create-vpc-association-authorization \
  --hosted-zone-id <id-zone> \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-tai-khoan-b

# Bước 2 — ở tài khoản SỞ HỮU VPC (B)
aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id <id-zone> \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-tai-khoan-b

⚠ Chỉ làm một bước thì không có tác dụng:

Chỉ bước 1: uỷ quyền tồn tại nhưng chưa gắn
Chỉ bước 2: bị từ chối vì chưa được uỷ quyền
        ↓
    Phải làm CẢ HAI, ở ĐÚNG tài khoản

⚠ Và xoá authorization sau khi xong là thực hành tốt:

aws route53 delete-vpc-association-authorization \
  --hosted-zone-id <id-zone> \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-tai-khoan-b

Uỷ quyền còn tồn tại = tài khoản B gắn lại được
  bất cứ lúc nào
        ↓
    Việc gắn đã hoàn tất không bị ảnh hưởng
    → xoá uỷ quyền chỉ dọn sạch

Điều kiện bắt buộc của VPC: | Thuộc tính | Giá trị | |---|---| | enableDnsSupport | true | | enableDnsHostnames | true |

aws ec2 modify-vpc-attribute --vpc-id vpc-abc --enable-dns-support
aws ec2 modify-vpc-attribute --vpc-id vpc-abc --enable-dns-hostnames

⚠ Hai thuộc tính này tắt thì private hosted zone hoàn toàn im lặng:

Không có lỗi, không có cảnh báo
    → chỉ là mọi truy vấn trả về NXDOMAIN
        ↓
    Kiểm tra chúng TRƯỚC khi đi tìm nguyên nhân khác

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một hosted zone cho mọi tài khoản | | | Không cần forwarder hay Resolver rule | | | Đội DNS trung tâm giữ toàn quyền kiểm soát | |

⚠ Đây là kiến trúc DNS đơn giản nhất cho nhiều tài khoản:

Cách khác: mỗi tài khoản một hosted zone
           + Resolver rule chuyển tiếp
        ↓
    Nhiều hosted zone cho cùng tên miền
    → bản ghi lệch nhau theo thời gian

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

• **C. Tạo private hosted zone MỚI ở Tài khoản B và "associate zone này với zone ở Tài khoản A để nhân bản" — đây là phương án gần nhất vì cũng nói tới association, nhưng hosted zone KHÔNG gắn với hosted zone khác; association chỉ giữa hosted zone và VPC. Không có cơ chế nhân bản giữa hai hosted zone.
• **E. VPC peering giữa hai tài khoản và cấu hình EC2 dùng DNS resolver IP của Tài khoản A — Route 53 Resolver chỉ trả lời trong chính VPC của nó; địa chỉ VPC_CIDR + 2 không truy cập được qua peering.
• **D. Tạo AMI có sẵn /etc/resolv.conf ánh xạ endpoint RDS sang IP — cứng hoá IP của RDS là sai nghiêm trọng: endpoint RDS đổi IP khi failover, và ánh xạ tĩnh sẽ trỏ vào máy đã chết.

Ghi nhớ

⚠ Ba cách phân giải DNS riêng tư xuyên tài khoản — bảng phải thuộc: | Cách | Độ phức tạp | |---|---| | Associate nhiều VPC vào MỘT private hosted zone | thấp nhất | | Route 53 Resolver rule chia sẻ qua RAM | trung bình | | Mỗi VPC một hosted zone + forwarder | cao nhất |

⚠ Khi nào cần Resolver rule thay vì associate:

Associate VPC: khi hosted zone nằm TRONG AWS
        ↓
Resolver rule: khi cần chuyển tiếp tới
               DNS server TẠI CHỖ

Từ khoá nhận diện:

"private hosted zone not resolving in another account" → VPC association authorization "resolve on-premises names from VPC" → Resolver outbound endpoint + rule "resolve VPC names from on-premises" → Resolver inbound endpoint "share DNS rules across accounts" → RAM + Resolver rule

Ba lưu ý về Route 53 Resolver: | Lưu ý | Chi tiết | |---|---| | Địa chỉ là VPC_CIDR + 2 | ví dụ 10.0.0.2 | | Hoặc 169.254.169.253 | | | CHỈ truy cập được từ TRONG VPC đó | |

⚠ Đây là lý do phương án E sai:

Resolver của VPC A không nhận truy vấn
từ VPC B, kể cả có peering
        ↓
    Muốn VPC B phân giải: gắn VPC B vào hosted zone
    → hoặc dùng Resolver inbound endpoint

Ba lưu ý về private hosted zone: | Lưu ý | Chi tiết | |---|---| | Gắn được nhiều VPC, nhiều Region | | | Tối đa 300 VPC (tăng được) | | | VPC gắn được nhiều hosted zone | |

⚠ Cẩn thận với tên miền chồng lấn:

VPC gắn hai hosted zone cùng tên miền
    → Route 53 chọn bản ghi CỤ THỂ NHẤT
        ↓
    Kết quả khó đoán
    → giữ mỗi tên miền một hosted zone duy nhất

Ba lưu ý về CNAME cho RDS: | Lưu ý | Chi tiết | |---|---| | Trỏ CNAME tới endpoint RDS, không tới IP | | | Endpoint RDS đổi IP khi failover | | | CNAME tự theo, IP cứng thì không | |

⚠ Đây là lý do phương án D sai nghiêm trọng:

Ánh xạ endpoint → IP trong /etc/resolv.conf
    → RDS failover sang standby
    → IP đổi
        ↓
    Ứng dụng trỏ vào máy đã chết
    → và không có gì báo cho nó biết

Ba lưu ý về tự động hoá: | Lưu ý | Chi tiết | |---|---| | Viết script cho quy trình hai bước | | | Đưa vào pipeline tạo tài khoản mới | | | CloudFormation hỗ trợ association | |

Ba lưu ý về gỡ lỗi DNS trong VPC: | Bước | Cách | |---|---| | Kiểm tra hai thuộc tính DNS của VPC | | | Kiểm tra VPC có trong danh sách gắn | | | dig từ máy trong VPC | |

aws route53 get-hosted-zone --id <id-zone> \
  --query "VPCs[].[VPCId,VPCRegion]" --output table

Ba lưu ý về VPC sharing (lựa chọn khác): | Lưu ý | Chi tiết | |---|---| | RAM chia sẻ subnet giữa các tài khoản | | | Mọi tài khoản dùng chung một VPC | | | DNS tự nhiên hoạt động, không cần association | |

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | VPC gắn mỗi hosted zone | 300 | | Bản ghi mỗi hosted zone | 10.000 | | Hosted zone mỗi tài khoản | 500 |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | nslookup db.tutorialsdojo.com từ máy ở Tài khoản B | | | Kiểm tra danh sách VPC đã gắn | | | Xác nhận hai thuộc tính DNS đều true | |

aws ec2 describe-vpc-attribute --vpc-id vpc-abc \
  --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-abc \
  --attribute enableDnsHostnames

Và một lời khuyên: hãy kiểm tra enableDnsSupport và enableDnsHostnames trước khi nghi ngờ bất cứ điều gì khác. Private hosted zone không phát ra một tín hiệu lỗi nào khi hai thuộc tính này tắt — mọi truy vấn chỉ đơn giản trả về NXDOMAIN, và cấu hình DNS phía trên trông hoàn toàn đúng.