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

Đáp án

C, D — hai bước cho quản trị tập trung và mã hoá S3 trên mọi tài khoản:

• C — Dựng cấu trúc AWS Organizations, triển khai AWS Control Tower, bật các guardrail bảo mật cần thiết, gom mọi tài khoản vào tổ chức và sắp xếp thành OU theo chức năng.
• D — Tạo Lambda function được EventBridge kích hoạt để giám sát và tự động bật mã hoá cho bucket S3 chưa mã hoá, cả bucket mới lẫn bucket đang có.

Vì sao đúng

Đề đòi hai thứ tách bạch: quản trị tập trung có trọng tâm bảo mật và tuân thủ, và xử lý số bucket chưa mã hoá đang tồn tại cùng với việc đảm bảo tuân thủ về sau.

⚠ Điểm mấu chốt: EventBridge phục vụ CẢ hai chiều — bucket mới bắt theo sự kiện, bucket cũ quét theo lịch:

Luồng 1 — bucket mới:
    CloudTrail ghi CreateBucket
        ↓
    EventBridge rule khớp sự kiện → gọi Lambda
        ↓
    → bật mã hoá ngay khi bucket vừa ra đời

Luồng 2 — bucket cũ:
    EventBridge scheduled rule (ví dụ mỗi ngày)
        ↓
    Lambda liệt kê mọi bucket, kiểm cấu hình mã hoá
        ↓
    → bật cho những bucket còn thiếu

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

def handler(su_kien, ngu_canh):
    for b in s3.list_buckets()['Buckets']:
        ten = b['Name']
        try:
            s3.get_bucket_encryption(Bucket=ten)
        except s3.exceptions.ClientError:
            s3.put_bucket_encryption(
                Bucket=ten,
                ServerSideEncryptionConfiguration={'Rules': [{
                    'ApplyServerSideEncryptionByDefault': {'SSEAlgorithm': 'AES256'},
                    'BucketKeyEnabled': True}]})

C — vì sao Control Tower chứ không chỉ Organizations. Đề đòi "centralized management solution with a focus on security and regulatory compliance". Control Tower dựng sẵn landing zone: OU chuẩn, tài khoản log archive và audit riêng, CloudTrail tập trung, Config tập trung, và bộ guardrail phòng ngừa lẫn phát hiện — tất cả những thứ mà nếu chỉ có Organizations thì phải tự dựng từng mảnh.

⚠ Từ tháng 1/2023, S3 mã hoá SSE-S3 theo mặc định cho object mới:

Mọi object PUT vào bucket bất kỳ đều được mã hoá SSE-S3 mặc định
        ↓
    Nhưng object có TRƯỚC thời điểm đó thì KHÔNG tự động được mã hoá
        ↓
    Và cấu hình "default encryption" của bucket vẫn là thứ cần kiểm tra khi audit
        ↓
    → nên việc rà soát và bật tường minh vẫn cần thiết

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

• B (Organizations + Security Hub giám sát tập trung, Config rule phát hiện và TỰ ĐỘNG mã hoá bucket) — đây là phương án gần nhất và hai thành phần đầu của nó rất hợp lý: Organizations làm nền, Security Hub gom phát hiện bảo mật từ nhiều tài khoản. Nó hỏng ở vế cuối. AWS Config rule tự nó không sửa gì cả — nó chỉ đánh giá và đánh dấu tài nguyên là tuân thủ hay không. Muốn khắc phục thì phải gắn thêm remediation action dùng SSM Automation document, một thành phần mà phương án không nhắc tới. Câu "Config rules to detect and automatically encrypt" gộp hai việc mà Config chỉ làm được một. So với C, nó cũng thiếu hẳn phần landing zone và OU mà đề yêu cầu.

• A (chạy script AWS CLI lặp qua mọi bucket ở mọi tài khoản để bật mã hoá) — chỉ là hành động một lần, không có tính liên tục. Bucket tạo ra sau khi script chạy sẽ không được xử lý, mà đề đòi "ensure future compliance". Nó cũng đòi ai đó nhớ chạy lại định kỳ và tự quản lý quyền cross-account cho script.

• E (CloudTrail liên tài khoản, Athena quét định kỳ tìm bucket chưa mã hoá rồi kích hoạt mã hoá) — sai nguồn dữ liệu. CloudTrail ghi lời gọi API, không ghi trạng thái cấu hình hiện tại của tài nguyên. Từ log CloudTrail bạn biết được ai đã gọi PutBucketEncryption, nhưng không biết bucket nào đang thiếu mã hoá — đặc biệt với bucket tạo từ trước khi bật trail. Công cụ trả lời câu hỏi "tài nguyên đang ở trạng thái nào" là AWS Config, không phải CloudTrail.

Ghi nhớ

⚠ Bốn dịch vụ quản trị đa tài khoản — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Organizations | nền tảng: tài khoản, OU, SCP, hoá đơn gộp | | Control Tower | landing zone dựng sẵn trên Organizations: guardrail, log archive, audit account | | Security Hub | gom phát hiện bảo mật, chấm điểm theo chuẩn (CIS, PCI DSS) | | AWS Config | trạng thái cấu hình + đánh giá tuân thủ + remediation |

Từ khoá nhận diện:

"centralized management" + "security and compliance" → Control Tower "encrypt EXISTING buckets AND ensure future compliance" → cần cả quét lẫn bắt sự kiện "Config rules to automatically encrypt" → SAI, Config cần remediation action mới sửa được "CloudTrail + Athena để tìm bucket chưa mã hoá" → SAI, CloudTrail ghi API không ghi trạng thái "CLI script" khi đề đòi tuân thủ liên tục → hành động một lần, không đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket nào chưa mã hoá | Config rule s3-bucket-server-side-encryption-enabled | | Lambda có chạy đủ tài khoản không | so số bucket xử lý với tổng số bucket toàn tổ chức | | Có bucket mới nào lọt không | kiểm sự kiện CreateBucket gần đây và trạng thái mã hoá của chúng |

Và một lời khuyên: hãy dùng Config rule làm nguồn sự thật về tuân thủ, đừng tin vào việc Lambda đã chạy xong. Đây là chỗ khoảng trống hình thành mà không ai thấy: Lambda tự động bật mã hoá chạy trong một tài khoản cụ thể với một role cụ thể — nếu một tài khoản mới được thêm vào tổ chức mà chưa được cấp role cross-account, hoặc một Region mới được dùng tới mà rule chưa phủ, thì bucket ở đó không bao giờ được quét. Lambda vẫn chạy thành công, log vẫn sạch, không có lỗi nào — vì với nó, những bucket đó không tồn tại. Con số cần theo dõi là tỷ lệ tài nguyên tuân thủ trên toàn tổ chức, không phải số bucket mà hàm đã xử lý.

Đáp án

A, B — hai bước cho cụm HPC 10 node cần kết nối liên instance nhanh và độ trễ thấp:

• B — Triển khai EC2 instance trong một cluster placement group.
• A — Dùng loại instance và AMI hỗ trợ EFA (Elastic Fabric Adapter).

Vì sao đúng

Đề nói rõ "high speed and low latency inter-instance connectivity". Đó là bài toán mạng giữa các node, và AWS có đúng hai công cụ cho nó.

⚠ Điểm mấu chốt: EFA cho phép BỎ QUA kernel, đó là chỗ độ trễ giảm mạnh nhất:

ENA thường: ứng dụng → kernel → driver → card mạng
        ↓
    Mỗi lần chuyển ngữ cảnh tốn vài chục micro giây

EFA: ứng dụng (qua libfabric) → THẲNG tới card mạng
        ↓
    Bỏ qua kernel hoàn toàn
        ↓
    → độ trễ giảm mạnh và ổn định — thứ mà workload gắn kết chặt cần nhất

Đây là lý do EFA không thay thế được bằng "instance mạng nhanh hơn": vấn đề không phải băng thông mà là độ trễ và độ ổn định của độ trễ.

B — vì sao cluster placement group. Nó đặt các instance trong cùng một Availability Zone, trên cùng một nhóm phần cứng gần nhau, cho băng thông cao nhất và độ trễ thấp nhất giữa các node.

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

aws ec2 run-instances --count 10 --instance-type c6in.32xlarge \
  --placement GroupName=hpc-cum \
  --network-interfaces '[{"DeviceIndex":0,"InterfaceType":"efa","SubnetId":"subnet-abc"}]'

⚠ Cluster placement group nằm trong MỘT Availability Zone — đó là đánh đổi có chủ ý:

Mọi node trong một AZ
        ↓
    Độ trễ thấp nhất có thể
        ↓
    Nhưng mất một AZ là mất cả cụm
        ↓
    → với HPC gắn kết chặt thì đây là đánh đổi ĐÚNG: workload vốn đã không chịu được
      mất một node giữa chừng, nên trải nhiều AZ chỉ thêm độ trễ mà không thêm khả năng chịu lỗi

Đây chính là lý do phương án E sai.

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

• C (partition placement group) — đây là phương án gần nhất và nó cũng là một chiến lược placement group thật, dễ nhầm vì chỉ khác một từ. Nhưng mục đích của nó ngược hẳn: partition placement group tách các instance ra nhiều nhóm phần cứng riêng biệt để một sự cố rack không hạ cả hệ thống. Đó là thứ hệ phân tán như HDFS, Cassandra, Kafka cần — chúng tự sao chép dữ liệu và muốn các bản sao nằm trên phần cứng khác nhau. Với HPC gắn kết chặt, phân tán các node ra xa nhau làm tăng độ trễ giữa chúng, tức là đi ngược đúng yêu cầu của đề.

• E (triển khai trên ít nhất ba Availability Zone) — trực tiếp mâu thuẫn với mục tiêu. Lưu lượng giữa các AZ đi qua khoảng cách vật lý lớn hơn nhiều, thêm hàng trăm micro giây độ trễ cho mỗi chặng. Với workload trao đổi tin nhắn liên tục giữa các node (MPI), đó là mức phạt khổng lồ. Ngoài ra cluster placement group không thể trải nhiều AZ, nên hai phương án này loại trừ nhau.

• D (dùng instance có burstable performance) — sai hoàn toàn về loại tải. Instance dòng T (t3, t4g) tích luỹ credit CPU khi nhàn rỗi và tiêu credit khi cần hiệu năng — mô hình dành cho tải nhẹ, không đều. HPC chạy CPU ở 100% trong nhiều giờ; credit sẽ cạn ngay và instance bị bóp xuống mức nền. Đây là lựa chọn tệ nhất có thể cho tính toán hiệu năng cao.

Ghi nhớ

⚠ Ba chiến lược placement group — bảng phải thuộc: | Chiến lược | Bố trí | Dùng cho | |---|---|---| | Cluster | sát nhau, MỘT AZ | HPC, workload gắn kết chặt, độ trễ thấp nhất | | Partition | nhiều nhóm phần cứng tách biệt | HDFS, Cassandra, Kafka — hệ phân tán lớn | | Spread | mỗi instance một phần cứng riêng | số ít instance quan trọng, cần cách ly tối đa |

Từ khoá nhận diện:

"HPC" / "tightly coupled" / "low latency inter-instance" → cluster placement group + EFA "MPI" → EFA "partition placement group" cho HPC → SAI, nó tách các node ra xa "multiple Availability Zones" cho HPC gắn kết chặt → SAI, thêm độ trễ "burstable performance" cho HPC → LUÔN SAI, credit cạn ngay

Ba việc kiểm chứng: | Việc | Cách | |---|---| | EFA có bật thật không | fi_info -p efa trên instance | | Độ trễ giữa các node | chạy benchmark MPI (ví dụ OSU micro-benchmarks) | | Placement group có nhận đủ máy không | lỗi InsufficientInstanceCapacity khi khởi động cả cụm |

Và một lời khuyên: hãy khởi động toàn bộ cụm trong một lời gọi run-instances duy nhất, đừng khởi động từng máy một. Đây là chỗ cluster placement group hay thất bại theo cách khó hiểu: AWS cần tìm đủ dung lượng liền kề cho cả nhóm, và nếu bạn thêm dần từng instance, những lần thêm sau có thể nhận InsufficientInstanceCapacity dù Region còn rất nhiều máy trống — vì chỗ trống ấy không nằm cạnh những máy đã có. Thông báo lỗi nói về dung lượng chứ không nói về placement group, nên rất dễ đi tìm nguyên nhân ở hạn mức tài khoản hoặc ở loại instance, trong khi vấn đề thật chỉ là thứ tự khởi động.

Đáp án

C — Lưu dữ liệu trong DynamoDB global table ở hai Region với chế độ on-demand; chạy dịch vụ web ở cả hai Region bằng ECS Fargate trong ECS service có Auto Scaling, đặt sau ALB; Route 53 dùng alias record với latency-based routing policy kèm health check.

Vì sao đúng

Đề nêu bốn ràng buộc, và chỉ một phương án thoả cả bốn.

⚠ Điểm mấu chốt: on-demand capacity mode là thứ duy nhất hấp thụ được đỉnh tải đột ngột mà không cần dự báo:

Provisioned capacity + auto scaling
        ↓
    Auto scaling phản ứng theo CloudWatch — mất vài phút mới tăng
        ↓
    Đỉnh tải "ngắn nhưng lớn" đã qua trước khi kịp tăng
        ↓
    → trong lúc đó request bị throttle

On-demand capacity
        ↓
    Hấp thụ tức thì tới gấp đôi đỉnh tải cao nhất từng thấy
        ↓
    → đúng hình thái "variable với spike ngắn" mà đề mô tả

Vì sao latency-based routing kèm health check. Đây là điểm phân biệt với failover routing: latency-based dùng cả hai Region cùng lúc (mỗi người dùng đi tới nơi nhanh nhất với họ), và health check tự loại Region hỏng ra khỏi kết quả. Vừa tối ưu hiệu năng vừa chịu lỗi.

Vì sao Fargate. Đề đòi "dynamically scale" và không nhắc gì tới nhu cầu kiểm soát máy chủ. Fargate bỏ hẳn việc quản lý EC2, co giãn theo task.

# global table hai Region, on-demand
aws dynamodb create-table --table-name du-lieu \
  --billing-mode PAY_PER_REQUEST \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH

aws dynamodb update-table --table-name du-lieu \
  --replica-updates '[{"Create":{"RegionName":"ap-northeast-1"}}]'

⚠ Global table dùng "last writer wins" — không có khoá phân tán giữa các Region:

Hai Region cùng ghi một mục trong khoảng thời gian rất ngắn
        ↓
    Bản ghi có timestamp muộn hơn THẮNG
        ↓
    → bản ghi kia biến mất, không có lỗi, không có cảnh báo
        ↓
    → ứng dụng phải thiết kế sao cho xung đột không quan trọng, hoặc phân vùng
      khoá theo Region

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

• A (Aurora global database, replica auto scaling ở cả hai Region, EC2 + ALB, Route 53 multi-value routing) — đây là phương án gần nhất và nó thật sự là một kiến trúc đa Region hợp lệ: Aurora global database sao chép rất nhanh và EC2 sau ALB là mẫu quen thuộc. Nhưng nó vỡ ở hai chỗ. Thứ nhất, Aurora global database chỉ ghi được ở Region chính — Region phụ là read-only cho tới khi promote, nên "read and write access" ở cả hai Region không đạt được nếu không có bước chuyển vùng thủ công. Thứ hai, multi-value answer routing không phải cơ chế chịu lỗi đa Region đúng nghĩa: nó trả về nhiều bản ghi và để client tự chọn, không định tuyến theo độ trễ và không có ngữ nghĩa chính/phụ. Aurora cũng khó hấp thụ đỉnh tải đột ngột như DynamoDB on-demand vì phải thêm replica, mất vài phút.

• B (DocumentDB ở hai Region, DMS đồng bộ giữa chúng) — dùng DMS để đồng bộ hai cơ sở dữ liệu cùng loại là chọn đường vòng, thêm một thành phần phải vận hành và giám sát, với độ trễ và nguy cơ lệch dữ liệu. DocumentDB cũng có global cluster riêng, nên dùng DMS ở đây là bỏ qua tính năng sẵn có. Failover routing thì chỉ dùng một Region tại một thời điểm, không tận dụng được cả hai.

• D (S3 hai Region + CRR, CloudFront nhiều origin, API Gateway + Lambda) — sai loại kho dữ liệu. Đề nói structured data với read và write; S3 là kho object, không phải nơi lưu dữ liệu có cấu trúc cần truy vấn và cập nhật từng bản ghi. Cross-Region Replication cũng chỉ một chiều, nên không hỗ trợ ghi ở cả hai nơi.

Ghi nhớ

⚠ Bốn lựa chọn dữ liệu đa Region — bảng phải thuộc: | Dịch vụ | Ghi được ở | Ghi chú | |---|---|---| | DynamoDB global table | mọi Region (multi-active) | last writer wins | | Aurora global database | chỉ Region chính | RPO ~1 giây, RTO dưới 1 phút khi promote | | S3 CRR / MRR | một chiều (hoặc hai chiều với S3 RTC) | kho object | | DocumentDB global cluster | chỉ Region chính | tương tự Aurora |

Từ khoá nhận diện:

"read and write in multiple Regions" → DynamoDB global table "short but significant spikes" → on-demand capacity mode "fault tolerant across Regions" → latency-based hoặc failover routing + health check "Aurora global database" khi cần ghi ở cả hai Region → SAI, chỉ Region chính ghi được "DMS để đồng bộ hai CSDL cùng loại" → đường vòng, có cơ chế sẵn tốt hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị throttle không | chỉ số ThrottledRequests của DynamoDB | | Độ trễ sao chép global table | ReplicationLatency theo từng cặp Region | | Health check có loại đúng Region không | tắt thử một Region, xem dig trả về gì |

Và một lời khuyên: hãy thiết kế dữ liệu sao cho hai Region không cùng ghi một mục, đừng trông vào việc xung đột hiếm khi xảy ra. Global table giải quyết xung đột bằng "last writer wins" và không báo cho ai biết rằng nó vừa làm điều đó — không có chỉ số nào đếm số ghi bị mất, không có log, không có sự kiện. Với một ứng dụng có người dùng cố định ở một Region thì xung đột gần như không xảy ra và mọi thứ trông hoàn hảo trong nhiều tháng. Rồi một sự cố mạng khiến lưu lượng dồn sang Region kia, hai bên cùng ghi, và một phần cập nhật lặng lẽ biến mất — thứ chỉ phát hiện được khi có người báo rằng thay đổi họ vừa lưu đã bị mất.

Đáp án

B — Dùng AWS Secrets Manager quản lý thông tin đăng nhập cơ sở dữ liệu, tạo secret riêng cho môi trường phát triển và production, bật tự động xoay vòng, truyền ARN của secret vào Lambda qua biến môi trường, và gán IAM role phù hợp cho hàm.

Vì sao đúng

Đề đòi hai thứ, và thứ hai loại gần hết các phương án: không hard-code thông tin đăng nhập và tự động xoay vòng mật khẩu.

⚠ Điểm mấu chốt: chỉ Secrets Manager có xoay vòng tự động ĐẦY ĐỦ — nó đổi mật khẩu ở CẢ hai nơi:

Đến hạn xoay vòng
        ↓
    Secrets Manager gọi Lambda function xoay vòng (AWS cung cấp sẵn cho RDS/Aurora)
        ↓
    Hàm đó ĐỔI MẬT KHẨU TRONG CHÍNH CƠ SỞ DỮ LIỆU
        ↓
    Rồi cập nhật giá trị secret
        ↓
    → hai bên luôn khớp nhau, ứng dụng không cần biết gì

Đây là điểm phân biệt cốt lõi với Parameter Store và KMS: chúng lưu được giá trị, nhưng không có cơ chế nào tự đổi mật khẩu trong cơ sở dữ liệu. Xoay vòng ở đó nghĩa là ai đó phải làm thủ công cả hai phía.

Secrets Manager dùng chiến lược bốn bước để không có khoảng gián đoạn:

import boto3, json, os
sm = boto3.client('secretsmanager')

# lấy secret lúc chạy — KHÔNG hard-code
bi_mat = json.loads(sm.get_secret_value(
    SecretId=os.environ['SECRET_ARN'])['SecretString'])

⚠ Gọi get_secret_value trong handler mỗi lời gọi là tốn tiền và tốn thời gian:

Secrets Manager tính tiền theo lượt gọi API
        ↓
    Lambda tần suất cao → hàng triệu lượt gọi mỗi tháng
        ↓
    → nên dùng Lambda extension của Secrets Manager (có cache cục bộ),
      hoặc cache trong biến ở phạm vi module với thời gian sống ngắn

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

• C (Systems Manager Parameter Store, mã hoá bằng KMS, hàm lấy giá trị bằng SDK) — đây là phương án gần nhất và nó đáp ứng trọn vẹn yêu cầu thứ nhất: SecureString parameter mã hoá bằng KMS là cách lưu thông tin đăng nhập hoàn toàn hợp lệ, rẻ hơn Secrets Manager đáng kể, và Lambda lấy ra lúc chạy nên không có gì hard-code. Nó chỉ thiếu đúng yêu cầu thứ hai — Parameter Store không có xoay vòng tự động. Bạn có thể tự dựng một Lambda và một lịch EventBridge để làm việc đó, nhưng khi ấy bạn đang tự viết lại thứ Secrets Manager cung cấp sẵn, bao gồm cả chiến lược bốn bước để tránh gián đoạn. Đây là bẫy hay của câu này: một phương án hợp lý, rẻ hơn, và sai vì đúng một tính năng mà đề nêu thẳng.

• A (lưu thông tin đăng nhập trong AWS KMS, bật xoay vòng khoá tự động) — hiểu sai bản chất KMS. KMS quản lý KHOÁ MÃ HOÁ, không phải kho lưu bí mật — nó không lưu chuỗi mật khẩu. Và "automatic key rotation" của KMS xoay vòng vật liệu khoá mã hoá, hoàn toàn không liên quan tới việc đổi mật khẩu cơ sở dữ liệu. Đây là phương án chỉ giống đúng ở chỗ có chữ "rotation".

• D (bucket S3 riêng cho mỗi môi trường, SSE-KMS, quy ước đặt tên tệp để Lambda lấy đúng thông tin đăng nhập) — tự dựng một kho bí mật bằng tay. Không có xoay vòng, không có kiểm soát phiên bản của secret, không có audit riêng cho từng lần truy cập bí mật, và nguy cơ cấu hình sai quyền bucket là rất thật. Đây chính là loại giải pháp mà Secrets Manager sinh ra để thay thế.

Ghi nhớ

⚠ Ba nơi lưu cấu hình và bí mật — bảng phải thuộc: | Dịch vụ | Xoay vòng tự động | Chi phí | Dùng cho | |---|---|---|---| | Secrets Manager | CÓ, đổi cả ở CSDL | ~0,4 USD/secret/tháng + phí API | mật khẩu CSDL, khoá API | | Parameter Store (SecureString) | không | miễn phí ở bậc Standard | cấu hình, và bí mật không cần xoay vòng | | KMS | xoay vòng khoá mã hoá | theo khoá + lượt gọi | quản lý khoá, không lưu bí mật |

Từ khoá nhận diện:

"automated rotation of passwords" → Secrets Manager, không có lựa chọn khác "not hardcoded" → cả Secrets Manager lẫn Parameter Store đều đạt "KMS to store credentials" → LUÔN SAI, KMS quản lý khoá không lưu bí mật "S3 bucket để lưu thông tin đăng nhập" → SAI, tự dựng lại thứ đã có cần rẻ và KHÔNG cần xoay vòng → Parameter Store là lựa chọn hợp lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoay vòng có chạy không | aws secretsmanager describe-secret, xem LastRotatedDate | | Ai đang đọc secret | CloudTrail, sự kiện GetSecretValue | | Hàm có xử lý được lúc xoay vòng không | xoay vòng thủ công một lần trong giờ thấp điểm và quan sát |

Và một lời khuyên: hãy bắt lỗi xác thực trong mã và lấy lại secret một lần trước khi báo lỗi ra ngoài. Đây là sự cố kinh điển xảy ra đúng vào ngày xoay vòng đầu tiên: nếu bạn cache thông tin đăng nhập ở phạm vi module, một môi trường thực thi Lambda đang sống có thể giữ mật khẩu cũ sau khi mật khẩu trong cơ sở dữ liệu đã đổi. Hàm bắt đầu ném lỗi xác thực, nhưng chỉ ở một phần các lời gọi — những lời gọi rơi vào môi trường cũ — nên tỷ lệ lỗi tăng lên vài phần trăm rồi tự hết sau vài chục phút khi các môi trường cũ bị thu hồi. Nó trông y hệt một sự cố mạng thoáng qua, và bạn sẽ gặp lại nó đúng chu kỳ xoay vòng tiếp theo.

Đáp án

B, D — hai thay đổi giải quyết tận gốc cả nghẽn API lẫn nghẽn ghi cơ sở dữ liệu:

• B — Dùng Kinesis Data Streams và AWS Lambda để nhận và xử lý dữ liệu thô.
• D — Thiết kế lại tầng dữ liệu, dùng DynamoDB thay cho RDS MySQL.

Vì sao đúng

Đề có hai triệu chứng, và cả hai đều bắt nguồn từ việc kiến trúc hiện tại không hợp với hình thái dữ liệu IoT.

⚠ Điểm mấu chốt: hai vấn đề này là MỘT — cả hai đều do dữ liệu chảy đồng bộ qua từng tầng:

Hiện tại: cảm biến → ALB → EC2 (Node.js) → ghi từng dòng vào RDS
        ↓
    Thêm cảm biến = thêm request đồng thời = thêm kết nối CSDL
        ↓
    Cả API lẫn CSDL đều tăng tải tuyến tính theo số thiết bị

Sau khi sửa: cảm biến → Kinesis (đệm) → Lambda đọc theo lô → BatchWriteItem vào DynamoDB
        ↓
    Số Lambda đồng thời = số shard, KHÔNG phải số cảm biến
        ↓
    → thêm cảm biến chỉ cần thêm shard, tiên đoán được và tuyến tính về chi phí

Vì sao DynamoDB hợp với dữ liệu cảm biến. Đây là dữ liệu chuỗi thời gian: ghi rất nhiều, đọc theo khoá thiết bị và khoảng thời gian, gần như không có join. Đó chính là mô hình truy cập DynamoDB phục vụ tốt nhất, với thông lượng ghi mở rộng ngang theo số phân vùng.

# Lambda đọc lô từ Kinesis rồi ghi gộp vào DynamoDB
import boto3, base64, json
bang = boto3.resource('dynamodb').Table('du-lieu-cam-bien')

def handler(su_kien, ngu_canh):
    with bang.batch_writer() as ghi:
        for ban_ghi in su_kien['Records']:
            du_lieu = json.loads(base64.b64decode(ban_ghi['kinesis']['data']))
            ghi.put_item(Item=du_lieu)

⚠ Khoá phân vùng phải trải đều, nếu không một phân vùng nóng sẽ bóp nghẹt toàn bảng:

Khoá phân vùng = ngày hôm nay
        ↓
    Mọi ghi trong ngày dồn vào một phân vùng
        ↓
    → chạm trần 1.000 WCU mỗi phân vùng, bị throttle
        ↓
    → dùng device_id làm khoá phân vùng và timestamp làm khoá sắp xếp

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

• C (chuyển sang Aurora và thêm read replica) — đây là phương án gần nhất và Aurora thật sự nhanh hơn RDS MySQL đáng kể, kể cả về ghi. Nhưng nó không nhắm đúng vấn đề. Đề nói write latency cao, mà read replica không giúp gì cho việc ghi — mọi ghi vẫn dồn về một instance writer duy nhất. Aurora nâng trần lên chứ không đổi hình thái mở rộng: vẫn là mở rộng dọc, vẫn có một điểm nghẽn ghi. Với hàng nghìn cảm biến sắp được triển khai thêm, đây là hoãn vấn đề chứ không giải quyết. Nó cũng bỏ trắng vế API server quá tải.

• A (dùng X-Ray gỡ lỗi và thêm EC2 cho khớp tải) — X-Ray là công cụ chẩn đoán, hữu ích nhưng không phải giải pháp; còn "thêm EC2 cho khớp tải" là mở rộng dọc theo cách thủ công, không phải thứ đề gọi là "resolve permanently and enable growth". Nó cũng làm tăng số kết nối vào RDS, khiến nghẽn ghi tệ hơn.

• E (tăng dung lượng gp2 lên 6 TB để tăng IOPS) — chữa triệu chứng bằng cách nâng trần, và chỉ nâng được một lần. Với gp2 thì 4 TB đã cho 12.000 IOPS, lên 6 TB thành 16.000 — nhưng vấn đề gốc là kiến trúc ghi đồng bộ từng dòng, và số cảm biến sẽ tiếp tục tăng. Nó cũng không rẻ, đi ngược yêu cầu "cost-efficient".

Ghi nhớ

⚠ Bốn dấu hiệu nên rời khỏi CSDL quan hệ cho dữ liệu IoT — bảng phải thuộc: | Dấu hiệu | Vì sao | |---|---| | Ghi liên tục tốc độ cao | writer đơn lẻ là điểm nghẽn | | Không cần join | mất lợi thế chính của quan hệ | | Truy cập theo khoá và khoảng thời gian | đúng mô hình DynamoDB | | Tải tăng theo số thiết bị | cần mở rộng ngang |

Từ khoá nhận diện:

"IoT" / "sensor data" / "real time" → Kinesis + xử lý theo lô "high write latency" trên RDS → read replica KHÔNG giúp gì "API servers consistently overloaded" → bỏ đường đồng bộ, đệm lại "add read replicas" để chữa nghẽn ghi → LUÔN SAI "tăng dung lượng đĩa để tăng IOPS" khi vấn đề là kiến trúc → hoãn chứ không giải quyết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tụt lại sau không | IteratorAge của Lambda đọc Kinesis | | Có phân vùng nóng không | bật CloudWatch Contributor Insights cho DynamoDB | | Có bị throttle không | WriteThrottleEvents của DynamoDB |

Và một lời khuyên: hãy bật Contributor Insights cho bảng DynamoDB ngay từ đầu, đừng chờ tới lúc bị throttle. Phân vùng nóng là dạng nghẽn khó thấy nhất trong DynamoDB: tổng dung lượng ghi được cấp trông thừa thãi, chỉ số ConsumedWriteCapacityUnits ở mức thấp so với mức cấp, và mọi thứ trên bảng điều khiển đều nói rằng bảng đang rảnh — trong khi một phân vùng cụ thể đã chạm trần và request rơi vào đó bị từ chối. Với dữ liệu cảm biến, phân vùng nóng thường hình thành đúng lúc triển khai thêm một lô thiết bị mới cùng model, cùng tiền tố định danh, và nó xuất hiện dưới dạng lỗi rải rác mà không tương quan với bất kỳ chỉ số tổng nào.

Đáp án

B — Lưu mỗi bản ghi vào bảng DynamoDB, dùng tính năng Time to Live (TTL) để xoá bản ghi quá 90 ngày.

Vì sao đúng

Bốn dữ kiện của đề khớp gần như hoàn hảo với hồ sơ của DynamoDB: hàng triệu bản ghi mỗi phút, mỗi bản ghi dưới 4 KB, truy cập độ trễ thấp, tự xoá sau 90 ngày.

⚠ Điểm mấu chốt: TTL xoá dữ liệu mà KHÔNG tiêu tốn write capacity — đó là điều kiện chi phí quyết định:

Cách thủ công: quét bảng tìm bản ghi cũ rồi gọi DeleteItem
        ↓
    Mỗi lần xoá tiêu 1 WCU, mỗi lần quét tiêu RCU
        ↓
    Với hàng tỷ bản ghi, chi phí xoá có thể vượt chi phí ghi

TTL: đặt một thuộc tính timestamp trên mỗi mục
        ↓
    DynamoDB tự xoá trong nền, KHÔNG tính WCU
        ↓
    → hoàn toàn miễn phí

Đây là lý do B thắng phương án A một cách dứt khoát về chi phí.

import time, boto3
bang = boto3.resource('dynamodb').Table('ban-ghi')

bang.put_item(Item={
    'thiet_bi_id': 'dev-001',
    'thoi_diem': int(time.time()),
    'du_lieu': '...',
    'het_han': int(time.time()) + 90 * 24 * 3600,   # thuộc tính TTL
})

aws dynamodb update-time-to-live --table-name ban-ghi \
  --time-to-live-specification Enabled=true,AttributeName=het_han

⚠ TTL không xoá đúng giây — nó xoá trong vòng vài ngày sau khi hết hạn:

Mục hết hạn
        ↓
    DynamoDB xoá trong nền, thường trong vòng 48 giờ, có khi lâu hơn
        ↓
    Trong khoảng đó mục VẪN nằm trong bảng và VẪN trả về khi truy vấn
        ↓
    → nếu yêu cầu là không được đọc thấy dữ liệu quá hạn, phải LỌC ở tầng truy vấn

Về ước tính dung lượng: 15–20 TB cho một năm, giữ 90 ngày, tức là khoảng 4–5 TB tại một thời điểm — hoàn toàn nằm trong khả năng của DynamoDB.

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

• A (RDS MySQL một bảng duy nhất, cron job hằng đêm xoá bản ghi cũ hơn 90 ngày) — đây là phương án gần nhất và nó chạy được về mặt chức năng: MySQL lưu được dữ liệu, cron xoá được bản ghi cũ. Nhưng nó hỏng ở cả hai tiêu chí của đề. Về quy mô: hàng triệu bản ghi mỗi phút vượt xa khả năng ghi của một instance RDS, và mở rộng dọc chỉ đi được tới một mức. Về chi phí và vận hành: một câu DELETE quét vài trăm triệu dòng mỗi đêm sẽ khoá bảng rất lâu, sinh khối lượng lớn dữ liệu hoàn tác, làm phình transaction log, và cạnh tranh I/O với chính luồng ghi đang diễn ra. Đây là mẫu thiết kế mà TTL của DynamoDB sinh ra để thay thế.

• C (mỗi bản ghi thành một tệp .csv riêng trong S3, lifecycle policy xoá sau 90 ngày) — sai ở kích thước đối tượng. Hàng triệu object mỗi phút, mỗi object dưới 4 KB, nghĩa là chi phí bị chi phối bởi phí request chứ không phải phí lưu trữ — PUT tính theo lượt, và với tốc độ này con số trở nên rất lớn. S3 cũng không cho độ trễ ở mức mili giây khi truy cập từng bản ghi, và không có cách truy vấn theo khoá như DynamoDB. S3 hợp khi gom nhiều bản ghi thành tệp lớn, không phải một bản ghi một tệp.

• D (lưu trong Kinesis Data Stream, dùng TTL xoá sau 90 ngày) — nhầm vai trò dịch vụ. Kinesis là đường ống truyền dữ liệu, không phải kho lưu trữ để truy vấn — bạn đọc tuần tự theo shard, không truy cập được một bản ghi cụ thể theo khoá. Thời gian giữ tối đa là 365 ngày nhưng đó là bộ đệm phát lại, không phải nơi để ứng dụng đọc dữ liệu với độ trễ thấp. Kinesis cũng không có tính năng nào tên là "TTL".

Ghi nhớ

⚠ Bốn kho dữ liệu cho bản ghi nhỏ, số lượng lớn — bảng phải thuộc: | Kho | Hợp khi | Không hợp khi | |---|---|---| | DynamoDB | bản ghi nhỏ, truy cập theo khoá, độ trễ mili giây | truy vấn phân tích phức tạp | | RDS / Aurora | cần join, giao dịch, SQL | ghi tốc độ rất cao | | S3 | object lớn, lưu trữ rẻ, phân tích theo lô | truy cập từng bản ghi nhỏ | | Timestream | chuỗi thời gian có truy vấn phân tích | truy cập kiểu khoá-giá trị đơn thuần |

Từ khoá nhận diện:

"millions of records per minute" + "less than 4 KB" → DynamoDB "delete after N days" → DynamoDB TTL, hoặc S3 lifecycle "low latency access" → loại S3 và Kinesis "cron job to delete old records" trên CSDL quan hệ quy mô lớn → tốn kém và khoá bảng "Kinesis TTL" → LUÔN SAI, không có tính năng đó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TTL có xoá thật không | theo dõi TimeToLiveDeletedItemCount | | Đơn vị thời gian có đúng không | so giá trị thuộc tính với date +%s | | Kích thước bảng có ổn định không | TableSizeBytes phải đi ngang sau 90 ngày |

Và một lời khuyên: hãy kiểm tra rằng giá trị TTL của bạn là epoch tính bằng GIÂY, ngay trong lần ghi đầu tiên. Đây là lỗi im lặng tốn kém nhất liên quan tới TTL: rất nhiều thư viện trả về thời gian bằng mili giây, và một giá trị mili giây được hiểu như giây sẽ rơi vào năm 56000 — nghĩa là không mục nào bao giờ bị xoá. DynamoDB không báo lỗi, không cảnh báo, không có gì bất thường trong log; bảng vẫn hoạt động hoàn hảo, chỉ là nó lớn dần mãi mãi. Với hàng triệu bản ghi mỗi phút, khoảng cách giữa "đang xoá đúng" và "không xoá gì cả" chỉ hiện ra trên hoá đơn lưu trữ vài tháng sau đó.

Đáp án

B — Dựng kết nối AWS Direct Connect 1 Gbps, tạo private virtual interface, rồi dùng AWS Application Migration Service (MGN) để chuyển các VM sang Amazon EC2.

Vì sao đúng

Đề có bốn ràng buộc, và ràng buộc thứ ba là chìa khoá: băng thông Internet đã dùng hết và không tăng được.

⚠ Điểm mấu chốt: MGN sao chép LIÊN TỤC trong lúc máy nguồn vẫn chạy — đó là cách giảm downtime:

Cài agent MGN lên VM nguồn (vẫn đang phục vụ)
        ↓
    Sao chép khối lưu trữ liên tục sang staging area trong AWS
        ↓
    Đồng bộ ban đầu xong → giữ trạng thái đồng bộ liên tục
        ↓
    Đến giờ cắt chuyển: dừng VM nguồn, phóng instance thử/thật
        ↓
    → downtime chỉ vài phút, không phụ thuộc kích thước dữ liệu

Đây là điểm phân biệt cốt lõi: với cách sao chép offline, downtime bằng thời gian chuyển toàn bộ dữ liệu; với MGN, downtime chỉ bằng thời gian cắt chuyển.

Phép tính băng thông — vì sao 1 Gbps là hợp lý:

Sáu tới bảy ngày nằm gọn trong ba tháng, kể cả khi tính thêm thời gian cung cấp Direct Connect.

⚠ Direct Connect mất thời gian cung cấp — phải tính vào lịch:

Đặt cổng DX chuyên dụng: thường vài tuần tới vài tháng
        ↓
    Qua đối tác (hosted connection): thường nhanh hơn nhiều
        ↓
    → với deadline 3 tháng, nên đi qua đối tác hoặc dùng hosted connection

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

• D (dùng MGN cho các VM quan trọng, xuất các VM còn lại rồi chuyển bằng Snowball, VM Import/Export để nhập) — đây là phương án gần nhất và nó rất hợp lý về mặt tư duy: dùng đúng công cụ cho từng nhóm máy, MGN cho máy không được dừng và Snowball cho phần còn lại khi băng thông thiếu. Nó cũng né được vấn đề băng thông. Nhưng nó vướng một mâu thuẫn nội tại: MGN cần băng thông mạng để sao chép liên tục, mà đề nói băng thông Internet đã dùng hết. Nếu không có Direct Connect thì chính phần MGN của phương án này cũng không chạy được. Ngoài ra, xử lý 150 VM qua hai đường ống khác nhau — với việc xuất OVA thủ công, chuyển đĩa vật lý, rồi nhập từng máy — là khối lượng công việc lớn hơn nhiều so với một quy trình MGN thống nhất, và ba tháng là khung thời gian eo hẹp cho việc đó.

• C (xuất VM cục bộ, dùng S3 Transfer Acceleration để tải lên, VM Import/Export để nhập) — S3 Transfer Acceleration vẫn đi qua Internet, mà băng thông Internet chính là thứ đã cạn. Transfer Acceleration tối ưu đường đi tới S3 nhưng không tạo thêm băng thông ở đầu ra của công ty. Phương án này bỏ qua ràng buộc trung tâm của đề. Nó cũng gây downtime lớn cho các VM quan trọng vì phải xuất offline.

• A (Storage Gateway file gateway, đồng bộ hệ thống tệp của VM, rồi VM Import/Export) — sai công cụ cho việc di chuyển máy chủ. File gateway đồng bộ tệp, không tạo ra ảnh máy khởi động được. VM Import/Export cần tệp OVA/VMDK hoàn chỉnh chứ không nhận một cây thư mục đã đồng bộ. Nó cũng vẫn đi qua Internet.

Ghi nhớ

⚠ Bốn công cụ di chuyển máy chủ — bảng phải thuộc: | Công cụ | Downtime | Điều kiện | |---|---|---| | MGN (Application Migration Service) | vài phút | cần băng thông cho sao chép liên tục | | VM Import/Export | bằng thời gian xuất + chuyển + nhập | phải xuất OVA/VMDK | | Snow Family | lớn (offline) | dùng khi băng thông không đủ | | DataSync | không áp dụng cho máy chủ | chỉ chuyển dữ liệu tệp |

Từ khoá nhận diện:

"downtime must be minimized" → MGN với sao chép liên tục "internet bandwidth fully utilized" → Direct Connect, hoặc Snow Family "S3 Transfer Acceleration" khi băng thông đã cạn → SAI, vẫn dùng chính đường đó "Server Migration Service (SMS)" → đã bị MGN thay thế "Storage Gateway để di chuyển máy chủ" → SAI, nó đồng bộ tệp không tạo AMI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sao chép có bắt kịp không | trạng thái Healthy và độ trễ trong console MGN | | Bản thử có khởi động được không | luôn chạy test launch trước cutover | | Băng thông thực tế | đo trên chính đường DX bằng iperf |

Và một lời khuyên: hãy chạy test launch cho mọi máy quan trọng và thật sự đăng nhập vào bản thử, đừng chỉ xem trạng thái sao chép là Healthy. Trạng thái đó chỉ nói rằng các khối dữ liệu đã được sao chép đầy đủ — nó không nói gì về việc máy có khởi động được trên phần cứng ảo của AWS hay không. Driver thiếu, cấu hình mạng cứng nhắc theo card cũ, phần mềm bị khoá theo địa chỉ MAC, boot loader trỏ tới thiết bị không còn tồn tại — tất cả đều cho ra một bản sao "hoàn hảo" ở tầng khối và một máy không lên nổi ở tầng hệ điều hành. Phát hiện điều đó trong một lần test launch tốn vài chục phút; phát hiện nó trong cửa sổ cắt chuyển đêm khuya thì tốn cả kế hoạch.

Đáp án

D — Tạo EC2 instance cho dịch vụ; tạo một Elastic IP cho MỖI Availability Zone; tạo Network Load Balancer phơi cổng TCP đã định, gán các Elastic IP cho NLB ở từng AZ; tạo target group đăng ký các EC2; tạo bản ghi A (alias) cloud.myservice.com trỏ tới tên DNS của NLB.

Vì sao đúng

Đề đòi ba thứ, và cách chúng kết hợp mới là nội dung câu hỏi: cổng TCP tuỳ biến, địa chỉ cố định để công ty khác đưa vào danh sách cho phép, và sẵn sàng cao trên nhiều AZ trong một Region.

⚠ Điểm mấu chốt: địa chỉ cần whitelist phải là của BỘ CÂN BẰNG TẢI, không phải của EC2:

Whitelist IP của từng EC2
        ↓
    Auto Scaling thay máy, hoặc máy hỏng và được dựng lại
        ↓
    IP đổi → đối tác phải cập nhật tường lửa của họ
        ↓
    → không bao giờ chấp nhận được

Whitelist Elastic IP của NLB
        ↓
    Địa chỉ đó cố định vĩnh viễn, không phụ thuộc máy phía sau
        ↓
    → thay máy, thêm máy, bớt máy đều không ảnh hưởng đối tác

Đây là lý do phương án A và C sai dù chúng cũng dùng NLB: chúng đưa IP của EC2 cho đối tác.

Vì sao mỗi AZ một Elastic IP. NLB đặt một node ở mỗi AZ được bật, và mỗi node có địa chỉ riêng. Đó chính là cách NLB đạt tính sẵn sàng cao — mất một AZ thì các node còn lại vẫn phục vụ. Đối tác đưa toàn bộ các địa chỉ đó vào danh sách cho phép.

aws elbv2 create-load-balancer --name dich-vu-nlb --type network \
  --subnet-mappings SubnetId=subnet-1a,AllocationId=eipalloc-aaa \
                    SubnetId=subnet-1b,AllocationId=eipalloc-bbb

⚠ Elastic IP chỉ gán được LÚC TẠO NLB — không thêm được sau:

Tạo NLB không kèm allocation ID
        ↓
    Nó nhận địa chỉ do AWS cấp, không cố định theo cách bạn kiểm soát
        ↓
    → KHÔNG có cách nào gán Elastic IP về sau
        ↓
    → phải tạo lại NLB từ đầu

Vì sao bản ghi A alias. Alias trỏ tới tên DNS của NLB và dùng được ở zone apex, không tính phí truy vấn, và tự cập nhật khi hạ tầng NLB thay đổi.

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

• A (ECS cluster, gán IP công cộng cho cluster, NLB phơi cổng TCP, bản ghi A trỏ tới IP công cộng của ECS, đưa IP của ECS cho đối tác whitelist) — đây là phương án gần nhất và nó chọn đúng NLB cho cổng TCP tuỳ biến. Nhưng nó phá hỏng chính mục đích của bộ cân bằng tải: bản ghi DNS trỏ thẳng tới IP của các host ECS, bỏ qua NLB hoàn toàn, và IP đưa cho đối tác cũng là của các host đó. Những địa chỉ ấy thay đổi mỗi khi task được xếp lại hoặc instance được thay — đúng thứ mà yêu cầu "fixed address assignments" cấm. Kết quả là NLB tồn tại nhưng không nằm trên đường đi, và tính sẵn sàng cao biến mất.

• C (EC2 với Elastic IP cho từng instance, NLB, bản ghi "name server" trỏ tới Elastic IP của EC2, đưa IP của EC2 cho đối tác) — cùng lỗi cốt lõi: whitelist IP của máy chứ không của bộ cân bằng tải, nên mỗi lần thay máy là đối tác phải sửa tường lửa. Ngoài ra nó còn một lỗi kỹ thuật rõ ràng: "name server record set" (bản ghi NS) dùng để uỷ quyền một zone DNS cho máy chủ tên khác — nó không trỏ tới địa chỉ IP của một dịch vụ. Dùng bản ghi NS ở đây là sai loại bản ghi.

• B (ALB phơi "static TCP port", bản ghi CNAME, đưa Elastic IP của EC2 cho đối tác) — sai từ chỗ căn bản nhất: ALB không xử lý được cổng TCP tuỳ biến, nó chỉ hiểu HTTP/HTTPS ở tầng 7. Nó cũng lặp lại lỗi whitelist IP của EC2, và dùng CNAME thì không đặt được ở zone apex.

Ghi nhớ

⚠ Bốn cách có địa chỉ cố định trên AWS — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Elastic IP gán cho NLB | một IP mỗi AZ, cố định vĩnh viễn | | Global Accelerator | hai IP anycast toàn cầu, dùng được đa Region | | Elastic IP gán cho EC2 | cố định nhưng gắn với một máy — không sẵn sàng cao | | ALB | không có IP tĩnh, chỉ có tên DNS |

Từ khoá nhận diện:

"custom TCP port" → NLB, loại ALB "fixed addresses for whitelisting" → Elastic IP trên NLB, hoặc Global Accelerator "whitelist the EC2 instance IPs" → LUÔN SAI, IP đổi khi thay máy "high availability across AZs in a single Region" → NLB nhiều AZ, không cần Global Accelerator "name server record set" để trỏ tới dịch vụ → SAI loại bản ghi, NS dùng để uỷ quyền zone

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Địa chỉ có thật sự cố định không | dig cloud.myservice.com nhiều lần, so kết quả | | Đối tác đã whitelist đủ chưa | phải đủ tất cả Elastic IP, mỗi AZ một cái | | Mất một AZ có sao không | tắt thử target ở một AZ, xem dịch vụ còn chạy không |

Và một lời khuyên: hãy gửi cho đối tác đầy đủ danh sách Elastic IP của mọi AZ, và báo cho họ mỗi khi bạn thêm một AZ mới. Đây là chỗ sự cố xảy ra rất lâu sau khi mọi thứ đã chạy ổn: nếu đối tác chỉ whitelist hai trong ba địa chỉ, kết nối của họ vẫn thành công phần lớn thời gian — DNS của NLB trả về nhiều địa chỉ và client xoay vòng giữa chúng, nên chỉ khoảng một phần ba số kết nối bị chặn. Triệu chứng là lỗi ngắt quãng, không tái hiện được, tự khỏi khi thử lại, và cả hai bên đều sẽ đổ cho mạng trước khi có ai nghĩ tới việc đếm xem danh sách cho phép có đủ địa chỉ hay không.

Đáp án

D — Dựng REST API bằng Amazon API Gateway, chạy nghiệp vụ trong AWS Lambda, lưu dữ liệu phiên của trader trong DynamoDB với on-demand capacity.

Vì sao đúng

Đề nêu ba yêu cầu và mỗi thành phần của phương án D lo một cái.

⚠ Điểm mấu chốt: nguyên nhân độ trễ hiện tại là NAS tại chỗ, nên đích đến phải là kho khoá-giá trị nhanh:

Hiện tại: dữ liệu phiên nằm trên NAS trong trung tâm dữ liệu
        ↓
    Mỗi lần chạy mô phỏng phải đọc tệp qua giao thức tệp mạng
        ↓
    Giờ cao điểm → NAS quá tải → độ trễ tăng vọt
        ↓
    DynamoDB: đọc theo khoá, mili giây một chữ số, thông lượng mở rộng ngang
        ↓
    → nút thắt biến mất chứ không chỉ được nới rộng

Vì sao API Gateway chứ không phải ALB. Đề nói "use the same API model" — API hiện tại là REST với nhiều hàm. API Gateway là dịch vụ dựng riêng cho REST API: quản lý stage, phiên bản, throttling, API key, usage plan, xác thực, cache. ALB chỉ định tuyến HTTP; nó không có khái niệm "REST API" với các tài nguyên và phương thức.

Vì sao on-demand capacity. Đề mô tả tải biến động với đỉnh trong ngày. On-demand hấp thụ đỉnh tức thì mà không cần dự báo, đúng hình thái đó.

aws dynamodb create-table --table-name phien-trader \
  --billing-mode PAY_PER_REQUEST \
  --attribute-definitions AttributeName=phien_id,AttributeType=S \
  --key-schema AttributeName=phien_id,KeyType=HASH

⚠ Lambda có giới hạn 15 phút — mô phỏng thị trường chạy lâu hơn thì cần kiến trúc khác:

Nếu một lần mô phỏng vượt 15 phút
        ↓
    Lambda không chạy nổi
        ↓
    → tách thành các bước điều phối bằng Step Functions,
      hoặc chuyển phần tính toán nặng sang Fargate / Batch
        ↓
    → API Gateway + Lambda vẫn giữ vai trò tiếp nhận và điều phối

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

• C (ALB, Lambda, DynamoDB on-demand) — đây là phương án gần nhất và hai phần ba của nó giống hệt đáp án đúng: Lambda cho nghiệp vụ và DynamoDB cho phiên đều chuẩn. Nó chỉ khác ở lớp API. ALB có thể gọi Lambda qua target group, nên về mặt kỹ thuật nó chạy — nhưng nó không giữ được "same API model" mà đề đòi. Với ALB bạn mất hết những thứ định nghĩa nên một REST API được quản lý: định nghĩa tài nguyên và phương thức, stage và giai đoạn triển khai, throttling theo từng client, usage plan và API key, xác thực bằng authorizer, request/response mapping, và tài liệu OpenAPI sinh sẵn. Với một API tài chính phục vụ nhiều trader, những thứ đó không phải tuỳ chọn trang trí.

• B (AWS AppSync, Lambda, Aurora Serverless) — sai ở cả hai đầu. AppSync là dịch vụ GraphQL, không phải REST — chuyển sang nó nghĩa là viết lại toàn bộ hợp đồng API, trái với yêu cầu giữ nguyên mô hình. Còn Aurora Serverless là cơ sở dữ liệu quan hệ; dữ liệu phiên là khoá-giá trị đơn giản, không cần quan hệ, và Aurora cho độ trễ cao hơn DynamoDB cho kiểu truy cập này.

• A (NLB, một EC2 instance, Aurora Serverless) — không giải quyết gì cả. Một EC2 instance lặp lại đúng vấn đề thiếu dung lượng ở giờ cao điểm mà đề mô tả. NLB ở tầng 4 cũng không phải cách dựng REST API. Và Aurora Serverless lại là lựa chọn sai cho dữ liệu phiên.

Ghi nhớ

⚠ Bốn lớp API của AWS — bảng phải thuộc: | Dịch vụ | Kiểu API | Dùng khi | |---|---|---| | API Gateway REST API | REST đầy đủ tính năng | cần usage plan, API key, cache, authorizer | | API Gateway HTTP API | REST tối giản | rẻ hơn ~70%, độ trễ thấp hơn, ít tính năng | | AppSync | GraphQL | client tự chọn trường, gộp nhiều nguồn | | ALB | định tuyến HTTP thuần | không phải công cụ quản lý API |

Từ khoá nhận diện:

"same API model" + REST → API Gateway "session data with low latency" → DynamoDB (hoặc ElastiCache) "variable load" → Lambda + DynamoDB on-demand "AppSync" khi đề nói giữ nguyên REST → SAI, đó là GraphQL "a single EC2 instance" khi vấn đề là thiếu dung lượng → SAI, lặp lại vấn đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ ở đâu | bật X-Ray để thấy thời gian của từng chặng | | Có bị throttle không | 4XXError của API Gateway và ThrottledRequests của DynamoDB | | Cold start ảnh hưởng bao nhiêu | so Duration với InitDuration trong log Lambda |

Và một lời khuyên: hãy bật X-Ray trước khi kết luận thành phần nào đang chậm. Với kiến trúc nhiều tầng như thế này, độ trễ mà người dùng cảm nhận là tổng của API Gateway, cold start Lambda, thời gian chạy hàm và thời gian truy vấn DynamoDB — nhưng không tầng nào trong số đó tự báo rằng mình là thủ phạm. Chỉ số Duration của Lambda đã bao gồm cả thời gian chờ DynamoDB, còn chỉ số Latency của API Gateway đã bao gồm cả Lambda. Nhìn từng biểu đồ riêng lẻ, mọi thứ đều trông "hơi chậm" và bạn sẽ tối ưu nhầm chỗ. X-Ray tách chúng ra thành từng đoạn riêng biệt, và câu trả lời thường không phải cái bạn đoán.

Đáp án

D, E, F — ba bước đáp ứng cả năm mục tiêu của đề:

• F — Tạo Auto Scaling group của EC2 trên hai Availability Zone và gắn Application Load Balancer.
• E — Chuyển cơ sở dữ liệu sang Aurora MySQL cluster cấu hình Multi-AZ.
• D — Đưa nội dung tĩnh vào S3, dùng CloudFront giảm độ trễ, dùng AWS WAF tăng bảo mật.

Vì sao đúng

Đề liệt kê năm mục tiêu. Cách nhanh nhất để giải là lập bảng xem bước nào phục vụ mục tiêu nào — phương án đúng phải phủ hết.

⚠ Điểm mấu chốt: CloudFront giảm độ trễ toàn cầu, còn S3 Transfer Acceleration thì KHÔNG — nó cho chiều ngược lại:

CloudFront: phân phối nội dung XUỐNG người dùng
        ↓
    Cache tại hơn 600 điểm biên gần người dùng
        ↓
    → đúng thứ một website quốc tế cần

S3 Transfer Acceleration: tối ưu việc TẢI LÊN S3 từ nơi xa
        ↓
    → không phải công cụ phục vụ trang web cho khách

Đây là điểm phân biệt duy nhất giữa phương án C và D, và nó quyết định.

Vì sao Aurora Multi-AZ chứ không phải RDS single-AZ (phương án B). Single-AZ nghĩa là một AZ hỏng thì cơ sở dữ liệu mất — trái hẳn hai mục tiêu "reliability" và "availability". Aurora còn thêm lợi thế: lưu trữ tự sao chép sáu bản trên ba AZ, chuyển dự phòng thường dưới 30 giây, và mở rộng đọc bằng replica.

aws rds create-db-cluster --db-cluster-identifier shop-aurora \
  --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.05.2 \
  --master-username admin --manage-master-user-password

# thêm hai instance ở hai AZ khác nhau — đây là phần tạo tính sẵn sàng
aws rds create-db-instance --db-instance-identifier shop-aurora-1 \
  --db-cluster-identifier shop-aurora --db-instance-class db.r6g.large --engine aurora-mysql
aws rds create-db-instance --db-instance-identifier shop-aurora-2 \
  --db-cluster-identifier shop-aurora --db-instance-class db.r6g.large --engine aurora-mysql

⚠ Một cụm Aurora chỉ có một instance thì KHÔNG phải Multi-AZ:

Lưu trữ Aurora luôn trải ba AZ — đó là mặc định
        ↓
    Nhưng nếu chỉ có MỘT instance, AZ chứa nó hỏng là mất khả năng phục vụ
        ↓
    → phải có ít nhất hai instance ở hai AZ mới có tự chuyển dự phòng

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

• C (S3 + S3 Transfer Acceleration để giảm độ trễ khi phục vụ trang, WAF) — đây là phương án gần nhất và hai phần ba của nó trùng với đáp án đúng: đưa nội dung tĩnh vào S3 và dùng WAF đều chuẩn. Nó chỉ sai đúng một công cụ, và sai theo hướng dễ nhầm nhất: Transfer Acceleration tối ưu chiều TẢI LÊN, dùng mạng điểm biên để đưa dữ liệu vào S3 nhanh hơn từ nơi xa. Nó không cache gì và không giúp gì cho việc phục vụ trang web cho khách quốc tế. Cả hai dịch vụ đều dùng chung hạ tầng điểm biên của CloudFront, nên tên gọi rất dễ khiến người ta nghĩ chúng thay thế được cho nhau — nhưng chúng phục vụ hai chiều ngược nhau.

• A (EC2 trên hai AZ để tự dựng cụm MySQL sẵn sàng cao) — đi ngược mục tiêu "reduces maintenance". Tự quản MySQL nghĩa là tự vá, tự sao lưu, tự viết cơ chế phát hiện hỏng và chuyển dự phòng, tự giám sát sao chép. Aurora làm sẵn tất cả và thường cho độ tin cậy cao hơn, vì cơ chế chuyển dự phòng tự viết chính là chỗ hay hỏng nhất.

• B (chuyển sang RDS for MySQL single-AZ) — giảm được bảo trì nhưng phá hỏng hai mục tiêu về độ tin cậy và tính sẵn sàng. Một AZ hỏng là cơ sở dữ liệu ngừng phục vụ, và trong lúc bảo trì có kế hoạch cũng có downtime. Với danh sách năm mục tiêu của đề, đây là phương án tự mâu thuẫn.

Ghi nhớ

⚠ Bốn cặp dịch vụ hay bị lẫn — bảng phải thuộc: | Cặp | Khác nhau | |---|---| | CloudFront ↔ S3 Transfer Acceleration | xuống (phục vụ) ↔ lên (tải vào S3) | | Multi-AZ ↔ Read replica | sẵn sàng (tự chuyển) ↔ mở rộng đọc (promote thủ công) | | ALB ↔ NLB | tầng 7 ↔ tầng 4 | | WAF ↔ Shield | tầng 7 theo nội dung ↔ chống DDoS tầng 3/4 |

Từ khoá nhận diện:

"reduce latency" cho người dùng quốc tế → CloudFront "improve availability" + CSDL → Multi-AZ "reduce maintenance" → dịch vụ có quản lý, loại tự dựng trên EC2 "S3 Transfer Acceleration để phục vụ trang web" → SAI, đó là chiều tải lên "single-AZ" khi đề đòi tính sẵn sàng → LUÔN SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm có thật sự nhiều AZ không | kiểm số instance và AZ của chúng, không chỉ xem nhãn cụm | | CloudFront có cache không | chỉ số CacheHitRate | | Chuyển dự phòng có chạy không | aws rds failover-db-cluster trong giờ thấp điểm |

Và một lời khuyên: hãy đếm số instance trong cụm Aurora và xem chúng nằm ở AZ nào, đừng tin vào chữ "Multi-AZ" trên giao diện. Lưu trữ của Aurora luôn trải ba AZ, nên bảng điều khiển có thể tạo cảm giác cụm đã sẵn sàng cao ngay cả khi nó chỉ có đúng một instance. Trong trạng thái bình thường không có gì khác biệt — hiệu năng như nhau, sao lưu như nhau, mọi chỉ số như nhau. Khác biệt chỉ xuất hiện đúng vào lúc AZ chứa instance duy nhất đó gặp sự cố: dữ liệu của bạn vẫn an toàn nguyên vẹn ở hai AZ còn lại, nhưng không có instance nào để phục vụ nó, và cụm phải dựng một instance mới từ đầu trong khi trang web đang nằm im.