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

Đáp án

C — Dùng Lambda@Edge để nén các tệp khi gửi tới người dùng.

Vì sao đúng

Đề nêu ba ràng buộc, và nén là cách duy nhất trong bốn phương án giảm được lượng dữ liệu truyền: | Ràng buộc | Ý nghĩa | |---|---| | Tệp là DUY NHẤT cho từng khách hàng | KHÔNG cache được — mỗi tệp chỉ dùng một lần | | Giảm chi phí TRUYỀN DỮ LIỆU | phải giảm số BYTE, không phải số request | | KHÔNG sửa ứng dụng | xử lý ở tầng CDN |

⚠ Vế thứ nhất loại ngay phương án cache:

Cache chỉ tiết kiệm khi cùng một tệp
được yêu cầu NHIỀU LẦN
        ↓
    Tệp duy nhất cho mỗi khách hàng
    → tỷ lệ trúng cache bằng 0
    → bật cache không tiết kiệm được gì

Lambda@Edge nén ở origin response:

'use strict';
const zlib = require('zlib');

exports.handler = async (event) => {
  const response = event.Records[0].cf.response;
  const request = event.Records[0].cf.request;
  const acceptEncoding =
    (request.headers['accept-encoding'] || [{value:''}])[0].value;

  if (!acceptEncoding.includes('gzip')) return response;
  if (response.body === undefined) return response;

  const nen = zlib.gzipSync(Buffer.from(response.body, 'base64'));
  response.body = nen.toString('base64');
  response.bodyEncoding = 'base64';
  response.headers['content-encoding'] = [
    {key: 'Content-Encoding', value: 'gzip'}];
  return response;
};

⚠ Phải kiểm tra Accept-Encoding trước khi nén:

Client cũ không hiểu gzip
    → gửi nội dung nén cho nó = dữ liệu rác
        ↓
    Luôn tôn trọng header của client

Triển khai:

aws lambda publish-version --function-name nen-phan-hoi \
  --region us-east-1

aws cloudfront update-distribution --id E1ABCDEF \
  --distribution-config file://cau-hinh-co-lambda.json

⚠ Lambda@Edge BẮT BUỘC ở us-east-1 — CloudFront tự nhân bản nó ra các edge.

Hiệu quả nén thực tế: | Loại nội dung | Tỷ lệ giảm | |---|---| | JSON, XML, CSV | 60-90% | | HTML, CSS, JS | 70-80% | | Ảnh JPEG, PNG | gần 0 — đã nén rồi | | PDF | tuỳ, thường 10-30% |

Chi phí truyền dữ liệu CloudFront ~0,085 USD/GB
    → nén 70% = giảm 70% khoản đó
        ↓
    Với vài chục TB mỗi tháng, khoản tiết kiệm rất lớn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không sửa ứng dụng gốc | | | Giảm cả chi phí lẫn thời gian tải | | | Áp dụng cho mọi tệp, kể cả tệp duy nhất | |

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

⚠ CloudFront có nén TỰ ĐỘNG sẵn — thường không cần Lambda@Edge.

Bật một cờ trong cache policy là đủ:

aws cloudfront create-cache-policy --cache-policy-config '{
  "Name":"nen-tu-dong",
  "DefaultTTL":0,"MinTTL":0,"MaxTTL":0,
  "ParametersInCacheKeyAndForwardedToOrigin":{
    "EnableAcceptEncodingGzip":true,
    "EnableAcceptEncodingBrotli":true,
    ...}}'

Nhưng nén tự động có điều kiện, và chính chúng là lý do Lambda@Edge vẫn có chỗ dùng:

Tệp lớn hơn 10 MB
    → nén tự động KHÔNG áp dụng
        ↓
Content-Type lạ (application/x-custom)
    → không nằm trong danh sách
        ↓
    Đó là lúc cần Lambda@Edge

Nói rõ điều này vì gặp tình huống tương tự ngoài đời, hãy thử bật nén tự động trước — nó miễn phí và không thêm độ trễ. Chỉ dùng Lambda@Edge khi nội dung rơi ra ngoài các điều kiện đó.

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

• **A. Bật caching trên CloudFront để lưu tệp ở edge — đây là phương án gần nhất và là cách giảm chi phí đúng cho nội dung dùng chung, nhưng đề nói rõ tệp là duy nhất cho từng khách hàng: tỷ lệ trúng cache bằng 0, không tiết kiệm được gì.
• **B. Bật S3 Transfer Acceleration — tăng tốc TẢI LÊN S3 từ xa; nó không liên quan tới việc gửi tệp xuống người dùng, và còn tính phí thêm.
• **D. Dùng Global Accelerator — cải thiện độ trễ và định tuyến qua mạng AWS, nhưng không giảm lượng byte truyền; và nó tính phí riêng.

Ghi nhớ

⚠ Ba cách giảm chi phí truyền dữ liệu — bảng phải thuộc: | Cách | Khi nào hiệu quả | |---|---| | Cache ở CDN | nội dung DÙNG CHUNG, đọc nhiều lần | | Nén | mọi nội dung nén được, kể cả tệp duy nhất | | Giảm kích thước nguồn | tối ưu ảnh, bỏ dữ liệu thừa |

Từ khoá nhận diện:

"unique files per customer, reduce transfer cost" → nén "same content served repeatedly" → cache "reduce latency, not cost" → Global Accelerator hoặc CloudFront "faster uploads to S3" → Transfer Acceleration

⚠ CloudFront Functions vs Lambda@Edge: | Tiêu chí | CloudFront Functions | Lambda@Edge | |---|---|---| | Thời gian chạy tối đa | 1 ms | 5 giây (viewer) / 30 giây (origin) | | Truy cập body | ❌ | ✅ | | Gọi mạng | ❌ | ✅ | | Chi phí | rẻ hơn ~6 lần | | | Sự kiện | viewer request/response | cả bốn |

Nén cần đọc và sửa BODY
    → CloudFront Functions không làm được
    → phải dùng Lambda@Edge

Bốn điểm kích hoạt của Lambda@Edge: | Điểm | Khi nào chạy | |---|---| | Viewer request | mọi request từ client | | Origin request | chỉ khi cache miss | | Origin response | khi origin trả về — nén ở đây | | Viewer response | trước khi trả cho client |

⚠ Chọn origin response để nén là đúng:

Viewer response: chạy cho MỌI request, kể cả cache hit
    → nén lại nội dung đã nén
        ↓
Origin response: chỉ chạy khi lấy từ origin
    → nén một lần, cache bản đã nén

Ba lưu ý về giới hạn Lambda@Edge: | Giới hạn | Giá trị | |---|---| | Bộ nhớ (viewer) | 128 MB | | Kích thước response body sửa được | 1 MB | | Không dùng biến môi trường | |

⚠ Giới hạn 1 MB là ràng buộc thật:

Tệp lớn hơn 1 MB
    → Lambda@Edge không sửa body được
        ↓
    Phải nén ở origin, hoặc dùng nén tự động
      của CloudFront (tới 10 MB)

Ba cách nén tốt hơn nữa: | Cách | Chi tiết | |---|---| | Nén ở ORIGIN trước khi trả | rẻ nhất, không giới hạn kích thước | | Dùng Brotli thay gzip | nén tốt hơn ~15-20% | | Chọn định dạng gọn hơn | Protobuf thay JSON |

⚠ Nén ở origin là lựa chọn tốt nhất nếu sửa được:

Đề nói "without modifying the application"
    → nên mới phải xử lý ở edge
        ↓
    Nếu sửa được ứng dụng: bật gzip ở web server
    → không tốn Lambda@Edge, không giới hạn 1 MB

Ba lưu ý về chi phí CloudFront: | Khoản | Chi tiết | |---|---| | Truyền dữ liệu ra ~0,085 USD/GB | thay đổi theo Region | | Request HTTPS ~0,01 USD mỗi 10.000 | | | Lambda@Edge tính theo lời gọi và GB-giây | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | BytesDownloaded | lượng truyền — phải giảm | | CacheHitRate | | | Lambda@Edge Duration, Errors | |

Ba lưu ý về triển khai: | Lưu ý | Chi tiết | |---|---| | Lambda@Edge lan ra edge mất vài phút | | | Không xoá được hàm khi còn gắn | | | Log nằm ở Region gần edge, không ở us-east-1 | |

⚠ Tìm log Lambda@Edge là chuyện gây bối rối:

Hàm ở us-east-1
    → nhưng log nằm ở Region của EDGE đã chạy nó
        ↓
    Người dùng ở Singapore → log ở ap-southeast-1
    → phải tìm ở nhiều Region

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra header Content-Encoding: gzip | | | So BytesDownloaded trước và sau | | | Thử với client không hỗ trợ gzip | |

curl -H "Accept-Encoding: gzip" -sI https://vidu.com/tep-duy-nhat \
  | grep -i content-encoding

Và một lời khuyên: hãy thử bật nén tự động của CloudFront trước khi viết Lambda@Edge. Nó miễn phí, không thêm độ trễ, và xử lý được phần lớn nội dung — chỉ khi tệp vượt 10 MB hoặc có Content-Type lạ thì mới đáng trả tiền cho một hàm chạy ở mọi edge trên thế giới.

Đáp án

A — Tạo một bucket Amazon S3 và host trang web ở đó.

Vì sao đúng

Đề mô tả một trang web hoàn toàn tĩnh, và S3 static website hosting là cách rẻ nhất để phục vụ nó: | Dữ kiện | Ý nghĩa | |---|---| | HTML, CSS, JavaScript phía client, ảnh | không có mã chạy phía máy chủ | | RẺ NHẤT | S3 không có máy chủ nào chạy 24/7 |

⚠ "Client-side JavaScript" là từ khoá quyết định:

JavaScript chạy trong TRÌNH DUYỆT
    → máy chủ chỉ cần gửi tệp đi
        ↓
    Không cần runtime, không cần container,
    không cần máy nào bật

Dựng:

aws s3 mb s3://trang-noi-bo-dev

aws s3 website s3://trang-noi-bo-dev \
  --index-document index.html --error-document 404.html

aws s3 sync ./trang-web s3://trang-noi-bo-dev --delete

So sánh chi phí: | Cách | Chi phí tháng (ước tính) | |---|---| | S3 static hosting | vài xu tới vài USD | | EC2 t3.micro | ~8 USD + công vá | | Fargate 0,25 vCPU | ~9 USD | | ALB + Lambda | ~16 USD chỉ riêng ALB |

⚠ ALB tính phí theo giờ dù không có ai truy cập — đó là lý do phương án D đắt nhất dù Lambda rẻ.

Cách khuyến nghị hiện nay — S3 riêng tư + CloudFront + OAC:

aws s3api put-public-access-block --bucket trang-noi-bo-dev \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

aws cloudfront create-origin-access-control \
  --origin-access-control-config '{
    "Name":"oac-trang-web",
    "OriginAccessControlOriginType":"s3",
    "SigningBehavior":"always","SigningProtocol":"sigv4"}'

⚠ Vì sao không dùng static website endpoint công khai: | Vấn đề | Chi tiết | |---|---| | Chỉ HTTP, không HTTPS | | | Bucket phải công khai | | | Không có WAF, không có geo restriction | |

S3 static website endpoint: http://... — KHÔNG có TLS
        ↓
    CloudFront + OAC: HTTPS miễn phí qua ACM,
    bucket vẫn riêng tư

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không máy chủ nào để vá hay giám sát | | | Tự mở rộng tới bất kỳ lưu lượng nào | | | Độ bền 11 số 9 | |

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

• **B. EC2 instance — đây là phương án gần nhất về mặt cũng phục vụ được trang web, nhưng phải trả tiền máy chạy liên tục, tự vá hệ điều hành, tự lo sẵn sàng cao; hoàn toàn thừa cho tệp tĩnh.
• **C. Docker container trên Fargate — cũng phải trả tiền task chạy liên tục cộng ALB phía trước; nhiều tầng cho một việc không cần tính toán.
• **D. ALB với Lambda target — ALB tính phí ~16 USD mỗi tháng dù không ai truy cập; đắt nhất trong bốn phương án cho một trang tĩnh.

Ghi nhớ

⚠ Bốn cách host web — bảng phải thuộc: | Cách | Khi nào | Chi phí khi rảnh | |---|---|---| | S3 (+ CloudFront) | hoàn toàn TĨNH | gần 0 | | Amplify Hosting | tĩnh + CI/CD tích hợp | gần 0 | | API Gateway + Lambda | có logic phía máy chủ, thưa thớt | 0 | | ALB + EC2/Fargate | ứng dụng thường trực | cao |

Từ khoá nhận diện:

"HTML, CSS, client-side JS, images" → S3 static hosting "static site with Git-based CI/CD" → Amplify "server-side rendering, API" → Lambda hoặc container "needs a database and sessions" → không phải trang tĩnh

⚠ AWS Amplify Hosting là lựa chọn đáng cân nhắc:

amplify init
amplify add hosting
amplify publish

Gói sẵn: S3 + CloudFront + HTTPS + tên miền
         + CI/CD từ Git + preview cho mỗi nhánh
        ↓
    Ít việc hơn tự dựng, giá tương đương

Ba lưu ý về SPA (ứng dụng một trang): | Lưu ý | Chi tiết | |---|---| | Đường dẫn client-side trả 404 từ S3 | | | Cấu hình error document về index.html | | | Hoặc dùng CloudFront Function viết lại URL | |

⚠ Đây là lỗi hay gặp nhất khi host SPA trên S3:

Người dùng vào thẳng /san-pham/123
    → S3 không có object đó → 404
        ↓
    Trỏ 404 về index.html, mã trạng thái 200
    → router phía client xử lý tiếp

{"CustomErrorResponses": {"Quantity": 1, "Items": [{
  "ErrorCode": 404,
  "ResponsePagePath": "/index.html",
  "ResponseCode": "200",
  "ErrorCachingMinTTL": 0}]}}

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access, dùng OAC | | | Chứng chỉ ACM ở us-east-1 cho CloudFront | | | Đặt header bảo mật bằng response headers policy | |

aws cloudfront create-response-headers-policy \
  --response-headers-policy-config '{
    "Name":"header-bao-mat",
    "SecurityHeadersConfig":{
      "StrictTransportSecurity":{"Override":true,
        "AccessControlMaxAgeSec":31536000,
        "IncludeSubdomains":true},
      "ContentTypeOptions":{"Override":true},
      "FrameOptions":{"Override":true,"FrameOption":"DENY"}}}'

Ba lưu ý về cache: | Loại tệp | TTL nên đặt | |---|---| | index.html | ngắn hoặc 0 | | JS/CSS có hash trong tên | rất dài (1 năm) | | Ảnh | dài |

⚠ Mẫu triển khai chuẩn cho trang tĩnh:

Tệp có hash: app.a1b2c3.js — cache 1 năm
index.html:  trỏ tới tên có hash — cache 0
        ↓
    Triển khai mới = index.html mới trỏ hash mới
    → không cần invalidation

Ba lưu ý về invalidation: | Lưu ý | Chi tiết | |---|---| | 1.000 đường dẫn đầu mỗi tháng miễn phí | | | Sau đó ~0,005 USD mỗi đường dẫn | | | Dùng versioning tên tệp thay vì invalidate | |

Ba lưu ý về triển khai: | Lưu ý | Chi tiết | |---|---| | aws s3 sync --delete đồng bộ chính xác | | | Đặt --cache-control theo loại tệp | | | Tự động hoá bằng CodePipeline hoặc GitHub Actions | |

aws s3 sync ./build s3://trang-noi-bo-dev \
  --exclude "index.html" \
  --cache-control "public,max-age=31536000,immutable"

aws s3 cp ./build/index.html s3://trang-noi-bo-dev/index.html \
  --cache-control "no-cache"

Ba lưu ý về chi phí S3: | Khoản | Giá tham khảo | |---|---| | Lưu trữ | ~0,023 USD/GB-tháng | | GET request | ~0,0004 USD mỗi 1000 | | Truyền ra qua CloudFront | rẻ hơn truyền thẳng từ S3 |

Ba lưu ý về tên miền: | Lưu ý | Chi tiết | |---|---| | Route 53 alias record trỏ tới CloudFront | | | Alias record miễn phí truy vấn | | | Chứng chỉ ACM phải ở us-east-1 | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy cập qua HTTPS | | | Thử URL sâu của SPA | | | Kiểm tra bucket không truy cập trực tiếp được | |

Và một lời khuyên: hãy đặt CloudFront trước S3 ngay cả cho trang nội bộ. Static website endpoint của S3 chỉ chạy HTTP và đòi bucket công khai — hai điều mà ngày nay không có lý do gì phải chấp nhận khi CloudFront với OAC cho bạn HTTPS miễn phí và một bucket hoàn toàn riêng tư.

Đáp án

B và E — Tạo Auto Scaling group và Application Load Balancer trải nhiều AZ; tạo subnet riêng tư mới ở AZ khác và chuyển CSDL sang RDS Multi-AZ.

Vì sao đúng

Đề mô tả kiến trúc có hai điểm hỏng duy nhất, và mỗi lựa chọn xử lý một cái: | Vấn đề | Giải pháp | |---|---| | Tầng web trên EC2, một AZ | B — ASG + ALB trải nhiều AZ | | CSDL trên EC2, một AZ | E — RDS Multi-AZ ở subnet nhiều AZ |

⚠ "Cùng một Availability Zone" là vấn đề cốt lõi:

Cả hai tầng nằm trong MỘT AZ
    → AZ đó mất điện hay mất mạng
        ↓
    Toàn bộ ứng dụng ngừng
    → không có gì cứu được

B — tầng web sẵn sàng cao:

aws elbv2 create-load-balancer --name alb-ung-dung \
  --subnets subnet-cong-khai-a subnet-cong-khai-b \
  --scheme internet-facing --type application

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-rieng-tu-a,subnet-rieng-tu-b" \
  --target-group-arns <arn-tg> --health-check-type ELB

⚠ ALB BẮT BUỘC phải có subnet ở ít nhất 2 AZ — đây là ràng buộc của chính dịch vụ.

E — tầng CSDL sẵn sàng cao:

aws rds create-db-subnet-group \
  --db-subnet-group-name nhom-subnet-csdl \
  --db-subnet-group-description "Subnet rieng tu nhieu AZ" \
  --subnet-ids subnet-csdl-a subnet-csdl-b

aws rds create-db-instance \
  --db-instance-identifier csdl-ung-dung \
  --engine mysql --db-instance-class db.r6g.large \
  --allocated-storage 200 --storage-type gp3 \
  --db-subnet-group-name nhom-subnet-csdl \
  --multi-az --storage-encrypted \
  --manage-master-user-password

⚠ Chuyển từ CSDL tự quản lý sang RDS cho thêm hai thứ: | Thứ | Chi tiết | |---|---| | Failover tự động | 60-120 giây, endpoint không đổi | | Bớt công vận hành | AWS vá, sao lưu, giám sát |

Ba lợi ích khi làm cả hai: | Lợi ích | Chi tiết | |---|---| | Không còn điểm hỏng duy nhất nào | | | Mất một AZ vẫn phục vụ được | | | Tầng web co giãn theo tải | |

⚠ Ứng dụng phải KHÔNG có trạng thái để ASG hoạt động đúng:

Session lưu trong bộ nhớ máy
    → ASG thay máy = người dùng đăng xuất
        ↓
    Đưa session vào ElastiCache hoặc DynamoDB
    → hoặc bật sticky session (kém hơn)

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

• **C. Đưa instance hiện có vào ASG sau ALB — đây là phương án gần nhất và là một phần đúng, nhưng nó không nói tới nhiều AZ: đưa các máy vốn đã nằm cùng một AZ vào ASG thì AZ đó hỏng vẫn mất tất cả.
• **A. Tạo subnet riêng tư ở AZ khác rồi dựng CSDL trên EC2 ở MỘT AZ — vẫn là CSDL tự quản lý ở một AZ; không có failover tự động, không giải quyết được gì.
• **D. Tạo subnet công khai cùng AZ và chuyển tầng web ra đó — đưa máy ứng dụng ra Internet là bước lùi về bảo mật, và "cùng AZ" không cải thiện tính sẵn sàng chút nào.

Ghi nhớ

⚠ Ba trụ cột của sẵn sàng cao trên AWS — bảng phải thuộc: | Trụ cột | Cách làm | |---|---| | Nhiều Availability Zone | bắt buộc — mọi tầng | | Không có điểm hỏng duy nhất | ALB, ASG, Multi-AZ | | Tự phục hồi | ASG thay máy hỏng, RDS tự failover |

⚠ "Highly available" trong đề thi LUÔN có nghĩa là nhiều AZ:

Một AZ = một hoặc vài trung tâm dữ liệu
    → có thể mất điện, mất mạng, cháy
        ↓
    Mọi kiến trúc sản xuất phải trải ít nhất 2 AZ

Từ khoá nhận diện:

"high availability, multi-tier" → ALB + ASG nhiều AZ + RDS Multi-AZ "survive Region failure" → kiến trúc đa Region "scale reads" → read replica "stateless application" → session ra ngoài

Ba lưu ý về RDS Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Standby KHÔNG phục vụ đọc (DB instance) | | | Nhân bản đồng bộ | | | Endpoint không đổi khi failover | |

⚠ Multi-AZ DB cluster là lựa chọn mới tốt hơn: | | DB instance | DB cluster | |---|---|---| | Số standby | 1 | 2 | | Standby đọc được | ❌ | ✅ | | Thời gian failover | 60-120 giây | dưới 35 giây | | Số AZ | 2 | 3 |

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | min-size ít nhất bằng số AZ | | | Health check type ELB | | | Grace period đủ dài cho ứng dụng khởi động | |

⚠ Health check EC2 không đủ:

Health check EC2: chỉ kiểm máy có chạy không
    → ứng dụng chết mà máy vẫn "khoẻ"
        ↓
    Health check ELB: kiểm ứng dụng có trả lời không
    → phát hiện đúng vấn đề

Ba lưu ý về phân bổ AZ: | Lưu ý | Chi tiết | |---|---| | ASG tự cân bằng số máy giữa các AZ | | | Mỗi AZ nên đủ năng lực gánh phần của AZ hỏng | | | 2 AZ = mỗi bên phải chịu được 100% | |

⚠ Đây là tính toán hay bị bỏ qua:

2 AZ, mỗi AZ 2 máy, tổng 4 máy đủ tải
    → một AZ hỏng, còn 2 máy
        ↓
    2 máy có gánh nổi 100% tải không?
    → nếu không, phải chạy 3 máy mỗi AZ

Ba lưu ý về subnet: | Lưu ý | Chi tiết | |---|---| | Subnet KHÔNG trải nhiều AZ | mỗi subnet một AZ | | Cần subnet riêng cho từng tầng, từng AZ | | | Chừa đủ IP cho mở rộng | |

Ba lưu ý về NAT gateway: | Lưu ý | Chi tiết | |---|---| | Một NAT gateway MỖI AZ | | | Dùng chung một cái là điểm hỏng duy nhất | | | Cũng tránh được phí liên AZ | |

Ba lưu ý về session: | Cách | Chi tiết | |---|---| | ElastiCache Redis | phổ biến nhất | | DynamoDB | bền hơn, độ trễ cao hơn chút | | Sticky session của ALB | tạm được, phân bổ tải kém |

Ba lưu ý về triển khai: | Lưu ý | Chi tiết | |---|---| | Dùng CloudFormation hoặc CDK | | | Rolling update qua ASG | | | Không sửa máy bằng tay | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt hết máy ở một AZ, xem còn phục vụ | | | Chạy --force-failover cho RDS | | | Kiểm tra target group có target ở cả hai AZ | |

aws elbv2 describe-target-health --target-group-arn <arn> \
  --query "TargetHealthDescriptions[].
    [Target.Id,Target.AvailabilityZone,TargetHealth.State]" \
  --output table

Và một lời khuyên: hãy kiểm tra một AZ có gánh nổi toàn bộ tải không, chứ đừng chỉ đếm số AZ. Trải hai vùng sẵn sàng chỉ có ý nghĩa nếu vùng còn lại chịu được 100% lưu lượng — nếu không thì bạn đã biến một sự cố hạ tầng thành một sự cố quá tải.

Đáp án

C — Dùng AWS Transfer Family tạo máy chủ SFTP lưu tệp vào S3 Standard; tạo hàm Lambda xử lý và xoá tệp; dùng S3 event notification kích hoạt hàm khi tệp tới.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Client FTP đổi càng ít càng tốt | Transfer Family — client vẫn nói SFTP | | Xử lý NGAY khi tệp tới | S3 event → Lambda, độ trễ dưới một giây | | Xoá tệp sau khi xử lý thành công | chính hàm Lambda xoá | | Mỗi tệp mất ~10 phút | trong giới hạn 15 phút của Lambda |

⚠ Con số 10 phút là chi tiết quyết định:

Lambda tối đa 15 phút
    → 10 phút vừa đủ, còn dư 5 phút biên
        ↓
    Nếu đề nói 20 phút thì Lambda sai
    → phải dùng Fargate hoặc Batch

Dựng máy chủ SFTP được quản lý:

aws transfer create-server \
  --identity-provider-type SERVICE_MANAGED \
  --protocols SFTP \
  --endpoint-type VPC \
  --endpoint-details 'VpcId=vpc-abc,
                      SubnetIds=subnet-a,subnet-b,
                      SecurityGroupIds=sg-sftp' \
  --domain S3

Ánh xạ người dùng vào bucket:

aws transfer create-user --server-id s-abc \
  --user-name benh-vien-a \
  --role <arn-role> \
  --home-directory-type LOGICAL \
  --home-directory-mappings '[{"Entry":"/",
    "Target":"/du-lieu-benh-nhan/benh-vien-a"}]' \
  --ssh-public-key-body "ssh-rsa AAAA..."

⚠ LOGICAL home directory che giấu cấu trúc bucket:

Client thấy: /
Thực tế:     s3://du-lieu-benh-nhan/benh-vien-a/
        ↓
    Mỗi client bị nhốt trong thư mục của mình
    → không thấy dữ liệu bệnh viện khác

Kích hoạt Lambda:

aws s3api put-bucket-notification-configuration \
  --bucket du-lieu-benh-nhan \
  --notification-configuration '{
    "LambdaFunctionConfigurations": [{
      "LambdaFunctionArn": "<arn-ham>",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": {"Key": {"FilterRules": [
        {"Name": "suffix", "Value": ".dat"}]}}}]}'

Xử lý rồi xoá:

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

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        gau = ban_ghi['s3']['bucket']['name']
        khoa = ban_ghi['s3']['object']['key']
        xu_ly_ho_so(gau, khoa)
        s3.delete_object(Bucket=gau, Key=khoa)

⚠ Chỉ xoá SAU KHI xử lý thành công:

Xoá trước, xử lý sau
    → xử lý lỗi = mất dữ liệu bệnh nhân vĩnh viễn
        ↓
    Lệnh xoá phải nằm sau khi xử lý hoàn tất
    → và có DLQ cho tệp lỗi

Cấu hình hàm:

aws lambda update-function-configuration \
  --function-name xu-ly-ho-so \
  --timeout 900 --memory-size 2048 \
  --ephemeral-storage Size=2048

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Xử lý ngay, không chờ hai lần mỗi ngày | | | Không máy chủ nào chạy khi rảnh | | | Song song hoàn toàn — hàng nghìn tệp cùng lúc | |

⚠ Đây là cải thiện lớn nhất so với hiện trạng:

Trước: một máy chủ xử lý tuần tự, mất HÀNG GIỜ
        ↓
    Sau: mỗi tệp một thực thi Lambda riêng
    → 1000 tệp xử lý song song
    → tổng thời gian ≈ thời gian một tệp

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

• **D. Transfer Family + Lambda khởi chạy EC2 để xử lý — đây là phương án gần nhất và cũng dùng đúng cơ chế nhận tệp, nhưng khởi chạy EC2 cho mỗi đợt tệp là công vận hành lớn: chờ máy boot, tự quản lý vòng đời, tự lo tắt máy.
• **B. EC2 chạy SFTP + AWS Batch chạy hai lần mỗi ngày — giữ nguyên đúng vấn đề đề muốn bỏ (xử lý theo lô hai lần/ngày), và thêm một máy chủ SFTP tự quản lý.
• **A. Transfer Family lưu thẳng vào S3 Glacier rồi xử lý hai lần/ngày — Glacier cần 12-48 giờ để lấy dữ liệu, hoàn toàn ngược với "xử lý ngay khi tệp tới".

Ghi nhớ

⚠ AWS Transfer Family — bảng phải thuộc: | Giao thức | Hỗ trợ | |---|---| | SFTP | ✅ | | FTPS | ✅ | | FTP | ✅ chỉ trong VPC, không ra Internet | | AS2 | ✅ trao đổi dữ liệu B2B |

⚠ FTP thuần không phơi ra Internet được — vì nó truyền credential dạng thô.

Từ khoá nhận diện:

"keep FTP/SFTP clients unchanged, store in S3" → Transfer Family "process on arrival, under 15 min" → S3 event + Lambda "process on arrival, over 15 min" → S3 event → Fargate hoặc Batch "scheduled batch processing" → EventBridge + Batch

Ba kiểu nhà cung cấp danh tính của Transfer Family: | Kiểu | Chi tiết | |---|---| | Service managed | AWS lưu khoá công khai SSH | | Directory Service | nối Active Directory | | Custom (Lambda/API Gateway) | logic xác thực riêng |

Ba lưu ý về endpoint: | Kiểu | Chi tiết | |---|---| | VPC (internal) | chỉ truy cập từ trong VPC hoặc qua VPN/DX | | VPC (internet-facing) | có Elastic IP cố định | | Public | AWS quản lý IP, thay đổi được |

⚠ Endpoint VPC với Elastic IP quan trọng cho đối tác:

Đối tác thường phải khai IP vào allowlist tường lửa
    → endpoint public có IP thay đổi
        ↓
    Endpoint VPC + EIP: IP cố định, khai một lần

Ba lưu ý về Lambda cho tệp lớn: | Lưu ý | Chi tiết | |---|---| | Đọc theo LUỒNG, đừng nạp cả tệp | | | /tmp tới 10 GB nếu cần ghi tạm | | | Bộ nhớ lớn hơn = CPU nhiều hơn | |

doi_tuong = s3.get_object(Bucket=gau, Key=khoa)
for dong in doi_tuong['Body'].iter_lines():
    xu_ly(dong)

Ba lưu ý về xử lý lỗi: | Lưu ý | Chi tiết | |---|---| | S3 → Lambda chỉ thử lại 2 lần rồi bỏ | | | Cấu hình destination OnFailure | | | Hoặc đi qua SQS để có DLQ đầy đủ | |

⚠ Với dữ liệu bệnh nhân, mất tệp là không chấp nhận được:

S3 → SQS → Lambda
    → tin nhắn nằm trong hàng đợi tới khi xử lý xong
    → hỏng thì vào DLQ, không biến mất
        ↓
    Đáng thêm một bộ phận cho loại dữ liệu này

Ba lưu ý về đồng thời: | Lưu ý | Chi tiết | |---|---| | Hàng nghìn tệp cùng lúc = hàng nghìn Lambda | | | Mặc định 1.000 đồng thời mỗi tài khoản | | | Reserved concurrency bảo vệ hàm khác | |

Ba lưu ý về HIPAA (dữ liệu y tế): | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | | | Mã hoá at rest (SSE-KMS) và in transit | | | Bật CloudTrail data event cho bucket | |

⚠ Tệp đã mã hoá sẵn từ nguồn vẫn nên mã hoá lại ở S3:

Đề nói "encrypted patient data files"
    → mã hoá ở tầng ứng dụng
        ↓
    Vẫn bật SSE-KMS cho bucket
    → phòng thủ nhiều lớp, và có nhật ký dùng khoá

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Transfer Family | ~0,30 USD/giờ mỗi giao thức | | Phí truyền dữ liệu | ~0,04 USD/GB | | Lambda | theo GB-giây |

⚠ Transfer Family tính phí theo GIỜ dù không ai kết nối:

~0,30 USD/giờ × 24 × 30 ≈ 216 USD/tháng
    → khoản cố định đáng kể
        ↓
    Cân nhắc nếu lưu lượng rất thấp
    → nhưng thường vẫn rẻ hơn tự quản lý máy chủ SFTP

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | FilesIn của Transfer Family | | | Lambda Errors, Duration | | | Cảnh báo khi không có tệp nào trong X giờ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải tệp thử qua SFTP | | | Xác nhận Lambda chạy và tệp bị xoá | | | Kiểm tra thời gian xử lý dưới 15 phút | |

sftp -i khoa-rieng benh-vien-a@s-abc.server.transfer.ap-southeast-1.amazonaws.com

Và một lời khuyên: hãy đưa tệp qua SQS trước khi tới Lambda với dữ liệu bệnh nhân. S3 gọi Lambda trực tiếp chỉ thử lại hai lần rồi bỏ cuộc trong im lặng — và với hồ sơ y tế thì một tệp biến mất vì lỗi tạm thời là hậu quả không thể chấp nhận.

Đáp án

B — Chuyển dữ liệu và ứng dụng sang Amazon RDS, bật mã hoá at rest bằng AWS KMS.

Vì sao đúng

Đề nêu ba yêu cầu, và RDS + KMS đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Dữ liệu khách hàng nhạy cảm được lưu AN TOÀN | mã hoá at rest bằng KMS | | Quản lý an toàn | key policy, CloudTrail ghi lần dùng khoá | | GIẢM công vận hành quản lý CSDL | RDS — AWS lo vá, sao lưu, HA |

⚠ Vế thứ ba là chỗ phân biệt B với D:

EC2 tự cài CSDL:
    → tự vá hệ điều hành và engine
    → tự dựng sao lưu và khôi phục
    → tự dựng Multi-AZ và failover
        ↓
RDS: AWS làm tất cả
    → đúng "reducing operational overhead"

Tạo instance mã hoá:

aws rds create-db-instance \
  --db-instance-identifier csdl-khach-hang \
  --engine postgres --engine-version 16.3 \
  --db-instance-class db.r6g.xlarge \
  --allocated-storage 500 --storage-type gp3 \
  --storage-encrypted --kms-key-id <arn-khoa> \
  --multi-az --backup-retention-period 35 \
  --manage-master-user-password \
  --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' \
  --no-publicly-accessible

⚠ --storage-encrypted chỉ đặt được LÚC TẠO:

Không bật lúc tạo
    → phải snapshot → chép có mã hoá → khôi phục
    → tốn một cửa sổ ngừng dịch vụ
        ↓
    Bật ngay từ đầu

Mã hoá phủ toàn bộ: | Thành phần | Được mã hoá | |---|---| | Dữ liệu trên đĩa | ✅ | | Snapshot tự động và thủ công | ✅ | | Read replica | ✅ | | Bản sao lưu | ✅ | | Log | ✅ |

Thêm mã hoá khi truyền:

aws rds modify-db-parameter-group \
  --db-parameter-group-name nhom-tham-so \
  --parameters "ParameterName=rds.force_ssl,ParameterValue=1,
                ApplyMethod=pending-reboot"

⚠ Hai loại mã hoá là hai thứ khác nhau:

At rest:    dữ liệu trên đĩa   → KMS
In transit: dữ liệu trên dây   → SSL/TLS
        ↓
    Tuân thủ ngành tài chính cần CẢ HAI

Ba lợi ích của KMS so với mã hoá tự quản lý: | Lợi ích | Chi tiết | |---|---| | Key policy quyết định ai giải mã được | | | CloudTrail ghi mọi lần dùng khoá | | | Xoay khoá tự động | |

Ba lợi ích vận hành của RDS: | Lợi ích | Chi tiết | |---|---| | Vá tự động trong cửa sổ bảo trì | | | Sao lưu tự động, khôi phục tới từng giây | | | Multi-AZ failover tự động | |

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

• **D. Chuyển sang EC2 và dùng KMS customer managed key — đây là phương án gần nhất vì cũng mã hoá bằng KMS, nhưng nó giữ nguyên toàn bộ công vận hành CSDL, ngược thẳng với yêu cầu chính của đề.
• **C. RDS với GuardDuty để "bảo vệ dữ liệu" — GuardDuty phát hiện mối đe doạ, nó không mã hoá gì cả; và đề hỏi cách lưu trữ an toàn.
• **A. Lưu ở S3 với Macie — đổi CSDL thành lưu trữ đối tượng là thay đổi kiến trúc lớn; và Macie chỉ phát hiện dữ liệu nhạy cảm, không phải cơ chế bảo vệ.

Ghi nhớ

⚠ Ba khái niệm bảo mật hay bị lẫn — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | KMS | MÃ HOÁ và quản lý khoá | | GuardDuty | PHÁT HIỆN mối đe doạ | | Macie | PHÁT HIỆN dữ liệu nhạy cảm trong S3 | | Inspector | phát hiện lỗ hổng |

Từ khoá nhận diện:

"store data securely, reduce database management" → RDS + KMS "detect compromised resources" → GuardDuty "find PII in S3" → Macie "encrypt with my own keys" → KMS customer managed key

Ba loại khoá KMS: | Loại | Chi phí | Kiểm soát | |---|---|---| | AWS managed (aws/rds) | miễn phí | không sửa key policy được | | Customer managed | ~1 USD/tháng | đầy đủ | | AWS owned | miễn phí | không thấy được |

⚠ Ngành tài chính thường bắt buộc customer managed key:

Cần chứng minh kiểm soát khoá
    → key policy, nhật ký dùng khoá, quyền xoay
        ↓
    AWS managed key không cho những thứ đó

Ba lưu ý về bảo vệ khoá: | Lưu ý | Chi tiết | |---|---| | Chặn kms:ScheduleKeyDeletion | | | Bật xoay khoá tự động | | | Xoá khoá = dữ liệu mất vĩnh viễn | |

{"Effect": "Deny", "Principal": "*",
 "Action": ["kms:ScheduleKeyDeletion", "kms:DisableKey"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/QuanTriKhoa"}}}

Ba lưu ý về CloudHSM: | Lưu ý | Chi tiết | |---|---| | Cần FIPS 140-2 Level 3 thì dùng CloudHSM | | | Bạn kiểm soát HSM hoàn toàn | | | Đắt và nhiều việc hơn KMS nhiều | |

Ba lưu ý về quản lý credential: | Cách | Chi tiết | |---|---| | --manage-master-user-password | RDS tự tạo và xoay qua Secrets Manager | | IAM database authentication | không có mật khẩu tĩnh | | RDS Proxy | gộp kết nối, giữ credential |

⚠ --manage-master-user-password là tính năng nên dùng:

RDS tự tạo mật khẩu, lưu vào Secrets Manager,
tự xoay theo lịch
        ↓
    Không ai nhìn thấy mật khẩu
    → không có gì để rò rỉ

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | --no-publicly-accessible | | | DB subnet group chỉ gồm subnet riêng tư | | | Security group tham chiếu SG của ứng dụng | |

Ba lưu ý về audit: | Lưu ý | Chi tiết | |---|---| | Bật export log ra CloudWatch Logs | | | Database Activity Streams cho Aurora | | | CloudTrail ghi thao tác quản trị | |

⚠ Database Activity Streams ghi MỌI câu lệnh:

aws rds start-activity-stream \
  --resource-arn <arn-cum> --mode async \
  --kms-key-id <arn-khoa>

Luồng gần thời gian thực mọi hoạt động CSDL
    → gửi qua Kinesis
    → đáp ứng yêu cầu audit nghiêm ngặt

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Config rule rds-storage-encrypted | | | SCP chặn tạo RDS chưa mã hoá | | | Conformance pack cho PCI-DSS | |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Retention tới 35 ngày cho PITR | | | Snapshot thủ công giữ vô hạn | | | Chép snapshot sang Region khác cho DR | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra StorageEncrypted: true | | | Thử kết nối không SSL | phải bị từ chối | | Xem CloudTrail ghi lần dùng khoá | |

aws rds describe-db-instances --db-instance-identifier csdl-khach-hang \
  --query "DBInstances[0].[StorageEncrypted,KmsKeyId,PubliclyAccessible]"

Và một lời khuyên: hãy bật mã hoá ngay lúc tạo instance chứ đừng để sau. Đây là thuộc tính duy nhất của RDS không sửa được sau khi tạo, và cách chữa — snapshot, chép có mã hoá, khôi phục, đổi endpoint — luôn tốn một cửa sổ ngừng dịch vụ mà lẽ ra không cần có.

Đáp án

A — Bật automatic storage scaling (RDS Storage Auto Scaling) cho instance MySQL.

Vì sao đúng

Đề nêu ba yêu cầu, và tính năng này giải quyết đúng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Sắp hết dung lượng lưu trữ | tự tăng dung lượng | | KHÔNG gián đoạn | mở rộng không cần ngừng dịch vụ | | KHÔNG can thiệp thủ công | hoàn toàn tự động |

⚠ Đây là tính năng có sẵn, chỉ cần bật một cờ:

aws rds modify-db-instance \
  --db-instance-identifier csdl-cms \
  --max-allocated-storage 2000 \
  --apply-immediately

Cách hoạt động:

RDS theo dõi dung lượng còn trống
    → còn dưới 10% VÀ tình trạng đó kéo dài 5 phút
    → VÀ đã 6 giờ kể từ lần mở rộng trước
        ↓
    Tự tăng thêm max(5 GB, 10% dung lượng hiện tại)
    → không ngừng dịch vụ

⚠ Ba điều kiện phải thoả đồng thời: | Điều kiện | Giá trị | |---|---| | Dung lượng trống | dưới 10% | | Kéo dài | ít nhất 5 phút | | Từ lần mở rộng trước | ít nhất 6 giờ |

Đây là lý do vẫn nên đặt cảnh báo dung lượng
    → tăng đột ngột 50% trong một giờ
    → auto scaling không kịp (phải chờ 6 giờ)

Đặt cảnh báo bổ sung:

aws cloudwatch put-metric-alarm --alarm-name rds-sap-het-dia \
  --namespace AWS/RDS --metric-name FreeStorageSpace \
  --dimensions Name=DBInstanceIdentifier,Value=csdl-cms \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 10737418240 --comparison-operator LessThanThreshold \
  --alarm-actions <arn-sns>

⚠ --max-allocated-storage là trần an toàn:

Không đặt trần
    → không bật được auto scaling
        ↓
    Đặt quá cao: rò rỉ dữ liệu có thể phình tới đó
    → đặt ở mức bạn sẵn sàng trả tiền

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không bao giờ đầy đĩa giữa đêm | | | Không ngừng dịch vụ | | | Không tốn thêm phí — chỉ trả GB thật cấp | |

⚠ Đầy đĩa là một trong những sự cố RDS tệ nhất:

Dung lượng cạn
    → instance chuyển sang trạng thái `storage-full`
    → CSDL NGỪNG NHẬN GHI
        ↓
    Ứng dụng lỗi hàng loạt
    → và mở rộng lúc đó mất nhiều phút

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

• **B. Chuyển sang instance RDS MySQL lớn hơn — đây là phương án gần nhất và cũng tăng được dung lượng, nhưng đổi cỡ instance là thao tác có gián đoạn và vẫn là can thiệp thủ công; đề nói rõ không muốn cả hai.
• **C. Dùng ElastiCache giảm tải đọc — cache giảm tải truy vấn, không giảm dung lượng lưu trữ chút nào.
• **D. Dùng lifecycle policy xoá dữ liệu cũ — RDS không có lifecycle policy; đó là khái niệm của S3. Và xoá dữ liệu là quyết định nghiệp vụ, không phải giải pháp hạ tầng.

Ghi nhớ

⚠ Ba loại "auto scaling" cho CSDL — bảng phải thuộc: | Loại | Mở rộng cái gì | |---|---| | RDS Storage Auto Scaling | DUNG LƯỢNG ĐĨA | | Aurora Serverless v2 | CPU và RAM | | Read replica auto scaling | số bản sao ĐỌC |

⚠ Ba thứ này giải ba vấn đề khác nhau — đừng nhầm:

Đĩa đầy        → Storage Auto Scaling
CPU quá tải    → đổi cỡ instance, hoặc Aurora Serverless
Đọc quá nhiều  → read replica

Từ khoá nhận diện:

"running out of storage, no interruption, no manual work" → Storage Auto Scaling "unpredictable compute load" → Aurora Serverless v2 "read traffic overwhelming" → read replica "reduce database load" → ElastiCache

Ba giới hạn của Storage Auto Scaling: | Giới hạn | Chi tiết | |---|---| | Chỉ TĂNG, không giảm | | | Tối thiểu 6 giờ giữa hai lần | | | Không vượt max-allocated-storage | |

⚠ Không giảm được là điều phải nhớ khi lập ngân sách:

Đĩa tăng lên 2 TB sau một đợt nhập dữ liệu
    → xoá dữ liệu không làm đĩa nhỏ lại
        ↓
    Vẫn trả tiền 2 TB
    → muốn giảm phải dump và tạo instance mới

Ba lưu ý về loại lưu trữ: | Loại | Đặc điểm | |---|---| | gp3 | mặc định tốt, IOPS độc lập dung lượng | | gp2 | IOPS gắn với dung lượng | | io1/io2 | IOPS cấp phát riêng, đắt |

⚠ Với gp2, tăng dung lượng cũng tăng IOPS:

gp2: 3 IOPS mỗi GB
    → tăng đĩa từ 500 GB lên 1 TB
    → IOPS từ 1.500 lên 3.000
        ↓
    Đây là tác dụng phụ tích cực
    → nhưng gp3 tách hai thứ ra, tốt hơn

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | FreeStorageSpace | dung lượng còn trống | | ReadIOPS / WriteIOPS | | | BurstBalance | với gp2 |

Ba nguyên nhân đĩa phình nhanh bất thường: | Nguyên nhân | Cách kiểm | |---|---| | Bảng tạm không được dọn | | | Binlog tích tụ | expire_logs_days | | Bảng log của ứng dụng | |

⚠ Binlog là thủ phạm hay gặp với MySQL:

SHOW BINARY LOGS;

Read replica dừng hoặc chậm
    → primary giữ binlog chờ replica đọc
        ↓
    Đĩa đầy dần mà không có dữ liệu mới nào

Ba lưu ý về dọn dẹp: | Việc | Chi tiết | |---|---| | OPTIMIZE TABLE thu hồi không gian (InnoDB) | | | Xoá dữ liệu cũ theo lịch nghiệp vụ | | | Chuyển dữ liệu lịch sử sang S3 | |

⚠ Xoá dòng KHÔNG trả lại dung lượng ngay:

DELETE trong InnoDB đánh dấu trang là trống
    → dung lượng vẫn thuộc về bảng
        ↓
    Chỉ tái dùng cho dữ liệu mới của bảng đó
    → muốn trả về hệ thống phải OPTIMIZE TABLE

Ba lưu ý về mở rộng dung lượng: | Lưu ý | Chi tiết | |---|---| | Không ngừng dịch vụ | | | Có thể chậm tạm thời trong lúc mở rộng | | | Chờ tối thiểu 6 giờ giữa hai lần | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo GB CẤP PHÁT, không phải GB dùng | | | Sao lưu vượt dung lượng cấp mới tính phí | | | Snapshot thủ công tính riêng | |

Ba lưu ý về kiến trúc dài hạn: | Cách | Chi tiết | |---|---| | Aurora tự mở rộng lưu trữ tới 128 TB | không cần cấu hình | | Phân vùng bảng theo thời gian | | | Đưa dữ liệu lạnh sang S3, truy vấn bằng Athena | |

⚠ Aurora không có khái niệm cấp phát dung lượng:

RDS: cấp trước, tự mở rộng trong giới hạn
        ↓
Aurora: lưu trữ tự lớn theo dữ liệu
        → trả tiền theo GB thật dùng
        → và tự nhỏ lại khi xoá dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra MaxAllocatedStorage đã đặt | | | Theo dõi FreeStorageSpace | | | Xem sự kiện RDS ghi lần mở rộng | |

aws rds describe-db-instances --db-instance-identifier csdl-cms \
  --query "DBInstances[0].[AllocatedStorage,MaxAllocatedStorage]"

Và một lời khuyên: hãy giữ cảnh báo FreeStorageSpace ngay cả khi đã bật auto scaling. Cơ chế tự mở rộng chỉ hoạt động sau khi dung lượng trống xuống dưới 10% và chờ đủ năm phút, nên một đợt nhập dữ liệu lớn vẫn có thể làm đầy đĩa nhanh hơn tốc độ nó phản ứng.

Đáp án

B — Cấu hình scheduled scaling policy cho Auto Scaling group theo lịch hằng tháng.

Vì sao đúng

Đề cho một dữ kiện quyết định: sự cố xảy ra vào một ngày và giờ CỤ THỂ mỗi tháng.

⚠ Đoán trước được thì chuẩn bị trước — không cần phản ứng:

Chính sách phản ứng (target tracking):
    → chờ CPU tăng → phát hiện → thêm máy → chờ boot
    → người dùng chịu chậm suốt quãng đó
        ↓
Scheduled scaling:
    → máy đã sẵn sàng TRƯỚC khi báo cáo bắt đầu
    → không có khoảng chậm nào

Cấu hình:

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name asg-tai-chinh \
  --scheduled-action-name nang-truoc-bao-cao \
  --recurrence "30 1 28 * *" \
  --time-zone "Asia/Ho_Chi_Minh" \
  --min-size 10 --desired-capacity 12 --max-size 30

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name asg-tai-chinh \
  --scheduled-action-name ha-sau-bao-cao \
  --recurrence "0 6 28 * *" \
  --time-zone "Asia/Ho_Chi_Minh" \
  --min-size 2 --desired-capacity 2 --max-size 30

⚠ --time-zone là tham số phải đặt:

Không đặt: cron chạy theo UTC
    → "1 giờ 30 sáng" thành 8 giờ 30 sáng giờ Việt Nam
        ↓
    Máy được thêm sau khi báo cáo đã chạy xong

⚠ Nâng min-size chứ đừng chỉ đặt desired-capacity:

Chỉ đặt desired: chính sách target tracking
                 có thể thu nhỏ ngay sau đó
        ↓
    Nâng min-size: giữ SÀN trong suốt cửa sổ báo cáo
    → target tracking vẫn thêm được ở trên

Kết hợp cả hai chính sách là cách làm đúng:

Scheduled: đặt SÀN trước giờ cao điểm
Target tracking: lo phần trên nếu tải vượt dự kiến
        ↓
    Vừa không chậm lúc bắt đầu
    vừa co giãn theo tải thật

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Máy sẵn sàng trước khi tải tới | | | Chỉ trả tiền trong cửa sổ báo cáo | | | Không cần ai trực | |

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

• **D. Simple scaling policy theo CPU — đây là phương án gần nhất và cũng thêm máy khi CPU cao, nhưng nó phản ứng SAU khi tải đã tới, và simple scaling còn phải chờ hết cooldown giữa các đợt; người dùng vẫn chịu chậm ở đầu.
• **A. Dùng ElastiCache giảm tải — cache giúp với tải đọc lặp lại; báo cáo cuối tháng thường là truy vấn tổng hợp nặng CPU, không phải đọc lặp.
• **C. Đặt CloudFront trước ALB — CloudFront cache nội dung cho người dùng phân tán; nó không giảm tải tính toán của báo cáo.

Ghi nhớ

⚠ Bốn chính sách mở rộng — chọn theo tính đoán trước được: | Chính sách | Khi nào | |---|---| | Scheduled | biết trước NGÀY GIỜ cụ thể | | Predictive | mẫu lặp lại, để AWS tự học | | Target tracking | tải không đoán trước — mặc định tốt | | Step scaling | cần kiểm soát biên độ theo bậc |

⚠ So sánh với một câu hỏi rất giống:

"Chậm mỗi sáng khi mọi người đăng nhập"
    → mẫu lặp HẰNG NGÀY
    → predictive hoặc scheduled + target tracking
        ↓
"Chậm vào một ngày cụ thể mỗi tháng"
    → sự kiện ĐƠN LẺ, ngày giờ xác định
    → scheduled là câu trả lời rõ ràng nhất

Từ khoá nhận diện:

"specific day and time each month" → scheduled scaling "recurring daily pattern" → predictive scaling "unpredictable traffic" → target tracking "slow at the start of a surge" → warm pool

⚠ Predictive scaling là lựa chọn cho mẫu lặp:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-tai-chinh \
  --policy-name du-doan --policy-type PredictiveScaling \
  --predictive-scaling-configuration '{
    "MetricSpecifications":[{"TargetValue":50,
      "PredefinedMetricPairSpecification":{
        "PredefinedMetricType":"ASGCPUUtilization"}}],
    "Mode":"ForecastAndScale",
    "SchedulingBufferTime":600}'

Học mẫu tải 14 ngày qua
    → tự chuẩn bị máy trước
        ↓
    Nhưng chu kỳ hằng tháng có thể quá thưa
      để nó học được
    → scheduled chắc chắn hơn

Ba lưu ý về cú pháp lịch: | Dạng | Ví dụ | |---|---| | Cron | "30 1 28 * *" — 1h30 ngày 28 hằng tháng | | Một lần | --start-time 2026-09-28T01:30:00Z | | Múi giờ | --time-zone "Asia/Ho_Chi_Minh" |

⚠ Cron của ASG có 5 trường (không có giây):

phút giờ ngày tháng thứ
 30    1   28   *    *

Ba lưu ý về warm pool: | Lưu ý | Chi tiết | |---|---| | Giữ máy đã boot ở trạng thái Stopped | | | Khởi động lại trong vài chục giây | | | Chỉ trả tiền EBS, không trả tiền compute | |

aws autoscaling put-warm-pool \
  --auto-scaling-group-name asg-tai-chinh \
  --min-size 8 --pool-state Stopped

⚠ Warm pool rất hợp khi ứng dụng khởi động chậm:

Ứng dụng mất 5 phút để sẵn sàng
    → scheduled scaling phải chạy sớm 5 phút
        ↓
    Warm pool: máy đã boot xong, chỉ cần start
    → giảm còn vài chục giây

Ba lưu ý về giới hạn: | Lưu ý | Chi tiết | |---|---| | max-size phải đủ lớn | | | Kiểm tra hạn ngạch vCPU của tài khoản | | | Chạm quota = không khởi động đủ máy | |

⚠ Hạn ngạch vCPU là thứ hay chặn đúng lúc cần:

aws service-quotas get-service-quota \
  --service-code ec2 \
  --quota-code L-1216C47A

Tăng từ 4 lên 30 máy
    → chạm quota vCPU On-Demand
        ↓
    Xin tăng TRƯỚC, không phải lúc đang cần

Ba lưu ý về tối ưu chính báo cáo: | Cách | Chi tiết | |---|---| | Chạy báo cáo trên read replica | | | Dùng Redshift hoặc Athena nếu quá nặng | | | Tối ưu truy vấn, thêm index | |

⚠ Mở rộng là cách chữa triệu chứng:

CPU 100% khi chạy báo cáo
    → thêm máy giải quyết được
        ↓
    Nhưng có thể truy vấn thiếu index
    → sửa truy vấn rẻ hơn nhiều so với
      trả tiền 30 máy mỗi tháng

Ba lưu ý về giám sát: | Việc | Cách | |---|---| | Xem lịch sử hoạt động ASG quanh giờ báo cáo | | | Đo thời gian phản hồi trong cửa sổ đó | | | Kiểm tra scheduled action đã chạy | |

aws autoscaling describe-scheduled-actions \
  --auto-scaling-group-name asg-tai-chinh \
  --query "ScheduledUpdateGroupActions[].
    [ScheduledActionName,Recurrence,MinSize,DesiredCapacity]" \
  --output table

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Chỉ trả tiền trong cửa sổ đã nâng | | | Nhớ có hành động HẠ xuống | | | Quên hạ = trả tiền cả tháng | |

⚠ Đây là lỗi vận hành rất tốn kém:

Chỉ tạo scheduled action nâng lên
    → không tạo action hạ xuống
        ↓
    ASG giữ min-size 10 mãi mãi
    → hoá đơn tăng gấp năm lần mà không ai để ý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử một lần với lịch gần | | | Xác nhận cả nâng và hạ đều chạy | | | Đo hiệu năng trong kỳ báo cáo tiếp theo | |

Và một lời khuyên: hãy tạo hành động hạ xuống cùng lúc với hành động nâng lên, đừng để sau. Một scheduled action nâng min-size mà không có cặp đôi hạ xuống sẽ giữ đội máy ở mức cao điểm suốt phần còn lại của tháng — và khoản đó chỉ lộ ra khi có người đọc kỹ hoá đơn.

Đáp án

D — Lập một tổ chức trong AWS Organizations gồm mọi tài khoản và tạo một service control policy (SCP) từ chối việc khởi chạy EC2 instance cỡ lớn.

Vì sao đúng

Đề nêu ba yêu cầu, và SCP là công cụ duy nhất đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Hạn chế trên MỌI tài khoản | SCP áp cho toàn tổ chức | | CÔNG VẬN HÀNH ÍT NHẤT | viết một lần, không đụng từng tài khoản | | Không ai gỡ được | SCP chặn cả root của tài khoản thành viên |

⚠ SCP là cơ chế DUY NHẤT chặn được người dùng root của tài khoản thành viên:

IAM policy: root của tài khoản bỏ qua mọi IAM policy
    → lập trình viên có quyền quản trị gỡ được policy
        ↓
SCP: root cũng không vượt qua được
    → đây mới là hàng rào thật

SCP giới hạn loại instance:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChanMayLon",
   "Effect": "Deny",
   "Action": "ec2:RunInstances",
   "Resource": "arn:aws:ec2:*:*:instance/*",
   "Condition": {"StringNotEquals": {
     "ec2:InstanceType": [
       "t3.micro", "t3.small", "t3.medium",
       "m5.large", "m5.xlarge"]}}}]}

aws organizations create-policy --name chan-may-lon \
  --type SERVICE_CONTROL_POLICY --content file://scp.json

aws organizations attach-policy --policy-id p-abc \
  --target-id ou-phat-trien

⚠ Resource phải là instance/*, không phải *:

Dùng Resource "*" với điều kiện ec2:InstanceType
    → chặn luôn cả việc tạo security group,
      volume, network interface
        ↓
    RunInstances tạo nhiều loại tài nguyên
    → điều kiện chỉ áp cho tài nguyên instance

Bổ sung: chặn cả việc đổi cỡ máy đang chạy:

{"Sid": "ChanDoiCoMayLon",
 "Effect": "Deny",
 "Action": "ec2:ModifyInstanceAttribute",
 "Resource": "*",
 "Condition": {"StringNotEquals": {
   "ec2:InstanceType": ["t3.micro","t3.small","m5.large"]}}}

⚠ Chỉ chặn RunInstances là chưa đủ:

Lập trình viên khởi chạy t3.micro (được phép)
    → rồi ModifyInstanceAttribute lên m5.24xlarge
        ↓
    Phải chặn cả hai hành động

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn ngay từ gốc, không phải phát hiện sau | | | Tài khoản mới tự động được áp | | | Không ai gỡ được từ tài khoản thành viên | |

⚠ Chặn tốt hơn phát hiện:

Cost Explorer, Budgets: cho biết SAU KHI đã tốn tiền
        ↓
SCP: máy lớn không bao giờ được tạo
    → không có chi phí nào để đi tìm

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

• **A. Tạo IAM role ở mỗi tài khoản từ chối khởi chạy máy lớn, cấp cho nhóm lập trình viên — đây là phương án gần nhất và có hiệu lực với người dùng đó, nhưng phải dựng ở từng tài khoản một, và người có quyền quản trị trong tài khoản có thể gỡ ra.
• **C. Tạo service-linked role cho EC2 và gắn policy từ chối — service-linked role là vai trò do chính dịch vụ AWS dùng cho công việc nội bộ; nó không kiểm soát hành động của người dùng.
• **B. Tạo resource-based policy gắn vào Amazon EC2 — EC2 không hỗ trợ resource-based policy; đó là khái niệm của S3, SQS, KMS, Lambda...

Ghi nhớ

⚠ Bốn cơ chế kiểm soát quyền — bảng phải thuộc: | Cơ chế | Phạm vi | Chặn được root | |---|---|---| | SCP | tài khoản trong tổ chức | ✅ | | IAM policy | user, group, role | ❌ | | Permissions boundary | một identity | ❌ | | Resource policy | tài nguyên cụ thể | tuỳ |

Từ khoá nhận diện:

"restrict across all accounts, least overhead" → SCP "limit what a specific user can do" → IAM policy "cap the max permissions a role can be given" → permissions boundary "who can access this bucket/queue" → resource policy

⚠ Ba ngoại lệ SCP không áp: | Ngoại lệ | Chi tiết | |---|---| | Management account | SCP KHÔNG áp cho nó | | Service-linked role | | | Hành động ngoài phạm vi Organizations | |

Đừng chạy tải sản xuất trong management account
    → nó nằm ngoài mọi hàng rào

Ba SCP nên có sớm: | SCP | Chặn gì | |---|---| | Giới hạn loại instance | | | Giới hạn Region được dùng | | | Chặn tắt CloudTrail, Config, GuardDuty | |

⚠ SCP giới hạn Region phải loại trừ dịch vụ toàn cầu:

{"Effect": "Deny",
 "NotAction": ["iam:*","organizations:*","route53:*",
               "cloudfront:*","support:*","budgets:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:RequestedRegion": ["ap-southeast-1"]}}}

Quên loại trừ iam:*
    → không tạo được IAM role nào nữa
    → khoá chính mình

Ba chiến lược viết SCP: | Chiến lược | Cách làm | |---|---| | Deny list | giữ FullAWSAccess, thêm Deny — an toàn hơn | | Allow list | gỡ FullAWSAccess, chỉ Allow thứ cần | | Kết hợp theo OU | mỗi OU một mức chặt |

⚠ Thiết kế OU theo MỨC KIỂM SOÁT:

Root
 ├── OU Sản xuất   → SCP chặt nhất
 ├── OU Phát triển → cho phép nhiều loại máy hơn
 └── OU Sandbox    → lỏng + budget action

Ba lưu ý về kiểm thử: | Lưu ý | Chi tiết | |---|---| | Thử ở OU sandbox trước | | | CloudTrail ghi hành động bị chặn | | | Lỗi hiện là AccessDenied, không nói do SCP | |

⚠ Lỗi do SCP rất khó chẩn đoán:

Thông báo chỉ nói AccessDenied
    → người gỡ lỗi soi IAM policy vốn đã đúng
        ↓
    Luôn kiểm SCP khi IAM có vẻ đúng mà vẫn bị từ chối

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | Kích thước SCP | 5.120 byte | | SCP gắn mỗi thực thể | 5 | | Độ sâu OU | 5 cấp |

Ba biện pháp bổ sung kiểm soát chi phí: | Biện pháp | Việc | |---|---| | AWS Budgets + budget action | phản ứng khi vượt ngân sách | | Config rule desired-instance-type | phát hiện vi phạm | | Compute Optimizer | khuyến nghị đổi cỡ |

⚠ SCP và Budgets bổ sung nhau:

SCP: chặn cứng thứ không bao giờ được dùng
Budget action: phản ứng khi chi tiêu vượt dự kiến
        ↓
    Một cái phòng ngừa, một cái ứng phó

Ba lưu ý về Organizations: | Lưu ý | Chi tiết | |---|---| | Phải bật ALL features, không chỉ consolidated billing | | | SCP chỉ dùng được khi bật all features | | | Control Tower dựng sẵn nhiều guardrail | |

aws organizations describe-organization \
  --query "Organization.FeatureSet"

Ba lưu ý về ngoại lệ: | Cách | Chi tiết | |---|---| | Loại trừ vai trò cụ thể bằng điều kiện | | | Đặt tài khoản đặc biệt ở OU riêng | | | Ghi tài liệu vì sao có ngoại lệ | |

{"Condition": {
  "StringNotEquals": {"ec2:InstanceType": [...]},
  "ArnNotLike": {"aws:PrincipalArn":
    "arn:aws:iam::*:role/VaiTroHPCDacBiet"}}}

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử khởi chạy m5.24xlarge | phải bị từ chối | | Thử khởi chạy t3.micro | phải được | | Kiểm tra management account không bị áp | |

Và một lời khuyên: hãy chặn cả ec2:ModifyInstanceAttribute cùng với ec2:RunInstances. Chỉ chặn lúc tạo là để hở một đường vòng hiển nhiên — khởi chạy một máy nhỏ được phép rồi lập tức đổi nó thành máy lớn nhất trong danh mục.

Đáp án

D — Khởi chạy EC2 instance trong một cluster placement group trong một Availability Zone.

Vì sao đúng

Đề nêu hai yêu cầu về mạng giữa các máy, và cluster placement group được thiết kế đúng cho chúng: | Yêu cầu | Cách đáp ứng | |---|---| | Độ trễ THẤP giữa các instance | máy đặt gần nhau về mặt vật lý | | Thông lượng mạng CAO | tới 100 Gbps giữa các máy trong group |

⚠ Cluster placement group đặt máy trên cùng một rack hoặc rất gần:

Không có placement group:
    → AWS đặt máy rải khắp AZ
    → mỗi bước nhảy mạng thêm độ trễ
        ↓
Cluster placement group:
    → máy nằm gần nhau nhất có thể
    → độ trễ giữa các node xuống mức micro giây

Tạo và dùng:

aws ec2 create-placement-group --group-name cum-hpc \
  --strategy cluster

aws ec2 run-instances --image-id ami-abc \
  --instance-type c6in.16xlarge --count 8 \
  --placement GroupName=cum-hpc \
  --subnet-id subnet-a \
  --network-interfaces '[{"DeviceIndex":0,
    "InterfaceType":"efa","SubnetId":"subnet-a",
    "Groups":["sg-hpc"]}]'

⚠ EFA là bổ sung quan trọng cho HPC:

Elastic Fabric Adapter
    → bỏ qua kernel của hệ điều hành
    → giao tiếp trực tiếp giữa các tiến trình
        ↓
    Độ trễ thấp hơn nhiều so với ENA thường
    → bắt buộc cho MPI và tải HPC thật

Ba chiến lược placement group: | Chiến lược | Đặt máy | Dùng cho | |---|---|---| | Cluster | gần nhau, MỘT AZ | HPC, độ trễ thấp | | Spread | tách xa nhau, phần cứng khác nhau | tính sẵn sàng tối đa | | Partition | nhóm trên rack khác nhau | HDFS, Cassandra |

⚠ Đây là đánh đổi có chủ ý:

Cluster: hiệu năng mạng cao nhất
         → nhưng MỘT AZ, một sự cố hạ tầng ảnh hưởng tất cả
        ↓
Spread: sẵn sàng cao nhất
        → nhưng máy xa nhau, độ trễ cao hơn
        ↓
    Đề hỏi HIỆU NĂNG → chọn cluster

Ba lưu ý khi khởi chạy: | Lưu ý | Chi tiết | |---|---| | Khởi chạy TẤT CẢ máy trong một lệnh | | | Dùng cùng một loại instance | | | Có thể gặp lỗi thiếu năng lực | |

⚠ Khởi chạy từng máy một dễ thất bại:

Khởi chạy 8 máy riêng lẻ
    → sau vài máy, rack đó hết chỗ
    → InsufficientInstanceCapacity
        ↓
    Một lệnh cho cả 8 máy
    → AWS tìm chỗ đủ cho tất cả

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ giữa node thấp nhất có thể | | | Thông lượng tới 100 Gbps | | | Không tính phí thêm | |

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

• **B. Spread placement group trong một AZ — đây là phương án gần nhất và cũng là placement group, nhưng spread cố tình đặt máy XA NHAU trên phần cứng khác nhau để tăng tính sẵn sàng; điều đó làm tăng độ trễ, ngược yêu cầu.
• **C. ASG trải nhiều Availability Zone — trải nhiều AZ tăng tính sẵn sàng nhưng tăng độ trễ giữa các máy (AZ cách nhau vài km) và phát sinh phí truyền dữ liệu liên AZ.
• **A. ASG ở hai Region với NLB phía trước — độ trễ xuyên Region là hàng chục tới hàng trăm mili giây, tệ nhất trong bốn phương án cho HPC.

Ghi nhớ

⚠ Ba chiến lược placement group — bảng phải thuộc: | Chiến lược | Mục tiêu | Giới hạn | |---|---|---| | Cluster | hiệu năng mạng | một AZ | | Spread | tính sẵn sàng | 7 instance mỗi AZ | | Partition | cô lập theo phân vùng | 7 phân vùng mỗi AZ |

Từ khoá nhận diện:

"low latency, high throughput between instances, HPC" → cluster placement group "critical instances must not share hardware" → spread "HDFS, Cassandra, Kafka" → partition "survive AZ failure" → nhiều AZ (không phải placement group)

⚠ Giới hạn 7 instance mỗi AZ của spread là con số phải nhớ:

Spread placement group: tối đa 7 máy mỗi AZ
    → 3 AZ = tối đa 21 máy
        ↓
    Cần nhiều hơn thì phải dùng nhiều group

Ba lưu ý về EFA: | Lưu ý | Chi tiết | |---|---| | Chỉ một số loại instance hỗ trợ | | | Phải trong cùng cluster placement group | | | Cần security group cho phép mọi lưu lượng nội bộ | |

aws ec2 authorize-security-group-ingress --group-id sg-hpc \
  --protocol -1 --source-group sg-hpc

⚠ EFA yêu cầu security group tự tham chiếu chính nó với MỌI giao thức — đây là điều kiện hay bị bỏ sót.

Ba lưu ý về enhanced networking: | Loại | Chi tiết | |---|---| | ENA | mặc định trên máy đời mới, tới 100 Gbps | | EFA | ENA + kênh bỏ qua kernel cho HPC | | Intel 82599 VF | cũ, tới 10 Gbps |

Ba lưu ý về loại instance cho HPC: | Họ | Đặc điểm | |---|---| | hpc6a, hpc7g | chuyên HPC, mạng 100-200 Gbps | | c6in, c7gn | tối ưu mạng | | p4d, p5 | GPU cho ML |

⚠ Họ hpc có giá mạng tốt hơn:

Instance họ hpc6a/hpc7g
    → không tính phí truyền dữ liệu trong cùng AZ
    → thiết kế riêng cho cụm HPC

Ba lưu ý về lưu trữ cho HPC: | Lựa chọn | Khi nào | |---|---| | Instance store NVMe | scratch cục bộ, IOPS cao nhất | | FSx for Lustre | hệ thống tệp dùng chung, thông lượng cao | | EFS | dùng chung nhưng chậm hơn |

⚠ FSx for Lustre liên kết được với S3:

aws fsx create-file-system --file-system-type LUSTRE \
  --storage-capacity 12000 --subnet-ids subnet-a \
  --lustre-configuration 'DeploymentType=SCRATCH_2,
    DataRepositoryConfiguration={
      ImportPath=s3://du-lieu-dau-vao,
      ExportPath=s3://ket-qua}'

Dữ liệu nằm ở S3, Lustre nạp theo nhu cầu
    → kết quả tự đẩy ngược về S3

Ba lưu ý về rủi ro của một AZ: | Lưu ý | Chi tiết | |---|---| | Cluster placement group buộc một AZ | | | AZ hỏng = mất cả cụm | | | HPC thường chấp nhận vì job chạy rồi kết thúc | |

⚠ Đây là đánh đổi phải nói rõ với bên nghiệp vụ:

Job HPC chạy vài giờ rồi xong
    → mất cụm giữa chừng thì chạy lại
    → chấp nhận được
        ↓
    Dịch vụ chạy liên tục 24/7
    → không nên dùng cluster placement group

Ba lưu ý về checkpoint: | Lưu ý | Chi tiết | |---|---| | Job dài phải có checkpoint | | | Lưu checkpoint ra S3 hoặc FSx | | | Cho phép dùng Spot instance | |

Ba lưu ý về AWS ParallelCluster: | Lưu ý | Chi tiết | |---|---| | Công cụ dựng cụm HPC tự động | | | Tích hợp Slurm | | | Tự cấu hình placement group và EFA | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ giữa các node | | | Kiểm tra máy nằm trong placement group | | | Chạy benchmark MPI | |

aws ec2 describe-instances --instance-ids i-abc \
  --query "Reservations[0].Instances[0].Placement"

Và một lời khuyên: hãy khởi chạy toàn bộ cụm trong một lệnh duy nhất. Cluster placement group đòi hỏi năng lực ở một vị trí vật lý hẹp, và việc thêm dần từng máy sẽ va vào lỗi thiếu năng lực đúng lúc bạn đã dựng xong nửa cụm.

Đáp án

A và B — Bật xác thực đa yếu tố (MFA) cho người dùng root, và bảo đảm root dùng mật khẩu mạnh.

Vì sao đúng

Đề hỏi cách bảo vệ tài khoản root của một tài khoản AWS mới, và đây là hai bước đầu tiên trong mọi hướng dẫn bảo mật của AWS.

⚠ Root là danh tính KHÔNG giới hạn được:

Root có toàn quyền tuyệt đối
    → IAM policy KHÔNG áp cho root
    → chỉ SCP giới hạn được, và chỉ với tài khoản thành viên
        ↓
    Mất root = mất cả tài khoản AWS

Bật MFA:

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name root-mfa \
  --outfile qr.png --bootstrap-method QRCodePNG

aws iam enable-mfa-device --user-name root \
  --serial-number <arn-thiet-bi> \
  --authentication-code1 123456 --authentication-code2 654321

⚠ Với tài khoản quan trọng, dùng khoá phần cứng: | Loại MFA | Mức bảo vệ | |---|---| | Khoá bảo mật FIDO2 (YubiKey) | cao nhất — chống lừa đảo | | Ứng dụng TOTP trên điện thoại | tốt | | SMS | không còn được khuyến nghị |

Khoá FIDO2 kiểm tra tên miền
    → trang lừa đảo không lấy được mã
        ↓
    TOTP: người dùng có thể bị lừa nhập mã
      vào trang giả

Mật khẩu mạnh cho root:

Không dùng lại từ nơi khác
Dài, sinh ngẫu nhiên
Lưu trong trình quản lý mật khẩu của tổ chức
        ↓
    Root không dùng hằng ngày
    → không cần dễ nhớ

Ba việc phải làm ngay sau đó: | Việc | Chi tiết | |---|---| | XOÁ mọi access key của root | | | Tạo IAM user hoặc SSO cho công việc hằng ngày | | | Cảnh báo khi root đăng nhập | |

⚠ Root KHÔNG BAO GIỜ được có access key:

aws iam delete-access-key --user-name root --access-key-id <id>

Access key của root = toàn quyền không thể thu hồi
    → rò rỉ một lần là mất cả tài khoản
        ↓
    AWS khuyến nghị: xoá hết, không tạo lại bao giờ

Cảnh báo khi root đăng nhập:

{"source": ["aws.signin"],
 "detail-type": ["AWS Console Sign In via CloudTrail"],
 "detail": {"userIdentity": {"type": ["Root"]}}}

aws events put-rule --name canh-bao-root-dang-nhap \
  --event-pattern file://mau.json
aws events put-targets --rule canh-bao-root-dang-nhap \
  --targets 'Id=1,Arn=<arn-sns>'

⚠ Root chỉ nên dùng cho vài việc bắt buộc: | Việc | Chi tiết | |---|---| | Đổi email hoặc tên tài khoản | | | Đóng tài khoản AWS | | | Đổi gói hỗ trợ | | | Khôi phục quyền khi IAM bị khoá | | | Đăng ký một số dịch vụ đặc biệt | |

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

• **C. Thêm root vào một nhóm có quyền quản trị — đây là phương án gần nhất về mặt nghe như đang quản lý quyền, nhưng root không thuộc nhóm IAM nào; nó đã có toàn quyền và IAM policy không áp cho nó.
• **D. Lưu access key của root trong bucket S3 mã hoá — sai từ gốc: root không nên có access key nào cả; mã hoá chỗ lưu không làm cho việc tồn tại khoá đó bớt nguy hiểm.
• **E. Xoá tài khoản root — không xoá được; root là danh tính gắn liền với chính tài khoản AWS.

Ghi nhớ

⚠ Sáu bước bảo vệ root — bảng phải thuộc: | Bước | Chi tiết | |---|---| | 1. Bật MFA (ưu tiên khoá phần cứng) | | | 2. Mật khẩu mạnh, sinh ngẫu nhiên | | | 3. XOÁ mọi access key của root | | | 4. Không dùng root cho việc hằng ngày | | | 5. Cảnh báo khi root đăng nhập | | | 6. Dùng email của nhóm, không của cá nhân | |

⚠ Bước 6 hay bị bỏ qua nhưng rất quan trọng:

Email root là của một nhân viên
    → người đó nghỉ việc
        ↓
    Không ai đặt lại được mật khẩu root
    → phải liên hệ AWS Support, quy trình dài
        ↓
    Dùng danh sách thư nội bộ như
    aws-root@congty.vn

Từ khoá nhận diện:

"secure the root user" → MFA + mật khẩu mạnh + xoá access key "restrict what member accounts can do" → SCP "daily administrative work" → IAM Identity Center (SSO) "programmatic access" → IAM role, không phải access key

⚠ SCP giới hạn được root của tài khoản THÀNH VIÊN:

Root của management account: KHÔNG giới hạn được
Root của tài khoản thành viên: SCP áp được
        ↓
    Đây là lý do nữa để dùng Organizations

Ba lưu ý về IAM Identity Center: | Lưu ý | Chi tiết | |---|---| | Thay cho IAM user cho con người | | | Credential tạm, tự hết hạn | | | Quản lý tập trung cho nhiều tài khoản | |

⚠ IAM user cho con người là cách cũ:

IAM user: mật khẩu và access key tồn tại lâu dài
    → phải tự xoay, dễ bị rò rỉ
        ↓
IAM Identity Center: đăng nhập một lần
    → nhận credential tạm cho từng tài khoản
    → hết hạn tự động

Ba lưu ý về access key nói chung: | Lưu ý | Chi tiết | |---|---| | EC2 dùng instance profile, không dùng key | | | Lambda dùng execution role | | | Máy ngoài AWS dùng IAM Roles Anywhere | |

⚠ Access key tĩnh gần như luôn tránh được:

Ứng dụng trong AWS → IAM role
CI/CD trên GitHub  → OIDC federation
Máy tại chỗ        → IAM Roles Anywhere
        ↓
    Rất ít trường hợp thật sự cần access key

Ba lưu ý về khôi phục tài khoản: | Lưu ý | Chi tiết | |---|---| | Giữ số điện thoại liên hệ cập nhật | | | Lưu thiết bị MFA ở nơi an toàn | | | Có quy trình khi mất thiết bị MFA | |

⚠ Mất cả mật khẩu và MFA của root là tình huống rất khó:

AWS Support có quy trình khôi phục
    → nhưng cần xác minh danh tính, mất nhiều ngày
        ↓
    Lưu thiết bị MFA dự phòng trong két
    → AWS cho phép tối đa 8 thiết bị MFA cho root

Ba lưu ý về giám sát: | Việc | Cách | |---|---| | Config rule root-account-mfa-enabled | | | Config rule iam-root-access-key-check | | | Cảnh báo mọi hoạt động của root | |

Ba lưu ý về báo cáo: | Công cụ | Việc | |---|---| | Credential report | trạng thái mọi credential | | IAM Access Analyzer | quyền thừa | | Security Hub | tổng hợp phát hiện |

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text \
  | base64 -d | head -2

Ba lưu ý về nhiều tài khoản: | Lưu ý | Chi tiết | |---|---| | Mỗi tài khoản có root riêng | | | Phải bảo vệ TẤT CẢ, không chỉ management | | | Control Tower kiểm tra tự động | |

⚠ Tài khoản thành viên tạo qua Organizations có root không mật khẩu:

Root tồn tại nhưng chưa đặt mật khẩu
    → ai đó có thể dùng "quên mật khẩu"
      với email của tài khoản đó
        ↓
    Kiểm soát chặt hộp thư đó
    → hoặc đặt mật khẩu và bật MFA cho mọi root

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy credential report | | | Kiểm tra Config rule tuân thủ | | | Thử đăng nhập root, xác nhận cảnh báo chạy | |

Và một lời khuyên: hãy đặt email root là một danh sách thư của nhóm chứ đừng là hộp thư cá nhân. Ngày người giữ hộp thư đó rời công ty, khả năng khôi phục quyền truy cập tài khoản AWS sẽ ra đi cùng họ — và đó là loại sự cố không có giải pháp kỹ thuật nào.