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

Đáp án

A và D.

• D — Amazon S3
• A — Amazon CloudFront

Vì sao đúng

Đề nêu ba yêu cầu, và cặp S3 + CloudFront là kiến trúc chuẩn cho cả ba: | Yêu cầu | Cơ chế | |---|---| | Giảm chi phí máy chủ | S3 — không có máy chủ nào để trả tiền | | Phân phối toàn cầu với độ trễ thấp | CloudFront — hơn 600 điểm biên | | Phân phối AN TOÀN cho người dùng trả phí và đối tác | signed URL và signed cookie |

Vì sao S3 thay máy chủ web là khoản tiết kiệm lớn:

Trước:  Đội EC2 phục vụ tệp tĩnh
        → trả tiền cho máy chạy 24/7 dù tải thấp
        → phải tự lo mở rộng và sẵn sàng cao

Sau:    S3 lưu và phục vụ trực tiếp
        → trả theo dung lượng thực dùng và số request
        → tự mở rộng, độ bền 11 số 9, dữ liệu trên nhiều AZ

Và CloudFront giải quyết cả độ trễ lẫn chi phí: | Lợi ích | Chi tiết | |---|---| | Cache ở biên gần người dùng | độ trễ thấp trên toàn cầu | | Giảm request tới origin | ít lời gọi S3 hơn = rẻ hơn | | Phí truyền dữ liệu rẻ hơn S3 trực tiếp | khoản tiết kiệm thật với lưu lượng lớn | | Signed URL / signed cookie | kiểm soát ai xem được nội dung |

Vế "securely deliver" được đáp ứng bằng hai cơ chế đi cùng nhau:

OAC (Origin Access Control)  → S3 bucket RIÊNG TƯ, chỉ CloudFront đọc được
Signed URL / signed cookie   → chỉ người dùng trả phí xem được nội dung

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

• **E. AWS Global Accelerator — đây là phương án gần nhất về mặt cũng là dịch vụ biên toàn cầu, nhưng nó tối ưu cho TCP/UDP không phải HTTP (game, VoIP, IoT) và KHÔNG CACHE nội dung. Với tệp tĩnh, CloudFront thắng rõ ràng vì nó phục vụ từ cache thay vì chuyển tiếp mọi request về origin.
• **B. AWS Fargate — là dịch vụ tính toán container: nó vẫn là "máy chủ" cần trả tiền, trái yêu cầu "reduce server costs". Và nó không phân phối nội dung toàn cầu.
• **C. AWS Lambda — cùng vấn đề: đây là dịch vụ tính toán, không phải lưu trữ hay phân phối. (Lambda@Edge có vai trò bổ trợ cho CloudFront, nhưng nó không thay thế được S3 lẫn CloudFront.)

Ghi nhớ

Kiến trúc phục vụ nội dung tĩnh chuẩn của AWS:

Người dùng toàn cầu
    ↓
CloudFront (cache ở biên, WAF, signed URL)
    ↓ OAC
S3 bucket RIÊNG TƯ (lưu trữ, độ bền 11 số 9)

Đây là mẫu xuất hiện liên tục trong đề thi — nhận ra nó là trả lời được rất nhiều câu.

Ba dịch vụ biên toàn cầu — chọn đúng: | Dịch vụ | Giao thức | Cache | Dùng cho | |---|---|---|---| | CloudFront | HTTP/HTTPS | ✅ | nội dung tĩnh và động qua web | | Global Accelerator | TCP/UDP | ❌ | game, VoIP, ứng dụng không phải HTTP | | Route 53 | DNS | — | định tuyến ở tầng DNS |

Từ khoá phân biệt:

"static content", "images", "videos", "website", "cache" → CloudFront "TCP/UDP", "gaming", "static IP", "non-HTTP" → Global Accelerator

Ba cách kiểm soát truy cập nội dung trên CloudFront: | Cách | Phạm vi | |---|---| | Signed URL | một tệp, có thời hạn | | Signed cookie | nhiều tệp theo mẫu đường dẫn — URL không đổi | | Geo restriction | theo quốc gia, MIỄN PHÍ |

Với đề này — "premium users" và "partners who syndicate media files" — signed cookie thường phù hợp hơn: người dùng trả phí xem cả một thư viện, và không phải ký lại URL cho từng tệp.

Hai cơ chế bảo vệ S3 origin: | Cơ chế | Trạng thái | |---|---| | Origin Access Control (OAC) | KHUYẾN NGHỊ hiện nay | | Origin Access Identity (OAI) | cơ chế cũ |

OAC hơn OAI ở chỗ nó hỗ trợ SSE-KMS — OAI không đọc được object mã hoá bằng KMS key, và triệu chứng là lỗi 403 khó hiểu.

Ba cách tối ưu chi phí thêm cho kiến trúc này: | Cách | Tiết kiệm | |---|---| | Đặt Cache-Control: max-age dài | ít request tới origin hơn | | Chọn price class phù hợp | PriceClass_100 chỉ dùng edge Bắc Mỹ và châu Âu | | S3 Intelligent-Tiering cho tệp ít xem | tự chuyển tầng lưu trữ |

Price class đáng cân nhắc: nếu phần lớn người dùng ở vài khu vực, giới hạn edge location giảm chi phí đáng kể — nhưng đề nói "customers globally", nên PriceClass_All có thể là đúng ở đây.

Và một lưu ý bảo mật quan trọng: đặt CloudFront trước S3 chỉ có ý nghĩa nếu bucket thực sự riêng tư. Nếu bucket vẫn công khai, người ta gọi thẳng URL S3 và bỏ qua toàn bộ signed URL, WAF và geo restriction — bật Block Public Access cùng với OAC là bắt buộc.

Đáp án

B — Tạo một SQS queue cho thành viên miễn phí và một queue khác cho thành viên trả phí. Cấu hình EC2 instance đọc thông điệp từ queue trả phí TRƯỚC, và chỉ khi nó rỗng thì mới đọc từ queue miễn phí.

Vì sao đúng

Đề cần ưu tiên xử lý cho thành viên trả phí — và mấu chốt là: SQS KHÔNG có khái niệm độ ưu tiên trong một queue.

Vì sao không thể đặt ưu tiên trong một queue:

SQS Standard queue:
    → thông điệp được lấy ra theo thứ tự GẦN ĐÚNG với thứ tự gửi
    → KHÔNG có trường "priority"
    → KHÔNG có cách nào bảo consumer "lấy thông điệp này trước"

Giải pháp là dùng NHIỀU QUEUE và để consumer quyết định thứ tự đọc:

Request từ thành viên trả phí → queue-tra-phi
Request từ thành viên miễn phí → queue-mien-phi

Consumer (EC2):
    ① đọc từ queue-tra-phi
    ② nếu rỗng → đọc từ queue-mien-phi
    → thành viên trả phí LUÔN được xử lý trước

def lay_cong_viec():
    tin = sqs.receive_message(QueueUrl=QUEUE_TRA_PHI,
                              MaxNumberOfMessages=10, WaitTimeSeconds=1)
    if tin.get('Messages'):
        return tin['Messages'], QUEUE_TRA_PHI
    tin = sqs.receive_message(QueueUrl=QUEUE_MIEN_PHI,
                              MaxNumberOfMessages=10, WaitTimeSeconds=20)
    return tin.get('Messages', []), QUEUE_MIEN_PHI

Chú ý WaitTimeSeconds khác nhau ở hai queue — đây là chi tiết thực dụng: queue ưu tiên dùng thời gian chờ ngắn (kiểm tra nhanh rồi chuyển sang queue kia), còn queue thường dùng long polling đầy đủ để tiết kiệm lời gọi API.

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

• **A. Đặt độ ưu tiên cao hơn trong SQS queue cho request của thành viên trả phí để nó được xử lý trước — đây là phương án gần nhất và mô tả đúng điều bạn MUỐN, nhưng nó mô tả một tính năng không tồn tại: SQS không có thuộc tính priority cho thông điệp.
• **C. Dùng Amazon Kinesis xử lý ảnh và tạo video theo thời gian thực — nhầm loại bài toán: Kinesis dành cho luồng dữ liệu thời gian thực với nhiều consumer và khả năng phát lại. Việc tạo video montage là tác vụ dài, nặng tính toán — đúng mô hình hàng đợi công việc, không phải xử lý luồng. Và nó không giải quyết vấn đề ưu tiên.
• **D. Dùng Amazon S3 để lưu và xử lý ảnh rồi tạo video sau đó — S3 không xử lý gì cả: nó là kho lưu trữ. Và phương án không đề cập gì tới cơ chế ưu tiên.

Ghi nhớ

Nguyên tắc quan trọng nhất từ câu này:

SQS không có độ ưu tiên trong một queue. Cần ưu tiên → dùng NHIỀU QUEUE và cho consumer quyết định thứ tự đọc.

Hai loại SQS queue: | Loại | Đặc điểm | |---|---| | Standard | thông lượng gần như không giới hạn, thứ tự gần đúng, có thể trùng | | FIFO | đúng thứ tự, xử lý chính xác một lần, giới hạn 3.000 thông điệp/giây (có batching) |

FIFO đảm bảo THỨ TỰ, không phải ĐỘ ƯU TIÊN — đây là hai khái niệm khác nhau và hay bị nhầm.

Ba cấu hình quan trọng của SQS: | Cấu hình | Việc | |---|---| | VisibilityTimeout | thời gian thông điệp bị ẩn khi đang xử lý — đặt DÀI HƠN thời gian xử lý | | Long polling (ReceiveMessageWaitTimeSeconds) | tới 20 giây — giảm lời gọi API rỗng và chi phí | | Dead-letter queue | thông điệp lỗi sau N lần thử chuyển sang đây |

VisibilityTimeout đặc biệt quan trọng cho tình huống này: tạo video montage mất nhiều phút. Nếu timeout là 30 giây, thông điệp sẽ xuất hiện lại và bị xử lý lặp — sinh ra nhiều video trùng nhau.

# Gia hạn khi công việc còn đang chạy
sqs.change_message_visibility(QueueUrl=q, ReceiptHandle=rh,
                              VisibilityTimeout=600)

Ba cách mở rộng consumer theo tải: | Cách | Metric | |---|---| | ASG target tracking | ApproximateNumberOfMessagesVisible chia số instance | | Backlog per instance | chỉ báo trực tiếp nhất | | ECS service auto scaling | tương tự cho container |

Với hai queue, bạn mở rộng độc lập được: đội máy xử lý queue trả phí có thể lớn hơn và phản ứng nhanh hơn — một cách cụ thể hoá "guaranteed faster processing" mà đề hứa với khách hàng.

Ba mẫu kiến trúc dùng SQS: | Mẫu | Chi tiết | |---|---| | Work queue | nhiều worker chia nhau công việc ← câu này | | Fan-out (SNS → nhiều SQS) | một sự kiện tới nhiều hệ thống | | Buffer trước cơ sở dữ liệu | hấp thụ đợt ghi đột biến |

Và một cải thiện đáng cân nhắc cho thiết kế này: nếu số lượng bậc dịch vụ tăng lên (miễn phí, cơ bản, cao cấp, doanh nghiệp), việc lặp qua nhiều queue theo thứ tự sẽ trở nên vụng về. Khi đó AWS Step Functions hoặc một hệ thống hàng đợi có hỗ trợ ưu tiên gốc sẽ phù hợp hơn — nhưng với hai bậc như đề mô tả, hai queue là giải pháp đơn giản và hiệu quả nhất.

Đáp án

C — Tạo bucket S3 Standard với S3 Object Lock ở chế độ COMPLIANCE, rồi cấu hình lifecycle rule chuyển tệp sang Amazon S3 Glacier Deep Archive sau 3 năm.

Vì sao đúng

Đề nêu ba yêu cầu, và C đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Giữ được trạng thái cũ khi tệp bị sửa | Object Lock BẮT BUỘC bật versioning | | Tuân thủ quy định: dữ liệu trên 3 năm phải được lưu trữ | Object Lock COMPLIANCE + lifecycle | | Sau đó chỉ truy cập một lần mỗi năm | Glacier Deep Archive |

Điểm mấu chốt: Object Lock tự động bao gồm versioning — nên một cấu hình giải quyết cả hai yêu cầu đầu:

Bật Object Lock
    → BẮT BUỘC bật versioning (không tắt được)
    → mọi lần ghi đè tạo phiên bản mới, bản cũ giữ nguyên   ← yêu cầu 1
    → chế độ COMPLIANCE khiến không ai xoá được             ← yêu cầu 2

Và "regulatory compliance" là từ khoá nghiêng về Object Lock thay vì versioning thuần:

Versioning một mình:
    → giữ được bản cũ
    → NHƯNG người có quyền vẫn xoá vĩnh viễn phiên bản được
    → không chứng minh được tính bất biến với cơ quan quản lý

Object Lock COMPLIANCE:
    → KHÔNG AI xoá được, kể cả root user
    → là bằng chứng tuân thủ chấp nhận được

aws s3api create-bucket --bucket ho-so-quy-dinh --object-lock-enabled-for-bucket

aws s3api put-object-lock-configuration --bucket ho-so-quy-dinh   --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Years": 3}}}'

Lifecycle rule cho giai đoạn lưu trữ dài hạn:

{"Rules": [{"Status": "Enabled",
  "Transitions": [{"Days": 1095, "StorageClass": "DEEP_ARCHIVE"}]}]}

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

• A. Bucket S3 Standard với object-level versioning và lifecycle chuyển sang Deep Archive sau 3 năm — đây là phương án gần nhất và đáp ứng được yêu cầu giữ phiên bản cũ lẫn chuyển tầng lưu trữ, nhưng nó thiếu tính bất biến mà yêu cầu tuân thủ đòi hỏi. Xem ghi chú cuối bài.
• **B. Bucket S3 Standard và bật Object Lock ở chế độ GOVERNANCE — hai vấn đề: GOVERNANCE gỡ được bởi người có quyền s3:BypassGovernanceRetention; và nó hoàn toàn thiếu vế chuyển sang lưu trữ dài hạn.
• D. Bucket One-Zone-IA với versioning và lifecycle chuyển sang Deep Archive — One Zone-IA chỉ lưu ở MỘT AZ, trái yêu cầu "highly available". Và vẫn thiếu tính bất biến.

Ghi nhớ

Hai chế độ của Object Lock: | | GOVERNANCE | COMPLIANCE | |---|---|---| | Gỡ trước hạn | ✅ với quyền bypass | ❌ KHÔNG AI — kể cả root | | Rút ngắn thời hạn | ✅ | ❌ | | Dùng khi | bảo vệ khỏi xoá nhầm | yêu cầu pháp lý |

Cảnh báo về COMPLIANCE: đặt nhầm thời hạn nghĩa là trả tiền lưu trữ đủ thời hạn đó — AWS Support cũng không gỡ hộ. Luôn kiểm thử ở GOVERNANCE trước.

Object Lock hoạt động ở MỌI lớp lưu trữ — đây là điều khiến phương án C khả thi: object bị khoá vẫn chuyển sang Deep Archive được, giữ được tính bất biến mà giảm mạnh chi phí.

Các lớp lưu trữ cho dữ liệu ít truy cập: | Lớp | Truy xuất | Chi phí | |---|---|---| | Standard-IA | mili giây | ~45% rẻ hơn Standard | | Glacier Instant Retrieval | mili giây | rẻ hơn | | Glacier Flexible Retrieval | 1 phút – 12 giờ | rẻ hơn nữa | | Glacier Deep Archive | 12–48 giờ | ~1 USD/TB/tháng |

Với "truy cập một lần mỗi năm", Deep Archive là lựa chọn đúng — thời gian chờ dài nhưng chi phí thấp nhất.

Ràng buộc thời gian lưu tối thiểu: | Lớp | Tối thiểu | |---|---| | Standard-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Glacier Deep Archive | 180 ngày |

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

Câu này gần như trùng lặp với câu #8182 trong cùng lô đề — cùng bộ phương án, cùng đáp án, chỉ khác cách diễn đạt yêu cầu.

Khác biệt duy nhất đáng kể nằm ở một cụm từ: | Câu | Cách diễn đạt | |---|---| | #8182 | "data retention in an IMMUTABLE STATE for at least 3 years" | | #8191 | "data over 3 years must be RETAINED in an archive" |

Ở #8182, chữ "immutable" khiến C là đáp án duy nhất đúng — không có gì để tranh luận.

Ở câu này, tính bất biến KHÔNG được nêu tường minh. Yêu cầu chỉ nói "giữ trạng thái cũ" (versioning làm được) và "lưu trữ để tuân thủ quy định" (lifecycle làm được). Đọc theo nghĩa đen, phương án A cũng đáp ứng đủ — và nó đơn giản hơn, ít rủi ro hơn (không có nguy cơ khoá nhầm dữ liệu vĩnh viễn).

Cách bênh cho C: cụm "meet regulatory compliance" trong ngữ cảnh lưu trữ dữ liệu thường hàm ý yêu cầu WORM, và Object Lock là cách duy nhất chứng minh điều đó.

Nếu gặp câu này trong đề thật: có chữ "immutable" hoặc "WORM" thì chọn Object Lock; chỉ nói "preserve previous version" thì versioning là đủ. Ở đây đề nằm giữa hai vế, nên hãy nhận biết sự mập mờ thay vì cho rằng mình hiểu sai.

Đáp án

A — Tạo một DynamoDB gateway endpoint và gắn nó vào route table phù hợp. Dùng AWS Backup để tự động sao chép các bản sao lưu on-demand của DynamoDB sang một tài khoản AWS khác phục vụ khôi phục thảm hoạ.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi vế của đáp án giải quyết một cái: | Yêu cầu | Cơ chế | |---|---| | Ngăn lời gọi cơ sở dữ liệu đi qua Internet công cộng | DynamoDB gateway endpoint | | Sao lưu tự động CHÉO TÀI KHOẢN, lưu trữ dài hạn | AWS Backup |

Vế đầu — DynamoDB dùng GATEWAY endpoint, không phải interface endpoint:

Gateway endpoint (MIỄN PHÍ):  CHỈ S3 và DynamoDB
                               → hoạt động qua ROUTE TABLE ENTRY

Interface endpoint (tính phí): hầu hết dịch vụ khác
                               → ENI trong subnet, qua PrivateLink

Nhớ đúng danh sách hai dịch vụ của gateway endpoint là điểm phân biệt của câu hỏi này.

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.us-east-1.dynamodb   --vpc-endpoint-type Gateway   --route-table-ids rtb-private-a rtb-private-b

Và vế "gắn vào route table phù hợp" là bước bắt buộc — gateway endpoint chỉ có tác dụng cho các subnet có route table trỏ tới nó.

Vế thứ hai — AWS Backup là dịch vụ duy nhất trong các phương án làm được sao lưu chéo tài khoản: | Khả năng | Chi tiết | |---|---| | Cross-account copy | sao chép bản sao lưu sang tài khoản khác | | Cross-Region copy | sang Region khác | | Backup Vault Lock | chế độ WORM — không ai xoá được bản sao lưu | | Quản lý tập trung | một chính sách cho DynamoDB, EBS, RDS, EFS |

Sao lưu ở tài khoản riêng là mô hình chống ransomware chuẩn: kẻ chiếm được tài khoản sản xuất không chạm tới được bản sao lưu.

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

• B. Tạo DynamoDB INTERFACE endpoint; bật Point-in-Time Recovery (PITR) để khôi phục sang tài khoản khác — đây là phương án gần nhất và sai ở hai điểm: DynamoDB dùng GATEWAY endpoint, không phải interface; và PITR KHÔNG khôi phục chéo tài khoản — nó chỉ khôi phục trong cùng tài khoản và cùng Region.
• **C. Tạo DynamoDB gateway endpoint; thiết lập NACL rule cho phép lưu lượng ra tới dynamodb.us-east-1.amazonaws.com; dùng bản sao lưu on-demand dựng sẵn cho sao lưu chéo tài khoản — hai lỗi: NACL làm việc với địa chỉ IP và CIDR, không với tên miền; và bản sao lưu on-demand của DynamoDB không tự sao chép chéo tài khoản — cần AWS Backup.
• **D. Tạo DynamoDB interface endpoint; AWS Network Firewall với stateless rule giới hạn lưu lượng ra; tích hợp DynamoDB với Amazon Timestream để khôi phục theo thời điểm từ tài khoản khác — nhiều lỗi: sai loại endpoint; và Timestream là cơ sở dữ liệu chuỗi thời gian, hoàn toàn không liên quan tới sao lưu DynamoDB.

Ghi nhớ

Hai loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ | Cơ chế | Chi phí | |---|---|---|---| | Gateway | CHỈ S3 và DynamoDB | route table entry | MIỄN PHÍ | | Interface | hầu hết dịch vụ khác | ENI (PrivateLink) | theo giờ + GB |

Gateway endpoint miễn phí và còn giúp tiết kiệm — nó loại bỏ lưu lượng đi qua NAT Gateway, nên không có lý do gì để không dùng.

Ba cách sao lưu DynamoDB: | Cách | Đặc điểm | Chéo tài khoản | |---|---|---| | PITR | khôi phục về bất kỳ giây nào trong 35 ngày | ❌ | | On-demand backup | ảnh chụp thủ công, giữ vô thời hạn | ❌ tự nó | | AWS Backup | quản lý tập trung, theo lịch, có vault lock | ✅ |

PITR là công cụ tuyệt vời cho lỗi con người (xoá nhầm bản ghi vài giờ trước), còn AWS Backup cho lưu trữ dài hạn và cách ly tài khoản — hai nhu cầu khác nhau, nên bật cả hai.

Ba khả năng của AWS Backup đáng biết: | Khả năng | Chi tiết | |---|---| | Backup plan theo lịch | tần suất, thời hạn giữ, chuyển sang cold storage | | Cross-account và cross-Region copy | ← câu này | | Backup Vault Lock | WORM — không ai xoá được bản sao lưu trước hạn |

Vault Lock là mảnh ghép chống ransomware mạnh nhất:

aws backup put-backup-vault-lock-configuration   --backup-vault-name vault-dr --min-retention-days 30   --max-retention-days 365 --changeable-for-days 3

Sau ba ngày, cấu hình khoá trở nên không thể thay đổi — kể cả bởi root user.

Các dịch vụ mà AWS Backup hỗ trợ:

DynamoDB, EBS, EC2, RDS, Aurora, EFS, FSx,
Storage Gateway, DocumentDB, Neptune, S3, Redshift

Ba lưu ý về endpoint policy cho gateway endpoint:

{"Effect": "Allow", "Principal": "*",
 "Action": ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query"],
 "Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/bang-cua-toi"}

Endpoint policy giới hạn những gì đi qua endpoint — một pod bị xâm nhập trong cụm EKS cũng không dùng endpoint để chạm tới bảng khác.

Và một chi tiết về kiến trúc trong đề: DAX cũng nằm trong VPC của bạn (nó là cụm node thật), nên lưu lượng ứng dụng → DAX vốn đã riêng tư. Gateway endpoint cần cho các lời gọi đi thẳng tới DynamoDB — ví dụ thao tác ghi, hoặc khi DAX cache miss và phải hỏi bảng gốc.

Đáp án

A và D.

• D — Kiểm tra security group có cho phép máy ứng dụng kết nối tới cơ sở dữ liệu đúng cổng và đúng giao thức không
• A — Kiểm tra Network ACL có cho phép giao tiếp giữa hai subnet không

Vì sao đúng

Đề mô tả hai instance trong cùng VPC, cùng AZ, nhưng khác subnet — và đó là hai lớp kiểm soát duy nhất có thể chặn chúng.

Trong cùng một VPC, mọi subnet đã được định tuyến tới nhau sẵn:

VPC tự động có một tuyến LOCAL trong mọi route table:
    Destination: 10.0.0.0/16   Target: local
    → mọi subnet trong VPC nói chuyện được với nhau
    → KHÔNG cần Internet Gateway, KHÔNG cần NAT

Nên chỉ còn hai lớp có thể chặn: | Lớp | Mức | Đặc điểm | |---|---|---| | Security group | ENI/instance | stateful, CHỈ Allow | | Network ACL | subnet | stateless, Allow và Deny |

D — security group là chỗ hay hỏng nhất:

Security group của CƠ SỞ DỮ LIỆU cần rule inbound:
    Type: MySQL/Aurora   Protocol: TCP   Port: 3306
    Source: sg-ung-dung   ← THAM CHIẾU security group của máy ứng dụng

Tham chiếu security group tốt hơn CIDR: instance thay đổi IP thì rule vẫn đúng.

A — NACL cần kiểm tra vì nó KHÔNG CÓ TRẠNG THÁI:

NACL của subnet CSDL:
    Inbound:  cho phép 3306 từ CIDR subnet ứng dụng
    Outbound: cho phép 1024–65535 về CIDR subnet ứng dụng  ← hay bị quên

Quên chiều outbound là lỗi kinh điển: request tới được nhưng phản hồi bị chặn, và triệu chứng là kết nối treo rồi timeout.

Và NACL tuỳ chỉnh mặc định CHẶN HẾT — khác hẳn NACL mặc định của VPC vốn cho phép mọi thứ.

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

• **C. Kiểm tra default route có trỏ tới NAT instance hoặc Internet Gateway để chúng giao tiếp — đây là phương án gần nhất về mặt cũng nói về định tuyến, nhưng nó hiểu sai cách VPC hoạt động: giao tiếp trong cùng VPC đi qua tuyến local có sẵn. IGW và NAT dành cho lưu lượng RA Internet.
• **B. Kiểm tra hai instance có cùng instance class không — không liên quan: loại instance quyết định CPU, bộ nhớ và băng thông, nó không ảnh hưởng tới khả năng kết nối.
• **E. Đảm bảo hai instance nằm trong cùng Placement Group — không cần thiết: placement group tối ưu độ trễ mạng và thông lượng cho workload HPC. Nó không phải điều kiện để hai instance nói chuyện được.

Ghi nhớ

Bảng phân biệt nền tảng nhất về mạng trong VPC: | | Security group | Network ACL | |---|---|---| | Mức | ENI/instance | subnet | | Trạng thái | STATEFUL — phản hồi tự động qua | STATELESS — phải mở CẢ HAI chiều | | Rule | CHỈ Allow | Allow VÀ Deny | | Đánh giá | tất cả rule | theo thứ tự số, dừng ở rule khớp đầu | | Nguồn chấp nhận | IP, CIDR, security group, prefix list | CHỈ CIDR | | Mặc định (VPC) | chặn inbound | cho phép hết | | Mặc định (tự tạo) | chặn inbound | CHẶN HẾT |

Hai dòng cuối là bẫy hay gặp: NACL bạn tự tạo chặn mọi thứ, khác hẳn NACL mặc định.

Danh sách kiểm tra khi hai instance trong VPC không kết nối được:

① Security group của ĐÍCH có rule inbound cho nguồn và cổng chưa?
② NACL của cả hai subnet thông CẢ HAI chiều chưa?
③ Ứng dụng có thực sự lắng nghe trên cổng đó không?  (ss -tlnp)
④ Route table có tuyến local không?  (mặc định là có)
⑤ Tường lửa của hệ điều hành (iptables, Windows Firewall)?
⑥ Instance có ở cùng VPC không?  (khác VPC cần peering hoặc TGW)

Bước ③ và ⑤ hay bị bỏ qua vì người ta chỉ nhìn vào cấu hình AWS — trong khi vấn đề nằm bên trong hệ điều hành.

Các cổng cần thuộc: | Cổng | Dịch vụ | |---|---| | 22 / 3389 | SSH / RDP | | 80 / 443 | HTTP / HTTPS | | 3306 | MySQL, MariaDB, Aurora MySQL | | 5432 | PostgreSQL | | 1433 / 1521 | SQL Server / Oracle | | 6379 / 11211 | Redis / Memcached | | 2049 / 445 | NFS (EFS) / SMB |

Nguyên tắc thiết kế security group cho ứng dụng nhiều tầng:

ALB     ← 443 từ 0.0.0.0/0
  ↓
Ứng dụng ← 80 từ sg-alb
  ↓
CSDL    ← 3306 từ sg-ung-dung

Mỗi tầng chỉ chấp nhận kết nối từ tầng ngay trước nó — instance bị xâm nhập ở tầng web không chạm thẳng vào cơ sở dữ liệu được.

Ba dải cổng tạm (ephemeral) cần biết khi cấu hình NACL: | Hệ điều hành | Dải | |---|---| | Linux hiện đại | 32768–60999 | | Windows mới | 49152–65535 | | Khuyến nghị của AWS cho NACL | 1024–65535 (bao trọn) |

Và một lời khuyên thực dụng: dùng NACL mặc định (thông suốt) trừ khi có nhu cầu rõ ràng. Security group đủ cho hầu hết trường hợp, và NACL là nguồn gốc của rất nhiều sự cố mạng khó chẩn đoán. Chỉ siết NACL khi cần rule DENY — thứ mà security group không có.

Đáp án

C — Dùng Amazon S3 Transfer Acceleration trên bucket hiện có và cho các máy chủ Outposts tải xuống qua endpoint Transfer Acceleration.

Vì sao đúng

Đề nêu ba điều kiện, và Transfer Acceleration khớp với cả ba: | Điều kiện | Cơ chế | |---|---| | Máy chủ ở nhiều vị trí XA trên toàn cầu | khoảng cách lớn tới us-west-2 | | Giảm độ trễ phân phối | đi qua mạng xương sống của AWS thay vì Internet công cộng | | Ít công vận hành nhất | bật MỘT cờ, đổi endpoint — không dựng gì thêm |

Cách Transfer Acceleration hoạt động:

KHÔNG có acceleration:
    Máy chủ Outposts ở châu Âu
        → INTERNET CÔNG CỘNG (nhiều chặng, không tối ưu)
        → S3 ở us-west-2

CÓ acceleration:
    Máy chủ Outposts
        → điểm biên CloudFront GẦN NHẤT (vài mili giây)
        → MẠNG XƯƠNG SỐNG CỦA AWS (tối ưu, ổn định)
        → S3 ở us-west-2

Vế "minimizing operational overhead" là điểm quyết định:

# Toàn bộ cấu hình phía AWS
aws s3api put-bucket-accelerate-configuration   --bucket kho-cap-nhat --accelerate-configuration Status=Enabled

# Phía client chỉ đổi endpoint
aws configure set default.s3.use_accelerate_endpoint true

Không có distribution nào phải tạo, không có cặp khoá ký nào phải quản lý, không có cache policy nào phải điều chỉnh.

Và AWS có công cụ đo trước khi cam kết — bạn kiểm chứng được mức cải thiện thật từ từng vị trí:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
    en/accelerate-speed-comparsion.html

Chi phí chỉ phát sinh khi thực sự có tăng tốc — AWS không tính phí nếu đường thường nhanh hơn.

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

• A. CloudFront distribution với bucket us-west-2 làm origin chính và một origin phụ ở Region khác, dùng cache policy CachingDisabled; signed URL — đây là phương án gần nhất về mặt dùng CDN, nhưng CachingDisabled triệt tiêu chính lợi ích của CloudFront: mọi request vẫn phải về origin, nên nó chỉ còn là một chặng trung gian thừa.
• **B. Global Accelerator định tuyến từ Outposts tới edge location gần nhất, rồi dùng private VIF để truy cập S3 — hai lỗi khái niệm: Global Accelerator dùng cho endpoint trong VPC hoặc Elastic IP, nó không tăng tốc truy cập S3; và private VIF là thành phần của Direct Connect, không liên quan tới edge location.
• **D. CloudFront distribution với bucket us-west-2 làm origin; signed URL cho việc tải phần mềm — hoạt động tốt về mặt kỹ thuật, nhưng nó nhiều công hơn: phải tạo distribution, cấu hình OAC, tạo và quản lý cặp khoá ký, sinh signed URL cho từng lượt tải. Xem ghi chú cuối bài.

Ghi nhớ

Ba cách tăng tốc truyền dữ liệu với S3: | Cách | Phù hợp | |---|---| | S3 Transfer Acceleration | truyền qua khoảng cách xa, ít công cấu hình ← câu này | | CloudFront | nội dung được tải LẶP LẠI nhiều lần — có cache | | Multipart upload song song | tận dụng băng thông cho tệp lớn |

Kết hợp Transfer Acceleration với multipart upload là cấu hình tối ưu cho tệp lớn qua khoảng cách xa.

Ba đặc điểm của Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Dùng mạng biên của CloudFront | hơn 600 điểm hiện diện | | Endpoint riêng | bucket.s3-accelerate.amazonaws.com | | Chỉ tính phí khi có tăng tốc thật | công bằng và đo được trước |

Ba dịch vụ tăng tốc mạng của AWS — phân biệt: | Dịch vụ | Giao thức | Cache | Dùng cho | |---|---|---|---| | CloudFront | HTTP/HTTPS | ✅ | nội dung web, tải lặp lại | | Transfer Acceleration | S3 API | ❌ | truyền dữ liệu tới/từ S3 qua khoảng cách xa | | Global Accelerator | TCP/UDP | ❌ | ứng dụng không phải HTTP, cần IP tĩnh |

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

Phương án D (CloudFront) đáng lẽ hoạt động tốt hơn cho chính tình huống này, và đây là điểm mập mờ thật của câu hỏi.

Lý do: đề nói nhiều máy chủ ở nhiều vị trí cùng tải MỘT bộ bản cập nhật. Đó là mẫu truy cập mà cache phát huy tối đa:

Với CloudFront:
    Máy chủ đầu tiên ở châu Âu tải bản cập nhật
        → CloudFront lưu vào cache tại edge châu Âu
    Mọi máy chủ khác ở châu Âu tải cùng tệp đó
        → phục vụ TỪ CACHE, không chạm tới us-west-2
        → nhanh hơn hẳn và rẻ hơn về phí truyền dữ liệu

Với Transfer Acceleration:
    MỌI lượt tải đều đi về us-west-2
        → chỉ tối ưu ĐƯỜNG ĐI, không loại bỏ chặng dài

Ngoài ra, Transfer Acceleration được AWS mô tả chủ yếu cho việc TẢI LÊN qua khoảng cách xa — dù nó hoạt động cho cả hai chiều.

Cách bênh cho C: đề nhấn mạnh "minimizing operational overhead", và Transfer Acceleration đúng là một cờ bật so với việc dựng distribution, cấu hình OAC và quản lý cặp khoá signed URL mà D yêu cầu.

Trong thực tế, nếu bạn thiết kế hệ thống này: hãy dùng CloudFront. Lợi ích từ cache cho nội dung tải lặp lại lớn hơn nhiều so với khoản công cấu hình ban đầu — và nếu không cần kiểm soát truy cập, bạn bỏ được cả phần signed URL để giảm độ phức tạp.

Đáp án

D — Đặt nhiều thiết bị AWS Snowball để tải tệp lên Amazon S3.

Vì sao đúng

Đề cho hai con số, và phép tính quyết định câu trả lời:

Dữ liệu:    250 TB = 250.000 GB = 2.000.000 Gigabit
Băng thông: 100 Mbps = 0,1 Gbps

Thời gian = 2.000.000 / 0,1 = 20.000.000 giây
          ≈ 231 NGÀY (và đó là khi dùng HẾT băng thông, 24/7)

Hơn bảy tháng để truyền — hoàn toàn không khả thi. Và trong suốt thời gian đó, đường truyền Internet của văn phòng bị chiếm dụng hoàn toàn.

Snowball giải quyết bằng cách vận chuyển vật lý:

① AWS gửi thiết bị tới trung tâm dữ liệu của bạn
② Bạn sao chép dữ liệu vào thiết bị qua mạng NỘI BỘ (nhanh)
③ Gửi thiết bị về AWS
④ AWS nạp dữ liệu vào S3
    → tổng thời gian: khoảng MỘT TUẦN

Và "nhiều thiết bị" là chi tiết đúng: | Thiết bị | Dung lượng khả dụng | |---|---| | Snowball Edge Storage Optimized | ~80 TB | | Snowball Edge Compute Optimized | ~28 TB | | Snowcone | 8 TB (SSD) |

250 TB cần khoảng 3–4 thiết bị Storage Optimized — và chúng chạy song song, nên thời gian không tăng theo.

Quy tắc ước lượng thô đáng nhớ:

Nếu truyền qua Internet mất hơn MỘT TUẦN, hãy cân nhắc Snow Family.

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

• **C. Dùng AWS Snowmobile để chuyển dữ liệu — đây là phương án gần nhất về mặt cũng là vận chuyển vật lý, nhưng nó hoàn toàn không tương xứng về quy mô: Snowmobile là xe container dài 45 foot chở được tới 100 PB. Dùng nó cho 250 TB giống như thuê một tàu chở hàng để gửi một kiện bưu phẩm.
• **B. Thiết lập Direct Connect rồi truyền dữ liệu — quá chậm để thiết lập và không tiết kiệm: Direct Connect mất vài tuần tới vài tháng để lắp đặt, và chi phí cho một kết nối băng thông cao chỉ để chuyển một lần là không hợp lý. (Direct Connect đáng đầu tư khi cần kết nối lâu dài, không phải cho một đợt di chuyển.)
• **A. Tải trực tiếp lên S3 — chính là phương án mất 231 ngày. Không khả thi.

Ghi nhớ

Các thiết bị của AWS Snow Family: | Thiết bị | Dung lượng | Dùng cho | |---|---|---| | Snowcone | 8 TB (SSD) / 14 TB (HDD) | nhỏ gọn, môi trường khắc nghiệt | | Snowball Edge Storage Optimized | ~80 TB | di chuyển dữ liệu quy mô TB ← câu này | | Snowball Edge Compute Optimized | ~28 TB + GPU | xử lý tại chỗ, học máy ở biên | | Snowmobile | tới 100 PB | di chuyển quy mô EXABYTE |

(AWS đã ngừng nhận đơn mới cho một số biến thể Snow; kiểm tra tài liệu hiện hành khi triển khai thật.)

Bảng quyết định theo quy mô và băng thông: | Dữ liệu | Băng thông | Nên dùng | |---|---|---| | Vài GB tới vài TB | tốt | tải trực tiếp, hoặc Transfer Acceleration | | Chục tới trăm TB | hạn chế | Snowball | | PB trở lên | bất kỳ | Snowmobile hoặc nhiều Snowball | | Đồng bộ LIÊN TỤC | có kết nối | DataSync hoặc Storage Gateway |

Công thức tính thời gian truyền:

Số ngày = (Dung lượng GB × 8) / (Băng thông Mbps × 0,0864)

250 TB qua 100 Mbps    → ~231 ngày   → Snowball
10 TB qua 1 Gbps       → ~1 ngày     → tải trực tiếp
80 TB qua 10 Gbps      → ~18 giờ     → tải trực tiếp

Ba đặc điểm bảo mật của Snowball: | Đặc điểm | Chi tiết | |---|---| | Mã hoá AES-256 bằng KMS key của bạn | dữ liệu mã hoá trước khi ghi vào thiết bị | | Vỏ chống giả mạo, có TPM | phát hiện can thiệp vật lý | | AWS xoá sạch thiết bị sau khi nạp xong | theo chuẩn NIST 800-88 |

Và AWS KHÔNG BAO GIỜ có khoá của bạn — nếu thiết bị thất lạc trên đường vận chuyển, dữ liệu vẫn không đọc được.

Ba lưu ý khi lập kế hoạch dùng Snowball: | Lưu ý | Chi tiết | |---|---| | Thời gian vận chuyển | vài ngày mỗi chiều tuỳ vị trí | | Tốc độ sao chép cục bộ | dùng nhiều luồng song song và cổng 10 GbE | | Dữ liệu vẫn thay đổi trong lúc chuyển | cần cơ chế đồng bộ phần chênh lệch sau đó |

Dòng cuối là bước hay bị quên: sau khi Snowball nạp xong 250 TB, dữ liệu tại chỗ đã thay đổi trong hai tuần. Dùng DataSync để đồng bộ phần chênh lệch — nó chỉ chuyển những gì khác biệt, nên nhanh và tiết kiệm băng thông.

Và một lựa chọn thay thế đáng biết cho di chuyển liên tục: AWS DataSync đạt tốc độ cao hơn nhiều so với công cụ tự viết nhờ giao thức tối ưu và nén — nếu băng thông thật sự tốt, nó có thể rút ngắn đáng kể con số 231 ngày. Nhưng với 100 Mbps thì không có công cụ nào cứu được.

Đáp án

C và D.

• C — EBS volume là lưu trữ ngoài instance (off-instance), tồn tại ĐỘC LẬP với vòng đời của instance
• D — EBS volume hỗ trợ thay đổi cấu hình khi đang chạy — đổi loại volume, dung lượng và IOPS mà không gián đoạn dịch vụ

Vì sao đúng

Đề nêu ba mối lo của CTO, và hai đáp án giải quyết trực tiếp hai trong số đó: | Mối lo | Đáp án | |---|---| | Kịch bản gián đoạn (downtime) | C — dữ liệu sống sót qua vòng đời instance | | Hiệu năng IOPS | D — thay đổi được khi đang chạy | | Yêu cầu tuân thủ | mã hoá, snapshot, kiểm toán |

C — tính bền vững là khác biệt căn bản với instance store:

EBS volume:
    → là tài nguyên ĐỘC LẬP, gắn qua mạng
    → dừng, khởi động lại instance → dữ liệu VẪN CÒN
    → terminate instance (với DeleteOnTermination=false) → vẫn còn
    → tháo ra gắn sang instance khác được

Instance store:
    → đĩa VẬT LÝ trên máy chủ chủ
    → DỪNG instance → MẤT SẠCH

D — Elastic Volumes là tính năng giải quyết trực tiếp lo ngại về IOPS:

aws ec2 modify-volume --volume-id vol-0abc   --volume-type io2 --size 500 --iops 20000

Không cần dừng instance, không cần tháo volume — hệ điều hành chỉ cần mở rộng phân vùng sau đó (growpart và resize2fs).

Đây là câu trả lời thẳng cho CTO: nếu chọn sai cấu hình ban đầu, bạn điều chỉnh được mà không gián đoạn.

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

• **B. EBS volume gắn được vào bất kỳ EC2 instance nào ở BẤT KỲ Availability Zone nào — đây là phương án gần nhất và sai ở một ràng buộc quan trọng: EBS volume gắn với MỘT AZ duy nhất. Muốn chuyển sang AZ khác phải chụp snapshot rồi tạo volume mới từ snapshot đó ở AZ đích.
• A. Khi tạo EBS volume trong một AZ, nó tự động được sao chép sang một AWS REGION khác — sai phạm vi sao chép: EBS sao chép dữ liệu trong CÙNG một AZ để chống hỏng phần cứng đơn lẻ. Nó không sao chép chéo AZ, càng không chéo Region.
• E. EBS cho phép tạo snapshot và ghi bản sao dữ liệu vào Amazon RDS — sai đích lưu trữ: EBS snapshot được lưu trong Amazon S3 do AWS quản lý (không nằm trong bucket của bạn), không phải RDS.

Ghi nhớ

EBS và instance store — bảng phân biệt cần thuộc: | | EBS | Instance store | |---|---|---| | Bền vững | ✅ độc lập với instance | ❌ mất khi dừng/terminate | | Vị trí | mạng lưu trữ | đĩa vật lý trên host | | Hiệu năng | rất tốt | cao hơn — không qua mạng | | Snapshot | ✅ | ❌ | | Đổi kích thước khi chạy | ✅ | ❌ | | Chi phí | tính riêng | bao gồm trong giá instance |

Ba ràng buộc về phạm vi của EBS: | Ràng buộc | Chi tiết | |---|---| | Volume gắn với MỘT AZ | chuyển AZ phải qua snapshot | | Sao chép trong CÙNG AZ | chống hỏng phần cứng, không chống sự cố AZ | | Snapshot là REGION-scope | sao chép sang Region khác được |

Dòng cuối là cách vượt ràng buộc AZ và Region: snapshot → copy sang Region đích → tạo volume mới.

Các loại EBS volume: | Loại | Đặc điểm | IOPS tối đa | |---|---|---| | gp3 | SSD đa dụng — IOPS và throughput cấp ĐỘC LẬP với dung lượng | 16.000 | | gp2 | SSD đa dụng cũ — IOPS gắn với dung lượng | 16.000 | | io2 Block Express | SSD IOPS cao nhất | 256.000 | | st1 | HDD thông lượng cao | — | | sc1 | HDD lạnh, rẻ nhất | — |

gp3 nên là mặc định cho triển khai mới: rẻ hơn gp2 khoảng 20% và cho phép cấp IOPS mà không phải mua thừa dung lượng.

Ba tính năng của EBS đáp ứng lo ngại tuân thủ: | Tính năng | Chi tiết | |---|---| | Mã hoá bằng KMS | bật mặc định ở mức tài khoản được | | Snapshot tự động | qua Data Lifecycle Manager hoặc AWS Backup | | Mã hoá cả snapshot | và mọi volume tạo từ snapshot đó |

Bật mã hoá mặc định là việc nên làm ngay:

aws ec2 enable-ebs-encryption-by-default --region ap-northeast-1

Nó đảm bảo không ai vô tình tạo volume không mã hoá — mạnh hơn việc dựa vào từng launch template nhớ bật.

Lưu ý về việc mã hoá volume đã có: không bật tại chỗ được. Quy trình là snapshot → copy snapshot với mã hoá → tạo volume mới → tháo cũ gắn mới — có thời gian ngừng, nên bật từ đầu tiết kiệm rất nhiều công.

Và một tính năng đáng biết cho yêu cầu sẵn sàng cao: EBS Multi-Attach cho phép gắn một volume io1/io2 vào tối đa 16 instance trong cùng AZ — nhưng nó đòi hệ thống tệp hỗ trợ truy cập đồng thời (như GFS2), không dùng được với ext4 hay XFS thông thường.

Đáp án

B và E.

• B — Amazon CloudWatch
• E — Amazon Simple Notification Service (SNS)

Vì sao đúng

Đề cần giám sát metric cơ sở dữ liệu và gửi email cho đội vận hành — và cặp CloudWatch + SNS là luồng chuẩn cho việc đó:

RDS tự phát metric lên CloudWatch
    ↓ CPUUtilization, DatabaseConnections, FreeStorageSpace...
CloudWatch Alarm so với ngưỡng
    ↓ vượt ngưỡng → chuyển sang trạng thái ALARM
    ↓ alarm action
SNS Topic
    ↓ subscriber là email của đội vận hành
Email được gửi

aws cloudwatch put-metric-alarm   --alarm-name canh-bao-csdl-day-o-dia   --namespace AWS/RDS --metric-name FreeStorageSpace   --dimensions Name=DBInstanceIdentifier,Value=csdl-san-xuat   --statistic Average --period 300 --threshold 10737418240   --comparison-operator LessThanThreshold --evaluation-periods 2   --alarm-actions arn:aws:sns:ap-northeast-1:111122223333:doi-van-hanh

Vì sao SNS chứ không phải SES cho thông báo vận hành: | | SNS | SES | |---|---|---| | Mục đích | thông báo pub/sub | gửi email cho NGƯỜI DÙNG CUỐI | | Đích | email, SMS, Lambda, SQS, HTTP | chỉ email | | Là target của CloudWatch alarm | ✅ trực tiếp | ❌ cần Lambda trung gian | | Dùng cho | cảnh báo vận hành ← câu này | bản tin, email giao dịch |

Dòng thứ ba là lý do kỹ thuật quyết định: CloudWatch alarm gọi thẳng SNS được, còn muốn dùng SES thì phải chèn một Lambda vào giữa — thừa và phức tạp hơn.

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

• **A. Amazon Simple Email Service (SES) — đây là phương án gần nhất và cũng gửi được email, nhưng nó không phải target trực tiếp của CloudWatch alarm. SES phục vụ email hàng loạt cho ứng dụng (bản tin, xác nhận đơn hàng), không phải cảnh báo hạ tầng.
• **C. Amazon SQS — hàng đợi thông điệp, không gửi thông báo: SQS là nơi thông điệp chờ được consumer kéo về xử lý. Nó không đẩy email tới ai cả.
• **D. EC2 instance chạy BIND server — hoàn toàn không liên quan: BIND là phần mềm máy chủ DNS. Nó không giám sát và không gửi thông báo.

Ghi nhớ

Luồng cảnh báo chuẩn của AWS:

Nguồn metric → CloudWatch → Alarm → SNS → email / SMS / Lambda / webhook

Đây là mẫu xuất hiện liên tục trong đề thi — nhận ra nó là trả lời được rất nhiều câu.

Các metric quan trọng của RDS trong CloudWatch: | Metric | Cảnh báo khi | |---|---| | CPUUtilization | vượt 80% kéo dài | | FreeStorageSpace | xuống dưới ngưỡng — đầy đĩa là CSDL dừng | | DatabaseConnections | gần chạm giới hạn | | ReadLatency / WriteLatency | tăng bất thường | | FreeableMemory | xuống thấp | | ReplicaLag | replica tụt hậu |

FreeStorageSpace là metric đáng đặt alarm nhất — RDS hết dung lượng sẽ chuyển sang trạng thái storage-full và ngừng nhận ghi. Bật thêm storage autoscaling để phòng ngừa.

Ba loại giám sát cho RDS — mỗi cái một tầng: | Công cụ | Trả lời | |---|---| | CloudWatch metric | "Instance có đang quá tải không?" | | Enhanced Monitoring | "TIẾN TRÌNH nào chiếm tài nguyên?" | | Performance Insights | "TRUY VẤN SQL nào gây tải?" |

Ba câu hỏi khác nhau — và thường cần cả ba khi chẩn đoán một sự cố hiệu năng.

Bốn tham số của CloudWatch alarm: | Tham số | Việc | |---|---| | Period | độ dài mỗi chu kỳ (giây) | | EvaluationPeriods | số chu kỳ được xem xét | | DatapointsToAlarm | số chu kỳ phải vi phạm — cơ chế "M trên N" | | TreatMissingData | xử lý chu kỳ thiếu dữ liệu — đặt sai gây báo động giả |

Cơ chế "M trên N" giảm báo động giả cho metric hay nhiễu:

EvaluationPeriods = 5, DatapointsToAlarm = 3
    → báo động khi 3 trong 5 chu kỳ gần nhất vi phạm
    → chịu được biến động ngắn, vẫn bắt được vấn đề kéo dài

Ba loại subscriber của SNS: | Loại | Dùng cho | |---|---| | Email / Email-JSON | thông báo cho người ← câu này | | SMS | cảnh báo khẩn | | Lambda, SQS, HTTP/S | tự động khắc phục, tích hợp hệ thống khác |

Subscriber email phải XÁC NHẬN qua liên kết trong thư đầu tiên — nếu không, thông báo sẽ không bao giờ tới. Đây là bước hay bị quên khi thiết lập lần đầu.

Và một lựa chọn bổ sung đáng biết: RDS Event Subscription gửi thông báo về sự kiện hạ tầng (chuyển đổi dự phòng, sao lưu hoàn tất, thay đổi cấu hình) qua SNS. Nó khác với CloudWatch alarm vốn theo dõi metric — nên bật cả hai để phủ đủ cả hiệu năng lẫn vòng đời của instance.

Đáp án

C và E.

• C — Cho phép xây dựng RESTful API và WebSocket API được tối ưu cho workload không máy chủ
• E — Bạn chỉ trả tiền cho số lời gọi API nhận được và lượng dữ liệu truyền ra

Vì sao đúng

Hai phát biểu này mô tả đúng hai đặc điểm cốt lõi của Amazon API Gateway.

C — ba loại API mà API Gateway hỗ trợ: | Loại | Đặc điểm | |---|---| | REST API | đầy đủ tính năng: caching, usage plan, request validation, WAF | | HTTP API | đơn giản hơn, rẻ hơn ~70%, độ trễ thấp hơn | | WebSocket API | giao tiếp HAI CHIỀU, giữ kết nối lâu dài |

WebSocket API rất phù hợp với ngữ cảnh của đề — một công ty game cần giao tiếp thời gian thực giữa máy chủ và người chơi trên PS4, Xbox, Switch, di động:

REST API:      client hỏi → server trả lời → kết nối đóng
WebSocket API: kết nối MỞ liên tục
               → server CHỦ ĐỘNG đẩy dữ liệu về client
               → đúng cho bảng xếp hạng, trò chuyện, trạng thái trận đấu

E — mô hình giá theo mức dùng:

Không có phí tối thiểu, không có máy chủ chạy nhàn rỗi
    → REST API: ~3,50 USD / triệu request
    → HTTP API: ~1,00 USD / triệu request
    + phí truyền dữ liệu ra

Với một công ty có nhiều tựa game và lưu lượng biến động mạnh, mô hình này tránh được việc trả tiền cho dung lượng dư.

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

• **A. Nó tự động cung cấp ngôn ngữ truy vấn cho API tương tự GraphQL — đây là phương án gần nhất về mặt cũng là dịch vụ API, nhưng đó là AWS AppSync, không phải API Gateway. AppSync là dịch vụ GraphQL được quản lý của AWS.
• **B. Cung cấp địa chỉ IP anycast tĩnh làm điểm vào cố định cho ứng dụng ở một hoặc nhiều Region — đó là AWS Global Accelerator. API Gateway không cung cấp IP tĩnh.
• **D. Cho phép chạy ứng dụng cần giao tiếp giữa các node ở mức cao thông qua giao diện phần cứng bỏ qua hệ điều hành — đó là Elastic Fabric Adapter (EFA), dùng cho HPC và huấn luyện mô hình phân tán. Hoàn toàn không liên quan tới API Gateway.

Ghi nhớ

Ba loại API của API Gateway — bảng chọn: | | REST API | HTTP API | WebSocket API | |---|---|---|---| | Chi phí | cao nhất | rẻ hơn ~70% | theo phút kết nối + thông điệp | | Caching | ✅ | ❌ | — | | Usage plan + API key | ✅ | ❌ | — | | Request validation | ✅ | hạn chế | — | | Tích hợp WAF | ✅ | ❌ | ❌ | | Giao tiếp hai chiều | ❌ | ❌ | ✅ | | Độ trễ | cao hơn | thấp hơn | — |

Chọn HTTP API khi chỉ cần proxy đơn giản tới Lambda hoặc ALB — rẻ hơn đáng kể. Chọn REST API khi cần caching, usage plan hoặc WAF.

Ba loại endpoint của REST API: | Loại | Truy cập từ | |---|---| | Edge-optimized | Internet, qua mạng CloudFront — mặc định | | Regional | Internet, trực tiếp trong Region | | Private | chỉ từ VPC qua interface endpoint |

Với người dùng toàn cầu như công ty game trong đề, edge-optimized là lựa chọn hợp lý — request đi vào mạng AWS ở điểm gần người chơi nhất.

Bốn cách xác thực người gọi API Gateway: | Cách | Đặc điểm | |---|---| | IAM authorization | request ký SigV4 — cho lời gọi từ trong AWS | | Cognito authorizer | JWT từ User Pool — phù hợp cho ứng dụng di động | | Lambda authorizer | logic tuỳ ý | | API key + usage plan | chỉ để đo lường và giới hạn tần suất, KHÔNG phải bảo mật |

Dòng cuối cần nhấn mạnh: AWS nêu rõ API key không phải cơ chế bảo mật — dùng nó một mình để bảo vệ API là sai.

Ba cơ chế bảo vệ backend qua API Gateway: | Cơ chế | Chống | |---|---| | Throttling (rate + burst) | quá tải do khối lượng | | Caching | request lặp lại | | WAF (chỉ REST API) | request độc hại |

Với công ty game, throttling theo usage plan rất hữu ích: mỗi tựa game hoặc mỗi đối tác một hạn mức riêng, nên một trò chơi bùng nổ lưu lượng không làm sập backend của các trò khác.

Ba dịch vụ API của AWS — phân biệt: | Dịch vụ | Loại API | |---|---| | API Gateway | REST, HTTP, WebSocket | | AWS AppSync | GraphQL | | Application Load Balancer | HTTP thuần, không có tính năng quản lý API |

Và một lưu ý về WebSocket API cho ngữ cảnh game: nó tính phí theo phút kết nối và số thông điệp. Với hàng chục nghìn người chơi giữ kết nối liên tục, đây là khoản chi cần ước lượng trước — và với trạng thái trận đấu tần suất rất cao, một giải pháp chuyên biệt như Amazon GameLift có thể phù hợp hơn.