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

Đáp án

A — Cài CloudWatch agent lên các instance, chạy script thu thập theo lịch, và theo dõi metric SwapUtilization trong CloudWatch.

Vì sao đúng

Đề cần đo mức dùng swap trên EC2, và điểm mấu chốt là:

⚠ CloudWatch KHÔNG tự thấy được bộ nhớ và swap:

Metric mặc định của EC2 lấy từ HYPERVISOR
    → CPU, mạng, đĩa (ở mức thiết bị)
        ↓
    Bộ nhớ, swap, dung lượng đĩa còn trống
    → nằm BÊN TRONG hệ điều hành
    → hypervisor không nhìn thấy
        ↓
    Phải cài agent bên trong máy để đẩy ra

Đây là lý do các phương án B, C, D đều sai: chúng giả định metric đã tồn tại sẵn.

Cài agent bằng Systems Manager:

aws ssm send-command \
  --document-name "AWS-ConfigureAWSPackage" \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'action=Install,name=AmazonCloudWatchAgent'

Cấu hình thu thập swap và bộ nhớ:

{"metrics": {
  "namespace": "UngDung/HeDieuHanh",
  "append_dimensions": {
    "InstanceId": "${aws:InstanceId}",
    "AutoScalingGroupName": "${aws:AutoScalingGroupName}"},
  "metrics_collected": {
    "mem": {"measurement": ["mem_used_percent", "mem_available"],
            "metrics_collection_interval": 60},
    "swap": {"measurement": ["swap_used_percent", "swap_used"],
             "metrics_collection_interval": 60},
    "disk": {"measurement": ["used_percent"],
             "resources": ["/"]}}}}

Đẩy cấu hình và khởi động:

aws ssm put-parameter --name /cloudwatch/cau-hinh-agent \
  --type String --value file://cau-hinh.json --overwrite

aws ssm send-command \
  --document-name "AmazonCloudWatch-ManageAgent" \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'action=configure,mode=ec2,
    optionalConfigurationSource=ssm,
    optionalConfigurationLocation=/cloudwatch/cau-hinh-agent,
    optionalRestart=yes'

⚠ Instance profile phải có quyền:

CloudWatchAgentServerPolicy
    → đẩy metric lên CloudWatch
AmazonSSMManagedInstanceCore
    → nhận lệnh và đọc parameter

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thấy được metric bên trong hệ điều hành | | | Quản lý cấu hình tập trung qua SSM | | | Gộp chung với việc thu thập log | |

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

⚠ Tên metric trong đề là của bộ công cụ ĐÃ LỖI THỜI.

SwapUtilization là tên metric của CloudWatch Monitoring Scripts — bộ script Perl cũ (mon-put-instance-data.pl) mà AWS đã ngừng khuyến nghị. Đó cũng là lý do đề nhắc tới "chạy script theo lịch".

Với unified CloudWatch agent hiện nay, tên metric khác:

Và agent hiện đại KHÔNG chạy theo lịch
    → nó là daemon chạy liên tục
    → tự đẩy metric theo `metrics_collection_interval`
        ↓
    Vế "run an appropriate script on a set schedule"
    mô tả cách làm của mười năm trước

Kết luận không đổi — phải cài agent, đó là ý chính và ba phương án kia đều sai vì bỏ qua điều đó. Nhưng nếu dựng thật, hãy dùng unified agent và tên metric swap_used_percent.

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

• **B. Bật detailed monitoring rồi tạo custom metric SwapUtilization — đây là phương án gần nhất và nhắc đúng tên metric, nhưng detailed monitoring chỉ tăng tần suất metric đã có từ 5 phút xuống 1 phút; nó không thêm metric nào mới, và custom metric không tự xuất hiện — phải có thứ gì đó đẩy lên.
• **C. Dùng EC2 metadata thu thập rồi đẩy lên CloudWatch — metadata chứa thông tin về cấu hình instance (ID, loại máy, IAM role), không chứa số liệu vận hành như swap.
• **D. Cấu hình dimension SwapUsage trong metric EC2 — dimension là cách phân nhóm một metric đã tồn tại, không phải cách tạo ra metric mới; và EC2 không có metric swap nào.

Ghi nhớ

⚠ Metric EC2 có sẵn và KHÔNG có sẵn — bảng phải thuộc: | Có sẵn (từ hypervisor) | KHÔNG có sẵn (cần agent) | |---|---| | CPUUtilization | bộ nhớ (mem_used_percent) | | NetworkIn / NetworkOut | swap (swap_used_percent) | | DiskReadOps / DiskWriteOps | dung lượng đĩa còn trống (disk_used_percent) | | StatusCheckFailed | số tiến trình, kết nối TCP |

⚠ Đây là một trong những câu hỏi hay gặp nhất về CloudWatch.

Từ khoá nhận diện:

"memory, swap, disk space utilization" → phải cài CloudWatch agent "CPU, network, disk I/O" → có sẵn, không cần agent "1-minute instead of 5-minute" → detailed monitoring "application logs" → CloudWatch agent hoặc Logs agent

Ba lưu ý về detailed monitoring: | Lưu ý | Chi tiết | |---|---| | Chỉ đổi TẦN SUẤT, không thêm metric | | | 5 phút → 1 phút | | | ~0,30 USD mỗi instance mỗi tháng | |

Ba nhóm metric agent thu thập được: | Nhóm | Ví dụ | |---|---| | mem | mem_used_percent, mem_available | | swap | swap_used_percent | | disk, diskio | used_percent, io_time | | net, netstat, processes | |

⚠ Chọn ít metric thôi — mỗi metric tính tiền:

Custom metric: ~0,30 USD mỗi metric mỗi tháng
    → 10 metric × 100 máy = 300 USD/tháng
        ↓
    Chỉ thu thập thứ thật sự dùng để cảnh báo

Ba lưu ý về dimension: | Lưu ý | Chi tiết | |---|---| | Mỗi tổ hợp dimension là một metric riêng | | | Thêm dimension = nhân số metric | | | append_dimensions gắn tự động | |

Ba lưu ý về đặt cảnh báo cho swap: | Lưu ý | Chi tiết | |---|---| | Swap dùng nhiều = thiếu RAM | | | Ngưỡng thường 20-30% | | | Cảnh báo kèm cả mem_available | |

aws cloudwatch put-metric-alarm --alarm-name swap-cao \
  --namespace UngDung/HeDieuHanh --metric-name swap_used_percent \
  --dimensions Name=AutoScalingGroupName,Value=asg-web \
  --statistic Average --period 300 --evaluation-periods 3 \
  --threshold 25 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

⚠ Swap cao thường là triệu chứng, không phải nguyên nhân:

Swap tăng = hệ điều hành đang đẩy trang ra đĩa
    → RAM không đủ cho tải hiện tại
        ↓
    Cách chữa: tăng cỡ instance, hoặc tìm rò rỉ
                bộ nhớ trong ứng dụng
    → không phải tăng swap

Ba lưu ý về cài agent hàng loạt: | Cách | Chi tiết | |---|---| | SSM Distributor | cài gói lên nhiều máy | | State Manager | giữ agent luôn được cài | | Đưa vào AMI | máy mới có sẵn |

⚠ State Manager tốt hơn cài một lần:

aws ssm create-association \
  --name AWS-ConfigureAWSPackage \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'action=Install,name=AmazonCloudWatchAgent' \
  --schedule-expression "rate(1 day)"

Máy mới do ASG tạo tự được cài
    → không phụ thuộc ai nhớ

Ba lưu ý về log: | Lưu ý | Chi tiết | |---|---| | Cùng agent thu thập cả log | | | Cấu hình trong mục logs | | | Đặt retention cho log group | |

Ba lưu ý về container: | Môi trường | Cách thu thập | |---|---| | ECS | Container Insights | | EKS | CloudWatch agent dạng DaemonSet | | Fargate | Container Insights |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra agent đang chạy | | | Xem metric xuất hiện trong namespace | | | Đối chiếu với free -m trên máy | |

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a status

Và một lời khuyên: hãy dùng State Manager để giữ agent luôn được cài thay vì cài một lần. Auto Scaling tạo máy mới liên tục, và một đội máy mà chỉ những máy cũ có agent sẽ cho ra đồ thị trông bình thường trong khi phần lớn hạ tầng không được giám sát chút nào.

Đáp án

C — Tạo thêm một bucket S3 có bật versioning ở Region khác và cấu hình Cross-Region Replication (CRR).

Vì sao đúng

Đề nêu hai yêu cầu, và chi tiết quyết định nằm ở từ "versioning": | Yêu cầu | Cách đáp ứng | |---|---| | Nhân bản dữ liệu sang Region khác cho DR | Cross-Region Replication | | Bucket nguồn đã bật versioning | bucket ĐÍCH cũng PHẢI bật versioning |

⚠ Versioning ở CẢ HAI bucket là điều kiện BẮT BUỘC của CRR:

CRR yêu cầu:
    → bucket nguồn bật versioning
    → bucket đích bật versioning
        ↓
    Thiếu một bên = KHÔNG cấu hình được replication
    → không phải "chạy kém", mà là không tạo được

Đây chính là lý do phương án B sai — nó tạo bucket đích mà không nói tới versioning.

Bật versioning ở bucket đích:

aws s3api put-bucket-versioning \
  --bucket kho-du-lieu-dr --region ap-northeast-1 \
  --versioning-configuration Status=Enabled

Cấu hình replication:

{"Role": "arn:aws:iam::123456789012:role/VaiTroNhanBanS3",
 "Rules": [{
   "ID": "nhan-ban-dr",
   "Priority": 1,
   "Status": "Enabled",
   "Filter": {},
   "DeleteMarkerReplication": {"Status": "Enabled"},
   "Destination": {
     "Bucket": "arn:aws:s3:::kho-du-lieu-dr",
     "StorageClass": "STANDARD_IA",
     "ReplicationTime": {"Status": "Enabled",
                         "Time": {"Minutes": 15}},
     "Metrics": {"Status": "Enabled",
                 "EventThreshold": {"Minutes": 15}}}}]}

aws s3api put-bucket-replication --bucket kho-du-lieu-chinh \
  --replication-configuration file://nhan-ban.json

⚠ ReplicationTime bật S3 RTC — cam kết 15 phút cho 99,99% object:

Không bật RTC: nhân bản "thường trong vài phút"
              nhưng không có cam kết
        ↓
    Bật RTC: có SLA, có metric, có sự kiện khi trễ
    → tính phí thêm nhưng đo được RPO

⚠ CRR chỉ nhân bản object TỪ LÚC BẬT trở đi:

Object đã có từ trước KHÔNG tự nhân bản
    → phải chạy S3 Batch Replication cho chúng

aws s3control create-job --account-id 123456789012 \
  --operation '{"S3ReplicateObject":{}}' \
  --manifest-generator '{"S3JobManifestGenerator":{
    "SourceBucket":"arn:aws:s3:::kho-du-lieu-chinh",
    "Filter":{"ObjectReplicationStatuses":["NONE"]},
    "EnableManifestOutput":false}}' \
  --priority 10 --role-arn <arn-role> --no-confirmation-required

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bản sao ở Region khác cho DR | | | Giữ được lịch sử phiên bản hai bên | | | Chuyển sang lớp rẻ hơn ở đích được | |

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

• **B. Tạo bucket ở Region khác và cấu hình CRR — đây là phương án gần nhất và đúng về công cụ, nhưng thiếu điều kiện versioning ở bucket đích; không có nó thì CRR không cấu hình được.
• **A và D. Cấu hình CORS — CORS (Cross-Origin Resource Sharing) kiểm soát trình duyệt có được gọi bucket từ tên miền khác hay không; nó hoàn toàn không liên quan tới sao chép dữ liệu.

Ghi nhớ

⚠ Bốn điều kiện của S3 Replication — bảng phải thuộc: | Điều kiện | Chi tiết | |---|---| | Versioning bật ở CẢ HAI bucket | | | Vai trò IAM cho S3 đảm nhận | | | Object mới mới được nhân bản | cũ cần Batch Replication | | Bucket đích phải tồn tại trước | |

⚠ CRR vs SRR: | Loại | Phạm vi | Dùng cho | |---|---|---| | CRR | Region khác | DR, tuân thủ địa lý, giảm độ trễ | | SRR | cùng Region | gộp log, tách môi trường, khác tài khoản |

Từ khoá nhận diện:

"replicate to another Region for DR" → CRR (versioning cả hai bên) "browser calling bucket from another domain" → CORS "replicate existing objects" → S3 Batch Replication "guaranteed replication time" → S3 RTC

Ba thứ CRR KHÔNG nhân bản mặc định: | Thứ | Chi tiết | |---|---| | Object đã có trước khi bật | cần Batch Replication | | Object mã hoá SSE-C | không hỗ trợ | | Xoá theo version ID cụ thể | chỉ delete marker |

⚠ DeleteMarkerReplication là lựa chọn phải cân nhắc:

Bật:  xoá ở nguồn → delete marker sang đích
      → hai bên giống nhau
        ↓
Tắt:  xoá ở nguồn → đích GIỮ NGUYÊN
      → bảo vệ khỏi xoá nhầm
        ↓
    Cho DR thuần: bật
    Cho lưu trữ chống xoá nhầm: tắt

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | SSE-S3 và SSE-KMS nhân bản được | | | SSE-KMS cần cấu hình SourceSelectionCriteria | | | Cần khoá KMS ở Region đích | |

{"SourceSelectionCriteria": {
   "SseKmsEncryptedObjects": {"Status": "Enabled"}},
 "Destination": {
   "EncryptionConfiguration": {
     "ReplicaKmsKeyID": "<arn-khoa-vung-dich>"}}}

Ba lưu ý về vai trò IAM: | Quyền cần | Ở đâu | |---|---| | s3:GetObjectVersionForReplication | bucket nguồn | | s3:ReplicateObject, s3:ReplicateDelete | bucket đích | | kms:Decrypt và kms:Encrypt | nếu dùng SSE-KMS |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí truyền dữ liệu xuyên Region | | | Phí lưu trữ ở bucket đích | | | RTC tính phí thêm theo GB | |

⚠ Chuyển lớp lưu trữ ở đích để giảm chi phí:

{"Destination": {"StorageClass": "STANDARD_IA"}}

Bản sao DR hiếm khi đọc
    → để ở Standard-IA hoặc Glacier IR
    → giảm ~50-80% chi phí lưu trữ

Ba lưu ý về theo dõi: | Cách | Chi tiết | |---|---| | Metric ReplicationLatency | | | OperationsPendingReplication | | | Sự kiện s3:Replication:OperationFailedReplication | |

⚠ Đặt cảnh báo cho object nhân bản thất bại:

aws s3api put-bucket-notification-configuration \
  --bucket kho-du-lieu-chinh \
  --notification-configuration '{
    "EventBridgeConfiguration": {}}'

Object thất bại không tự thử lại vô hạn
    → không có cảnh báo thì chúng biến mất khỏi bản DR
      mà không ai biết

Ba lưu ý về replication nhiều đích: | Lưu ý | Chi tiết | |---|---| | Một bucket nhân bản tới NHIỀU đích được | | | Mỗi đích một rule, khác priority | | | Dùng cho DR + tuân thủ đồng thời | |

Ba lưu ý về versioning: | Lưu ý | Chi tiết | |---|---| | Phiên bản cũ vẫn tính tiền | | | Đặt lifecycle cho phiên bản không hiện hành | | | Bật rồi chỉ tạm dừng được, không tắt hẳn | |

{"NoncurrentVersionExpiration": {"NoncurrentDays": 90}}

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy object mới, kiểm tra ở đích | | | Xem ReplicationStatus của object | | | Theo dõi metric độ trễ | |

aws s3api head-object --bucket kho-du-lieu-chinh --key tep.dat \
  --query ReplicationStatus

Và một lời khuyên: hãy chạy S3 Batch Replication cho dữ liệu đã có ngay sau khi bật CRR. Cấu hình replication chỉ áp cho object ghi từ thời điểm đó trở đi, nên nếu bạn vừa tải lên "một lượng lớn dữ liệu quan trọng" thì phần lớn nó vẫn chỉ tồn tại ở một Region.

Đáp án

B — Dùng AWS AppSync với nhiều data source và resolver.

Vì sao đúng

Đề nêu ba yêu cầu, và AppSync đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Tương tác với NHIỀU bảng DynamoDB | mỗi bảng là một data source | | Hiệu năng NHẤT QUÁN, không bị ảnh hưởng | resolver gọi song song, không xếp chồng | | HIỆU QUẢ VẬN HÀNH nhất | không viết mã kết nối, không quản lý máy chủ |

⚠ Điểm mạnh nhất của AppSync — một yêu cầu, nhiều bảng, gọi SONG SONG:

Kiến trúc Lambda thông thường:
    → một hàm gọi bảng A, chờ
    → rồi gọi bảng B, chờ
    → rồi gọi bảng C
        ↓
    Độ trễ = tổng của cả ba
        ↓
AppSync: resolver cho từng trường chạy SONG SONG
    → độ trễ = chậm nhất trong ba

Schema với nhiều nguồn:

type DonHang {
  ma: ID!
  khachHang: KhachHang
  sanPham: [SanPham]
  vanChuyen: VanChuyen
}

type Query {
  layDonHang(ma: ID!): DonHang
}

DonHang    → bảng DonHang
khachHang  → bảng KhachHang
sanPham    → bảng SanPham
vanChuyen  → bảng VanChuyen
        ↓
    Bốn data source, client gọi MỘT lần

Gắn data source:

aws appsync create-data-source --api-id <id-api> \
  --name BangDonHang --type AMAZON_DYNAMODB \
  --service-role-arn <arn-role> \
  --dynamodb-config 'tableName=DonHang,
                     awsRegion=ap-southeast-1'

Resolver không cần Lambda:

export function request(ctx) {
  return {
    operation: 'GetItem',
    key: util.dynamodb.toMapValues({ma: ctx.args.ma})
  };
}
export function response(ctx) {
  return ctx.result;
}

⚠ Đây là chỗ "operationally efficient" thể hiện rõ nhất:

AppSync gọi THẲNG DynamoDB
    → không có Lambda ở giữa
        ↓
    Không khởi động nguội
    → không quản lý hàm, không quản lý phiên bản
    → độ trễ ổn định hơn hẳn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Client lấy đúng dữ liệu cần, không thừa | | | Gọi nhiều nguồn song song trong một request | | | Có subscription thời gian thực sẵn | |

⚠ GraphQL giải quyết vấn đề over-fetching:

REST: client gọi /don-hang rồi /khach-hang rồi /san-pham
    → ba vòng mạng
        ↓
GraphQL: một truy vấn, khai đúng trường cần
    → một vòng mạng, không dữ liệu thừa

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

• **D. Lambda với Step Functions — đây là phương án gần nhất và cũng điều phối được nhiều bảng, nhưng Step Functions dành cho quy trình nghiệp vụ nhiều bước có trạng thái, không phải cho việc phục vụ yêu cầu người dùng có độ trễ thấp; nó thêm độ trễ và thêm thứ phải quản lý.
• **A. AWS Glue với DynamoDB connector — Glue là ETL theo lô cho phân tích dữ liệu, hoàn toàn không phải tầng phục vụ ứng dụng web.
• **C. S3 với Lambda trigger — S3 event là kiến trúc bất đồng bộ theo sự kiện; nó không trả lời được yêu cầu đồng bộ của người dùng.

Ghi nhớ

⚠ Ba cách dựng API serverless — bảng phải thuộc: | Cách | Khi nào | |---|---| | API Gateway + Lambda | REST, logic tuỳ chỉnh | | AppSync (GraphQL) | nhiều nguồn dữ liệu, client cần linh hoạt | | API Gateway + tích hợp trực tiếp | proxy thẳng tới DynamoDB, SQS |

Từ khoá nhận diện:

"multiple data sources in one request, GraphQL" → AppSync "REST API with custom logic" → API Gateway + Lambda "real-time subscriptions" → AppSync "multi-step business workflow" → Step Functions "batch ETL" → Glue

Ba loại data source của AppSync: | Loại | Chi tiết | |---|---| | DynamoDB | resolver trực tiếp, không cần Lambda | | Lambda | logic phức tạp | | HTTP | gọi API bên ngoài | | Aurora Serverless (Data API) | CSDL quan hệ | | OpenSearch | tìm kiếm |

⚠ Ba thao tác của GraphQL: | Thao tác | Việc | |---|---| | Query | đọc | | Mutation | ghi | | Subscription | nhận cập nhật thời gian thực qua WebSocket |

Subscription là tính năng ít người biết nhưng rất mạnh:

type Subscription {
  donHangCapNhat(ma: ID!): DonHang
    @aws_subscribe(mutations: ["capNhatDonHang"])
}

Client đăng ký một đơn hàng
    → khi có mutation, AppSync tự đẩy xuống
        ↓
    Không phải tự dựng WebSocket API

Ba lưu ý về xác thực: | Cách | Dùng cho | |---|---| | Cognito User Pools | người dùng cuối | | IAM | dịch vụ nội bộ | | Lambda authorizer | logic tuỳ chỉnh | | API key | chỉ cho thử nghiệm |

⚠ Phân quyền tới mức TRƯỜNG:

type KhachHang {
  ten: String
  email: String @aws_auth(cognito_groups: ["QuanTri"])
}

Người thường không thấy trường email
    → phân quyền chi tiết hơn REST nhiều

Ba lưu ý về caching: | Lưu ý | Chi tiết | |---|---| | AppSync có cache tích hợp | | | Cache theo resolver hoặc theo API | | | TTL tới 1 giờ | |

aws appsync create-api-cache --api-id <id-api> \
  --ttl 300 --api-caching-behavior PER_RESOLVER_CACHING \
  --type SMALL

Ba lưu ý về vấn đề N+1: | Lưu ý | Chi tiết | |---|---| | Truy vấn danh sách gọi resolver cho từng phần tử | | | 100 đơn hàng = 100 lời gọi bảng khách hàng | | | Dùng BatchGetItem resolver | |

⚠ Đây là bẫy hiệu năng lớn nhất của GraphQL:

export function request(ctx) {
  return {
    operation: 'BatchGetItem',
    tables: {
      KhachHang: {
        keys: ctx.prev.result.items.map(x =>
          util.dynamodb.toMapValues({ma: x.maKhachHang}))
      }
    }
  };
}

Ba lưu ý về thiết kế DynamoDB: | Lưu ý | Chi tiết | |---|---| | Thiết kế theo mẫu truy vấn | | | Cân nhắc single-table design | | | GSI cho mẫu truy vấn khác | |

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | Độ sâu truy vấn | cấu hình được | | Timeout resolver | 30 giây | | Kích thước phản hồi | 1 MB (DynamoDB) |

⚠ Giới hạn độ sâu chống truy vấn độc hại:

Truy vấn lồng 20 tầng
    → mỗi tầng nhân số lời gọi
        ↓
    Một request có thể sinh hàng nghìn lời gọi bảng
    → đặt giới hạn độ sâu và độ phức tạp

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | Latency | độ trễ toàn request | | 4XXError / 5XXError | | | Resolver-level log | resolver nào chậm |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy truy vấn nhiều nguồn, đo độ trễ | | | Kiểm tra resolver chạy song song | | | Thử truy vấn danh sách lớn tìm N+1 | |

Và một lời khuyên: hãy kiểm tra vấn đề N+1 ngay khi thêm resolver cho trường lồng nhau. GraphQL làm cho truy vấn trông rất gọn ở phía client, nhưng một danh sách trăm phần tử có trường lồng có thể lặng lẽ sinh ra trăm lời gọi bảng — và triệu chứng chỉ xuất hiện khi dữ liệu thật đủ lớn.

Đáp án

B — Amazon DynamoDB.

Vì sao đúng

Đề cho ba dữ kiện, và cả ba đều chỉ vào DynamoDB: | Dữ kiện | Ý nghĩa | |---|---| | Dữ liệu BÁN CẤU TRÚC dạng cặp khoá–giá trị | đúng mô hình dữ liệu của DynamoDB | | Mã ứng dụng chuyển sang AWS Lambda | DynamoDB không có khái niệm kết nối | | Cần khả năng mở rộng CAO | DynamoDB mở rộng gần như không giới hạn |

⚠ Vế thứ hai quan trọng hơn người ta nghĩ:

Lambda mở rộng lên hàng nghìn thực thi đồng thời
    → mỗi thực thi mở một kết nối tới CSDL quan hệ
        ↓
    RDS chạm `max_connections` và từ chối
        ↓
    DynamoDB gọi qua HTTPS API
    → không có pool kết nối, không có giới hạn kiểu đó

Tạo bảng chế độ on-demand:

aws dynamodb create-table --table-name DuLieuUngDung \
  --attribute-definitions \
    AttributeName=maKhoa,AttributeType=S \
    AttributeName=thoiDiem,AttributeType=S \
  --key-schema \
    AttributeName=maKhoa,KeyType=HASH \
    AttributeName=thoiDiem,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --sse-specification Enabled=true,SSEType=KMS

⚠ On-demand hợp với Lambda có tải thất thường:

Provisioned: phải đoán trước RCU/WCU
    → đoán thấp = throttle
    → đoán cao = trả tiền thừa
        ↓
On-demand: trả theo request thật
    → tự mở rộng tức thì

Bán cấu trúc nghĩa là mỗi item có thể khác nhau:

bang.put_item(Item={
    'maKhoa': 'kh-001', 'thoiDiem': '2026-08-30T10:00:00',
    'ten': 'Nguyen Van A', 'diemThuong': 120})

bang.put_item(Item={
    'maKhoa': 'kh-002', 'thoiDiem': '2026-08-30T10:05:00',
    'ten': 'Tran Thi B', 'diaChi': {'thanhPho': 'Ha Noi'},
    'theTag': ['vip', 'moi']})

Hai item cùng bảng, cấu trúc khác nhau
    → CSDL quan hệ đòi schema cố định
    → DynamoDB không

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ đơn vị mili giây ở mọi quy mô | | | Không quản lý máy chủ nào | | | Tích hợp Lambda tự nhiên qua SDK | |

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

• **D. Amazon RDS MySQL — đây là phương án gần nhất vì cũng là CSDL được quản lý, nhưng nó là CSDL quan hệ có schema cố định, và mô hình kết nối của nó xung đột với cách Lambda mở rộng.
• **C. Amazon EFS — hệ thống tệp dùng chung, không phải kho khoá–giá trị; không có truy vấn, không có index.
• **A. Amazon EBS — lưu trữ khối gắn vào một EC2; Lambda thậm chí không mount được EBS.

Ghi nhớ

⚠ Chọn CSDL theo mô hình dữ liệu — bảng phải thuộc: | Mô hình | Dịch vụ | |---|---| | Khoá–giá trị, tài liệu | DynamoDB | | Quan hệ | RDS, Aurora | | Trong bộ nhớ | ElastiCache, MemoryDB | | Đồ thị | Neptune | | Chuỗi thời gian | Timestream | | Sổ cái | QLDB | | Kho dữ liệu | Redshift |

Từ khoá nhận diện:

"key-value, semi-structured, highly scalable, serverless" → DynamoDB "complex joins, transactions, SQL" → RDS / Aurora "shared POSIX file system" → EFS "in-memory with persistence" → MemoryDB for Redis

⚠ Hai chế độ tính phí của DynamoDB: | Chế độ | Khi nào | |---|---| | On-demand | tải thất thường, mới bắt đầu | | Provisioned + auto scaling | tải ổn định, đoán được |

On-demand đắt hơn ~6-7 lần mỗi request
    → nhưng chỉ trả cho request thật
        ↓
    Điểm hoà vốn khoảng 15-20% mức dùng liên tục

Ba khái niệm thiết kế bảng: | Khái niệm | Việc | |---|---| | Partition key | quyết định phân vùng vật lý | | Sort key | sắp xếp trong một phân vùng | | GSI / LSI | mẫu truy vấn khác |

⚠ Partition key phải phân tán ĐỀU:

Partition key = "ngay"
    → mọi ghi trong ngày dồn vào MỘT phân vùng
        ↓
    Hot partition → throttle dù bảng còn thừa năng lực
        ↓
    Thêm hậu tố ngẫu nhiên, hoặc chọn khoá phân tán hơn

Ba lưu ý về truy vấn: | Thao tác | Chi phí | |---|---| | GetItem | rẻ nhất — biết khoá chính | | Query | rẻ — trong một phân vùng | | Scan | đắt nhất — đọc CẢ BẢNG |

⚠ Tránh Scan bằng mọi giá:

Scan đọc toàn bộ bảng rồi lọc
    → tốn RCU cho mọi item, kể cả item không khớp
        ↓
    Nếu phải Scan thường xuyên
    → mô hình dữ liệu sai, cần thêm GSI

Ba lưu ý về Lambda và DynamoDB: | Lưu ý | Chi tiết | |---|---| | Khởi tạo client NGOÀI handler | tái dùng giữa các lần gọi | | Không có pool kết nối để lo | | | IAM role cấp quyền, không có mật khẩu | |

import boto3
bang = boto3.resource('dynamodb').Table('DuLieuUngDung')

def handler(su_kien, ngu_canh):
    return bang.get_item(Key={'maKhoa': su_kien['ma']})

Ba lưu ý về tính nhất quán: | Kiểu đọc | Đặc điểm | |---|---| | Eventually consistent | mặc định, rẻ hơn một nửa | | Strongly consistent | tốn gấp đôi RCU | | Transactional | ACID, tốn gấp đôi nữa |

Ba tính năng đáng biết: | Tính năng | Việc | |---|---| | TTL | tự xoá item hết hạn, MIỄN PHÍ | | Streams | bắt thay đổi, kích hoạt Lambda | | Global Tables | active-active nhiều Region |

aws dynamodb update-time-to-live --table-name DuLieuUngDung \
  --time-to-live-specification 'Enabled=true,AttributeName=hetHan'

⚠ TTL là cách dọn dữ liệu rẻ nhất:

Xoá bằng DeleteItem: tốn WCU
        ↓
    TTL: AWS tự xoá trong nền, KHÔNG tốn WCU
    → nhưng có thể trễ tới 48 giờ

Ba lưu ý về sao lưu: | Cách | Chi tiết | |---|---| | Point-in-time recovery | khôi phục tới bất kỳ giây nào trong 35 ngày | | On-demand backup | ảnh chụp thủ công | | AWS Backup | quản lý tập trung |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ ~0,25 USD mỗi GB-tháng | | | GSI nhân đôi chi phí ghi | | | Item lớn tốn nhiều WCU hơn | |

⚠ Mỗi WCU ghi được 1 KB — item lớn tốn nhiều:

Item 4 KB = 4 WCU mỗi lần ghi
    → cân nhắc tách dữ liệu lớn ra S3
    → lưu con trỏ trong DynamoDB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Theo dõi ThrottledRequests | | | Kiểm tra ConsumedReadCapacityUnits | | | Xem có Scan nào trong mã không | |

Và một lời khuyên: hãy thiết kế bảng theo mẫu truy vấn trước khi viết dòng mã đầu tiên. DynamoDB rất khó sửa mô hình dữ liệu sau khi có dữ liệu thật, và dấu hiệu của một thiết kế sai luôn là cùng một thứ: mã của bạn đầy những lời gọi Scan.

Đáp án

D — Amazon Aurora Serverless.

Vì sao đúng

Đề cho ba dữ kiện, và cả ba đều là mô tả chính xác của Aurora Serverless: | Dữ kiện | Cách đáp ứng | |---|---| | Chỉ dùng vài lần mỗi tuần, trong thời gian NGẮN | rảnh thì thu về mức tối thiểu | | Tự KHỞI TẠO (automatic instantiation) | tự khởi động khi có kết nối | | Tự MỞ RỘNG | tăng giảm ACU theo tải, trong vài giây |

⚠ "Automatic instantiation" là từ khoá riêng của Serverless:

RDS và Aurora provisioned: instance chạy 24/7
    → trả tiền cả những ngày không ai dùng
        ↓
Aurora Serverless: min capacity 0
    → không có tải = không tính phí tính toán
    → có kết nối = tự khởi động lại

Dựng cụm:

aws rds create-db-cluster \
  --db-cluster-identifier cum-thinh-thoang \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.05.2 \
  --serverless-v2-scaling-configuration \
    MinCapacity=0,MaxCapacity=8,SecondsUntilAutoPause=3600 \
  --master-username quantri --manage-master-user-password

aws rds create-db-instance \
  --db-instance-identifier phien-ban-1 \
  --db-cluster-identifier cum-thinh-thoang \
  --db-instance-class db.serverless --engine aurora-mysql

⚠ MinCapacity=0 là tính năng làm nên đáp án này:

Serverless v2 hỗ trợ thu về 0 ACU
    → CSDL "ngủ" hoàn toàn
    → chỉ trả tiền lưu trữ
        ↓
    Đúng cho CSDL dùng vài lần mỗi tuần

Đánh đổi phải biết: | Điểm | Chi tiết | |---|---| | Kết nối đầu tiên sau khi ngủ | có độ trễ khởi động | | SecondsUntilAutoPause | thời gian rảnh trước khi ngủ | | Không nên đặt 0 cho sản xuất | |

⚠ ACU là đơn vị tính:

1 ACU ≈ 2 GB RAM + CPU và mạng tương ứng
    → tăng giảm theo bước 0,5 ACU
    → phản ứng trong VÀI GIÂY
        ↓
    Khác hẳn v1 vốn mất chục giây và cần
      "điểm mở rộng" an toàn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ trả tiền lúc thật sự dùng | | | Tương thích MySQL — không đổi mã | | | Vẫn có mọi tính năng Aurora | |

⚠ "Mọi tính năng Aurora" gồm những thứ đáng giá: | Tính năng | Chi tiết | |---|---| | 6 bản sao dữ liệu trên 3 AZ | | | Lưu trữ tự mở rộng tới 128 TB | | | Read replica, Global Database | | | Backtrack | |

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

• **B. Amazon Aurora (provisioned) — đây là phương án gần nhất và cũng là Aurora, nhưng instance chạy liên tục: với CSDL chỉ dùng vài lần mỗi tuần thì phần lớn hoá đơn là tiền cho máy không làm gì.
• **C. Amazon RDS MySQL — cũng chạy 24/7, và không có cơ chế tự mở rộng tính toán.
• **A. MySQL tự cài trên EC2 — công vận hành cao nhất (tự vá, tự sao lưu, tự HA) và vẫn trả tiền máy liên tục.

Ghi nhớ

⚠ Bốn lựa chọn CSDL quan hệ — bảng phải thuộc: | Lựa chọn | Co giãn tính toán | Chi phí khi rảnh | |---|---|---| | Aurora Serverless v2 | TỰ ĐỘNG theo giây | gần 0 nếu min=0 | | Aurora provisioned | thủ công | đầy đủ | | RDS | thủ công | đầy đủ | | MySQL trên EC2 | thủ công | đầy đủ + công vận hành |

Từ khoá nhận diện:

"used occasionally, automatic instantiation and scaling" → Aurora Serverless "unpredictable but continuous workload" → Aurora Serverless v2 "steady predictable load" → Aurora provisioned + RI/SP "key-value, serverless" → DynamoDB on-demand

⚠ v1 và v2 khác nhau rất nhiều — dùng v2: | Tiêu chí | v1 | v2 | |---|---|---| | Tốc độ mở rộng | chục giây | giây | | Bước mở rộng | gấp đôi | 0,5 ACU | | Read replica | ❌ | ✅ | | Multi-AZ | hạn chế | ✅ | | Global Database | ❌ | ✅ | | Thu về 0 | có (pause) | ✅ từ 2024 |

Ba lưu ý về đặt min và max: | Lưu ý | Chi tiết | |---|---| | Min quá thấp → chậm khi tải tăng đột ngột | | | Max quá thấp → truy vấn xếp hàng | | | Max quá cao → hoá đơn bất ngờ | |

⚠ Đặt cảnh báo cho ACUUtilization:

aws cloudwatch put-metric-alarm --alarm-name aurora-cham-tran \
  --namespace AWS/RDS --metric-name ACUUtilization \
  --dimensions Name=DBClusterIdentifier,Value=cum-thinh-thoang \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 80 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

Ba lưu ý về độ trễ khởi động: | Lưu ý | Chi tiết | |---|---| | Kết nối đầu sau khi ngủ mất vài giây | | | Ứng dụng phải chịu được | | | Đặt timeout kết nối đủ dài | |

⚠ Đây là lý do không dùng min=0 cho sản xuất:

Người dùng đầu tiên buổi sáng
    → chờ CSDL tỉnh dậy
        ↓
    Chấp nhận được cho công cụ nội bộ,
    không chấp nhận được cho ứng dụng khách hàng

Ba lưu ý về Data API: | Lưu ý | Chi tiết | |---|---| | Gọi SQL qua HTTPS, không cần kết nối | | | Rất hợp với Lambda | | | Hỗ trợ Aurora Serverless v2 | |

aws rds-data execute-statement \
  --resource-arn <arn-cum> --secret-arn <arn-secret> \
  --database ungdung \
  --sql "SELECT * FROM don_hang WHERE ma = :ma" \
  --parameters '[{"name":"ma","value":{"stringValue":"123"}}]'

⚠ Data API bỏ hẳn vấn đề pool kết nối:

Lambda + CSDL quan hệ: bài toán kết nối kinh điển
        ↓
    Data API: mỗi câu lệnh là một lời gọi HTTPS
    → không có kết nối để cạn

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính toán theo ACU-giây | | | Lưu trữ theo GB-tháng | | | I/O tính riêng trừ khi dùng I/O-Optimized | |

Ba lưu ý về kết nối: | Endpoint | Việc | |---|---| | Cluster (writer) | ghi | | Reader | cân bằng giữa replica | | RDS Proxy | gộp kết nối |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | ServerlessDatabaseCapacity | ACU đang dùng | | ACUUtilization | tỷ lệ so với max | | Performance Insights | truy vấn nào tốn |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Để rảnh vài giờ, xem ACU về min | | | Kết nối lại, đo độ trễ khởi động | | | Kiểm tra hoá đơn sau một tháng | |

Và một lời khuyên: hãy đặt max capacity ở mức bạn sẵn sàng trả tiền, không phải mức bạn nghĩ là đủ. Aurora Serverless mở rộng mượt đến đâu thì hoá đơn cũng mượt đến đó — và một truy vấn thiếu index chạy trong vòng lặp có thể đẩy cụm lên trần rồi giữ nó ở đó suốt cuối tuần.

Đáp án

B — Amazon DynamoDB.

Vì sao đúng

Đề nêu hai yêu cầu, và DynamoDB là dịch vụ khớp cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | CSDL dạng KHOÁ–GIÁ TRỊ | đúng mô hình dữ liệu của DynamoDB | | Khả năng mở rộng CAO | mở rộng ngang gần như không giới hạn |

⚠ Thương mại điện tử là ca dùng điển hình của DynamoDB:

Giỏ hàng, phiên người dùng, danh mục sản phẩm
    → tra cứu theo khoá, độ trễ mili giây
    → tải tăng vọt trong đợt khuyến mãi
        ↓
    DynamoDB mở rộng mà không cần dựng thêm gì

Tạo bảng:

aws dynamodb create-table --table-name GioHang \
  --attribute-definitions \
    AttributeName=maNguoiDung,AttributeType=S \
    AttributeName=maSanPham,AttributeType=S \
  --key-schema \
    AttributeName=maNguoiDung,KeyType=HASH \
    AttributeName=maSanPham,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --sse-specification Enabled=true,SSEType=KMS

⚠ Mở rộng của DynamoDB khác hẳn CSDL quan hệ:

RDS: mở rộng DỌC — đổi sang instance lớn hơn
    → có trần, và cần khởi động lại
        ↓
DynamoDB: mở rộng NGANG — thêm phân vùng
    → AWS tự làm, không giới hạn thực tế
    → không có thời gian ngừng

Ba đặc điểm quan trọng: | Đặc điểm | Chi tiết | |---|---| | Độ trễ mili giây một chữ số | ở mọi quy mô | | Không có máy chủ để quản lý | | | Dữ liệu tự nhân bản qua 3 AZ | |

Mẫu thiết kế cho thương mại điện tử:

Bảng SanPham:  PK = maSanPham
Bảng GioHang:  PK = maNguoiDung, SK = maSanPham
Bảng DonHang:  PK = maNguoiDung, SK = thoiDiem#maDon
        ↓
    Mỗi mẫu truy vấn có một cách tra cứu trực tiếp

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chịu được đợt tăng tải đột ngột | | | Không cần đoán trước năng lực với on-demand | | | Tích hợp tự nhiên với Lambda | |

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

• **D. Amazon ElastiCache — đây là phương án gần nhất vì cũng là kho khoá–giá trị, nhưng ElastiCache là bộ nhớ đệm: dữ liệu nằm trong RAM, dung lượng giới hạn theo cỡ node, và không phải kho lưu trữ chính bền vững cho dữ liệu thương mại điện tử.
• **C. Amazon RDS — CSDL quan hệ có schema cố định; mở rộng dọc có trần và không hợp mô hình khoá–giá trị.
• **A. Amazon Redshift — kho dữ liệu cho phân tích theo cột; nó tối ưu cho truy vấn tổng hợp trên hàng tỷ dòng, hoàn toàn không phải cho tra cứu từng bản ghi.

Ghi nhớ

⚠ Chọn CSDL theo mô hình — bảng phải thuộc: | Mô hình | Dịch vụ | |---|---| | Khoá–giá trị, tài liệu | DynamoDB | | Quan hệ (OLTP) | RDS, Aurora | | Kho dữ liệu (OLAP) | Redshift | | Cache trong bộ nhớ | ElastiCache | | Bộ nhớ nhưng BỀN | MemoryDB for Redis | | Đồ thị | Neptune | | Chuỗi thời gian | Timestream |

⚠ ElastiCache vs MemoryDB — khác biệt quan trọng:

ElastiCache: bộ nhớ đệm, mất dữ liệu chấp nhận được
        ↓
MemoryDB: kho CHÍNH trong bộ nhớ, có transaction log bền
    → dùng làm CSDL thật được
    → đắt hơn ElastiCache

Từ khoá nhận diện:

"key-value, highly scalable" → DynamoDB "cache to reduce database load" → ElastiCache "in-memory as primary database, durable" → MemoryDB "complex analytics on petabytes" → Redshift "SQL joins and transactions" → RDS / Aurora

Ba khái niệm thiết kế bảng: | Khái niệm | Việc | |---|---| | Partition key | quyết định phân vùng vật lý | | Sort key | sắp xếp trong phân vùng | | GSI | mẫu truy vấn khác, khoá khác |

⚠ Hot partition là vấn đề hiệu năng số một:

Partition key phân tán kém
    → mọi request dồn vào một phân vùng
        ↓
    Throttle dù bảng còn thừa năng lực
    → chọn khoá có độ đa dạng cao

Ba lưu ý về GSI: | Lưu ý | Chi tiết | |---|---| | Có khoá riêng, truy vấn theo chiều khác | | | Ghi vào bảng cũng ghi vào GSI | nhân đôi chi phí ghi | | Chỉ eventually consistent | |

Ba lưu ý về truy vấn: | Thao tác | Chi phí | |---|---| | GetItem | rẻ nhất | | Query | rẻ, trong một phân vùng | | Scan | đắt nhất — tránh |

Ba lưu ý về chế độ tính phí: | Chế độ | Khi nào | |---|---| | On-demand | tải thất thường, khuyến mãi bất ngờ | | Provisioned + auto scaling | tải ổn định | | Chuyển đổi được | mỗi 24 giờ một lần |

⚠ Thương mại điện tử thường nên dùng on-demand:

Đợt sale bất ngờ, tải tăng 50 lần trong vài phút
    → provisioned auto scaling phản ứng theo phút
    → throttle trong lúc chờ
        ↓
    On-demand hấp thụ được ngay
    → hoặc dùng provisioned với scheduled scaling
      nếu biết trước lịch sale

Ba tính năng đáng biết: | Tính năng | Việc | |---|---| | DAX | cache microsecond, ít sửa mã | | Streams | bắt thay đổi, kích hoạt Lambda | | Global Tables | active-active nhiều Region |

⚠ DAX rất hợp danh mục sản phẩm:

Danh mục đọc nhiều, ghi ít
    → DAX cache, độ trễ từ mili giây xuống micro giây
        ↓
    Và giảm RCU của DynamoDB

Ba lưu ý về transaction: | Lưu ý | Chi tiết | |---|---| | TransactWriteItems cho ACID nhiều item | | | Tối đa 100 item mỗi transaction | | | Tốn gấp đôi WCU | |

khach.transact_write_items(TransactItems=[
  {'Update': {'TableName':'TonKho','Key':{'maSanPham':{'S':'sp1'}},
    'UpdateExpression':'SET soLuong = soLuong - :n',
    'ConditionExpression':'soLuong >= :n',
    'ExpressionAttributeValues':{':n':{'N':'1'}}}},
  {'Put': {'TableName':'DonHang','Item':{...}}}])

⚠ ConditionExpression chống bán quá tồn kho:

Không có điều kiện: hai đơn cùng lúc
    → cả hai đọc soLuong = 1, cả hai trừ đi
    → tồn kho thành -1
        ↓
    Điều kiện `soLuong >= :n` khiến một đơn thất bại

Ba lưu ý về sao lưu: | Cách | Chi tiết | |---|---| | Point-in-time recovery | 35 ngày, tới từng giây | | On-demand backup | thủ công, giữ vô hạn | | AWS Backup | quản lý tập trung |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ ~0,25 USD/GB-tháng | | | GSI nhân đôi chi phí ghi | | | TTL xoá miễn phí | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Theo dõi ThrottledRequests | | | Kiểm tra không có Scan trong đường nóng | | | Chạy tải giả mức đợt khuyến mãi | |

Và một lời khuyên: hãy dùng ConditionExpression cho mọi thao tác trừ tồn kho. DynamoDB không có khoá hàng như CSDL quan hệ, nên hai đơn hàng đến cùng lúc sẽ cùng đọc thấy còn hàng — và cách duy nhất để một trong hai thất bại là nói cho DynamoDB biết điều kiện đó.

Đáp án

B — Dùng Amazon API Gateway cùng AWS Lambda có provisioned concurrency.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này là phương án duy nhất giải quyết cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Tải tăng vọt vào những dịp cụ thể | Lambda tự mở rộng tức thì | | Độ trễ thấp NHẤT QUÁN | provisioned concurrency loại bỏ khởi động nguội | | Công vận hành tối thiểu | không quản lý máy chủ nào |

⚠ Provisioned concurrency chính là chi tiết đáp ứng "consistent low latency":

Lambda thường: lần gọi đầu sau khi rảnh phải
               khởi tạo môi trường
    → khởi động nguội: hàng trăm ms tới vài giây
        ↓
    Tải tăng vọt = RẤT NHIỀU môi trường mới
    → rất nhiều lần khởi động nguội cùng lúc
    → độ trễ p99 tệ đúng lúc đông người nhất
        ↓
Provisioned concurrency: giữ sẵn N môi trường đã khởi tạo
    → không có khởi động nguội cho N request đầu tiên

Cấu hình:

aws lambda publish-version --function-name api-goi-cuoc

aws lambda put-provisioned-concurrency-config \
  --function-name api-goi-cuoc --qualifier prod \
  --provisioned-concurrent-executions 50

⚠ Provisioned concurrency phải gắn với ALIAS hoặc VERSION, không gắn với $LATEST.

Tự động tăng giảm theo lịch:

aws application-autoscaling register-scalable-target \
  --service-namespace lambda \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --resource-id function:api-goi-cuoc:prod \
  --min-capacity 20 --max-capacity 500

aws application-autoscaling put-scheduled-action \
  --service-namespace lambda \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --resource-id function:api-goi-cuoc:prod \
  --scheduled-action-name cuoi-thang \
  --schedule "cron(0 0 28 * ? *)" \
  --scalable-target-action MinCapacity=200

⚠ Đề nói tải tăng vào "cuối tháng và dịp khuyến mãi" — lịch đoán trước được:

Tăng provisioned concurrency TRƯỚC ngày cao điểm
    → hạ xuống sau đó
        ↓
    Không trả tiền giữ môi trường suốt tháng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ ổn định kể cả lúc đỉnh | | | Không có máy chủ, không vá, không mở rộng thủ công | | | Trả tiền theo request ngoài phần provisioned | |

⚠ Đánh đổi: provisioned concurrency tính phí kể cả khi rảnh:

Nó giữ môi trường sẵn 24/7 (trong thời gian bật)
    → mất một phần lợi thế "rảnh thì không tốn"
        ↓
    Đó là cái giá của độ trễ nhất quán
    → dùng scheduled scaling để giảm thiểu

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

• **D. API Gateway với Fargate task — đây là phương án gần nhất và cũng không quản lý máy chủ, nhưng Fargate mở rộng theo task: khởi động một task mất vài chục giây, nên đợt tăng đột ngột vẫn gây chậm; và bạn phải cấu hình auto scaling cho service.
• **A. Elastic Beanstalk với Auto Scaling group — vẫn là EC2 bên dưới: phải vá, phải chờ máy khởi động khi mở rộng, công vận hành cao hơn hẳn.
• **C. EC2 sau ALB với mở rộng THỦ CÔNG — mở rộng thủ công là điều tệ nhất cho tải tăng vọt; ai đó phải có mặt đúng lúc để bấm nút.

Ghi nhớ

⚠ Ba mức độ "serverless" cho API — bảng phải thuộc: | Cách | Mở rộng | Khởi động | |---|---|---| | Lambda | tức thì, theo request | mili giây (có provisioned) | | Fargate | theo task | chục giây | | EC2 + ASG | theo instance | phút |

Từ khoá nhận diện:

"traffic spikes, consistent low latency, minimal overhead" → Lambda + provisioned concurrency "long-running, > 15 minutes" → Fargate "steady predictable load" → EC2 với Savings Plans "cold start is a problem" → provisioned concurrency hoặc SnapStart

⚠ Lambda SnapStart là lựa chọn thay thế cho Java:

SnapStart chụp ảnh môi trường đã khởi tạo
    → giảm khởi động nguội tới 90%
    → MIỄN PHÍ (không như provisioned concurrency)
        ↓
    Hỗ trợ Java, Python, .NET

aws lambda update-function-configuration \
  --function-name api-goi-cuoc \
  --snap-start ApplyOn=PublishedVersions

Ba loại đồng thời của Lambda: | Loại | Việc | |---|---| | Unreserved | dùng chung hạn ngạch tài khoản | | Reserved | dành riêng, cũng là TRẦN | | Provisioned | giữ sẵn môi trường đã khởi tạo |

⚠ Reserved và Provisioned khác nhau:

Reserved concurrency: đảm bảo hàm có N slot,
                      và KHÔNG vượt quá N
    → không giảm khởi động nguội
        ↓
Provisioned concurrency: giữ N môi trường ẤM SẴN
    → giảm khởi động nguội

Ba yếu tố ảnh hưởng khởi động nguội: | Yếu tố | Chi tiết | |---|---| | Runtime | Go, Rust nhanh; Java, .NET chậm | | Kích thước gói | gói lớn nạp lâu hơn | | VPC | nay đã nhanh, không còn là vấn đề lớn |

⚠ Lambda trong VPC không còn chậm như trước:

Trước 2019: gắn ENI mỗi lần khởi động nguội
    → thêm 10+ giây
        ↓
    Nay: ENI dùng chung, chỉ thêm vài chục ms
    → đừng tránh VPC vì lý do hiệu năng nữa

Ba lưu ý về API Gateway: | Lưu ý | Chi tiết | |---|---| | HTTP API rẻ hơn REST API ~70% | | | Timeout 29 giây | | | Đặt throttling bảo vệ backend | |

Ba lưu ý về throttling: | Lưu ý | Chi tiết | |---|---| | Đặt rate và burst ở stage | | | Usage plan cho từng khách hàng (REST API) | | | Bảo vệ CSDL phía sau | |

aws apigateway update-stage --rest-api-id abc --stage-name prod \
  --patch-operations \
    op=replace,path=/*/*/throttling/rateLimit,value=5000 \
    op=replace,path=/*/*/throttling/burstLimit,value=10000

Ba lưu ý về chi phí provisioned concurrency: | Khoản | Chi tiết | |---|---| | Tính theo GB-giờ giữ môi trường | | | Cộng phí thực thi (rẻ hơn giá thường) | | | Application Auto Scaling giảm được | |

⚠ Tính thử để quyết định:

50 môi trường × 1 GB × 24 giờ × 30 ngày
    → 36.000 GB-giờ ≈ 150 USD/tháng
        ↓
    Chỉ bật vào giờ cao điểm: giảm còn ~20 USD

Ba lưu ý về kết nối CSDL: | Lưu ý | Chi tiết | |---|---| | RDS Proxy gộp kết nối | | | Hoặc dùng DynamoDB | | | Đặt reserved concurrency bảo vệ CSDL | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | ProvisionedConcurrencyUtilization | dùng hết chưa | | ProvisionedConcurrencySpilloverInvocations | vượt quá, phải khởi động nguội | | Duration p99 | độ trễ thật |

⚠ SpilloverInvocations là chỉ số quyết định:

Con số này lớn hơn 0
    → provisioned concurrency đặt quá thấp
    → một phần request vẫn chịu khởi động nguội
        ↓
    Tăng lên hoặc bật auto scaling

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo p99 trước và sau khi bật | | | Theo dõi spillover trong đợt cao điểm | | | Chạy tải giả mức đỉnh dự kiến | |

Và một lời khuyên: hãy dùng scheduled scaling cho provisioned concurrency thay vì đặt một con số cố định. Đề đã nói rõ tải tăng vào những dịp đoán trước được, nên giữ sẵn năm mươi môi trường suốt cả tháng là trả tiền cho hai mươi chín ngày không cần đến chúng.

Đáp án

B — Amazon GuardDuty.

Vì sao đúng

Đề nêu hai yêu cầu, và GuardDuty là dịch vụ phát hiện mối đe doạ của AWS: | Yêu cầu | Cách đáp ứng | |---|---| | Phát hiện việc EC2 và S3 bị xâm phạm | GuardDuty phân tích hành vi bất thường | | Bảo vệ trước tấn công | phát hiện sớm, kết hợp khắc phục tự động |

⚠ GuardDuty phân tích ba nguồn log, liên tục, không cần cài gì:

CloudTrail (lời gọi API)
VPC Flow Logs (lưu lượng mạng)
DNS logs (truy vấn tên miền)
        ↓
    Đối chiếu với tình báo mối đe doạ + học máy
    → phát hiện hành vi bất thường

Bật cho cả tổ chức:

aws guardduty create-detector --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES

aws guardduty enable-organization-admin-account \
  --admin-account-id 123456789012

aws guardduty update-organization-configuration \
  --detector-id <id> --auto-enable-organization-members ALL

⚠ auto-enable-organization-members ALL là chi tiết quan trọng:

Tài khoản mới gia nhập tổ chức
    → TỰ ĐỘNG được bật GuardDuty
        ↓
    Không có tài khoản nào lọt ra ngoài tầm giám sát

Ví dụ phát hiện liên quan tới đề: | Loại phát hiện | Nghĩa | |---|---| | CryptoCurrency:EC2/BitcoinTool.B | máy bị chiếm để đào tiền ảo | | UnauthorizedAccess:EC2/SSHBruteForce | dò mật khẩu SSH | | Discovery:S3/AnomalousBehavior | liệt kê bucket bất thường | | Exfiltration:S3/ObjectRead.Unusual | tải dữ liệu bất thường | | UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration | credential của EC2 dùng từ ngoài |

⚠ Phát hiện cuối rất đáng chú ý:

Credential tạm của instance profile
    → bị lấy ra và dùng từ IP bên ngoài AWS
        ↓
    Dấu hiệu rõ ràng của SSRF hoặc máy bị chiếm
    → GuardDuty bắt được điều này

Khắc phục tự động — vế "remediate" của đề:

{"source": ["aws.guardduty"],
 "detail-type": ["GuardDuty Finding"],
 "detail": {"severity": [{"numeric": [">=", 7]}]}}

aws events put-rule --name guardduty-nghiem-trong \
  --event-pattern file://mau.json

aws events put-targets --rule guardduty-nghiem-trong \
  --targets 'Id=1,Arn=<arn-lambda-cach-ly>' \
            'Id=2,Arn=<arn-sns>'

Ba bước khắc phục thường dùng: | Bước | Chi tiết | |---|---| | Cách ly máy | đổi sang security group không cho ra vào | | Chụp snapshot để điều tra | | | Thu hồi credential | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bật một lần, không cài agent | | | Không ảnh hưởng hiệu năng | phân tích log, không chặn đường dữ liệu | | Tình báo mối đe doạ cập nhật liên tục | |

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

• **C. Amazon Inspector — đây là phương án gần nhất và cũng là dịch vụ bảo mật cho EC2, nhưng Inspector quét LỖ HỔNG (CVE, phần mềm chưa vá) — tức là điểm yếu có thể bị khai thác. GuardDuty phát hiện việc đang bị tấn công hoặc đã bị chiếm.
• **A. Amazon Macie — Macie quét NỘI DUNG object S3 tìm dữ liệu nhạy cảm (PII, PHI); nó không phát hiện xâm nhập.
• **D. Amazon Cognito — Cognito là dịch vụ xác thực người dùng cho ứng dụng, không liên quan tới phát hiện mối đe doạ.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật hay bị lẫn — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | GuardDuty | "có ai đang tấn công hoặc đã chiếm được không?" | | Inspector | "hệ thống có lỗ hổng nào không?" | | Macie | "có dữ liệu nhạy cảm nằm sai chỗ không?" | | Security Hub | "tổng hợp mọi phát hiện ở đâu?" |

⚠ Cách nhớ ngắn nhất:

Inspector: điểm yếu CÓ THỂ bị khai thác
GuardDuty: dấu hiệu ĐANG bị khai thác
Macie:     dữ liệu nhạy cảm ở sai chỗ
Security Hub: màn hình gom tất cả

Từ khoá nhận diện:

"detect compromise, unusual behavior, threats" → GuardDuty "CVE, unpatched software, vulnerability scan" → Inspector "PII/PHI in S3" → Macie "aggregate findings, compliance standards" → Security Hub "analyze API calls after the fact" → CloudTrail

Ba tính năng bảo vệ mở rộng của GuardDuty: | Tính năng | Việc | |---|---| | S3 Protection | phân tích data event của S3 | | Malware Protection | quét volume EBS khi có phát hiện | | EKS Protection | audit log của Kubernetes | | RDS Protection | hành vi đăng nhập bất thường | | Lambda Protection | lưu lượng mạng bất thường |

⚠ Malware Protection quét mà không cần agent:

GuardDuty phát hiện máy đáng ngờ
    → tự chụp snapshot EBS
    → quét mã độc trên bản sao
        ↓
    Không cài gì lên máy sản xuất
    → không ảnh hưởng hiệu năng

Ba mức nghiêm trọng: | Mức | Điểm | Hành động | |---|---|---| | Low | 1,0 - 3,9 | ghi nhận | | Medium | 4,0 - 6,9 | xem xét | | High | 7,0 - 8,9 | xử lý ngay |

Ba lưu ý về giảm nhiễu: | Cách | Chi tiết | |---|---| | Suppression rule cho phát hiện đã biết | | | Trusted IP list cho dải IP của mình | | | Threat IP list cho IP đã biết là xấu | |

⚠ Dương tính giả làm hỏng cả hệ thống cảnh báo:

Máy quét bảo mật nội bộ chạy hằng đêm
    → GuardDuty báo "port scan" mỗi đêm
        ↓
    Đội bảo mật quen bỏ qua
    → bỏ qua luôn cảnh báo thật
        ↓
    Đưa IP máy quét vào trusted list

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo lượng CloudTrail event phân tích | | | Cộng theo GB VPC Flow Logs và DNS log | | | S3 Protection tính riêng | |

Ba lưu ý về kiến trúc nhiều tài khoản: | Lưu ý | Chi tiết | |---|---| | Chỉ định một tài khoản quản trị | | | Bật tự động cho thành viên mới | | | Gom phát hiện về Security Hub | |

Ba lưu ý về Inspector (dịch vụ bổ trợ): | Lưu ý | Chi tiết | |---|---| | Quét EC2, container image trong ECR, Lambda | | | Quét liên tục, không theo lịch | | | Dùng SSM agent cho EC2 | |

⚠ GuardDuty và Inspector nên bật CẢ HAI:

Inspector: giảm bề mặt tấn công (vá lỗ hổng)
GuardDuty: phát hiện khi có kẻ vượt qua được
        ↓
    Phòng thủ nhiều lớp

Ba lưu ý về phản ứng sự cố: | Lưu ý | Chi tiết | |---|---| | Có runbook viết sẵn cho từng loại phát hiện | | | Tự động cách ly, đừng tự động xoá | | | Giữ bằng chứng để điều tra | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo phát hiện mẫu để thử đường ống | | | Xác nhận thư cảnh báo tới nơi | | | Kiểm tra mọi tài khoản đều bật | |

aws guardduty create-sample-findings --detector-id <id> \
  --finding-types "UnauthorizedAccess:EC2/SSHBruteForce"

Và một lời khuyên: hãy tạo phát hiện mẫu để thử toàn bộ đường ống cảnh báo trước khi tin vào nó. Bật GuardDuty là việc của một lệnh, nhưng giá trị của nó nằm ở chuỗi EventBridge → SNS → người trực — và mắt xích đó chỉ được kiểm chứng khi bạn cố tình kích hoạt nó.

Đáp án

D — Liên kết Direct Connect gateway với virtual private gateway ở tài khoản A và B.

Vì sao đúng

Đề mô tả đúng ca dùng mà Direct Connect gateway sinh ra để giải quyết: | Dữ kiện | Cách đáp ứng | |---|---| | Kết nối DX nằm ở tài khoản Z | DX gateway ở tài khoản Z | | Tài khoản A và B ở Region KHÁC | DX gateway là tài nguyên TOÀN CẦU | | A và B cần dùng đường DX của Z | liên kết VGW của A và B với DX gateway |

⚠ Direct Connect gateway là tài nguyên TOÀN CẦU, không theo Region:

Kết nối DX vật lý nằm ở một địa điểm
    → DX gateway cho phép nó phục vụ VPC
      ở BẤT KỲ Region nào
        ↓
    Đây chính là lý do nó tồn tại

Quy trình liên kết xuyên tài khoản:

# Ở tài khoản A: lấy ID của virtual private gateway
aws ec2 describe-vpn-gateways \
  --query "VpnGateways[].VpnGatewayId"

# Ở tài khoản Z: đề xuất liên kết
aws directconnect create-direct-connect-gateway-association-proposal \
  --direct-connect-gateway-id <id-dxgw> \
  --direct-connect-gateway-owner-account 111111111111 \
  --gateway-id vgw-tai-khoan-a \
  --add-allowed-prefixes-to-direct-connect-gateway cidr=10.1.0.0/16

# Ở tài khoản Z (chủ DX gateway): chấp nhận
aws directconnect accept-direct-connect-gateway-association-proposal \
  --direct-connect-gateway-id <id-dxgw> \
  --proposal-id <id-de-xuat> \
  --associated-gateway-owner-account 111111111111

⚠ allowed-prefixes là cơ chế kiểm soát định tuyến:

Chủ DX gateway quyết định dải IP nào
được quảng bá ra hai văn phòng
        ↓
    Tài khoản A không tự ý quảng bá dải bất kỳ
    → chủ hạ tầng giữ quyền kiểm soát

Giới hạn phải nhớ: | Giới hạn | Giá trị | |---|---| | VGW liên kết mỗi DX gateway | tối đa 10 | | Private VIF mỗi DX gateway | 30 | | CIDR không được chồng lấn | |

⚠ Và giới hạn quan trọng nhất — KHÔNG có định tuyến giữa các VPC:

VPC của A và VPC của B cùng liên kết DX gateway
    → cả hai tới được VĂN PHÒNG
    → nhưng KHÔNG nói chuyện được VỚI NHAU
        ↓
    Đề chỉ yêu cầu tới văn phòng → đủ
    → cần VPC nói chuyện với nhau thì phải
      dùng Transit Gateway

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dùng chung một đường DX vật lý | | | Xuyên Region và xuyên tài khoản | | | Không tính phí thêm cho DX gateway | |

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

• **A. Liên kết DX gateway với Transit Gateway ở mỗi Region — đây là phương án gần nhất và là kiến trúc hợp lệ, thậm chí mạnh hơn (cho phép VPC nói chuyện với nhau), nhưng đề nói kiến trúc hiện có là VPC ở các tài khoản, không nhắc tới Transit Gateway; và DX gateway chỉ liên kết được tối đa 3 Transit Gateway, ít hơn nhiều so với 10 VGW.
• **B. Tạo VPC endpoint tới DX gateway — VPC endpoint dùng để truy cập dịch vụ AWS hoặc dịch vụ PrivateLink; không có endpoint nào trỏ tới DX gateway.
• **C. Dùng PrivateLink với ENI ở tài khoản A và B — PrivateLink phơi bày một dịch vụ theo một chiều; nó không cung cấp định tuyến mạng hai chiều tới trung tâm dữ liệu.

Ghi nhớ

⚠ Ba thành phần của Direct Connect — bảng phải thuộc: | Thành phần | Việc | |---|---| | Connection | đường vật lý tại địa điểm DX | | Virtual Interface (VIF) | kênh logic trên đường đó | | Direct Connect Gateway | nối VIF với VPC ở nhiều Region |

Ba loại VIF: | Loại | Tới đâu | |---|---| | Private VIF | VPC (qua VGW hoặc DX gateway) | | Public VIF | dịch vụ công khai của AWS (S3, DynamoDB) | | Transit VIF | Transit Gateway |

⚠ Chọn đúng loại VIF là quyết định kiến trúc quan trọng:

Private VIF + DX gateway + VGW
    → tới nhiều VPC, KHÔNG bắc cầu giữa chúng
        ↓
Transit VIF + DX gateway + Transit Gateway
    → tới nhiều VPC VÀ chúng nói chuyện được với nhau

Từ khoá nhận diện:

"share DX across accounts and Regions" → DX gateway + VGW "VPCs must also talk to each other" → Transit Gateway + Transit VIF "reach S3 over DX privately" → Public VIF "quick connectivity, no DX yet" → Site-to-Site VPN

Ba lưu ý về hạn ngạch DX gateway: | Hạn ngạch | Giá trị | |---|---| | VGW liên kết | 10 | | Transit Gateway liên kết | 3 | | Prefix quảng bá tới on-premises | 200 |

Ba lưu ý về tính sẵn sàng: | Lưu ý | Chi tiết | |---|---| | Một kết nối DX KHÔNG phải HA | | | Hai kết nối ở hai địa điểm khác nhau | | | Hoặc DX + VPN dự phòng | |

⚠ BGP tự ưu tiên DX khi cả hai lên:

DX và VPN cùng quảng bá cùng prefix
    → BGP chọn DX (AS path ngắn hơn)
        ↓
    DX đứt → tự chuyển sang VPN
    → cấu hình dự phòng chuẩn

Ba lưu ý về băng thông: | Loại | Băng thông | |---|---| | Dedicated connection | 1, 10, 100 Gbps | | Hosted connection | 50 Mbps – 10 Gbps | | Link Aggregation Group (LAG) | gộp nhiều đường |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cổng theo giờ | | | Phí truyền dữ liệu RA (rẻ hơn Internet) | | | DX gateway MIỄN PHÍ | |

⚠ DX rẻ hơn Internet ở lưu lượng lớn:

Truyền dữ liệu ra Internet: ~0,09 USD/GB
Truyền dữ liệu qua DX:      ~0,02 USD/GB
        ↓
    Vài trăm TB mỗi tháng thì DX trả tiền cho chính nó

Ba lưu ý về định tuyến: | Lưu ý | Chi tiết | |---|---| | BGP quảng bá tuyến hai chiều | | | allowed-prefixes kiểm soát chiều ra | | | Route table VPC phải có tuyến về on-premises | |

⚠ Bật route propagation — bước hay quên:

aws ec2 enable-vgw-route-propagation \
  --route-table-id rtb-abc --gateway-id vgw-abc

Không bật: BGP nhận tuyến nhưng route table trống
    → gói tin không biết đi đâu
    → "DX đã lên" mà vẫn không thông

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | DX KHÔNG mã hoá theo mặc định | | | Chồng VPN lên DX nếu cần mã hoá | | | Hoặc dùng MACsec trên đường 10/100 Gbps | |

⚠ Đây là điều hay bị hiểu nhầm:

"Đường riêng" không có nghĩa là "được mã hoá"
    → DX là kênh riêng nhưng dữ liệu đi dạng thô
        ↓
    Yêu cầu tuân thủ về mã hoá đường truyền
    → phải thêm IPsec hoặc MACsec

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra trạng thái liên kết | | | Ping từ VPC của A tới văn phòng | | | Xem tuyến BGP đã nhận | |

aws directconnect describe-direct-connect-gateway-associations \
  --direct-connect-gateway-id <id-dxgw> \
  --query "directConnectGatewayAssociations[].
    [associatedGateway.id,associationState]" --output table

Và một lời khuyên: hãy cân nhắc Transit Gateway ngay từ đầu nếu có khả năng các VPC sẽ cần nói chuyện với nhau. DX gateway với virtual private gateway giải quyết đúng yêu cầu hôm nay, nhưng nó không bắc cầu — và ngày ai đó hỏi vì sao tài khoản A không gọi được dịch vụ ở tài khoản B, bạn sẽ phải dựng lại toàn bộ tầng định tuyến.

Đáp án

A — Amazon Aurora Global Database.

Vì sao đúng

Đề nêu ba yêu cầu, và Aurora Global Database là dịch vụ duy nhất đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | CSDL QUAN HỆ | Aurora tương thích MySQL và PostgreSQL | | RPO 1 giây | nhân bản lưu trữ, độ trễ thường dưới 1 giây | | RTO 1 phút | thăng cấp vùng phụ trong chưa tới một phút |

⚠ Aurora nhân bản ở TẦNG LƯU TRỮ — đây là điều làm nên hai con số đó:

Read replica thông thường: phát lại giao dịch ở đích
    → tốn CPU cụm nguồn, độ trễ theo tải
        ↓
Aurora Global: hạ tầng lưu trữ tự nhân bản
    → KHÔNG tốn CPU cụm chính
    → độ trễ thường dưới 1 giây dù cách nửa vòng trái đất

Dựng cụm toàn cầu:

aws rds create-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --source-db-cluster-identifier <arn-cum-chinh>

aws rds create-db-cluster \
  --db-cluster-identifier cum-vung-phu \
  --engine aurora-postgresql \
  --global-cluster-identifier cum-toan-cau \
  --region ap-northeast-1

Hai cách chuyển vùng — khác nhau hoàn toàn:

# Có kế hoạch — KHÔNG mất dữ liệu
aws rds failover-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --target-db-cluster-identifier <arn-cum-vung-phu>

# Khẩn cấp — vùng chính đã chết
aws rds remove-from-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --db-cluster-identifier <arn-cum-vung-phu>

⚠ RTO 1 phút chỉ đạt được với lệnh thứ hai:

`failover-global-cluster` chờ đồng bộ hoàn tất
    → không mất dữ liệu nhưng cần vùng chính còn sống
        ↓
`remove-from-global-cluster` tách ngay lập tức
    → dưới 1 phút
    → có thể mất phần chưa nhân bản (trong RPO 1 giây)

Ba lợi ích ngoài DR: | Lợi ích | Chi tiết | |---|---| | Vùng phụ phục vụ ĐỌC | giảm độ trễ cho người dùng địa phương | | Tới 5 vùng phụ | | | Không tốn CPU của cụm chính | |

⚠ Vùng phụ dùng được ngay cho báo cáo và tải đọc:

Không phải hạ tầng "ngồi chờ"
    → nó đang phục vụ thật mỗi ngày
        ↓
    Vừa là DR vừa là mở rộng đọc toàn cầu
    → và được kiểm chứng liên tục

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

• **D. RDS với cross-Region read replica — đây là phương án gần nhất và cũng là CSDL quan hệ nhân bản xuyên vùng, nhưng dùng nhân bản logic qua binlog: RPO thường vài giây tới vài phút (không đảm bảo 1 giây), và thăng cấp mất nhiều phút — không đạt RTO 1 phút.
• **C. DynamoDB Global Tables — RPO và RTO rất tốt, nhưng DynamoDB là NoSQL; đề nói rõ cần CSDL quan hệ.
• **B. RDS với Multi-AZ — Multi-AZ chỉ trong MỘT Region; nó không bảo vệ trước sự cố toàn Region mà đề yêu cầu.

Ghi nhớ

⚠ Bốn cơ chế nhân bản xuyên Region — bảng phải thuộc: | Cơ chế | Kiểu CSDL | RPO | |---|---|---| | Aurora Global Database | quan hệ | ~1 giây | | DynamoDB Global Tables | NoSQL | dưới 1 giây, active-active | | RDS cross-region read replica | quan hệ | giây - phút | | S3 Cross-Region Replication | object | phút (RTC 15 phút) |

Từ khoá nhận diện:

"relational, multi-Region DR, RPO ~1s, RTO ~1min" → Aurora Global Database "NoSQL, write in multiple Regions" → DynamoDB Global Tables "HA within one Region" → Multi-AZ "scale reads in same Region" → read replica

⚠ Multi-AZ và Multi-Region giải hai bài toán khác nhau:

Multi-AZ:     bảo vệ khỏi hỏng một AZ (trung tâm dữ liệu)
Multi-Region: bảo vệ khỏi hỏng cả một Region
        ↓
    Đề nói "across multiple AWS Regions"
    → Multi-AZ không đủ

Ba giới hạn của Aurora Global Database: | Giới hạn | Chi tiết | |---|---| | Chỉ MỘT cụm ghi tại một thời điểm | không active-active | | Tới 5 vùng phụ | | | Vùng phụ chỉ đọc cho tới khi thăng cấp | |

⚠ Cần ghi ở nhiều vùng thì Aurora không đáp ứng:

Aurora Global: một writer, nhiều reader vùng
        ↓
DynamoDB Global Tables: GHI ở mọi vùng
    → nhưng phải chấp nhận "last writer wins"

Ba lưu ý về Write Forwarding: | Lưu ý | Chi tiết | |---|---| | Vùng phụ nhận lệnh ghi rồi chuyển về vùng chính | | | Ứng dụng dùng một endpoint duy nhất | | | Độ trễ ghi cao hơn (đi vòng) | |

SET aurora_replica_read_consistency = 'SESSION';

Ba lưu ý về giám sát độ trễ: | Metric | Ý nghĩa | |---|---| | AuroraGlobalDBReplicationLag | RPO thực tế | | AuroraGlobalDBRPOLag | tương tự, đo bằng ms | | AuroraGlobalDBDataTransferBytes | lượng nhân bản |

⚠ Đặt cảnh báo cho độ trễ — đó là RPO thật của bạn:

aws cloudwatch put-metric-alarm --alarm-name aurora-global-tre \
  --namespace AWS/RDS --metric-name AuroraGlobalDBReplicationLag \
  --dimensions Name=DBClusterIdentifier,Value=cum-vung-phu \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 1000 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

Ba thứ phải chuẩn bị ở vùng phụ: | Thứ | Hậu quả nếu quên | |---|---| | Tầng ứng dụng | CSDL sẵn sàng mà không ai gọi được | | Chứng chỉ ACM | ACM theo Region | | Hạn ngạch | không mở rộng đủ |

⚠ CSDL không phải toàn bộ kiến trúc DR:

Aurora Global cho RPO 1 giây, RTO 1 phút cho CSDL
    → nhưng tầng ứng dụng vẫn phải dựng
        ↓
    RTO tổng thể = tầng chậm nhất

Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Failover routing với health check | | | TTL thấp (60 giây) cho bản ghi failover | | | TTL cao làm RTO thực tế dài hơn | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Cụm phụ tính phí instance đầy đủ | | | Phí nhân bản theo triệu I/O | | | Phí truyền dữ liệu xuyên vùng | |

⚠ Giảm chi phí bằng Serverless v2 ở vùng phụ:

Vùng phụ chỉ phục vụ đọc nhẹ
    → dùng db.serverless với min capacity thấp
        ↓
    Tự tăng lên khi được thăng cấp

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | failover-global-cluster không mất dữ liệu | | | Diễn tập ít nhất 2 lần/năm | | | Đo RTO thật từ lúc quyết định tới lúc phục vụ | |

Ba lưu ý về backtrack và snapshot: | Lưu ý | Chi tiết | |---|---| | Global Database không thay thế sao lưu | | | Xoá nhầm dữ liệu được nhân bản ngay | | | Vẫn cần PITR và snapshot | |

⚠ Đây là điều quan trọng dễ bị bỏ qua:

Nhân bản bảo vệ khỏi hỏng HẠ TẦNG
    → không bảo vệ khỏi lỗi CON NGƯỜI
        ↓
    Câu DELETE nhầm được nhân bản sang mọi vùng
    trong một giây

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo AuroraGlobalDBReplicationLag | | | Chạy failover có kế hoạch, bấm giờ | | | Kiểm tra tầng ứng dụng vùng phụ sẵn sàng | |

Và một lời khuyên: hãy đo RTO của toàn bộ kiến trúc chứ đừng chỉ đo của CSDL. Aurora Global Database thăng cấp trong chưa tới một phút, nhưng nếu tầng ứng dụng ở vùng phụ cần mười lăm phút để dựng thì RTO thật của bạn là mười lăm phút — con số một phút chỉ là của một mắt xích.