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

Đáp án

D — Phát triển ứng dụng bằng AWS AppSync và dùng tính năng custom domain dựng sẵn; gắn chứng chỉ SSL từ AWS Certificate Manager (ACM) để bật HTTPS.

Vì sao đúng

Đề nêu ba yêu cầu, và AppSync đáp ứng cả ba một cách trực tiếp: | Yêu cầu | Cơ chế | |---|---| | API GraphQL | AppSync là dịch vụ GraphQL được quản lý của AWS | | Không máy chủ, giảm chi phí vận hành | serverless hoàn toàn — trả tiền theo request | | Tên miền tuỳ chỉnh với HTTPS | tính năng custom domain dựng sẵn + ACM |

AppSync là dịch vụ GraphQL gốc của AWS:

Bạn khai schema GraphQL
    → AppSync tự dựng endpoint
    → resolver nối thẳng tới DynamoDB, Aurora, Lambda, OpenSearch
    → không có máy chủ nào để quản lý

Và tính năng custom domain là dựng sẵn từ 2022:

aws appsync create-domain-name   --domain-name api.congty.com   --certificate-arn <arn-chung-chi-acm>

aws appsync associate-api --domain-name api.congty.com --api-id <api-id>

Sau đó tạo alias record trong Route 53 trỏ tới appsyncDomainName.

Ba lợi ích của AppSync cho việc "tăng tốc phát triển" mà đề nêu: | Lợi ích | Chi tiết | |---|---| | Resolver gọi THẲNG nguồn dữ liệu | không cần viết Lambda cho thao tác CRUD cơ bản | | Subscription dựng sẵn | thời gian thực qua WebSocket, không phải tự dựng | | Nhiều chế độ xác thực | Cognito, IAM, OIDC, Lambda authorizer, API key |

Và mô hình chi phí phù hợp với "lower the monthly operating cost":

Trả tiền theo:
    số truy vấn và mutation
    số phút kết nối subscription
    → KHÔNG có chi phí nền khi không ai dùng

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

• **A. Dùng Elastic Beanstalk và Route 53 cho tên miền; cấu hình DNSSEC để bật HTTPS — đây là phương án gần nhất vì cũng dựng được API GraphQL, nhưng nó sai hai chỗ: Elastic Beanstalk chạy trên EC2 — không phải serverless, có chi phí nền liên tục. Và DNSSEC KHÔNG liên quan gì tới HTTPS — nó bảo vệ tính toàn vẹn của phản hồi DNS, còn HTTPS cần chứng chỉ TLS.
• **C. Triển khai GraphQL API thành Kubernetes pod trên Fargate và Outposts qua EKS Anywhere; dùng CloudFront với Origin Shield để bật HTTPS — phức tạp và sai chức năng: Outposts là phần cứng tại chỗ, không phải serverless. Và Origin Shield là lớp cache, không phải cơ chế HTTPS.
• **B. Host trên VMware Cloud on AWS; gắn tên miền qua Directory Service — sai hoàn toàn: VMware Cloud là hạ tầng máy ảo, ngược với serverless. Và Directory Service là dịch vụ thư mục (AD), nó không quản lý tên miền DNS công khai hay chứng chỉ.

Ghi nhớ

Ba cách dựng API trên AWS — bảng chọn: | Cách | Kiểu API | Serverless | |---|---|---| | AWS AppSync | GraphQL | ✅ | | API Gateway + Lambda | REST, HTTP, WebSocket | ✅ | | ALB + ECS/EC2 | tuỳ ứng dụng | ❌ |

Quy tắc nhận diện:

"GraphQL" → AppSync "REST API", "serverless" → API Gateway + Lambda

Hai loại resolver của AppSync: | Loại | Đặc điểm | |---|---| | Unit resolver | một thao tác trên một nguồn dữ liệu | | Pipeline resolver | chuỗi nhiều bước — gọi nhiều nguồn trong một request |

Các nguồn dữ liệu mà AppSync gọi TRỰC TIẾP: | Nguồn | Ghi chú | |---|---| | DynamoDB | không cần Lambda ở giữa — không có cold start | | Aurora Serverless (Data API) | trực tiếp | | OpenSearch | trực tiếp | | Lambda | khi cần logic phức tạp | | HTTP endpoint | gọi API bên ngoài | | EventBridge | phát sự kiện |

Việc gọi thẳng DynamoDB là lợi thế lớn về hiệu năng và chi phí — bỏ được cả một tầng Lambda.

Ba thao tác của GraphQL: | Thao tác | Việc | |---|---| | Query | đọc dữ liệu | | Mutation | ghi dữ liệu | | Subscription | nhận cập nhật THỜI GIAN THỰC qua WebSocket |

Subscription là tính năng rất mạnh cho cổng dịch vụ khách hàng:

Nhân viên hỗ trợ trả lời ticket
    → mutation ghi vào DynamoDB
    → subscription tự đẩy tới khách hàng đang mở trang
    → không cần polling

Năm chế độ xác thực của AppSync: | Chế độ | Phù hợp | |---|---| | Cognito User Pool | người dùng ứng dụng — có group và claim | | IAM | dịch vụ nội bộ | | OIDC | nhà cung cấp danh tính bên ngoài | | Lambda authorizer | logic tuỳ chỉnh | | API key | chỉ cho phát triển |

Và AppSync phân quyền tới TỪNG TRƯỜNG:

type KhachHang @aws_cognito_user_pools {
  ma: ID!
  hoTen: String!
  soDienThoai: String @aws_auth(cognito_groups: ["ho-tro-cap-cao"])
}

Quyền tối thiểu ở mức trường dữ liệu — thứ mà REST API phải tự dựng.

Ba yêu cầu cho custom domain của AppSync: | Yêu cầu | Chi tiết | |---|---| | Chứng chỉ ACM | phải ở us-east-1 (AppSync dùng CloudFront bên dưới) | | Alias record trong Route 53 | trỏ tới appsyncDomainName | | Chứng chỉ phải phủ tên miền | wildcard hoặc SAN |

Dòng đầu là chi tiết dễ sai — giống CloudFront, chứng chỉ phải cấp ở us-east-1.

Ba tính năng khác của AppSync: | Tính năng | Việc | |---|---| | Caching | giảm tải xuống nguồn dữ liệu | | Offline sync (Amplify DataStore) | ứng dụng di động dùng được khi mất mạng | | Merged API | gộp nhiều schema thành một API |

Ưu và nhược của GraphQL so với REST: | | GraphQL | REST | |---|---|---| | Số request | một request lấy đủ dữ liệu | nhiều endpoint | | Over-fetching | client khai đúng trường cần | trả cả object | | Thời gian thực | subscription dựng sẵn | phải tự dựng | | Cache HTTP | khó hơn | dễ — theo URL |

Nhược điểm cần lưu ý: một truy vấn GraphQL lồng sâu có thể gây tải lớn bất ngờ — hãy đặt giới hạn độ sâu và độ phức tạp của truy vấn.

Và một lưu ý về chi phí: AppSync tính phí theo số thao tác (~4 USD mỗi triệu) và số phút kết nối subscription. Với cổng dịch vụ khách hàng có nhiều người mở trang cùng lúc, phần subscription có thể chiếm tỷ trọng đáng kể — hãy đóng subscription khi người dùng rời trang.

Đáp án

A — Tạo Web ACL rule trong AWS WAF chặn quốc gia đã nêu và gắn rule đó vào các Application Load Balancer.

Vì sao đúng

Đề cần chặn truy cập từ một quốc gia cụ thể — và WAF có sẵn geo match condition cho đúng việc đó.

Cách geo match hoạt động:

WAF tra địa chỉ IP nguồn trong cơ sở dữ liệu GeoIP
    → xác định quốc gia
    → so với danh sách mã quốc gia trong rule
    → khớp → Block

{"Name": "chan-quoc-gia-bi-cam",
 "Priority": 1,
 "Statement": {"GeoMatchStatement": {"CountryCodes": ["XX"]}},
 "Action": {"Block": {}},
 "VisibilityConfig": {"SampledRequestsEnabled": true,
                      "CloudWatchMetricsEnabled": true,
                      "MetricName": "chan-quoc-gia"}}

Và gắn vào từng ALB ở mỗi Region:

aws wafv2 associate-web-acl   --web-acl-arn <arn-web-acl>   --resource-arn <arn-alb>

Vì sao WAF là công cụ đúng thay vì NACL:

Chặn theo QUỐC GIA nghĩa là phải biết IP nào thuộc nước nào
    → danh sách đó gồm HÀNG NGHÌN dải CIDR
    → và THAY ĐỔI liên tục khi các nhà mạng cấp phát lại
        ↓
WAF: AWS duy trì cơ sở dữ liệu GeoIP, tự cập nhật
NACL: bạn phải tự nhập và tự cập nhật hàng nghìn dải

Và WAF gắn được vào nhiều ALB ở nhiều Region — đúng với kiến trúc đa Region mà đề mô tả. (Web ACL mang tính Region, nên cần tạo ở mỗi Region, nhưng cấu hình giống nhau và quản lý được tập trung bằng AWS Firewall Manager.)

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

• **D. Cập nhật NACL của các subnet chứa ALB để từ chối mọi IP từ quốc gia đó — đây là phương án gần nhất vì NACL có rule Deny, nhưng nó không khả thi: NACL chỉ lọc theo CIDR và giới hạn 20 rule (tối đa 40). Danh sách IP của một quốc gia gồm hàng nghìn dải — không nhét vừa, và không có cách nào cập nhật tự động.
• **C. Cập nhật NACL của các subnet chứa EC2 instance — cùng vấn đề, và còn sai vị trí: lưu lượng tới EC2 đi qua ALB, nên IP nguồn mà instance thấy là IP của ALB, không phải của người dùng cuối. Rule sẽ không khớp gì cả.
• **B. Chuyển lưu lượng RA sang AWS Network Firewall với stateful domain list rule — sai chiều và sai cơ chế: đề cần chặn lưu lượng ĐI VÀO từ một quốc gia; cấu hình này lọc lưu lượng ĐI RA theo tên miền. Hai thứ hoàn toàn khác nhau.

Ghi nhớ

Bốn lớp kiểm soát mạng — chọn đúng công cụ: | Lớp | Lọc theo | Chặn theo quốc gia | |---|---|---| | Security group | IP, cổng, SG khác | ❌ chỉ có Allow | | Network ACL | CIDR | ❌ không thực tế | | AWS WAF | tầng 7: quốc gia, IP set, chuỗi, tốc độ | ✅ | | AWS Network Firewall | tên miền, chữ ký, IP | ✅ nhưng nặng hơn |

Quy tắc: chặn theo quốc gia → WAF geo match, hoặc CloudFront geo restriction.

Và CloudFront có tính năng geo restriction riêng, đơn giản hơn:

CloudFront → Restrictions → Geographic restrictions
    → Whitelist hoặc Blacklist theo quốc gia
    → MIỄN PHÍ, không cần WAF

Nếu ứng dụng đứng sau CloudFront, đây là cách rẻ nhất. Với ALB trực tiếp như đề mô tả thì phải dùng WAF.

Các loại statement của WAF rule: | Statement | Lọc theo | |---|---| | GeoMatchStatement | quốc gia (mã ISO hai chữ) ← câu này | | IPSetReferenceStatement | danh sách IP hoặc CIDR (tới 10.000) | | RateBasedStatement | số request mỗi 5 phút từ một IP | | ByteMatchStatement | chuỗi trong request | | SqliMatchStatement / XssMatchStatement | tấn công SQL injection, XSS | | LabelMatchStatement | nhãn do rule khác gắn |

Và nếu cần ngoại lệ (chặn nước X nhưng cho phép vài IP), dùng thứ tự ưu tiên:

Priority 1: Allow IP set (danh sách ngoại lệ)   ← xét TRƯỚC
Priority 2: Block geo match (quốc gia X)

WAF dừng ở rule khớp đầu tiên có action kết thúc — đặt ngược thứ tự là rule Allow không bao giờ được xét.

Ba lưu ý về geo match: | Lưu ý | Chi tiết | |---|---| | Dựa trên cơ sở dữ liệu GeoIP | không chính xác 100% | | VPN và proxy vượt qua được | không phải biện pháp chống kẻ tấn công có chủ ý | | Cần header X-Forwarded-For đúng nếu có proxy phía trước | nếu không sẽ nhận nhầm quốc gia |

Dòng giữa quan trọng cho bối cảnh của đề: chặn theo quốc gia phù hợp cho tuân thủ pháp lý — chứng minh rằng công ty đã thực hiện biện pháp hợp lý để không phục vụ nước đó. Nó không ngăn được người cố tình dùng VPN.

Ba nơi gắn được AWS WAF: | Nơi | Scope | |---|---| | Application Load Balancer | REGIONAL ← đề này | | API Gateway, AppSync, Cognito | REGIONAL | | CloudFront | CLOUDFRONT — web ACL phải tạo ở us-east-1 |

Và với kiến trúc đa Region như đề mô tả, AWS Firewall Manager đáng dùng:

Firewall Manager:
    → định nghĩa chính sách WAF MỘT LẦN
    → tự áp cho mọi ALB ở mọi Region, mọi tài khoản
    → tự áp cho tài nguyên MỚI tạo
    → yêu cầu: AWS Organizations

Nó giải quyết đúng vấn đề "nhiều Region, nhiều ALB, phải nhất quán".

Ba nhóm managed rule nên cân nhắc bổ sung: | Nhóm | Chống | |---|---| | AWSManagedRulesCommonRuleSet | tấn công web phổ biến (OWASP) | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu, botnet | | AWSManagedRulesKnownBadInputsRuleSet | payload khai thác đã biết |

Và triển khai an toàn: dùng action Count trước.

Đặt rule ở chế độ Count vài ngày
    → xem log để biết nó sẽ chặn những request nào
    → xác nhận không chặn nhầm khách hàng thật
    → rồi mới chuyển sang Block

Và một lời khuyên về tuân thủ: hãy bật WAF logging vào Kinesis Firehose → S3. Khi cơ quan quản lý hỏi "công ty đã chặn nước đó từ khi nào và có hiệu quả không", log là bằng chứng cụ thể duy nhất.

Đáp án

B và D.

• D — Viết Lambda function LÀM MỚI (refresh) các kiểm tra Service Limits của Trusted Advisor, chạy mỗi 24 giờ
• B — Bắt sự kiện bằng EventBridge và dùng SNS topic làm đích gửi thông báo

Vì sao đúng

Đề cần theo dõi mức dùng tài nguyên để không chạm hạn mức bất ngờ — và Trusted Advisor có sẵn kiểm tra cho việc đó.

Vì sao phải LÀM MỚI (refresh) chứ không chỉ đọc:

Kết quả kiểm tra của Trusted Advisor được CACHE
    → không tự cập nhật liên tục
    → đọc mà không refresh sẽ nhận dữ liệu cũ
        ↓
Lambda gọi RefreshTrustedAdvisorCheck mỗi 24 giờ
    → buộc Trusted Advisor đánh giá lại

support = boto3.client('support', region_name='us-east-1')
support.refresh_trusted_advisor_check(checkId='eW7HH0l7J9')  # Service Limits

Và việc refresh phát ra sự kiện mà EventBridge bắt được:

{"source": ["aws.trustedadvisor"],
 "detail-type": ["Trusted Advisor Check Item Refresh Notification"],
 "detail": {"status": ["WARN", "ERROR"],
            "check-name": ["Service Limits"]}}

Luồng hoàn chỉnh:

EventBridge scheduled rule (mỗi 24 giờ)
    → Lambda gọi RefreshTrustedAdvisorCheck
        ↓
Trusted Advisor đánh giá lại và phát sự kiện
        ↓
EventBridge rule bắt sự kiện có status WARN hoặc ERROR
    → SNS topic → email đội vận hành

Trusted Advisor cảnh báo khi mức dùng đạt 80% hạn mức — đủ thời gian để yêu cầu tăng.

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

• **C. Truy vấn Service Limits mỗi 24 giờ bằng DescribeTrustedAdvisorChecks với gói hỗ trợ Developer — đây là phương án gần nhất và API đó có thật, nhưng nó sai ở hai chỗ: AWS Support API yêu cầu gói Business, Enterprise On-Ramp hoặc Enterprise — gói Developer không truy cập được. Và DescribeTrustedAdvisorChecks chỉ liệt kê danh sách các kiểm tra, không trả về kết quả; cái trả kết quả là DescribeTrustedAdvisorCheckResult.
• **A. Chỉ tạo SNS topic và cấu hình làm đích nhận thông báo — thiếu hẳn phần phát hiện: một topic SNS đứng một mình không theo dõi gì cả. Nó chỉ là kênh gửi.
• **E. Dùng AWS managed rule của AWS Config để giám sát hạn mức dịch vụ — không có managed rule như vậy: AWS Config đánh giá cấu hình tài nguyên so với quy tắc, nó không theo dõi hạn mức dịch vụ.

Ghi nhớ

Ba công cụ theo dõi hạn mức — bảng cần thuộc: | Công cụ | Đặc điểm | |---|---| | Service Quotas | dịch vụ CHUYÊN DỤNG cho hạn mức — xem, yêu cầu tăng, đặt alarm | | Trusted Advisor (Service Limits check) | kiểm tra một số hạn mức phổ biến, cảnh báo ở 80% | | CloudWatch usage metric | metric AWS/Usage cho một số dịch vụ |

Và Service Quotas thực ra là công cụ hiện đại hơn cho việc này:

aws service-quotas put-service-quota-increase-request-into-template   --service-code ec2 --quota-code L-1216C47A --desired-value 100   --aws-region ap-southeast-1

# Đặt CloudWatch alarm cho hạn mức
aws cloudwatch put-metric-alarm --alarm-name canh-bao-han-muc-ec2   --metric-name ResourceCount --namespace AWS/Usage   --statistic Maximum --period 300 --threshold 80   --comparison-operator GreaterThanThreshold   --dimensions Name=Service,Value=EC2 Name=Type,Value=Resource                Name=Resource,Value=vCPU Name=Class,Value=Standard/OnDemand

(Trusted Advisor vẫn là đáp án đúng theo bộ đề; Service Quotas ra sau và bao phủ nhiều hạn mức hơn.)

Các gói hỗ trợ của AWS và quyền truy cập Trusted Advisor: | Gói | Trusted Advisor | Support API | |---|---|---| | Basic (miễn phí) | 7 kiểm tra cơ bản | ❌ | | Developer | 7 kiểm tra cơ bản | ❌ | | Business | ĐẦY ĐỦ (hơn 100 kiểm tra) | ✅ | | Enterprise On-Ramp / Enterprise | đầy đủ + tư vấn viên | ✅ |

Dòng "Developer" là điểm loại bỏ phương án C.

Bảy kiểm tra miễn phí có ở mọi gói:

Service Limits              ← có sẵn cho mọi gói
Security Groups – Specific Ports Unrestricted
IAM Use
MFA on Root Account
EBS Public Snapshots
RDS Public Snapshots
S3 Bucket Permissions

Năm hạng mục kiểm tra của Trusted Advisor: | Hạng mục | Nội dung | |---|---| | Cost Optimization | tài nguyên nhàn rỗi, RI chưa dùng hết | | Performance | cấu hình dưới mức tối ưu | | Security | cấu hình rủi ro | | Fault Tolerance | thiếu dự phòng | | Service Limits | mức dùng so với hạn mức ← câu này |

Hai loại hạn mức của AWS: | Loại | Đặc điểm | |---|---| | Soft limit (adjustable) | yêu cầu tăng được qua Service Quotas hoặc Support | | Hard limit | KHÔNG tăng được — ràng buộc kiến trúc |

Ví dụ hard limit cần biết:

5 VPC mỗi Region (soft, tăng được)
200 subnet mỗi VPC (soft)
5 Elastic IP mỗi Region (soft)
CIDR của VPC: /16 tới /28 (HARD)
20 rule mỗi NACL, tối đa 40 (HARD ở mức 40)

Ba lưu ý khi quản lý hạn mức trong tổ chức nhiều đội: | Lưu ý | Chi tiết | |---|---| | Hạn mức tính theo TÀI KHOẢN và REGION | tách tài khoản là tách hạn mức | | Yêu cầu tăng mất từ vài giờ tới vài ngày | đừng đợi tới lúc chạm trần | | Quota template áp cho tài khoản MỚI | tự động với AWS Organizations |

Dòng cuối rất hữu ích cho tình huống của đề — nhiều phòng ban tự tạo tài nguyên:

aws service-quotas associate-service-quota-template

Mọi tài khoản mới trong tổ chức tự nhận mức hạn mức đã định — không phải yêu cầu tăng cho từng tài khoản.

Và mẫu kiến trúc chung cho mọi loại cảnh báo trên AWS:

Nguồn phát hiện → EventBridge → SNS → người nhận
                              → Lambda → tự khắc phục

Và một lời khuyên vận hành: hãy đặt cảnh báo ở mức 70–80% hạn mức, không phải 95%. Yêu cầu tăng hạn mức cần AWS xử lý, và với một số hạn mức lớn có thể mất vài ngày — biết trước là điều kiện để không bị chặn giữa lúc cần mở rộng gấp.

Đáp án

A — Dùng AWS Batch để quản lý việc thực thi phần mềm.

Vì sao đúng

Đề nêu ba yêu cầu, và AWS Batch được thiết kế cho đúng loại công việc này: | Yêu cầu | Cơ chế | |---|---| | Chạy nhiều mô phỏng SONG SONG | Batch điều phối hàng nghìn job đồng thời | | Cần nhiều tài nguyên (32 vCPU, 256 GiB) | chọn loại instance phù hợp, không giới hạn 15 phút | | ÍT CÔNG VẬN HÀNH NHẤT | Batch tự cấp phát và thu hồi tài nguyên |

AWS Batch lo toàn bộ phần điều phối:

Bạn nộp job vào hàng đợi
    ↓
Batch tự:
    ✓ chọn loại instance phù hợp với yêu cầu tài nguyên của job
    ✓ khởi chạy instance khi có job
    ✓ đặt job lên instance
    ✓ TẮT instance khi hết job
    ✓ thử lại job thất bại

Và không phải viết logic điều phối nào:

aws batch submit-job --job-name mo-phong-001   --job-queue hang-doi-mo-phong   --job-definition dinh-nghia-mo-phong   --array-properties size=100

array-properties chạy 100 mô phỏng song song bằng MỘT lệnh — đúng mục tiêu "run them in parallel" của đề.

Và Batch hỗ trợ Spot Instance sẵn:

Compute environment với Spot:
    → tiết kiệm tới 90%
    → Batch tự giao lại job khi instance bị thu hồi

Ba thành phần của AWS Batch: | Thành phần | Việc | |---|---| | Compute environment | loại instance, số vCPU tối đa, On-Demand hay Spot | | Job queue | hàng đợi công việc, có độ ưu tiên | | Job definition | image container, tài nguyên yêu cầu, biến môi trường |

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

• **B. Dùng EC2 Spot Instance để chạy mô phỏng — đây là phương án gần nhất và Batch cũng dùng Spot bên dưới, nhưng nó nhiều công hơn hẳn: bạn phải tự viết logic phân phối job, tự xử lý instance bị thu hồi, tự khởi chạy và tắt máy, tự theo dõi tiến độ. Đề hỏi cách "LEAST operational overhead".
• **C. Dùng Lambda xử lý các tác vụ mô phỏng song song — vượt giới hạn kỹ thuật: Lambda tối đa 10 GB bộ nhớ và 15 phút. Đề nói phần mềm cần 256 GiB bộ nhớ và chạy vài giờ — cả hai đều vượt xa khả năng của Lambda.
• **D. Chạy mô phỏng bằng AWS Fargate — cũng vượt giới hạn: Fargate tối đa 16 vCPU và 120 GB bộ nhớ. Đề cần 32 vCPU và 256 GiB. Và Fargate không có cơ chế hàng đợi job như Batch.

Ghi nhớ

Giới hạn tài nguyên của các dịch vụ compute — bảng cần thuộc: | Dịch vụ | vCPU tối đa | Bộ nhớ tối đa | Thời gian chạy | |---|---|---|---| | Lambda | ~6 (theo bộ nhớ) | 10 GB | 15 phút | | Fargate | 16 | 120 GB | không giới hạn | | EC2 / AWS Batch trên EC2 | 192+ | 24 TB (x1e, u-series) | không giới hạn |

Đề cần 32 vCPU và 256 GiB → chỉ EC2 đáp ứng được.

Chọn dịch vụ compute theo đặc điểm công việc: | Đặc điểm | Dịch vụ | |---|---| | Ngắn (dưới 15 phút), theo sự kiện | Lambda | | Chạy lâu, dịch vụ thường trực | Fargate hoặc ECS/EKS | | Xử lý LÔ, hàng nghìn job, tài nguyên lớn | AWS Batch ← câu này | | HPC chặt chẽ với MPI | AWS ParallelCluster + EFA | | Cần GPU hoặc phần cứng đặc biệt | EC2 |

AWS Batch và AWS ParallelCluster — phân biệt: | | AWS Batch | AWS ParallelCluster | |---|---|---| | Mô hình | job độc lập, song song "embarrassingly parallel" | HPC chặt chẽ, các node GIAO TIẾP với nhau | | Bộ lập lịch | Batch tự lo | Slurm | | Công vận hành | rất thấp | cao hơn | | Phù hợp | mô phỏng độc lập, xử lý ảnh, render | CFD, mô phỏng phân tử với MPI |

Với "chạy nhiều mô phỏng song song" — mỗi mô phỏng độc lập — Batch là lựa chọn đúng. Nếu một mô phỏng cần chia nhỏ và các phần phải trao đổi dữ liệu liên tục thì mới cần ParallelCluster với EFA.

Ba loại compute environment của Batch: | Loại | Đặc điểm | |---|---| | Managed trên EC2 | Batch tự chọn loại instance và mở rộng | | Managed trên Fargate | không quản lý máy, nhưng giới hạn 16 vCPU | | Unmanaged | bạn tự quản lý cụm ECS |

Và BEST_FIT_PROGRESSIVE là chiến lược phân bổ đáng dùng:

BEST_FIT:              chọn loại instance rẻ nhất vừa đủ — có thể chờ lâu
BEST_FIT_PROGRESSIVE:  mở rộng sang loại khác nếu loại tốt nhất không có sẵn
SPOT_CAPACITY_OPTIMIZED: chọn pool Spot ít bị thu hồi nhất

Ba tính năng của Batch cho mô phỏng khoa học: | Tính năng | Việc | |---|---| | Array job | chạy N bản sao của cùng job với chỉ số khác nhau | | Job dependency | job B chỉ chạy sau khi job A xong | | Multi-node parallel job | một job chạy trên nhiều instance (có hỗ trợ MPI) |

Array job là cách gọn nhất để quét tham số:

# Mỗi job đọc biến môi trường AWS_BATCH_JOB_ARRAY_INDEX
# → chạy mô phỏng với bộ tham số thứ N
chi_so = int(os.environ['AWS_BATCH_JOB_ARRAY_INDEX'])
tham_so = danh_sach_tham_so[chi_so]

Đúng nhu cầu "experiment with more tunable parameters" mà đề nêu.

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Phần mềm phải đóng gói thành container | Docker image trong ECR | | Dữ liệu vào/ra nên ở S3 hoặc FSx for Lustre | không lưu trên instance | | Đặt maxvCpus hợp lý | tránh mở rộng ngoài tầm kiểm soát chi phí |

Và FSx for Lustre đáng cân nhắc cho mô phỏng dữ liệu lớn:

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
    → nhiều node đọc song song

Mô phỏng thường nghẽn ở I/O chứ không phải CPU — đây thường là cải thiện lớn hơn cả việc thêm máy.

Và một lời khuyên về chi phí: đặt compute environment dùng Spot với SPOT_CAPACITY_OPTIMIZED cho phần lớn công việc, và giữ một environment On-Demand nhỏ cho các job cần chắc chắn hoàn thành. Batch tự chuyển job sang environment còn dung lượng, nên bạn được cả tiết kiệm lẫn độ tin cậy.

Đáp án

A và B.

• A — Cài Kubernetes Metrics Server vào cụm EKS và bật Horizontal Pod Autoscaling (HPA)
• B — Thiết lập Karpenter để tự điều chỉnh số node của cụm

Vì sao đúng

Kubernetes cần co giãn ở hai tầng, và hai đáp án lo hai tầng đó:

Tầng POD (HPA):
    tải tăng → tăng SỐ POD
        ↓ hết chỗ trên node → pod ở trạng thái Pending
Tầng NODE (Karpenter):
    thấy pod Pending → THÊM NODE
    node trống → GỠ node đi

Metrics Server là điều kiện tiên quyết của HPA:

Không có Metrics Server:
    → HPA không biết CPU và bộ nhớ của pod
    → không tăng pod
    → không có pod Pending
    → tầng node KHÔNG BAO GIỜ được kích hoạt

Và Karpenter được chọn vì "LEAST operational overhead": | | Cluster Autoscaler | Karpenter | |---|---|---| | Cơ chế | điều chỉnh Auto Scaling group | gọi THẲNG API EC2 | | Cần định nghĩa node group trước | ✅ phải khai sẵn từng nhóm | ❌ không cần | | Tốc độ phản ứng | vài phút | vài chục giây | | Chọn loại instance | bị bó trong node group đã định | TỰ chọn loại phù hợp nhất với pod đang chờ | | Hợp nhất node để tiết kiệm | hạn chế | ✅ tự dồn pod và tắt node thừa |

Việc không phải định nghĩa node group là khác biệt lớn nhất về công vận hành — với Cluster Autoscaler, mỗi khi có loại workload mới bạn phải tạo node group mới.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: mac-dinh
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

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

• **E. Bật Cluster Autoscaler cho EKS để tự quản lý số node — đâ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 vận hành hơn Karpenter: phải định nghĩa và bảo trì node group cho từng loại workload, phải gắn tag đúng, và phản ứng chậm hơn. Đề hỏi cách "LEAST amount of operational overhead".
• **C. Cài Metrics Server và bật Vertical Pod Autoscaler (VPA) — sai chiều co giãn: VPA điều chỉnh tài nguyên yêu cầu của MỖI pod (cho pod nhiều CPU hơn), nó không tăng SỐ LƯỢNG pod. Và VPA thường khởi động lại pod để áp giá trị mới — gây gián đoạn.
• **D. Dùng CloudWatch Alarm để kích hoạt co giãn — alarm chỉ QUAN SÁT, không HÀNH ĐỘNG: nó thông báo khi tải cao nhưng không thêm pod hay node nào.

Ghi nhớ

Ba tầng tự co giãn trong Kubernetes: | Tầng | Công cụ | Điều chỉnh | |---|---|---| | Pod ngang | Horizontal Pod Autoscaler | SỐ LƯỢNG pod | | Pod dọc | Vertical Pod Autoscaler | tài nguyên mỗi pod | | Node | Karpenter hoặc Cluster Autoscaler | SỐ LƯỢNG node |

HPA và tầng node phải dùng CÙNG NHAU — thiếu một cái là hệ thống không co giãn được đầy đủ.

Điều kiện bắt buộc cho HPA: pod phải khai resources.requests.

resources:
  requests: {cpu: "250m", memory: "512Mi"}
  limits:   {cpu: "500m", memory: "1Gi"}

Không khai requests thì HPA không tính được phần trăm sử dụng — đây là lỗi cấu hình phổ biến nhất khiến HPA "không làm gì cả".

Cấu hình HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: {type: Utilization, averageUtilization: 70}

Ba ưu điểm khác của Karpenter: | Ưu điểm | Chi tiết | |---|---| | Tự chọn kích thước instance vừa vặn | giảm lãng phí — không phải dùng node to cho pod nhỏ | | Hỗ trợ Spot tự nhiên | tự xử lý cảnh báo thu hồi và thay node | | Consolidation | tự dồn pod lại và tắt node dùng chưa hết |

Consolidation là tính năng tiết kiệm chi phí đáng kể — sau đợt cao điểm, Karpenter tự gom pod về ít node hơn thay vì để nhiều node chạy nửa tải.

Và có một cách bỏ qua hoàn toàn tầng node: EKS trên Fargate.

Không có node nào để quản lý
    → mỗi pod tự có tài nguyên riêng
    → chỉ cần HPA

Đổi lại: không hỗ trợ DaemonSet, không dùng được GPU, chỉ EFS cho lưu trữ bền vững, và đắt hơn tính theo vCPU-giờ.

Ba lưu ý khi triển khai Karpenter: | Lưu ý | Chi tiết | |---|---| | Cần IAM role qua IRSA | quyền gọi API EC2 | | Cần một node group nhỏ để chạy CHÍNH Karpenter | hoặc chạy trên Fargate | | Subnet và security group phải gắn tag | karpenter.sh/discovery |

Dòng giữa là chi tiết triển khai quan trọng: Karpenter không tự tạo node cho chính nó — cần một nhóm node nhỏ hoặc Fargate profile để nó chạy trên đó.

Ba cách giảm chi phí cụm EKS có tải theo mùa: | Cách | Lợi ích | |---|---| | Trộn Spot và On-Demand | tới 90% cho phần chịu được gián đoạn | | Karpenter consolidation | tắt node dùng chưa hết | | Savings Plan cho mức nền | cam kết phần chạy quanh năm |

Với thương mại điện tử có đỉnh dịp lễ, mô hình đúng là:

Mức nền quanh năm → On-Demand kèm Savings Plan
Phần tăng dịp lễ  → Spot qua Karpenter

Ba metric nên dùng cho HPA của ứng dụng web: | Metric | Phù hợp | |---|---| | CPU | mặc định, dễ dùng | | Số request mỗi pod (qua Prometheus Adapter) | phản ánh tải thật tốt hơn | | Độ dài hàng đợi | ứng dụng xử lý bất đồng bộ |

Và một lời khuyên chuẩn bị cho dịp cao điểm: hãy chạy thử tải trước vài tuần để đo xem HPA và Karpenter phản ứng nhanh đến mức nào. Nếu thời gian khởi động pod cộng thời gian tạo node vượt quá tốc độ tăng tải, hãy cân nhắc mở rộng trước theo lịch cho những ngày biết chắc sẽ đông.

Đáp án

C — Dùng On-Demand Capacity Reservations, cung cấp dung lượng tính toán luôn sẵn có theo lịch định kỳ đã khai.

Vì sao đúng

Đề nêu ba yêu cầu, và On-Demand Capacity Reservation (ODCR) là cơ chế duy nhất đáp ứng yêu cầu cốt lõi: | Yêu cầu | Cơ chế | |---|---| | ĐẶT TRƯỚC dung lượng ở một Availability Zone CỤ THỂ | ODCR là cơ chế duy nhất làm được | | Xử lý không được chậm trễ hay gián đoạn | dung lượng được đảm bảo sẵn | | Tải ổn định, chạy 10 giờ đêm tới 3 giờ sáng | chỉ cần dung lượng trong khung giờ đó |

Điểm mấu chốt: chỉ ODCR và zonal RI mới THỰC SỰ giữ chỗ.

On-Demand Capacity Reservation:
    → GIỮ CHỖ trong một AZ cụ thể
    → dung lượng luôn có khi bạn khởi chạy instance
    → tạo và huỷ bất cứ lúc nào, không cam kết dài hạn

Regional Reserved Instance:
    → CHỈ giảm giá, KHÔNG giữ chỗ
    → khi AZ hết dung lượng, bạn vẫn không khởi chạy được máy

Đó là hiểu nhầm phổ biến nhất về Reserved Instance — và cũng là điểm phân biệt của câu hỏi này.

aws ec2 create-capacity-reservation   --instance-type m5.4xlarge --instance-platform Linux/UNIX   --availability-zone ap-southeast-1a --instance-count 20   --end-date-type limited --end-date 2026-08-31T03:30:00Z

Và vì workload chỉ chạy 5 giờ mỗi đêm, tạo rồi huỷ theo lịch là cách tiết kiệm nhất:

21h45: EventBridge → Lambda tạo capacity reservation
22h00: khởi chạy instance, chạy xử lý
03h00: xử lý xong, chấm dứt instance
03h15: huỷ capacity reservation
    → chỉ trả tiền cho 5,5 giờ mỗi ngày

Lưu ý về cách tính phí ODCR:

Capacity reservation tính phí NHƯ instance đang chạy
    → dù bạn có khởi chạy máy hay không
    → nên chỉ nên giữ trong khoảng thời gian thật sự cần

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

• **B. Dùng Regional Reserved Instance để đặt trước dung lượng ở một AZ cụ thể — đây là phương án gần nhất và là bẫy chính của câu hỏi: regional RI KHÔNG đặt trước dung lượng nào — nó chỉ áp giảm giá linh hoạt trong Region. Chỉ zonal RI (khai AZ cụ thể) mới giữ chỗ.
• **A. Dùng On-Demand instance và "đặt trước dung lượng ở một AZ" — mô tả mâu thuẫn: On-Demand tự nó không giữ chỗ; muốn giữ chỗ thì phải tạo Capacity Reservation — tức là chính đáp án C. Phương án A nói tới việc đó nhưng không nêu đúng tên cơ chế.
• **D. Dùng Dedicated Host — giải quyết vấn đề khác và đắt hơn nhiều: Dedicated Host cho bạn cả máy chủ vật lý riêng, phục vụ yêu cầu tuân thủ hoặc giấy phép phần mềm tính theo lõi. Đề không nêu yêu cầu nào như vậy.

Ghi nhớ

Cơ chế nào THỰC SỰ giữ chỗ dung lượng — bảng cần thuộc: | Cơ chế | Giữ chỗ | Giảm giá | Cam kết | |---|---|---|---| | On-Demand Capacity Reservation | ✅ | ❌ | không — huỷ bất cứ lúc nào | | Zonal Reserved Instance | ✅ | ✅ | 1 hoặc 3 năm | | Regional Reserved Instance | ❌ | ✅ | 1 hoặc 3 năm | | Savings Plan | ❌ | ✅ | 1 hoặc 3 năm | | On-Demand | ❌ | ❌ | không |

Hai dòng "❌ giữ chỗ" ở giữa là hiểu nhầm phổ biến nhất về AWS.

Zonal RI và Regional RI — bảng phân biệt: | | Zonal RI | Regional RI | |---|---|---| | Khai AZ | ✅ cụ thể | ❌ chỉ Region | | Giữ chỗ dung lượng | ✅ | ❌ | | Linh hoạt về kích thước instance | ❌ | ✅ (trong cùng họ) | | Áp cho AZ nào | chỉ AZ đã khai | mọi AZ trong Region |

Và ODCR kết hợp được với Savings Plan để có cả hai lợi ích:

ODCR:          đảm bảo dung lượng
Savings Plan:  giảm giá cho phần dung lượng đó
    → cộng dồn được, đây là mẫu được khuyến nghị

Đây là cách tối ưu nhất cho workload quan trọng chạy đều đặn.

Ba tuỳ chọn khi tạo Capacity Reservation: | Tuỳ chọn | Ý nghĩa | |---|---| | open (mặc định) | mọi instance khớp cấu hình đều dùng được chỗ này | | targeted | chỉ instance khai rõ ID reservation mới dùng | | end-date-type | unlimited hoặc limited (tự huỷ theo giờ) |

Chế độ targeted hữu ích khi muốn dành chỗ cho đúng một workload — tránh việc instance khác vô tình chiếm mất.

Bốn thuộc tính phải khớp để instance dùng được reservation:

① Loại instance (ví dụ m5.4xlarge)
② Nền tảng (Linux/UNIX, Windows...)
③ Availability Zone
④ Tenancy (default hoặc dedicated)

Sai một thuộc tính là instance không dùng được chỗ đã giữ.

Ba trường hợp cần Capacity Reservation: | Trường hợp | Lý do | |---|---| | Workload quan trọng theo lịch | ← câu này | | Phục hồi thảm hoạ | đảm bảo có dung lượng khi cần chuyển sang | | Sự kiện lớn biết trước | đợt khuyến mãi, phát hành sản phẩm |

Và có một tính năng đáng biết: Capacity Blocks for ML — đặt trước cụm GPU cho khoảng thời gian cụ thể trong tương lai, dành riêng cho huấn luyện mô hình.

Ba lưu ý về chi phí ODCR: | Lưu ý | Chi tiết | |---|---| | Tính phí như instance đang chạy | dù có dùng hay không | | Kết hợp Savings Plan để giảm giá | phần giảm áp cho reservation | | Huỷ khi không cần | đặc biệt với workload theo lịch |

Tự động hoá tạo và huỷ theo lịch:

# Lambda chạy lúc 21h45
ec2.create_capacity_reservation(
    InstanceType='m5.4xlarge', InstancePlatform='Linux/UNIX',
    AvailabilityZone='ap-southeast-1a', InstanceCount=20,
    EndDateType='limited',
    EndDate=datetime.now().replace(hour=3, minute=30) + timedelta(days=1))

EndDateType=limited khiến reservation tự huỷ — không sợ quên và tính tiền cả ngày.

Và một lời khuyên về kiến trúc: workload xử lý theo lô ban đêm như đề mô tả cũng là ứng viên tốt cho AWS Batch — nó tự cấp phát và thu hồi tài nguyên, và kết hợp được với Capacity Reservation để đảm bảo dung lượng. Cách đó bỏ được phần lớn công điều phối thủ công.

Đáp án

C — Cross-zone load balancing.

Vì sao đúng

Đề cần phân phối request ĐỀU tới MỌI instance qua NHIỀU Availability Zone — và đó chính là định nghĩa của cross-zone load balancing.

Vì sao tính năng này cần thiết:

KHÔNG bật cross-zone:
    Load balancer node ở AZ-a chỉ gửi tới instance trong AZ-a
    Load balancer node ở AZ-b chỉ gửi tới instance trong AZ-b
        ↓
    AZ-a có 2 instance, AZ-b có 8 instance
    Lưu lượng chia đều 50/50 giữa hai AZ
        → mỗi instance ở AZ-a nhận 25% tải
        → mỗi instance ở AZ-b nhận 6,25% tải
        → LỆCH 4 LẦN

CÓ cross-zone:
    Mọi node gửi tới MỌI instance ở MỌI AZ
        → cả 10 instance nhận đều nhau, mỗi máy 10%

Và trạng thái mặc định khác nhau theo loại load balancer: | Loại | Cross-zone mặc định | |---|---| | Application Load Balancer | BẬT, không tắt được ở mức LB | | Network Load Balancer | TẮT | | Gateway Load Balancer | TẮT | | Classic Load Balancer | tắt (bật được) |

Với ALB, phân phối đều qua các AZ là hành vi sẵn có — nhưng câu hỏi kiểm tra việc bạn biết tên và ý nghĩa của tính năng này.

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn-nlb>   --attributes Key=load_balancing.cross_zone.enabled,Value=true

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

• **B. Path-based routing — đây là phương án gần nhất vì cũng là tính năng định tuyến của ALB, nhưng nó giải quyết vấn đề khác: path-based routing gửi request tới target group KHÁC NHAU tuỳ ĐƯỜNG DẪN URL (ví dụ /api tới nhóm này, /hinh-anh tới nhóm kia). Nó không liên quan tới việc cân bằng đều giữa các AZ.
• **A. Amazon VPC IP Address Manager (IPAM) — là công cụ QUẢN LÝ địa chỉ IP: nó giúp quy hoạch, cấp phát và theo dõi dải CIDR trong tổ chức. Không liên quan tới cân bằng tải.
• **D. AWS Direct Connect SiteLink — là tính năng MẠNG LAI: nó cho phép các văn phòng nối với nhau qua mạng xương sống của AWS mà không cần đi qua Region. Không liên quan tới load balancer.

Ghi nhớ

Cross-zone load balancing — bảng cần thuộc: | Loại LB | Mặc định | Đổi được | |---|---|---| | ALB | BẬT | không tắt được ở mức LB (tắt được ở mức target group) | | NLB | TẮT | ✅ bật được | | GWLB | TẮT | ✅ | | CLB | tắt | ✅ |

Và với NLB, việc bật cross-zone có ĐÁNH ĐỔI CHI PHÍ:

Cross-zone TẮT:
    lưu lượng ở lại trong AZ → KHÔNG có phí truyền dữ liệu giữa AZ

Cross-zone BẬT:
    lưu lượng đi chéo AZ → TÍNH PHÍ ~0,01 USD/GB mỗi chiều

Đó là lý do NLB mặc định tắt — nó ưu tiên chi phí và độ trễ, còn ALB ưu tiên phân phối đều.

Ba tính năng định tuyến của ALB — đừng nhầm: | Tính năng | Việc | |---|---| | Cross-zone load balancing | phân phối đều qua các AZ ← câu này | | Path-based routing | định tuyến theo đường dẫn URL | | Host-based routing | định tuyến theo tên miền trong host header | | Header, query string, IP nguồn | điều kiện định tuyến khác |

Ba thuật toán cân bằng tải của target group: | Thuật toán | Cách hoạt động | |---|---| | Round robin (mặc định) | lần lượt từng target | | Least outstanding requests | gửi tới target đang có ít request chưa xong nhất | | Weighted random | ngẫu nhiên có trọng số |

least_outstanding_requests thường tốt hơn round robin khi thời gian xử lý request chênh lệch nhiều:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=load_balancing.algorithm.type,Value=least_outstanding_requests

Ba yếu tố khác cần có cho "highly available and scalable" như đề nêu: | Yếu tố | Chi tiết | |---|---| | ASG trải qua ít nhất HAI AZ | và đủ dung lượng khi mất một AZ | | Health check kiểu ELB cho ASG | thay instance mà LB đánh giá là hỏng | | Database Multi-AZ | tầng web nhiều AZ mà database một AZ là vô nghĩa |

Và một chi tiết về ALB: nó tự mở rộng nhưng cần thời gian.

ALB tự thêm node khi lưu lượng tăng
    → nhưng mất vài phút
    → với đợt tăng vọt đột ngột (flash sale, sự kiện trực tiếp)
      hãy liên hệ AWS để làm nóng (pre-warm) load balancer

Với ứng dụng streaming phim như đề mô tả, đây là điều đáng biết trước những sự kiện phát hành lớn.

Ba tính năng khác của ALB đáng dùng cho streaming: | Tính năng | Việc | |---|---| | Sticky session | giữ người dùng ở cùng một target | | Slow start | cho target mới nhận lưu lượng TĂNG DẦN | | Deregistration delay | xử nốt request đang dở trước khi gỡ target |

slow_start hữu ích cho ứng dụng cần làm nóng cache:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=slow_start.duration_seconds,Value=120

Không có nó, target vừa vào đã nhận đủ tải và có thể phản hồi chậm trong lúc cache còn lạnh.

Và với ứng dụng streaming, CloudFront là bổ sung quan trọng hơn cả:

Video và tài sản tĩnh → CloudFront cache tại điểm biên
    → giảm hẳn tải xuống ALB và EC2
    → và người xem ở xa được phục vụ từ điểm gần họ

Và một lưu ý về giám sát: theo dõi metric UnHealthyHostCount theo từng AZ. Nếu một AZ liên tục có nhiều instance hỏng hơn AZ khác, đó thường là dấu hiệu vấn đề riêng của AZ đó — và cross-zone load balancing sẽ che giấu triệu chứng bằng cách dồn tải sang AZ còn lại.

Đáp án

C — Xác thực người dùng bằng Redis AUTH: tạo cụm Redis mới với cả --transit-encryption-enabled LẪN --auth-token.

Vì sao đúng

Đề cần bắt người dùng nhập mật khẩu trước khi được chạy lệnh Redis — và Redis AUTH là cơ chế đó.

Cách Redis AUTH hoạt động:

Client kết nối tới cụm Redis
    → phải gửi lệnh AUTH kèm token
    → sai token → mọi lệnh bị từ chối

Và điểm mấu chốt: Redis AUTH BẮT BUỘC phải bật mã hoá đường truyền.

Không có in-transit encryption:
    → token AUTH đi qua mạng dưới dạng VĂN BẢN THUẦN
    → ai nghe lén được là có mật khẩu
        ↓
AWS BẮT BUỘC --transit-encryption-enabled khi dùng --auth-token
    → hai cờ này không tách rời được

aws elasticache create-replication-group   --replication-group-id cum-giao-dich   --replication-group-description "Cum Redis co xac thuc"   --engine redis --cache-node-type cache.r6g.large   --transit-encryption-enabled   --auth-token 'MatKhauRatDaiVaPhucTap123!'   --at-rest-encryption-enabled

Và cụm phải TẠO MỚI — không bật AUTH cho cụm đang chạy được (với các phiên bản engine cũ). Đó là lý do phương án nói "creating a NEW Redis Cluster".

Yêu cầu về token:

Dài 16–128 ký tự
Chỉ chữ, số, và các ký tự ! & # $ ^ < > -
KHÔNG chứa khoảng trắng

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

• **A. Bật in-transit encryption cho replication group — đây là phương án gần nhất và là ĐIỀU KIỆN CẦN, nhưng nó không đủ: mã hoá đường truyền bảo vệ dữ liệu khỏi bị nghe lén, nhưng không yêu cầu mật khẩu. Ai kết nối tới được cụm vẫn chạy lệnh thoải mái.
• **B. Tạo replication group mới với AtRestEncryptionEnabled = true — sai loại bảo vệ: mã hoá at rest bảo vệ dữ liệu trên đĩa và trong snapshot. Nó không liên quan tới xác thực.
• **D. Không cần làm gì, tính năng này đã bật mặc định — sai: Redis AUTH không bật mặc định. Cụm ElastiCache mặc định chỉ được bảo vệ bằng security group.
• **E. Không đáp án nào ở trên — sai vì C đúng.

Ghi nhớ

Ba lớp bảo mật của ElastiCache for Redis: | Lớp | Cơ chế | |---|---| | Mạng | VPC + security group — chỉ cho phép từ SG của ứng dụng | | Xác thực | Redis AUTH hoặc RBAC ← câu này | | Mã hoá | in-transit (TLS) và at-rest (KMS) |

Và Redis AUTH bắt buộc đi kèm in-transit encryption — đây là ràng buộc của AWS, không phải tuỳ chọn.

Hai cơ chế xác thực của ElastiCache for Redis: | Cơ chế | Đặc điểm | |---|---| | Redis AUTH (token) | một token dùng chung cho cả cụm ← câu này | | Redis RBAC (từ Redis 6.0) | NHIỀU người dùng, mỗi người quyền riêng |

RBAC là cơ chế mạnh hơn và đáng dùng cho hệ thống giao dịch:

aws elasticache create-user --user-id nguoi-doc   --user-name nguoi_doc --engine redis   --passwords 'MatKhauRatDaiVaPhucTap123!'   --access-string "on ~* +@read"

aws elasticache create-user-group --user-group-id nhom-ung-dung   --engine redis --user-ids default nguoi-doc

~* +@read nghĩa là: truy cập mọi khoá, chỉ được chạy lệnh ĐỌC — quyền tối thiểu ở mức lệnh Redis.

Và RBAC hỗ trợ xác thực bằng IAM (từ 2023):

Người dùng ElastiCache liên kết với IAM identity
    → không cần quản lý mật khẩu
    → dùng token ngắn hạn như IAM DB Authentication của RDS

Hai loại mã hoá của ElastiCache: | Loại | Bảo vệ | |---|---| | In-transit (TLS) | dữ liệu và lệnh khi truyền qua mạng | | At-rest (KMS) | dữ liệu trên đĩa, snapshot, và bộ nhớ swap |

Cả hai đều BẮT BUỘC bật lúc TẠO cụm — không bật cho cụm đang chạy được. Đây là ràng buộc quan trọng cần biết khi lập kế hoạch.

Redis và Memcached — bảng phân biệt: | | Redis | Memcached | |---|---|---| | Xác thực | ✅ AUTH và RBAC | ❌ (chỉ SASL với một số cấu hình) | | Mã hoá | ✅ in-transit và at-rest | hạn chế | | Cấu trúc dữ liệu | list, set, sorted set, hash, stream | chỉ chuỗi | | Bền vững | ✅ snapshot và AOF | ❌ | | Sao chép và failover | ✅ | ❌ | | Đa luồng | (Valkey có) | ✅ |

Với hệ thống giao dịch chứng khoán, Redis là lựa chọn đúng — nó có đủ bảo mật, bền vững và sẵn sàng cao.

Ba cấu hình sẵn sàng cao cho ElastiCache Redis: | Cấu hình | Việc | |---|---| | Multi-AZ với automatic failover | replica ở AZ khác tự tiếp quản | | Cluster mode enabled | phân mảnh dữ liệu qua nhiều shard | | Snapshot tự động | khôi phục được khi cần |

Ba lưu ý khi dùng Redis AUTH: | Lưu ý | Chi tiết | |---|---| | Lưu token trong Secrets Manager | đừng nhúng vào mã hoặc biến môi trường | | Xoay vòng token được | ElastiCache hỗ trợ đổi token mà không gián đoạn | | Client phải hỗ trợ TLS | vì AUTH bắt buộc đi kèm mã hoá |

Xoay vòng token:

aws elasticache modify-replication-group   --replication-group-id cum-giao-dich   --auth-token 'TokenMoi456!' --auth-token-update-strategy ROTATE

Chiến lược ROTATE cho phép cả token cũ và mới cùng hoạt động một thời gian — client có thời gian cập nhật mà không bị ngắt kết nối.

Và một lưu ý về kiến trúc: dù đã có AUTH, hãy vẫn đặt cụm trong private subnet với security group chỉ nhận từ security group của ứng dụng. Xác thực là lớp bảo vệ bổ sung, không thay thế cho việc thu hẹp bề mặt mạng — nguyên tắc phòng thủ nhiều lớp áp cho cả cache.

Đáp án

A — Dùng AWS Storage Gateway — File Gateway với dung lượng cache đủ chứa dữ liệu 48 giờ gần nhất; gửi bản sao lưu tới SMB share mount như ổ đĩa cục bộ.

Vì sao đúng

Đề nêu ba yêu cầu, và File Gateway đáp ứng cả ba với ít cấu hình nhất: | Yêu cầu | Cơ chế | |---|---| | Sao lưu qua giao thức SMB | File Gateway hỗ trợ SMB | | Dữ liệu 48 giờ gần nhất phải truy cập NGAY | cache cục bộ giữ phần mới nhất | | Dữ liệu cũ hơn chậm hơn cũng chấp nhận được | lấy từ S3 khi cần |

Cách cache của File Gateway phục vụ đúng mẫu này:

Ghi bản sao lưu vào SMB share
    → File Gateway lưu vào cache cục bộ
    → đồng thời đẩy lên S3
        ↓
Đọc dữ liệu MỚI (trong cache):
    → tốc độ đĩa cục bộ, TỨC THÌ  ✅
Đọc dữ liệu CŨ (đã rời cache):
    → lấy từ S3, chậm hơn  ✅ chấp nhận được

Và "LEAST amount of configuration effort" được đáp ứng:

Chỉ cần:
    ① Triển khai gateway (máy ảo hoặc thiết bị)
    ② Cấp đĩa cache đủ chứa 48 giờ dữ liệu
    ③ Tạo SMB file share
    ④ Mount trên máy chủ
        ↓
    Không phải viết script đồng bộ
    Không phải quản lý vòng đời dữ liệu thủ công

Và dữ liệu cũ tự động được lưu trữ giá rẻ:

{"Rules": [{
  "Status": "Enabled", "Filter": {},
  "Transitions": [{"Days": 30, "StorageClass": "GLACIER"}]}]}

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

• **B. Tạo SMB file share trong FSx for Windows File Server đủ chứa TOÀN BỘ bản sao lưu — đây là phương án gần nhất và cũng dùng SMB, nhưng nó đắt hơn nhiều và không tận dụng phân tầng: FSx tính phí cho toàn bộ dung lượng ở mức giá cao, trong khi 99% dữ liệu hiếm khi đọc. File Gateway chỉ cần cache nhỏ, phần còn lại nằm ở S3 rẻ hơn nhiều lần.
• **C. Mount Amazon EFS trên client tại chỗ và sao chép sang NFS share — sai giao thức: đề nói rõ dùng SMB, còn EFS là NFS. Và mount EFS từ tại chỗ đòi Direct Connect hoặc VPN, cộng thêm độ trễ cao cho mọi lần đọc vì không có cache cục bộ.
• **D. Tạo AWS Backup plan sao chép dữ liệu tới SMB share cục bộ mỗi 48 giờ — sai chiều: AWS Backup sao lưu tài nguyên AWS vào AWS. Nó không đẩy dữ liệu ngược về SMB share tại chỗ.

Ghi nhớ

Ba loại Storage Gateway: | Loại | Giao thức | Đích | |---|---|---| | File Gateway | NFS, SMB | S3 ← câu này | | Volume Gateway | iSCSI | S3 dạng EBS snapshot | | Tape Gateway | iSCSI VTL | S3 Glacier |

Từ khoá nhận diện:

"SMB", "NFS", "file share" → File Gateway "iSCSI", "block volume" → Volume Gateway "tape", "backup software", "VTL" → Tape Gateway

Và mẫu "dữ liệu gần đây nhanh, dữ liệu cũ chậm" chính là mô hình CACHE:

Bất kỳ khi nào đề mô tả:
    "recent data must be immediately available"
    "older data with delay is tolerable"
        ↓
    → nghĩ tới cache: File Gateway hoặc Volume Gateway cached mode

Ba yếu tố quyết định kích thước cache: | Yếu tố | Chi tiết | |---|---| | Lượng dữ liệu trong khoảng thời gian cần truy cập nhanh | 48 giờ trong đề này | | Tốc độ sinh dữ liệu mỗi ngày | nhân với số ngày cần cache | | Biên độ an toàn | thêm 20–30% |

Cache quá nhỏ là lỗi triển khai phổ biến nhất — nó khiến mọi lần đọc phải lấy từ S3 và mất hết lợi ích của mô hình.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CachePercentUsed | gần đầy nghĩa là cần mở rộng | | CacheHitPercent | thấp nghĩa là cache quá nhỏ | | UploadBufferPercentUsed | buffer đầy sẽ chặn việc ghi |

Ba đặc điểm của S3 File Gateway: | Đặc điểm | Chi tiết | |---|---| | Mỗi tệp = một object S3 | truy cập được bằng CẢ SMB LẪN S3 API | | Tích hợp Active Directory | phân quyền SMB theo người dùng miền | | Tích hợp lifecycle của S3 | tự chuyển sang Glacier |

Dòng đầu là lợi ích đáng chú ý cho phục hồi thảm hoạ: nếu trung tâm dữ liệu mất hoàn toàn, bạn vẫn đọc được bản sao lưu trực tiếp từ S3 bằng bất kỳ công cụ nào — không cần dựng lại gateway trước.

Ba biện pháp bảo vệ dữ liệu sao lưu trên S3: | Biện pháp | Chống lại | |---|---| | Versioning | ghi đè và xoá nhầm | | Object Lock chế độ Compliance | xoá cố ý, ransomware | | Cross-Region Replication | sự cố cả Region |

Object Lock đặc biệt quan trọng với dữ liệu sao lưu — nhiều cuộc tấn công ransomware nhắm chính vào bản sao lưu trước khi mã hoá dữ liệu chính.

Ba lựa chọn lưu trữ lai — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | Storage Gateway | truy cập lai LIÊN TỤC với cache ← câu này | | FSx for Windows | hệ thống tệp Windows ĐẦY ĐỦ trên AWS | | DataSync | di chuyển hoặc đồng bộ định kỳ |

FSx File Gateway là lựa chọn thứ tư đáng biết:

Kết hợp FSx for Windows với cache tại chỗ
    → dùng khi cần đầy đủ tính năng Windows (NTFS ACL, DFS)
      NHƯNG truy cập từ tại chỗ với độ trễ thấp

Ba lưu ý khi triển khai gateway: | Lưu ý | Chi tiết | |---|---| | Đặt giới hạn băng thông theo lịch | tránh nghẽn đường truyền giờ làm việc | | Gateway cần đĩa cho cache VÀ upload buffer | hai thứ riêng biệt | | Giám sát CacheHitPercent | chỉ báo trực tiếp chất lượng cấu hình |

Và một lời khuyên cho kế hoạch phục hồi kinh doanh: hãy diễn tập khôi phục định kỳ, gồm cả việc lấy dữ liệu cũ hơn 48 giờ từ S3. Đó là đường dẫn ít được kiểm chứng nhất, và cũng là đường bạn sẽ cần đúng lúc có sự cố thật.

Đáp án

C — Dùng path condition để định nghĩa rule chuyển tiếp request tới các target group khác nhau dựa trên URL trong request.

Vì sao đúng

Đề mô tả chính xác path-based routing — tính năng dựng sẵn của Application Load Balancer:

/api/android → Android-Target-Group
/api/ios     → iOS-Target-Group

Cách cấu hình:

aws elbv2 create-rule --listener-arn <arn-listener> --priority 10   --conditions '[{"Field":"path-pattern","Values":["/api/android*"]}]'   --actions '[{"Type":"forward","TargetGroupArn":"<arn-android>"}]'

aws elbv2 create-rule --listener-arn <arn-listener> --priority 20   --conditions '[{"Field":"path-pattern","Values":["/api/ios*"]}]'   --actions '[{"Type":"forward","TargetGroupArn":"<arn-ios>"}]'

Và ALB làm được điều này vì nó hoạt động ở TẦNG 7:

ALB đọc và hiểu nội dung HTTP:
    ✓ đường dẫn URL
    ✓ tên miền trong host header
    ✓ HTTP header
    ✓ phương thức, query string
    ✓ IP nguồn

Ba lợi ích của mô hình này cho hệ thống đặt món: | Lợi ích | Chi tiết | |---|---| | Một ALB phục vụ nhiều dịch vụ | tiết kiệm chi phí và đơn giản hoá DNS | | Mỗi nền tảng co giãn ĐỘC LẬP | Android đông hơn thì chỉ mở rộng nhóm Android | | Triển khai riêng biệt | cập nhật API iOS không ảnh hưởng Android |

Và rule được đánh giá theo THỨ TỰ ƯU TIÊN — số nhỏ xét trước, dừng ở rule khớp đầu tiên.

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

• **A. Dùng host condition định tuyến theo tên miền trong host header — đây là phương án gần nhất vì cũng là điều kiện định tuyến của ALB, nhưng nó dựa trên TÊN MIỀN, không phải đường dẫn: nó phù hợp khi bạn có android.congty.com và ios.congty.com. Đề nói rõ phân biệt theo URL path.
• **B. Thay ALB bằng Gateway Load Balancer rồi dùng path condition — sai loại load balancer: Gateway Load Balancer hoạt động ở tầng 3, dùng để chèn thiết bị bảo mật của bên thứ ba (tường lửa ảo) vào đường đi của lưu lượng. Nó không hiểu HTTP và không có path condition.
• **D. Thay ALB bằng Network Load Balancer rồi dùng host condition — sai loại: NLB hoạt động ở tầng 4 (TCP/UDP), nó không đọc được nội dung HTTP nên không có host condition hay path condition nào.

Ghi nhớ

Bốn loại Elastic Load Balancer — bảng cần thuộc: | | ALB | NLB | GWLB | CLB | |---|---|---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | 3 (IP) | 4 và 7 | | Định tuyến theo đường dẫn | ✅ | ❌ | ❌ | hạn chế | | Định tuyến theo host | ✅ | ❌ | ❌ | ❌ | | UDP | ❌ | ✅ | ✅ | ❌ | | IP tĩnh | ❌ | ✅ | — | ❌ | | Dùng cho | ứng dụng web, microservice | game, IoT, độ trễ cực thấp | thiết bị bảo mật | cũ |

Quy tắc chọn:

Định tuyến theo URL hoặc tên miền → ALB UDP, TCP, cần IP tĩnh → NLB Chèn tường lửa ảo của bên thứ ba → GWLB

Bảy loại điều kiện của ALB listener rule: | Điều kiện | Ví dụ | |---|---| | path-pattern | /api/android* ← câu này | | host-header | android.congty.com | | http-header | User-Agent chứa một chuỗi | | http-request-method | POST, GET | | query-string | ?nen-tang=android | | source-ip | dải CIDR của người gọi |

Và các điều kiện KẾT HỢP được trong một rule:

{"Conditions": [
   {"Field": "path-pattern", "Values": ["/api/*"]},
   {"Field": "http-header",
    "HttpHeaderConfig": {"HttpHeaderName": "X-Nen-Tang", "Values": ["android"]}}]}

Cả hai điều kiện phải khớp thì rule mới áp dụng.

Ba lưu ý về path pattern: | Lưu ý | Chi tiết | |---|---| | Phân biệt chữ hoa chữ thường | /API/Android không khớp /api/android | | Hỗ trợ ký tự đại diện * và ? | /api/android* khớp mọi đường dẫn con | | KHÔNG khớp query string | dùng điều kiện query-string riêng |

Bốn loại action của listener rule: | Action | Việc | |---|---| | forward | chuyển tới target group | | redirect | chuyển hướng 301 hoặc 302 | | fixed-response | trả thẳng nội dung cố định | | authenticate-cognito / authenticate-oidc | xác thực NGAY TẠI ALB |

fixed-response hữu ích cho trang bảo trì — trả về thông báo mà không cần máy chủ nào chạy phía sau.

Và forward hỗ trợ nhiều target group với trọng số — dùng cho triển khai canary:

{"Type": "forward", "ForwardConfig": {"TargetGroups": [
   {"TargetGroupArn": "<arn-phien-ban-cu>", "Weight": 90},
   {"TargetGroupArn": "<arn-phien-ban-moi>", "Weight": 10}]}}

Rất hữu ích khi phát hành API mới cho một nền tảng — 10% người dùng Android thử phiên bản mới trước.

Ba giới hạn của ALB cần biết: | Giới hạn | Giá trị | |---|---| | Số rule mỗi listener | 100 (tăng được) | | Số target group mỗi ALB | 100 | | Số chứng chỉ mỗi listener (SNI) | 25 (tăng được) |

Và mỗi target group có health check và cấu hình RIÊNG:

Android-Target-Group → health check /api/android/health
iOS-Target-Group     → health check /api/ios/health
    → mỗi nhóm được đánh giá độc lập

Và một lời khuyên về kiến trúc: nếu số lượng đường dẫn và dịch vụ tăng lên nhiều, hãy cân nhắc API Gateway thay vì ALB — nó có thêm quản lý phiên bản API, giới hạn tốc độ theo khách hàng, và tài liệu API tự sinh. Với hai nhóm như trong đề thì ALB gọn và rẻ hơn.