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

Đáp án

A — Tạo SNS topic và SQS queue mới; thêm cấu hình S3 event notification để phát các sự kiện s3:ObjectCreated:* và s3:ObjectRemoved:Delete tới SQS và SNS.

Vì sao đúng

Đề nêu ba yêu cầu theo dõi, và cặp sự kiện này phủ đủ: | Yêu cầu | Sự kiện | |---|---| | Object MỚI được thêm vào bucket | s3:ObjectCreated:* | | Object bị XOÁ | s3:ObjectRemoved:Delete | | Object có phiên bản bị XOÁ VĨNH VIỄN | s3:ObjectRemoved:Delete cũng bắt trường hợp này |

Điểm mấu chốt: phân biệt hai loại sự kiện xoá trong bucket có versioning.

Bucket BẬT versioning, gọi DELETE không kèm versionId:
    → S3 tạo DELETE MARKER, các phiên bản cũ VẪN CÒN
    → phát sự kiện: s3:ObjectRemoved:DeleteMarkerCreated

Bucket BẬT versioning, gọi DELETE CÓ kèm versionId:
    → phiên bản đó bị XOÁ VĨNH VIỄN, không khôi phục được
    → phát sự kiện: s3:ObjectRemoved:Delete    ← đây mới là "permanently deleted"

Đề nói rõ "track whether a versioned object is PERMANENTLY deleted" — nên phải dùng Delete, không phải DeleteMarkerCreated.

Và hai đích SQS + SNS đúng như đề mô tả:

SQS  → hàng đợi cho việc xử lý hậu kỳ (post-processing)
SNS  → thông báo tới đội vận hành

Cấu hình:

{"QueueConfigurations": [{
   "QueueArn": "arn:aws:sqs:...:hang-doi-audit",
   "Events": ["s3:ObjectCreated:*", "s3:ObjectRemoved:Delete"]}],
 "TopicConfigurations": [{
   "TopicArn": "arn:aws:sns:...:canh-bao-van-hanh",
   "Events": ["s3:ObjectCreated:*", "s3:ObjectRemoved:Delete"]}]}

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

• **C. SNS + SQS với s3:ObjectCreated:* và ObjectRemoved:DeleteMarkerCreated — đây là phương án gần nhất và hai đích dịch vụ hoàn toàn đúng, nhưng nó theo dõi sai loại xoá: DeleteMarkerCreated báo khi có delete marker được tạo — tức là xoá mềm, dữ liệu vẫn còn. Nó không bắt được việc xoá vĩnh viễn mà đề yêu cầu.
• **B. SNS + Amazon MQ với sự kiện s3:ObjectAdded:* — hai lỗi: s3:ObjectAdded KHÔNG TỒN TẠI (tên đúng là s3:ObjectCreated). Và Amazon MQ không phải đích hợp lệ của S3 event notification.
• **D. SNS + Amazon MQ với ObjectRemoved:DeleteMarkerCreated — cùng lỗi về Amazon MQ, cộng thêm lỗi chọn sai loại sự kiện xoá.

Ghi nhớ

Các loại sự kiện S3 event notification — bảng cần thuộc: | Sự kiện | Kích hoạt khi | |---|---| | s3:ObjectCreated:* | mọi cách tạo object | | s3:ObjectCreated:Put | tải lên bằng PUT | | s3:ObjectCreated:Post | tải lên qua form POST | | s3:ObjectCreated:Copy | sao chép object | | s3:ObjectCreated:CompleteMultipartUpload | hoàn tất multipart | | s3:ObjectRemoved:Delete | XOÁ VĨNH VIỄN một phiên bản | | s3:ObjectRemoved:DeleteMarkerCreated | tạo delete marker (xoá mềm) | | s3:ObjectRestore:* | khôi phục từ Glacier | | s3:ReducedRedundancyLostObject | mất object ở lớp RRS | | s3:LifecycleExpiration:* | lifecycle rule xoá object | | s3:Replication:* | sự kiện sao chép chéo |

Cặp Delete và DeleteMarkerCreated là điểm phân biệt chính của câu hỏi này.

Ba đích hợp lệ của S3 event notification: | Đích | Phù hợp | |---|---| | Amazon SQS | hàng đợi để xử lý sau, chịu được lỗi và tải đột biến | | Amazon SNS | fan-out — nhiều người nhận cùng một thông báo | | AWS Lambda | xử lý ngay bằng mã | | Amazon EventBridge | định tuyến linh hoạt, lọc theo mẫu phức tạp |

Amazon MQ, Kinesis, DynamoDB KHÔNG phải đích trực tiếp — muốn tới đó phải đi qua Lambda hoặc EventBridge.

Hành vi xoá trong bucket có versioning: | Thao tác | Kết quả | Khôi phục được | |---|---|---| | DELETE không kèm versionId | tạo delete marker | ✅ xoá delete marker là xong | | DELETE kèm versionId | xoá vĩnh viễn phiên bản đó | ❌ | | Lifecycle NoncurrentVersionExpiration | xoá vĩnh viễn phiên bản cũ | ❌ |

Với yêu cầu kiểm toán như đề mô tả, nên theo dõi CẢ HAI loại sự kiện xoá — biết ai xoá mềm cũng quan trọng không kém biết ai xoá hẳn.

Ba lưu ý khi cấu hình S3 event notification: | Lưu ý | Chi tiết | |---|---| | Cần resource policy ở đích | SQS queue policy hoặc SNS topic policy phải cho phép s3.amazonaws.com | | Giao ÍT NHẤT MỘT LẦN | có thể trùng lặp — bên nhận phải idempotent | | Thứ tự không đảm bảo | dùng sequencer trong thông điệp để sắp xếp |

Policy cần thiết cho SQS queue:

{"Effect": "Allow",
 "Principal": {"Service": "s3.amazonaws.com"},
 "Action": "sqs:SendMessage",
 "Resource": "arn:aws:sqs:...:hang-doi-audit",
 "Condition": {"ArnLike": {"aws:SourceArn": "arn:aws:s3:::kho-tai-chinh"}}}

Thiếu policy này thì sự kiện bị bỏ im lặng — không có lỗi nào hiện ra ở phía S3.

Và với yêu cầu kiểm toán, hãy cân nhắc thêm hai cơ chế bổ sung: | Cơ chế | Bổ sung gì | |---|---| | CloudTrail data event cho S3 | ghi AI thực hiện thao tác, từ IP nào — event notification KHÔNG có thông tin này | | S3 Object Lock ở chế độ Compliance | ngăn xoá hoàn toàn trong thời hạn quy định |

Dòng đầu rất quan trọng: S3 event notification cho biết có gì đó bị xoá, nhưng không cho biết AI xoá. Với kiểm toán tài chính, câu hỏi "ai" thường quan trọng hơn "cái gì".

Và với tài liệu quy định như đề mô tả, S3 Object Lock đáng cân nhắc nghiêm túc: thay vì phát hiện sau khi tài liệu bị xoá, nó khiến việc xoá không thể xảy ra trong thời hạn giữ. Phòng ngừa luôn tốt hơn phát hiện.

Đáp án

A — Dùng S3 Object Lambda với một Lambda function xử lý dữ liệu dựa trên tên bucket và KHOÁ (key) của object.

Vì sao đúng

Đề cần lọc và biến đổi dữ liệu ngay khi lấy về, không tải cả tệp — và S3 Object Lambda làm đúng việc đó.

Cách hoạt động:

Ứng dụng gọi GET qua Object Lambda Access Point
    ↓
S3 lấy object gốc
    ↓
Gọi Lambda function của bạn với dữ liệu đó
    ↓
Lambda lọc, biến đổi, chỉ trả về phần cần
    ↓
Ứng dụng nhận kết quả ĐÃ XỬ LÝ
    → object gốc trong S3 KHÔNG bị thay đổi

Và điểm mấu chốt của câu hỏi: Lambda cần gì để xác định object nào cần xử lý.

Để trỏ tới DUY NHẤT một object trong S3, cần đủ hai thứ:
    ① Tên bucket   → biết object ở kho nào
    ② KHOÁ (key)   → biết object nào trong kho đó

Metadata và tag KHÔNG xác định được object — chúng là thuộc tính của object, chỉ đọc được sau khi đã biết object nào. Chúng không phải định danh.

Hàm Lambda nhận sự kiện có dạng:

def lambda_handler(event, context):
    ctx = event['getObjectContext']
    url = ctx['inputS3Url']            # URL đã ký sẵn tới object gốc
    du_lieu = requests.get(url).content
    ket_qua = loc_csv(du_lieu)         # chỉ giữ phần cần
    boto3.client('s3').write_get_object_response(
        Body=ket_qua,
        RequestRoute=ctx['outputRoute'],
        RequestToken=ctx['outputToken'])

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

(Bốn phương án chỉ khác nhau ở thông tin mà Lambda dùng để xác định object.)

• **B. Xử lý dựa trên tên bucket và metadata của object — đây là phương án gần nhất về mặt cũng dùng thông tin của object, nhưng metadata không xác định được object nào. Bạn phải biết khoá trước rồi mới đọc được metadata của nó.
• **C. Xử lý dựa trên tên bucket và tag của object — cùng vấn đề: tag là nhãn gắn thêm, nhiều object có thể mang cùng tag. Nó không phải định danh duy nhất.
• **D. Xử lý chỉ dựa trên tên bucket — thiếu hẳn thông tin cần thiết: một bucket chứa hàng triệu object, biết tên bucket thôi thì không biết phải xử lý cái nào.

(Ghi chú về chất lượng câu hỏi: bốn phương án gần như giống hệt nhau, chỉ đổi vài chữ ở cuối. Đây là dạng câu kiểm tra một chi tiết rất hẹp — rằng bucket + key là cặp định danh của object S3 — chứ không kiểm tra hiểu biết về kiến trúc.)

Ghi nhớ

Ba cách lấy một phần dữ liệu từ object S3 — phân biệt rõ: | Cách | Việc | Phù hợp | |---|---|---| | S3 Object Lambda | chạy MÃ TUỲ Ý để biến đổi khi đọc | logic phức tạp, đổi định dạng, che dữ liệu ← câu này | | Byte-range fetch | lấy một dải byte cụ thể | biết chính xác vị trí cần | | Amazon Athena | truy vấn SQL trên nhiều tệp | phân tích trên tập dữ liệu lớn |

(S3 Select — truy vấn SQL trên một object đơn — đã được AWS ngừng nhận khách hàng mới; hướng thay thế là Athena hoặc Object Lambda.)

Bốn ứng dụng điển hình của S3 Object Lambda: | Ứng dụng | Chi tiết | |---|---| | Che dữ liệu nhạy cảm (PII) | cùng một tệp, mỗi vai trò thấy mức chi tiết khác nhau | | Đổi định dạng khi đọc | XML → JSON, CSV → JSON | | Đổi cỡ ảnh động | một ảnh gốc, nhiều kích thước | | Bổ sung dữ liệu | ghép thêm thông tin từ nguồn khác |

Ứng dụng đầu là mạnh nhất về mặt bảo mật: thay vì lưu nhiều bản sao của cùng dữ liệu với mức che khác nhau, bạn giữ một bản gốc và để Lambda quyết định người gọi được thấy gì.

Ba thành phần phải tạo cho S3 Object Lambda:

① S3 Access Point            → trỏ vào bucket gốc
② Object Lambda Access Point → trỏ vào access point ở trên
③ Lambda function            → chứa logic biến đổi

Ứng dụng gọi vào ② chứ không gọi thẳng bucket.

Ba lưu ý khi dùng: | Lưu ý | Chi tiết | |---|---| | Tính phí Lambda cho MỖI request | object bị đọc nhiều lần thì chi phí tích tụ | | Thời gian chạy tối đa 60 giây | ngắn hơn giới hạn 15 phút thông thường của Lambda | | Tăng độ trễ | có thêm một chặng xử lý |

Dòng đầu là cân nhắc chi phí quan trọng: nếu cùng một phép biến đổi được yêu cầu lặp đi lặp lại, tính sẵn kết quả và lưu thành object riêng thường rẻ hơn nhiều so với chạy Lambda mỗi lần đọc.

Ba cách tối ưu cho tình huống của đề (lọc dữ liệu từ CSV lớn): | Cách | Lợi ích | |---|---| | Chuyển sang Parquet | định dạng cột — đọc ít dữ liệu hơn hẳn | | Chia tệp lớn thành nhiều tệp theo phân vùng | chỉ đọc phân vùng cần | | Athena nếu truy vấn dạng SQL | không phải viết mã lọc |

Nếu nhu cầu thật sự là "chạy truy vấn SQL trên CSV", Athena đơn giản hơn Object Lambda — không phải viết và bảo trì hàm nào. Object Lambda xứng đáng khi phép biến đổi không diễn đạt được bằng SQL, hoặc khi cần trả về đúng giao diện GetObject cho ứng dụng đã có sẵn.

Đáp án

D — Tạo Kinesis Data Stream và dùng AWS Lambda đọc bản ghi từ luồng.

Vì sao đúng

Đề hỏi một câu rất cụ thể: cái nào cho phép đọc bản ghi THEO LÔ (in batches) — và đó là đặc điểm của tích hợp Kinesis Data Streams với Lambda.

Cách Lambda đọc từ Kinesis:

Lambda event source mapping poll shard của Kinesis
    → gom nhiều bản ghi thành MỘT LÔ
    → gọi hàm MỘT LẦN với cả lô
    → tham số BatchSize quyết định kích thước (tối đa 10.000 bản ghi)

def lambda_handler(event, context):
    for ban_ghi in event['Records']:      # ← cả một LÔ bản ghi
        du_lieu = base64.b64decode(ban_ghi['kinesis']['data'])
        xu_ly(du_lieu)

Và Kinesis Data Streams là dịch vụ phân tích thời gian thực đúng nghĩa: | Đặc điểm | Chi tiết | |---|---| | Độ trễ mili giây | thật sự thời gian thực | | Giữ dữ liệu 1–365 ngày | phát lại được khi xử lý lỗi | | Nhiều consumer độc lập | mỗi consumer đọc theo tốc độ riêng |

Đề cũng mô tả bối cảnh phù hợp: hệ thống đang quá tải với lỗi 503, và họ cần tách việc thu thập dữ liệu ra khỏi việc phục vụ request — Kinesis làm được vùng đệm đó.

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

• **B. Tạo Data Firehose và dùng Lambda đọc bản ghi từ luồng — đây là phương án gần nhất và cũng là dịch vụ luồng dữ liệu, nhưng nó sai về vai trò của Lambda: với Firehose, Lambda dùng để BIẾN ĐỔI dữ liệu trên đường đi, chứ không phải để đọc luồng. Firehose tự giao dữ liệu tới đích (S3, Redshift, OpenSearch) — bạn không viết consumer đọc nó.
• **A. Lưu vào S3 rồi phân tích bằng Athena — không phải thời gian thực: dữ liệu phải được ghi thành tệp trên S3 trước, rồi mới truy vấn. Đề yêu cầu "real-time analytics service".
• **C. Lưu vào S3 rồi dùng Redshift Spectrum — cùng vấn đề: đây là phân tích theo lô trên dữ liệu đã lưu, không phải xử lý luồng thời gian thực.

Ghi nhớ

Kinesis Data Streams và Data Firehose — bảng phân biệt cốt lõi: | | Data Streams | Data Firehose | |---|---|---| | Bạn viết consumer | ✅ CÓ | ❌ không cần | | Vai trò của Lambda | ĐỌC bản ghi (consumer) | BIẾN ĐỔI dữ liệu trên đường đi | | Phát lại (replay) | ✅ giữ 1–365 ngày | ❌ | | Nhiều consumer độc lập | ✅ | ❌ một đích chính | | Độ trễ | mili giây | tối thiểu ~60 giây (theo lô) | | Quản lý shard | có (chế độ provisioned) | không — tự mở rộng | | Đích | tuỳ bạn | S3, Redshift, OpenSearch, Splunk, HTTP |

Quy tắc chọn:

"real-time", "sub-second", "replay", "multiple consumers", "read records" → Data Streams "deliver to S3/Redshift", "no code", "near real-time" → Firehose

Ba tham số của Lambda event source mapping với Kinesis: | Tham số | Ý nghĩa | |---|---| | BatchSize | số bản ghi tối đa mỗi lần gọi (tới 10.000) | | MaximumBatchingWindowInSeconds | chờ gom thêm bản ghi trước khi gọi (tới 300 giây) | | ParallelizationFactor | số lô xử lý SONG SONG trên mỗi shard (tới 10) | | StartingPosition | LATEST, TRIM_HORIZON, hoặc AT_TIMESTAMP |

MaximumBatchingWindowInSeconds là công cụ cân bằng chi phí và độ trễ: đặt 0 thì gọi ngay khi có dữ liệu (độ trễ thấp, nhiều lời gọi); đặt 30 thì gom lại (ít lời gọi hơn, rẻ hơn, trễ hơn).

ParallelizationFactor đáng biết: mặc định mỗi shard được xử lý tuần tự bởi một instance Lambda. Tăng lên cho phép nhiều lô của cùng shard chạy song song — nhưng làm mất thứ tự trong shard, nên chỉ dùng khi ứng dụng không phụ thuộc thứ tự.

Ba cách xử lý lỗi khi Lambda đọc Kinesis: | Cách | Chi tiết | |---|---| | BisectBatchOnFunctionError | chia đôi lô khi lỗi để cô lập bản ghi hỏng | | MaximumRetryAttempts | giới hạn số lần thử lại | | DestinationConfig (on-failure) | gửi bản ghi hỏng sang SQS hoặc SNS |

Không cấu hình ba thứ này thì một bản ghi hỏng sẽ CHẶN CẢ SHARD: Lambda thử lại mãi, không xử lý được bản ghi nào phía sau, cho tới khi bản ghi hỏng hết hạn lưu trữ. Đây là sự cố kinh điển với Kinesis + Lambda.

Ba metric cần đặt alarm: | Metric | Cảnh báo khi | |---|---| | IteratorAge | consumer tụt hậu — nguy cơ mất dữ liệu khi hết hạn lưu | | WriteProvisionedThroughputExceeded | không đủ shard cho lượng ghi | | ReadProvisionedThroughputExceeded | quá nhiều consumer standard |

IteratorAge là metric quan trọng nhất: nếu nó tiến gần thời gian giữ dữ liệu (mặc định 24 giờ), bản ghi sắp bị xoá trước khi được xử lý.

Và một lưu ý về nguyên nhân gốc trong đề: lỗi 503 xảy ra vì đội EC2 đã chạm giới hạn dung lượng. Kinesis giúp tách phần thu thập dữ liệu ra, nhưng không sửa được việc web server thiếu năng lực — vẫn cần Auto Scaling group với chính sách mở rộng phù hợp cho tầng web.

Đáp án

B — Tạo một AWS Backup plan chụp snapshot hằng ngày với thời hạn giữ 90 ngày.

Vì sao đúng

Đề cần giữ bản sao lưu 90 ngày — và đó là con số vượt giới hạn của backup tự động trong RDS.

Giới hạn quyết định của câu hỏi:

RDS automated backup:
    thời hạn giữ tối đa = 35 NGÀY
        → KHÔNG đặt được 90 ngày

AWS Backup không có giới hạn đó:

Backup plan:
    - lịch chụp: hằng ngày
    - thời hạn giữ: tuỳ ý (ngày, tháng, năm)
    - chuyển sang kho lạnh sau N ngày để tiết kiệm

{"Rules": [{
  "RuleName": "sao-luu-hang-ngay-giu-90-ngay",
  "TargetBackupVaultName": "kho-sao-luu-chinh",
  "ScheduleExpression": "cron(0 3 ? * * *)",
  "Lifecycle": {"DeleteAfterDays": 90}
}]}

Và AWS Backup còn cho nhiều thứ mà backup tự động của RDS không có: | Lợi ích | Chi tiết | |---|---| | Quản lý tập trung | RDS, EBS, EFS, DynamoDB, FSx trong một chính sách | | Sao chép xuyên Region và xuyên tài khoản | phục hồi thảm hoạ | | Backup vault lock | ngăn xoá bản sao lưu — chống ransomware | | Báo cáo tuân thủ | chứng minh chính sách được thực thi |

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

• **A. Cấu hình automated backup với thời hạn giữ 90 ngày — đây là phương án gần nhất và là điều người ta thử đầu tiên, nhưng nó vượt giới hạn kỹ thuật: RDS chỉ cho phép tối đa 35 ngày. Đặt 90 sẽ bị từ chối.
• **C. Cấu hình RDS tự động xuất snapshot sang S3 rồi dùng lifecycle policy xoá sau 90 ngày — không có tính năng tự động này: RDS có thể xuất snapshot sang S3, nhưng đó là thao tác thủ công hoặc phải tự viết tự động hoá, không phải cấu hình bật tắt. Và snapshot xuất ra S3 ở dạng Parquet, không dùng để khôi phục database trực tiếp được.
• **D. Dùng CloudWatch Events + Lambda tải snapshot tự động về S3 rồi lưu trữ sang Glacier — rất nhiều công và có lỗi kỹ thuật: bạn không "tải" được RDS snapshot như một tệp. Và tự viết Lambda để làm việc mà AWS Backup đã làm sẵn là công vận hành thừa.

Ghi nhớ

Giới hạn thời gian giữ bản sao lưu — bảng cần thuộc: | Loại | Thời hạn giữ | |---|---| | RDS automated backup | 1–35 ngày (0 = tắt) | | RDS manual snapshot | vô hạn — tới khi bạn xoá | | Aurora backtrack | tới 72 giờ (chỉ Aurora MySQL) | | AWS Backup | tuỳ ý cấu hình — ngày, tháng, năm |

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

Yêu cầu giữ QUÁ 35 ngày → AWS Backup (hoặc manual snapshot) Trong vòng 35 ngày → automated backup là đủ

Automated backup và manual snapshot: | | Automated backup | Manual snapshot | |---|---|---| | Tần suất | hằng ngày + transaction log mỗi 5 phút | khi bạn chụp | | Point-in-time recovery | ✅ khôi phục về bất kỳ giây nào trong kỳ giữ | ❌ chỉ về thời điểm chụp | | Thời hạn | tối đa 35 ngày | vô hạn | | Khi XOÁ DB instance | BỊ XOÁ THEO (trừ khi tạo final snapshot) | VẪN CÒN |

Dòng cuối là cạm bẫy nghiêm trọng: xoá DB instance mà quên tạo final snapshot thì toàn bộ automated backup biến mất cùng lúc. Manual snapshot thì sống độc lập.

Ba tính năng của AWS Backup đáng dùng cho yêu cầu tuân thủ: | Tính năng | Việc | |---|---| | Backup Vault Lock | KHÔNG AI xoá được bản sao lưu trong thời hạn — kể cả tài khoản root | | Cross-Region copy | bản sao ở Region khác cho phục hồi thảm hoạ | | Cross-account copy | bản sao ở tài khoản khác — chống tài khoản chính bị chiếm | | Audit Manager tích hợp | báo cáo chứng minh tuân thủ |

Backup Vault Lock ở chế độ Compliance là biện pháp chống ransomware mạnh nhất: kẻ tấn công chiếm được quyền quản trị vẫn không xoá được bản sao lưu.

Ba cấp lifecycle trong AWS Backup: | Cấp | Chi phí | Thời gian khôi phục | |---|---|---| | Warm storage | cao hơn | nhanh | | Cold storage | rẻ hơn nhiều | vài giờ |

Ràng buộc: bản sao lưu phải ở warm storage ít nhất 90 ngày trước khi chuyển sang cold — nên với yêu cầu giữ đúng 90 ngày của đề, cold storage không áp dụng được.

Ba lưu ý về sao lưu Aurora: | Lưu ý | Chi tiết | |---|---| | Aurora sao lưu LIÊN TỤC vào S3 | không có "cửa sổ sao lưu" gây ảnh hưởng hiệu năng | | Backtrack quay ngược tại chỗ | tới 72 giờ, không cần khôi phục sang cluster mới | | Snapshot không ảnh hưởng hiệu năng | khác với RDS thông thường ở chế độ Single-AZ |

Backtrack là tính năng rất hữu ích cho lỗi do người: lỡ chạy DELETE thiếu WHERE thì quay ngược cả cluster về vài phút trước trong ít phút, thay vì khôi phục snapshot mất hàng giờ.

Và một lời khuyên vận hành: hãy kiểm thử việc khôi phục định kỳ. Một chính sách sao lưu chưa từng được khôi phục thử chỉ là giả định — thời điểm phát hiện bản sao lưu không dùng được không nên là lúc đang có sự cố thật.

Đáp án

D — Dùng AWS Storage Gateway file gateway để lưu toàn bộ dữ liệu sao lưu vào Amazon S3.

Vì sao đúng

Đề nêu yêu cầu quyết định: lưu và lấy object qua GIAO THỨC TỆP TIÊU CHUẨN — và file gateway là loại gateway duy nhất làm điều đó.

Ba loại Storage Gateway và giao thức của chúng: | Loại | Giao thức | Đích trên AWS | |---|---|---| | File Gateway | NFS và SMB ← giao thức tệp tiêu chuẩn | S3 | | Volume Gateway | iSCSI (giao thức khối) | S3 dạng EBS snapshot | | Tape Gateway | iSCSI VTL (thư viện băng ảo) | S3 Glacier |

Chỉ file gateway dùng NFS/SMB — đúng thứ đề mô tả là "standard file storage protocols".

Cách nó hoạt động:

Máy chủ tại chỗ mount thư mục qua NFS hoặc SMB
    → ghi tệp như ghi vào ổ đĩa mạng bình thường
    ↓
File gateway đồng bộ lên S3
    → MỖI TỆP thành MỘT OBJECT trong S3
    → giữ nguyên cấu trúc thư mục
    ↓
Cache cục bộ giữ dữ liệu hay truy cập
    → đọc lại nhanh, đúng yêu cầu "quick recovery"

Và vì mỗi tệp thành một object S3 độc lập, bạn truy cập được nó bằng cả API của S3 — điều mà volume gateway không cho.

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

• **A. Dùng volume gateway để lưu dữ liệu và truy cập trực tiếp bằng S3 API — đây là phương án gần nhất và cũng là Storage Gateway, nhưng nó sai ở cả hai vế: volume gateway dùng iSCSI (giao thức KHỐI), không phải giao thức tệp. Và dữ liệu của nó lưu dạng EBS snapshot — không truy cập được bằng S3 API như những object riêng lẻ.
• **C. Dùng AWS Snowball Edge sao lưu thẳng vào S3 Glacier — sai loại nhu cầu: Snowball là thiết bị vật lý cho một đợt di chuyển dữ liệu lớn, không phải kênh sao lưu liên tục. Và nó không cung cấp giao thức tệp cho việc truy cập hằng ngày.
• **B. Dùng EBS volume gắn vào EC2 instance — sai kiến trúc: EBS chỉ gắn được vào EC2 trong AWS, máy chủ tại chỗ không mount EBS được. Và độ bền của EBS thấp hơn S3 nhiều.

Ghi nhớ

Ba loại Storage Gateway — bảng cần thuộc: | Loại | Giao thức | Trường hợp dùng | |---|---|---| | File Gateway (S3 File Gateway) | NFS, SMB | chia sẻ tệp, sao lưu, kho dữ liệu ← câu này | | Volume Gateway | iSCSI | ổ đĩa khối cho ứng dụng, sao lưu ổ đĩa | | Tape Gateway | iSCSI VTL | thay thế thư viện băng từ vật lý |

Từ khoá nhận diện trong đề thi:

"NFS", "SMB", "file share", "standard file protocols" → File Gateway "iSCSI", "block storage", "volume" → Volume Gateway "tape", "backup software", "VTL" → Tape Gateway

Hai chế độ của Volume Gateway: | Chế độ | Dữ liệu chính ở đâu | |---|---| | Cached volume | AWS — chỉ cache tại chỗ (tới 32 TB mỗi volume) | | Stored volume | TẠI CHỖ — AWS giữ bản sao lưu (tới 16 TB mỗi volume) |

Stored volume phù hợp khi ứng dụng cần độ trễ thấp cho TOÀN BỘ dữ liệu; cached volume phù hợp khi chỉ một phần dữ liệu được truy cập thường xuyên.

Ba chế độ của File Gateway: | Chế độ | Đích | |---|---| | S3 File Gateway | S3 — mỗi tệp là một object | | FSx File Gateway | Amazon FSx for Windows File Server |

Ba đặc điểm quan trọng của S3 File Gateway: | Đặc điểm | Chi tiết | |---|---| | Mỗi tệp = một object S3 | truy cập được bằng cả S3 API lẫn NFS/SMB | | Cache cục bộ | dữ liệu hay dùng đọc với độ trễ thấp | | Tích hợp lifecycle của S3 | tự chuyển sang Glacier để tiết kiệm | | Hỗ trợ Active Directory | phân quyền SMB theo người dùng miền |

Dòng đầu là lợi ích lớn nhất so với volume gateway: dữ liệu sao lưu vừa dùng được như tệp thông thường tại chỗ, vừa xử lý được bằng dịch vụ AWS (Athena, Glue, Lambda) mà không cần bước chuyển đổi.

Các dịch vụ chuyển dữ liệu vào AWS — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | Storage Gateway | truy cập lai LIÊN TỤC — tại chỗ và đám mây cùng dùng | | AWS DataSync | đồng bộ định kỳ, một chiều, hiệu năng cao | | AWS Snow Family | khối lượng rất lớn, băng thông hạn chế | | AWS Transfer Family | endpoint SFTP/FTPS cho đối tác bên ngoài |

DataSync và Storage Gateway hay bị nhầm:

DataSync:         DI CHUYỂN dữ liệu (đồng bộ, một lần hoặc theo lịch)
Storage Gateway:  TRUY CẬP dữ liệu (tại chỗ dùng như ổ đĩa, dữ liệu ở AWS)

Chúng bổ sung nhau: dùng DataSync để chuyển khối lượng ban đầu, rồi Storage Gateway cho truy cập hằng ngày.

Ba lưu ý khi triển khai Storage Gateway: | Lưu ý | Chi tiết | |---|---| | Gateway chạy dạng máy ảo tại chỗ | VMware, Hyper-V, KVM — hoặc thiết bị phần cứng của AWS | | Cần đĩa cục bộ cho cache và buffer tải lên | kích thước ảnh hưởng trực tiếp tới hiệu năng | | Băng thông tới AWS quyết định tốc độ đồng bộ | đặt giới hạn băng thông theo lịch nếu cần |

Và một lưu ý về chi phí cho tình huống sao lưu của đề: kết hợp file gateway với lifecycle rule chuyển sang Glacier cho dữ liệu sao lưu cũ. Bản sao lưu ít khi được đọc, nên giữ toàn bộ ở S3 Standard là lãng phí — nhưng nhớ rằng khôi phục từ Glacier mất thời gian, nên hãy giữ các bản gần đây ở lớp truy cập nhanh.

Đáp án

D — Tạo Direct Connect gateway mới và tích hợp với kết nối DX hiện có. Thiết lập Transit Gateway giữa các tài khoản AWS và liên kết nó với Direct Connect gateway.

Vì sao đúng

Đề nêu bài toán: nhiều tài khoản AWS mới đều cần dùng chung một kết nối Direct Connect để tới các dịch vụ mạng tại chỗ.

Kiến trúc đúng có hai tầng, mỗi tầng giải một vấn đề: | Thành phần | Vấn đề nó giải | |---|---| | Direct Connect gateway | cho phép MỘT kết nối DX phục vụ NHIỀU VPC ở nhiều Region và nhiều tài khoản | | Transit Gateway | trung tâm định tuyến giữa các VPC và tài khoản — thay cho lưới peering |

Vì sao cần cả hai:

Chỉ DX gateway:
    → liên kết được tới 10 virtual private gateway (mỗi VPC một cái)
    → các VPC KHÔNG nói chuyện được với nhau qua đó

DX gateway + Transit Gateway:
    → TGW là trung tâm, mọi VPC gắn vào nó
    → một liên kết duy nhất giữa DX gateway và TGW
    → thêm tài khoản mới = gắn VPC của họ vào TGW
    → KHÔNG đụng gì tới kết nối DX vật lý

Và đó chính là "LEAST operational overhead" — thêm tài khoản là một thao tác gắn kết, không phải dựng hạ tầng mới.

    Trung tâm dữ liệu (DNS, Active Directory)
              │ Direct Connect (kết nối vật lý)
              ▼
      Direct Connect Gateway
              │
      Transit Gateway  ──── VPC tài khoản A
              ├─────────── VPC tài khoản B
              └─────────── VPC tài khoản C   ← thêm mới rất dễ

Chia sẻ Transit Gateway giữa các tài khoản bằng AWS RAM:

aws ram create-resource-share --name chia-se-tgw   --resource-arns arn:aws:ec2:...:transit-gateway/tgw-0abc123   --principals 111122223333

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

• **B. Direct Connect gateway mới + VPC peering giữa các tài khoản, liên kết peering với DX gateway — đây là phương án gần nhất và có phần DX gateway đúng, nhưng nó sai ở cách kết nối các VPC: VPC peering KHÔNG hỗ trợ định tuyến bắc cầu. VPC A peering với B, B peering với C thì A không đi tới C được. Và peering không liên kết được với DX gateway. Với N tài khoản cần N×(N−1)/2 kết nối — công quản lý tăng theo cấp số nhân.
• **A. Thiết lập một kết nối Direct Connect RIÊNG cho MỖI tài khoản mới — cực kỳ tốn kém và chậm: mỗi kết nối DX đòi lắp đặt vật lý tại điểm hiện diện, mất hàng tuần tới hàng tháng và chi phí lớn. Ngược hẳn yêu cầu "least operational overhead" và "cost-effective".
• **C. Tạo AWS VPN CloudHub và dùng VPN cho các tài khoản mới — bỏ phí kết nối DX đã có: đề nói rõ đã có Direct Connect. Chuyển sang VPN qua Internet nghĩa là mất tính nhất quán về độ trễ và băng thông — mà đề yêu cầu "consistent and dedicated access".

Ghi nhớ

Ba cách kết nối nhiều VPC với nhau: | Cách | Đặc điểm | |---|---| | VPC Peering | một–một, KHÔNG bắc cầu, không giới hạn băng thông, rẻ | | Transit Gateway | trung tâm hình sao, CÓ bắc cầu, quản lý tập trung | | PrivateLink | phơi một dịch vụ cụ thể, không nối toàn bộ mạng |

Quy tắc chọn:

2–3 VPC, kết nối đơn giản → peering Nhiều VPC, nhiều tài khoản, cần bắc cầu → Transit Gateway Chỉ cần gọi một dịch vụ, không cần nối mạng → PrivateLink

Vì sao peering không mở rộng được — phép tính:

5 VPC  → 10 kết nối peering
10 VPC → 45 kết nối
20 VPC → 190 kết nối
    → mỗi kết nối cần route table cập nhật ở cả hai đầu

Transit Gateway: N VPC → N kết nối. Tuyến tính thay vì bậc hai.

Direct Connect gateway — công dụng chính: | Công dụng | Chi tiết | |---|---| | Một DX phục vụ nhiều VPC | tới 10 virtual private gateway hoặc TGW | | Xuyên Region | VPC ở Region khác vẫn dùng chung DX | | Xuyên tài khoản | VPC của tài khoản khác liên kết được | | Miễn phí | không tính phí riêng cho DX gateway |

Ba đặc điểm của Transit Gateway: | Đặc điểm | Chi tiết | |---|---| | Route table riêng cho từng attachment | phân tách lưu lượng — ví dụ tách môi trường prod và dev | | Chia sẻ qua AWS RAM | dùng chung giữa các tài khoản trong Organization | | Peering giữa các TGW ở Region khác nhau | dựng mạng toàn cầu |

Route table riêng là tính năng quan trọng cho tổ chức nhiều tài khoản: bạn quyết định VPC nào nói chuyện được với VPC nào, thay vì mọi thứ nối với mọi thứ.

Ba lưu ý về chi phí Transit Gateway: | Khoản | Chi tiết | |---|---| | Phí mỗi attachment mỗi giờ | tích luỹ theo số VPC gắn vào | | Phí xử lý dữ liệu mỗi GB | khoản này thường lớn hơn phí attachment | | So với peering | peering không tính phí xử lý dữ liệu trong cùng AZ |

Với hai VPC trao đổi rất nhiều dữ liệu, peering trực tiếp có thể rẻ hơn — kiến trúc thực tế đôi khi kết hợp cả hai: TGW cho kết nối chung, peering riêng cho cặp VPC có lưu lượng lớn.

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Một kết nối DX đơn KHÔNG dự phòng | cần hai kết nối ở hai vị trí khác nhau cho sẵn sàng cao | | Thời gian lắp đặt tính bằng tuần | không phải tài nguyên bật tắt được | | Nên có VPN dự phòng | rẻ, thiết lập nhanh, đảm bảo kết nối khi DX đứt |

Dòng cuối là thực hành tốt được AWS khuyến nghị: cấu hình VPN làm đường dự phòng cho DX, với định tuyến BGP tự chuyển khi DX mất kết nối.

Và một lưu ý về dịch vụ DNS mà đề đề cập: để tài nguyên trong AWS phân giải được tên miền nội bộ của trung tâm dữ liệu, cần Route 53 Resolver outbound endpoint với forwarding rule trỏ về máy chủ DNS tại chỗ — kết nối mạng thông suốt là điều kiện cần, nhưng chưa đủ để DNS hoạt động.

Đáp án

A và E.

• A — Trong Security Group, thêm rule cho phép TCP cổng 443 từ nguồn 0.0.0.0/0
• E — Trong Network ACL, cho phép inbound TCP 443 từ 0.0.0.0/0 và outbound TCP 32768–65535 tới 0.0.0.0/0

Vì sao đúng

Đề mô tả tình huống có hai lớp lọc đều đang chặn, nên phải mở cả hai: | Lớp | Trạng thái hiện tại | Cần làm | |---|---|---| | Security group (mặc định) | chặn mọi lưu lượng VÀO | A — thêm rule inbound 443 | | Network ACL (không mặc định) | chặn cả vào lẫn ra | E — mở inbound 443 và outbound cổng tạm |

A — security group là STATEFUL, nên chỉ cần một rule:

Rule inbound: TCP 443 từ 0.0.0.0/0
    → request vào được
    → PHẢN HỒI tự động được phép ra
    → KHÔNG cần rule outbound

(Security group mặc định đã cho phép mọi lưu lượng ra, nên phương án C là thừa.)

E — network ACL là STATELESS, nên phải mở CẢ HAI chiều:

Chiều VÀO:  TCP 443 từ 0.0.0.0/0          → request tới được
Chiều RA:   TCP 32768–65535 tới 0.0.0.0/0  → PHẢN HỒI đi về được

Vì sao chiều ra là cổng 32768–65535 chứ không phải 443:

Client mở kết nối:
    IP client : cổng tạm (ví dụ 54321)  ──▶  máy chủ : 443
Máy chủ trả lời:
    máy chủ : 443  ──▶  IP client : cổng tạm 54321
                                    ↑
              phản hồi đi TỚI cổng tạm của client, không phải 443

Đó là lý do rule outbound phải mở dải cổng tạm (ephemeral port).

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

• **B. Trong Network ACL, cho phép cả inbound lẫn outbound TCP 443 — đây là phương án gần nhất và nửa đầu đúng, nhưng nửa sau sai cổng: phản hồi từ máy chủ đi tới cổng tạm của client, không phải cổng 443. Rule này không cho phản hồi đi ra được, và kết nối sẽ treo.
• **C. Trong Security Group, tạo rule cho phép TCP 443 tới đích 0.0.0.0/0 — thừa và sai chiều: đó là rule outbound, mà security group mặc định đã cho phép mọi lưu lượng ra. Và vì SG là stateful nên phản hồi không cần rule riêng.
• **D. Trong Network ACL, chỉ cho phép outbound cổng tạm — thiếu một nửa: không có rule inbound cho cổng 443 thì request không vào được ngay từ đầu.

Ghi nhớ

Stateful và stateless — khác biệt quyết định: | | Security group | Network ACL | |---|---|---| | Trạng thái | STATEFUL | STATELESS | | Phản hồi | tự động được phép | phải có rule riêng cho cổng tạm | | Số rule cần cho một dịch vụ | 1 (inbound) | 2 (inbound + outbound cổng tạm) | | Áp ở mức | ENI/instance | subnet | | Loại rule | chỉ Allow | Allow và Deny | | Đánh giá | mọi rule | theo thứ tự số, dừng ở rule đầu khớp |

Dải cổng tạm khác nhau theo hệ điều hành: | Hệ thống | Dải | |---|---| | Linux nhân hiện đại | 32768–60999 | | Windows Server 2008 trở lên | 49152–65535 | | Elastic Load Balancer | 1024–65535 | | NAT Gateway | 1024–65535 |

Mở 32768–65535 phủ được hầu hết trường hợp; nếu có ELB hoặc NAT gateway trong đường đi thì mở 1024–65535 để chắc chắn.

Bộ rule NACL tối thiểu cho web server HTTPS:

INBOUND
  100 | HTTPS (443)             | 0.0.0.0/0 | ALLOW
  110 | Custom TCP 32768-65535  | 0.0.0.0/0 | ALLOW  ← phản hồi cho kết nối RA
  *   | ALL                     | 0.0.0.0/0 | DENY

OUTBOUND
  100 | HTTPS (443)             | 0.0.0.0/0 | ALLOW  ← gọi API bên ngoài
  110 | Custom TCP 32768-65535  | 0.0.0.0/0 | ALLOW  ← phản hồi cho client
  *   | ALL                     | 0.0.0.0/0 | DENY

Rule inbound cổng tạm cần khi nào: khi chính instance khởi tạo kết nối ra ngoài (gọi API, cập nhật gói phần mềm) — phản hồi từ máy chủ bên ngoài quay về sẽ tới cổng tạm của instance.

Bốn mặc định cần nhớ: | Đối tượng | Mặc định | |---|---| | Security group mặc định của VPC | chặn inbound từ ngoài, cho phép giữa các thành viên cùng nhóm; cho phép mọi outbound | | Security group bạn TỰ TẠO | chặn mọi inbound; cho phép mọi outbound | | NACL mặc định của VPC | CHO PHÉP mọi lưu lượng hai chiều | | NACL bạn TỰ TẠO | CHẶN mọi lưu lượng hai chiều |

Dòng cuối là nguyên nhân của rất nhiều sự cố khó chẩn đoán, và chính là tình huống của đề: NACL không mặc định đang chặn hết.

Kỹ thuật chẩn đoán khi kết nối bị chặn: | Triệu chứng | Nghi ngờ | |---|---| | Timeout, không có phản hồi nào | security group hoặc NACL chặn | | Connection refused | tới được máy nhưng không có dịch vụ nghe cổng đó | | Chỉ MỘT instance hỏng | security group của instance đó | | CẢ SUBNET hỏng | NACL hoặc route table | | Kết nối được rồi treo giữa chừng | thường là NACL thiếu rule cổng tạm |

Dòng cuối là dấu hiệu đặc trưng của lỗi cổng tạm: bắt tay TCP thành công nhưng dữ liệu không đi về được.

Công cụ chẩn đoán tốt nhất: VPC Flow Logs.

Bản ghi có ACCEPT/REJECT cho từng luồng
    → REJECT ở chiều nào cho biết lớp nào chặn

aws ec2 create-flow-logs --resource-type Subnet --resource-ids subnet-0abc   --traffic-type ALL --log-destination-type cloud-watch-logs   --log-group-name /vpc/flow-logs

Và một lời khuyên thiết kế: chỉ dùng NACL khi thực sự cần rule DENY. Security group đủ cho phần lớn nhu cầu, và nó stateful nên ít sai sót hơn hẳn. NACL tuỳ chỉnh nên dành cho việc chặn dải IP cụ thể hoặc làm lớp phòng thủ bổ sung ở mức subnet.

Đáp án

A — Sửa cấu hình DB instance và bật storage autoscaling.

Vì sao đúng

Đề cần tăng dung lượng đĩa mà không ảnh hưởng hiệu năng, với ÍT CÔNG VẬN HÀNH NHẤT — và storage autoscaling giải quyết cả ba.

Cách nó hoạt động:

RDS theo dõi dung lượng còn trống liên tục
    ↓
Còn dưới 10% VÀ tình trạng đó kéo dài ít nhất 5 phút
    ↓
TỰ ĐỘNG tăng dung lượng thêm 10 GB hoặc 10% (lấy giá trị lớn hơn)
    ↓
KHÔNG có thời gian ngừng, không ảnh hưởng hiệu năng

Và nó giải quyết vấn đề tận gốc chứ không chỉ lần này:

Tăng dung lượng thủ công:
    → hết chỗ lần nữa sau vài tháng
    → lại phải can thiệp
    → và nếu không ai để ý → database DỪNG HOẠT ĐỘNG

Storage autoscaling:
    → tự xử lý MÃI VỀ SAU
    → chỉ cần đặt trần dung lượng tối đa

aws rds modify-db-instance --db-instance-identifier db-san-xuat   --max-allocated-storage 1000 --apply-immediately

Chỉ cần khai max-allocated-storage — đó là trần an toàn để một lỗi ứng dụng ghi vô hạn không làm hoá đơn tăng không kiểm soát.

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

• **B. Tăng dung lượng đã cấp cho DB instance — đây là phương án gần nhất và có tác dụng thật, nhưng nó nhiều công hơn và chỉ chữa một lần: thao tác thủ công, phải theo dõi để biết khi nào cần làm lại, và có nguy cơ quên tới lúc database đầy đĩa. Ngoài ra RDS có giới hạn 6 giờ giữa hai lần đổi dung lượng, nên không phải muốn tăng lúc nào cũng được.
• **D. Đổi loại lưu trữ sang Provisioned IOPS — giải quyết vấn đề khác: io1/io2 cải thiện hiệu năng I/O, không phải dung lượng. Và việc đổi loại lưu trữ tốn kém hơn nhiều.
• **C. Đổi default_storage_engine sang MyISAM — rất tệ và không liên quan: MyISAM không hỗ trợ giao dịch, không có khoá mức dòng, dễ hỏng dữ liệu khi sự cố. Và nó không tăng dung lượng đĩa. Đây là thay đổi có hại cho một database sản xuất.

Ghi nhớ

Ba điều kiện để storage autoscaling kích hoạt: | Điều kiện | Chi tiết | |---|---| | Dung lượng trống dưới 10% | của tổng đã cấp | | Tình trạng kéo dài ít nhất 5 phút | tránh phản ứng với đột biến ngắn | | Đã qua ít nhất 6 giờ kể từ lần tăng trước | giới hạn tần suất |

Mức tăng mỗi lần: 10 GB, 10% dung lượng hiện tại, hoặc mức đủ dùng cho 7 giờ tới — lấy giá trị LỚN NHẤT.

Ba giới hạn quan trọng của RDS storage: | Giới hạn | Chi tiết | |---|---| | Chỉ TĂNG được, không giảm | muốn giảm phải tạo instance mới và di chuyển dữ liệu | | 6 giờ giữa hai lần đổi | kể cả thủ công | | Dung lượng tối đa | 64 TB (tuỳ engine) |

Dòng đầu là lý do nên đặt max-allocated-storage cẩn thận: autoscaling chỉ đi một chiều, và dung lượng đã tăng thì trả tiền mãi cho tới khi bạn tái tạo instance.

Ba loại lưu trữ của RDS: | Loại | Đặc điểm | Phù hợp | |---|---|---| | gp3 (General Purpose SSD) | IOPS và throughput cấu hình ĐỘC LẬP với dung lượng | mặc định tốt cho hầu hết workload | | gp2 | IOPS gắn với dung lượng (3 IOPS/GB) | thế hệ cũ | | io1/io2 (Provisioned IOPS) | IOPS cao nhất, độ trễ thấp nhất | database I/O rất nặng | | Magnetic | thế hệ cũ | không dùng cho mới |

gp3 là cải tiến quan trọng so với gp2: với gp2, muốn nhiều IOPS thì phải mua nhiều dung lượng — nhiều người cấp 1 TB chỉ để có đủ IOPS dù dữ liệu chỉ 100 GB. gp3 tách hai thứ đó ra.

Ba metric cần đặt alarm cho RDS: | Metric | Cảnh báo khi | |---|---| | FreeStorageSpace | dưới 15–20% — trước khi autoscaling phải can thiệp | | CPUUtilization | trên 80% kéo dài | | DatabaseConnections | tiến gần max_connections | | ReadLatency / WriteLatency | tăng đột biến |

Đặt alarm cho FreeStorageSpace vẫn cần thiết dù đã bật autoscaling: nếu dung lượng chạm trần max-allocated-storage, autoscaling ngừng hoạt động và bạn cần biết trước khi database đầy.

Điều gì xảy ra khi RDS hết đĩa hoàn toàn:

Instance chuyển sang trạng thái storage-full
    → database KHÔNG GHI ĐƯỢC nữa
    → ứng dụng lỗi hàng loạt
    → phải tăng dung lượng thủ công rồi chờ instance khôi phục

Đây là sự cố nghiêm trọng và hoàn toàn tránh được — đó là lý do storage autoscaling nên bật mặc định cho mọi instance sản xuất.

Ba nguyên nhân phổ biến khiến RDS hết đĩa: | Nguyên nhân | Cách kiểm tra | |---|---| | Dữ liệu tăng tự nhiên | theo dõi xu hướng FreeStorageSpace | | Binary log hoặc WAL tích tụ | replica bị treo khiến log không được dọn | | Bảng tạm hoặc log chậm phình to | kiểm tra cấu hình slow_query_log |

Dòng giữa là nguyên nhân âm thầm hay gặp: một read replica ngừng đồng bộ khiến primary phải giữ lại toàn bộ binary log chờ nó đọc — dung lượng tăng rất nhanh mà dữ liệu thật không đổi.

Và một lời khuyên: kết hợp autoscaling với việc dọn dẹp định kỳ. Autoscaling ngăn sự cố nhưng không giải quyết nguyên nhân; nếu dung lượng tăng vì log không được xoay vòng hay dữ liệu cũ không được lưu trữ, chi phí sẽ tăng đều đặn mà không ai chú ý.

Đáp án

C — Tạo Amazon S3 gateway endpoint để instance kết nối tới S3.

Vì sao đúng

Đề nêu hai yêu cầu, và gateway endpoint đáp ứng cả hai một cách tối ưu: | Yêu cầu | Cơ chế | |---|---| | Instance chuyển vào private subnet nhưng vẫn dùng S3 | endpoint cho phép truy cập S3 không cần Internet | | GIẢM CHI PHÍ truyền dữ liệu | gateway endpoint HOÀN TOÀN MIỄN PHÍ |

Điểm mấu chốt: gateway endpoint không tính phí gì cả.

Gateway endpoint (S3 và DynamoDB):
    ✓ Không phí giờ
    ✓ Không phí xử lý dữ liệu
    ✓ HOÀN TOÀN MIỄN PHÍ

So với NAT gateway thì chênh lệch rất lớn:

NAT Gateway:
    ~0,045 USD mỗi giờ         → ~32 USD/tháng chỉ để tồn tại
  + ~0,045 USD mỗi GB xử lý    → 10 TB/tháng = ~450 USD
                                 ────────────────────────
                                 ~482 USD/tháng

S3 Gateway Endpoint:
    0 USD

Cách nó hoạt động — chỉ là một route:

Tạo gateway endpoint
    → AWS thêm route vào route table của subnet
    → prefix list của S3 (pl-xxxx) → vpce-xxxx
    → lưu lượng tới S3 đi qua MẠNG NỘI BỘ của AWS
    → không ra Internet, không qua NAT

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc123   --service-name com.amazonaws.ap-southeast-1.s3   --route-table-ids rtb-private-1 rtb-private-2

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

• **B. Tạo S3 INTERFACE endpoint — đây là phương án gần nhất và cũng cho phép truy cập S3 riêng tư, nhưng nó TỐN TIỀN: interface endpoint tính phí theo giờ cho mỗi AZ cộng phí xử lý mỗi GB. Với yêu cầu "MOST cost-efficient", gateway endpoint miễn phí thắng rõ ràng.
• **A. Đặt NAT Gateway trong public subnet để kết nối tới S3 — đắt nhất trong các phương án: vừa tốn phí giờ vừa tốn phí mỗi GB, và lưu lượng đi vòng ra Internet rồi quay lại — không cần thiết khi đích là dịch vụ của chính AWS.
• **D. Dùng AWS Transit Gateway để truy cập S3 — sai công cụ: TGW là trung tâm định tuyến giữa các VPC và mạng tại chỗ. Nó không phải cách kết nối tới S3, và cũng tính phí attachment cùng phí xử lý dữ liệu.

Ghi nhớ

Hai loại VPC endpoint — bảng phân biệt cốt lõi: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ hỗ trợ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Chi phí | MIỄN PHÍ | phí giờ + phí mỗi GB | | Cơ chế | route trong route table | ENI có IP riêng trong subnet | | Truy cập từ tại chỗ (qua DX/VPN) | ❌ KHÔNG | ✅ CÓ | | Dùng được qua VPC peering | ❌ | ✅ | | DNS | dùng tên miền công khai của S3 | có DNS riêng tư |

"Chỉ S3 và DynamoDB" là điều cần thuộc lòng — mọi dịch vụ khác đều dùng interface endpoint.

Khi nào phải dùng interface endpoint cho S3 dù nó tốn tiền: | Tình huống | Lý do | |---|---| | Truy cập S3 từ trung tâm dữ liệu qua Direct Connect | gateway endpoint không hoạt động ngoài VPC | | Truy cập từ VPC khác qua peering | gateway endpoint không đi qua peering | | Cần địa chỉ IP riêng tư cho S3 | tường lửa tại chỗ lọc theo IP |

Ba lợi ích của VPC endpoint ngoài chi phí: | Lợi ích | Chi tiết | |---|---| | Bảo mật | lưu lượng KHÔNG BAO GIỜ ra Internet | | Hiệu năng | đi trong mạng AWS, ổn định hơn | | Kiểm soát bằng endpoint policy | giới hạn endpoint chỉ truy cập được bucket cụ thể |

Endpoint policy là công cụ bảo mật mạnh mà nhiều người bỏ qua:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": ["arn:aws:s3:::kho-cua-cong-ty/*"]}]}

Nó ngăn instance dùng endpoint để tải dữ liệu lên bucket của người khác — một biện pháp chống rò rỉ dữ liệu hiệu quả.

Và ở chiều ngược lại, bucket policy giới hạn theo endpoint:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": "arn:aws:s3:::kho-cua-cong-ty/*",
 "Condition": {"StringNotEquals": {"aws:sourceVpce": "vpce-0abc123"}}}

Bucket chỉ truy cập được qua đúng endpoint đó — kể cả người có thông tin đăng nhập hợp lệ cũng không tải dữ liệu về từ ngoài được.

Ba lưu ý khi triển khai gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Phải gắn vào ĐÚNG route table | quên một route table nghĩa là subnet đó vẫn đi qua NAT | | Chỉ hoạt động trong cùng Region | S3 ở Region khác vẫn phải đi Internet | | Không thay thế được IAM | endpoint là đường đi, quyền vẫn do IAM và bucket policy quyết định |

Dòng đầu là lỗi triển khai phổ biến nhất: tạo endpoint xong nhưng chỉ gắn vào một route table, các subnet khác vẫn âm thầm đi qua NAT gateway và tiếp tục tính phí.

Cách kiểm chứng endpoint đang hoạt động:

# Trên instance, xem lưu lượng có đi qua NAT không
aws s3 ls s3://kho-cua-cong-ty --debug 2>&1 | grep -i endpoint
# Hoặc kiểm tra route table
aws ec2 describe-route-tables --route-table-ids rtb-private-1

Và một lời khuyên tối ưu chi phí rộng hơn: sau khi đặt gateway endpoint cho S3 và DynamoDB, hãy xem VPC Flow Logs để biết còn lưu lượng nào đi qua NAT gateway. Các dịch vụ hay tốn tiền qua NAT là ECR (kéo image container), CloudWatch Logs, và Systems Manager — cả ba đều có interface endpoint, và với khối lượng lớn thì phí endpoint vẫn rẻ hơn phí NAT.

Đáp án

A — Dùng AWS Database Migration Service (AWS DMS) để di chuyển sang một database Aurora Serverless mới.

Vì sao đúng

Đề nêu hai ràng buộc, và DMS là cách duy nhất đáp ứng cả hai: | Ràng buộc | Cơ chế | |---|---| | GIẢM THIỂU thời gian ngừng | DMS sao chép LIÊN TỤC (CDC) trong khi nguồn vẫn chạy | | Ít ảnh hưởng tới hoạt động của ứng dụng | ứng dụng dùng database cũ tới phút cuối |

Cách DMS giảm thời gian ngừng xuống mức tối thiểu:

① Tải đầy đủ (full load): sao chép dữ liệu hiện có
    → database nguồn VẪN PHỤC VỤ bình thường
② CDC (change data capture): bắt mọi thay đổi phát sinh
    → hai bên đồng bộ liên tục
③ Cắt chuyển: dừng ghi vào nguồn, chờ CDC bắt kịp,
   đổi chuỗi kết nối của ứng dụng
    → thời gian ngừng chỉ là VÀI PHÚT

So với việc khôi phục từ snapshot:

Snapshot:
    chụp → khôi phục (mất hàng chục phút tới hàng giờ với DB lớn)
    → mọi thay đổi TRONG khoảng đó bị MẤT
    → phải dừng ghi từ lúc chụp → thời gian ngừng RẤT DÀI

Và DMS còn cho phép kiểm chứng trước khi cắt chuyển:

Bật data validation → DMS so sánh từng dòng giữa nguồn và đích
    → biết chắc dữ liệu khớp trước khi chuyển ứng dụng sang

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

• **D. Thêm Aurora Replica với instance class là Serverless, failover sang replica rồi promote — đây là phương án gần nhất về mặt ý tưởng chuyển đổi mượt, nhưng nó không dựng được như mô tả: Aurora Serverless v1 là kiểu cluster riêng, không phải một instance class thêm vào cluster provisioned. (Aurora Serverless v2 thì khác — xem ghi chú bên dưới.)
• **C. Chụp snapshot rồi tạo cluster Aurora mới từ đó — hoạt động được nhưng thời gian ngừng dài: mọi thay đổi sau thời điểm chụp đều mất, nên phải dừng ứng dụng từ lúc bắt đầu chụp cho tới khi khôi phục xong.
• **B. Đổi instance class của Aurora sang Serverless — không phải thao tác hợp lệ với Aurora Serverless v1: không có instance class nào tên là "Serverless" để chọn trong cluster provisioned.

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

Đáp án này phản ánh Aurora Serverless v1. Với Aurora Serverless v2 (ra mắt 2022), tình hình đã khác hẳn:

Aurora Serverless v2 dùng instance class db.serverless
    → THÊM ĐƯỢC vào cluster provisioned đang chạy
    → trộn lẫn instance provisioned và serverless trong cùng cluster
    → chuyển đổi bằng cách thêm reader serverless rồi failover
    → thời gian ngừng chỉ khoảng 30 giây

Nghĩa là với Aurora Serverless v2, phương án D mô tả đúng quy trình được khuyến nghị hiện nay. Đáp án A vẫn đúng theo bộ đề và vẫn là cách hợp lệ, nhưng nếu gặp tình huống này trong thực tế hôm nay, hãy kiểm tra phiên bản Serverless trước khi chọn cách làm.

Ghi nhớ

Aurora Serverless v1 và v2: | | v1 | v2 | |---|---|---| | Mở rộng | theo bậc ACU, có gián đoạn | liên tục, mượt, tính bằng giây | | Về 0 khi rảnh | ✅ (tạm dừng hoàn toàn) | ❌ tối thiểu 0,5 ACU | | Trộn với instance provisioned | ❌ | ✅ | | Read replica | ❌ | ✅ tới 15 | | Global Database, RDS Proxy | ❌ | ✅ | | Phù hợp | dev/test, tải rất thưa | sản xuất, tải biến động |

Với tình huống của đề — tải bình thường ổn định nhưng tăng vọt khi có đợt giảm giá chớp nhoáng — Aurora Serverless v2 là lựa chọn rất hợp lý: nó mở rộng trong vài giây mà không gián đoạn kết nối.

Ba thành phần của AWS DMS: | Thành phần | Việc | |---|---| | Replication instance | máy chạy tiến trình sao chép | | Endpoint | thông tin kết nối nguồn và đích | | Task | định nghĩa di chuyển gì, theo cách nào |

Ba chế độ của DMS task: | Chế độ | Việc | |---|---| | Full load | chỉ sao chép dữ liệu hiện có | | Full load + CDC | sao chép rồi tiếp tục đồng bộ — dùng cho di chuyển ít gián đoạn | | CDC only | chỉ đồng bộ thay đổi (dữ liệu đã có sẵn ở đích) |

Yêu cầu cho CDC: database nguồn phải bật binary log (MySQL) hoặc logical replication (PostgreSQL), và giữ log đủ lâu để DMS đọc kịp.

Ba lưu ý khi dùng DMS: | Lưu ý | Chi tiết | |---|---| | DMS chuyển DỮ LIỆU, không chuyển lược đồ đầy đủ | stored procedure, trigger, view phải làm riêng | | Bật validation để so sánh nguồn và đích | phát hiện sai lệch trước khi cắt chuyển | | Kích thước replication instance ảnh hưởng tốc độ | database lớn cần instance mạnh |

Với di chuyển giữa hai engine khác nhau, dùng thêm AWS Schema Conversion Tool (SCT) để chuyển lược đồ và mã. Trong đề này nguồn và đích đều là Aurora nên không cần.

Ba bước cắt chuyển an toàn:

① Dừng ghi vào database nguồn (đặt ứng dụng ở chế độ chỉ đọc)
② Chờ CDC latency về 0 — kiểm tra metric CDCLatencySource
③ Đổi chuỗi kết nối, khởi động lại ứng dụng

Metric CDCLatencyTarget là con số quyết định thời điểm cắt chuyển — nó cho biết đích còn tụt hậu bao nhiêu giây so với nguồn.

Và một lời khuyên vận hành cho hệ thống đăng ký trực tuyến như đề mô tả: hãy cắt chuyển vào thời điểm ít người dùng nhất, và chuẩn bị sẵn kế hoạch quay lui — giữ database cũ chạy thêm vài ngày trước khi xoá, để nếu phát sinh vấn đề thì đổi chuỗi kết nối ngược lại được ngay.