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

Đáp án

A — Dùng chứng chỉ SSL với SNI (Server Name Indication).

Vì sao đúng

Đề nêu bốn URL thuộc HAI tên miền khác nhau, và tất cả phải là HTTPS trên CÙNG MỘT load balancer:

checkout.mycorp.com
www.mycorp.com
yourcorp.com/profile
yourcorp.com/search
        ↓
    Hai tên miền gốc: mycorp.com và yourcorp.com

Và đó là lý do wildcard certificate không đủ:

Wildcard *.mycorp.com:
    ✓ checkout.mycorp.com
    ✓ www.mycorp.com
    ✗ yourcorp.com          ← KHÔNG bao phủ
        ↓
    Cần hai chứng chỉ khác nhau

SNI cho phép gắn NHIỀU chứng chỉ vào MỘT listener:

SNI (Server Name Indication):
    → client gửi TÊN MIỀN muốn kết nối trong lúc bắt tay TLS
    → ALB chọn đúng chứng chỉ tương ứng
        ↓
    Một listener HTTPS phục vụ nhiều tên miền

Cấu hình:

# Chứng chỉ mặc định khi tạo listener
aws elbv2 create-listener --load-balancer-arn <arn-alb>   --protocol HTTPS --port 443   --certificates CertificateArn=<arn-cert-mycorp>   --default-actions Type=forward,TargetGroupArn=<arn-tg-mac-dinh>

# Thêm chứng chỉ khác qua SNI
aws elbv2 add-listener-certificates --listener-arn <arn-listener>   --certificates CertificateArn=<arn-cert-yourcorp>

Và ALB hỗ trợ tới 25 chứng chỉ mỗi listener (nâng được).

Và vế "ít công cấu hình nhất" cũng đúng:

✓ MỘT load balancer
✓ MỘT listener HTTPS
✓ chỉ thêm chứng chỉ, không dựng thêm hạ tầng
✓ chứng chỉ ACM miễn phí và tự gia hạn

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

• **D. Dùng wildcard SSL certificate — đây là phương án gần nhất và giải quyết được phần mycorp.com, nhưng nó không bao phủ hai tên miền khác nhau: wildcard *.mycorp.com không hợp lệ cho yourcorp.com. Và wildcard cũng không bao phủ chính tên miền gốc mycorp.com (không có phần đầu).
• **B. Dùng HTTP sang HTTPS redirect — giải quyết vấn đề khác: redirect đảm bảo người dùng gõ HTTP được chuyển sang HTTPS, nhưng nó không cung cấp chứng chỉ cho các tên miền.
• **C. Đổi SSL Security Policy của ELB — cũng giải quyết vấn đề khác: security policy quy định bộ mã hoá và phiên bản TLS được chấp nhận, không liên quan tới việc phục vụ nhiều tên miền.

Ghi nhớ

Ba cách phục vụ nhiều tên miền HTTPS: | Cách | Đặc điểm | |---|---| | SNI với nhiều chứng chỉ | nhiều tên miền bất kỳ trên MỘT listener ← câu này | | Wildcard certificate | nhiều subdomain của MỘT tên miền | | SAN certificate (multi-domain) | nhiều tên miền trong MỘT chứng chỉ |

Bảng so sánh: | | Wildcard | SAN | SNI | |---|---|---|---| | Bao phủ | *.mycorp.com | nhiều tên trong một cert | nhiều CERT khác nhau | | Hai tên miền gốc khác nhau | ❌ | ✅ | ✅ | | Thêm tên miền mới | không cần cert mới | phải cấp lại cert | chỉ thêm cert mới | | Linh hoạt nhất | | | ✅ |

SAN certificate cũng là lựa chọn hợp lệ:

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

Nhưng thêm tên miền mới phải cấp lại chứng chỉ — SNI linh hoạt hơn.

Ba lưu ý về wildcard certificate: | Lưu ý | Chi tiết | |---|---| | *.mycorp.com KHÔNG bao phủ mycorp.com | phải khai cả hai | | Chỉ bao phủ MỘT cấp subdomain | *.mycorp.com không bao a.b.mycorp.com | | Một tên miền gốc duy nhất | |

Dòng đầu là lỗi cấu hình rất phổ biến:

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

Phải khai CẢ tên miền gốc LẪN wildcard.

Ba đặc điểm của SNI: | Đặc điểm | Chi tiết | |---|---| | Là mở rộng của TLS | client gửi tên miền trong ClientHello | | Hầu hết client hiện đại hỗ trợ | trình duyệt, SDK, curl | | ALB tự chọn chứng chỉ khớp nhất | |

Ba lưu ý về ALB và chứng chỉ: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ mặc định dùng khi client không gửi SNI | | | Tối đa 25 chứng chỉ mỗi listener | nâng được | | Chứng chỉ phải ở CÙNG Region với ALB | khác CloudFront |

Chứng chỉ cho CloudFront phải ở us-east-1 — chi tiết hay bị nhầm.

Ba lợi ích của AWS Certificate Manager: | Lợi ích | Chi tiết | |---|---| | MIỄN PHÍ | cho chứng chỉ công khai dùng với dịch vụ AWS | | TỰ GIA HẠN | bắt đầu 60 ngày trước hạn | | Tích hợp sẵn | ALB, CloudFront, API Gateway |

Ba điều kiện để ACM tự gia hạn: | Điều kiện | Chi tiết | |---|---| | Chứng chỉ đang ĐƯỢC DÙNG | gắn với tài nguyên AWS | | Xác minh DNS còn hợp lệ | bản ghi CNAME xác minh vẫn còn | | Hoặc xác minh email được xác nhận | kém tin cậy hơn |

Xác minh DNS là cách đúng:

DNS validation:
    → thêm một bản ghi CNAME, GIỮ NGUYÊN nó
    → ACM tự xác minh lại khi gia hạn
        ↓
    Xoá bản ghi đó là nguyên nhân tự gia hạn thất bại

Ba tính năng định tuyến của ALB liên quan: | Tính năng | Việc | |---|---| | host-header | định tuyến theo TÊN MIỀN | | path-pattern | định tuyến theo ĐƯỜNG DẪN | | Kết hợp cả hai | |

Và đề cần cả hai loại:

# Theo host
aws elbv2 create-rule --listener-arn <arn> --priority 10   --conditions '[{"Field":"host-header","Values":["checkout.mycorp.com"]}]'   --actions '[{"Type":"forward","TargetGroupArn":"<tg-checkout>"}]'

# Theo path
aws elbv2 create-rule --listener-arn <arn> --priority 20   --conditions '[{"Field":"host-header","Values":["yourcorp.com"]},
                 {"Field":"path-pattern","Values":["/profile","/profile/*"]}]'   --actions '[{"Type":"forward","TargetGroupArn":"<tg-profile>"}]'

Ba lưu ý về SSL security policy: | Lưu ý | Chi tiết | |---|---| | Quy định phiên bản TLS và bộ mã hoá | | | Chọn policy hiện đại | ELBSecurityPolicy-TLS13-1-2-2021-06 | | Cân bằng bảo mật và tương thích client cũ | |

Ba việc nên làm: | Việc | Chi tiết | |---|---| | Chuyển hướng HTTP sang HTTPS | listener cổng 80 với redirect | | Bật HSTS | qua response headers | | Theo dõi ngày hết hạn chứng chỉ | AWS Config rule |

Và một lời khuyên: hãy dùng xác minh DNS cho mọi chứng chỉ ACM và giữ nguyên bản ghi CNAME xác minh mãi mãi. Với xác minh email, ai đó phải bấm link mỗi lần gia hạn — và với chứng chỉ cho hai tên miền và nhiều subdomain, đó là nhiều cơ hội để một lần gia hạn bị bỏ lỡ.

Đáp án

C và D.

• C — Amazon S3
• D — Amazon DynamoDB

Vì sao đúng

Đây là một trong những chi tiết cần nhớ chính xác nhất về VPC endpoint:

Gateway endpoint CHỈ hỗ trợ ĐÚNG HAI dịch vụ:
    ✓ Amazon S3
    ✓ Amazon DynamoDB
        ↓
    Mọi dịch vụ khác dùng INTERFACE endpoint (PrivateLink)

Và gateway endpoint có ba đặc điểm nổi bật: | Đặc điểm | Chi tiết | |---|---| | HOÀN TOÀN MIỄN PHÍ | không phí giờ, không phí dữ liệu | | Hoạt động qua ROUTE TABLE | không có ENI nào được tạo | | Không gắn security group | kiểm soát bằng endpoint policy |

Tạo gateway endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.s3   --route-table-ids rtb-private-a rtb-private-b

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.dynamodb   --route-table-ids rtb-private-a rtb-private-b

AWS tự thêm route với prefix list:

Đích                            Target
10.0.0.0/16                     local
0.0.0.0/0                       nat-0abc
pl-xxxxx (prefix list của S3)   vpce-0abc123

Không phải khai tay dải IP — AWS duy trì prefix list và tự cập nhật.

Và khoản tiết kiệm rất cụ thể:

Không có gateway endpoint:
    EC2 → NAT Gateway → S3
    → trả ~0,045 USD/GB phí xử lý NAT

Có gateway endpoint:
    EC2 → endpoint → S3
    → 0 USD

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

• **A. Amazon SQS — đây là phương án gần nhất và thực sự có VPC endpoint, nhưng đó là interface endpoint (PrivateLink), không phải gateway endpoint. Nó có phí theo giờ và theo GB.
• **B. Amazon Kinesis — cũng dùng interface endpoint.
• **E. Amazon SNS — cũng dùng interface endpoint.

Ghi nhớ

Ba loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ | Cơ chế | Chi phí | |---|---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | route table | MIỄN PHÍ | | Interface endpoint (PrivateLink) | hầu hết dịch vụ AWS | ENI có IP riêng | có phí | | Gateway Load Balancer endpoint | thiết bị bảo mật | chuyển hướng lưu lượng | có phí |

Câu "chỉ S3 và DynamoDB" là chi tiết được hỏi rất thường xuyên.

Gateway và Interface endpoint — bảng phân biệt: | | Gateway | Interface | |---|---|---| | Chi phí | MIỄN PHÍ | ~0,01 USD/giờ mỗi ENI mỗi AZ | | Cơ chế | route table | ENI có IP riêng | | Security group | ❌ | ✅ | | Truy cập từ TẠI CHỖ | ❌ KHÔNG | ✅ CÓ | | Truy cập từ VPC khác (peering) | ❌ | ✅ | | Private DNS | ❌ (dùng prefix list) | ✅ |

Dòng "truy cập từ tại chỗ" rất quan trọng:

Gateway endpoint hoạt động qua ROUTE TABLE của VPC
    → chỉ tài nguyên TRONG VPC dùng được
    → máy tại chỗ qua Direct Connect KHÔNG dùng được
        ↓
    Muốn truy cập S3 riêng tư từ tại chỗ:
        → interface endpoint cho S3, hoặc public VIF

Ba dịch vụ dùng interface endpoint phổ biến: | Nhóm | Dịch vụ | |---|---| | Quản lý instance | ssm, ssmmessages, ec2messages | | Container | ecr.api, ecr.dkr, ecs | | Bí mật và mã hoá | secretsmanager, kms | | Giám sát | logs, monitoring | | Nhắn tin | sqs, sns, kinesis-streams |

Ba lưu ý khi VPC không có Internet: | Lưu ý | Chi tiết | |---|---| | Cần endpoint cho MỌI dịch vụ dùng tới | dễ sót một cái | | Gateway endpoint cho S3 là BẮT BUỘC | ECR lưu layer image trong S3 | | Kiểm tra bằng cách thử gọi | |

Dòng giữa là chi tiết hay gây sự cố:

Tạo endpoint cho ecr.api và ecr.dkr nhưng quên S3
    → kéo image thất bại
    → vì layer của image nằm trong S3

Ba cách kiểm soát truy cập qua endpoint: | Cách | Chi tiết | |---|---| | Endpoint policy | giới hạn tài nguyên và hành động qua endpoint | | Resource policy với aws:SourceVpce | chỉ cho phép qua endpoint cụ thể | | Security group (chỉ interface endpoint) | ai trong VPC gọi được |

Endpoint policy cho gateway endpoint:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": ["arn:aws:s3:::kho-ung-dung/*"]}]}

Và bucket policy siết chặt hơn:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-ung-dung",
              "arn:aws:s3:::kho-ung-dung/*"],
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Bucket chỉ truy cập được qua đúng endpoint đó.

Ba cạm bẫy khi dùng VPC endpoint: | Cạm bẫy | Chi tiết | |---|---| | aws:SourceIp KHÔNG hoạt động qua endpoint | dùng aws:SourceVpce | | Chính sách chặn theo IP có thể chặn nhầm | kiểm tra lại sau khi bật | | Gateway endpoint chỉ dùng cho CÙNG Region | Region khác vẫn qua NAT |

Cạm bẫy đầu tiên gây sự cố thật:

Bucket policy chặn theo aws:SourceIp
    → EC2 gọi qua gateway endpoint
    → request không có SourceIp công cộng
        ↓
    Bị TỪ CHỐI dù đúng ra phải được phép

Ba lợi ích của VPC endpoint: | Lợi ích | Chi tiết | |---|---| | Lưu lượng không ra Internet | bảo mật | | Tiết kiệm phí NAT Gateway | ~0,045 USD/GB | | Độ trễ thấp hơn | ít chặng hơn |

Ba lưu ý về prefix list: | Lưu ý | Chi tiết | |---|---| | AWS tự cập nhật dải IP | không phải khai tay | | Dùng được trong security group outbound | giới hạn ra S3 | | Xem bằng describe-prefix-lists | |

aws ec2 describe-prefix-lists   --filters Name=prefix-list-name,Values=com.amazonaws.ap-northeast-1.s3

Ba metric để kiểm chứng hiệu quả: | Metric | Ý nghĩa | |---|---| | NAT gateway BytesOutToDestination | giảm mạnh sau khi bật endpoint | | Chi phí NAT trong Cost Explorer | xác nhận tiết kiệm | | Lỗi AccessDenied | endpoint policy quá hẹp |

Và một lời khuyên: hãy tạo gateway endpoint cho S3 và DynamoDB ở MỌI VPC ngay khi dựng, kể cả khi chưa dùng tới. Chúng hoàn toàn miễn phí, không có nhược điểm nào, và khi ứng dụng bắt đầu đọc ghi nhiều thì bạn đã tránh được khoản phí NAT mà không phải nhớ làm gì thêm.

Đáp án

D — Triển khai Kubernetes Cluster Autoscaler vào cụm EKS; cấu hình nó tích hợp với EC2 Auto Scaling group hiện có để tự khởi động hoặc chấm dứt node theo nhu cầu của pod đang chờ.

Vì sao đúng

Đề mô tả chính xác triệu chứng của việc thiếu tầng co giãn thứ hai:

HPA (Horizontal Pod Autoscaler) tăng số POD
    ↓
    Nhưng số NODE không đổi
    → pod mới không có chỗ để chạy
    → ở trạng thái Pending
        ↓
    Cần cơ chế co giãn NODE

Hai tầng co giãn của Kubernetes: | Tầng | Co giãn gì | Cơ chế | |---|---|---| | Horizontal Pod Autoscaler (HPA) | số POD | ← đã có | | Cluster Autoscaler | số NODE | ← thiếu |

Cluster Autoscaler hoạt động thế nào:

Theo dõi pod ở trạng thái PENDING
    → không xếp được chỗ vì thiếu tài nguyên
        ↓
    Tăng desiredCapacity của EC2 Auto Scaling group
    → node mới tham gia cụm
    → pod được xếp chỗ
        ↓
    Và ngược lại: node nhàn rỗi lâu thì bị gỡ

Triển khai:

eksctl create iamserviceaccount --cluster cum-render   --namespace kube-system --name cluster-autoscaler   --attach-policy-arn arn:aws:iam::123456789012:policy/ClusterAutoscalerPolicy   --approve

helm install cluster-autoscaler autoscaler/cluster-autoscaler   --namespace kube-system   --set autoDiscovery.clusterName=cum-render   --set awsRegion=ap-northeast-1   --set rbac.serviceAccount.create=false   --set rbac.serviceAccount.name=cluster-autoscaler

Và ASG cần gắn thẻ để Cluster Autoscaler tự phát hiện:

k8s.io/cluster-autoscaler/enabled = true
k8s.io/cluster-autoscaler/cum-render = owned

Vì sao đây là "ít công vận hành nhất":

✓ là giải pháp CHUẨN của cộng đồng Kubernetes
✓ tích hợp với ASG HIỆN CÓ — không đổi kiến trúc
✓ phản ứng theo pod PENDING, chính xác hơn metric gián tiếp

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

• **A. Dùng EC2 Auto Scaling với CloudWatch alarm dựa trên CPU và bộ nhớ toàn cụm — đây là phương án gần nhất và có co giãn node, nhưng nó dùng metric GIÁN TIẾP: CPU trung bình của cụm không phản ánh đúng việc "có pod nào không xếp được chỗ hay không". Một pod đòi 8 GB bộ nhớ có thể không xếp được dù CPU toàn cụm chỉ 40% — và alarm sẽ không kích hoạt.
• **C. Dùng Fargate thay thế EC2 worker node — là giải pháp hợp lệ nhưng thay đổi kiến trúc lớn: phải chuyển toàn bộ workload sang Fargate profile, và Fargate có hạn chế (không DaemonSet, không GPU, không hostPath) — với tải kết xuất video thường cần GPU thì đây là vấn đề nghiêm trọng.
• **B. Viết Lambda chạy mỗi 10 phút kiểm tra pod và gọi eksctl để co giãn thủ công — nhiều công nhất và phản ứng chậm nhất: mã tự viết phải bảo trì, và chu kỳ 10 phút quá chậm với đỉnh tải trong giờ cao điểm.

Ghi nhớ

Hai tầng co giãn của Kubernetes trên AWS — bảng phải thuộc: | Tầng | Công cụ | Co giãn | |---|---|---| | Pod | Horizontal Pod Autoscaler (HPA) | số replica của deployment | | Pod (dọc) | Vertical Pod Autoscaler (VPA) | tài nguyên mỗi pod | | Node | Cluster Autoscaler hoặc Karpenter | số EC2 worker node |

Ba cách co giãn node trên EKS: | Cách | Đặc điểm | |---|---| | Cluster Autoscaler | chuẩn Kubernetes, dùng ASG ← câu này | | Karpenter | của AWS, KHÔNG cần ASG, nhanh hơn và linh hoạt hơn | | EKS Auto Mode | AWS quản lý toàn bộ tính toán |

Karpenter đáng biết — nó là hướng AWS khuyến nghị hiện nay: | | Cluster Autoscaler | Karpenter | |---|---|---| | Cần node group / ASG | ✅ phải định nghĩa trước | ❌ không cần | | Chọn loại instance | theo node group đã khai | tự chọn loại phù hợp nhất với pod | | Tốc độ | phút | thường dưới 1 phút | | Tối ưu chi phí | theo node group | tự chọn instance rẻ nhất phù hợp | | Độ phức tạp cấu hình | phải khai nhiều node group | ít hơn |

Karpenter provisioner:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: mac-dinh
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["c6i.2xlarge", "c6i.4xlarge", "m6i.2xlarge"]
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

Với tải bursty như kết xuất video, Karpenter thường phù hợp hơn vì nó phản ứng nhanh hơn và tự chọn loại instance tối ưu. (Cluster Autoscaler vẫn là đáp án đúng theo các phương án cho sẵn và là giải pháp tích hợp với ASG hiện có.)

Ba metric cho HPA: | Metric | Chi tiết | |---|---| | CPU utilization | ← đề đang dùng | | Memory utilization | | | Custom metric | qua Prometheus Adapter hoặc CloudWatch Adapter |

Và với tải kết xuất, metric tuỳ chỉnh thường tốt hơn:

CPU tăng SAU KHI hàng đợi công việc đã dài
    → phản ứng muộn

Độ dài hàng đợi công việc kết xuất:
    → phản ánh nhu cầu NGAY LẬP TỨC

Ba cấu hình quan trọng của Cluster Autoscaler: | Cấu hình | Việc | |---|---| | --scale-down-delay-after-add | chờ trước khi thu hẹp sau khi mở rộng | | --scale-down-unneeded-time | node nhàn rỗi bao lâu thì gỡ | | --expander | chiến lược chọn node group nào để mở rộng |

Bốn chiến lược expander: | Chiến lược | Cách chọn | |---|---| | random | ngẫu nhiên | | most-pods | node group xếp được nhiều pod nhất | | least-waste | ít lãng phí tài nguyên nhất | | priority | theo mức ưu tiên bạn đặt |

Ba yêu cầu để Cluster Autoscaler hoạt động: | Yêu cầu | Chi tiết | |---|---| | IAM permission cho ASG | qua IRSA hoặc EKS Pod Identity | | ASG có thẻ tự phát hiện | k8s.io/cluster-autoscaler/* | | Pod khai resources.requests | nếu không, scheduler không biết cần bao nhiêu |

Dòng cuối rất quan trọng:

Pod không khai resources.requests:
    → Kubernetes coi như cần 0 tài nguyên
    → xếp được vô hạn pod lên một node
    → Cluster Autoscaler không bao giờ thấy pod Pending
        ↓
    Node quá tải nhưng không mở rộng

Ba lưu ý về thu hẹp: | Lưu ý | Chi tiết | |---|---| | PodDisruptionBudget bảo vệ pod quan trọng | | | Node có pod không di chuyển được sẽ không bị gỡ | ví dụ pod dùng local storage | | Annotation cluster-autoscaler.kubernetes.io/safe-to-evict: false | giữ pod lại |

PodDisruptionBudget:

apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 2
  selector:
    matchLabels: {app: ket-xuat}

Ba lựa chọn tối ưu chi phí cho tải bursty: | Lựa chọn | Chi tiết | |---|---| | Spot instance cho node | giảm tới 90%, phù hợp với tải chịu gián đoạn | | Karpenter với consolidation | tự gộp pod và gỡ node thừa | | Mixed instances policy | trộn Spot và On-Demand |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Số pod ở trạng thái Pending | chỉ báo trực tiếp cho việc thiếu node | | Mức dùng tài nguyên của node | quá thấp thì đang lãng phí | | Thời gian từ pod Pending tới Running | tốc độ phản ứng |

Và một lời khuyên: hãy kiểm tra mọi pod đều khai resources.requests trước khi triển khai Cluster Autoscaler. Đó là điều kiện tiên quyết mà không có tài liệu nào nhấn mạnh đủ — và nếu thiếu, Cluster Autoscaler sẽ chạy hoàn toàn bình thường mà không bao giờ mở rộng cụm, khiến bạn tưởng nó bị hỏng.

Đáp án

C — Nối cả hai kết nối Direct Connect vào một Direct Connect gateway DÙNG CHUNG; gắn virtual private gateway (VGW) của mỗi Region vào DX gateway đó.

Vì sao đúng

Đề nêu bốn yêu cầu, và trong các phương án cho sẵn, C là lựa chọn duy nhất hợp lý: | Yêu cầu | Cơ chế | |---|---| | Kết nối hai trung tâm dữ liệu với VPC ở hai Region | DX gateway là tài nguyên TOÀN CẦU | | CIDR không chồng lấn | điều kiện đã thoả | | Mở rộng được | DX gateway liên kết tới 10 VGW | | Ít công cấu hình thủ công | một gateway thay vì nhiều VIF riêng |

Direct Connect gateway là tài nguyên TOÀN CẦU:

DX gateway KHÔNG thuộc Region nào
    → một DX gateway liên kết được với VGW ở NHIỀU Region
        ↓
    Trung tâm dữ liệu ở Mỹ → DX gateway → VPC ở eu-central-1 ✓
    Trung tâm dữ liệu ở châu Âu → DX gateway → VPC ở us-west-2 ✓

Và đó là điều mà private VIF thông thường không làm được:

Private VIF thường:
    → gắn trực tiếp vào MỘT virtual private gateway
    → chỉ tới MỘT VPC, trong CÙNG Region

Private VIF qua DX gateway:
    → tới NHIỀU VPC, ở NHIỀU Region

Cấu hình:

aws directconnect create-direct-connect-gateway   --direct-connect-gateway-name dxgw-toan-cau --amazon-side-asn 64512

aws directconnect create-direct-connect-gateway-association   --direct-connect-gateway-id <id> --gateway-id vgw-us-west-2

aws directconnect create-direct-connect-gateway-association   --direct-connect-gateway-id <id> --gateway-id vgw-eu-central-1

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

• **B. Thiết lập inter-Region VPC peering giữa từng cặp VPC ở hai Region, dùng route table tĩnh — đây là phương án gần nhất và peering xuyên Region là tính năng có thật, nhưng nó không mở rộng được và tốn rất nhiều công: với nhiều VPC ở hai Region, số kết nối peering tăng theo cấp số nhân, và peering không bắc cầu nên phải tạo đủ mọi cặp. Đề yêu cầu "minimizes manual network configuration".
• **A. Tạo private VIF ở mỗi Region và liên kết trực tiếp với VPC ở Region NGOÀI bằng route table và BGP, dùng VPC endpoint chuyển tiếp lưu lượng xuyên Region — không phải cơ chế tồn tại: private VIF không "liên kết trực tiếp với VPC ở Region khác", và VPC endpoint không chuyển tiếp lưu lượng xuyên Region.
• **D. Triển khai thiết bị VPN chạy trên EC2 và dựng full mesh VPN kiểu CloudHub — công vận hành lớn nhất: phải tự cài, vá lỗi, mở rộng và đảm bảo sẵn sàng cao cho hàng chục thiết bị ảo. Đi ngược hẳn yêu cầu.

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

Đáp án C nói "enabling TRANSITIVE ROUTING between the VPCs" — và đó là điều Direct Connect gateway với VGW KHÔNG làm được.

AWS nêu rõ giới hạn của DX gateway khi liên kết với virtual private gateway:

❌ VPC gắn vào cùng một DX gateway KHÔNG nói chuyện được với nhau
❌ Hai kết nối Direct Connect qua cùng DX gateway KHÔNG định tuyến
   lưu lượng giữa hai mạng tại chỗ với nhau

Nói cách khác, C cho:

✓ Trung tâm dữ liệu Mỹ    ↔ mọi VPC (cả hai Region)
✓ Trung tâm dữ liệu châu Âu ↔ mọi VPC (cả hai Region)
✗ VPC ↔ VPC
✗ Trung tâm dữ liệu Mỹ ↔ trung tâm dữ liệu châu Âu

Kiến trúc thật sự cho "full connectivity" là Transit Gateway:

Mỗi Region: Transit Gateway gắn mọi VPC của Region đó
    ↓ transit VIF qua DX gateway → trung tâm dữ liệu
    ↓ TGW peering xuyên Region → TGW của Region kia
        ↓
    Bấy giờ mới có kết nối đầy đủ giữa mọi thành phần

aws ec2 create-transit-gateway-peering-attachment   --transit-gateway-id tgw-us-west-2   --peer-transit-gateway-id tgw-eu-central-1   --peer-region eu-central-1

Vậy nên hiểu câu này thế nào: C là lựa chọn tốt nhất trong bốn phương án — nó dùng đúng công cụ cho kết nối lai đa Region và tránh được sự bùng nổ kết nối của peering. Nhưng cụm từ "transitive routing between the VPCs" không phản ánh đúng khả năng thật, và trong thực tế bạn cần Transit Gateway để đạt yêu cầu đầy đủ của đề.

Ghi nhớ

Ba loại virtual interface của Direct Connect — bảng phải thuộc: | Loại | Nối tới | Phục vụ | |---|---|---| | Private VIF | virtual private gateway hoặc DX gateway | VPC | | Transit VIF | DX gateway → TRANSIT GATEWAY | nhiều VPC, có bắc cầu | | Public VIF | endpoint công khai của AWS | S3, DynamoDB qua IP công cộng |

Direct Connect gateway — ba đặc điểm: | Đặc điểm | Chi tiết | |---|---| | Là tài nguyên TOÀN CẦU | dùng cho mọi Region | | Liên kết với VGW HOẶC TGW | KHÔNG trộn cả hai trong cùng DX gateway | | VPC qua VGW KHÔNG nói chuyện với nhau | ← giới hạn quan trọng |

Bảng khả năng theo cách liên kết: | Liên kết | VPC ↔ tại chỗ | VPC ↔ VPC | |---|---|---| | DX gateway + VGW | ✅ | ❌ | | DX gateway + Transit Gateway | ✅ | ✅ |

Đây là bảng quyết định cho mọi thiết kế mạng lai đa VPC.

Ba đặc điểm của Transit Gateway: | Đặc điểm | Chi tiết | |---|---| | Định tuyến BẮC CẦU | | | Nối tới 5.000 VPC | | | Peering xuyên Region | nối TGW của hai Region |

Và TGW peering là mảnh ghép cho kiến trúc đa Region:

TGW (us-west-2) ⟷ TGW peering ⟷ TGW (eu-central-1)
        ↓
    Mọi VPC ở hai Region nói chuyện được với nhau

Ba lưu ý về TGW peering: | Lưu ý | Chi tiết | |---|---| | Phải thêm route THỦ CÔNG | peering attachment KHÔNG hỗ trợ propagation | | CIDR không được chồng lấn | | | Tính phí như attachment thường | cộng phí dữ liệu xuyên Region |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | TGW attachment | ~0,05 USD/giờ mỗi cái | | Dữ liệu qua TGW | ~0,02 USD/GB | | Dữ liệu xuyên Region | ~0,02 USD/GB thêm | | DX port | theo băng thông |

Ba biện pháp cho sẵn sàng cao của Direct Connect: | Biện pháp | Chi tiết | |---|---| | Hai kết nối ở hai vị trí khác nhau | chống hỏng một điểm | | VPN dự phòng qua Internet | BGP tự chuyển đổi | | Direct Connect SLA | phụ thuộc cấu hình dư thừa |

Ba lưu ý khi sáp nhập hạ tầng của hai công ty: | Lưu ý | Chi tiết | |---|---| | Kiểm tra CIDR không chồng lấn | ← đề đã đảm bảo | | Thống nhất quy ước đặt tên và gắn thẻ | | | Lập bản đồ mạng đầy đủ trước khi nối | |

Ba công cụ quản lý mạng đa Region: | 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 (trong một Region) | | AWS RAM | chia sẻ TGW giữa các tài khoản |

Ba bước chuyển đổi an toàn: | Bước | Chi tiết | |---|---| | Dựng TGW song song với hạ tầng hiện có | | | Chuyển từng VPC một | | | Gỡ private VIF cũ sau khi xác nhận | |

Và một lời khuyên cho dự án sáp nhập: hãy dựng Transit Gateway ở mỗi Region rồi peering chúng lại, thay vì cố ghép bằng DX gateway và VGW. Kiến trúc đó cho kết nối đầy đủ thật sự, mở rộng được khi có thêm VPC, và tránh được việc phát hiện giới hạn "VPC không nói chuyện với nhau" vào giữa dự án.

Đáp án

D — Dùng Amazon EventBridge để tách rời kiến trúc.

Vì sao đúng

Đề nêu ba đặc điểm, và EventBridge phù hợp nhất với cả ba: | Đặc điểm | Cơ chế | |---|---| | Ứng dụng SaaS phát cập nhật | EventBridge có SaaS partner integration dựng sẵn | | Nhiều ứng dụng NỘI BỘ VÀ BÊN THỨ BA nhận | định tuyến theo quy tắc tới nhiều đích | | Tách rời BẤT ĐỒNG BỘ | bus sự kiện, người gửi không biết người nhận |

Vế "SaaS" là điểm phân biệt quan trọng:

EventBridge có PARTNER EVENT SOURCE:
    → nhận sự kiện TRỰC TIẾP từ ứng dụng SaaS
      (Salesforce, Zendesk, Datadog, Shopify, Auth0...)
    → không cần viết mã tích hợp
        ↓
    Đề nói rõ "SaaS application feeds updates to other
    in-house and THIRD-PARTY applications"

Và định tuyến theo quy tắc là điều SNS không có:

EventBridge rule lọc theo NỘI DUNG sự kiện:

{"source": ["crm.congty"],
 "detail-type": ["KhachHangCapNhat"],
 "detail": {
   "loai": ["doanh-nghiep"],
   "gia-tri": [{"numeric": [">", 100000]}]}}

    → chỉ sự kiện KHỚP mới được gửi tới đích
    → mỗi ứng dụng đăng ký loại sự kiện mình quan tâm

Và EventBridge hỗ trợ hơn 270 đích:

Lambda, SQS, SNS, Step Functions, ECS task,
Kinesis, API Destination (HTTP endpoint bất kỳ),
và hầu hết API của AWS

API Destination là thứ giải quyết vế "third-party applications":

aws events create-connection --name ket-noi-doi-tac   --authorization-type API_KEY   --auth-parameters '{"ApiKeyAuthParameters":
    {"ApiKeyName":"x-api-key","ApiKeyValue":"..."}}'

aws events create-api-destination --name doi-tac-a   --connection-arn <arn> --invocation-endpoint https://api.doitac.com/webhook   --http-method POST

Gửi sự kiện tới API của bên thứ ba mà không cần viết mã tích hợp.

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

• **C. Dùng Amazon SNS để giao tiếp và tách rời — đây là phương án gần nhất và cũng là mô hình phát tán bất đồng bộ, nhưng nó thiếu hai khả năng: SNS không nhận sự kiện từ nguồn SaaS và lọc kém linh hoạt hơn (chỉ lọc theo message attribute, không lọc sâu vào nội dung JSON như EventBridge).
• **A. Dùng Amazon SQS — sai mô hình: SQS là hàng đợi một consumer nhận, không phát tán tới nhiều ứng dụng. Muốn nhiều bên nhận thì phải tạo nhiều hàng đợi và tự viết logic sao chép.
• **B. Dùng Elastic Load Balancing — sai loại dịch vụ hoàn toàn: ELB phân phối lưu lượng đồng bộ tới các máy chủ, nó không phải cơ chế tách rời bất đồng bộ.

Ghi nhớ

Bốn dịch vụ nhắn tin — bảng phải thuộc: | Dịch vụ | Mô hình | Lọc | Nguồn SaaS | |---|---|---|---| | EventBridge | bus sự kiện, định tuyến theo quy tắc | lọc sâu vào JSON | ✅ | | SNS | phát tán tới subscriber | message attribute | ❌ | | SQS | hàng đợi, một consumer nhận | ❌ | ❌ | | Kinesis | luồng, đọc lại được | ❌ | ❌ |

Từ khoá nhận diện:

"SaaS integration", "route events by content", "many targets" → EventBridge "fan-out to subscribers", "simple pub/sub" → SNS "decouple two components", "buffer" → SQS "real-time streaming, replay" → Kinesis

EventBridge và SNS — bảng phân biệt cốt lõi: | | EventBridge | SNS | |---|---|---| | Lọc | theo NỘI DUNG JSON, rất linh hoạt | theo message attribute | | Nguồn SaaS | ✅ partner event source | ❌ | | Số đích hỗ trợ | hơn 270 API của AWS | Lambda, SQS, HTTP, email, SMS | | Schema registry | ✅ tự khám phá lược đồ sự kiện | ❌ | | Archive và replay | ✅ phát lại sự kiện cũ | ❌ | | Thông lượng | thấp hơn | rất cao | | Độ trễ | ~nửa giây | thấp hơn |

Với thông lượng cực cao và độ trễ tối thiểu, SNS vẫn tốt hơn — nhưng cho tích hợp ứng dụng, EventBridge mạnh hơn nhiều.

Ba loại event bus của EventBridge: | Loại | Việc | |---|---| | Default bus | nhận sự kiện của dịch vụ AWS | | Custom bus | cho sự kiện của ứng dụng bạn | | Partner bus | nhận sự kiện từ SaaS |

Tạo custom bus:

aws events create-event-bus --name bus-crm

aws events put-events --entries '[{
  "Source":"crm.congty",
  "DetailType":"KhachHangCapNhat",
  "Detail":"{\"maKhachHang\":\"KH-001\",\"loai\":\"doanh-nghiep\"}",
  "EventBusName":"bus-crm"}]'

Ba khả năng lọc mạnh của EventBridge: | Mẫu | Ví dụ | |---|---| | Khớp giá trị | {"loai": ["doanh-nghiep"]} | | So sánh số | {"gia-tri": [{"numeric": [">", 100000]}]} | | Tiền tố | {"ma": [{"prefix": "KH-"}]} | | Loại trừ | {"trang-thai": [{"anything-but": "huy"}]} | | Tồn tại | {"email": [{"exists": true}]} |

Ba tính năng nâng cao: | Tính năng | Việc | |---|---| | Archive và Replay | lưu sự kiện và phát lại khi cần | | Schema Registry | tự khám phá và sinh mã cho lược đồ sự kiện | | API Destination | gửi tới HTTP endpoint bất kỳ, có xác thực |

Archive rất hữu ích khi gỡ lỗi:

aws events create-archive --archive-name luu-tru-crm   --event-source-arn <arn-bus> --retention-days 30

aws events start-replay --replay-name phat-lai   --event-source-arn <arn-archive>   --event-start-time 2026-08-30T00:00:00Z   --event-end-time 2026-08-30T23:59:59Z   --destination '{"Arn":"<arn-bus>","FilterArns":["<arn-rule>"]}'

Ứng dụng nhận sự kiện bị lỗi trong một khoảng thời gian
    → phát lại đúng khoảng đó
    → không mất dữ liệu

Ba cấu hình xử lý lỗi: | Cấu hình | Việc | |---|---| | RetryPolicy | số lần thử lại và tuổi tối đa | | DeadLetterConfig | gửi sự kiện thất bại vào SQS | | Input transformer | biến đổi sự kiện trước khi gửi |

Ba lưu ý về EventBridge Pipes: | Đặc điểm | Chi tiết | |---|---| | Nối một nguồn với một đích | point-to-point | | Có bước lọc và làm giàu | Lambda hoặc Step Functions | | Phù hợp | thay thế mã tích hợp thủ công |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Sự kiện tuỳ chỉnh | ~1,00 USD/triệu | | Sự kiện của dịch vụ AWS | MIỄN PHÍ trên default bus | | Archive và replay | tính riêng |

Ba lưu ý khi thiết kế sự kiện: | Lưu ý | Chi tiết | |---|---| | Đặt source và detail-type có quy ước rõ | dễ lọc | | Sự kiện nên mô tả VIỆC ĐÃ XẢY RA | không phải lệnh | | Giữ payload nhỏ | giới hạn 256 KB |

Dòng cuối quan trọng: payload lớn thì lưu vào S3 và gửi tham chiếu trong sự kiện.

Và một lời khuyên: hãy bật archive cho custom bus ngay từ đầu. Khi một ứng dụng bên thứ ba báo "chúng tôi không nhận được cập nhật hôm qua", archive cho phép bạn vừa kiểm chứng sự kiện có được phát hay không, vừa phát lại chính xác khoảng thời gian đó — hai thứ mà SNS và SQS không cung cấp.

Đáp án

B, C và F.

• B — Dùng field level encryption trong CloudFront để bảo vệ dữ liệu nhạy cảm cho nội dung cụ thể
• C — CloudFront định tuyến tới NHIỀU ORIGIN dựa trên loại nội dung
• F — Dùng origin group với origin chính và origin phụ để cấu hình sẵn sàng cao và chuyển đổi

Vì sao đúng

Ba đáp án mô tả ba khả năng thật của CloudFront:

C — nhiều origin theo loại nội dung:

Một distribution có nhiều CACHE BEHAVIOR
    → mỗi behavior khớp một mẫu đường dẫn
    → và trỏ tới một origin khác nhau
        ↓
    /api/*     → API Gateway hoặc ALB
    /anh/*     → S3 bucket ảnh
    /video/*   → S3 bucket video
    /*         → S3 bucket mặc định

aws cloudfront create-distribution --distribution-config '{
  "Origins": {"Items": [
    {"Id": "s3-tinh", "DomainName": "kho-tinh.s3.amazonaws.com", ...},
    {"Id": "alb-api", "DomainName": "api.congty.com", ...}]},
  "CacheBehaviors": {"Items": [
    {"PathPattern": "/api/*", "TargetOriginId": "alb-api", ...}]},
  "DefaultCacheBehavior": {"TargetOriginId": "s3-tinh", ...}}'

F — origin group cho chuyển đổi:

Origin group = origin CHÍNH + origin PHỤ
    → origin chính trả về mã lỗi đã cấu hình (500, 502, 503, 504, 403, 404)
    → CloudFront TỰ thử origin phụ
        ↓
    Sẵn sàng cao ở tầng origin

{"OriginGroups": {"Items": [{
  "Id": "nhom-origin",
  "FailoverCriteria": {"StatusCodes": {"Items": [500,502,503,504]}},
  "Members": {"Items": [{"OriginId": "s3-chinh"},
                        {"OriginId": "s3-du-phong"}]}}]}}

B — field level encryption bảo vệ trường nhạy cảm:

Field level encryption:
    → mã hoá các TRƯỜNG cụ thể trong form POST
      (số thẻ tín dụng, số CMND) ngay tại ĐIỂM BIÊN
    → dùng khoá công khai bạn cung cấp
        ↓
    Dữ liệu đi qua mọi tầng ứng dụng dưới dạng ĐÃ MÃ HOÁ
    → chỉ dịch vụ có khoá riêng mới giải mã được

Đây là bảo vệ sâu hơn TLS — TLS chỉ bảo vệ đường truyền, còn field level encryption bảo vệ dữ liệu suốt hành trình qua các tầng nội bộ.

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

• **A. Dùng geo restriction để cấu hình CloudFront cho sẵn sàng cao và chuyển đổi — đây là phương án gần nhất vì geo restriction là tính năng có thật của CloudFront, nhưng nó phục vụ mục đích khác: chặn người dùng ở một số quốc gia truy cập nội dung. Nó không liên quan gì tới sẵn sàng cao.
• **E. Dùng AWS KMS encryption trong CloudFront để bảo vệ dữ liệu nhạy cảm cho nội dung cụ thể — không phải tính năng của CloudFront: KMS được dùng để mã hoá dữ liệu at rest ở S3, không phải cơ chế mã hoá trường trong CloudFront. Tính năng đúng tên là field level encryption với khoá RSA bạn cung cấp.
• **D. CloudFront định tuyến tới nhiều origin dựa trên price class — nhầm khái niệm: price class quyết định những điểm biên nào được dùng để giảm chi phí, nó không liên quan tới việc chọn origin.

Ghi nhớ

Ba khả năng định tuyến của CloudFront: | Khả năng | Cơ chế | |---|---| | Nhiều origin theo đường dẫn | cache behavior với PathPattern ← câu này | | Origin group cho chuyển đổi | failover khi origin chính lỗi ← câu này | | Lambda@Edge / CloudFront Functions | định tuyến theo logic tuỳ ý |

Ba tính năng bảo mật của CloudFront: | Tính năng | Việc | |---|---| | Field level encryption | mã hoá trường cụ thể tại điểm biên ← câu này | | Signed URL / signed cookie | giới hạn ai xem được nội dung | | Origin Access Control (OAC) | khoá bucket S3 | | AWS WAF | lọc tấn công tầng 7 | | Geo restriction | chặn theo quốc gia |

Ba bước cấu hình field level encryption:

① Tạo cặp khoá RSA, tải KHOÁ CÔNG KHAI lên CloudFront
② Tạo profile khai TRƯỜNG nào cần mã hoá
③ Gắn profile với cache behavior
        ↓
    Ứng dụng phía sau dùng KHOÁ RIÊNG để giải mã

Ba giới hạn của field level encryption: | Giới hạn | Chi tiết | |---|---| | Chỉ áp cho POST với application/x-www-form-urlencoded | | | Tối đa 10 trường mỗi profile | | | Kích thước trường có giới hạn | |

Ba lưu ý về origin group: | Lưu ý | Chi tiết | |---|---| | Chỉ chuyển đổi khi origin chính trả MÃ LỖI cấu hình sẵn | 403, 404, 500, 502, 503, 504 | | Chỉ áp cho request GET, HEAD, OPTIONS | không cho POST, PUT | | Origin phụ phải có CÙNG nội dung | nếu không thì người dùng nhận nội dung khác |

Dòng giữa là hạn chế quan trọng:

Origin group KHÔNG chuyển đổi cho POST
    → chỉ bảo vệ được nội dung đọc
        ↓
    Với API ghi, cần cơ chế khác (Route 53 failover, Global Accelerator)

Ba loại chính sách của CloudFront: | Chính sách | Việc | |---|---| | Cache policy | cái gì tạo nên KHOÁ CACHE | | Origin request policy | cái gì được CHUYỂN TIẾP tới origin | | Response headers policy | header thêm vào phản hồi |

Ba tính năng tính toán ở biên: | Tính năng | Đặc điểm | |---|---| | CloudFront Functions | JavaScript nhẹ, dưới 1ms, chỉ viewer request/response | | Lambda@Edge | đầy đủ hơn, chạy được ở cả origin request/response | | — | Functions rẻ hơn nhiều |

Bốn điểm kích hoạt của Lambda@Edge:

Viewer Request  → trước khi kiểm tra cache
Origin Request  → trước khi gọi origin
Origin Response → sau khi origin trả về
Viewer Response → trước khi trả cho người dùng

Ba lựa chọn price class: | Price class | Phạm vi | |---|---| | PriceClass_All | mọi điểm biên (đắt nhất) | | PriceClass_200 | bỏ Nam Mỹ, Úc, New Zealand | | PriceClass_100 | chỉ Bắc Mỹ và châu Âu (rẻ nhất) |

Ba cách tăng tỷ lệ trúng cache: | Cách | Chi tiết | |---|---| | Mã băm nội dung trong tên tệp | TTL rất dài | | Chỉ chuyển tiếp header cần thiết | header thừa giảm tỷ lệ trúng | | Bật Origin Shield | thêm một lớp đệm |

Origin Shield đáng biết:

Không có Origin Shield:
    600 điểm biên đều có thể gọi thẳng origin

Có Origin Shield:
    600 điểm biên → 1 điểm shield → origin
        ↓
    Giảm rất nhiều tải cho origin

Ba lưu ý về sẵn sàng cao với CloudFront: | Lưu ý | Chi tiết | |---|---| | Origin group cho nội dung đọc | ← đáp án F | | Route 53 health check cho toàn hệ thống | | | CloudFront bản thân đã dư thừa cao | AWS quản lý |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | nên trên 90% với nội dung tĩnh | | OriginLatency | thời gian origin phản hồi | | 5xxErrorRate | lỗi từ origin hoặc CloudFront |

Và một lời khuyên: hãy dùng CloudFront Functions thay Lambda@Edge cho các tác vụ đơn giản như viết lại URL, thêm header bảo mật hay chuyển hướng. Chúng chạy dưới một mili giây, rẻ hơn khoảng sáu lần, và với kiến trúc nhiều origin như câu hỏi này thì phần lớn logic định tuyến đơn giản đều nằm trong khả năng của chúng.

Đáp án

A — Dùng Kinesis Data Streams thu dữ liệu từ website, đưa vào Kinesis Data Analytics để truy vấn thời gian thực; kết quả đưa vào Kinesis Data Firehose để lưu vào S3.

Vì sao đúng

Đề nêu bốn yêu cầu, và chuỗi Kinesis đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Tách rời và co giãn | Kinesis nạp độc lập với xử lý | | Phân tích THỜI GIAN THỰC | Kinesis Data Analytics truy vấn trên luồng | | KHÔNG mất dữ liệu khi đỉnh tải | dữ liệu giữ trong stream 24 giờ tới 365 ngày | | Lưu trữ để phân tích sau | Firehose → S3 |

Kiến trúc ba tầng đúng vai:

Website → Kinesis Data Streams (NẠP và GIỮ)
              ↓
          Kinesis Data Analytics (PHÂN TÍCH thời gian thực)
              ↓
          Kinesis Data Firehose (GIAO vào S3)
              ↓
            Amazon S3 (LƯU TRỮ)

Và mỗi dịch vụ làm đúng việc của nó: | Dịch vụ | Việc | |---|---| | Data Streams | nạp, giữ, cho nhiều consumer | | Data Analytics (Flink) | truy vấn SQL trên cửa sổ thời gian | | Data Firehose | giao vào đích, tự gom lô và nén |

Ví dụ truy vấn thời gian thực:

CREATE OR REPLACE STREAM "SAN_PHAM_HOT" (
  ma_san_pham VARCHAR(32), so_luot_click INTEGER);

CREATE OR REPLACE PUMP "BOM" AS INSERT INTO "SAN_PHAM_HOT"
SELECT STREAM ma_san_pham, COUNT(*)
FROM "NGUON_001"
GROUP BY ma_san_pham,
  STEP("NGUON_001".ROWTIME BY INTERVAL '1' MINUTE);

Đếm lượt click theo sản phẩm trong cửa sổ một phút — đúng nhu cầu gợi ý sản phẩm gần thời gian thực.

Và vế "không mất dữ liệu khi đỉnh tải":

Kinesis Data Streams giữ dữ liệu 24 giờ mặc định
    → consumer xử lý chậm cũng không mất gì
    → đọc lại được từ vị trí bất kỳ

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

• **C. Kinesis Data Streams → Firehose → S3, rồi dùng Athena phân tích thời gian thực — đây là phương án gần nhất và kiến trúc nạp dữ liệu hoàn toàn đúng, nhưng nó không phải phân tích THỜI GIAN THỰC: Firehose gom lô tối thiểu 60 giây, và Athena là truy vấn theo yêu cầu trên dữ liệu đã lưu — độ trễ tính bằng phút, không phù hợp cho gợi ý sản phẩm gần thời gian thực.
• **B. Kinesis Data Streams → QuickSight truy vấn thời gian thực — sai vai trò dịch vụ: QuickSight là công cụ trực quan hoá và BI, nó không nhận dữ liệu trực tiếp từ Kinesis và không phải công cụ xử lý luồng.
• **D. Dùng SQS với fleet EC2 và thư viện bên thứ ba để phân tích — nhiều công vận hành nhất: phải tự quản lý EC2, tự viết logic phân tích cửa sổ thời gian, và SQS không cho đọc lại dữ liệu.

Ghi nhớ

Ba dịch vụ trong họ Kinesis — bảng phải thuộc: | Dịch vụ | Việc | Giữ dữ liệu | |---|---|---| | Data Streams | nạp luồng, nhiều consumer | ✅ 24 giờ – 365 ngày | | Data Firehose | giao vào S3, Redshift, OpenSearch, Splunk | ❌ | | Managed Service for Apache Flink | phân tích luồng bằng SQL hoặc Java | qua nguồn |

(Kinesis Data Analytics nay được gọi là Amazon Managed Service for Apache Flink.)

Từ khoá nhận diện:

"real-time analytics on streaming data", "windowed aggregation" → Data Analytics / Flink "ingest and retain, multiple consumers, replay" → Data Streams "deliver to S3/Redshift, no code" → Data Firehose "query data already in S3" → Athena

Data Streams và Firehose — bảng phân biệt: | | Data Streams | Data Firehose | |---|---|---| | Giữ dữ liệu | ✅ đọc lại được | ❌ | | Nhiều consumer | ✅ | ❌ | | Quản lý shard | có (hoặc on-demand) | KHÔNG — tự co giãn | | Độ trễ | ~200ms | tối thiểu 60 giây | | Công vận hành | cao hơn | thấp nhất |

Dòng "độ trễ" là lý do phương án C không đạt yêu cầu thời gian thực.

Ba loại cửa sổ trong phân tích luồng: | Loại | Chi tiết | |---|---| | Tumbling window | cửa sổ cố định, không chồng lấn | | Sliding window | cửa sổ trượt, có chồng lấn | | Session window | nhóm theo phiên hoạt động |

Tumbling window là loại phổ biến nhất:

GROUP BY STEP(ROWTIME BY INTERVAL '1' MINUTE)
    → gom mọi bản ghi trong từng phút

Ba đặc điểm của Data Streams: | Đặc điểm | Chi tiết | |---|---| | Shard là đơn vị thông lượng | 1 MB/giây ghi, 2 MB/giây đọc | | Thứ tự đảm bảo trong shard | qua partition key | | Nhiều consumer độc lập | mỗi cái có vị trí đọc riêng |

Hai chế độ dung lượng: | Chế độ | Đặc điểm | |---|---| | Provisioned | chọn số shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn — phù hợp với đỉnh tải khó đoán |

Với thương mại điện tử có đỉnh tải bất ngờ, on-demand là lựa chọn an toàn.

Ba lưu ý khi chọn partition key: | Lưu ý | Chi tiết | |---|---| | Phân bố ĐỀU giữa các shard | key lệch tạo "hot shard" | | Dùng mã người dùng hoặc mã phiên | phân bố tự nhiên | | Số key nhiều hơn số shard | |

Ba đích của Firehose: | Đích | Chi tiết | |---|---| | Amazon S3 | ← câu này | | Amazon Redshift | qua S3 rồi COPY | | OpenSearch Service | tìm kiếm và dashboard | | Splunk, endpoint HTTP | bên thứ ba |

Ba cấu hình của Firehose: | Cấu hình | Việc | |---|---| | Buffer size và buffer interval | gom lô trước khi giao | | Chuyển đổi định dạng | JSON sang Parquet hoặc ORC | | Nén | GZIP, Snappy, ZIP | | Lambda transformation | biến đổi bản ghi |

Chuyển sang Parquet rất đáng làm:

Firehose tự chuyển JSON sang Parquet
    → giảm dung lượng 70–90%
    → Athena truy vấn nhanh hơn nhiều
        ↓
    Cấu hình một lần, không cần viết mã

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAge của Data Streams | tăng = xử lý không kịp, có thể MẤT DỮ LIỆU | | WriteProvisionedThroughputExceeded | producer bị throttle | | DeliveryToS3.Success của Firehose | giao thành công |

IteratorAge là metric quan trọng nhất:

IteratorAge vượt thời gian giữ dữ liệu
    → MẤT DỮ LIỆU VĨNH VIỄN
    → và không có lỗi nào báo

Ba lựa chọn cho tầng phân tích: | Lựa chọn | Đặc điểm | |---|---| | Managed Service for Apache Flink | SQL hoặc Java, cửa sổ thời gian ← câu này | | Lambda | logic đơn giản, không có cửa sổ dựng sẵn | | KCL trên EC2/ECS | kiểm soát nhiều nhất |

Ba lưu ý cho hệ thống gợi ý sản phẩm: | Lưu ý | Chi tiết | |---|---| | Kết quả phân tích nên vào kho đọc nhanh | DynamoDB hoặc ElastiCache | | Cân nhắc Amazon Personalize | dịch vụ gợi ý được quản lý | | Lưu dữ liệu thô vào S3 để huấn luyện lại | |

Amazon Personalize đáng biết:

Personalize:
    → nhận luồng sự kiện tương tác thời gian thực
    → tự huấn luyện mô hình gợi ý
    → không cần chuyên gia học máy
        ↓
    Có thể thay thế phần logic gợi ý tự viết

Và một lời khuyên: hãy đặt alarm cho IteratorAge ngay khi triển khai. Với thương mại điện tử có đỉnh tải bất ngờ, xử lý tụt lại phía sau là chuyện sẽ xảy ra — và nếu độ trễ vượt thời gian giữ dữ liệu, bạn mất vĩnh viễn dữ liệu hành vi người dùng mà không có bất kỳ thông báo lỗi nào.

Đáp án

B và E.

• E — Dùng AWS Direct Connect làm kết nối CHÍNH
• B — Dùng AWS Site-to-Site VPN làm kết nối DỰ PHÒNG

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi yêu cầu chỉ ra một vai trò: | Yêu cầu | Kết nối | |---|---| | Kết nối RIÊNG, chuyên dụng | Direct Connect làm chính | | Khi hỏng thì chấp nhận đi Internet có mã hoá | VPN làm dự phòng |

Vì sao Direct Connect làm chính:

"dedicated PRIVATE connection"
    ↓
    Direct Connect:
    ✓ đường truyền vật lý riêng, không qua Internet
    ✓ băng thông ổn định và cam kết
    ✓ độ trễ thấp và nhất quán

Và vì sao VPN làm dự phòng:

"in case of FAILURES, willing to use the PUBLIC INTERNET
 for an ENCRYPTED connection"
    ↓
    Site-to-Site VPN:
    ✓ chạy qua Internet công cộng
    ✓ mã hoá IPsec
    ✓ dựng được trong vài phút, chi phí thấp

Và BGP tự chuyển đổi giữa hai đường:

Cả DX và VPN cùng quảng bá route qua BGP
    → DX có AS path ngắn hơn hoặc local preference cao hơn
    → lưu lượng đi qua DX
        ↓
    DX hỏng → BGP tự rút route
    → lưu lượng chuyển sang VPN trong vài chục giây

Cấu hình để DX được ưu tiên:

Trên router tại chỗ:
    → quảng bá cùng dải qua cả hai
    → đặt local-preference cao hơn cho DX
        hoặc thêm AS path prepend cho VPN

Và AWS ưu tiên theo thứ tự:

① Route cụ thể hơn (prefix dài hơn) thắng
② Direct Connect ưu tiên hơn VPN (với cùng prefix)
③ AS path ngắn hơn thắng

Điểm thứ hai nghĩa là AWS TỰ ĐỘNG ưu tiên DX — không cần cấu hình gì thêm.

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

• **A. Dùng VPN làm kết nối CHÍNH — đây là phương án gần nhất vì VPN thực sự là một kết nối hợp lệ, nhưng nó đảo ngược vai trò: đề nêu rõ muốn "dedicated private connection" làm chính, và chỉ chấp nhận Internet khi có sự cố.
• **C. Dùng Direct Connect làm dự phòng — cùng lỗi đảo ngược, và còn lãng phí: DX đắt hơn nhiều, để nó nhàn rỗi làm dự phòng là không hợp lý về chi phí.
• **D. Dùng Egress-only internet gateway làm dự phòng — sai loại dịch vụ: egress-only IGW cho lưu lượng IPv6 đi ra Internet từ VPC, nó không phải cơ chế kết nối tới trung tâm dữ liệu.

Ghi nhớ

Direct Connect và Site-to-Site VPN — bảng phải thuộc: | | Direct Connect | Site-to-Site VPN | |---|---|---| | Đường truyền | riêng, chuyên dụng | Internet công cộng | | Băng thông | 50 Mbps – 100 Gbps | ~1,25 Gbps mỗi tunnel | | Độ trễ | thấp và ỔN ĐỊNH | biến động | | Mã hoá | KHÔNG mặc định | IPsec dựng sẵn | | Thời gian triển khai | vài tuần tới vài tháng | vài phút | | Chi phí | cao | thấp |

Dòng "mã hoá" đáng chú ý:

Direct Connect KHÔNG mã hoá mặc định
    → là đường riêng nhưng không mã hoá
        ↓
    Muốn mã hoá:
        → MACsec (ở tầng vật lý, cho kết nối chuyên dụng)
        → hoặc chạy VPN CHỒNG LÊN Direct Connect

Ba mẫu kết nối lai — bảng cần thuộc: | Mẫu | Đặc điểm | |---|---| | DX chính + VPN dự phòng | cân bằng chi phí và độ tin cậy ← câu này | | Hai DX ở hai vị trí | độ tin cậy cao nhất, đắt nhất | | VPN chính (không có DX) | rẻ nhất, băng thông và độ trễ biến động |

Ba mức dư thừa của Direct Connect: | Mức | Cấu hình | |---|---| | Phát triển và thử nghiệm | một kết nối | | Sản xuất | hai kết nối ở HAI vị trí DX khác nhau | | Tối đa | hai kết nối + VPN dự phòng |

AWS chỉ cam kết SLA khi có cấu hình dư thừa:

Một kết nối:      không có SLA về sẵn sàng
Hai kết nối, hai vị trí: SLA 99,99%

Ba loại virtual interface của Direct Connect: | Loại | Nối tới | |---|---| | Private VIF | VPC (qua VGW hoặc DX gateway) | | Transit VIF | Transit Gateway — nhiều VPC | | Public VIF | endpoint công khai của AWS |

Ba cách nối VPN tới AWS: | Cách | Đặc điểm | |---|---| | VPN tới virtual private gateway | một VPC | | VPN tới Transit Gateway | nhiều VPC, hỗ trợ ECMP | | Client VPN | người dùng cá nhân |

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

Ba lưu ý khi cấu hình dự phòng: | Lưu ý | Chi tiết | |---|---| | Cấu hình CẢ HAI đường hầm của mỗi VPN | chỉ một là mất dư thừa | | Dùng BGP, không dùng static route | BGP tự chuyển đổi | | Kiểm chứng bằng cách ngắt DX thật | diễn tập |

Dòng cuối rất quan trọng:

Cấu hình dự phòng chưa thử là cấu hình chưa có
    → phải ngắt DX trong cửa sổ bảo trì
    → xác nhận lưu lượng chuyển sang VPN
    → đo thời gian chuyển đổi

Ba cách điều chỉnh ưu tiên định tuyến: | Cách | Chi tiết | |---|---| | AWS tự ưu tiên DX hơn VPN | với cùng prefix | | AS path prepend trên VPN | làm VPN kém hấp dẫn hơn | | Local preference trên router tại chỗ | cho chiều đi ra |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ConnectionState của DX | up hay down | | TunnelState của VPN | 0 = down, 1 = up | | ConnectionBpsEgress/Ingress | băng thông đang dùng |

Và alarm nên đặt cho từng đường hầm:

Đặt alarm khi BẤT KỲ đường nào down
    → không chỉ khi cả hai down
        ↓
    Chạy một đường nghĩa là đã mất dư thừa

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | DX port | theo băng thông và vị trí | | DX data transfer out | rẻ hơn Internet đáng kể | | VPN connection | ~0,05 USD/giờ (~36 USD/tháng) |

Phí truyền dữ liệu ra qua DX rẻ hơn nhiều so với qua Internet — với khối lượng lớn, đó là khoản bù cho phí port.

Ba lưu ý về Accelerated Site-to-Site VPN: | Đặc điểm | Chi tiết | |---|---| | Dùng Global Accelerator | vào mạng AWS ở điểm biên gần nhất | | Độ trễ và jitter ổn định hơn | | | Cần Transit Gateway | không dùng với VGW |

Và một lời khuyên: hãy diễn tập chuyển đổi ít nhất mỗi quý bằng cách tạm ngắt Direct Connect trong cửa sổ bảo trì. Cấu hình BGP dự phòng thường có sai sót nhỏ — thiếu một route, sai local preference — và những thứ đó chỉ lộ ra khi thử thật, chứ không phải khi đọc lại cấu hình.

Đáp án

B và E.

• B — Dùng Amazon EKS với AWS Fargate
• E — Dùng Amazon ECS với AWS Fargate

Vì sao đúng

Đề hỏi dịch vụ điều phối container không máy chủ, và AWS có đúng hai lựa chọn: | Dịch vụ | Đặc điểm | |---|---| | ECS với Fargate | điều phối container riêng của AWS, không máy chủ | | EKS với Fargate | Kubernetes chuẩn, không máy chủ |

Và điểm chung là Fargate:

AWS Fargate:
    ✓ KHÔNG có EC2 instance nào để cấp phát
    ✓ không vá lỗi hệ điều hành
    ✓ mỗi task hoặc pod có vCPU và bộ nhớ riêng
    ✓ tự co giãn
        ↓
    Đó chính là "serverless orchestration"

ECS với Fargate:

aws ecs create-cluster --cluster-name cum-api   --capacity-providers FARGATE FARGATE_SPOT

aws ecs create-service --cluster cum-api --service-name dich-vu-api   --task-definition api:1 --desired-count 3   --launch-type FARGATE   --network-configuration 'awsvpcConfiguration={subnets=[subnet-a,subnet-b],
                            securityGroups=[sg-api],assignPublicIp=DISABLED}'

EKS với Fargate:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: cum-api
  region: ap-northeast-1
fargateProfiles:
  - name: mac-dinh
    selectors:
      - namespace: ung-dung

Và chọn giữa hai cái phụ thuộc vào hệ sinh thái: | Chọn | Khi nào | |---|---| | ECS | đơn giản hơn, riêng của AWS, control plane MIỄN PHÍ | | EKS | Kubernetes chuẩn, hệ sinh thái rộng, di động giữa các đám mây |

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

• **C. Dùng ECS với Amazon EC2 để điều phối container không máy chủ — đây là phương án gần nhất và ECS là dịch vụ điều phối đúng, nhưng EC2 launch type KHÔNG phải serverless: bạn phải quản lý instance, AMI, vá lỗi hệ điều hành và cluster auto scaling.
• **A. Dùng Amazon SageMaker — sai loại dịch vụ: SageMaker là nền tảng học máy (huấn luyện, triển khai mô hình), không phải dịch vụ điều phối container đa dụng.
• **D. Dùng Amazon EMR — cũng sai: EMR là nền tảng xử lý dữ liệu lớn (Spark, Hadoop, Hive), không phải dịch vụ điều phối container.

Ghi nhớ

Ba dịch vụ container của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Amazon ECS | điều phối container, riêng của AWS | | Amazon EKS | Kubernetes được quản lý | | AWS Fargate | NĂNG LỰC TÍNH TOÁN không máy chủ cho ECS và EKS | | Amazon ECR | kho lưu trữ container image |

Điểm quan trọng: Fargate KHÔNG phải dịch vụ điều phối.

Fargate là LAUNCH TYPE (chế độ tính toán)
    → dùng CÙNG với ECS hoặc EKS
        ↓
    "ECS với Fargate" và "EKS với Fargate" là hai lựa chọn serverless

ECS và EKS — bảng phân biệt: | | Amazon ECS | Amazon EKS | |---|---|---| | Độ phức tạp | thấp hơn | Kubernetes chuẩn | | Chi phí control plane | MIỄN PHÍ | ~73 USD/tháng mỗi cụm | | Hệ sinh thái | AWS | Kubernetes rất rộng | | Di động sang đám mây khác | ❌ | ✅ | | Phù hợp | mới lên đám mây, muốn đơn giản | đã dùng Kubernetes |

Ba chế độ tính toán của ECS: | Chế độ | Bạn quản lý | |---|---| | Fargate | KHÔNG có máy nào | | EC2 launch type | instance, AMI, vá lỗi, cluster autoscaling | | ECS Anywhere | máy chủ của bạn |

Ba chế độ tính toán của EKS: | Chế độ | Bạn quản lý | |---|---| | Fargate | KHÔNG có node nào | | Managed node group | AWS quản lý vòng đời EC2, bạn vẫn thấy máy | | Self-managed node | mọi thứ | | EKS Auto Mode | AWS quản lý toàn bộ tính toán |

Ba hạn chế của Fargate cần biết: | Hạn chế | Chi tiết | |---|---| | Không mount hostPath hay instance store | chỉ EFS | | Không dùng được GPU | | | EKS trên Fargate: không hỗ trợ DaemonSet | công cụ giám sát phải là sidecar | | Tài nguyên tối đa | 16 vCPU, 120 GB |

Ba lợi ích của Fargate: | Lợi ích | Chi tiết | |---|---| | Không quản lý máy chủ | không vá lỗi, không cấp phát | | Cách ly ở mức task | mỗi task có kernel riêng | | Trả tiền theo tài nguyên task dùng | không trả cho phần thừa của instance |

Điểm cách ly đáng chú ý với công ty làm dịch vụ cho nhiều khách hàng:

Fargate:
    → mỗi task chạy trong môi trường cách ly riêng
    → không chia sẻ kernel với task khác
        ↓
    An toàn hơn cho môi trường nhiều khách hàng

Ba cấu hình quan trọng của Fargate task: | Cấu hình | Chi tiết | |---|---| | CPU và bộ nhớ theo tổ hợp cho phép | 1 vCPU → 2–8 GB, 2 vCPU → 4–16 GB... | | networkMode: awsvpc | bắt buộc, mỗi task có ENI riêng | | Task role và execution role | quyền cho ứng dụng và cho việc kéo image |

Hai loại role dễ nhầm: | Role | Việc | |---|---| | Execution role | ECS dùng để KÉO IMAGE và ghi log | | Task role | ứng dụng dùng để gọi API của AWS |

Ba lưu ý về mạng cho Fargate: | Lưu ý | Chi tiết | |---|---| | Cần đường ra để kéo image từ ECR | NAT Gateway hoặc VPC endpoint | | VPC endpoint cần: ecr.api, ecr.dkr, logs, và gateway S3 | | | Mỗi task có ENI riêng | tính vào hạn mức ENI của subnet |

Ba cách tối ưu chi phí: | Cách | Tiết kiệm | |---|---| | Fargate Spot | giảm tới 70% cho tải chịu gián đoạn | | Compute Savings Plans | áp cho Fargate, giảm tới 50% | | Đặt CPU và bộ nhớ vừa đủ | không cấp thừa |

Cấu hình trộn Fargate và Fargate Spot:

{"capacityProviderStrategy": [
   {"capacityProvider": "FARGATE", "base": 2, "weight": 1},
   {"capacityProvider": "FARGATE_SPOT", "weight": 4}]}

Ba lưu ý về co giãn: | Lưu ý | Chi tiết | |---|---| | ECS Service Auto Scaling | co giãn số task | | EKS: HPA cho pod | Fargate lo phần node | | Không cần Cluster Autoscaler với Fargate | ← lợi ích lớn |

Ba lựa chọn khác cho container không máy chủ: | Lựa chọn | Đặc điểm | |---|---| | AWS App Runner | đơn giản nhất, từ mã nguồn hoặc image tới URL | | Lambda với container image | dưới 15 phút, theo sự kiện | | ECS/EKS với Fargate | ← câu này, linh hoạt nhất |

App Runner đáng cân nhắc cho API đơn giản:

App Runner:
    ✓ nối repo git hoặc ECR
    ✓ tự build, triển khai, co giãn
    ✓ có HTTPS và tên miền tuỳ chỉnh sẵn
        ↓
    Ít công hơn cả ECS Fargate cho ứng dụng web đơn giản

Và một lời khuyên khi tư vấn cho khách hàng: hãy hỏi họ đã có kinh nghiệm Kubernetes chưa. Nếu chưa, ECS với Fargate cho họ chạy được nhanh hơn nhiều và không mất phí control plane; nếu đã có, EKS giữ nguyên công cụ và quy trình mà đội ngũ đang quen — và đó thường là yếu tố quyết định hơn mọi so sánh kỹ thuật.

Đáp án

B — Tạo AWS Transit Gateway với định tuyến ECMP (equal cost multipath) và thêm nhiều đường hầm VPN.

Vì sao đúng

Đề nêu vấn đề rõ: thông lượng VPN không đủ, và ECMP là cơ chế duy nhất nhân được thông lượng.

Một VPN connection = 2 đường hầm IPsec
    → mỗi đường hầm tối đa ~1,25 Gbps
    → và LƯU LƯỢNG CHỈ ĐI QUA MỘT đường hầm tại một thời điểm
        ↓
    Trần thực tế: ~1,25 Gbps

ECMP thay đổi điều đó:

Transit Gateway với ECMP:
    → nhiều VPN connection cùng quảng bá cùng dải
    → lưu lượng CHIA ĐỀU qua tất cả đường hầm
        ↓
    4 VPN connection × 1,25 Gbps = ~5 Gbps
    → thông lượng nhân lên theo số kết nối

Bật ECMP:

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

# Tạo nhiều VPN connection tới cùng Transit Gateway
for i in 1 2 3 4; do
  aws ec2 create-vpn-connection --type ipsec.1     --transit-gateway-id tgw-0abc --customer-gateway-id cgw-$i     --options '{"StaticRoutesOnly":false}'
done

Ba điều kiện để ECMP hoạt động: | Điều kiện | Chi tiết | |---|---| | PHẢI dùng Transit Gateway | virtual private gateway KHÔNG hỗ trợ ECMP | | PHẢI dùng BGP (định tuyến động) | static route không ECMP được | | Các đường phải quảng bá CÙNG prefix với cùng chi phí | |

Điều kiện đầu tiên là lý do phương án C sai — VGW không có ECMP.

Và phía tại chỗ cũng cần hỗ trợ:

Router tại chỗ phải:
    → thiết lập nhiều phiên BGP
    → bật ECMP để chia tải chiều đi ra
        ↓
    Nếu không, chỉ chiều vào AWS được chia tải

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

• **C. Tạo virtual private gateway với ECMP và nhiều kênh — đây là phương án gần nhất và nêu đúng khái niệm ECMP, nhưng nó sai thành phần: virtual private gateway KHÔNG hỗ trợ ECMP. Chỉ Transit Gateway mới có.
• **A. Dùng Global Accelerator cho VPN để tăng thông lượng — hiểu sai chức năng: Accelerated Site-to-Site VPN thực sự tồn tại và dùng mạng Global Accelerator, nhưng nó cải thiện độ trễ và độ ổn định, không nhân được thông lượng vượt trần của đường hầm.
• **D. Dùng Transfer Acceleration cho VPN — không phải tính năng có thật: S3 Transfer Acceleration chỉ áp cho việc tải lên S3, không liên quan tới VPN.

Ghi nhớ

Giới hạn thông lượng của Site-to-Site VPN — con số phải nhớ:

Mỗi đường hầm IPsec: ~1,25 Gbps
Mỗi VPN connection:  2 đường hầm (nhưng chỉ 1 active tại một thời điểm)
        ↓
    Trần của một VPN connection: ~1,25 Gbps

Ba cách tăng thông lượng VPN: | Cách | Chi tiết | |---|---| | ECMP với Transit Gateway | nhân thông lượng theo số kết nối ← câu này | | Accelerated VPN | ổn định hơn, không nhân thông lượng | | Chuyển sang Direct Connect | băng thông cao nhất |

VGW và Transit Gateway — bảng phân biệt: | | Virtual Private Gateway | Transit Gateway | |---|---|---| | Số VPC | MỘT | nhiều (tới 5.000) | | ECMP cho VPN | ❌ KHÔNG | ✅ CÓ | | Định tuyến bắc cầu | ❌ | ✅ | | Chi phí | miễn phí (chỉ trả VPN) | theo attachment |

Đây là bảng quyết định cho câu hỏi này.

Ba đặc điểm của ECMP: | Đặc điểm | Chi tiết | |---|---| | Chia tải theo LUỒNG (flow), không theo gói | một kết nối TCP vẫn đi qua một đường | | Cần BGP | static route không dùng được | | Cần các đường có chi phí BẰNG NHAU | AS path và metric giống nhau |

Dòng đầu là điểm quan trọng:

ECMP chia theo 5-tuple (IP nguồn, cổng nguồn, IP đích, cổng đích, giao thức)
    → một luồng TCP duy nhất KHÔNG vượt được 1,25 Gbps
        ↓
    ECMP tăng thông lượng TỔNG, không tăng thông lượng của MỘT kết nối

Điều này có ý nghĩa thực tế:

Nhiều người dùng, nhiều kết nối → ECMP rất hiệu quả
Một lần chuyển tệp lớn duy nhất → ECMP KHÔNG giúp gì

Ba lưu ý về Site-to-Site VPN: | Lưu ý | Chi tiết | |---|---| | Mỗi VPN connection có 2 đường hầm | cấu hình CẢ HAI để có dư thừa | | Dùng BGP thay static route | tự chuyển đổi | | Bật DPD (Dead Peer Detection) | phát hiện đứt nhanh |

Direct Connect và VPN — bảng so sánh: | | VPN | Direct Connect | |---|---|---| | Băng thông | ~1,25 Gbps mỗi tunnel | 50 Mbps – 100 Gbps | | Độ trễ | biến động | ổn định | | Thời gian triển khai | vài phút | vài tuần tới vài tháng | | Chi phí | thấp | cao | | Mã hoá | IPsec dựng sẵn | không mặc định |

Với nhu cầu thông lượng cao lâu dài, Direct Connect là giải pháp căn bản — ECMP là cách nhanh để giải quyết trước mắt.

Ba lựa chọn khi cần thông lượng lớn: | Lựa chọn | Băng thông | |---|---| | ECMP với 4 VPN connection | ~5 Gbps | | Direct Connect 10 Gbps | 10 Gbps ổn định | | DX + VPN dự phòng | tốt nhất |

Ba lưu ý về Accelerated VPN: | Đặc điểm | Chi tiết | |---|---| | Dùng mạng Global Accelerator | vào mạng AWS ở điểm biên gần nhất | | Cải thiện độ trễ và jitter | không tăng thông lượng tối đa | | Cần Transit Gateway | không dùng với VGW |

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

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TunnelState | 0 = down, 1 = up — đặt alarm cho TỪNG tunnel | | TunnelDataIn/Out | lưu lượng qua mỗi tunnel — xác nhận ECMP chia đều | | Số phiên BGP đang hoạt động | |

Metric thứ hai là cách kiểm chứng ECMP hoạt động:

Nếu chỉ một tunnel có lưu lượng
    → ECMP chưa hoạt động
    → kiểm tra BGP và cấu hình phía tại chỗ

Ba lưu ý về cấu hình phía tại chỗ: | Lưu ý | Chi tiết | |---|---| | Router phải hỗ trợ nhiều phiên BGP | | | Bật ECMP trên router | cho chiều đi ra | | Quảng bá cùng prefix qua mọi đường | với metric bằng nhau |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Mỗi VPN connection | ~0,05 USD/giờ (~36 USD/tháng) | | TGW attachment cho VPN | ~0,05 USD/giờ | | Truyền dữ liệu ra | theo giá thông thường |

4 VPN connection + TGW: khoảng 300 USD/tháng — vẫn rẻ hơn nhiều so với Direct Connect.

Và một lời khuyên: hãy kiểm chứng lưu lượng chia đều qua các tunnel bằng metric TunnelDataIn sau khi bật ECMP. Rất thường gặp trường hợp cấu hình phía AWS đúng nhưng router tại chỗ chưa bật ECMP — và khi đó chiều vào AWS được chia tải còn chiều ra vẫn dồn vào một đường, giải quyết được một nửa vấn đề.