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

Tìm thấy 2194 câu.

Câu 691 Design Secure Architectures

A fintech company recently conducted a security audit and discovered that some IAM roles and Amazon S3 buckets might be unintentionally shared with external accounts or publicly accessible. The security team wants to identify these overly permissive resources and ensure that only intended principals (within their AWS Organization or specific AWS accounts) have access. They need a solution that can analyze IAM policies and resource policies to detect unintended access paths to AWS resources such as S3 buckets, IAM roles, KMS keys, and SNS topics.

Which solution should the team use to meet this requirement?

  1. A

    Use AWS Identity and Access Management (IAM) Access Analyzer to evaluate resource-based and identity-based policies and identify resources shared outside the account or organization
  2. B

    Use AWS Config to track configuration changes and infer resource-sharing behavior by analyzing compliance rules
  3. C

    Use IAM Access Advisor to get detailed access analysis of S3 bucket policies and determine which principals outside the organization have access
  4. D

    Use Amazon Inspector to detect over-permissive IAM policies and access paths across the environment
Xem giải thích

Đáp án

A — Dùng AWS IAM Access Analyzer để đánh giá chính sách dựa trên tài nguyên và dựa trên danh tính, phát hiện tài nguyên được chia sẻ ra ngoài tài khoản hoặc ngoài tổ chức.

Vì sao đúng

Đề nêu chính xác việc mà IAM Access Analyzer được thiết kế để làm: | Yêu cầu trong đề | Khả năng của Access Analyzer | |---|---| | Tìm tài nguyên chia sẻ ngoài ý muốn | phân tích chính sách bằng chứng minh toán học | | Với S3, IAM role, KMS key, SNS topic | đúng các loại tài nguyên nó hỗ trợ | | Chỉ principal mong muốn mới truy cập được | định nghĩa zone of trust |

Cơ chế của Access Analyzer đáng biết:

Không phải quét theo mẫu hay heuristic
    → dùng "automated reasoning" (chứng minh hình thức)
    → phân tích TOÀN BỘ không gian đường truy cập có thể
        ↓
    Kết quả là bằng chứng toán học, không phải phỏng đoán

Bật:

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

Và type quyết định "vùng tin cậy": | Type | Vùng tin cậy | |---|---| | ACCOUNT | một tài khoản — báo mọi chia sẻ ra ngoài tài khoản | | ORGANIZATION | cả tổ chức — chỉ báo chia sẻ ra NGOÀI tổ chức |

Với công ty dùng AWS Organizations, ORGANIZATION là lựa chọn đúng — không báo nhầm việc chia sẻ nội bộ hợp lệ.

Xem kết quả:

aws accessanalyzer list-findings --analyzer-arn <arn>   --filter '{"status":{"eq":["ACTIVE"]}}'

Các loại tài nguyên được hỗ trợ: | Tài nguyên | Hỗ trợ | |---|---| | S3 bucket và access point | ✅ | | IAM role (trust policy) | ✅ | | KMS key | ✅ | | SNS topic, SQS queue | ✅ | | Lambda function và layer | ✅ | | Secrets Manager secret | ✅ | | RDS snapshot, EBS snapshot, ECR repository | ✅ | | DynamoDB table và stream | ✅ |

Bốn loại đầu chính là những gì đề liệt kê.

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

  • **B. Dùng AWS Config theo dõi thay đổi cấu hình rồi suy ra hành vi chia sẻ từ các rule tuân thủ — đây là phương án gần nhất và Config thật sự có rule phát hiện bucket công khai, nhưng nó kiểm tra theo quy tắc cụ thể, không phân tích toàn diện đường truy cập: nó không suy luận được các đường truy cập phức tạp qua nhiều chính sách kết hợp.
  • **C. Dùng IAM Access Advisor phân tích bucket policy — sai công cụ: Access Advisor cho biết một principal đã dùng dịch vụ nào lần cuối khi nào, dùng để thu hẹp quyền dư thừa. Nó không phân tích ai từ ngoài có thể truy cập vào.
  • **D. Dùng Amazon Inspector phát hiện chính sách IAM quá rộng — sai loại dịch vụ: Inspector quét lỗ hổng phần mềm trên EC2, container image và Lambda. Nó không phân tích chính sách IAM.

Ghi nhớ

Các công cụ bảo mật của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | IAM Access Analyzer | phát hiện tài nguyên CHIA SẺ ra ngoài ← câu này | | IAM Access Advisor | quyền nào KHÔNG DÙNG tới (thu hẹp quyền) | | Amazon Inspector | lỗ hổng phần mềm và CVE | | Amazon GuardDuty | phát hiện hành vi đe doạ (threat detection) | | Amazon Macie | phát hiện dữ liệu NHẠY CẢM trong S3 | | AWS Config | tuân thủ cấu hình theo quy tắc | | AWS Security Hub | tổng hợp phát hiện từ mọi dịch vụ | | AWS Detective | điều tra sâu sau sự cố |

Bảng này bị hỏi rất nhiều — nên thuộc lòng.

Từ khoá nhận diện:

"resources shared with external accounts", "unintended access" → IAM Access Analyzer "unused permissions", "last accessed" → Access Advisor "software vulnerabilities", "CVE" → Inspector "compromised credentials", "crypto mining", "unusual API calls" → GuardDuty "PII in S3 buckets" → Macie

Ba tính năng của IAM Access Analyzer: | Tính năng | Việc | |---|---| | External access findings | tài nguyên chia sẻ ra ngoài vùng tin cậy | | Unused access findings | role, quyền, khoá truy cập không dùng | | Policy validation | kiểm tra cú pháp và cảnh báo bảo mật khi viết policy | | Custom policy checks | so policy mới với chuẩn của bạn |

Policy validation rất hữu ích khi viết chính sách:

aws accessanalyzer validate-policy   --policy-document file://chinh-sach.json   --policy-type IDENTITY_POLICY

Nó cảnh báo:
    ✓ cú pháp sai
    ✓ hành động không tồn tại
    ✓ quyền quá rộng (Resource: "*")
    ✓ mẫu bảo mật đáng ngờ

Và tính năng sinh policy từ CloudTrail:

aws accessanalyzer start-policy-generation   --policy-generation-details principalArn=<arn-role>   --cloud-trail-details file://cau-hinh-cloudtrail.json

Phân tích những gì role ĐÃ THỰC SỰ LÀM trong CloudTrail
    → sinh ra policy chỉ gồm quyền đó
        ↓
    Cách thực tế nhất để đạt quyền tối thiểu

Ba loại phát hiện thường gặp: | Phát hiện | Ý nghĩa | |---|---| | Bucket có policy cho phép Principal: "*" | công khai | | Role có trust policy cho tài khoản ngoài | có thể hợp lệ | | KMS key chia sẻ ra ngoài | thường là vô ý |

Ba cách xử lý một phát hiện: | Cách | Khi nào | |---|---| | Sửa chính sách | chia sẻ ngoài ý muốn | | Archive finding | chia sẻ CÓ CHỦ ĐÍCH và hợp lệ | | Tạo archive rule | tự bỏ qua các trường hợp đã duyệt |

aws accessanalyzer create-archive-rule --analyzer-name phan-tich   --rule-name doi-tac-tin-cay   --filter '{"principal.AWS":{"eq":["123456789012"]}}'

Giảm nhiễu để đội bảo mật chỉ nhìn vào cái mới và bất thường.

Ba lưu ý về Access Analyzer: | Lưu ý | Chi tiết | |---|---| | External access analyzer MIỄN PHÍ | | | Unused access analyzer CÓ PHÍ | theo số role phân tích | | Cần tạo ở MỖI Region | là dịch vụ theo Region |

Dòng cuối là điểm hay bị bỏ sót:

Tạo analyzer ở ap-northeast-1
    → KHÔNG phân tích tài nguyên ở us-east-1
        ↓
    Phải tạo ở mọi Region đang dùng
    → hoặc dùng CloudFormation StackSets triển khai đồng loạt

Ba biện pháp phòng ngừa bổ sung: | Biện pháp | Chi tiết | |---|---| | S3 Block Public Access ở cấp TÀI KHOẢN | chặn mọi bucket công khai | | SCP chặn tạo policy có Principal: "*" | | | aws:PrincipalOrgID trong resource policy | giới hạn trong tổ chức |

aws s3control put-public-access-block --account-id 123456789012   --public-access-block-configuration   BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Đây là biện pháp phòng ngừa mạnh nhất cho S3.

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | Xem findings mới | hàng tuần | | Rà soát archive rule | hàng quý | | Chạy unused access analyzer | hàng quý |

Và một lời khuyên: hãy bật Access Analyzer ở mọi Region qua CloudFormation StackSets thay vì tạo tay ở Region chính. Một bucket bị chia sẻ nhầm ở Region ít dùng vẫn là một bucket bị lộ — và đó thường chính là nơi không ai nghĩ tới việc kiểm tra.

Câu 692 Design Cost-Optimized Architectures

The content division at a digital media agency has an application that generates a large number of files on Amazon S3, each approximately 10 megabytes in size. The agency mandates that the files be stored for 5 years before they can be deleted. The files are frequently accessed in the first 30 days of the object creation but are rarely accessed after the first 30 days. The files contain critical business data that is not easy to reproduce, therefore, immediate accessibility is always required.

Which solution is the MOST cost-effective for the given use case?

  1. A

    Set up an Amazon S3 bucket lifecycle policy to move files from Amazon S3 Standard to Amazon S3 Glacier Flexible Retrieval 30 days after object creation. Delete the files 5 years after object creation
  2. B

    Set up an Amazon S3 bucket lifecycle policy to move files from Amazon S3 Standard to Amazon S3 Standard-IA 30 days after object creation. Delete the files 5 years after object creation
  3. C

    Set up an Amazon S3 bucket lifecycle policy to move files from Amazon S3 Standard to Amazon S3 Standard-IA 30 days after object creation. Archive the files to Amazon S3 Glacier Deep Archive 5 years after object creation
  4. D

    Set up an Amazon S3 bucket lifecycle policy to move files from Amazon S3 Standard to Amazon S3 One Zone-IA 30 days after object creation. Delete the files 5 years after object creation
Xem giải thích

Đáp án

B — Lifecycle policy chuyển tệp từ S3 Standard sang S3 Standard-IA sau 30 ngày, xoá tệp sau 5 năm.

Vì sao đúng

Đề nêu bốn ràng buộc, và chỉ Standard-IA thoả cả bốn: | Ràng buộc | Kết luận | |---|---| | Truy cập nhiều trong 30 ngày đầu, hiếm sau đó | chuyển sang IA sau 30 ngày | | Cần truy cập TỨC THÌ mọi lúc | loại Glacier Flexible và Deep Archive | | Dữ liệu quan trọng, KHÓ TÁI TẠO | loại One Zone-IA | | Giữ 5 năm rồi xoá | expiration sau 5 năm |

Ràng buộc thứ hai loại Glacier:

"IMMEDIATE ACCESSIBILITY is always required"
        ↓
    Glacier Flexible Retrieval: 1 phút – 12 giờ
    Deep Archive:               12–48 giờ
        ↓
    Cả hai đều KHÔNG tức thì

Ràng buộc thứ ba loại One Zone-IA:

"critical business data that is NOT EASY TO REPRODUCE"
        ↓
    One Zone-IA lưu ở CHỈ MỘT AZ
    → AZ đó mất là MẤT DỮ LIỆU
        ↓
    Với dữ liệu không tái tạo được, rủi ro không chấp nhận được

Và tệp 10 MB đủ lớn để chuyển sang IA:

Object dưới 128 KB KHÔNG được lifecycle chuyển sang IA
    → tệp 10 MB không vướng giới hạn này

Quy tắc lifecycle:

{"Rules": [{
  "ID": "chuyen-ia-va-xoa-sau-5-nam",
  "Status": "Enabled",
  "Filter": {},
  "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}],
  "Expiration": {"Days": 1825}}]}

Phép tính tiết kiệm:

Giả sử 100 TB dữ liệu:
    S3 Standard suốt 5 năm:  100.000 GB × 0,023 ≈ 2.300 USD/tháng
    Chuyển sang IA sau 30 ngày: ≈ 1.250 USD/tháng
        ↓
    Tiết kiệm khoảng 46%

Lưu ý về phí truy xuất của IA:

Standard-IA: ~0,01 USD/GB phí truy xuất
    → đề nói "rarely accessed after 30 days"
    → phí truy xuất không đáng kể
        ↓
    Nếu dữ liệu vẫn được đọc nhiều, IA sẽ ĐẮT HƠN Standard

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

  • **C. Chuyển sang Standard-IA sau 30 ngày, rồi Deep Archive sau 5 năm — đây là phương án gần nhất và đúng hoàn toàn ở bước đầu, nhưng nó sai ở bước sau: đề nói tệp phải được XOÁ sau 5 năm, không phải lưu trữ tiếp. Chuyển sang Deep Archive nghĩa là tiếp tục trả tiền vô thời hạn cho dữ liệu đáng lẽ đã bỏ.
  • **A. Chuyển sang Glacier Flexible Retrieval sau 30 ngày — vi phạm yêu cầu truy cập tức thì: Glacier mất từ một phút tới 12 giờ để lấy dữ liệu.
  • **D. Chuyển sang One Zone-IA sau 30 ngày — rủi ro độ bền: dữ liệu chỉ nằm ở một AZ, trong khi đề nói rõ dữ liệu quan trọng và khó tái tạo.

Ghi nhớ

Các lớp lưu trữ S3 — bảng phải thuộc: | Lớp | Số AZ | Thời gian lấy | Giá tham khảo | |---|---|---|---| | Standard | ≥3 | tức thì | ~0,023 USD/GB | | Intelligent-Tiering | ≥3 | tức thì | ~0,023 + giám sát | | Standard-IA | ≥3 | tức thì | ~0,0125 USD/GB | | One Zone-IA | 1 ⚠ | tức thì | ~0,01 USD/GB | | Glacier Instant Retrieval | ≥3 | mili giây | ~0,004 USD/GB | | Glacier Flexible | ≥3 | 1 phút – 12 giờ | ~0,0036 USD/GB | | Deep Archive | ≥3 | 12–48 giờ | ~0,00099 USD/GB |

Bốn câu hỏi để chọn lớp lưu trữ: | Câu hỏi | Nếu "có" | |---|---| | Cần truy cập TỨC THÌ? | Standard, IA, hoặc Glacier Instant | | Dữ liệu tái tạo được? | One Zone-IA rẻ hơn | | Mẫu truy cập đoán trước được? | lifecycle; nếu không → Intelligent-Tiering | | Truy cập rất hiếm và chờ được? | Glacier Flexible hoặc Deep Archive |

Glacier Instant Retrieval đáng cân nhắc cho câu này:

Glacier Instant Retrieval:
    ✓ truy xuất mili giây — TỨC THÌ
    ✓ rẻ hơn Standard-IA (~0,004 vs ~0,0125 USD/GB)
    ✗ phí truy xuất CAO HƠN (~0,03 vs ~0,01 USD/GB)
    ✗ thời gian lưu tối thiểu 90 ngày
        ↓
    Nếu thật sự hiếm truy cập, nó còn rẻ hơn Standard-IA

(Không có trong danh sách phương án, nhưng đáng biết cho thực tế.)

Ba ràng buộc của lifecycle: | Ràng buộc | Chi tiết | |---|---| | Standard-IA và One Zone-IA: tối thiểu 30 ngày | không chuyển sớm hơn | | Object nhỏ hơn 128 KB không tự chuyển sang IA | | | Thời gian lưu tối thiểu tính phí | IA 30, Glacier 90, Deep Archive 180 ngày |

Dòng cuối rất quan trọng:

Xoá object khỏi Deep Archive sau 30 ngày
    → vẫn tính phí đủ 180 ngày
        ↓
    Đừng chuyển sang lớp lạnh dữ liệu sắp bị xoá

Ba loại chi phí của lớp lạnh: | Chi phí | Standard-IA | |---|---| | Lưu trữ | ~0,0125 USD/GB | | Truy xuất | ~0,01 USD/GB | | Request | cao hơn Standard |

Điểm hoà vốn của Standard-IA:

Nếu đọc lại HƠN ~50% dữ liệu mỗi tháng
    → phí truy xuất vượt tiền tiết kiệm lưu trữ
    → Standard rẻ hơn
        ↓
    Đây là lý do phải chắc chắn dữ liệu THẬT SỰ ít đọc

Ba thành phần của quy tắc lifecycle: | Thành phần | Chi tiết | |---|---| | Filter | prefix, tag, hoặc kích thước | | Transitions | chuyển lớp theo số ngày | | Expiration | XOÁ sau số ngày ← câu này |

Ba quy tắc lifecycle nên có ở mọi bucket: | Quy tắc | Lợi ích | |---|---| | AbortIncompleteMultipartUpload | dọn phần dở dang — chi phí ẩn | | NoncurrentVersionExpiration | với bucket bật versioning | | ExpiredObjectDeleteMarker | dọn delete marker mồ côi |

{"ID": "don-dep", "Status": "Enabled", "Filter": {},
 "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7},
 "NoncurrentVersionExpiration": {"NoncurrentDays": 90},
 "Expiration": {"ExpiredObjectDeleteMarker": true}}

Ba lưu ý về versioning và lifecycle: | Lưu ý | Chi tiết | |---|---| | Expiration với versioning chỉ tạo DELETE MARKER | phiên bản cũ vẫn còn | | Cần NoncurrentVersionExpiration để xoá thật | | | Kiểm tra Storage Lens xem phiên bản cũ chiếm bao nhiêu | |

Đây là nguồn chi phí âm thầm rất phổ biến.

Ba công cụ phân tích: | Công cụ | Việc | |---|---| | S3 Storage Lens | tổng quan và khuyến nghị | | S3 Storage Class Analysis | phân tích mẫu truy cập theo tuổi object | | Cost Explorer | chi phí theo lớp |

Storage Class Analysis nên chạy trước khi đặt lifecycle:

aws s3api put-bucket-analytics-configuration --bucket kho-noi-dung   --id phan-tich --analytics-configuration file://cau-hinh.json

Nó cho biết chính xác sau bao nhiêu ngày thì dữ liệu ngừng được đọc.

Ba lưu ý về yêu cầu tuân thủ: | Lưu ý | Chi tiết | |---|---| | Kiểm tra quy định trước khi đặt expiration | có ngành cấm xoá sớm | | Object Lock nếu cần bất biến | | | Ghi lại chính sách lưu giữ vào tài liệu | |

Và một lời khuyên: hãy chạy Storage Class Analysis ít nhất 30 ngày trước khi cố định con số "30 ngày" trong lifecycle. Giả định về mẫu truy cập rất hay sai — có kho dữ liệu ngừng được đọc sau một tuần, có kho vẫn được truy cập đều sau ba tháng, và phí truy xuất của IA khiến việc đoán sai theo hướng thứ hai tốn kém hơn là không làm gì.

Câu 693 Design Secure Architectures

An organization operates a legacy reporting tool hosted on an Amazon EC2 instance located within a public subnet of a VPC. This tool aggregates scanned PDF reports from field devices and temporarily stores them on an attached Amazon EBS volume. At the end of each day, the tool transfers the accumulated files to an Amazon S3 bucket for archival. A solutions architect identifies that the files are being uploaded over the internet using S3's public endpoint. To improve security and avoid exposing data traffic to the public internet, the architect needs to reconfigure the setup so that uploads to Amazon S3 occur privately without using the public S3 endpoint.

Which solution will fulfill these requirements?

  1. A

    Set up a NAT gateway in the public subnet and modify the route table of the EC2 instance's subnet to direct Amazon S3 traffic through the NAT gateway
  2. B

    Create an S3 access point within the same Region and attach a policy that grants the EC2 instance access. Update the application to use the access point alias to upload data
  3. C

    Provision a dedicated AWS Direct Connect link to route traffic from the VPC to Amazon S3 privately
  4. D

    Create a gateway VPC endpoint for Amazon S3 in the VPC. Ensure that the EC2 instance’s subnet route table is updated to route S3 traffic through the endpoint. Confirm that appropriate IAM policies are in place to permit access via the VPC endpoint
Xem giải thích

Đáp án

D — Tạo gateway VPC endpoint cho S3, cập nhật route table của subnet chứa EC2 để định tuyến lưu lượng S3 qua endpoint, và đảm bảo IAM policy cho phép truy cập qua endpoint đó.

Vì sao đúng

Đề nêu yêu cầu rõ: tải lên S3 phải diễn ra RIÊNG TƯ, không qua endpoint công cộng.

Gateway VPC endpoint cho S3:
    → thêm ROUTE trong route table
    → lưu lượng tới S3 đi qua mạng RIÊNG của AWS
        ↓
    KHÔNG đi ra Internet
    → không cần IP công cộng, không cần Internet Gateway cho việc này

Cơ chế hoạt động:

AWS thêm vào route table một prefix list:
    pl-xxxxx (dải IP của S3 trong Region) → vpce-xxxxx
        ↓
    Mọi request tới S3 tự động đi qua endpoint
    → ứng dụng KHÔNG phải sửa gì

Triển khai:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-northeast-1.s3   --vpc-endpoint-type Gateway   --route-table-ids rtb-abc rtb-def

Và endpoint policy giới hạn thêm:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:PutObject", "s3:GetObject"],
  "Resource": "arn:aws:s3:::kho-luu-tru-bao-cao/*"}]}

Chỉ cho phép thao tác với đúng bucket cần dùng qua endpoint này.

Và bucket policy có thể bắt buộc đi qua endpoint:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-luu-tru-bao-cao",
              "arn:aws:s3:::kho-luu-tru-bao-cao/*"],
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Chặn MỌI truy cập không đi qua VPC endpoint
    → kể cả từ Internet với credential hợp lệ
        ↓
    Đây là biện pháp mạnh nhất

Và gateway endpoint MIỄN PHÍ:

Gateway endpoint (S3, DynamoDB): KHÔNG tính phí
Interface endpoint (mọi dịch vụ khác): ~0,01 USD/giờ mỗi AZ + theo GB

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

  • **A. Dựng NAT Gateway ở public subnet và định tuyến lưu lượng S3 qua đó — đây là phương án gần nhất vì cũng thay đổi đường đi, nhưng NAT Gateway vẫn đi ra Internet công cộng: nó chỉ dịch địa chỉ, request vẫn tới endpoint công cộng của S3. Và nó tốn phí (~32 USD/tháng cộng phí theo GB).
  • **B. Tạo S3 access point và dùng alias để tải lên — access point không thay đổi đường đi mạng: nó là cơ chế quản lý quyền truy cập, không phải cơ chế kết nối riêng tư. (Có loại "VPC-only access point" giới hạn truy cập từ một VPC, nhưng nó vẫn cần VPC endpoint để lưu lượng đi riêng.)
  • **C. Dựng Direct Connect để định tuyến lưu lượng từ VPC tới S3 — sai mục đích hoàn toàn: Direct Connect nối on-premises với AWS. Ở đây cả EC2 lẫn S3 đều đã ở trong AWS.

Ghi nhớ

Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ hỗ trợ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Cơ chế | route trong route table | ENI có IP riêng trong subnet | | Chi phí | MIỄN PHÍ | ~0,01 USD/giờ mỗi AZ + theo GB | | Truy cập từ on-premises | ❌ | ✅ qua VPN/DX | | Security group | ❌ | ✅ | | DNS riêng | ❌ | ✅ |

Quy tắc: S3 và DynamoDB dùng gateway endpoint (miễn phí), trừ khi cần truy cập từ on-premises.

Ba lợi ích của VPC endpoint: | Lợi ích | Chi tiết | |---|---| | Lưu lượng KHÔNG ra Internet | ← yêu cầu trong đề | | Tiết kiệm phí NAT Gateway | đáng kể với khối lượng lớn | | Kiểm soát bằng endpoint policy | |

Phép tính tiết kiệm NAT:

1 TB dữ liệu lên S3 mỗi tháng qua NAT Gateway:
    Phí xử lý NAT: 1.000 GB × 0,045 = 45 USD
    + phí giờ NAT: ~32 USD
        ↓
    Qua gateway endpoint: 0 USD

Ba loại chính sách ảnh hưởng tới truy cập qua endpoint: | Chính sách | Việc | |---|---| | IAM policy của EC2 role | principal được làm gì | | Bucket policy | ai truy cập được bucket | | Endpoint policy | những gì đi qua endpoint này được phép |

Cả ba phải cho phép — đây là điểm hay gây "Access Denied" khó hiểu.

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Phải gắn vào ĐÚNG route table của subnet | | | Chỉ hoạt động TRONG Region | không truy cập bucket ở Region khác | | Không dùng được từ on-premises | |

Dòng giữa là hạn chế cần biết:

Gateway endpoint cho S3 ở ap-northeast-1
    → chỉ định tuyến riêng tới bucket Ở ap-northeast-1
    → bucket ở us-east-1 vẫn đi qua Internet
        ↓
    Cần interface endpoint nếu muốn xuyên Region riêng tư

Ba dịch vụ nên có endpoint trong VPC riêng tư: | Dịch vụ | Loại endpoint | |---|---| | S3 | gateway (miễn phí) | | DynamoDB | gateway (miễn phí) | | Systems Manager (ssm, ssmmessages, ec2messages) | interface | | Secrets Manager, KMS | interface | | ECR (api và dkr) | interface | | CloudWatch Logs | interface |

Ba endpoint của Systems Manager là bộ bắt buộc:

Thiếu một trong ba:
    com.amazonaws.<region>.ssm
    com.amazonaws.<region>.ssmmessages
    com.amazonaws.<region>.ec2messages
        ↓
    Instance không hiện trong Fleet Manager,
    và Session Manager không kết nối được

Ba lưu ý về interface endpoint: | Lưu ý | Chi tiết | |---|---| | Tạo ENI ở mỗi subnet khai | tính phí theo AZ | | Bật private DNS để dùng tên miền chuẩn | không phải sửa mã | | Gắn security group cho phép cổng 443 | |

Ba cách kiểm chứng lưu lượng đi qua endpoint: | Cách | Việc | |---|---| | VPC Flow Logs | thấy đích là IP nội bộ của endpoint | | CloudTrail: trường vpcEndpointId | bằng chứng rõ ràng nhất | | Kiểm tra route table | có prefix list của S3 |

aws cloudtrail lookup-events --lookup-attributes   AttributeKey=EventName,AttributeValue=PutObject   --query 'Events[].CloudTrailEvent' | grep vpcEndpointId

Ba biện pháp bảo mật kết hợp: | Biện pháp | Chi tiết | |---|---| | aws:SourceVpce trong bucket policy | chỉ cho phép từ endpoint | | Endpoint policy giới hạn bucket | | | Chuyển EC2 sang private subnet | không cần IP công cộng nữa |

Dòng cuối là bước tiếp theo hợp lý:

Sau khi có VPC endpoint cho S3
    → EC2 không cần ra Internet để tải lên nữa
    → chuyển sang private subnet
        ↓
    Giảm hẳn bề mặt tấn công

Và một lời khuyên: hãy thêm điều kiện aws:SourceVpce vào bucket policy sau khi dựng endpoint. Nếu không, endpoint chỉ cho phép đường đi riêng tư chứ không bắt buộc nó — và một cấu hình sai ở route table sau này sẽ âm thầm đưa lưu lượng trở lại Internet mà không có gì báo cho bạn biết.

Câu 694 Design Secure Architectures

A biomedical research firm operates a file exchange system for external research partners to upload and download experimental data. Currently, the system runs on two Amazon EC2 Linux instances, each configured with Elastic IP addresses to allow access from trusted IPs. File transfers use the SFTP protocol, and Linux user accounts are manually provisioned to enforce file-level access control. Data is stored on a shared file system mounted to both EC2 instances. The firm wants to modernize the solution to a fully managed, serverless model with high IOPS, fine-grained user permission control, and strict IP-based access restrictions. They also want to reduce operational overhead without sacrificing performance or security.

Which solution best meets these requirements?

  1. A

    Use Amazon EFS with encryption enabled. Create an AWS Transfer Family SFTP endpoint in a VPC with Elastic IP addresses. Restrict access using a security group that allows traffic only from known IPs. Manage user access using POSIX identity mappings and IAM policies
  2. B

    Use AWS Storage Gateway in file gateway mode to expose an NFS file share. Deploy AWS Transfer Family with a public endpoint and map user identities using IAM roles. Configure IP allow lists using AWS WAF
  3. C

    Use Amazon S3 with server-side encryption enabled. Create an AWS Transfer Family SFTP endpoint with a VPC endpoint in a private subnet. Restrict access to known IPs using security group rules. Manage user-level permissions using IAM role-based access mappings
  4. D

    Use Amazon FSx for Lustre as the backend storage. Create an AWS Transfer Family SFTP service with a public endpoint. Configure IAM policies to manage user access and attach a security group that restricts access to trusted IP addresses
Xem giải thích

Đáp án

A — Dùng Amazon EFS có mã hoá; tạo AWS Transfer Family SFTP endpoint trong VPC với Elastic IP; giới hạn truy cập bằng security group chỉ cho phép IP đã biết; quản lý người dùng bằng ánh xạ POSIX và IAM policy.

Vì sao đúng

Đề nêu năm yêu cầu, và phương án A đáp ứng cả năm: | Yêu cầu | Cơ chế | |---|---| | Serverless, được quản lý hoàn toàn | AWS Transfer Family | | IOPS cao | EFS với Elastic throughput | | Phân quyền cấp người dùng chi tiết | POSIX identity mapping + IAM | | Giới hạn theo địa chỉ IP nghiêm ngặt | VPC endpoint + security group | | Giảm công vận hành | không còn EC2 nào để quản lý |

Vế "giới hạn IP" là điểm phân biệt quyết định:

Transfer Family có ba kiểu endpoint:
    PUBLIC:            KHÔNG gắn security group được
    VPC_ENDPOINT (cũ): hạn chế
    VPC:               ✓ có security group, ✓ gắn Elastic IP
        ↓
    Chỉ kiểu VPC mới lọc được theo IP nguồn

Và hệ thống hiện tại dùng chia sẻ tệp POSIX với tài khoản Linux:

"Linux user accounts are manually provisioned to enforce
 file-level access control"
"Data is stored on a SHARED FILE SYSTEM"
        ↓
    EFS giữ nguyên mô hình POSIX đó
    → uid/gid ánh xạ trực tiếp
        ↓
    Chuyển sang S3 sẽ mất mô hình quyền cấp tệp theo POSIX

Triển khai:

aws transfer create-server --protocols SFTP   --identity-provider-type SERVICE_MANAGED   --endpoint-type VPC   --endpoint-details '{"VpcId":"vpc-abc",
    "SubnetIds":["subnet-a","subnet-c"],
    "SecurityGroupIds":["sg-sftp"],
    "AddressAllocationIds":["eipalloc-1","eipalloc-2"]}'   --domain EFS

Và tạo người dùng với ánh xạ POSIX:

aws transfer create-user --server-id s-abc   --user-name doi-tac-a --role <arn-role>   --home-directory-type LOGICAL   --home-directory-mappings '[{"Entry":"/","Target":"/fs-0abc/doi-tac-a"}]'   --posix-profile Uid=1001,Gid=1001   --ssh-public-key-body "ssh-rsa AAAA..."

--domain EFS là tham số quan trọng — Transfer Family hỗ trợ cả S3 lẫn EFS làm kho phía sau.

Và security group giới hạn IP:

aws ec2 authorize-security-group-ingress --group-id sg-sftp   --protocol tcp --port 22 --cidr 203.0.113.0/24

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

  • **C. Dùng Amazon S3 làm kho, Transfer Family SFTP với VPC endpoint ở private subnet, phân quyền bằng IAM role — đây là phương án gần nhất và hoàn toàn khả thi về mặt kỹ thuật, nhưng nó không giữ mô hình POSIX: đề nói rõ hệ thống hiện dùng tài khoản Linux và hệ thống tệp chia sẻ để kiểm soát quyền cấp tệp. Và đặt endpoint ở private subnet mà không có Elastic IP thì đối tác bên ngoài không kết nối tới được.
  • **B. Storage Gateway chế độ file gateway với Transfer Family public endpoint, giới hạn IP bằng WAF — hai lỗi: public endpoint không gắn security group được, và WAF chỉ lọc HTTP/HTTPS, không lọc được SFTP.
  • **D. FSx for Lustre làm kho với Transfer Family public endpoint — hai lỗi: Transfer Family không hỗ trợ FSx for Lustre (chỉ S3 và EFS), và public endpoint không gắn security group được.

Ghi nhớ

Ba kiểu endpoint của AWS Transfer Family — bảng phải thuộc: | Kiểu | Security group | Elastic IP | Truy cập từ Internet | |---|---|---|---| | PUBLIC | ❌ | ❌ | ✅ | | VPC_ENDPOINT (legacy) | hạn chế | ❌ | qua PrivateLink | | VPC | ✅ | ✅ | ✅ khi có EIP |

Cần lọc theo IP thì BẮT BUỘC dùng kiểu VPC.

Hai kho phía sau được hỗ trợ: | Kho | Đặc điểm | |---|---| | Amazon S3 | object, rẻ, không POSIX | | Amazon EFS | POSIX đầy đủ, uid/gid, IOPS cao ← câu này |

Chọn giữa hai kho:

Ứng dụng xuôi dòng đọc bằng API S3       → S3
Cần quyền POSIX và nhiều máy cùng mount  → EFS

Bốn giao thức được Transfer Family hỗ trợ: | Giao thức | Cổng | |---|---| | SFTP | 22 | | FTPS | 21 (dữ liệu ở dải riêng) | | FTP | 21 (chỉ trong VPC — không mã hoá) | | AS2 | trao đổi dữ liệu B2B |

Ba kiểu nhà cung cấp danh tính: | Kiểu | Chi tiết | |---|---| | Service managed | Transfer Family lưu khoá SSH | | Directory Service | tích hợp AWS Managed Microsoft AD | | Custom (Lambda hoặc API Gateway) | xác thực bằng hệ thống riêng |

Custom identity provider rất linh hoạt:

Lambda nhận username và password
    → kiểm tra với database của bạn
    → trả về IAM role và home directory
        ↓
    Tích hợp được với bất kỳ hệ thống người dùng nào

Ba cách phân quyền người dùng: | Cách | Chi tiết | |---|---| | IAM role mỗi người dùng | quyền ở tầng AWS | | Session policy | thu hẹp thêm trong phiên | | POSIX profile (uid/gid) | quyền ở tầng hệ thống tệp EFS |

Với EFS, POSIX profile là cơ chế chính:

Uid=1001, Gid=1001
    → người dùng thấy tệp đúng như tài khoản Linux uid 1001
        ↓
    Giữ nguyên mô hình quyền cũ khi di chuyển

Ba loại home directory: | Loại | Chi tiết | |---|---| | PATH | đường dẫn thật, người dùng thấy cấu trúc đầy đủ | | LOGICAL | ánh xạ ảo — người dùng CHỈ thấy phần của mình |

LOGICAL được khuyến nghị cho đối tác bên ngoài — họ không thấy được cấu trúc thư mục của người khác.

Ba đặc điểm của EFS phù hợp ở đây: | Đặc điểm | Chi tiết | |---|---| | Elastic throughput | tự co giãn, không cấp phát trước | | Mã hoá at rest và in transit | | | Access Point cách ly từng người dùng | |

Ba lưu ý về Elastic IP với Transfer Family: | Lưu ý | Chi tiết | |---|---| | Một EIP mỗi subnet (AZ) | | | IP KHÔNG đổi | đối tác đưa vào danh sách trắng | | Cần Internet Gateway trong VPC | để EIP hoạt động |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Chỉ dùng SFTP hoặc FTPS, không dùng FTP thuần | | | Bật logging vào CloudWatch Logs | audit mọi thao tác | | Xoay vòng khoá SSH định kỳ | |

aws transfer update-server --server-id s-abc   --logging-role <arn-role>   --structured-log-destinations <arn-log-group>

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Endpoint | ~0,30 USD/giờ mỗi giao thức (~216 USD/tháng) | | Dữ liệu tải lên/xuống | ~0,04 USD/GB | | EFS | theo lớp lưu trữ |

Endpoint tính phí theo giờ dù không ai dùng — đây là chi phí cố định đáng kể.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | FilesIn, FilesOut | lượng tệp trao đổi | | BytesIn, BytesOut | | | CloudWatch Logs | lỗi xác thực, thao tác thất bại |

Và một lời khuyên: hãy bật structured logging vào CloudWatch Logs ngay khi tạo server. Với hệ thống trao đổi dữ liệu nghiên cứu y sinh, khả năng trả lời "ai đã tải tệp nào lúc nào" là yêu cầu tuân thủ chứ không phải tiện ích — và log không thể bật ngược lại cho những phiên đã xảy ra.

Câu 695 Design Cost-Optimized Architectures

Computer vision researchers at a university are trying to optimize the I/O bound processes for a proprietary algorithm running on Amazon EC2 instances. The ideal storage would facilitate high-performance IOPS when doing file processing in a temporary storage space before uploading the results back into Amazon S3.

As a solutions architect, which of the following AWS storage options would you recommend as the MOST performant as well as cost-optimal?

  1. A

    Use Amazon EC2 instances with Amazon EBS Provisioned IOPS SSD (io1) as the storage option
  2. B

    Use Amazon EC2 instances with Instance Store as the storage option
  3. C

    Use Amazon EC2 instances with Amazon EBS Throughput Optimized HDD (st1) as the storage option
  4. D

    Use Amazon EC2 instances with Amazon EBS General Purpose SSD (gp2) as the storage option
Xem giải thích

Đáp án

B — Dùng EC2 instance với Instance Store làm lựa chọn lưu trữ.

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba dẫn tới instance store: | Đặc điểm | Kết luận | |---|---| | Tiến trình bị giới hạn bởi I/O | cần IOPS cao nhất có thể | | Không gian lưu trữ TẠM THỜI | mất dữ liệu chấp nhận được | | Kết quả tải lên S3 sau khi xong | nguồn và đích đều ở S3 |

Vế thứ hai là điều kiện cho phép dùng instance store:

"temporary storage space before uploading the results back into S3"
        ↓
    Dữ liệu chỉ tồn tại trong lúc xử lý
    → mất khi máy dừng KHÔNG gây hậu quả
        ↓
    Đúng trường hợp instance store được thiết kế cho

Và instance store nhanh hơn mọi lựa chọn EBS:

Instance store (NVMe):
    → gắn TRỰC TIẾP vào máy chủ vật lý
    → KHÔNG đi qua mạng
        ↓
    Hàng triệu IOPS, độ trễ micro giây

EBS (kể cả io2):
    → đi qua mạng lưu trữ của AWS
    → tối đa 64.000 IOPS (256.000 với Block Express)
    → độ trễ dưới mili giây, nhưng vẫn cao hơn

Và về chi phí — đây là vế "cost-optimal" của đề:

Instance store: ĐÃ BAO GỒM trong giá instance
    → KHÔNG tính phí riêng
        ↓
io1/io2: tính phí dung lượng CỘNG phí IOPS
    → 20.000 IOPS ≈ 1.300 USD/tháng chỉ riêng phần IOPS

Vừa nhanh nhất vừa rẻ nhất — hiếm khi có lựa chọn thoả cả hai.

Chọn instance có NVMe:

aws ec2 run-instances --instance-type i4i.2xlarge   --image-id ami-0abc --count 1

Và phải tự khởi tạo ổ:

lsblk                              # tìm ổ NVMe
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir /scratch
sudo mount /dev/nvme1n1 /scratch

Instance store KHÔNG được định dạng sẵn — phải làm trong user data hoặc AMI.

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

  • **A. EBS Provisioned IOPS SSD (io1) — đây là phương án gần nhất và cho IOPS cao có đảm bảo, nhưng nó chậm hơn instance store và đắt hơn nhiều: phí IOPS tính riêng, trong khi instance store đã nằm trong giá instance. Đề hỏi "MOST performant as well as cost-optimal".
  • **D. EBS General Purpose SSD (gp2) — IOPS thấp hơn nhiều và có cơ chế credit gây tụt tốc.
  • **C. EBS Throughput Optimized HDD (st1) — sai loại tải: st1 là HDD tối ưu cho thông lượng tuần tự, IOPS rất thấp. Xử lý tệp thị giác máy tính là I/O ngẫu nhiên.

Ghi nhớ

Hiệu năng lưu trữ — thứ tự từ nhanh nhất: | Lưu trữ | IOPS tối đa | Độ trễ | Bền vững | |---|---|---|---| | Instance store (NVMe) | hàng triệu | micro giây | ❌ | | io2 Block Express | 256.000 | dưới mili giây | ✅ | | io2 / io1 | 64.000 | dưới mili giây | ✅ | | gp3 / gp2 | 16.000 | mili giây | ✅ | | st1 / sc1 | 500 / 250 | cao | ✅ |

Từ khoá nhận diện:

"maximum IOPS", "temporary", "scratch", "cost-optimal" → instance store "consistent high IOPS", "persistent", "database" → io2 "general purpose" → gp3

Ba điều kiện để dùng instance store: | Điều kiện | Chi tiết | |---|---| | Dữ liệu TÁI TẠO ĐƯỢC | nguồn ở nơi khác | | Chấp nhận mất khi stop hoặc hỏng phần cứng | | | Loại instance có instance store | không phải loại nào cũng có |

Ba trạng thái và dữ liệu instance store: | Thao tác | Dữ liệu | |---|---| | Reboot | CÒN | | Stop / Start | MẤT | | Terminate | MẤT | | Hỏng phần cứng | MẤT |

Dòng đầu hay bị hiểu nhầm — reboot không mất dữ liệu instance store.

Ba họ instance có NVMe lớn: | Họ | Đặc điểm | |---|---| | i4i, i3en | tối ưu lưu trữ, NVMe dung lượng lớn nhất | | d3, d3en | HDD dung lượng rất lớn | | m6id, c6id, r6id | biến thể "d" của họ thông thường |

Chữ "d" trong tên loại instance nghĩa là có instance store — m5d, c5d, r5d.

Ba cách tăng hiệu năng thêm nữa: | Cách | Chi tiết | |---|---| | RAID 0 nhiều ổ NVMe | cộng dồn IOPS và thông lượng | | Chọn hệ thống tệp phù hợp | XFS thường tốt cho tệp lớn | | Tăng độ sâu hàng đợi I/O | |

RAID 0 với nhiều ổ NVMe:

sudo mdadm --create /dev/md0 --level=0 --raid-devices=4   /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1
sudo mkfs -t xfs /dev/md0

RAID 0 KHÔNG có dư thừa
    → nhưng instance store vốn đã không bền
    → nên không mất gì thêm

Ba lưu ý khi thiết kế quy trình dùng instance store: | Lưu ý | Chi tiết | |---|---| | Tải dữ liệu từ S3 lúc bắt đầu | | | Ghi kết quả lên S3 theo từng phần | không đợi tới cuối | | Làm lại được từ đầu nếu máy biến mất | |

Dòng giữa quan trọng:

Job chạy 6 giờ, chỉ ghi kết quả ở phút cuối
    → máy hỏng ở giờ thứ 5 = mất tất cả

Ghi kết quả từng phần lên S3
    → máy hỏng chỉ mất phần đang xử lý

Ba lưu ý về user data để chuẩn bị ổ: | Lưu ý | Chi tiết | |---|---| | Instance store chưa được định dạng | | | Tên thiết bị có thể đổi giữa các lần khởi động | dùng lsblk để tìm | | Thêm vào /etc/fstab với nofail | tránh máy không khởi động được |

#!/bin/bash
DEV=$(lsblk -dn -o NAME,MODEL | grep -i "Instance Storage" | head -1 | awk '{print "/dev/"$1}')
mkfs -t xfs $DEV
mkdir -p /scratch && mount $DEV /scratch
chmod 777 /scratch

Ba lựa chọn cho tải I/O nặng chia sẻ nhiều máy: | Lựa chọn | Đặc điểm | |---|---| | Instance store | nhanh nhất, KHÔNG chia sẻ được ← câu này | | FSx for Lustre | chia sẻ, tích hợp S3, rất nhanh | | EFS với Elastic throughput | chia sẻ, đơn giản hơn |

FSx for Lustre đáng cân nhắc nếu nhiều máy cùng xử lý:

FSx for Lustre liên kết bucket S3:
    → tự nạp dữ liệu khi cần
    → nhiều máy cùng đọc ghi
    → dựng theo đợt rồi xoá
        ↓
    Phù hợp với tải nghiên cứu chạy theo mẻ

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Instance store MIỄN PHÍ | đã trong giá instance | | Instance có NVMe đắt hơn loại thường một chút | | | Dùng Spot cho tải nghiên cứu chịu gián đoạn | tiết kiệm thêm tới 90% |

Dòng cuối kết hợp rất tốt với đề:

Tải nghiên cứu, tái tạo được, dữ liệu tạm
    → Spot + instance store
        ↓
    Rẻ nhất và nhanh nhất cùng lúc

Và một lời khuyên: hãy ghi kết quả lên S3 theo từng phần thay vì đợi tới cuối job. Instance store và Spot đều có thể biến mất bất ngờ, và một quy trình ghi tăng dần biến sự cố mất máy từ thảm hoạ thành một chút chậm trễ.

Câu 696 Design Cost-Optimized Architectures

A retail company maintains an AWS Direct Connect connection to AWS and has recently migrated its data warehouse to AWS. The data analysts at the company query the data warehouse using a visualization tool. The average size of a query returned by the data warehouse is 60 megabytes and the query responses returned by the data warehouse are not cached in the visualization tool. Each webpage returned by the visualization tool is approximately 600 kilobytes.

Which of the following options offers the LOWEST data transfer egress cost for the company?

  1. A

    Deploy the visualization tool on-premises. Query the data warehouse over the internet at a location in the same AWS region
  2. B

    Deploy the visualization tool in the same AWS region as the data warehouse. Access the visualization tool over a Direct Connect connection at a location in the same region
  3. C

    Deploy the visualization tool in the same AWS region as the data warehouse. Access the visualization tool over the internet at a location in the same region
  4. D

    Deploy the visualization tool on-premises. Query the data warehouse directly over an AWS Direct Connect connection at a location in the same AWS region
Xem giải thích

Đáp án

B — Triển khai công cụ trực quan hoá TRONG CÙNG Region với kho dữ liệu, truy cập công cụ đó qua Direct Connect tại một địa điểm trong cùng Region.

Vì sao đúng

Đây là bài toán tính chi phí truyền dữ liệu RA KHỎI AWS (egress). Điểm mấu chốt là cái gì phải rời AWS.

Hai con số trong đề: | Dữ liệu | Kích thước | |---|---| | Kết quả truy vấn từ kho dữ liệu | 60 MB mỗi truy vấn | | Trang web do công cụ trả về | 600 KB mỗi trang |

Chênh lệch 100 lần — đó là toàn bộ bài toán.

Xét từng phương án:

Công cụ TẠI CHỖ:
    → 60 MB kết quả truy vấn phải RA KHỎI AWS mỗi lần
    → và không được cache (đề nói rõ)
        ↓
    Egress = 60 MB mỗi truy vấn

Công cụ TRONG AWS:
    → 60 MB đi từ kho dữ liệu tới công cụ — TRONG CÙNG REGION
    → chỉ 600 KB trang web ra khỏi AWS
        ↓
    Egress = 600 KB mỗi truy vấn
        ↓
    Giảm 100 LẦN

Và giữa hai cách truy cập công cụ trong AWS: | Đường ra | Giá tham khảo | |---|---| | Internet | ~0,09 USD/GB | | Direct Connect | ~0,02 USD/GB |

Direct Connect có phí truyền dữ liệu ra RẺ HƠN Internet đáng kể — đây là lợi ích chi phí ít được nhắc tới của Direct Connect.

Tổng hợp bốn phương án: | Phương án | Dữ liệu ra | Đơn giá | Tương đối | |---|---|---|---| | A: công cụ tại chỗ, qua Internet | 60 MB | 0,09 USD/GB | cao nhất | | D: công cụ tại chỗ, qua DX | 60 MB | 0,02 USD/GB | cao | | C: công cụ trong AWS, qua Internet | 600 KB | 0,09 USD/GB | thấp | | B: công cụ trong AWS, qua DX | 600 KB | 0,02 USD/GB | THẤP NHẤT |

Nguyên tắc rút ra: đặt tầng xử lý CẠNH dữ liệu, chỉ đưa kết quả đã cô đọng ra ngoài.

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

  • **C. Công cụ trong cùng Region, truy cập qua Internet — đây là phương án gần nhất và đúng hoàn toàn ở quyết định quan trọng nhất (đặt công cụ cạnh dữ liệu), nhưng đường ra qua Internet đắt hơn Direct Connect khoảng 4,5 lần.
  • **D. Công cụ tại chỗ, truy vấn kho dữ liệu qua Direct Connect — 60 MB vẫn phải rời AWS mỗi truy vấn, chỉ được hưởng đơn giá rẻ hơn. Vẫn tốn hơn nhiều so với việc chỉ đưa 600 KB ra.
  • **A. Công cụ tại chỗ, truy vấn qua Internet — tệ nhất trên cả hai phương diện: dữ liệu ra nhiều nhất với đơn giá cao nhất.

Ghi nhớ

Nguyên tắc chi phí truyền dữ liệu của AWS — bảng phải thuộc: | Chiều | Chi phí | |---|---| | VÀO AWS (ingress) | MIỄN PHÍ | | Trong cùng AZ, IP riêng | MIỄN PHÍ | | Giữa các AZ trong cùng Region | ~0,01 USD/GB mỗi chiều | | Giữa các Region | ~0,02 USD/GB trở lên | | RA Internet | ~0,09 USD/GB (giảm dần theo bậc) | | RA qua Direct Connect | ~0,02 USD/GB |

Hai dòng cuối là chìa khoá của câu này.

Nguyên tắc thiết kế rút ra:

Đưa TÍNH TOÁN tới gần DỮ LIỆU, đừng đưa dữ liệu tới gần tính toán. Chỉ đưa ra ngoài phần đã được cô đọng.

Ba cách giảm chi phí egress: | Cách | Tiết kiệm | |---|---| | Đặt xử lý trong AWS, chỉ đưa kết quả ra | ← câu này | | CloudFront cho nội dung phục vụ nhiều lần | rẻ hơn egress trực tiếp | | Direct Connect nếu khối lượng lớn và đều | ~0,02 vs ~0,09 USD/GB |

Ba lợi ích của Direct Connect: | Lợi ích | Chi tiết | |---|---| | Băng thông ổn định | 1–400 Gbps | | Độ trễ thấp và ít biến động | | | Phí truyền dữ liệu ra RẺ HƠN | ← điểm của câu này |

Điểm hoà vốn của Direct Connect:

Chi phí cố định: phí cổng + phí kết nối của nhà cung cấp
Tiết kiệm: (0,09 − 0,02) × số GB mỗi tháng
        ↓
    Với vài chục TB egress mỗi tháng, Direct Connect
    thường tiết kiệm được ngay cả sau khi trừ phí cố định

Ba loại virtual interface của Direct Connect: | Loại | Truy cập | |---|---| | Private VIF | VPC qua IP riêng | | Public VIF | dịch vụ AWS công cộng (S3, DynamoDB) qua DX | | Transit VIF | qua Transit Gateway |

Public VIF đáng biết:

Truy cập S3 qua Direct Connect thay vì Internet
    → hưởng đơn giá egress của DX
    → và không đi qua Internet công cộng

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | KHÔNG mã hoá theo mặc định | chạy IPsec VPN lên trên nếu cần | | Một kết nối là điểm hỏng đơn | nên có hai, hoặc DX + VPN | | Mất hàng tuần tới hàng tháng để thiết lập | |

Ba khoản chi phí của Direct Connect: | Khoản | Chi tiết | |---|---| | Phí cổng theo giờ | tuỳ băng thông | | Phí truyền dữ liệu ra | ~0,02 USD/GB | | Phí kết nối của nhà cung cấp | ngoài AWS |

Ba cách khác giảm dữ liệu truyền: | Cách | Chi tiết | |---|---| | Nén phản hồi | gzip cho HTTP | | Cache ở tầng ứng dụng | đề nói rõ công cụ KHÔNG cache | | Chỉ trả về dữ liệu thật sự cần | phân trang, tổng hợp sẵn |

Dòng giữa là chi tiết cố ý của đề:

"query responses are NOT CACHED in the visualization tool"
        ↓
    Mỗi lần xem là một truy vấn 60 MB mới
    → làm cho quyết định đặt công cụ ở đâu càng quan trọng
        ↓
    Nếu có cache, chênh lệch sẽ nhỏ hơn nhiều

Ba lựa chọn công cụ trực quan hoá trên AWS: | Công cụ | Đặc điểm | |---|---| | Amazon QuickSight | serverless, có SPICE cache trong bộ nhớ | | Amazon Managed Grafana | được quản lý | | Công cụ bên thứ ba trên EC2 | Tableau, Power BI Gateway |

QuickSight với SPICE giải quyết luôn vấn đề cache:

SPICE: bộ nhớ đệm trong RAM của QuickSight
    → truy vấn lặp lại KHÔNG chạm kho dữ liệu
        ↓
    Vừa nhanh hơn, vừa giảm tải Redshift

Ba công cụ phân tích chi phí truyền dữ liệu: | Công cụ | Việc | |---|---| | Cost Explorer lọc theo usage type | DataTransfer-Out-Bytes | | Cost and Usage Report | chi tiết nhất | | VPC Flow Logs | luồng nào chiếm nhiều nhất |

Và một lời khuyên: hãy kiểm tra mục DataTransfer trong Cost Explorer khi rà soát chi phí. Ở nhiều tổ chức, đó là khoản lớn thứ hai hoặc thứ ba sau tính toán và lưu trữ — và gần như luôn giảm được bằng cách đặt lại vị trí của một thành phần, chứ không phải bằng cách dùng ít dữ liệu hơn.

Câu 697 Chọn nhiều đáp án Design Resilient Architectures

The engineering team at an e-commerce company uses an AWS Lambda function to write the order data into a single DB instance Amazon Aurora cluster. The team has noticed that many order- writes to its Aurora cluster are getting missed during peak load times. The diagnostics data has revealed that the database is experiencing high CPU and memory consumption during traffic spikes. The team also wants to enhance the availability of the Aurora DB.

Which of the following steps would you combine to address the given scenario? (Select two)

  1. A

    Handle all read operations for your application by connecting to the reader endpoint of the Amazon Aurora cluster so that Aurora can spread the load for read-only connections across the Aurora replica
  2. B

    Create a replica Aurora instance in another Availability Zone to improve the availability as the replica can serve as a failover target
  3. C

    Create a standby Aurora instance in another Availability Zone to improve the availability as the standby can serve as a failover target
  4. D

    Use Amazon EC2 instances behind an Application Load Balancer to write the order data into Amazon Aurora cluster
  5. E

    Increase the concurrency of the AWS Lambda function so that the order-writes do not get missed during traffic spikes
Xem giải thích

Đáp án

A và B.

  • A — Cho mọi thao tác ĐỌC dùng reader endpoint của Aurora cluster để trải tải qua các replica
  • B — Tạo Aurora replica ở AZ khác để tăng tính sẵn sàng — replica đóng vai trò mục tiêu chuyển đổi

Vì sao đúng

Đề nêu hai vấn đề, và hai đáp án giải quyết đúng từng cái: | Vấn đề | Đáp án | |---|---| | CPU và bộ nhớ cao khi tải tăng → ghi bị bỏ lỡ | A — chuyển tải ĐỌC sang replica, giải phóng writer | | Muốn tăng tính SẴN SÀNG | B — replica ở AZ khác làm mục tiêu chuyển đổi |

A — giải phóng writer bằng cách tách tải đọc:

Cluster chỉ có MỘT instance
    → mọi truy vấn đọc VÀ ghi đều dồn vào nó
    → CPU và bộ nhớ cạn kiệt
        ↓
    Thêm replica + định tuyến đọc qua reader endpoint
    → writer chỉ còn xử lý GHI
    → có đủ tài nguyên cho các lệnh ghi

Reader endpoint:
    cum-abc.cluster-ro-xyz.ap-northeast-1.rds.amazonaws.com
        ↓
    Tự cân bằng tải qua MỌI replica

B — replica cũng là cơ chế sẵn sàng cao:

Aurora replica ở AZ khác:
    ✓ phục vụ đọc
    ✓ ĐỒNG THỜI là mục tiêu chuyển đổi tự động
        ↓
    Writer hỏng → Aurora tự thăng cấp replica
    → thường dưới 30 giây

Đây là điểm khác biệt cốt lõi của Aurora so với RDS thường:

RDS Multi-AZ:  standby KHÔNG phục vụ đọc — chỉ để chờ
Aurora replica: VỪA phục vụ đọc VỪA là mục tiêu chuyển đổi
        ↓
    Một tài nguyên, hai công dụng

Thêm replica:

aws rds create-db-instance --db-instance-identifier reader-1   --db-cluster-identifier cum-don-hang --engine aurora-mysql   --db-instance-class db.r6g.xlarge   --availability-zone ap-northeast-1c   --promotion-tier 1

promotion-tier quyết định thứ tự thăng cấp — tier thấp hơn được ưu tiên.

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

  • **C. Tạo STANDBY Aurora instance ở AZ khác làm mục tiêu chuyển đổi — đây là phương án gần nhất và chỉ khác đáp án B ở một từ, nhưng đó là từ quan trọng: Aurora KHÔNG có khái niệm "standby instance". Aurora dùng replica — vừa phục vụ đọc vừa làm mục tiêu chuyển đổi. "Standby" là thuật ngữ của RDS Multi-AZ.
  • **E. Tăng concurrency của Lambda để lệnh ghi không bị bỏ lỡ — làm vấn đề TỆ HƠN: database đang quá tải, tăng số Lambda ghi đồng thời nghĩa là đẩy thêm áp lực vào chính nút thắt.
  • **D. Dùng EC2 sau ALB để ghi dữ liệu vào Aurora — không giải quyết gì: thay Lambda bằng EC2 không làm database bớt tải, và thêm hạ tầng phải quản lý.

Ghi nhớ

Aurora và RDS Multi-AZ — bảng phải thuộc: | | Aurora replica | RDS Multi-AZ standby | |---|---|---| | Phục vụ đọc | ✅ | ❌ | | Mục tiêu chuyển đổi | ✅ | ✅ | | Số lượng | tới 15 | 1 | | Sao chép | lưu trữ chia sẻ, độ trễ < 100ms | đồng bộ ở tầng khối | | Thời gian chuyển đổi | thường < 30 giây | 60–120 giây |

Ba loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance GHI hiện tại | | Reader | cân bằng tải qua MỌI replica | | Custom | nhóm instance do bạn định nghĩa | | Instance | một instance cụ thể (tránh dùng) |

Ứng dụng phải dùng ĐÚNG endpoint:

Ghi:  cluster endpoint
Đọc:  reader endpoint
        ↓
    Dùng cluster endpoint cho cả hai
    = mọi tải dồn vào writer ← lỗi trong đề

Ba cách tách tải đọc và ghi: | Cách | Chi tiết | |---|---| | Hai chuỗi kết nối trong ứng dụng | đơn giản nhất | | RDS Proxy với read/write splitting | | | Driver hỗ trợ tách tự động | AWS JDBC Driver for MySQL |

Ba đặc điểm của kiến trúc lưu trữ Aurora: | Đặc điểm | Chi tiết | |---|---| | Lưu trữ CHIA SẺ giữa mọi instance | replica không sao chép dữ liệu riêng | | 6 bản sao qua 3 AZ | | | Tự co giãn tới 128 TB | |

Dòng đầu giải thích vì sao độ trễ replica của Aurora rất thấp:

RDS replica: sao chép qua binlog → độ trễ giây tới phút
Aurora replica: đọc từ CÙNG bộ lưu trữ → độ trễ < 100 mili giây

Ba cấu hình cho Aurora sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Ít nhất 1 replica ở AZ khác | ← đáp án B | | Đặt promotion-tier phù hợp | | | Bật Multi-AZ cho cluster | trải qua ít nhất 2 AZ |

Ba lưu ý về Lambda ghi vào database: | Lưu ý | Chi tiết | |---|---| | Dùng RDS Proxy | gộp kết nối, tránh cạn kết nối | | Đặt reserved concurrency | giới hạn áp lực lên database | | Có logic thử lại với backoff | |

RDS Proxy giải quyết vấn đề quan trọng với Lambda:

Mỗi lời gọi Lambda mở một kết nối mới
    → 1.000 Lambda đồng thời = 1.000 kết nối
    → database cạn kết nối
        ↓
    RDS Proxy gộp và tái sử dụng kết nối
    → và giữ kết nối qua các lần chuyển đổi

aws rds create-db-proxy --db-proxy-name proxy-don-hang   --engine-family MYSQL   --auth '[{"SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]'   --role-arn <arn-role> --vpc-subnet-ids subnet-a subnet-c

Ba cách mở rộng khả năng GHI của Aurora: | Cách | Chi tiết | |---|---| | Nâng cỡ instance writer | cách chính | | Aurora Serverless v2 | tự co giãn theo tải | | Sharding ở tầng ứng dụng | phức tạp |

Aurora chỉ có MỘT writer (trừ cấu hình multi-master hiếm dùng) — nên mở rộng ghi chủ yếu là mở rộng theo chiều dọc.

Aurora Serverless v2 đáng cân nhắc cho tải có đỉnh:

aws rds modify-db-cluster --db-cluster-identifier cum-don-hang   --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=64

Tự co giãn trong vài giây theo CPU và bộ nhớ
    → không phải đoán trước cỡ instance
    → phù hợp với "traffic spikes" trong đề

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CPUUtilization của writer | ← vấn đề trong đề | | DatabaseConnections | gần trần thì ghi bị từ chối | | AuroraReplicaLag | replica tụt lại bao xa | | FreeableMemory | |

Ba lưu ý khi định tuyến đọc sang replica: | Lưu ý | Chi tiết | |---|---| | Replica có độ trễ (dù rất nhỏ) | | | Đọc-sau-ghi có thể chưa thấy dữ liệu | đọc lại từ writer nếu cần nhất quán | | Không phải mọi truy vấn đều chuyển sang replica được | |

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

Ghi đơn hàng qua writer
    → ngay lập tức đọc lại qua reader endpoint
    → có thể CHƯA THẤY (độ trễ vài chục mili giây)
        ↓
    Với thao tác cần đọc-sau-ghi, dùng writer endpoint

Và một lời khuyên: hãy thêm RDS Proxy cùng lúc với replica. Vấn đề "ghi bị bỏ lỡ khi tải tăng" thường có hai nguyên nhân chồng lên nhau — database quá tải và cạn kết nối do Lambda mở quá nhiều — và chỉ sửa một trong hai thì triệu chứng vẫn còn nguyên vào lần cao điểm tiếp theo.

Câu 698 Design Resilient Architectures

A data analytics team at a global media firm is building a new analytics platform to process large volumes of both historical and real-time data. This data is stored in Amazon S3. The team wants to implement a serverless solution that allows them to query the data directly using SQL. Additionally, the solution must ensure that all data is encrypted at rest and automatically replicated to another AWS Region to support business continuity.

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

  1. A

    Create an Amazon S3 bucket configured with server-side encryption using Amazon S3 managed keys (SSE-S3). Enable cross-Region replication (CRR) on the source bucket. Use Amazon Redshift Spectrum to query the S3 data using SQL
  2. B

    Create an Amazon S3 bucket configured with server-side encryption using AWS KMS multi-Region keys (SSE-KMS). Enable cross-Region replication (CRR) on the source bucket. Use Amazon Athena to run SQL queries on the data
  3. C

    Enable Cross-Region Replication (CRR) on the existing Amazon S3 bucket. Apply server-side encryption using Amazon S3 managed keys (SSE-S3). Use Amazon Athena to run SQL queries on the replicated data
  4. D

    Enable Cross-Region Replication (CRR) on the existing Amazon S3 bucket. Apply server-side encryption using AWS KMS multi-Region keys (SSE-KMS). Use Amazon Athena to run SQL queries on the replicated data
Xem giải thích

Đáp án

B — Tạo bucket S3 mã hoá bằng SSE-KMS với multi-Region key, bật Cross-Region Replication, dùng Amazon Athena chạy truy vấn SQL.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án B đáp ứng cả bốn với ít công vận hành nhất: | Yêu cầu | Cơ chế | |---|---| | Serverless, truy vấn SQL trực tiếp | Athena | | Mã hoá at rest | SSE-KMS | | Tự sao chép sang Region khác | Cross-Region Replication | | Ít công vận hành nhất | không cụm nào, không ETL nào |

Điểm mấu chốt: multi-Region KMS key.

SSE-KMS với khoá THƯỜNG (một Region):
    → object sao chép sang Region khác
    → nhưng khoá KHÔNG có ở đó
        ↓
    Phải cấu hình khoá riêng ở Region đích
    → và CRR phải mã hoá lại bằng khoá đó
    → thêm cấu hình, thêm chỗ sai

SSE-KMS với MULTI-REGION KEY:
    → cùng key material, cùng key ID ở nhiều Region
    → object sao chép sang giải mã được NGAY
        ↓
    Ít công vận hành nhất — đúng yêu cầu đề

Tạo multi-Region key:

aws kms create-key --multi-region --description "Khoa data lake"   --region ap-northeast-1

aws kms replicate-key --key-id mrk-abc123   --replica-region us-west-2

Và bật CRR:

{"Role": "<arn-role>",
 "Rules": [{
   "ID": "sao-chep-du-phong", "Status": "Enabled",
   "Priority": 1, "Filter": {},
   "DeleteMarkerReplication": {"Status": "Enabled"},
   "SourceSelectionCriteria": {
     "SseKmsEncryptedObjects": {"Status": "Enabled"}},
   "Destination": {
     "Bucket": "arn:aws:s3:::kho-du-phong",
     "EncryptionConfiguration": {"ReplicaKmsKeyID": "<arn-mrk-us-west-2>"}}}]}

SseKmsEncryptedObjects: Enabled là bắt buộc — không có nó thì object mã hoá SSE-KMS không được sao chép.

Và vì sao truy vấn bucket NGUỒN chứ không phải bản sao:

Bản sao là để KHÔI PHỤC THẢM HOẠ
    → truy vấn nó hằng ngày không mang lại lợi ích gì
    → và Athena ở Region khác phải trả phí truyền dữ liệu
        ↓
    Truy vấn nguồn, giữ bản sao để dự phòng

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

  • **D. Bật CRR trên bucket ĐANG CÓ, áp SSE-KMS multi-Region key, dùng Athena truy vấn DỮ LIỆU ĐÃ SAO CHÉP — đây là phương án gần nhất và dùng đúng loại khoá, nhưng nó sai ở hai điểm nhỏ: áp mã hoá sau khi bucket đã có dữ liệu chỉ ảnh hưởng object MỚI (object cũ vẫn chưa mã hoá), và truy vấn bản sao thay vì nguồn là lựa chọn kém tối ưu.
  • **A. SSE-S3 + CRR + Redshift Spectrum — thêm công vận hành: Redshift Spectrum cần một cụm Redshift, đi ngược yêu cầu "least operational overhead" và "serverless".
  • **C. Bật CRR trên bucket đang có, áp SSE-S3, dùng Athena truy vấn dữ liệu đã sao chép — SSE-S3 không cho kiểm soát khoá, và cùng vấn đề áp mã hoá sau khi đã có dữ liệu.

Ghi nhớ

Ba yêu cầu bắt buộc để bật S3 Cross-Region Replication: | Yêu cầu | Chi tiết | |---|---| | Versioning bật ở CẢ HAI bucket | bắt buộc | | IAM role cho S3 thực hiện sao chép | | | Bucket ở HAI Region khác nhau | |

Ba đặc điểm quan trọng của CRR: | Đặc điểm | Chi tiết | |---|---| | Chỉ sao chép object MỚI | object cũ cần S3 Batch Replication | | Bất đồng bộ | thường trong vài phút | | RTC cho SLA 15 phút | Replication Time Control, có phí |

Dòng đầu là điểm hay bị bỏ sót:

aws s3control create-job --account-id 123456789012   --operation '{"S3ReplicateObject":{}}'   --manifest-generator file://manifest.json   --priority 10 --role-arn <arn>

Batch Replication để sao chép dữ liệu đã có từ trước.

Ba loại khoá KMS: | Loại | Đặc điểm | |---|---| | Single-Region key | chỉ dùng trong một Region | | Multi-Region key (MRK) | cùng key material ở nhiều Region | | — | KHÔNG chuyển single-Region thành multi-Region được |

Dòng cuối rất quan trọng:

Khoá đã tạo là single-Region
    → KHÔNG nâng cấp thành multi-Region được
        ↓
    Phải tạo khoá MRK mới và mã hoá lại dữ liệu
    → quyết định này phải đúng từ đầu

Ba trường hợp dùng multi-Region key: | Trường hợp | Chi tiết | |---|---| | S3 CRR với SSE-KMS | ← câu này | | DynamoDB global tables | | | Khôi phục thảm hoạ đa Region | |

Ba lưu ý về CRR với dữ liệu mã hoá: | Lưu ý | Chi tiết | |---|---| | Phải bật SseKmsEncryptedObjects | không thì object SSE-KMS bị bỏ qua | | Role cần quyền kms:Decrypt ở nguồn và kms:Encrypt ở đích | | | Với MRK, cấu hình đơn giản hơn nhiều | |

Ba tính năng của S3 Replication: | Tính năng | Việc | |---|---| | Cross-Region Replication (CRR) | sang Region khác | | Same-Region Replication (SRR) | cùng Region, khác tài khoản hoặc lớp lưu trữ | | Replication Time Control (RTC) | SLA 99,99% trong 15 phút |

Ba lưu ý về Athena với dữ liệu mã hoá: | Lưu ý | Chi tiết | |---|---| | Athena giải mã tự động nếu có quyền KMS | | | Kết quả truy vấn nên được mã hoá | cấu hình ở workgroup | | Không phải sửa truy vấn | trong suốt |

aws athena update-work-group --work-group primary   --configuration-updates '{"ResultConfigurationUpdates":{
    "EncryptionConfiguration":{"EncryptionOption":"SSE_KMS",
    "KmsKey":"<arn-khoa>"}}}'

Ba cách giảm chi phí Athena: | Cách | Tiết kiệm | |---|---| | Định dạng cột (Parquet) | tới 90% | | Phân vùng | rất nhiều | | Nén | |

Ba lưu ý về chi phí của kiến trúc này: | Khoản | Chi tiết | |---|---| | Lưu trữ NHÂN ĐÔI | bản sao tính phí đầy đủ | | Truyền dữ liệu xuyên Region | ~0,02 USD/GB | | Lời gọi KMS | bật S3 Bucket Keys để giảm 99% |

S3 Bucket Keys rất quan trọng với data lake:

{"ApplyServerSideEncryptionByDefault": {
   "SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "<arn-mrk>"},
 "BucketKeyEnabled": true}

Data lake có hàng triệu object
    → không có Bucket Keys thì mỗi lần đọc là một lời gọi KMS
    → chi phí và nguy cơ throttle rất lớn

Ba cách giảm chi phí bản sao: | Cách | Chi tiết | |---|---| | Lifecycle ở bucket đích sang lớp lạnh | bản sao chỉ để khôi phục | | Chỉ sao chép prefix quan trọng | dùng filter | | Destination.StorageClass khai lớp rẻ hơn | |

{"Destination": {"Bucket": "arn:aws:s3:::kho-du-phong",
                 "StorageClass": "STANDARD_IA"}}

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicationLatency | độ trễ sao chép | | OperationsPendingReplication | tồn đọng | | OperationsFailedReplication | thất bại — cần điều tra |

Và một lời khuyên: hãy tạo multi-Region key trước khi ghi bất kỳ dữ liệu nào. Khoá single-Region không chuyển đổi được, nên phát hiện sau khi data lake đã có hàng terabyte nghĩa là phải mã hoá lại toàn bộ — một thao tác vừa tốn kém vừa dài, chỉ để sửa một quyết định mất năm giây ở lúc đầu.

Câu 699 Design High-Performing Architectures

A financial analytics firm runs performance-intensive modeling software on Amazon EC2 instances backed by Amazon EBS volumes. The production data resides on EBS volumes attached to EC2 instances in the same AWS Region where the testing environment is hosted. To maintain data integrity, any changes made during testing must not affect production data. The development team needs to frequently create clones of this production data for simulations. The modeling software requires high and consistent I/O performance, and the firm wants to minimize the time required to provision test data.

Which solution should a solutions architect recommend to meet these requirements?

  1. A

    Create new EBS volumes in the test environment and use AWS Backup to perform a backup job of the production volumes. Restore the backup directly to the test EBS volumes to begin simulations
  2. B

    Use Amazon EBS io2 volumes with Multi-Attach enabled. Attach the same production EBS volumes to both the production and test EC2 instances simultaneously to avoid cloning delays and ensure high IOPS performance
  3. C

    Create Amazon EBS-backed Amazon Machine Images (AMIs) from the production EC2 instances. Launch new EC2 instances in the test environment from the AMIs. Use Amazon EC2 instance store volumes for temporary simulation data
  4. D

    Take snapshots of the production EBS volumes. Enable EBS fast snapshot restore on the snapshots. Create new EBS volumes from the snapshots and attach them to EC2 instances in the test environment
Xem giải thích

Đáp án

D — Chụp snapshot của EBS volume sản xuất, bật EBS Fast Snapshot Restore (FSR) trên snapshot đó, tạo volume mới từ snapshot và gắn vào EC2 ở môi trường thử nghiệm.

Vì sao đúng

Đề nêu bốn yêu cầu, và FSR giải quyết đúng vấn đề khó nhất: | Yêu cầu | Cơ chế | |---|---| | Bản sao dữ liệu sản xuất | snapshot → volume mới | | Thay đổi khi thử nghiệm KHÔNG ảnh hưởng sản xuất | volume độc lập hoàn toàn | | Hiệu năng I/O cao và NHẤT QUÁN ngay | Fast Snapshot Restore | | Rút ngắn thời gian chuẩn bị dữ liệu thử | FSR bỏ giai đoạn khởi tạo |

Vấn đề mà FSR giải quyết — rất đáng biết:

Volume tạo từ snapshot BÌNH THƯỜNG:
    → dữ liệu được nạp LƯỜI (lazy) từ S3
    → khối chưa nạp lần đầu đọc rất CHẬM
        ↓
    Hiệu năng kém trong vài phút tới vài giờ đầu
    → và không đoán trước được khi nào ổn định

Với Fast Snapshot Restore:
    → volume đạt hiệu năng ĐẦY ĐỦ NGAY từ đầu
    → không có giai đoạn khởi tạo
        ↓
    Đúng "high and CONSISTENT I/O performance"
      và "minimize the time required to provision test data"

Bật FSR:

aws ec2 enable-fast-snapshot-restores   --availability-zones ap-northeast-1a ap-northeast-1c   --source-snapshot-ids snap-0abc123

Và tạo volume:

aws ec2 create-volume --snapshot-id snap-0abc123   --availability-zone ap-northeast-1a   --volume-type io2 --iops 20000

Ba đặc điểm của FSR: | Đặc điểm | Chi tiết | |---|---| | Bật theo AZ | phải bật ở AZ sẽ tạo volume | | Cần thời gian "khởi tạo" ban đầu | khoảng 60 phút mỗi TiB | | Tính phí theo AZ-giờ | ~0,75 USD/giờ mỗi snapshot mỗi AZ |

Dòng cuối là đánh đổi cần cân nhắc:

FSR đắt nếu bật liên tục
    → chiến lược tốt: bật trước đợt thử nghiệm, tắt sau đó
        ↓
    Hoặc chỉ bật cho snapshot dùng lặp đi lặp lại

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

  • **A. Tạo EBS volume mới ở môi trường thử, dùng AWS Backup sao lưu volume sản xuất rồi khôi phục vào đó — đây là phương án gần nhất và tạo được bản sao độc lập, nhưng nó chậm hơn và không giải quyết vấn đề hiệu năng ban đầu: khôi phục qua AWS Backup mất thời gian và volume kết quả vẫn có giai đoạn nạp lười.
  • **B. Dùng io2 với Multi-Attach, gắn CHÍNH volume sản xuất vào cả máy sản xuất lẫn máy thử — vi phạm yêu cầu cốt lõi: đề nói rõ thay đổi khi thử nghiệm không được ảnh hưởng dữ liệu sản xuất. Multi-Attach chia sẻ cùng một volume, nên mọi thay đổi đều ảnh hưởng trực tiếp.
  • **C. Tạo AMI từ EC2 sản xuất, khởi động máy thử từ AMI, dùng instance store cho dữ liệu mô phỏng tạm — vòng vèo và mất dữ liệu: AMI dựng lại cả máy chứ không chỉ dữ liệu, và instance store mất dữ liệu khi máy dừng.

Ghi nhớ

Cơ chế nạp lười của EBS snapshot — nên hiểu rõ:

Snapshot lưu trong S3 (do AWS quản lý)
    ↓ tạo volume
Volume "sẵn sàng" ngay, nhưng dữ liệu CHƯA có trên đĩa
    ↓ ứng dụng đọc khối chưa nạp
Khối được kéo từ S3 → chậm cho lần đọc đầu tiên
        ↓
    Fast Snapshot Restore bỏ hẳn giai đoạn này

Ba cách xử lý vấn đề nạp lười: | Cách | Chi tiết | |---|---| | Fast Snapshot Restore | hiệu năng đầy đủ ngay, có phí | | Đọc trước toàn bộ volume | dd if=/dev/nvme1n1 of=/dev/null bs=1M | | Chấp nhận chậm lúc đầu | với tải không nhạy cảm |

Cách thứ hai là giải pháp miễn phí:

sudo dd if=/dev/nvme1n1 of=/dev/null bs=1M status=progress

Buộc mọi khối được nạp trước khi ứng dụng bắt đầu — chậm nhưng không tốn phí FSR.

Ba đặc điểm của EBS snapshot: | Đặc điểm | Chi tiết | |---|---| | Tăng dần (incremental) | chỉ lưu khối THAY ĐỔI so với snapshot trước | | Lưu trong S3 do AWS quản lý | không thấy trong bucket của bạn | | Sao chép xuyên Region được | |

Tính tăng dần là điểm quan trọng về chi phí:

Snapshot đầu:  lưu toàn bộ dữ liệu đã dùng
Snapshot sau:  chỉ lưu phần THAY ĐỔI
        ↓
    Xoá snapshot cũ KHÔNG làm hỏng snapshot mới
    → AWS tự giữ khối còn được tham chiếu

Ba lưu ý về tính nhất quán của snapshot: | Lưu ý | Chi tiết | |---|---| | Snapshot khi đang ghi có thể KHÔNG nhất quán | như rút điện đột ngột | | Với database, dùng cơ chế của chính database | hoặc dừng ghi tạm thời | | AWS Backup hỗ trợ VSS trên Windows | nhất quán ở tầng ứng dụng |

Với phần mềm mô hình tài chính, nên dừng ghi hoặc flush trước khi chụp.

Ba tính năng liên quan tới snapshot: | Tính năng | Việc | |---|---| | Fast Snapshot Restore | hiệu năng đầy đủ ngay ← câu này | | EBS Snapshot Archive | lưu trữ rẻ hơn ~75%, khôi phục mất 24–72 giờ | | Recycle Bin | giữ snapshot đã xoá trong N ngày |

Ba cách tự động hoá snapshot: | Cách | Chi tiết | |---|---| | Data Lifecycle Manager (DLM) | chính sách theo tag, MIỄN PHÍ | | AWS Backup | quản lý tập trung nhiều dịch vụ | | EventBridge + Lambda | tự viết |

DLM là lựa chọn đơn giản nhất:

aws dlm create-lifecycle-policy --description "Snapshot hang ngay"   --state ENABLED --execution-role-arn <arn>   --policy-details file://chinh-sach.json

Ba lưu ý về Multi-Attach: | Lưu ý | Chi tiết | |---|---| | Chỉ io1 và io2 | | | Tới 16 instance trong CÙNG AZ | | | Cần hệ thống tệp CLUSTER-AWARE | ext4 và xfs sẽ HỎNG dữ liệu |

Dòng cuối là lý do phương án B nguy hiểm hơn cả việc vi phạm yêu cầu:

Gắn cùng volume ext4 vào hai máy
    → cả hai cache metadata riêng
    → ghi đè lẫn nhau
        ↓
    HỎNG hệ thống tệp — không chỉ là ảnh hưởng dữ liệu

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Snapshot | ~0,05 USD/GB-tháng (chỉ phần thay đổi) | | Fast Snapshot Restore | ~0,75 USD/giờ mỗi snapshot mỗi AZ | | Snapshot Archive | ~0,0125 USD/GB-tháng |

FSR đắt nếu bật liên tục:

Một snapshot, hai AZ, cả tháng:
    2 × 0,75 × 730 ≈ 1.095 USD/tháng
        ↓
    Chỉ bật khi thật sự cần, rồi tắt

aws ec2 disable-fast-snapshot-restores   --availability-zones ap-northeast-1a   --source-snapshot-ids snap-0abc123

Ba cách khác tạo môi trường thử từ dữ liệu sản xuất: | Cách | Đặc điểm | |---|---| | Snapshot + FSR | ← câu này | | Aurora database cloning | copy-on-write, gần như tức thì, chỉ Aurora | | RDS restore-to-point-in-time | cho RDS |

Aurora cloning đáng biết:

Aurora clone:
    ✓ tạo trong vài phút bất kể dung lượng
    ✓ copy-on-write — ban đầu không tốn thêm dung lượng
    ✓ hoàn toàn độc lập với bản gốc
        ↓
    Nếu database chạy trên Aurora, đây là cách tốt nhất

Ba việc nên làm khi dựng môi trường thử: | Việc | Chi tiết | |---|---| | Che dữ liệu nhạy cảm | dữ liệu tài chính có yêu cầu tuân thủ | | Tách tài khoản AWS riêng | cách ly mạnh nhất | | Tự động hoá việc dựng và huỷ | |

Và một lời khuyên: hãy tắt Fast Snapshot Restore ngay sau khi tạo xong volume thử. Phí của nó tính theo giờ và tiếp tục chạy dù bạn không tạo thêm volume nào — đây là một trong những khoản chi phí âm thầm hay bị bỏ quên nhất, vì nó không gắn với bất kỳ tài nguyên nào hiện trong danh sách EC2.

Câu 700 Design High-Performing Architectures

A global e-commerce platform currently operates its order processing system in a single on-premises data center located in Europe. As the company grows its customer base across Asia and North America, it plans to deploy the application across multiple AWS Regions to improve availability and reduce latency. The company requires that updates to the central order database be completed in under one second with global consistency. The application layer will be deployed separately in each Region, but the order management data must remain centrally managed and globally synchronized.

Which solution should a solutions architect recommend to meet these requirements?

  1. A

    Use Amazon RDS for MySQL with a cross-Region read replica. Route all writes to the primary Region and use read replicas for local access in other Regions
  2. B

    Use Amazon Neptune to store tracking updates as graph data. Deploy clusters in each Region and replicate changes using custom-built Lambda functions and Amazon SQS.
  3. C

    Migrate the order data to Amazon DynamoDB and create a global table. Deploy the application in each Region and connect to the local DynamoDB replica for low-latency access
  4. D

    Use Amazon Aurora database with MySQL engine, and configure read-only nodes in other Regions to handle local traffic while routing all write operations to the central Region
Xem giải thích

Đáp án

C — Chuyển dữ liệu đơn hàng sang Amazon DynamoDB và tạo global table; triển khai ứng dụng ở mỗi Region và kết nối tới bản sao DynamoDB cục bộ.

Vì sao đúng

Đề nêu ba yêu cầu, và global table đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Cập nhật hoàn tất DƯỚI MỘT GIÂY | ghi cục bộ ở Region gần nhất | | Ứng dụng triển khai riêng ở mỗi Region | mỗi Region có bản sao ĐỌC VÀ GHI | | Dữ liệu quản lý tập trung và đồng bộ toàn cầu | DynamoDB tự sao chép hai chiều |

Điểm mấu chốt: global table cho phép GHI ở MỌI Region.

DynamoDB global table:
    → mỗi Region có bản sao ĐẦY ĐỦ
    → ứng dụng ghi vào bản sao CỤC BỘ
    → độ trễ ghi tính bằng mili giây
        ↓
    Sao chép sang các Region khác thường dưới một giây

Và đây là điều Aurora và RDS không làm được:

Aurora Global Database:
    → CHỈ MỘT writer ở Region primary
    → Region phụ chỉ ĐỌC
        ↓
    Ứng dụng ở châu Á muốn ghi
    → phải gửi request về Region primary ở châu Âu
    → độ trễ hàng trăm mili giây

Tạo global table:

aws dynamodb create-table --table-name don-hang   --attribute-definitions AttributeName=ma_don,AttributeType=S   --key-schema AttributeName=ma_don,KeyType=HASH   --billing-mode PAY_PER_REQUEST   --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws dynamodb update-table --table-name don-hang   --replica-updates '[{"Create":{"RegionName":"ap-northeast-1"}},
                      {"Create":{"RegionName":"us-east-1"}}]'

StreamEnabled là điều kiện bắt buộc — global table dùng DynamoDB Streams để sao chép.

Và ứng dụng ở mỗi Region chỉ cần trỏ tới endpoint cục bộ:

import boto3
# Ứng dụng ở Tokyo
bang = boto3.resource('dynamodb', region_name='ap-northeast-1').Table('don-hang')
# Ứng dụng ở Frankfurt
bang = boto3.resource('dynamodb', region_name='eu-central-1').Table('don-hang')

Cùng một dòng mã, chỉ khác tham số Region.

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

  • **D. Dùng Aurora MySQL với read-only node ở các Region khác, định tuyến mọi lệnh ghi về Region trung tâm — đây là phương án gần nhất và là kiến trúc đa Region hợp lệ cho tải nặng đọc, nhưng nó không đạt yêu cầu ghi dưới một giây: lệnh ghi từ châu Á phải đi tới Region trung tâm ở châu Âu, và độ trễ vòng lượt liên lục địa thường vượt xa mức đó.
  • **A. RDS for MySQL với cross-Region read replica, mọi lệnh ghi về Region chính — cùng vấn đề, và độ trễ sao chép của RDS còn cao hơn Aurora.
  • **B. Dùng Amazon Neptune lưu cập nhật dưới dạng đồ thị, sao chép bằng Lambda và SQS tự viết — sai loại database và tự dựng lại thứ đã có: dữ liệu đơn hàng không phải dữ liệu đồ thị, và tự viết cơ chế sao chép đa Region là bài toán rất khó (xử lý xung đột, thứ tự, thử lại).

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

Đề nói "global consistency" nhưng DynamoDB global table là NHẤT QUÁN CUỐI CÙNG.

DynamoDB global table:
    → sao chép BẤT ĐỒNG BỘ
    → thường dưới một giây, nhưng KHÔNG đảm bảo
    → giải quyết xung đột bằng "last writer wins"
        ↓
    KHÔNG có nhất quán mạnh toàn cầu

Hệ quả thực tế cần biết: | Tình huống | Kết quả | |---|---| | Đọc ngay sau khi ghi ở CÙNG Region | có thể nhất quán mạnh (ConsistentRead=True) | | Đọc ở Region KHÁC ngay sau khi ghi | có thể chưa thấy | | Hai Region ghi cùng item cùng lúc | bản ghi có timestamp muộn hơn THẮNG — bản kia MẤT |

Dòng cuối là rủi ro thật với dữ liệu đơn hàng:

Cùng một đơn hàng được cập nhật đồng thời ở hai Region
    → một trong hai thay đổi biến mất
    → KHÔNG có cảnh báo nào
        ↓
    Phải thiết kế sao cho mỗi item chỉ được ghi từ MỘT Region
    (ví dụ: phân vùng theo khu vực của khách hàng)

Nếu nghiệp vụ thật sự đòi nhất quán mạnh toàn cầu, không dịch vụ AWS nào cho điều đó với độ trễ dưới một giây — đó là giới hạn vật lý, không phải giới hạn sản phẩm. Cách hiểu hợp lý của đề là "dữ liệu có mặt ở mọi Region trong dưới một giây", và global table đáp ứng đúng điều đó.

Ghi nhớ

Các lựa chọn database đa Region — bảng phải thuộc: | Dịch vụ | Ghi đa Region | Độ trễ sao chép | |---|---|---| | DynamoDB global table | ✅ mọi Region | thường < 1 giây | | Aurora Global Database | ❌ một writer | < 1 giây (đọc) | | RDS cross-Region replica | ❌ | giây tới phút | | S3 Cross-Region Replication | ✅ (object) | phút |

Từ khoá nhận diện:

"write from multiple Regions", "active-active", "multi-master" → DynamoDB global table "read from multiple Regions, write to one" → Aurora Global Database

Ba yêu cầu của DynamoDB global table: | Yêu cầu | Chi tiết | |---|---| | DynamoDB Streams bật | NEW_AND_OLD_IMAGES | | Cùng tên bảng ở mọi Region | | | Cùng schema khoá | |

Ba đặc điểm của global table: | Đặc điểm | Chi tiết | |---|---| | Ghi được ở MỌI Region | active-active thật sự | | Giải quyết xung đột: last writer wins | dựa trên timestamp | | Thêm Region bất cứ lúc nào | |

Ba lưu ý về chi phí global table: | Khoản | Chi tiết | |---|---| | Mỗi Region tính dung lượng và thông lượng RIÊNG | | | Ghi tính bằng rWCU | đắt hơn WCU thường | | Truyền dữ liệu xuyên Region | |

Phép tính:

3 Region, 1 triệu ghi/tháng:
    → mỗi ghi được sao chép sang 2 Region khác
    → tổng 3 triệu thao tác ghi tính phí
        ↓
    Chi phí gần gấp 3 so với một Region

Ba chiến lược tránh xung đột: | Chiến lược | Chi tiết | |---|---| | Phân vùng theo Region | khách hàng châu Á chỉ ghi ở Region châu Á | | Item bất biến, chỉ thêm mới | event sourcing | | Khoá logic ở tầng ứng dụng | phức tạp |

Chiến lược đầu là cách thực tế nhất:

Thêm mã Region vào partition key hoặc định tuyến theo khách hàng
    → mỗi item chỉ có MỘT Region ghi vào
    → xung đột không bao giờ xảy ra
        ↓
    Vẫn đọc được từ mọi Region

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicationLatency | độ trễ sao chép giữa các Region | | PendingReplicationCount | tồn đọng | | ThrottledRequests | |

Ba tính năng nên bật: | Tính năng | Chi tiết | |---|---| | Point-in-time recovery | bật RIÊNG ở mỗi Region | | Deletion protection | miễn phí | | On-demand hoặc auto scaling | tải toàn cầu khó đoán |

Ba lưu ý về thiết kế bảng: | Lưu ý | Chi tiết | |---|---| | Partition key phân bố đều | mã đơn hàng là lựa chọn tốt | | Tránh item quá lớn | trần 400 KB | | Cân nhắc TTL cho dữ liệu có hạn | |

Ba lựa chọn kiến trúc đa Region cho tầng ứng dụng: | Lựa chọn | Chi tiết | |---|---| | Route 53 latency-based routing | người dùng tới Region gần nhất | | Global Accelerator | IP tĩnh, chuyển vùng nhanh | | CloudFront | cho phần tĩnh |

Và một lời khuyên: hãy thiết kế để mỗi bản ghi đơn hàng chỉ được ghi từ một Region. Cơ chế "last writer wins" của global table không báo lỗi khi có xung đột — nó chỉ lặng lẽ bỏ một trong hai bản cập nhật, và với dữ liệu đơn hàng thì bản bị mất đó có thể là một khoản thanh toán.