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

Đáp án

A — Dùng AWS Global Accelerator và tạo một endpoint group cho mỗi AWS Region; gắn ALB của từng Region vào endpoint group tương ứng.

Vì sao đúng

Đề nêu vấn đề rõ: hàng trăm EC2 instance với nhiều ALB ở nhiều Region, và cần giảm số địa chỉ IP phải khai vào danh sách cho phép của tường lửa.

Và Global Accelerator giải quyết triệt để:

Global Accelerator cấp ĐÚNG HAI IP TĨNH ANYCAST
    → không đổi trong suốt vòng đời của accelerator
    → phục vụ MỌI Region, MỌI ALB phía sau
        ↓
    Tường lửa công ty chỉ cần khai HAI địa chỉ

Trong khi ALB thì ngược lại:

ALB KHÔNG có IP tĩnh
    → địa chỉ thay đổi khi AWS mở rộng hoặc thay node
    → mỗi ALB ở mỗi Region lại có tập IP riêng
        ↓
    Không có cách nào khai vào tường lửa một cách ổn định

Kiến trúc:

Global Accelerator (2 IP tĩnh anycast)
    ├─▶ Endpoint group Region A → ALB A
    ├─▶ Endpoint group Region B → ALB B
    └─▶ Endpoint group Region C → ALB C

aws globalaccelerator create-accelerator --name accelerator-ung-dung

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener>   --endpoint-group-region ap-southeast-1   --endpoint-configurations EndpointId=<arn-alb>,Weight=100

Và Global Accelerator còn mang lại ba lợi ích khác: | Lợi ích | Chi tiết | |---|---| | Người dùng vào điểm biên GẦN NHẤT | rồi đi trên mạng xương sống AWS | | Chuyển đổi khi Region hỏng trong VÀI GIÂY | không phụ thuộc cache DNS | | Health check liên tục tới từng endpoint | tự loại Region không khoẻ |

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

• **B. Dùng Global Accelerator và tạo nhiều endpoint cho mọi Region, gắn địa chỉ IP RIÊNG TƯ của EC2 instance — đây là phương án gần nhất vì cũng dùng đúng dịch vụ, nhưng nó bỏ qua tầng ALB: gắn trực tiếp hàng trăm instance nghĩa là mất khả năng cân bằng tải và health check của ALB, và phải cập nhật danh sách endpoint mỗi khi Auto Scaling thay instance.
• **C. Viết Lambda theo dõi thay đổi IP của ALB và cập nhật tường lửa mỗi giờ — rất nhiều công và vẫn mong manh: phải viết và bảo trì mã, và có khoảng trễ tới một giờ giữa lúc IP đổi và lúc tường lửa được cập nhật — trong khoảng đó người dùng không truy cập được.
• **D. Khởi chạy Network Load Balancer với Elastic IP và đặt các ALB làm target — không dựng được như mô tả xuyên Region: NLB là dịch vụ trong phạm vi MỘT Region. Nó không đăng ký được ALB ở Region khác làm target.

Ghi nhớ

Địa chỉ IP của các dịch vụ cân bằng tải: | Dịch vụ | Địa chỉ | |---|---| | Application Load Balancer | IP ĐỘNG — bắt buộc dùng tên DNS | | Network Load Balancer | IP TĨNH mỗi AZ (hoặc gán Elastic IP) | | Global Accelerator | HAI IP TĨNH ANYCAST TOÀN CẦU | | CloudFront | IP động, dải rất rộng |

Quy tắc nhận diện:

"static IP", "whitelist on firewall", "multiple Regions" → Global Accelerator "static IP", một Region, TCP/UDP → NLB với Elastic IP

Ba khái niệm của Global Accelerator: | Khái niệm | Việc | |---|---| | Accelerator | cấp hai IP tĩnh anycast | | Listener | cổng và giao thức nhận lưu lượng | | Endpoint group | một nhóm cho mỗi Region | | Endpoint | ALB, NLB, EC2 instance, hoặc Elastic IP |

Global Accelerator và CloudFront — bảng phân biệt: | | Global Accelerator | CloudFront | |---|---|---| | Giao thức | TCP, UDP — mọi ứng dụng | HTTP/HTTPS | | Cache | ❌ | ✅ | | IP tĩnh | ✅ hai IP anycast | ❌ | | Chuyển đổi khi hỏng | vài giây | theo origin group | | Phù hợp | game, IoT, VoIP, API cần IP tĩnh | nội dung web, tài sản tĩnh |

Global Accelerator và Route 53 latency routing: | | Global Accelerator | Route 53 latency | |---|---|---| | Cơ chế | IP anycast — không phụ thuộc DNS | DNS | | Chuyển đổi khi Region hỏng | VÀI GIÂY | phụ thuộc TTL | | Lưu lượng đi qua | mạng xương sống AWS | Internet công cộng | | IP tĩnh | ✅ | ❌ | | Chi phí | phí giờ + phí mỗi GB | phí truy vấn DNS |

Global Accelerator vượt trội khi cần chuyển đổi nhanh và IP cố định.

Ba lợi ích của việc đi trên mạng xương sống AWS: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp hơn và ổn định hơn | không phụ thuộc chất lượng Internet | | Ít mất gói tin hơn | đường truyền được quản lý | | Cải thiện tới 60% với người dùng ở xa | theo đo lường của AWS |

Ba tính năng khác của Global Accelerator: | Tính năng | Việc | |---|---| | Traffic dial | điều chỉnh phần trăm lưu lượng tới mỗi Region | | Endpoint weight | phân phối trong một Region | | Client affinity | giữ client dính với cùng endpoint | | Custom routing accelerator | định tuyến tới instance cụ thể theo cổng |

Traffic dial rất hữu ích cho việc triển khai dần:

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

Region mới chỉ nhận 10% lưu lượng để quan sát trước khi mở hết.

Ba lưu ý về chi phí Global Accelerator: | Khoản | Chi tiết | |---|---| | Phí cố định mỗi giờ cho accelerator | ~0,025 USD/giờ (~18 USD/tháng) | | Phí truyền dữ liệu bổ sung theo GB | tuỳ Region nguồn và đích | | Không có mức miễn phí | tính phí ngay từ đầu |

Với hàng trăm instance và nhiều ALB, chi phí này nhỏ so với giá trị vận hành mà nó mang lại.

Và có một lựa chọn khác cho bài toán danh sách IP: AWS-managed prefix list.

AWS công bố dải IP của mình qua ip-ranges.json
    → tường lửa có thể khai theo dải
    → NHƯNG dải rất rộng và thay đổi
    → không thu hẹp được như hai IP của Global Accelerator

Và một lời khuyên vận hành: hai IP của Global Accelerator không đổi trong suốt vòng đời của accelerator — nhưng nếu xoá và tạo lại accelerator thì nhận IP mới. Hãy ghi lại chúng và bảo vệ accelerator khỏi việc bị xoá nhầm, vì đổi IP nghĩa là phải làm việc lại với đội mạng của công ty.

Đáp án

A — Amazon S3 Standard.

Vì sao đúng

Đề cho một con số quyết định: dữ liệu chỉ cần giữ 12 GIỜ.

Và mọi lớp lưu trữ rẻ hơn đều có RÀNG BUỘC THỜI GIAN LƯU TỐI THIỂU: | Lớp | Lưu tối thiểu | |---|---| | S3 Standard | KHÔNG có | | Standard-IA | 30 ngày | | One Zone-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Glacier Deep Archive | 180 ngày |

Nên với dữ liệu chỉ tồn tại 12 giờ:

Đưa vào Standard-IA:
    → xoá sau 12 giờ
    → VẪN BỊ TÍNH PHÍ ĐỦ 30 NGÀY
    → đắt hơn Standard rất nhiều

Đưa vào Deep Archive:
    → bị tính phí đủ 180 NGÀY cho dữ liệu tồn tại nửa ngày
    → đắt hơn hàng chục lần

Và S3 Standard không có ràng buộc nào:

Trả tiền theo GB-GIỜ thực tế
    → lưu 12 giờ thì trả cho 12 giờ
    → không phí truy xuất, không phí tối thiểu

Và nên đặt lifecycle rule tự xoá:

{"Rules": [{
  "ID": "xoa-log-sau-1-ngay",
  "Status": "Enabled",
  "Filter": {"Prefix": "log-tam/"},
  "Expiration": {"Days": 1}}]}

(Lifecycle rule có độ phân giải theo NGÀY, nên giá trị nhỏ nhất là 1 ngày.)

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

• **C. S3 Standard-IA — đây là phương án gần nhất vì giá lưu trữ mỗi GB rẻ hơn Standard, nhưng nó có ràng buộc 30 NGÀY: xoá sau 12 giờ vẫn bị tính đủ một tháng. Với dữ liệu ngắn hạn, đây là lựa chọn đắt hơn.
• **B. S3 One Zone-IA — cùng ràng buộc 30 ngày, và thêm rủi ro chỉ lưu ở một AZ.
• **D. Glacier Deep Archive — tệ nhất cho tình huống này: ràng buộc 180 ngày, và thời gian truy xuất 12–48 giờ — lâu hơn cả thời gian dữ liệu cần tồn tại.

Ghi nhớ

Ràng buộc thời gian lưu tối thiểu — bảng cần thuộc: | Lớp | Tối thiểu | Kích thước tính phí tối thiểu | |---|---|---| | Standard | không | không | | Standard-IA | 30 ngày | 128 KB | | One Zone-IA | 30 ngày | 128 KB | | Glacier Instant Retrieval | 90 ngày | 128 KB | | Glacier Flexible Retrieval | 90 ngày | 40 KB | | Glacier Deep Archive | 180 ngày | 40 KB | | Intelligent-Tiering | không | không (có phí giám sát) |

Hai cột này là nguyên nhân khiến "lớp rẻ hơn" đôi khi đắt hơn.

Và cột "kích thước tối thiểu" cũng quan trọng:

Tệp 10 KB đưa vào Standard-IA
    → bị TÍNH PHÍ NHƯ 128 KB
    → với hàng triệu tệp nhỏ, khoản này rất lớn

Ba câu hỏi để chọn đúng lớp lưu trữ:

① Dữ liệu tồn tại BAO LÂU?
      Dưới 30 ngày → Standard
② Truy cập BAO NHIÊU LẦN?
      Thường xuyên → Standard
      Hiếm → IA hoặc Glacier
③ Cần truy xuất NHANH đến mức nào?
      Tức thì → Standard, IA, Glacier Instant Retrieval
      Chờ được → Glacier Flexible hoặc Deep Archive

Và với mẫu "log tạm, xoá sau vài giờ", có ba lựa chọn: | Lựa chọn | Đặc điểm | |---|---| | S3 Standard + lifecycle expiration | đơn giản nhất ← câu này | | CloudWatch Logs với retention ngắn | tìm kiếm được ngay bằng Logs Insights | | Kinesis Data Streams | nếu chỉ là vùng đệm cho xử lý luồng |

CloudWatch Logs đáng cân nhắc cho log:

aws logs put-retention-policy --log-group-name /ung-dung/tam   --retention-in-days 1

Nó cho tìm kiếm và đặt alarm — thứ mà S3 thuần không có.

Bảng lớp lưu trữ S3 đầy đủ: | Lớp | Số AZ | Truy xuất | Phù hợp | |---|---|---|---| | Standard | ≥ 3 | tức thì | dữ liệu nóng, ngắn hạn ← câu này | | Intelligent-Tiering | ≥ 3 | tức thì | mẫu truy cập khó đoán | | Standard-IA | ≥ 3 | tức thì | ít truy cập, giữ trên 30 ngày | | One Zone-IA | 1 | tức thì | dữ liệu tái tạo được | | Glacier Instant Retrieval | ≥ 3 | mili giây | lưu trữ nhưng cần ngay | | Glacier Flexible | ≥ 3 | 1 phút – 12 giờ | lưu trữ, chờ được | | Glacier Deep Archive | ≥ 3 | 12–48 giờ | rẻ nhất, gần như không đọc |

Và một lifecycle rule nên có cho MỌI bucket:

{"Rules": [{"Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Multipart upload thất bại để lại các phần đã tải, tính phí mãi mãi mà không hiện trong danh sách object.

Ba lưu ý về lifecycle expiration: | Lưu ý | Chi tiết | |---|---| | Độ phân giải theo NGÀY | không đặt được theo giờ | | Chạy MỘT LẦN mỗi ngày | không xoá đúng vào giờ thứ 12 | | Với bucket có versioning, cần NoncurrentVersionExpiration | nếu không phiên bản cũ vẫn tính phí |

Nếu cần xoá chính xác sau 12 giờ, dùng cách khác:

EventBridge Scheduler → Lambda xoá object theo tag hoặc theo thời gian tạo
    → kiểm soát chính xác hơn lifecycle rule

Ba cách giảm chi phí lưu trữ ngắn hạn: | Cách | Chi tiết | |---|---| | Lifecycle expiration | tự xoá, miễn phí | | Nén dữ liệu trước khi lưu | log nén gzip giảm 80–90% | | Gộp nhiều log nhỏ thành tệp lớn | giảm phí request |

Và một lưu ý về phí request: với hàng triệu tệp log nhỏ, phí PUT request có thể vượt cả phí lưu trữ. S3 tính khoảng 0,005 USD cho mỗi 1.000 request PUT — hãy gộp log lại trước khi ghi thay vì mỗi dòng một tệp.

Đáp án

D — Chuyển toàn bộ tài sản tĩnh và trang web sang Amazon S3; đưa ứng dụng lên Amazon ECS với Service Auto Scaling; chuyển database sang Amazon RDS với Multi-AZ.

Vì sao đúng

Đề nêu yêu cầu tách rời các tầng để có ứng dụng sẵn sàng cao — và đáp án xử lý cả ba tầng: | Tầng | Vấn đề hiện tại | Giải pháp | |---|---|---| | Front-end (trang tĩnh) | nằm cùng máy chủ ứng dụng | S3 — tách hẳn ra, độ bền 11 số 9 | | Ứng dụng (MỘT EC2 instance) | điểm hỏng đơn | ECS với Service Auto Scaling | | Dữ liệu (MySQL) | không rõ sẵn sàng cao | RDS Multi-AZ — failover tự động |

Và điểm mấu chốt: đề nói ứng dụng xử lý TÁC VỤ CHẠY LÂU.

"a single EC2 instance that handles LONG-RUNNING PROCESSES"
    ↓
    → Lambda KHÔNG dùng được (giới hạn 15 phút)
    → cần container hoặc EC2 chạy liên tục
    → ECS là lựa chọn đúng

Ba lợi ích của việc tách tầng: | Lợi ích | Chi tiết | |---|---| | Mỗi tầng co giãn ĐỘC LẬP | trang tĩnh không cần máy chủ nào | | Mất một thành phần không làm sập cả hệ thống | | | Chi phí thấp hơn | S3 rẻ hơn nhiều so với EC2 phục vụ tệp tĩnh |

Và với xử lý thanh toán thẻ tín dụng, sẵn sàng cao ở tầng dữ liệu là bắt buộc:

RDS Multi-AZ:
    → sao chép ĐỒNG BỘ sang standby ở AZ khác
    → failover TỰ ĐỘNG trong 60–120 giây
    → KHÔNG MẤT DỮ LIỆU (RPO = 0)

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

• **A. Chuyển tài sản tĩnh sang CloudFront; dùng Auto Scaling cho EC2; RDS Multi-AZ — đây là phương án gần nhất và có hai vế cuối đúng, nhưng vế đầu hiểu sai CloudFront: CloudFront là CDN, nó CACHE nội dung từ một origin — nó không phải nơi LƯU TRỮ. Vẫn cần S3 hoặc máy chủ nào đó làm origin.
• **C. Chuyển tài sản sang S3; dùng Lambda với concurrency limit; chuyển database sang DynamoDB — hai vấn đề: Lambda giới hạn 15 phút, không chạy được tác vụ dài như đề mô tả. Và chuyển từ MySQL sang DynamoDB đòi viết lại toàn bộ mô hình dữ liệu và truy vấn — không phải "tách rời tầng".
• **B. Gộp mọi thứ vào một instance LỚN HƠN — đi ngược yêu cầu: đề nói phải TÁCH RỜI (decouple) các tầng. Gộp lại là làm ngược, và một instance vẫn là điểm hỏng đơn dù to đến đâu.

Ghi nhớ

Kiến trúc ba tầng chuẩn trên AWS: | Tầng | Dịch vụ | |---|---| | Trình bày (tĩnh) | S3 + CloudFront | | Ứng dụng | ALB + ECS/EKS/EC2 với Auto Scaling | | Dữ liệu | RDS Multi-AZ, Aurora, hoặc DynamoDB |

Và mỗi tầng phải trải qua ít nhất HAI Availability Zone.

Ba nguyên tắc tách rời (decoupling): | Nguyên tắc | Chi tiết | |---|---| | Tách nội dung tĩnh khỏi máy chủ ứng dụng | S3 phục vụ tệp, EC2 lo logic | | Tách trạng thái khỏi instance | phiên ở ElastiCache, tệp ở S3 hoặc EFS | | Tách các thành phần bằng hàng đợi hoặc sự kiện | SQS, SNS, EventBridge |

Dòng giữa là điều kiện tiên quyết để co giãn ngang được — nếu ứng dụng còn giữ phiên trong bộ nhớ máy chủ, Auto Scaling sẽ làm người dùng bị đăng xuất.

Chọn dịch vụ compute theo thời gian chạy: | Thời gian | Dịch vụ | |---|---| | Dưới 15 phút, theo sự kiện | Lambda | | Chạy lâu, dịch vụ thường trực | ECS/EKS trên Fargate hoặc EC2 | | Xử lý lô lớn | AWS Batch | | Cần kiểm soát hoàn toàn | EC2 |

Đề nói "long-running processes" → loại Lambda ngay.

Ba lựa chọn chạy container trên AWS: | Lựa chọn | Đặc điểm | |---|---| | ECS trên Fargate | không quản lý máy chủ nào | | ECS trên EC2 | kiểm soát instance, rẻ hơn với tải ổn định | | EKS | Kubernetes chuẩn, hệ sinh thái rộng |

Với đội ngũ nhỏ và không cần Kubernetes, ECS trên Fargate là lựa chọn ít công nhất.

Ba loại Auto Scaling trong ECS: | Loại | Điều chỉnh | |---|---| | Service Auto Scaling | SỐ TASK của một service | | Cluster Auto Scaling (capacity provider) | số EC2 instance trong cụm | | Không cần (với Fargate) | Fargate tự cấp tài nguyên cho mỗi task |

Ba metric để co giãn ECS service: | Metric | Phù hợp | |---|---| | ECSServiceAverageCPUUtilization | ứng dụng nặng CPU | | ECSServiceAverageMemoryUtilization | ứng dụng nặng bộ nhớ | | ALBRequestCountPerTarget | phản ánh tải thật tốt nhất cho ứng dụng web |

Và với xử lý thanh toán, hãy cân nhắc thêm SQS để tách rời hơn nữa:

Web tier nhận yêu cầu thanh toán
    ↓ đẩy vào SQS
Worker tier (ECS) xử lý theo tốc độ của mình
    ↓
RDS ghi kết quả

Ba yêu cầu tuân thủ PCI-DSS cho xử lý thẻ tín dụng: | Yêu cầu | Cấu hình | |---|---| | Mã hoá dữ liệu at rest | KMS cho RDS, S3, EBS | | Mã hoá in transit | TLS cho mọi kết nối, require_secure_transport | | Phân đoạn mạng | tầng dữ liệu ở private subnet | | Audit trail | CloudTrail, VPC Flow Logs, database audit log |

Và cân nhắc KHÔNG lưu số thẻ tín dụng chút nào:

Dùng dịch vụ thanh toán bên thứ ba (tokenization)
    → hệ thống chỉ giữ TOKEN, không giữ số thẻ
    → phạm vi tuân thủ PCI-DSS thu hẹp rất nhiều

Đây là quyết định kiến trúc có tác động lớn nhất tới chi phí tuân thủ.

Và một lời khuyên về thứ tự triển khai: hãy tách tầng tĩnh sang S3 trước — đó là thay đổi ít rủi ro nhất, cho kết quả ngay (tải trang nhanh hơn, giảm tải EC2), và không đụng tới logic nghiệp vụ. Rồi mới container hoá tầng ứng dụng, và cuối cùng là chuyển database.

Đáp án

A — Tạo một Lambda Function URL và dùng nó làm webhook cho dịch vụ phân tích bên thứ ba.

Vì sao đúng

Đề cần một endpoint HTTP để bên thứ ba gọi POST vào, với ít công vận hành nhất — và Function URL là tính năng dựng sẵn của Lambda cho đúng việc đó.

Function URL là gì:

Bật một công tắc trên Lambda function
    → nhận ngay một URL HTTPS chuyên dụng:
      https://<id>.lambda-url.<region>.on.aws/
    → không cần dịch vụ nào khác

aws lambda create-function-url-config   --function-name xu-ly-du-lieu-benh-nhan   --auth-type AWS_IAM   --cors '{"AllowOrigins":["https://dich-vu-phan-tich.com"]}'

Và "MOST operationally efficient" được đáp ứng: | So sánh | Function URL | API Gateway | |---|---|---| | Số thành phần phải tạo | 1 (chỉ Lambda) | 2 (Lambda + API Gateway) | | Cấu hình | một lệnh | tạo API, resource, method, integration, stage, deploy | | Chi phí | chỉ trả phí Lambda | thêm phí API Gateway | | Bảo trì | không có gì thêm | quản lý stage, phiên bản |

Hai chế độ xác thực: | Chế độ | Đặc điểm | |---|---| | AWS_IAM | người gọi phải ký request bằng SigV4 | | NONE | công khai — ai cũng gọi được |

Với dữ liệu y tế, AWS_IAM là lựa chọn đúng — bên thứ ba dùng IAM role được cấp quyền để ký request.

Và nếu bên thứ ba không hỗ trợ SigV4, dùng NONE kèm xác minh chữ ký trong mã:

def lambda_handler(event, context):
    chu_ky = event['headers'].get('x-signature')
    if not xac_minh_hmac(event['body'], chu_ky, BI_MAT):
        return {'statusCode': 401}
    xu_ly(json.loads(event['body']))

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

• **D. Tạo API Gateway endpoint cho Lambda function — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó nhiều công hơn: phải tạo và cấu hình thêm một dịch vụ, quản lý stage và deployment, và trả thêm phí. Với nhu cầu chỉ là một webhook đơn giản, đó là thành phần thừa. (API Gateway đáng dùng khi cần giới hạn tốc độ theo khách hàng, caching, hoặc quản lý nhiều phiên bản API.)
• **B. Gắn SQS queue vào Lambda và dùng URL của hàng đợi làm webhook — sai về mặt kỹ thuật: URL của SQS queue không phải endpoint HTTP nhận POST thông thường — nó là endpoint API cần request được ký SigV4 với định dạng riêng của SQS. Bên thứ ba không gọi được như một webhook.
• **C. Dựng EC2 instance làm proxy cho Lambda — nhiều công nhất: phải quản lý một máy chủ, vá lỗi, giám sát, và lo sẵn sàng cao — cho một việc mà AWS đã có tính năng dựng sẵn.

Ghi nhớ

Ba cách phơi Lambda ra dưới dạng HTTP endpoint: | Cách | Đặc điểm | |---|---| | Function URL | đơn giản nhất, miễn phí thêm ← câu này | | API Gateway | đầy đủ tính năng: throttling, caching, API key, WAF | | Application Load Balancer | Lambda làm target, phù hợp khi đã có ALB |

Quy tắc chọn:

Một webhook đơn giản, ít công nhất → Function URL Nhiều endpoint, cần quản lý API, giới hạn tốc độ theo khách hàng → API Gateway Đã có ALB và muốn gộp chung → ALB với Lambda target

Bảng so sánh đầy đủ: | | Function URL | API Gateway | |---|---|---| | Thiết lập | một lệnh | nhiều bước | | Chi phí thêm | 0 | ~1 USD/triệu request (HTTP API) | | Timeout | 15 phút (bằng Lambda) | 29 giây | | Xác thực | IAM hoặc NONE | IAM, Cognito, Lambda authorizer, API key | | Throttling theo khách hàng | ❌ | ✅ usage plan | | Caching | ❌ | ✅ | | Tên miền tuỳ chỉnh | ❌ | ✅ | | WAF | ❌ (dùng CloudFront phía trước) | ✅ | | Streaming response | ✅ | hạn chế |

Hai dòng đáng chú ý:

Timeout: Function URL cho tới 15 PHÚT
         API Gateway giới hạn 29 GIÂY
    → với xử lý dài, Function URL có lợi thế thật

Tên miền tuỳ chỉnh: Function URL KHÔNG hỗ trợ trực tiếp
    → muốn có thì đặt CloudFront phía trước

Ba lưu ý bảo mật cho Function URL: | Lưu ý | Chi tiết | |---|---| | AuthType: NONE là CÔNG KHAI hoàn toàn | ai biết URL đều gọi được | | Không có WAF trực tiếp | đặt CloudFront phía trước nếu cần | | Đặt reserved concurrency | giới hạn thiệt hại nếu bị lạm dụng |

aws lambda put-function-concurrency   --function-name xu-ly-du-lieu-benh-nhan   --reserved-concurrent-executions 50

Nó vừa giới hạn chi phí khi bị tấn công, vừa bảo vệ hạn mức đồng thời của các hàm khác.

Và với AuthType: AWS_IAM, resource policy quyết định ai gọi được:

aws lambda add-permission --function-name xu-ly-du-lieu-benh-nhan   --statement-id cho-phep-doi-tac   --action lambda:InvokeFunctionUrl   --principal 111122223333   --function-url-auth-type AWS_IAM

Ba mẫu xử lý webhook tin cậy: | Mẫu | Chi tiết | |---|---| | Trả về 200 NGAY rồi xử lý bất đồng bộ | nhiều dịch vụ có timeout ngắn cho webhook | | Làm hàm IDEMPOTENT | webhook thường được gửi lại khi lỗi | | Ghi log mọi payload nhận được | phục vụ chẩn đoán và audit |

Mẫu đầu rất quan trọng:

def lambda_handler(event, context):
    # Đẩy vào SQS rồi trả về ngay
    sqs.send_message(QueueUrl=q, MessageBody=event['body'])
    return {'statusCode': 200}
    # Một Lambda khác xử lý từ SQS, không bị giới hạn thời gian của webhook

Ba yêu cầu cho dữ liệu y tế: | Yêu cầu | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc về pháp lý cho PHI | | Mã hoá at rest và in transit | Function URL luôn dùng HTTPS | | Audit trail | CloudTrail ghi lời gọi; bật cả log của Lambda |

Và Function URL luôn dùng HTTPS — không có tuỳ chọn HTTP thuần, nên vế mã hoá đường truyền được đảm bảo sẵn.

Và một lời khuyên: hãy đặt CloudFront phía trước Function URL nếu cần tên miền tuỳ chỉnh, WAF, hoặc giới hạn theo địa lý. Cấu hình đó vẫn đơn giản hơn API Gateway nhiều, và cho thêm lớp bảo vệ mà webhook công khai nên có.

Đáp án

C — Bật tính năng EBS Encryption By Default cho toàn bộ AWS Region.

Vì sao đúng

Đề nêu yêu cầu rõ: mọi EBS volume MỚI khôi phục từ snapshot chưa mã hoá đều phải TỰ ĐỘNG được mã hoá.

Và EBS encryption by default làm đúng điều đó:

Bật ở mức REGION
    → MỌI volume mới tạo trong Region đó đều được mã hoá
    → kể cả volume khôi phục từ snapshot CHƯA mã hoá
    → không ai phải nhớ khai tham số gì

aws ec2 enable-ebs-encryption-by-default --region ap-southeast-1
aws ec2 modify-ebs-default-kms-key-id --kms-key-id alias/khoa-cua-toi

Và điểm quan trọng: nó áp cho VOLUME MỚI, không đổi snapshot cũ.

Snapshot chưa mã hoá vẫn chưa mã hoá
    ↓
Nhưng khi ai đó tạo volume TỪ snapshot đó:
    → volume mới TỰ ĐỘNG được mã hoá
    → dữ liệu từ lúc đó trở đi được bảo vệ

Và đó là cách duy nhất đảm bảo "tự động" như đề yêu cầu:

Không bật mặc định:
    → phải nhớ khai --encrypted mỗi lần tạo volume
    → một lần quên là có volume không mã hoá
    → và không ai phát hiện ra

Đây là cấu hình nên bật cho mọi tài khoản sản xuất — nó biến việc mã hoá từ "phải nhớ" thành "không thể quên".

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

• **A. Bật EBS Encryption By Default cho các EBS volume cụ thể — sai phạm vi: tính năng này chỉ đặt được ở mức REGION, không đặt được cho từng volume. Không có tuỳ chọn nào như vậy.
• **B. Tạo volume mới và khai khoá KMS đối xứng khi tạo — đây là phương án gần nhất và thực sự mã hoá được, nhưng nó là thao tác THỦ CÔNG: phải khai mỗi lần, và quên một lần là có volume không mã hoá. Đề yêu cầu "tự động".
• **D. Tạo volume mới và mã hoá bằng khoá KMS BẤT ĐỐI XỨNG — sai loại khoá: EBS chỉ hỗ trợ khoá đối xứng. Khoá bất đối xứng dùng cho ký số và mã hoá dữ liệu nhỏ, không dùng cho mã hoá khối lượng lớn.

Ghi nhớ

Ba cách khôi phục volume có mã hoá từ snapshot chưa mã hoá: | Cách | Đặc điểm | |---|---| | Bật encryption by default cho Region | tự động, không ai quên được ← câu này | | Khai --encrypted khi tạo volume | thủ công, dễ sót | | Sao chép snapshot có mã hoá trước | rồi tạo volume từ snapshot đã mã hoá |

# Cách 3: mã hoá chính snapshot
aws ec2 copy-snapshot --source-snapshot-id snap-0abc123   --source-region ap-southeast-1 --encrypted --kms-key-id alias/khoa-cua-toi

Những gì được mã hoá khi bật mã hoá EBS: | Đối tượng | Mã hoá | |---|---| | Dữ liệu trên volume | ✅ | | Dữ liệu giữa volume và instance | ✅ (nhiều người không biết) | | Snapshot tạo từ volume mã hoá | ✅ tự động | | Volume tạo từ snapshot mã hoá | ✅ tự động | | AMI tạo từ volume mã hoá | ✅ |

Tính mã hoá LAN TRUYỀN theo chuỗi — không có cách nào vô tình tạo ra bản sao không mã hoá từ nguồn đã mã hoá.

Và cạm bẫy quan trọng: KHÔNG mã hoá volume ĐANG TỒN TẠI trực tiếp được.

Quy trình chuyển đổi cho volume chưa mã hoá:
    ① Chụp snapshot
    ② Sao chép snapshot với --encrypted
    ③ Tạo volume mới từ snapshot đã mã hoá
    ④ Tháo volume cũ, gắn volume mới

Ba loại khoá KMS cho EBS: | Loại | Chi phí | Kiểm soát | |---|---|---| | AWS managed key (aws/ebs) | miễn phí lưu | không đổi được policy | | Customer managed key | ~1 USD/tháng | đầy đủ: policy, xoay vòng, vô hiệu hoá |

Khi nào cần customer managed key: | Trường hợp | Lý do | |---|---| | Yêu cầu tuân thủ | cần kiểm soát và audit được khoá | | Chia sẻ snapshot mã hoá với tài khoản khác | khoá aws/ebs KHÔNG chia sẻ được | | Cần vô hiệu hoá khoá khẩn cấp | khoá AWS managed không tắt được |

Dòng giữa là ràng buộc kỹ thuật cứng — nhiều người chỉ phát hiện khi cần chia sẻ snapshot mới biết.

Ba lưu ý về khoá KMS đối xứng và bất đối xứng: | Loại | Dùng cho | |---|---| | Đối xứng (AES-256) | mã hoá dữ liệu — EBS, S3, RDS đều dùng loại này | | Bất đối xứng (RSA, ECC) | ký số, mã hoá dữ liệu NHỎ, ứng dụng bên ngoài AWS |

Mọi dịch vụ AWS mã hoá at rest đều dùng khoá đối xứng — đó là lý do phương án D sai.

Ba lưu ý về encryption by default: | Lưu ý | Chi tiết | |---|---| | Chỉ áp cho tài nguyên MỚI | volume và snapshot cũ không đổi | | Áp theo TỪNG Region | phải bật ở mọi Region đang dùng | | Không ảnh hưởng tới việc chia sẻ AMI | nhưng AMI mã hoá cần chia sẻ cả khoá |

Và có thể ép bằng SCP cho toàn tổ chức:

{"Effect": "Deny",
 "Action": ["ec2:CreateVolume"],
 "Resource": "*",
 "Condition": {"Bool": {"ec2:Encrypted": "false"}}}

Nó chặn việc tạo volume không mã hoá ở mọi tài khoản — biện pháp mạnh hơn cả encryption by default.

Ba công cụ rà soát: | Công cụ | Việc | |---|---| | AWS Config rule encrypted-volumes | phát hiện volume chưa mã hoá | | AWS Config rule ec2-ebs-encryption-by-default | kiểm tra cấu hình Region | | Security Hub | tổng hợp finding |

Và lưu ý về hiệu năng: mã hoá EBS gần như không ảnh hưởng IOPS hay độ trễ — việc mã hoá diễn ra ở tầng hạ tầng với phần cứng chuyên dụng. Không có lý do về hiệu năng để không bật.

Và một lời khuyên: sau khi bật encryption by default, hãy rà soát và mã hoá dần các volume cũ. Encryption by default chỉ lo tài nguyên mới — volume đang chạy vẫn chưa mã hoá, và đó thường là phần dữ liệu quan trọng nhất.

Đáp án

A — Chuyển database sang Amazon Aurora và tạo cross-region read replica.

Vì sao đúng

Đề cho một con số quyết định: độ trễ sao chép DƯỚI 1 GIÂY giữa hai Region.

Và chỉ Aurora đạt được con số đó:

Aurora Global Database / cross-region replica:
    → độ trễ sao chép thường DƯỚI 1 GIÂY
    → dùng hạ tầng sao chép chuyên dụng của AWS
    → không đi qua tầng ứng dụng của engine

RDS MySQL cross-region read replica:
    → sao chép qua BINARY LOG của MySQL
    → độ trễ thường VÀI GIÂY tới hàng chục giây
    → phụ thuộc khoảng cách và lượng ghi

Vì sao Aurora nhanh hơn:

RDS MySQL replica:
    Primary ghi → sinh binary log → gửi qua mạng
        → replica ĐỌC LẠI và ÁP DỤNG từng câu lệnh
        → tốn CPU của replica, và có độ trễ

Aurora:
    Sao chép ở TẦNG LƯU TRỮ, không phải tầng SQL
        → gửi bản ghi redo log, không phải câu lệnh
        → replica không phải thực thi lại gì

Và Aurora Global Database còn cho thêm: | Lợi ích | Chi tiết | |---|---| | Tới 5 Region phụ | mỗi Region có thể có 16 replica đọc | | Thăng cấp Region phụ trong DƯỚI 1 PHÚT | phục hồi thảm hoạ | | Đọc cục bộ ở mỗi Region | độ trễ thấp cho người dùng địa phương | | Write forwarding | ghi từ Region phụ, chuyển tiếp về Region chính |

aws rds create-global-cluster --global-cluster-identifier cum-toan-cau   --source-db-cluster-identifier arn:aws:rds:us-east-1:...:cluster/cum-chinh

aws rds create-db-cluster --db-cluster-identifier cum-phu-ap-southeast   --global-cluster-identifier cum-toan-cau --engine aurora-mysql   --region ap-southeast-1

Và Aurora MySQL tương thích MySQL 5.6/5.7/8.0 — việc di chuyển từ RDS MySQL 5.6 khá thẳng thắn.

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

• **D. Tạo RDS for MySQL read replica ở Region thứ hai — đây là phương án gần nhất và thực sự giải quyết được vấn đề đọc, nhưng nó không đạt mốc dưới 1 giây: sao chép qua binary log của MySQL có độ trễ vài giây tới hàng chục giây, đặc biệt khi lượng ghi cao như đề mô tả.
• **B. Nâng cấp phiên bản MySQL — không thay đổi cơ chế sao chép: dù MySQL 8.0 có cải tiến (parallel replication), nó vẫn dựa trên binary log và không đạt được độ trễ dưới một giây xuyên Region.
• **C. Dùng ElastiCache để cải thiện hiệu năng — giải quyết vấn đề khác: cache giảm số truy vấn tới database, nhưng nó không sao chép dữ liệu sang Region khác. Và với "highly dynamic reads" như đề mô tả, tỷ lệ trúng cache sẽ thấp.

Ghi nhớ

Độ trễ sao chép của các lựa chọn: | Lựa chọn | Độ trễ | |---|---| | Aurora replica trong cùng Region | mili giây | | Aurora Global Database (xuyên Region) | thường DƯỚI 1 GIÂY | | RDS read replica cùng Region | giây | | RDS cross-region read replica | vài giây tới hàng chục giây |

Aurora và RDS — bảng phân biệt cốt lõi: | | Aurora | RDS MySQL | |---|---|---| | Cơ chế sao chép | tầng LƯU TRỮ chung | binary log của engine | | Độ trễ replica | mili giây | giây | | Số replica | 15 | 5 | | Failover | dưới 30 giây | 60–120 giây | | Lưu trữ tối đa | 128 TB, tự mở rộng | 64 TB, phải cấp phát | | Global Database | ✅ | ❌ (chỉ cross-region replica) | | Backtrack | ✅ tới 72 giờ | ❌ | | Cloning copy-on-write | ✅ | ❌ |

Ba đặc điểm của Aurora Global Database: | Đặc điểm | Chi tiết | |---|---| | Một Region chính (ghi) + tới 5 Region phụ (đọc) | | | Độ trễ sao chép dưới 1 giây | dùng hạ tầng chuyên dụng | | RPO 1 giây, RTO dưới 1 phút | cho phục hồi thảm hoạ |

Và write forwarding cho phép ghi từ Region phụ:

Ứng dụng ở Region phụ gửi câu lệnh ghi
    → Aurora chuyển tiếp về Region chính
    → ứng dụng không cần biết Region nào là chính
        ↓
    Đơn giản hoá mã ứng dụng đa Region rất nhiều

Ba bước di chuyển từ RDS MySQL sang Aurora: | Bước | Cách làm | |---|---| | ① Tạo Aurora read replica của RDS instance | AWS hỗ trợ trực tiếp | | ② Chờ replica bắt kịp | theo dõi metric replica lag | | ③ Promote Aurora replica thành cluster độc lập | thời gian ngừng chỉ vài phút |

aws rds create-db-cluster --db-cluster-identifier cum-aurora   --engine aurora-mysql --replication-source-identifier <arn-rds-instance>

Đây là cách di chuyển ít gián đoạn nhất — không cần DMS.

Ba loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster endpoint (writer) | instance chính | | Reader endpoint | tự cân bằng tải giữa các replica | | Custom endpoint | nhóm instance do bạn định nghĩa |

Và trong kiến trúc đa Region, mỗi Region có reader endpoint riêng — ứng dụng ở Region nào dùng endpoint của Region đó.

Ba lưu ý về chi phí Aurora Global Database: | Khoản | Chi tiết | |---|---| | Instance ở mỗi Region | trả tiền cho từng cluster | | Phí sao chép xuyên Region | theo số thao tác ghi được sao chép | | Lưu trữ tính riêng ở mỗi Region | dữ liệu được nhân bản |

Và Aurora I/O-Optimized đáng cân nhắc với tải đọc cao:

Không tính phí I/O, đổi lại giá compute và lưu trữ cao hơn ~25%
    → có lợi khi chi phí I/O vượt 25% tổng hoá đơn
    → và làm hoá đơn dự đoán được

Ba lưu ý khi chuyển từ MySQL 5.6: | Lưu ý | Chi tiết | |---|---| | MySQL 5.6 đã hết vòng đời hỗ trợ | nên nâng cấp bất kể có chuyển Aurora hay không | | Aurora MySQL hỗ trợ 5.7 và 8.0 | có thể cần nâng cấp trước | | Kiểm thử tương thích | một số tham số và tính năng khác nhau |

Và một lời khuyên: bên cạnh việc chuyển sang Aurora, hãy đo lại xem truy vấn đọc có thực sự cần dữ liệu mới nhất không. Rất nhiều truy vấn "highly dynamic" thực ra chấp nhận được dữ liệu cũ vài giây — và khi đó ElastiCache đặt trước replica sẽ giảm tải hơn nữa với chi phí thấp hơn nhiều.

Đáp án

D và E.

• D — Tạo chính sách co giãn mở rộng ECS SERVICE khi mức dùng BỘ NHỚ của service quá cao
• E — Tạo chính sách co giãn mở rộng ECS CLUSTER khi mức dùng CPU của service quá cao

Vì sao đúng

ECS cần co giãn ở hai tầng, và hai đáp án lo hai tầng đó: | Tầng | Cơ chế | Đáp án | |---|---|---| | SERVICE (số task) | Service Auto Scaling | D | | CLUSTER (số instance EC2) | Cluster Auto Scaling / capacity provider | E |

Vì sao cần cả hai:

Tầng SERVICE:
    tải tăng → thêm TASK
        ↓
    hết chỗ trên instance hiện có → task ở trạng thái PENDING
        ↓
Tầng CLUSTER:
    thấy task pending → THÊM INSTANCE EC2
    → task được đặt lên máy mới

Và metric của SERVICE là thứ đúng để co giãn:

ECSServiceAverageCPUUtilization
ECSServiceAverageMemoryUtilization
    → đo mức dùng tài nguyên của CÁC TASK trong service
    → phản ánh đúng nhu cầu của ứng dụng

aws application-autoscaling register-scalable-target   --service-namespace ecs   --resource-id service/cum-web/dich-vu-web   --scalable-dimension ecs:service:DesiredCount   --min-capacity 3 --max-capacity 50

aws application-autoscaling put-scaling-policy   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageMemoryUtilization"}}'

Và co giãn theo CẢ CPU LẪN BỘ NHỚ là thực hành tốt — ứng dụng có thể nghẽn ở một trong hai.

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

• **C. Mở rộng ECS cluster khi mức dùng CPU của TARGET GROUP quá cao — đây là phương án gần nhất và cấu trúc đúng, nhưng nó sai nguồn metric: target group KHÔNG có metric CPU. Target group có metric về số request, độ trễ, và số target khoẻ — CPU thuộc về task hoặc instance.
• **B. Mở rộng ECS service khi ALB đạt CPU cao — cùng lỗi: ALB là dịch vụ được quản lý, nó KHÔNG phơi metric CPU nào. AWS lo hạ tầng của ALB.
• **A. Mở rộng ECS service khi endpoint ALB không truy cập được — phản ứng quá muộn: khi ALB đã không phản hồi thì dịch vụ đã ngừng hoạt động. Co giãn phải xảy ra trước khi tới mức đó.

Ghi nhớ

Hai tầng co giãn của ECS trên EC2: | Tầng | Công cụ | Điều chỉnh | |---|---|---| | Service Auto Scaling | Application Auto Scaling | SỐ TASK | | Cluster Auto Scaling | capacity provider + ASG | SỐ INSTANCE EC2 |

Và với Fargate, tầng thứ hai biến mất:

ECS trên Fargate:
    → mỗi task tự có tài nguyên riêng
    → KHÔNG có instance nào để quản lý
    → chỉ cần Service Auto Scaling

Ba metric dựng sẵn cho ECS Service Auto Scaling: | Metric | Đo gì | |---|---| | ECSServiceAverageCPUUtilization | CPU trung bình của các task | | ECSServiceAverageMemoryUtilization | bộ nhớ trung bình của các task | | ALBRequestCountPerTarget | số request mỗi target — thường phản ánh tải tốt nhất |

ALBRequestCountPerTarget đáng cân nhắc cho ứng dụng web — số request tăng ngay lập tức, còn CPU cần thời gian mới lên theo.

Ba loại scaling policy: | Loại | Đặc điểm | |---|---| | Target tracking | giữ metric ở một giá trị — đơn giản nhất | | Step scaling | nhiều bậc theo mức vượt ngưỡng | | Scheduled scaling | theo giờ định trước |

AWS khuyến nghị target tracking cho hầu hết trường hợp.

Cấu hình Cluster Auto Scaling qua capacity provider:

aws ecs create-capacity-provider --name cp-ec2   --auto-scaling-group-provider '{
    "autoScalingGroupArn": "<arn-asg>",
    "managedScaling": {
      "status": "ENABLED",
      "targetCapacity": 80,
      "minimumScalingStepSize": 1,
      "maximumScalingStepSize": 10},
    "managedTerminationProtection": "ENABLED"}'

managedTerminationProtection là cấu hình quan trọng:

Bật lên:
    → ASG KHÔNG chấm dứt instance đang chạy task
    → tránh việc thu hẹp làm gián đoạn dịch vụ

Và targetCapacity quyết định mức lấp đầy của cụm:

targetCapacity = 80
    → ECS giữ cụm ở mức dùng khoảng 80% tài nguyên
    → chừa 20% để đặt task mới ngay khi cần

Ba lưu ý khi co giãn ECS: | Lưu ý | Chi tiết | |---|---| | Task phải khai cpu và memory | ECS dùng để tính mức sử dụng và đặt task | | Đặt minimumHealthyPercent phù hợp | tránh giảm dung lượng khi triển khai | | Instance warmup cho cluster scaling | instance mới cần thời gian sẵn sàng |

Và với Fargate, hãy cân nhắc Fargate Spot cho phần vượt mức nền:

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

Ba task luôn trên Fargate thường, phần vượt dùng Spot rẻ hơn tới 70%.

Ba cách giảm thời gian phản ứng khi tải tăng đột ngột: | Cách | Chi tiết | |---|---| | Giảm thời gian khởi động container | image nhỏ, ít bước khởi tạo | | Dùng metric phản ứng nhanh | request count thay vì CPU | | Predictive scaling hoặc scheduled scaling | mở rộng TRƯỚC nếu tải có mẫu lặp lại |

Và với "peak traffic" như đề mô tả, scheduled scaling rất phù hợp:

aws application-autoscaling put-scheduled-action   --service-namespace ecs --resource-id service/cum-web/dich-vu-web   --scalable-dimension ecs:service:DesiredCount   --scheduled-action-name tang-truoc-gio-cao-diem   --schedule "cron(45 7 * * ? *)"   --scalable-target-action MinCapacity=20,MaxCapacity=50

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | RunningTaskCount | số task đang chạy | | PendingTaskCount | task chờ chỗ — dấu hiệu thiếu dung lượng cụm | | TargetResponseTime (ALB) | trực tiếp phản ánh trải nghiệm người dùng |

PendingTaskCount khác 0 kéo dài là dấu hiệu rõ ràng rằng tầng cluster không theo kịp tầng service.

Và một lời khuyên: hãy đặt alarm cho TargetResponseTime của ALB bên cạnh các alarm co giãn. Nó là chỉ báo trực tiếp nhất của trải nghiệm người dùng — nếu nó tăng trong khi CPU và bộ nhớ đều bình thường, nút thắt nằm ở chỗ khác (database, dịch vụ phụ thuộc), và thêm task sẽ không giúp gì.

Đáp án

A — Dùng Amazon EFS với chế độ Provisioned Throughput và performance mode Max I/O; gắn EFS làm điểm mount trong task definition của cụm ECS.

Vì sao đúng

Đề nêu bốn dữ kiện, và chúng dẫn tới cấu hình rất cụ thể: | Dữ kiện | Kết luận | |---|---| | Hàng TRĂM ECS task chạy đồng thời | Max I/O — tối ưu cho số lượng client lớn | | Đọc ghi TẦN SUẤT CAO | cần thông lượng cao và ổn định | | Tổng dung lượng chỉ khoảng 10 TB | Bursting sẽ không đủ — cần Provisioned | | Cần hệ thống tệp CHIA SẺ cho container | EFS gắn được vào nhiều task |

Vì sao Bursting không đủ — đây là điểm mấu chốt:

Chế độ Bursting:
    mức cơ sở = 50 KB/giây cho MỖI GB lưu trữ
        ↓
    10 TB = 10.000 GB → mức cơ sở 500 MB/giây
    tín dụng burst tích luỹ theo dung lượng
        ↓
    Hàng trăm task đọc ghi liên tục
    → CẠN tín dụng
    → tụt về mức cơ sở → hiệu năng sụp đổ

Provisioned Throughput tách thông lượng khỏi dung lượng:

aws efs create-file-system   --throughput-mode provisioned --provisioned-throughput-in-mibps 500   --performance-mode maxIO --encrypted

Và Max I/O phù hợp khi có RẤT NHIỀU client: | | General Purpose | Max I/O | |---|---|---| | Độ trễ | thấp nhất | cao hơn một chút | | Thông lượng tổng | có giới hạn thao tác/giây | cao hơn nhiều | | Số client đồng thời | vừa phải | hàng trăm tới hàng nghìn |

Đề nói "hundreds of ECS tasks running most of the time" → Max I/O.

Gắn EFS vào ECS task definition:

{"volumes": [{
   "name": "du-lieu-chung",
   "efsVolumeConfiguration": {
     "fileSystemId": "fs-0abc123",
     "transitEncryption": "ENABLED",
     "authorizationConfig": {"accessPointId": "fsap-0abc123", "iam": "ENABLED"}}}],
 "containerDefinitions": [{
   "mountPoints": [{"sourceVolume": "du-lieu-chung", "containerPath": "/du-lieu"}]}]}

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

• **C. EFS với Bursting Throughput và performance mode General Purpose — đây là phương án gần nhất và là cấu hình mặc định, nhưng nó không đáp ứng được quy mô: Bursting cạn tín dụng với tải liên tục, và General Purpose có trần thao tác/giây thấp hơn Max I/O — không phù hợp cho hàng trăm client.
• **B. Tạo SMB file share qua FSx File Gateway — sai ngữ cảnh và giao thức: FSx File Gateway phục vụ truy cập từ trung tâm dữ liệu TẠI CHỖ. Ứng dụng ở đây chạy trên ECS trong AWS. Và SMB là giao thức Windows, còn container HPC thường chạy Linux.
• **D. Dùng DynamoDB với DAX làm điểm mount cho container — sai về mặt kỹ thuật: DynamoDB là cơ sở dữ liệu, KHÔNG mount làm hệ thống tệp được. Không có khái niệm "mount point" cho DynamoDB.

Ghi nhớ

Ba chế độ throughput của EFS — bảng cần thuộc: | Chế độ | Cách hoạt động | Phù hợp | |---|---|---| | Bursting (mặc định) | thông lượng theo DUNG LƯỢNG, có tín dụng | tải nhẹ, không liên tục | | Provisioned | khai trước mức cố định, ĐỘC LẬP với dung lượng | dữ liệu ít mà cần thông lượng cao ← câu này | | Elastic | tự điều chỉnh, trả theo lượng dùng thật | tải khó đoán — được khuyến nghị hiện nay |

Elastic throughput ra sau và thường là lựa chọn tốt nhất — nó không có khái niệm tín dụng và không phải khai trước con số nào. (Provisioned vẫn là đáp án đúng theo bộ đề và phù hợp khi biết rõ nhu cầu.)

Cách tính thông lượng của chế độ Bursting:

Mức cơ sở:  50 KB/giây mỗi GB lưu trữ
Mức burst:  100 MB/giây mỗi TB (tới 3 GB/giây)
Tín dụng:   tích luỹ khi dùng dưới mức cơ sở

Với 10 TB: mức cơ sở 500 MB/giây, burst tới 1 GB/giây — nhưng chỉ khi còn tín dụng.

Hai performance mode của EFS: | Mode | Đặc điểm | Đổi được sau | |---|---|---| | General Purpose | độ trễ thấp nhất, tới 35.000 thao tác/giây | ❌ KHÔNG | | Max I/O | thông lượng tổng cao hơn, độ trễ cao hơn chút | ❌ không |

Cả hai đều KHÔNG đổi được sau khi tạo file system — phải chọn đúng ngay từ đầu.

Ba lưu ý khi dùng EFS với ECS: | Lưu ý | Chi tiết | |---|---| | Mount target ở MỖI AZ có task | thiếu thì trả phí truyền chéo AZ | | Security group của mount target mở cổng 2049 | NFS | | Dùng EFS Access Point | ép POSIX user và thư mục gốc cho từng service |

EFS Access Point rất hữu ích cho nhiều task dùng chung file system:

Access point A → thư mục /service-a, uid 1001
Access point B → thư mục /service-b, uid 1002
    → mỗi service chỉ thấy phần của mình

Hai lớp lưu trữ của EFS: | Lớp | Chi phí | |---|---| | Standard | cao hơn | | Infrequent Access (IA) | rẻ hơn ~92%, có phí truy xuất |

Và lifecycle policy tự chuyển tệp ít dùng — đúng với vế "obsolete data will be archived" của đề:

aws efs put-lifecycle-configuration --file-system-id fs-0abc123   --lifecycle-policies TransitionToIA=AFTER_30_DAYS                        TransitionToPrimaryStorageClass=AFTER_1_ACCESS

Các dịch vụ lưu trữ chia sẻ — chọn đúng: | Dịch vụ | Giao thức | Thông lượng | |---|---|---| | EFS | NFS | GB/giây | | FSx for Lustre | Lustre | hàng TRĂM GB/giây | | FSx for Windows | SMB | tới 2 GB/giây | | EBS multi-attach | khối | chỉ 16 instance cùng AZ |

Và với HPC thật sự, FSx for Lustre mạnh hơn nhiều:

FSx for Lustre:
    ✓ thông lượng hàng trăm GB/giây
    ✓ liên kết trực tiếp với S3
    ✗ Single-AZ (Persistent) — kém chịu lỗi hơn EFS

(EFS là đáp án đúng theo bộ đề vì nó tích hợp trực tiếp với ECS task definition và trải nhiều AZ.)

Ba metric cần theo dõi cho EFS: | Metric | Ý nghĩa | |---|---| | BurstCreditBalance | giảm dần nghĩa là sắp cạn tín dụng | | PermittedThroughput | thông lượng đang được phép | | PercentIOLimit | với Max I/O, gần 100% nghĩa là chạm trần |

BurstCreditBalance là metric quan trọng nhất nếu dùng chế độ Bursting — nó cảnh báo trước khi hiệu năng sụp đổ.

Và một lời khuyên về chi phí: Provisioned Throughput tính phí theo mức bạn khai, dù có dùng hết hay không. Hãy đo thông lượng thật trong vài tuần bằng metric MeteredIOBytes rồi mới chốt con số — hoặc dùng Elastic throughput để không phải đoán.

Đáp án

C — Triển khai chatbot hội thoại bằng Amazon Lex; định nghĩa luồng hội thoại cho từng ý định của người dùng; tích hợp AWS Lambda làm code hook để thực hiện hành động.

Vì sao đúng

Đề nêu bốn yêu cầu, và Amazon Lex được thiết kế cho đúng tất cả: | Yêu cầu | Cơ chế | |---|---| | Giải pháp DỰA TRÊN VĂN BẢN, người dùng gõ vào khung chat | Lex hỗ trợ cả text lẫn voice | | AI phân tích Ý ĐỊNH của người dùng | intent recognition — chức năng lõi của Lex | | Trả lời hoặc THỰC HIỆN hành động định sẵn | Lambda code hook | | Không cần nhân viên can thiệp | chatbot tự phục vụ |

Ba khái niệm cốt lõi của Lex: | Khái niệm | Việc | |---|---| | Intent (ý định) | điều người dùng muốn làm — "đặt vé", "đổi lịch bay" | | Utterance (cách nói) | các cách diễn đạt khác nhau của cùng ý định | | Slot (thông tin cần) | dữ liệu Lex phải thu thập — điểm đi, điểm đến, ngày bay |

Ví dụ với nghiệp vụ hàng không:

Intent: DatVeMayBay
Utterances:
    "Tôi muốn đặt vé đi Đà Nẵng"
    "Đặt chuyến bay ngày mai"
    "Cho tôi mua vé"
Slots:
    DiemDi (bắt buộc)   → "Bạn bay từ đâu?"
    DiemDen (bắt buộc)  → "Bạn muốn đi đâu?"
    NgayBay (bắt buộc)  → "Ngày nào ạ?"

Lex tự hỏi thiếu slot nào — bạn không phải viết logic hội thoại.

Và Lambda code hook thực hiện hành động thật: | Loại hook | Khi nào gọi | |---|---| | Dialog code hook | sau mỗi lượt — kiểm tra dữ liệu, gợi ý | | Fulfillment code hook | khi đủ slot — THỰC HIỆN hành động (gọi API đặt vé) |

def lambda_handler(event, context):
    slots = event['sessionState']['intent']['slots']
    ma_dat_cho = goi_api_dat_ve(
        slots['DiemDi']['value']['interpretedValue'],
        slots['DiemDen']['value']['interpretedValue'],
        slots['NgayBay']['value']['interpretedValue'])
    return {'sessionState': {
        'dialogAction': {'type': 'Close'},
        'intent': {'name': 'DatVeMayBay', 'state': 'Fulfilled'}},
        'messages': [{'contentType': 'PlainText',
                      'content': f'Đã đặt vé, mã đặt chỗ: {ma_dat_cho}'}]}

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

• **A. Dùng Amazon Comprehend làm NLP cho chatbot rồi gọi Lambda theo ý định — đây là phương án gần nhất vì Comprehend thực sự là dịch vụ NLP, nhưng nó thiếu phần quan trọng nhất: Comprehend phân tích văn bản (cảm xúc, thực thể, chủ đề) nhưng KHÔNG quản lý luồng hội thoại. Bạn phải tự viết toàn bộ logic: theo dõi trạng thái, hỏi thông tin còn thiếu, xử lý ngắt quãng — đúng những thứ Lex làm sẵn.
• **B. Dùng Amazon Polly làm NLP với SSML — sai chức năng: Polly chuyển VĂN BẢN thành GIỌNG NÓI. Nó không hiểu ý định gì cả. Và đề nói rõ giải pháp phải dựa trên văn bản.
• **D. Dùng Amazon Rekognition để dựng chatbot — sai hoàn toàn: Rekognition phân tích ẢNH và VIDEO. Không liên quan tới hội thoại văn bản.

Ghi nhớ

Các dịch vụ AI được quản lý của AWS — bảng cần thuộc: | Dịch vụ | Việc | |---|---| | Lex | CHATBOT — nhận diện ý định, quản lý hội thoại ← câu này | | Comprehend | phân tích văn bản: cảm xúc, thực thể, chủ đề | | Polly | văn bản → giọng nói | | Transcribe | giọng nói → văn bản | | Translate | dịch giữa các ngôn ngữ | | Textract | trích xuất văn bản từ tài liệu quét | | Rekognition | ảnh và video | | Kendra | tìm kiếm doanh nghiệp | | Personalize | gợi ý |

Quy tắc nhận diện:

"chatbot", "conversational", "intent", "fulfillment" → Lex "sentiment", "entities" từ văn bản → Comprehend "text to speech" → Polly "search across documents" → Kendra

Ba khả năng khác của Amazon Lex: | Khả năng | Chi tiết | |---|---| | Hỗ trợ nhiều ngôn ngữ | tiếng Anh, Tây Ban Nha, Pháp, Nhật... | | Tích hợp nhiều kênh | web, di động, Slack, Facebook Messenger, Twilio | | Tích hợp Amazon Connect | dùng chung bot cho cả chat lẫn tổng đài |

Và Lex dùng chung công nghệ với Alexa — nên nó có khả năng hiểu ngôn ngữ tự nhiên khá tốt ngay từ đầu.

Ba tính năng nâng cao của Lex V2: | Tính năng | Việc | |---|---| | Slot elicitation thông minh | tự hỏi lại khi người dùng trả lời không rõ | | Confirmation prompt | xác nhận trước khi thực hiện hành động quan trọng | | Session attributes | giữ ngữ cảnh qua nhiều lượt hội thoại |

Confirmation prompt quan trọng với nghiệp vụ hàng không:

"Bạn muốn đặt vé Hà Nội → Đà Nẵng ngày 15/9, đúng không?"
    → tránh đặt nhầm do hiểu sai ý định

Ba loại slot type: | Loại | Ví dụ | |---|---| | Built-in | AMAZON.Date, AMAZON.Number, AMAZON.City | | Custom | danh sách sân bay, hạng vé | | Grammar slot type | biểu thức chính quy cho mã đặt chỗ |

Và Lex tích hợp với Amazon Connect cho trải nghiệm đa kênh:

Cùng một bot phục vụ:
    → khung chat trên website (text)
    → tổng đài điện thoại qua Connect (voice, dùng Transcribe + Polly)
    → ứng dụng di động

Ba lưu ý khi triển khai chatbot: | Lưu ý | Chi tiết | |---|---| | Luôn có đường THOÁT sang người thật | không phải mọi vấn đề bot giải quyết được | | Ghi log hội thoại để cải thiện | xem người dùng hỏi gì mà bot không hiểu | | Kiểm thử với cách nói đa dạng | thêm nhiều utterance cho mỗi intent |

Dòng đầu là nguyên tắc thiết kế quan trọng nhất — chatbot không xử lý được mà không có lối thoát sẽ khiến khách hàng bực bội hơn là không có chatbot.

Và bật conversation log để cải thiện liên tục:

aws lexv2-models update-bot-alias --bot-id <id> --bot-alias-id <alias-id>   --conversation-log-settings '{
    "textLogSettings": [{"enabled": true,
      "destination": {"cloudWatch": {
        "cloudWatchLogGroupArn": "<arn>", "logPrefix": "hoi-thoai/"}}}]}'

Phân tích log cho biết intent nào hay bị nhận nhầm và utterance nào cần bổ sung.

Ba biện pháp bảo mật cho chatbot xử lý dữ liệu khách hàng: | Biện pháp | Chi tiết | |---|---| | Che thông tin nhạy cảm trong log | Lex hỗ trợ đánh dấu slot là "obfuscated" | | Xác thực người dùng trước hành động quan trọng | không cho đổi vé mà chưa xác minh danh tính | | Giới hạn quyền của Lambda | chỉ gọi được API cần thiết |

Và một lời khuyên về triển khai: hãy bắt đầu với ba tới năm intent phổ biến nhất thay vì cố phủ hết mọi tình huống. Đo tỷ lệ giải quyết thành công, xem log để biết người dùng thực sự hỏi gì, rồi mở rộng dần — cách đó cho kết quả tốt hơn nhiều so với thiết kế toàn bộ luồng hội thoại từ đầu bằng phỏng đoán.

Đáp án

B và E.

• B — Tạo EventBridge rule bắt sự kiện của AWS Health hoặc ACM liên quan tới chứng chỉ sắp hết hạn; gửi thông báo tới SNS topic
• E — Tạo EventBridge rule chạy hằng ngày kiểm tra metric DaysToExpiry của mọi chứng chỉ ACM trong CloudWatch; gửi cảnh báo tới SNS khi còn 30 ngày

Vì sao đúng

Đề cần được thông báo TRƯỚC 30 NGÀY khi chứng chỉ SSL hết hạn — và ACM cung cấp hai cơ chế cho việc này: | Cơ chế | Nguồn | |---|---| | B — sự kiện tự động | ACM phát sự kiện qua AWS Health khi chứng chỉ sắp hết hạn | | E — metric có sẵn | DaysToExpiry trong namespace AWS/CertificateManager |

B — ACM phát sự kiện qua AWS Health:

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

Sự kiện này được phát ra ở các mốc 45, 30, 15, 7, 3 và 1 ngày trước khi hết hạn.

E — và metric DaysToExpiry cho phép đặt ngưỡng tuỳ ý:

aws cloudwatch put-metric-alarm --alarm-name chung-chi-sap-het-han   --metric-name DaysToExpiry --namespace AWS/CertificateManager   --statistic Minimum --period 86400 --threshold 30   --comparison-operator LessThanThreshold --evaluation-periods 1   --dimensions Name=CertificateArn,Value=<arn-chung-chi>   --alarm-actions <arn-sns-topic>

Và vì sao vẫn cần theo dõi dù ACM tự gia hạn:

ACM tự động gia hạn chứng chỉ nó cấp
    → NHƯNG việc gia hạn THẤT BẠI LẶNG LẼ nếu:
        ✗ bản ghi CNAME xác thực DNS bị xoá
        ✗ tên miền không còn trỏ về tài nguyên AWS
        ✗ chứng chỉ được NHẬP VÀO (imported) — ACM KHÔNG gia hạn

Đây là lý do thật của việc giám sát — không phải vì ACM hay quên, mà vì có những trường hợp nó không tự xử lý được.

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

• **A. Dùng AWS Config tạo rule THỦ CÔNG kiểm tra hết hạn chứng chỉ — đây là phương án gần nhất vì Config thực sự có rule liên quan, nhưng nó thừa và nói sai: AWS Config có sẵn managed rule acm-certificate-expiration-check, không cần "tạo thủ công". Và cách này nhiều công hơn so với dùng metric có sẵn.
• **C. Chuyển mọi chứng chỉ sang ACM Private Certificate Authority — đi ngược yêu cầu: chứng chỉ từ Private CA KHÔNG được trình duyệt công cộng tin cậy. Website sẽ báo lỗi bảo mật. Và Private CA tốn khoảng 400 USD mỗi tháng.
• **D. Dùng Trusted Advisor để kiểm tra chứng chỉ hết hạn trong 30 ngày — Trusted Advisor không có kiểm tra nào cho ACM certificate expiry. Nó có kiểm tra cho chứng chỉ trong IAM certificate store, không phải ACM.

Ghi nhớ

Hai cơ chế giám sát chứng chỉ ACM: | Cơ chế | Đặc điểm | |---|---| | Sự kiện ACM Certificate Approaching Expiration | tự động, ở các mốc định sẵn | | Metric DaysToExpiry trong CloudWatch | đặt ngưỡng tuỳ ý |

Cả hai đều có sẵn, không cần cấu hình gì thêm ở phía ACM.

Chứng chỉ ACM CẤP và chứng chỉ NHẬP VÀO — khác biệt quyết định: | | ACM cấp | Nhập vào ACM | |---|---|---| | Chi phí | miễn phí | phải mua từ CA | | Tự động gia hạn | ✅ | ❌ BẠN phải nhập lại thủ công | | Xuất khoá riêng | ❌ | ❌ | | Metric DaysToExpiry | ✅ | ✅ — và ở đây nó THIẾT YẾU |

Với chứng chỉ nhập vào, giám sát không phải tuỳ chọn mà là bắt buộc.

Ba lý do việc tự gia hạn của ACM thất bại: | Lý do | Cách phòng | |---|---| | Bản ghi CNAME xác thực bị xoá | giữ nguyên bản ghi đó vĩnh viễn | | Tên miền không còn dùng cho tài nguyên AWS | ACM chỉ gia hạn chứng chỉ đang được dùng | | Chứng chỉ được nhập vào | không có cơ chế tự gia hạn |

Dòng đầu là nguyên nhân phổ biến nhất — ai đó dọn dẹp DNS và xoá nhầm bản ghi trông có vẻ vô nghĩa.

Hai cách xác thực của ACM: | Cách | Đặc điểm | |---|---| | DNS validation | thêm CNAME MỘT LẦN → tự gia hạn VĨNH VIỄN | | Email validation | phải bấm link xác nhận mỗi lần gia hạn |

DNS validation là lựa chọn đúng gần như luôn luôn.

Giới hạn Region của ACM: | Dùng cho | Chứng chỉ phải ở | |---|---| | ALB, NLB, API Gateway regional | cùng Region với tài nguyên | | CloudFront | BẮT BUỘC us-east-1 | | API Gateway edge-optimized | BẮT BUỘC us-east-1 |

Và với nhiều Region như đề mô tả, phải đặt alarm ở TỪNG Region — metric CloudWatch mang tính Region.

Ba cách gom cảnh báo từ nhiều Region: | Cách | Chi tiết | |---|---| | CloudWatch cross-account cross-Region dashboard | xem tập trung | | SNS topic ở một Region, alarm ở nhiều Region trỏ về | đơn giản nhất | | EventBridge với event bus tập trung | linh hoạt nhất |

Ba AWS Config rule liên quan tới chứng chỉ: | Rule | Kiểm tra | |---|---| | acm-certificate-expiration-check | chứng chỉ sắp hết hạn (tham số daysToExpiration) | | acm-certificate-rsa-check | độ dài khoá RSA | | alb-http-to-https-redirection-check | ALB có chuyển hướng HTTPS không |

Config rule là lựa chọn hợp lệ thứ ba, chỉ là nhiều công hơn so với dùng metric có sẵn:

{"ConfigRuleName": "kiem-tra-chung-chi",
 "Source": {"Owner": "AWS", "SourceIdentifier": "ACM_CERTIFICATE_EXPIRATION_CHECK"},
 "InputParameters": "{\"daysToExpiration\":\"30\"}"}

Ba lưu ý về vòng đời chứng chỉ: | Lưu ý | Chi tiết | |---|---| | Ngành đang rút ngắn thời hạn chứng chỉ | hướng tới 47 ngày trong vài năm tới | | Chứng chỉ nhập vào sẽ phải nhập lại rất thường xuyên | thêm lý do dùng chứng chỉ ACM cấp | | Chứng chỉ hết hạn = website ngừng hoạt động | với người dùng, đó là sự cố toàn phần |

Và một cấu hình bảo vệ khác cho ALB: SNI với nhiều chứng chỉ.

aws elbv2 add-listener-certificates --listener-arn <arn>   --certificates CertificateArn=<arn-chung-chi-moi>

Thêm chứng chỉ mới trước khi chứng chỉ cũ hết hạn — ALB tự chọn chứng chỉ phù hợp, và bạn có thời gian chuyển đổi êm ái.

Và một lời khuyên vận hành: hãy đặt cảnh báo ở hai mốc — 45 ngày và 15 ngày. Mốc đầu để lên kế hoạch, mốc sau để báo động nếu chưa ai xử lý. Một cảnh báo duy nhất rất dễ bị bỏ qua trong luồng thông báo hằng ngày.