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

Đáp án

C — Đóng gói job thành container, chạy trên AWS Fargate với Amazon ECS, lập lịch bằng Amazon EventBridge Scheduler.

Vì sao đúng

Đề cho bốn ràng buộc, và Fargate thoả cả bốn: | Ràng buộc | Cơ chế | |---|---| | Chạy ÍT NHẤT 2 GIỜ | Fargate KHÔNG giới hạn thời gian | | KHÔNG được gián đoạn | Fargate On-Demand không bị thu hồi | | Job có TRẠNG THÁI | container chạy liên tục tới khi xong | | Ít công vận hành nhất | không quản lý máy chủ nào |

Con số 2 giờ loại Lambda ngay:

AWS Lambda: thời gian chạy tối đa 15 PHÚT
    → job 2 giờ KHÔNG chạy được
        ↓
    Đây là giới hạn cứng, không nâng được

Và "không được gián đoạn" loại Spot:

"requires at least 2 hours to complete WITHOUT INTERRUPTIONS"
"The job is STATEFUL"
        ↓
    Spot Instance bị thu hồi với thông báo 2 phút
    → job có trạng thái phải chạy lại từ đầu
        ↓
    Không phù hợp

Triển khai:

aws ecs register-task-definition   --family phan-tich-hang-tuan   --requires-compatibilities FARGATE   --network-mode awsvpc --cpu 4096 --memory 16384   --execution-role-arn <arn-execution-role>   --task-role-arn <arn-task-role>   --container-definitions file://container.json

Và EventBridge Scheduler lập lịch:

aws scheduler create-schedule --name chay-thu-sau   --schedule-expression "cron(0 19 ? * FRI *)"   --schedule-expression-timezone "Asia/Ho_Chi_Minh"   --flexible-time-window Mode=OFF   --target '{"Arn":"<arn-cum-ecs>",
             "RoleArn":"<arn-role>",
             "EcsParameters":{"TaskDefinitionArn":"<arn-task-def>",
                              "LaunchType":"FARGATE",
                              "NetworkConfiguration":{...}}}'

Ba lợi ích của Fargate ở đây: | Lợi ích | Chi tiết | |---|---| | Không quản lý instance, AMI, vá lỗi | | | Chỉ trả tiền trong 2 giờ chạy | | | Không giới hạn thời gian | |

Và chi phí rất thấp:

4 vCPU, 16 GB, chạy 2 giờ mỗi tuần
    → khoảng 8 giờ mỗi tháng
        ↓
    Vài USD mỗi tháng

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

• **A. Chạy trên EC2 On-Demand riêng với cron job — đây là phương án gần nhất và đảm bảo không gián đoạn, nhưng nó nhiều công vận hành hơn hẳn: phải quản lý AMI, vá lỗi, giám sát, và máy chạy 24/7 dù chỉ dùng 2 giờ mỗi tuần — trừ khi tự viết logic tắt bật.
• **B. Dùng EMR với Spot Instance — vi phạm yêu cầu không gián đoạn: Spot bị thu hồi bất cứ lúc nào, và job có trạng thái sẽ mất toàn bộ tiến độ. (Và "EMR Step Functions" không phải tên dịch vụ chính xác.)
• **D. Chạy trong Lambda với reserved concurrency — vượt giới hạn cứng 15 phút.

Ghi nhớ

Giới hạn thời gian chạy — bảng phải thuộc: | Dịch vụ | Tối đa | |---|---| | AWS Lambda | 15 phút | | AWS Fargate | không giới hạn | | AWS Batch | không giới hạn | | EC2 | không giới hạn | | Step Functions Standard | 1 năm |

Con số 15 phút là điểm loại trừ hay dùng nhất trong đề thi.

Ba lựa chọn cho job chạy dài theo lịch: | Lựa chọn | Đặc điểm | |---|---| | ECS/Fargate + EventBridge Scheduler | ← câu này, ít công vận hành | | AWS Batch | tự quản hàng đợi và năng lực | | EC2 + cron | nhiều công vận hành nhất |

AWS Batch cũng là lựa chọn tốt:

aws batch submit-job --job-name phan-tich-hang-tuan   --job-queue hang-doi-phan-tich --job-definition <arn>

Batch tự:
    ✓ khởi động năng lực khi có việc
    ✓ tắt khi xong
    ✓ thử lại khi lỗi
        ↓
    Với job theo lịch đơn giản, ECS + Scheduler đủ và đơn giản hơn

Ba đặc điểm của EventBridge Scheduler: | Đặc điểm | Chi tiết | |---|---| | Hỗ trợ cron, rate, và one-time | | | Có múi giờ | quan trọng với lịch theo giờ địa phương | | Gọi trực tiếp API AWS | không cần Lambda trung gian |

Múi giờ là chi tiết đáng lưu ý:

cron(0 19 ? * FRI *) với timezone Asia/Ho_Chi_Minh
    → chạy 19h thứ Sáu giờ Việt Nam
        ↓
    Không có timezone thì mặc định UTC
    → lệch 7 giờ, chạy nhầm ngày

EventBridge Scheduler và EventBridge Rule — bảng phân biệt: | | Scheduler | Rule (scheduled) | |---|---|---| | Múi giờ | ✅ | ❌ chỉ UTC | | One-time schedule | ✅ | ❌ | | Số lịch | hàng triệu | giới hạn thấp hơn | | Flexible time window | ✅ | ❌ |

Scheduler là dịch vụ mới hơn và phù hợp hơn cho lập lịch.

Ba lựa chọn năng lực cho ECS: | Lựa chọn | Đặc điểm | |---|---| | Fargate | không quản node, không bị thu hồi | | Fargate Spot | rẻ hơn ~70% nhưng BỊ THU HỒI | | EC2 launch type | kiểm soát instance |

Fargate Spot KHÔNG dùng được ở đây — job có trạng thái và không chịu gián đoạn.

Ba cấu hình task Fargate: | Cấu hình | Khoảng | |---|---| | CPU | 0,25–16 vCPU | | Bộ nhớ | 0,5–120 GB | | Ephemeral storage | 20–200 GB |

Ba lưu ý về job có trạng thái: | Lưu ý | Chi tiết | |---|---| | Ghi tiến độ ra ngoài định kỳ | S3 hoặc DynamoDB | | Thiết kế để làm lại được | phòng khi task hỏng | | Đặt stopTimeout đủ dài | cho việc dọn dẹp |

Dòng đầu vẫn đáng làm dù Fargate không bị thu hồi:

Task vẫn có thể hỏng vì lỗi phần cứng hoặc lỗi ứng dụng
    → ghi checkpoint mỗi 15 phút
        ↓
    Chạy lại chỉ mất phần chưa checkpoint

Ba cách theo dõi job: | Cách | Chi tiết | |---|---| | CloudWatch Logs từ container | | | EventBridge bắt sự kiện task state change | | | Alarm khi task thoát với mã lỗi | |

Bắt sự kiện task thất bại:

{"source":["aws.ecs"],
 "detail-type":["ECS Task State Change"],
 "detail":{"lastStatus":["STOPPED"],
           "stoppedReason":[{"anything-but":{"prefix":"Essential container"}}]}}

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Fargate theo vCPU-giây và GB-giây | chỉ trong lúc chạy | | EventBridge Scheduler | ~1,00 USD mỗi triệu lời gọi | | EC2 chạy 24/7 | đắt hơn nhiều cho job hằng tuần |

Ba lưu ý về quyền: | Vai trò | Việc | |---|---| | Task execution role | kéo image, ghi log | | Task role | quyền của chính ứng dụng | | Scheduler role | quyền gọi RunTask |

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Fargate cần subnet và security group | | | Private subnet cần NAT hoặc VPC endpoint | để kéo image từ ECR | | assignPublicIp chỉ dùng với public subnet | |

Và một lời khuyên: hãy ghi checkpoint tiến độ ra S3 mỗi 15 phút dù Fargate không bị thu hồi. Một job hai giờ vẫn có thể hỏng vì lỗi phần cứng hoặc một ngoại lệ ở phút thứ 110 — và khác biệt giữa việc chạy lại 15 phút hay chạy lại toàn bộ là điều bạn sẽ rất biết ơn vào đúng lúc đó.

Đáp án

D — Amazon FSx (cụ thể là FSx for Windows File Server).

Vì sao đúng

Đề nêu từ khoá quyết định: file server farm Windows dùng DFSR.

DFSR (Distributed File System Replication):
    → công nghệ RIÊNG của Windows Server
    → đồng bộ dữ liệu giữa các file server
        ↓
    Thay thế nó cần dịch vụ hiểu SMB, NTFS và Active Directory
        ↓
    Chỉ FSx for Windows File Server có đủ ba

Và FSx Multi-AZ thay thế trọn vẹn vai trò của DFSR:

FSx for Windows Multi-AZ:
    → hai file server ở hai AZ
    → sao chép ĐỒNG BỘ
    → tự chuyển đổi khi một bên hỏng
        ↓
    Cùng mục đích với DFSR, nhưng AWS quản lý

Tạo file system:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 2048 --storage-type SSD   --subnet-ids subnet-a subnet-c   --security-group-ids sg-fsx   --windows-configuration       ActiveDirectoryId=d-abc123,DeploymentType=MULTI_AZ_1,ThroughputCapacity=64,PreferredSubnetId=subnet-a

Ba thứ FSx giữ nguyên từ môi trường Windows: | Thứ | Chi tiết | |---|---| | Quyền NTFS và ACL | theo tài khoản Active Directory | | Shadow copy | người dùng tự khôi phục tệp | | DFS Namespace | gộp nhiều file system |

Và di chuyển dữ liệu giữ được ACL:

aws datasync create-location-smb   --server-hostname 192.168.1.50 --subdirectory /share   --user quantri --domain CORP --password '<mat-khau>'   --agent-arns <arn-agent>

DataSync giữ nguyên quyền NTFS — quan trọng khi chuyển file server.

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

• **C. Amazon EFS — đây là phương án gần nhất vì cũng là hệ thống tệp chia sẻ được quản lý, nhưng nó chỉ hỗ trợ NFS: không có SMB, không có quyền NTFS, không tích hợp Active Directory.
• **B. AWS Storage Gateway — là cầu nối lai, không phải file server thay thế: File Gateway cho truy cập S3 qua SMB nhưng vẫn là lớp đệm trước S3, không có đầy đủ ngữ nghĩa của file server Windows.
• **A. Amazon S3 — là object storage, không phải hệ thống tệp và không hỗ trợ SMB.

Ghi nhớ

Các hệ thống tệp được quản lý của AWS — bảng phải thuộc: | Dịch vụ | Giao thức | Dùng cho | |---|---|---| | Amazon EFS | NFS | Linux | | FSx for Windows File Server | SMB | Windows, AD, NTFS | | FSx for Lustre | Lustre | HPC | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức | | FSx for OpenZFS | NFS | ZFS |

Từ khoá nhận diện:

"Windows", "SMB", "DFSR", "Active Directory", "NTFS" → FSx for Windows File Server "Linux", "NFS" → EFS "HPC", "highest throughput" → FSx for Lustre

Ba kiểu triển khai của FSx for Windows: | Kiểu | Đặc điểm | |---|---| | Single-AZ 1 | thế hệ trước | | Single-AZ 2 | hiệu năng cao hơn | | Multi-AZ | sao chép đồng bộ, tự chuyển đổi |

Ba yêu cầu để dùng: | Yêu cầu | Chi tiết | |---|---| | Active Directory | Managed AD hoặc AD tự quản | | Hai subnet cho Multi-AZ | | | Security group mở cổng SMB và AD | |

Ba tính năng đáng dùng: | Tính năng | Chi tiết | |---|---| | Data deduplication | tiết kiệm 50–60% dung lượng | | Shadow copy | khôi phục tệp tự phục vụ | | User quota | |

Bật deduplication:

Enable-FSxDedup -FileSystemPath \\amznfsxabc.corp.vidu.com\share

Hai loại lưu trữ: | Loại | Đặc điểm | |---|---| | SSD | độ trễ thấp, IOPS cao | | HDD | rẻ hơn ~6 lần |

Ba cách di chuyển dữ liệu: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh nhất, giữ ACL | | Robocopy | quen thuộc với quản trị Windows | | Storage Gateway | di chuyển dần |

Robocopy giữ ACL với tham số đúng:

robocopy \\nguon\share Z:\ /E /COPYALL /DCOPY:DAT /R:1 /W:1 /MT:32

/COPYALL chép cả ACL, owner và audit setting.

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Backup tự động hằng ngày | giữ tới 90 ngày | | AWS Backup quản lý tập trung | | | Shadow copy cho khôi phục nhanh | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Throughput capacity đổi được sau | | | Multi-AZ có độ trễ ghi cao hơn | do sao chép đồng bộ | | SSD cho tải nhạy độ trễ | |

Ba lưu ý về truy cập từ on-premises: | Lưu ý | Chi tiết | |---|---| | Cần VPN hoặc Direct Connect | | | DNS phải phân giải được tên FSx | | | Mở đủ cổng SMB (445) và AD | |

Ba lựa chọn nếu ứng dụng chạy Linux: | Lựa chọn | Khi nào | |---|---| | EFS | NFS thuần | | FSx for ONTAP | cần cả NFS lẫn SMB | | S3 | nếu sửa được ứng dụng |

FSx for ONTAP đáng cân nhắc khi có cả hai:

Môi trường lai Windows và Linux
    → ONTAP xuất cả SMB lẫn NFS trên cùng dữ liệu
        ↓
    Nhưng phức tạp và đắt hơn FSx for Windows

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Dung lượng | SSD đắt hơn HDD nhiều | | Throughput capacity | tính riêng | | Multi-AZ gấp đôi phí lưu trữ | |

Ba việc nên làm khi di chuyển: | Việc | Chi tiết | |---|---| | Kiểm tra ACL giữ nguyên sau khi chép | | | Chạy song song một thời gian | | | Cập nhật DFS Namespace nếu có | |

Và một lời khuyên: hãy kiểm tra vài tệp mẫu bằng cách so ACL trước và sau khi di chuyển. Quyền NTFS là thứ dễ mất nhất trong quá trình chuyển file server, và một tệp mất quyền không báo lỗi gì — nó chỉ đơn giản là ai đó không mở được, và thường phải vài tuần sau mới có người phát hiện.

Đáp án

A — Cập nhật permission policy của hàng đợi SQS để cấp quyền sqs:SendMessage cho tài khoản AWS của đối tác.

Vì sao đúng

Đề nêu hai yêu cầu, và resource policy của SQS đáp ứng đúng: | Yêu cầu | Cơ chế | |---|---| | Đối tác ở tài khoản AWS KHÁC gửi được thông điệp | queue policy cấp quyền cho principal ngoài | | Quyền TỐI THIỂU | CHỈ sqs:SendMessage, CHỈ hàng đợi đó |

SQS có resource-based policy — đó là cơ chế đúng cho truy cập xuyên tài khoản:

Resource-based policy (queue policy):
    → có trường Principal
    → cấp quyền trực tiếp cho tài khoản khác
        ↓
    Đối tác dùng chính danh tính của họ
    → không cần assume role, không cần chia sẻ credential

Queue policy:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "cho-phep-doi-tac-gui",
   "Effect": "Allow",
   "Principal": {"AWS": "arn:aws:iam::222222222222:root"},
   "Action": "sqs:SendMessage",
   "Resource": "arn:aws:sqs:ap-northeast-1:111111111111:hang-doi-doi-tac"}]}

Và có thể thu hẹp hơn nữa tới đúng một role:

{"Principal": {"AWS": "arn:aws:iam::222222222222:role/ung-dung-doi-tac"}}

Áp policy:

aws sqs set-queue-attributes --queue-url <url>   --attributes file://policy.json

Và phía đối tác cũng cần IAM policy:

{"Effect": "Allow",
 "Action": "sqs:SendMessage",
 "Resource": "arn:aws:sqs:ap-northeast-1:111111111111:hang-doi-doi-tac"}

Truy cập XUYÊN TÀI KHOẢN cần CẢ HAI phía cho phép
    → queue policy (phía bạn) + IAM policy (phía đối tác)
        ↓
    Thiếu một trong hai là bị từ chối

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

• **B. Tạo cross-account role có quyền trên MỌI hàng đợi SQS — đây là phương án gần nhất vì assume role cũng là cơ chế xuyên tài khoản hợp lệ, nhưng nó vi phạm quyền tối thiểu: "access to all SQS queues" là quá rộng khi đối tác chỉ cần gửi vào một hàng đợi. Và assume role phức tạp hơn cần thiết ở đây.
• **D. Cập nhật queue policy cấp TẤT CẢ quyền cho tài khoản đối tác — quá rộng: đối tác sẽ xoá được hàng đợi, đọc được thông điệp của người khác, đổi được cấu hình.
• **C. Tạo IAM user và chia sẻ credential — vi phạm nguyên tắc bảo mật cơ bản: không bao giờ chia sẻ access key giữa các tổ chức. Khoá không xoay vòng, không truy vết được, và lộ ra là mất kiểm soát.

Ghi nhớ

Hai loại chính sách trong IAM — bảng phải thuộc: | Loại | Gắn vào | Có Principal | |---|---|---| | Identity-based | user, group, role | ❌ | | Resource-based | hàng đợi SQS, bucket S3, KMS key, Lambda | ✅ |

Quy tắc vàng cho truy cập xuyên tài khoản:

CẢ HAI phía phải cho phép — resource policy VÀ identity policy. Trong CÙNG tài khoản: chỉ cần MỘT trong hai.

Ba dịch vụ có resource-based policy: | Dịch vụ | Chính sách | |---|---| | SQS, SNS | queue/topic policy | | S3 | bucket policy | | KMS | key policy — BẮT BUỘC phải có | | Lambda, Secrets Manager, EventBridge | resource policy |

Hai mô hình truy cập xuyên tài khoản: | Mô hình | Cơ chế | |---|---| | Resource-based policy | principal GIỮ NGUYÊN danh tính | | Assume role | ĐỔI sang danh tính của tài khoản kia |

Khác biệt quan trọng:

Resource-based policy:
    → đối tác gọi bằng chính credential của họ
    → CloudTrail của bạn ghi rõ tài khoản nào gọi

Assume role:
    → đối tác lấy credential tạm của tài khoản bạn
    → mất danh tính gốc trong phiên đó
        ↓
    Với việc chỉ gửi thông điệp, cách đầu đơn giản và rõ ràng hơn

Ba hành động của SQS đáng phân biệt: | Hành động | Ai cần | |---|---| | sqs:SendMessage | producer ← đối tác | | sqs:ReceiveMessage, sqs:DeleteMessage | consumer | | sqs:GetQueueAttributes | cả hai |

Cấp SendMessage mà không cấp ReceiveMessage — đối tác gửi được nhưng không đọc được thông điệp của người khác.

Ba điều kiện hữu ích trong queue policy: | Điều kiện | Việc | |---|---| | aws:PrincipalOrgID | giới hạn trong tổ chức | | aws:SourceArn | cho dịch vụ AWS gọi tới | | aws:SourceIp | giới hạn IP |

Ba nguyên nhân "Access Denied" xuyên tài khoản: | Nguyên nhân | Kiểm tra | |---|---| | Thiếu queue policy | phía bạn | | Thiếu IAM policy | phía đối tác | | KMS key policy chưa cho phép | với hàng đợi mã hoá |

Dòng cuối là bẫy hay gặp:

Hàng đợi mã hoá bằng SSE-KMS
    → queue policy đúng ✓
    → nhưng KEY POLICY không cho phép tài khoản đối tác
        ↓
    Vẫn Access Denied, và thông báo không nhắc tới KMS

Key policy cần thêm:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::222222222222:root"},
 "Action": ["kms:GenerateDataKey", "kms:Decrypt"],
 "Resource": "*"}

Ba biện pháp bảo mật bổ sung: | Biện pháp | Chi tiết | |---|---| | Mã hoá hàng đợi bằng KMS | | | VPC endpoint nếu đối tác ở AWS | | | CloudTrail ghi mọi lời gọi | |

Ba lưu ý về thiết kế hàng đợi cho đối tác: | Lưu ý | Chi tiết | |---|---| | Hàng đợi RIÊNG cho mỗi đối tác | cách ly và đo lường riêng | | DLQ cho thông điệp sai định dạng | | | Kiểm tra định dạng ở consumer | không tin dữ liệu ngoài |

Ba công cụ rà soát quyền: | Công cụ | Việc | |---|---| | IAM Access Analyzer | phát hiện tài nguyên chia sẻ ra ngoài | | Policy Simulator | thử một hành động | | CloudTrail | ai đã gọi gì |

Access Analyzer sẽ báo hàng đợi này là "chia sẻ ra ngoài" — đó là kết quả mong muốn, nên archive finding đó.

Ba lưu ý về quyền tối thiểu: | Nguyên tắc | Chi tiết | |---|---| | Chỉ hành động cần thiết | SendMessage | | Chỉ tài nguyên cần thiết | ARN của đúng hàng đợi | | Thu hẹp principal tới role cụ thể nếu được | |

Và một lời khuyên: hãy thu hẹp principal xuống đúng IAM role của ứng dụng đối tác thay vì cả tài khoản. Cấp cho :root nghĩa là mọi danh tính trong tổ chức đối tác đều gửi được — và tuy thường không gây vấn đề, việc ghi rõ role duy nhất khiến chính sách trở thành tài liệu về ai được phép làm gì.

Đáp án

B và C.

• B — Tạo tag policy trong AWS Organizations ép key compliance-level với giá trị hợp lệ, gắn vào OU
• C — Tạo SCP từ chối tạo EC2 instance nếu thiếu tag đó, gắn vào OU

Vì sao đúng

Đề nêu ba yêu cầu, và hai công cụ chia nhau giải quyết: | Yêu cầu | Cơ chế | |---|---| | Tag phải có giá trị compliant hoặc noncompliant | tag policy ép DANH SÁCH GIÁ TRỊ | | Không tạo được instance thiếu tag | SCP chặn ec2:RunInstances | | Không sửa được tag sau khi tạo | SCP chặn ec2:DeleteTags |

Vì sao cần CẢ HAI:

SCP:        chặn HÀNH ĐỘNG khi thiếu tag
            → nhưng khó ép DANH SÁCH giá trị hợp lệ

Tag policy: định nghĩa key và GIÁ TRỊ hợp lệ
            → chuẩn hoá cả cách viết hoa thường
        ↓
    Hai công cụ bù đắp cho nhau

SCP chặn tạo instance thiếu tag:

{"Effect": "Deny",
 "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"Null": {"aws:RequestTag/compliance-level": "true"}}}

Và SCP chặn xoá tag:

{"Effect": "Deny",
 "Action": "ec2:DeleteTags",
 "Resource": "*",
 "Condition": {"ForAnyValue:StringEquals":
   {"aws:TagKeys": "compliance-level"}}}

Tag policy ép giá trị:

{"tags": {
  "compliance-level": {
    "tag_key": {"@@assign": "compliance-level"},
    "tag_value": {"@@assign": ["compliant", "noncompliant"]},
    "enforced_for": {"@@assign": ["ec2:instance"]}}}}

⚠ enforced_for là chi tiết quyết định:

Không có enforced_for:
    → tag policy chỉ BÁO CÁO không tuân thủ
    → không chặn gì

Có enforced_for:
    → CHẶN thao tác gắn tag với giá trị sai
        ↓
    Đây là khác biệt giữa "biết" và "ngăn"

Và SCP là biện pháp mạnh nhất:

SCP áp cho MỌI principal trong tài khoản
    → kể cả root của tài khoản thành viên
        ↓
    Không ai lách được

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

• **A. Dùng AWS Config kiểm tra tag và tự động remediate bằng cách thêm tag — đây là phương án gần nhất và hữu ích cho tài nguyên đã có, nhưng nó phản ứng SAU khi vi phạm: instance đã chạy một khoảng thời gian không có tag. Đề yêu cầu ngăn chặn, và việc tự thêm tag còn đoán sai giá trị.
• **D. Tạo IAM policy từ chối xoá tag gắn cho mọi IAM user — yếu hơn SCP nhiều: phải gắn vào từng danh tính, ai tạo user hoặc role mới mà quên gắn là lọt. SCP áp cho cả OU tự động.
• **E. Dùng Lambda với EventBridge chấm dứt instance thiếu tag — hành động nguy hiểm và phản ứng sau: tự động chấm dứt instance có thể phá hỏng tải hợp lệ, và instance đã tồn tại một khoảng thời gian.

Ghi nhớ

Bốn cơ chế quản trị của AWS Organizations — bảng phải thuộc: | Cơ chế | Việc | |---|---| | Service Control Policy (SCP) | giới hạn quyền TỐI ĐA — chỉ Deny | | Tag policy | chuẩn hoá tag key và giá trị | | Backup policy | kế hoạch sao lưu tập trung | | AI services opt-out policy | từ chối dùng dữ liệu |

Ba đặc điểm quan trọng của SCP: | Đặc điểm | Chi tiết | |---|---| | KHÔNG cấp quyền | chỉ giới hạn | | Áp cho MỌI principal, kể cả root | trừ tài khoản quản lý | | Deny của SCP THẮNG mọi Allow của IAM | |

Ba khoá điều kiện về tag — bảng cần thuộc: | Khoá | Dùng khi | |---|---| | aws:RequestTag/<key> | tag gửi TRONG request (lúc tạo) | | aws:ResourceTag/<key> | tag ĐANG CÓ trên tài nguyên | | aws:TagKeys | danh sách key trong request |

Ba toán tử hay dùng với tag: | Toán tử | Việc | |---|---| | Null | kiểm tra tag CÓ TỒN TẠI không | | StringEquals | so giá trị chính xác | | ForAnyValue:StringEquals | với danh sách nhiều giá trị |

Null là toán tử đúng để bắt buộc có tag:

{"Null": {"aws:RequestTag/compliance-level": "true"}}

"true" nghĩa là "khoá này KHÔNG tồn tại"
    → kết hợp Deny = "từ chối nếu thiếu tag"

⚠ Ba lưu ý khi viết SCP cho RunInstances: | Lưu ý | Chi tiết | |---|---| | RunInstances tạo NHIỀU loại tài nguyên | instance, volume, ENI | | Chỉ áp điều kiện cho instance/* | không thì chặn nhầm | | Thử ở OU thử nghiệm trước | |

Dòng đầu gây lỗi khó hiểu nếu bỏ qua:

SCP Deny RunInstances khi thiếu tag, Resource: "*"
    → chặn cả việc tạo VOLUME và ENI đi kèm
    → mà chúng không nhận tag của instance
        ↓
    MỌI lần khởi động thất bại, kể cả khi có tag đúng

Ba cấp gắn SCP: | Cấp | Ảnh hưởng | |---|---| | Root của tổ chức | mọi tài khoản | | OU | mọi tài khoản trong OU ← câu này | | Tài khoản | một tài khoản |

SCP là GIAO của mọi cấp — bị chặn ở bất kỳ cấp nào là bị chặn.

Ba lưu ý quan trọng về SCP: | Lưu ý | Chi tiết | |---|---| | KHÔNG áp cho tài khoản QUẢN LÝ | kể cả gắn ở root | | KHÔNG áp cho service-linked role | | | Phải bật "all features" trong Organizations | |

Ba đặc điểm của tag policy: | Đặc điểm | Chi tiết | |---|---| | Chuẩn hoá cách viết KEY | phân biệt hoa thường | | Giới hạn danh sách GIÁ TRỊ | | | enforced_for để CHẶN | không có thì chỉ báo cáo |

Ba lợi ích của chiến lược gắn tag tốt: | Lợi ích | Chi tiết | |---|---| | Quy chi phí theo đội hoặc dự án | | | Phân quyền theo tag (ABAC) | | | Tự động hoá theo tag | backup, tắt máy ngoài giờ |

ABAC dựa hoàn toàn vào tag:

{"Effect": "Allow", "Action": "ec2:StopInstances", "Resource": "*",
 "Condition": {"StringEquals":
   {"aws:ResourceTag/doi": "${aws:PrincipalTag/doi}"}}}

Ba công cụ bổ trợ: | Công cụ | Việc | |---|---| | AWS Config | phát hiện tài nguyên CŨ chưa tuân thủ | | Resource Groups Tag Editor | gắn tag hàng loạt | | Cost allocation tag | quy chi phí |

SCP ngăn vi phạm MỚI, Config tìm vi phạm CŨ — nên dùng cả hai.

Ba bước triển khai: | Bước | Chi tiết | |---|---| | Định nghĩa chuẩn tag và ghi tài liệu | | | Áp tag policy ở chế độ BÁO CÁO trước | xem mức tuân thủ | | Rồi bật enforced_for và SCP | |

Ba lưu ý khi bật cưỡng chế: | Lưu ý | Chi tiết | |---|---| | Kiểm tra quy trình tự động có gắn tag không | | | Cập nhật CloudFormation và Terraform | | | Thông báo cho các đội trước | |

Dòng đầu là nguyên nhân sự cố hay gặp:

Bật SCP chặn RunInstances thiếu tag
    → Auto Scaling group không gắn tag
    → KHÔNG khởi động được máy mới
        ↓
    Kiểm tra launch template có `TagSpecifications` chưa

Và một lời khuyên: hãy chạy tag policy ở chế độ báo cáo ít nhất một tháng trước khi bật cưỡng chế. Báo cáo tuân thủ sẽ cho thấy những cách viết tag mà bạn không ngờ tới — và bật cưỡng chế trước khi biết điều đó sẽ chặn đứng những quy trình tự động đang chạy tốt bằng một cách đặt tên hơi khác.

Đáp án

A — Dùng AWS Storage Gateway File Gateway dạng thiết bị phần cứng tại chỗ để sao chép dữ liệu lên Amazon S3.

Vì sao đúng

Đề nêu ba dữ kiện, và cả ba dẫn tới File Gateway phần cứng: | Dữ kiện | Cơ chế | |---|---| | Dữ liệu trên NAS dùng giao thức NFS | File Gateway xuất NFS | | Nhà máy chỉ có RACK NHỎ tài nguyên tính toán | thiết bị phần cứng không tốn tài nguyên máy chủ | | Cần sao lưu ngoài site hằng ngày | dữ liệu tự đẩy lên S3 |

Vế thứ hai là điểm phân biệt quan trọng:

Storage Gateway triển khai được ba cách:
    → máy ảo (VMware, Hyper-V, KVM) — cần máy chủ ảo hoá
    → EC2 — cho tải chạy trên AWS
    → THIẾT BỊ PHẦN CỨNG — máy riêng của AWS
        ↓
    Nhà máy có rack nhỏ, không dư tài nguyên ảo hoá
    → thiết bị phần cứng là lựa chọn phù hợp

Và File Gateway là chế độ đúng cho dữ liệu NFS:

S3 File Gateway:
    ✓ xuất NFS hoặc SMB share tại chỗ
    ✓ mỗi tệp thành MỘT object S3
    ✓ có cache cục bộ cho tệp hay dùng
        ↓
    Ứng dụng ghi vào share như bình thường
    → dữ liệu tự lên S3

Triển khai:

aws storagegateway create-nfs-file-share   --client-token $(uuidgen) --gateway-arn <arn-gateway>   --location-arn arn:aws:s3:::sao-luu-nha-may   --role <arn-role>   --client-list 192.168.1.0/24   --default-storage-class S3_STANDARD_IA

Và lifecycle chuyển sang lớp rẻ hơn:

{"Rules": [{"ID":"luu-tru-dai-han","Status":"Enabled","Filter":{},
  "Transitions":[{"Days":30,"StorageClass":"GLACIER"}]}]}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi tệp là object S3 bình thường | đọc trực tiếp từ AWS được | | Cache cục bộ cho truy cập nhanh | | | Không cần viết script sao lưu | |

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

• **C. Dùng Volume Gateway với cached volume — đây là phương án gần nhất vì cũng sao chép dữ liệu lên S3, nhưng nó sai giao diện: Volume Gateway xuất iSCSI (khối), còn dữ liệu ở đây nằm trên NAS dùng NFS. Và dữ liệu Volume Gateway lưu dạng snapshot EBS chứ không phải tệp đọc được trực tiếp.
• **B. Dùng Volume Gateway với stored volume — cùng vấn đề giao diện, và stored volume giữ toàn bộ dữ liệu tại chỗ (chỉ sao lưu lên S3), không giải quyết được vấn đề dung lượng cục bộ hạn chế.
• **D. Dựng IPsec VPN và mount EFS, chạy job chép dữ liệu — hiệu năng rất kém: NFS qua VPN Internet có độ trễ cao, và EFS đắt hơn S3 nhiều lần cho việc sao lưu.

Ghi nhớ

Bốn chế độ của AWS Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Dùng cho | |---|---|---| | S3 File Gateway | NFS, SMB | tệp lưu vào S3 ← câu này | | FSx File Gateway | SMB | truy cập FSx for Windows | | Volume Gateway | iSCSI (khối) | ổ đĩa, snapshot EBS | | Tape Gateway | iSCSI VTL | thay băng từ |

Từ khoá nhận diện:

"NFS/SMB files", "backup to S3", "cache" → S3 File Gateway "iSCSI block volumes" → Volume Gateway "replace physical tapes" → Tape Gateway

Ba cách triển khai gateway: | Cách | Khi nào | |---|---| | Máy ảo (VMware, Hyper-V, KVM) | có sẵn hạ tầng ảo hoá | | Hardware Appliance | không có tài nguyên ảo hoá ← câu này | | Amazon EC2 | cho tải chạy trên AWS |

Ba đặc điểm của Hardware Appliance: | Đặc điểm | Chi tiết | |---|---| | AWS gửi thiết bị vật lý | máy chủ 1U | | Cài sẵn phần mềm gateway | | | Không tốn tài nguyên máy chủ hiện có | |

Hai chế độ của Volume Gateway (để phân biệt): | Chế độ | Đặc điểm | |---|---| | Cached volume | dữ liệu chính ở S3, cache nóng tại chỗ | | Stored volume | dữ liệu chính TẠI CHỖ, snapshot lên S3 |

Ba đặc điểm của S3 File Gateway: | Đặc điểm | Chi tiết | |---|---| | Mỗi tệp thành MỘT object S3 | đọc trực tiếp được | | Ghi vào share tự đẩy lên S3 | bất đồng bộ | | Cache tối thiểu 150 GB | |

Dòng đầu là lợi thế lớn so với Volume Gateway:

File Gateway: tệp thành object S3 → dùng được lifecycle, replication, Athena
Volume Gateway: dữ liệu dạng khối → chỉ đọc qua gateway

Ba lưu ý về cache: | Lưu ý | Chi tiết | |---|---| | Cache lớn = tỷ lệ trúng cao | | | Dùng SSD cho đĩa cache | | | Theo dõi CachePercentUsed | |

Ba lưu ý về nhất quán: | Lưu ý | Chi tiết | |---|---| | Ghi qua share → đẩy lên S3 BẤT ĐỒNG BỘ | | | Object ghi thẳng vào S3 không tự hiện trong share | phải RefreshCache | | CacheStaleTimeoutInSeconds tự làm mới | |

aws storagegateway refresh-cache --file-share-arn <arn>

Ba yêu cầu hạ tầng: | Yêu cầu | Chi tiết | |---|---| | Đĩa cache tối thiểu 150 GB | | | Băng thông đủ cho việc tải lên | | | Cổng 443 ra AWS | hoặc VPC endpoint |

Ba cách giới hạn băng thông:

aws storagegateway update-bandwidth-rate-limit --gateway-arn <arn>   --average-upload-rate-limit-in-bits-per-sec 52428800

Giới hạn 50 Mbps để không nghẽn mạng nhà máy trong giờ làm việc
    → hoặc lập lịch giới hạn theo giờ

Ba lựa chọn thay thế: | Lựa chọn | Đặc điểm | |---|---| | DataSync | di chuyển theo lịch, nhanh hơn | | AWS Backup Gateway | sao lưu máy ảo tại chỗ | | Script tự viết chép lên S3 | công vận hành cao |

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 | ❌ | ✅ | | Chạy | theo lịch | liên tục |

Với yêu cầu "daily offsite backup", cả hai đều dùng được — nhưng File Gateway còn cho ứng dụng truy cập tệp cũ mà không tốn dung lượng cục bộ.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CachePercentUsed | cache đầy làm chậm | | CloudBytesUploaded | lượng lên S3 | | FilesFailingUpload | tệp lỗi |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest trong S3 | SSE-S3 hoặc SSE-KMS | | Truyền qua TLS | | | client-list giới hạn IP mount được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ S3 theo lớp | | | Phí gateway theo lượng dữ liệu ghi | | | Lifecycle sang Glacier cho bản cũ | |

Và một lời khuyên: hãy đặt giới hạn băng thông tải lên theo giờ. Nhà máy thường có đường mạng chia sẻ với hệ thống điều khiển sản xuất, và một đợt sao lưu chiếm hết băng thông vào giữa ca làm việc có thể gây hậu quả lớn hơn nhiều so với việc sao lưu chậm vài giờ.

Đáp án

A — Bật detailed monitoring trên mọi EC2 instance và dùng số liệu Amazon 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 dòng:

aws ec2 monitor-instances --instance-ids i-1234567890abcdef0

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

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

Và RDS thì sao?

RDS gửi số liệu CloudWatch mặc định 60 GIÂY
    → CPUUtilization, DatabaseConnections, FreeableMemory,
      ReadLatency, WriteLatency...
        ↓
    Tầng CSDL đã đạt yêu cầu 1 phút mà không cần làm gì
    → chỉ tầng EC2 cần bật thêm

Vì sao chỉ EC2 cần bật:

EC2 basic = 5 phút → KHÔNG đạt yêu cầu
RDS       = 1 phút → đã đạt sẵn
        ↓
    Nên đáp án chỉ nhắc tới EC2

Ba lợi ích trong sự kiện bán hàng: | Lợi ích | Chi tiết | |---|---| | Phát hiện nghẽn nhanh gấp 5 lần | 1 phút thay vì 5 | | Auto Scaling phản ứng nhanh hơn | alarm đánh giá theo chu kỳ 1 phút | | Không phải viết mã gì | bật một cờ |

Vế thứ hai đáng nhấn mạnh:

Alarm dùng metric 5 phút:
    tăng tải → 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
    → sự kiện bán hàng đã hỏng trải nghiệm rồi

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

• **C. Dùng CloudWatch Events + Lambda thu thập metric tuỳ chỉnh — đây là phương án gần nhất vì cũng cho số liệu 1 phút, nhưng nó viết lại thứ AWS đã có sẵn: phải viết mã, xử lý lỗi, trả phí Lambda và phí custom metric, trong khi một cờ cấu hình làm được điều tương tự. Đây là "công vận hành cao nhất" chứ không phải "giải pháp".
• **B. Dùng CloudWatch Logs Insights + QuickSight — sai loại dữ liệu: đây là công cụ cho log, còn đề hỏi về metric hiệu năng (CPU, mạng, đĩa). Log ứng dụng không cho biết CPU của instance.
• **D. Dùng Systems Manager thu log, lưu S3, truy vấn Athena — cùng nhầm lẫn log/metric, và thêm độ trễ rất lớn: dữ liệu phải qua S3 rồi mới truy vấn được, không dùng để phát hiện nhanh trong sự kiện đang diễn ra.

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

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 DoDaiHangDoi --value 42 --storage-resolution 1

⚠ Metric mà EC2 KHÔNG tự gửi — bảng hay bị hỏi: | Metric | Vì sao thiếu | |---|---| | Bộ nhớ (RAM) đang dùng | hypervisor không nhìn thấy bên 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:

Cài CloudWatch Agent trong instance
    → 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

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

Ba nguồn số liệu cho tầng RDS: | Nguồn | Chi tiết | |---|---| | CloudWatch metric | mặc định 60 giây, miễn phí | | Enhanced Monitoring | tới 1 GIÂY, số liệu từ trong OS | | Performance Insights | tải theo truy vấn, chờ theo loại |

Bảng phân biệt ba thứ dễ lẫn: | | Đo gì | Chu kỳ | |---|---|---| | CloudWatch | ngoài instance | 60 giây | | Enhanced Monitoring | trong OS (agent) | 1-60 giây | | Performance Insights | tải CSDL, truy vấn chậm | 1 giây |

Khi nghẽn nằm ở CSDL, Performance Insights là công cụ đúng:

CloudWatch nói "CPU 95%"
Performance Insights nói "truy vấn nào chiếm 95% đó"
        ↓
    Câu thứ hai mới sửa được

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 | | | Có thể bật tạm cho sự kiện rồi tắt | |

Bật tạm là cách làm hợp lý ở đây — sự kiện bán hàng thường niên chỉ vài ngày.

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   --period 60 --evaluation-periods 2 --threshold 80   --comparison-operator GreaterThanThreshold   --treat-missing-data notBreaching

Ba việc nên làm trước sự kiện lớn: | Việc | Chi tiết | |---|---| | Bật detailed monitoring sớm vài ngày | có đường cơ sở để so | | Dựng dashboard gộp EC2 và RDS | | | Thử tải trước | biết ngưỡng gãy |

Ba metric quan trọng nhất cho tầng web: | Metric | Ngưỡng tham khảo | |---|---| | CPUUtilization | | | TargetResponseTime của ALB | | | HTTPCode_Target_5XX_Count | |

Ba metric quan trọng nhất cho RDS: | Metric | Ý nghĩa | |---|---| | DatabaseConnections | sát giới hạn là nghẽn | | FreeableMemory | tụt là sắp swap | | ReadLatency / WriteLatency | |

Và một lời khuyên: hãy bật detailed monitoring ít nhất một tuần trước sự kiện. 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 vào hôm sự kiện 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

B — On-Demand Capacity Reservations.

Vì sao đúng

Đề nêu bốn dữ kiện, và chỉ một lựa chọn đáp ứng được cái quan trọng nhất: | Dữ kiện | Ý nghĩa | |---|---| | Chạy vài giờ mỗi đêm, 5 ngày một tuần | KHÔNG chạy liên tục | | Không được gián đoạn khi đã bắt đầu | loại Spot | | Cần tối thiểu 1 năm | có thể cam kết dài hạn | | Phải ĐẢM BẢO có máy khi cần | cần ĐẶT TRƯỚC năng lực |

Vế cuối là điểm mấu chốt của câu này:

Câu hỏi là "ensure the EC2 instances are AVAILABLE"
    → không phải "rẻ nhất"
    → mà là ĐẢM BẢO CÓ MÁY
        ↓
    Chỉ On-Demand Capacity Reservation đảm bảo năng lực

Vì sao cần đảm bảo:

On-Demand thường KHÔNG bảo đảm gì
    → gặp lúc AZ hết năng lực loại instance đó
    → InsufficientInstanceCapacity
        ↓
    Job phân tích đêm đó không chạy được

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

aws ec2 create-capacity-reservation   --instance-type m5.4xlarge --instance-platform Linux/UNIX   --availability-zone ap-southeast-1a --instance-count 10   --instance-match-criteria targeted

Ba đặc điểm: | Đặc điểm | Chi tiết | |---|---| | Năng lực dành riêng trong MỘT AZ | | | Tạo và huỷ bất cứ lúc nào | không cam kết thời hạn | | Trả tiền kể cả khi không dùng | giá On-Demand |

Vế thứ ba là điều phải hiểu rõ:

Capacity Reservation TÍNH TIỀN LIÊN TỤC
    → kể cả những giờ ban ngày không chạy job
        ↓
    Nhưng có thể HUỶ vào ban ngày và TẠO LẠI trước giờ chạy
    → chỉ trả cho khoảng thời gian giữ chỗ

Và ghép với Savings Plans để giảm giá:

Capacity Reservation:  đảm bảo CÓ MÁY
Savings Plans / RI:     giảm GIÁ
        ↓
    Hai thứ độc lập, ÁP CHỒNG được
    → đây mới là kiến trúc tối ưu cho bài này

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

• **A. Regional Reserved Instances — đây là phương án gần nhất và rất nhiều người chọn nhầm, nhưng RI theo vùng KHÔNG đặt trước năng lực. Nó chỉ là cam kết thanh toán để được giảm giá; khi AZ hết máy bạn vẫn không khởi động được. Chỉ zonal RI (RI gắn với một AZ cụ thể) mới có đảm bảo năng lực.
• **D. Savings Plans — cùng vấn đề: đây thuần tuý là công cụ giảm giá đổi lấy cam kết chi tiêu theo giờ. Không có bất kỳ đảm bảo năng lực nào.
• **C. On-Demand Instances — linh hoạt và không bị gián đoạn, nhưng không đảm bảo có máy khi AZ cạn năng lực, và không có giảm giá dù cam kết 1 năm.

Ghi nhớ

Bảng đảm bảo năng lực — thuộc bảng này là làm được cả một 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) |

Từ khoá nhận diện:

"ensure capacity is available", "guarantee" → Capacity Reservation hoặc zonal RI "lowest cost", "commit" → Savings Plans "cannot be interrupted" → loại Spot

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

Ba lưu ý về Capacity Reservation: | Lưu ý | 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 | | | instance-match-criteria: open hoặc targeted | |

Hai chế độ khớp — chi tiết hay bị bỏ qua: | 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 job đêm
        ↓
    `targeted` an toàn hơn cho bài này

Khai dùng chỗ đã đặt:

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

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Trả tiền dù dùng hay không | | | Huỷ và tạo lại theo lịch để tiết kiệm | | | Áp chồng Savings Plans để giảm giá | |

Tự động theo lịch bằng EventBridge Scheduler:

21:00 các ngày thứ 2-6:  tạo Capacity Reservation
23:00:                    chạy job
02:00:                    huỷ Capacity Reservation
        ↓
    Chỉ trả 5 giờ mỗi đêm thay vì 24 giờ

Ba lựa chọn thay thế cho bài này: | Lựa chọn | Đặc điểm | |---|---| | Capacity Reservation + Savings Plans | đảm bảo + rẻ | | Zonal RI 1 năm | cả hai trong một | | Spot Fleet | rẻ nhất nhưng bị gián đoạn |

Zonal RI đáng cân nhắc vì đề nói "tối thiểu 1 năm":

Zonal RI 1 năm:  vừa giảm giá vừa đảm bảo năng lực
    → nhưng khoá vào một AZ và một loại instance suốt 1 năm
        ↓
    Capacity Reservation linh hoạt hơn, huỷ lúc nào cũng được

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 phù hợp job không được gián đoạn | | | "Spot blocks" đã NGỪNG từ 12/2021 | |

Ba việc nên làm khi lập kế hoạch năng lực: | Việc | Chi tiết | |---|---| | Đặt trước ở nhiều AZ nếu job chia được | | | Theo dõi UsedInstanceCount của reservation | | | Đặt alarm khi tỷ lệ dùng thấp | đang lãng phí |

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

Phương án A gọi là "Regional Reserved Instances", và cần nói rõ vì đây là hiểu nhầm phổ biến nhất về Reserved Instance:

Reserved Instance có HAI dạng, và chúng khác nhau ở đúng điểm câu này hỏi: | Dạng | Giảm giá | Đảm bảo năng lực | Linh hoạt AZ | |---|---|---|---| | Zonal RI | ✅ | ✅ | ❌ khoá một AZ | | Regional RI | ✅ | ❌ | ✅ mọi AZ trong vùng |

Nếu đề chỉ ghi "Reserved Instances" thì câu sẽ mơ hồ. Việc ghi rõ "Regional" là cố ý và làm câu hỏi chính xác — nhưng cũng khiến nhiều người bỏ qua từ đó rồi chọn nhầm, vì "Reserved" nghe như đã "đặt trước".

Ngoài ra, Savings Plans chưa từng có bất kỳ hình thức đảm bảo năng lực nào kể từ khi ra mắt năm 2019 — nó thuần tuý là mô hình thanh toán, và đây là điểm AWS nhấn mạnh trong tài liệu chính thức.

Đáp án

B — Sửa Auto Scaling group để chạy hai instance ở mỗi trong ba Availability Zone.

Vì sao đúng

Đề nêu ba ràng buộc, và chỉ một phương án thoả cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | Đang chạy 6 máy trong MỘT AZ | rủi ro: mất AZ là mất hết | | Cần tính sẵn sàng cao | trải qua NHIỀU AZ | | KHÔNG được sửa ứng dụng | chỉ đổi hạ tầng |

Điểm hỏng duy nhất nằm ở đâu:

Trước:  ALB → ASG 6 máy → tất cả trong AZ-a
            ↓
    AZ-a hỏng → 0 máy còn sống → ứng dụng chết

Sau:    ALB → ASG 6 máy → 2 ở AZ-a, 2 ở AZ-b, 2 ở AZ-c
            ↓
    AZ-a hỏng → còn 4 máy → ứng dụng vẫn chạy

Sửa bằng một lệnh, giữ nguyên số máy:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-web   --vpc-zone-identifier "subnet-aaa,subnet-bbb,subnet-ccc"   --min-size 6 --desired-capacity 6 --max-size 12

Và ALB cũng phải bật ở cả ba AZ:

aws elbv2 set-subnets --load-balancer-arn <arn>   --subnets subnet-pub-a subnet-pub-b subnet-pub-c

Vì sao ba AZ tốt hơn hai: | Số AZ | Mất 1 AZ còn | Phải dự phòng | |---|---|---| | 2 AZ | 50% năng lực | +100% để chịu được | | 3 AZ | 67% năng lực | +50% |

Với 3 AZ: mất 1 AZ chỉ mất 1/3 năng lực
    → dự phòng ít hơn, chi phí thấp hơn
        ↓
    Đây là lý do AWS khuyến nghị 3 AZ

Ba đặc điểm đáng chú ý: | Đặc điểm | Chi tiết | |---|---| | ASG tự cân bằng giữa các AZ | AZRebalance | | Không cần đổi mã ứng dụng | | | Chi phí không tăng | vẫn 6 máy |

Vế cuối quan trọng: đây là cải thiện tính sẵn sàng miễn phí — chỉ trải cùng số máy ra rộng hơn.

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

• **C. Tạo ASG chạy ba instance ở mỗi trong hai Region — đây là phương án gần nhất vì cũng trải rộng ra, nhưng nó phức tạp quá mức và không làm được như mô tả: một ASG không trải qua nhiều vùng, phải dựng hai bộ hạ tầng riêng, và cần Route 53 định tuyến. Đề chỉ cần "tính sẵn sàng cao", mà đa AZ đã đủ.
• **A. Tạo launch template để tạo nhanh máy ở vùng khác — không phải tính sẵn sàng cao: đây là kế hoạch khôi phục thủ công, vẫn có thời gian ngừng khi AZ hỏng. Tính sẵn sàng cao nghĩa là tự động, không gián đoạn.
• **D. Tạo CloudFront với origin ở nhiều vùng — CloudFront là CDN tăng tốc, không giải quyết việc backend nằm trong một AZ. Origin vẫn chết khi AZ chết.

Ghi nhớ

Ba tầng dự phòng của AWS — bảng phải thuộc: | Tầng | Bảo vệ khỏi | Công | |---|---|---| | Nhiều AZ trong một Region | hỏng một trung tâm dữ liệu | thấp ← câu này | | Nhiều Region | thảm hoạ cả vùng | cao | | Nhiều tài khoản | sự cố quản trị | cao |

Từ khoá nhận diện:

"highly available", "single AZ" → trải qua NHIỀU AZ "disaster recovery", "regional outage" → đa Region "no modifications to the application" → chỉ đổi hạ tầng

Ba khái niệm dễ lẫn: | Khái niệm | Nghĩa | |---|---| | Tính sẵn sàng cao (HA) | tự chịu được hỏng, không gián đoạn | | Khôi phục thảm hoạ (DR) | phục hồi sau sự cố lớn, có RTO/RPO | | Khả năng chịu lỗi (FT) | hoạt động bình thường dù có lỗi |

Ba yêu cầu để ASG đa AZ chạy tốt: | Yêu cầu | Chi tiết | |---|---| | Mỗi AZ phải có SUBNET riêng | subnet gắn với đúng một AZ | | ALB phải bật ở cùng các AZ | | | Ứng dụng KHÔNG lưu trạng thái cục bộ | |

Vế thứ ba là chỗ hay gãy:

Ứng dụng lưu session trong bộ nhớ máy
    → người dùng bị chuyển sang máy khác
    → mất phiên đăng nhập
        ↓
    Chuyển session sang ElastiCache hoặc DynamoDB
    → hoặc bật sticky session của ALB (giải pháp tạm)

Ba chiến lược phân bổ khi ASG có nhiều AZ: | Chiến lược | Hành vi | |---|---| | Cân bằng đều giữa các AZ | mặc định | | AZRebalance | tự cân lại khi lệch | | balanced-best-effort với nhiều loại máy | |

Ba lưu ý về AZRebalance: | Lưu ý | Chi tiết | |---|---| | ASG KHỞI ĐỘNG máy mới TRƯỚC khi tắt máy cũ | | | Có thể vượt desired capacity tạm thời | | | Tạm dừng được bằng suspend-processes | |

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Đặt --health-check-type ELB | không chỉ EC2 | | health-check-grace-period đủ cho khởi động | | | ALB health check trỏ đúng đường dẫn | |

Dòng đầu là lỗi cấu hình rất hay gặp:

Health check kiểu EC2:  chỉ xem máy có chạy không
    → ứng dụng treo mà máy vẫn "chạy"
    → ASG không thay máy, ALB vẫn gửi request
        ↓
    Kiểu ELB mới thấy được ứng dụng hỏng

Ba lưu ý về tầng CSDL: | Lưu ý | Chi tiết | |---|---| | CSDL cũng phải đa AZ | RDS Multi-AZ | | Tầng web đa AZ mà CSDL một AZ vẫn hỏng | | | Kiểm tra mọi tầng, không chỉ tầng đầu | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Trải cùng số máy ra nhiều AZ: MIỄN PHÍ | | | Lưu lượng giữa các AZ có tính phí | | | ALB tự tính phí theo LCU | |

Về phí giữa các AZ:

ALB gửi request tới target ở AZ khác → tính phí data transfer
    → bật "cross-zone load balancing" (mặc định BẬT với ALB)
        ↓
    Đánh đổi: cân bằng tốt hơn nhưng tốn phí truyền
    → với ALB thì AWS KHÔNG tính phí cross-zone, chỉ NLB mới tính

Ba việc kiểm tra sau khi chuyển: | Việc | Chi tiết | |---|---| | Xem instance đã chia đều ba AZ chưa | | | Thử tắt hết máy một AZ | xem còn phục vụ không | | Kiểm tra session còn giữ được không | |

Và một lời khuyên: hãy thực sự thử tắt hết instance trong một AZ sau khi chuyển. Kiến trúc đa AZ trên giấy và kiến trúc đa AZ chịu được sự cố là hai chuyện khác nhau — thường thì thứ gãy không phải tầng web mà là một dịch vụ phụ nào đó vẫn còn cắm chân trong AZ cũ.

Đáp án

A — Tạo SCP với quy tắc Deny từ chối mọi loại instance trừ những loại được phép.

Vì sao đúng

Đề hỏi cách áp chính sách cho nhiều tài khoản trong một OU với ít công sức nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Nhiều tài khoản thành viên trong một OU | SCP gắn vào OU áp cho tất cả | | Hạn chế loại EC2 instance | điều kiện ec2:InstanceType | | Ít công nhất | một chính sách, một lần gắn |

Vì sao dùng Deny chứ không dùng Allow:

SCP mặc định của AWS Organizations là FullAWSAccess (Allow *)
    → gắn thêm một SCP Deny → giới hạn được ngay
        ↓
    Gắn một SCP chỉ Allow vài hành động
    → GIAO với FullAWSAccess → chỉ còn vài hành động đó
    → MỌI dịch vụ khác bị chặn hết!

Chính sách:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Deny",
   "Action": "ec2:RunInstances",
   "Resource": "arn:aws:ec2:*:*:instance/*",
   "Condition": {"StringNotEquals": {
     "ec2:InstanceType": ["t3.micro", "t3.small", "m5.large"]}}}]}

Đọc chính sách này:

Deny RunInstances khi InstanceType KHÁC danh sách cho phép
    → t3.micro   → không khớp Deny → được phép
    → m5.24xlarge → khớp Deny      → bị chặn

Gắn vào OU:

aws organizations attach-policy   --policy-id p-abc123 --target-id ou-root-xyz789

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Áp cho MỌI principal, kể cả root tài khoản | | | Tài khoản mới vào OU tự chịu chính sách | | | Một chỗ sửa, mọi nơi đổi theo | |

Vế thứ hai là điều làm SCP thắng IAM policy hoàn toàn ở bài này.

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

• **B. Tạo SCP với quy tắc Allow cho phép các loại instance cụ thể — đây là phương án gần nhất và nghe rất hợp lý, nhưng hiểu sai cách SCP hoạt động: SCP Allow không cấp quyền, nó chỉ giới hạn danh sách quyền tối đa. Gắn một SCP chỉ liệt kê ec2:RunInstances sẽ chặn đứng mọi dịch vụ AWS khác trong toàn OU. Và Allow trong SCP cũng không nhận điều kiện theo cách này.
• **C. Tạo IAM policy từ chối các loại instance — về mặt kỹ thuật làm được, nhưng công sức lớn nhất: phải gắn cho từng user và role trong từng tài khoản, và ai tạo danh tính mới mà quên gắn là lọt. Đề hỏi "least effort".
• **D. Dùng AWS Resource Access Manager — sai công cụ hoàn toàn: RAM dùng để chia sẻ tài nguyên (subnet, Transit Gateway, license) giữa các tài khoản, không phải để hạn chế quyền.

Ghi nhớ

Quy tắc vàng về SCP — thuộc câu này là làm được cả nhóm:

SCP KHÔNG cấp quyền, chỉ giới hạn quyền tối đa. Quyền thật = GIAO của SCP và IAM policy.

Bảng hai cách viết SCP: | Cách | Hành vi | Rủi ro | |---|---|---| | Deny list (mặc định) | cấm vài thứ, còn lại cho | thấp ← nên dùng | | Allow list | chỉ cho vài thứ, cấm hết còn lại | rất cao |

Nếu dùng Allow list, phải liệt kê ĐỦ:

Quên iam:*, sts:*, cloudwatch:*, s3:*, ...
    → tài khoản gần như không làm được gì
        ↓
    Deny list an toàn hơn nhiều cho hầu hết trường hợp

Ba khoá điều kiện hay dùng với RunInstances: | Khoá | Việc | |---|---| | ec2:InstanceType | giới hạn loại máy ← câu này | | ec2:Region | giới hạn vùng | | aws:RequestTag/<key> | bắt buộc gắn tag |

Cách viết đúng để giới hạn loại instance: | Cách | Đúng/Sai | |---|---| | Deny + StringNotEquals | ✅ | | Allow + StringEquals | ❌ không cấp quyền | | Deny + StringEquals danh sách cấm | ✅ nhưng phải liệt kê hết |

Dùng ký tự đại diện để gọn hơn:

{"Effect": "Deny", "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringNotLike": {"ec2:InstanceType": ["t3.*", "m5.*"]}}}

⚠ Bẫy lớn nhất khi viết SCP cho RunInstances:

RunInstances tạo nhiều loại tài nguyên cùng lúc:
    instance, volume, network-interface, security-group...
        ↓
    Nếu Resource: "*" và điều kiện là InstanceType
    → điều kiện KHÔNG áp cho volume (nó không có InstanceType)
    → StringNotEquals đúng → Deny → MỌI lần khởi động thất bại
        ↓
    Phải giới hạn Resource ở "instance/*"

Ba đặc điểm áp dụng của SCP: | Đặc điểm | Chi tiết | |---|---| | Áp cho root của tài khoản THÀNH VIÊN | | | KHÔNG áp cho tài khoản QUẢN LÝ | kể cả gắn ở root | | KHÔNG áp cho service-linked role | |

Vế thứ hai đáng nhớ:

Nhiều người thử SCP từ tài khoản quản lý → không thấy bị chặn
    → tưởng chính sách hỏng
        ↓
    Phải thử từ một tài khoản THÀNH VIÊN

Ba cấp gắn SCP và cách kết hợp: | Cấp | Ảnh hưởng | |---|---| | Root tổ chức | mọi tài khoản | | OU | mọi tài khoản trong OU ← câu này | | Tài khoản | một tài khoản |

SCP là GIAO qua mọi cấp — bị Deny ở bất kỳ cấp nào là bị chặn.

Ba điều kiện tiên quyết: | Điều kiện | Chi tiết | |---|---| | Bật "all features" trong Organizations | | | Bật loại chính sách SCP | | | Thao tác từ tài khoản quản lý | |

aws organizations enable-policy-type   --root-id r-abc1 --policy-type SERVICE_CONTROL_POLICY

Ba giới hạn kỹ thuật: | Giới hạn | Con số | |---|---| | Kích thước một SCP | 5.120 ký tự | | Số SCP gắn cho một mục tiêu | 5 | | Độ sâu OU | 5 cấp |

Giới hạn 5.120 ký tự là chỗ hay vấp — chính sách dài phải tách thành nhiều SCP.

Ba công cụ kiểm chứng: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử trước khi gắn | | CloudTrail | xem lệnh bị từ chối | | Access Analyzer | tìm quyền dư |

Ba lời khuyên khi triển khai: | Lời khuyên | Chi tiết | |---|---| | Thử ở OU thử nghiệm trước | | | Có OU "sandbox" nới lỏng hơn | | | Ghi tài liệu vì sao chặn | |

Ba SCP nên có ở hầu hết tổ chức: | SCP | Việc | |---|---| | Chặn vùng không dùng tới | giảm bề mặt tấn công | | Chặn tắt CloudTrail và Config | | | Chặn xoá bản sao lưu | |

Và một lời khuyên: hãy luôn kèm một điều kiện loại trừ role quản trị khẩn cấp trong SCP hạn chế. Một SCP viết sai gắn ở cấp OU có thể khoá tất cả mọi người ra khỏi chính công cụ cần dùng để sửa nó, và lúc đó chỉ còn cách vào tài khoản quản lý để gỡ chính sách.

Đáp án

B — Tạo CloudFront distribution và đặt price class chỉ gồm Hoa Kỳ, Canada và Mexico.

Vì sao đúng

Đề nêu ba dữ kiện, và price class giải quyết đúng cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | Trang tĩnh trên S3 | CloudFront cache rất hiệu quả | | Khách hàng chủ yếu ở Mỹ, Canada, Mexico | chỉ cần edge ở khu vực đó | | Giảm độ trễ, TIẾT KIỆM CHI PHÍ | price class loại bỏ edge đắt tiền |

Vế cuối là điểm mấu chốt:

Giá CloudFront khác nhau theo khu vực địa lý
    → Bắc Mỹ và châu Âu: rẻ nhất
    → Nam Mỹ, Ấn Độ:      đắt gấp 2-3 lần
        ↓
    Price class = chọn dùng nhóm edge nào
    → không dùng nhóm đắt = không trả tiền cho nhóm đó

Ba price class của CloudFront: | Price class | Bao gồm | Giá | |---|---|---| | PriceClass_All | mọi edge toàn cầu | cao nhất | | PriceClass_200 | bỏ Nam Mỹ và Úc/NZ | trung bình | | PriceClass_100 | Mỹ, Canada, châu Âu, Israel | thấp nhất ← đáp án |

Cấu hình:

aws cloudfront update-distribution --id E123ABC   --distribution-config file://cau-hinh.json

{"PriceClass": "PriceClass_100", "Enabled": true, ...}

Điều quan trọng cần hiểu về price class:

Price class KHÔNG chặn người dùng ở vùng khác
    → khách từ Nhật vẫn truy cập được
    → chỉ là request của họ đi tới edge Mỹ (xa hơn)
        ↓
    Đánh đổi: độ trễ cao hơn cho vùng ngoài, chi phí thấp hơn

Vì sao vẫn giảm được độ trễ cho khách chính:

Không có CloudFront:  khách Mexico → S3 bucket (vd: us-east-1)
                      → mọi request đi xuyên quốc gia

Có CloudFront:        khách Mexico → edge tại Mexico City
                      → nội dung tĩnh trả ngay từ cache
                          ↓
                      Độ trễ giảm đáng kể

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

• **A. Đặt price class dùng tất cả edge location — đây là phương án gần nhất và cho độ trễ tốt nhất, nhưng đề hỏi "most cost-effective". Trả tiền cho edge ở Nam Mỹ, Úc, Ấn Độ khi không có khách ở đó là lãng phí thuần tuý.
• **C. CloudFront với origin ở Mỹ, Canada và Mexico — hiểu sai kiến trúc: CloudFront có một origin chính (origin group chỉ dùng để dự phòng), và nhân bản bucket ở ba nơi làm tăng chi phí lưu trữ và độ phức tạp mà không giảm độ trễ hơn — vì cache ở edge mới là thứ quyết định.
• **D. Dùng Lambda@Edge để xử lý dữ liệu gần người dùng — sai vấn đề: đây là trang brochure tĩnh, không có xử lý gì để chạy. Lambda@Edge chỉ thêm chi phí và độ trễ tính toán.

Ghi nhớ

Ba price class — bảng phải thuộc: | Price class | Khu vực | Khi nào dùng | |---|---|---| | PriceClass_All | toàn cầu | khách ở khắp nơi | | PriceClass_200 | trừ Nam Mỹ, Úc/NZ | phần lớn thế giới | | PriceClass_100 | Bắc Mỹ, châu Âu, Israel | khách tập trung |

Từ khoá nhận diện:

"customers mainly in <vài khu vực>" + "cost-effective" → giới hạn price class "global audience" + "best performance" → PriceClass_All "restrict access by country" → geo restriction (khác hẳn)

⚠ Price class và geo restriction là HAI thứ khác nhau: | | Price class | Geo restriction | |---|---|---| | Mục đích | giảm chi phí | chặn truy cập | | Khách ngoài vùng | vẫn vào được (chậm hơn) | bị chặn 403 | | Dùng cho | tối ưu chi phí | bản quyền, tuân thủ |

aws cloudfront update-distribution --id E123ABC --distribution-config '{
  "Restrictions": {"GeoRestriction": {
    "RestrictionType": "whitelist", "Quantity": 3,
    "Items": ["US", "CA", "MX"]}}}'

Ba thành phần chi phí CloudFront: | Thành phần | Chi tiết | |---|---| | Data transfer out ra Internet | theo khu vực edge | | Số request HTTP/HTTPS | theo khu vực | | Tính năng thêm | Lambda@Edge, Field-level encryption |

Và một khoản ĐƯỢC MIỄN:

Data transfer từ S3 (hoặc EC2, ELB) SANG CloudFront: MIỄN PHÍ
    → dùng CloudFront trước S3 thường RẺ HƠN dùng S3 trực tiếp
        ↓
    Đây là điều nhiều người không biết

Ba cách tối ưu chi phí thêm: | Cách | Chi tiết | |---|---| | Tăng TTL cache | ít request tới origin | | Bật nén (gzip, Brotli) | giảm lượng byte | | Origin Shield | thêm một tầng cache |

Ba lưu ý về cache cho trang tĩnh: | Lưu ý | Chi tiết | |---|---| | Dùng CachingOptimized policy | | | Đặt Cache-Control ở object S3 | | | Đặt tên tệp có mã băm | cache vĩnh viễn, đổi tên khi sửa |

aws s3 cp brochure.html s3://bucket/   --cache-control "public, max-age=86400"

Ba lưu ý về bảo mật cho S3 làm origin: | Lưu ý | Chi tiết | |---|---| | Dùng OAC (Origin Access Control) | không phải OAI đã cũ | | Chặn public access ở bucket | | | Bật ViewerProtocolPolicy: redirect-to-https | |

OAC thay thế OAI từ 08/2022 — OAI không dùng được với SSE-KMS và các vùng mới.

Ba lưu ý khi đổi price class: | Lưu ý | Chi tiết | |---|---| | Đổi được bất cứ lúc nào, không gián đoạn | | | Mất vài phút để lan ra | | | Theo dõi độ trễ trước và sau | |

Ba cách đo hiệu quả: | Cách | Công cụ | |---|---| | CloudFront standard log hoặc real-time log | | | CloudWatch metric OriginLatency | | | CloudFront tỷ lệ cache hit | |

Tỷ lệ cache hit là số quan trọng nhất với trang tĩnh:

Cache hit 95% → chỉ 5% request chạm origin
    → chi phí S3 và độ trễ đều thấp
        ↓
    Dưới 80% với nội dung tĩnh là dấu hiệu cấu hình sai
    → thường do forward cookie hoặc query string không cần thiết

Ba lỗi làm hỏng tỷ lệ cache hit: | Lỗi | Hậu quả | |---|---| | Forward mọi cookie | mỗi khách một bản cache | | Forward mọi query string | ?utm_source=... tách cache | | Forward header không cần | như trên |

Ba lựa chọn khác cho trang tĩnh: | Lựa chọn | Đặc điểm | |---|---| | S3 + CloudFront | chuẩn mực ← câu này | | AWS Amplify Hosting | có CI/CD sẵn | | S3 website endpoint trực tiếp | không HTTPS, không CDN |

Và một lời khuyên: hãy xem báo cáo "Popular objects" và "Viewers by location" của CloudFront sau vài tuần trước khi khoá price class. Giả định về nơi khách hàng ở thường lệch so với thực tế — và nếu có một lượng khách đáng kể ở Nam Mỹ mà bạn không biết, PriceClass_100 sẽ làm trải nghiệm của họ tệ đi mà không ai báo cho bạn.