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

Đáp án

B — Đưa luồng giao dịch vào Kinesis Data Streams; dùng tích hợp Lambda để gỡ dữ liệu nhạy cảm rồi lưu bản đã làm sạch vào DynamoDB; các ứng dụng nội bộ đọc giao dịch thô trực tiếp từ stream.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án B đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Chia sẻ với NHIỀU ứng dụng nội bộ | Kinesis Data Streams — nhiều consumer độc lập | | Gần thời gian thực | Kinesis độ trễ dưới một giây | | Gỡ dữ liệu nhạy cảm | Lambda biến đổi | | Lưu vào DATABASE TÀI LIỆU, truy xuất độ trễ thấp | DynamoDB |

Vế thứ nhất là điểm phân biệt quyết định:

Kinesis Data Streams:
    → GIỮ dữ liệu 1–365 ngày
    → NHIỀU consumer đọc ĐỘC LẬP cùng một luồng
    → mỗi consumer có con trỏ riêng
        ↓
    Đúng "share with MULTIPLE internal applications"

Và Firehose không làm được điều đó:

Kinesis Data Firehose:
    → KHÔNG giữ dữ liệu
    → giao thẳng tới ĐÍCH đã cấu hình
    → không có khái niệm "consumer đọc từ Firehose"
        ↓
    Ứng dụng nội bộ KHÔNG đọc được từ Firehose

Kiến trúc:

Ứng dụng web
    ↓ PutRecords
Kinesis Data Streams (giữ 24 giờ trở lên)
    ├─→ Lambda: gỡ dữ liệu nhạy cảm → DynamoDB (bản sạch)
    ├─→ Ứng dụng nội bộ A (đọc bản thô)
    ├─→ Ứng dụng nội bộ B
    └─→ Ứng dụng nội bộ C

Cấu hình Lambda đọc từ Kinesis:

aws lambda create-event-source-mapping   --function-name lam-sach-giao-dich   --event-source-arn <arn-stream>   --starting-position LATEST   --batch-size 100 --maximum-batching-window-in-seconds 1

Và DynamoDB đúng là "document database" cho truy xuất độ trễ thấp:

DynamoDB:
    ✓ mô hình key-value và document
    ✓ độ trễ mili giây một chữ số
    ✓ không giới hạn quy mô

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

• **D. Đưa vào Kinesis Data FIREHOSE, Lambda làm sạch, lưu vào DynamoDB, ứng dụng nội bộ đọc giao dịch thô từ Firehose — đây là phương án gần nhất và đúng ở phần biến đổi bằng Lambda, nhưng nó sai ở hai điểm: Firehose không cho ứng dụng đọc lại dữ liệu (nó chỉ đẩy tới đích), và DynamoDB không phải đích được Firehose hỗ trợ.
• **A. Ghi giao dịch thô vào DynamoDB, dùng "rule trong DynamoDB" để gỡ dữ liệu nhạy cảm, chia sẻ qua DynamoDB Streams — DynamoDB KHÔNG có khái niệm "rule": không có cơ chế tự biến đổi bản ghi khi ghi vào. Và lưu dữ liệu nhạy cảm rồi mới xoá nghĩa là nó đã từng nằm trong database.
• **C. Gom lô vào tệp phẳng trên S3, S3 event gọi Lambda làm sạch — không phải gần thời gian thực: xử lý theo lô thêm độ trễ đáng kể, trái yêu cầu "near-real-time".

Ghi nhớ

Kinesis Data Streams và Firehose — bảng phải thuộc: | | Data Streams | Firehose | |---|---|---| | Giữ dữ liệu | 1–365 ngày | ❌ không giữ | | Nhiều consumer đọc lại | ✅ | ❌ | | Độ trễ | dưới 1 giây | ~60 giây trở lên | | Quản lý shard | có (hoặc on-demand) | hoàn toàn tự động | | Đích | ứng dụng tự đọc | S3, Redshift, OpenSearch, Splunk, HTTP |

Quy tắc nhận diện:

"multiple applications consume", "replay", "sub-second" → Data Streams "load into S3/Redshift/OpenSearch", "no code" → Firehose

Đích được Firehose hỗ trợ — bảng cần biết: | Đích | Hỗ trợ | |---|---| | Amazon S3 | ✅ | | Amazon Redshift | ✅ | | OpenSearch Service | ✅ | | Splunk và endpoint HTTP | ✅ | | Amazon DynamoDB | ❌ | | Snowflake, Apache Iceberg | ✅ (mới) |

Dòng gạch đậm là lý do phương án D sai ở vế thứ hai.

Ba cách consumer đọc từ Kinesis Data Streams: | Cách | Đặc điểm | |---|---| | GetRecords (chia sẻ) | 2 MB/giây chia cho MỌI consumer của shard | | Enhanced fan-out | 2 MB/giây RIÊNG mỗi consumer | | Lambda event source mapping | được quản lý, tự thử lại |

Với nhiều ứng dụng nội bộ cùng đọc, enhanced fan-out đáng cân nhắc:

5 consumer dùng chung 2 MB/giây:
    → mỗi cái chỉ được ~400 KB/giây
    → và cạnh tranh giới hạn 5 GetRecords/giây

5 consumer với enhanced fan-out:
    → mỗi cái 2 MB/giây riêng
    → độ trễ giảm từ ~200ms xuống ~70ms
        ↓
    Đổi lại: tính phí riêng mỗi consumer-shard-giờ

Ba kỹ thuật gỡ dữ liệu nhạy cảm: | Kỹ thuật | Chi tiết | |---|---| | Loại bỏ trường | xoá hẳn khỏi bản ghi | | Mã hoá thay thế (tokenization) | thay bằng token, tra ngược được | | Che một phần (masking) | giữ 4 số cuối của thẻ |

Và AWS có dịch vụ chuyên cho việc này:

Amazon Comprehend có tính năng phát hiện PII
    → tự nhận diện tên, số thẻ, số bảo hiểm xã hội
    → dùng trong Lambda để che tự động
        ↓
    An toàn hơn danh sách trường viết tay

Ba lưu ý khi Lambda đọc từ Kinesis: | Lưu ý | Chi tiết | |---|---| | Một Lambda cho mỗi shard (mặc định) | song song theo shard | | ParallelizationFactor tới 10 | nhiều Lambda mỗi shard | | Lỗi CHẶN cả shard | phải cấu hình BisectBatchOnFunctionError và DLQ |

Dòng cuối là bẫy nghiêm trọng:

Một bản ghi gây lỗi Lambda
    → Lambda thử lại cả lô
    → thất bại tiếp → CHẶN toàn bộ shard
        ↓
    Dữ liệu phía sau không được xử lý cho tới khi hết hạn

{"MaximumRetryAttempts": 3,
 "BisectBatchOnFunctionError": true,
 "DestinationConfig": {"OnFailure": {"Destination": "<arn-sqs-dlq>"}}}

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAgeMilliseconds | consumer tụt lại bao xa — quan trọng nhất | | WriteProvisionedThroughputExceeded | producer bị throttle | | GetRecords.Success | |

Ba lưu ý về DynamoDB cho dữ liệu giao dịch: | Lưu ý | Chi tiết | |---|---| | Thiết kế partition key phân bố đều | mã giao dịch là lựa chọn tốt | | On-demand cho tải khó đoán | | | TTL nếu dữ liệu có hạn lưu | |

Ba biện pháp bảo mật cho dữ liệu tài chính: | Biện pháp | Chi tiết | |---|---| | Mã hoá Kinesis bằng KMS | at rest | | Mã hoá DynamoDB bằng customer managed key | | | VPC endpoint cho Kinesis và DynamoDB | không đi Internet |

Và một lời khuyên: hãy cấu hình DLQ cho Lambda đọc Kinesis ngay từ đầu. Một bản ghi sai định dạng có thể chặn đứng cả shard, và với dữ liệu giao dịch tài chính thì việc dừng xử lý im lặng nguy hiểm hơn nhiều so với việc mất một bản ghi vào hàng đợi lỗi.

Đáp án

C và E.

• C — Bật automated backup của RDS trong triển khai Multi-AZ, tạo bản sao lưu ở NHIỀU Region
• E — Dùng cross-Region read replica

Vì sao đúng

Đề yêu cầu khôi phục thảm hoạ (disaster recovery), và điểm mấu chốt là thảm hoạ có thể ở cấp Region.

Disaster recovery ≠ high availability
    High availability: chịu lỗi trong MỘT Region (Multi-AZ)
    Disaster recovery:  chịu mất CẢ MỘT REGION
        ↓
    Cả hai đáp án đều là cơ chế XUYÊN REGION

C — sao lưu tự động xuyên Region:

RDS cross-Region automated backup:
    → sao chép cả snapshot LẪN transaction log sang Region khác
    → khôi phục về bất kỳ thời điểm nào ở Region đó
        ↓
    Region chính mất hoàn toàn vẫn khôi phục được

aws rds start-db-instance-automated-backups-replication   --source-db-instance-arn <arn-db-nguon>   --backup-retention-period 14   --region us-west-2

E — cross-Region read replica:

Read replica ở Region khác:
    → sao chép LIÊN TỤC, độ trễ thường vài giây
    → promote thành database độc lập khi cần
        ↓
    RTO ngắn hơn nhiều so với khôi phục từ backup

aws rds create-db-instance-read-replica   --db-instance-identifier replica-us-west   --source-db-instance-identifier arn:aws:rds:ap-northeast-1:...:db:chinh   --region us-west-2

Hai đáp án bổ sung nhau: | | Cross-Region backup | Cross-Region read replica | |---|---|---| | RPO | tới 5 phút (với log) | vài giây | | RTO | hàng chục phút tới giờ | vài phút (promote) | | Chi phí | thấp (chỉ lưu trữ) | cao (một instance đầy đủ) | | Bảo vệ khỏi lỗi con người | ✅ khôi phục về trước sự cố | ❌ lỗi sao chép ngay sang |

Dòng cuối rất quan trọng: read replica sao chép cả lỗi — xoá nhầm bảng thì replica cũng mất bảng đó. Chỉ backup mới quay ngược thời gian được.

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

• **B. Automated backup trong Multi-AZ tạo backup trong MỘT Region — đây là phương án gần nhất và là biện pháp bảo vệ tốt, nhưng nó không đủ cho khôi phục thảm hoạ: nếu cả Region gặp sự cố thì backup cũng không truy cập được.
• **A. Đổi từ General Purpose SSD sang Provisioned IOPS — giải quyết vấn đề hiệu năng, không phải khôi phục thảm hoạ: loại lưu trữ hoàn toàn không liên quan tới việc phục hồi sau sự cố.
• **D. Dùng tính năng database cloning của Aurora — hai vấn đề: đề nói rõ đây là RDS for PostgreSQL, không phải Aurora; và cloning tạo bản sao trong CÙNG Region trên cùng bộ lưu trữ, không bảo vệ khỏi thảm hoạ Region.

Ghi nhớ

High availability và Disaster recovery — bảng phải thuộc: | | High availability | Disaster recovery | |---|---|---| | Phạm vi | trong MỘT Region | XUYÊN Region | | Cơ chế RDS | Multi-AZ | cross-Region replica, cross-Region backup | | Chống lại | hỏng phần cứng, mất một AZ | mất cả Region, lỗi con người |

Câu hỏi nói "disaster recovery" thì đáp án phải là cơ chế XUYÊN REGION.

Ba cơ chế bảo vệ dữ liệu của RDS: | Cơ chế | Việc | |---|---| | Automated backup | snapshot hằng ngày + transaction log, PITR trong 1–35 ngày | | Manual snapshot | giữ VÔ THỜI HẠN, sống sót khi xoá instance | | Read replica | mở rộng đọc và khôi phục thảm hoạ |

Điểm khác biệt quan trọng:

Xoá RDS instance
    → automated backup BỊ XOÁ THEO (trừ khi giữ final snapshot)
    → manual snapshot VẪN CÒN
        ↓
    Với dữ liệu quan trọng, luôn có manual snapshot định kỳ

Ba lưu ý về cross-Region automated backup: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ engine giới hạn | PostgreSQL, MySQL, MariaDB, Oracle, SQL Server (kiểm tra tài liệu) | | Sao chép cả snapshot lẫn log | cho PITR ở Region đích | | Cần khoá KMS ở Region đích | nếu database mã hoá |

Ba đặc điểm của cross-Region read replica: | Đặc điểm | Chi tiết | |---|---| | Sao chép BẤT ĐỒNG BỘ | có độ trễ | | Promote THỦ CÔNG | không tự chuyển vùng | | Tốn phí truyền dữ liệu xuyên Region | |

Và promote là thao tác một chiều:

aws rds promote-read-replica --db-instance-identifier replica-us-west

Sau khi promote:
    → replica thành database ĐỘC LẬP
    → KHÔNG quay lại làm replica được
        ↓
    Chỉ làm khi thật sự chuyển vùng

Multi-AZ và Read Replica — bảng nhắc lại: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | mở rộng đọc + DR | | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Chuyển đổi | TỰ ĐỘNG | thủ công | | Standby phục vụ đọc | ❌ (Multi-AZ instance) | ✅ | | Phạm vi | cùng Region | cùng hoặc khác Region |

Bốn chiến lược khôi phục thảm hoạ — bảng cần thuộc: | Chiến lược | RTO | RPO | Chi phí | |---|---|---|---| | Backup & Restore | giờ | giờ | thấp nhất | | Pilot Light | chục phút | phút | thấp | | Warm Standby | phút | giây | vừa | | Multi-Site Active/Active | gần 0 | gần 0 | cao nhất |

Cross-Region read replica tương ứng với Pilot Light hoặc Warm Standby.

Ba việc cần chuẩn bị cho DR ngoài database: | Việc | Chi tiết | |---|---| | AMI sao chép sang Region phụ | | | Hạ tầng mạng (VPC, subnet, SG) sẵn sàng | dựng bằng IaC | | DNS chuyển vùng được | Route 53 health check |

Ba lưu ý về chi phí DR: | Lưu ý | Chi tiết | |---|---| | Read replica tính phí như instance đầy đủ | | | Backup xuyên Region chỉ tính lưu trữ và truyền | rẻ hơn nhiều | | Cân nhắc replica cỡ nhỏ hơn primary | nâng cỡ khi promote |

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | DIỄN TẬP khôi phục thật | hàng quý | | Đo RTO và RPO thực tế | | | Kiểm tra ReplicaLag | liên tục |

Và một lời khuyên: hãy thực sự khôi phục một backup xuyên Region ít nhất một lần. Rất nhiều tổ chức phát hiện lúc cần dùng rằng khoá KMS không có ở Region đích, hoặc subnet group chưa được tạo — cả hai đều là việc năm phút khi bình tĩnh và là thảm hoạ khi đang mất Region chính.

Đáp án

C và E.

• C — Auto Scaling group triển khai EC2 qua nhiều AZ trong MỘT Region, đăng ký vào target group sau Application Load Balancer
• E — Chuyển MySQL sang Aurora MySQL cluster, đặt instance chính và read replica ở các AZ khác nhau

Vì sao đúng

Đề nêu hai vấn đề của kiến trúc hiện tại, và hai đáp án giải quyết đúng từng cái: | Vấn đề | Đáp án | |---|---| | Ứng dụng chạy trên MỘT EC2 — không sẵn sàng, không co giãn | C — ASG đa AZ + ALB | | Database cùng máy, cần cải thiện HIỆU NĂNG ĐỌC | E — Aurora với read replica |

C — đa AZ trong một Region là mức phù hợp:

Yêu cầu: "high availability and scalability"
    → nhiều AZ đủ đáp ứng
    → và đơn giản hơn nhiều so với đa Region
        ↓
    Đa Region chỉ cần khi yêu cầu chịu mất CẢ MỘT REGION
    → đề không nêu yêu cầu đó

E — Aurora read replica giải quyết đúng vế hiệu năng đọc:

"improve READ PERFORMANCE on the database layer"
        ↓
    Aurora replica:
        ✓ tới 15 replica
        ✓ độ trễ sao chép thường dưới 100 mili giây
        ✓ reader endpoint tự cân bằng tải
        ✓ replica cũng là mục tiêu chuyển đổi tự động

Và tách database khỏi máy chủ web là bước quan trọng nhất:

Trước: ứng dụng + MySQL trên CÙNG một EC2
    → không co giãn được tầng nào
    → máy hỏng là mất cả hai

Sau: ứng dụng trong ASG, database trong Aurora cluster
    → mỗi tầng co giãn độc lập
    → mỗi tầng có cơ chế chịu lỗi riêng

Triển khai:

aws rds create-db-cluster --db-cluster-identifier cum-ung-dung   --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.05.2   --master-username quantri --manage-master-user-password   --availability-zones ap-northeast-1a ap-northeast-1c ap-northeast-1d

aws rds create-db-instance --db-instance-identifier reader-1   --db-cluster-identifier cum-ung-dung --engine aurora-mysql   --db-instance-class db.r6g.large

Và ứng dụng dùng hai endpoint:

Ghi:  cum-ung-dung.cluster-abc.ap-northeast-1.rds.amazonaws.com
Đọc:  cum-ung-dung.cluster-ro-abc.ap-northeast-1.rds.amazonaws.com
        ↓
    Reader endpoint TỰ cân bằng qua mọi replica

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

• **A. ASG triển khai qua nhiều AZ trong HAI AWS REGION, đăng ký vào target group sau MỘT ALB — đây là phương án gần nhất và nghe có vẻ sẵn sàng hơn, nhưng nó không làm được về mặt kỹ thuật: một ASG chỉ hoạt động trong MỘT Region, và một ALB chỉ định tuyến tới target trong Region của nó.
• **B. EC2 bổ sung ở Region khác với Route 53 failover — không giải quyết vấn đề co giãn: vẫn là một máy đơn ở mỗi bên, và không cải thiện hiệu năng đọc của database.
• **D. CloudFront với Lambda@Edge phục vụ nội dung động từ EC2 ở nhiều Region — phức tạp và sai công cụ: Lambda@Edge dùng để biến đổi request và response ở biên, không phải để dựng kiến trúc sẵn sàng cao cho ứng dụng.

Ghi nhớ

Ba tầng của kiến trúc web sẵn sàng cao — bảng chuẩn: | Tầng | Cơ chế | |---|---| | Cân bằng tải | ALB (tự dư thừa qua các AZ) | | Ứng dụng | ASG qua ít nhất 2 AZ | | Dữ liệu | Aurora hoặc RDS Multi-AZ + read replica |

Đa AZ và đa Region — khi nào cần cái nào: | Yêu cầu | Mức cần | |---|---| | "High availability", "fault tolerant" | đa AZ | | "Survive a Region outage", "disaster recovery" | đa Region | | "Low latency for global users" | đa Region hoặc CloudFront |

Đa Region đắt hơn nhiều và phức tạp hơn nhiều — chỉ dùng khi đề nêu rõ yêu cầu.

Ba loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance GHI hiện tại | | Reader | cân bằng tải qua MỌI replica | | Custom | nhóm instance do bạn định nghĩa |

Custom endpoint hữu ích:

Tách báo cáo nặng khỏi truy vấn ứng dụng:
    → custom endpoint trỏ tới 2 replica cỡ lớn cho báo cáo
    → reader endpoint cho phần còn lại
        ↓
    Truy vấn báo cáo không làm chậm ứng dụng

Ba đặc điểm của Aurora khác RDS thường: | Đặc điểm | Chi tiết | |---|---| | Lưu trữ chia sẻ, tự co giãn tới 128 TB | 6 bản sao qua 3 AZ | | Tới 15 replica, độ trễ dưới 100ms | RDS MySQL chỉ 5 replica | | Chuyển đổi thường dưới 30 giây | nhanh hơn RDS Multi-AZ |

Ba cách di chuyển MySQL sang Aurora: | Cách | Đặc điểm | |---|---| | Snapshot của RDS MySQL → restore thành Aurora | đơn giản, có ngừng | | Aurora read replica của RDS MySQL → promote | ngừng rất ngắn | | AWS DMS | ngừng tối thiểu, di chuyển từ ngoài AWS |

Cách thứ hai là lựa chọn tốt nhất khi nguồn đã ở RDS:

aws rds create-db-cluster --db-cluster-identifier cum-moi   --engine aurora-mysql --replication-source-identifier <arn-rds-mysql>
# chờ đồng bộ, rồi promote

Ba cấu hình ASG quan trọng: | Cấu hình | Chi tiết | |---|---| | Trải ít nhất 2 AZ | vpc-zone-identifier nhiều subnet | | HealthCheckType = ELB | thay máy mà ứng dụng hỏng | | MinSize chịu được mất một AZ | |

Ba việc cần làm khi tách database khỏi máy ứng dụng: | Việc | Chi tiết | |---|---| | Ứng dụng phải STATELESS | phiên lưu ở ElastiCache hoặc DynamoDB | | Tệp tải lên chuyển sang S3 hoặc EFS | không lưu trên đĩa cục bộ | | Chuỗi kết nối lấy từ Secrets Manager | |

Dòng đầu là điều kiện tiên quyết cho ASG:

Ứng dụng lưu phiên trong bộ nhớ máy:
    → người dùng bị đăng xuất khi ASG thay máy
    → hoặc phải bật sticky session (giảm hiệu quả cân bằng tải)
        ↓
    Chuyển phiên ra ngoài là bước bắt buộc

Ba lưu ý về sticky session của ALB: | Lưu ý | Chi tiết | |---|---| | Là giải pháp tạm, không phải đích đến | | | Làm lệch phân phối tải | | | Máy hỏng vẫn mất phiên của người dùng đó | |

Ba biện pháp bảo mật khi tái kiến trúc: | Biện pháp | Chi tiết | |---|---| | EC2 chuyển sang PRIVATE subnet | chỉ ALB ở public | | Database trong private subnet | | | Security group tham chiếu nhau theo tầng | |

Ba lưu ý về Route 53 trong kiến trúc mới: | Lưu ý | Chi tiết | |---|---| | Dùng alias record trỏ tới ALB | miễn phí, dùng được ở zone apex | | Bật EvaluateTargetHealth | | | Không cần đổi gì thêm cho đa AZ | ALB tự lo |

Và một lời khuyên: hãy giải quyết vấn đề trạng thái của ứng dụng trước khi dựng ASG. Đưa một ứng dụng còn lưu phiên và tệp trên đĩa cục bộ vào Auto Scaling group sẽ tạo ra lỗi ngắt quãng rất khó tái hiện — người dùng bị đăng xuất ngẫu nhiên, tệp vừa tải lên biến mất — và những lỗi đó trông giống lỗi mạng hơn là lỗi kiến trúc.

Đáp án

B — Tạo bucket S3 bật Intelligent-Tiering, sửa ứng dụng để lưu và truy xuất tệp dự án qua API của Amazon S3.

Vì sao đúng

Đề cho một dữ kiện then chốt: họ SẴN SÀNG tái cấu trúc ứng dụng.

"They are OPEN TO REFACTORING the application to use managed AWS services"
        ↓
    Bỏ được ràng buộc phải dùng hệ thống tệp POSIX
    → S3 trở thành lựa chọn khả thi
        ↓
    Và S3 rẻ hơn EFS RẤT NHIỀU

So sánh giá: | Lưu trữ | Giá tham khảo | |---|---| | EFS Standard | ~0,30 USD/GB-tháng | | EFS Standard-IA | ~0,025 USD/GB-tháng + phí truy xuất | | S3 Standard | ~0,023 USD/GB-tháng | | S3 Intelligent-Tiering | ~0,023 USD/GB-tháng, tự hạ tầng, KHÔNG phí truy xuất |

Và Intelligent-Tiering đúng cho mẫu truy cập của kho lưu trữ:

Kho lưu trữ dự án thiết kế:
    → tệp mới được truy cập nhiều
    → tệp cũ hầu như không ai mở
    → nhưng KHÔNG đoán trước được tệp nào sẽ được mở lại
        ↓
    Intelligent-Tiering tự chuyển tầng theo truy cập thật
    → KHÔNG có phí truy xuất

Bốn tầng của Intelligent-Tiering: | Tầng | Chuyển sau | Giá tham khảo | |---|---|---| | Frequent Access | — | ~0,023 USD/GB | | Infrequent Access | 30 ngày | ~0,0125 USD/GB | | Archive Instant Access | 90 ngày | ~0,004 USD/GB | | Archive / Deep Archive (tuỳ chọn) | 90/180 ngày | rẻ hơn nữa |

Ba tầng đầu đều truy xuất TỨC THÌ — người dùng không cảm nhận khác biệt.

Bật:

aws s3api put-bucket-intelligent-tiering-configuration   --bucket kho-thiet-ke --id tu-phan-tang   --intelligent-tiering-configuration '{
    "Id":"tu-phan-tang","Status":"Enabled","Filter":{},
    "Tierings":[{"Days":90,"AccessTier":"ARCHIVE_ACCESS"},
                {"Days":180,"AccessTier":"DEEP_ARCHIVE_ACCESS"}]}'

Và điểm quan trọng về EFS Standard-IA mà đề đang dùng:

EFS Standard-IA có PHÍ TRUY XUẤT
    → mỗi lần nhà thiết kế mở một tệp cũ đều tốn tiền
        ↓
    Với kho lưu trữ được duyệt thường xuyên,
    phí truy xuất có thể vượt cả tiền tiết kiệm được

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

• **D. Dùng AWS Backup xuất EFS sang S3 hằng ngày, giữ EFS ở Standard-IA cho truy cập thời gian thực — đây là phương án gần nhất vì có đưa dữ liệu sang S3, nhưng nó trả tiền HAI LẦN: giữ nguyên chi phí EFS cộng thêm chi phí S3, thay vì thay thế. Và bản xuất của AWS Backup không phải kho lưu trữ để truy vấn trực tiếp.
• **A. Thay EFS bằng FSx for NetApp ONTAP với volume tiering — ONTAP đắt hơn S3 rất nhiều: nó là hệ thống tệp doanh nghiệp đầy đủ tính năng, phù hợp khi cần giao thức NFS/SMB và tính năng của ONTAP, không phải khi mục tiêu là tối ưu chi phí lưu trữ.
• **C. Thay EFS bằng FSx for Lustre — đi ngược mục tiêu: Lustre là hệ thống tệp hiệu năng cao cho HPC, đắt hơn EFS, và chỉ nằm ở một AZ.

Ghi nhớ

Chi phí lưu trữ trên AWS — bảng phải thuộc (giá tham khảo mỗi GB-tháng): | Dịch vụ | Giá | Ghi chú | |---|---|---| | S3 Glacier Deep Archive | ~0,00099 USD | rẻ nhất | | S3 Glacier Flexible | ~0,0036 USD | | | S3 Standard-IA | ~0,0125 USD | có phí truy xuất | | S3 Standard | ~0,023 USD | | | EBS gp3 | ~0,08 USD | | | EFS Standard | ~0,30 USD | đắt hơn S3 ~13 lần | | FSx for Lustre | ~0,145 USD trở lên | |

Quy tắc: nếu tái cấu trúc được, S3 gần như luôn rẻ hơn hệ thống tệp.

Ba câu hỏi quyết định giữa S3 và EFS: | Câu hỏi | Trả lời "có" thì dùng | |---|---| | Ứng dụng cần POSIX (khoá tệp, sửa tại chỗ)? | EFS | | Nhiều máy ghi cùng lúc vào cùng tệp? | EFS | | Chỉ đọc/ghi cả tệp, sửa được mã? | S3 |

Với kho lưu trữ hình ảnh, câu trả lời thường là S3.

Ba lưu ý về S3 Intelligent-Tiering: | Lưu ý | Chi tiết | |---|---| | Phí giám sát ~0,0025 USD/1.000 object | | | KHÔNG có phí truy xuất | ưu điểm lớn nhất | | Không phù hợp với hàng triệu object rất nhỏ | phí giám sát vượt tiết kiệm |

Tính điểm hoà vốn:

Phí giám sát: 0,0025 USD mỗi 1.000 object/tháng
Tiết kiệm khi xuống IA: ~0,0105 USD/GB/tháng
        ↓
    Object trung bình phải lớn hơn ~250 KB
    thì Intelligent-Tiering mới đáng
        ↓
    Ảnh độ phân giải cao (nhiều MB) → rất đáng

Ba lớp lưu trữ của EFS: | Lớp | Giá | Phí truy xuất | |---|---|---| | Standard | ~0,30 USD/GB | ❌ | | Standard-IA | ~0,025 USD/GB | ✅ ~0,01 USD/GB | | Archive | ~0,008 USD/GB | ✅ cao hơn |

Phí truy xuất là chi tiết hay bị bỏ qua khi tính toán tiết kiệm.

Ba thay đổi cần làm ở ứng dụng khi chuyển sang S3: | Thay đổi | Chi tiết | |---|---| | Đọc ghi qua SDK thay vì file system | get_object, put_object | | Dùng presigned URL cho tải lên/xuống trực tiếp | không qua máy chủ ứng dụng | | Multipart upload cho tệp lớn | ảnh độ phân giải cao |

Presigned URL là mẫu quan trọng:

url = s3.generate_presigned_url('get_object',
    Params={'Bucket': 'kho-thiet-ke', 'Key': khoa}, ExpiresIn=3600)

Nhà thiết kế tải trực tiếp từ S3
    → không đi qua EC2
    → giảm tải máy chủ và giảm phí truyền dữ liệu

Ba cách tối ưu thêm: | Cách | Lợi ích | |---|---| | CloudFront trước S3 | đệm ảnh hay xem, giảm phí egress | | S3 Transfer Acceleration | tải lên nhanh hơn từ xa | | Lifecycle cho phiên bản cũ | nếu bật versioning |

Ba lưu ý khi di chuyển dữ liệu từ EFS sang S3: | Lưu ý | Chi tiết | |---|---| | Dùng AWS DataSync | nhanh và có kiểm tra toàn vẹn | | Giữ cấu trúc thư mục thành tiền tố | du-an/2026/anh.tif | | Chạy song song một thời gian | xác nhận trước khi tắt EFS |

aws datasync create-task --source-location-arn <arn-efs>   --destination-location-arn <arn-s3>   --options VerifyMode=POINT_IN_TIME_CONSISTENT

Ba lưu ý về metadata: | Lưu ý | Chi tiết | |---|---| | RDS PostgreSQL vẫn giữ nguyên | chỉ đổi đường dẫn thành khoá S3 | | Lưu khoá S3 thay vì đường dẫn tệp | | | Cân nhắc lưu thêm ETag để kiểm tra toàn vẹn | |

Ba metric để đánh giá sau khi chuyển: | Metric | Ý nghĩa | |---|---| | Chi phí lưu trữ hằng tháng | mục tiêu chính | | Phân bố object theo tầng Intelligent-Tiering | qua Storage Lens | | Độ trễ truy xuất từ ứng dụng | xác nhận trải nghiệm không giảm |

Và một lời khuyên: hãy bật S3 Storage Lens sau khi chuyển. Nó cho biết bao nhiêu phần trăm dung lượng đã tự xuống tầng lạnh sau vài tháng — và nếu con số đó thấp hơn nhiều so với dự đoán, nghĩa là kho lưu trữ được truy cập nhiều hơn bạn tưởng, và giả định về mẫu sử dụng cần xem lại.

Đáp án

B — Dựng AMI từ EC2 hiện có, tạo launch template, dựng Auto Scaling group dùng Spot Instance, gắn Application Load Balancer phân phối lưu lượng.

Vì sao đúng

Đề cho ba đặc điểm, và cả ba dẫn thẳng tới Spot + ASG: | Đặc điểm | Kết luận | |---|---| | Ứng dụng STATELESS và CHỊU LỖI | Spot Instance dùng được | | Đỉnh tải KHÔNG ĐOÁN TRƯỚC | ASG co giãn tự động | | Không muốn cấp thừa lúc thấp điểm | trả theo nhu cầu thật |

Vế đầu là điều kiện tiên quyết cho Spot:

"designed to be STATELESS, FAULT-TOLERANT"
        ↓
    Instance bị thu hồi không gây mất dữ liệu
    → Spot hoàn toàn phù hợp
    → tiết kiệm tới 90% so với On-Demand

Và ASG + ALB giải quyết cả hai vấn đề trong đề:

Vấn đề: độ trễ và lỗi 5xx khi có đỉnh tải
    ↓
ALB: phân phối qua nhiều máy
ASG: thêm máy khi tải tăng, bớt khi giảm
        ↓
    Không còn một máy đơn làm nút thắt

Triển khai:

aws ec2 create-image --instance-id i-0abc --name "bao-cao-v1" --no-reboot

aws ec2 create-launch-template --launch-template-name lt-bao-cao   --launch-template-data '{"ImageId":"ami-0abc","InstanceType":"t3.medium"}'

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-bao-cao   --min-size 2 --desired-capacity 2 --max-size 20   --vpc-zone-identifier "subnet-a,subnet-c"   --target-group-arns <arn-tg> --health-check-type ELB   --mixed-instances-policy '{
    "LaunchTemplate":{"LaunchTemplateSpecification":{"LaunchTemplateName":"lt-bao-cao"},
      "Overrides":[{"InstanceType":"t3.medium"},{"InstanceType":"t3a.medium"},
                   {"InstanceType":"t2.medium"},{"InstanceType":"m5.large"}]},
    "InstancesDistribution":{"OnDemandBaseCapacity":2,
      "OnDemandPercentageAboveBaseCapacity":0,
      "SpotAllocationStrategy":"price-capacity-optimized"}}'

OnDemandBaseCapacity: 2 là chi tiết đáng lưu ý:

2 máy On-Demand làm nền đảm bảo
    + phần mở rộng toàn Spot
        ↓
    Ngay cả khi Spot bị thu hồi hàng loạt,
    dịch vụ vẫn còn 2 máy phục vụ

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

• **C. Nhân bản EC2 bằng AMI, chạy thêm MỘT máy On-Demand, đăng ký cả hai vào ALB — đây là phương án gần nhất và cải thiện được sẵn sàng, nhưng nó không co giãn: hai máy cố định vẫn quá tải khi có đỉnh lớn, và vẫn trả tiền đủ hai máy lúc thấp điểm.
• **A. Container hoá bằng ECS Fargate với MỘT task, đặt CloudWatch alarm để tăng CPU và bộ nhớ động — không làm được như mô tả: không thay đổi được CPU và bộ nhớ của một task Fargate đang chạy. Cách co giãn đúng của ECS là tăng số lượng task, không phải tài nguyên của một task.
• **D. EventBridge theo dõi metric, Lambda triển khai lại ứng dụng ở AZ khác khi CPU vượt 70% — hiểu sai vấn đề: CPU cao nghĩa là cần THÊM máy, không phải chuyển sang AZ khác. Và triển khai lại giữa lúc tải cao làm dịch vụ gián đoạn.

Ghi nhớ

Ba điều kiện để dùng Spot Instance: | Điều kiện | Chi tiết | |---|---| | Ứng dụng STATELESS | không giữ dữ liệu trên máy | | CHỊU ĐƯỢC gián đoạn | thông báo trước 2 phút | | Có nhiều loại instance thay thế | tăng khả năng có năng lực |

Các mô hình mua EC2 — bảng nhắc lại: | Mô hình | Tiết kiệm | Phù hợp | |---|---|---| | On-Demand | 0% | tải ngắn, không gián đoạn được | | Savings Plans | tới 72% | tải nền ổn định | | Reserved Instances | tới 72% | tải nền, loại cố định | | Spot | tới 90% | stateless, chịu lỗi ← câu này |

Mẫu kết hợp được khuyến nghị:

On-Demand hoặc Savings Plans cho phần NỀN
    + Spot cho phần ĐỈNH
        ↓
    Cân bằng giữa tin cậy và chi phí

Ba cơ chế xử lý thu hồi Spot: | Cơ chế | Chi tiết | |---|---| | Thông báo trước 2 phút | qua metadata /spot/instance-action | | Rebalance recommendation | cảnh báo SỚM HƠN 2 phút | | Capacity Rebalancing của ASG | tự thay máy trước khi bị thu hồi |

aws autoscaling create-auto-scaling-group ... --capacity-rebalance

Ba chiến lược phân bổ Spot: | Chiến lược | Đặc điểm | |---|---| | price-capacity-optimized | cân bằng giá và ổn định — khuyến nghị | | capacity-optimized | ưu tiên ít bị thu hồi nhất | | lowest-price | rẻ nhất nhưng hay bị thu hồi |

Ba yếu tố tăng khả năng có Spot: | Yếu tố | Chi tiết | |---|---| | Nhiều loại instance | quan trọng nhất — ít nhất 4 loại | | Nhiều AZ | nhiều nguồn năng lực | | Linh hoạt về thế hệ và cỡ | |

Ba loại scaling policy: | Loại | Khi nào | |---|---| | Target tracking | đơn giản nhất, giữ metric ở mức mục tiêu | | Step scaling | kiểm soát chi tiết | | Predictive scaling | tải có chu kỳ |

Target tracking theo request là lựa chọn tốt cho web:

aws autoscaling put-scaling-policy --auto-scaling-group-name asg-bao-cao   --policy-name theo-request --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 1000,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "<app/alb/id>/<targetgroup/tg/id>"}}'

Số request mỗi target phản ánh tải chính xác hơn CPU với ứng dụng web.

Ba cấu hình ASG quan trọng: | Cấu hình | Chi tiết | |---|---| | HealthCheckType = ELB | thay máy mà ứng dụng hỏng | | HealthCheckGracePeriod | đủ dài cho khởi động | | EstimatedInstanceWarmup | tránh mở rộng quá mức |

Ba lưu ý về golden AMI: | Lưu ý | Chi tiết | |---|---| | Nướng phần ổn định vào AMI | rút ngắn thời gian khởi động | | Phần thay đổi để trong user data | | | Dùng SSM Parameter trỏ tới AMI mới nhất | |

Ba lưu ý về ứng dụng stateless: | Lưu ý | Chi tiết | |---|---| | Phiên lưu ngoài máy | ElastiCache hoặc DynamoDB | | Tệp tải lên vào S3 | | | Log gửi lên CloudWatch Logs | máy bị thu hồi là mất log cục bộ |

Dòng cuối đặc biệt quan trọng với Spot:

Máy Spot bị thu hồi
    → log trên đĩa MẤT THEO
    → không gỡ lỗi được sự cố vừa xảy ra
        ↓
    CloudWatch agent gửi log ra ngoài là bắt buộc

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TargetResponseTime của ALB | độ trễ người dùng cảm nhận | | HTTPCode_Target_5XX_Count | đúng lỗi đề nêu | | GroupInServiceInstances | số máy đang phục vụ |

Và một lời khuyên: hãy giữ ít nhất hai máy On-Demand làm nền thay vì chạy hoàn toàn bằng Spot. Đợt thiếu năng lực Spot ở một Region có thể thu hồi toàn bộ đội máy trong vài phút — và với ứng dụng phục vụ tin tức y tế trong lúc có sự kiện lớn, đó chính là thời điểm bạn ít có thể chấp nhận việc mất toàn bộ năng lực nhất.

Đáp án

B — Dùng Amazon Transcribe chuyển âm thanh thành văn bản và Amazon Athena chạy truy vấn SQL để phân tích cảm xúc khách hàng.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi yêu cầu có dịch vụ đúng: | Yêu cầu | Dịch vụ | |---|---| | Chuyển ghi âm cuộc gọi thành văn bản | Amazon Transcribe | | Phân tích bằng truy vấn SQL ĐẶC BIỆT (ad-hoc) | Amazon Athena |

Amazon Transcribe là dịch vụ chuyển giọng nói thành văn bản của AWS:

Amazon Transcribe:
    ✓ nhận diện giọng nói tự động (ASR)
    ✓ hỗ trợ nhiều ngôn ngữ
    ✓ TÁCH NGƯỜI NÓI (speaker diarization) — phân biệt
      nhân viên và khách hàng
    ✓ có bản chuyên cho tổng đài: Transcribe Call Analytics

Và Athena là công cụ đúng cho "ad-hoc SQL":

Amazon Athena:
    ✓ SQL trực tiếp trên tệp ở S3
    ✓ KHÔNG cần nạp vào database
    ✓ KHÔNG có hạ tầng để quản lý
    ✓ trả tiền theo lượng dữ liệu quét
        ↓
    Đúng "ad-hoc SQL queries"

Đường ống hoàn chỉnh:

Tệp ghi âm → S3
    ↓ Transcribe (bất đồng bộ)
Văn bản JSON → S3
    ↓ Comprehend (phân tích cảm xúc)
Kết quả có nhãn cảm xúc → S3
    ↓
Athena: SELECT ... WHERE sentiment = 'NEGATIVE'

Gọi Transcribe:

aws transcribe start-transcription-job   --transcription-job-name cuoc-goi-001   --media MediaFileUri=s3://ghi-am/cuoc-goi-001.mp3   --language-code vi-VN   --output-bucket-name van-ban-cuoc-goi   --settings ShowSpeakerLabels=true,MaxSpeakerLabels=2

Và Transcribe Call Analytics làm sẵn phần cảm xúc:

aws transcribe start-call-analytics-job   --call-analytics-job-name phan-tich-001   --media MediaFileUri=s3://ghi-am/cuoc-goi-001.mp3   --data-access-role-arn <arn-role>   --output-location s3://ket-qua/

Call Analytics trả về sẵn:
    ✓ cảm xúc theo từng đoạn
    ✓ thời gian nói của mỗi bên
    ✓ khoảng im lặng
    ✓ từ khoá và chủ đề
        ↓
    Không cần gọi Comprehend riêng

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

• **D. Transcribe chuyển âm thanh thành văn bản, dùng QuickSight thực hiện phân tích SQL — đây là phương án gần nhất và đúng hoàn toàn ở vế Transcribe, nhưng nó sai vai trò của QuickSight: QuickSight là công cụ trực quan hoá, không phải công cụ truy vấn SQL đặc biệt. Nó kết nối tới nguồn dữ liệu (thường là chính Athena) để vẽ biểu đồ.
• **A. Kinesis Data Streams đọc tệp âm thanh, Amazon Alexa chuyển thành văn bản — Alexa KHÔNG phải dịch vụ chuyển giọng nói thành văn bản cho nhà phát triển: nó là trợ lý ảo. Dịch vụ đúng là Transcribe.
• **C. Kinesis Data Streams đọc tệp âm thanh, tự viết thuật toán học máy chuyển đổi — công sức khổng lồ không cần thiết: xây mô hình nhận diện giọng nói từ đầu là dự án nhiều tháng, trong khi Transcribe cho kết quả ngay.

Ghi nhớ

Các dịch vụ AI/ML của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Amazon Transcribe | giọng nói → VĂN BẢN | | Amazon Polly | văn bản → GIỌNG NÓI | | Amazon Translate | dịch giữa các ngôn ngữ | | Amazon Comprehend | phân tích văn bản: cảm xúc, thực thể, PII | | Amazon Rekognition | phân tích ảnh và video | | Amazon Textract | trích xuất chữ và bảng từ tài liệu quét | | Amazon Lex | chatbot | | Amazon Kendra | tìm kiếm doanh nghiệp bằng ngôn ngữ tự nhiên | | Amazon Personalize | gợi ý cá nhân hoá | | Amazon Forecast | dự báo chuỗi thời gian |

Bảng này bị hỏi rất nhiều — nên thuộc lòng.

Từ khoá nhận diện:

"audio to text", "call recordings" → Transcribe "sentiment analysis", "extract entities from text" → Comprehend "text to speech" → Polly "scanned documents, forms, tables" → Textract "images, faces, objects" → Rekognition

Ba tính năng của Amazon Transcribe: | Tính năng | Chi tiết | |---|---| | Speaker diarization | phân biệt ai đang nói | | Custom vocabulary | thuật ngữ riêng của ngành | | Automatic content redaction | tự che số thẻ, thông tin cá nhân |

Tính năng cuối rất quan trọng với tổng đài:

Khách hàng đọc số thẻ tín dụng qua điện thoại
    → bản ghi âm và văn bản chứa dữ liệu nhạy cảm
        ↓
    Transcribe tự che thành [PII]
    → tuân thủ PCI DSS

Ba tính năng của Amazon Comprehend: | Tính năng | Việc | |---|---| | Sentiment | tích cực, tiêu cực, trung tính, lẫn lộn | | Entity recognition | tên người, địa điểm, tổ chức | | PII detection | phát hiện thông tin cá nhân | | Topic modeling | chủ đề trong tập tài liệu |

Ba đặc điểm của Amazon Athena: | Đặc điểm | Chi tiết | |---|---| | Serverless hoàn toàn | không có cụm nào | | Trả tiền theo dữ liệu QUÉT | ~5 USD mỗi TB | | Dùng AWS Glue Data Catalog | định nghĩa schema |

Ba cách giảm chi phí Athena — rất đáng nhớ: | Cách | Tiết kiệm | |---|---| | Dùng định dạng cột (Parquet, ORC) | tới 90% | | Phân vùng theo ngày hoặc chiều hay lọc | rất nhiều | | Nén dữ liệu | |

CREATE EXTERNAL TABLE cuoc_goi (
  ma_cuoc_goi string, van_ban string, cam_xuc string)
PARTITIONED BY (nam int, thang int)
STORED AS PARQUET
LOCATION 's3://van-ban-cuoc-goi/';

Phân vùng khiến truy vấn "tháng này" chỉ quét dữ liệu tháng này.

Ba lựa chọn phân tích dữ liệu trên S3: | Lựa chọn | Phù hợp | |---|---| | Athena | SQL đặc biệt, không thường xuyên ← câu này | | Redshift Spectrum | đã có cụm Redshift | | EMR (Spark) | biến đổi phức tạp, quy mô lớn |

Ba dịch vụ tổng đài trên AWS: | Dịch vụ | Việc | |---|---| | Amazon Connect | tổng đài đám mây đầy đủ | | Contact Lens for Amazon Connect | phân tích cuộc gọi TỰ ĐỘNG, dựng sẵn | | Transcribe Call Analytics | phân tích cuộc gọi từ nguồn bất kỳ |

Nếu công ty chuyển hẳn tổng đài lên AWS:

Amazon Connect + Contact Lens:
    ✓ ghi âm, chuyển văn bản, phân tích cảm xúc — TỰ ĐỘNG
    ✓ cảnh báo thời gian thực khi cuộc gọi chuyển hướng xấu
    ✓ không phải dựng đường ống nào
        ↓
    Đây là giải pháp trọn gói cho bài toán trong đề

Ba lưu ý về chi phí: | Dịch vụ | Giá tham khảo | |---|---| | Transcribe | ~0,024 USD/phút âm thanh | | Comprehend sentiment | ~0,0001 USD mỗi đơn vị 100 ký tự | | Athena | ~5 USD/TB quét |

Ba lưu ý về quyền riêng tư: | Lưu ý | Chi tiết | |---|---| | Thông báo cho khách hàng về việc ghi âm | yêu cầu pháp lý ở nhiều nơi | | Bật content redaction của Transcribe | | | Mã hoá tệp âm thanh và văn bản trong S3 | |

Và một lời khuyên: hãy xem xét Amazon Connect với Contact Lens trước khi tự dựng đường ống. Nếu công ty đằng nào cũng đang cân nhắc chuyển tổng đài lên đám mây, Contact Lens làm sẵn toàn bộ chuỗi chuyển văn bản và phân tích cảm xúc — và có thêm cảnh báo thời gian thực, thứ mà một đường ống xử lý theo lô không bao giờ cho được.

Đáp án

B và D.

• B — Cấu hình S3 chấp nhận tải lên từ CloudFront bằng Origin Access Control (OAC)
• D — Xin chứng chỉ công khai từ ACM ở Region us-east-1 và gắn vào CloudFront distribution

Vì sao đúng

D — chứng chỉ cho CloudFront BẮT BUỘC ở us-east-1:

CloudFront là dịch vụ TOÀN CẦU
    → nhưng nó chỉ đọc chứng chỉ ACM từ MỘT Region: us-east-1
        ↓
    Chứng chỉ xin ở eu-west-2 (nơi có bucket)
    → KHÔNG hiện ra trong danh sách chọn của CloudFront

Đây là một trong những chi tiết bị hỏi nhiều nhất về CloudFront.

aws acm request-certificate --region us-east-1   --domain-name tai-len.example.com   --validation-method DNS

B — Origin Access Control là cơ chế hiện tại:

OAC:
    ✓ CloudFront ký request bằng SigV4 khi gọi S3
    ✓ bucket giữ Block Public Access, chỉ cho phép CloudFront
    ✓ HỖ TRỢ cả GET lẫn PUT/POST (tải lên)
    ✓ hỗ trợ SSE-KMS
    ✓ hoạt động ở MỌI Region

Cấu hình OAC:

aws cloudfront create-origin-access-control   --origin-access-control-config '{
    "Name":"oac-tai-len","OriginAccessControlOriginType":"s3",
    "SigningBehavior":"always","SigningProtocol":"sigv4"}'

Và bucket policy tương ứng:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::kho-anh/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1ABC"}}}

Lưu ý cần cả s3:PutObject vì đề yêu cầu TẢI LÊN qua CloudFront.

Và phải bật phương thức HTTP cho tải lên:

--allowed-methods GET,HEAD,OPTIONS,PUT,POST,PATCH,DELETE

Mặc định CloudFront chỉ cho GET và HEAD — thiếu bước này thì tải lên trả về 403.

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

• **E. Xin chứng chỉ ACM ở Region eu-west-2 và gắn vào CloudFront — đây là phương án gần nhất và chỉ khác D đúng một chữ, nhưng đó là chữ quyết định: CloudFront chỉ nhận chứng chỉ từ us-east-1.
• **A. Dùng S3 static website endpoint làm origin và bật tải lên — static website endpoint chỉ hỗ trợ GET: nó không nhận PUT/POST, nên không tải lên được. Và nó chỉ chạy HTTP, không có HTTPS giữa CloudFront và origin.
• **C. Origin request policy chuyển mọi header và query string, bật S3 Object Ownership để CloudFront kiểm soát tệp qua signed URL — hỗn hợp các khái niệm không liên quan: chuyển mọi header phá hỏng việc đệm, và Object Ownership là cấu hình về quyền sở hữu object trong tài khoản, không liên quan tới CloudFront.

Ghi nhớ

Ba dịch vụ đọc chứng chỉ ACM từ us-east-1 — bảng phải thuộc: | Dịch vụ | Region chứng chỉ | |---|---| | CloudFront | BẮT BUỘC us-east-1 | | API Gateway edge-optimized | BẮT BUỘC us-east-1 | | ALB, NLB | CÙNG Region với load balancer | | API Gateway regional | cùng Region |

Origin Access Control và Origin Access Identity — bảng phân biệt: | | OAC (hiện tại) | OAI (cũ) | |---|---|---| | Hỗ trợ SSE-KMS | ✅ | ❌ | | Hỗ trợ PUT/POST | ✅ | ❌ chỉ GET | | Mọi Region | ✅ | hạn chế ở Region mới | | Trạng thái | khuyến nghị | legacy |

AWS đã thay OAI bằng OAC từ tháng 8/2022 — mọi thiết kế mới nên dùng OAC.

Ba loại origin của CloudFront với S3: | Loại | Đặc điểm | |---|---| | S3 REST endpoint + OAC | bucket riêng tư, đầy đủ tính năng ← câu này | | S3 static website endpoint | CHỈ GET, chỉ HTTP, bucket phải công khai | | S3 qua VPC origin | mới, cho origin trong VPC |

Ba bước để tải lên qua CloudFront hoạt động: | Bước | Chi tiết | |---|---| | Bật phương thức PUT/POST trong cache behavior | | | OAC với SigningBehavior: always | | | Bucket policy cho phép s3:PutObject | |

Và cân nhắc presigned URL thay vì tải qua CloudFront:

Tải lên trực tiếp lên S3 bằng presigned URL:
    ✓ đơn giản hơn
    ✓ không tốn phí CloudFront
    ✗ không tận dụng mạng biên của AWS
        ↓
    Với tệp lớn và người dùng ở xa,
    tải qua CloudFront (hoặc S3 Transfer Acceleration) nhanh hơn

Ba lưu ý về caching với PUT/POST: | Lưu ý | Chi tiết | |---|---| | CloudFront KHÔNG đệm phản hồi PUT/POST | | | Nên tách cache behavior riêng cho đường dẫn tải lên | | | Đặt cache policy CachingDisabled cho đường dẫn đó | |

# Behavior /tai-len/* : không đệm, cho PUT
# Behavior mặc định   : đệm, chỉ GET

Ba chính sách dựng sẵn của CloudFront: | Chính sách | Việc | |---|---| | CachingOptimized | đệm tối đa, bỏ hầu hết header | | CachingDisabled | không đệm — cho tải lên và API | | AllViewerExceptHostHeader | chuyển mọi thứ trừ Host |

Ba lưu ý về tên miền tuỳ chỉnh: | Lưu ý | Chi tiết | |---|---| | Khai trong Aliases của distribution | | | Chứng chỉ phải bao gồm tên miền đó | | | Route 53 alias record trỏ tới distribution | |

aws cloudfront update-distribution --id E1ABC   --distribution-config '{"Aliases":{"Quantity":1,
    "Items":["tai-len.example.com"]}, ...}'

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ công khai MIỄN PHÍ | | | Xác thực DNS tự gia hạn | khuyến nghị hơn email | | Chứng chỉ đại diện *.example.com KHÔNG bao gồm example.com | phải thêm vào SAN |

Ba biện pháp bảo mật cho luồng tải lên: | Biện pháp | Chi tiết | |---|---| | CloudFront signed URL hoặc signed cookie | chỉ người được cấp mới tải lên được | | AWS WAF trên distribution | chặn tải lên độc hại | | Giới hạn kích thước tệp | ở tầng ứng dụng |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | 4xxErrorRate | thường là quyền hoặc phương thức chưa bật | | 5xxErrorRate | origin có vấn đề | | BytesUploaded | lượng tải lên |

Và một lời khuyên: hãy kiểm tra danh sách phương thức HTTP trong cache behavior nếu tải lên qua CloudFront trả về 403. Đó là nguyên nhân phổ biến nhất và cũng khó đoán nhất — bucket policy đúng, OAC đúng, chứng chỉ đúng, mà CloudFront vẫn từ chối vì mặc định nó chỉ được phép chuyển tiếp GET và HEAD.

Đáp án

A — Dựng HAI hàng đợi SQS tách rời hai giai đoạn: một hàng đợi nhận việc đến, một hàng đợi chờ xử lý; EC2 lấy việc từ hàng đợi tương ứng; co giãn ASG theo SỐ THÔNG ĐIỆP trong mỗi hàng đợi.

Vì sao đúng

Đề nêu ba vấn đề, và phương án A giải quyết cả ba: | Vấn đề | Cơ chế | |---|---| | Giai đoạn xử lý tụt lại giờ cao điểm | hàng đợi đệm, không mất việc | | Lo mất việc khi instance bị chấm dứt | SQS giữ thông điệp tới khi xử lý xong | | Hai giai đoạn có tốc độ khác nhau | HAI hàng đợi riêng, co giãn ĐỘC LẬP |

Vì sao phải là HAI hàng đợi:

Giai đoạn 1: nhận việc NHANH
Giai đoạn 2: xử lý CHẬM
        ↓
    Hai tốc độ khác nhau → hai độ sâu hàng đợi khác nhau
    → hai chính sách co giãn khác nhau
        ↓
    Một hàng đợi chung thì không phân biệt được
    việc nào thuộc giai đoạn nào

Và SQS bảo vệ việc khỏi bị mất:

Instance bị chấm dứt giữa lúc xử lý:
    → thông điệp KHÔNG bị xoá (chỉ xoá sau khi xong)
    → hết visibility timeout → thông điệp HIỆN LẠI
    → instance khác nhận và làm lại
        ↓
    Không mất việc nào

Co giãn theo độ dài hàng đợi:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-xu-ly   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 10,
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS", "Statistic": "Average",
      "Dimensions": [{"Name":"QueueName","Value":"hang-doi-xu-ly"}]}}'

Và metric tốt hơn là "số thông điệp trên mỗi instance":

Backlog per instance = số thông điệp ÷ số instance đang chạy
    → mục tiêu: mỗi instance có khoảng N việc chờ
        ↓
    Đây là cách AWS khuyến nghị chính thức

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

• **D. Hai hàng đợi SQS, nhưng co giãn ASG theo THÔNG BÁO (notification) từ mỗi hàng đợi — đây là phương án gần nhất và đúng hoàn toàn ở phần kiến trúc, nhưng nó sai ở cơ chế co giãn: SQS không phát ra thông báo để kích hoạt Auto Scaling. Co giãn dựa trên metric CloudWatch (ApproximateNumberOfMessagesVisible), không phải notification.
• **C. MỘT hàng đợi chung cho cả hai giai đoạn — không tách được hai tốc độ: mọi instance lấy chung một hàng đợi thì không phân biệt được việc nhận và việc xử lý, và không co giãn riêng từng giai đoạn được.
• **B. Giữ dung lượng tối thiểu bằng đỉnh tải suốt giờ cao điểm, theo dõi CPU — lãng phí và vẫn mất việc: trả tiền cho năng lực không dùng, và không có hàng đợi nào bảo vệ việc khi instance bị chấm dứt.

Ghi nhớ

Ba lợi ích của việc tách rời bằng SQS: | Lợi ích | Chi tiết | |---|---| | Đệm khi tải tăng đột ngột | producer không bị chặn | | KHÔNG mất việc khi consumer hỏng | ← vấn đề chính trong đề | | Hai bên co giãn ĐỘC LẬP | |

Ba metric của SQS để co giãn — bảng cần biết: | Metric | Dùng cho | |---|---| | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | ApproximateAgeOfOldestMessage | việc chờ quá lâu — chỉ báo tốt nhất về trải nghiệm | | NumberOfMessagesSent/Received | thông lượng |

Metric thứ hai đáng dùng làm cảnh báo:

Số thông điệp có thể lớn mà vẫn ổn nếu xử lý nhanh
    → nhưng "thông điệp cũ nhất đã chờ 30 phút"
      luôn là dấu hiệu có vấn đề
        ↓
    Đặt alarm cho ApproximateAgeOfOldestMessage

Công thức backlog per instance của AWS:

Backlog per instance = ApproximateNumberOfMessagesVisible ÷ số instance
Mục tiêu = (thời gian chấp nhận được) ÷ (thời gian xử lý mỗi việc)

Ví dụ: chấp nhận chờ 10 phút, mỗi việc mất 30 giây
    → mục tiêu = 600 ÷ 30 = 20 việc mỗi instance

Ba thông số quan trọng của SQS: | Thông số | Mặc định | Ghi chú | |---|---|---| | Visibility timeout | 30 giây | phải ≥ thời gian xử lý dài nhất | | Message retention | 4 ngày | tối đa 14 ngày | | Receive wait time | 0 | đặt 20 để dùng long polling |

Visibility timeout sai gây xử lý trùng:

Xử lý mất 10 phút, visibility timeout 30 giây
    → thông điệp hiện lại sau 30 giây
    → instance khác nhận và làm lại
        ↓
    Cùng một việc được xử lý nhiều lần song song

Và với việc xử lý dài, dùng heartbeat:

while dang_xu_ly:
    sqs.change_message_visibility(
        QueueUrl=url, ReceiptHandle=rh, VisibilityTimeout=300)
    time.sleep(240)

Gia hạn định kỳ thay vì đặt timeout rất dài ngay từ đầu.

Hai loại hàng đợi SQS: | | Standard | FIFO | |---|---|---| | Thứ tự | không đảm bảo | đảm bảo trong group | | Trùng lặp | có thể | xử lý đúng một lần | | Thông lượng | gần như vô hạn | 300/3.000 msg/giây, high throughput ~70.000 |

Ba yêu cầu với consumer khi dùng SQS Standard: | Yêu cầu | Chi tiết | |---|---| | IDEMPOTENT | xử lý trùng không gây hậu quả | | Chỉ xoá thông điệp SAU KHI xong | | | Xử lý được lỗi và có DLQ | |

Ba cấu hình ASG cho consumer: | Cấu hình | Chi tiết | |---|---| | Lifecycle hook TERMINATING | cho phép hoàn tất việc đang xử lý trước khi tắt | | MinSize đủ để không bao giờ trống | | | Scale in bảo vệ instance đang bận | instance scale-in protection |

Lifecycle hook giải quyết đúng nỗi lo trong đề:

aws autoscaling put-lifecycle-hook   --auto-scaling-group-name asg-xu-ly   --lifecycle-hook-name cho-xong-viec   --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING   --heartbeat-timeout 600

Instance nhận tín hiệu sắp bị chấm dứt
    → ngừng lấy việc mới
    → hoàn tất việc đang xử lý
    → gọi complete-lifecycle-action
        ↓
    Không có việc nào bị bỏ dở

Ba mẫu kiến trúc tách rời: | Mẫu | Dịch vụ | |---|---| | Hàng đợi điểm-tới-điểm | SQS ← câu này | | Phát tán một-tới-nhiều | SNS, EventBridge | | Luồng có thứ tự, phát lại được | Kinesis, MSK |

Ba lựa chọn thay thế cho ASG + SQS: | Lựa chọn | Đặc điểm | |---|---| | AWS Batch | tự quản hàng đợi công việc và năng lực | | Lambda từ SQS | không quản máy, giới hạn 15 phút | | ECS/Fargate với co giãn theo SQS | container |

Ba lưu ý về DLQ: | Lưu ý | Chi tiết | |---|---| | maxReceiveCount 3–5 | | | DLQ giữ lâu hơn hàng đợi chính | | | ĐẶT ALARM cho DLQ | không có alarm thì DLQ vô dụng |

Và một lời khuyên: hãy dùng ApproximateAgeOfOldestMessage làm chỉ số sức khoẻ chính thay vì số lượng thông điệp. Một hàng đợi có 10.000 việc mà xử lý xong trong hai phút là hoàn toàn bình thường, còn một hàng đợi có 5 việc mà việc cũ nhất đã chờ một giờ là dấu hiệu consumer đã chết — và chỉ metric thứ hai phân biệt được hai tình huống đó.

Đáp án

A — Dùng AWS Site-to-Site VPN để thiết lập kết nối mạng mã hoá giữa trung tâm dữ liệu tại chỗ và AWS.

Vì sao đúng

Đề nêu hai yêu cầu, và Site-to-Site VPN đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Dựng NHANH NHẤT có thể | vài giờ — chỉ cần cấu hình | | Mã hoá trên đường truyền | IPsec, mã hoá SẴN CÓ |

Vế thứ nhất là điểm phân biệt quyết định:

Site-to-Site VPN:
    → dùng đường Internet có sẵn
    → cấu hình xong trong VÀI GIỜ
        ↓
Direct Connect:
    → cần kéo đường vật lý
    → mất VÀI TUẦN tới VÀI THÁNG

Và vế thứ hai cũng quan trọng không kém:

Site-to-Site VPN dùng IPsec
    → mã hoá là ĐẶC TÍNH GỐC của giao thức
    → không phải bật thêm gì
        ↓
Direct Connect KHÔNG mã hoá theo mặc định
    → là đường riêng, nhưng dữ liệu đi ở dạng KHÔNG mã hoá

Đây là hiểu lầm phổ biến: "đường riêng" không đồng nghĩa với "được mã hoá".

Triển khai:

aws ec2 create-customer-gateway --type ipsec.1   --public-ip 203.0.113.10 --bgp-asn 65000

aws ec2 create-vpn-gateway --type ipsec.1
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-abc --vpc-id vpc-abc

aws ec2 create-vpn-connection --type ipsec.1   --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc   --options TunnelOptions='[{},{}]'

Và mỗi kết nối VPN có HAI đường hầm:

AWS tự tạo 2 tunnel ở 2 endpoint khác nhau
    → dư thừa sẵn có
    → nhưng thiết bị tại chỗ phải cấu hình CẢ HAI
        ↓
    Chỉ cấu hình một tunnel là mất dư thừa

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

• **B. Dùng AWS Direct Connect — đây là phương án gần nhất và là kết nối riêng tốt nhất về băng thông và độ ổn định, nhưng nó sai ở CẢ HAI yêu cầu: mất hàng tuần tới hàng tháng để thiết lập, và không mã hoá theo mặc định.
• **D. Dùng AWS DataSync — sai loại dịch vụ: DataSync là công cụ di chuyển dữ liệu, không phải giải pháp kết nối mạng. Nó chạy trên một kết nối đã có.
• **C. Dùng AWS Secrets Manager — hoàn toàn không liên quan: Secrets Manager lưu và xoay vòng thông tin bí mật như mật khẩu database.

Ghi nhớ

Ba cách kết nối on-premises với AWS — bảng phải thuộc: | Cách | Thời gian dựng | Mã hoá mặc định | Băng thông | |---|---|---|---| | Site-to-Site VPN | vài GIỜ | ✅ IPsec | tới ~1,25 Gbps mỗi tunnel | | Direct Connect | vài TUẦN–THÁNG | ❌ | 1–400 Gbps, ổn định | | Direct Connect + VPN | như DX | ✅ | như DX |

Từ khoá nhận diện — rất hay được hỏi:

"fastest to set up", "encrypted", "quickly" → Site-to-Site VPN "consistent bandwidth", "low jitter", "large data transfer" → Direct Connect "private AND encrypted", "compliance" → Direct Connect + VPN qua nó

Mẫu kết hợp đáng nhớ:

Direct Connect cho băng thông ổn định
    + IPsec VPN chạy TRÊN Direct Connect
        ↓
    Vừa riêng tư, vừa mã hoá, vừa ổn định
    → đây là kiến trúc doanh nghiệp phổ biến

Ba thành phần của Site-to-Site VPN: | Thành phần | Việc | |---|---| | Customer Gateway | đại diện thiết bị TẠI CHỖ | | Virtual Private Gateway (VGW) | phía AWS, gắn vào một VPC | | Transit Gateway | thay VGW khi cần nối NHIỀU VPC |

Với nhiều VPC, Transit Gateway là lựa chọn đúng:

VGW: một VPN cho MỘT VPC
Transit Gateway: một VPN cho MỌI VPC gắn vào
        ↓
    Ít kết nối VPN hơn, dễ quản lý hơn

Ba đặc điểm của Site-to-Site VPN: | Đặc điểm | Chi tiết | |---|---| | Hai tunnel mỗi kết nối | dư thừa | | Băng thông tối đa ~1,25 Gbps mỗi tunnel | | | Đi qua Internet công cộng | độ trễ biến động |

Dòng cuối là hạn chế chính:

VPN đi qua Internet
    → độ trễ và mất gói phụ thuộc chất lượng đường
    → không đảm bảo được như Direct Connect
        ↓
    Với tải nhạy độ trễ, Direct Connect vẫn cần

Ba cách tăng băng thông VPN: | Cách | Chi tiết | |---|---| | Nhiều kết nối VPN + ECMP | qua Transit Gateway | | Accelerated Site-to-Site VPN | qua mạng Global Accelerator | | Chuyển sang Direct Connect | |

Accelerated VPN đáng biết:

Lưu lượng vào mạng riêng của AWS ở edge gần nhất
    → giảm số chặng qua Internet công cộng
    → độ trễ ổn định hơn

Ba loại Direct Connect virtual interface: | Loại | Truy cập | |---|---| | Private VIF | VPC qua IP riêng | | Public VIF | dịch vụ AWS công cộng (S3, DynamoDB) | | Transit VIF | qua Transit Gateway |

Ba lưu ý về định tuyến: | Lưu ý | Chi tiết | |---|---| | BGP động được khuyến nghị | tự thích ứng khi tunnel hỏng | | Static route đơn giản hơn nhưng cứng nhắc | | | Bật route propagation trong route table | |

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

Quên bước này là VPN lên nhưng không có lưu lượng nào đi qua.

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | VPN connection | ~0,05 USD/giờ (~36 USD/tháng) | | Truyền dữ liệu ra | theo GB | | Direct Connect port | cao hơn nhiều, cộng phí cổng |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TunnelState | 0 = DOWN, 1 = UP | | TunnelDataIn/Out | lưu lượng | | — | đặt alarm khi một tunnel xuống |

aws cloudwatch put-metric-alarm --alarm-name tunnel-vpn-xuong   --metric-name TunnelState --namespace AWS/VPN   --dimensions Name=VpnId,Value=vpn-abc   --statistic Maximum --period 300 --threshold 1   --comparison-operator LessThanThreshold

Ba lưu ý khi cấu hình thiết bị tại chỗ: | Lưu ý | Chi tiết | |---|---| | AWS cung cấp file cấu hình mẫu | cho nhiều hãng thiết bị | | Cấu hình CẢ HAI tunnel | | | Kiểm tra MTU và MSS clamping | tránh phân mảnh gói |

Và một lời khuyên: hãy dựng Site-to-Site VPN ngay cả khi đang chờ Direct Connect. Nó lên trong vài giờ, cho phép bắt đầu công việc luôn, và sau này trở thành đường dự phòng cho Direct Connect — một kết nối riêng không có đường dự phòng là điểm hỏng đơn ở đúng chỗ tệ nhất.

Đáp án

C — Đặt CloudWatch alarm theo dõi trạng thái sức khoẻ của instance; khi Instance Health Check thất bại, dùng EC2 Reboot alarm action để khởi động lại instance.

Vì sao đúng

Đề hỏi cách tối ưu chi phí và tiết kiệm tài nguyên nhất, và CloudWatch alarm action là cơ chế dựng sẵn.

CloudWatch alarm hỗ trợ bốn hành động EC2 DỰNG SẴN:
    ✓ Stop
    ✓ Terminate
    ✓ Reboot     ← đúng nhu cầu
    ✓ Recover
        ↓
    KHÔNG cần Lambda, KHÔNG cần SNS, KHÔNG cần mã nào

Cấu hình:

aws cloudwatch put-metric-alarm   --alarm-name khoi-dong-lai-khi-treo   --metric-name StatusCheckFailed_Instance   --namespace AWS/EC2   --dimensions Name=InstanceId,Value=i-0abc123   --statistic Maximum --period 60 --evaluation-periods 2   --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold   --alarm-actions arn:aws:automate:ap-northeast-1:ec2:reboot

arn:aws:automate:<region>:ec2:reboot là ARN đặc biệt — không phải tài nguyên bạn tạo, mà là hành động dựng sẵn của CloudWatch.

Và so sánh chi phí: | Cách | Chi phí | |---|---| | CloudWatch alarm action | chỉ phí alarm ~0,10 USD/tháng | | Alarm → SNS → Lambda | thêm phí SNS và Lambda | | EventBridge → Lambda mỗi 5 phút | 8.640 lần gọi/tháng dù không có sự cố |

Và về mặt phản ứng:

Alarm action: kích hoạt NGAY khi metric vượt ngưỡng
Lambda theo lịch 5 phút: chờ tới lần kiểm tra tiếp theo
        ↓
    Instance có thể treo tới 5 phút trước khi được xử lý

Ba loại status check của EC2 — bảng quan trọng: | Loại | Kiểm tra | Cách khắc phục | |---|---|---| | StatusCheckFailed_Instance | hệ điều hành / phần mềm | REBOOT ← câu này | | StatusCheckFailed_System | hạ tầng AWS bên dưới | RECOVER hoặc stop/start | | StatusCheckFailed_AttachedEBS | volume EBS | kiểm tra volume |

Ứng dụng treo là lỗi ở tầng hệ điều hành → dùng metric Instance và hành động Reboot.

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

• **A. CloudWatch alarm → SNS → Lambda → Lambda gọi EC2 API để reboot — đây là phương án gần nhất và hoạt động được, nhưng nó thêm hai dịch vụ không cần thiết: CloudWatch có sẵn hành động reboot. Thêm SNS và Lambda nghĩa là thêm chi phí, thêm quyền IAM phải quản lý, và thêm chỗ có thể hỏng.
• **B. EventBridge gọi Lambda mỗi 5 phút kiểm tra trạng thái — tốn tài nguyên liên tục và phản ứng chậm: gọi Lambda 8.640 lần mỗi tháng dù hầu hết lần đều không có gì, và có độ trễ tới 5 phút.
• **D. EventBridge gọi Lambda khởi động lại instance mỗi 5 phút — khởi động lại vô điều kiện: máy bị reboot mỗi 5 phút bất kể có treo hay không, làm dịch vụ gián đoạn liên tục.

Ghi nhớ

Bốn hành động EC2 dựng sẵn của CloudWatch alarm — bảng phải thuộc: | Hành động | ARN | Khi nào dùng | |---|---|---| | Reboot | arn:aws:automate:<region>:ec2:reboot | hệ điều hành treo | | Recover | arn:aws:automate:<region>:ec2:recover | hạ tầng AWS hỏng | | Stop | arn:aws:automate:<region>:ec2:stop | tiết kiệm chi phí | | Terminate | arn:aws:automate:<region>:ec2:terminate | dọn dẹp |

Reboot và Recover — phân biệt quan trọng: | | Reboot | Recover | |---|---|---| | Dùng cho | StatusCheckFailed_Instance | StatusCheckFailed_System | | Nguyên nhân | hệ điều hành, ứng dụng | phần cứng máy chủ vật lý | | Cơ chế | khởi động lại tại chỗ | chuyển sang phần cứng KHÁC | | Giữ IP và metadata | ✅ | ✅ (kể cả IPv4 tự động) |

Và auto-recovery đã BẬT MẶC ĐỊNH từ tháng 3/2022:

Mọi instance dùng loại được hỗ trợ
    → tự phục hồi khi StatusCheckFailed_System
    → KHÔNG cần cấu hình gì
        ↓
    Nhưng lỗi ở tầng hệ điều hành (như trong đề)
    thì auto-recovery KHÔNG xử lý — cần reboot alarm

Ba metric status check: | Metric | Ý nghĩa | |---|---| | StatusCheckFailed_Instance | hệ điều hành không phản hồi, hết bộ nhớ, hỏng file system | | StatusCheckFailed_System | mất điện, lỗi mạng, lỗi phần cứng máy chủ | | StatusCheckFailed | một trong hai cái trên |

Ba tham số quan trọng của alarm: | Tham số | Chi tiết | |---|---| | Period | 60 giây cho status check | | EvaluationPeriods | 2 để tránh báo động giả | | TreatMissingData | thường dùng breaching cho status check |

EvaluationPeriods = 2 là cân bằng hợp lý:

1 chu kỳ: phản ứng nhanh nhưng dễ báo động giả
3 chu kỳ trở lên: chắc chắn hơn nhưng chậm
        ↓
    2 chu kỳ (2 phút) là lựa chọn thường dùng

Ba cách xử lý instance hay treo: | Cách | Đặc điểm | |---|---| | Reboot alarm | giải pháp TẠM THỜI ← đúng đề | | Đưa vào ASG | thay máy tự động, sẵn sàng cao hơn | | Sửa lỗi ứng dụng | giải pháp CĂN BẢN |

Đề nói rõ "cho tới khi đội phát triển sửa xong" — nên giải pháp tạm là phù hợp.

Ba cách phát hiện treo sâu hơn status check: | Cách | Chi tiết | |---|---| | CloudWatch agent với metric bộ nhớ | status check KHÔNG đo RAM | | Custom metric từ ứng dụng | heartbeat | | ALB health check nếu có load balancer | kiểm tra ứng dụng thật |

Dòng đầu là hạn chế quan trọng của status check:

Instance hết RAM và swap dữ dội
    → hệ điều hành vẫn phản hồi (chậm)
    → status check vẫn PASS
        ↓
    Cần metric bộ nhớ từ CloudWatch agent mới thấy

Ba lưu ý về CloudWatch alarm action: | Lưu ý | Chi tiết | |---|---| | KHÔNG cần quyền IAM riêng | hành động dựng sẵn | | Kết hợp nhiều hành động được | reboot + gửi SNS | | Có lịch sử trong alarm history | |

Nên kết hợp cả hai:

--alarm-actions arn:aws:automate:ap-northeast-1:ec2:reboot                 arn:aws:sns:ap-northeast-1:123456789012:canh-bao-van-hanh

Vừa tự khởi động lại
vừa báo cho đội vận hành biết chuyện đã xảy ra
        ↓
    Không im lặng che giấu vấn đề

Ba lưu ý về chi phí CloudWatch: | Khoản | Giá tham khảo | |---|---| | Alarm tiêu chuẩn | ~0,10 USD/tháng | | Metric tuỳ chỉnh | ~0,30 USD/metric/tháng | | Detailed monitoring | ~2,10 USD/instance/tháng |

Ba việc nên làm khi máy hay treo: | Việc | Chi tiết | |---|---| | Gửi log ra CloudWatch Logs | treo là mất log cục bộ | | Bật CloudWatch agent đo RAM và đĩa | | | Ghi lại thời điểm mỗi lần treo | tìm quy luật |

Và một lời khuyên: hãy gửi thêm thông báo SNS bên cạnh hành động reboot. Một máy tự khởi động lại và không ai biết sẽ che giấu tần suất thật của lỗi — và khi đội phát triển hỏi "nó treo bao nhiêu lần một tuần" để ưu tiên sửa, bạn cần con số đó chứ không phải một hệ thống âm thầm che vấn đề đi.