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

Đáp án

C — Cấu hình S3 Multi-Region Access Point ở chế độ active-active với một global endpoint duy nhất, kèm S3 Cross-Region Replication.

Vì sao đúng

Đề nêu bốn yêu cầu, và Multi-Region Access Point khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Gửi dữ liệu tới bucket GẦN NHẤT | MRAP tự định tuyến theo độ trễ | | KHÔNG qua mạng công cộng tắc nghẽn | đi trên mạng xương sống AWS | | Chuyển đổi dự phòng tự động | MRAP tự né vùng hỏng | | ÍT quản lý S3 nhất | một endpoint, không logic ở ứng dụng |

Multi-Region Access Point làm gì:

Một tên miền toàn cầu duy nhất
    → khách ở châu Á  → tự tới bucket Singapore
    → khách ở châu Âu → tự tới bucket Ireland
        ↓
    Ứng dụng chỉ biết MỘT endpoint
    → không phải viết logic chọn vùng

Và lưu lượng đi qua mạng riêng của AWS:

Request tới edge location gần nhất
    → rồi đi trên MẠNG XƯƠNG SỐNG AWS tới bucket
        ↓
    Đây là cách đáp ứng "no public network congestion"
    → giống nguyên lý của Global Accelerator

Tạo MRAP:

aws s3control create-multi-region-access-point --account-id 123456789012   --details '{"Name":"kho-toan-cau",
    "Regions":[{"Bucket":"kho-ap-southeast-1"},{"Bucket":"kho-eu-west-1"}]}'

Endpoint có dạng:

kho-toan-cau.abcd1234.mrap.accesspoint.s3-global.amazonaws.com

Và CRR giữ hai bucket đồng bộ:

{"Role": "arn:aws:iam::123456789012:role/vai-tro-crr",
 "Rules": [{"ID":"dong-bo-hai-chieu","Status":"Enabled","Priority":1,
   "Filter":{},"DeleteMarkerReplication":{"Status":"Enabled"},
   "Destination":{"Bucket":"arn:aws:s3:::kho-eu-west-1",
                  "ReplicationTime":{"Status":"Enabled","Time":{"Minutes":15}},
                  "Metrics":{"Status":"Enabled"}}}]}

Vì sao cần CRR bên cạnh MRAP:

MRAP chỉ ĐỊNH TUYẾN request
    → nó KHÔNG tự sao chép dữ liệu
        ↓
    Ghi vào bucket Singapore → khách châu Âu đọc bucket Ireland
    → không thấy object đó nếu chưa sao chép
        ↓
    CRR là phần làm cho active-active thực sự hoạt động

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ứng dụng dùng một endpoint | không có logic vùng | | Tự chuyển khi một vùng hỏng | | | Độ trễ thấp cho mọi khu vực | |

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

• **B. Dùng MRAP ở chế độ active-passive, tạo một global endpoint cho MỖI vùng — đây là phương án gần nhất vì cũng dùng MRAP, nhưng nó sai ở hai chỗ: active-passive nghĩa là mọi lưu lượng đổ về một vùng (không đạt "gần nhất"), và tạo nhiều global endpoint là hiểu sai — MRAP vốn sinh ra để có một endpoint duy nhất.
• **A. Thiết kế active-active rồi cấu hình ứng dụng tự chọn regional endpoint gần nhất — làm được nhưng đẩy toàn bộ logic vào ứng dụng: phải tự phát hiện vùng gần, tự phát hiện vùng hỏng, tự chuyển. Ngược hẳn yêu cầu "least amount of management".
• **D. Gửi tới regional endpoint gần nhất và dùng cross-ACCOUNT replication — nhầm khái niệm: cái cần ở đây là cross-REGION replication. Và vẫn không có cơ chế chuyển đổi dự phòng nào.

Ghi nhớ

Ba cách phân phối truy cập S3 toàn cầu — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Multi-Region Access Point | một endpoint, tự định tuyến và failover ← câu này | | CloudFront | cache nội dung ĐỌC ở edge | | Transfer Acceleration | tăng tốc GHI từ xa vào một bucket |

Từ khoá nhận diện:

"nearest bucket" + "automatic failover" + "least management" → MRAP "cache static content globally" → CloudFront "faster uploads to one bucket" → Transfer Acceleration

Ba đặc điểm của MRAP: | Đặc điểm | Chi tiết | |---|---| | Một tên miền cho nhiều bucket ở nhiều vùng | | | Định tuyến theo độ trễ mạng | | | Đặt trọng số định tuyến từng vùng | 0 tới 100 |

Trọng số 0 chính là cách làm active-passive:

aws s3control submit-multi-region-access-point-routes   --account-id 123456789012 --mrap kho-toan-cau   --route-updates Bucket=kho-eu-west-1,TrafficDialPercentage=0

Đặt trọng số 0 cho một vùng → không nhận lưu lượng
    → dùng để rút một vùng khỏi vòng phục vụ khi bảo trì

Ba yêu cầu để dùng MRAP: | Yêu cầu | Chi tiết | |---|---| | Client hỗ trợ SigV4A | chữ ký đa vùng | | SDK phiên bản mới | | | Bucket bật versioning nếu dùng CRR | |

Vế đầu là ràng buộc kỹ thuật hay vấp:

MRAP yêu cầu ký kiểu SigV4A (asymmetric)
    → SDK cũ chỉ hỗ trợ SigV4
    → request bị từ chối
        ↓
    Kiểm tra phiên bản SDK trước khi thiết kế

Ba đặc điểm của Cross-Region Replication: | Đặc điểm | Chi tiết | |---|---| | BẮT BUỘC bật versioning ở cả hai bucket | | | Chỉ sao chép object MỚI | | | Bất đồng bộ | |

Vế thứ hai là chỗ hay quên:

Bật CRR trên bucket đã có dữ liệu
    → object CŨ không tự sao chép
        ↓
    Phải dùng S3 Batch Replication để chép phần cũ

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

Ba tính năng nâng cao của CRR: | Tính năng | Chi tiết | |---|---| | Replication Time Control (RTC) | cam kết 99,99% object trong 15 phút | | Replication metrics | theo dõi độ trễ và số object chờ | | Two-way replication | đồng bộ hai chiều cho active-active |

Two-way replication là bắt buộc cho active-active thật:

Chỉ sao chép một chiều A → B
    → khách ghi vào B không xuất hiện ở A
        ↓
    Phải cấu hình quy tắc ở CẢ HAI bucket
    → và bật replica modification sync để tránh vòng lặp

Ba lưu ý về nhất quán trong active-active: | Lưu ý | Chi tiết | |---|---| | Sao chép BẤT ĐỒNG BỘ — có độ trễ | | | Ghi cùng key ở hai vùng: bản mới nhất thắng | | | Không có khoá phân tán | |

Vế thứ hai là rủi ro mất dữ liệu âm thầm:

Hai người ở hai vùng cùng ghi đè một object
    → một bản bị mất, KHÔNG có cảnh báo
        ↓
    Thiết kế key theo vùng hoặc theo người dùng để tránh

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ nhân đôi | hai bản đầy đủ | | Phí truyền giữa vùng | | | Phí request của MRAP | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicationLatency | độ trễ sao chép | | OperationsPendingReplication | tồn đọng | | OperationsFailedReplication | lỗi |

Và một lời khuyên: hãy thiết kế khoá object sao cho hai vùng không bao giờ ghi cùng một key (thêm tiền tố vùng hoặc id người dùng). Sao chép hai chiều xử lý được xung đột bằng quy tắc "bản mới nhất thắng", nhưng quy tắc đó có nghĩa là một lần ghi hợp lệ bị vứt đi không dấu vết — và không có metric nào đếm được điều đó cho bạn.

Đáp án

D — Cấu hình AWS Global Accelerator và đặt các ALB làm target.

Vì sao đúng

Đề nêu ba yêu cầu, và Global Accelerator là dịch vụ duy nhất thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Định tuyến TẤT ĐỊNH tới vùng gần nhất | anycast — mạng quyết định, không phải DNS | | Chuyển đổi dự phòng TỰ ĐỘNG | health check, chuyển trong vài giây | | Lưu lượng đi trên MẠNG TOÀN CẦU CỦA AWS | vào edge rồi đi mạng riêng |

Vế đầu là từ khoá quyết định — "deterministic":

DNS (Route 53):  client phân giải tên → nhận IP → CACHE lại
    → hết hạn TTL mới hỏi lại
    → resolver trung gian có thể trả kết quả cũ
        ↓
    Không tất định: cùng một khách có thể nhận IP khác nhau
    → và giữ IP cũ sau khi cấu hình đã đổi

Global Accelerator: hai IP TĨNH anycast
    → cùng một IP được quảng bá từ MỌI edge của AWS
    → mạng tự chọn đường ngắn nhất
        ↓
    Không phụ thuộc DNS cache

Vế thứ ba giải thích vì sao hiệu năng ổn định:

Không có GA:  client ──── Internet công cộng, nhiều nhà mạng ────▶ ALB
              → đường đi thay đổi, độ trễ dao động

Có GA:        client ──▶ edge AWS gần nhất (vài chục ms)
                        │
                        └── MẠNG XƯƠNG SỐNG AWS ──▶ ALB ở vùng đích
              → chặng dài chạy trên mạng riêng

Cấu hình:

aws globalaccelerator create-accelerator --name tang-toc-ung-dung   --ip-address-type IPV4 --enabled

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

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region ap-southeast-1   --endpoint-configurations EndpointId=<arn-alb-sg>,Weight=100   --health-check-interval-seconds 10 --threshold-count 3

Chuyển đổi dự phòng nhanh thế nào:

Health check mỗi 10 giây, ngưỡng 3 lần
    → phát hiện hỏng trong ~30 giây
    → IP không đổi, chỉ đổi đích phía sau
        ↓
    Client KHÔNG cần phân giải lại DNS
    → đây là điểm hơn hẳn Route 53 failover

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hai IP tĩnh — dễ đưa vào allowlist của khách hàng | | | Không phụ thuộc TTL của DNS | | | Hiệu năng ổn định hơn Internet công cộng | |

Vế đầu là lợi ích thực tế lớn với khách hàng doanh nghiệp:

Khách hàng có tường lửa chỉ cho phép IP cụ thể
    → ALB có IP thay đổi → không đưa vào allowlist được
        ↓
    Global Accelerator cho hai IP tĩnh, không đổi suốt đời accelerator

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

• **C. Tạo Route 53 alias record cho mỗi ALB với chính sách latency-based — đây là phương án gần nhất và thực sự định tuyến theo độ trễ, nhưng nó không tất định: kết quả phụ thuộc DNS cache của client và resolver, chuyển đổi dự phòng chậm hơn (phải chờ TTL hết hạn), và lưu lượng vẫn đi qua Internet công cộng chứ không qua mạng AWS.
• **B. Dùng CloudFront với nhiều custom origin — CloudFront tối ưu cho nội dung tĩnh có thể cache. Với ứng dụng web động, phần lớn request vẫn phải về origin, và CloudFront không có cơ chế chọn origin theo độ trễ như đề mô tả.
• **A. Đặt một EC2 proxy trước ALB — tự dựng thứ AWS đã cung cấp: proxy đó thành điểm hỏng mới, phải tự lo co giãn, tự lo health check, và không có mạng anycast toàn cầu.

Ghi nhớ

Global Accelerator và CloudFront — bảng phải thuộc: | | Global Accelerator | CloudFront | |---|---|---| | Có cache | ❌ | ✅ | | Giao thức | TCP và UDP | HTTP/HTTPS | | IP | 2 IP TĨNH anycast | thay đổi | | Tối ưu cho | ứng dụng động, non-HTTP | nội dung tĩnh | | Failover | vài chục giây, không qua DNS | qua origin group |

Từ khoá nhận diện:

"deterministic routing", "static IP", "AWS global network" → Global Accelerator "cache static content", "reduce origin load" → CloudFront "latency-based DNS" → Route 53 (nhưng phụ thuộc DNS cache)

Ba chính sách định tuyến Route 53 dễ lẫn: | Chính sách | Chọn theo | |---|---| | Latency-based | độ trễ mạng đo được | | Geolocation | vị trí địa lý của người dùng | | Geoproximity | khoảng cách tới tài nguyên, có bias |

Ba đặc điểm của Global Accelerator: | Đặc điểm | Chi tiết | |---|---| | Hai IP tĩnh từ hai network zone khác nhau | | | Hỗ trợ ALB, NLB, EC2, Elastic IP | KHÔNG hỗ trợ S3 | | Health check chủ động tới endpoint | |

Ba tham số điều khiển lưu lượng: | Tham số | Việc | |---|---| | Traffic dial (0-100%) | rút bớt lưu lượng khỏi một vùng | | Endpoint weight | tỷ lệ trong cùng nhóm | | Client affinity | giữ client ở cùng endpoint |

Traffic dial rất hữu ích khi triển khai:

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

Đặt 10% cho vùng vừa triển khai bản mới
    → quan sát lỗi
    → ổn thì tăng dần lên 100
        ↓
    Triển khai kiểu blue-green giữa các vùng

Ba lưu ý về client affinity: | Giá trị | Hành vi | |---|---| | NONE | mỗi kết nối định tuyến độc lập | | SOURCE_IP | cùng IP nguồn luôn tới cùng endpoint |

Ứng dụng giữ trạng thái theo phiên
    → dùng SOURCE_IP
    → nhưng làm phân bố tải kém đều hơn

Hai loại accelerator: | Loại | Dùng cho | |---|---| | Standard | định tuyến tới endpoint gần nhất | | Custom routing | ánh xạ cổng tới instance cụ thể (game, VoIP) |

Ba trường hợp Global Accelerator toả sáng: | Trường hợp | Chi tiết | |---|---| | Ứng dụng đa vùng cần failover nhanh | ← câu này | | Giao thức không phải HTTP (game, IoT, VoIP) | | | Khách hàng cần IP tĩnh cho allowlist | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cố định theo GIỜ cho accelerator | ~0,025 USD/giờ | | Phí truyền dữ liệu cao cấp theo GB | | | Đắt hơn Route 53 đáng kể | |

Cân nhắc chi phí là thật:

Route 53 latency-based gần như miễn phí
Global Accelerator có phí cố định + phí theo GB
        ↓
    Chỉ dùng khi thực sự cần IP tĩnh, failover nhanh,
    hoặc hiệu năng qua mạng AWS

Ba lưu ý khi kết hợp với CloudFront: | Lưu ý | Chi tiết | |---|---| | Dùng CloudFront cho nội dung tĩnh | | | Dùng GA cho API và nội dung động | | | Hai dịch vụ bổ sung, không thay thế | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyEndpointCount | endpoint nào còn sống | | NewFlowCount | lượng kết nối mới | | ProcessedBytesIn/Out | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ nhiều khu vực | trước và sau | | Tắt một vùng, đo thời gian chuyển | | | Kiểm tra hai IP tĩnh đã vào allowlist khách | |

Và một lời khuyên: hãy ghi lại hai địa chỉ IP tĩnh vào tài liệu vận hành ngay khi tạo accelerator. Chúng là thứ khách hàng doanh nghiệp sẽ đưa vào tường lửa của họ, và việc xoá rồi tạo lại accelerator sẽ cấp một cặp IP hoàn toàn khác — kéo theo một vòng làm việc với từng khách hàng để cập nhật.

Đáp án

C — Cấu hình AWS Transit Gateway nối Direct Connect gateway với VPC của các tài khoản mới, định tuyến lưu lượng về trung tâm dữ liệu qua transit gateway.

Vì sao đúng

Đề nêu bốn yêu cầu, và Transit Gateway là kiến trúc chuẩn cho tình huống này: | Yêu cầu | Cách đáp ứng | |---|---| | Đã có DX nối trung tâm dữ liệu | tái dùng chính kết nối đó | | Nhiều tài khoản mới cần truy cập DNS và xác thực | chia sẻ TGW qua AWS RAM | | Có khả năng mở rộng | thêm tài khoản = thêm một attachment | | Tiết kiệm, ít công vận hành | một trung tâm định tuyến |

Vì sao dịch vụ hạ tầng lõi cần kiến trúc này:

Xác thực (AD) và DNS là dịch vụ MỌI tài khoản đều cần
    → mỗi tài khoản mới lại nối riêng = không mở rộng nổi
        ↓
    Transit Gateway: nối một lần, dùng cho tất cả

Kiến trúc:

      Trung tâm dữ liệu (AD, DNS)
            │ Direct Connect
      Direct Connect Gateway
            │ transit VIF
      ┌─────▼──────┐
      │  Transit   │◀── chia sẻ qua AWS RAM cho cả OU
      │  Gateway   │
      └─┬───┬───┬──┘
    Khoa A  Khoa B  Khoa C   (tài khoản riêng)

Chia sẻ TGW cho toàn tổ chức:

aws ram create-resource-share --name chia-se-tgw   --resource-arns arn:aws:ec2:ap-southeast-1:111122223333:transit-gateway/tgw-abc   --principals arn:aws:organizations::111122223333:ou/o-abc/ou-root-xyz

Tài khoản khoa mới chỉ cần một lệnh:

aws ec2 create-transit-gateway-vpc-attachment   --transit-gateway-id tgw-abc --vpc-id vpc-khoa-moi   --subnet-ids subnet-a subnet-b

Và định tuyến về trung tâm dữ liệu:

aws ec2 create-route --route-table-id rtb-khoa-moi   --destination-cidr-block 192.168.0.0/16 --transit-gateway-id tgw-abc

Ba lợi ích cho môi trường nhiều đơn vị: | Lợi ích | Chi tiết | |---|---| | Phân đoạn giữa các khoa | bảng định tuyến riêng | | Mọi khoa ra được dịch vụ lõi | | | Nhưng khoa không thấy nhau | |

Phân đoạn bằng nhiều route table:

TGW route table "khoa":
    → có route tới trung tâm dữ liệu
    → KHÔNG có route tới VPC khoa khác
        ↓
    Cách ly bằng cấu hình, không cần firewall riêng

Ba đặc điểm về chi phí: | Đặc điểm | Chi tiết | |---|---| | Một kết nối DX dùng chung | không nhân lên | | Phí attachment theo giờ mỗi VPC | | | Vẫn rẻ hơn nhiều DX hoặc nhiều VPN riêng | |

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

• **D. Dựng Site-to-Site VPN từ trung tâm dữ liệu tới mỗi tài khoản mới — đây là phương án gần nhất vì cũng nối được và cũng rẻ, nhưng nó không mở rộng: mỗi tài khoản một VPN riêng, mỗi cái phải cấu hình BGP và bảo trì, và nó bỏ phí kết nối DX đã có để chạy qua Internet với độ trễ cao hơn.
• **A. Tạo Direct Connect riêng cho mỗi tài khoản — đắt và chậm nhất: DX mất hàng tuần tới hàng tháng để cung cấp, mỗi kết nối một khoản phí cổng. Ngược hẳn "scalable and cost-effective".
• **B. VPC peering giữa VPC có DX và mỗi tài khoản mới — peering KHÔNG bắc cầu: lưu lượng từ VPC khoa không đi xuyên qua VPC trung gian để tới trung tâm dữ liệu được. Đây là hạn chế cơ bản của peering, và cũng là lý do Transit Gateway ra đời.

Ghi nhớ

Ba cách nối nhiều VPC — bảng phải thuộc: | Cách | Bắc cầu | Mở rộng | |---|---|---| | VPC Peering | ❌ KHÔNG | kém — n(n-1)/2 | | Transit Gateway | ✅ | tốt — hình sao ← câu này | | PrivateLink | không áp dụng | tốt (một dịch vụ) |

⚠ "Peering không bắc cầu" là điều phải thuộc:

VPC-A ↔ VPC-Hub (có DX)
VPC-B ↔ VPC-Hub
        ↓
    VPC-A KHÔNG đi qua Hub để tới trung tâm dữ liệu
    → lưu lượng bị chặn ở Hub
        ↓
    Cũng đúng cho: NAT Gateway, VPN, Internet Gateway của VPC khác

Từ khoá nhận diện:

"multiple accounts" + "Direct Connect" + "scalable" → Transit Gateway "expose one service to many VPCs" → PrivateLink "exactly two VPCs" → VPC Peering

Ba thành phần nối DX với nhiều VPC: | Thành phần | Việc | |---|---| | Direct Connect connection | đường vật lý | | Direct Connect Gateway | gộp nhiều vùng, toàn cầu | | Transit VIF | nối DX gateway với TGW |

⚠ Transit VIF cần DX từ 1 Gbps trở lên — hosted connection nhỏ hơn không dùng được.

Ba loại VIF: | Loại | Nối tới | |---|---| | Private VIF | VPC (qua VGW) | | Transit VIF | Transit Gateway ← câu này | | Public VIF | dịch vụ AWS công khai |

Ba khái niệm route table của TGW: | Khái niệm | Nghĩa | |---|---| | Association | attachment này tra bảng nào | | Propagation | route của attachment này vào bảng nào | | Static route | route khai tay |

Mẫu phân đoạn hình sao:

Bảng "dich-vu-loi":
    association: attachment DX
    propagation: từ MỌI VPC khoa

Bảng "khoa":
    association: mọi VPC khoa
    propagation: CHỈ từ attachment DX
        ↓
    Khoa ra được trung tâm dữ liệu
    Khoa không thấy nhau

Ba lưu ý về AWS RAM: | Lưu ý | Chi tiết | |---|---| | Chia sẻ cho OU hoặc từng tài khoản | | | Trong cùng tổ chức: tự chấp nhận | | | Chủ sở hữu vẫn giữ quyền quản lý route table | |

Vế cuối quan trọng về quản trị:

Tài khoản khoa gắn VPC vào TGW được
    → nhưng KHÔNG sửa được bảng định tuyến
        ↓
    Đội hạ tầng trung tâm giữ quyền kiểm soát đường đi

Ba giới hạn cần biết: | Giới hạn | Con số | |---|---| | VPC attachment mỗi TGW | 5.000 | | Băng thông mỗi attachment | ~50 Gbps | | Bảng định tuyến mỗi TGW | 20 |

Ba lưu ý về DNS: | Lưu ý | Chi tiết | |---|---| | Route 53 Resolver endpoint để phân giải tên tại chỗ | | | Forward rule chia sẻ qua RAM | | | Đừng để mỗi tài khoản tự dựng resolver | |

Đây là chi tiết quan trọng vì đề nhắc tới DNS:

aws route53resolver create-resolver-endpoint --direction OUTBOUND   --ip-addresses SubnetId=subnet-a SubnetId=subnet-b   --security-group-ids sg-resolver --name ra-tai-cho

aws route53resolver create-resolver-rule --domain-name truong.edu.vn   --rule-type FORWARD --resolver-endpoint-id rslvr-out-abc   --target-ips Ip=192.168.1.10,Port=53

Rồi chia sẻ rule qua RAM
    → mọi tài khoản khoa phân giải được tên nội bộ

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí attachment theo giờ | nhân số VPC | | Phí xử lý dữ liệu theo GB | | | Phí cổng DX (không đổi) | |

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | search-transit-gateway-routes | route đã lan chưa | | Reachability Analyzer | tìm chỗ chặn | | TGW Flow Logs | xem lưu lượng thật |

Và một lời khuyên: hãy thiết kế bảng định tuyến phân đoạn trước khi gắn tài khoản đầu tiên. Với môi trường nhiều khoa, mặc định "mọi VPC thấy nhau" là một quyết định bảo mật mà không ai chủ động đưa ra — và tách chúng ra sau khi đã có hai chục attachment là việc phải làm từng bước để không cắt nhầm đường đang chạy.

Đáp án

D và E.

• D — Dùng AWS Compute Optimizer lấy khuyến nghị loại instance để co giãn DỌC
• E — Tạo Auto Scaling group và Application Load Balancer để co giãn NGANG

Vì sao đúng

Đề nêu ba dữ kiện, và hai hành động giải quyết hai vấn đề khác nhau: | Dữ kiện | Vấn đề | Giải bằng | |---|---|---| | CPU chạm 100% vào giờ cao điểm | máy quá nhỏ hoặc quá ít | D: đúng cỡ máy | | Cần cải thiện TÍNH SẴN SÀNG | một instance = một điểm hỏng | E: nhiều máy sau ALB | | Tiết kiệm nhất | | cả hai đều không thừa |

Vì sao cần cả hai:

Chỉ làm E (co giãn ngang):
    → nhân bản một loại máy có thể đang sai cỡ
    → nếu máy quá nhỏ, phải chạy rất nhiều máy → đắt
        ↓
Chỉ làm D (đổi cỡ máy):
    → vẫn MỘT máy → vẫn một điểm hỏng
    → không cải thiện tính sẵn sàng
        ↓
    Đúng cỡ TRƯỚC, rồi nhân bản
    → đó mới là cách tiết kiệm nhất

Compute Optimizer làm gì:

Phân tích CloudWatch metric 14 ngày gần nhất
    → so với hàng nghìn cấu hình instance
    → khuyến nghị loại máy phù hợp về CPU, RAM, mạng, đĩa
        ↓
    Kèm ước tính tiết kiệm và mức rủi ro hiệu năng

aws compute-optimizer get-ec2-instance-recommendations   --instance-arns arn:aws:ec2:ap-southeast-1:123456789012:instance/i-abc123   --query "instanceRecommendations[0].recommendationOptions[]" --output table

Rồi dựng ASG + ALB:

aws ec2 create-launch-template --launch-template-name mau-web   --launch-template-data '{"ImageId":"ami-abc","InstanceType":"m6i.large"}'

aws autoscaling create-auto-scaling-group --auto-scaling-group-name asg-web   --launch-template LaunchTemplateName=mau-web,Version='$Latest'   --min-size 2 --max-size 10 --desired-capacity 2   --vpc-zone-identifier "subnet-a,subnet-b,subnet-c"   --target-group-arns <arn-tg> --health-check-type ELB

Chính sách co giãn:

aws autoscaling put-scaling-policy --auto-scaling-group-name asg-web   --policy-name theo-cpu --policy-type TargetTrackingScaling   --target-tracking-configuration '{"TargetValue":60.0,
    "PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"}}'

Ba lợi ích kết hợp: | Lợi ích | Chi tiết | |---|---| | Không còn 100% CPU | máy đúng cỡ + thêm máy khi cần | | Không còn điểm hỏng đơn lẻ | | | Trả tiền theo tải thật | |

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

• **B. Tạo AMI từ máy chủ web và tham chiếu trong launch template mới — đây là phương án gần nhất và thực ra là một BƯỚC cần làm để thực hiện E, nhưng bản thân nó không giải quyết gì: có AMI mà không có ASG thì không có máy nào được tạo thêm, không có ALB thì không có gì phân phối tải.
• **C. Tạo ASG và ALB để co giãn DỌC — mô tả sai: ASG và ALB là công cụ co giãn ngang (thêm máy). Cụm từ "scale vertically" gắn với chúng là không đúng về khái niệm.
• **A. Dùng Compute Optimizer lấy khuyến nghị để co giãn NGANG — cũng lẫn khái niệm: Compute Optimizer khuyến nghị loại instance, tức là công cụ cho co giãn dọc. Nó không quyết định số lượng máy.

Ghi nhớ

Hai kiểu co giãn — bảng phải thuộc: | Kiểu | Nghĩa | Công cụ | |---|---|---| | Dọc (vertical / scale up) | đổi sang máy TO HƠN | Compute Optimizer gợi ý | | Ngang (horizontal / scale out) | THÊM MÁY | ASG + ALB |

Từ khoá nhận diện:

"right-size the instance" → co giãn dọc, Compute Optimizer "add instances", "load balancer" → co giãn ngang, ASG "improve availability" → bắt buộc co giãn ngang (nhiều máy)

Bảng so sánh hai kiểu: | | Dọc | Ngang | |---|---|---| | Trần | loại instance lớn nhất | gần như không | | Gián đoạn | ✅ phải khởi động lại | ❌ không | | Cải thiện tính sẵn sàng | ❌ | ✅ | | Yêu cầu ứng dụng | không | stateless |

Ba dịch vụ tối ưu chi phí của AWS: | Dịch vụ | Việc | |---|---| | Compute Optimizer | khuyến nghị loại instance, volume, Lambda | | Cost Explorer Rightsizing | khuyến nghị dựa trên chi phí | | Trusted Advisor | tài nguyên nhàn rỗi, bảo mật |

Ba loại tài nguyên Compute Optimizer phân tích: | Tài nguyên | Khuyến nghị | |---|---| | EC2 instance | loại và cỡ | | EBS volume | loại và IOPS | | Lambda function | bộ nhớ cấp phát | | Auto Scaling group | loại instance trong nhóm |

Ba mức phân loại của Compute Optimizer: | Mức | Nghĩa | |---|---| | Under-provisioned | quá nhỏ — gây nghẽn ← trường hợp này | | Over-provisioned | quá to — lãng phí | | Optimized | vừa đúng |

⚠ Cần ít nhất 14 ngày dữ liệu CloudWatch để có khuyến nghị đáng tin.

Bật Enhanced Infrastructure Metrics để chính xác hơn:

Mặc định dùng 14 ngày
    → bật enhanced → dùng tới 3 THÁNG
        ↓
    Quan trọng với tải có chu kỳ theo tháng

Ba lưu ý khi chọn máy đúng cỡ: | Lưu ý | Chi tiết | |---|---| | Xem cả CPU, RAM và mạng | không chỉ CPU | | Cân nhắc họ Graviton (ARM) | rẻ hơn ~20% | | Kiểm tra ứng dụng tương thích ARM chưa | |

Vế đầu quan trọng vì CloudWatch không có metric RAM mặc định:

Compute Optimizer không thấy RAM nếu chưa cài CloudWatch Agent
    → khuyến nghị chỉ dựa trên CPU và mạng
        ↓
    Cài agent trước để có khuyến nghị đầy đủ

Ba bước chuyển từ một máy sang ASG: | Bước | Việc | |---|---| | 1. Tách trạng thái ra khỏi máy | session, tệp tải lên | | 2. Tạo AMI, dựng launch template | | | 3. Dựng ALB, target group, ASG | |

Bước 1 là chỗ hay bị bỏ qua nhất:

Ứng dụng nguyên khối thường lưu:
    → session trong bộ nhớ  → chuyển sang ElastiCache
    → tệp tải lên trên đĩa  → chuyển sang S3 hoặc EFS
    → log trên đĩa          → chuyển sang CloudWatch Logs
        ↓
    Bỏ qua bước này thì nhân bản máy sẽ sinh lỗi khó hiểu

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Trải qua nhiều AZ | | | Health check trỏ đường dẫn nhẹ | | | Sticky session nếu chưa tách được state | giải pháp tạm |

Ba metric theo dõi sau khi làm: | Metric | Ý nghĩa | |---|---| | CPUUtilization trung bình nhóm | có còn 100% không | | TargetResponseTime | trải nghiệm thật | | GroupInServiceInstances | ASG có phản ứng không |

Ba cách tiết kiệm thêm: | Cách | Chi tiết | |---|---| | Savings Plans cho phần tải nền | | | Spot cho phần tăng thêm | nếu chịu được gián đoạn | | Graviton nếu ứng dụng chạy được | |

Và một lời khuyên: hãy làm đúng cỡ máy TRƯỚC khi bật Auto Scaling, đừng làm ngược lại. Nếu bạn nhân bản một loại instance đang quá nhỏ, Auto Scaling sẽ vui vẻ chạy mười máy để làm việc mà bốn máy đúng cỡ làm được — và hoá đơn sẽ nói rằng co giãn tự động rất đắt, trong khi vấn đề thật nằm ở chỗ khác.

Đáp án

B — Amazon FSx for Lustre kết hợp với Amazon S3.

Vì sao đúng

Đề nêu bốn yêu cầu, và cặp FSx for Lustre + S3 khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Tải HPC trên Linux, nhiều EC2 | Lustre là hệ thống tệp song song cho HPC | | Truy cập bằng GIAO DIỆN HỆ THỐNG TỆP GỐC | mount POSIX, mã không cần đổi | | Sinh nhiều tệp nhỏ đầu ra | | | Lưu dài hạn TIẾT KIỆM | S3 là kho rẻ nhất |

Vế thứ hai loại hẳn phương án dùng S3 trực tiếp:

"access data using NATIVE FILE SYSTEM INTERFACES"
    → ứng dụng HPC dùng open(), read(), write()
    → không dùng SDK gọi API
        ↓
    S3 là object store qua HTTP — không mount như hệ thống tệp
    → cần một tầng tệp ở giữa

Cách hai dịch vụ phối hợp:

S3 bucket (kho dài hạn, rẻ)
    │ ▲
    │ │ export tự động (tệp đầu ra chảy về S3)
    ▼ │
FSx for Lustre (hệ thống tệp tốc độ cao)
    │
    └── mount trên hàng trăm EC2 chạy tải HPC
        ↓
    Chạy xong → xoá file system → chỉ còn trả tiền S3

Tạo FSx for Lustre liên kết S3:

aws fsx create-file-system --file-system-type LUSTRE   --storage-capacity 1200 --storage-type SSD   --subnet-ids subnet-hpc   --lustre-configuration     'DeploymentType=PERSISTENT_2,PerUnitStorageThroughput=250,
     DataRepositoryConfiguration={
       ImportPath=s3://du-lieu-hpc/dau-vao,
       ExportPath=s3://du-lieu-hpc/dau-ra,
       AutoImportPolicy=NEW_CHANGED}'

Mount trên EC2:

sudo mount -t lustre -o noatime,flock   fs-0123456789abcdef0.fsx.ap-southeast-1.amazonaws.com@tcp:/abcdefgh /fsx

Vì sao Lustre là lựa chọn cho HPC: | Đặc điểm | Con số | |---|---| | Thông lượng | hàng trăm GB/s | | Độ trễ | dưới mili giây | | IOPS | hàng triệu |

So với EFS (vài GB/s), Lustre nhanh hơn hàng chục lần
    → thiết kế cho hàng nghìn client đọc song song một tệp

Ba lợi ích của mô hình "tính toán tạm thời": | Lợi ích | Chi tiết | |---|---| | Chỉ trả tiền Lustre trong lúc chạy | | | Dữ liệu bền vững nằm ở S3 | | | Xoá file system không mất dữ liệu | đã export |

Vế đầu là cách tiết kiệm chính:

Tải HPC chạy theo đợt (mỗi tuần vài giờ)
    → dựng FSx trước khi chạy, xoá sau khi xong
        ↓
    Trả tiền lưu trữ hiệu năng cao chỉ vài giờ mỗi tuần

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

• **A. DataSync với S3 Intelligent-Tiering — đây là phương án gần nhất về mặt lưu trữ dài hạn rẻ, nhưng nó không cung cấp hệ thống tệp nào cho lúc tính toán: DataSync là công cụ di chuyển dữ liệu, không mount được. EC2 vẫn không có giao diện tệp gốc để đọc ghi tốc độ cao.
• **D. FSx for Windows File Server với S3 — sai hệ điều hành: đề nói rõ Linux, còn FSx for Windows dùng SMB và cần Active Directory. Và nó không đạt thông lượng mà tải HPC đòi hỏi.
• **C. EBS volume với S3 Glacier — EBS gắn vào một instance, không chia sẻ được cho nhiều EC2 chạy song song. Và Glacier cần khôi phục hàng giờ, không dùng làm kho cho dữ liệu còn phải truy cập.

Ghi nhớ

Bốn dịch vụ FSx — bảng phải thuộc: | Dịch vụ | Giao thức | Dùng cho | |---|---|---| | FSx for Lustre | Lustre (POSIX) | HPC, ML, thông lượng cực cao ← câu này | | FSx for Windows | SMB | Windows, AD | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức | | FSx for OpenZFS | NFS | di chuyển từ ZFS |

Từ khoá nhận diện:

"HPC", "parallel", "hundreds of GB/s", "Linux" → FSx for Lustre "native file system interface" + "cheap long-term" → Lustre + S3 "shared Linux file system, general purpose" → EFS

EFS và FSx for Lustre — bảng phân biệt: | | EFS | FSx for Lustre | |---|---|---| | Thông lượng | vài GB/s | hàng trăm GB/s | | Độ trễ | mili giây | dưới mili giây | | Tích hợp S3 | ❌ | ✅ import/export tự động | | Đa AZ | ✅ | ❌ một AZ | | Giá | thấp hơn | cao hơn |

Dòng "một AZ" là hạn chế phải biết:

FSx for Lustre nằm trong MỘT AZ
    → EC2 phải cùng AZ để tránh phí và độ trễ chéo
    → không có dự phòng AZ
        ↓
    Nhưng với tải HPC tạm thời thì chấp nhận được
    → dữ liệu bền vững đã nằm ở S3

Hai kiểu triển khai Lustre: | Kiểu | Đặc điểm | |---|---| | Scratch | rẻ hơn, KHÔNG nhân bản, mất dữ liệu khi hỏng đĩa | | Persistent | có nhân bản trong AZ, tự sửa lỗi |

Scratch:    tải chạy ngắn, dữ liệu gốc còn ở S3
Persistent: tải chạy dài, cần dữ liệu tồn tại
        ↓
    Với mô hình "chạy đợt rồi xoá", scratch rẻ hơn đáng kể

Ba tính năng tích hợp S3: | Tính năng | Việc | |---|---| | Import path | object S3 hiện ra như tệp (lazy load) | | Export path | tệp mới ghi chảy về S3 | | AutoImportPolicy | object mới trong S3 tự hiện trong file system |

Lazy loading là chi tiết hay:

Tạo file system với import path
    → METADATA của mọi object hiện ra ngay
    → NỘI DUNG chỉ tải về khi có ai đọc lần đầu
        ↓
    File system 1 TB dùng được ngay mà không phải chép trước

Export thủ công khi cần:

aws fsx create-data-repository-task --file-system-id fs-abc   --type EXPORT_TO_REPOSITORY --paths /fsx/ket-qua   --report Enabled=true,Path=s3://du-lieu-hpc/bao-cao,Format=REPORT_CSV_20191124,Scope=FAILED_FILES_ONLY

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Thông lượng theo dung lượng cấp phát | file system lớn hơn = nhanh hơn | | PerUnitStorageThroughput cho Persistent | 125/250/500/1000 MB/s mỗi TiB | | Dùng cluster placement group cho EC2 | |

Ba lưu ý về nhiều tệp nhỏ: | Lưu ý | Chi tiết | |---|---| | Lustre xử lý tệp nhỏ kém hơn tệp lớn | | | Cân nhắc gom tệp đầu ra trước khi export | | | S3 cũng có phí request theo số object | |

Vế cuối liên quan trực tiếp tới đề:

"large quantity of SMALL output files"
    → hàng triệu object nhỏ trong S3
    → phí PUT request có thể vượt phí lưu trữ
        ↓
    Gom thành archive trước khi export là cách tối ưu

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lustre đắt hơn S3 nhiều lần mỗi GB | | | Xoá file system khi không chạy | | | S3 lifecycle sang IA hoặc Glacier cho dữ liệu cũ | |

Ba bước quy trình HPC điển hình: | Bước | Việc | |---|---| | 1. Tạo FSx từ S3 import path | | | 2. Chạy tải, ghi kết quả vào /fsx | | | 3. Export về S3 rồi xoá file system | |

Ba dịch vụ bổ trợ: | Dịch vụ | Việc | |---|---| | AWS ParallelCluster | dựng cụm HPC tự động | | AWS Batch | xếp lịch job | | Elastic Fabric Adapter (EFA) | mạng độ trễ cực thấp giữa node |

Và một lời khuyên: hãy kiểm tra báo cáo của tác vụ export trước khi xoá file system. Export là bất đồng bộ, và một tệp bị lỗi sẽ nằm im trong báo cáo chứ không chặn việc xoá — nghĩa là bạn có thể xoá đi kết quả của một lần chạy dài mà tin rằng nó đã an toàn trong S3.

Đáp án

B — Tạo Amazon FSx for Lustre file system, nối vào máy chủ gốc và máy chủ ứng dụng.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ một dịch vụ đáp ứng được: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu trữ CHIA SẺ cho ứng dụng game | hệ thống tệp nhiều máy mount chung | | **Phải dùng được Lustre client | chỉ FSx for Lustre nói giao thức Lustre | | ĐƯỢC QUẢN LÝ HOÀN TOÀN | AWS lo hạ tầng, vá lỗi, nhân bản |

Vế thứ hai là ràng buộc tuyệt đối:

"the ability to use LUSTRE CLIENTS to access data"
    → Lustre là một giao thức hệ thống tệp song song cụ thể
    → không có dịch vụ AWS nào khác nói giao thức này
        ↓
    Câu hỏi gần như tự trả lời

Tạo file system:

aws fsx create-file-system --file-system-type LUSTRE   --storage-capacity 1200 --storage-type SSD   --subnet-ids subnet-game   --lustre-configuration     'DeploymentType=PERSISTENT_2,PerUnitStorageThroughput=250'

Mount bằng Lustre client:

sudo amazon-linux-extras install -y lustre
sudo mount -t lustre -o noatime,flock   fs-0123456789abcdef0.fsx.ap-southeast-1.amazonaws.com@tcp:/abcdefgh /du-lieu-game

Vì sao Lustre hợp với ứng dụng game: | Đặc điểm | Lợi ích | |---|---| | Thông lượng hàng trăm GB/s | tải asset lớn nhanh | | Độ trễ dưới mili giây | | | Hàng nghìn client đọc song song | nhiều máy chủ game cùng đọc |

Ba lợi ích của "fully managed": | Lợi ích | Chi tiết | |---|---| | Không tự cài và cấu hình cụm Lustre | vốn rất phức tạp | | AWS lo vá lỗi và nhân bản | | | Sao lưu tự động (với Persistent) | |

Vế đầu đáng nhấn mạnh:

Tự dựng Lustre trên EC2:
    → cấu hình MDS, OSS, OST, mạng
    → tự lo hỏng đĩa, tự lo mở rộng
        ↓
    Đây là một trong những hệ thống tệp khó vận hành nhất
    → "fully managed" là yêu cầu rất đáng giá

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

• **D. Tạo EFS và cấu hình nó hỗ trợ Lustre — đây là phương án gần nhất vì cũng là hệ thống tệp chia sẻ được quản lý, nhưng nó mô tả một thứ không tồn tại: EFS chỉ nói NFS, không có tuỳ chọn nào bật Lustre. Đây là bẫy phổ biến — ghép tên hai dịch vụ có thật thành một tính năng không có thật.
• **A. Tạo file gateway với Storage Gateway — Storage Gateway xuất NFS hoặc SMB, không phải Lustre. Và nó dành cho hạ tầng tại chỗ truy cập đám mây, còn đây là ứng dụng đã chạy trên AWS.
• **C. Giao DataSync task chia sẻ dữ liệu như một hệ thống tệp mount được — hiểu sai vai trò DataSync: nó là công cụ di chuyển dữ liệu giữa các kho, không tạo ra hệ thống tệp nào để mount.

Ghi nhớ

Bốn dịch vụ FSx và giao thức của chúng — bảng phải thuộc: | Dịch vụ | Giao thức | |---|---| | FSx for Lustre | Lustre ← câu này | | FSx for Windows File Server | SMB | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | | FSx for OpenZFS | NFS |

Và ba dịch vụ tệp khác: | Dịch vụ | Giao thức | |---|---| | Amazon EFS | NFS v4 | | Storage Gateway (file) | NFS, SMB | | Amazon S3 | HTTP API (không phải hệ thống tệp) |

Từ khoá nhận diện — ánh xạ giao thức là cách nhanh nhất:

"Lustre" → FSx for Lustre "SMB", "Windows", "Active Directory" → FSx for Windows "NFS", "Linux", "POSIX" → EFS "iSCSI" → Volume Gateway hoặc FSx for ONTAP

Hai kiểu triển khai FSx for Lustre: | Kiểu | Đặc điểm | |---|---| | Scratch | rẻ, KHÔNG nhân bản, cho dữ liệu tạm | | Persistent | nhân bản trong AZ, tự sửa lỗi, có sao lưu |

Ứng dụng game phục vụ người chơi thật
    → dữ liệu phải tồn tại
    → Persistent

Ba mức thông lượng của Persistent: | PerUnitStorageThroughput | Đơn vị | |---|---| | 125, 250, 500, 1000 | MB/s trên mỗi TiB dung lượng |

File system 4,8 TiB với 250 MB/s/TiB
    → 1.200 MB/s tổng thông lượng
        ↓
    Muốn nhanh hơn: tăng dung lượng hoặc tăng mức

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | FSx for Lustre nằm trong MỘT AZ | | | EC2 nên cùng AZ | tránh phí và độ trễ chéo | | Security group mở cổng 988 và 1018-1023 | |

Cổng là chỗ hay quên:

aws ec2 authorize-security-group-ingress --group-id sg-fsx   --protocol tcp --port 988 --source-group sg-game
aws ec2 authorize-security-group-ingress --group-id sg-fsx   --protocol tcp --port 1018-1023 --source-group sg-game

Ba tính năng tích hợp S3: | Tính năng | Việc | |---|---| | Import path | object S3 hiện ra như tệp | | Export path | tệp mới chảy về S3 | | Lazy loading | nội dung tải khi đọc lần đầu |

Với ứng dụng game, mô hình thường dùng là:

Asset gốc nằm trong S3 (bền, rẻ)
    → FSx for Lustre import từ S3
    → máy chủ game đọc từ Lustre (nhanh)
        ↓
    Cập nhật asset: ghi vào S3, AutoImportPolicy tự đồng bộ

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Chỉ Persistent mới có sao lưu tự động | | | Sao lưu giữ tối đa 90 ngày | | | Scratch không sao lưu được | |

Ba lưu ý về hiệu năng phía client: | Lưu ý | Chi tiết | |---|---| | Cài đúng phiên bản Lustre client cho kernel | | | Dùng noatime giảm ghi metadata | | | Tăng số luồng đọc song song | |

Vế đầu là nguồn sự cố hay gặp:

Nâng cấp kernel của EC2
    → module Lustre client không còn khớp
    → mount thất bại sau khi khởi động lại
        ↓
    Ghim phiên bản kernel, hoặc cài lại client sau mỗi lần nâng cấp

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Đắt hơn EFS và S3 nhiều lần mỗi GB | | | Tính theo dung lượng CẤP PHÁT, không phải dùng thật | | | Persistent đắt hơn Scratch | |

Vế thứ hai khác hẳn EFS:

EFS:    trả theo dung lượng THỰC DÙNG
Lustre: trả theo dung lượng ĐÃ CẤP PHÁT
        ↓
    Cấp 12 TiB mà dùng 1 TiB vẫn trả tiền 12 TiB

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | DataReadBytes / DataWriteBytes | thông lượng thật | | FreeDataStorageCapacity | sắp đầy chưa | | ClientConnections | số máy đang mount |

Và một lời khuyên: hãy ghim phiên bản kernel trên các máy chủ game mount Lustre, hoặc đưa việc cài lại client vào quy trình vá hệ điều hành. Lustre client là module kernel, và một bản vá bảo mật định kỳ có thể làm mọi máy chủ mất kết nối tới kho dữ liệu ngay lần khởi động lại tiếp theo.

Đáp án

C và E.

• C — Tạo VPC endpoint cho Amazon S3
• E — Áp bucket policy giới hạn truy cập chỉ từ endpoint đó

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi hành động giải quyết một vế: | Yêu cầu | Hành động | |---|---| | Lưu lượng KHÔNG qua Internet, dùng IP riêng | C: VPC endpoint | | Bucket CHỈ cho phép truy cập từ dịch vụ trong VPC | E: bucket policy điều kiện endpoint |

Vì sao cần cả hai:

Chỉ làm C:
    → lưu lượng từ EC2 đi qua endpoint (riêng tư) ✓
    → NHƯNG bucket vẫn nhận request từ Internet
    → ai có credential hợp lệ vẫn vào được từ ngoài
        ↓
Chỉ làm E:
    → chặn được đường ngoài
    → nhưng không có endpoint thì chính EC2 cũng không vào được
        ↓
    Hai vế bổ sung nhau chặt chẽ

Tạo gateway endpoint cho S3:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-southeast-1.s3   --vpc-endpoint-type Gateway   --route-table-ids rtb-rieng-tu-a rtb-rieng-tu-b

Gateway endpoint hoạt động thế nào:

Nó thêm một route vào bảng định tuyến:
    đích = prefix list của S3 (pl-xxxx)
    next hop = vpce-xxxx
        ↓
    Gói tin tới S3 không đi ra Internet Gateway hay NAT
    → đi thẳng qua hạ tầng AWS

Bucket policy giới hạn theo endpoint:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChiChoQuaVpcEndpoint",
   "Effect": "Deny",
   "Principal": "*",
   "Action": "s3:*",
   "Resource": ["arn:aws:s3:::kho-nhay-cam",
                "arn:aws:s3:::kho-nhay-cam/*"],
   "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}]}

Đọc chính sách này:

TỪ CHỐI mọi thao tác nếu request KHÔNG đến từ endpoint vpce-0abc123
    → request từ Internet: bị từ chối
    → request từ VPC khác: bị từ chối
    → request qua endpoint đúng: được phép (theo IAM policy)

Ba khoá điều kiện dùng được: | Khoá | Ý nghĩa | |---|---| | aws:SourceVpce | một endpoint cụ thể ← chặt nhất | | aws:SourceVpc | mọi endpoint trong một VPC | | aws:VpcSourceIp | IP riêng của nguồn |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần NAT Gateway cho lưu lượng S3 | tiết kiệm đáng kể | | Không có đường ra Internet | | | Bucket bị khoá vào đúng một VPC | |

Vế đầu là lợi ích chi phí thật:

Không có endpoint:  EC2 ở subnet riêng tư gọi S3 qua NAT Gateway
                    → trả phí xử lý dữ liệu của NAT theo GB
        ↓
Có gateway endpoint: MIỄN PHÍ, không tính phí dữ liệu
    → với tải nặng S3, tiết kiệm rất lớn

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

• **A. Bật mã hoá mặc định trên bucket — đây là việc nên làm và thường xuất hiện cùng nhóm chủ đề, nhưng mã hoá bảo vệ dữ liệu khi lưu trữ, hoàn toàn không liên quan tới đường đi mạng hay kiểm soát truy cập mà đề hỏi.
• **B. Tạo VPC peering tới "VPC chứa S3 bucket" — S3 không nằm trong VPC nào cả. Nó là dịch vụ vùng, truy cập qua endpoint công khai hoặc VPC endpoint. Không có VPC nào để peer tới.
• **D. Áp IAM policy lên một VPC peering connection — không có khái niệm này: IAM policy gắn vào danh tính hoặc tài nguyên, không gắn vào kết nối peering.

Ghi nhớ

Hai loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ hỗ trợ | Cơ chế | Phí | |---|---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | route trong bảng định tuyến | MIỄN PHÍ | | Interface endpoint (PrivateLink) | hầu hết dịch vụ AWS | ENI có IP riêng trong subnet | tính phí giờ + GB |

Từ khoá nhận diện:

"S3 or DynamoDB" + "no internet" → gateway endpoint (miễn phí) "other AWS services" + "no internet" → interface endpoint "bucket only accessible from VPC" → bucket policy với aws:SourceVpce

Ba đặc điểm của gateway endpoint: | Đặc điểm | Chi tiết | |---|---| | Miễn phí hoàn toàn | | | Chỉ dùng được TỪ TRONG VPC | không dùng từ tại chỗ qua DX/VPN | | Phải gắn vào BẢNG ĐỊNH TUYẾN | |

Vế thứ ba là lỗi im lặng hay gặp nhất:

Tạo endpoint nhưng quên chọn route table
    → không có route nào được thêm
    → lưu lượng vẫn đi qua NAT như cũ
        ↓
    Mọi thứ VẪN CHẠY, chỉ là vẫn tốn phí NAT
    → không có lỗi nào để phát hiện

Kiểm tra route đã có chưa:

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu-a   --query "RouteTables[0].Routes[?GatewayId!=null].[DestinationPrefixListId,GatewayId]"   --output table

Vế thứ hai cũng quan trọng:

Máy chủ tại chỗ qua Direct Connect muốn tới S3 riêng tư
    → gateway endpoint KHÔNG dùng được
        ↓
    Phải dùng interface endpoint cho S3
    → hoặc public VIF của DX

Ba lớp kiểm soát cho một bucket nhạy cảm: | Lớp | Việc | |---|---| | Block Public Access | chặn cấu hình công khai nhầm | | Bucket policy với điều kiện endpoint | giới hạn đường vào ← câu này | | IAM policy trên role của EC2 | ai được làm gì |

Ba lưu ý về endpoint policy: | Lưu ý | Chi tiết | |---|---| | Endpoint cũng có policy riêng | mặc định cho phép tất cả | | Siết lại để chỉ cho vài bucket | | | Chặn được việc gửi dữ liệu ra bucket lạ | |

Endpoint policy chống rò rỉ dữ liệu:

{"Statement": [{
  "Effect": "Allow", "Principal": "*", "Action": "s3:*",
  "Resource": ["arn:aws:s3:::kho-nhay-cam",
               "arn:aws:s3:::kho-nhay-cam/*"]}]}

Endpoint chỉ cho phép truy cập bucket của công ty
    → mã độc trong EC2 không đẩy được dữ liệu
      ra bucket của kẻ tấn công
        ↓
    Đây là biện pháp chống exfiltration rất hiệu quả

Ba lưu ý khi áp bucket policy Deny: | Lưu ý | Chi tiết | |---|---| | Deny áp cho MỌI principal, kể cả root | | | Dễ tự khoá mình ra ngoài | | | Thử ở bucket không quan trọng trước | |

Vế thứ hai là rủi ro thật:

Áp Deny theo aws:SourceVpce
    → console AWS truy cập từ trình duyệt (qua Internet)
    → chính bạn cũng không xem được bucket
        ↓
    Cân nhắc thêm ngoại lệ cho một role quản trị

Ba khoá điều kiện liên quan cần biết: | Khoá | Dùng khi | |---|---| | aws:SourceVpce | giới hạn theo endpoint | | aws:SourceVpc | giới hạn theo VPC | | aws:PrincipalOrgID | chỉ tài khoản trong tổ chức |

Ba dịch vụ hay cần interface endpoint: | Dịch vụ | Vì sao | |---|---| | Secrets Manager | lấy mật khẩu CSDL | | SSM và SSM Messages | Session Manager | | ECR (api và dkr) | kéo ảnh container |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra route đã thêm chưa | describe-route-tables | | Thử aws s3 ls từ EC2 | phải chạy được | | Thử từ ngoài với credential hợp lệ | phải bị từ chối |

Và một lời khuyên: hãy kiểm tra bảng định tuyến sau khi tạo gateway endpoint, đừng chỉ tin vào thông báo "created". Đây là kiểu lỗi tệ nhất: mọi thứ vẫn hoạt động bình thường, chỉ có điều lưu lượng vẫn chạy qua NAT Gateway và bạn vẫn trả tiền cho từng GB — cho tới khi ai đó đọc kỹ hoá đơn.

Đáp án

A — Cấu hình EC2 Auto Scaling target tracking cho tầng xử lý, dùng metric ApproximateNumberOfMessages của SQS để co giãn theo độ dài hàng đợi.

Vì sao đúng

Đề nêu bốn dữ kiện, và cả bốn chỉ về cùng một lời giải: | Dữ kiện | Ý nghĩa | |---|---| | Tầng xử lý chạm 100% CPU | thiếu năng lực xử lý | | Độ dài hàng đợi SQS TĂNG MẠNH | tồn đọng — chỉ báo trực tiếp nhất | | Đợt cao điểm KHÔNG ĐOÁN TRƯỚC ĐƯỢC | loại co giãn theo lịch và dự đoán | | Đã có SQS giữa hai tầng | hạ tầng sẵn sàng cho co giãn theo hàng đợi |

Vì sao độ dài hàng đợi tốt hơn CPU:

CPU 100% chỉ nói "máy đang bận"
    → nó bão hoà ở 100% và không cho biết CÒN THIẾU BAO NHIÊU
        ↓
Độ dài hàng đợi nói "còn 8.000 đơn chưa xử lý"
    → đo được mức tồn đọng thật
    → biết cần thêm bao nhiêu máy

Và nó phản ứng sớm hơn:

Tải tăng → hàng đợi dài ra NGAY LẬP TỨC
         → CPU cần thời gian mới lên tới ngưỡng
             ↓
    Co giãn theo hàng đợi bắt đầu thêm máy sớm hơn

Cách làm chuẩn — dùng metric "backlog mỗi instance":

Backlog per instance = ApproximateNumberOfMessagesVisible / số instance đang chạy
        ↓
    Đây là con số nên đặt làm mục tiêu
    → ví dụ: mỗi máy xử lý được 100 thông điệp
    → đặt TargetValue = 100

Cấu hình:

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

Hoặc đơn giản hơn, dùng thẳng metric SQS:

aws cloudwatch put-metric-alarm --alarm-name hang-doi-dai   --metric-name ApproximateNumberOfMessagesVisible   --namespace AWS/SQS --dimensions Name=QueueName,Value=hang-doi-don   --statistic Average --period 60 --evaluation-periods 2   --threshold 1000 --comparison-operator GreaterThanThreshold

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phản ứng với tải thật, không phải triệu chứng | | | Không cần đoán trước lịch cao điểm | | | Tự bớt máy khi hàng đợi rỗng | |

Và target tracking tự lo phần khó:

Nó tự tạo hai CloudWatch alarm (một để thêm, một để bớt)
    → tự tính cần thay đổi bao nhiêu máy
    → scale out nhanh, scale in chậm để tránh dao động
        ↓
    Không phải khai từng bậc như step scaling

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

• **D. Dùng predictive scaling thêm máy trước giờ cao điểm, dựa trên CPU — đây là phương án gần nhất vì cũng là co giãn tự động, nhưng đề nói rõ "These peak periods are UNPREDICTABLE". Predictive scaling học từ mẫu lịch sử lặp lại; với tải ngẫu nhiên nó không có gì để dự đoán.
• **B. Dùng CloudFront cache nội dung tĩnh ở tầng web và co giãn tầng xử lý theo số request HTTP — CloudFront không giúp gì cho tầng xử lý bất đồng bộ, và tầng xử lý không nhận request HTTP — nó lấy việc từ SQS, nên metric đó không phản ánh tải của nó.
• **C. Dùng ElastiCache giảm tải DynamoDB và co giãn tầng xử lý theo lịch — đề không nói DynamoDB là nút thắt (nút thắt là CPU của tầng xử lý), và co giãn theo lịch mâu thuẫn với "không đoán trước được".

Ghi nhớ

Nguyên tắc gốc:

Co giãn theo metric phản ánh CÔNG VIỆC CÒN LẠI, không phải theo triệu chứng của máy.

Từ khoá nhận diện:

"SQS queue length increases" + "unpredictable" → co giãn theo ApproximateNumberOfMessagesVisible "predictable daily pattern" → scheduled hoặc predictive "CPU bound web tier" → CPU utilization

Bốn kiểu chính sách co giãn: | Kiểu | Kích hoạt bởi | |---|---| | Target tracking | giữ metric ở mục tiêu ← nên dùng | | Step scaling | bậc theo mức vượt ngưỡng | | Simple scaling | kiểu cũ | | Scheduled / Predictive | thời gian / dự đoán — cần mẫu lặp lại |

Ba metric SQS quan trọng: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | đang chờ xử lý ← dùng để co giãn | | ApproximateNumberOfMessagesNotVisible | đang được xử lý | | ApproximateAgeOfOldestMessage | có bị kẹt không |

Metric thứ ba đáng đặt alarm nhất:

Hàng đợi ngắn nhưng thông điệp cũ
    → có gì đó không xử lý được, cứ quay vòng
        ↓
    Dấu hiệu cần dead-letter queue

Công thức tính mục tiêu backlog:

1. Đo: một instance xử lý được bao nhiêu thông điệp mỗi phút?
2. Quyết định: chấp nhận chờ tối đa bao lâu?
3. Mục tiêu = (thông lượng mỗi máy) × (thời gian chờ chấp nhận được)

Ví dụ: 20 thông điệp/phút mỗi máy, chấp nhận chờ 5 phút
    → mục tiêu backlog mỗi instance = 100

Đẩy metric tuỳ chỉnh:

import boto3
sqs = boto3.client('sqs'); asg = boto3.client('autoscaling')
cw = boto3.client('cloudwatch')

so_tin = int(sqs.get_queue_attributes(QueueUrl=URL,
    AttributeNames=['ApproximateNumberOfMessages'])
    ['Attributes']['ApproximateNumberOfMessages'])
so_may = len([i for i in asg.describe_auto_scaling_groups(
    AutoScalingGroupNames=['asg-xu-ly'])['AutoScalingGroups'][0]['Instances']
    if i['LifecycleState'] == 'InService'])

cw.put_metric_data(Namespace='UngDung/DonHang', MetricData=[{
    'MetricName': 'BacklogPerInstance',
    'Value': so_tin / max(so_may, 1)}])

Ba lưu ý về scale in: | Lưu ý | Chi tiết | |---|---| | Đặt ScaleInCooldown dài hơn scale out | | | Dùng lifecycle hook để xử lý nốt việc | | | Ứng dụng phải xử lý SIGTERM | |

Lifecycle hook là chi tiết quan trọng:

aws autoscaling put-lifecycle-hook --auto-scaling-group-name asg-xu-ly   --lifecycle-hook-name cho-xu-ly-xong   --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING   --heartbeat-timeout 300

Máy sắp bị tắt → ASG giữ nó ở trạng thái chờ
    → ứng dụng xử lý nốt thông điệp đang cầm
    → rồi báo ASG tiếp tục
        ↓
    Không có hook: thông điệp đang xử lý bị cắt giữa chừng
    (nó quay lại hàng đợi, nhưng công đã làm bị phí)

Ba lưu ý về visibility timeout: | Lưu ý | Chi tiết | |---|---| | Phải ≥ thời gian xử lý dài nhất | | | Tối đa 12 giờ | | | Gia hạn động khi cần | change_message_visibility |

Ba lưu ý về dead-letter queue: | Lưu ý | Chi tiết | |---|---| | BẮT BUỘC phải có | | | maxReceiveCount thường 3-5 | | | Đặt alarm khi DLQ có thông điệp | |

Không có DLQ thì hậu quả rõ ràng:

Một đơn hàng gây lỗi ứng dụng
    → thông điệp quay lại hàng đợi mãi
    → chiếm chỗ, làm metric co giãn sai
        ↓
    ASG thêm máy để xử lý một thông điệp không xử lý được

Ba metric theo dõi sau khi triển khai: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | thời gian chờ thật của khách | | GroupInServiceInstances | ASG có phản ứng không | | Số thông điệp trong DLQ | |

Ba cách tối ưu chi phí: | Cách | Chi tiết | |---|---| | Spot cho tầng xử lý | công việc idempotent, chịu gián đoạn | | Long polling giảm phí request SQS | WaitTimeSeconds=20 | | Xử lý theo lô | MaxNumberOfMessages=10 |

Và một lời khuyên: hãy đặt alarm trên ApproximateAgeOfOldestMessage chứ không chỉ trên độ dài hàng đợi. Độ dài hàng đợi cho biết có bao nhiêu việc; tuổi của thông điệp cũ nhất cho biết khách hàng đang phải chờ bao lâu — và đó mới là con số mà người dùng thực sự cảm nhận.

Đáp án

A — Tạo bucket S3 mới dùng SSE-KMS với multi-Region key, bật Cross-Region Replication, nạp dữ liệu vào bucket mới, và dùng Amazon Athena để truy vấn.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này thoả từng cái với công ít nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Serverless, ít công vận hành | Athena — không có cụm nào để quản lý | | Truy vấn SQL trên dữ liệu cũ VÀ mới | Athena đọc thẳng từ S3 | | Mã hoá at rest | SSE-KMS | | Nhân bản sang vùng khác | CRR với multi-Region key |

Vì sao phải là multi-Region KMS key:

Object mã hoá bằng khoá KMS ở vùng A
    → sao chép sang vùng B
    → vùng B cần giải mã để đọc
        ↓
    Khoá thường chỉ tồn tại trong MỘT vùng
    → phải mã hoá lại bằng khoá của vùng B khi sao chép (tốn thời gian, phức tạp)
        ↓
    Multi-Region key: cùng một khoá logic tồn tại ở nhiều vùng
    → object sao chép sang là giải mã được ngay

Tạo multi-Region key:

aws kms create-key --multi-region --description "Khoa du lieu khoa hoc"
aws kms replicate-key --key-id mrk-abc123 --replica-region eu-west-1

Bật mã hoá cho bucket:

aws s3api put-bucket-encryption --bucket du-lieu-khoa-hoc   --server-side-encryption-configuration '{
    "Rules":[{"ApplyServerSideEncryptionByDefault":{
      "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"mrk-abc123"},
      "BucketKeyEnabled":true}]}'

Cấu hình CRR:

{"Role": "arn:aws:iam::123456789012:role/vai-tro-crr",
 "Rules": [{"ID":"nhan-ban","Status":"Enabled","Priority":1,"Filter":{},
   "SourceSelectionCriteria":{"SseKmsEncryptedObjects":{"Status":"Enabled"}},
   "Destination":{"Bucket":"arn:aws:s3:::du-lieu-khoa-hoc-eu",
     "EncryptionConfiguration":{"ReplicaKmsKeyID":"arn:aws:kms:eu-west-1:...:key/mrk-abc123"}}}]}

⚠ SseKmsEncryptedObjects là dòng bắt buộc:

Không khai dòng này
    → CRR BỎ QUA mọi object mã hoá bằng SSE-KMS
    → không sao chép gì cả, KHÔNG có lỗi nào
        ↓
    Đây là cấu hình sai im lặng rất hay gặp

Vì sao Athena chứ không phải Redshift: | | Athena | Redshift | |---|---|---| | Hạ tầng | KHÔNG có | cụm phải quản lý | | Trả tiền | theo dữ liệu quét | theo giờ cụm chạy | | Đọc dữ liệu mới | ngay lập tức | cần nạp hoặc Spectrum | | Công vận hành | thấp nhất | cao hơn |

Truy vấn bằng Athena:

CREATE EXTERNAL TABLE du_lieu_khoa_hoc (
  ma_mau string, nhiet_do double, thoi_gian timestamp)
STORED AS PARQUET
LOCATION 's3://du-lieu-khoa-hoc/du-lieu/';

SELECT ma_mau, avg(nhiet_do) FROM du_lieu_khoa_hoc
WHERE thoi_gian > date '2026-01-01' GROUP BY ma_mau;

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

• **D. Bật CRR trên bucket hiện có với SSE-S3, dùng Athena — đây là phương án gần nhất và thực ra đơn giản hơn, nhưng nó yếu hơn về kiểm soát khoá: SSE-S3 do AWS quản lý hoàn toàn, không có key policy, không có audit từng lần dùng khoá trong CloudTrail. Với dữ liệu khoa học có yêu cầu tuân thủ, SSE-KMS là mức phù hợp hơn.
• **B. CRR trên bucket hiện có, SSE-KMS, dùng AWS Glue ETL và Redshift — công vận hành cao hơn hẳn: phải dựng job Glue, phải quản lý cụm Redshift, và dữ liệu phải qua ETL trước khi truy vấn được. Đề đòi "LEAST operational overhead".
• **C. Bucket mới với SSE-S3, CRR, dùng Redshift Spectrum — Spectrum vẫn cần một cụm Redshift để chạy, nên không phải serverless. Và SSE-S3 lại là mức mã hoá yếu hơn về kiểm soát.

Ghi nhớ

Ba dịch vụ truy vấn dữ liệu trong S3 — bảng phải thuộc: | Dịch vụ | Hạ tầng | Trả tiền theo | |---|---|---| | Amazon Athena | KHÔNG có (serverless) | dữ liệu QUÉT | | Redshift Spectrum | cần cụm Redshift | cụm + dữ liệu quét | | EMR / Spark | cụm | giờ cụm |

Từ khoá nhận diện:

"serverless" + "SQL on S3" → Athena "data warehouse", "complex joins, BI" → Redshift "encrypted + replicated cross-Region" → multi-Region KMS key

Bốn lựa chọn mã hoá S3: | Lựa chọn | Khoá do ai giữ | Audit | |---|---|---| | SSE-S3 | AWS hoàn toàn | ❌ | | SSE-KMS | KMS, bạn đặt policy | ✅ CloudTrail | | SSE-C | bạn gửi mỗi request | — | | Client-side | bạn | — |

Ba đặc điểm của multi-Region KMS key: | Đặc điểm | Chi tiết | |---|---| | Cùng key material ở nhiều vùng | | | Cùng key ID (tiền tố mrk-) | | | Mỗi bản sao có key policy RIÊNG | |

Vế thứ ba đáng nhớ:

Nhân bản khoá sang vùng khác
    → nhưng key policy KHÔNG tự sao chép giống hệt
    → phải kiểm tra quyền ở vùng đích
        ↓
    Quên bước này: object sao chép sang nhưng không ai đọc được

Ba yêu cầu bắt buộc của CRR: | Yêu cầu | Chi tiết | |---|---| | Versioning bật ở CẢ HAI bucket | | | IAM role cho S3 sao chép | | | SseKmsEncryptedObjects nếu dùng SSE-KMS | |

Và một điều CRR KHÔNG làm:

CRR chỉ sao chép object GHI SAU KHI bật quy tắc
    → object cũ không tự sang
        ↓
    Dùng S3 Batch Replication cho phần cũ

aws s3control create-job --account-id 123456789012   --operation '{"S3ReplicateObject":{}}' --priority 10   --role-arn <arn-role> --report '{"Enabled":false}'   --manifest-generator '{"S3JobManifestGenerator":{
    "SourceBucket":"arn:aws:s3:::du-lieu-khoa-hoc","EnableManifestOutput":false}}'

Đây chính là lý do phương án A chọn "tạo bucket MỚI rồi nạp dữ liệu vào":

Bucket mới + CRR bật từ đầu
    → mọi object đều được sao chép tự nhiên
        ↓
    Đơn giản hơn là bật CRR trên bucket cũ
    rồi phải chạy thêm Batch Replication

Ba cách giảm chi phí Athena: | Cách | Mức giảm | |---|---| | Dùng định dạng cột (Parquet, ORC) | thường 90%+ | | Phân vùng theo ngày hoặc khu vực | rất lớn | | Nén (Snappy, ZSTD) | |

Athena tính tiền theo dữ liệu QUÉT, nên điều này rất quan trọng:

CSV không nén 1 TB, truy vấn quét hết  → trả tiền 1 TB
Parquet phân vùng, truy vấn một ngày   → quét 2 GB
        ↓
    Cùng một câu hỏi, chênh nhau 500 lần chi phí

Phân vùng:

ALTER TABLE du_lieu_khoa_hoc ADD
  PARTITION (nam='2026', thang='08')
  LOCATION 's3://du-lieu-khoa-hoc/du-lieu/nam=2026/thang=08/';

Ba dịch vụ bổ trợ: | Dịch vụ | Việc | |---|---| | AWS Glue Data Catalog | lưu schema cho Athena | | Glue Crawler | tự phát hiện schema | | Athena workgroup | giới hạn chi phí mỗi truy vấn |

Workgroup đáng bật ngay:

aws athena create-work-group --name nhom-nghien-cuu   --configuration '{"BytesScannedCutoffPerQuery":10737418240,
    "EnforceWorkGroupConfiguration":true}'

Giới hạn 10 GB mỗi truy vấn
    → một câu SELECT * viết nhầm không quét cả kho

Ba lưu ý về S3 Bucket Keys: | Lưu ý | Chi tiết | |---|---| | Giảm số lần gọi KMS tới 99% | | | Giảm chi phí KMS đáng kể | | | Nên bật cho bucket nhiều object | |

Và một lời khuyên: hãy kiểm tra SseKmsEncryptedObjects đã bật chưa ngay sau khi cấu hình CRR với SSE-KMS. Đây là kiểu lỗi tệ nhất trong nhóm này — bảng điều khiển hiển thị quy tắc sao chép ở trạng thái "Enabled", không có lỗi nào, và bucket đích cứ thế trống rỗng cho tới ngày bạn cần tới nó.

Đáp án

A và E.

• A — Amazon S3 cho lưu trữ dữ liệu nguội
• E — Amazon FSx for Lustre cho lưu trữ song song hiệu năng cao

Vì sao đúng

Đề mô tả một mô hình lưu trữ phân tầng, và AWS có đúng một cặp tương ứng: | Tầng tại chỗ | Tương ứng trên AWS | |---|---| | Lưu trữ song song hiệu năng cao (lúc chạy) | FSx for Lustre | | Lưu trữ nguội, rẻ (lúc không chạy) | Amazon S3 |

Và hai dịch vụ này được thiết kế để làm việc cùng nhau:

S3 (kho bền, rẻ)
    │ ▲
    │ │ export tự động
    ▼ │
FSx for Lustre (tốc độ cao, tạm thời)
    │
    └── mount trên các node HPC
        ↓
    Chạy xong → export về S3 → XOÁ file system
    → chỉ còn trả tiền S3

Vì sao đây là mô hình tiết kiệm nhất cho HPC theo đợt:

Tải HPC chạy PERIODIC (theo đợt), không liên tục
    → giữ lưu trữ hiệu năng cao 24/7 là lãng phí lớn
        ↓
    Dựng FSx trước đợt chạy, xoá sau khi xong
    → trả tiền tốc độ cao chỉ trong vài giờ

Quy trình một đợt chạy:

# 1. Tạo file system, liên kết S3
aws fsx create-file-system --file-system-type LUSTRE   --storage-capacity 4800 --storage-type SSD --subnet-ids subnet-hpc   --lustre-configuration 'DeploymentType=SCRATCH_2,
    ImportPath=s3://kho-hpc/dau-vao,ExportPath=s3://kho-hpc/dau-ra'

# 2. Mount trên node tính toán
sudo mount -t lustre -o noatime,flock   fs-abc.fsx.ap-southeast-1.amazonaws.com@tcp:/xyz /fsx

# 3. Chạy tải, kết quả ghi vào /fsx

# 4. Export rồi xoá
aws fsx create-data-repository-task --file-system-id fs-abc   --type EXPORT_TO_REPOSITORY --paths /fsx --report Enabled=false
aws fsx delete-file-system --file-system-id fs-abc

Vì sao Lustre chứ không phải EFS: | | FSx for Lustre | EFS | |---|---|---| | Thông lượng | hàng trăm GB/s | vài GB/s | | Độ trễ | dưới mili giây | mili giây | | Thiết kế cho | HPC, truy cập song song | mục đích chung | | Tích hợp S3 | ✅ import/export | ❌ |

Vì sao S3 cho tầng nguội: | Lý do | Chi tiết | |---|---| | Rẻ nhất trong các kho AWS | | | 11 số 9 độ bền | | | Lifecycle sang Glacier cho dữ liệu rất cũ | | | Tích hợp sẵn với Lustre | |

Lifecycle cho dữ liệu HPC cũ:

{"Rules": [{"ID":"ha-tang-du-lieu-cu","Status":"Enabled","Filter":{},
  "Transitions":[
    {"Days":90,"StorageClass":"GLACIER_IR"},
    {"Days":365,"StorageClass":"DEEP_ARCHIVE"}]}]}

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

• **C. Amazon S3 cho lưu trữ song song hiệu năng cao — đây là phương án gần nhất vì S3 đúng là một phần của lời giải, nhưng nó sai vai trò: S3 là object store qua HTTP API, không mount làm hệ thống tệp POSIX, và độ trễ tính bằng mili giây. Nó là tầng nguội, không phải tầng nóng.
• **D. FSx for Windows cho lưu trữ song song hiệu năng cao — sai hệ điều hành và sai mục đích: FSx for Windows dùng SMB cho môi trường Windows, không phải hệ thống tệp song song cho HPC (vốn gần như luôn chạy Linux).
• **B. Amazon EFS cho lưu trữ nguội — EFS đắt hơn S3 nhiều lần mỗi GB. Dùng nó làm kho nguội là ngược hẳn mục tiêu "more economical cold storage".

Ghi nhớ

Bảng lưu trữ theo tầng cho HPC — phải thuộc: | Tầng | Dịch vụ | Vì sao | |---|---|---| | Nóng (đang tính toán) | FSx for Lustre | thông lượng cực cao, POSIX | | Nguội (lưu trữ) | Amazon S3 | rẻ nhất, bền nhất | | Rất lạnh (nhiều năm) | S3 Glacier Deep Archive | |

Từ khoá nhận diện:

"HPC", "parallel file system", "high-performance" → FSx for Lustre "economical", "cold storage", "long-term" → S3 (+ lifecycle) "tiered storage" trong đề HPC → cặp Lustre + S3

Ba dịch vụ tệp trên AWS — phân biệt nhanh: | Dịch vụ | Giao thức | Điểm mạnh | |---|---|---| | EFS | NFS | đa AZ, mục đích chung, tự co giãn | | FSx for Lustre | Lustre | thông lượng cực cao | | FSx for Windows | SMB | Windows, AD |

Hai kiểu triển khai Lustre: | Kiểu | Đặc điểm | Hợp với | |---|---|---| | Scratch | rẻ, không nhân bản | tải tạm, dữ liệu gốc ở S3 ← bài này | | Persistent | nhân bản, tự sửa lỗi, có sao lưu | tải chạy dài |

Với mô hình "dựng → chạy → export → xoá",
Scratch là lựa chọn đúng và rẻ hơn đáng kể

Ba tính năng liên kết S3: | Tính năng | Việc | |---|---| | Import path | metadata object hiện ra ngay, nội dung lazy load | | Export path | tệp mới chảy về S3 | | AutoImportPolicy | object mới trong S3 tự hiện |

Lazy loading là điều làm mô hình này khả thi:

File system mới tạo với import path
    → thấy ngay toàn bộ cây thư mục của bucket
    → nội dung chỉ tải về khi có ai đọc
        ↓
    Không phải chờ chép trước hàng TB

Ba lưu ý về thông lượng: | Lưu ý | Chi tiết | |---|---| | Thông lượng tỷ lệ với dung lượng cấp phát | | | Persistent chọn 125/250/500/1000 MB/s mỗi TiB | | | Cấp dung lượng lớn hơn nhu cầu để có tốc độ | |

Vế cuối là mẹo thực tế:

Cần 2 GB/s nhưng chỉ có 1 TiB dữ liệu
    → cấp 4,8 TiB với 500 MB/s/TiB
        ↓
    Trả thêm tiền dung lượng để mua thông lượng
    → vẫn rẻ hơn nhiều so với chạy chậm gấp đôi thời gian

Ba lưu ý về mạng cho HPC: | Lưu ý | Chi tiết | |---|---| | Cluster placement group cho node tính toán | | | Elastic Fabric Adapter (EFA) nếu dùng MPI | | | Node và FSx cùng AZ | |

Ba dịch vụ điều phối HPC: | Dịch vụ | Việc | |---|---| | AWS ParallelCluster | dựng cụm HPC với Slurm | | AWS Batch | xếp lịch job container | | AWS Research and Engineering Studio | giao diện cho nhà nghiên cứu |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lustre tính theo dung lượng CẤP PHÁT | không phải dùng thật | | S3 tính theo dùng thật | | | Xoá file system ngay sau khi export xong | |

Ba lưu ý khi export: | Lưu ý | Chi tiết | |---|---| | Export là BẤT ĐỒNG BỘ | phải chờ hoàn tất | | Bật báo cáo để bắt tệp lỗi | | | Kiểm tra báo cáo TRƯỚC khi xoá file system | |

aws fsx describe-data-repository-tasks --task-ids task-abc   --query "DataRepositoryTasks[0].[Lifecycle,Status]"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thông lượng thật khi chạy | metric DataReadBytes | | So thời gian chạy với hệ thống tại chỗ | | | Kiểm tra số tệp và dung lượng sau export | |

Và một lời khuyên: hãy đưa lệnh kiểm tra báo cáo export vào script tự động hoá trước lệnh xoá file system. Việc xoá FSx là thao tác không lùi lại được, và một tác vụ export vẫn đang chạy sẽ không ngăn được lệnh đó — nghĩa là kết quả của cả một đợt tính toán dài có thể biến mất vì script chạy nhanh hơn dữ liệu.