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

Tìm thấy 2194 câu.

Câu 1051 Chọn nhiều đáp án AWS Networking & Content Delivery

A travel agency operates a web service in an AWS Region. The service is accessed by customers via a REST API on Amazon API Gateway. The agency uses Amazon Route 53 for DNS and wants to provide individual and secure URLs for each travel agent using the service.

Which combination of steps will meet these requirements with the LEAST operational complexity? (Select THREE.)

  1. A

    Establish separate API endpoints in API Gateway for each travel agent.
  2. B

    Request a wildcard certificate that corresponds to the custom domain name in AWS Certificate Manager (ACM), within a different Region.
  3. C

    Establish a custom domain name in API Gateway for the REST API. Import the corresponding certificate from AWS Certificate Manager (ACM).
  4. D

    Request a wildcard certificate that matches the custom domain name in AWS Certificate Manager (ACM) in the same Region.
  5. E

    Create separate hosted zones in Route 53 for each travel agent as needed. Set up zone records that point to the API Gateway endpoint.
  6. F

    Register the desired domain with a domain registrar. Set up a wildcard custom domain in a Route 53 hosted zone and create a record in the zone that points to the API Gateway endpoint.
Xem giải thích

Đáp án

C, D và F.

  • C — Tạo custom domain name trong API Gateway cho REST API, import chứng chỉ từ ACM
  • D — Yêu cầu wildcard certificate khớp custom domain trong ACM CÙNG VÙNG
  • F — Đăng ký tên miền, tạo wildcard custom domain trong Route 53 hosted zone và bản ghi trỏ tới API Gateway

Vì sao đúng

Đề nêu ba yêu cầu, và ba bước này là quy trình chuẩn: | Yêu cầu | Bước | |---|---| | URL riêng cho mỗi đại lý | F: wildcard DNS *.dai-ly.vidu.com | | URL phải AN TOÀN (HTTPS) | D: wildcard certificate trong ACM | | CÔNG SỨC ÍT NHẤT | C: một custom domain thay vì nhiều API |

⚠ Wildcard là chìa khoá cho "least operational complexity":

Không dùng wildcard:
    → mỗi đại lý một chứng chỉ, một bản ghi DNS, một cấu hình
    → thêm đại lý là thêm ba thao tác
        ↓
Dùng wildcard:
    → MỘT chứng chỉ *.dai-ly.vidu.com
    → MỘT bản ghi DNS *.dai-ly.vidu.com
    → thêm đại lý: KHÔNG cần làm gì

Bước 1 — xin wildcard certificate:

aws acm request-certificate \
  --domain-name "*.dai-ly.vidu.com" \
  --validation-method DNS \
  --region ap-southeast-1

⚠ Vùng của chứng chỉ phụ thuộc loại endpoint API Gateway: | Loại endpoint | Chứng chỉ ở vùng | |---|---| | Regional | CÙNG vùng với API | | Edge-optimized | us-east-1 |

Đề nói "in the same Region" (phương án D)
    → tức là dùng REGIONAL endpoint
        ↓
    Phương án B nói "different Region" → sai

Bước 2 — tạo custom domain trong API Gateway:

aws apigateway create-domain-name \
  --domain-name "*.dai-ly.vidu.com" \
  --regional-certificate-arn <arn-chung-chi> \
  --endpoint-configuration types=REGIONAL

aws apigateway create-base-path-mapping \
  --domain-name "*.dai-ly.vidu.com" \
  --rest-api-id abc123 --stage prod

Bước 3 — bản ghi DNS wildcard:

aws route53 change-resource-record-sets --hosted-zone-id Z123 \
  --change-batch '{"Changes":[{"Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"*.dai-ly.vidu.com","Type":"A",
      "AliasTarget":{"HostedZoneId":"<zone-id-cua-api-gateway>",
        "DNSName":"<regional-domain-name>",
        "EvaluateTargetHealth":false}}}]}'

Kết quả:

dai-ly-a.dai-ly.vidu.com → cùng một API Gateway
dai-ly-b.dai-ly.vidu.com → cùng một API Gateway
        ↓
    API đọc header Host để biết đại lý nào
    → và áp dụng phân quyền tương ứng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thêm đại lý không cần thao tác nào | | | Một chứng chỉ, một bản ghi DNS | | | Một API để bảo trì | |

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

  • **A. Tạo endpoint API Gateway RIÊNG cho mỗi đại lý — đây là phương án gần nhất về mặt "cho mỗi đại lý một thứ riêng", nhưng nó nhân bản công việc: mỗi API là một tài nguyên phải triển khai, theo dõi và cập nhật riêng.
  • **E. Tạo hosted zone RIÊNG trong Route 53 cho mỗi đại lý — mỗi hosted zone tính phí riêng và phải cấu hình riêng. Một wildcard record trong một hosted zone làm được việc tương đương.
  • **B. Xin wildcard certificate ở VÙNG KHÁC — với regional endpoint, chứng chỉ phải ở cùng vùng với API. Chỉ edge-optimized mới cần chứng chỉ ở us-east-1.

Ghi nhớ

⚠ Ba loại endpoint của API Gateway — bảng phải thuộc: | Loại | Chứng chỉ ACM ở | Truy cập từ | |---|---|---| | Edge-optimized | us-east-1 | Internet, qua edge CloudFront | | Regional | CÙNG vùng với API | Internet, thẳng tới vùng | | Private | cùng vùng | chỉ trong VPC |

⚠ Quy tắc vùng của chứng chỉ ACM — dễ nhầm nhất: | Dịch vụ | Chứng chỉ ở vùng | |---|---| | CloudFront | LUÔN us-east-1 | | API Gateway edge-optimized | us-east-1 | | API Gateway regional | cùng vùng | | ALB / NLB | cùng vùng |

Từ khoá nhận diện:

"individual URL per customer" + "least complexity" → wildcard domain + wildcard cert "custom domain for API" → API Gateway custom domain name "one certificate for many subdomains" → wildcard certificate

⚠ Ba lưu ý về wildcard certificate: | Lưu ý | Chi tiết | |---|---| | *.vidu.com KHÔNG khớp vidu.com | phải thêm domain gốc | | KHÔNG khớp nhiều cấp | *.vidu.com không khớp a.b.vidu.com | | Xác thực DNS tự động gia hạn | |

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

⚠ Xác thực DNS hơn xác thực email: | | DNS validation | Email validation | |---|---|---| | Tự động gia hạn | ✅ | ❌ phải xác nhận lại | | Cần quyền DNS | ✅ | ❌ | | Khuyến nghị | ✅ | |

Ba khái niệm của API Gateway custom domain: | Khái niệm | Việc | |---|---| | Domain name | tên miền tuỳ chỉnh | | Base path mapping | ánh xạ đường dẫn tới API và stage | | Regional domain name | tên để trỏ DNS tới |

Base path mapping cho nhiều API:

aws apigateway create-base-path-mapping \
  --domain-name api.vidu.com --base-path "dat-cho" \
  --rest-api-id abc123 --stage prod

aws apigateway create-base-path-mapping \
  --domain-name api.vidu.com --base-path "thanh-toan" \
  --rest-api-id def456 --stage prod

⚠ Ba cách phân biệt đại lý trong API: | Cách | Chi tiết | |---|---| | Header Host | API đọc tên miền con | | API key + usage plan | giới hạn tần suất riêng | | Lambda authorizer | logic phân quyền tuỳ chỉnh |

Đọc Host trong Lambda:

def handler(event, context):
    ten_mien = event['headers'].get('Host', '')
    ma_dai_ly = ten_mien.split('.')[0]
    # áp dụng phân quyền theo ma_dai_ly

Ba lưu ý về usage plan: | Lưu ý | Chi tiết | |---|---| | Mỗi đại lý một API key | | | Đặt throttle và quota riêng | | | API key KHÔNG phải cơ chế bảo mật | |

⚠ API key chỉ để đo lường và giới hạn:

AWS nói rõ: API key dùng để ĐO LƯỜNG và GIỚI HẠN TẦN SUẤT
    → không dùng làm cơ chế xác thực duy nhất
        ↓
    Luôn kết hợp với authorizer

Ba lưu ý về ALIAS record: | Lưu ý | Chi tiết | |---|---| | Dùng ALIAS, không dùng CNAME | miễn phí, dùng được ở apex | | Zone ID lấy từ regional-hosted-zone-id | | | Wildcard record hoạt động như bản ghi thường | |

aws apigateway get-domain-name --domain-name "*.dai-ly.vidu.com" \
  --query "[regionalDomainName,regionalHostedZoneId]"

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Đặt securityPolicy là TLS_1_2 | | | Gắn WAF vào API Gateway | | | Resource policy giới hạn IP nếu cần | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Chứng chỉ ACM MIỄN PHÍ | | | Hosted zone tính phí theo tháng | dùng chung một zone | | HTTP API rẻ hơn REST API ~70% | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl https://dai-ly-a.dai-ly.vidu.com/ | | | Kiểm tra chứng chỉ hợp lệ | | | Thử một tên miền con chưa từng dùng | wildcard phải khớp |

Và một lời khuyên: hãy nhớ rằng *.vidu.com không khớp chính vidu.com. Đây là chi tiết khiến rất nhiều cấu hình wildcard trông đúng nhưng tên miền gốc lại báo lỗi chứng chỉ — thêm nó vào subject-alternative-names ngay từ khi xin chứng chỉ.

Câu 1052 AWS Cloud Architecture & Design

An organization is planning their disaster recovery solution. They plan to run a scaled down version of a fully functional environment. In a DR situation the recovery time must be minimized.

Which DR strategy should a Solutions Architect recommend?

  1. A

    Backup and restore
  2. B

    Multi-site
  3. C

    Pilot light
  4. D

    Warm standby
Xem giải thích

Đáp án

D — Warm standby.

Vì sao đúng

Đề mô tả chính xác định nghĩa của Warm Standby: | Dữ kiện | Khớp với | |---|---| | Chạy một bản THU NHỎ của môi trường ĐẦY ĐỦ CHỨC NĂNG | "scaled down but fully functional" | | Thời gian phục hồi phải TỐI THIỂU | RTO tính bằng phút |

⚠ "Fully functional" là từ khoá phân biệt với Pilot Light:

Warm Standby: MỌI tầng đều CHẠY, chỉ ở quy mô nhỏ
    → có thể phục vụ lưu lượng ngay (dù ít)
        ↓
Pilot Light:  chỉ tầng dữ liệu chạy
    → tầng ứng dụng TẮT hoàn toàn

Kiến trúc điển hình:

Vùng chính:  ASG 20 máy + Aurora primary
Vùng DR:     ASG 2 máy (ĐANG CHẠY) + Aurora secondary
        ↓
    Khi thảm hoạ:
    1. Tăng ASG từ 2 lên 20        (~5 phút)
    2. Promote Aurora secondary     (~1 phút)
    3. Route 53 chuyển traffic      (~1-2 phút)
        ↓
    RTO thường vài phút

Cấu hình ASG ở vùng DR:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name asg-dr --region us-west-2 \
  --launch-template LaunchTemplateName=mau-dr,Version='$Latest' \
  --min-size 2 --max-size 20 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-dr-a,subnet-dr-b" \
  --target-group-arns <arn-tg-dr> --health-check-type ELB

⚠ Vì sao RTO của Warm Standby thấp hơn Pilot Light:

Warm Standby: máy đã chạy, đã qua health check
    → chỉ cần TĂNG số lượng
        ↓
Pilot Light:  máy chưa chạy
    → phải khởi động từ 0
    → chờ boot, chờ ứng dụng sẵn sàng, chờ health check

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RTO tính bằng phút | | | Hạ tầng đã được kiểm chứng liên tục | máy đang chạy thật | | Có thể phục vụ một phần lưu lượng ngay | |

⚠ Vế thứ hai là ưu thế ít người nói tới:

Pilot Light: hạ tầng ứng dụng chưa bao giờ chạy
    → không biết nó có khởi động được không
        ↓
Warm Standby: máy đang chạy, đang qua health check
    → biết chắc nó hoạt động

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

  • **C. Pilot light — đây là phương án gần nhất và cũng có dữ liệu sao chép sẵn, nhưng tầng ứng dụng TẮT hoàn toàn. Đề nói rõ "fully functional", tức mọi tầng đang chạy.
  • **B. Multi-site (active-active) — cả hai site cùng phục vụ lưu lượng thật, không có site nào "chờ tiếp quản". RTO gần bằng 0 nhưng chi phí cao nhất và đề không mô tả như vậy.
  • **A. Backup and restore — chỉ có bản sao lưu, phải dựng lại toàn bộ hạ tầng. RTO tính bằng giờ tới ngày, ngược với "recovery time must be minimized".

Ghi nhớ

⚠ Bốn chiến lược DR — bảng phải thuộc: | Chiến lược | RTO | RPO | Chi phí | Tầng ứng dụng ở DR | |---|---|---|---|---| | Backup & Restore | giờ - ngày | giờ | thấp nhất | không có gì | | Pilot Light | chục phút | phút - giây | thấp | TẮT | | Warm Standby | phút | giây | trung bình | CHẠY quy mô nhỏ | | Multi-Site Active-Active | gần 0 | gần 0 | cao nhất | CHẠY đầy đủ, phục vụ thật |

⚠ Cách phân biệt nhanh nhất — nhìn vào tầng ứng dụng ở vùng DR:

Không có gì dựng sẵn        → Backup & Restore
Dữ liệu sao chép, app TẮT   → Pilot Light
App CHẠY nhỏ, chưa phục vụ  → Warm Standby
App CHẠY và ĐANG phục vụ    → Multi-Site

Hai định nghĩa phải thuộc: | Chỉ số | Nghĩa | |---|---| | RTO (Recovery Time Objective) | bao lâu để KHÔI PHỤC dịch vụ | | RPO (Recovery Point Objective) | được phép MẤT bao nhiêu dữ liệu |

Từ khoá nhận diện: | Cụm từ trong đề | Chiến lược | |---|---| | "scaled down but fully functional" | Warm Standby | | "core services replicated, others switched off" | Pilot Light | | "both Regions serve traffic" | Multi-Site | | "restore from backups when needed" | Backup & Restore |

⚠ Ba cơ chế sao chép dữ liệu cho DR: | Cơ chế | RPO | |---|---| | Aurora Global Database | ~1 giây | | DynamoDB Global Tables | dưới 1 giây, active-active | | S3 Cross-Region Replication | phút (RTC cam kết 15 phút) | | RDS cross-region read replica | giây - phút |

Ba cách kích hoạt chuyển đổi: | Cách | Chi tiết | |---|---| | Route 53 health check + failover record | tự động | | EventBridge + Lambda | logic tuỳ chỉnh | | Runbook thủ công | chậm nhất |

⚠ Route 53 TTL ảnh hưởng trực tiếp tới RTO:

Health check phát hiện trong 90 giây
    → TTL 300 giây → client vẫn dùng IP cũ thêm 5 phút
        ↓
    Đặt TTL 60 giây cho bản ghi failover

⚠ Ba thứ hay bị quên chuẩn bị ở vùng DR: | Thứ | Hậu quả nếu quên | |---|---| | AMI và launch template | ASG không khởi động nổi máy nào | | Chứng chỉ ACM | ACM theo vùng | | Hạn ngạch tài khoản | quota vùng chưa dùng thường rất thấp |

Tăng ASG từ 2 lên 20
    → chạm quota, chỉ khởi động được 8
        ↓
    RTO thực tế bị quyết định bởi tầng chậm nhất

Ba lưu ý về chi phí Warm Standby: | Khoản | Chi tiết | |---|---| | Máy nhỏ vẫn chạy 24/7 | | | CSDL vùng phụ tính phí instance | | | ALB tính phí kể cả ít lưu lượng | |

⚠ Cách giảm chi phí Warm Standby:

Dùng instance NHỎ ở vùng DR
    → tăng cỡ khi chuyển đổi (thay vì chỉ tăng số lượng)
        ↓
    Hoặc dùng Aurora Serverless v2 với min capacity thấp

Ba lưu ý về ứng dụng khi failover: | Lưu ý | Chi tiết | |---|---| | Endpoint CSDL thay đổi | dùng Route 53 CNAME hoặc Secrets Manager | | Kết nối đang mở bị ngắt | ứng dụng phải thử lại | | Session mất nếu lưu trong bộ nhớ | |

Ba việc phải làm định kỳ: | Việc | Tần suất | |---|---| | Diễn tập chuyển đổi thật | ít nhất 2 lần/năm | | Kiểm tra AMI vùng DR còn mới | mỗi lần phát hành | | Đo RTO thực tế | mỗi lần diễn tập |

⚠ Aurora cho phép diễn tập không mất dữ liệu:

aws rds failover-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --target-db-cluster-identifier <arn-cum-dr>

Ba lưu ý về tự động hoá: | Lưu ý | Chi tiết | |---|---| | Viết runbook thành Systems Manager Automation | | | Hoặc Step Functions | | | Mỗi bước thủ công là một chỗ để sai | |

Ba dịch vụ hỗ trợ DR: | Dịch vụ | Việc | |---|---| | AWS Elastic Disaster Recovery (DRS) | nhân bản liên tục máy chủ | | AWS Backup | sao lưu và copy xuyên vùng | | Route 53 Application Recovery Controller | kiểm soát chuyển đổi có chủ ý |

⚠ Route 53 ARC đáng biết cho DR nghiêm túc:

Readiness check: kiểm tra vùng DR có SẴN SÀNG không
    → hạn ngạch, năng lực, cấu hình
        ↓
Routing control: bật/tắt vùng bằng một công tắc
    → không phụ thuộc health check tự động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy diễn tập đầy đủ | | | Đo thời gian từng bước | | | Kiểm tra hạn ngạch vùng DR | |

Và một lời khuyên: hãy kiểm tra hạn ngạch EC2 ở vùng DR ít nhất mỗi quý. Warm Standby cho RTO tính bằng phút vì máy đã chạy sẵn — nhưng nếu quota chỉ đủ cho 8 máy trong khi bạn cần 20, thì con số RTO đẹp đẽ đó sẽ được thay bằng một cuộc gọi cho AWS Support giữa lúc sự cố.

Câu 1053 AWS Security, Identity, & Compliance

A software development company is creating a microservices-based application using Amazon Elastic Kubernetes Service (Amazon EKS). The company needs to ensure that sensitive configuration data like database credentials and API keys stored in Kubernetes ConfigMaps and Secrets are encrypted at rest.

Which solution will meet these requirements?

  1. A

    Create the Amazon EKS cluster with default options. Use the Amazon Elastic File System (Amazon EFS) Container Storage Interface (CSI) driver as an add-on.
  2. B

    Implement AWS Secrets Manager to manage, rotate, and store all sensitive data. Integrate it with the Amazon EKS cluster.
  3. C

    Create a new AWS Key Management Service (AWS KMS) key. Enable Amazon EKS KMS secrets encryption on the Amazon EKS cluster.
  4. D

    Use Amazon S3 to store all sensitive data. Enable server-side encryption with a new AWS Key Management Service (AWS KMS) key.
Xem giải thích

Đáp án

C — Tạo một khoá AWS KMS mới và bật EKS KMS secrets encryption trên cụm.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể, và đây là tính năng gốc của EKS: | Yêu cầu | Cách đáp ứng | |---|---| | Kubernetes Secrets và ConfigMap phải mã hoá AT REST | envelope encryption bằng KMS ở tầng etcd |

⚠ Vì sao cần bật thêm:

Mặc định, Kubernetes Secret chỉ được ENCODE base64
    → base64 KHÔNG phải mã hoá, ai đọc được cũng giải được
        ↓
    EKS lưu chúng trong etcd (đã mã hoá bằng khoá của AWS)
    → nhưng bạn không kiểm soát khoá đó
        ↓
    KMS secrets encryption thêm một lớp bằng KHOÁ CỦA BẠN

Bật khi tạo cụm:

aws kms create-key --description "Khoa ma hoa secret EKS"

aws eks create-cluster --name cum-ung-dung \
  --role-arn <arn-role> \
  --resources-vpc-config subnetIds=subnet-a,subnet-b \
  --encryption-config '[{"provider":{"keyArn":"<arn-khoa>"},
                         "resources":["secrets"]}]'

Hoặc bật cho cụm đã có:

aws eks associate-encryption-config --cluster-name cum-ung-dung \
  --encryption-config '[{"provider":{"keyArn":"<arn-khoa>"},
                         "resources":["secrets"]}]'

⚠ Bật rồi thì KHÔNG tắt được:

Sau khi bật KMS encryption cho cụm
    → không gỡ bỏ được
    → và không đổi sang khoá khác được
        ↓
    Xoá khoá KMS = mọi secret không giải mã được
    → cụm hỏng vĩnh viễn

Cách envelope encryption hoạt động:

Kubernetes tạo một data key
    → KMS mã hoá data key đó
    → data key thô dùng để mã hoá secret trong etcd
        ↓
    Đọc secret: gọi KMS giải mã data key, rồi giải mã secret

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bạn kiểm soát khoá qua key policy | | | Mọi lần dùng khoá ghi vào CloudTrail | | | Vô hiệu hoá khoá = khoá sạch dữ liệu | |

⚠ Vế thứ ba là con dao hai lưỡi:

aws kms disable-key --key-id <id>

Vô hiệu hoá khoá → không ai đọc được secret nữa
    → dùng khi nghi bị xâm nhập
        ↓
    Nhưng cũng làm cụm ngừng hoạt động ngay lập tức

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

  • **B. Dùng AWS Secrets Manager quản lý, xoay và lưu mọi dữ liệu nhạy cảm, tích hợp với EKS — đây là phương án gần nhất và là thực hành tốt trong thực tế, nhưng đề hỏi cụ thể về mã hoá Kubernetes Secrets và ConfigMap at rest. Secrets Manager lưu bí mật bên ngoài Kubernetes; nó không mã hoá các đối tượng đã nằm trong etcd.
  • **A. Tạo cụm với tuỳ chọn mặc định và dùng EFS CSI driver — EFS CSI driver để mount hệ thống tệp vào pod, hoàn toàn không liên quan tới mã hoá secret.
  • **D. Dùng S3 lưu dữ liệu nhạy cảm với SSE-KMS — chuyển bí mật ra S3 không phải cách Kubernetes hoạt động, và không mã hoá được ConfigMap trong etcd.

Ghi nhớ

⚠ Ba cách quản lý bí mật với EKS — bảng phải thuộc: | Cách | Việc | |---|---| | EKS KMS secrets encryption | mã hoá Secret/ConfigMap TRONG etcd | | AWS Secrets Manager + CSI driver | lưu bí mật NGOÀI Kubernetes, có xoay | | External Secrets Operator | đồng bộ từ Secrets Manager vào Secret |

⚠ Chúng bổ sung nhau, không thay thế:

KMS encryption: bảo vệ thứ ĐÃ nằm trong etcd
Secrets Manager: giữ bí mật ở ngoài, có xoay tự động
        ↓
    Thực hành tốt: dùng CẢ HAI

Secrets Manager CSI driver:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: bi-mat-csdl
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "prod/csdl/mat-khau"
        objectType: "secretsmanager"

Từ khoá nhận diện:

"encrypt Kubernetes Secrets at rest" → EKS KMS secrets encryption "rotate credentials automatically" → Secrets Manager "pod needs AWS permissions" → IRSA hoặc Pod Identity "encrypt EBS volumes of nodes" → KMS trên launch template

⚠ Ba lưu ý quan trọng về EKS KMS encryption: | Lưu ý | Chi tiết | |---|---| | Bật rồi KHÔNG tắt được | | | KHÔNG đổi khoá được | | | Xoá khoá = cụm hỏng vĩnh viễn | |

⚠ Ba biện pháp bảo vệ khoá: | Biện pháp | Chi tiết | |---|---| | Bật key rotation tự động | | | Đặt key policy chặt chẽ | | | Không cho phép kms:ScheduleKeyDeletion | |

{"Effect": "Deny", "Principal": "*",
 "Action": ["kms:ScheduleKeyDeletion", "kms:DisableKey"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/QuanTriKhoa"}}}

Ba lớp mã hoá cho EKS: | Lớp | Việc | |---|---| | Secrets encryption (KMS) | Secret và ConfigMap trong etcd | | EBS volume của node | mã hoá bằng KMS | | EFS / FSx nếu mount | mã hoá at rest |

⚠ Ba lưu ý về Kubernetes Secret: | Lưu ý | Chi tiết | |---|---| | Base64 KHÔNG phải mã hoá | | | Ai có quyền get secrets là đọc được | | | Dùng RBAC giới hạn quyền đọc secret | |

RBAC giới hạn:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: san-xuat
  name: doc-secret-han-che
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["bi-mat-ung-dung-a"]
    verbs: ["get"]

Ba lưu ý về logging: | Lưu ý | Chi tiết | |---|---| | Bật audit log của control plane | | | CloudTrail ghi lần dùng khoá KMS | | | Theo dõi kms:Decrypt bất thường | |

aws eks update-cluster-config --name cum-ung-dung \
  --logging '{"clusterLogging":[{"types":["audit","authenticator"],
    "enabled":true}]}'

Ba lưu ý về IRSA: | Lưu ý | Chi tiết | |---|---| | Cấp quyền AWS cho từng service account | | | Cần OIDC provider | | | Chặn pod truy cập IMDS của node | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Customer managed key ~1 USD/tháng | | | Phí theo số lần gọi KMS | | | Envelope encryption giảm số lần gọi | |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | KMS đáp ứng nhiều tiêu chuẩn | | | CloudHSM nếu cần FIPS 140-2 Level 3 | | | Ghi tài liệu ánh xạ khoá và dữ liệu | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra encryptionConfig của cụm | | | Xem CloudTrail ghi lần gọi KMS | | | Thử tạo secret và xác nhận mã hoá | |

aws eks describe-cluster --name cum-ung-dung \
  --query "cluster.encryptionConfig"

Và một lời khuyên: hãy bảo vệ khoá KMS của cụm bằng key policy chặn xoá và vô hiệu hoá. Bật secrets encryption là thao tác không thể hoàn tác, và xoá nhầm khoá đó nghĩa là mọi Secret trong cụm trở thành dữ liệu không đọc được — kể cả AWS Support cũng không khôi phục được.

Câu 1054 AWS Networking & Content Delivery

An online game platform company is launching a new game feature that involves a significant update to their existing API hosted on Amazon API Gateway. The company wants to minimize the impact on their existing users, and they need a deployment strategy that allows them to gradually roll out the changes while monitoring for any potential issues.

What should the company do to achieve this?

  1. A

    Use an API Gateway canary release deployment. Initially direct a small percentage of user traffic to the new API version. After API verification, promote the canary stage to the production stage.
  2. B

    Create a new version of the API and use Route 53 to gradually shift DNS queries from the existing API endpoint to the new API endpoint.
  3. C

    Create a completely new API for the new game feature and redirect half of the user traffic to the new API while maintaining the other half on the existing API.
  4. D

    Update the existing API directly in API Gateway with the new feature and immediately direct all traffic to the updated API.
Xem giải thích

Đáp án

A — Dùng API Gateway canary release deployment: ban đầu đưa một tỷ lệ nhỏ lưu lượng sang phiên bản API mới, sau khi kiểm chứng thì thăng canary stage lên production stage.

Vì sao đúng

Đề nêu ba yêu cầu, và canary release là tính năng sinh ra đúng cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Giảm thiểu ảnh hưởng tới người dùng hiện tại | chỉ một phần nhỏ lưu lượng chạm bản mới | | Triển khai DẦN DẦN | tăng tỷ lệ từng bước | | Theo dõi vấn đề trong quá trình | metric và log tách riêng cho canary |

⚠ Canary release của API Gateway hoạt động ở cấp STAGE:

Một stage có hai bản triển khai:
    → bản production (phần lớn lưu lượng)
    → bản canary (tỷ lệ nhỏ)
        ↓
    Cùng một URL, API Gateway tự chia lưu lượng
    → client không biết gì

Tạo canary:

aws apigateway create-deployment --rest-api-id abc123 \
  --stage-name prod --canary-settings \
    'percentTraffic=10.0,useStageCache=false'

Tăng dần tỷ lệ:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=replace,path=/canarySettings/percentTraffic,value=50

Thăng canary thành production:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=replace,path=/deploymentId,value=<id-canary>

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=remove,path=/canarySettings

⚠ Và quay lui chỉ là một lệnh:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=remove,path=/canarySettings

Gỡ canary settings
    → 100% lưu lượng quay về bản production cũ
        ↓
    Quay lui gần như tức thì

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cùng một URL — client không phải đổi gì | | | Metric và log tách riêng cho canary | | | Quay lui tức thì | |

⚠ Metric riêng cho canary là điểm quan trọng:

CloudWatch có dimension riêng cho canary
    → so sánh tỷ lệ lỗi và độ trễ giữa hai bản
        ↓
    Phát hiện vấn đề trước khi nó lan ra

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

  • **B. Tạo phiên bản API mới và dùng Route 53 chuyển dần DNS — đây là phương án gần nhất vì cũng chuyển lưu lượng dần, nhưng nó kém chính xác và chậm hơn: DNS phụ thuộc TTL và cache của client, nên tỷ lệ thực tế không khớp con số bạn đặt, và quay lui cũng chậm.
  • **C. Tạo một API hoàn toàn mới và chuyển một nửa lưu lượng sang — 50% ngay từ đầu là quá nhiều cho một bản cập nhật lớn, và duy trì hai API riêng là công vận hành gấp đôi.
  • **D. Cập nhật API trực tiếp và chuyển toàn bộ lưu lượng ngay — ngược hẳn yêu cầu "gradually roll out" và "minimize impact".

Ghi nhớ

⚠ Ba chiến lược triển khai — bảng phải thuộc: | Chiến lược | Cách hoạt động | |---|---| | Canary | tỷ lệ NHỎ sang bản mới, tăng dần | | Blue/Green | hai môi trường, chuyển TOÀN BỘ một lúc | | Rolling | thay thế từng phần instance | | All-at-once | thay hết ngay — rủi ro cao nhất |

Từ khoá nhận diện:

"gradually roll out", "small percentage first" → canary "switch all traffic at once, easy rollback" → blue/green "replace instances in batches" → rolling

⚠ Ba dịch vụ AWS hỗ trợ canary: | Dịch vụ | Cơ chế | |---|---| | API Gateway | canary settings trên stage | | Lambda | alias với weighted routing | | CodeDeploy | canary cho Lambda, ECS, EC2 |

Lambda alias weighted:

aws lambda update-alias --function-name xu-ly-api \
  --name prod --function-version 5 \
  --routing-config '{"AdditionalVersionWeights":{"6":0.1}}'

10% lưu lượng sang version 6
    → tăng dần rồi chuyển hẳn

⚠ CodeDeploy có cấu hình canary dựng sẵn: | Cấu hình | Nghĩa | |---|---| | Canary10Percent5Minutes | 10% trong 5 phút rồi 100% | | Canary10Percent30Minutes | 10% trong 30 phút | | Linear10PercentEvery1Minute | tăng 10% mỗi phút | | AllAtOnce | chuyển hết ngay |

Ba tham số của canary settings: | Tham số | Việc | |---|---| | percentTraffic | tỷ lệ lưu lượng sang canary | | useStageCache | canary có dùng cache của stage không | | stageVariableOverrides | biến khác cho canary |

⚠ stageVariableOverrides rất hữu ích:

{"canarySettings": {
  "percentTraffic": 10.0,
  "stageVariableOverrides": {"lambdaAlias": "canary"}}}

Canary gọi alias Lambda khác
    → cùng một API nhưng backend khác

Ba metric cần theo dõi khi chạy canary: | Metric | Ý nghĩa | |---|---| | 4XXError và 5XXError | tỷ lệ lỗi | | Latency và IntegrationLatency | | | Count | tỷ lệ chia có đúng không |

⚠ Tự động quay lui bằng CloudWatch alarm:

aws cloudwatch put-metric-alarm --alarm-name canary-loi-cao \
  --namespace AWS/ApiGateway --metric-name 5XXError \
  --dimensions Name=ApiName,Value=api-game Name=Stage,Value=prod \
  --statistic Average --period 60 --evaluation-periods 2 \
  --threshold 0.05 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns-hoac-lambda>

Ba lưu ý về stage của API Gateway: | Lưu ý | Chi tiết | |---|---| | Mỗi stage có URL riêng | /prod, /dev | | Stage variable truyền cấu hình | | | Deployment là ảnh chụp bất biến | |

⚠ Ba lưu ý về cache khi chạy canary: | Lưu ý | Chi tiết | |---|---| | useStageCache=false cho canary | tránh lẫn kết quả | | Cache có thể che vấn đề của bản mới | | | Xoá cache sau khi thăng canary | |

Ba lưu ý về versioning: | Lưu ý | Chi tiết | |---|---| | Deployment ID xác định một bản | | | Có thể quay về bất kỳ deployment cũ nào | | | Ghi mô tả cho mỗi deployment | |

aws apigateway get-deployments --rest-api-id abc123 \
  --query "items[].[id,createdDate,description]" --output table

Ba lưu ý khi thay đổi phá vỡ tương thích: | Lưu ý | Chi tiết | |---|---| | Canary KHÔNG hợp với breaking change | client cũ sẽ lỗi | | Dùng versioning trong đường dẫn (/v2/) | | | Hoặc header version | |

⚠ Đây là giới hạn quan trọng của canary:

Canary chia lưu lượng NGẪU NHIÊN
    → cùng một client có thể lần này vào bản cũ,
      lần sau vào bản mới
        ↓
    Chỉ hợp khi hai bản TƯƠNG THÍCH với nhau

Ba lưu ý về theo dõi: | Lưu ý | Chi tiết | |---|---| | Bật execution log và access log | | | Dùng X-Ray để so độ trễ | | | Log riêng cho canary | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi API nhiều lần, xem tỷ lệ chia | | | So metric của canary và production | | | Thử quay lui | |

Và một lời khuyên: hãy đặt CloudWatch alarm tự động quay lui trước khi bắt đầu canary. Điểm của canary 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 thì 10% người dùng vẫn chịu lỗi suốt khoảng thời gian đó.

Câu 1055 AWS Database

A Solutions Architect manages multiple Amazon RDS MySQL databases. To improve security, the Solutions Architect wants to enable secure user access with short-lived credentials. How can these requirements be met?

  1. A

    Configure the application to use the AUTH command to send a unique password
  2. B

    Configure the MySQL databases to use AWS KMS data encryption keys
  3. C

    Create the MySQL user accounts to use the AWSAuthenticationPlugin with IAM
  4. D

    Configure the MySQL databases to use the AWS Security Token Service (STS)
Xem giải thích

Đáp án

C — Tạo tài khoản người dùng MySQL dùng AWSAuthenticationPlugin với IAM.

Vì sao đúng

Đề nêu hai yêu cầu, và IAM database authentication đáp ứng chính xác: | Yêu cầu | Cách đáp ứng | |---|---| | Truy cập an toàn | không có mật khẩu tĩnh nào | | Credential NGẮN HẠN | token IAM hết hạn sau 15 phút |

⚠ Cách hoạt động:

1. Ứng dụng gọi API AWS sinh auth token
2. Token có hạn 15 PHÚT
3. Dùng token đó thay cho mật khẩu khi kết nối MySQL
        ↓
    KHÔNG có mật khẩu nào để lưu, để xoay, để rò rỉ

Bật IAM authentication:

aws rds modify-db-instance --db-instance-identifier csdl-ung-dung \
  --enable-iam-database-authentication --apply-immediately

Tạo user trong MySQL:

CREATE USER 'app_user'@'%' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
GRANT SELECT, INSERT, UPDATE ON ungdung.* TO 'app_user'@'%';

⚠ AWSAuthenticationPlugin là plugin đặc biệt của RDS — chính là thứ đề nhắc tới.

Sinh token và kết nối:

import boto3, pymysql

token = boto3.client('rds').generate_db_auth_token(
    DBHostname='csdl.abc.ap-southeast-1.rds.amazonaws.com',
    Port=3306, DBUsername='app_user')

ket_noi = pymysql.connect(
    host='csdl.abc.ap-southeast-1.rds.amazonaws.com',
    user='app_user', password=token,
    ssl={'ca': '/opt/rds-ca-bundle.pem'})

⚠ Ba điều kiện bắt buộc: | Điều kiện | Chi tiết | |---|---| | Bật IAM auth trên instance | | | User trong MySQL dùng AWSAuthenticationPlugin | | | BẮT BUỘC kết nối SSL/TLS | |

IAM policy cho phép kết nối:

{"Effect": "Allow",
 "Action": "rds-db:connect",
 "Resource": "arn:aws:rds-db:ap-southeast-1:123456789012:dbuser:db-ABCDEFGHIJKL/app_user"}

⚠ Resource dùng DbiResourceId, không phải tên instance:

aws rds describe-db-instances --db-instance-identifier csdl-ung-dung \
  --query "DBInstances[0].DbiResourceId"

Định danh này KHÔNG đổi khi đổi tên instance
    → nên policy vẫn đúng sau khi đổi tên

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có mật khẩu tĩnh | | | Token hết hạn sau 15 phút | | | Quản lý quyền tập trung bằng IAM | |

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

  • **D. Cấu hình CSDL dùng AWS Security Token Service (STS) — STS sinh credential tạm cho AWS API, không phải cơ chế xác thực trực tiếp vào MySQL. (Nó nằm bên dưới IAM auth, nhưng cách diễn đạt không đúng.)
  • **A. Cấu hình ứng dụng dùng lệnh AUTH gửi mật khẩu duy nhất — AUTH là lệnh của Redis, không phải MySQL. Và một mật khẩu duy nhất vẫn là credential tĩnh.
  • **B. Cấu hình CSDL dùng khoá mã hoá dữ liệu KMS — mã hoá bảo vệ dữ liệu khi lưu trữ, hoàn toàn không liên quan tới xác thực người dùng.

Ghi nhớ

⚠ Ba cách quản lý credential CSDL — bảng phải thuộc: | Cách | Credential | Xoay | |---|---|---| | IAM database authentication | token 15 phút | không cần | | Secrets Manager | mật khẩu tĩnh | tự động | | Parameter Store SecureString | mật khẩu tĩnh | tự viết |

⚠ Thứ tự ưu tiên khi thiết kế:

1. IAM authentication (không có mật khẩu)
2. Secrets Manager (có xoay tự động)
3. Parameter Store (miễn phí, tự xoay)
        ↓
    Không bao giờ: mật khẩu trong mã hay biến môi trường

Từ khoá nhận diện:

"short-lived credentials", "no static password" → IAM database authentication "rotate credentials automatically" → Secrets Manager "AUTH command" → Redis (không phải MySQL) "encrypt data at rest" → KMS

⚠ Ba giới hạn của IAM database authentication: | Giới hạn | Chi tiết | |---|---| | Giới hạn số kết nối MỚI mỗi giây | ~200 với MySQL | | Bắt buộc SSL | | | Không dùng cho user quản trị | |

Ứng dụng mở nhiều kết nối ngắn
    → chạm giới hạn tần suất xác thực
        ↓
    Dùng connection pool, hoặc RDS Proxy

⚠ RDS Proxy kết hợp rất tốt:

aws rds create-db-proxy --db-proxy-name proxy-csdl \
  --engine-family MYSQL --role-arn <arn-role> \
  --auth '[{"AuthScheme":"SECRETS","SecretArn":"<arn-secret>",
            "IAMAuth":"REQUIRED"}]' \
  --vpc-subnet-ids subnet-a subnet-b --require-tls

Client dùng IAM auth tới Proxy
    → Proxy dùng Secrets Manager tới CSDL
        ↓
    Vừa không có mật khẩu ở client
    vừa gộp kết nối

Ba engine hỗ trợ IAM authentication: | Engine | Hỗ trợ | |---|---| | RDS for MySQL, MariaDB | ✅ | | RDS for PostgreSQL | ✅ | | Aurora MySQL, Aurora PostgreSQL | ✅ | | Oracle, SQL Server | ❌ |

⚠ Với PostgreSQL, cú pháp khác:

CREATE USER app_user;
GRANT rds_iam TO app_user;

Ba lưu ý về SSL: | Lưu ý | Chi tiết | |---|---| | Tải RDS CA bundle | | | Bắt buộc verify chứng chỉ | | | Bật rds.force_ssl ở parameter group | |

curl -o rds-ca-bundle.pem \
  https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

⚠ rds.force_ssl chặn kết nối không mã hoá:

Không bật: client kết nối không TLS vẫn được chấp nhận
    → một cấu hình sai ở ứng dụng là dữ liệu đi trần

Ba lưu ý về token: | Lưu ý | Chi tiết | |---|---| | Hạn 15 phút | | | Sinh lại trước mỗi lần kết nối mới | | | Không cần sinh lại cho kết nối đang mở | |

Ba lưu ý về IAM policy: | Lưu ý | Chi tiết | |---|---| | Action là rds-db:connect | | | Resource dùng DbiResourceId | | | Có thể dùng * cho tên user | |

{"Effect":"Allow","Action":"rds-db:connect",
 "Resource":"arn:aws:rds-db:*:123456789012:dbuser:db-ABCDEFGHIJKL/*"}

Ba lưu ý về Secrets Manager (lựa chọn thứ hai): | Lưu ý | Chi tiết | |---|---| | Có Lambda xoay dựng sẵn cho RDS | | | Chiến lược alternating users tránh gián đoạn | | | ~0,40 USD mỗi secret mỗi tháng | |

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | CSDL trong subnet riêng tư | | | --no-publicly-accessible | | | Security group tham chiếu SG của ứng dụng | |

Ba lưu ý về audit: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi việc sinh token | | | Bật audit log của CSDL | | | Database Activity Streams cho Aurora | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối bằng token | phải thành công | | Thử kết nối bằng mật khẩu | phải bị từ chối | | Chờ quá 15 phút rồi dùng lại token cũ | phải bị từ chối |

Và một lời khuyên: hãy đặt RDS Proxy giữa ứng dụng và CSDL khi dùng IAM authentication. Việc sinh token cho mỗi kết nối mới chạm giới hạn tần suất rất nhanh với ứng dụng mở nhiều kết nối ngắn — và proxy vừa gộp kết nối vừa giữ được mô hình không mật khẩu.

Câu 1056 AWS Compute

A finance organization wants to deploy end of day processing applications to a fleet of Amazon EC2 instances with a focus on reducing cost. These applications are stateless and can be re-triggered in case of failure. The company needs a solution that minimizes cost and operational overhead.

What should a solutions architect do to meet these requirements?

  1. A

    Use On-Demand Instances in an Amazon Elastic Kubernetes Service (Amazon EKS) managed node group.
  2. B

    Use Spot Instances in an Amazon Elastic Kubernetes Service (Amazon EKS) managed node group.
  3. C

    Use On-Demand Instances in an Amazon EC2 Auto Scaling group to run the application containers.
  4. D

    Use Spot Instances in an Amazon EC2 Auto Scaling group to run the application containers.
Xem giải thích

Đáp án

B — Dùng Spot Instances trong một EKS managed node group.

Vì sao đúng

Đề mô tả khối lượng công việc hợp với Spot đến mức hiếm thấy: | Dữ kiện | Vì sao Spot hợp | |---|---| | Xử lý theo lô (batch) | không cần chạy liên tục | | Chịu được gián đoạn | đúng điều kiện duy nhất của Spot | | Cần tối ưu chi phí | giảm tới 90% so với On-Demand |

⚠ Spot chỉ có một điều kiện, và đề đã nói rõ nó được thoả mãn:

Spot rẻ vì AWS có thể LẤY LẠI máy bất cứ lúc nào
    → báo trước 2 phút
        ↓
    Ứng dụng chịu được gián đoạn → Spot là lựa chọn đúng
    Ứng dụng không chịu được    → Spot là lựa chọn sai

Tạo managed node group dùng Spot:

aws eks create-nodegroup --cluster-name cum-xu-ly \
  --nodegroup-name nhom-spot --capacity-type SPOT \
  --instance-types m5.large m5a.large m5d.large m4.large \
  --scaling-config minSize=0,maxSize=50,desiredSize=5 \
  --subnets subnet-a subnet-b subnet-c \
  --node-role <arn-role>

⚠ Khai NHIỀU loại instance là quan trọng nhất:

Chỉ khai một loại
    → hết năng lực loại đó = mất toàn bộ node
        ↓
Khai 4-6 loại tương đương
    → EKS chọn pool nào còn năng lực
    → xác suất bị lấy lại đồng loạt giảm mạnh

Managed node group xử lý sẵn phần khó: | Việc | EKS làm tự động | |---|---| | Cài Node Termination Handler | ✅ có sẵn trong managed node group Spot | | Cordon và drain node khi có cảnh báo | ✅ | | Dùng Capacity Optimized allocation | ✅ |

⚠ Đây là lý do dùng managed node group thay vì tự dựng ASG:

Tự dựng: phải cài aws-node-termination-handler,
         phải cấu hình IMDS, phải tự xử lý drain
        ↓
Managed node group: EKS lo hết

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giảm tới 90% chi phí | | | Tự động thay node bị lấy lại | | | Không cần đặt cam kết trước | |

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

  • **A. Dùng Reserved Instances cho các node — đây là phương án gần nhất về mặt "giảm chi phí", nhưng RI đòi cam kết 1 hoặc 3 năm và chỉ có lợi khi tải chạy liên tục và ổn định. Với tải theo lô thì phần lớn thời gian bạn trả tiền cho máy không chạy.
  • **C. Dùng On-Demand — đắt nhất và không tận dụng được đặc tính "chịu được gián đoạn" mà đề nêu ra.
  • **D. Dùng Dedicated Hosts — đắt hơn nữa, sinh ra cho yêu cầu tuân thủ hoặc license theo socket, hoàn toàn không phải công cụ tiết kiệm.

Ghi nhớ

⚠ Bốn mô hình mua EC2 — bảng phải thuộc: | Mô hình | Giảm giá | Cam kết | Khi nào | |---|---|---|---| | On-Demand | 0% | không | tải không đoán trước, ngắn | | Spot | tới 90% | không | chịu được gián đoạn | | Savings Plans / RI | tới 72% | 1-3 năm | tải ổn định liên tục | | Dedicated Host | — | tuỳ | tuân thủ, license theo socket |

Từ khoá nhận diện:

"fault-tolerant", "interruption-tolerant", "batch" → Spot "steady state, predictable, 24/7" → Savings Plans / RI "cannot be interrupted, short-term" → On-Demand "bring your own license per socket" → Dedicated Host

⚠ Ba khối lượng công việc HỢP với Spot: | Loại | Ví dụ | |---|---| | Xử lý theo lô | ETL, render, transcode | | Phân tích dữ liệu lớn | EMR, Spark | | CI/CD runner | build agent | | Huấn luyện ML có checkpoint | |

⚠ Ba khối lượng công việc KHÔNG hợp với Spot: | Loại | Vì sao | |---|---| | CSDL có trạng thái | mất node là mất dữ liệu đang xử lý | | Dịch vụ đòi SLA cao | có thể mất toàn bộ node | | Tác vụ dài không checkpoint | mất công từ đầu |

Ba chiến lược tăng độ bền cho Spot: | Chiến lược | Chi tiết | |---|---| | Đa dạng loại instance (6+ loại) | | | Đa dạng Availability Zone | | | Trộn Spot với một phần On-Demand | |

⚠ Trộn hai loại trong EKS:

Nhóm On-Demand: 3 node, chạy pod hệ thống và pod trạng thái
Nhóm Spot:      0-50 node, chạy pod xử lý lô
        ↓
    Dùng taint và toleration để phân bổ đúng

# taint trên nhóm Spot
kubectl taint nodes -l eks.amazonaws.com/capacityType=SPOT \
  spot=true:NoSchedule

# pod chấp nhận chạy trên Spot
spec:
  tolerations:
    - key: "spot"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"
  nodeSelector:
    eks.amazonaws.com/capacityType: SPOT

Ba lưu ý về cảnh báo bị lấy lại: | Lưu ý | Chi tiết | |---|---| | Báo trước 2 phút | qua IMDS và EventBridge | | Rebalance recommendation báo SỚM HƠN | | | Node Termination Handler drain tự động | |

⚠ Rebalance recommendation là tín hiệu sớm hơn 2 phút:

AWS đánh giá node này có nguy cơ cao bị lấy lại
    → gửi rebalance recommendation
        ↓
    Chuẩn bị node thay thế TRƯỚC khi cảnh báo 2 phút tới

Ba lưu ý về Karpenter (giải pháp hiện đại): | Lưu ý | Chi tiết | |---|---| | Tự chọn loại instance rẻ nhất phù hợp | | | Cấp node trong ~1 phút | | | Tự hợp nhất node để giảm lãng phí | |

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: nhom-spot
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
      nodeClassRef:
        name: mac-dinh
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

Ba lưu ý về pod khi node biến mất: | Lưu ý | Chi tiết | |---|---| | Đặt PodDisruptionBudget | | | Đặt terminationGracePeriodSeconds hợp lý | | | Tác vụ dài phải có checkpoint | |

⚠ PodDisruptionBudget bảo vệ tính sẵn sàng:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb-xu-ly
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: xu-ly-lo

Ba lưu ý về theo dõi chi phí: | Lưu ý | Chi tiết | |---|---| | Cost Explorer lọc theo purchase option | | | Gắn tag cho node group | | | Spot placement score chọn vùng tốt | |

Ba lưu ý về giá Spot: | Lưu ý | Chi tiết | |---|---| | Giá đổi theo cung cầu, không đấu giá nữa | | | Không cần đặt max price | mặc định = giá On-Demand | | Spot Instance Advisor cho tần suất bị lấy lại | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra capacityType của node | | | Thử mô phỏng bị lấy lại | FIS | | So hoá đơn trước và sau | |

kubectl get nodes -L eks.amazonaws.com/capacityType

Và một lời khuyên: hãy khai ít nhất sáu loại instance tương đương cho node group Spot. Spot không rủi ro vì máy bị lấy lại — nó rủi ro khi toàn bộ node bị lấy lại cùng lúc, và điều đó chỉ xảy ra khi tất cả chúng nằm trong cùng một capacity pool.

Câu 1057 AWS Networking & Content Delivery

An application is running in a private subnet of an Amazon VPC and must have outbound internet access for downloading updates. The Solutions Architect does not want the application exposed to inbound connection attempts. Which steps should be taken?

  1. A

    Create a NAT gateway and attach an internet gateway to the VPC
  2. B

    Create a NAT gateway but do not attach an internet gateway to the VPC
  3. C

    Attach an internet gateway to the private subnet and create a NAT gateway
  4. D

    Attach an internet gateway to the VPC but do not create a NAT gateway
Xem giải thích

Đáp án

A — Tạo một NAT gateway và gắn một internet gateway vào VPC.

Vì sao đúng

Đề mô tả tình huống kinh điển: instance trong subnet riêng tư cần gọi ra Internet để tải bản vá, nhưng không được nhận kết nối từ Internet vào.

⚠ NAT gateway cần internet gateway để hoạt động:

NAT gateway ĐẶT TRONG subnet CÔNG KHAI
    → subnet công khai định tuyến 0.0.0.0/0 tới internet gateway
        ↓
    Không có internet gateway = NAT gateway vô dụng

Luồng đầy đủ:

EC2 trong subnet riêng tư
    → route table riêng tư: 0.0.0.0/0 → NAT gateway
        ↓
    NAT gateway (subnet công khai, có Elastic IP)
        → route table công khai: 0.0.0.0/0 → internet gateway
            ↓
        Internet

Dựng đầy đủ:

# 1. Gắn internet gateway
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-abc \
  --internet-gateway-id igw-abc

# 2. Route table CÔNG KHAI trỏ ra internet gateway
aws ec2 create-route --route-table-id rtb-cong-khai \
  --destination-cidr-block 0.0.0.0/0 --gateway-id igw-abc

# 3. NAT gateway trong subnet CÔNG KHAI
aws ec2 allocate-address --domain vpc
aws ec2 create-nat-gateway --subnet-id subnet-cong-khai \
  --allocation-id eipalloc-abc

# 4. Route table RIÊNG TƯ trỏ ra NAT gateway
aws ec2 create-route --route-table-id rtb-rieng-tu \
  --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-abc

⚠ Ba lỗi hay gặp khi dựng: | Lỗi | Hậu quả | |---|---| | Đặt NAT gateway trong subnet RIÊNG TƯ | không ra được Internet | | Quên gắn internet gateway | NAT gateway không hoạt động | | Sửa nhầm route table | instance riêng tư thành công khai |

Đặt NAT gateway 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

Vì sao NAT một chiều:

NAT gateway thực hiện dịch địa chỉ CHO KẾT NỐI ĐI RA
    → nó nhớ kết nối để trả lời về
        ↓
    Không có kết nối đi ra tương ứng
    → gói tin từ ngoài vào bị bỏ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Instance riêng tư ra Internet được | | | Không ai từ Internet vào được | | | AWS quản lý, tự mở rộng tới 100 Gbps | |

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

  • **B. Tạo NAT instance và gắn internet gateway — đây là phương án gần nhất và về mặt kỹ thuật cũng chạy được, nhưng NAT instance là cách cũ: bạn phải tự vá, tự lo tính sẵn sàng, tự tắt source/destination check, và băng thông giới hạn theo cỡ máy. AWS khuyến nghị NAT gateway.
  • **C. Chỉ tạo internet gateway — instance trong subnet riêng tư không có địa chỉ IP công khai, nên riêng internet gateway không giúp nó ra ngoài được.
  • **D. Chỉ tạo NAT gateway mà không có internet gateway — NAT gateway phải dựa vào internet gateway để đi tiếp; thiếu nó thì không có đường ra.

Ghi nhớ

⚠ NAT gateway vs NAT instance — bảng phải thuộc: | Tiêu chí | NAT gateway | NAT instance | |---|---|---| | Quản lý | AWS lo | bạn tự lo | | Sẵn sàng | trong một AZ, tự dự phòng | tự dựng | | Băng thông | 5 Gbps → 100 Gbps tự động | theo cỡ máy | | Security group | KHÔNG gắn được | gắn được | | Bastion host | không dùng được | dùng được | | Port forwarding | không | được |

⚠ NAT gateway KHÔNG có security group — kiểm soát nằm ở NACL của subnet chứa nó.

Từ khoá nhận diện:

"private instances need outbound internet, no inbound" → NAT gateway "instance needs public IP and inbound" → internet gateway + public subnet "IPv6 outbound only" → egress-only internet gateway "no internet at all, reach AWS services" → VPC endpoint

⚠ Ba lưu ý về tính sẵn sàng: | Lưu ý | Chi tiết | |---|---| | NAT gateway nằm TRONG MỘT AZ | | | AZ hỏng = subnet dùng nó mất Internet | | | Đặt MỘT NAT gateway MỖI AZ | |

Một NAT gateway dùng chung cho 3 AZ
    → AZ chứa nó hỏng = cả 3 mất Internet
    → và trả phí truyền dữ liệu liên AZ
        ↓
    Mỗi AZ một NAT gateway, route table riêng

⚠ Ba khoản chi phí của NAT gateway: | Khoản | Giá tham khảo | |---|---| | Phí giờ | ~0,045 USD/giờ (~32 USD/tháng) | | Phí xử lý dữ liệu | ~0,045 USD/GB | | Nhân 3 AZ | ~100 USD/tháng chỉ tiền giờ |

⚠ Phí xử lý dữ liệu là chỗ hoá đơn nổ:

Ứng dụng tải 10 TB từ S3 qua NAT gateway
    → 10.000 GB × 0,045 = 450 USD
        ↓
    Dùng S3 Gateway Endpoint: MIỄN PHÍ hoàn toàn

Ba VPC endpoint nên có để tiết kiệm: | Endpoint | Loại | Phí | |---|---|---| | S3 | Gateway | miễn phí | | DynamoDB | Gateway | miễn phí | | ECR, Secrets Manager, SSM | Interface | ~0,01 USD/giờ + dữ liệu |

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-rieng-tu

Ba cách giảm chi phí NAT: | Cách | Chi tiết | |---|---| | VPC endpoint cho dịch vụ AWS | | | Đặt cache/mirror gói trong VPC | | | Xem VPC Flow Logs tìm lưu lượng bất ngờ | |

Ba lưu ý về IPv6: | Lưu ý | Chi tiết | |---|---| | NAT gateway dành cho IPv4 | | | IPv6 dùng egress-only internet gateway | | | Egress-only MIỄN PHÍ | |

Ba lưu ý về giới hạn: | Lưu ý | Chi tiết | |---|---| | ~55.000 kết nối đồng thời mỗi đích | | | Vượt thì lỗi ErrorPortAllocation | | | Chia tải ra nhiều NAT gateway | |

Ba lưu ý về quản lý vá: | Lưu ý | Chi tiết | |---|---| | Systems Manager Patch Manager thay cho tải trực tiếp | | | SSM qua VPC endpoint không cần NAT | | | Cân nhắc AMI đã vá sẵn | |

⚠ Nếu chỉ cần vá thì có thể không cần NAT chút nào:

Systems Manager qua interface endpoint
    → ssm, ssmmessages, ec2messages
        ↓
    Vá được, chạy lệnh được, Session Manager được
    → không cần NAT gateway

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl ra Internet từ instance riêng tư | phải được | | Thử kết nối từ ngoài vào | phải bị chặn | | Kiểm tra route table | |

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu \
  --query "RouteTables[0].Routes"

Và một lời khuyên: hãy tạo S3 Gateway Endpoint ngay khi dựng NAT gateway. Nó miễn phí, mất một lệnh, và ở phần lớn kiến trúc thì lưu lượng S3 chính là phần lớn nhất của hoá đơn xử lý dữ liệu NAT.

Câu 1058 Chọn nhiều đáp án AWS Database

A global financial services company is currently operating a three-tier web application to handle their main customer facing website. This application uses several Amazon EC2 instances behind an Application Load Balancer and connects directly to a DynamoDB table.

Due to recent customer complaints of slow loading times, their Solutions Architect has been asked to implement changes to solve this problem, without rearchitecting the core application components.


Which combination of actions should the solutions architect take to accomplish this? (Select TWO.)

  1. A

    Create a CloudFront distribution and place it in front of the Application Load Balancer.
  2. B

    Set up an Amazon DynamoDB Accelerator (DAX) cluster in front of the DynamoDB table.
  3. C

    Migrate the entire application stack to AWS Elastic Beanstalk with both web server and worker environments.
  4. D

    Migrate the web application to be hosted on a containerized solution using AWS Fargate.
  5. E

    Migrate the DynamoDB database to Amazon Aurora with a multi-AZ deployment model.
Xem giải thích

Đáp án

A và B — Đặt CloudFront trước Application Load Balancer, và đặt DynamoDB Accelerator (DAX) trước DynamoDB.

Vì sao đúng

Đề mô tả ứng dụng ba tầng bị chậm và cần giảm độ trễ cho cả nội dung lẫn truy vấn dữ liệu. Hai phương án này giải quyết hai tầng khác nhau:

Tầng Vấn đề Giải pháp
Trình bày nội dung đi từ một vùng tới người dùng toàn cầu CloudFront
Dữ liệu mỗi lần đọc đều chạm DynamoDB DAX

⚠ CloudFront giảm độ trễ theo hai cách:

1. Cache nội dung tĩnh ở edge gần người dùng
    → không phải đi tới vùng gốc
        ↓
2. Nội dung động vẫn đi qua mạng xương sống của AWS
    → nhanh hơn Internet công cộng dù không cache được

Cấu hình CloudFront trước ALB:

aws cloudfront create-distribution --distribution-config '{
  "CallerReference": "phan-phoi-ung-dung",
  "Origins": {"Quantity": 1, "Items": [{
    "Id": "alb-goc",
    "DomainName": "alb-abc.ap-southeast-1.elb.amazonaws.com",
    "CustomOriginConfig": {"HTTPPort":80,"HTTPSPort":443,
                           "OriginProtocolPolicy":"https-only"}}]},
  "DefaultCacheBehavior": {
    "TargetOriginId": "alb-goc",
    "ViewerProtocolPolicy": "redirect-to-https",
    "CachePolicyId": "<id-chinh-sach>"},
  "Enabled": true}'

⚠ DAX là bộ nhớ đệm ĐẶC THÙ cho DynamoDB:

Đọc từ DynamoDB:  đơn vị mili giây (single-digit ms)
Đọc từ DAX:       đơn vị MICRO giây
        ↓
    Nhanh hơn ~10 lần cho tải đọc nhiều

Điểm mạnh nhất của DAX — API tương thích hoàn toàn:

# Trước
import boto3
bang = boto3.resource('dynamodb').Table('DonHang')

# Sau — chỉ đổi client
import amazondax
dax = amazondax.AmazonDaxClient.resource(
    endpoint_url='dax://cum-dax.abc.dax-clusters.ap-southeast-1.amazonaws.com')
bang = dax.Table('DonHang')

# Mọi lời gọi giữ nguyên
bang.get_item(Key={'id': '123'})

⚠ Đây là khác biệt lớn nhất so với ElastiCache: | Tiêu chí | DAX | ElastiCache | |---|---|---| | Sửa mã ứng dụng | gần như không | phải viết logic cache | | Xử lý cache miss | tự động đọc DynamoDB | tự viết | | Ghi xuyên cache | tự động | tự viết | | Dùng cho | chỉ DynamoDB | mọi nguồn |

Tạo cụm DAX:

aws dax create-cluster --cluster-name cum-dax \
  --node-type dax.r5.large --replication-factor 3 \
  --iam-role-arn <arn-role> \
  --subnet-group-name nhom-subnet-dax \
  --security-group-ids sg-dax

Ba lợi ích của cặp này: | Lợi ích | Chi tiết | |---|---| | Giảm độ trễ ở cả hai tầng | | | Giảm tải cho ALB và DynamoDB | | | Giảm chi phí đọc DynamoDB | |

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

  • **E. Dùng ElastiCache trước DynamoDB — đây là phương án gần nhất và về mặt kỹ thuật cũng cache được, nhưng bạn phải tự viết toàn bộ logic: kiểm tra cache, xử lý miss, ghi lại, vô hiệu hoá. DAX làm sẵn tất cả cho DynamoDB.
  • **C. Dùng Auto Scaling để tăng số instance — mở rộng giúp chịu thông lượng cao hơn, nhưng không giảm độ trễ của một yêu cầu đơn lẻ. Một truy vấn DynamoDB vẫn mất chừng ấy thời gian dù có bao nhiêu máy.
  • **D. Chuyển sang instance mạnh hơn — cũng vậy: CPU nhanh hơn không rút ngắn quãng đường mạng tới người dùng ở châu lục khác.

Ghi nhớ

⚠ Bốn lớp cache của AWS — bảng phải thuộc: | Lớp | Dịch vụ | Cache gì | |---|---|---| | Edge | CloudFront | nội dung tĩnh và động | | API | API Gateway cache | phản hồi API | | Ứng dụng | ElastiCache | bất kỳ dữ liệu nào | | CSDL | DAX | chỉ DynamoDB |

Từ khoá nhận diện:

"global users, high latency for content" → CloudFront "microsecond DynamoDB reads, minimal code change" → DAX "cache anything, session store, leaderboard" → ElastiCache "handle more requests" → Auto Scaling (thông lượng, KHÔNG phải độ trễ)

⚠ Phân biệt độ trễ và thông lượng — bẫy kinh điển:

Độ trễ (latency):     một yêu cầu mất bao lâu
Thông lượng (throughput): xử lý được bao nhiêu yêu cầu
        ↓
    Auto Scaling tăng THÔNG LƯỢNG
    Cache và CDN giảm ĐỘ TRỄ

Ba lưu ý về DAX: | Lưu ý | Chi tiết | |---|---| | Chỉ tăng tốc ĐỌC, không tăng tốc GHI | | | Ghi đi qua DAX rồi tới DynamoDB (write-through) | | | Có eventual consistency với DynamoDB | |

⚠ DAX KHÔNG hợp khi: | Trường hợp | Vì sao | |---|---| | Cần strongly consistent read | DAX luôn trả từ cache | | Tải ghi nhiều hơn đọc | không có lợi | | Dữ liệu đổi liên tục | cache luôn cũ |

Yêu cầu strongly consistent read qua DAX
    → DAX chuyển thẳng tới DynamoDB, không cache
        ↓
    Không sai kết quả, nhưng cũng không nhanh hơn

Ba tham số TTL của DAX: | Tham số | Mặc định | |---|---| | Item cache TTL | 5 phút | | Query cache TTL | 5 phút | | Cả hai chỉnh được | |

Ba lưu ý về cụm DAX: | Lưu ý | Chi tiết | |---|---| | Tối thiểu 3 node cho sản xuất | | | Trải trên nhiều AZ | | | Nằm trong VPC, cần security group | |

⚠ DAX chỉ truy cập được từ trong VPC — không có endpoint công khai.

Ba lưu ý về CloudFront với ALB: | Lưu ý | Chi tiết | |---|---| | Dùng cache policy phù hợp từng đường dẫn | | | Nội dung động: TTL 0 nhưng vẫn qua mạng AWS | | | Bảo vệ ALB bằng custom header | |

⚠ Chặn truy cập thẳng vào ALB:

CloudFront thêm header bí mật
    → ALB listener rule chỉ nhận yêu cầu có header đó
        ↓
    Ai gọi thẳng ALB bị từ chối

aws elbv2 create-rule --listener-arn <arn> --priority 1 \
  --conditions '[{"Field":"http-header",
    "HttpHeaderConfig":{"HttpHeaderName":"X-Origin-Secret",
                        "Values":["chuoi-bi-mat"]}}]' \
  --actions Type=forward,TargetGroupArn=<arn-tg>

Ba loại cache policy nên biết: | Policy | Dùng cho | |---|---| | CachingOptimized | nội dung tĩnh | | CachingDisabled | API động | | CachingOptimizedForUncompressedObjects | ảnh, video |

Ba lưu ý về đo hiệu quả: | Metric | Ý nghĩa | |---|---| | CloudFront CacheHitRate | tỷ lệ trúng cache | | DAX ItemCacheHits / ItemCacheMisses | | | DynamoDB ConsumedReadCapacityUnits | phải giảm sau khi bật DAX |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | DAX tính theo giờ node | | | Nhưng giảm RCU của DynamoDB | | | CloudFront rẻ hơn truyền thẳng từ vùng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ nhiều nơi trước và sau | | | Xem CacheHitRate của CloudFront | | | Xem tỷ lệ trúng cache của DAX | |

Và một lời khuyên: hãy đo độ trễ trước khi thêm bất kỳ lớp cache nào. Cache giảm độ trễ chỉ khi độ trễ đến từ việc đọc dữ liệu lặp lại — nếu nó thực ra đến từ một truy vấn scan toàn bảng thì DAX chỉ cache lại chính cái chậm đó.

Câu 1059 AWS Management & Governance

A solutions architect in a large finance organization must restrict access for a specific S3 bucket to only users in accounts within the organization in AWS Organizations. This is due to the confidentiality of project reports data.

Which solution meets these requirements with the LEAST amount of operational overhead?

  1. A

    Tag each user that needs access to the S3 bucket. Add the aws:PrincipalTag global condition key to the S3 bucket policy.
  2. B

    Create an organizational unit (OU) for each department. Add the aws:PrincipalOrgPaths global condition key to the S3 bucket policy.
  3. C

    Use AWS CloudTrail to monitor the CreateAccount, InviteAccountToOrganization, LeaveOrganization, and RemoveAccountFromOrganization events. Update the S3 bucket policy accordingly.
  4. D

    Add the aws:PrincipalOrgID global condition key with a reference to the organization ID to the S3 bucket policy.
Xem giải thích

Đáp án

D — Thêm khoá điều kiện aws:PrincipalOrgID vào bucket policy của S3, với ID của tổ chức.

Vì sao đúng

Đề nêu yêu cầu: chỉ cho phép các tài khoản trong AWS Organizations truy cập bucket, và giải pháp phải ít công vận hành nhất.

⚠ aws:PrincipalOrgID là khoá sinh ra đúng cho việc này:

Nó so ID TỔ CHỨC của principal gọi tới
    → thêm tài khoản mới vào tổ chức: TỰ ĐỘNG được phép
    → gỡ tài khoản khỏi tổ chức: TỰ ĐỘNG mất quyền
        ↓
    KHÔNG phải sửa policy lần nào

Bucket policy:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChiChoPhepToChuc",
   "Effect": "Allow",
   "Principal": "*",
   "Action": ["s3:GetObject", "s3:PutObject"],
   "Resource": "arn:aws:s3:::kho-du-lieu-chung/*",
   "Condition": {
     "StringEquals": {"aws:PrincipalOrgID": "o-abc123def4"}}}]}

Lấy ID tổ chức:

aws organizations describe-organization --query "Organization.Id"

⚠ So sánh với cách liệt kê từng tài khoản:

Liệt kê account ID trong Principal:
    → 40 tài khoản = 40 dòng
    → thêm tài khoản thứ 41 = phải sửa policy
        ↓
    Và bucket policy có giới hạn 20 KB
    → tổ chức lớn có thể chạm trần

Một biến thể chặt hơn — chặn cả người ngoài:

{"Sid": "TuChoiNgoaiToChuc",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-du-lieu-chung",
              "arn:aws:s3:::kho-du-lieu-chung/*"],
 "Condition": {
   "StringNotEquals": {"aws:PrincipalOrgID": "o-abc123def4"}}}

⚠ Deny mạnh hơn Allow — dùng dạng này khi muốn đảm bảo tuyệt đối không ai ngoài tổ chức chạm được, kể cả khi có statement Allow khác lỏng lẻo.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một dòng điều kiện thay cho danh sách dài | | | Tự cập nhật khi tổ chức thay đổi | | | Không chạm trần kích thước policy | |

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

  • **A. Tạo bucket policy liệt kê từng account ID — đây là phương án gần nhất và có hiệu lực đúng, nhưng vi phạm yêu cầu "least operational overhead": mỗi lần tổ chức thêm hay bớt tài khoản là phải sửa policy.
  • **B. Dùng SCP giới hạn truy cập S3 — SCP chỉ áp cho principal TRONG tổ chức; nó không ngăn được tài khoản ngoài tổ chức truy cập bucket. SCP là hàng rào bên trong, không phải cổng ngoài.
  • **C. Dùng ACL của S3 — ACL là cơ chế cũ, không hỗ trợ khoá điều kiện, và AWS khuyến nghị tắt hẳn bằng Object Ownership = Bucket owner enforced.

Ghi nhớ

⚠ Ba khoá điều kiện tổ chức — bảng phải thuộc: | Khoá | So sánh với | |---|---| | aws:PrincipalOrgID | ID tổ chức của người GỌI | | aws:PrincipalOrgPaths | đường dẫn OU của người gọi | | aws:ResourceOrgID | ID tổ chức của TÀI NGUYÊN |

⚠ aws:PrincipalOrgPaths giới hạn tới OU cụ thể:

{"Condition": {"ForAnyValue:StringLike": {
  "aws:PrincipalOrgPaths": ["o-abc123def4/r-xyz/ou-sanxuat/*"]}}}

Chỉ tài khoản trong OU "sanxuat" được phép
    → chặt hơn cả tổ chức

Từ khoá nhận diện:

"only accounts in my organization", "least overhead" → aws:PrincipalOrgID "only accounts in a specific OU" → aws:PrincipalOrgPaths "restrict what my own accounts can do" → SCP "specific accounts only" → liệt kê Principal

⚠ SCP vs bucket policy — khác biệt cốt lõi:

SCP:           giới hạn quyền TỐI ĐA của principal trong tổ chức
               → không cấp quyền, chỉ giới hạn
               → KHÔNG áp cho người ngoài tổ chức
        ↓
Bucket policy: quyết định AI được chạm vào bucket
               → áp cho MỌI người gọi, trong hay ngoài

Ba lưu ý về aws:PrincipalOrgID: | Lưu ý | Chi tiết | |---|---| | Chỉ có giá trị khi người gọi thuộc một tổ chức | | | Dịch vụ AWS gọi thay không có khoá này | | | Kết hợp với aws:SourceArn cho dịch vụ | |

⚠ Đây là bẫy hay gặp:

CloudFront, CloudTrail... gọi vào bucket
    → chúng KHÔNG mang aws:PrincipalOrgID
        ↓
    Chính sách Deny StringNotEquals sẽ CHẶN LUÔN CHÚNG
    → dùng thêm điều kiện loại trừ theo service principal

{"Condition": {
  "StringNotEquals": {"aws:PrincipalOrgID": "o-abc123def4"},
  "BoolIfExists": {"aws:PrincipalIsAWSService": "false"}}}

Ba lớp bảo vệ bucket: | Lớp | Việc | |---|---| | Block Public Access | chặn mọi cấu hình công khai | | Bucket policy | ai được làm gì | | VPC endpoint policy | giới hạn theo đường mạng |

aws s3api put-public-access-block --bucket kho-du-lieu-chung \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

Ba lưu ý về Object Ownership: | Lưu ý | Chi tiết | |---|---| | BucketOwnerEnforced tắt hẳn ACL | khuyến nghị | | Chủ bucket sở hữu mọi object | | | Đơn giản hoá quyền xuyên tài khoản | |

Ba lưu ý về giới hạn policy: | Giới hạn | Giá trị | |---|---| | Bucket policy | 20 KB | | IAM policy quản lý | 6 KB | | SCP | 5 KB |

Ba lưu ý về kiểm tra: | Công cụ | Việc | |---|---| | IAM Access Analyzer | phát hiện truy cập ngoài tổ chức | | aws s3control policy status | | | IAM Policy Simulator | |

⚠ Access Analyzer với phạm vi tổ chức:

aws accessanalyzer create-analyzer \
  --analyzer-name phan-tich-to-chuc --type ORGANIZATION

Nó báo mọi tài nguyên có thể truy cập
từ NGOÀI tổ chức
    → đúng cái đề đang muốn ngăn

Ba lưu ý về truy cập xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | Cần cả bucket policy VÀ IAM policy bên gọi | | | Vai trò IAM là cách sạch hơn ACL | | | KMS key policy cũng phải cho phép | |

⚠ Bucket mã hoá SSE-KMS cần thêm một bước:

Bucket policy cho phép, nhưng KMS key policy không
    → AccessDenied mà thông báo không nói rõ vì KMS
        ↓
    Thêm aws:PrincipalOrgID vào CẢ key policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử từ tài khoản trong tổ chức | phải được | | Thử từ tài khoản ngoài | phải bị từ chối | | Chạy Access Analyzer | |

Và một lời khuyên: hãy đặt aws:PrincipalOrgID vào cả bucket policy lẫn KMS key policy khi bucket dùng SSE-KMS. Mở một bên mà quên bên kia cho ra lỗi AccessDenied chẳng nói gì về nguyên nhân, và người gỡ lỗi sẽ dành cả buổi soi lại đúng cái policy đã đúng sẵn.

Câu 1060 AWS Networking & Content Delivery

An international logistics company has web applications running on AWS in the us-west-2 Region and database servers in the eu-central-1 Region. The applications running in a VPC in us-west-2 need to communicate securely with the databases running in a VPC in eu-central-1.

Which network design will meet these requirements?

  1. A

    Create a VPC peering connection between the us-west-2 VPC and the eu-central-1 VPC. Add the appropriate routes to the subnet route tables. Create an inbound rule in the us-west-2 application security group that allows traffic from the eu-central-1 database server IP addresses.
  2. B

    Configure a VPC peering connection between the us-west-2 VPC and the eu-central-1 VPC. Update the subnet route tables accordingly. Create an inbound rule in the eu-central-1 database security group that allows traffic from the us-west-2 application server IP addresses.
  3. C

    Establish a VPC peering connection between the us-west-2 VPC and the eu-central-1 VPC. Modify the subnet route tables accordingly. Create an inbound rule in the eu-central-1 database security group that references the security group ID of the application servers in us-west-2.
  4. D

    Establish a transit gateway with a peering attachment between the us-west-2 VPC and the eu-central-1 VPC. After the transit gateways are properly peered and routing is configured, create an inbound rule in the eu-central-1 database security group that references the security group ID of the application servers in us-west-2.
Xem giải thích

Đáp án

B — Tạo VPC peering giữa hai VPC ở hai Region, cập nhật route table, và dùng địa chỉ IP trong quy tắc security group.

Vì sao đúng

Đề nêu hai VPC ở hai Region khác nhau cần nói chuyện riêng tư. VPC peering hỗ trợ liên vùng từ 2017, và đây là cách trực tiếp nhất.

⚠ Nhưng chi tiết quyết định nằm ở vế cuối — "dùng địa chỉ IP":

Trong CÙNG một Region:
    → security group được tham chiếu security group khác
    → sg-abc cho phép sg-xyz
        ↓
XUYÊN Region:
    → tham chiếu security group KHÔNG hoạt động
    → BẮT BUỘC dùng dải CIDR

Đây chính là điều làm B đúng và các phương án nhắc tới "reference security group" sai.

Dựng peering liên vùng:

# Từ vùng A
aws ec2 create-vpc-peering-connection --vpc-id vpc-a \
  --peer-vpc-id vpc-b --peer-region ap-northeast-1 \
  --region ap-southeast-1

# Chấp nhận ở vùng B
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-abc --region ap-northeast-1

Cập nhật route table hai chiều:

aws ec2 create-route --route-table-id rtb-a \
  --destination-cidr-block 10.2.0.0/16 \
  --vpc-peering-connection-id pcx-abc --region ap-southeast-1

aws ec2 create-route --route-table-id rtb-b \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-abc --region ap-northeast-1

Security group dùng CIDR:

aws ec2 authorize-security-group-ingress --group-id sg-b \
  --protocol tcp --port 3306 --cidr 10.1.10.0/24 \
  --region ap-northeast-1

⚠ Hai điều kiện bắt buộc của peering: | Điều kiện | Chi tiết | |---|---| | CIDR KHÔNG được chồng lấn | | | KHÔNG có định tuyến bắc cầu | A↔B, B↔C không cho A↔C |

VPC A: 10.1.0.0/16
VPC B: 10.1.0.0/16
        ↓
    Không peer được — không phân biệt nổi đích đến

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lưu lượng đi trên mạng xương sống AWS | không qua Internet | | Được mã hoá tự động khi qua Region | | | Không có điểm nghẽn băng thông | |

⚠ AWS mã hoá lưu lượng peering liên vùng ở tầng vật lý — không cần VPN chồng lên.

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

  • **A. VPC peering rồi tham chiếu security group của VPC kia — đây là phương án gần nhất và chỉ sai đúng một chi tiết, nhưng chi tiết đó khiến nó không chạy: security group referencing không hoạt động xuyên Region. Trong cùng Region thì A sẽ đúng.
  • **C. Dùng AWS Direct Connect — Direct Connect nối trung tâm dữ liệu tại chỗ với AWS, không phải nối hai VPC với nhau. Sai công cụ hoàn toàn.
  • **D. Dùng internet gateway và IP công khai — vi phạm yêu cầu "riêng tư": lưu lượng đi qua Internet công cộng.

Ghi nhớ

⚠ Security group referencing — bảng phải thuộc: | Tình huống | Tham chiếu SG | |---|---| | Cùng VPC | ✅ | | VPC peering CÙNG Region | ✅ | | VPC peering XUYÊN Region | ❌ phải dùng CIDR | | Transit Gateway | ❌ phải dùng CIDR | | Direct Connect / VPN | ❌ |

⚠ Đây là bẫy hay gặp nhất trong đề thi lẫn thực tế:

Kiến trúc chạy tốt trong một Region
    → nhân bản sang Region thứ hai
        ↓
    Quy tắc SG tham chiếu SG im lặng không khớp gì
    → kết nối treo, không có thông báo lỗi nào

Từ khoá nhận diện:

"two VPCs, different Regions, private" → VPC peering liên vùng (dùng CIDR) "many VPCs need to connect" → Transit Gateway "on-premises to AWS, dedicated" → Direct Connect "on-premises to AWS, over internet" → Site-to-Site VPN

⚠ Peering vs Transit Gateway — khi nào đổi:

2-3 VPC:   peering đơn giản và rẻ
        ↓
10 VPC full mesh: 45 kết nối peering
    → không quản nổi
        ↓
    Transit Gateway: 10 attachment, một bảng định tuyến

Công thức số kết nối full mesh: n × (n-1) / 2

Ba lưu ý về Transit Gateway liên vùng: | Lưu ý | Chi tiết | |---|---| | TGW peering nối hai Region | | | Định tuyến bắc cầu ĐƯỢC hỗ trợ | khác peering | | Đắt hơn peering | phí attachment + dữ liệu |

Ba khoản chi phí của peering liên vùng: | Khoản | Chi tiết | |---|---| | Không có phí giờ | khác Transit Gateway | | Phí truyền dữ liệu liên vùng | ~0,02 USD/GB | | Tính cả hai chiều | |

⚠ Peering CÙNG Region, CÙNG AZ thì miễn phí truyền dữ liệu — khác vùng thì luôn tính phí.

Ba lưu ý về DNS: | Lưu ý | Chi tiết | |---|---| | Bật EnableDnsSupport hai bên | | | Bật DNS resolution cho peering | | | Không tự phân giải tên riêng tư nếu chưa bật | |

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

Ba lưu ý về route table: | Lưu ý | Chi tiết | |---|---| | Phải thêm route ở CẢ HAI bên | | | Mỗi subnet dùng route table riêng của nó | | | Thiếu một chiều = kết nối một chiều, treo | |

⚠ Đây là lỗi phổ biến thứ hai:

Thêm route ở VPC A, quên VPC B
    → gói tin đi được sang B
    → phản hồi không tìm được đường về
        ↓
    Kết nối treo tới timeout, trông như lỗi security group

Ba giới hạn của peering: | Giới hạn | Chi tiết | |---|---| | Không bắc cầu | | | Không dùng chung NAT gateway của VPC kia | | | Không dùng chung VPC endpoint của VPC kia | |

Ba cách tổ chức CIDR: | Cách | Chi tiết | |---|---| | Lập kế hoạch dải IP toàn tổ chức từ đầu | | | Dùng AWS IPAM để quản lý | | | Chừa dải cho mở rộng | |

⚠ IPAM ngăn đúng vấn đề chồng lấn:

aws ec2 create-ipam --operating-regions RegionName=ap-southeast-1 \
  RegionName=ap-northeast-1

Cấp CIDR từ pool trung tâm
    → không bao giờ trùng
    → peering sau này luôn khả thi

Ba lưu ý về theo dõi: | Lưu ý | Chi tiết | |---|---| | VPC Flow Logs xem lưu lượng qua peering | | | Reachability Analyzer chẩn đoán đường đi | | | CloudWatch metric cho TGW, không có cho peering | |

⚠ Reachability Analyzer là công cụ gỡ lỗi tốt nhất:

aws ec2 create-network-insights-path \
  --source i-nguon --destination i-dich \
  --protocol tcp --destination-port 3306

Nó chỉ ra CHÍNH XÁC chặn ở đâu:
route table, security group, hay NACL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra route ở cả hai bên | | | Xác nhận SG dùng CIDR, không dùng SG ID | | | Chạy Reachability Analyzer | |

Và một lời khuyên: hãy rà lại mọi quy tắc security group tham chiếu SG khi mở rộng sang Region thứ hai. Chúng không báo lỗi khi tạo, không hiện gì bất thường trong console, và chỉ lộ ra dưới dạng kết nối treo mà mọi cấu hình nhìn đều đúng.