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

Tìm thấy 2194 câu.

Câu 781 Design Resilient Architectures

A company is experiencing stability issues with their cluster of self-managed RabbitMQ message brokers and the company now wants to explore an alternate solution on AWS.

As a solutions architect, which of the following AWS services would you recommend that can provide support for quick and easy migration from RabbitMQ?

  1. A

    Amazon Simple Notification Service (Amazon SNS)
  2. B

    Amazon Simple Queue Service (Amazon SQS) Standard
  3. C

    Amazon MQ
  4. D

    Amazon SQS FIFO (First-In-First-Out)
Xem giải thích

Đáp án

C — Amazon MQ.

Vì sao đúng

Đề nêu yêu cầu: di chuyển NHANH và DỄ từ RabbitMQ, và Amazon MQ hỗ trợ chính engine đó.

Amazon MQ có hai engine:
    ✓ Apache ActiveMQ
    ✓ RabbitMQ          ← đúng thứ công ty đang dùng
        ↓
    Ứng dụng chỉ cần đổi CHUỖI KẾT NỐI
    → giao thức AMQP 0-9-1 giữ nguyên

Và đó là lý do "quick and easy migration":

Chuyển sang SQS hay SNS:
    → API riêng của AWS
    → phải VIẾT LẠI toàn bộ tầng nhắn tin

Chuyển sang Amazon MQ với engine RabbitMQ:
    → cùng giao thức, cùng thư viện client
    → chỉ đổi địa chỉ broker

Tạo broker:

aws mq create-broker --broker-name broker-chinh   --engine-type RABBITMQ --engine-version 3.13   --host-instance-type mq.m5.large   --deployment-mode CLUSTER_MULTI_AZ   --users Username=quantri,Password='<mat-khau>'   --publicly-accessible false   --subnet-ids subnet-a subnet-b subnet-c

CLUSTER_MULTI_AZ giải quyết vấn đề ổn định trong đề:

Đề nói cụm RabbitMQ tự quản gặp "stability issues"
        ↓
    Amazon MQ cluster deployment:
        → 3 node qua 3 AZ
        → AWS lo vá lỗi, giám sát, thay node hỏng
        ↓
    Bỏ hẳn gánh nặng vận hành cụm

Và ứng dụng kết nối như cũ:

amqps://b-abc123.mq.ap-northeast-1.amazonaws.com:5671

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

  • **B. SQS Standard — đây là phương án gần nhất vì cũng là dịch vụ hàng đợi được quản lý và mở rộng tốt hơn nhiều, nhưng nó dùng API riêng của AWS: mọi mã liên quan tới nhắn tin phải viết lại. Đề nhấn mạnh "quick and easy migration".
  • **D. SQS FIFO — cùng vấn đề API, và còn thêm giới hạn thông lượng.
  • **A. Amazon SNS — sai mô hình: SNS là dịch vụ phát tán thông báo, không phải message broker có hàng đợi bền vững.

Ghi nhớ

Bốn dịch vụ nhắn tin của AWS — bảng phải thuộc: | Dịch vụ | Giao thức | Phù hợp | |---|---|---| | Amazon MQ | AMQP, MQTT, STOMP, OpenWire, JMS | DI CHUYỂN ứng dụng dùng broker chuẩn | | Amazon SQS | API riêng (HTTPS) | ứng dụng mới trên đám mây | | Amazon SNS | API riêng | phát tán thông báo | | Amazon MSK | Kafka | luồng sự kiện quy mô lớn |

Quy tắc nhận diện — rất hay được hỏi:

"existing RabbitMQ/ActiveMQ/AMQP/JMS", "lift and shift", "no code change" → Amazon MQ "cloud-native", "unlimited scale" → SQS hoặc SNS "existing Kafka" → Amazon MSK

Hai engine của Amazon MQ: | Engine | Giao thức | |---|---| | RabbitMQ | AMQP 0-9-1 | | ActiveMQ | MQTT, AMQP, STOMP, OpenWire, JMS, WebSocket |

ActiveMQ hỗ trợ nhiều giao thức hơn, nhưng nếu nguồn là RabbitMQ thì chọn engine RabbitMQ.

Ba kiểu triển khai: | Kiểu | Sẵn sàng | |---|---| | Single-instance | không chịu lỗi — chỉ cho dev | | Active/standby (ActiveMQ) | hai AZ, tự chuyển đổi | | Cluster (RabbitMQ) | ba node qua ba AZ |

Amazon MQ và SQS — bảng phân biệt: | | Amazon MQ | SQS | |---|---|---| | Giao thức chuẩn ngành | ✅ | ❌ | | Mở rộng | giới hạn bởi cỡ broker | gần như vô hạn | | Cần chọn cỡ instance | ✅ | ❌ | | Nằm trong VPC | ✅ | ❌ endpoint công khai | | Chi phí | theo giờ broker | theo request |

Đánh đổi quan trọng:

Amazon MQ dễ di chuyển
    → nhưng KHÔNG mở rộng vô hạn
    → vẫn là broker chạy trên instance có kích thước
        ↓
    Phải theo dõi và nâng cỡ khi tải tăng

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | MessageCount / QueueSize | tồn đọng — consumer không kịp | | CpuUtilization của broker | cần nâng cỡ | | ConnectionCount, ChannelCount | gần trần |

Ba lưu ý khi di chuyển từ RabbitMQ tự quản: | Lưu ý | Chi tiết | |---|---| | Kiểm tra phiên bản và plugin đang dùng | Amazon MQ hỗ trợ tập con plugin | | Xuất và nhập định nghĩa queue, exchange | | | Chạy song song một thời gian | |

Xuất định nghĩa từ cụm cũ:

rabbitmqadmin export dinh-nghia.json
# rồi nhập vào broker mới qua management UI

Ba plugin phổ biến và tình trạng hỗ trợ: | Plugin | Amazon MQ | |---|---| | Management | ✅ có sẵn | | Shovel, Federation | ✅ | | Một số plugin cộng đồng | ❌ kiểm tra trước |

Ba biện pháp bảo mật: | Biện pháp | Chi tiết | |---|---| | Broker trong PRIVATE subnet | publicly-accessible false | | Mã hoá at rest bằng KMS, in transit bằng TLS | | | Thông tin đăng nhập trong Secrets Manager | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Broker instance-giờ | như EC2 | | Lưu trữ theo GB | | | Cluster gấp ba chi phí instance | ba node |

Ba lưu ý về nâng cấp: | Lưu ý | Chi tiết | |---|---| | Đặt maintenance window | | | Bật auto minor version upgrade | | | Nâng cấp major version cần lập kế hoạch | |

Ba lựa chọn lộ trình dài hạn: | Giai đoạn | Chi tiết | |---|---| | ① Amazon MQ | di chuyển không viết lại | | ② Đánh giá lại khi ổn định | | | ③ Chuyển dần sang SQS/SNS nếu cần quy mô lớn | |

Và một lời khuyên: hãy coi Amazon MQ là bước trung gian chứ không phải đích cuối. Nó cho phép chuyển lên đám mây mà không viết lại mã, nhưng vẫn là broker có kích thước cố định — và nếu hệ thống tiếp tục lớn, việc chuyển dần từng dịch vụ sang SQS sau khi đã ổn định trên AWS dễ hơn nhiều so với làm hai việc cùng lúc.

Câu 782 Design High-Performing Architectures

The systems administrator at a company wants to set up a highly available architecture for a bastion host solution.

As a solutions architect, which of the following options would you recommend as the solution?

  1. A

    Create a VPC Endpoint for a fleet of Amazon EC2 instances that are bastion hosts managed by an Auto Scaling Group
  2. B

    Create a public Application Load Balancer that links to Amazon EC2 instances that are bastion hosts managed by an Auto Scaling Group
  3. C

    Create an elastic IP address (EIP) and assign it to all Amazon EC2 instances that are bastion hosts managed by an Auto Scaling Group
  4. D

    Create a public Network Load Balancer that links to Amazon EC2 instances that are bastion hosts managed by an Auto Scaling Group
Xem giải thích

Đáp án

D — Tạo Network Load Balancer công khai trỏ tới các EC2 bastion host do Auto Scaling group quản lý.

Vì sao đúng

Đề nêu hai yêu cầu, và NLB đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Bastion host SẴN SÀNG CAO | NLB + ASG trải nhiều AZ | | Truy cập bằng SSH | NLB hoạt động ở tầng 4 (TCP) |

Vế thứ hai là điểm phân biệt quyết định:

SSH chạy trên TCP cổng 22
    → KHÔNG phải HTTP
        ↓
    ALB CHỈ hỗ trợ HTTP/HTTPS
    → không định tuyến được SSH
        ↓
    NLB hoạt động ở tầng 4 → định tuyến mọi TCP

Và NLB còn cho Elastic IP tĩnh:

Gán Elastic IP cho NLB
    → quản trị viên luôn SSH tới cùng một địa chỉ
    → dù ASG thay bastion host bao nhiêu lần

Triển khai:

aws elbv2 create-load-balancer --name nlb-bastion --type network   --subnet-mappings SubnetId=subnet-az-a,AllocationId=eipalloc-1                     SubnetId=subnet-az-c,AllocationId=eipalloc-2

aws elbv2 create-target-group --name tg-bastion   --protocol TCP --port 22 --vpc-id vpc-abc --target-type instance

aws elbv2 create-listener --load-balancer-arn <arn-nlb>   --protocol TCP --port 22   --default-actions Type=forward,TargetGroupArn=<arn-tg>

Và ASG trải nhiều AZ:

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-bastion   --launch-template LaunchTemplateName=lt-bastion,Version='$Latest'   --min-size 2 --desired-capacity 2 --max-size 4   --vpc-zone-identifier "subnet-az-a,subnet-az-c"   --target-group-arns <arn-tg>

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

  • **B. Tạo Application Load Balancer công khai trỏ tới bastion host — đây là phương án gần nhất và cấu trúc hoàn toàn đúng, nhưng nó sai loại load balancer: ALB chỉ hiểu HTTP và HTTPS, không chuyển tiếp được lưu lượng SSH.
  • **C. Tạo Elastic IP và gán cho TẤT CẢ bastion host trong ASG — không làm được: một Elastic IP chỉ gắn được vào một ENI tại một thời điểm.
  • **A. Tạo VPC Endpoint cho nhóm bastion host — hiểu sai dịch vụ: VPC endpoint cho phép truy cập riêng tư tới dịch vụ AWS, không phải cơ chế cân bằng tải cho EC2.

Ghi nhớ

ALB và NLB — bảng phải thuộc: | | ALB | NLB | |---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | | SSH, RDP, database | ❌ | ✅ | | IP tĩnh | ❌ | ✅ Elastic IP | | Định tuyến theo đường dẫn | ✅ | ❌ | | WAF | ✅ | ❌ |

Quy tắc: giao thức KHÔNG PHẢI HTTP → NLB.

⚠ Và cách tốt hơn nhiều: bỏ hẳn bastion host.

aws ssm start-session --target i-0abc123

AWS Systems Manager Session Manager:
    ✓ KHÔNG cần bastion host nào
    ✓ KHÔNG mở cổng 22 ra Internet
    ✓ KHÔNG cần key pair
    ✓ ghi log TOÀN BỘ phiên
    ✓ kiểm soát bằng IAM
        ↓
    Đây là cách AWS khuyến nghị hiện nay

Ba yêu cầu của Session Manager: | Yêu cầu | Chi tiết | |---|---| | SSM Agent chạy | có sẵn trên AMI của AWS | | Instance profile có AmazonSSMManagedInstanceCore | | | Đường tới endpoint SSM | 3 VPC endpoint hoặc NAT |

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages

Ba cách truy cập máy trong private subnet: | Cách | Cổng mở | |---|---| | Session Manager | KHÔNG mở gì | | EC2 Instance Connect Endpoint | không mở gì | | Bastion host | ← câu này, cần mở 22 |

Ba lưu ý nếu vẫn dùng bastion: | Lưu ý | Chi tiết | |---|---| | Giới hạn IP nguồn trong security group | chỉ mạng công ty | | Ghi log phiên SSH | | | Vá lỗi thường xuyên | máy phơi ra Internet |

Ba lưu ý về NLB với target type instance: | Lưu ý | Chi tiết | |---|---| | GIỮ IP nguồn của client | | | Security group của target thấy IP CLIENT | không phải IP của NLB | | Phải cho phép dải IP quản trị viên | |

Dòng giữa là bẫy hay gặp:

Cấu hình security group cho phép sg-nlb
    → KHÔNG hoạt động với target type `instance`
        ↓
    Phải cho phép chính dải IP của quản trị viên

Ba lưu ý về health check của NLB: | Lưu ý | Chi tiết | |---|---| | Mặc định là TCP | chỉ kiểm tra cổng mở | | Với bastion, TCP là đủ | | | Ngưỡng khoẻ và hỏng mặc định 3 | |

Ba lưu ý về Elastic IP với NLB: | Lưu ý | Chi tiết | |---|---| | Một EIP mỗi AZ | | | IP không đổi | ghi vào tài liệu | | Cần Internet Gateway trong VPC | |

Ba lưu ý về ASG cho bastion: | Lưu ý | Chi tiết | |---|---| | min = 2 trải hai AZ | chịu lỗi AZ | | HealthCheckType = ELB | | | Golden AMI có sẵn công cụ quản trị | |

Ba lưu ý về ghi log: | Lưu ý | Chi tiết | |---|---| | NLB access log ghi kết nối | ai kết nối từ đâu | | Log SSH gửi lên CloudWatch Logs | máy bị thay là mất log cục bộ | | CloudTrail nếu dùng Session Manager | |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | NLB | ~0,0225 USD/giờ + NLCU | | 2 bastion instance | tuỳ cỡ | | Session Manager | MIỄN PHÍ |

Dòng cuối là lập luận mạnh nhất cho việc bỏ bastion.

Và một lời khuyên: hãy đánh giá Session Manager trước khi dựng bastion host sẵn sàng cao. Toàn bộ kiến trúc NLB, ASG, Elastic IP và security group trong câu này tồn tại để giải quyết một bài toán mà AWS đã có sẵn lời giải không tốn đồng nào — và lời giải đó còn an toàn hơn vì không mở cổng nào ra Internet.

Câu 783 Design Resilient Architectures

A healthcare company runs a fleet of Amazon EC2 instances in two private subnets (named PR1 and PR2) across two Availability Zones (AZs) named A1 and A2. The Amazon EC2 instances need access to the internet for operating system patch management and third-party software maintenance. To facilitate this, the engineering team at the company wants to set up two Network Address Translation gateways (NAT gateways) in a highly available configuration.

Which of the following options would you suggest?

  1. A

    Set up a total of two NAT gateways. NAT gateway N1 should be set up in public subnet PU1 in Availability Zone A1. NAT gateway N2 should be set up in public subnet PU2 in Availability Zone A2
  2. B

    Set up a total of two NAT gateways. NAT gateway N1 should be set up in private subnet PR1 in Availability Zone A1. NAT gateway N2 should be set up in private subnet PR2 in Availability Zone A2
  3. C

    Set up a total of one NAT gateway. NAT gateway N1 should be set up in public subnet PU1 in any of the Availability Zones A1 or A2
  4. D

    Set up a total of two NAT gateways. Both NAT gateways N1 and N2 should be set up in a single public subnet PU1 in any of the Availability Zones A1 or A2
Xem giải thích

Đáp án

A — Dựng hai NAT gateway: N1 ở public subnet PU1 trong AZ A1, N2 ở public subnet PU2 trong AZ A2.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án A đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | NAT gateway phải hoạt động | BẮT BUỘC đặt ở PUBLIC subnet | | Cấu hình SẴN SÀNG CAO | một NAT ở MỖI AZ |

Vì sao NAT gateway phải ở public subnet:

NAT gateway cần ra Internet để chuyển tiếp lưu lượng
    → nó cần route 0.0.0.0/0 → Internet Gateway
        ↓
    Đó chính là định nghĩa của PUBLIC subnet
        ↓
    Đặt ở private subnet = không có đường ra = vô dụng

Và vì sao mỗi AZ một NAT:

NAT gateway là tài nguyên THEO AZ
    → AZ chứa nó hỏng → NAT đó biến mất
        ↓
    Nếu cả hai private subnet dùng chung một NAT:
        → AZ chứa NAT hỏng
        → CẢ HAI subnet mất đường ra Internet
        ↓
    Mỗi AZ một NAT → hỏng AZ nào chỉ ảnh hưởng AZ đó

Và route table phải tách riêng:

Route table của PR1: 0.0.0.0/0 → N1 (cùng AZ A1)
Route table của PR2: 0.0.0.0/0 → N2 (cùng AZ A2)
        ↓
    Đây là bước hay bị quên
    → dùng chung một route table = mất luôn tính dư thừa
      VÀ tốn phí truyền chéo AZ

Triển khai:

aws ec2 create-nat-gateway --subnet-id subnet-pu1   --allocation-id eipalloc-1
aws ec2 create-nat-gateway --subnet-id subnet-pu2   --allocation-id eipalloc-2

aws ec2 create-route --route-table-id rtb-pr1   --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-1
aws ec2 create-route --route-table-id rtb-pr2   --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-2

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

  • **D. Hai NAT gateway nhưng cả hai ở CÙNG một public subnet PU1 — đây là phương án gần nhất vì có đúng hai NAT, nhưng cả hai nằm trong cùng một AZ: AZ đó hỏng là mất cả hai. Đó không phải sẵn sàng cao.
  • **B. Hai NAT gateway đặt ở PRIVATE subnet — không hoạt động: NAT gateway ở private subnet không có đường ra Internet.
  • **C. Một NAT gateway duy nhất — là điểm hỏng đơn: AZ chứa nó hỏng là mọi instance mất đường ra.

Ghi nhớ

Ba quy tắc bắt buộc về NAT gateway: | Quy tắc | Chi tiết | |---|---| | Đặt ở PUBLIC subnet | cần route tới IGW | | Cần Elastic IP | | | Là tài nguyên THEO AZ | một NAT mỗi AZ cho sẵn sàng cao |

Kiến trúc chuẩn cho hai AZ:

AZ A1: PU1 (NAT N1) ←──── PR1 (route 0.0.0.0/0 → N1)
AZ A2: PU2 (NAT N2) ←──── PR2 (route 0.0.0.0/0 → N2)

Ba lỗi thường gặp: | Lỗi | Hậu quả | |---|---| | Đặt NAT ở private subnet | không hoạt động | | Một NAT cho nhiều AZ | điểm hỏng đơn + phí chéo AZ | | Quên tách route table theo AZ | mất tính dư thừa |

Phí chéo AZ đáng chú ý:

Private subnet ở AZ-B dùng NAT ở AZ-A
    → mọi byte đi qua ranh giới AZ
    → ~0,01 USD/GB mỗi chiều
        ↓
    Cộng với phí xử lý NAT 0,045 USD/GB

NAT Gateway và NAT Instance — bảng phân biệt: | | NAT Gateway | NAT Instance | |---|---|---| | Quản lý | AWS | bạn tự | | Sẵn sàng | dư thừa trong AZ | tự lo | | Băng thông | tới 100 Gbps, tự co giãn | theo cỡ instance | | Security group | ❌ | ✅ | | Bastion host | ❌ | ✅ dùng kiêm được | | Chi phí | ~32 USD/tháng + GB | rẻ hơn với tải nhỏ |

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

Ba lưu ý về chi phí NAT Gateway: | Khoản | Giá tham khảo | |---|---| | Phí giờ | ~0,045 USD/giờ (~32 USD/tháng) | | Phí xử lý dữ liệu | ~0,045 USD/GB | | — | hai NAT ≈ 64 USD/tháng phí cố định |

Ba cách giảm chi phí NAT: | Cách | Tiết kiệm | |---|---| | VPC gateway endpoint cho S3 và DynamoDB | MIỄN PHÍ, bỏ hẳn lưu lượng đó | | Interface endpoint cho dịch vụ hay dùng | rẻ hơn NAT | | Đặt NAT cùng AZ với private subnet | bỏ phí chéo AZ |

Cách đầu thường tiết kiệm nhiều nhất:

Instance tải bản vá và gọi API AWS
    → phần gọi S3, DynamoDB đi qua gateway endpoint (0 USD)
    → chỉ còn lưu lượng tới Internet thật đi qua NAT

Ba lựa chọn thay thế NAT Gateway: | Lựa chọn | Khi nào | |---|---| | VPC endpoint | chỉ gọi dịch vụ AWS | | NAT instance | tải rất nhỏ, muốn tiết kiệm | | Egress-only Internet Gateway | cho IPv6 |

Egress-only IGW là bản tương đương cho IPv6:

IPv6 không có khái niệm NAT
    → egress-only IGW cho phép ra Internet
    → nhưng chặn kết nối vào
        ↓
    Và nó MIỄN PHÍ

Ba lưu ý về vá lỗi qua NAT: | Lưu ý | Chi tiết | |---|---| | Systems Manager Patch Manager cần endpoint hoặc NAT | | | VPC endpoint cho SSM rẻ hơn | | | Repository của bản phân phối Linux đi qua NAT | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BytesOutToDestination | lưu lượng ra Internet | | ErrorPortAllocation | cạn cổng — cần thêm NAT | | PacketsDropCount | |

ErrorPortAllocation là dấu hiệu quan trọng:

Một NAT Gateway hỗ trợ ~55.000 kết nối đồng thời
  tới CÙNG một đích
    → vượt ngưỡng → lỗi cấp phát cổng
        ↓
    Cần chia tải sang nhiều NAT

Ba lưu ý về thiết kế subnet: | Lưu ý | Chi tiết | |---|---| | Public subnet chỉ chứa NAT, load balancer, bastion | | | Ứng dụng và database ở private subnet | | | Mỗi AZ có cả public lẫn private subnet | |

Và một lời khuyên: hãy tạo VPC gateway endpoint cho S3 và DynamoDB cùng lúc với NAT Gateway. Chúng miễn phí và thường chiếm phần lớn lưu lượng ra khỏi private subnet — bỏ qua bước này nghĩa là trả phí xử lý NAT cho lưu lượng đáng lẽ không cần đi qua đó chút nào.

Câu 784 Design High-Performing Architectures

You are looking to build an index of your files in Amazon S3, using Amazon RDS PostgreSQL. To build this index, it is necessary to read the first 250 bytes of each object in Amazon S3, which contains some metadata about the content of the file itself. There are over 100,000 files in your S3 bucket, amounting to 50 terabytes of data.

How can you build this index efficiently?

  1. A

    Create an application that will traverse the Amazon S3 bucket, read all the files one by one, extract the first 250 bytes, and store that information in Amazon RDS
  2. B

    Create an application that will traverse the Amazon S3 bucket, then use S3 Select Byte Range Fetch parameter to get the first 250 bytes, and store that information in Amazon RDS
  3. C

    Use the Amazon RDS Import feature to load the data from Amazon S3 to PostgreSQL, and run a SQL query to build the index
  4. D

    Create an application that will traverse the S3 bucket, issue a Byte Range Fetch for the first 250 bytes, and store that information in Amazon RDS
Xem giải thích

Đáp án

D — Viết ứng dụng duyệt bucket, phát Byte Range Fetch cho 250 byte đầu, rồi lưu thông tin đó vào Amazon RDS.

Vì sao đúng

Đề nêu bài toán rõ: chỉ cần 250 byte đầu của mỗi tệp, trong khi tổng dung lượng là 50 TB.

Đọc toàn bộ tệp:
    → tải 50 TB qua mạng
    → tốn thời gian và phí truyền dữ liệu khổng lồ

Byte Range Fetch:
    → CHỈ tải 250 byte đầu mỗi tệp
    → 100.000 tệp × 250 byte = 25 MB tổng cộng
        ↓
    Giảm từ 50 TB xuống 25 MB

Cú pháp:

import boto3
s3 = boto3.client('s3')

for khoa in danh_sach_khoa:
    r = s3.get_object(Bucket='kho-du-lieu', Key=khoa, Range='bytes=0-249')
    metadata = r['Body'].read()
    luu_vao_rds(khoa, metadata)

Header Range là tính năng chuẩn của HTTP — S3 hỗ trợ nguyên bản, không cần dịch vụ nào khác.

Và nên chạy song song:

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor(max_workers=50) as executor:
    list(executor.map(xu_ly_mot_tep, danh_sach_khoa))

100.000 tệp với 50 luồng song song
    → hoàn tất trong vài phút

Và nên chạy từ EC2 hoặc Lambda trong CÙNG Region:

Cùng Region với bucket:
    → không tốn phí truyền dữ liệu ra
    → độ trễ thấp nhất

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

  • **B. Duyệt bucket rồi dùng "S3 Select Byte Range Fetch parameter" — đây là phương án gần nhất vì cũng nhắc tới byte range, nhưng nó trộn lẫn hai tính năng khác nhau: S3 Select dùng truy vấn SQL trên nội dung có cấu trúc (CSV, JSON, Parquet), nó không có "byte range fetch parameter". Byte Range Fetch là tính năng riêng của GetObject.
  • **A. Đọc TOÀN BỘ từng tệp rồi trích 250 byte — tải 50 TB thay vì 25 MB: chậm hơn và tốn hơn hàng nghìn lần.
  • **C. Dùng "RDS Import feature" nạp dữ liệu từ S3 vào PostgreSQL — cũng phải nạp toàn bộ 50 TB, và RDS for PostgreSQL không có tính năng nhập trực tiếp từ S3 theo cách mô tả (chỉ có aws_s3 extension cho tệp CSV).

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

Phương án B nhắc tới S3 Select — dịch vụ AWS đã ngừng cung cấp cho khách hàng mới.

S3 Select cho phép chạy SQL đơn giản trên
  một object CSV, JSON hoặc Parquet
    → trả về CHỈ phần dữ liệu khớp
        ↓
    AWS đã ngừng nhận khách hàng mới cho S3 Select
    → khuyến nghị dùng Amazon Athena thay thế

Điều đó khiến phương án B sai theo cả hai nghĩa: nó mô tả một tham số không tồn tại, và dịch vụ mà nó nhắc tới không còn được khuyến nghị.

Phân biệt ba tính năng dễ nhầm: | Tính năng | Việc | |---|---| | Byte Range Fetch | lấy một KHOẢNG BYTE bất kỳ ← câu này | | S3 Select (legacy) | truy vấn SQL trong MỘT object có cấu trúc | | Amazon Athena | truy vấn SQL trên NHIỀU object |

Ghi nhớ

Ba trường hợp dùng Byte Range Fetch: | Trường hợp | Chi tiết | |---|---| | Đọc header hoặc metadata đầu tệp | ← câu này | | Tải song song nhiều phần của một tệp lớn | tăng thông lượng | | Tiếp tục tải sau khi đứt kết nối | |

Tải song song một tệp lớn:

def tai_mot_phan(khoa, bat_dau, ket_thuc):
    return s3.get_object(Bucket=b, Key=khoa,
                         Range=f'bytes={bat_dau}-{ket_thuc}')['Body'].read()

Chia tệp 10 GB thành 20 phần, tải song song
    → nhanh hơn nhiều so với tải tuần tự
    → AWS CLI tự làm việc này

Ba cách lấy metadata của object mà KHÔNG tải nội dung: | Cách | Lấy gì | |---|---| | HeadObject | kích thước, ETag, content-type, metadata tuỳ chỉnh | | ListObjectsV2 | khoá, kích thước, lớp lưu trữ | | S3 Inventory | danh sách hàng loạt dạng tệp |

Nếu metadata đã có trong HeadObject thì không cần đọc nội dung:

r = s3.head_object(Bucket='kho-du-lieu', Key=khoa)
print(r['ContentLength'], r['Metadata'])

S3 Inventory rất phù hợp với 100.000 tệp:

aws s3api put-bucket-inventory-configuration --bucket kho-du-lieu   --id danh-sach-hang-ngay --inventory-configuration '{
    "Destination":{"S3BucketDestination":{
      "Bucket":"arn:aws:s3:::bao-cao","Format":"Parquet"}},
    "IsEnabled":true,"Id":"danh-sach-hang-ngay",
    "IncludedObjectVersions":"Current",
    "Schedule":{"Frequency":"Daily"},
    "OptionalFields":["Size","LastModifiedDate","ETag","StorageClass"]}'

Xuất danh sách MỌI object dạng tệp
    → không phải gọi ListObjects hàng nghìn lần
        ↓
    Dùng làm đầu vào cho việc duyệt

Ba cách chạy việc duyệt hàng loạt: | Cách | Đặc điểm | |---|---| | EC2 với nhiều luồng | đơn giản | | Lambda song song | tự co giãn | | S3 Batch Operations | xử lý hàng tỷ object |

S3 Batch Operations với Lambda:

Manifest từ S3 Inventory
    → Batch Operations gọi Lambda cho MỖI object
    → Lambda đọc 250 byte và ghi vào RDS
        ↓
    AWS lo việc chia việc, thử lại, báo cáo tiến độ

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Chạy trong CÙNG Region với bucket | | | Song song hoá | S3 chịu được rất nhiều request | | Dùng connection pool cho RDS | tránh cạn kết nối |

Ba giới hạn của S3 cần biết: | Giới hạn | Giá trị | |---|---| | Request GET mỗi prefix | 5.500/giây | | Request PUT mỗi prefix | 3.500/giây | | — | dùng nhiều prefix để nhân lên |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | GET request | ~0,0004 USD mỗi 1.000 | | Byte Range Fetch tính như một GET | dù chỉ lấy 250 byte | | Truyền dữ liệu trong Region | miễn phí |

100.000 GET request ≈ 0,04 USD — chi phí không đáng kể.

Ba lưu ý khi ghi vào RDS: | Lưu ý | Chi tiết | |---|---| | Ghi theo lô thay vì từng dòng | nhanh hơn nhiều | | Dùng COPY hoặc INSERT nhiều dòng | | | Tạo index SAU khi nạp xong | |

Và một lời khuyên: hãy kiểm tra xem thông tin bạn cần có nằm sẵn trong metadata của object không trước khi đọc nội dung. Nếu ứng dụng ghi tệp có thể gắn metadata tuỳ chỉnh lúc tải lên, thì HeadObject lấy được thông tin đó mà không đọc một byte nội dung nào — nhanh hơn và rẻ hơn cả Byte Range Fetch.

Câu 785 Chọn nhiều đáp án Design Cost-Optimized Architectures

A technology startup has stabilized its cloud infrastructure after a successful product launch. The backend services are now running at a predictable rate with minimal scaling events. The application architecture includes workloads running on Amazon EC2, AWS Lambda functions for asynchronous processing, container workloads on AWS Fargate, and machine learning inference models deployed with Amazon SageMaker. The company is now focusing on reducing long-term operational expenses without redesigning its architecture. The company wants to apply long-term pricing discounts with the least administrative overhead and the broadest service coverage possible using the fewest number of savings plans.

Which combination of savings plans will satisfy these requirements? (Select two)

  1. A

    Purchase an EC2 Instance Savings Plan that covers EC2 and containerized tasks on Amazon ECS running with Fargate launch type
  2. B

    Purchase a Compute Savings Plan that provides cost savings for usage across EC2, Fargate, and Lambda services
  3. C

    Create a Reserved Instance for each EC2 instance and subscribe to AWS Support to monitor Reserved Instance utilization monthly
  4. D

    Subscribe to a hybrid deployment discount plan that includes discounts for both AWS and on-premises Kubernetes workloads
  5. E

    Purchase a SageMaker Savings Plan that applies discounted pricing to SageMaker training, inference, and notebook instances
Xem giải thích

Đáp án

B và E.

  • B — Mua Compute Savings Plan phủ EC2, Fargate và Lambda
  • E — Mua SageMaker Savings Plan cho training, inference và notebook instance

Vì sao đúng

Đề nêu bốn tải và yêu cầu ít số lượng savings plan nhất với phạm vi rộng nhất: | Tải | Được phủ bởi | |---|---| | EC2 | Compute Savings Plan | | AWS Lambda | Compute Savings Plan | | AWS Fargate | Compute Savings Plan | | Amazon SageMaker | SageMaker Savings Plan |

Điểm mấu chốt: Compute Savings Plan phủ ba dịch vụ trong một cam kết.

Compute Savings Plan:
    ✓ EC2 (mọi họ, mọi cỡ, mọi Region)
    ✓ Fargate (ECS và EKS)
    ✓ Lambda
        ↓
    MỘT cam kết cho ba dịch vụ

Và SageMaker cần plan RIÊNG:

SageMaker KHÔNG nằm trong Compute Savings Plan
    → phải mua SageMaker Savings Plan riêng
        ↓
    Đó là lý do cần ĐÚNG HAI plan, không ít hơn được

Mua Compute Savings Plan:

aws savingsplans describe-savings-plans-offering-rates   --savings-plan-types Compute --products EC2 Fargate Lambda

aws savingsplans create-savings-plan   --savings-plan-offering-id <id>   --commitment 10.0 --upfront-payment-amount 0

--commitment 10.0 nghĩa là cam kết 10 USD mỗi giờ — mọi chi tiêu tới mức đó được hưởng giá ưu đãi.

Và cách tính khác hẳn Reserved Instance:

Reserved Instance: cam kết theo LOẠI INSTANCE cụ thể
Savings Plan:      cam kết theo SỐ TIỀN mỗi giờ
        ↓
    Đổi loại instance, đổi Region, chuyển sang Fargate
    → vẫn được hưởng ưu đãi

Và đề nói tải đã ỔN ĐỊNH — điều kiện đúng để cam kết:

"running at a predictable rate with minimal scaling events"
        ↓
    Đây là lúc mua cam kết dài hạn có lợi nhất

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

  • **A. Mua EC2 Instance Savings Plan phủ EC2 và Fargate — đây là phương án gần nhất và EC2 Instance Savings Plan là sản phẩm có thật với mức giảm cao hơn (tới 72%), nhưng nó KHÔNG phủ Fargate hay Lambda: nó chỉ áp cho một họ instance trong một Region. Mệnh đề trong phương án sai.
  • **C. Tạo Reserved Instance cho từng EC2 và theo dõi thủ công — nhiều công quản trị nhất và phạm vi hẹp nhất: không phủ Lambda, Fargate hay SageMaker, và đi ngược yêu cầu "least administrative overhead".
  • **D. Đăng ký "hybrid deployment discount plan" cho cả AWS lẫn Kubernetes tại chỗ — không phải sản phẩm có thật.

Ghi nhớ

Ba loại Savings Plans — bảng phải thuộc: | Loại | Phủ | Tiết kiệm | |---|---|---| | Compute Savings Plan | EC2, Fargate, Lambda — mọi Region, mọi họ | tới 66% | | EC2 Instance Savings Plan | MỘT họ instance, MỘT Region | tới 72% | | SageMaker Savings Plan | SageMaker: training, inference, notebook | tới 64% |

Bảng này là toàn bộ nội dung câu hỏi.

Từ khoá nhận diện:

"broadest coverage", "fewest plans", "EC2 + Lambda + Fargate" → Compute Savings Plan "maximum discount, fixed instance family" → EC2 Instance Savings Plan "machine learning workloads" → SageMaker Savings Plan

Savings Plans và Reserved Instances — bảng phân biệt: | | Savings Plans | Reserved Instances | |---|---|---| | Cam kết theo | USD/giờ | loại instance cụ thể | | Linh hoạt | cao | thấp | | Áp cho Lambda, Fargate | ✅ (Compute SP) | ❌ | | Bán lại trên marketplace | ❌ | ✅ (Standard RI) | | Áp cho RDS, ElastiCache, Redshift | ❌ | ✅ |

Dòng cuối là điểm quan trọng: Savings Plans không áp cho database — những dịch vụ đó vẫn dùng Reserved Instance.

Ba dịch vụ vẫn dùng Reserved Instance: | Dịch vụ | Chi tiết | |---|---| | RDS | Reserved DB Instance | | ElastiCache | Reserved Node | | Redshift, OpenSearch | Reserved Node |

Ba mức cam kết: | Kỳ hạn và trả trước | Tiết kiệm | |---|---| | 1 năm, không trả trước | thấp nhất | | 1 năm, trả trước một phần | vừa | | 3 năm, trả trước toàn bộ | cao nhất |

Ba nguyên tắc khi mua cam kết: | Nguyên tắc | Chi tiết | |---|---| | TỐI ƯU KÍCH THƯỚC TRƯỚC | đừng khoá lãng phí 1–3 năm | | Cam kết ở mức NỀN, không phải đỉnh | phần đỉnh dùng On-Demand hoặc Spot | | Bắt đầu với 1 năm | linh hoạt hơn |

Dòng đầu là sai lầm tốn kém nhất:

Mua Savings Plan cho hạ tầng đang cấp thừa
    → khoá khoản lãng phí đó suốt 1–3 năm
        ↓
    Chạy Compute Optimizer và thu nhỏ TRƯỚC

Ba công cụ hỗ trợ quyết định: | Công cụ | Việc | |---|---| | Cost Explorer Savings Plans recommendation | gợi ý mức cam kết tối ưu | | Compute Optimizer | thu nhỏ trước khi cam kết | | AWS Budgets coverage/utilization | theo dõi sau khi mua |

aws ce get-savings-plans-purchase-recommendation   --savings-plans-type COMPUTE_SP --term-in-years ONE_YEAR   --payment-option NO_UPFRONT --lookback-period-in-days SIXTY_DAYS

Hai chỉ số cần theo dõi sau khi mua: | Chỉ số | Thấp nghĩa là | |---|---| | Utilization | mua THỪA — cam kết không dùng hết | | Coverage | mua THIẾU — còn chi tiêu ở giá On-Demand |

Nên đặt ngân sách cho cả hai:

aws budgets create-budget --account-id 123456789012   --budget '{"BudgetName":"do-phu-sp","BudgetLimit":{"Amount":"80","Unit":"PERCENT"},
             "TimeUnit":"DAILY","BudgetType":"SAVINGS_PLANS_COVERAGE"}'

Ba đặc điểm của Savings Plans: | Đặc điểm | Chi tiết | |---|---| | Áp TỰ ĐỘNG cho chi tiêu đủ điều kiện | không phải gán | | Ưu tiên áp cho mức giảm cao nhất trước | | | Dùng chung trong toàn tổ chức | với consolidated billing |

Dòng cuối rất quan trọng với đa tài khoản:

Mua ở tài khoản quản lý
    → tự áp cho MỌI tài khoản thành viên
        ↓
    Không phải mua riêng ở từng tài khoản

Ba cách tiết kiệm khác: | Cách | Tiết kiệm | |---|---| | Spot cho tải chịu gián đoạn | tới 90% | | Graviton | ~20% cho cùng hiệu năng | | Tối ưu kích thước | tuỳ mức cấp thừa |

Và một lời khuyên: hãy chạy Compute Optimizer và thu nhỏ hạ tầng trước khi mua bất kỳ Savings Plan nào. Đề nói tải đã ổn định — đó đúng là lúc nên cam kết, nhưng cũng đúng là lúc dễ khoá nhầm một mức chi tiêu vốn có thể giảm 30% chỉ bằng việc đổi cỡ instance.

Câu 786 Design Secure Architectures

Your application is deployed on Amazon EC2 instances fronted by an Application Load Balancer. Recently, your infrastructure has come under attack. Attackers perform over 100 requests per second, while your normal users only make about 5 requests per second.

How can you efficiently prevent attackers from overwhelming your application?

  1. A

    Use AWS Shield Advanced and setup a rate-based rule
  2. B

    Use an AWS Web Application Firewall (AWS WAF) and setup a rate-based rule
  3. C

    Define a network access control list (network ACL) on your Application Load Balancer
  4. D

    Configure Sticky Sessions on the Application Load Balancer
Xem giải thích

Đáp án

B — Dùng AWS WAF và thiết lập rate-based rule.

Vì sao đúng

Đề cho hai con số, và chúng chỉ thẳng tới rate-based rule:

Kẻ tấn công: hơn 100 request mỗi giây
Người dùng bình thường: khoảng 5 request mỗi giây
        ↓
    Chênh lệch 20 lần
    → đặt ngưỡng ở giữa là phân biệt được

Rate-based rule của WAF:

Đếm số request từ MỖI IP trong cửa sổ trượt
    → vượt ngưỡng → CHẶN IP đó
    → tự bỏ chặn khi tốc độ giảm
        ↓
    Không cần danh sách IP viết tay

Cấu hình:

aws wafv2 create-web-acl --name acl-chong-lam-dung   --scope REGIONAL --default-action Allow={}   --rules '[{
    "Name":"gioi-han-toc-do","Priority":1,
    "Statement":{"RateBasedStatement":{
      "Limit":600,"EvaluationWindowSec":300,"AggregateKeyType":"IP"}},
    "Action":{"Block":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"gioiHan"}}]'   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=aclChongLamDung

Tính ngưỡng:

Người dùng bình thường: 5 request/giây × 300 giây = 1.500
Kẻ tấn công: 100 request/giây × 300 giây = 30.000
        ↓
    Đặt Limit ở khoảng 3.000–5.000 cho cửa sổ 5 phút
    → chặn kẻ tấn công, không chạm người dùng thật

Và gắn vào ALB:

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

Và có thể thu hẹp phạm vi bằng scope-down statement:

{"RateBasedStatement": {
  "Limit": 300, "AggregateKeyType": "IP",
  "ScopeDownStatement": {"ByteMatchStatement": {
    "SearchString": "/dang-nhap", "FieldToMatch": {"UriPath": {}},
    "PositionalConstraint": "STARTS_WITH",
    "TextTransformations": [{"Priority":0,"Type":"LOWERCASE"}]}}}}

Giới hạn chặt riêng cho trang đăng nhập — chống dò mật khẩu mà không ảnh hưởng phần còn lại.

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

  • **A. Dùng AWS Shield Advanced và thiết lập rate-based rule — đây là phương án gần nhất và Shield Advanced thật sự bao gồm WAF miễn phí, nhưng nó quá tốn kém cho bài toán này: Shield Advanced có phí khoảng 3.000 USD mỗi tháng và dành cho tấn công DDoS quy mô lớn. Rate-based rule vốn là tính năng của WAF, mua Shield Advanced chỉ để có nó là không cần thiết.
  • **C. Định nghĩa network ACL trên Application Load Balancer — hai lỗi: NACL áp cho subnet, không gắn vào ALB; và NACL không đếm được tốc độ request, chỉ chặn theo IP tĩnh.
  • **D. Cấu hình sticky session — hoàn toàn không liên quan: sticky session giữ người dùng ở cùng một target, không giới hạn tốc độ gì.

Ghi nhớ

WAF và Shield — bảng phải thuộc: | | AWS WAF | AWS Shield | |---|---|---| | Tầng | 7 (HTTP) | 3, 4 (và 7 với Advanced) | | Chặn | SQLi, XSS, bot, tốc độ cao | DDoS thể tích lớn | | Chi phí | ~5 USD/tháng + rule + request | Standard miễn phí, Advanced ~3.000 USD/tháng | | Rate limiting | ✅ rate-based rule | qua WAF |

Shield Standard đã tự động và miễn phí cho mọi tài khoản.

Ba đặc điểm của rate-based rule: | Đặc điểm | Chi tiết | |---|---| | Cửa sổ đánh giá 60, 120, 300 hoặc 600 giây | | | Ngưỡng tối thiểu 10 request | | | Tự bỏ chặn khi tốc độ giảm | |

Ba cách gộp khoá đếm (AggregateKeyType): | Kiểu | Đếm theo | |---|---| | IP | địa chỉ IP nguồn ← phổ biến nhất | | FORWARDED_IP | IP trong header X-Forwarded-For | | CUSTOM_KEYS | header, cookie, query, hoặc kết hợp |

CUSTOM_KEYS rất mạnh:

{"CustomKeys": [
  {"Header": {"Name": "x-api-key",
              "TextTransformations": [{"Priority":0,"Type":"NONE"}]}}]}

Giới hạn theo API key thay vì IP
    → nhiều người dùng sau cùng một NAT không bị ảnh hưởng lẫn nhau

Ba hành động của rule: | Hành động | Chi tiết | |---|---| | Block | chặn | | Count | chỉ đếm — dùng để THỬ ngưỡng an toàn | | CAPTCHA / Challenge | thử thách thay vì chặn thẳng |

CAPTCHA là lựa chọn tốt hơn Block trong nhiều trường hợp:

Block: người dùng thật bị chặn oan không có cách nào qua
CAPTCHA: người thật giải được, bot thì không
        ↓
    Giảm rủi ro chặn nhầm

Ba nhóm managed rule nên bật kèm: | Nhóm | Chống lại | |---|---| | AWSManagedRulesCommonRuleSet | OWASP Top 10 | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesBotControlRuleSet | bot (có phí thêm) |

Ba tài nguyên gắn được WAF: | Tài nguyên | Scope | |---|---| | CloudFront | CLOUDFRONT (us-east-1) | | ALB, API Gateway, AppSync, Cognito | REGIONAL | | NLB, EC2 | ❌ |

Ba lưu ý khi đặt ngưỡng: | Lưu ý | Chi tiết | |---|---| | Chạy Count trước vài ngày | xem bao nhiêu request khớp | | Tính từ hành vi người dùng THẬT | không đoán | | Chừa biên cho người dùng nặng hợp lệ | |

Ba lưu ý về NAT và IP dùng chung: | Lưu ý | Chi tiết | |---|---| | Văn phòng, trường học dùng chung IP | | | Chặn theo IP có thể ảnh hưởng nhiều người | | | Cân nhắc CUSTOM_KEYS hoặc CAPTCHA | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BlockedRequests | tăng đột biến = đang bị tấn công | | CountedRequests | rule đang ở chế độ thử | | AllowedRequests | |

Ba biện pháp bảo vệ bổ sung: | Biện pháp | Chi tiết | |---|---| | CloudFront trước ALB | chặn ở biên, gần kẻ tấn công | | Shield Advanced nếu bị DDoS nhắm mục tiêu | có đội hỗ trợ và bảo vệ chi phí | | Auto Scaling để chịu tải đột biến | |

Ba lưu ý về log của WAF: | Lưu ý | Chi tiết | |---|---| | Gửi vào S3, CloudWatch Logs hoặc Firehose | | | Che trường nhạy cảm | mật khẩu, token | | Sampled requests xem ngay trong console | không cần bật log |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Web ACL | ~5 USD/tháng | | Mỗi rule | ~1 USD/tháng | | Mỗi triệu request | ~0,60 USD |

Và một lời khuyên: hãy đặt rate-based rule ở chế độ Count trong vài ngày trước khi bật Block. Con số "5 request mỗi giây" trong đề là mức trung bình — luôn có người dùng hợp lệ vượt xa mức đó, và chế độ đếm cho bạn biết chính xác bao nhiêu người sẽ bị ảnh hưởng trước khi quyết định.

Câu 787 AWS Networking & Content Delivery

A global logistics company hosts its shipment tracking system in the eu-west-1 Region. The system runs on Amazon EC2 instances, and customers access the shipment tracking API to retrieve real-time updates about their packages. Customers from Asia and South America report slower API response times compared to customers in Europe.

The company wants to improve API response times for international customers in a cost-effective manner.

Which solution will meet these requirements MOST cost-effectively?

  1. A

    Deploy EC2 instances hosting the API in Asia and South America. Use an Application Load Balancer to distribute traffic across all Regions based on the geolocation of customer requests.
  2. B

    Establish an AWS Direct Connect connection with a public virtual interface (VIF) from each international customer's data center to the eu-west-1 Region. Route API requests over the Direct Connect connection to the shipment tracking system.
  3. C

    Use AWS Global Accelerator to route traffic through the closest AWS edge location to customers. Configure endpoint groups for the shipment tracking API to distribute traffic globally and reduce response times.
  4. D

    Deploy Amazon CloudFront in front of the API. Configure the API response to be cached and use the CachingOptimized managed policy to improve efficiency and reduce latency for frequently requested data.
Xem giải thích

Đáp án

C — Dùng AWS Global Accelerator định tuyến lưu lượng qua edge location gần khách hàng nhất; cấu hình endpoint group cho API theo dõi vận đơn.

Vì sao đúng

Đề nêu ba ràng buộc, và Global Accelerator đáp ứng cả ba: | Ràng buộc | Cơ chế | |---|---| | Cải thiện độ trễ cho châu Á và Nam Mỹ | lưu lượng vào mạng riêng AWS ở edge gần nhất | | Dữ liệu THỜI GIAN THỰC | không đệm — đúng cho nội dung động | | Tiết kiệm chi phí nhất | không phải nhân bản hạ tầng |

Cơ chế giảm độ trễ:

Không có Global Accelerator:
    Khách ở São Paulo → Internet công cộng → eu-west-1
        ↓
    Nhiều chặng qua nhiều nhà mạng
    → độ trễ cao và BIẾN ĐỘNG

Có Global Accelerator:
    Khách ở São Paulo → edge location São Paulo
        → MẠNG RIÊNG của AWS → eu-west-1
        ↓
    Ít chặng công cộng, độ trễ thấp và ổn định hơn

Triển khai:

aws globalaccelerator create-accelerator --name tang-toc-api --enabled

aws globalaccelerator create-listener --accelerator-arn <arn>   --protocol TCP --port-ranges FromPort=443,ToPort=443

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region eu-west-1   --endpoint-configurations EndpointId=<arn-alb>,Weight=128

Và chi phí rất thấp so với việc mở rộng đa Region:

Global Accelerator: ~18 USD/tháng + phí truyền dữ liệu
    → KHÔNG nhân bản EC2, database, hay hạ tầng nào

Triển khai ở 3 Region:
    → gấp 3 chi phí tính toán
    → cộng phức tạp của đồng bộ dữ liệu

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

  • **D. Đặt CloudFront trước API với CachingOptimized — đây là phương án gần nhất và CloudFront cũng có mạng biên toàn cầu, nhưng CachingOptimized sai với dữ liệu THỜI GIAN THỰC: trạng thái vận đơn thay đổi liên tục, đệm sẽ trả về thông tin cũ cho khách hàng. (CloudFront với CachingDisabled vẫn giúp về mặt mạng, nhưng Global Accelerator được thiết kế riêng cho việc tăng tốc TCP như thế này.)
  • **A. Triển khai EC2 ở châu Á và Nam Mỹ, dùng ALB phân phối theo vị trí — hai lỗi: ALB không hoạt động xuyên Region, và triển khai đa Region tốn kém hơn nhiều so với yêu cầu "cost-effectively".
  • **B. Dựng Direct Connect với Public VIF từ trung tâm dữ liệu của TỪNG KHÁCH HÀNG — hoàn toàn không khả thi: khách hàng là người dùng cuối trên Internet, không phải doanh nghiệp có trung tâm dữ liệu để kéo đường riêng.

Ghi nhớ

Global Accelerator và CloudFront — bảng phải thuộc: | | Global Accelerator | CloudFront | |---|---|---| | Cơ chế | định tuyến qua mạng riêng AWS | ĐỆM nội dung ở biên | | Giao thức | TCP và UDP, mọi cổng | HTTP/HTTPS | | Nội dung động | tối ưu cho việc này | có nhưng không đệm được | | Địa chỉ | 2 IP anycast tĩnh | tên miền | | Chuyển vùng Region | ~30 giây | theo origin |

Quy tắc chọn:

Nội dung TĨNH đệm được → CloudFront API động, TCP/UDP, cần IP tĩnh → Global Accelerator

Ba lợi ích của Global Accelerator: | Lợi ích | Chi tiết | |---|---| | Giảm độ trễ và jitter | ← câu này | | 2 IP anycast tĩnh | cho danh sách trắng tường lửa | | Chuyển vùng ~30 giây | không phụ thuộc TTL của DNS |

Ba khái niệm: | Khái niệm | Việc | |---|---| | Accelerator | mang hai IP tĩnh | | Listener | cổng và giao thức | | Endpoint group | một Region, có traffic dial |

Các endpoint được hỗ trợ: | Endpoint | Hỗ trợ | |---|---| | ALB, NLB | ✅ | | EC2 instance | ✅ | | Elastic IP | ✅ | | S3 bucket | ❌ |

Ba yếu tố quyết định định tuyến: | Yếu tố | Chi tiết | |---|---| | Sức khoẻ endpoint | không gửi tới endpoint hỏng | | Traffic dial | tỷ lệ lưu lượng mỗi Region | | Vị trí client | Region gần nhất khoẻ mạnh |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Phí cố định | ~0,025 USD/giờ (~18 USD/tháng) | | Phí truyền dữ liệu cao cấp | theo GB và khu vực | | — | không có phí request |

Ba cách khác giảm độ trễ cho người dùng xa: | Cách | Chi phí | |---|---| | Global Accelerator | thấp | | CloudFront cho phần đệm được | thấp | | Triển khai đa Region | cao |

Ba lưu ý về đo lường: | Đo | Cách | |---|---| | Độ trễ từ nhiều vị trí | CloudWatch Synthetics canary | | Phân bố P50, P95, P99 | quan trọng hơn trung bình | | Tỷ lệ timeout | |

Synthetics canary rất phù hợp:

aws synthetics create-canary --name kiem-tra-api-sao-paulo   --artifact-s3-location s3://ket-qua/   --execution-role-arn <arn> --runtime-version syn-nodejs-puppeteer-6.2   --schedule Expression="rate(5 minutes)"

Chạy từ nhiều Region để đo trải nghiệm thật.

Ba biện pháp bổ sung cho API: | Biện pháp | Chi tiết | |---|---| | Bật HTTP keep-alive | giảm số lần bắt tay TLS | | HTTP/2 | ghép nhiều request trên một kết nối | | Nén phản hồi | giảm byte truyền |

Dòng đầu đáng chú ý với người dùng xa:

Mỗi kết nối mới cần 2–3 vòng lượt cho TCP và TLS
    → với độ trễ 200ms, đó là 400–600ms trước khi
      byte dữ liệu đầu tiên được gửi
        ↓
    Keep-alive loại bỏ chi phí đó cho request tiếp theo

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyEndpointCount | Region nào đang phục vụ | | NewFlowCount | kết nối mới | | ProcessedBytesIn/Out | lưu lượng |

Và một lời khuyên: hãy đo độ trễ P95 từ São Paulo và Singapore trước khi bật Global Accelerator, rồi đo lại sau. Mức cải thiện phụ thuộc vào chất lượng đường Internet cụ thể — thường 20–60%, nhưng con số của chính bạn là thứ duy nhất chứng minh khoản chi này xứng đáng.

Câu 788 AWS Compute

A media processing company is migrating its on-premises application to the AWS Cloud. The application processes high volumes of videos and generates large output files during the workflow.

The company requires a scalable solution to handle an increasing number of video processing jobs. The solution should minimize manual intervention, simplify job orchestration, and eliminate the need to manage infrastructure. Operational overhead must be kept to a minimum.

Which solution will fulfill these requirements with the LEAST operational overhead?

  1. A

    Use a fleet of Amazon EC2 Spot Instances to process the videos. Use AWS Step Functions for workflow management and store the processed files in Amazon Elastic File System (Amazon EFS).
  2. B

    Use AWS Batch to run video processing jobs. Use AWS Step Functions to manage the workflow. Store the processed files in Amazon S3.
  3. C

    Use Amazon Elastic Container Service (Amazon ECS) with AWS Fargate to process the videos. Use Amazon Simple Queue Service (Amazon SQS) for workflow orchestration and store the processed files in Amazon S3.
  4. D

    Use AWS Lambda and Amazon EC2 On-Demand Instances for video processing. Store the processed files in Amazon FSx for Lustre.
Xem giải thích

Đáp án

B — Dùng AWS Batch chạy công việc xử lý video, Step Functions quản lý luồng, lưu tệp kết quả vào Amazon S3.

Vì sao đúng

Đề nêu bốn yêu cầu, và bộ ba này đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Xử lý khối lượng lớn công việc | AWS Batch quản lý hàng đợi và năng lực | | Không quản lý hạ tầng | Batch tự cấp và thu hồi năng lực | | Đơn giản hoá điều phối công việc | Step Functions | | Tệp kết quả LỚN | S3, không giới hạn dung lượng |

AWS Batch giải quyết đúng bài toán xử lý theo lô:

AWS Batch tự lo:
    ✓ hàng đợi công việc có độ ưu tiên
    ✓ chọn loại instance phù hợp
    ✓ cấp phát và thu hồi năng lực tự động
    ✓ thử lại khi công việc thất bại
    ✓ hỗ trợ Fargate và Spot
        ↓
    Bạn chỉ định nghĩa CÔNG VIỆC

Và Step Functions lo điều phối:

{"StartAt": "ChuyenMa",
 "States": {
   "ChuyenMa": {
     "Type": "Task",
     "Resource": "arn:aws:states:::batch:submitJob.sync",
     "Parameters": {"JobDefinition":"chuyen-ma-video",
                    "JobName":"chuyen-ma","JobQueue":"hang-doi-video"},
     "Retry": [{"ErrorEquals":["States.ALL"],"MaxAttempts":3,"BackoffRate":2.0}],
     "Next": "TaoThumbnail"},
   "TaoThumbnail": {
     "Type": "Task",
     "Resource": "arn:aws:states:::batch:submitJob.sync",
     "Parameters": {"JobDefinition":"tao-thumbnail",
                    "JobName":"thumbnail","JobQueue":"hang-doi-video"},
     "End": true}}}

.sync khiến Step Functions CHỜ job Batch hoàn tất trước khi sang bước tiếp.

Và S3 đúng cho tệp video lớn:

Tệp video đầu ra có thể hàng GB
    → S3 không giới hạn dung lượng
    → rẻ hơn EFS ~13 lần
    → mọi job ở mọi AZ đều truy cập được

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

  • **C. ECS với Fargate xử lý video, SQS điều phối luồng, lưu vào S3 — đây là phương án gần nhất và cũng là kiến trúc serverless hợp lệ, nhưng nó thiếu điều phối luồng thật sự: SQS là hàng đợi thông điệp, không quản lý được thứ tự các bước và trạng thái công việc. Đề nêu rõ "simplify job orchestration".
  • **A. EC2 Spot fleet + Step Functions, lưu vào EFS — vẫn phải quản lý hạ tầng: tự dựng fleet, tự lo AMI và co giãn. Và EFS đắt hơn S3 nhiều cho tệp lớn.
  • **D. Lambda và EC2 On-Demand, lưu vào FSx for Lustre — Lambda giới hạn 15 phút không đủ cho xử lý video, và trộn hai mô hình tính toán làm kiến trúc phức tạp không cần thiết.

Ghi nhớ

Ba dịch vụ xử lý theo lô — bảng phải thuộc: | Dịch vụ | Đặc điểm | |---|---| | AWS Batch | hàng đợi công việc + tự quản năng lực | | AWS Lambda | ngắn (dưới 15 phút), sự kiện | | Amazon EMR | phân tích dữ liệu lớn |

Từ khoá nhận diện:

"batch jobs", "job queue", "no infrastructure management" → AWS Batch "workflow orchestration", "job state transitions" → Step Functions "message queue" → SQS

SQS và Step Functions — bảng phân biệt: | | SQS | Step Functions | |---|---|---| | Việc | đệm thông điệp | điều phối các BƯỚC | | Biết trạng thái công việc | ❌ | ✅ | | Rẽ nhánh, chạy song song | ❌ | ✅ | | Thử lại khai báo được | tự viết | ✅ | | Lịch sử thực thi | ❌ | ✅ đầy đủ |

Bốn khái niệm của AWS Batch: | Khái niệm | Việc | |---|---| | Compute environment | loại và số lượng năng lực | | Job queue | hàng đợi có độ ưu tiên | | Job definition | container image, vCPU, bộ nhớ | | Job | một lần chạy |

Ba loại compute environment: | Loại | Đặc điểm | |---|---| | Managed Fargate | serverless hoàn toàn | | Managed EC2 | Batch tự cấp instance | | Unmanaged | bạn tự quản |

Fargate là lựa chọn ít công vận hành nhất:

{"type":"MANAGED","computeResources":{
   "type":"FARGATE","maxvCpus":256,
   "subnets":["subnet-a","subnet-c"],"securityGroupIds":["sg-abc"]}}

Và Spot giảm chi phí mạnh:

{"type":"SPOT","bidPercentage":100,
 "allocationStrategy":"SPOT_CAPACITY_OPTIMIZED"}

Xử lý video theo lô chịu được gián đoạn
    → Batch tự thử lại job bị thu hồi
        ↓
    Tiết kiệm tới 90%

Ba tính năng của Step Functions: | Tính năng | Chi tiết | |---|---| | Retry và Catch khai báo | không viết mã xử lý lỗi | | Map state | xử lý song song nhiều phần tử | | Tích hợp trực tiếp 200+ dịch vụ | |

Distributed Map cho xử lý hàng loạt:

{"Type":"Map","ItemProcessor":{"ProcessorConfig":{"Mode":"DISTRIBUTED"}},
 "ItemReader":{"Resource":"arn:aws:states:::s3:listObjectsV2",
               "Parameters":{"Bucket":"video-dau-vao"}},
 "MaxConcurrency":1000}

Hai loại workflow: | Loại | Đặc điểm | |---|---| | Standard | tới 1 năm, có lịch sử đầy đủ | | Express | tới 5 phút, thông lượng cao, rẻ hơn |

Với xử lý video chạy lâu, Standard là lựa chọn đúng.

Ba lựa chọn thay thế cho xử lý video: | Lựa chọn | Đặc điểm | |---|---| | AWS Batch | ← câu này, linh hoạt | | AWS Elemental MediaConvert | dịch vụ chuyển mã được quản lý | | ECS/Fargate tự dựng | công vận hành cao hơn |

MediaConvert đáng cân nhắc mạnh:

Trả theo PHÚT video xử lý
    → không quản hạ tầng nào
    → hỗ trợ sẵn mọi định dạng và profile
        ↓
    Với chuyển mã thuần tuý, đây là lựa chọn ít
      công vận hành nhất

Ba lưu ý về S3 cho video: | Lưu ý | Chi tiết | |---|---| | Multipart upload cho tệp lớn | bắt buộc trên 5 GB | | Lifecycle chuyển bản gốc sang lớp rẻ | | | AbortIncompleteMultipartUpload | dọn phần dở dang |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Số job ở trạng thái RUNNABLE | tồn đọng | | Tỷ lệ job FAILED | | | Thời gian từ submit tới hoàn tất | |

Ba lưu ý về job definition: | Lưu ý | Chi tiết | |---|---| | Dùng container image trong ECR | | | Khai đúng vCPU và bộ nhớ | ảnh hưởng chi phí | | Đặt timeout | tránh job treo |

Và một lời khuyên: hãy đánh giá AWS Elemental MediaConvert trước khi tự dựng đường ống Batch. Nếu công việc chủ yếu là chuyển mã video sang nhiều định dạng, MediaConvert bỏ hẳn phần định nghĩa job, quản lý container và tối ưu năng lực — và với yêu cầu "least operational overhead" thì đó là khác biệt lớn.

Câu 789 AWS Compute

A logistics company is running a containerized application on an Amazon Elastic Kubernetes Service (Amazon EKS) cluster with Amazon EC2 instances as the worker nodes. The application includes a management dashboard that uses Amazon DynamoDB for real-time tracking data and a reporting service that stores large datasets in Amazon S3.

The company needs to ensure that the EKS Pods running the management dashboard can access only Amazon DynamoDB, and the EKS Pods running the reporting service can access only Amazon S3. The company uses AWS Identity and Access Management (IAM) for access control.

Which solution will meet these requirements?

  1. A

    Create IAM roles with permissions for Amazon S3 and DynamoDB access. Attach the Amazon S3 role to the reporting service Pods and the DynamoDB role to the management dashboard Pods using a shared service account.
  2. B

    Configure role-based access control (RBAC) within Kubernetes to define which Pods can access Amazon S3 and DynamoDB. Use Kubernetes ConfigMaps to store the IAM credentials for each service.
  3. C

    Create separate IAM roles with policies for Amazon S3 and DynamoDB access. Use Kubernetes service accounts with IAM Role for Service Accounts (IRSA) to assign the AmazonS3FullAccess policy to the reporting service Pods and the AmazonDynamoDBFullAccess policy to the management dashboard Pods.
  4. D

    Create separate IAM policies for Amazon S3 and DynamoDB access. Attach both policies to the IAM role associated with the EC2 instance profile. Use Kubernetes namespaces to restrict access for the respective Pods to Amazon S3 or DynamoDB.
Xem giải thích

Đáp án

C — Tạo IAM role riêng cho S3 và DynamoDB, dùng Kubernetes service account với IAM Roles for Service Accounts (IRSA) để gán role tương ứng cho từng nhóm Pod.

Vì sao đúng

Đề yêu cầu phân quyền ở cấp POD, và IRSA là cơ chế duy nhất làm được điều đó.

Không có IRSA:
    → mọi Pod trên một node dùng chung
      IAM role của EC2 instance profile
        ↓
    Pod dashboard và Pod reporting có QUYỀN GIỐNG NHAU
    → không tách được

IRSA hoạt động qua OIDC:

① EKS cluster có một OIDC provider
② IAM tin cậy provider đó
③ Service account trong Kubernetes được gắn annotation
     eks.amazonaws.com/role-arn
④ Pod dùng service account đó nhận token OIDC
⑤ Token đổi lấy credential AWS tạm thời qua STS
        ↓
    Mỗi Pod chỉ có đúng quyền của role gắn với
      service account của nó

Thiết lập:

eksctl utils associate-iam-oidc-provider --cluster cum-logistics --approve

eksctl create iamserviceaccount   --cluster cum-logistics --namespace mac-dinh   --name sa-dashboard   --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess   --approve

eksctl create iamserviceaccount   --cluster cum-logistics --namespace mac-dinh   --name sa-bao-cao   --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess   --approve

Và Pod khai service account:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dashboard
spec:
  template:
    spec:
      serviceAccountName: sa-dashboard

Và credential là TẠM THỜI:

Token OIDC có hạn
    → SDK tự đổi lấy credential AWS mới
        ↓
    KHÔNG có access key dài hạn nào trong cụm

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

  • **A. Tạo IAM role rồi gắn vào Pod qua một service account DÙNG CHUNG — đây là phương án gần nhất vì cũng dùng service account, nhưng service account dùng chung nghĩa là quyền dùng chung: cả hai nhóm Pod sẽ có cả hai quyền, đúng điều đề muốn tránh.
  • **B. Dùng Kubernetes RBAC và lưu credential IAM trong ConfigMap — hai lỗi nghiêm trọng: RBAC kiểm soát quyền trong Kubernetes API, không kiểm soát quyền tới dịch vụ AWS; và ConfigMap không mã hoá, lưu credential ở đó là lỗ hổng bảo mật.
  • **D. Gắn cả hai policy vào instance profile rồi dùng namespace để hạn chế — namespace không phải ranh giới quyền AWS: mọi Pod trên node vẫn lấy được credential của instance profile qua metadata service, bất kể nằm ở namespace nào.

Ghi nhớ

Ba cách cấp quyền AWS cho Pod trên EKS — bảng phải thuộc: | Cách | Mức chi tiết | |---|---| | EC2 instance profile | cả NODE — mọi Pod dùng chung | | IRSA (IAM Roles for Service Accounts) | từng SERVICE ACCOUNT | | EKS Pod Identity | từng service account, đơn giản hơn IRSA |

EKS Pod Identity là cơ chế mới hơn:

aws eks create-pod-identity-association   --cluster-name cum-logistics --namespace mac-dinh   --service-account sa-dashboard --role-arn <arn-role>

So với IRSA:
    ✓ KHÔNG cần OIDC provider
    ✓ KHÔNG cần sửa trust policy khi đổi cụm
    ✓ role dùng lại được giữa nhiều cụm
        ↓
    AWS khuyến nghị cho thiết lập mới

IRSA và Pod Identity — bảng phân biệt: | | IRSA | Pod Identity | |---|---|---| | Cần OIDC provider | ✅ | ❌ | | Trust policy | ràng buộc theo cụm | đơn giản, dùng lại được | | Cần EKS add-on | ❌ | ✅ Pod Identity Agent | | Hỗ trợ Fargate | ✅ | kiểm tra phiên bản |

Ba lớp phân quyền trong EKS: | Lớp | Kiểm soát | |---|---| | Kubernetes RBAC | quyền trong Kubernetes API | | IRSA / Pod Identity | quyền tới dịch vụ AWS | | IAM cho cụm | ai quản trị được cụm |

Ba lớp này độc lập — đây là điểm phương án B hiểu sai.

Ba lưu ý về bảo mật node: | Lưu ý | Chi tiết | |---|---| | Chặn Pod truy cập instance metadata | tránh lấy credential của node | | Bắt buộc IMDSv2 | | | Đặt hop limit = 1 | container không gọi được metadata |

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-tokens required --http-put-response-hop-limit 1

Hop limit = 1
    → gói tin từ container (thêm một hop) bị chặn
        ↓
    Pod KHÔNG lấy được credential của node
    → buộc phải dùng IRSA

Ba nguyên tắc quyền tối thiểu: | Nguyên tắc | Chi tiết | |---|---| | Tránh policy FullAccess | đề dùng nó chỉ để minh hoạ | | Giới hạn theo tài nguyên cụ thể | ARN của bảng và bucket | | Dùng condition khi được | |

Policy chặt hơn cho Pod dashboard:

{"Effect": "Allow",
 "Action": ["dynamodb:GetItem","dynamodb:Query","dynamodb:PutItem"],
 "Resource": "arn:aws:dynamodb:*:*:table/theo-doi-van-don"}

Ba thành phần của IRSA: | Thành phần | Việc | |---|---| | OIDC identity provider | IAM tin cậy cụm EKS | | IAM role với trust policy trỏ tới provider | | | Service account có annotation | eks.amazonaws.com/role-arn |

Trust policy của IRSA:

{"Effect": "Allow",
 "Principal": {"Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks..."},
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {"StringEquals": {
   "oidc.eks.ap-northeast-1.amazonaws.com/id/ABC:sub":
     "system:serviceaccount:mac-dinh:sa-dashboard"}}}

Điều kiện sub ràng buộc chính xác service account nào được assume role.

Ba lưu ý khi gỡ lỗi IRSA: | Triệu chứng | Nguyên nhân | |---|---| | Pod dùng credential của node | thiếu annotation trên service account | | AccessDenied khi assume role | trust policy sai sub | | Pod không thấy biến môi trường | cần khởi động lại Pod sau khi sửa |

kubectl exec -it <pod> -- env | grep AWS
# AWS_ROLE_ARN=...
# AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/...

Ba lưu ý về EKS nói chung: | Lưu ý | Chi tiết | |---|---| | Fargate profile bỏ hẳn việc quản node | | | Managed node group tự vá lỗi | | | aws-auth ConfigMap ánh xạ IAM sang RBAC | |

Ba dịch vụ hay dùng với IRSA: | Dịch vụ | Việc | |---|---| | AWS Load Balancer Controller | tạo ALB từ Ingress | | EBS CSI Driver | cấp volume | | External Secrets Operator | lấy bí mật từ Secrets Manager |

Và một lời khuyên: hãy đặt hop limit của metadata service về 1 trên mọi node EKS. Nếu không, một Pod bị xâm nhập vẫn lấy được credential của instance profile và bỏ qua toàn bộ phân quyền IRSA bạn vừa thiết lập — đó là lỗ hổng làm vô hiệu hoá cả kiến trúc.

Câu 790 AWS Compute

Amazon EC2 instances in an Auto Scaling group. The application stores temporary training data on attached Amazon Elastic Block Store (Amazon EBS) volumes. The company seeks recommendations to optimize costs for the EC2 instances, the Auto Scaling group, and the EBS volumes with minimal manual intervention.

Which solution will meet these requirements with the MOST operational efficiency?

  1. A

    Use AWS Cost and Usage Reports to export data to Amazon Athena. Query the data to identify inefficiencies in the EC2 instances, the Auto Scaling group, and the EBS volumes.
  2. B

    Set up Amazon CloudWatch billing alerts and manually analyze metrics to identify cost-saving opportunities for the EC2 instances, the Auto Scaling group, and the EBS volumes.
  3. C

    Configure AWS Compute Optimizer to provide cost optimization recommendations for the EC2 instances, the Auto Scaling group, and the EBS volumes.
  4. D

    Use AWS Compute Optimizer for recommendations on EC2 instances and Auto Scaling groups. Use Amazon Data Lifecycle Manager to evaluate cost optimizations for the EBS volumes.
Xem giải thích

Đáp án

C — Cấu hình AWS Compute Optimizer để nhận khuyến nghị tối ưu chi phí cho EC2 instance, Auto Scaling group và EBS volume.

Vì sao đúng

Đề nêu ba loại tài nguyên, và Compute Optimizer phân tích cả ba trong một công cụ: | Tài nguyên | Compute Optimizer hỗ trợ | |---|---| | EC2 instance | ✅ khuyến nghị loại và cỡ | | Auto Scaling group | ✅ khuyến nghị loại instance | | EBS volume | ✅ khuyến nghị loại và IOPS |

Và khuyến nghị dựa trên ĐO ĐẠC, không phải phỏng đoán:

Compute Optimizer phân tích metric CloudWatch (14 ngày mặc định):
    → CPU, bộ nhớ (nếu có agent), mạng, đĩa
    → so với đặc tính của mọi loại instance
        ↓
    Đưa ra tối đa 3 lựa chọn thay thế
    → kèm ước tính tiết kiệm và mức rủi ro hiệu năng

Bật:

aws compute-optimizer update-enrollment-status --status Active   --include-member-accounts

Xem khuyến nghị:

aws compute-optimizer get-ec2-instance-recommendations   --query 'instanceRecommendations[?finding==`Overprovisioned`].{
    Id:instanceArn,HienTai:currentInstanceType,
    DeXuat:recommendationOptions[0].instanceType}'

aws compute-optimizer get-ebs-volume-recommendations
aws compute-optimizer get-auto-scaling-group-recommendations

Ba phân loại kết quả: | Phân loại | Nghĩa | |---|---| | Overprovisioned | cấp thừa — giảm được | | Underprovisioned | đang THIẾU — nên tăng | | Optimized | phù hợp rồi |

Phân loại thứ hai quan trọng ngang phân loại thứ nhất — nó ngăn bạn thu nhỏ nhầm thứ đang chật vật.

Và với dữ liệu huấn luyện tạm trên EBS, khuyến nghị thường là:

io1 hoặc gp2 cấp thừa
    → chuyển sang gp3
        ↓
    gp3 rẻ hơn gp2 ~20% và cho 3.000 IOPS miễn phí

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

  • **D. Dùng Compute Optimizer cho EC2 và ASG, dùng Data Lifecycle Manager cho EBS — đây là phương án gần nhất và đúng hoàn toàn ở hai vế đầu, nhưng nó gán sai vai trò cho DLM: Data Lifecycle Manager quản lý vòng đời snapshot và AMI, nó không đánh giá hiệu năng hay chi phí của volume. Compute Optimizer đã phân tích EBS rồi.
  • **A. Xuất Cost and Usage Report sang Athena rồi tự truy vấn — nhiều công vận hành: phải viết và bảo trì truy vấn, và CUR chỉ có dữ liệu chi phí, không có metric hiệu năng để biết tài nguyên có cấp thừa không.
  • **B. CloudWatch billing alert và phân tích metric THỦ CÔNG — hoàn toàn thủ công, đi ngược yêu cầu "most operational efficiency".

Ghi nhớ

Các công cụ tối ưu chi phí của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | Compute Optimizer | KHUYẾN NGHỊ kích thước dựa trên METRIC | | Cost Explorer | PHÂN TÍCH chi tiêu và dự báo | | AWS Budgets | CẢNH BÁO và HÀNH ĐỘNG khi vượt ngưỡng | | Cost Optimization Hub | TẬP HỢP mọi khuyến nghị | | Trusted Advisor | kiểm tra tổng quát | | Cost and Usage Report | dữ liệu thô chi tiết nhất |

Từ khoá nhận diện:

"rightsize without impacting performance" → Compute Optimizer "consolidated savings opportunities" → Cost Optimization Hub "where is my money going" → Cost Explorer "alert when exceeding budget" → Budgets

Các tài nguyên Compute Optimizer phân tích: | Tài nguyên | Khuyến nghị | |---|---| | EC2 instance | loại và kích thước | | Auto Scaling group | loại instance | | EBS volume | loại volume và IOPS | | Lambda function | cấu hình bộ nhớ | | ECS service trên Fargate | CPU và bộ nhớ | | RDS (mới) | loại instance | | Commercial software licenses | |

Ba mức độ tin cậy của khuyến nghị: | Yếu tố | Chi tiết | |---|---| | Cần ít nhất 14 ngày metric | ít hơn thì không đủ dữ liệu | | Enhanced infrastructure metrics | dùng 3 THÁNG dữ liệu | | performanceRisk 0–4 | càng thấp càng an toàn |

Enhanced metrics quan trọng với tải có chu kỳ:

Tải chốt sổ cuối tháng
    → 14 ngày dữ liệu có thể bỏ lỡ đỉnh đó
    → khuyến nghị thu nhỏ sai
        ↓
    Bật enhanced metrics để nhìn đủ 3 tháng

Ba metric Compute Optimizer KHÔNG có sẵn: | Metric | Cần gì | |---|---| | Sử dụng bộ nhớ | CloudWatch agent | | Dung lượng đĩa | CloudWatch agent | | — | thiếu chúng, khuyến nghị kém chính xác hơn |

Nên cài CloudWatch agent để có metric bộ nhớ:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl   -a fetch-config -m ec2 -s -c ssm:/cau-hinh/cloudwatch-agent

Bảy hướng tối ưu chi phí — thứ tự nên làm: | Thứ tự | Hướng | |---|---| | ① | Thu nhỏ tài nguyên cấp thừa ← câu này | | ② | Xoá tài nguyên nhàn rỗi | | ③ | Mua Savings Plans SAU KHI thu nhỏ | | ④ | Spot cho tải chịu gián đoạn | | ⑤ | Graviton | | ⑥ | Lifecycle cho S3 và snapshot | | ⑦ | Tắt tài nguyên ngoài giờ |

Thứ tự rất quan trọng:

Mua Savings Plan cho instance cấp thừa
    → khoá khoản lãng phí 1–3 năm
        ↓
    Thu nhỏ TRƯỚC, cam kết SAU

Ba nguồn lãng phí phổ biến với EBS: | Nguồn | Chi tiết | |---|---| | Volume không gắn vào đâu | tính phí đầy đủ | | io1/io2 cấp IOPS thừa | phí IOPS tính riêng | | gp2 chưa chuyển sang gp3 | rẻ hơn ~20% |

Tìm volume mồ côi:

aws ec2 describe-volumes --filters Name=status,Values=available   --query 'Volumes[].{Id:VolumeId,Size:Size,Created:CreateTime}' --output table

Chuyển gp2 sang gp3 hàng loạt:

aws ec2 describe-volumes --filters Name=volume-type,Values=gp2   --query 'Volumes[].VolumeId' --output text |   xargs -n1 -I{} aws ec2 modify-volume --volume-id {} --volume-type gp3

Ba lưu ý về Data Lifecycle Manager: | Lưu ý | Chi tiết | |---|---| | Quản lý vòng đời SNAPSHOT và AMI | | | Tạo và xoá theo lịch, theo tag | | | MIỄN PHÍ | |

DLM hữu ích nhưng cho việc khác — đó là điểm phương án D nhầm.

Ba việc nên làm sau khi có khuyến nghị: | Việc | Chi tiết | |---|---| | Bắt đầu ở môi trường không sản xuất | | | Thay đổi từng đợt nhỏ | dễ quay lại | | Theo dõi metric sau khi đổi | xác nhận hiệu năng |

Và một lời khuyên: hãy bật enhanced infrastructure metrics nếu tải có chu kỳ theo tháng. Với 14 ngày dữ liệu mặc định, một đợt huấn luyện mô hình chạy mỗi tháng có thể hoàn toàn nằm ngoài cửa sổ quan sát — và thu nhỏ instance ngay trước đợt đó là cách nhanh nhất biến một dự án tiết kiệm thành một sự cố.