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

Tìm thấy 1221 câu.

Câu 111 Domain - Design Solutions for Organizational Complexity


A company located on the west coast of North America plans to release a new online service for its customers. The company already created a new VPC in the us-west-1 region where they will launch the Amazon EC2 instances that will host the web application. The application must be highly-available and must dynamically scale based on user traffic. In addition, the company wants to have a disaster recovery site in the us-east-1 region that will act as a passive backup of the running application.

Which of the following options should the Solutions Architect implement in order to achieve the requirements?

  1. A

    Create an Application Load Balancer (ALB) in the us-west-1 region that spans multiple Availability Zones (AZs) of the VPC. Create an Auto Scaling group that will deploy EC2 instances across the multiple AZs and place it behind the ALB. Set up the same configuration to the us-east-1 region VPC. Create record entries in Amazon Route 53 pointing to the ALBs with health check enabled and a failover routing policy.
  2. B

    Configure an Inter-Region VPC peering between the us-west-1 VPC and a new VPC in the us-east-1 region. Create an Application Load Balancer (ALB) that spans multiple Availability Zones (AZs) on both VPCs. Create an Auto Scaling group that will deploy EC2 instances across the multiple AZs of both regions and place it behind the ALB. Create an Alias record entry in Amazon Route 53 that points to the DNS name of the ALB.
  3. C

    Configure an Inter-Region VPC peering between the us-west-1 VPC and a new VPC in the us-east-1 region. Create an Application Load Balancer (ALB) in the us-west-1 region that spans multiple Availability Zones (AZs) of the VPC. Create an Auto Scaling group that will deploy EC2 instances across the multiple AZs of both regions and place it behind the ALB.
  4. D

    Create an Application Load Balancer (ALB) in the us-west-1 region that spans multiple Availability Zones (AZs) of the VPC. Create an Auto Scaling group that will deploy EC2 instances across the multiple AZs and place it behind the ALB. Set up the same configuration to the us-east-1 region VPC. Create separate record entries for each region’s ALB on Amazon Route 53 and enable health checks to ensure high-availability for both regions.
Xem giải thích

Đáp án

**A — Tạo ALB trải nhiều AZ ở us-west-1 với Auto Scaling group phía sau; dựng cấu hình tương tự ở us-east-1; và tạo bản ghi Route 53 trỏ tới hai ALB, bật health check và dùng failover routing.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Sẵn sàng cao | ALB + ASG trên nhiều AZ | | Co giãn theo lưu lượng | Auto Scaling group | | Vùng DR ở us-east-1 kiểu bị động | Route 53 failover routing |

⚠ Failover routing là kiểu định tuyến DUY NHẤT diễn tả được "dự phòng bị động": | Kiểu định tuyến | Hành vi | |---|---| | Failover | chính phục vụ; chính hỏng thì chuyển sang phụ | | Weighted | chia lưu lượng theo tỷ lệ — CẢ HAI cùng phục vụ | | Latency | chọn Region nhanh nhất — cả hai cùng phục vụ | | Geolocation | theo vị trí người dùng |

Đề nói us-east-1 là "passive backup"
    → chỉ nhận lưu lượng khi us-west-1 hỏng
        ↓
    Chỉ failover routing làm đúng điều đó

Đây là lý do phương án D sai — nó tạo bản ghi cho cả hai Region mà không nói kiểu định tuyến nào.

Bản ghi chính:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes": [{"Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "app.congty.com", "Type": "A",
      "SetIdentifier": "chinh-west",
      "Failover": "PRIMARY",
      "HealthCheckId": "<id-health-check>",
      "AliasTarget": {
        "HostedZoneId": "<zone-alb-west>",
        "DNSName": "alb-west.us-west-1.elb.amazonaws.com",
        "EvaluateTargetHealth": true}}}]}'

Bản ghi phụ: giống hệt nhưng "Failover": "SECONDARY" và trỏ tới ALB ở us-east-1.

⚠ EvaluateTargetHealth: true là cấu hình bắt buộc:

Health check của Route 53 kiểm tra
  từ ngoài Internet
        ↓
    `EvaluateTargetHealth` kiểm tra
      chính target khoẻ không
    → ALB không còn target khoẻ nào
      cũng bị coi là hỏng

Tạo health check:

aws route53 create-health-check \
  --caller-reference hc-west-1 \
  --health-check-config '{
    "Type": "HTTPS", "ResourcePath": "/health",
    "FullyQualifiedDomainName": "alb-west.us-west-1.elb.amazonaws.com",
    "RequestInterval": 10, "FailureThreshold": 3}'

⚠ Thời gian chuyển đổi phụ thuộc ba yếu tố:

Khoảng kiểm tra (10 hoặc 30 giây)
    × ngưỡng thất bại (thường 3)
    + TTL của bản ghi DNS
        ↓
    10 × 3 + 60 = khoảng 90 giây
    → đặt TTL 60 giây cho bản ghi failover

⚠ Và ALB không hoạt động xuyên Region — đây là điểm phân biệt với B và C:

Target của ALB phải nằm trong CÙNG VPC
  hoặc VPC đã peering trong CÙNG Region
        ↓
    Một ALB không nhận target ở Region khác
    → mỗi Region phải có ALB riêng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chuyển đổi tự động khi Region chính hỏng | | | Mỗi Region tự chịu lỗi ở mức AZ | | | Region phụ có thể chạy công suất tối thiểu để tiết kiệm | |

⚠ Điểm cuối là quyết định về chi phí phải cân nhắc:

Pilot Light: ASG min = 0 hoặc 1
    → rẻ nhất, nhưng mở rộng mất vài phút
        ↓
    Warm Standby: ASG chạy quy mô nhỏ
    → tốn hơn, chuyển đổi nhanh hơn
        ↓
    Chọn theo RTO chấp nhận được

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

  • **D. Dựng cấu hình giống nhau ở hai Region rồi tạo bản ghi riêng cho mỗi ALB có bật health check — đây là phương án gần nhất và hạ tầng hoàn toàn đúng, nhưng nó không nói kiểu định tuyến; hai bản ghi cùng tên không có Failover sẽ thành round-robin đơn giản, tức là Region phụ nhận lưu lượng ngay — trái với yêu cầu "bị động".
  • **B. Peering hai Region rồi tạo ALB trải AZ trên cả hai VPC với một ASG chung — ALB không nhận target xuyên Region, và ASG không trải Region được.
  • **C. Peering hai Region và tạo một ALB ở us-west-1 với ASG trải AZ của cả hai Region — cùng lỗi trên, và không có cơ chế chuyển đổi nào.

Ghi nhớ

⚠ Bốn chiến lược DR — bảng phải thuộc: | Chiến lược | RTO | Chi phí | |---|---|---| | Backup & Restore | giờ | thấp nhất | | Pilot Light | chục phút | thấp | | Warm Standby | phút | trung bình | | Multi-Site Active-Active | gần 0 | cao nhất |

Từ khoá nhận diện:

"passive backup Region" → Route 53 failover routing "both Regions serve traffic" → latency hoặc weighted routing "failover in seconds, any protocol" → Global Accelerator "gradual migration" → weighted routing

⚠ Global Accelerator chuyển đổi nhanh hơn Route 53: | Tiêu chí | Route 53 failover | Global Accelerator | |---|---|---| | Cơ chế | DNS | anycast tầng mạng | | Phụ thuộc TTL | CÓ | không | | Thời gian chuyển | phút | ~30 giây | | Giao thức | mọi thứ qua DNS | TCP/UDP |

Client cache DNS bất chấp TTL
    → đây là điểm yếu cố hữu của
      chuyển đổi bằng DNS
        ↓
    Global Accelerator: IP không đổi
    → chuyển đích ở tầng mạng

Ba lưu ý về nhân bản dữ liệu: | Dịch vụ | Cách | |---|---| | RDS | read replica xuyên Region | | Aurora | Global Database, độ trễ dưới 1 giây | | DynamoDB | global table, ghi được ở mọi Region | | S3 | Cross-Region Replication |

⚠ Chuyển đổi ở tầng DNS vô nghĩa nếu dữ liệu không sẵn:

Route 53 chuyển sang us-east-1
    → ứng dụng ở đó gọi CSDL...
      ở us-west-1 đã sập
        ↓
    Phải nhân bản dữ liệu TRƯỚC
    → và có kế hoạch thăng cấp replica

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Kiểm tra từ nhiều nơi trên thế giới | | | Đường dẫn phải phản ánh sức khoẻ thật | | | Calculated health check gộp nhiều điều kiện | |

⚠ Health check quá nông và quá sâu đều nguy hiểm:

Quá nông (chỉ trả 200 tĩnh)
    → CSDL chết mà vẫn báo khoẻ
        ↓
    Quá sâu (gọi mọi phụ thuộc)
    → một dịch vụ phụ chậm là
      cả Region bị coi là hỏng
        ↓
    Kiểm tra đúng những phụ thuộc THIẾT YẾU

Ba lưu ý về ASG nhiều AZ: | Lưu ý | Chi tiết | |---|---| | Ít nhất 2 AZ, nên 3 | | | health-check-type ELB | | | Kiểm hạn ngạch ở Region phụ | |

⚠ Hạn ngạch ở Region phụ là bẫy hay gặp nhất khi diễn tập DR:

Region chính chạy 50 instance
    → Region phụ chưa bao giờ chạy quá 2
        ↓
    Hạn ngạch vCPU ở đó vẫn ở mức mặc định
    → lúc chuyển đổi không mở rộng nổi
    → xin tăng hạn ngạch TRƯỚC

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Diễn tập định kỳ, không chờ sự cố thật | | | Dùng Fault Injection Service mô phỏng | | | Đo RTO thật và ghi lại | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt ALB chính, đo thời gian chuyển | | | Kiểm dữ liệu ở Region phụ có mới không | | | Xác nhận Region phụ mở rộng được | |

Và một lời khuyên: hãy diễn tập chuyển đổi ít nhất mỗi quý và bấm giờ thật. Kiến trúc DR trên giấy luôn hoạt động — thứ hỏng là hạn ngạch chưa xin, ảnh AMI chưa sao chép, và bí mật chưa nhân bản, và cả ba chỉ lộ ra khi bạn thật sự thử.

Câu 112 Domain - Continuous Improvement for Existing Solutions

A company has built an application that allows painters to upload photos of their creations. The app allows users from North America and European regions to browse the galleries and order their chosen artworks. The application is hosted on a fixed set of Amazon EC2 instances in the us-east-1 region. Using mobile phones, the artists can scan and upload large, high-resolution images of their artworks which are stored in a centralized Amazon S3 bucket also in the same region. After the initial week of operation, the European artists are reporting slow performance on their image uploads.

Which of the following is the best solution to improve the image upload process?

  1. A

    Enable Amazon S3 Transfer Acceleration on the central S3 bucket. Use the s3-accelerate endpoint to upload the images.
  2. B

    Increase the upload capacity by creating an AWS Global Accelerator endpoint in front of the Amazon EC2 instances. Create an Auto Scaling Group that can scale automatically based on the users' traffic.
  3. C

    Set the centralized Amazon S3 bucket as the custom origin on an Amazon CloudFront distribution. This will use CloudFront’s global edge network to improve the upload speed.
  4. D

    Enable multipart upload on Amazon S3 and redeploy the application to support it. This allows the transmitting of separate parts of the image in parallel.
Xem giải thích

Đáp án

**A — Bật S3 Transfer Acceleration trên bucket trung tâm và dùng endpoint s3-accelerate để tải ảnh lên.

Vì sao đúng

Đề mô tả đúng bài toán mà Transfer Acceleration sinh ra để giải: | Dữ kiện | Ý nghĩa | |---|---| | Bucket ở us-east-1 | hoạ sĩ châu Âu ở xa bucket | | Ảnh độ phân giải cao | tệp lớn | | Chậm khi TẢI LÊN | vấn đề ở chiều upload |

⚠ Cách hoạt động:

Hoạ sĩ ở châu Âu tải lên
    → đi tới POP CloudFront gần nhất
      (vài chục mili giây)
        ↓
    Từ POP đi tiếp tới bucket qua
      MẠNG XƯƠNG SỐNG của AWS
    → không qua Internet công cộng
        ↓
    Đường đi tối ưu, ít mất gói, ít nghẽn

⚠ Lợi ích đến từ việc rút ngắn đoạn đường "xấu":

Internet công cộng: nhiều chặng,
  mất gói, TCP liên tục giảm cửa sổ
        ↓
    Mạng AWS: đường riêng, ổn định
    → tốc độ giữ ở mức cao suốt quá trình

Bật tính năng:

aws s3api put-bucket-accelerate-configuration \
  --bucket kho-anh --accelerate-configuration Status=Enabled

Dùng endpoint tăng tốc:

aws s3 cp anh-lon.tif s3://kho-anh/ \
  --endpoint-url https://kho-anh.s3-accelerate.amazonaws.com

import boto3
from botocore.config import Config
s3 = boto3.client('s3', config=Config(
    s3={'use_accelerate_endpoint': True}))

⚠ Phải dùng ĐÚNG endpoint, bật thôi chưa đủ:

Bật Transfer Acceleration nhưng vẫn gọi
  endpoint thường
        ↓
    Không có gì thay đổi
    → và vẫn không tính phí thêm
    → nên rất dễ tưởng "bật rồi mà
      không nhanh hơn"

Đo thử trước khi cam kết:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html

Công cụ chính thức của AWS
    → so tốc độ có và không tăng tốc
      từ chính vị trí của bạn
        ↓
    Ở gần bucket thì lợi ích rất nhỏ
    → đo trước, đừng bật mù

⚠ Và nên kết hợp với multipart upload:

Tệp lớn chia thành nhiều phần
    → tải song song
    → phần nào lỗi chỉ tải lại phần đó
        ↓
    AWS CLI và SDK tự làm việc này
      với tệp trên 8 MB
        ↓
    Transfer Acceleration + multipart
    → cộng hưởng, không loại trừ nhau

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đổi kiến trúc, chỉ đổi endpoint | | | Chỉ tính phí khi thật sự nhanh hơn | | | Giữ được một bucket trung tâm | |

⚠ Chính sách tính phí rất công bằng:

AWS không tính phí tăng tốc nếu
  việc truyền KHÔNG nhanh hơn
        ↓
    Rủi ro tài chính gần bằng 0
    → nhưng vẫn nên đo trước để biết
      có đáng đổi endpoint không

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

  • **D. Bật multipart upload và triển khai lại ứng dụng để hỗ trợ — đây là phương án gần nhất và multipart thật sự cải thiện việc tải tệp lớn, nhưng nó không rút ngắn quãng đường mạng; và với tệp lớn thì AWS CLI/SDK đã tự dùng multipart rồi, nên "triển khai lại để hỗ trợ" là việc phần lớn đã có.
  • **C. Đặt bucket làm custom origin của CloudFront để tăng tốc tải lên — CloudFront tối ưu cho việc phân phối ra; đặt S3 làm custom origin không phải cách dùng cho chiều upload.
  • **B. Dựng Global Accelerator trước EC2 và thêm ASG — ảnh được tải thẳng vào S3 chứ không qua EC2; thêm tầng máy chủ vào đường upload là đi ngược hướng.

Ghi nhớ

⚠ Bốn cách tăng tốc truyền dữ liệu — bảng phải thuộc: | Cách | Dùng cho | |---|---| | S3 Transfer Acceleration | upload từ xa qua Internet | | Multipart upload | tệp lớn, tải song song | | DataSync | đồng bộ khối lượng lớn có lịch | | Snowball Edge | hàng chục TB trở lên, mạng yếu |

Từ khoá nhận diện:

"slow uploads from distant regions" → Transfer Acceleration "large files, resumable" → multipart upload "terabytes over the network on a schedule" → DataSync "petabytes, poor connectivity" → Snowball Edge

⚠ Multi-Region Access Point là lựa chọn khác đáng biết:

Nhiều bucket ở nhiều Region
    + một endpoint toàn cầu duy nhất
        ↓
    Yêu cầu tự đi tới bucket gần nhất
    → và có failover giữa các Region
        ↓
    Hợp khi cần cả upload lẫn download
      tối ưu ở nhiều châu lục

Ba lưu ý về Transfer Acceleration: | Lưu ý | Chi tiết | |---|---| | Tên bucket không được chứa dấu chấm | | | Có phí mỗi GB, cao hơn truyền thường | | | Không tính phí nếu không nhanh hơn | |

Ba lưu ý về multipart upload: | Lưu ý | Chi tiết | |---|---| | Bắt buộc với tệp trên 5 GB | | | Mỗi phần từ 5 MB tới 5 GB | | | Tối đa 10.000 phần | |

⚠ Phần tải dở dang tốn tiền âm thầm:

{"Rules": [{
  "ID": "don-upload-do-dang",
  "Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Upload hỏng giữa chừng
    → các phần đã tải VẪN NẰM TRONG BUCKET
    → vẫn tính phí lưu trữ
        ↓
    Không hiện trong danh sách object
    → nhiều bucket tích tụ hàng TB
      mà chủ không biết

Kiểm tra:

aws s3api list-multipart-uploads --bucket kho-anh

Ba lưu ý về tối ưu upload từ ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | Pre-signed URL để tải thẳng lên S3 | | | Không đi vòng qua máy chủ ứng dụng | | | Nén hoặc giảm cỡ ở phía client nếu được | |

⚠ Tải thẳng lên S3 là mẫu quan trọng nhất:

Ảnh đi qua EC2 rồi mới vào S3
    → tốn băng thông gấp đôi
    → EC2 thành nút thắt
        ↓
    Pre-signed URL: client tải thẳng
    → máy chủ chỉ cấp URL

Ba lưu ý về xử lý ảnh sau khi tải lên: | Lưu ý | Chi tiết | |---|---| | S3 event → Lambda tạo bản thu nhỏ | | | Lưu bản gốc ở lớp rẻ | | | Phục vụ bản đã tối ưu qua CloudFront | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Nhập dữ liệu vào S3 miễn phí (trừ tăng tốc) | | | Truyền ra qua CloudFront rẻ hơn từ S3 | | | Lifecycle chuyển ảnh cũ sang lớp rẻ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy công cụ so tốc độ từ châu Âu | | | Đo thời gian tải một tệp lớn trước và sau | | | Kiểm có upload dở dang nào không | |

Và một lời khuyên: hãy đặt lifecycle rule dọn upload dở dang trên mọi bucket nhận tệp lớn. Đó là khoản chi phí vô hình nhất trên S3 — nó không hiện trong danh sách object, không ai nghĩ tới nó, và với ảnh độ phân giải cao thì nó tích tụ rất nhanh.

Câu 113 Domain - Design for New Solutions

A company is planning to launch a mobile app for the Department of Transportation that allows government staff to upload the latest photos of ongoing construction works such as bridges, roads culverts, and dams all over the country. The mobile app should send the photos to a web server hosted on an EC2 instance which then adds a watermark to each photo that contains the project details and the date it was taken. The solutions architect must design a solution in which the photos generated by the server will be uploaded to an S3 bucket for durable storage.

Which of the following solutions is a secure architecture and allows the EC2 instance to upload photos to S3?

  1. A Set up an IAM service role with permissions to list and write objects to the S3 bucket. Attach the IAM role to the EC2 instance which will enable it to retrieve temporary security credentials from the instance userdata and use that access to upload the photos to the S3 bucket.
  2. B Set up an IAM user with permissions to list and write objects to the S3 bucket. Launch the instance as the IAM user which will enable the EC2 instance to retrieve temporary security credentials from the instance userdata and use that access to upload the photos to the S3 bucket.
  3. C

    Set up a service control policy (SCP) with permissions to list and write objects to the S3 bucket. Attach the SCP to the EC2 instance which will enable it to retrieve temporary security credentials from the instance metadata and use that access to upload the photos to the S3 bucket.
  4. D

    Set up an IAM role with permissions to list and write objects to the S3 bucket. Attach the IAM role to the EC2 instance which will enable it to retrieve temporary security credentials from the instance metadata and use that access to upload the photos to the S3 bucket.
Xem giải thích

Đáp án

**D — Tạo IAM role có quyền liệt kê và ghi object vào bucket, gắn vai trò vào EC2 để nó lấy credential tạm từ instance METADATA rồi dùng để tải ảnh lên S3.

Vì sao đúng

Đề hỏi kiến trúc an toàn cho việc EC2 ghi vào S3, và có đúng một cách đúng:

IAM role gắn qua instance profile
    → EC2 lấy credential tạm từ
      169.254.169.254 (METADATA)
        ↓
    Credential tự xoay, tự hết hạn
    → không có khoá tĩnh nào tồn tại

⚠ Metadata và user-data là hai thứ khác nhau — đây là chỗ phân biệt D với A: | Nguồn | Chứa gì | Ai đặt | |---|---|---| | Instance metadata | thông tin instance + CREDENTIAL của vai trò | AWS | | Instance user-data | script khởi động do bạn viết | bạn |

`http://169.254.169.254/latest/meta-data/
   iam/security-credentials/<ten-vai-tro>`
        ↓
    Đây là nơi credential nằm
    → user-data KHÔNG bao giờ chứa
      credential của vai trò

Vai trò với quyền tối thiểu:

{"Version": "2012-10-17", "Statement": [
  {"Effect": "Allow",
   "Action": "s3:PutObject",
   "Resource": "arn:aws:s3:::anh-cong-trinh/*"},
  {"Effect": "Allow",
   "Action": "s3:ListBucket",
   "Resource": "arn:aws:s3:::anh-cong-trinh"}]}

⚠ Chú ý hai ARN khác nhau:

`s3:PutObject` áp cho OBJECT
    → ARN có `/*` ở cuối
        ↓
    `s3:ListBucket` áp cho BUCKET
    → ARN KHÔNG có `/*`
        ↓
    Nhầm lẫn chỗ này là nguyên nhân
      phổ biến nhất của lỗi AccessDenied

Lấy credential (SDK tự làm, đây chỉ để hiểu):

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

⚠ Lệnh trên dùng IMDSv2 — và phải bắt buộc dùng nó:

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

IMDSv1: một GET đơn giản là lấy được
    → lỗ hổng SSRF trong ứng dụng web
      đủ để đánh cắp credential
        ↓
    IMDSv2: bắt buộc PUT lấy token
    → và `hop-limit 1` chặn container
      trên máy đó lấy credential của host

Ứng dụng chỉ cần gọi SDK:

import boto3
s3 = boto3.client('s3')
s3.upload_file('anh-da-dong-dau.jpg',
               'anh-cong-trinh',
               'cau-duong/2026/08/anh-001.jpg')

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có access key nào để rò rỉ | | | Sửa quyền có hiệu lực ngay | | | CloudTrail ghi rõ vai trò nào ghi object | |

⚠ Nhưng nên xem lại chính kiến trúc trong đề:

Ảnh đi: điện thoại → EC2 → S3
    → EC2 phải nhận toàn bộ băng thông
    → và là nút thắt khi nhiều người
      cùng tải lên
        ↓
    Tốt hơn: điện thoại tải THẲNG lên S3
      bằng pre-signed URL
    → S3 event kích hoạt Lambda đóng dấu

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

  • **A. Tạo IAM service role rồi cho EC2 lấy credential tạm từ user-data — đây là phương án gần nhất và phần vai trò hoàn toàn đúng, nhưng credential của vai trò nằm ở instance metadata chứ không phải user-data; mô tả này sai về mặt cơ chế.
  • **B. Tạo IAM user rồi "khởi chạy instance dưới danh nghĩa IAM user đó" — không có khái niệm khởi chạy EC2 "với tư cách IAM user"; và IAM user nghĩa là access key tĩnh.
  • **C. Tạo service control policy (SCP) rồi gắn vào EC2 — SCP áp cho tài khoản và OU trong Organizations, không gắn được vào instance; và SCP chỉ đặt trần chứ không cấp quyền.

Ghi nhớ

⚠ Bốn cơ chế chính sách IAM — bảng phải thuộc: | Cơ chế | Gắn vào | Tác dụng | |---|---|---| | Identity policy | user, group, role | CẤP quyền | | Resource policy | bucket, queue, key | cấp quyền từ phía tài nguyên | | SCP | tài khoản, OU | đặt TRẦN, không cấp | | Permission boundary | user, role | trần cho principal đó |

Từ khoá nhận diện:

"EC2 needs to access AWS service securely" → IAM role + instance profile "where do the credentials come from" → instance metadata "limit what an entire account can do" → SCP "mobile app uploads directly" → pre-signed URL hoặc Cognito

Ba lưu ý về instance metadata: | Lưu ý | Chi tiết | |---|---| | Địa chỉ link-local 169.254.169.254 | | | Credential có hạn, SDK tự làm mới | | | Tắt hẳn nếu instance không cần vai trò | |

aws ec2 modify-instance-metadata-options \
  --instance-id i-abc --http-endpoint disabled

Ba lưu ý về đặc quyền tối thiểu với S3: | Lưu ý | Chi tiết | |---|---| | Chỉ PutObject nếu chỉ cần ghi | | | Giới hạn theo tiền tố nếu được | | | Không cấp s3:* bao giờ | |

{"Effect": "Allow", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::anh-cong-trinh/cau-duong/*"}

Ba lưu ý về bảo mật bucket: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access | | | Bắt buộc HTTPS bằng bucket policy | | | Bật versioning chống ghi đè nhầm | |

⚠ Bắt buộc mã hoá khi ghi:

{"Effect": "Deny", "Principal": "*",
 "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::anh-cong-trinh/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Ba lưu ý về pre-signed URL cho ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | Máy chủ cấp URL, client tải thẳng | | | Đặt hạn ngắn | | | Giới hạn Content-Length và loại tệp | |

url = s3.generate_presigned_post(
    Bucket='anh-cong-trinh', Key='tam/${filename}',
    Fields={'Content-Type': 'image/jpeg'},
    Conditions=[['content-length-range', 0, 10485760],
                {'Content-Type': 'image/jpeg'}],
    ExpiresIn=300)

⚠ content-length-range là điều kiện bắt buộc:

Không giới hạn kích thước
    → ai có URL đều tải lên tệp 5 GB
        ↓
    Chi phí lưu trữ ngoài dự kiến
    → và có thể là tấn công có chủ đích

Ba lưu ý về xử lý ảnh: | Lưu ý | Chi tiết | |---|---| | S3 event → Lambda đóng dấu | | | Bucket tạm và bucket cuối tách nhau | | | Đừng ghi lại vào cùng bucket kích hoạt | |

⚠ Điểm cuối là bẫy vòng lặp vô hạn:

Lambda đọc object trong bucket X
    → ghi kết quả lại vào bucket X
        ↓
    Kích hoạt chính nó
    → chạy mãi, hoá đơn tăng mãi
    → tách hai bucket, hoặc lọc tiền tố

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử ghi vào bucket khác — phải bị từ chối | | | Kiểm IMDSv2 đã bắt buộc chưa | | | Xem CloudTrail ghi đúng vai trò | |

Và một lời khuyên: hãy cho ứng dụng di động tải thẳng lên S3 thay vì đi qua máy chủ. Mỗi tấm ảnh đi qua EC2 tốn băng thông hai lần và biến máy chủ ứng dụng thành nút thắt — trong khi S3 vốn được thiết kế để nhận đúng loại lưu lượng đó.

Câu 114 Domain - Design for New Solutions

A company is migrating a legacy Oracle database from their on-premises data center to AWS. It will be deployed in an existing EBS-backed EC2 instance with multiple EBS volumes attached. For the migration, a new volume must be created for the Oracle database and then attached to the instance. This will be used by a financial web application and will primarily store historical financial data that are infrequently accessed.

Which of the following is the MOST cost-effective and throughput-oriented solution that the solutions architect should implement?

  1. A

    Migrate the database using the AWS Application Migration Service and use a General Purpose (gp2) EBS Volume.
  2. B

    Migrate the database using the AWS Database Migration Service and use a Provisioned IOPS (io1) EBS volume.
  3. C

    Migrate the database using the AWS Application Migration Service and use a Throughput Optimized (st1) EBS volume.
  4. D

    Migrate the database using the AWS Database Migration Service and use a Cold HDD (sc1) EBS volume.
Xem giải thích

Đáp án

**D — Di chuyển CSDL bằng AWS Database Migration Service (DMS) và dùng volume Cold HDD (sc1).

Vì sao đúng

Đề nêu hai lựa chọn phải đưa ra, và mỗi lựa chọn có một dữ kiện dẫn đường: | Lựa chọn | Dữ kiện | Kết luận | |---|---|---| | Công cụ di chuyển | "CSDL Oracle" | DMS — công cụ cho CSDL | | Loại volume | "dữ liệu lịch sử, ÍT KHI truy cập", "rẻ nhất" | sc1 |

⚠ Bốn loại volume EBS — bảng phải thuộc: | Loại | Bản chất | Hợp với | |---|---|---| | gp3 / gp2 | SSD đa dụng | khối lượng công việc thường | | io1 / io2 | SSD IOPS cao | CSDL đòi IOPS cam kết | | st1 | HDD tối ưu thông lượng | truy cập tuần tự, THƯỜNG XUYÊN | | sc1 | HDD lạnh | truy cập tuần tự, ÍT KHI |

⚠ Điểm phân biệt st1 và sc1 là TẦN SUẤT chứ không phải kiểu truy cập:

Cả hai đều là HDD, đều tối ưu tuần tự
    → cả hai đều "throughput-oriented"
        ↓
    st1: thông lượng nền 40 MB/s mỗi TB,
      đắt hơn
    sc1: thông lượng nền 12 MB/s mỗi TB,
      RẺ NHẤT trong mọi loại EBS
        ↓
    Đề nói "infrequently accessed"
      và "most cost-effective"
    → sc1

Tạo volume:

aws ec2 create-volume --volume-type sc1 --size 4000 \
  --availability-zone ap-southeast-1a \
  --encrypted --kms-key-id <arn>

⚠ HDD có kích thước tối thiểu:

st1 và sc1: tối thiểu 125 GiB
    → dưới mức đó không tạo được
        ↓
    Và cả hai KHÔNG dùng làm
      volume khởi động được

⚠ Cơ chế burst của HDD phải hiểu:

sc1: nền 12 MB/s mỗi TB
    → burst tới 80 MB/s mỗi TB
        ↓
    Volume nhỏ có thông lượng nền rất thấp
    → volume 500 GB chỉ 6 MB/s nền
    → thông lượng TỶ LỆ THUẬN với dung lượng

Di chuyển bằng DMS:

aws dms create-replication-task \
  --replication-task-identifier chuyen-oracle \
  --source-endpoint-arn <arn-nguon> \
  --target-endpoint-arn <arn-dich> \
  --replication-instance-arn <arn-instance> \
  --migration-type full-load-and-cdc \
  --table-mappings file://anh-xa-bang.json

⚠ full-load-and-cdc là chế độ cho việc chuyển ít gián đoạn: | Chế độ | Nghĩa | |---|---| | full-load | chép một lần, nguồn phải dừng ghi | | cdc | chỉ theo dõi thay đổi | | full-load-and-cdc | chép rồi theo dõi tiếp — cắt chuyển nhanh |

Chép toàn bộ, trong lúc đó nguồn vẫn chạy
    → CDC bắt kịp phần thay đổi
        ↓
    Khi độ trễ gần 0: chuyển ứng dụng
    → gián đoạn chỉ vài phút

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | sc1 rẻ nhất trong các loại EBS | | | DMS chuyển được với gián đoạn tối thiểu | | | Hợp mẫu truy cập tuần tự, ít khi dùng | |

⚠ Nhưng phải cảnh báo: sc1 KHÔNG hợp với CSDL giao dịch:

CSDL tài chính có truy vấn ngẫu nhiên
    → HDD rất kém với I/O ngẫu nhiên
    → độ trễ hàng chục mili giây
        ↓
    sc1 chỉ đúng khi dữ liệu THẬT SỰ
      là kho lịch sử đọc tuần tự
    → đề nói đúng như vậy

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

  • **C. Dùng Application Migration Service (MGN) và volume st1 — đây là phương án gần nhất và st1 cũng là HDD tối ưu thông lượng, nhưng nó đắt hơn sc1 mà đề nhấn mạnh "rẻ nhất"; ngoài ra MGN chuyển cả máy chủ, còn đề nói tạo volume mới cho CSDL nên DMS đúng hơn.
  • **B. Dùng DMS và volume io1 — io1 là loại đắt nhất, dành cho CSDL đòi IOPS cam kết cao; hoàn toàn ngược với "dữ liệu ít khi truy cập, rẻ nhất".
  • **A. Dùng MGN và volume gp2 — gp2 là SSD đa dụng, đắt hơn HDD cho khối lượng lưu trữ lớn kiểu này; và gp3 đã thay thế gp2 nên gp2 không còn là lựa chọn nên dùng.

Ghi nhớ

⚠ gp3 đã thay thế gp2 hoàn toàn — bảng phải thuộc: | Tiêu chí | gp2 | gp3 | |---|---|---| | IOPS nền | 3 IOPS/GB, cần credit | 3.000 miễn phí | | Thông lượng | theo dung lượng | 125 MB/s miễn phí | | Tăng IOPS riêng | phải tăng dung lượng | tăng độc lập | | Giá | | rẻ hơn ~20% |

Không còn lý do nào để chọn gp2
    → chuyển gp2 sang gp3 là việc
      giảm chi phí dễ nhất trên AWS

Từ khoá nhận diện:

"infrequently accessed, lowest cost, throughput" → sc1 "frequently accessed, sequential, big data" → st1 "database, consistent IOPS" → io2 Block Express "general purpose" → gp3

⚠ Bốn công cụ di chuyển — bảng phải thuộc: | Công cụ | Chuyển gì | |---|---| | DMS | CSDL (kể cả đổi engine với SCT) | | MGN | cả máy chủ, lift-and-shift | | DataSync | tệp và thư mục | | Snowball | khối lượng lớn, mạng yếu |

Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | Cần replication instance chạy trong VPC | | | SCT chuyển schema khi đổi engine | | | Nguồn phải bật supplemental logging cho CDC | |

⚠ Với Oracle, quên bật supplemental logging là lỗi hay gặp:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER TABLE ten_bang ADD SUPPLEMENTAL LOG DATA
  (ALL) COLUMNS;

Thiếu: full load chạy được
    → nhưng CDC không bắt được thay đổi
    → phát hiện lúc sắp cắt chuyển

Ba lưu ý về hiệu năng volume: | Lưu ý | Chi tiết | |---|---| | Thông lượng HDD tỷ lệ với dung lượng | | | Instance cũng có trần băng thông EBS | | | Dùng instance EBS-optimized | |

⚠ Trần của instance thường bị bỏ qua:

Volume sc1 4 TB: nền 48 MB/s
    → instance nhỏ có trần EBS thấp hơn
        ↓
    Nút thắt nằm ở instance, không ở volume
    → tăng volume không giúp gì

Ba lưu ý về chi phí lưu trữ: | Lưu ý | Chi tiết | |---|---| | sc1 rẻ hơn gp3 nhiều lần mỗi GB | | | Ảnh chụp tính phí riêng | | | Volume không gắn vào đâu vẫn tính tiền | |

⚠ Volume mồ côi là khoản lãng phí kinh điển:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType]'

Terminate instance mà không xoá volume
    → volume vẫn tính tiền mãi
    → rà soát định kỳ

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá mặc định ở mức Region | | | Không đổi được volume chưa mã hoá thành mã hoá tại chỗ | | | Phải qua ảnh chụp và tạo lại | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thông lượng thật bằng fio | | | Theo dõi BurstBalance của volume HDD | | | Kiểm độ trễ CDC trước khi cắt chuyển | |

Và một lời khuyên: hãy đo mẫu truy cập thật trước khi chọn HDD. sc1 rẻ hơn rất nhiều nhưng chỉ khi dữ liệu được đọc tuần tự và thưa thớt — một truy vấn ngẫu nhiên bất ngờ trên đó cho độ trễ tệ đến mức người dùng tưởng hệ thống đã chết.

Câu 115 Domain - Accelerate Workload Migration and Modernization

An organization is migrating its on-premises web application to AWS. The application comprises a Java-based backend and a NoSQL MongoDB database. Due to constraints, the application cannot be modified during the migration process, and the migrated solution must maintain an architecture similar to the on-premises setup. Additionally, the application requires high availability for both the backend and the database to ensure continuous operation.

Which solution will meet these requirements while adhering to the constraints?

  1. A

    Containerize the Java application using AWS App2Container and deploy it on Amazon Elastic Kubernetes Service (EKS). Use Amazon DynamoDB for the database layer to achieve high availability.
  2. B

    Deploy the Java application on Amazon EC2 instances within an Auto Scaling group spanning multiple Availability Zones. Use Amazon DocumentDB (with MongoDB compatibility) in a single Availability Zone deployment to host the MongoDB database.
  3. C

    Use AWS Elastic Beanstalk to deploy the Java application and migrate the MongoDB database to Amazon Aurora with multiple read replicas across different Availability Zones.
  4. D

    Deploy the Java application on Amazon EC2 instances within an Auto Scaling group spanning multiple Availability Zones. Migrate the MongoDB database to Amazon DocumentDB (with MongoDB compatibility) across multiple Availability Zones.
Xem giải thích

Đáp án

**D — Triển khai ứng dụng Java trên EC2 trong Auto Scaling group trải nhiều AZ, và chuyển MongoDB sang Amazon DocumentDB (tương thích MongoDB) triển khai trên nhiều AZ.

Vì sao đúng

Đề đặt ra ba ràng buộc, và phương án này là phương án duy nhất thoả cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | KHÔNG được sửa ứng dụng | DocumentDB nói giao thức MongoDB | | Kiến trúc giống tại chỗ | máy chủ ứng dụng + CSDL riêng | | Sẵn sàng cao ở CẢ HAI tầng | ASG nhiều AZ + DocumentDB nhiều AZ |

⚠ DocumentDB tương thích ở tầng GIAO THỨC, đó là lý do không phải sửa mã:

Ứng dụng Java dùng driver MongoDB
    → trỏ chuỗi kết nối sang endpoint
      DocumentDB
        ↓
    Driver nói cùng giao thức
    → không đổi một dòng mã nào

⚠ Đây là điểm phân biệt với DynamoDB:

DynamoDB: API hoàn toàn khác
    → phải viết lại toàn bộ tầng
      truy cập dữ liệu
        ↓
    Đề nói "không được sửa ứng dụng"
    → loại DynamoDB ngay lập tức

Tạo cụm nhiều AZ:

aws docdb create-db-cluster \
  --db-cluster-identifier cum-tai-lieu \
  --engine docdb --master-username quantri \
  --master-user-password '<mat-khau>' \
  --db-subnet-group-name nhom-subnet-3az \
  --vpc-security-group-ids sg-csdl

# them instance o AZ khac nhau
aws docdb create-db-instance --db-instance-identifier node-1 \
  --db-cluster-identifier cum-tai-lieu \
  --db-instance-class db.r6g.large --engine docdb
aws docdb create-db-instance --db-instance-identifier node-2 \
  --db-cluster-identifier cum-tai-lieu \
  --db-instance-class db.r6g.large --engine docdb

⚠ Sẵn sàng cao đòi ÍT NHẤT hai instance:

Chỉ một instance: writer chết
    → không có gì để thăng cấp
    → mất dịch vụ tới khi tạo lại
        ↓
    Hai instance trở lên ở hai AZ
    → reader tự thăng cấp trong
      khoảng 30 giây

Đây chính là lý do phương án B sai.

Hai endpoint phải dùng đúng:

Cluster endpoint  → luôn trỏ writer
Reader endpoint   → cân bằng qua các reader
        ↓
    Ứng dụng ghi qua cluster endpoint
    → chuyển đổi tự động theo sau

String uri = "mongodb://quantri:matkhau@" +
  "cum-tai-lieu.cluster-abc.ap-southeast-1.docdb.amazonaws.com:27017/" +
  "?replicaSet=rs0&readPreference=secondaryPreferred" +
  "&retryWrites=false&tls=true&tlsCAFile=global-bundle.pem";

⚠ Ba tham số bắt buộc mà người mới hay bỏ sót: | Tham số | Vì sao | |---|---| | tls=true + CA bundle | DocumentDB bắt buộc TLS | | retryWrites=false | DocumentDB KHÔNG hỗ trợ retryable writes | | replicaSet=rs0 | để driver biết topology |

Thiếu `retryWrites=false`
    → driver MongoDB đời mới bật mặc định
    → mọi lệnh ghi thất bại
    → đây là lỗi số một khi chuyển sang DocumentDB

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không sửa mã ứng dụng | | | AWS lo vá lỗi, sao lưu, chuyển đổi | | | Lưu trữ tự mở rộng, sáu bản trên ba AZ | |

⚠ Lưu trữ của DocumentDB tách khỏi tính toán:

Sáu bản dữ liệu trên ba AZ
    → độc lập với số instance
        ↓
    Thêm reader không phải chép lại dữ liệu
    → thêm được trong vài phút

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

  • **B. EC2 trong ASG nhiều AZ + DocumentDB triển khai ở MỘT AZ — đây là phương án gần nhất và chọn đúng DocumentDB, nhưng cụm một AZ không có sẵn sàng cao ở tầng CSDL; đề đòi HA cho cả hai tầng.
  • **A. Đóng gói bằng App2Container chạy trên EKS và dùng DynamoDB — DynamoDB có API hoàn toàn khác MongoDB, buộc phải viết lại ứng dụng; vi phạm ràng buộc rõ ràng nhất của đề.
  • **C. Dùng Elastic Beanstalk và chuyển MongoDB sang Aurora — Aurora là CSDL quan hệ, chuyển từ NoSQL sang quan hệ đòi thiết kế lại mô hình dữ liệu và viết lại truy vấn.

Ghi nhớ

⚠ Ba dịch vụ NoSQL trên AWS — bảng phải thuộc: | Dịch vụ | Mô hình | Chọn khi | |---|---|---| | DocumentDB | tài liệu, tương thích MongoDB | đã có ứng dụng MongoDB | | DynamoDB | khoá-giá trị và tài liệu | thiết kế mới, quy mô rất lớn | | Keyspaces | tương thích Cassandra | đã có ứng dụng Cassandra |

Từ khoá nhận diện:

"cannot modify the application" → dịch vụ tương thích giao thức "MongoDB workload" → DocumentDB "Cassandra workload" → Keyspaces "greenfield, massive scale" → DynamoDB

⚠ Bảy chiến lược 7R và câu này:

"Không sửa ứng dụng" + "đổi CSDL sang
  dịch vụ quản lý"
        ↓
    Đây là REPLATFORM
    → không phải rehost (không đổi gì)
    → không phải refactor (viết lại)

Ba lưu ý về tương thích DocumentDB: | Lưu ý | Chi tiết | |---|---| | Không hỗ trợ mọi toán tử của MongoDB | | | Kiểm tra bằng công cụ đánh giá tương thích | | | Không có sharding kiểu MongoDB | |

⚠ Chạy công cụ kiểm tra TRƯỚC khi cam kết:

python3 compat.py --uri mongodb://<nguon>:27017 \
  --version 5.0

Công cụ chính thức của AWS
    → liệt kê toán tử ứng dụng đang dùng
      mà DocumentDB không hỗ trợ
        ↓
    Phát hiện sớm còn sửa được
    → phát hiện sau khi chuyển thì rất đau

Ba lưu ý về ASG cho tầng ứng dụng: | Lưu ý | Chi tiết | |---|---| | Trải ít nhất hai AZ, nên ba | | | health-check-type ELB | | | ALB phải gắn đủ các AZ mà ASG dùng | |

Ba lưu ý về sẵn sàng cao của DocumentDB: | Lưu ý | Chi tiết | |---|---| | Ít nhất hai instance ở hai AZ | | | Reader tự thăng cấp khi writer hỏng | | | Đặt failover priority để chọn thứ tự | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Tách đọc sang reader endpoint | | | Tạo chỉ mục cho truy vấn hay chạy | | | Theo dõi BufferCacheHitRatio | |

⚠ readPreference=secondaryPreferred là cách chia tải đơn giản nhất:

Driver tự gửi truy vấn đọc sang reader
    → writer chỉ lo ghi
        ↓
    Nhưng chú ý độ trễ nhân bản
    → thao tác vừa ghi phải đọc từ primary

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | TLS bắt buộc | | | Mã hoá khi lưu bằng KMS | | | Chỉ truy cập được trong VPC | |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Tự động, PITR trong khoảng giữ | | | Ảnh chụp thủ công giữ tới khi xoá | | | Sao chép ảnh chụp sang Region khác | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy công cụ tương thích trên ứng dụng thật | | | Buộc chuyển đổi cụm và bấm giờ | | | Thử tắt một AZ, xem ứng dụng còn chạy | |

Và một lời khuyên: hãy chạy công cụ kiểm tra tương thích trên chính truy vấn của ứng dụng trước khi chọn DocumentDB. "Tương thích MongoDB" không có nghĩa là mọi thứ đều chạy — và khoảng cách giữa hai điều đó thường chỉ lộ ra ở một truy vấn hiếm gặp trong luồng nghiệp vụ quan trọng nhất.

Câu 116 Domain - Design for New Solutions

An international humanitarian aid organization has a requirement to store 20 TB worth of scanned files for the relief operations, which can grow to a total of 50 TB of data. There is also a requirement to have a website with a search feature in place that can be used to easily find a certain item through the thousands of scanned files. The new system is expected to run for more than three years.

Which of the following is the most cost-effective option for implementing the search feature in the system?

  1. A

    Use Amazon EFS to store and serve the scanned files. Install a 3rd-party search software on an Auto Scaling group of On-Demand EC2 Instances and an Elastic Load Balancer.
  2. B

    Design the new system using a CloudFormation template. Use an EC2 instance running an NGINX web server and an open-source search application. Launch multiple standard EBS volumes with RAID configuration to store the scanned files with a search index.
  3. C

    Use S3 for both storing and searching the scanned files by utilizing the native search capabilities of S3.
  4. D

    Set up a new S3 bucket with standard storage to store and serve the scanned files. Use Amazon OpenSearch Service for query processing and use Elastic Beanstalk to host the website across multiple availability zones.
Xem giải thích

Đáp án

**D — Lưu tệp quét trên S3 lớp Standard, dùng Amazon OpenSearch Service cho việc tìm kiếm, và dùng Elastic Beanstalk chạy website trên nhiều vùng sẵn sàng.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu 20-50 TB tệp quét | S3 — rẻ nhất cho khối lượng này | | Tìm kiếm trong hàng nghìn tệp | OpenSearch — công cụ tìm kiếm thật | | Chạy hơn ba năm, rẻ nhất | dịch vụ quản lý, không tự dựng máy chủ |

⚠ Điểm mấu chốt: S3 KHÔNG có tính năng tìm kiếm nội dung:

S3 chỉ liệt kê object theo TIỀN TỐ khoá
    → `s3 ls anh/2026/`
        ↓
    Không tìm được theo NỘI DUNG bên trong tệp
    → không có xếp hạng, không có
      tìm gần đúng, không có bộ lọc

Đây là lý do phương án C sai — "khả năng tìm kiếm gốc của S3" là thứ không tồn tại.

⚠ Kiến trúc tách bạch: S3 lưu, OpenSearch đánh chỉ mục:

Tệp quét (PDF, ảnh) → S3
        ↓
    Trích xuất văn bản (Textract)
        ↓
    Đánh chỉ mục vào OpenSearch
    → chỉ lưu VĂN BẢN và đường dẫn S3
        ↓
    Người dùng tìm → OpenSearch trả
      danh sách khoá S3
    → tải tệp gốc từ S3

⚠ Chỉ đánh chỉ mục văn bản, KHÔNG đưa tệp vào OpenSearch:

50 TB tệp vào OpenSearch
    → chi phí khổng lồ
        ↓
    Văn bản trích xuất: vài chục GB
    → cụm nhỏ là đủ
    → đây là điều làm kiến trúc này rẻ

Trích xuất văn bản từ tệp quét:

import boto3
textract = boto3.client('textract')
ket_qua = textract.start_document_text_detection(
    DocumentLocation={'S3Object':
        {'Bucket': 'tai-lieu-quet', 'Name': khoa}})

Đánh chỉ mục:

from opensearchpy import OpenSearch
os_client = OpenSearch(hosts=[{'host': diem_cuoi, 'port': 443}],
                       use_ssl=True, http_auth=xac_thuc)
os_client.index(index='tai-lieu', body={
    'khoaS3': khoa,
    'noiDung': van_ban,
    'ngayQuet': ngay,
    'loaiTaiLieu': loai})

Truy vấn với xếp hạng:

{"query": {"multi_match": {
   "query": "cứu trợ khẩn cấp",
   "fields": ["noiDung", "loaiTaiLieu^2"],
   "fuzziness": "AUTO"}},
 "highlight": {"fields": {"noiDung": {}}}}

⚠ Ba thứ OpenSearch cho mà LIKE trong CSDL không cho:

1. Xếp hạng theo độ liên quan
2. Tìm gần đúng (gõ sai vẫn ra)
3. Tô sáng đoạn khớp
        ↓
    Đây là lý do dùng công cụ tìm kiếm
      thay vì tự viết bằng SQL

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | S3 rẻ nhất cho 50 TB | | | OpenSearch là dịch vụ quản lý, không tự vá | | | Beanstalk lo co giãn và nhiều AZ | |

⚠ Và vòng đời S3 giảm thêm chi phí cho tệp cũ:

{"Rules": [{
  "ID": "tai-lieu-cu",
  "Status": "Enabled",
  "Transitions": [
    {"Days": 90, "StorageClass": "STANDARD_IA"},
    {"Days": 365, "StorageClass": "GLACIER_IR"}]}]}

Chỉ mục vẫn tìm được tệp
    → chỉ khi TẢI mới cần lấy từ Glacier
    → Instant Retrieval lấy trong mili giây

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

  • **A. Lưu trên EFS và cài phần mềm tìm kiếm bên thứ ba trên ASG EC2 On-Demand — đây là phương án gần nhất và kiến trúc chạy được, nhưng EFS đắt hơn S3 nhiều lần cho 50 TB, và phải tự cài, vá, vận hành phần mềm tìm kiếm suốt ba năm.
  • **B. Dùng EC2 chạy NGINX với EBS RAID — RAID không có dự phòng ở mức AZ, một máy chủ là một điểm hỏng, và tự vận hành mọi thứ.
  • **C. Dùng khả năng tìm kiếm gốc của S3 — S3 không có tính năng đó.

Ghi nhớ

⚠ Bốn cách "tìm kiếm" trên AWS — bảng phải thuộc: | Cách | Dùng cho | |---|---| | OpenSearch Service | tìm toàn văn có xếp hạng, phân tích log | | Amazon Kendra | tìm kiếm ngữ nghĩa bằng ngôn ngữ tự nhiên | | Athena | truy vấn SQL trên dữ liệu S3 | | S3 Select | lọc trong MỘT object |

⚠ Kendra là lựa chọn đáng cân nhắc cho tài liệu:

OpenSearch: khớp từ khoá, xếp hạng
    → cần tinh chỉnh phân tích ngôn ngữ
        ↓
    Kendra: hiểu câu hỏi tự nhiên
    → "quy trình xin cứu trợ ở đâu?"
    → trả về đoạn văn trả lời
        ↓
    Đắt hơn đáng kể
    → chọn theo giá trị của việc tìm đúng

Từ khoá nhận diện:

"search across thousands of documents" → OpenSearch hoặc Kendra "natural language questions" → Kendra "SQL over S3 data" → Athena "extract text from scans" → Textract

Ba lưu ý về OpenSearch Service: | Lưu ý | Chi tiết | |---|---| | Dùng ba master node chuyên dụng cho sản xuất | | | Trải nhiều AZ | | | UltraWarm và Cold cho dữ liệu ít truy cập | |

⚠ UltraWarm giảm mạnh chi phí cho chỉ mục cũ:

Hot: SSD, truy vấn nhanh nhất
    ↓
UltraWarm: lưu trên S3, chậm hơn
    → rẻ hơn tới 90%
    ↓
Cold: chỉ lưu, phải "hâm nóng" mới truy vấn

Ba lưu ý về OpenSearch Serverless: | Lưu ý | Chi tiết | |---|---| | Không phải chọn cỡ cụm | | | Tự co giãn theo tải | | | Hợp với tải khó đoán | |

Ba lưu ý về Textract: | Lưu ý | Chi tiết | |---|---| | Đọc được bảng và biểu mẫu, không chỉ văn bản | | | Bất đồng bộ cho tài liệu nhiều trang | | | Tính phí theo trang | |

⚠ Chi phí Textract cho 50 TB tài liệu là con số phải tính trước:

Hàng triệu trang × giá mỗi trang
    → có thể lớn hơn cả chi phí lưu trữ
        ↓
    Cân nhắc chỉ trích xuất tài liệu
      thật sự cần tìm kiếm

Ba lưu ý về Elastic Beanstalk: | Lưu ý | Chi tiết | |---|---| | Tự dựng ASG, ALB, health check | | | Chỉ trả tiền tài nguyên bên dưới | | | Deploy theo kiểu rolling hoặc blue/green | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Đặt OpenSearch trong VPC | | | Fine-grained access control cho quyền theo chỉ mục | | | Mã hoá khi lưu và khi truyền | |

⚠ Cụm OpenSearch công khai là lỗ hổng nghiêm trọng hay gặp:

Endpoint công khai + access policy lỏng
    → ai cũng đọc và xoá được chỉ mục
        ↓
    Đây là nguyên nhân của nhiều vụ
      rò rỉ dữ liệu đã công bố
    → luôn đặt trong VPC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tìm thử một cụm từ có trong tệp | | | Đo thời gian phản hồi truy vấn | | | So chi phí ba năm giữa các phương án | |

Và một lời khuyên: hãy giữ tệp gốc trong S3 và chỉ đưa văn bản vào chỉ mục tìm kiếm. Việc trộn lẫn nơi lưu trữ với nơi tìm kiếm là cách chắc chắn nhất để biến một hệ thống 50 TB rẻ tiền thành một cụm tìm kiếm đắt đỏ không ai dám mở rộng.

Câu 117 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

A technology company runs an industrial chain orchestration software on the AWS cloud. It consists of a web application tier that is currently deployed on a fixed fleet of Amazon EC2 instances. The database tier is deployed on Amazon RDS. The web and database tiers are deployed in the public and private subnet of the VPC respectively. The company wants to improve the service to make it more cost-effective, scalable, highly available and should require minimal human intervention.

Which of the following actions should the solutions architect implement to improve the availability and load balancing of this cloud architecture? (Select TWO.)

  1. A Create a CloudFront distribution whose origin points to the private IP addresses of your web servers. Also set up a CNAME record in Route 53 mapped to your CloudFront distribution.
  2. B

    Set up a NAT instance in your VPC. Update your route table by creating a default route via the NAT instance with all subnets associated with it. Configure a DNS A Record in Route 53 pointing to the NAT instance's public IP address.
  3. C Create a Non-Alias Record in Route 53 with a Multivalue Answer Routing configuration and add all the IP addresses for your web servers.
  4. D Launch a load balancer in front of all the web servers then create a Non-Alias Record in Route 53 which maps to the DNS name of the load balancer.
  5. E Place an Application Load Balancer in front of all the web servers. Create a new Alias Record in Route 53 which maps to the DNS name of the load balancer.
Xem giải thích

Đáp án

**C và E — Tạo bản ghi Non-Alias trong Route 53 với Multivalue Answer Routing liệt kê IP của các máy chủ web; và đặt Application Load Balancer trước toàn bộ máy chủ web rồi tạo bản ghi Alias trỏ tới DNS name của ALB.

Vì sao đúng

Đề hỏi cách cải thiện tính sẵn sàng và cân bằng tải, và cả hai phương án đều làm được điều đó theo hai cách khác nhau: | Phương án | Cơ chế | |---|---| | ALB + Alias record | cân bằng tải thật ở tầng 7, health check, tự co giãn | | Multivalue answer routing | trả nhiều IP kèm health check ở tầng DNS |

⚠ Alias record là bắt buộc khi trỏ tới ALB — đây là chỗ phân biệt E với D: | Tiêu chí | Alias record | CNAME | |---|---|---| | Dùng ở đỉnh tên miền (congty.com) | CÓ | KHÔNG được | | Chi phí truy vấn | miễn phí | tính phí | | Theo dõi IP đổi của ALB | tự động | qua tên, cũng được |

ALB đổi IP liên tục khi co giãn
    → không bao giờ trỏ bản ghi A
      tới IP của ALB
        ↓
    Alias là bản ghi riêng của Route 53
    → phân giải tới ALB ở tầng dịch vụ

Tạo Alias record:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{"Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"www.congty.com","Type":"A",
      "AliasTarget":{
        "HostedZoneId":"<zone-id-cua-alb>",
        "DNSName":"alb-ung-dung.ap-southeast-1.elb.amazonaws.com",
        "EvaluateTargetHealth":true}}}]}'

⚠ Còn multivalue answer routing khác hẳn round-robin thường:

Round-robin DNS thường
    → trả về mọi IP, kể cả IP đã chết
        ↓
    Multivalue answer: mỗi bản ghi
      gắn một HEALTH CHECK
    → chỉ trả về IP đang khoẻ
    → tối đa 8 bản ghi mỗi lần trả lời

Tạo bản ghi multivalue:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{"Action":"CREATE",
    "ResourceRecordSet":{
      "Name":"www.congty.com","Type":"A","TTL":60,
      "SetIdentifier":"web-1",
      "MultiValueAnswer":true,
      "HealthCheckId":"<hc-web-1>",
      "ResourceRecords":[{"Value":"203.0.113.10"}]}}]}'

⚠ Nhưng phải nói thẳng: multivalue KHÔNG phải cân bằng tải: | Tiêu chí | ALB | Multivalue answer | |---|---|---| | Phân phối theo tải thật | CÓ | không, chỉ ngẫu nhiên | | Gỡ máy hỏng khỏi luồng | ngay lập tức | phụ thuộc TTL và cache client | | Định tuyến theo đường dẫn | có | không | | Chấm dứt TLS | có | không |

AWS gọi multivalue là "cải thiện
  tính sẵn sàng", KHÔNG gọi là
  cân bằng tải
        ↓
    Nó hữu ích khi KHÔNG dùng được
      load balancer
    → nhưng có ALB thì ALB tốt hơn hẳn

Ba lợi ích của ALB: | Lợi ích | Chi tiết | |---|---| | Health check chủ động, gỡ máy hỏng ngay | | | Trải nhiều AZ, tự co giãn | | | Chấm dứt TLS, giảm tải cho máy chủ | |

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

⚠ Hai đáp án này không cùng một hạng, và đề chấm chúng ngang nhau.

Phương án E (ALB + Alias) là kiến trúc chuẩn cho mọi tiêu chí đề nêu: cân bằng tải, sẵn sàng cao, tự co giãn, ít can thiệp thủ công. Phương án C (multivalue answer) chỉ cải thiện tính sẵn sàng ở tầng DNS và phụ thuộc vào việc client tôn trọng TTL — điều không có gì bảo đảm.

Máy chủ chết lúc 10:00
    → health check phát hiện sau ~30 giây
    → Route 53 ngừng trả IP đó
        ↓
    Nhưng client và DNS resolver trung gian
      vẫn còn cache
    → người dùng vẫn gặp lỗi thêm vài phút

⚠ Và ba yêu cầu khác của đề không được phương án nào giải: | Yêu cầu trong đề | Cần gì | Có trong đáp án không | |---|---|---| | Rẻ hơn | ASG thay đội máy cố định | không | | Co giãn | Auto Scaling group | không | | Ít can thiệp thủ công | ASG + health check ELB | một phần |

Đề nói "fixed fleet of EC2 instances"
    → vấn đề gốc là ĐỘI MÁY CỐ ĐỊNH
        ↓
    Không có phương án nào nhắc tới
      Auto Scaling group
    → phần quan trọng nhất của
      câu hỏi bị bỏ trống

Câu hỏi thu hẹp phạm vi ở dòng cuối ("cải thiện tính sẵn sàng và cân bằng tải") nên hai đáp án vẫn chấm được — nhưng phần đầu của đề đặt ra những yêu cầu mà không lựa chọn nào đáp ứng.

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

  • **D. Đặt load balancer trước máy chủ rồi tạo bản ghi Non-Alias trỏ tới DNS name của load balancer — đây là phương án gần nhất và phần load balancer hoàn toàn đúng, nhưng bản ghi Non-Alias trỏ tới tên DNS phải là CNAME, mà CNAME không đặt được ở đỉnh tên miền; Alias mới là cách đúng.
  • **A. Tạo CloudFront với origin là IP riêng tư của máy chủ web — CloudFront không tới được IP riêng tư trong VPC; origin phải công khai hoặc qua VPC origin.
  • **B. Dựng NAT instance và trỏ bản ghi A tới IP công khai của nó — NAT dành cho lưu lượng đi ra, không phải nhận lưu lượng vào; và đó là một điểm hỏng duy nhất.

Ghi nhớ

⚠ Bảy kiểu định tuyến của Route 53 — bảng phải thuộc: | Kiểu | Dùng khi | |---|---| | Simple | một đích duy nhất | | Weighted | chia tỷ lệ, thử nghiệm A/B | | Latency | chọn Region nhanh nhất | | Failover | chính/phụ | | Geolocation | theo quốc gia người dùng | | Geoproximity | theo khoảng cách, có bias | | Multivalue answer | nhiều IP kèm health check |

Từ khoá nhận diện:

"point to an ALB at the zone apex" → Alias record "return multiple healthy IPs" → multivalue answer "active-passive DR" → failover routing "gradual traffic shift" → weighted routing

Ba lưu ý về Alias record: | Lưu ý | Chi tiết | |---|---| | Chỉ trỏ tới tài nguyên AWS | | | Miễn phí truy vấn | | | EvaluateTargetHealth kiểm sức khoẻ đích | |

Ba lưu ý về multivalue answer: | Lưu ý | Chi tiết | |---|---| | Tối đa 8 bản ghi khoẻ mỗi lần trả lời | | | Mỗi bản ghi một health check | | | Không thay thế được load balancer | |

Ba lưu ý về health check của Route 53: | Lưu ý | Chi tiết | |---|---| | Kiểm tra từ nhiều nơi trên thế giới | | | Đích phải có IP công khai | | | Calculated health check gộp nhiều điều kiện | |

⚠ Health check không tới được IP riêng tư:

Máy chủ trong subnet riêng tư
    → Route 53 health check không tới được
        ↓
    Dùng CloudWatch alarm làm nguồn
      cho health check
    → hoặc dựa vào health check của ALB

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Phải gắn ít nhất hai AZ | | | Cross-zone luôn bật | | | Định tuyến theo host, đường dẫn, header | |

Ba lưu ý về ASG — thứ đề thật sự cần: | Lưu ý | Chi tiết | |---|---| | Thay đội máy cố định bằng co giãn theo tải | | | health-check-type ELB để thay máy hỏng | | | Target tracking theo CPU hoặc số request | |

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-web \
  --policy-name theo-request --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 1000.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "<alb>/<target-group>"}}'

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL ngắn: chuyển đổi nhanh, nhiều truy vấn | | | TTL dài: rẻ hơn, chuyển đổi chậm | | | 60 giây là mức cân bằng phổ biến | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig www.congty.com xem trả về gì | | | Tắt một máy chủ, đo thời gian bị gỡ khỏi luồng | | | Kiểm HealthyHostCount theo từng AZ | |

Và một lời khuyên: hãy dùng load balancer chứ đừng cân bằng tải bằng DNS khi có thể chọn. DNS không biết máy chủ nào đang bận, không rút một máy khỏi luồng ngay lập tức, và không kiểm soát được bộ nhớ đệm nằm ở phía client.

Câu 118 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

A company has an on-premises identity provider (IdP) used for authenticating employees. The Solutions Architect has created a SAML 2.0 based federated identity solution that integrates with the company IdP. This solution is used to authenticate users’ access to the AWS environment. Upon initial testing, the Solutions Architect has been successfully granted access to the AWS environment through the federated identity web portal. However, other test users who tried to authenticate through the federated identity web portal are not given access to the AWS environment.

Which of the following options must be checked to ensure the proper configuration of identity federation? (Select THREE.)

  1. A

    Ensure that the ARN of the SAML provider, the ARN of the created IAM role, and SAML assertion from the IdP are all included when the federated identity web portal calls the AWS STS AssumeRoleWithSAML API.
  2. B

    Ensure that the IAM policy for that user has “Allow” permissions to use SAML federation.
  3. C

    Ensure that the appropriate IAM roles are mapped to company users and groups in the IdP’s SAML assertions.
  4. D

    Ensure that the resources on the AWS environment Amazon VPC can reach the on-premises IdP using its DNS hostname.
  5. E

    Ensure that the trust policy of the IAM roles created for the federated users or groups has set the SAML provider as principal.
  6. F

    Check the company’s IdP to ensure that the users are all part of the default AWSFederatedUser IAM group which is readily available in AWS.
Xem giải thích

Đáp án

**A, C và E — Bảo đảm lời gọi AssumeRoleWithSAML có đủ ARN của SAML provider, ARN của IAM role và SAML assertion; bảo đảm vai trò IAM được ánh xạ đúng tới người dùng và nhóm trong SAML assertion của IdP; và bảo đảm trust policy của vai trò đặt SAML provider làm principal.

Vì sao đúng

Một người thành công còn những người khác thất bại — đó là dấu hiệu rất đặc trưng:

Nếu cấu hình NỀN sai (provider,
  chứng chỉ, metadata)
    → KHÔNG AI đăng nhập được
        ↓
    Một người được, người khác không
    → vấn đề nằm ở ÁNH XẠ theo người dùng
    → tức là thuộc tính trong SAML assertion

⚠ Ba mảnh ghép của liên kết SAML — thiếu một là hỏng: | Mảnh | Ở đâu | |---|---| | SAML provider | trong IAM, chứa metadata của IdP | | Trust policy | trên vai trò, nói provider nào được tin | | Thuộc tính assertion | ở IdP, nói người này nhận vai trò nào |

Trust policy đúng:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"Federated":
    "arn:aws:iam::111122223333:saml-provider/IdPCongTy"},
  "Action": "sts:AssumeRoleWithSAML",
  "Condition": {"StringEquals":
    {"SAML:aud": "https://signin.aws.amazon.com/saml"}}}]}

⚠ Thuộc tính bắt buộc trong SAML assertion: | Thuộc tính | Giá trị | |---|---| | https://aws.amazon.com/SAML/Attributes/Role | <arn-vai-tro>,<arn-provider> | | https://aws.amazon.com/SAML/Attributes/RoleSessionName | tên phiên, hiện trong CloudTrail | | SessionDuration | tuỳ chọn, thời hạn phiên |

Thuộc tính Role có hai ARN
  ngăn bởi dấu phẩy
        ↓
    Đảo thứ tự hoặc thiếu một cái
    → AWS từ chối với lỗi rất chung chung

Lời gọi API:

aws sts assume-role-with-saml \
  --role-arn arn:aws:iam::111122223333:role/NhanVien \
  --principal-arn arn:aws:iam::111122223333:saml-provider/IdPCongTy \
  --saml-assertion <chuoi-base64>

⚠ AssumeRoleWithSAML là API KHÔNG cần credential AWS:

Người dùng chưa có gì trên AWS
    → chính assertion đã ký là bằng chứng
      xác thực
        ↓
    Đây là lý do phương án B sai:
      không có "chính sách IAM cho phép
      dùng SAML federation"

Kiểm chứng assertion:

echo "<chuoi-base64>" | base64 -d | xmllint --format -

Xem thuộc tính Role có mặt không
    + ARN có đúng không
        ↓
    Đây là bước gỡ lỗi hiệu quả nhất
    → và hầu như luôn tìm ra nguyên nhân

Ba lợi ích khi cấu hình đúng: | Lợi ích | Chi tiết | |---|---| | Không có IAM user nào cho nhân viên | | | Nghỉ việc: khoá ở IdP là mất quyền ngay | | | Credential tạm, tự hết hạn | |

⚠ Và ánh xạ theo NHÓM là cách quản lý đúng:

Ánh xạ theo từng người
    → mỗi lần tuyển người phải sửa
        ↓
    Ánh xạ theo nhóm AD/LDAP
    → thêm người vào nhóm là xong
    → IdP tự sinh thuộc tính Role

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

  • **B. Bảo đảm chính sách IAM của người dùng cho phép dùng SAML federation — đây là phương án gần nhất và nghe rất hợp lý, nhưng người dùng liên kết không có IAM user nào để gắn chính sách; quyền được xác định hoàn toàn qua trust policy và thuộc tính assertion.
  • **D. Bảo đảm tài nguyên trong VPC tới được IdP tại chỗ bằng tên DNS — luồng SAML đi qua trình duyệt của người dùng, không cần AWS gọi ngược về IdP.
  • **F. Kiểm tra người dùng thuộc nhóm AWSFederatedUser có sẵn — không tồn tại nhóm IAM nào tên như vậy.

Ghi nhớ

⚠ Luồng SAML đầy đủ — phải thuộc từng bước:

1. Người dùng vào cổng của IdP
2. IdP xác thực (mật khẩu + MFA)
3. IdP sinh assertion đã KÝ, gồm
   thuộc tính Role
4. Trình duyệt POST assertion tới
   `signin.aws.amazon.com/saml`
5. AWS kiểm chữ ký bằng chứng chỉ
   trong SAML provider
6. STS trả credential tạm
7. Chuyển hướng vào bảng điều khiển

Từ khoá nhận diện:

"one user works, others don't" → ánh xạ vai trò trong assertion "nobody can log in" → provider, chứng chỉ, hoặc trust policy "manage many accounts centrally" → IAM Identity Center "CLI access for federated users" → aws sso login hoặc assertion + STS

⚠ Bốn lỗi phổ biến nhất khi dựng liên kết SAML: | Lỗi | Triệu chứng | |---|---| | Chứng chỉ ký của IdP hết hạn | mọi người đột nhiên không vào được | | Thiếu thuộc tính Role cho một nhóm | nhóm đó không vào được | | ARN trong assertion sai thứ tự | lỗi "not authorized" | | SAML:aud không khớp | bị từ chối ở bước kiểm điều kiện |

⚠ Chứng chỉ IdP hết hạn là sự cố đau nhất:

Chứng chỉ ký có hạn, thường 1-3 năm
    → hết hạn là TOÀN BỘ tổ chức
      mất quyền đăng nhập cùng lúc
        ↓
    Đặt lịch nhắc trước 60 ngày
    → và cập nhật metadata trong IAM

aws iam update-saml-provider \
  --saml-provider-arn <arn> \
  --saml-metadata-document file://metadata-moi.xml

Ba lưu ý về trust policy: | Lưu ý | Chi tiết | |---|---| | Principal là Federated với ARN provider | | | Action là sts:AssumeRoleWithSAML | | | Thêm điều kiện SAML:aud | |

Ba lưu ý về thẻ phiên: | Lưu ý | Chi tiết | |---|---| | Truyền thuộc tính từ IdP thành thẻ | | | Dùng cho kiểm soát theo thuộc tính (ABAC) | | | Một chính sách phục vụ nhiều phòng ban | |

{"Effect": "Allow", "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::du-lieu/*",
 "Condition": {"StringEquals":
   {"s3:ExistingObjectTag/PhongBan":
     "${aws:PrincipalTag/PhongBan}"}}}

Ba lưu ý về IAM Identity Center: | Lưu ý | Chi tiết | |---|---| | Nối IdP một lần cho cả tổ chức | | | Permission set thay cho vai trò từng tài khoản | | | SCIM tự đồng bộ người dùng và nhóm | |

⚠ Đây là lý do nên chuyển sang Identity Center:

30 tài khoản × 8 nhóm quyền
    → 240 vai trò và trust policy
      phải bảo trì bằng tay
        ↓
    Identity Center: 8 permission set
    → gán cho nhóm ở tài khoản cần

Ba lưu ý về gỡ lỗi: | Công cụ | Việc | |---|---| | Giải mã assertion base64 | xem thuộc tính thật gửi đi | | Trình gỡ lỗi SAML của trình duyệt | bắt POST | | CloudTrail AssumeRoleWithSAML | xem lỗi phía AWS |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bắt buộc MFA ở tầng IdP | | | Đặt thời hạn phiên ngắn nhất dùng được | | | Cảnh báo khi root đăng nhập | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giải mã assertion của người thất bại | | | So thuộc tính Role với người thành công | | | Kiểm CloudTrail xem lỗi cụ thể | |

Và một lời khuyên: hãy giải mã SAML assertion của người không đăng nhập được trước khi đụng vào bất cứ cấu hình nào. Nó cho biết chính xác IdP đã gửi gì, và trong gần như mọi trường hợp thì thứ thiếu nằm ngay ở đó — chứ không nằm ở phía AWS.

Câu 119 Domain - Design for New Solutions

A software development company implements cloud best practices on its AWS infrastructure. The solutions architect has been instructed to manage its AWS cloud infrastructure as code to automate its software build, test, and deploy process. The company would like to have the ability to easily deploy exact copies of different versions of your cloud infrastructure, stage changes into different environments, revert back to previous versions, and identify the specific versions running in the VPC. Plus, all new public-facing applications should also have a global content delivery network (CDN) service.

Which of the following options is the recommended action to meet the company requirement?

  1. A Use CloudFront as the CDN and Elastic Beanstalk to deploy and manage the cloud architecture.
  2. B Use CloudWatch as the CDN and CloudFormation to manage the cloud architecture.
  3. C Use CloudWatch as the CDN and Elastic Beanstalk to deploy and manage the cloud architecture.
  4. D Use AWS CloudFormation to manage the cloud architecture and CloudFront as the CDN.
Xem giải thích

Đáp án

**D — Dùng AWS CloudFormation để quản lý kiến trúc và CloudFront làm mạng phân phối nội dung.

Vì sao đúng

Đề liệt kê bốn khả năng cần có, và đó chính là định nghĩa của hạ tầng dạng mã: | Khả năng cần | CloudFormation cho | |---|---| | Dựng bản sao chính xác của nhiều phiên bản | template có phiên bản trong Git | | Đưa thay đổi qua từng môi trường | cùng template, khác tham số | | Quay lại phiên bản trước | triển khai lại template cũ | | Biết chính xác phiên bản nào đang chạy | stack gắn với template cụ thể |

Cộng thêm yêu cầu CDN — và CloudFront là dịch vụ CDN duy nhất của AWS.

⚠ Vì sao CloudFormation chứ không phải Elastic Beanstalk:

Beanstalk: triển khai ỨNG DỤNG
    → nó tự dựng ASG, ALB, RDS cho bạn
    → nhưng bạn không mô tả được
      toàn bộ hạ tầng
        ↓
    CloudFormation: mô tả MỌI tài nguyên
    → VPC, subnet, IAM, CloudFront,
      Route 53, tất cả

Một template, ba môi trường:

Parameters:
  MoiTruong:
    Type: String
    AllowedValues: [dev, staging, prod]
Mappings:
  CauHinh:
    dev:     {LoaiMay: t3.small,  SoLuong: 1}
    staging: {LoaiMay: t3.medium, SoLuong: 2}
    prod:    {LoaiMay: m6g.large, SoLuong: 6}
Resources:
  NhomCoGian:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: !FindInMap [CauHinh, !Ref MoiTruong, SoLuong]

⚠ Change set là công cụ quan trọng nhất khi làm việc với stack sản xuất:

aws cloudformation create-change-set \
  --stack-name he-thong-san-xuat \
  --change-set-name kiem-tra-truoc \
  --template-body file://template.yaml

aws cloudformation describe-change-set \
  --stack-name he-thong-san-xuat \
  --change-set-name kiem-tra-truoc \
  --query 'Changes[?ResourceChange.Replacement==`True`]'

Cho biết TRƯỚC cái gì sẽ bị
  thay thế hay xoá
        ↓
    Thay thế CSDL = mất dữ liệu
    → phát hiện ở đây, không phải
      sau khi đã chạy

⚠ Và quay lui không tự động như nhiều người tưởng:

CloudFormation tự rollback khi
  TẠO/CẬP NHẬT thất bại
        ↓
    Nhưng cập nhật THÀNH CÔNG mà
      sai nghiệp vụ
    → phải triển khai lại template cũ
    → đây là lý do template phải nằm
      trong Git có lịch sử

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hạ tầng có lịch sử như mã nguồn | | | Môi trường giống hệt nhau | | | Xoá stack là dọn sạch tài nguyên | |

⚠ Drift detection phát hiện thay đổi thủ công:

aws cloudformation detect-stack-drift \
  --stack-name he-thong-san-xuat

Ai đó sửa security group qua bảng
  điều khiển
    → template và thực tế lệch nhau
        ↓
    Lần cập nhật sau ghi đè mất thay đổi đó
    → phát hiện sớm bằng drift detection

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

  • **A. Dùng CloudFront + Elastic Beanstalk — đây là phương án gần nhất và CloudFront hoàn toàn đúng, nhưng Beanstalk quản lý vòng đời ứng dụng chứ không mô tả toàn bộ hạ tầng; nó không cho khả năng "biết chính xác phiên bản hạ tầng nào đang chạy trong VPC".
  • **B. Dùng CloudWatch làm CDN + CloudFormation — CloudWatch là dịch vụ giám sát, không phải CDN.
  • **C. Dùng CloudWatch làm CDN + Elastic Beanstalk — sai cả hai vế.

Ghi nhớ

⚠ Bốn công cụ hạ tầng dạng mã trên AWS — bảng phải thuộc: | Công cụ | Ngôn ngữ | Chọn khi | |---|---|---| | CloudFormation | YAML/JSON | chuẩn AWS, khai báo thuần | | CDK | TypeScript, Python, Java... | muốn dùng vòng lặp, điều kiện, kiểu | | SAM | YAML rút gọn | ứng dụng không máy chủ | | Terraform | HCL | đa nhà cung cấp |

⚠ CDK sinh ra CloudFormation:

Viết bằng TypeScript
    → `cdk synth` ra template CloudFormation
        ↓
    Triển khai vẫn qua CloudFormation
    → nên mọi kiến thức về stack,
      change set, drift đều áp dụng

Từ khoá nhận diện:

"exact copies, version, roll back" → CloudFormation "deploy application, managed platform" → Elastic Beanstalk "content delivery network" → CloudFront "multi-account, multi-Region rollout" → StackSets

⚠ StackSets triển khai một template ra nhiều tài khoản:

aws cloudformation create-stack-instances \
  --stack-set-name chuan-bao-mat \
  --deployment-targets OrganizationalUnitIds=ou-abc \
  --regions ap-southeast-1 us-east-1 \
  --operation-preferences MaxConcurrentPercentage=25

Áp cấu hình chuẩn cho toàn tổ chức
    → tài khoản mới tự nhận
      (auto-deployment)

Ba lưu ý về template: | Lưu ý | Chi tiết | |---|---| | Tách theo tầng: mạng, bảo mật, ứng dụng | | | Dùng nested stack hoặc module | | | Xuất giá trị bằng Outputs và Export | |

⚠ Nhưng Export tạo phụ thuộc cứng:

Stack A export VPC ID
    → stack B import nó
        ↓
    KHÔNG xoá hay đổi được export đó
      khi còn ai import
    → cân nhắc dùng SSM Parameter Store
      cho phụ thuộc lỏng hơn

Ba lưu ý về bảo vệ tài nguyên: | Cơ chế | Bảo vệ khỏi | |---|---| | DeletionPolicy | xoá stack | | UpdateReplacePolicy | thay thế khi cập nhật | | Termination protection | xoá cả stack |

Ba lưu ý về bí mật: | Lưu ý | Chi tiết | |---|---| | Không đặt mật khẩu trong tham số | | | Dùng dynamic reference tới Secrets Manager | | | NoEcho chỉ che hiển thị | |

Ba lưu ý về CI/CD cho hạ tầng: | Lưu ý | Chi tiết | |---|---| | Template trong Git, review qua pull request | | | CodePipeline tạo change set rồi chờ duyệt | | | cfn-lint và cfn-guard kiểm trước | |

⚠ cfn-guard bắt vi phạm chính sách trước khi triển khai:

let s3_buckets = Resources.*[ Type == 'AWS::S3::Bucket' ]
rule bucket_phai_ma_hoa when %s3_buckets !empty {
  %s3_buckets.Properties.BucketEncryption exists
}

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ACM phải ở us-east-1 | | | OAC để bucket không công khai | | | Cache policy quyết định tỷ lệ trúng cache | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dựng lại toàn bộ stack ở tài khoản trống | | | Chạy drift detection định kỳ | | | Xem change set trước mọi lần cập nhật sản xuất | |

Và một lời khuyên: hãy thử dựng lại toàn bộ hệ thống từ template trong một tài khoản trống ít nhất một lần. Đó là cách duy nhất biết template có thật sự mô tả đủ hạ tầng hay không — và gần như lần đầu nào cũng lộ ra vài thứ ai đó đã tạo bằng tay rồi quên mất.

Câu 120 Domain - Accelerate Workload Migration and Modernization

A media company in South Korea offers high-quality wildlife photos to its clients. Its photographers upload a large number of photographs to the company’s Amazon S3 bucket. Currently, the company is using a dedicated group of on-premises servers to process the photos and uses an open-source messaging system to deliver job information to the servers. After processing, the data would go to a tape library and be stored for long-term archival. The company decided to shift everything to AWS Cloud, and the solutions architect was tasked to implement the same existing infrastructure design and leverage AWS tools such as storage and messaging services to minimize cost.

Which of the following options is the recommended solution that will meet the requirement?

  1. A

    Initially change the storage class of the S3 objects to S3 IA-Standard. Then create an Auto-scaling group of spot instance workers that scale according to the queue depth in SQS to process job messages. After the data has been processed, transfer your S3 objects to Amazon S3-IA.
  2. B SQS will handle the job messages, while CloudWatch alarms will terminate any idle EC2 worker instances. After the data has been processed, change the storage class of your S3 objects to S3 IA-Standard.
  3. C SNS will handle the passing of job messages, while CloudWatch alarms will terminate any idle spot worker instances. After the data has been processed, transfer your S3 objects to Amazon Glacier.
  4. D Create an Auto-scaling group of spot instance workers that scale according to the queue depth in SQS to process job messages. After the data has been processed, transfer your S3 objects to Amazon Glacier.
Xem giải thích

Đáp án

**D — Tạo Auto Scaling group gồm Spot instance co giãn theo độ sâu hàng đợi SQS để xử lý thông điệp công việc; sau khi xử lý xong thì chuyển object S3 sang Amazon Glacier.

Vì sao đúng

Đề yêu cầu giữ nguyên thiết kế hiện có và tối thiểu chi phí, và phương án này ánh xạ một-một: | Thành phần tại chỗ | Thay bằng | |---|---| | Hệ thống nhắn tin mã nguồn mở | SQS | | Đội máy chủ xử lý riêng | ASG dùng Spot | | Thư viện băng từ lưu trữ dài hạn | S3 Glacier |

⚠ Spot là lựa chọn đúng ở đây vì bản chất công việc:

Xử lý ảnh theo lô, bất đồng bộ
    → thông điệp nằm trong SQS
        ↓
    Spot bị thu hồi giữa chừng
    → visibility timeout hết
    → thông điệp quay lại hàng đợi
    → máy khác xử lý lại
        ↓
    KHÔNG mất việc, chỉ chậm hơn chút

Đây là mẫu chuẩn cho việc dùng Spot: hàng đợi làm cho việc gián đoạn trở nên vô hại.

⚠ Và co giãn theo độ sâu hàng đợi phải tính đúng chỉ số:

`ApproximateNumberOfMessagesVisible` một mình
    → 1.000 thông điệp là nhiều hay ít?
    → phụ thuộc số máy đang có
        ↓
    Chỉ số đúng: hàng chờ / số instance
    → gọi là backlog per instance

Đẩy chỉ số tuỳ chỉnh:

import boto3
cw = boto3.client('cloudwatch')
so_thong_diep = lay_do_sau_hang_doi()
so_may = lay_so_instance_dang_chay()
cw.put_metric_data(Namespace='UngDung', MetricData=[{
    'MetricName': 'BacklogPerInstance',
    'Value': so_thong_diep / max(so_may, 1)}])

Chính sách co giãn:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-xu-ly-anh \
  --policy-name theo-hang-doi \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 10.0,
    "CustomizedMetricSpecification": {
      "MetricName": "BacklogPerInstance",
      "Namespace": "UngDung", "Statistic": "Average"}}'

⚠ Xử lý tín hiệu thu hồi Spot là việc phải làm:

import requests
def sap_bi_thu_hoi():
    r = requests.get(
        'http://169.254.169.254/latest/meta-data/spot/instance-action',
        timeout=1)
    return r.status_code == 200

Báo trước 2 phút
    → dừng nhận việc mới
    → trả thông điệp đang giữ về hàng đợi
      bằng `ChangeMessageVisibility(0)`
        ↓
    Máy khác nhận ngay, không chờ
      hết visibility timeout

Vòng đời chuyển sang Glacier:

{"Rules": [{
  "ID": "luu-tru-sau-xu-ly",
  "Status": "Enabled",
  "Filter": {"Prefix": "da-xu-ly/"},
  "Transitions": [
    {"Days": 30, "StorageClass": "GLACIER"}]}]}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Spot rẻ hơn On-Demand tới 90% | | | Glacier rẻ hơn nhiều so với Standard | | | Kiến trúc gần như giống hệt hệ thống cũ | |

⚠ Đa dạng loại máy là biện pháp giữ Spot ổn định:

MixedInstancesPolicy:
  InstancesDistribution:
    OnDemandBaseCapacity: 1
    SpotAllocationStrategy: price-capacity-optimized
  LaunchTemplate:
    Overrides:
      - InstanceType: c6i.large
      - InstanceType: c6a.large
      - InstanceType: c5.large
      - InstanceType: m6i.large

Chỉ xin một loại: hết công suất
  loại đó là mất sạch
        ↓
    Xin nhiều loại tương đương
    → xác suất mất hết cùng lúc rất thấp

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

  • **A. Đổi lớp lưu trữ sang S3 Standard-IA trước khi xử lý, ASG Spot theo SQS, xong rồi lại chuyển sang Standard-IA — đây là phương án gần nhất và phần ASG Spot + SQS hoàn toàn đúng, nhưng chuyển sang IA trước khi xử lý là sai: tệp vừa tải lên sẽ được đọc ngay, và IA tính phí truy xuất cộng với thời gian lưu tối thiểu 30 ngày; ngoài ra lưu trữ dài hạn phải là Glacier chứ không phải IA.
  • **C. Dùng SNS truyền công việc và CloudWatch alarm tắt máy rảnh — SNS không lưu thông điệp: máy Spot bị thu hồi là mất việc; và tắt máy bằng alarm là cách thủ công thay cho ASG.
  • **B. Dùng SQS và CloudWatch alarm tắt EC2 rảnh, xong chuyển sang Standard-IA — vẫn tự quản lý vòng đời máy thay vì dùng ASG, và IA không phải lớp lưu trữ dài hạn.

Ghi nhớ

⚠ Ba mô hình mua EC2 và chỗ dùng — bảng phải thuộc: | Mô hình | Chiết khấu | Dùng cho | |---|---|---| | Spot | tới 90% | việc chịu được gián đoạn | | On-Demand | 0 | tải khó đoán, không gián đoạn được | | Reserved / Savings Plan | tới 72% | tải nền ổn định |

⚠ Bốn điều kiện để dùng Spot an toàn:

1. Công việc chia nhỏ được
2. Trạng thái nằm ngoài instance
   (hàng đợi, S3, CSDL)
3. Chạy lại được mà không hại gì
4. Không có hạn chót cứng
        ↓
    Xử lý ảnh theo lô: thoả cả bốn

Từ khoá nhận diện:

"fault-tolerant batch processing" → Spot "scale by queue depth" → backlog per instance "long-term archive" → Glacier "consistent response time" → KHÔNG dùng Spot

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Visibility timeout dài hơn thời gian xử lý | | | Long polling giảm chi phí lời gọi | | | Dead-letter queue cho thông điệp hỏng | |

⚠ Visibility timeout đặt sai gây xử lý trùng:

Xử lý ảnh mất 5 phút, timeout 30 giây
    → thông điệp hiện lại sau 30 giây
        ↓
    Máy khác xử lý CÙNG ảnh
    → tốn tiền, và có thể ghi đè kết quả

Ba lưu ý về xử lý idempotent: | Lưu ý | Chi tiết | |---|---| | SQS Standard có thể giao trùng | | | Ghi kết quả với khoá xác định | | | Hoặc ghi id đã xử lý vào DynamoDB | |

Ba lưu ý về lớp lưu trữ S3: | Lớp | Thời gian lưu tối thiểu | |---|---| | Standard | không có | | Standard-IA | 30 ngày | | Glacier Flexible Retrieval | 90 ngày | | Glacier Deep Archive | 180 ngày |

⚠ Thời gian lưu tối thiểu là bẫy chi phí:

Chuyển sang Glacier rồi xoá sau 10 ngày
    → vẫn bị tính đủ 90 ngày
        ↓
    Chỉ chuyển những gì chắc chắn
      giữ đủ lâu

Ba lưu ý về thời gian lấy từ Glacier: | Chế độ | Thời gian | |---|---| | Expedited | 1-5 phút | | Standard | 3-5 giờ | | Bulk | 5-12 giờ |

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | Capacity Rebalancing thay máy trước khi bị thu hồi | | | Lifecycle hook để dọn dẹp trước khi tắt | | | Trải nhiều AZ để có nhiều nhóm công suất Spot | |

⚠ Capacity Rebalancing nên bật:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-xu-ly-anh \
  --capacity-rebalance

EC2 phát tín hiệu "rủi ro thu hồi cao"
    → ASG tạo máy thay thế TRƯỚC
        ↓
    Không phải chờ tới thông báo 2 phút

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô phỏng thu hồi Spot bằng FIS | | | Xem hàng đợi có bị dồn không | | | Kiểm DLQ có thông điệp lạ không | |

Và một lời khuyên: hãy mô phỏng một lần thu hồi Spot trước khi tin rằng hệ thống chịu được. Fault Injection Service làm được điều đó chỉ bằng một lệnh — và nó thường phát hiện ra rằng thông điệp đang xử lý không hề được trả về hàng đợi như bạn nghĩ.