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

Đáp án

D — Dùng AWS Organizations và Service Control Policy (SCP) để kiểm soát dịch vụ trên từng tài khoản.

Vì sao đúng

Đề nêu hai yêu cầu, và SCP là cơ chế duy nhất đáp ứng đủ: | Yêu cầu | Cơ chế | |---|---| | Nhiều tài khoản tách theo phòng ban | AWS Organizations quản lý tập trung | | Kiểm soát truy cập dịch vụ và hành động ở mức TÀI KHOẢN | SCP đặt TRẦN QUYỀN cho cả tài khoản |

Vì sao SCP mạnh hơn mọi cơ chế IAM thông thường:

SCP là TRẦN QUYỀN của cả tài khoản
    → áp cho MỌI principal trong tài khoản đó
    → kể cả TÀI KHOẢN ROOT của tài khoản thành viên
    → quản trị viên phòng ban KHÔNG vượt qua được

Trong khi IAM policy thì không:

IAM policy nằm TRONG tài khoản
    → quản trị viên của tài khoản đó SỬA ĐƯỢC
    → không phải cơ chế thực thi ở cấp tổ chức

Cấu trúc OU điển hình:

Root
├── Security          (log, audit)
├── Infrastructure    (mạng dùng chung)
├── Workloads
│   ├── TaiChinh
│   ├── NhanSu
│   └── KyThuat
└── Sandbox

SCP gắn vào OU và kế thừa xuống mọi tài khoản trong đó:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "GioiHanRegion",
   "Effect": "Deny",
   "NotAction": ["iam:*", "organizations:*", "s3:GetBucket*",
                 "cloudfront:*", "route53:*", "support:*"],
   "Resource": "*",
   "Condition": {"StringNotEquals":
     {"aws:RequestedRegion": ["ap-southeast-1"]}}}]}

Và với dữ liệu nhân sự nhạy cảm, SCP chặn được các thao tác nguy hiểm:

{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
            "config:DeleteConfigRule", "guardduty:DeleteDetector",
            "s3:PutBucketPublicAccessBlock"],
 "Resource": "*"}

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

• **B. Thiết lập cross-account access giữa các tài khoản và gắn IAM policy theo phòng ban — đây là phương án gần nhất vì cũng dùng nhiều tài khoản, nhưng nó thiếu cơ chế thực thi ở cấp tổ chức: IAM policy nằm trong từng tài khoản và quản trị viên tài khoản đó sửa được. Không có "trần quyền" nào ngăn họ tự nâng quyền.
• **A. Thiết lập một IAM policy chung áp cho mọi tài khoản — không có cơ chế như vậy: IAM policy là tài nguyên trong phạm vi một tài khoản. Không có cách nào tạo một policy dùng chung cho nhiều tài khoản mà không qua Organizations.
• **C. Cấp truy cập qua Identity Federation với IAM role cho từng phòng ban — giải quyết vấn đề XÁC THỰC, không phải KIỂM SOÁT: federation lo việc ai đăng nhập được, nhưng không đặt trần quyền cho cả tài khoản.

Ghi nhớ

SCP và IAM policy — bảng phân biệt cốt lõi: | | SCP | IAM policy | |---|---|---| | Vai trò | GIỚI HẠN quyền tối đa | CẤP quyền | | Áp cho | tài khoản hoặc OU | user, group, role | | Ảnh hưởng root của tài khoản thành viên | ✅ CÓ | ❌ KHÔNG | | Tự cấp quyền | ❌ không bao giờ | ✅ | | Quản lý ở | tài khoản quản lý của Organization | trong từng tài khoản |

Quy tắc quan trọng: quyền hiệu lực = GIAO của SCP và IAM policy.

SCP cho phép + IAM cho phép  → ĐƯỢC
SCP cho phép + IAM không     → không được
SCP CHẶN     + IAM cho phép  → KHÔNG ĐƯỢC   ← SCP luôn thắng

Và một lưu ý quan trọng: SCP KHÔNG áp cho tài khoản QUẢN LÝ — kể cả khi gắn vào gốc Organization. Đó là lý do thực hành tốt khuyên không chạy workload nào trong tài khoản quản lý.

Hai chiến lược viết SCP: | Chiến lược | Cách làm | |---|---| | Deny list (phổ biến) | giữ FullAWSAccess, thêm SCP Deny cho việc cấm | | Allow list | gỡ FullAWSAccess, chỉ liệt kê thứ cho phép |

Deny list dễ quản lý hơn nhiều — allow list đòi liệt kê mọi hành động của mọi dịch vụ, và thiếu một cái là ứng dụng hỏng theo cách khó chẩn đoán.

Ba SCP nên có cho mọi tổ chức:

// ① Chặn tắt các dịch vụ giám sát
{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging", "config:DeleteConfigurationRecorder",
            "guardduty:DeleteDetector"],
 "Resource": "*"}

// ② Chặn rời khỏi Organization
{"Effect": "Deny", "Action": "organizations:LeaveOrganization", "Resource": "*"}

// ③ Giới hạn Region được dùng
{"Effect": "Deny", "NotAction": ["iam:*", "organizations:*", "support:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals": {"aws:RequestedRegion": ["ap-southeast-1"]}}}

Ba lợi ích của mô hình đa tài khoản: | Lợi ích | Chi tiết | |---|---| | Cách ly rủi ro | sự cố ở một tài khoản không lan sang tài khoản khác | | Ranh giới hạn mức rõ ràng | phòng ban này dùng hết hạn mức không ảnh hưởng phòng ban khác | | Phân bổ chi phí tự nhiên | mỗi tài khoản một hoá đơn riêng |

Ba tính năng khác của AWS Organizations: | Tính năng | Việc | |---|---| | Consolidated billing | một hoá đơn, và gộp mức dùng để hưởng giá bậc thang tốt hơn | | Tag policy | chuẩn hoá cách viết khoá và giá trị thẻ | | Backup policy | áp chính sách sao lưu cho toàn tổ chức | | AI services opt-out policy | ngăn AWS dùng dữ liệu để cải thiện dịch vụ AI |

Và AWS Control Tower dựng sẵn toàn bộ nền tảng này:

Control Tower tự tạo:
    ✓ cấu trúc OU chuẩn
    ✓ tài khoản Log Archive và Audit
    ✓ CloudTrail toàn tổ chức
    ✓ AWS Config ở mọi tài khoản
    ✓ IAM Identity Center
    ✓ Bộ guardrail (chính là SCP và Config rule) được khuyến nghị
    ✓ Account Factory để cấp tài khoản mới tự động

Với tổ chức đa quốc gia nhiều phòng ban như đề mô tả, Control Tower tiết kiệm hàng tuần công việc.

Ba lưu ý khi triển khai SCP: | Lưu ý | Chi tiết | |---|---| | Thử trên OU nhỏ trước | SCP quá chặt phá vỡ thứ bạn không lường trước | | Lỗi AccessDenied do SCP khó chẩn đoán | thông báo không nói rõ nguồn gốc | | Giới hạn 5 SCP mỗi OU, mỗi SCP 5.120 ký tự | cần gộp khi tổ chức lớn |

Và một lời khuyên: hãy dùng aws:PrincipalOrgID trong bucket policy và resource policy để giới hạn truy cập trong phạm vi tổ chức:

{"Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-abc123xyz"}}}

Nó đơn giản hơn nhiều so với liệt kê từng ID tài khoản, và tự áp cho tài khoản mới thêm vào.

Đáp án

C — Chỉ thị Cache-Control: max-age đang được đặt bằng 0.

Vì sao đúng

Đề mô tả triệu chứng rõ: origin bị gọi cho MỌI request, kể cả object hay được yêu cầu — nghĩa là CloudFront không cache gì cả.

Và nguyên nhân phổ biến nhất là header từ chính origin:

Origin trả về: Cache-Control: max-age=0
    ↓
CloudFront hiểu là "object này hết hạn NGAY LẬP TỨC"
    → không giữ trong cache
    → mọi request đều phải hỏi lại origin

Điểm mấu chốt: header từ ORIGIN được ưu tiên hơn cấu hình TTL của CloudFront.

Origin gửi Cache-Control  → CloudFront TUÂN THEO (trong khoảng Min/Max TTL)
Origin KHÔNG gửi gì       → CloudFront dùng Default TTL

Cách kiểm tra:

curl -sI https://origin.congty.com/anh/logo.png | grep -i cache-control
# Cache-Control: max-age=0, no-cache

Hai cách khắc phục:

① Sửa ở ORIGIN (cách đúng):
     Cache-Control: max-age=86400
     → 24 giờ cho nội dung tĩnh

② Ép ở CloudFront bằng Minimum TTL:
     đặt MinTTL = 3600
     → CloudFront giữ ít nhất 1 giờ dù origin nói gì

Cấu hình cache policy:

aws cloudfront create-cache-policy --cache-policy-config '{
  "Name": "chinh-sach-noi-dung-tinh",
  "MinTTL": 3600, "DefaultTTL": 86400, "MaxTTL": 31536000,
  "ParametersInCacheKeyAndForwardedToOrigin": {
    "EnableAcceptEncodingGzip": true,
    "HeadersConfig": {"HeaderBehavior": "none"},
    "CookiesConfig": {"CookieBehavior": "none"},
    "QueryStringsConfig": {"QueryStringBehavior": "none"}}}'

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

• **A. Object chỉ được cache sau lần request thành công đầu tiên, nên các object chưa từng được yêu cầu vẫn đi tới origin — đây là phương án gần nhất và mô tả đúng cách CloudFront hoạt động, nhưng nó không giải thích được triệu chứng: đề nói rõ vấn đề xảy ra KỂ CẢ với object THƯỜNG XUYÊN được yêu cầu. Nếu chỉ là lần đầu thì các lần sau phải được phục vụ từ cache.
• **B. Kích thước object quá lớn để CloudFront xử lý — sai về giới hạn: CloudFront cache được object tới 30 GB. Và nếu quá lớn thì nó vẫn phục vụ, chỉ không cache — nhưng đó không phải nguyên nhân thường gặp.
• **D. Có hai origin chính trong Origin Group — cấu hình này không tồn tại: origin group có đúng một primary và một secondary cho mục đích chuyển đổi khi origin chính hỏng. Và nó không ảnh hưởng tới việc cache.

Ghi nhớ

Thứ tự ưu tiên quyết định TTL của CloudFront:

① Origin gửi Cache-Control hoặc Expires
       → CloudFront tuân theo, NHƯNG bị kẹp trong khoảng [MinTTL, MaxTTL]
② Origin không gửi gì
       → dùng DefaultTTL

Ba tham số TTL của cache policy: | Tham số | Việc | |---|---| | MinTTL | thời gian TỐI THIỂU CloudFront giữ, dù origin nói gì | | DefaultTTL | dùng khi origin không gửi Cache-Control | | MaxTTL | trần trên, giới hạn giá trị lớn từ origin |

MinTTL là công cụ ép cache khi không sửa được origin.

Các chỉ thị Cache-Control thường gặp: | Chỉ thị | Ý nghĩa | |---|---| | max-age=N | cache N giây | | no-cache | phải kiểm tra lại với origin trước khi dùng | | no-store | KHÔNG được lưu ở đâu cả | | private | chỉ trình duyệt cache, CDN KHÔNG được cache | | public | cả CDN lẫn trình duyệt được cache | | s-maxage=N | TTL riêng cho CDN, ghi đè max-age |

private là nguyên nhân âm thầm hay gặp: framework web thường đặt nó mặc định cho phản hồi có session, và CloudFront tuân theo — không cache gì.

Bốn nguyên nhân khác khiến tỷ lệ cache hit thấp: | Nguyên nhân | Cách kiểm tra | |---|---| | Chuyển tiếp quá nhiều header, cookie, query string | mỗi biến thể là một mục cache riêng | | Cookie luôn thay đổi được chuyển tiếp | tỷ lệ hit sụp về gần 0 | | no-cache hoặc private từ origin | kiểm tra header | | Object quá ít được yêu cầu | bị đẩy khỏi cache tự nhiên |

Dòng đầu là nguyên nhân nghiêm trọng nhất:

Chuyển tiếp cookie session tới origin
    → mỗi người dùng có cookie khác nhau
    → mỗi người tạo một mục cache RIÊNG
    → cache gần như vô dụng

Chỉ chuyển tiếp những gì origin thực sự cần để tạo phản hồi khác nhau.

Ba metric theo dõi hiệu quả cache: | Metric | Ý nghĩa | |---|---| | CacheHitRate | dưới 80% là có chỗ để tối ưu | | OriginLatency | thời gian origin phản hồi | | 4xxErrorRate / 5xxErrorRate | lỗi từ origin |

Và bật CloudFront access log để phân tích chi tiết:

Trường x-edge-result-type cho biết:
    Hit           → phục vụ từ cache
    Miss          → phải gọi origin
    RefreshHit    → kiểm tra lại rồi dùng cache cũ
    Error         → lỗi

Thống kê theo trường này chỉ ra chính xác URL nào không được cache.

Ba cách tăng tỷ lệ cache hit: | Cách | Chi tiết | |---|---| | Đặt TTL dài cho nội dung tĩnh | ảnh, CSS, JS đổi hiếm | | Chỉ chuyển tiếp header và cookie CẦN THIẾT | tác động lớn nhất | | Bật Origin Shield | thêm lớp cache trung tâm — giảm hẳn số lần gọi origin |

Origin Shield đặc biệt hữu ích cho trang tin toàn cầu như đề mô tả:

Không có Origin Shield:
    hơn 600 điểm biên đều gọi origin khi cache miss

Có Origin Shield:
    các điểm biên gọi qua MỘT lớp trung gian
    → origin chỉ nhận một request

Và mẫu quản lý phiên bản cho nội dung tĩnh:

/tinh/app.a1b2c3.js   → TTL 1 năm (tên đổi khi nội dung đổi)
/tinh/app.d4e5f6.js   → phiên bản mới, URL mới
    → không bao giờ cần invalidation

Đây là cách tốt hơn nhiều so với invalidation — invalidation tốn phí và mất vài phút để lan khắp mạng biên.

Và một lưu ý cho trang tin: nội dung động cũng cache được. Trang chủ đổi mỗi vài phút thì đặt TTL 60 giây — 10.000 lượt xem trong phút đó chỉ tạo một request tới origin. Nhiều người chỉ cache tài sản tĩnh và bỏ lỡ phần lợi ích lớn nhất.

Đáp án

A — Dùng AWS Lambda và Amazon API Gateway.

Vì sao đúng

Đề nêu hai yêu cầu, và mô hình serverless đáp ứng cả hai tốt nhất: | Yêu cầu | Cơ chế | |---|---| | TIẾT KIỆM CHI PHÍ NHẤT | không trả tiền khi không có request | | MỞ RỘNG được | tự co giãn từ 0 tới hàng nghìn lời gọi đồng thời |

Vì sao serverless rẻ nhất cho API của game:

Tải game rất biến động:
    → giờ cao điểm: hàng nghìn request/giây
    → 3 giờ sáng: gần như không có ai
        ↓
EC2 hoặc container:
    → phải giữ máy chạy 24/7
    → trả tiền cho cả lúc không ai chơi

Lambda + API Gateway:
    → không có request = KHÔNG TỐN GÌ
    → tự mở rộng khi đông

Và mức miễn phí rất rộng:

Lambda:      1 triệu request + 400.000 GB-giây mỗi tháng — VĨNH VIỄN
API Gateway: 1 triệu lời gọi HTTP API mỗi tháng trong 12 tháng đầu

Và nó đáp ứng đúng "RESTful web APIs" mà đề mô tả:

API Gateway:
    ✓ định nghĩa endpoint REST
    ✓ xác thực (Cognito, IAM, Lambda authorizer)
    ✓ giới hạn tốc độ theo khách hàng
    ✓ caching
    ✓ quản lý phiên bản và stage
        ↓
Lambda:
    ✓ chứa logic nghiệp vụ
    ✓ tự mở rộng

Ba lợi ích vận hành: | Lợi ích | Chi tiết | |---|---| | Không máy chủ để vá lỗi | AWS lo hạ tầng | | Không cấu hình co giãn | tự động hoàn toàn | | Sẵn sàng cao dựng sẵn | trải nhiều AZ mặc định |

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

• **B. Dựng kiến trúc microservice với ECS, ECR và Fargate — đây là phương án gần nhất và cũng serverless ở tầng hạ tầng, nhưng nó đắt hơn cho tải biến động: Fargate tính phí theo thời gian task CHẠY, và task phải chạy liên tục để sẵn sàng nhận request. Lambda chỉ tính phí khi thực sự xử lý.
• **C. Host API trong S3 static website hosting sau CloudFront — sai về mặt kỹ thuật: S3 chỉ phục vụ nội dung TĨNH. API cần chạy mã để xử lý logic — S3 không làm được.
• **D. Dùng Spot Fleet EC2 với Elastic Fabric Adapter (EFA) sau ALB — sai công cụ nghiêm trọng: EFA dành cho HPC (mô phỏng khoa học, huấn luyện phân tán), nó chỉ hỗ trợ Linux và tối ưu giao tiếp giữa các node trong cụm — không liên quan tới API web. Và Spot bị thu hồi bất cứ lúc nào, không phù hợp cho API phục vụ người chơi.

Ghi nhớ

Ba cách dựng API trên AWS — bảng chọn: | Cách | Chi phí khi rảnh | Mở rộng | Công vận hành | |---|---|---|---| | API Gateway + Lambda | 0 đồng | tự động, tức thì | thấp nhất | | ALB + Fargate | trả tiền task đang chạy | tự động, chậm hơn | vừa | | ALB + EC2 | trả tiền instance | Auto Scaling | cao nhất |

Quy tắc chọn:

Tải biến động mạnh, request ngắn → Lambda Tải ổn định, request dài, cần kiểm soát runtime → Fargate hoặc EC2

Hai loại API của API Gateway: | Loại | Đặc điểm | |---|---| | HTTP API | rẻ hơn ~70%, độ trễ thấp hơn, ít tính năng hơn | | REST API | đầy đủ tính năng: caching, usage plan, request validation, WAF |

Với API game đơn giản, HTTP API thường là lựa chọn đúng — rẻ hơn đáng kể ở khối lượng lớn.

Ba giới hạn của Lambda cần cân nhắc: | Giới hạn | Giá trị | |---|---| | Thời gian chạy tối đa | 15 phút | | Payload đồng bộ | 6 MB | | Timeout của API Gateway | 29 giây |

Dòng cuối là giới hạn thực tế cho API: dù Lambda chạy được 15 phút, API Gateway ngắt kết nối sau 29 giây. Với tác vụ dài hơn, dùng mẫu bất đồng bộ (trả về ngay một mã theo dõi, xử lý ở nền).

Ba cách giảm cold start: | Cách | Chi tiết | |---|---| | Provisioned concurrency | giữ sẵn môi trường thực thi — hết cold start, có phí | | Chọn runtime khởi động nhanh | Node.js, Python nhanh hơn Java, .NET | | Giảm kích thước gói | ít thư viện, dùng Lambda layer |

Với game cần độ trễ thấp, provisioned concurrency cho các hàm quan trọng là đáng cân nhắc:

aws lambda put-provisioned-concurrency-config   --function-name api-nguoi-choi --qualifier prod   --provisioned-concurrent-executions 50

Ba tính năng của API Gateway nên dùng cho API game: | Tính năng | Việc | |---|---| | Usage plan và API key | giới hạn tốc độ theo từng khách hàng | | Throttling | bảo vệ backend khỏi tăng tải đột ngột | | Caching | giảm số lời gọi Lambda cho dữ liệu ít đổi | | WAF | chặn tấn công tầng 7 |

Và với dữ liệu người chơi, DynamoDB là cặp đôi tự nhiên của Lambda:

API Gateway → Lambda → DynamoDB
    → cả ba đều serverless
    → cùng mô hình chi phí theo mức dùng
    → độ trễ mili giây

Ba lưu ý khi chuyển API từ tại chỗ sang Lambda: | Lưu ý | Chi tiết | |---|---| | Hàm phải KHÔNG LƯU TRẠNG THÁI | trạng thái ở DynamoDB hoặc ElastiCache | | Kết nối database phải dùng RDS Proxy | Lambda mở rất nhiều kết nối đồng thời | | Đóng gói lại theo mô hình hàm | thay vì một ứng dụng monolith |

Dòng giữa là cạm bẫy quan trọng: 1.000 lời gọi Lambda đồng thời có thể mở 1.000 kết nối tới RDS và làm cạn max_connections. RDS Proxy gộp kết nối và giải quyết triệt để.

Và với game AR/VR có phần thời gian thực, hãy tách hai loại lưu lượng:

API REST (hồ sơ, bảng xếp hạng, mua hàng)
    → API Gateway + Lambda

Kết nối thời gian thực trong game (vị trí, trạng thái)
    → WebSocket API, hoặc NLB + máy chủ game trên EC2/GameLift

Amazon GameLift là dịch vụ chuyên cho máy chủ game — đáng biết nếu phần thời gian thực trở nên quan trọng.

Và một lưu ý về chi phí ở quy mô lớn: Lambda rẻ nhất khi tải biến động; nếu API đạt tới mức chạy liên tục ở mức cao và ổn định, Fargate hoặc EC2 với Savings Plan có thể rẻ hơn. Hãy đo lại khi lưu lượng đã ổn định thay vì giữ nguyên lựa chọn ban đầu mãi.

Đáp án

C — NAT Gateway.

Vì sao đúng

Đề nêu ba yêu cầu, và NAT Gateway đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Instance ở private subnet cần RA Internet để cập nhật phần mềm | NAT cho lưu lượng ĐI RA | | Mạng bên ngoài KHÔNG khởi tạo được kết nối vào | NAT hoạt động MỘT CHIỀU | | Giải pháp SẴN SÀNG CAO | NAT Gateway do AWS quản lý, tự chịu lỗi trong AZ |

NAT hoạt động một chiều theo thiết kế:

Instance gọi ra Internet:
    instance → NAT Gateway → Internet Gateway → máy chủ cập nhật
        → NAT đổi IP nguồn thành IP của chính nó
        → phản hồi quay về đúng instance
    ✅ ĐI RA ĐƯỢC

Ai đó từ Internet gọi vào:
    → không có route nào dẫn vào private subnet
    → NAT KHÔNG chuyển tiếp kết nối khởi tạo từ ngoài
    ❌ KHÔNG VÀO ĐƯỢC

Và vế "highly available" là điểm phân biệt với NAT instance: | | NAT Gateway | NAT instance | |---|---|---| | Quản lý | AWS lo hoàn toàn | bạn tự vá, tự giám sát | | Sẵn sàng cao | tự động trong AZ | phải tự dựng | | Băng thông | tới 100 Gbps, tự mở rộng | theo loại instance | | Chi phí | cao hơn | có thể rẻ hơn với lưu lượng nhỏ |

Và với "IPv4" mà đề nêu, NAT Gateway là lựa chọn đúng:

NAT Gateway  → chỉ hỗ trợ IPv4
Egress-only IGW → chỉ hỗ trợ IPv6

Kiến trúc chuẩn:

Route table PUBLIC subnet:
    0.0.0.0/0 → igw-xxxxx

Route table PRIVATE subnet:
    0.0.0.0/0 → nat-xxxxx

NAT Gateway phải nằm ở PUBLIC subnet — vì chính nó cần đường ra Internet Gateway.

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

• **D. NAT Instance — đây là phương án gần nhất và làm được cùng việc, nhưng nó không sẵn sàng cao: NAT instance là một máy ảo đơn lẻ — máy chết là mất kết nối. Muốn chịu lỗi phải tự dựng cơ chế chuyển đổi. Đề nêu rõ "highly available solution".
• **A. Egress-Only Internet Gateway — sai giao thức: nó chỉ hoạt động với IPv6. Đề nói rõ instance dùng địa chỉ IPv4.
• **B. VPC Endpoint — phạm vi hạn chế: endpoint cho phép truy cập dịch vụ AWS (S3, DynamoDB, và các dịch vụ có interface endpoint). Nó không cho instance tới máy chủ cập nhật phần mềm trên Internet — ví dụ Windows Update.

Ghi nhớ

Bốn cổng ra vào của VPC — bảng cần thuộc: | Cổng | Chiều | Giao thức | Dùng cho | |---|---|---|---| | Internet Gateway | HAI chiều | IPv4, IPv6 | public subnet | | NAT Gateway | CHỈ ĐI RA | IPv4 | private subnet ra Internet ← câu này | | Egress-Only IGW | CHỈ ĐI RA | IPv6 | private subnet IPv6 ra Internet | | VPC Endpoint | tới dịch vụ AWS | — | truy cập riêng tư, không qua Internet |

Quy tắc nhận diện:

"private subnet", "outbound only", "IPv4" → NAT Gateway "private subnet", "outbound only", "IPv6" → Egress-Only Internet Gateway "access S3/DynamoDB privately" → VPC Gateway Endpoint

Ba đặc điểm về sẵn sàng cao của NAT Gateway: | Đặc điểm | Chi tiết | |---|---| | Dự phòng TRONG một AZ | AWS tự xử lý lỗi phần cứng | | KHÔNG tự động đa AZ | AZ chứa nó sập là mọi subnet trỏ tới nó mất mạng | | Nên đặt MỘT NAT Gateway MỖI AZ | và mỗi private subnet trỏ tới NAT trong AZ của mình |

Dòng giữa là điểm thiết kế quan trọng:

Một NAT Gateway dùng chung cho mọi AZ:
    ✗ AZ đó sập → toàn bộ private subnet mất đường ra
    ✗ và lưu lượng chéo AZ còn TÍNH PHÍ THÊM

Một NAT Gateway mỗi AZ:
    ✓ chịu lỗi thật sự
    ✓ không có phí truyền dữ liệu chéo AZ

Ba đặc điểm khác của NAT Gateway: | Đặc điểm | Chi tiết | |---|---| | Cần Elastic IP | gắn khi tạo | | KHÔNG gắn security group được | kiểm soát bằng SG của instance và NACL | | Hỗ trợ tới 55.000 kết nối đồng thời mỗi đích | vượt thì thêm NAT Gateway |

Và NAT Gateway là khoản chi phí âm thầm phổ biến nhất trên AWS:

~0,045 USD/giờ         → ~32 USD/tháng mỗi cái
+ ~0,045 USD mỗi GB    → 10 TB/tháng = ~450 USD

Ba cách giảm chi phí NAT: | Cách | Chi tiết | |---|---| | VPC gateway endpoint cho S3 và DynamoDB | HOÀN TOÀN MIỄN PHÍ | | Interface endpoint cho ECR, CloudWatch Logs, SSM | rẻ hơn NAT ở khối lượng lớn | | Kiểm tra lưu lượng bất thường | tiến trình tải lặp lại có thể tốn rất nhiều |

Sau khi đặt endpoint, hãy xem VPC Flow Logs để biết còn gì đi qua NAT:

fields @timestamp, srcAddr, dstAddr, bytes
| filter dstAddr not like /^10\./
| stats sum(bytes) by dstAddr
| sort by sum desc

Và với "cập nhật phần mềm" cụ thể, có hai lựa chọn tránh NAT: | Lựa chọn | Chi tiết | |---|---| | AWS Systems Manager Patch Manager | vá lỗi qua SSM, dùng VPC endpoint — không cần NAT | | Máy chủ repository nội bộ | mirror các gói cần thiết trong VPC |

Systems Manager Patch Manager đáng cân nhắc cho đội máy Windows:

Cần ba VPC endpoint: ssm, ssmmessages, ec2messages
    → instance không cần đường ra Internet
    → vá lỗi vẫn hoạt động
    → và có báo cáo tuân thủ dựng sẵn

Ba metric cần theo dõi cho NAT Gateway: | Metric | Ý nghĩa | |---|---| | BytesOutToDestination | lưu lượng ra Internet — tăng đột biến là dấu hiệu bất thường | | ErrorPortAllocation | cạn cổng, cần thêm NAT Gateway | | IdleTimeoutCount | kết nối bị đóng do nhàn rỗi |

Và một lưu ý về timeout: NAT Gateway đóng kết nối nhàn rỗi sau 350 giây. Với ứng dụng giữ kết nối lâu (ví dụ tới database bên ngoài), hãy bật TCP keepalive ở phía client với chu kỳ dưới ngưỡng đó — nếu không kết nối sẽ bị ngắt âm thầm.

Đáp án

D — AWS Elastic Beanstalk.

Vì sao đúng

Đề nêu yêu cầu rõ: dễ dàng đưa ứng dụng lên AWS, và nền tảng TỰ ĐỘNG lo mọi việc — cân bằng tải, tự co giãn, giám sát, và đặt container lên cụm.

Elastic Beanstalk làm đúng danh sách đó:

Bạn tải lên: Dockerfile hoặc Dockerrun.aws.json
    ↓
Elastic Beanstalk tự dựng:
    ✓ Elastic Load Balancer
    ✓ Auto Scaling group
    ✓ EC2 instance (hoặc cụm ECS cho multi-container)
    ✓ CloudWatch alarm và dashboard sức khoẻ
    ✓ Security group, cấu hình mạng

Và điểm mấu chốt: bạn không phải cấu hình từng thành phần.

ECS:
    → bạn phải tự tạo cluster, task definition, service
    → tự cấu hình ALB và target group
    → tự viết auto scaling policy

Elastic Beanstalk:
    → một lệnh eb deploy
    → mọi thứ được dựng theo mẫu có sẵn

eb init -p docker ung-dung-tai-chinh
eb create moi-truong-san-xuat --elb-type application
eb deploy

Và Elastic Beanstalk vẫn cho bạn toàn quyền can thiệp:

Mọi tài nguyên nó tạo ra đều là tài nguyên AWS bình thường
    → sửa được trực tiếp
    → hoặc tuỳ chỉnh qua tệp .ebextensions
    → không bị khoá vào một mô hình đóng

Và bản thân Elastic Beanstalk MIỄN PHÍ — chỉ trả tiền cho tài nguyên bên dưới.

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

• **C. Amazon Elastic Container Service (ECS) — đây là phương án gần nhất và thực sự làm được mọi việc đề liệt kê, nhưng nó đòi cấu hình nhiều hơn hẳn: bạn phải tự định nghĩa cluster, task definition, service, target group, và scaling policy. Đề nhấn mạnh "easily port that web application" và "automatically handle ALL the tasks" — Beanstalk đóng gói sẵn toàn bộ. (Lưu ý: Elastic Beanstalk ở chế độ multi-container dùng chính ECS bên dưới.)
• **A. AWS CloudFormation — là công cụ HẠ TẦNG DƯỚI DẠNG MÃ: nó dựng tài nguyên theo template bạn viết. Nhưng bạn phải tự viết template đó — bao gồm ALB, ASG, cụm container, alarm. Nó không "tự động lo" gì cả.
• **B. AWS Compute Optimizer — là công cụ KHUYẾN NGHỊ: nó phân tích mức dùng và gợi ý loại instance phù hợp hơn. Nó không triển khai hay chạy ứng dụng nào.

Ghi nhớ

Các cách triển khai ứng dụng container trên AWS — theo mức trừu tượng: | Cách | Bạn quản lý | Mức trừu tượng | |---|---|---| | Elastic Beanstalk | chỉ mã ứng dụng | cao nhất | | App Runner | chỉ mã hoặc image | rất cao | | ECS trên Fargate | task definition, service | vừa | | ECS trên EC2 | thêm cả cụm EC2 | thấp hơn | | EKS | Kubernetes | thấp nhất, linh hoạt nhất |

Quy tắc nhận diện trong đề thi:

"easily deploy", "automatically handles capacity/scaling/monitoring", "just upload code" → Elastic Beanstalk "container orchestration", "task definition", "fine-grained control" → ECS "Kubernetes", "kubectl", "pod" → EKS "infrastructure as code", "template" → CloudFormation

Và AWS App Runner là lựa chọn hiện đại hơn cho ứng dụng web container:

App Runner:
    ✓ chỉ trỏ vào ECR image hoặc repo mã nguồn
    ✓ tự dựng HTTPS endpoint, tự co giãn về 0
    ✓ không thấy VPC, ALB hay instance nào
    ✓ đơn giản hơn cả Beanstalk cho ứng dụng web thuần

(App Runner ra mắt sau khi câu hỏi được soạn; với ứng dụng MEAN đơn giản, nó đáng cân nhắc.)

Các nền tảng Elastic Beanstalk hỗ trợ:

Node.js, Python, Ruby, PHP, Java, .NET, Go
Docker (single container và multi-container)
Tomcat, Passenger, Puma

Ứng dụng MEAN chạy Node.js trong Docker — Beanstalk hỗ trợ cả hai cách.

Hai loại môi trường: | Loại | Đặc điểm | |---|---| | Web server environment | ALB + ASG, phục vụ HTTP ← đề này | | Worker environment | đọc từ SQS, xử lý bất đồng bộ |

Ba chính sách triển khai của Beanstalk: | Chính sách | Đặc điểm | |---|---| | All at once | nhanh nhất, có gián đoạn | | Rolling | thay từng nhóm, giảm dung lượng tạm thời | | Rolling with additional batch | giữ đủ dung lượng, chậm hơn | | Immutable | dựng đội máy MỚI hoàn toàn — an toàn nhất, quay lui nhanh | | Blue/Green | hai môi trường, đổi URL |

Với ứng dụng tài chính, Immutable hoặc Blue/Green là lựa chọn đúng — chúng cho phép quay lui gần như tức thì nếu phiên bản mới có vấn đề.

Ba cách tuỳ chỉnh Beanstalk: | Cách | Chi tiết | |---|---| | .ebextensions | tệp cấu hình YAML trong mã nguồn — cài gói, đặt biến, chạy lệnh | | Saved configuration | lưu cấu hình môi trường để tái dùng | | Custom AMI | rút ngắn thời gian khởi động |

Ba lưu ý khi dùng Elastic Beanstalk: | Lưu ý | Chi tiết | |---|---| | Không lưu trạng thái trên instance | dữ liệu ở RDS, S3, ElastiCache | | RDS tạo TRONG môi trường sẽ bị XOÁ theo môi trường | tạo RDS RIÊNG bên ngoài cho sản xuất | | Log lưu ở S3 hoặc CloudWatch Logs | bật tường minh |

Dòng giữa là cạm bẫy nghiêm trọng: nếu tạo database bên trong môi trường Beanstalk, xoá môi trường là mất luôn database. Với ứng dụng tài chính, luôn tạo RDS độc lập rồi trỏ tới bằng biến môi trường.

Và MongoDB trong stack MEAN cần được xử lý riêng: | Lựa chọn | Chi tiết | |---|---| | Amazon DocumentDB | tương thích API MongoDB, được quản lý | | MongoDB Atlas | dịch vụ của bên thứ ba trên AWS | | Tự chạy trên EC2 | toàn quyền, nhiều công vận hành |

Và một lời khuyên: hãy dùng cùng một môi trường Beanstalk cho staging và production nhưng khác cấu hình, rồi dùng swap URL để chuyển đổi. Đó là cách triển khai blue/green đơn giản nhất và cho phép quay lui trong vài giây.

Đáp án

B — Dùng Amazon S3 Multipart Upload API.

Vì sao đúng

Đề cho một con số quyết định: video 5 GB — đúng bằng giới hạn của một lần PUT.

Ba giới hạn kích thước của S3: | Giới hạn | Giá trị | |---|---| | Object tối đa | 5 TB | | MỘT lần PUT tối đa | 5 GB | | Khuyến nghị dùng multipart từ | 100 MB |

Với tệp 5 GB, multipart không chỉ nên dùng mà gần như bắt buộc.

Cách multipart upload cải thiện hiệu năng:

Một PUT đơn lẻ:
    → truyền tuần tự một luồng duy nhất
    → không tận dụng hết băng thông
    → lỗi giữa chừng → tải lại TỪ ĐẦU

Multipart upload:
    → chia thành nhiều phần
    → tải SONG SONG nhiều phần cùng lúc
    → tận dụng hết băng thông
    → lỗi ở một phần → chỉ tải lại phần đó

Ba bước của multipart upload:

① InitiateMultipartUpload  → nhận uploadId
② UploadPart × N           → tải song song (5 MB – 5 GB mỗi phần)
③ CompleteMultipartUpload  → S3 ghép các phần

AWS CLI và SDK tự dùng multipart khi vượt ngưỡng:

aws configure set default.s3.multipart_threshold 100MB
aws configure set default.s3.multipart_chunksize 64MB
aws configure set default.s3.max_concurrent_requests 20

max_concurrent_requests là tham số có tác động lớn nhất — mặc định 10 thường chưa dùng hết đường truyền của instance có băng thông cao.

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

• **A. Bật Enhanced Networking với ENA trên EC2 instance — đây là phương án gần nhất vì cũng liên quan tới hiệu năng mạng, nhưng nó không giải quyết vấn đề gốc: ENA tăng băng thông khả dụng, nhưng một luồng PUT đơn lẻ không tận dụng hết băng thông đó. Phải tải song song mới dùng hết được. (Và hầu hết instance thế hệ mới đã bật ENA sẵn.)
• **D. Dùng EBS Provisioned IOPS và instance tối ưu EBS — sai nút thắt: nút thắt nằm ở việc truyền lên S3, không phải đọc từ đĩa cục bộ. Cải thiện IOPS của EBS không tăng tốc quá trình tải lên.
• **C. Dùng CloudFront với phương thức HTTP POST — sai chiều: CloudFront tối ưu việc phân phối nội dung XUỐNG người dùng. Nó không tăng tốc tải lên. (CloudFront có hỗ trợ POST/PUT nhưng đó là chuyển tiếp tới origin, không phải tăng tốc.)

Ghi nhớ

Bốn lợi ích của multipart upload: | Lợi ích | Chi tiết | |---|---| | Vượt giới hạn 5 GB | tới 10.000 phần × 5 GB | | Tải SONG SONG | tận dụng hết băng thông | | Thử lại chỉ phần lỗi | không phải tải lại cả tệp | | Tạm dừng và tiếp tục | hữu ích với kết nối không ổn định |

Giới hạn của multipart: | Giới hạn | Giá trị | |---|---| | Số phần | 1 – 10.000 | | Kích thước mỗi phần | 5 MB – 5 GB (trừ phần cuối) | | Object tối đa | 5 TB |

Và một lifecycle rule BẮT BUỘC cho mọi bucket dùng multipart:

{"Rules": [{"Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Vì sao bắt buộc:

Multipart thất bại giữa chừng để lại các phần đã tải
    → TÍNH PHÍ LƯU TRỮ MÃI MÃI
    → và KHÔNG hiện trong danh sách object
    → nên rất dễ bị bỏ quên và tích tụ

# Kiểm tra có phần dở dang nào không
aws s3api list-multipart-uploads --bucket kho-video

Ba kỹ thuật tăng tốc truyền dữ liệu với S3 — mỗi cái cho một vấn đề: | Kỹ thuật | Giải quyết | |---|---| | Multipart upload | tải LÊN tệp lớn ← câu này | | Byte-range fetch | tải XUỐNG tệp lớn (song song) | | S3 Transfer Acceleration | người dùng ở XA Region của bucket |

S3 Transfer Acceleration đáng cân nhắc bổ sung:

Lưu lượng đi qua điểm biên CloudFront gần nhất
    → rồi đi trên mạng xương sống AWS tới bucket
    → chỉ tính phí khi thực sự nhanh hơn

aws s3api put-bucket-accelerate-configuration --bucket kho-video   --accelerate-configuration Status=Enabled
aws configure set default.s3.use_accelerate_endpoint true

(Với EC2 và S3 trong CÙNG Region như đề mô tả, Transfer Acceleration không giúp gì — đường đi đã tối ưu.)

Và một kiến trúc đáng cân nhắc: cho client tải THẲNG lên S3.

Hiện tại: người dùng → EC2 → S3
    → EC2 phải nhận toàn bộ 5 GB rồi mới đẩy tiếp
    → tốn băng thông, tốn đĩa tạm, và là nút thắt

Tốt hơn: người dùng → S3 (qua pre-signed URL)
    → EC2 chỉ cấp URL, không chạm vào dữ liệu

url = s3.generate_presigned_url('put_object',
    Params={'Bucket': 'kho-video', 'Key': f'{ma_nguoi_dung}/{ten_tep}'},
    ExpiresIn=3600)

Và pre-signed URL hỗ trợ cả multipart — client tải song song từng phần trực tiếp lên S3.

Ba lưu ý về kiểm tra tính toàn vẹn: | Lưu ý | Chi tiết | |---|---| | ETag của object multipart KHÁC MD5 thông thường | nó là hash của các hash phần | | Dùng checksum bổ sung | S3 hỗ trợ CRC32, CRC32C, SHA-1, SHA-256 | | Xác minh sau khi tải | so checksum để chắc chắn |

aws s3api put-object --bucket kho-video --key phim.mp4   --body phim.mp4 --checksum-algorithm SHA256

Và với video, hãy nghĩ tới bước tiếp theo sau khi tải lên: | Bước | Dịch vụ | |---|---| | Chuyển mã sang nhiều độ phân giải | AWS Elemental MediaConvert | | Phân phối tới người xem | CloudFront | | Lưu trữ bản gốc dài hạn | lifecycle chuyển sang Glacier |

Và một lời khuyên về giám sát: theo dõi metric 4xxErrors của S3 và log của ứng dụng để phát hiện multipart upload thất bại. Chúng thường thất bại âm thầm — người dùng thấy tải lên "xong" trong khi CompleteMultipartUpload chưa từng được gọi.

Đáp án

A — Tạo S3 bucket policy cấp quyền cho các tài khoản sandbox; dùng Amazon Macie để phát hiện thông tin cá nhân (PII) hoặc dữ liệu tài chính.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi phần của đáp án giải một yêu cầu: | Yêu cầu | Giải pháp | |---|---| | Lập trình viên ở nhiều tài khoản truy cập bucket chính | bucket policy — cấp một lần cho cả tài khoản | | Liên tục phát hiện PII và dữ liệu tài chính | Macie — dịch vụ chuyên cho việc này |

Vì sao bucket policy là cách ít công nhất:

Bucket policy nằm ở bucket (nơi BẠN kiểm soát)
    → cấp quyền cho CẢ TÀI KHOẢN sandbox
    → lập trình viên mới trong tài khoản đó tự động có quyền
    → KHÔNG phải sửa gì khi nhân sự thay đổi

{"Effect": "Allow",
 "Principal": {"AWS": ["arn:aws:iam::111122223333:root",
                       "arn:aws:iam::444455556666:root"]},
 "Action": ["s3:GetObject", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::kho-chung",
              "arn:aws:s3:::kho-chung/*"]}

Và Amazon Macie là dịch vụ được thiết kế đúng cho việc phát hiện PII:

Macie dùng học máy và khớp mẫu để quét S3
    → phát hiện: số thẻ tín dụng, số bảo hiểm xã hội,
      hộ chiếu, khoá API, thông tin y tế, tên và địa chỉ
    → phân loại theo mức nghiêm trọng
    → phát finding vào EventBridge và Security Hub

Và tự động hoá việc gỡ bỏ:

{"source": ["aws.macie"],
 "detail-type": ["Macie Finding"],
 "detail": {"type": [{"prefix": "SensitiveData:"}]}}

def lambda_handler(event, context):
    d = event['detail']
    bucket = d['resourcesAffected']['s3Bucket']['name']
    key = d['resourcesAffected']['s3Object']['key']
    s3.copy_object(Bucket='kho-cach-ly', Key=key,
                   CopySource={'Bucket': bucket, 'Key': key})
    s3.delete_object(Bucket=bucket, Key=key)

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

• **D. Thêm quyền đọc S3 vào IAM policy của TỪNG IAM user ở các tài khoản sandbox; dùng Amazon Detective — đây là phương án gần nhất vì cũng cấp được quyền, nhưng nó sai ở hai chỗ: sửa IAM policy của từng người dùng là công việc lặp lại vô tận khi nhân sự thay đổi. Và Detective là công cụ ĐIỀU TRA sự cố bảo mật, nó không quét nội dung dữ liệu để tìm PII.
• **B. Cấu hình cross-account replication và dùng AWS Audit Manager — sai cả hai: replication sao chép dữ liệu sang bucket khác, nó không cấp quyền truy cập. Và Audit Manager thu thập bằng chứng cho báo cáo tuân thủ, nó không phát hiện dữ liệu nhạy cảm.
• **C. Sinh pre-signed URL cho từng object và dùng S3 Storage Lens — không mở rộng được: pre-signed URL phải sinh cho từng object và có thời hạn — không thực tế cho việc chia sẻ cả bucket. Và Storage Lens phân tích DUNG LƯỢNG và mẫu sử dụng, không xem nội dung.

Ghi nhớ

Các dịch vụ bảo mật của AWS — mỗi cái một vai: | Dịch vụ | Phát hiện | |---|---| | Amazon Macie | DỮ LIỆU NHẠY CẢM trong S3 (PII, tài chính, thông tin đăng nhập) | | Amazon GuardDuty | HÀNH VI ĐE DOẠ (truy cập bất thường, mã độc) | | Amazon Inspector | LỖ HỔNG phần mềm (CVE) | | Amazon Detective | ĐIỀU TRA SÂU một sự cố đã phát hiện | | Security Hub | tổng hợp finding từ mọi dịch vụ | | AWS Config | cấu hình sai so với quy tắc |

Bốn dịch vụ đầu là bộ hay bị nhầm lẫn nhất:

Macie      → "có dữ liệu nhạy cảm nào để nhầm chỗ không?"
GuardDuty  → "có ai đang hành xử đáng ngờ không?"
Inspector  → "phần mềm có lỗ hổng nào không?"
Detective  → "chuyện gì đã xảy ra trong sự cố này?"

Ba cách chia sẻ bucket S3 với tài khoản khác: | Cách | Đặc điểm | |---|---| | Bucket policy | đơn giản nhất, cấp cho cả tài khoản ← câu này | | IAM role cho tài khoản kia đảm nhận | kiểm soát chi tiết hơn, có audit | | S3 Access Point | chính sách riêng cho từng nhóm — tốt khi có nhiều bên |

Và với AWS Organizations, có cách gọn hơn nữa:

{"Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-abc123xyz"}}}

Cấp cho MỌI tài khoản trong tổ chức — không phải liệt kê từng ID, và tài khoản mới tự có quyền.

Ba khả năng của Amazon Macie: | Khả năng | Chi tiết | |---|---| | Khám phá dữ liệu nhạy cảm tự động | quét liên tục, lấy mẫu thông minh để tiết kiệm | | Job phân loại theo lịch | quét sâu toàn bộ bucket | | Đánh giá tình trạng bảo mật bucket | phát hiện bucket công khai, chưa mã hoá |

Và Macie hỗ trợ mẫu tuỳ chỉnh cho định danh riêng của tổ chức:

{"regex": "TK-[0-9]{4}-[0-9]{8}",
 "name": "ma-tai-khoan-noi-bo",
 "keywords": ["ma tai khoan", "account number"]}

Các loại finding của Macie: | Loại | Nghĩa | |---|---| | SensitiveData:S3Object/Personal | thông tin cá nhân | | SensitiveData:S3Object/Financial | dữ liệu tài chính | | SensitiveData:S3Object/Credentials | khoá và mật khẩu | | Policy:IAMUser/S3BucketPublic | bucket bị mở công khai |

Ba lưu ý về chi phí Macie: | Khoản | Chi tiết | |---|---| | Đánh giá bucket | theo số bucket được giám sát | | Quét nội dung | theo GB được quét — khoản lớn nhất | | Mức miễn phí | 30 ngày dùng thử |

Với "lowest possible cost" như đề yêu cầu, hãy:

✓ Giới hạn phạm vi quét theo prefix
✓ Dùng lấy mẫu thay vì quét 100%
✓ Đặt lịch quét định kỳ thay vì liên tục cho bucket ít thay đổi

Ba biện pháp PHÒNG NGỪA — hiệu quả hơn phát hiện: | Biện pháp | Chi tiết | |---|---| | Block Public Access ở mức TÀI KHOẢN | ngăn bucket bị mở công khai | | Bắt buộc mã hoá khi ghi | bucket policy với điều kiện | | Đào tạo lập trình viên | hầu hết vụ để nhầm PII là do vô ý |

Và với môi trường sandbox nhiều tài khoản, SCP là công cụ mạnh:

{"Effect": "Deny",
 "Action": "s3:PutBucketPublicAccessBlock",
 "Resource": "*"}

Không ai tắt được Block Public Access — kể cả quản trị viên của tài khoản sandbox.

Và một lời khuyên về quy trình: khi Macie phát hiện PII, đừng chỉ xoá tệp. Hãy điều tra dữ liệu đã ở đó bao lâu và ai đã truy cập bằng CloudTrail data event. Với nhiều quy định về quyền riêng tư, việc dữ liệu bị phơi ra có thể kích hoạt nghĩa vụ thông báo cho người bị ảnh hưởng — và mốc thời gian là thông tin bắt buộc phải có.

Đáp án

B — Amazon Elastic File System (EFS).

Vì sao đúng

Đề nêu bốn yêu cầu, và EFS đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Tuân thủ POSIX | EFS là hệ thống tệp NFS đầy đủ POSIX | | Dữ liệu dự phòng qua NHIỀU AZ | EFS tự sao chép qua nhiều AZ | | Hàng NGHÌN EC2 instance kết nối đồng thời | EFS hỗ trợ hàng nghìn kết nối | | Mở rộng được | tự lớn lên tới petabyte, không cần cấp phát |

Ba từ khoá trong đề chỉ thẳng tới EFS:

"POSIX-compliant"           → hệ thống TỆP, không phải kho object
"redundantly across AZs"    → EFS trải nhiều AZ mặc định
"thousands of EC2 instances
 on multiple AZs"           → cần lưu trữ CHIA SẺ, không phải gắn riêng

Và EFS tự mở rộng hoàn toàn:

Không cấp phát dung lượng trước
    → tự lớn khi ghi thêm, tự nhỏ khi xoá
    → trả tiền theo dung lượng THỰC DÙNG

sudo mount -t efs -o tls fs-0abc123:/ /du-lieu-chung

Và với HPC, hãy dùng Elastic throughput:

Chế độ Bursting tích luỹ tín dụng theo DUNG LƯỢNG lưu trữ
    → file system nhỏ + hàng nghìn máy đọc → CẠN tín dụng → sụp hiệu năng
        ↓
Elastic throughput: không có khái niệm tín dụng, tự điều chỉnh

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

• **A. Amazon EBS Volumes — đây là phương án gần nhất vì cũng là lưu trữ khối POSIX, nhưng nó không chia sẻ được ở quy mô này: EBS volume gắn với MỘT AZ, và dù có multi-attach thì cũng tối đa 16 instance TRONG CÙNG AZ (chỉ io1/io2). Không thể phục vụ hàng nghìn máy trải nhiều AZ.
• **C. Amazon S3 — không tuân thủ POSIX: S3 là kho object, truy cập qua API HTTP. Nó không có ngữ nghĩa hệ thống tệp (khoá tệp, ghi từng phần, quyền POSIX). Ứng dụng HPC dùng đường dẫn tệp sẽ phải viết lại.
• **D. Amazon ElastiCache — là bộ nhớ đệm, không phải lưu trữ: nó lưu dữ liệu trong RAM để tăng tốc truy cập, không phải hệ thống tệp bền vững.

Ghi nhớ

Ba loại lưu trữ trên AWS — bảng cần thuộc: | Loại | Dịch vụ | POSIX | Chia sẻ nhiều máy | |---|---|---|---| | Khối (block) | EBS, instance store | ✅ | rất hạn chế | | Tệp (file) | EFS, FSx | ✅ | ✅ hàng nghìn máy | | Object | S3 | ❌ | ✅ nhưng qua API |

Quy tắc nhận diện:

"POSIX", "NFS", "shared file system", "thousands of instances", "Linux" → EFS "SMB", "Windows", "Active Directory" → FSx for Windows "HPC", "hundreds of GB/s", "Lustre" → FSx for Lustre "object", "REST API", "unlimited" → S3

Và với HPC, FSx for Lustre là lựa chọn đáng cân nhắc hơn EFS: | | EFS | FSx for Lustre | |---|---|---| | Thông lượng tối đa | hàng GB/giây | hàng TRĂM GB/giây | | Độ trễ | mili giây thấp | dưới mili giây | | Đa AZ | ✅ mặc định | Single-AZ (có tuỳ chọn persistent) | | Liên kết với S3 | ❌ | ✅ tự nạp và ghi ngược | | Chi phí | vừa | cao hơn |

Đề yêu cầu "redundantly across multiple AZs" — đó là điểm khiến EFS thắng. FSx for Lustre nhanh hơn nhiều nhưng chủ yếu chạy trong một AZ.

Hai chế độ hiệu năng của EFS: | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | độ trễ THẤP NHẤT — phù hợp hầu hết | | Max I/O | thông lượng cao hơn, độ trễ cao hơn một chút |

Ba chế độ throughput: | Chế độ | Đặc điểm | |---|---| | Elastic (khuyến nghị) | tự điều chỉnh, trả theo lượng dùng thật | | Bursting | tích luỹ tín dụng theo DUNG LƯỢNG lưu trữ | | Provisioned | khai trước mức cố định |

Cạm bẫy của Bursting với HPC:

Mức cơ sở: 50 KB/giây cho mỗi GB lưu trữ
    → file system 100 GB → chỉ 5 MB/giây khi cạn tín dụng
    → hàng nghìn máy đọc song song → cạn rất nhanh

Với HPC, luôn dùng Elastic hoặc Provisioned.

Hai lớp lưu trữ của EFS: | Lớp | Chi phí | |---|---| | Standard | cao hơn | | Infrequent Access (IA) | rẻ hơn ~92%, có phí truy xuất |

Lifecycle policy tự chuyển tệp ít dùng:

aws efs put-lifecycle-configuration --file-system-id fs-0abc123   --lifecycle-policies TransitionToIA=AFTER_30_DAYS                        TransitionToPrimaryStorageClass=AFTER_1_ACCESS

Đây là tối ưu chi phí quan trọng nhất với EFS.

Ba lưu ý khi triển khai EFS cho hàng nghìn instance: | Lưu ý | Chi tiết | |---|---| | Tạo mount target ở MỖI AZ | thiếu thì máy ở AZ đó trả phí truyền chéo AZ | | Security group của mount target mở cổng 2049 | NFS | | Dùng EFS Access Point | ép POSIX user và thư mục gốc cho từng nhóm |

Và bật mã hoá cả hai chiều:

At rest:    bật lúc tạo file system (KMS)
In transit: tuỳ chọn -o tls khi mount

Ba dịch vụ lưu trữ tệp — chọn theo yêu cầu: | Dịch vụ | Đa AZ | Thông lượng | Giao thức | |---|---|---|---| | EFS | ✅ | GB/giây | NFS | | FSx for Lustre | hạn chế | hàng trăm GB/giây | Lustre | | FSx for Windows | ✅ (Multi-AZ) | tới 2 GB/giây | SMB | | FSx for NetApp ONTAP | ✅ | cao | NFS, SMB, iSCSI |

Và một kiến trúc lai đáng cân nhắc cho nền tảng phân tích dữ liệu:

S3        → kho dữ liệu chính, rẻ, bền vững
FSx for Lustre → nạp từ S3 khi cần tính toán, thông lượng cực cao
EFS       → dữ liệu dùng chung cần đa AZ và POSIX

Ba tầng cho ba mục đích khác nhau — không phải chọn một.

Và một lưu ý về chi phí ở quy mô lớn: EFS đắt hơn S3 khoảng 10 lần tính theo GB. Nếu phần lớn dữ liệu chỉ được đọc tuần tự và không cần ngữ nghĩa hệ thống tệp, hãy để nó ở S3 và chỉ đưa vào EFS phần thực sự cần — kiến trúc lai như vậy thường giảm hoá đơn rất đáng kể.

Đáp án

B — Sửa security group để cho phép lưu lượng vào cổng 3389 từ địa chỉ IP của công ty.

Vì sao đúng

Đề cho một manh mối quyết định: kết nối bằng Remote Desktop — nghĩa là instance chạy Windows và dùng giao thức RDP.

Và RDP dùng cổng 3389 trên TCP:

RDP  → cổng 3389   (Windows)
SSH  → cổng 22     (Linux)

Suy luận từ các dữ kiện đã kiểm tra:

✅ Instance có IP công khai
✅ Internet Gateway đã có
✅ Route table đã đúng
    ↓
Còn lại: security group chưa mở cổng 3389

Và security group mặc định khi tạo mới CHẶN mọi lưu lượng vào — nên instance vừa dựng với security group mới sẽ không kết nối được, đúng như triệu chứng.

aws ec2 authorize-security-group-ingress --group-id sg-0abc123   --protocol tcp --port 3389 --cidr 203.0.113.25/32

Chú ý /32 — chỉ đúng một địa chỉ. Mở 0.0.0.0/0 cho cổng 3389 là phơi RDP ra cả Internet, và đó là một trong những bề mặt tấn công bị dò quét nhiều nhất.

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

• **A. Sửa security group cho phép cổng 22 — đây là phương án gần nhất vì cùng cấu trúc giải pháp, nhưng nó sai cổng: 22 là SSH cho Linux. Remote Desktop cần cổng 3389.
• **C. Khởi động lại instance vì có thể máy có vấn đề — đoán mò: không có dữ kiện nào cho thấy instance hỏng. Và khởi động lại không mở cổng nào.
• **D. Tạo instance mới vì có thể máy có vấn đề — cùng lý do, và còn tốn công hơn. Vấn đề nằm ở cấu hình mạng, không phải ở máy.

Ghi nhớ

Các cổng thường gặp trong đề thi — bảng cần thuộc: | Cổng | Dịch vụ | |---|---| | 22 | SSH, SFTP (Linux) | | 3389 | RDP (Windows) | | 80 / 443 | HTTP / HTTPS | | 3306 | MySQL, Aurora MySQL, MariaDB | | 5432 | PostgreSQL | | 1433 | Microsoft SQL Server | | 1521 | Oracle | | 6379 | Redis | | 11211 | Memcached | | 27017 | MongoDB, DocumentDB | | 2049 | NFS (EFS) | | 445 | SMB (FSx for Windows) | | 20–21 | FTP | | 25 / 587 | SMTP | | 53 | DNS |

Danh sách kiểm tra khi không kết nối được vào EC2 — theo thứ tự: | Bước | Kiểm tra | |---|---| | ① Security group | có rule inbound đúng CỔNG từ IP của bạn không | | ② Instance ở public subnet | route table có đường ra Internet Gateway | | ③ Có IP công khai | được cấp public IP hoặc Elastic IP | | ④ NACL | inbound đúng cổng VÀ outbound cổng tạm (stateless) | | ⑤ Tường lửa trong hệ điều hành | Windows Firewall, iptables | | ⑥ Instance đã boot xong | status check 2/2 | | ⑦ Thông tin đăng nhập | mật khẩu Administrator giải mã từ key pair |

Bước ④ có chi tiết dễ quên: NACL không có trạng thái, nên phải mở cổng tạm ở chiều RA để phản hồi đi được về máy bạn. Security group thì không cần vì nó stateful.

Kỹ thuật chẩn đoán quan trọng:

Chỉ MỘT instance hỏng → nghi security group hoặc cấu hình của chính instance CẢ SUBNET hỏng → nghi NACL, route table, hoặc Internet Gateway

Lấy mật khẩu Administrator của instance Windows:

aws ec2 get-password-data --instance-id i-0abc123   --priv-launch-key khoa-cua-toi.pem

Mật khẩu được mã hoá bằng public key của key pair — cần tệp .pem để giải mã.

Và một lựa chọn tốt hơn hẳn việc mở cổng 3389: AWS Systems Manager Fleet Manager.

Fleet Manager cho Remote Desktop qua trình duyệt:
    ✓ KHÔNG cần mở cổng 3389
    ✓ KHÔNG cần IP công khai
    ✓ phân quyền bằng IAM
    ✓ ghi log toàn bộ phiên

Yêu cầu: SSM Agent (đã cài sẵn trong AMI Windows gần đây), IAM role AmazonSSMManagedInstanceCore, và VPC endpoint nếu ở private subnet.

Và Session Manager cũng hỗ trợ port forwarding cho RDP:

aws ssm start-session --target i-0abc123   --document-name AWS-StartPortForwardingSession   --parameters '{"portNumber":["3389"],"localPortNumber":["13389"]}'

Sau đó kết nối RDP tới localhost:13389 — không có cổng nào mở ra Internet.

Ba lý do nên tránh mở RDP ra Internet: | Lý do | Chi tiết | |---|---| | Bot quét cổng 3389 liên tục | dò mật khẩu tự động 24/7 | | Nhiều lỗ hổng RDP nghiêm trọng đã biết | BlueKeep và các CVE khác | | Không có audit log chi tiết | khác với Session Manager |

Ba biện pháp nếu vẫn phải dùng RDP trực tiếp: | Biện pháp | Chi tiết | |---|---| | Chỉ mở cho IP công ty (/32) | ← đáp án của đề | | Bật Network Level Authentication | xác thực trước khi lập phiên | | Vá lỗi Windows thường xuyên | qua SSM Patch Manager |

Và bastion host là mô hình trung gian:

Internet → bastion (public subnet, chỉ mở 3389 cho IP công ty)
              ↓ RDP nội bộ
         instance ứng dụng (private subnet)

Security group của instance private nên nhận nguồn là SECURITY GROUP của bastion, không phải IP — như vậy bastion đổi IP thì rule vẫn đúng.

Và một lưu ý về chẩn đoán: VPC Reachability Analyzer kiểm tra được đường mạng giữa máy bạn và instance mà không cần gửi lưu lượng thật — nó chỉ ra chính xác security group hay NACL nào đang chặn, nhanh hơn nhiều so với thử từng cấu hình.

Đáp án

A và D.

• A — Tăng độ bền của database khi một thành phần của DB instance hỏng hoặc một Availability Zone gặp sự cố
• D — Tăng tính sẵn sàng trong các trường hợp bảo trì hệ thống như vá lỗi hệ điều hành hoặc thay đổi kích thước instance

Vì sao đúng

Multi-AZ là cơ chế SẴN SÀNG CAO, và hai đáp án nêu đúng hai lợi ích của nó.

A — chịu được sự cố ở mức thành phần và mức AZ:

Primary (AZ-a)  ──sao chép ĐỒNG BỘ──▶  Standby (AZ-b)
    → mọi giao dịch ghi vào CẢ HAI trước khi xác nhận
    → dữ liệu ở standby LUÔN GIỐNG HỆT primary
        ↓
Primary hỏng, hoặc AZ-a mất kết nối:
    → RDS TỰ ĐỘNG chuyển endpoint DNS sang standby
    → hoàn tất trong 60–120 giây
    → KHÔNG MẤT DỮ LIỆU (RPO = 0)

D — và lợi ích ít được nhắc tới: bảo trì không gián đoạn.

Vá lỗi hệ điều hành hoặc đổi kích thước instance:
    → RDS thực hiện trên STANDBY trước
    → rồi failover sang standby đã nâng cấp
    → rồi nâng cấp nốt máy còn lại
        ↓
    Thời gian ngừng chỉ bằng thời gian failover, thay vì cả quá trình bảo trì

Và với Single-AZ thì ngược lại:

Vá lỗi hoặc đổi kích thước với Single-AZ:
    → instance PHẢI DỪNG trong suốt quá trình
    → có thể mất nhiều phút tới hàng chục phút

Cùng lý do đó, việc chụp snapshot cũng không ảnh hưởng hiệu năng với Multi-AZ — nó diễn ra trên standby.

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

• **C. Tạo primary và sao chép ĐỒNG BỘ sang standby ở AZ khác TRONG MỘT REGION KHÁC — đây là phương án gần nhất và mô tả gần đúng cơ chế, nhưng nó sai một chi tiết quyết định: Multi-AZ đặt standby ở AZ khác TRONG CÙNG Region, không phải Region khác. Muốn chịu lỗi cả Region thì cần cross-Region read replica hoặc Aurora Global Database.
• **B. Tăng đáng kể hiệu năng của database — sai: standby KHÔNG phục vụ truy vấn nào. Và sao chép đồng bộ còn làm TĂNG độ trễ ghi vì primary phải chờ standby xác nhận. Thứ tăng hiệu năng đọc là read replica.
• **E. Cung cấp tối ưu hoá SQL — không phải chức năng của Multi-AZ: tối ưu truy vấn là việc của Performance Insights, chỉ mục, và thiết kế truy vấn.

Ghi nhớ

Multi-AZ và Read Replica — bảng phân biệt cốt lõi: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | ĐỒNG BỘ | bất đồng bộ | | Instance thứ hai phục vụ đọc | ❌ KHÔNG BAO GIỜ | ✅ | | Failover | TỰ ĐỘNG | thủ công (promote) | | Mất dữ liệu khi sự cố | KHÔNG (RPO = 0) | có thể mất | | Vị trí | AZ khác, CÙNG Region | cùng AZ, khác AZ, hoặc khác REGION | | Ảnh hưởng độ trễ ghi | có — phải chờ standby | không |

"Standby không phục vụ đọc" và "Multi-AZ trong cùng Region" là hai điểm hay bị hỏi nhất.

Và chúng bổ sung nhau — kiến trúc sản xuất dùng cả hai:

Primary (Multi-AZ)  ──đồng bộ──▶  Standby         (chịu lỗi AZ)
      │
      └──bất đồng bộ──▶  Read replica × N          (mở rộng đọc)
      └──bất đồng bộ──▶  Cross-Region replica      (chịu lỗi Region)

Các sự kiện kích hoạt failover tự động: | Sự kiện | Có failover | |---|---| | Mất kết nối AZ chứa primary | ✅ | | Lỗi phần cứng của primary | ✅ | | Lỗi mạng của primary | ✅ | | Đổi loại instance | ✅ (trong bảo trì) | | Vá lỗi hệ điều hành | ✅ | | Bấm "Reboot with failover" | ✅ (dùng để diễn tập) |

Hai loại triển khai Multi-AZ của RDS: | Loại | Đặc điểm | |---|---| | Multi-AZ DB instance | 1 primary + 1 standby (standby KHÔNG đọc được) | | Multi-AZ DB cluster | 1 writer + 2 READER (đọc được!), failover dưới 35 giây |

Multi-AZ DB cluster là lựa chọn mới đáng chú ý — kết hợp cả sẵn sàng cao lẫn mở rộng đọc. Hiện hỗ trợ MySQL và PostgreSQL.

Và với đề nói "highly available in MULTIPLE REGIONS", Multi-AZ là CHƯA ĐỦ: | Nhu cầu | Giải pháp | |---|---| | Chịu lỗi AZ | Multi-AZ | | Chịu lỗi REGION | cross-Region read replica, hoặc Aurora Global Database |

Aurora Global Database đáng cân nhắc cho ứng dụng chuyển tiền quốc tế:

Aurora Global Database:
    ✓ sao chép sang tối đa 5 Region phụ
    ✓ độ trễ sao chép thường DƯỚI 1 GIÂY
    ✓ thăng cấp Region phụ trong dưới 1 PHÚT
    ✓ đọc cục bộ ở mỗi Region → độ trễ thấp cho người dùng toàn cầu

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chi phí GẤP ĐÔI | trả tiền cho cả hai instance | | Độ trễ ghi cao hơn | phải chờ standby xác nhận | | Sao lưu và bảo trì diễn ra trên standby | không ảnh hưởng hiệu năng primary |

Ba cấu hình ứng dụng cần có để failover mượt: | Cấu hình | Lý do | |---|---| | Dùng ENDPOINT DNS, không hard-code IP | IP đổi sau failover | | Đặt TTL cache DNS ngắn | Java mặc định cache DNS VĨNH VIỄN | | Có cơ chế thử lại kết nối | failover mất 60–120 giây |

java.security.Security.setProperty("networkaddress.cache.ttl", "5");

Và RDS Proxy giảm thời gian failover cảm nhận được tới 66% — nó giữ kết nối của client trong lúc database chuyển đổi.

Và một lời khuyên vận hành: hãy diễn tập failover định kỳ bằng nút "Reboot with failover" vào giờ thấp điểm. Nó cho biết thời gian ngừng thật của ứng dụng và phát hiện các vấn đề như DNS cache — trước khi sự cố thật xảy ra.