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

Đáp án

D — Chuyển website sang Amazon S3 và cấu hình một CloudFront distribution cho bucket đó.

Vì sao đúng

Đề nêu ba dữ kiện, và cặp S3 + CloudFront là kiến trúc chuẩn: | Dữ kiện | Ý nghĩa | |---|---| | Website phục vụ nội dung TĨNH | không cần máy chủ ứng dụng nào | | Lưu lượng đang TĂNG | cần thứ mở rộng tốt | | Tối thiểu CHI PHÍ | bỏ EC2 và ALB |

Chi phí đang tiêu vào đâu:

Hiện tại:  ALB (~16 USD/tháng tối thiểu)
         + nhiều EC2 chạy 24/7
         + phí truyền dữ liệu
             ↓
Sau khi chuyển:
    S3: vài cent mỗi GB lưu trữ
    CloudFront: theo lượng truyền thật
    → KHÔNG có máy chủ nào, KHÔNG có ALB

Vì sao nội dung tĩnh không cần EC2:

Nội dung tĩnh = HTML, CSS, JS, ảnh — không có mã chạy phía máy chủ
    → EC2 chỉ đang làm việc trả tệp
    → S3 làm việc đó rẻ hơn nhiều và không bao giờ hết chỗ

Triển khai:

aws s3 sync ./website s3://trang-web-cong-ty/   --cache-control "public, max-age=86400"

aws cloudfront create-distribution --distribution-config file://cau-hinh.json

Cấu hình OAC để bucket vẫn riêng tư:

aws cloudfront create-origin-access-control   --origin-access-control-config   'Name=oac-trang-web,OriginAccessControlOriginType=s3,
   SigningBehavior=always,SigningProtocol=sigv4'

Bucket policy chỉ cho CloudFront:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"Service": "cloudfront.amazonaws.com"},
   "Action": "s3:GetObject",
   "Resource": "arn:aws:s3:::trang-web-cong-ty/*",
   "Condition": {"StringEquals":
     {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123ABC"}}}]}

Vì sao CloudFront còn làm giảm chi phí thêm:

⚠ Data transfer từ S3 SANG CloudFront: MIỄN PHÍ
    → phục vụ qua CloudFront thường RẺ HƠN
      phục vụ thẳng từ S3
        ↓
    Cộng thêm: cache ở edge giảm số request tới S3

Ba lợi ích khác: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp toàn cầu | | | HTTPS miễn phí qua ACM | | | Gắn được WAF | |

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

• **B. Chuyển sang AWS Amplify và cấu hình một ALB trỏ tới Amplify — Amplify Hosting là lựa chọn hợp lý cho website tĩnh (nó dùng CloudFront bên dưới), nhưng vế thứ hai vô nghĩa: không có cách nào để ALB trỏ tới một website Amplify, và giữ ALB lại chính là giữ khoản chi phí cần bỏ.
• **C. Chuyển sang AWS Amplify và cấu hình EC2 để cache website — cùng vấn đề: giữ EC2 lại là ngược hẳn mục tiêu giảm chi phí, và Amplify vốn đã có CDN riêng.
• **A. Chuyển sang S3 và cấu hình ElastiCache cho bucket — mô tả một thứ không tồn tại: ElastiCache là bộ nhớ đệm trong VPC cho ứng dụng (Redis/Memcached), không đặt trước S3 được và không phục vụ HTTP.

Ghi nhớ

Ba cách phục vụ website tĩnh — bảng phải thuộc: | Cách | Chi phí | HTTPS | |---|---|---| | S3 + CloudFront | thấp nhất | ✅ qua ACM ← câu này | | AWS Amplify Hosting | thấp, có CI/CD sẵn | ✅ | | S3 website endpoint trực tiếp | thấp | ❌ không HTTPS | | EC2 + ALB | cao nhất | ✅ |

Từ khoá nhận diện:

"static content" + "minimize cost" → S3 + CloudFront "static site with Git-based CI/CD" → Amplify "dynamic content, server-side code" → cần EC2, Lambda hoặc container

⚠ Hai kiểu endpoint của S3 — hay bị lẫn: | Kiểu | Đặc điểm | |---|---| | REST API endpoint (s3.amazonaws.com) | hỗ trợ HTTPS, dùng với OAC | | Website endpoint (s3-website-...) | CHỈ HTTP, có index và error document |

Dùng CloudFront với S3 → chọn REST endpoint + OAC
    → bucket riêng tư hoàn toàn
        ↓
    Website endpoint bắt buộc bucket phải công khai

⚠ OAC thay thế OAI: | | OAC (Origin Access Control) | OAI (Origin Access Identity) | |---|---|---| | Trạng thái | hiện hành (từ 08/2022) | cũ, AWS không khuyến nghị | | SSE-KMS | ✅ | ❌ | | Vùng mới | ✅ | ❌ | | Tải lên qua CloudFront | ✅ | ❌ |

Ba việc cần cấu hình cho website tĩnh trên CloudFront: | Việc | Chi tiết | |---|---| | DefaultRootObject: index.html | | | Custom error response cho SPA | 403/404 → /index.html | | Alternate domain name + chứng chỉ ACM | |

Custom error response cho ứng dụng một trang:

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

Người dùng vào /san-pham/123 trực tiếp
    → S3 không có object đó → 403
    → CloudFront trả index.html, router phía client xử lý

⚠ Chứng chỉ ACM cho CloudFront phải ở us-east-1 — bất kể website ở vùng nào.

Ba việc cần làm khi triển khai bản mới: | Việc | Chi tiết | |---|---| | Đặt tên tệp có mã băm nội dung | app.a3f9c1.js | | index.html cache ngắn hoặc không cache | | | Invalidation chỉ khi cần | có phí sau 1.000 đường dẫn/tháng |

Chiến lược cache tối ưu:

# Tài nguyên có mã băm: cache vĩnh viễn
aws s3 sync ./build/static s3://trang-web/static/   --cache-control "public, max-age=31536000, immutable"

# index.html: luôn kiểm tra lại
aws s3 cp ./build/index.html s3://trang-web/   --cache-control "public, max-age=0, must-revalidate"

Không cần invalidation nào cả
    → tệp mới có tên mới
    → index.html luôn mới

Ba cách tối ưu chi phí CloudFront: | Cách | Chi tiết | |---|---| | Chọn price class hợp phân bố khách | | | Bật nén (gzip, Brotli) | | | TTL dài cho nội dung tĩnh | |

Ba lỗi làm hỏng tỷ lệ cache hit: | Lỗi | Hậu quả | |---|---| | Forward mọi cookie | mỗi khách một bản cache | | Forward mọi query string | ?utm_source= tách cache | | TTL quá ngắn | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access trên bucket | | | ViewerProtocolPolicy: redirect-to-https | | | Thêm response header policy (CSP, HSTS) | |

Ba việc kiểm chứng sau khi chuyển: | Việc | Cách | |---|---| | Kiểm tra bucket KHÔNG truy cập trực tiếp được | | | Xem tỷ lệ cache hit sau vài ngày | | | So hoá đơn tháng trước và sau | |

Và một lời khuyên: hãy đặt chiến lược cache trước khi chuyển, đừng dựa vào invalidation. Invalidation là công cụ chữa cháy có phí và có độ trễ; đặt tên tệp theo mã băm nội dung khiến mỗi lần triển khai tự nhiên là một tệp mới — và bạn không bao giờ phải giải thích vì sao có người vẫn thấy giao diện cũ.

Đáp án

C — Dùng Kinesis Data Streams nạp dữ liệu, AWS Lambda xử lý, lưu vào Amazon OpenSearch Service để tìm kiếm và phân tích, và Amazon Managed Grafana dựng bảng điều khiển.

Vì sao đúng

Đề nêu bốn năng lực cần có, và mỗi thành phần đảm nhận một: | Năng lực | Dịch vụ | |---|---| | Nạp dữ liệu theo LUỒNG | Kinesis Data Streams | | Xử lý GẦN THỜI GIAN THỰC | Lambda | | Lưu trữ và TÌM KIẾM | OpenSearch Service | | Trực quan hoá | Managed Grafana |

Vì sao OpenSearch là mảnh ghép quyết định:

Đề nói rõ: "data ingestion, storage, SEARCH, and visualization"
        ↓
    Từ "search" là từ khoá
    → OpenSearch là dịch vụ TÌM KIẾM của AWS
    → Redshift và DynamoDB không phải công cụ tìm kiếm toàn văn

Và "near real-time" định hình cả chuỗi:

Kinesis: nạp liên tục, độ trễ dưới một giây
Lambda:  xử lý ngay khi có bản ghi
OpenSearch: index xong là tìm được ngay
        ↓
    Toàn chuỗi tính bằng giây

Luồng đầy đủ:

Thiết bị phát video
    │ PutRecord
    ▼
Kinesis Data Streams  (giữ 24 giờ tới 365 ngày)
    │ event source mapping
    ▼
AWS Lambda  (làm giàu, chuẩn hoá)
    ▼
Amazon OpenSearch Service  (index, tìm kiếm, tổng hợp)
    ▼
Amazon Managed Grafana  (bảng điều khiển)

Cấu hình Kinesis:

aws kinesis create-stream --stream-name luong-xem-video   --stream-mode-details StreamMode=ON_DEMAND

Nối Lambda vào luồng:

aws lambda create-event-source-mapping   --function-name xu-ly-su-kien-xem   --event-source-arn arn:aws:kinesis:...:stream/luong-xem-video   --starting-position LATEST --batch-size 100   --maximum-batching-window-in-seconds 5

Ba lợi ích của kiến trúc này: | Lợi ích | Chi tiết | |---|---| | Toàn dịch vụ AWS gốc được quản lý | đúng yêu cầu "AWS-native" | | Mỗi tầng co giãn độc lập | | | Kinesis giữ dữ liệu — đọc lại được | |

Vế cuối là ưu thế của Kinesis so với SQS:

Kinesis giữ dữ liệu suốt thời gian retention
    → nhiều consumer đọc CÙNG dữ liệu độc lập
    → thêm một consumer mới đọc lại từ đầu được
        ↓
    Với nền tảng phân tích, đây là tính chất quan trọng

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

• **B. Dùng Amazon MSK nạp dữ liệu, lưu vào Redshift, dùng Redshift Spectrum và QuickSight — đây là phương án gần nhất và hoàn toàn khả thi, nhưng nó yếu ở vế tìm kiếm: Redshift là kho dữ liệu phân tích cột, tốt cho tổng hợp và báo cáo, không phải công cụ tìm kiếm toàn văn. MSK cũng nhiều việc vận hành hơn Kinesis.
• **A. Dùng EC2 nạp dữ liệu vào S3, Glue catalog, Athena tìm kiếm, QuickSight trực quan — EC2 tự nạp dữ liệu là công vận hành cao nhất, và Athena truy vấn theo lô với độ trễ hàng giây tới phút, không đạt "near real-time insights".
• **D. Dùng EMR xử lý luồng, lưu DynamoDB, dùng truy vấn DynamoDB để tìm kiếm và CloudWatch dựng bảng điều khiển — DynamoDB không hỗ trợ tìm kiếm toàn văn hay tổng hợp linh hoạt, và CloudWatch dashboard không phải công cụ trực quan hoá dữ liệu nghiệp vụ.

Ghi nhớ

Bốn tầng của một nền tảng phân tích luồng — bảng phải thuộc: | Tầng | Lựa chọn AWS | |---|---| | Nạp | Kinesis Data Streams, Firehose, MSK | | Xử lý | Lambda, Kinesis Data Analytics (Managed Flink), EMR | | Lưu và truy vấn | OpenSearch, S3+Athena, Redshift, DynamoDB | | Trực quan | Managed Grafana, QuickSight, OpenSearch Dashboards |

Từ khoá nhận diện:

"search" + "near real-time" + "logs/events" → OpenSearch Service "BI dashboards, business reports" → QuickSight "operational metrics dashboards" → Managed Grafana "data warehouse, complex SQL joins" → Redshift

Ba dịch vụ nạp dữ liệu — bảng phân biệt: | Dịch vụ | Quản lý | Đặc điểm | |---|---|---| | Kinesis Data Streams | shard hoặc on-demand | giữ dữ liệu, nhiều consumer | | Kinesis Data Firehose | không có gì | ghi thẳng vào đích, không đọc lại | | Amazon MSK | cụm Kafka | tương thích Kafka |

Hai chế độ dung lượng của Kinesis: | Chế độ | Đặc điểm | |---|---| | Provisioned | tự quản shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn, không quản shard |

Mỗi shard: 1 MB/s hoặc 1.000 bản ghi/giây ghi vào
            2 MB/s đọc ra
        ↓
    On-demand tự lo — ít việc hơn

Ba đặc điểm của partition key: | Đặc điểm | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | | | Thứ tự đảm bảo TRONG một shard | | | Key phân bố kém gây hot shard | |

Với dữ liệu xem video, key nên là id thiết bị hoặc id phiên:

kinesis.put_record(StreamName='luong-xem-video',
    Data=json.dumps(su_kien),
    PartitionKey=su_kien['id_thiet_bi'])

Mọi sự kiện của một thiết bị vào cùng shard
    → giữ đúng thứ tự cho thiết bị đó
    → và phân tán đều giữa các shard

Ba đặc điểm của OpenSearch Service: | Đặc điểm | Chi tiết | |---|---| | Tìm kiếm toàn văn và tổng hợp | | | OpenSearch Dashboards có sẵn | | | Có bản Serverless | không quản lý node |

OpenSearch Serverless đáng cân nhắc:

Không phải chọn số node, loại instance, số shard
    → tự co giãn theo tải
        ↓
    Ít công vận hành hơn cụm truyền thống

Ba lưu ý về vòng đời dữ liệu trong OpenSearch: | Lưu ý | Chi tiết | |---|---| | Index State Management tự chuyển tầng | | | UltraWarm rẻ hơn cho dữ liệu cũ | | | Cold storage cho dữ liệu rất cũ | |

Nóng (SSD)  → 7 ngày
UltraWarm   → 30 ngày (rẻ hơn ~90%)
Cold        → lâu hơn
        ↓
    Không đặt vòng đời là chi phí tăng vô hạn

Ba lưu ý về Lambda đọc Kinesis: | Lưu ý | Chi tiết | |---|---| | Một Lambda mỗi shard (mặc định) | | | ParallelizationFactor tăng song song | tới 10 | | Lỗi chặn cả shard nếu không xử lý | |

Vế thứ ba là bẫy vận hành lớn:

Một bản ghi gây lỗi Lambda
    → Lambda thử lại mãi
    → shard đó KHÔNG tiến lên được
        ↓
    Cấu hình:
    → `BisectBatchOnFunctionError`: chia đôi lô để tìm bản ghi lỗi
    → `MaximumRetryAttempts`: giới hạn số lần
    → `DestinationConfig`: gửi bản ghi lỗi sang SQS

aws lambda update-event-source-mapping --uuid <uuid>   --maximum-retry-attempts 3 --bisect-batch-on-function-error   --destination-config '{"OnFailure":{"Destination":"<arn-sqs-dlq>"}}'

Ba lưu ý về Managed Grafana: | Lưu ý | Chi tiết | |---|---| | Nối được OpenSearch, CloudWatch, Prometheus, Redshift | | | Xác thực qua IAM Identity Center hoặc SAML | | | Tính phí theo người dùng đang hoạt động | |

Grafana và QuickSight — chọn cái nào: | | Managed Grafana | QuickSight | |---|---|---| | Hợp với | số liệu vận hành, thời gian thực | báo cáo nghiệp vụ, BI | | Nguồn dữ liệu | nhiều loại, kể cả ngoài AWS | chủ yếu AWS | | Người dùng | kỹ sư | người dùng nghiệp vụ |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Kinesis on-demand đắt hơn provisioned khi tải ổn định | | | OpenSearch tính theo giờ node | dùng UltraWarm | | Grafana tính theo người dùng | |

Và một lời khuyên: hãy đặt chính sách vòng đời index cho OpenSearch ngay từ ngày đầu. Dữ liệu sự kiện xem video tích tụ rất nhanh, và một cụm OpenSearch không có Index State Management sẽ lớn dần cho tới khi hết dung lượng — thời điểm phát hiện thường là lúc việc ghi bắt đầu thất bại, chứ không phải lúc hoá đơn tăng.

Đáp án

B — Dùng DynamoDB global tables để tự nhân bản dữ liệu qua nhiều vùng, và triển khai bảng ở chế độ on-demand.

Vì sao đúng

Đề nêu bốn yêu cầu, và global tables + on-demand khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Người dùng toàn cầu, độ trễ thấp | bảng ở nhiều vùng, đọc ghi tại chỗ | | Tính sẵn sàng cao | global tables đa vùng, đa AZ | | Chịu được sự cố CẢ VÙNG | vùng khác vẫn phục vụ | | Tải KHÔNG ĐOÁN TRƯỚC, tiết kiệm nhất | on-demand — trả theo request thật |

Global tables hoạt động thế nào:

Ghi vào bảng ở vùng Singapore
    → tự nhân bản sang Frankfurt và Virginia
    → thường dưới 1 giây
        ↓
    Mỗi vùng ĐỌC VÀ GHI được — active-active thật

Vì sao on-demand cho tải không đoán được:

Provisioned:  phải khai trước RCU/WCU
    → khai thấp → throttling khi đợt tăng
    → khai cao → trả tiền cho năng lực không dùng

On-demand:    trả theo số request THẬT
    → đợt tăng đột ngột được phục vụ ngay
        ↓
    Đúng nghĩa "handle unpredictable workloads cost-effectively"

Tạo global table:

aws dynamodb create-table --table-name ho-so-nguoi-dung   --attribute-definitions AttributeName=id_nguoi_dung,AttributeType=S   --key-schema AttributeName=id_nguoi_dung,KeyType=HASH   --billing-mode PAY_PER_REQUEST   --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws dynamodb update-table --table-name ho-so-nguoi-dung   --replica-updates '[{"Create":{"RegionName":"eu-central-1"}},
                      {"Create":{"RegionName":"us-east-1"}}]'

⚠ Hai điều kiện bắt buộc: | Điều kiện | Chi tiết | |---|---| | DynamoDB Streams phải bật | NEW_AND_OLD_IMAGES | | Tên bảng giống nhau ở mọi vùng | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đọc và ghi tại vùng gần người dùng | độ trễ vài mili giây | | Mất một vùng không ảnh hưởng vùng khác | | | AWS lo toàn bộ việc nhân bản | |

Và mô hình dữ liệu của đề rất hợp DynamoDB:

Hồ sơ người dùng, danh sách bạn bè, tương tác bài đăng
    → truy cập theo KHOÁ (id người dùng, id bài đăng)
    → không cần JOIN phức tạp
        ↓
    Đúng mô hình DynamoDB được thiết kế cho

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

• **A. Bảng ở một vùng với provisioned capacity, dùng DynamoDB Streams tự nhân bản sang vùng phụ để dự phòng — đây là phương án gần nhất và về nguyên lý là cách global tables hoạt động, nhưng nó bắt bạn tự dựng lại thứ AWS đã cung cấp: phải viết Lambda xử lý stream, tự lo thứ tự, tự lo lỗi. Và provisioned capacity mâu thuẫn với "unpredictable workloads".
• **D. Dùng DAX giảm độ trễ đọc, bảng ở một vùng, nhân bản thủ công sang vùng khác — DAX là cache trong một VPC, một vùng, không giúp gì cho người dùng ở châu lục khác. Và nhân bản thủ công là công vận hành cao nhất.
• **C. Dùng S3 lưu dữ liệu người dùng với Cross-Region Replication và Lambda cập nhật — sai loại kho dữ liệu: S3 là object store, không phục vụ được truy vấn theo khoá với độ trễ mili giây cho ứng dụng mạng xã hội.

Ghi nhớ

Ba đặc điểm của DynamoDB global tables — bảng phải thuộc: | Đặc điểm | Chi tiết | |---|---| | Active-active đa vùng | mọi vùng đọc VÀ ghi | | Nhân bản thường dưới 1 giây | | | Xung đột giải bằng LAST WRITER WINS | |

⚠ Vế thứ ba là điều phải hiểu rõ:

Hai người ở hai vùng cùng sửa một item
    → bản ghi sau (theo timestamp) THẮNG
    → bản kia bị mất, KHÔNG có cảnh báo
        ↓
    Không phù hợp với dữ liệu cần nhất quán mạnh
    → ví dụ số dư tài khoản

Từ khoá nhận diện:

"global users" + "multi-Region" + "NoSQL" → DynamoDB global tables "unpredictable workload" + "cost-effective" → on-demand capacity "single-digit millisecond reads" trong một vùng → DAX "relational, transactions" → không phải DynamoDB

Hai chế độ dung lượng — bảng phân biệt: | | On-demand | Provisioned | |---|---|---| | Trả tiền | theo request | theo năng lực khai | | Co giãn | tức thì | qua auto scaling (chậm hơn) | | Hợp với | tải biến động, mới ra mắt | tải ổn định, dự đoán được | | Chi phí khi tải đều | cao hơn | thấp hơn (có reserved) |

Đổi qua lại được, nhưng giới hạn số lần mỗi 24 giờ

Ba lưu ý khi thiết kế khoá: | Lưu ý | Chi tiết | |---|---| | Partition key phân bố đều | tránh hot partition | | Sort key cho truy vấn theo dải | | | GSI cho mẫu truy cập khác | |

Với mạng xã hội, mẫu thường dùng:

PK = "NGUOIDUNG#123", SK = "HOSO"           → hồ sơ
PK = "NGUOIDUNG#123", SK = "BANBE#456"      → danh sách bạn
PK = "BAIDANG#789",   SK = "TUONGTAC#123"   → tương tác
        ↓
    Một bảng phục vụ nhiều thực thể (single-table design)

Ba đặc điểm của DynamoDB Streams: | Đặc điểm | Chi tiết | |---|---| | Ghi lại mọi thay đổi item | | | Giữ 24 giờ | | | Là nền tảng của global tables | |

Ba lựa chọn StreamViewType: | Loại | Nội dung | |---|---| | KEYS_ONLY | chỉ khoá | | NEW_IMAGE | item sau khi đổi | | NEW_AND_OLD_IMAGES | cả hai — bắt buộc cho global tables |

Ba cách tối ưu chi phí DynamoDB: | Cách | Chi tiết | |---|---| | Chọn đúng chế độ dung lượng | | | TTL xoá dữ liệu cũ MIỄN PHÍ | | | Standard-IA table class cho dữ liệu ít đọc | |

Table class Standard-IA đáng biết:

aws dynamodb update-table --table-name luu-tru-cu   --table-class STANDARD_INFREQUENT_ACCESS

Rẻ hơn ~60% tiền lưu trữ
    → nhưng phí đọc ghi cao hơn ~25%
        ↓
    Hợp với dữ liệu lớn mà ít truy cập

Ba lưu ý về chi phí global tables: | Khoản | Chi tiết | |---|---| | Mỗi vùng tính phí như một bảng riêng | | | Ghi nhân bản tính là "replicated write" | | | Phí truyền dữ liệu giữa vùng | |

Vế thứ hai đáng lưu ý:

Một lần ghi ở vùng A với 3 vùng
    → 1 write ở A + 2 replicated write
        ↓
    Chi phí ghi tăng theo số vùng
    → chỉ thêm vùng thực sự có người dùng

Ba lưu ý về tính sẵn sàng: | Lưu ý | Chi tiết | |---|---| | Ứng dụng phải biết chuyển vùng | Route 53 hoặc Global Accelerator | | SDK có endpoint theo vùng | | | Kiểm thử mất một vùng | |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Point-in-Time Recovery bật riêng mỗi vùng | | | PITR khôi phục về bất kỳ giây nào trong 35 ngày | | | On-demand backup giữ vô thời hạn | |

aws dynamodb update-continuous-backups --table-name ho-so-nguoi-dung   --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicationLatency | độ trễ nhân bản | | ThrottledRequests | có bị giới hạn không | | ConsumedReadCapacityUnits | |

Và một lời khuyên: hãy thiết kế mô hình dữ liệu sao cho hai vùng hiếm khi ghi cùng một item. Global tables giải xung đột bằng "bản ghi sau thắng", nghĩa là một lần cập nhật hợp lệ có thể biến mất không dấu vết — và không có metric nào đếm số lần điều đó xảy ra với bạn.

Đáp án

C — Bật DynamoDB Streams trên bảng, dùng trigger đẩy sang một SNS topic duy nhất, và cho bốn đội đăng ký topic đó.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này thoả cả ba với công ít nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Gửi cảnh báo mỗi khi có sự kiện giao dịch mới | Streams bắt mọi thay đổi item | | Cho quản lý của BỐN đội | SNS fan-out — một topic, bốn subscriber | | KHÔNG ảnh hưởng hiệu năng ứng dụng hiện tại | Streams đọc bất đồng bộ, không đụng bảng |

Vế thứ ba là ràng buộc quyết định:

DynamoDB Streams là bản ghi thay đổi ĐỘC LẬP
    → đọc từ stream KHÔNG tiêu tốn read capacity của bảng
    → ứng dụng hiện tại không biết có ai đang đọc
        ↓
    Sửa ứng dụng để tự gửi thông báo thì ngược lại:
    → thêm độ trễ vào chính đường ghi
    → SNS lỗi có thể làm hỏng cả giao dịch

Vế thứ hai giải thích vì sao MỘT topic chứ không phải bốn:

SNS vốn là mô hình PUB/SUB fan-out
    → một thông điệp → mọi subscriber đều nhận
        ↓
    Một topic, bốn subscription
    → thêm đội thứ năm: thêm một subscription, không sửa mã

Cấu hình:

aws dynamodb update-table --table-name su-kien-giao-dich   --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE

aws sns create-topic --name canh-bao-giao-dich

aws sns subscribe --topic-arn <arn-topic> --protocol email   --notification-endpoint quanly.doi1@vidu.com

Lambda nối stream với SNS:

import json, boto3, os
sns = boto3.client('sns')

def handler(event, context):
    for ban_ghi in event['Records']:
        if ban_ghi['eventName'] != 'INSERT':
            continue
        item = ban_ghi['dynamodb']['NewImage']
        sns.publish(
            TopicArn=os.environ['ARN_TOPIC'],
            Subject='Su kien giao dich moi',
            Message=json.dumps({
                'ma': item['ma_giao_dich']['S'],
                'gia_tri': item['gia_tri']['N']}, ensure_ascii=False))

Nối Lambda vào stream:

aws lambda create-event-source-mapping   --function-name gui-canh-bao   --event-source-arn <arn-stream>   --starting-position LATEST --batch-size 10   --maximum-batching-window-in-seconds 5

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không sửa ứng dụng hiện tại | | | Không bỏ sót sự kiện nào | Streams bắt mọi ghi | | Thêm đội mới không cần triển khai lại | |

Vế thứ hai đáng nhấn mạnh:

Nếu ứng dụng tự gửi thông báo:
    → ghi vào DynamoDB thành công nhưng gửi SNS lỗi
    → sự kiện đó mất thông báo vĩnh viễn
        ↓
    Streams đảm bảo mọi thay đổi đều xuất hiện

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

• **A. Cho ứng dụng hiện tại publish vào BỐN SNS topic, mỗi đội một topic — đây là phương án gần nhất và thực sự gửi được cảnh báo, nhưng nó vi phạm yêu cầu "không ảnh hưởng hiệu năng": bốn lần gọi API đồng bộ thêm vào đường ghi. Và bốn topic là hiểu sai mô hình fan-out — một topic phục vụ được cả bốn.
• **D. Tạo thuộc tính cờ và cron job Scan bảng mỗi phút — Scan toàn bảng mỗi phút tiêu tốn read capacity rất lớn, đúng thứ đề yêu cầu tránh. Và độ trễ tới một phút.
• **B. Ghi bằng DynamoDB transaction và "cấu hình transaction để thông báo cho các đội" — mô tả một tính năng không tồn tại: transaction đảm bảo tính nguyên tử của nhiều thao tác ghi, nó không có cơ chế thông báo nào.

Ghi nhớ

Ba dịch vụ nhắn tin — bảng phải thuộc: | Dịch vụ | Mô hình | Dùng khi | |---|---|---| | Amazon SNS | pub/sub, ĐẨY, fan-out | nhiều bên cùng nhận ← câu này | | Amazon SQS | hàng đợi, KÉO | một consumer xử lý một việc | | EventBridge | định tuyến sự kiện | lọc theo nội dung, nhiều nguồn |

Từ khoá nhận diện:

"notify multiple teams" + "least overhead" → SNS một topic, nhiều subscription "react to database changes" + "no impact on app" → DynamoDB Streams "decouple, buffer work" → SQS

Ba đặc điểm của DynamoDB Streams: | Đặc điểm | Chi tiết | |---|---| | Ghi lại mọi thay đổi item theo thứ tự | trong một partition | | Giữ 24 giờ | | | KHÔNG tiêu read capacity của bảng | |

Bốn giá trị StreamViewType: | Giá trị | Nội dung | |---|---| | KEYS_ONLY | chỉ khoá | | NEW_IMAGE | item sau khi đổi ← đủ cho câu này | | OLD_IMAGE | item trước khi đổi | | NEW_AND_OLD_IMAGES | cả hai — bắt buộc cho global tables |

Ba loại eventName trong stream: | Loại | Nghĩa | |---|---| | INSERT | item mới ← đề cần | | MODIFY | item bị sửa | | REMOVE | item bị xoá (kể cả do TTL) |

Lọc theo eventName ngay ở event source mapping:

aws lambda create-event-source-mapping --function-name gui-canh-bao   --event-source-arn <arn-stream> --starting-position LATEST   --filter-criteria '{"Filters":[{"Pattern":"{\"eventName\":[\"INSERT\"]}"}]}'

Lọc ở tầng mapping → Lambda không bị gọi cho MODIFY và REMOVE
    → giảm số lần gọi, giảm chi phí

Ba giao thức subscription của SNS: | Giao thức | Dùng cho | |---|---| | Email / Email-JSON | người đọc ← câu này | | SQS | hệ thống khác xử lý bền | | Lambda, HTTPS, SMS | |

Mẫu fan-out SNS + SQS đáng biết:

SNS topic
  ├── SQS hệ thống A
  ├── SQS hệ thống B
  └── email quản lý
        ↓
    Mỗi hệ thống có hàng đợi riêng, xử lý theo nhịp riêng
    → và không mất thông điệp khi hệ thống đó chết

Ba lưu ý về lọc thông điệp SNS: | Lưu ý | Chi tiết | |---|---| | Subscription filter policy lọc theo thuộc tính | | | Mỗi đội chỉ nhận loại sự kiện họ quan tâm | | | Lọc ở SNS rẻ hơn lọc ở consumer | |

aws sns set-subscription-attributes --subscription-arn <arn-sub>   --attribute-name FilterPolicy   --attribute-value '{"loai_giao_dich":["mua","ban"]}'

Ba lưu ý về Lambda đọc DynamoDB Streams: | Lưu ý | Chi tiết | |---|---| | Một Lambda mỗi shard | | | Lỗi chặn cả shard nếu không cấu hình | | | Dùng BisectBatchOnFunctionError và DLQ | |

Vế thứ hai là bẫy vận hành:

Một bản ghi gây lỗi
    → Lambda thử lại mãi
    → shard đó đứng, cảnh báo ngừng gửi
        ↓
    Đặt MaximumRetryAttempts và destination cho bản ghi lỗi

Ba lưu ý về độ tin cậy: | Lưu ý | Chi tiết | |---|---| | Streams giao ÍT NHẤT MỘT LẦN | có thể trùng | | Email trùng ít gây hại, nhưng nên biết | | | Đặt DLQ cho Lambda | |

Ba lựa chọn thay thế: | Lựa chọn | Khi nào | |---|---| | EventBridge Pipes | nối Streams tới đích mà KHÔNG viết Lambda | | Kinesis Data Streams cho DynamoDB | cần giữ lâu hơn 24 giờ | | SNS trực tiếp từ ứng dụng | khi chấp nhận sửa mã |

EventBridge Pipes đáng biết — còn ít việc hơn:

aws pipes create-pipe --name ong-canh-bao   --source <arn-stream> --target <arn-topic>   --role-arn <arn-role>   --source-parameters '{"DynamoDBStreamParameters":{"StartingPosition":"LATEST"}}'

Nối thẳng Streams → SNS, không cần viết Lambda nào
    → công vận hành còn thấp hơn
    → nhưng đề đưa phương án có Lambda nên đó là đáp án

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Streams tính theo số lần đọc bản ghi | | | Lambda tính theo GB-giây | | | SNS email: 1.000 thư đầu miễn phí mỗi tháng | |

Và một lời khuyên: hãy cân nhắc EventBridge Pipes trước khi viết Lambda cho việc nối hai dịch vụ. Rất nhiều hàm Lambda trong hệ thống thực chất chỉ đọc từ một nơi và ghi sang nơi khác — và mỗi hàm như vậy là mã phải kiểm thử, vá lỗi và giám sát mãi mãi.

Đáp án

C — Cấu hình bảng định tuyến của subnet riêng tư để đẩy lưu lượng ra AWS Network Firewall, rồi cấu hình domain list rule group.

Vì sao đúng

Đề nêu bốn yêu cầu, và Network Firewall là dịch vụ duy nhất làm được: | Yêu cầu | Cách đáp ứng | |---|---| | EC2 ở subnet riêng tư, dữ liệu nhạy cảm | | | **Cần tải bản cập nhật từ URL bên thứ ba | domain list cho phép tên miền cụ thể | | MỌI lưu lượng Internet khác phải bị chặn | chính sách mặc định từ chối | | Không có ngoại lệ | lọc ở tầng mạng, không phụ thuộc ứng dụng |

Vì sao security group không làm được:

Security group lọc theo IP và CỔNG
    → KHÔNG lọc được theo TÊN MIỀN
        ↓
    Kho phần mềm dùng CDN với IP thay đổi liên tục
    → không thể liệt kê IP

Đây là điểm loại phương án A.

Network Firewall lọc theo tên miền như thế nào:

Nó đọc:
    → trường SNI trong bắt tay TLS (HTTPS)
    → header Host (HTTP)
        ↓
    So với danh sách tên miền cho phép
    → không khớp thì chặn kết nối

Kiến trúc định tuyến:

Subnet riêng tư (EC2)
    │ route 0.0.0.0/0 → VPC endpoint của Firewall
    ▼
Subnet firewall (Network Firewall endpoint)
    │ route 0.0.0.0/0 → NAT Gateway
    ▼
NAT Gateway ──▶ Internet Gateway ──▶ kho phần mềm

Tạo rule group cho phép tên miền:

aws network-firewall create-rule-group --rule-group-name cho-phep-kho-pm   --type STATEFUL --capacity 100   --rule-group '{"RulesSource":{"RulesSourceList":{
    "Targets":["repo.nhacungcap.com",".ubuntu.com",".amazonaws.com"],
    "TargetTypes":["TLS_SNI","HTTP_HOST"],
    "GeneratedRulesType":"ALLOWLIST"}}}'

Và chính sách mặc định từ chối:

aws network-firewall create-firewall-policy   --firewall-policy-name chinh-sach-chat   --firewall-policy '{
    "StatefulRuleGroupReferences":[{"ResourceArn":"<arn-rule-group>"}],
    "StatelessDefaultActions":["aws:forward_to_sfe"],
    "StatelessFragmentDefaultActions":["aws:forward_to_sfe"],
    "StatefulEngineOptions":{"RuleOrder":"STRICT_ORDER"},
    "StatefulDefaultActions":["aws:drop_established"]}'

aws:drop_established là dòng đáp ứng "no exceptions":

Mặc định DROP mọi kết nối không khớp luật cho phép
    → chỉ tên miền trong danh sách đi được
        ↓
    Không có "trừ trường hợp" nào

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lọc theo tên miền, không phải IP | | | Ghi log mọi kết nối bị chặn | | | Áp cho MỌI instance, không phụ thuộc cấu hình máy | |

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

• **A. Đặt quy tắc outbound của security group theo URL — security group KHÔNG hiểu URL hay tên miền, chỉ hiểu IP/CIDR/security group và cổng. Đây là mô tả một khả năng không tồn tại.
• **B. Đặt ALB trước EC2 và dùng listener rule theo URL cho lưu lượng RA — hiểu sai chiều của load balancer: ALB xử lý lưu lượng đi VÀO, không định tuyến lưu lượng đi ra Internet. Target group không phải đường ra.
• **D. Tạo WAF web ACL lọc theo dải IP nguồn và đích — WAF bảo vệ lưu lượng ĐI VÀO CloudFront, ALB, API Gateway. Nó không lọc lưu lượng đi ra từ EC2.

Ghi nhớ

Bốn công cụ lọc mạng của AWS — bảng phải thuộc: | Công cụ | Lọc theo | Chiều | |---|---|---| | Security Group | IP, cổng, SG — stateful | vào và ra | | Network ACL | IP, cổng — stateless | vào và ra (subnet) | | AWS Network Firewall | TÊN MIỀN, giao thức, nội dung gói | cả hai ← câu này | | AWS WAF | HTTP request (SQLi, XSS, rate) | chỉ ĐI VÀO |

Từ khoá nhận diện:

"allow specific URLs/domains outbound", "block all other internet" → Network Firewall domain list "protect web app from SQL injection" → WAF "allow port 443 from a security group" → security group "deny a specific IP" → NACL

Ba loại rule group của Network Firewall: | Loại | Lọc theo | |---|---| | Stateless | 5-tuple, nhanh, không nhớ trạng thái | | Stateful — domain list | tên miền (SNI, Host) ← câu này | | Stateful — Suricata rules | luật IDS/IPS đầy đủ |

Ba yêu cầu triển khai: | Yêu cầu | Chi tiết | |---|---| | Subnet RIÊNG cho firewall endpoint | mỗi AZ một cái | | Sửa bảng định tuyến để lưu lượng đi qua | | | Endpoint ở mỗi AZ có tải | |

Vế thứ hai là chỗ hay làm sai nhất:

Dựng firewall nhưng không sửa route table
    → lưu lượng vẫn đi thẳng ra NAT
    → firewall không thấy gói nào
        ↓
    Mọi thứ VẪN CHẠY — không có lỗi
    → và tưởng rằng đã được bảo vệ

Ba bảng định tuyến cần sửa: | Bảng | Route | |---|---| | Subnet riêng tư | 0.0.0.0/0 → firewall endpoint | | Subnet firewall | 0.0.0.0/0 → NAT Gateway | | Subnet công khai (nếu cần đối xứng) | CIDR nội bộ → firewall endpoint |

Ba lưu ý về domain list: | Lưu ý | Chi tiết | |---|---| | Dấu chấm đầu (.vidu.com) khớp cả tên miền con | | | Chỉ đọc được SNI — TLS 1.3 với ECH sẽ che SNI | | | Kết hợp với TLS inspection nếu cần sâu hơn | |

Vế thứ hai là hạn chế cần biết:

Encrypted Client Hello (ECH) mã hoá cả SNI
    → firewall không đọc được tên miền
        ↓
    Hiện chưa phổ biến, nhưng đang lan dần
    → theo dõi và cân nhắc TLS inspection

Ba lưu ý về logging: | Loại log | Nội dung | |---|---| | Alert log | gói khớp luật (bị chặn hoặc cho phép) | | Flow log | mọi luồng đi qua | | TLS log | chi tiết bắt tay TLS |

aws network-firewall update-logging-configuration   --firewall-arn <arn> --logging-configuration '{"LogDestinationConfigs":[
    {"LogType":"ALERT","LogDestinationType":"CloudWatchLogs",
     "LogDestination":{"logGroup":"/aws/nf/canh-bao"}}]}'

Alert log là công cụ chính để tinh chỉnh danh sách:

Bật ở chế độ cho phép rộng trước, đọc log
    → thấy ứng dụng thực sự gọi những tên miền nào
    → rồi mới siết lại
        ↓
    Siết ngay từ đầu sẽ chặn nhầm những thứ bạn không biết là cần

Ba tên miền hay bị quên trong danh sách cho phép: | Tên miền | Vì sao cần | |---|---| | .amazonaws.com | gọi API AWS, agent SSM, CloudWatch | | Kho gói của hệ điều hành | .amazonlinux.com, .ubuntu.com | | Máy chủ NTP và DNS | |

Ba lựa chọn thay thế cho một số dịch vụ: | Thay thế | Chi tiết | |---|---| | VPC endpoint cho dịch vụ AWS | không cần ra Internet chút nào | | Route 53 Resolver DNS Firewall | chặn ở tầng DNS, rẻ hơn | | Proxy tự dựng (Squid) | công vận hành cao |

DNS Firewall là bổ sung tốt:

DNS Firewall chặn việc PHÂN GIẢI tên miền
Network Firewall chặn KẾT NỐI
        ↓
    Dùng cả hai là phòng thủ nhiều lớp

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí theo GIỜ mỗi endpoint | nhân số AZ | | Phí theo GB xử lý | | | Đắt hơn NAT Gateway đáng kể | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử curl tới tên miền được phép | phải thành công | | Thử curl tới tên miền khác | phải bị chặn | | Kiểm tra alert log ghi lại lần chặn | |

Và một lời khuyên: hãy chạy firewall ở chế độ chỉ ghi log ít nhất một tuần trước khi bật chặn. Danh sách tên miền mà một máy chủ thực sự cần luôn dài hơn bạn nghĩ — agent giám sát, kiểm tra chứng chỉ, đồng bộ thời gian — và phát hiện chúng qua log thì tốt hơn nhiều so với phát hiện qua một sự cố sản xuất.

Đáp án

B — Bật RDS Proxy cho CSDL RDS.

Vì sao đúng

Đề nêu ba dữ kiện, và RDS Proxy giải quyết đúng nguyên nhân gốc: | Dữ kiện | Ý nghĩa | |---|---| | API Gateway + Lambda + RDS PostgreSQL | Lambda co giãn rất nhanh | | Lỗi do TIMEOUT KẾT NỐI CSDL khi cao điểm | CSDL cạn kết nối | | Sửa mã ÍT NHẤT | Proxy nằm ngoài, chỉ đổi endpoint |

Vấn đề thật sự:

Lambda co giãn tới hàng nghìn lần gọi song song
    → mỗi lần gọi mở một kết nối tới PostgreSQL
        ↓
    PostgreSQL có max_connections hữu hạn
    → mỗi kết nối tốn RAM đáng kể trên máy chủ
        ↓
    Vượt giới hạn → kết nối mới bị từ chối hoặc treo
    → đó chính là "connection timeout"

RDS Proxy làm gì:

Lambda ──▶ RDS Proxy ──▶ RDS PostgreSQL
              │
              └─ giữ một POOL kết nối dùng chung
                  ↓
    1.000 Lambda → proxy → có thể chỉ 50 kết nối thật
    → CSDL không bao giờ bị ngập

Bật proxy:

aws rds create-db-proxy --db-proxy-name proxy-ung-dung   --engine-family POSTGRESQL   --auth '[{"AuthScheme":"SECRETS","SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]'   --role-arn <arn-role>   --vpc-subnet-ids subnet-a subnet-b   --vpc-security-group-ids sg-proxy --require-tls

aws rds register-db-proxy-targets --db-proxy-name proxy-ung-dung   --db-instance-identifiers csdl-ung-dung

Và Lambda chỉ đổi một chuỗi:

# Trước
HOST = 'csdl-ung-dung.abc123.ap-southeast-1.rds.amazonaws.com'
# Sau
HOST = 'proxy-ung-dung.proxy-abc123.ap-southeast-1.rds.amazonaws.com'

Đây chính là nghĩa của "least amount of code changes".

Ba lợi ích khác của RDS Proxy: | Lợi ích | Chi tiết | |---|---| | Rút ngắn thời gian chuyển đổi dự phòng tới 66% | proxy giữ kết nối, chuyển đích | | Xác thực bằng IAM | không có mật khẩu trong Lambda | | Tích hợp Secrets Manager | xoay mật khẩu không đứt kết nối |

Vế đầu là lợi ích đáng giá:

Không có proxy: failover → mọi kết nối đứt → ứng dụng lỗi cho tới khi thử lại
Có proxy:       proxy giữ kết nối phía client, chuyển kết nối phía CSDL
        ↓
    Ứng dụng ít cảm nhận được failover hơn

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

• **C. Đổi sang instance class lớn hơn để có nhiều kết nối hơn — đây là phương án gần nhất và thực sự tăng max_connections, nhưng nó chỉ đẩy trần lên cao hơn một chút: Lambda vẫn co giãn nhanh hơn khả năng chịu kết nối của bất kỳ máy nào, và mỗi kết nối vẫn tiêu tốn RAM đáng lẽ dùng cho buffer cache. Đắt hơn mà vẫn gãy khi tải cao hơn nữa.
• **D. Giảm concurrency của Lambda — làm được và đôi khi cần, nhưng nó hy sinh khả năng phục vụ: request vượt giới hạn bị throttle, khách hàng vẫn nhận lỗi — chỉ đổi từ lỗi CSDL sang lỗi Lambda.
• **A. Đổi sang DynamoDB on-demand — giải quyết triệt để vấn đề kết nối (DynamoDB dùng HTTP, không giữ kết nối), nhưng đây là viết lại toàn bộ tầng dữ liệu: từ SQL sang NoSQL, mất JOIN và giao dịch quan hệ. Ngược hẳn "least amount of code changes".

Ghi nhớ

Vấn đề kinh điển: Lambda + CSDL quan hệ

Lambda co giãn nhanh hơn khả năng chịu kết nối của CSDL. Lời giải chuẩn: RDS Proxy.

Từ khoá nhận diện:

"Lambda" + "database connection timeout/exhaustion" → RDS Proxy "no connections at all" → Aurora Data API "no password in code" → IAM database authentication

Ba đặc điểm của RDS Proxy: | Đặc điểm | Chi tiết | |---|---| | Gộp và tái sử dụng kết nối | | | Hỗ trợ RDS MySQL, PostgreSQL, MariaDB, Aurora | | | Bắt buộc dùng Secrets Manager cho credential | |

Ba khái niệm của proxy: | Khái niệm | Nghĩa | |---|---| | MaxConnectionsPercent | % max_connections proxy được dùng | | MaxIdleConnectionsPercent | kết nối giữ sẵn | | ConnectionBorrowTimeout | chờ bao lâu khi pool cạn |

aws rds modify-db-proxy-target-group --db-proxy-name proxy-ung-dung   --target-group-name default   --connection-pool-config '{"MaxConnectionsPercent":90,
    "MaxIdleConnectionsPercent":50,"ConnectionBorrowTimeout":120}'

⚠ Pinning là chi tiết quan trọng làm giảm hiệu quả proxy:

Một số thao tác buộc proxy GHIM một kết nối cho một client
    → kết nối đó không dùng chung được nữa
        ↓
    Nguyên nhân thường gặp:
    → dùng temporary table
    → SET biến phiên
    → prepared statement (một số trường hợp)
    → giao dịch mở lâu

Xem có bị pinning không:

Bật log của proxy → tìm dòng "pinning"
    → CloudWatch metric DatabaseConnectionsCurrentlySessionPinned
        ↓
    Tỷ lệ pin cao nghĩa là proxy gần như vô dụng

Ba cách giảm pinning: | Cách | Chi tiết | |---|---| | Tránh temporary table | dùng CTE hoặc subquery | | Không đặt biến phiên tuỳ tiện | | | Đóng giao dịch nhanh | |

Ba lựa chọn khác cho cùng vấn đề: | Lựa chọn | Đặc điểm | |---|---| | RDS Proxy | ít sửa mã nhất ← câu này | | Aurora Data API | HTTP, không giữ kết nối — phải sửa mã | | Reserved concurrency cho Lambda | giới hạn tải, hy sinh throughput |

Aurora Data API đáng biết:

rds = boto3.client('rds-data')
rds.execute_statement(
    resourceArn='arn:aws:rds:...:cluster:cum-aurora',
    secretArn='arn:aws:secretsmanager:...:secret:db-abc',
    database='ungdung', sql='SELECT * FROM don_hang WHERE id = :id',
    parameters=[{'name':'id','value':{'longValue':123}}])

Không có kết nối nào để cạn
    → nhưng chỉ dùng được với Aurora
    → và phải viết lại tầng truy cập dữ liệu

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Proxy nằm trong VPC, cùng subnet với CSDL | | | Lambda phải ở trong VPC để gọi proxy | | | Security group của proxy cho phép từ Lambda | |

Ba lưu ý về xác thực: | Lưu ý | Chi tiết | |---|---| | Credential lưu trong Secrets Manager | | | IAMAuth=REQUIRED bỏ hẳn mật khẩu ở client | | | Role của Lambda cần rds-db:connect | |

import boto3
token = boto3.client('rds').generate_db_auth_token(
    DBHostname=HOST, Port=5432, DBUsername='app_user')
ket_noi(host=HOST, user='app_user', password=token, sslmode='require')

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | DatabaseConnections | số kết nối thật tới CSDL | | ClientConnections | số kết nối từ Lambda | | DatabaseConnectionsCurrentlySessionPinned | hiệu quả gộp |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo vCPU của instance CSDL | | | Không có phí theo request | | | Thường rẻ hơn nâng cấp instance | |

Ba lưu ý về khởi động lạnh Lambda trong VPC: | Lưu ý | Chi tiết | |---|---| | Hyperplane ENI đã giảm mạnh độ trễ | không còn 10 giây như trước | | Provisioned concurrency nếu cần ổn định | | | Tái dùng kết nối ngoài handler | |

import psycopg2, os
# Tạo NGOÀI handler → dùng lại giữa các lần gọi cùng container
ket_noi = psycopg2.connect(host=os.environ['PROXY_HOST'], ...)

def handler(event, context):
    with ket_noi.cursor() as cur:
        cur.execute('SELECT ...')

Và một lời khuyên: hãy theo dõi metric session pinning ngay sau khi bật RDS Proxy. Proxy có thể được cấu hình hoàn hảo mà vẫn không giảm được kết nối nào, chỉ vì mã ứng dụng dùng temporary table trong mỗi truy vấn — và bạn sẽ kết luận nhầm rằng proxy không có tác dụng.

Đáp án

D — Tạo AMI từ EC2 đang chạy các tác vụ, rồi tạo Auto Scaling group dùng AMI đó để chạy nhiều bản sao của máy.

Vì sao đúng theo đáp án nguồn

Lập luận của đáp án dựa trên hai dữ kiện: | Dữ kiện | Lập luận | |---|---| | Các tác vụ viết bằng NHIỀU NGÔN NGỮ khác nhau | không đóng gói lại được dễ dàng | | Lo ngại về hiệu năng và khả năng mở rộng | nhân bản máy là cách nhanh nhất |

Lập luận cho D:

Các tác vụ do nhiều đội viết, không chung ngôn ngữ
    → chúng đã CHẠY ĐƯỢC trên chính máy đó
        ↓
    Chụp AMI = giữ nguyên toàn bộ môi trường
    → không phải container hoá, không phải viết lại
    → không phải cài đặt runtime cho từng ngôn ngữ

Và vì sao Lambda bị loại:

Tác vụ chạy 1 GIỜ
    → Lambda giới hạn 15 PHÚT
        ↓
    Phương án C sai vì lý do kỹ thuật rõ ràng

Tạo AMI và ASG:

aws ec2 create-image --instance-id i-abc123   --name "may-chay-tac-vu" --no-reboot

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

aws autoscaling create-auto-scaling-group --auto-scaling-group-name asg-tac-vu   --launch-template LaunchTemplateName=mau-tac-vu,Version='$Latest'   --min-size 1 --max-size 5 --desired-capacity 1   --vpc-zone-identifier "subnet-a,subnet-b"

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

• **B. Dùng AWS Batch chạy các tác vụ dưới dạng job, lập lịch bằng EventBridge — đây là phương án gần nhất và là dịch vụ được thiết kế chính xác cho loại bài toán này (xem phần ghi chú bên dưới). Lập luận loại nó là: mỗi tác vụ phải được đóng gói thành ảnh container, mà các tác vụ viết bằng nhiều ngôn ngữ khác nhau nên đó là công việc đáng kể ban đầu.
• **C. Chuyển các tác vụ thành Lambda function — sai vì giới hạn kỹ thuật cứng: tác vụ chạy 1 giờ, còn Lambda tối đa 15 phút. Đây là lý do loại rõ ràng và không tranh cãi.
• **A. Chuyển máy thành container và dùng AWS App Runner — sai vai trò dịch vụ: App Runner phục vụ ứng dụng web và API luôn chạy, không phải job chạy theo lịch rồi kết thúc.

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

Đáp án nguồn chọn D, nhưng cần nói thẳng: B là câu trả lời đúng hơn theo tiêu chí "least operational overhead" mà chính đề đưa ra, và đây là điều người học nên biết.

Ba vấn đề cụ thể của phương án D: | Vấn đề | Chi tiết | |---|---| | AMI + ASG KHÔNG lập lịch gì cả | đề nói tác vụ chạy theo lịch, mà ASG không có cơ chế xếp lịch job | | Nhân bản máy nghĩa là chạy TRÙNG tác vụ | 3 bản sao của cùng một máy sẽ chạy cùng một cron 3 lần | | Không giải quyết "khả năng mở rộng" theo nghĩa job | thêm máy không có nghĩa là job được phân phối |

Vế thứ hai là lỗ hổng nghiêm trọng nhất:

Máy gốc có crontab chạy 5 tác vụ mỗi đêm
    → chụp AMI, tạo 3 instance từ AMI đó
        ↓
    Mỗi máy đều có crontab đó
    → mỗi tác vụ chạy 3 LẦN, song song
    → nếu tác vụ ghi vào CSDL thì dữ liệu hỏng

Trong khi AWS Batch giải quyết đúng cả ba: | Vấn đề | AWS Batch | |---|---| | Lập lịch | EventBridge Scheduler kích hoạt job | | Chạy trùng | mỗi job chạy đúng một lần | | Mở rộng | tự cấp máy theo hàng đợi job |

aws batch submit-job --job-name tac-vu-dem   --job-queue hang-doi-tac-vu --job-definition dinh-nghia-tac-vu:1

Về lập luận "nhiều ngôn ngữ nên khó container hoá": đó là công một lần, và Docker vốn được tạo ra chính để đóng gói mọi runtime. Đổi lại là bỏ hẳn việc quản lý máy chủ, quản lý cron, và quản lý việc chạy trùng.

Ba lựa chọn đúng cho job chạy theo lịch trên AWS: | Lựa chọn | Khi nào | |---|---| | AWS Batch | job chạy lâu, cần xếp hàng và ưu tiên | | ECS scheduled task (Fargate) | job đơn giản, chạy theo cron | | Step Functions + Fargate | quy trình nhiều bước |

ECS scheduled task cũng rất hợp:

aws events put-rule --name chay-tac-vu-dem   --schedule-expression "cron(0 2 * * ? *)"

aws events put-targets --rule chay-tac-vu-dem --targets '[{
  "Id":"1","Arn":"<arn-cum-ecs>","RoleArn":"<arn-role>",
  "EcsParameters":{"TaskDefinitionArn":"<arn-task-def>",
    "LaunchType":"FARGATE","TaskCount":1,
    "NetworkConfiguration":{"awsvpcConfiguration":{
      "Subnets":["subnet-a"],"AssignPublicIp":"DISABLED"}}}}]'

Ba giới hạn thời gian phải thuộc — đây là phần chắc chắn đúng của câu hỏi: | Dịch vụ | Thời gian tối đa | |---|---| | AWS Lambda | 15 phút | | ECS / Fargate task | không giới hạn | | AWS Batch job | không giới hạn | | Step Functions Standard | 1 năm |

Từ khoá nhận diện:

"scheduled batch jobs", "different languages", "hours" → AWS Batch "under 15 minutes", "event-driven" → Lambda "always-running web app/API" → App Runner, ECS service

Ba thành phần của AWS Batch: | Thành phần | Việc | |---|---| | Compute environment | máy chạy job (EC2, Fargate, Spot) | | Job queue | hàng đợi có ưu tiên | | Job definition | ảnh container, vCPU, RAM, biến môi trường |

Ba lợi ích của Batch: | Lợi ích | Chi tiết | |---|---| | Tự cấp và thu hồi máy theo hàng đợi | không trả tiền lúc rảnh | | Hỗ trợ Spot, giảm chi phí lớn | | | Job phụ thuộc, mảng job, thử lại | |

Và một lời khuyên: nếu bạn gặp câu này trong kỳ thi, hãy chọn theo khoá đáp án — nhưng khi thiết kế hệ thống thật, đừng nhân bản một máy có crontab. Đó là cách nhanh nhất để biến một tác vụ chạy đêm thành ba tác vụ chạy đêm cùng lúc, và loại lỗi đó thường chỉ lộ ra qua dữ liệu sai chứ không qua thông báo lỗi nào.

Đáp án

A — Tạo Network Load Balancer ở VPC chứa cụm ECS, và tạo AWS PrivateLink endpoint ở VPC bên kia.

Vì sao đúng

Đề nêu hai yêu cầu, và PrivateLink là cơ chế chuẩn: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng ở VPC-A gọi dịch vụ ECS ở VPC-B | PrivateLink phơi bày một dịch vụ qua VPC | | Lưu lượng KHÔNG được qua Internet | đi hoàn toàn trên hạ tầng AWS bằng IP riêng |

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

VPC-B (bên cung cấp):
    NLB đứng trước ECS service
        │
    VPC Endpoint Service (gắn với NLB đó)
        │
        ▼  ← kết nối riêng, một chiều
VPC-A (bên tiêu thụ):
    Interface VPC Endpoint (ENI có IP riêng trong subnet)
        ↓
    Ứng dụng gọi tên DNS của endpoint như gọi dịch vụ nội bộ

Vì sao phải có NLB:

Endpoint service của PrivateLink chỉ gắn được với
    → Network Load Balancer
    → hoặc Gateway Load Balancer
        ↓
    Không gắn thẳng vào ECS service được
    → NLB là bắt buộc, không phải tuỳ chọn

Cấu hình phía cung cấp (VPC-B):

aws elbv2 create-load-balancer --name nlb-dich-vu-ecs   --type network --scheme internal   --subnets subnet-b1 subnet-b2

aws ec2 create-vpc-endpoint-service-configuration   --network-load-balancer-arns <arn-nlb>   --no-acceptance-required

Cấu hình phía tiêu thụ (VPC-A):

aws ec2 create-vpc-endpoint --vpc-id vpc-a   --vpc-endpoint-type Interface   --service-name com.amazonaws.vpce.ap-southeast-1.vpce-svc-abc123   --subnet-ids subnet-a1 subnet-a2   --security-group-ids sg-endpoint --private-dns-enabled

Ba lợi ích so với VPC peering: | Lợi ích | Chi tiết | |---|---| | CHỈ phơi bày một dịch vụ, không phải cả VPC | | | CIDR hai bên được phép TRÙNG NHAU | | | Kết nối một chiều — bên cung cấp không vào được bên tiêu thụ | |

Vế thứ hai là ưu thế thực tế rất lớn:

VPC Peering: hai VPC KHÔNG được trùng dải CIDR
    → sáp nhập công ty, hai bên đều dùng 10.0.0.0/16
    → không peer được

PrivateLink: không quan tâm CIDR
    → lưu lượng đi tới ENI trong chính subnet của bên tiêu thụ

Và vế thứ ba là ưu thế bảo mật:

Peering mở hai chiều (theo bảng định tuyến và SG)
PrivateLink chỉ một chiều: tiêu thụ → cung cấp
        ↓
    Bên cung cấp không có đường vào mạng của bên tiêu thụ

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

• **B. Tạo NLB và PrivateLink endpoint đều ở VPC chứa cụm ECS — đây là phương án gần nhất và chỉ sai vị trí đặt endpoint, nhưng đó là sai điểm cốt lõi: interface endpoint phải nằm ở VPC TIÊU THỤ thì ứng dụng bên đó mới có ENI để gọi tới. Đặt cả hai cùng một VPC thì VPC-A vẫn không có đường vào.
• **C. Cấu hình gateway endpoint cho Amazon ECS — gateway endpoint chỉ hỗ trợ S3 và DynamoDB. Không có gateway endpoint cho ECS, và kể cả có thì nó dùng để gọi API của ECS, không phải để gọi ứng dụng đang chạy trong cụm.
• **D. Dùng Route 53 private hosted zone phân giải IP nội bộ ở mỗi VPC — DNS chỉ phân giải tên thành IP; nó không tạo ra đường đi mạng nào. Không có peering hay PrivateLink thì IP đó vẫn không tới được.

Ghi nhớ

Ba cách nối hai VPC — bảng phải thuộc: | Cách | Phơi bày | CIDR trùng | |---|---|---| | VPC Peering | cả VPC (theo route + SG) | ❌ không được | | Transit Gateway | cả VPC, có phân đoạn | ❌ | | PrivateLink | CHỈ MỘT dịch vụ | ✅ được ← câu này |

Từ khoá nhận diện:

"expose one service to another VPC" + "no internet" → PrivateLink "overlapping CIDR" → PrivateLink (peering không làm được) "connect many VPCs" → Transit Gateway "access S3/DynamoDB privately" → gateway endpoint

Hai loại VPC endpoint: | Loại | Dịch vụ | Cơ chế | Phí | |---|---|---|---| | Gateway | CHỈ S3 và DynamoDB | route trong bảng định tuyến | miễn phí | | Interface (PrivateLink) | hầu hết dịch vụ + dịch vụ tự tạo | ENI có IP riêng | theo giờ + GB |

Ba thành phần của PrivateLink tự tạo: | Thành phần | Ở đâu | |---|---| | Network Load Balancer | VPC cung cấp | | VPC Endpoint Service | VPC cung cấp | | Interface VPC Endpoint | VPC TIÊU THỤ |

Ba lưu ý về endpoint service: | Lưu ý | Chi tiết | |---|---| | AcceptanceRequired để duyệt từng kết nối | | | AllowedPrincipals giới hạn ai được kết nối | | | Hỗ trợ private DNS name (cần xác minh tên miền) | |

aws ec2 modify-vpc-endpoint-service-permissions   --service-id vpce-svc-abc123   --add-allowed-principals arn:aws:iam::111122223333:root

Ba lưu ý về NLB cho PrivateLink: | Lưu ý | Chi tiết | |---|---| | Phải là NLB (hoặc GWLB), không dùng ALB | | | Nên đặt internal scheme | | | Bật cross-zone nếu target lệch AZ | |

Vế thứ ba có ảnh hưởng chi phí:

NLB tính phí data transfer cross-zone (khác ALB)
    → bật cross-zone cho cân bằng tốt hơn nhưng tốn phí
    → hoặc đảm bảo mỗi AZ đều có target

Ba lưu ý về DNS: | Lưu ý | Chi tiết | |---|---| | Endpoint có tên DNS riêng theo AZ | | | --private-dns-enabled cho dịch vụ AWS | | | Dịch vụ tự tạo cần xác minh tên miền để dùng private DNS | |

Không có private DNS thì phải dùng tên endpoint:

vpce-0abc123-xyz.vpce-svc-abc.ap-southeast-1.vpce.amazonaws.com
    ↓
Hoặc tạo Route 53 private hosted zone
    → CNAME tên thân thiện → tên endpoint
    → đây mới là chỗ private hosted zone hữu ích

Đây là điểm đáng nói về phương án D: private hosted zone là bổ sung cho PrivateLink, không thay thế được nó.

Ba lưu ý về security group: | Lưu ý | Chi tiết | |---|---| | Interface endpoint CÓ security group | gateway endpoint thì không | | Cho phép cổng của dịch vụ từ ứng dụng | | | NLB không có security group (trước đây) | nay đã hỗ trợ |

Ba dịch vụ AWS hay cần interface endpoint: | Dịch vụ | Vì sao | |---|---| | Secrets Manager | lấy credential từ subnet riêng tư | | SSM, SSM Messages, EC2 Messages | Session Manager | | ECR api và dkr + S3 gateway | kéo ảnh container |

Vế cuối là combo hay bị thiếu:

Kéo ảnh từ ECR trong subnet riêng tư cần BA thứ:
    → interface endpoint cho ecr.api
    → interface endpoint cho ecr.dkr
    → GATEWAY endpoint cho S3 (lớp ảnh nằm ở S3)
        ↓
    Thiếu cái thứ ba: xác thực xong nhưng tải ảnh thất bại

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Interface endpoint tính theo GIỜ mỗi AZ | | | Cộng phí theo GB xử lý | | | Nhiều endpoint × nhiều AZ cộng lại đáng kể | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig tên endpoint từ VPC tiêu thụ | phải ra IP riêng | | curl tới dịch vụ | | | Reachability Analyzer nếu không thông | |

Và một lời khuyên: hãy nhớ rằng interface endpoint luôn nằm ở phía TIÊU THỤ. Đây là điểm gây nhầm lẫn nhiều nhất về PrivateLink — bên cung cấp dựng NLB và endpoint service, bên tiêu thụ dựng endpoint; đặt nhầm phía thì mọi thứ tạo được nhưng không có đường nào nối hai bên.

Đáp án

D — Chuyển tài liệu và tệp media sang Amazon FSx for Windows File Server.

Vì sao đúng

Đề nêu bốn dữ kiện, và FSx for Windows là dịch vụ duy nhất khớp hết: | Dữ kiện | Cách đáp ứng | |---|---| | File share Microsoft Windows | FSx for Windows dùng SMB | | Người dùng truy cập bằng client Windows | giao thức gốc, không cần đổi gì | | Xác thực bằng Active Directory hiện có | FSx nối trực tiếp vào AD | | Phải DÙNG LẠI hệ thống phân quyền hiện có | giữ nguyên ACL NTFS |

Vế thứ tư là ràng buộc quyết định:

"existing user authentication and access management system
 should be used"
        ↓
    Nghĩa là: giữ nguyên AD và giữ nguyên quyền NTFS
    → chỉ FSx for Windows làm được điều này

Vì sao các lựa chọn khác phá vỡ mô hình phân quyền:

EFS:  quyền POSIX (uid/gid) — khác hẳn ACL Windows
S3:   quyền IAM và bucket policy — không phải AD
        ↓
    Cả hai đều buộc xây lại toàn bộ mô hình phân quyền

Tạo FSx nối AD:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 2000 --storage-type SSD   --subnet-ids subnet-a subnet-b   --windows-configuration     'DeploymentType=MULTI_AZ_1,PreferredSubnetId=subnet-a,
     ThroughputCapacity=64,ActiveDirectoryId=d-1234567890,
     AutomaticBackupRetentionDays=30'

Người dùng mount như cũ:

net use Z: \\amznfsxabc123.congty.local\share /persistent:yes

Ba lợi ích trực tiếp cho mục tiêu của đề: | Lợi ích | Chi tiết | |---|---| | Hết lo chạm giới hạn dung lượng | tăng dung lượng bất cứ lúc nào | | Người dùng không thấy gì thay đổi | vẫn là ổ Z: | | Quyền và nhóm AD giữ nguyên | |

Và ba tính năng Windows gốc được giữ: | Tính năng | Chi tiết | |---|---| | ACL NTFS đầy đủ | | | Shadow Copies (Previous Versions) | người dùng tự khôi phục | | Deduplication và quota theo người dùng | |

Deduplication rất hiệu quả với tài liệu và media:

Enable-FSxDedup -FileSystemPath \\amznfsxabc.congty.local\share

Tệp Office và media trong doanh nghiệp trùng lặp nhiều
    → thường tiết kiệm 50-60% dung lượng

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

• **A. Chuyển sang Amazon EFS dùng quyền POSIX — đây là phương án gần nhất vì cũng là hệ thống tệp chia sẻ được quản lý, nhưng nó phá vỡ đúng ràng buộc quan trọng nhất: EFS dùng NFS và quyền POSIX, không tích hợp AD, không giữ ACL Windows. Đề nói rõ phải dùng lại hệ thống xác thực và phân quyền hiện có.
• **C. Chuyển sang S3 và dùng bucket ACL — thay đổi lớn nhất: người dùng mất ổ đĩa mạng quen thuộc, phải dùng công cụ khác để truy cập, và ACL của S3 (vốn đã là cơ chế cũ mà AWS khuyến nghị tắt) không có quan hệ gì với AD.
• **B. Chuyển sang FSx for Lustre — sai giao thức và sai mục đích: Lustre dành cho HPC trên Linux với thông lượng cực cao, không nói SMB, không tích hợp AD, và không phù hợp với file share văn phòng.

Ghi nhớ

Bốn dịch vụ FSx — bảng phải thuộc: | Dịch vụ | Giao thức | Xác thực | |---|---|---| | FSx for Windows File Server | SMB | Active Directory ← câu này | | FSx for Lustre | Lustre | POSIX | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | cả hai | | FSx for OpenZFS | NFS | POSIX |

Từ khoá nhận diện — ánh xạ nhanh nhất:

"Windows file share" + "Active Directory" → FSx for Windows "Linux", "NFS", "POSIX" → EFS "HPC", "Lustre" → FSx for Lustre "on-premises servers need cloud storage with cache" → Storage Gateway

⚠ Phân biệt FSx for Windows và S3 File Gateway: | | FSx for Windows | S3 File Gateway | |---|---|---| | Dữ liệu ở | hệ thống tệp Windows trên AWS | S3 (object) | | Chạy ở | AWS | tại chỗ (có cache) | | Mục đích | THAY THẾ file server | cầu nối tại chỗ ↔ đám mây | | Chi phí lưu trữ | cao hơn | rẻ hơn |

Đề nói "move the data to AWS" vì sắp hết dung lượng
    → và phải giữ nguyên xác thực AD
        ↓
    FSx for Windows là dịch vụ thay thế trực tiếp file server

Ba lựa chọn Active Directory: | Lựa chọn | Khi nào | |---|---| | AWS Managed Microsoft AD | AD thật trên AWS, lập trust được | | AD tự quản (self-managed) | nối trực tiếp AD tại chỗ qua DX/VPN | | AD Connector | KHÔNG dùng được cho FSx |

⚠ Chi tiết dễ nhầm:

FSx for Windows nối được: AWS Managed AD, hoặc AD tự quản
    → KHÔNG nối được qua AD Connector
        ↓
    AD Connector chỉ phục vụ IAM Identity Center, WorkSpaces...

Hai chế độ triển khai: | Chế độ | SLA | Đặc điểm | |---|---|---| | Single-AZ | 99,9% | rẻ hơn | | Multi-AZ | 99,99% | standby ở AZ khác, tự chuyển |

Ba yêu cầu mạng: | Yêu cầu | Chi tiết | |---|---| | Kết nối tới domain controller | DX hoặc VPN nếu AD tại chỗ | | Cổng SMB 445, và cổng AD (53, 88, 389, 445, 464...) | | | Subnet ở hai AZ nếu Multi-AZ | |

Ba cách di chuyển dữ liệu: | Cách | Đặc điểm | |---|---| | AWS DataSync | giữ ACL và metadata NTFS | | robocopy /COPYALL | kiểm soát chi tiết | | Snowball | lượng rất lớn |

DataSync là cách được khuyến nghị:

aws datasync create-task   --source-location-arn <arn-nas-cu>   --destination-location-arn <arn-fsx>   --options '{"SecurityDescriptorCopyFlags":"OWNER_DACL_SACL",
              "PreserveDeletedFiles":"PRESERVE","VerifyMode":"POINT_IN_TIME_CONSISTENT"}'

⚠ SecurityDescriptorCopyFlags là tham số quyết định:

Không đặt tham số này
    → tệp sang được nhưng MẤT quyền NTFS
    → mọi thư mục kế thừa quyền của thư mục gốc
        ↓
    Một file share mà ai cũng đọc được — sự cố im lặng

Ba loại lưu trữ: | Loại | Dùng cho | |---|---| | SSD | tài liệu hay truy cập | | HDD | dữ liệu nguội, rẻ hơn | | — | đổi HDD sang SSD được |

Ba lưu ý về throughput capacity: | Lưu ý | Chi tiết | |---|---| | Ảnh hưởng cả IOPS và băng thông | | | Tăng giảm được sau khi tạo | | | Tăng có gián đoạn ngắn | |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Tự động hằng ngày, giữ 0-90 ngày | | | Shadow Copies cho người dùng tự khôi phục | | | AWS Backup quản lý tập trung được | |

Ba lưu ý về mở rộng dung lượng: | Lưu ý | Chi tiết | |---|---| | Tăng dung lượng bất cứ lúc nào | không gián đoạn | | Không giảm được | | | DFS Namespaces gộp nhiều file system | vượt giới hạn 64 TB |

Ba việc kiểm chứng sau khi chuyển: | Việc | Cách | |---|---| | Kiểm tra ACL trên thư mục nhạy cảm | | | Đăng nhập bằng tài khoản AD thường | | | Thử Previous Versions | |

Và một lời khuyên: hãy kiểm tra quyền NTFS trên vài thư mục nhạy cảm ngay sau khi chép xong, đừng chỉ so số tệp và dung lượng. Mọi công cụ đều báo "hoàn tất" như nhau, nhưng nếu cờ giữ security descriptor không được bật thì thư mục lương hay hồ sơ nhân sự sẽ mở cho cả công ty — và không có cảnh báo nào cho bạn biết điều đó.

Đáp án

C — Dùng Amazon ElastiCache làm bộ nhớ đệm cho tầng CSDL.

Vì sao đúng

Đề nêu ba dữ kiện, và ElastiCache khớp cả ba: | Dữ kiện | Ý nghĩa | |---|---| | Ứng dụng hiển thị BẢNG ĐIỂM | cùng dữ liệu được đọc đi đọc lại rất nhiều | | Hiệu năng ĐỌC của RDS kém | cần giảm số truy vấn tới CSDL | | Thay đổi kiến trúc ÍT NHẤT | thêm một tầng cache, không đổi CSDL |

Vì sao bảng điểm là ca lý tưởng cho cache:

Hàng nghìn người cùng xem một bảng xếp hạng
    → cùng một truy vấn chạy đi chạy lại
    → kết quả gần như không đổi giữa các lần
        ↓
    Cache một lần, phục vụ hàng nghìn lượt
    → CSDL chỉ chịu một truy vấn thay vì hàng nghìn

Mẫu cache-aside (lazy loading):

import redis, json
cache = redis.Redis(host='cum-cache.abc.cache.amazonaws.com', port=6379)

def lay_bang_diem(ma_game):
    khoa = f'bangdiem:{ma_game}'
    kq = cache.get(khoa)
    if kq:
        return json.loads(kq)                    # trúng cache
    kq = truy_van_rds(ma_game)                   # trượt cache
    cache.setex(khoa, 60, json.dumps(kq))        # lưu 60 giây
    return kq

Hoặc dùng sorted set của Redis — đúng công cụ cho bảng điểm:

cache.zadd('bangdiem:game1', {'nguoichoi_a': 5200, 'nguoichoi_b': 4800})
top10 = cache.zrevrange('bangdiem:game1', 0, 9, withscores=True)

Sorted set giữ thứ hạng tự động
    → lấy top N là thao tác O(log N)
    → nhanh hơn nhiều so với ORDER BY trên CSDL

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ dưới mili giây | dữ liệu trong RAM | | Giảm mạnh tải đọc lên RDS | | | Không đổi CSDL, không đổi schema | |

Vì sao "thay đổi ít nhất":

Thêm ElastiCache = thêm một tầng phía trước
    → CSDL giữ nguyên
    → schema giữ nguyên
    → chỉ sửa hàm đọc dữ liệu

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

• **D. Nối ứng dụng và CSDL qua RDS Proxy — đây là phương án gần nhất vì cũng là một tầng đặt trước CSDL, nhưng nó giải quyết vấn đề khác: RDS Proxy gộp kết nối, hữu ích khi có quá nhiều kết nối (thường với Lambda). Ở đây vấn đề là số lượng truy vấn đọc, mà proxy không giảm truy vấn nào.
• **B. Đổi sang DynamoDB — có thể cho hiệu năng tốt, nhưng đây là viết lại toàn bộ tầng dữ liệu: từ SQL sang NoSQL, thiết kế lại mô hình dữ liệu. Ngược hẳn "minimizing changes to the architecture".
• **A. Đổi tầng tính toán từ EC2 sang Lambda — sai tầng: nút thắt nằm ở CSDL, không phải ở tầng tính toán. Đổi compute không giảm được một truy vấn đọc nào, và còn có thể làm nặng thêm vì Lambda mở nhiều kết nối hơn.

Ghi nhớ

Ba cách giảm tải đọc cho CSDL — bảng phải thuộc: | Cách | Giảm gì | Khi nào | |---|---|---| | ElastiCache | SỐ TRUY VẤN | cùng dữ liệu đọc lại nhiều ← câu này | | Read replica | phân tán truy vấn | truy vấn đa dạng, cần dữ liệu mới | | RDS Proxy | số KẾT NỐI | quá nhiều kết nối (Lambda) |

Từ khoá nhận diện:

"same data read repeatedly", "leaderboard", "session store" → ElastiCache "analysts running varied queries on latest data" → read replica "connection timeout with Lambda" → RDS Proxy

⚠ Hai engine của ElastiCache — bảng phải thuộc: | | Redis | Memcached | |---|---|---| | Cấu trúc dữ liệu | list, set, sorted set, hash | chỉ chuỗi | | Bền vững | ✅ snapshot, AOF | ❌ | | Nhân bản, Multi-AZ | ✅ | ❌ | | Pub/Sub | ✅ | ❌ | | Đa luồng | (Redis 6+ có I/O threads) | ✅ |

Bảng điểm cần sorted set và cần bền vững
    → Redis là lựa chọn rõ ràng

Ba mẫu cache: | Mẫu | Cách hoạt động | |---|---| | Lazy loading (cache-aside) | đọc cache trước, trượt thì đọc CSDL rồi lưu | | Write-through | ghi vào cả cache và CSDL | | TTL | để dữ liệu tự hết hạn |

Bảng đánh đổi: | Mẫu | Ưu | Nhược | |---|---|---| | Lazy loading | chỉ cache thứ được dùng | lần đọc đầu chậm; dữ liệu có thể cũ | | Write-through | cache luôn mới | cache đầy dữ liệu không ai đọc | | TTL | đơn giản, tự dọn | phải chọn thời hạn hợp lý |

Thực tế thường kết hợp lazy loading + TTL — đúng như đoạn mã ở trên.

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL ngắn: dữ liệu mới, ít trúng cache | | | TTL dài: trúng nhiều, dữ liệu có thể cũ | | | Bảng điểm chấp nhận cũ vài chục giây | |

⚠ Ba vấn đề kinh điển của cache: | Vấn đề | Chi tiết | |---|---| | Cache stampede | nhiều request cùng trượt cache, cùng dồn vào CSDL | | Hot key | một khoá bị đọc quá nhiều | | Cache invalidation | biết khi nào phải xoá |

Chống stampede:

# Dùng khoá tạm để chỉ một tiến trình nạp lại
if cache.set(f'{khoa}:lock', '1', nx=True, ex=10):
    kq = truy_van_rds(ma_game)
    cache.setex(khoa, 60, json.dumps(kq))
    cache.delete(f'{khoa}:lock')
else:
    kq = json.loads(cache.get(khoa) or '[]')   # dùng bản cũ

Không có cơ chế này:
    → TTL hết đúng lúc cao điểm
    → 5.000 request cùng trượt cache
    → 5.000 truy vấn dồn vào RDS cùng lúc
        ↓
    Cache lại chính là thứ gây sập CSDL

Ba đặc điểm của ElastiCache for Redis: | Đặc điểm | Chi tiết | |---|---| | Cluster mode disabled: một shard, có replica | đơn giản | | Cluster mode enabled: nhiều shard | dữ liệu lớn | | Multi-AZ với tự động failover | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Đặt trong subnet riêng tư | | | Bật encryption in transit và at rest | | | Dùng Redis AUTH hoặc IAM authentication | |

aws elasticache create-replication-group   --replication-group-id cum-bang-diem   --replication-group-description "Cache bang diem"   --engine redis --cache-node-type cache.r7g.large   --num-cache-clusters 2 --automatic-failover-enabled   --transit-encryption-enabled --at-rest-encryption-enabled   --cache-subnet-group-name nhom-subnet-rieng-tu

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp = cache không hiệu quả | | Evictions | bộ nhớ đầy, đang đẩy dữ liệu ra | | CPUUtilization / EngineCPUUtilization | |

Evictions tăng là tín hiệu rõ ràng:

Bộ nhớ đầy → Redis đẩy khoá cũ ra theo maxmemory-policy
    → tỷ lệ trúng cache giảm
        ↓
    Tăng cỡ node, hoặc thêm shard, hoặc rút ngắn TTL

Ba lựa chọn thay thế nên biết: | Lựa chọn | Khi nào | |---|---| | ElastiCache Serverless | không muốn chọn cỡ node | | DAX | chỉ cho DynamoDB | | MemoryDB for Redis | cần bền vững như một CSDL |

Và một lời khuyên: hãy chống cache stampede ngay khi thiết kế, đừng đợi gặp sự cố. Một bảng điểm có TTL 60 giây và hàng nghìn người xem sẽ tạo ra một đợt truy vấn dồn dập đúng mỗi 60 giây — và đó là kiểu tải mà CSDL chịu kém hơn hẳn so với tải đều đặn ban đầu.