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

Đáp án

A — AWS Private 5G.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể, và AWS có đúng một dịch vụ cho việc đó: | Yêu cầu | Dịch vụ | |---|---| | Dựng mạng di động RIÊNG (private cellular network) | AWS Private 5G |

AWS Private 5G là gì:

Dịch vụ được quản lý giúp dựng và vận hành
mạng di động riêng của bạn
    → AWS gửi phần cứng (radio unit, SIM card)
    → phần mềm lõi mạng chạy trên hạ tầng AWS
        ↓
    Bạn tự sở hữu và kiểm soát mạng
    → không phải qua nhà mạng

Ba thứ AWS cung cấp: | Thứ | Chi tiết | |---|---| | Phần cứng radio (small cell) | AWS gửi tới địa điểm | | SIM card | cho thiết bị | | Lõi mạng và bảng điều khiển | được quản lý |

Tạo mạng:

aws privatenetworks create-network --network-name mang-nha-may \
  --description "Mang 5G rieng cho nha may"

aws privatenetworks acknowledge-order-receipt --network-site-name khu-a

Ba trường hợp dùng điển hình: | Trường hợp | Chi tiết | |---|---| | Nhà máy, kho bãi | robot, xe tự hành, cảm biến | | Khu mỏ, cảng biển | vùng không có sóng nhà mạng tốt | | Cơ sở y tế, giáo dục | cần kiểm soát mạng riêng |

Ba lợi ích so với Wi-Fi: | Lợi ích | Chi tiết | |---|---| | Vùng phủ rộng hơn | một cell phủ cả nhà xưởng | | Chuyển vùng liền mạch | thiết bị di chuyển không đứt | | Độ trễ và độ tin cậy tốt hơn | |

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

• **C. AWS Wavelength — đây là phương án gần nhất vì cũng liên quan tới mạng 5G, nhưng nó phục vụ mục đích ngược lại: Wavelength đặt hạ tầng AWS bên trong mạng 5G của NHÀ MẠNG để ứng dụng chạy gần thiết bị di động. Nó không giúp bạn tự dựng mạng.
• **D. AWS Outposts — đưa phần cứng của AWS (EC2, EBS, S3) vào trung tâm dữ liệu của bạn. Đây là hạ tầng tính toán lai, không phải mạng di động.
• **B. AWS CloudHSM — module bảo mật phần cứng để quản lý khoá mã hoá. Hoàn toàn không liên quan.

Ghi nhớ

⚠ Bốn dịch vụ "biên" của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS Private 5G | TỰ DỰNG mạng di động riêng | | AWS Wavelength | hạ tầng AWS TRONG mạng 5G của nhà mạng | | AWS Outposts | phần cứng AWS trong trung tâm dữ liệu của bạn | | AWS Local Zones | hạ tầng AWS gần thành phố lớn |

⚠ Ba dịch vụ dễ lẫn nhất — phân biệt bằng "ai sở hữu mạng":

Private 5G:  BẠN sở hữu mạng di động
Wavelength:  NHÀ MẠNG sở hữu mạng, AWS đặt compute vào đó
Outposts:    không liên quan tới mạng di động

Từ khoá nhận diện:

"build their OWN private cellular network" → AWS Private 5G "ultra-low latency for mobile users on carrier 5G" → Wavelength "run AWS services in my data center" → Outposts "low latency in a city without a full Region" → Local Zones

Ba đặc điểm của AWS Wavelength: | Đặc điểm | Chi tiết | |---|---| | Wavelength Zone đặt tại trung tâm của nhà mạng | | | Ứng dụng chạy gần thiết bị di động | độ trễ một chữ số ms | | Dùng cho AR/VR, xe tự lái, game di động | |

Ba đặc điểm của AWS Outposts: | Đặc điểm | Chi tiết | |---|---| | AWS gửi rack phần cứng tới chỗ bạn | | | Chạy EC2, EBS, S3, RDS, EKS tại chỗ | | | AWS quản lý và bảo trì phần cứng | |

Hai dạng Outposts: | Dạng | Kích thước | |---|---| | Outposts rack | cả rack 42U | | Outposts server | 1U hoặc 2U |

Ba đặc điểm của Local Zones: | Đặc điểm | Chi tiết | |---|---| | Phần mở rộng của một Region | | | Đặt gần các thành phố lớn | | | Có một tập dịch vụ giới hạn | EC2, EBS, ELB... |

Ba lưu ý về AWS Private 5G: | Lưu ý | Chi tiết | |---|---| | Dùng phổ tần chia sẻ (CBRS ở Mỹ) | không cần giấy phép riêng | | Trả tiền theo dung lượng và thời gian | | | Khả dụng theo quốc gia | kiểm tra trước |

Ba lưu ý khi tích hợp với AWS: | Lưu ý | Chi tiết | |---|---| | Mạng riêng nối vào VPC của bạn | | | Thiết bị truy cập tài nguyên AWS như trong VPC | | | Dùng security group kiểm soát | |

Ba dịch vụ IoT thường đi kèm: | Dịch vụ | Việc | |---|---| | AWS IoT Core | quản lý thiết bị và thông điệp | | AWS IoT Greengrass | chạy logic tại biên | | Amazon Kinesis | nạp dữ liệu theo luồng |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | SIM card do AWS cấp, quản lý tập trung | | | Chỉ thiết bị có SIM hợp lệ vào được mạng | | | Lưu lượng cách ly khỏi mạng công cộng | |

Ba việc cần chuẩn bị: | Việc | Chi tiết | |---|---| | Khảo sát địa điểm để đặt radio | | | Kiểm tra quy định phổ tần địa phương | | | Lên kế hoạch tích hợp với VPC | |

Và một lời khuyên: hãy kiểm tra dịch vụ có khả dụng ở quốc gia của bạn trước khi lên kế hoạch. AWS Private 5G phụ thuộc vào quy định phổ tần của từng nước, và danh sách quốc gia được hỗ trợ hẹp hơn nhiều so với danh sách vùng AWS thông thường.

Đáp án

D — Bật detailed monitoring trên mọi EC2 instance và dùng số liệu CloudWatch để phân tích.

Vì sao đúng

Đề nêu một yêu cầu duy nhất và rất cụ thể: độ chi tiết 1 phút. Đó chính là định nghĩa của detailed monitoring: | Chế độ | Chu kỳ | Giá | |---|---|---| | Basic monitoring (mặc định) | 5 phút | miễn phí | | Detailed monitoring | 1 phút | tính phí theo metric |

Bật bằng một lệnh:

aws ec2 monitor-instances --instance-ids i-abc123 i-def456

Hoặc bật sẵn trong launch template:

{"Monitoring": {"Enabled": true}}

⚠ Vì sao ba phương án kia đều sai loại dữ liệu:

Đề hỏi về HIỆU NĂNG (CPU, mạng, đĩa)
    → đó là METRIC
        ↓
    Log (CloudWatch Logs, CloudTrail) ghi lại SỰ KIỆN
    → không cho biết CPU của máy là bao nhiêu

Ba lợi ích trong kiểm thử tải: | Lợi ích | Chi tiết | |---|---| | Thấy được biến động trong từng phút | | | Alarm phản ứng nhanh gấp 5 lần | | | Không phải viết mã gì | bật một cờ |

⚠ Vế thứ hai quan trọng khi có Auto Scaling:

Metric 5 phút:
    tải tăng → chờ tối đa 5 phút để có điểm số liệu
             → chờ thêm chu kỳ đánh giá
                 ↓
    Có thể mất 10-15 phút mới scale

Bật tạm cho đợt kiểm thử rồi tắt:

aws ec2 unmonitor-instances --instance-ids i-abc123

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

• **A. Viết Lambda lấy log EC2 từ CloudWatch Logs, rồi dùng CloudWatch metrics phân tích — đây là phương án gần nhất vì có nhắc tới CloudWatch metrics, nhưng nó lẫn lộn log và metric: log ứng dụng không chứa số liệu CPU. Và viết Lambda là công thừa khi chỉ cần bật một cờ.
• **C. Gửi CloudWatch Logs sang S3 rồi dùng Athena phân tích — cùng nhầm lẫn log/metric, cộng thêm độ trễ rất lớn: dữ liệu phải qua S3 rồi mới truy vấn được.
• **B. Tạo CloudTrail trail ghi data event rồi truy vấn bằng Athena — CloudTrail ghi lại lời gọi API, không ghi hiệu năng máy. Và data event của CloudTrail dành cho S3, Lambda, DynamoDB chứ không phải EC2.

Ghi nhớ

⚠ Hai chế độ giám sát EC2 — bảng phải thuộc: | Chế độ | Chu kỳ | Phí | |---|---|---| | Basic | 5 phút | miễn phí | | Detailed | 1 phút | tính phí mỗi metric |

Từ khoá nhận diện:

"1-minute granularity", "detailed monitoring" → bật detailed monitoring "sub-minute", "high resolution" → custom metric độ phân giải cao "who called which API" → CloudTrail "search application log content" → CloudWatch Logs Insights

Ba mức độ phân giải của CloudWatch: | Mức | Chu kỳ | |---|---| | Standard | 60 giây | | High resolution | 1, 5, 10, 30 giây ← chỉ custom metric | | Basic EC2 | 300 giây |

Custom metric độ phân giải cao:

aws cloudwatch put-metric-data --namespace UngDung \
  --metric-name DoTreRequest --value 42 --storage-resolution 1

⚠ Ba metric mà EC2 KHÔNG tự gửi: | Metric | Vì sao thiếu | |---|---| | Bộ nhớ (RAM) đang dùng | hypervisor không nhìn thấy trong OS | | Dung lượng đĩa đã dùng | như trên | | Số tiến trình | như trên |

Cách lấy chúng:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s -c ssm:CauHinhAgent

CloudWatch Agent gửi mem_used_percent, disk_used_percent
làm custom metric
    ↓
    Nhiều người tưởng thiếu memory metric là lỗi cấu hình

⚠ Ba loại dữ liệu quan sát — phân biệt rõ: | Loại | Công cụ | Trả lời | |---|---|---| | Metric | CloudWatch Metrics | "tài nguyên dùng bao nhiêu?" | | Log | CloudWatch Logs | "chuyện gì đã xảy ra?" | | Trace | AWS X-Ray | "request chậm ở bước nào?" | | Audit | CloudTrail | "ai gọi API nào?" |

Ba lưu ý khi đặt alarm: | Lưu ý | Chi tiết | |---|---| | Period không nhỏ hơn chu kỳ metric | 60s với detailed | | EvaluationPeriods cân bằng nhạy và nhiễu | | | TreatMissingData đặt rõ ràng | |

aws cloudwatch put-metric-alarm --alarm-name cpu-cao \
  --metric-name CPUUtilization --namespace AWS/EC2 \
  --dimensions Name=InstanceId,Value=i-abc123 \
  --period 60 --evaluation-periods 2 --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching

Ba lưu ý về chi phí detailed monitoring: | Lưu ý | Chi tiết | |---|---| | Tính theo SỐ METRIC mỗi instance | khoảng 7 metric | | Nhiều instance = chi phí nhân lên | | | Bật tạm cho đợt kiểm thử rồi tắt | |

Ba công cụ hỗ trợ kiểm thử tải: | Công cụ | Việc | |---|---| | CloudWatch dashboard | xem nhiều metric cùng lúc | | X-Ray | tìm nút thắt trong chuỗi request | | Distributed Load Testing solution | dựng máy sinh tải |

Ba metric quan trọng nhất khi thử tải web: | Metric | Ý nghĩa | |---|---| | CPUUtilization | | | TargetResponseTime của ALB | trải nghiệm thật | | HTTPCode_Target_5XX_Count | |

Ba lưu ý về CloudWatch Logs Insights: | Lưu ý | Chi tiết | |---|---| | Truy vấn log gần thời gian thực | | | Tính phí theo dữ liệu quét | | | Đặt retention cho log group | mặc định vô thời hạn |

Ba việc nên làm trước đợt kiểm thử: | Việc | Chi tiết | |---|---| | Bật detailed monitoring sớm vài ngày | có đường cơ sở để so | | Cài CloudWatch Agent nếu cần metric RAM | | | Dựng dashboard gộp mọi tầng | |

Và một lời khuyên: hãy bật detailed monitoring vài ngày trước khi bắt đầu kiểm thử tải. Số liệu 1 phút chỉ hữu ích khi bạn biết mức bình thường là bao nhiêu — bật đúng hôm chạy thử thì bạn có đồ thị đẹp nhưng không có gì để so sánh, và mọi con số đều trông đáng lo.

Đáp án

C — Amazon MQ.

Vì sao đúng

Đề nêu hai ràng buộc, và Amazon MQ là dịch vụ duy nhất thoả cả hai: | Ràng buộc | Cách đáp ứng | |---|---| | **Message broker dùng giao thức MQTT | Amazon MQ hỗ trợ MQTT | | KHÔNG được viết lại mã ứng dụng | giữ nguyên giao thức chuẩn ngành |

⚠ "MQTT" và "no rewriting code" là cặp từ khoá quyết định:

SQS và SNS dùng API RIÊNG của AWS
    → ứng dụng phải viết lại tầng nhắn tin
        ↓
Amazon MQ hỗ trợ giao thức CHUẨN NGÀNH
    → MQTT, AMQP, STOMP, OpenWire, JMS
    → ứng dụng kết nối như với broker cũ

Tạo broker:

aws mq create-broker --broker-name broker-iot \
  --engine-type ACTIVEMQ --engine-version 5.18 \
  --host-instance-type mq.m5.large \
  --deployment-mode ACTIVE_STANDBY_MULTI_AZ \
  --subnet-ids subnet-az-a subnet-az-b \
  --security-groups sg-mq \
  --users Username=ungdung,Password=<mat-khau>,ConsoleAccess=false \
  --publicly-accessible false

Ứng dụng kết nối bằng MQTT như cũ:

mqtt+ssl://b-abc123-1.mq.ap-southeast-1.amazonaws.com:8883

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đổi một dòng mã nào | | | AWS lo vá lỗi, sao lưu, chuyển đổi dự phòng | | | Active/standby qua hai AZ | |

⚠ Hai engine của Amazon MQ: | Engine | Giao thức hỗ trợ | |---|---| | ActiveMQ | MQTT, AMQP, STOMP, OpenWire, JMS, WebSocket | | RabbitMQ | AMQP 0-9-1 (và MQTT qua plugin) |

Đề nói MQTT → ActiveMQ là lựa chọn chuẩn

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

• **B. Amazon SQS — đây là phương án gần nhất vì cũng là dịch vụ hàng đợi được quản lý, nhưng SQS dùng API riêng của AWS, không hiểu MQTT. Chuyển sang SQS nghĩa là viết lại toàn bộ tầng nhắn tin.
• **A. Amazon SNS — cùng vấn đề, và SNS là mô hình pub/sub đẩy, không lưu trữ — khác hẳn một message broker.
• **D. AWS Step Functions — dịch vụ điều phối quy trình nhiều bước, không phải message broker.

Ghi nhớ

⚠ Bốn dịch vụ nhắn tin — bảng phải thuộc: | Dịch vụ | Giao thức | Dùng khi | |---|---|---| | Amazon MQ | MQTT, AMQP, STOMP, JMS, OpenWire | DI CHUYỂN ứng dụng có sẵn | | Amazon SQS | API AWS | xây MỚI trên AWS | | Amazon SNS | API AWS | fan-out | | AWS IoT Core | MQTT, HTTPS, LoRaWAN | thiết bị IoT quy mô lớn |

⚠ AWS IoT Core cũng hỗ trợ MQTT — khi nào chọn cái nào:

Amazon MQ:    di chuyển ứng dụng có broker sẵn
              → giữ nguyên mọi thứ
        ↓
AWS IoT Core: hàng triệu thiết bị IoT
              → có device registry, shadow, rules engine
              → serverless, không quản lý broker

Từ khoá nhận diện:

"existing broker" + "MQTT/AMQP/JMS" + "no code rewrite" → Amazon MQ "build new decoupled app on AWS" → SQS / SNS "millions of IoT devices" → AWS IoT Core "orchestrate multi-step workflow" → Step Functions

⚠ Amazon MQ và SQS — bảng phân biệt: | | Amazon MQ | Amazon SQS | |---|---|---| | Giao thức | chuẩn ngành | API riêng AWS | | Co giãn | theo cỡ broker | gần như vô hạn | | Vận hành | chọn cỡ, phiên bản | không có gì | | Chi phí | theo giờ broker | theo request | | Dùng cho | di chuyển | xây mới |

Ba chế độ triển khai Amazon MQ: | Chế độ | Đặc điểm | |---|---| | SINGLE_INSTANCE | một broker, không dự phòng | | ACTIVE_STANDBY_MULTI_AZ | hai broker ActiveMQ, tự chuyển đổi | | CLUSTER_MULTI_AZ | cụm ba node RabbitMQ |

⚠ Ba lưu ý về chuyển đổi dự phòng: | Lưu ý | Chi tiết | |---|---| | Mất khoảng 1-2 phút | | | Client phải TỰ kết nối lại | | | Dùng failover transport URI | |

failover:(ssl://b-1-abc.mq.ap-southeast-1.amazonaws.com:61617,
          ssl://b-2-abc.mq.ap-southeast-1.amazonaws.com:61617)

Ba cổng của ActiveMQ trên Amazon MQ: | Giao thức | Cổng | |---|---| | OpenWire (SSL) | 61617 | | MQTT (SSL) | 8883 | | AMQP (SSL) | 5671 | | STOMP (SSL) | 61614 |

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Đặt broker trong subnet RIÊNG TƯ | | | --publicly-accessible false | | | Security group mở đúng cổng cho ứng dụng | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá in transit bắt buộc (SSL) | | | Mã hoá at rest bằng KMS | | | Lưu credential trong Secrets Manager | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Chọn cỡ broker theo thông lượng | | | Theo dõi CpuUtilization và HeapUsage | | | Active/standby có độ trễ ghi cao hơn | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | QueueSize | tồn đọng | | ConsumerCount | có consumer nào không | | CpuUtilization | broker có quá tải không |

Ba bước di chuyển từ broker tự quản: | Bước | Chi tiết | |---|---| | Tạo broker Amazon MQ cùng phiên bản engine | | | Đổi chuỗi kết nối của ứng dụng | | | Chuyển dần producer rồi consumer | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Broker tính theo GIỜ | active/standby tính hai | | Cộng phí lưu trữ | | | Đắt hơn SQS đáng kể | |

Ba lưu ý về hiện đại hoá về sau: | Lưu ý | Chi tiết | |---|---| | Amazon MQ là bước đệm khi di chuyển | | | Về lâu dài, SQS/SNS rẻ và ít việc hơn | | | Chuyển dần từng luồng nhắn tin | |

Và một lời khuyên: hãy coi Amazon MQ là bước đệm chứ không phải đích đến. Nó cho phép chuyển ứng dụng lên AWS mà không đụng mã, nhưng bạn vẫn phải chọn cỡ broker, theo dõi bộ nhớ heap và trả tiền theo giờ — những việc mà SQS đã bỏ hẳn.

Đáp án

D — Dùng AWS Lambda biến đổi ảnh gốc theo yêu cầu, lưu cả ảnh gốc lẫn ảnh đã xử lý trong S3, và cấu hình CloudFront với S3 bucket làm origin.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này thoả hết với chi phí thấp nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Sinh ảnh tuỳ chỉnh THEO YÊU CẦU | Lambda — chỉ chạy khi có request | | Tính sẵn sàng cao | Lambda, S3, CloudFront đều đa AZ sẵn | | TIẾT KIỆM CHI PHÍ NHẤT | không máy chủ chạy 24/7 |

⚠ Hai lựa chọn trong mỗi phương án — hai trục quyết định: | Trục | Lựa chọn tốt | |---|---| | Tính toán | Lambda (chỉ trả khi chạy) hơn EC2 (trả 24/7) | | Lưu ảnh | S3 (thiết kế cho object lớn) hơn DynamoDB |

Chỉ phương án D chọn ĐÚNG cả hai trục

⚠ Vì sao DynamoDB sai cho việc lưu ảnh:

DynamoDB giới hạn 400 KB mỗi item
    → ảnh thường lớn hơn nhiều
        ↓
    Và giá mỗi GB của DynamoDB cao hơn S3 rất nhiều
    → dùng cho ảnh là sai mô hình

Kiến trúc:

Người dùng → CloudFront → S3 (ảnh đã xử lý)
                            │ nếu chưa có (404)
                            ▼
                       Lambda sinh ảnh
                            → ghi vào S3
                            → trả về cho người dùng

Cách gọn nhất — CloudFront custom error response:

{"CustomErrorResponses": {"Quantity": 1, "Items": [
  {"ErrorCode": 404, "ResponsePagePath": "/xu-ly",
   "ResponseCode": "200", "ErrorCachingMinTTL": 0}]}}

Ảnh chưa tồn tại → S3 trả 404
    → CloudFront chuyển sang Lambda sinh ảnh
    → ghi vào S3, lần sau lấy thẳng từ cache

Hoặc dùng S3 Object Lambda:

aws s3control create-access-point-for-object-lambda \
  --account-id 123456789012 --name olap-anh \
  --configuration '{
    "SupportingAccessPoint":"arn:aws:s3:ap-southeast-1:123456789012:accesspoint/ap-anh",
    "TransformationConfigurations":[{
      "Actions":["GetObject"],
      "ContentTransformation":{
        "AwsLambda":{"FunctionArn":"arn:aws:lambda:...:function:bien-doi-anh"}}}]}'

Ba lợi ích về chi phí: | Lợi ích | Chi tiết | |---|---| | Không có EC2 chạy 24/7 | Lambda tính theo mili giây | | CloudFront cache — Lambda chỉ chạy lần đầu | | | S3 rẻ hơn DynamoDB nhiều lần cho object lớn | |

⚠ Vế thứ hai là điểm quyết định về chi phí:

Không có CloudFront: mỗi request gọi Lambda
    → phí Lambda tăng theo lưu lượng
        ↓
Có CloudFront: kết quả cache ở edge
    → hàng nghìn người xem chỉ tốn vài lần gọi

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

• **B. Dùng EC2 biến đổi ảnh, lưu gốc ở S3 và ảnh đã xử lý ở DynamoDB, CloudFront với S3 origin — đây là phương án gần nhất vì cũng có CloudFront, nhưng sai ở hai trục: EC2 chạy 24/7 tốn kém hơn Lambda, và DynamoDB không phù hợp cho ảnh.
• **A. Dùng Lambda nhưng lưu ảnh đã xử lý ở DynamoDB và đặt ELB trước EC2 — mâu thuẫn nội tại: dùng Lambda mà lại có ELB trước EC2. Và DynamoDB vẫn sai cho ảnh.
• **C. Dùng EC2 biến đổi, lưu cả hai ở S3, đặt ELB phía trước — lưu trữ đúng nhưng tính toán sai: EC2 phải chạy liên tục, và ELB thêm chi phí cố định trong khi CloudFront còn cache được.

Ghi nhớ

⚠ Ba cách biến đổi ảnh trên AWS — bảng phải thuộc: | Cách | Khi nào biến đổi | |---|---| | S3 Object Lambda | LÚC ĐỌC (GET) | | S3 Event → Lambda | LÚC GHI (upload) | | CloudFront error → Lambda | lúc đọc, khi cache miss |

Từ khoá nhận diện:

"on-demand image generation" + "cost-effective" → Lambda + S3 + CloudFront "transform as retrieved" → S3 Object Lambda "process when uploaded" → S3 Event Notification "always-on processing" → EC2 hoặc ECS

⚠ Bảng chọn kho lưu trữ theo loại dữ liệu: | Loại dữ liệu | Kho | |---|---| | Object lớn (ảnh, video, tệp) | Amazon S3 | | Bản ghi nhỏ, truy vấn theo khoá | DynamoDB (tối đa 400 KB/item) | | Dữ liệu quan hệ | RDS / Aurora | | Hệ thống tệp chia sẻ | EFS / FSx |

Ba lý do S3 hợp cho ảnh: | Lý do | Chi tiết | |---|---| | Không giới hạn kích thước object (tới 5 TB) | | | Rẻ nhất mỗi GB | | | Tích hợp sẵn với CloudFront | |

⚠ Ba giới hạn của Lambda cần nhớ: | Giới hạn | Con số | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 128 MB - 10.240 MB | | /tmp | 512 MB - 10 GB | | Payload đồng bộ | 6 MB |

Xử lý ảnh lớn cần bộ nhớ và /tmp:

aws lambda update-function-configuration --function-name bien-doi-anh \
  --memory-size 3008 --ephemeral-storage Size=2048 --timeout 60

⚠ Tăng bộ nhớ có thể GIẢM tổng chi phí:

Lambda cấp CPU tỷ lệ với bộ nhớ
    → nhiều RAM hơn = chạy nhanh hơn
        ↓
    1024 MB × 4 giây có thể rẻ hơn 512 MB × 10 giây
    → dùng AWS Lambda Power Tuning để tìm điểm tối ưu

Ba lưu ý về cache của CloudFront: | Lưu ý | Chi tiết | |---|---| | Đưa tham số biến đổi vào CACHE KEY | ?w=800&f=webp | | TTL dài — ảnh đã xử lý không đổi | | | Bật nén | |

aws cloudfront create-cache-policy --cache-policy-config '{
  "Name":"cache-anh","DefaultTTL":86400,"MaxTTL":31536000,"MinTTL":1,
  "ParametersInCacheKeyAndForwardedToOrigin":{
    "QueryStringsConfig":{"QueryStringBehavior":"whitelist",
      "QueryStrings":{"Quantity":2,"Items":["w","f"]}},
    "HeadersConfig":{"HeaderBehavior":"none"},
    "CookiesConfig":{"CookieBehavior":"none"},
    "EnableAcceptEncodingGzip":true,"EnableAcceptEncodingBrotli":true}}'

⚠ Chỉ đưa tham số CẦN THIẾT vào cache key:

Forward mọi query string
    → ?utm_source=facebook tạo bản cache riêng
    → tỷ lệ trúng cache tụt thảm hại

⚠ Ba biện pháp chống lạm dụng: | Biện pháp | Chi tiết | |---|---| | Chỉ chấp nhận danh sách kích thước cố định | | | Đặt trần kích thước ảnh đầu ra | | | Rate-based rule của WAF | |

Không giới hạn tham số
    → kẻ tấn công gọi ?w=1&w=2&w=3... hàng nghìn lần
    → mỗi lần một cache key mới, một lần gọi Lambda

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Dùng OAC để bucket riêng tư | | | Lambda execution role quyền tối thiểu trên S3 | | | ViewerProtocolPolicy: redirect-to-https | |

Ba lưu ý về lưu trữ ảnh đã xử lý: | Lưu ý | Chi tiết | |---|---| | Đặt tiền tố riêng cho ảnh sinh ra | da-xu-ly/ | | Lifecycle xoá ảnh sinh ra sau N ngày | tái tạo lại được | | Giữ ảnh gốc lâu dài | |

{"Rules":[{"ID":"don-anh-sinh-ra","Status":"Enabled",
  "Filter":{"Prefix":"da-xu-ly/"},
  "Expiration":{"Days":90}}]}

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Tỷ lệ cache hit của CloudFront | quyết định chi phí Lambda | | Lambda Duration và Errors | | | Số object trong tiền tố ảnh sinh ra | |

Và một lời khuyên: hãy chỉ chấp nhận một danh sách cố định các biến thể ảnh. Cho phép tham số tuỳ ý nghe rất linh hoạt, nhưng mỗi giá trị khác nhau là một cache key mới và một lần gọi Lambda — đủ để biến một trang danh mục bình thường thành hoá đơn của một hệ thống xử lý ảnh.

Đáp án

A — Dùng Kinesis Data Streams cho sự kiện thời gian thực với một partition cho mỗi thiết bị, và dùng Kinesis Data Firehose lưu dữ liệu vào Amazon S3.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Nhận sự kiện theo ĐÚNG THỨ TỰ từ MỖI thiết bị | partition key theo thiết bị | | Thời gian thực | Kinesis Data Streams — độ trễ dưới giây | | Lưu dữ liệu cho xử lý sau | Firehose ghi vào S3 |

⚠ Cách Kinesis đảm bảo thứ tự:

Thứ tự được đảm bảo TRONG một SHARD
    → bản ghi có cùng partition key luôn vào cùng shard
        ↓
    Dùng mã thiết bị làm partition key
    → mọi sự kiện của một thiết bị giữ đúng thứ tự
    → thiết bị khác nhau xử lý SONG SONG

Gửi dữ liệu:

import boto3, json
kinesis = boto3.client('kinesis')

kinesis.put_record(
    StreamName='luong-thiet-bi',
    Data=json.dumps(su_kien),
    PartitionKey=su_kien['ma_thiet_bi'])

⚠ Phân biệt "partition" và "shard" — điểm quyết định giữa A và D: | Khái niệm | Nghĩa | |---|---| | Partition key | thuộc tính của BẢN GHI — quyết định vào shard nào | | Shard | đơn vị năng lực của stream |

Phương án D nói "một SHARD cho mỗi thiết bị"
    → với hàng nghìn thiết bị thì cần hàng nghìn shard
    → cực kỳ tốn kém và chạm giới hạn
        ↓
    Đúng cách: MỘT partition key cho mỗi thiết bị
    → nhiều thiết bị chia sẻ chung một shard

Và Firehose ghi vào S3:

aws firehose create-delivery-stream \
  --delivery-stream-name luu-du-lieu-thiet-bi \
  --delivery-stream-type KinesisStreamAsSource \
  --kinesis-stream-source-configuration \
    KinesisStreamARN=<arn-stream>,RoleARN=<arn-role> \
  --s3-destination-configuration \
    RoleARN=<arn-role>,BucketARN=arn:aws:s3:::kho-du-lieu-thiet-bi,\
Prefix=nam=!{timestamp:yyyy}/thang=!{timestamp:MM}/ngay=!{timestamp:dd}/,\
BufferingHints={SizeInMBs=64,IntervalInSeconds=300},\
CompressionFormat=GZIP

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thứ tự đảm bảo theo thiết bị | | | Nhiều consumer đọc cùng dữ liệu | | | Firehose tự gộp lô và nén | |

⚠ Và Kinesis cho phép ĐỌC LẠI:

Dữ liệu giữ 24 giờ tới 365 ngày
    → thêm một consumer mới đọc lại từ đầu được
        ↓
    SQS thì thông điệp bị xoá sau khi xử lý

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

• **D. Kinesis Data Streams với MỘT SHARD cho mỗi thiết bị, Firehose lưu vào Amazon EBS — đây là phương án gần nhất vì cũng dùng đúng Kinesis, nhưng sai hai chỗ: một shard mỗi thiết bị là không khả thi (hàng nghìn shard, chi phí khổng lồ), và Firehose không ghi vào EBS được — đích của nó là S3, Redshift, OpenSearch hoặc HTTP endpoint.
• **C. SQS FIFO một hàng đợi mỗi thiết bị, Lambda lưu vào EFS — FIFO đảm bảo thứ tự, nhưng hàng nghìn hàng đợi là không quản lý nổi. Và EFS đắt hơn S3 nhiều lần cho việc lưu trữ dữ liệu phân tích.
• **B. SQS Standard một hàng đợi mỗi thiết bị — Standard queue không đảm bảo thứ tự, vi phạm trực tiếp yêu cầu đầu tiên.

Ghi nhớ

⚠ Ba dịch vụ nạp dữ liệu theo luồng — bảng phải thuộc: | Dịch vụ | Thứ tự | Đọc lại | Quản lý | |---|---|---|---| | Kinesis Data Streams | theo partition key | ✅ tới 365 ngày | shard (hoặc on-demand) | | Kinesis Data Firehose | không đảm bảo | ❌ | không có gì | | Amazon MSK | theo partition | ✅ | cụm Kafka |

⚠ Data Streams và Firehose — bảng phân biệt cốt lõi: | | Data Streams | Firehose | |---|---|---| | Vai trò | giữ và phát dữ liệu | NẠP vào đích lưu trữ | | Đọc lại | ✅ | ❌ | | Độ trễ | dưới giây | 60-900 giây (đệm) | | Đích | consumer tự đọc | S3, Redshift, OpenSearch, HTTP |

Thường dùng CẢ HAI:
    Data Streams (thời gian thực) → Firehose → S3 (lưu trữ)
        ↓
    Đây chính là phương án A

Từ khoá nhận diện:

"ordered per device/asset" + "real time" → Kinesis với partition key "load streaming data into S3/Redshift" → Firehose "ordered, one consumer" → SQS FIFO "millions of IoT devices" → AWS IoT Core

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

Hot shard là vấn đề thật:

Một thiết bị gửi nhiều hơn hẳn các thiết bị khác
    → shard chứa nó bị quá tải
    → ProvisionedThroughputExceededException
        ↓
    Theo dõi metric theo shard để phát hiện

⚠ Giới hạn của một shard: | Chiều | Giới hạn | |---|---| | Ghi vào | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc ra | 2 MB/giây (chia cho mọi consumer) | | Enhanced fan-out | 2 MB/giây mỗi consumer |

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

aws kinesis create-stream --stream-name luong-thiet-bi \
  --stream-mode-details StreamMode=ON_DEMAND

⚠ Ba lưu ý về Firehose: | Lưu ý | Chi tiết | |---|---| | Đệm theo KÍCH THƯỚC hoặc THỜI GIAN | cái nào tới trước | | Buffer size 1-128 MB, interval 60-900 giây | | | Chuyển đổi định dạng sang Parquet được | |

Chuyển sang Parquet giảm chi phí truy vấn rất nhiều:

{"DataFormatConversionConfiguration": {
  "Enabled": true,
  "OutputFormatConfiguration": {"Serializer": {"ParquetSerDe": {}}},
  "SchemaConfiguration": {"DatabaseName":"kho_du_lieu",
    "TableName":"su_kien_thiet_bi","RoleARN":"<arn-role>"}}}

Ba lưu ý về phân vùng trên S3: | Lưu ý | Chi tiết | |---|---| | Dùng prefix động theo thời gian | !{timestamp:yyyy} | | Athena chỉ quét đúng phân vùng | | | Giảm chi phí truy vấn rất nhiều | |

Ba lưu ý về consumer: | Lưu ý | Chi tiết | |---|---| | Lambda: một hàm mỗi shard | | | Kinesis Client Library (KCL) | tự quản checkpoint | | Enhanced fan-out cho nhiều consumer | |

⚠ Lỗi một bản ghi chặn cả shard:

Lambda lỗi trên một bản ghi
    → thử lại mãi, shard không tiến lên
        ↓
    Đặt MaximumRetryAttempts, BisectBatchOnFunctionError,
    và destination cho bản ghi lỗi

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAge | consumer tụt lại bao xa | | WriteProvisionedThroughputExceeded | hot shard | | GetRecords.Success | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Provisioned tính theo shard-giờ | | | On-demand tính theo dữ liệu | | | Firehose tính theo GB nạp vào | |

Và một lời khuyên: hãy chọn partition key sao cho tải phân bố đều giữa các thiết bị. Dùng mã thiết bị là đúng về mặt thứ tự, nhưng nếu một vài thiết bị gửi gấp trăm lần các thiết bị khác thì shard chứa chúng sẽ nghẽn — và triệu chứng là lỗi throttling chỉ xảy ra với một phần dữ liệu.

Đáp án

A — Tạo bản ghi Route 53 với geolocation routing policy.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể, và geolocation là chính sách duy nhất diễn đạt được: | Yêu cầu | Cách đáp ứng | |---|---| | Quyền phân phối nội dung theo VÙNG ĐỊA LÝ | định tuyến theo QUỐC GIA của người dùng | | Người dùng ở vùng nào phải nhận nội dung từ vùng đó | ánh xạ tường minh quốc gia → vùng |

⚠ "Distribution rights" là từ khoá pháp lý, không phải hiệu năng:

Yêu cầu về BẢN QUYỀN
    → phải kiểm soát CHÍNH XÁC ai nhận nội dung nào
        ↓
    Geolocation: ánh xạ tường minh theo quốc gia
    → bạn khai rõ "người Đức → vùng eu-central-1"

Cấu hình:

aws route53 change-resource-record-sets --hosted-zone-id Z123 \
  --change-batch '{"Changes":[
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"noi-dung.vidu.com","Type":"A",
      "SetIdentifier":"chau-au","GeoLocation":{"ContinentCode":"EU"},
      "AliasTarget":{"HostedZoneId":"Z1","DNSName":"alb-eu...",
                     "EvaluateTargetHealth":true}}},
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"noi-dung.vidu.com","Type":"A",
      "SetIdentifier":"viet-nam","GeoLocation":{"CountryCode":"VN"},
      "AliasTarget":{"HostedZoneId":"Z2","DNSName":"alb-ap...",
                     "EvaluateTargetHealth":true}}},
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"noi-dung.vidu.com","Type":"A",
      "SetIdentifier":"mac-dinh","GeoLocation":{"CountryCode":"*"},
      "AliasTarget":{"HostedZoneId":"Z3","DNSName":"alb-us...",
                     "EvaluateTargetHealth":true}}}]}'

⚠ Bản ghi mặc định (CountryCode: "*") là BẮT BUỘC:

Chỉ khai vài quốc gia
    → người dùng ở quốc gia không khai KHÔNG khớp bản ghi nào
    → nhận lỗi NXDOMAIN
        ↓
    Luôn có một bản ghi Default

Ba mức chi tiết của geolocation: | Mức | Ví dụ | |---|---| | Châu lục | ContinentCode: "EU" | | Quốc gia | CountryCode: "VN" | | Bang (chỉ Mỹ) | SubdivisionCode: "CA" |

⚠ Route 53 chọn bản ghi CHI TIẾT NHẤT:

Có bản ghi cho châu Âu VÀ bản ghi cho Đức
    → người dùng ở Đức nhận bản ghi ĐỨC
        ↓
    Quốc gia thắng châu lục, bang thắng quốc gia

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Kiểm soát tường minh theo quốc gia | | | Đáp ứng yêu cầu pháp lý | | | Kết hợp được health check | |

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

• **B. Dùng geoproximity routing policy — đây là phương án gần nhất vì cũng dựa trên địa lý, nhưng nó định tuyến theo KHOẢNG CÁCH tới tài nguyên (có thể điều chỉnh bằng bias), không phải ánh xạ tường minh theo quốc gia. Người dùng gần biên giới có thể được đưa sang vùng sai — không chấp nhận được với yêu cầu bản quyền.
• **D. Dùng CloudFront với nhiều origin và WAF — CloudFront geo restriction chặn hoặc cho phép, nó không định tuyến tới origin khác nhau theo quốc gia. Và một distribution có một origin mặc định.
• **C. Cấu hình ALB với multi-Region routing — không có tính năng này: ALB chỉ hoạt động trong một vùng, không định tuyến giữa các vùng.

Ghi nhớ

⚠ Bảy chính sách định tuyến Route 53 — bảng phải thuộc: | Chính sách | Chọn theo | Dùng cho | |---|---|---| | Simple | một đích | cơ bản | | Weighted | tỷ lệ % | triển khai canary | | Latency-based | độ trễ mạng ĐO ĐƯỢC | hiệu năng | | Failover | health check | DR chính/phụ | | Geolocation | QUỐC GIA của người dùng | bản quyền, tuân thủ ← câu này | | Geoproximity | khoảng cách + bias | điều chỉnh tỷ lệ theo vùng | | Multivalue answer | tới 8 bản ghi khoẻ | cân bằng đơn giản |

⚠ Ba chính sách địa lý dễ lẫn nhất:

Latency-based:  "vùng nào TRẢ LỜI NHANH NHẤT"     → hiệu năng
Geolocation:    "người dùng Ở QUỐC GIA NÀO"        → tuân thủ, bản quyền
Geoproximity:   "KHOẢNG CÁCH địa lý + bias"        → điều chỉnh tỷ lệ

Từ khoá nhận diện:

"distribution rights", "licensing", "compliance by country" → geolocation "lowest latency", "best performance" → latency-based "shift traffic gradually" → weighted "block users from certain countries" → CloudFront geo restriction

⚠ Geolocation và CloudFront geo restriction — khác nhau: | | Route 53 geolocation | CloudFront geo restriction | |---|---|---| | Việc | ĐỊNH TUYẾN tới đích khác nhau | CHẶN hoặc cho phép | | Kết quả | người dùng vào đúng vùng | người dùng bị 403 | | Dùng khi | phục vụ nội dung khác nhau | cấm hoàn toàn |

Ba lưu ý về độ chính xác: | Lưu ý | Chi tiết | |---|---| | Dựa trên cơ sở dữ liệu IP → vị trí | | | VPN và proxy làm sai lệch | | | Không tuyệt đối 100% | |

⚠ Với yêu cầu bản quyền nghiêm ngặt:

Geolocation chặn được đa số
    → nhưng VPN vẫn lách được
        ↓
    Cần thêm: xác thực tài khoản, kiểm tra hồ sơ người dùng,
    hoặc CloudFront signed URL với kiểm tra phía máy chủ

Ba lưu ý khi cấu hình: | Lưu ý | Chi tiết | |---|---| | LUÔN có bản ghi Default | | | Gắn health check vào mỗi bản ghi | | | TTL ngắn cho bản ghi có health check | |

Kết hợp health check:

Vùng châu Âu hỏng
    → health check thất bại
    → Route 53 chuyển người dùng châu Âu sang bản ghi Default
        ↓
    Cân nhắc: điều đó có vi phạm bản quyền không?
    → nếu có thì phải trả lỗi thay vì chuyển vùng

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL dài giảm phí truy vấn | | | TTL ngắn cho bản ghi có failover | | | ALIAS record kế thừa TTL của đích | |

⚠ ALIAS và CNAME — nhắc lại: | | ALIAS | CNAME | |---|---|---| | Dùng ở zone apex | ✅ | ❌ | | Phí truy vấn | miễn phí (tài nguyên AWS) | tính phí | | EvaluateTargetHealth | ✅ | ❌ |

Ba cách kiểm chứng: | Cách | Chi tiết | |---|---| | test-dns-answer với resolver ở vùng khác | | | Thử qua VPN từ nhiều quốc gia | | | Xem Route 53 query log | |

aws route53 test-dns-answer --hosted-zone-id Z123 \
  --record-name noi-dung.vidu.com --record-type A \
  --resolver-ip 8.8.8.8 --edns0-client-subnet-ip 203.0.113.0 \
  --edns0-client-subnet-mask 24

⚠ --edns0-client-subnet-ip cho phép mô phỏng người dùng ở vị trí khác — rất hữu ích để kiểm chứng geolocation mà không cần VPN.

Ba lưu ý về nội dung khác nhau theo vùng: | Lưu ý | Chi tiết | |---|---| | Mỗi vùng có bộ nội dung riêng | | | Không dùng chung CloudFront cache | trừ khi tách theo quốc gia | | Ghi log để chứng minh tuân thủ | |

Ba lưu ý về Route 53 query logging: | Lưu ý | Chi tiết | |---|---| | Ghi mọi truy vấn DNS vào CloudWatch Logs | | | Hữu ích cho kiểm toán bản quyền | | | Có phí lưu trữ log | |

Và một lời khuyên: hãy quyết định trước điều gì xảy ra khi health check của một vùng thất bại. Với định tuyến theo bản quyền, chuyển người dùng sang vùng dự phòng có thể chính là hành vi vi phạm mà bạn đang cố tránh — đôi khi trả về lỗi là lựa chọn đúng hơn.

Đáp án

D — Mã hoá một snapshot từ instance chính, tạo một instance chính MỚI đã mã hoá, rồi tạo read replica xuyên vùng đã mã hoá từ đó.

Vì sao đúng

Đề mô tả một tình huống có ràng buộc kỹ thuật cứng: | Dữ kiện | Ràng buộc | |---|---| | CSDL chính CHƯA mã hoá | không bật mã hoá cho instance đang chạy được | | Read replica ở vùng mới phải mã hoá | replica chỉ mã hoá khi nguồn đã mã hoá |

⚠ Hai quy tắc cứng của RDS phải nhớ:

1. KHÔNG bật mã hoá cho instance đã tồn tại
   → phải tạo instance MỚI từ snapshot đã mã hoá

2. Read replica của instance CHƯA mã hoá
   → KHÔNG thể mã hoá
   → trạng thái mã hoá kế thừa từ nguồn

Quy trình đầy đủ:

1. Chụp snapshot của instance chính (chưa mã hoá)
2. COPY snapshot với --kms-key-id → snapshot ĐÃ mã hoá
3. RESTORE snapshot đó → instance chính MỚI (đã mã hoá)
4. Chuyển ứng dụng sang instance mới
5. Tạo read replica xuyên vùng từ instance mới
        ↓
    Bây giờ replica cũng được mã hoá

Thực hiện:

# 1. Chụp snapshot
aws rds create-db-snapshot --db-instance-identifier csdl-chinh \
  --db-snapshot-identifier snapshot-chua-ma-hoa

# 2. Copy có mã hoá
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier snapshot-chua-ma-hoa \
  --target-db-snapshot-identifier snapshot-da-ma-hoa \
  --kms-key-id alias/khoa-csdl

# 3. Restore thành instance mới
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier csdl-chinh-moi \
  --db-snapshot-identifier snapshot-da-ma-hoa \
  --multi-az

# 4. Tạo read replica xuyên vùng
aws rds create-db-instance-read-replica \
  --db-instance-identifier replica-eu \
  --source-db-instance-identifier arn:aws:rds:ap-southeast-1:...:db:csdl-chinh-moi \
  --region eu-west-1 --kms-key-id <arn-khoa-eu>

⚠ Read replica xuyên vùng cần khoá KMS Ở VÙNG ĐÍCH:

Khoá KMS gắn với một vùng cụ thể
    → replica ở eu-west-1 cần khoá của eu-west-1
        ↓
    Hoặc dùng multi-Region key

Ba lưu ý về thời gian ngừng: | Lưu ý | Chi tiết | |---|---| | Có thời gian ngừng khi chuyển sang instance mới | | | Dùng DMS để giảm thiểu | | | Hoặc chấp nhận cửa sổ bảo trì | |

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

• **B. Mã hoá snapshot từ instance chính, rồi tạo read replica xuyên vùng đã mã hoá TỪ SNAPSHOT — đây là phương án gần nhất và hai bước đầu đúng, nhưng không tạo read replica từ snapshot được: read replica luôn được tạo từ một DB instance đang chạy, không phải từ snapshot.
• **A. Bật mã hoá trên instance chính rồi tạo replica — không bật mã hoá cho instance đã tồn tại được. Đây là ràng buộc cứng của RDS.
• **C. Bật mã hoá bằng KMS khi tạo read replica — replica kế thừa trạng thái mã hoá của nguồn; nguồn chưa mã hoá thì replica không mã hoá được.

Ghi nhớ

⚠ Ba quy tắc cứng về mã hoá RDS — phải thuộc: | Quy tắc | Chi tiết | |---|---| | Bật mã hoá CHỈ LÚC TẠO | không bật sau được | | Read replica kế thừa trạng thái mã hoá của nguồn | | | Không tắt mã hoá của instance đã mã hoá | |

⚠ Quy trình chuẩn để mã hoá một CSDL đang chạy:

snapshot → copy có mã hoá → restore thành instance mới → chuyển ứng dụng

Ba thứ được mã hoá khi bật: | Thứ | Chi tiết | |---|---| | Dữ liệu trên storage | | | Bản sao lưu tự động và snapshot | | | Read replica | | | Log | |

Từ khoá nhận diện:

"master is not encrypted" + "replica must be encrypted" → snapshot → copy encrypted → restore → replica "encrypt existing RDS" → cùng quy trình "encrypt existing EBS volume" → snapshot → copy encrypted → volume mới

⚠ EBS cũng có quy trình tương tự:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region ap-southeast-1 --encrypted --kms-key-id alias/khoa

Ba loại khoá KMS: | Loại | Kiểm soát | |---|---| | AWS managed key (aws/rds) | AWS quản lý | | Customer managed key | bạn đặt policy, bật xoay | | Multi-Region key | dùng chung qua nhiều vùng |

⚠ Multi-Region key cho replica xuyên vùng:

aws kms create-key --multi-region --description "Khoa CSDL"
aws kms replicate-key --key-id mrk-abc --replica-region eu-west-1

Cùng key material ở nhiều vùng
    → replica giải mã được ngay
    → nhưng key policy phải kiểm tra ở vùng đích

Ba đặc điểm của cross-region read replica: | Đặc điểm | Chi tiết | |---|---| | Sao chép bất đồng bộ qua Internet của AWS | | | Độ trễ cao hơn replica cùng vùng | | | Có phí truyền dữ liệu giữa vùng | |

Ba trường hợp dùng cross-region replica: | Trường hợp | Chi tiết | |---|---| | Khôi phục thảm hoạ | promote khi vùng chính chết | | Phục vụ đọc ở vùng khác | giảm độ trễ cho người dùng | | Di chuyển sang vùng khác | |

⚠ Read Replica và Multi-AZ — nhắc lại: | | Read Replica | Multi-AZ | |---|---|---| | Mục đích | hiệu năng đọc / DR | tính sẵn sàng | | Sao chép | bất đồng bộ | đồng bộ | | Phục vụ đọc | ✅ | ❌ | | Chuyển đổi | thủ công (promote) | tự động |

Ba cách giảm thời gian ngừng khi chuyển instance: | Cách | Chi tiết | |---|---| | AWS DMS với CDC | đồng bộ liên tục rồi cắt | | Chuyển trong cửa sổ bảo trì | | | Dùng Route 53 CNAME cho endpoint | đổi trỏ nhanh |

⚠ Dùng CNAME cho endpoint CSDL là thực hành tốt:

Ứng dụng trỏ tới csdl.noi-bo.vidu.com (CNAME)
    → đổi CNAME sang instance mới
        ↓
    Không phải sửa cấu hình ứng dụng

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Snapshot của instance mã hoá LUÔN mã hoá | | | Copy snapshot có thể đổi khoá | | | Copy sang vùng khác được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Mã hoá RDS KHÔNG tính phí thêm | chỉ phí KMS | | Customer managed key ~1 USD/tháng | | | Phí truyền dữ liệu giữa vùng | |

Ba cách kiểm chứng tuân thủ: | Cách | Công cụ | |---|---| | AWS Config rule rds-storage-encrypted | | | SCP chặn tạo RDS không mã hoá | | | describe-db-instances kiểm tra StorageEncrypted | |

{"Effect": "Deny", "Action": "rds:CreateDBInstance", "Resource": "*",
 "Condition": {"Bool": {"rds:StorageEncrypted": "false"}}}

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra instance mới có StorageEncrypted: true | | | Kiểm tra replica cũng mã hoá | | | Thử khôi phục từ snapshot mã hoá | |

Và một lời khuyên: hãy bật mã hoá ngay khi tạo mọi CSDL mới, kể cả khi chưa có yêu cầu. Mã hoá không bật được sau, nên mỗi CSDL chưa mã hoá là một quy trình snapshot-copy-restore-chuyển-ứng-dụng đang chờ bạn ở tương lai — thường vào lúc có kiểm toán.

Đáp án

D — AWS DataSync.

Vì sao đúng

Đề nêu ba dữ kiện, và DataSync khớp cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | **Dữ liệu trên file share Windows (SMB) | DataSync hỗ trợ SMB | | Chuyển vào Amazon S3 | S3 là đích được hỗ trợ | | **TỰ ĐỘNG hoá qua Direct Connect | lập lịch + VPC endpoint đi qua DX |

⚠ "Automate" là từ khoá phân biệt DataSync với việc chép thủ công:

DataSync có:
    → lập lịch chạy định kỳ
    → chỉ chép phần THAY ĐỔI ở lần sau
    → kiểm tra toàn vẹn dữ liệu
    → báo cáo tệp lỗi
        ↓
    Đây là "automate the migration"

Triển khai agent:

aws datasync create-agent \
  --activation-key <khoa-kich-hoat> \
  --agent-name agent-tai-cho \
  --vpc-endpoint-id vpce-0abc123 \
  --subnet-arns arn:aws:ec2:ap-southeast-1:...:subnet/subnet-a \
  --security-group-arns arn:aws:ec2:...:security-group/sg-datasync

⚠ Dùng VPC endpoint để lưu lượng đi qua Direct Connect:

Agent kết nối tới endpoint kiểu VPC (PrivateLink)
    → đi qua private VIF của DX
    → KHÔNG chạm Internet
        ↓
    Dùng public endpoint thì đi qua Internet

Tạo location SMB và task:

aws datasync create-location-smb \
  --server-hostname 192.168.1.100 --subdirectory /tai-lieu \
  --user quan-tri --domain CONGTY --password '<mat-khau>' \
  --agent-arns <arn-agent>

aws datasync create-task \
  --source-location-arn <arn-smb> \
  --destination-location-arn <arn-s3> \
  --schedule ScheduleExpression="cron(0 2 * * ? *)" \
  --options '{"VerifyMode":"POINT_IN_TIME_CONSISTENT",
              "PreserveDeletedFiles":"PRESERVE",
              "BytesPerSecond":104857600}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nhanh hơn rsync nhiều lần | giao thức tối ưu riêng | | Chỉ chép phần thay đổi ở lần sau | | | Kiểm tra toàn vẹn tự động | |

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

• **B. AWS Snowball — đây là phương án gần nhất vì cũng chuyển dữ liệu lên S3, nhưng đề nói rõ đã có Direct Connect và muốn tự động hoá qua đường đó. Snowball là chuyển vật lý một lần, không tự động và không dùng DX.
• **A. AWS Database Migration Service (DMS) — dịch vụ chuyển CSDL, không chuyển file share.
• **C. AWS CloudFormation — công cụ hạ tầng dưới dạng mã, không di chuyển dữ liệu.

Ghi nhớ

⚠ Ba công cụ di chuyển dữ liệu — bảng phải thuộc: | Công cụ | Khi nào | |---|---| | AWS DataSync | di chuyển/đồng bộ qua MẠNG, tự động | | AWS Snow family | lượng lớn, mạng kém, một lần | | AWS Storage Gateway | truy cập LIÊN TỤC có cache |

Từ khoá nhận diện:

"automate migration over the network" → DataSync "limited bandwidth + deadline" → Snowball "local caching, keep using on-premises" → Storage Gateway "migrate a database" → DMS

⚠ DataSync và Storage Gateway — bảng phân biệt: | | DataSync | Storage Gateway | |---|---|---| | Mục đích | DI CHUYỂN dữ liệu | truy cập liên tục | | Cache cục bộ | ❌ | ✅ | | Chạy | theo lịch hoặc một lần | liên tục | | Tốc độ | nhanh hơn nhiều | |

Ba nguồn DataSync hỗ trợ: | Nguồn | Ghi chú | |---|---| | NFS, SMB tại chỗ | ← câu này | | HDFS | | | Object storage tương thích S3 | | | S3, EFS, FSx (giữa các dịch vụ AWS) | |

Ba đích DataSync hỗ trợ: | Đích | Ghi chú | |---|---| | Amazon S3 | mọi lớp lưu trữ | | Amazon EFS | | | FSx (Windows, Lustre, ONTAP, OpenZFS) | |

⚠ Ba tuỳ chọn giữ metadata quan trọng với SMB: | Tuỳ chọn | Việc | |---|---| | SecurityDescriptorCopyFlags | giữ ACL của Windows | | PosixPermissions | quyền POSIX | | Uid / Gid | chủ sở hữu |

Không đặt SecurityDescriptorCopyFlags
    → tệp sang được nhưng MẤT quyền NTFS
        ↓
    Với S3 làm đích thì ACL lưu thành metadata của object

Ba chế độ VerifyMode: | Chế độ | Đặc điểm | |---|---| | POINT_IN_TIME_CONSISTENT | kiểm tra TOÀN BỘ sau khi chép | | ONLY_FILES_TRANSFERRED | chỉ tệp vừa chép | | NONE | nhanh nhất, không kiểm tra |

⚠ Ba cách agent kết nối tới AWS: | Cách | Đặc điểm | |---|---| | Public service endpoint | qua Internet | | VPC endpoint (PrivateLink) | riêng tư, qua DX hoặc VPN ← câu này | | FIPS endpoint | tuân thủ FIPS |

Ba yêu cầu tài nguyên cho agent: | Yêu cầu | Con số tối thiểu | |---|---| | vCPU | 4 | | RAM | 32 GB (cho > 20 triệu tệp) | | Đĩa | 80 GB |

⚠ Giới hạn băng thông là việc nên làm:

aws datasync update-task --task-arn <arn> \
  --options '{"BytesPerSecond":104857600}'

100 MB/s
    → không nuốt hết băng thông Direct Connect
    → tải nghiệp vụ khác vẫn chạy được

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Nhiều tệp nhỏ chậm hơn ít tệp lớn | | | Một agent có giới hạn thông lượng | | | Chạy nhiều task song song trên thư mục khác nhau | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí theo GB dữ liệu chuyển | | | Phí VPC endpoint theo giờ và GB | | | KHÔNG tính phí data transfer IN vào AWS | |

Ba lưu ý về lịch chạy: | Lưu ý | Chi tiết | |---|---| | Cron expression cho lịch định kỳ | | | Lần đầu chép toàn bộ, lần sau chỉ phần thay đổi | | | Đọc task report tìm tệp lỗi | |

aws datasync describe-task-execution --task-execution-arn <arn> \
  --query "[Status,FilesTransferred,BytesTransferred,Result]"

Ba lưu ý khi đích là S3: | Lưu ý | Chi tiết | |---|---| | Chọn lớp lưu trữ đích ngay khi tạo location | | | Cấu trúc thư mục thành tiền tố object | | | Lifecycle chuyển tầng sau đó | |

Ba lựa chọn kết hợp: | Kết hợp | Khi nào | |---|---| | Snowball cho khối lượng ban đầu + DataSync đồng bộ tiếp | dữ liệu rất lớn | | DataSync + Storage Gateway | vừa di chuyển vừa giữ truy cập | | DataSync giữa các dịch vụ AWS | di chuyển nội bộ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử một thư mục nhỏ trước | | | So số tệp và dung lượng hai bên | | | Kiểm tra metadata còn đúng | |

Và một lời khuyên: hãy đặt giới hạn băng thông cho task DataSync ngay từ đầu. Nó được thiết kế để chạy nhanh nhất có thể, và với một đường Direct Connect dùng chung, "nhanh nhất có thể" nghĩa là mọi tải nghiệp vụ khác đều chậm lại suốt thời gian đồng bộ.

Đáp án

A — Dùng capacity reservation kèm Savings Plans.

Vì sao đúng

Đề nêu ba dữ kiện, và cặp này giải quyết từng cái: | Dữ kiện | Vấn đề | Giải bằng | |---|---|---| | **Đợt tăng tải DỰ ĐOÁN ĐƯỢC hai lần mỗi tuần | cần ĐẢM BẢO có máy | capacity reservation | | Muốn GIẢM CHI PHÍ | | Savings Plans | | Vẫn phải đáp ứng nhu cầu khách hàng | không được thiếu máy | |

⚠ Hai công cụ giải hai bài toán KHÁC NHAU:

On-Demand Capacity Reservation:
    → ĐẢM BẢO có máy khi cần
    → KHÔNG giảm giá

Savings Plans:
    → GIẢM GIÁ tới ~72%
    → KHÔNG đảm bảo năng lực
        ↓
    Chúng ÁP CHỒNG được lên nhau
    → dùng cả hai là kiến trúc đúng

Vì sao cần đảm bảo năng lực:

Đợt tăng tải lớn và đột ngột
    → gặp lúc AZ hết năng lực loại instance đó
    → InsufficientInstanceCapacity
        ↓
    Auto Scaling muốn thêm máy nhưng không có máy để thêm

Đặt trước năng lực:

aws ec2 create-capacity-reservation \
  --instance-type m6i.xlarge --instance-platform Linux/UNIX \
  --availability-zone ap-southeast-1a --instance-count 20 \
  --instance-match-criteria targeted \
  --end-date-type limited --end-date 2026-09-01T00:00:00Z

⚠ Và huỷ khi không cần để tiết kiệm:

Capacity Reservation tính tiền LIÊN TỤC
    → kể cả những giờ không dùng
        ↓
    Đợt tăng hai lần mỗi tuần
    → tạo trước vài giờ, huỷ sau khi xong
    → tự động bằng EventBridge Scheduler

Mua Savings Plans:

aws savingsplans create-savings-plan \
  --savings-plan-offering-id <id> \
  --commitment 10.0 --upfront-payment-amount 0

Ba lợi ích của việc kết hợp: | Lợi ích | Chi tiết | |---|---| | Chắc chắn có máy lúc cao điểm | | | Giảm giá cho toàn bộ tải | | | Không bị gián đoạn | khác Spot |

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

• **D. Dùng hỗn hợp Spot và On-Demand — đây là phương án gần nhất và thường là lời khuyên tốt về chi phí, nhưng Spot bị thu hồi với 2 phút báo trước và không đảm bảo có máy khi cần. Với đợt tăng tải phục vụ khách hàng, đó là rủi ro không nên chấp nhận.
• **B. Mua Dedicated Host — phần cứng vật lý riêng, đắt hơn On-Demand thường. Dùng khi có yêu cầu tuân thủ hoặc giấy phép theo core, không phải để tiết kiệm.
• **C. Tăng kích thước instance hiện có — trả tiền cho máy lớn 24/7 trong khi chỉ cần thêm năng lực hai lần mỗi tuần. Ngược hẳn mục tiêu giảm chi phí.

Ghi nhớ

⚠ Bảng đảm bảo năng lực — thuộc bảng này là làm được cả nhóm câu: | Lựa chọn | Giảm giá | Đảm bảo năng lực | |---|---|---| | On-Demand Capacity Reservation | ❌ | ✅ | | Zonal Reserved Instance | ✅ | ✅ | | Regional Reserved Instance | ✅ | ❌ | | Savings Plans | ✅ | ❌ | | On-Demand | ❌ | ❌ | | Spot | ✅✅ | ❌ (bị thu hồi) |

⚠ Đây là hiểu nhầm phổ biến nhất:

Nhiều người tưởng Savings Plans và Regional RI
đảm bảo có máy
    → KHÔNG. Chúng chỉ là mô hình THANH TOÁN
        ↓
    Chỉ Capacity Reservation và zonal RI mới giữ chỗ

Từ khoá nhận diện:

"ensure capacity is available" + "lower costs" → Capacity Reservation + Savings Plans "predictable surge" → có thể lập lịch tạo/huỷ reservation "fault-tolerant, can be interrupted" → Spot "compliance requires dedicated hardware" → Dedicated Host

Ba loại Savings Plans: | Loại | Giảm | Linh hoạt | |---|---|---| | Compute Savings Plans | tới ~66% | mọi vùng, mọi họ, cả Fargate và Lambda | | EC2 Instance Savings Plans | tới ~72% | cố định họ và vùng | | SageMaker | | cho ML |

⚠ Ba đặc điểm của Capacity Reservation: | Đặc điểm | Chi tiết | |---|---| | Gắn với MỘT AZ cụ thể | không phải cả vùng | | Phải khớp instance type, platform, tenancy | | | Tính tiền dù dùng hay không | |

Hai chế độ khớp: | Chế độ | Hành vi | |---|---| | open | mọi instance khớp thuộc tính TỰ dùng chỗ | | targeted | chỉ instance khai rõ ARN mới dùng |

Dùng `open` mà có tải khác cùng loại instance
    → nó chiếm mất chỗ đã đặt cho đợt cao điểm
        ↓
    `targeted` an toàn hơn

Khai dùng chỗ đã đặt trong launch template:

{"CapacityReservationSpecification": {
  "CapacityReservationTarget": {
    "CapacityReservationId": "cr-0123456789abcdef0"}}}

⚠ Tự động tạo và huỷ theo lịch:

aws scheduler create-schedule --name tao-reservation \
  --schedule-expression "cron(0 6 ? * TUE,FRI *)" \
  --schedule-expression-timezone "Asia/Ho_Chi_Minh" \
  --flex-time-window Mode=OFF \
  --target '{"Arn":"arn:aws:scheduler:::aws-sdk:ec2:createCapacityReservation",
    "RoleArn":"<arn-role>","Input":"{...}"}'

Tạo trước đợt phát coupon vài giờ
    → huỷ sau khi tải giảm
        ↓
    Chỉ trả cho khoảng thời gian giữ chỗ

Ba cách chuẩn bị cho đợt tăng dự đoán được: | Cách | Chi tiết | |---|---| | ASG scheduled action tăng desired capacity | làm nóng trước | | Capacity Reservation đảm bảo có máy | | | Predictive scaling | học từ mẫu lịch sử |

⚠ Kết hợp cả ba là kiến trúc đầy đủ:

Capacity Reservation: đảm bảo AWS có máy
ASG scheduled action:  bật máy trước giờ cao điểm
Savings Plans:         giảm giá cho toàn bộ

Ba lưu ý về ASG scheduled action: | Lưu ý | Chi tiết | |---|---| | Đặt desired, không đặt min | vẫn cho co giãn xuống | | Luôn khai --time-zone | | | Đặt sớm hơn ước tính 15 phút | |

Ba lưu ý về Spot (để biết vì sao loại): | Lưu ý | Chi tiết | |---|---| | Bị thu hồi với 2 phút báo trước | | | KHÔNG đảm bảo có máy | | | "Spot blocks" đã NGỪNG từ 12/2021 | |

Ba công cụ phân tích chi phí: | Công cụ | Việc | |---|---| | Cost Explorer SP recommendations | gợi ý mua bao nhiêu | | Compute Optimizer | đúng cỡ máy | | Trusted Advisor | tài nguyên nhàn rỗi |

Ba lưu ý khi mua Savings Plans: | Lưu ý | Chi tiết | |---|---| | Đúng cỡ máy TRƯỚC khi mua | | | Mua phủ tải NỀN, không phủ đỉnh | | | Xem lại mức phủ hằng quý | |

⚠ Vế thứ hai quan trọng:

Cam kết theo mức đỉnh
    → phần lớn thời gian không dùng hết
    → cam kết thành lãng phí
        ↓
    Phủ phần tải nền, để đỉnh chạy On-Demand

Và một lời khuyên: hãy lập lịch tạo và huỷ Capacity Reservation quanh đợt phát coupon. Nó tính tiền liên tục như một instance đang chạy, nên giữ nó suốt tuần cho hai đợt cao điểm là trả tiền cho khoảng 90% thời gian không dùng tới.

Đáp án

A và E.

• A — Amazon DynamoDB
• E — AWS Lambda

Vì sao đúng

Đề nêu bốn dữ kiện, và cặp này khớp từng cái: | Dữ kiện | Cách đáp ứng | |---|---| | API Gateway ở tầng đầu | Lambda là backend tự nhiên | | **Lưu dữ liệu bằng KEY-VALUE | DynamoDB | | Dữ liệu ~1 GB, tăng trưởng KHÔNG BIẾT TRƯỚC | DynamoDB tự co giãn | | 0 tới hơn 800 request/giây | cả hai tự co giãn từ 0 |

⚠ "Key-value requests" là từ khoá chỉ thẳng vào DynamoDB:

Key-value = truy cập theo khoá, không cần JOIN
    → đúng mô hình của DynamoDB
        ↓
    RDS là CSDL quan hệ — quá mức và không co giãn từ 0

⚠ Và "0 tới hơn 800 request/giây" là mẫu tải lý tưởng cho serverless:

Tải xuống 0 → Lambda và DynamoDB on-demand
              KHÔNG tính phí gì
        ↓
    EC2 hay Fargate luôn phải có ít nhất một máy chạy

Kiến trúc:

Client → API Gateway → Lambda → DynamoDB
        ↓
    Không có máy chủ nào phải quản lý
    → tự co giãn từ 0 tới hàng nghìn

Tạo bảng on-demand:

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

Lambda xử lý:

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

def handler(event, context):
    ma = event['pathParameters']['ma']
    r = bang.get_item(Key={'ma': ma})
    return {'statusCode': 200,
            'body': json.dumps(r.get('Item', {}), default=str)}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Trả tiền theo lượng dùng thật | 0 request = 0 đồng | | Không quản lý máy chủ nào | | | Co giãn tự động, không cấu hình | |

⚠ Và một chi tiết quan trọng về giới hạn:

Lambda concurrency mặc định 1.000 mỗi vùng
    → 800 request/giây với mỗi request 100 ms
    → cần khoảng 80 lần chạy đồng thời
        ↓
    Nằm trong giới hạn thoải mái

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

• **B. Amazon RDS — đây là phương án gần nhất vì cũng là CSDL được quản lý, nhưng đề nói rõ key-value requests, và RDS không co giãn từ 0: instance chạy 24/7 dù có request hay không.
• **C. EC2 Auto Scaling — có máy chủ phải quản lý, và ASG không co giãn xuống 0 một cách thực tế cho một API phục vụ người dùng.
• **D. AWS Fargate — ít việc hơn EC2 nhưng vẫn phải giữ ít nhất một task chạy để phục vụ request; với tải xuống 0 thì Lambda tiết kiệm hơn.

Ghi nhớ

⚠ Ba mô hình backend cho API — bảng phải thuộc: | Mô hình | Co giãn từ 0 | Quản lý | |---|---|---| | API Gateway + Lambda | ✅ | chỉ mã | | ALB + Fargate | ❌ (tối thiểu 1 task) | task definition | | ALB + EC2 ASG | ❌ | cụm máy |

⚠ Ba CSDL và mô hình truy cập: | CSDL | Mô hình | |---|---| | DynamoDB | key-value, document | | RDS / Aurora | quan hệ, có JOIN và giao dịch | | ElastiCache | cache trong bộ nhớ |

Từ khoá nhận diện:

"key-value" + "unknown growth" + "0 to N requests" → DynamoDB + Lambda "relational, JOIN, transactions" → RDS / Aurora "always-on API with steady traffic" → Fargate hoặc EC2 "in-memory cache" → ElastiCache

⚠ Hai chế độ dung lượng DynamoDB: | Chế độ | Đặc điểm | |---|---| | On-demand (PAY_PER_REQUEST) | trả theo request, tự co giãn tức thì | | Provisioned | khai RCU/WCU, rẻ hơn khi tải ổn định |

Tải "0 tới hơn 800/giây, tăng trưởng không biết"
    → on-demand là lựa chọn đúng
        ↓
    Provisioned phải đoán trước và tự chỉnh

⚠ Ba giới hạn của Lambda: | Giới hạn | Con số | |---|---| | Thời gian chạy | 15 phút | | Concurrency mặc định mỗi vùng | 1.000 | | Payload đồng bộ | 6 MB |

Ba lưu ý về thiết kế khoá DynamoDB: | Lưu ý | Chi tiết | |---|---| | Partition key phân bố đều | tránh hot partition | | Thiết kế theo MẪU TRUY CẬP | không theo mô hình chuẩn hoá | | GSI cho mẫu truy cập khác | |

⚠ Dùng Query, tránh Scan:

Scan đọc TOÀN BỘ bảng rồi mới lọc
    → tốn RCU cho cả dữ liệu không dùng
        ↓
    Query chỉ đọc đúng partition cần
    → thiết kế khoá để luôn Query được

Ba tính năng DynamoDB đáng biết: | Tính năng | Việc | |---|---| | TTL | xoá dữ liệu hết hạn MIỄN PHÍ | | Point-in-Time Recovery | khôi phục bất kỳ giây nào trong 35 ngày | | Streams | phản ứng với thay đổi |

Bật TTL:

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

⚠ Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | Xoá MIỄN PHÍ, không tốn WCU | | | Có thể trễ tới 48 giờ | | | Thuộc tính phải là số Unix epoch GIÂY | |

Ba cách tối ưu chi phí: | Cách | Chi tiết | |---|---| | On-demand cho tải không đều | | | Chuyển sang provisioned khi tải ổn định | | | Standard-IA table class cho dữ liệu ít đọc | |

Ba lưu ý về API Gateway: | Lưu ý | Chi tiết | |---|---| | HTTP API rẻ hơn REST API ~70% | | | Bật throttling bảo vệ backend | | | Cache giảm gọi Lambda | |

⚠ Và có thể bỏ hẳn Lambda:

API Gateway tích hợp TRỰC TIẾP với DynamoDB
    → không cần Lambda ở giữa cho CRUD đơn giản
        ↓
    Bớt một thành phần, bớt độ trễ, bớt chi phí
    → nhưng phải viết VTL mapping template

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Lambda execution role cần quyền DynamoDB | | | Giới hạn Resource tới đúng bảng | | | Thêm quyền index nếu dùng GSI | |

{"Effect":"Allow",
 "Action":["dynamodb:GetItem","dynamodb:PutItem","dynamodb:Query"],
 "Resource":["arn:aws:dynamodb:ap-southeast-1:123456789012:table/DuLieuUngDung",
             "arn:aws:dynamodb:ap-southeast-1:123456789012:table/DuLieuUngDung/index/*"]}

Ba lưu ý về khởi động lạnh: | Lưu ý | Chi tiết | |---|---| | Lambda ngoài VPC khởi động nhanh hơn | | | DynamoDB không cần VPC | gọi qua API công khai hoặc endpoint | | Provisioned concurrency nếu cần độ trễ ổn định | |

⚠ DynamoDB không cần Lambda trong VPC — đây là lợi thế so với RDS.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ThrottledRequests của DynamoDB | | | Lambda Throttles và Duration | | | API Gateway 4XXError và 5XXError | |

Và một lời khuyên: hãy thiết kế khoá DynamoDB theo mẫu truy cập trước khi viết dòng mã đầu tiên. Với CSDL quan hệ bạn có thể thêm index sau, nhưng với DynamoDB thì partition key sai nghĩa là phải tạo lại bảng và chép toàn bộ dữ liệu.