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

Đáp án

A — Dùng S3 Glacier vault lưu dữ liệu nhạy cảm đã lưu trữ, rồi dùng vault lock policy để thực thi kiểm soát tuân thủ.

Vì sao đúng

Đề nêu hai yêu cầu, và cặp vault + vault lock đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Giải pháp lưu trữ dựa trên S3 Glacier | Glacier vault | | Thực thi kiểm soát quy định và tuân thủ về truy cập | Vault Lock policy |

Vault Lock là cơ chế BẤT BIẾN, khác hẳn các cơ chế quyền thông thường:

Vault Lock policy sau khi hoàn tất khoá:
    → KHÔNG SỬA ĐƯỢC NỮA
    → kể cả tài khoản root
        ↓
    Đây chính là thứ kiểm toán viên cần cho hồ sơ y tế

Quy trình khoá có HAI bước có chủ đích:

# ① Khởi tạo — chính sách ở trạng thái NHÁP, có 24 giờ để thử
aws glacier initiate-vault-lock --account-id -   --vault-name ho-so-benh-nhan --policy file://chinh-sach.json

# Thử nghiệm trong 24 giờ...
aws glacier abort-vault-lock --account-id - --vault-name ho-so-benh-nhan  # nếu sai

# ② Hoàn tất — KHOÁ VĨNH VIỄN
aws glacier complete-vault-lock --account-id -   --vault-name ho-so-benh-nhan --lock-id <lock-id>

24 giờ đó là cơ hội DUY NHẤT để phát hiện chính sách sai.

Chính sách mẫu ép giữ 7 năm:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "cam-xoa-truoc-7-nam",
   "Effect": "Deny",
   "Principal": "*",
   "Action": "glacier:DeleteArchive",
   "Resource": "arn:aws:glacier:ap-northeast-1:123456789012:vaults/ho-so-benh-nhan",
   "Condition": {"NumericLessThan":
     {"glacier:ArchiveAgeInDays": "2555"}}}]}

Và vì sao lifecycle hay ACL không đủ:

Lifecycle policy:  chỉ chuyển LỚP LƯU TRỮ, không ngăn xoá
ACL:               cơ chế quyền CŨ, sửa được bất cứ lúc nào
        ↓
    Cả hai đều KHÔNG có tính bất biến
    → không đáp ứng yêu cầu tuân thủ

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

• **B. Dùng S3 Glacier lưu dữ liệu rồi dùng S3 lifecycle policy để thực thi kiểm soát tuân thủ — đây là phương án gần nhất vì lifecycle là công cụ quen thuộc với S3, nhưng nó không thực thi được gì về tuân thủ: lifecycle chỉ quyết định object chuyển lớp hoặc bị xoá khi nào, không ngăn ai xoá sớm.
• **C. Glacier vault + S3 Access Control List — ACL là cơ chế cũ AWS khuyến nghị không dùng, và nó không tạo được tính bất biến. ACL sửa được bất cứ lúc nào.
• **D. Glacier + S3 ACL — cùng vấn đề, và còn không dùng vault.

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

Đáp án dùng S3 Glacier Vault Lock — đây là dịch vụ Glacier NGUYÊN BẢN, khác với lớp lưu trữ Glacier của S3.

Hai thứ rất dễ nhầm: | | S3 Glacier (dịch vụ nguyên bản) | Lớp lưu trữ Glacier của S3 | |---|---|---| | Khái niệm | vault, archive | bucket, object | | API | API riêng của Glacier | API của S3 | | Cơ chế bất biến | Vault Lock | Object Lock |

AWS hiện khuyến nghị dùng lớp lưu trữ Glacier của S3 thay vì dịch vụ Glacier nguyên bản, vì nó dùng chung API, công cụ và cơ chế quyền với S3. Cách làm được khuyến nghị ngày nay cho bài toán trong đề là:

Bucket S3 bật Object Lock chế độ COMPLIANCE, retention 7 năm
    + lifecycle chuyển sang Glacier Deep Archive
        ↓
    Cùng mức bất biến, mà quản lý bằng API của S3
    → và tích hợp được với Access Analyzer, Storage Lens, replication

(Đáp án A vẫn đúng theo các phương án cho sẵn — Vault Lock là cơ chế bất biến hợp lệ.)

Ghi nhớ

Ba cơ chế bất biến của AWS — bảng phải thuộc: | Cơ chế | Dịch vụ | |---|---| | S3 Object Lock (Compliance) | S3 — khuyến nghị hiện nay | | Glacier Vault Lock | Glacier nguyên bản | | AWS Backup Vault Lock | AWS Backup |

Đặc điểm chung: khoá xong thì KHÔNG AI gỡ được, kể cả root.

Hai chế độ của S3 Object Lock: | | Governance | Compliance | |---|---|---| | Người có quyền đặc biệt xoá được | ✅ | ❌ | | Root xoá được | ✅ | ❌ | | Rút ngắn thời hạn | ✅ | ❌ |

Với hồ sơ y tế và yêu cầu tuân thủ, Compliance là chế độ đúng.

Ba đặc điểm của Glacier Vault Lock: | Đặc điểm | Chi tiết | |---|---| | Hai bước: initiate rồi complete | | | 24 giờ để thử và huỷ | cơ hội duy nhất | | Sau khi complete: VĨNH VIỄN | |

Ba điều kiện hữu ích trong Vault Lock policy: | Điều kiện | Việc | |---|---| | glacier:ArchiveAgeInDays | cấm xoá archive trẻ hơn N ngày | | aws:SourceIp | giới hạn nguồn | | aws:MultiFactorAuthPresent | yêu cầu MFA |

Ba tuỳ chọn lấy dữ liệu của Glacier: | Tuỳ chọn | Thời gian | |---|---| | Expedited | 1–5 phút | | Standard | 3–5 giờ | | Bulk | 5–12 giờ, rẻ nhất |

Ba yêu cầu tuân thủ với dữ liệu y tế: | Yêu cầu | Cơ chế | |---|---| | HIPAA | cần ký BAA với AWS | | Mã hoá at rest và in transit | KMS + TLS | | Kiểm soát và ghi log truy cập | CloudTrail |

Ba biện pháp bảo vệ bổ sung: | Biện pháp | Chi tiết | |---|---| | CloudTrail data event | ghi mọi thao tác đọc ghi | | Mã hoá bằng customer managed key | audit việc dùng khoá | | Replication sang tài khoản khác | chống mất cả tài khoản |

⚠ Ba rủi ro của cơ chế bất biến: | Rủi ro | Chi tiết | |---|---| | Đặt nhầm thời hạn = trả tiền suốt thời hạn đó | không sửa được | | Không xoá được dù dữ liệu sai | | | AWS Support KHÔNG can thiệp được | |

Vì vậy: LUÔN thử trên vault hoặc bucket nhỏ với thời hạn vài ngày trước.

Ba lưu ý về chi phí lưu trữ dài hạn: | Lớp | Giá tham khảo | |---|---| | Glacier Flexible Retrieval | ~0,0036 USD/GB-tháng | | Glacier Deep Archive | ~0,00099 USD/GB-tháng | | — | thời gian lưu tối thiểu 90 / 180 ngày |

Ba việc nên làm trước khi khoá: | Việc | Chi tiết | |---|---| | Xác nhận thời hạn với bộ phận pháp chế | | | Thử toàn bộ quy trình với thời hạn ngắn | | | Tính trước tổng chi phí cả thời hạn | |

Và một lời khuyên: hãy dùng trọn 24 giờ thử nghiệm để kiểm tra chính sách bằng cách thực sự thử xoá một archive. Đọc lại JSON không đủ — một điều kiện viết sai vẫn trông hợp lý trên giấy, và sau khi complete-vault-lock chạy thì không còn cách nào sửa nữa.

Đáp án

D — Dùng AWS Budgets đặt ngưỡng chi tiêu cho mỗi tài khoản của lập trình viên; cấu hình cảnh báo khi chi phí thực tế hoặc dự báo vượt hạn mức; gắn budget action tự động áp chính sách IAM DenyAll khi vượt ngưỡng.

Vì sao đúng

Đề nêu ba yêu cầu, và AWS Budgets với budget action đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Thực thi hạn mức ngân sách CHỦ ĐỘNG | cảnh báo theo chi phí THỰC TẾ và DỰ BÁO | | Phản ứng TỰ ĐỘNG khi vượt chi | budget action áp IAM policy | | Ít công quản trị nhất | tính năng dựng sẵn, không viết mã |

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

AWS Budgets hỗ trợ ba loại hành động tự động:
    ✓ áp IAM policy (chặn quyền)
    ✓ áp SCP (chặn cả tài khoản)
    ✓ dừng EC2 hoặc RDS instance
        ↓
    KHÔNG cần Lambda, KHÔNG cần mã nào

Tạo ngân sách:

aws budgets create-budget --account-id 123456789012   --budget '{"BudgetName":"ngan-sach-lap-trinh-vien",
             "BudgetLimit":{"Amount":"500","Unit":"USD"},
             "TimeUnit":"MONTHLY","BudgetType":"COST"}'   --notifications-with-subscribers '[{
    "Notification":{"NotificationType":"FORECASTED",
      "ComparisonOperator":"GREATER_THAN","Threshold":80},
    "Subscribers":[{"SubscriptionType":"EMAIL","Address":"doi@vidu.com"}]}]'

Và gắn hành động:

aws budgets create-budget-action --account-id 123456789012   --budget-name ngan-sach-lap-trinh-vien   --notification-type ACTUAL   --action-type APPLY_IAM_POLICY   --action-threshold ActionThresholdValue=100,ActionThresholdType=PERCENTAGE   --definition '{"IamActionDefinition":{
    "PolicyArn":"arn:aws:iam::aws:policy/AWSDenyAll",
    "Roles":["vai-tro-lap-trinh-vien"]}}'   --approval-model AUTOMATIC   --execution-role-arn <arn-role>

NotificationType: FORECASTED là điểm "chủ động":

ACTUAL:     báo khi ĐÃ vượt — muộn
FORECASTED: báo khi DỰ BÁO sẽ vượt cuối kỳ
        ↓
    Đúng "PROACTIVELY enforce budget limits"

Và approval-model cho hai chế độ: | Chế độ | Hành vi | |---|---| | AUTOMATIC | tự áp ngay khi vượt ngưỡng | | MANUAL | chờ người phê duyệt |

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

• **B. Lambda chạy hằng ngày ở mỗi tài khoản, phân tích qua Cost Explorer API, gọi AWS Config remediation nếu vượt ngưỡng — đây là phương án gần nhất và về nguyên tắc làm được việc, nhưng nó phải viết và bảo trì mã ở MỌI tài khoản: đi ngược yêu cầu "least operational overhead", và chạy mỗi ngày một lần nghĩa là có thể vượt chi nhiều trước khi phát hiện.
• **A. Service Catalog giới hạn template + Lambda theo lịch tắt bật tài nguyên — không phải kiểm soát ngân sách: nó giới hạn loại tài nguyên, không giới hạn số tiền. Và tắt tài nguyên mỗi tối là chính sách thô, không phản ứng theo chi tiêu.
• **C. Cost Explorer gửi báo cáo hằng ngày, yêu cầu lập trình viên tự theo dõi — hoàn toàn thủ công: không có cơ chế thực thi nào, phụ thuộc vào việc mỗi người tự giác đọc email.

Ghi nhớ

Các công cụ quản lý chi phí của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | AWS Budgets | đặt ngưỡng, CẢNH BÁO và HÀNH ĐỘNG tự động | | Cost Explorer | PHÂN TÍCH chi tiêu quá khứ và dự báo | | Cost and Usage Report | dữ liệu thô chi tiết nhất | | Compute Optimizer | khuyến nghị kích thước tài nguyên | | Cost Optimization Hub | tập hợp mọi khuyến nghị tiết kiệm | | Cost Anomaly Detection | phát hiện chi tiêu bất thường bằng học máy |

Từ khoá nhận diện:

"enforce budget", "automatic action when exceeded" → AWS Budgets + budget actions "analyze where money goes" → Cost Explorer "detect unusual spending automatically" → Cost Anomaly Detection

Bốn loại ngân sách của AWS Budgets: | Loại | Theo dõi | |---|---| | Cost budget | số tiền ← câu này | | Usage budget | lượng dùng (giờ, GB) | | RI/Savings Plans utilization | mức tận dụng cam kết | | RI/Savings Plans coverage | tỷ lệ phủ |

Ba loại budget action: | Hành động | Chi tiết | |---|---| | Áp IAM policy | chặn quyền của user, group, role | | Áp SCP | chặn ở cấp OU hoặc tài khoản | | Dừng EC2 hoặc RDS instance | |

Hai loại thông báo: | Loại | Khi nào kích hoạt | |---|---| | ACTUAL | chi phí thực tế đã vượt ngưỡng | | FORECASTED | dự báo sẽ vượt vào cuối kỳ |

Nên đặt cả hai: dự báo ở 80% để cảnh báo sớm, thực tế ở 100% để hành động.

Ba lưu ý về budget action: | Lưu ý | Chi tiết | |---|---| | Cần execution role có quyền tương ứng | | | Hoàn tác được | gỡ policy khi đã xử lý xong | | Nên thử ở tài khoản không quan trọng trước | |

Dòng cuối rất quan trọng:

Áp AWSDenyAll cho nhầm role
    → chặn cả quy trình tự động hoặc tài khoản vận hành
        ↓
    Thử kỹ, và KHÔNG áp cho role quản trị khẩn cấp

Ba lưu ý khi thiết kế mô hình đa tài khoản: | Lưu ý | Chi tiết | |---|---| | Tài khoản riêng là ranh giới chi phí và bảo mật tự nhiên | | | Dùng consolidated billing | gộp hoá đơn, hưởng bậc giá tốt hơn | | Tag để quy chi phí trong từng tài khoản | |

Ba cách kiểm soát chi phí bổ sung: | Cách | Chi tiết | |---|---| | SCP chặn Region hoặc loại instance đắt | | | Service Quotas giới hạn số tài nguyên | | | Cost Anomaly Detection | phát hiện chi tiêu bất thường tự động |

SCP chặn instance đắt:

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

Ngăn lập trình viên vô tình khởi động một máy hàng nghìn USD mỗi tháng.

Ba nguồn chi phí bất ngờ hay gặp ở tài khoản phát triển: | Nguồn | Chi tiết | |---|---| | NAT Gateway để quên | ~32 USD/tháng mỗi cái | | EBS volume và snapshot mồ côi | | | Instance lớn để chạy qua đêm | |

Ba lưu ý về Cost Anomaly Detection: | Lưu ý | Chi tiết | |---|---| | MIỄN PHÍ | | | Dùng học máy, không cần đặt ngưỡng | | | Phát hiện được thứ ngân sách cố định bỏ sót | |

Nên bật cả hai:

AWS Budgets:            ngưỡng cứng, có hành động
Cost Anomaly Detection: phát hiện bất thường không đoán trước
        ↓
    Hai cơ chế bổ sung cho nhau

Và một lời khuyên: hãy đặt cảnh báo FORECASTED ở mức 80% song song với hành động ở 100%. Cảnh báo dự báo cho lập trình viên cơ hội tự dọn dẹp trước khi bị chặn quyền — và một hệ thống chỉ biết chặn mà không cảnh báo trước sẽ nhanh chóng bị coi là chướng ngại thay vì công cụ hỗ trợ.

Đáp án

B — Dùng EBS làm root volume cho EC2 instance, và cấu hình ứng dụng dùng Amazon S3 làm kho tài liệu.

Vì sao đúng

Đề nêu ba yêu cầu, và S3 đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Kho tài liệu SẴN SÀNG CAO | S3 sao chép qua ≥3 AZ, độ bền 11 số 9 | | Trả tài liệu TỨC THÌ khi được yêu cầu | S3 Standard truy xuất tức thì | | EC2 ở NHIỀU AZ cùng truy cập | S3 là dịch vụ theo Region, mọi AZ đều gọi được |

Vấn đề gốc với EBS:

EBS volume gắn với MỘT Availability Zone
    → EC2 ở AZ khác KHÔNG gắn được volume đó
        ↓
    Ứng dụng trải nhiều AZ mà kho tài liệu ở một AZ
    → AZ đó hỏng là mất truy cập tài liệu

Và S3 giải quyết triệt để:

S3 là dịch vụ cấp REGION
    → mọi EC2 ở mọi AZ đều gọi được cùng một bucket
    → dữ liệu tự sao chép qua ít nhất 3 AZ
        ↓
    Không có điểm hỏng theo AZ nào

Và đề nói rõ đội sẵn sàng đổi cách lưu trữ:

"the team is WILLING TO CONSIDER OTHER OPTIONS
 to meet the availability requirement"
        ↓
    Bỏ được ràng buộc phải dùng khối
    → S3 trở thành lựa chọn tự nhiên

Mẫu triển khai:

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

def luu_tai_lieu(khoa, du_lieu):
    s3.put_object(Bucket='kho-tai-lieu', Key=khoa, Body=du_lieu,
                  ServerSideEncryption='aws:kms')

def lay_url_tai(khoa):
    return s3.generate_presigned_url('get_object',
        Params={'Bucket': 'kho-tai-lieu', 'Key': khoa}, ExpiresIn=3600)

Presigned URL là mẫu tốt:

Người dùng 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

Và S3 rẻ hơn EBS đáng kể:

EBS gp3:      ~0,08 USD/GB-tháng
S3 Standard:  ~0,023 USD/GB-tháng
        ↓
    Rẻ hơn khoảng 3,5 lần, và không phải cấp phát trước

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

• **A. Chụp snapshot EBS định kỳ rồi tạo volume mới từ snapshot ở các AZ khác — đây là phương án gần nhất và có tạo bản sao ở nhiều AZ, nhưng nó không phải kho dùng chung: mỗi AZ có một bản riêng, ghi ở AZ này không thấy ở AZ kia. Và snapshot theo lịch nghĩa là dữ liệu luôn cũ.
• **D. EBS làm root volume, dùng S3 Glacier làm kho tài liệu — vi phạm yêu cầu truy xuất tức thì: Glacier Flexible Retrieval mất từ một phút tới 12 giờ. Đề nói rõ "documents need to be returned IMMEDIATELY".
• **C. Cấp ba Provisioned IOPS Instance Store volume rồi mount vào nhiều EC2 — hai lỗi: không có thứ gọi là "Provisioned IOPS Instance Store", và instance store KHÔNG chia sẻ giữa các instance được (nó gắn vật lý vào một máy chủ).

Ghi nhớ

Phạm vi của các loại lưu trữ — bảng phải thuộc: | Lưu trữ | Phạm vi | Chia sẻ nhiều máy | |---|---|---| | Instance store | một INSTANCE | ❌ | | EBS | một AZ | ❌ (trừ Multi-Attach io1/io2 cùng AZ) | | EFS | REGION, nhiều AZ | ✅ (POSIX) | | FSx for Lustre | một AZ (hoặc nhiều với ONTAP) | ✅ | | S3 | REGION, ≥3 AZ | ✅ (object) |

Câu hỏi nào nói "nhiều AZ cùng truy cập" thì loại ngay EBS và instance store.

S3 và EFS — chọn cái nào: | Câu hỏi | Nếu "có" | |---|---| | Ứng dụng cần POSIX (khoá tệp, sửa tại chỗ)? | EFS | | Sửa được mã, chỉ đọc ghi cả tệp? | S3 | | Muốn rẻ nhất? | S3 |

Với kho tài liệu (ghi một lần, đọc nhiều lần), S3 gần như luôn đúng.

Ba đặc điểm của S3 liên quan tới sẵn sàng: | Đặc điểm | Chi tiết | |---|---| | Độ bền 99,999999999% | 11 số 9 | | Sẵn sàng 99,99% (Standard) | SLA | | Tự sao chép qua ≥3 AZ | |

Các lớp lưu trữ S3 và thời gian lấy: | Lớp | Thời gian lấy | |---|---| | Standard, Standard-IA, Intelligent-Tiering | tức thì | | Glacier Instant Retrieval | mili giây | | Glacier Flexible Retrieval | 1 phút – 12 giờ | | Deep Archive | 12–48 giờ |

Với yêu cầu "immediately", bốn dòng đầu dùng được.

Ba lưu ý khi chuyển từ lưu trữ khối sang S3: | Lưu ý | Chi tiết | |---|---| | Đổi mã từ thao tác tệp sang API S3 | | | Dùng presigned URL cho tải lên/xuống trực tiếp | | | Multipart upload cho tệp lớn | |

Ba cơ chế bảo vệ dữ liệu nên bật: | Cơ chế | Chi tiết | |---|---| | Versioning | chống ghi đè và xoá nhầm | | Mã hoá SSE-KMS | và bật S3 Bucket Keys | | Block Public Access | ở cấp tài khoản |

Ba cách cải thiện hiệu năng truy cập: | Cách | Chi tiết | |---|---| | CloudFront trước S3 | đệm tài liệu hay đọc | | S3 Transfer Acceleration | tải lên từ xa | | VPC gateway endpoint | truy cập riêng tư, MIỄN PHÍ |

Gateway endpoint nên có ở mọi VPC:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-northeast-1.s3   --vpc-endpoint-type Gateway --route-table-ids rtb-abc

✓ lưu lượng KHÔNG ra Internet
✓ tiết kiệm phí NAT Gateway
✓ MIỄN PHÍ

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | EC2 dùng instance profile, không dùng access key | | | Quyền tối thiểu: chỉ prefix cần thiết | | | Bucket policy chặn truy cập không mã hoá | |

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Chuyển tài liệu cũ sang Standard-IA hoặc Glacier Instant | | | AbortIncompleteMultipartUpload | dọn phần dở dang | | Xoá phiên bản cũ nếu bật versioning | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | 4xxErrors | quyền hoặc khoá sai | | FirstByteLatency | độ trễ truy xuất | | BucketSizeBytes | dung lượng và chi phí |

Và một lời khuyên: hãy tạo VPC gateway endpoint cho S3 ngay khi chuyển sang kiến trúc này. Nó miễn phí, giữ toàn bộ lưu lượng tài liệu trong mạng AWS, và tiết kiệm phí NAT Gateway — ba lợi ích cho một lệnh mất chưa tới một phút.

Đáp án

D — Dedicated Instances.

Vì sao đúng

Đề nêu hai yêu cầu, và Dedicated Instance là điểm cân bằng đúng: | Yêu cầu | Cơ chế | |---|---| | Phần cứng một khách thuê (single-tenant) | chạy trên phần cứng KHÔNG chia sẻ với tài khoản khác | | TIẾT KIỆM CHI PHÍ NHẤT trong các cách cách ly | rẻ hơn Dedicated Host |

Điểm phân biệt giữa hai lựa chọn cách ly:

Dedicated Instance:
    → chạy trên phần cứng dành riêng cho TÀI KHOẢN của bạn
    → nhưng bạn KHÔNG kiểm soát máy chủ vật lý cụ thể
    → tính phí theo INSTANCE-giờ (như On-Demand, cộng phụ phí)

Dedicated Host:
    → bạn thuê CẢ MÁY CHỦ VẬT LÝ
    → thấy được socket, core, và vị trí instance trên máy
    → tính phí theo HOST-giờ — trả tiền cả máy dù chỉ chạy 1 instance
        ↓
    Đắt hơn đáng kể

Với yêu cầu chỉ là "phần cứng một khách thuê", Dedicated Instance đủ và rẻ hơn.

Khởi động Dedicated Instance:

aws ec2 run-instances --instance-type m5.large   --image-id ami-0abc --count 2   --placement Tenancy=dedicated

Hoặc đặt ở cấp VPC:

aws ec2 create-vpc --cidr-block 10.0.0.0/16 --instance-tenancy dedicated

⚠ Lưu ý quan trọng về tenancy cấp VPC:

VPC với instance-tenancy = dedicated
    → MỌI instance trong VPC đó buộc phải là dedicated
    → và KHÔNG đổi ngược lại được
        ↓
    Chi phí tăng cho cả những tải không cần cách ly

Ba mức tenancy: | Mức | Nghĩa | |---|---| | default | phần cứng dùng chung | | dedicated | phần cứng dành riêng cho tài khoản | | host | máy chủ vật lý cụ thể bạn thuê |

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

• **C. Dedicated Hosts — đây là phương án gần nhất và cũng cho phần cứng một khách thuê, nhưng nó ĐẮT HƠN đáng kể: bạn trả tiền cho cả máy chủ vật lý theo giờ, dù chỉ chạy một instance. Nó chỉ đáng dùng khi cần thấy socket/core cho giấy phép phần mềm BYOL hoặc yêu cầu tuân thủ đòi biết vị trí vật lý.
• **B. On-Demand Instances — chạy trên phần cứng DÙNG CHUNG: không đáp ứng yêu cầu single-tenant.
• **A. Spot Instances — cũng dùng chung phần cứng, và còn bị thu hồi bất cứ lúc nào — không phù hợp với tải tuân thủ.

Ghi nhớ

Dedicated Instance và Dedicated Host — bảng phải thuộc: | | Dedicated Instance | Dedicated Host | |---|---|---| | Phần cứng một khách thuê | ✅ | ✅ | | Thấy socket và core vật lý | ❌ | ✅ | | Kiểm soát vị trí instance trên máy | ❌ | ✅ | | Tính phí | theo INSTANCE-giờ | theo HOST-giờ | | Hỗ trợ BYOL theo socket/core | ❌ | ✅ | | Chi phí | thấp hơn | cao hơn |

Quy tắc chọn:

"single-tenant hardware", "compliance", "most cost-effective" → Dedicated Instance "BYOL licensing per socket/core", "visibility into physical host" → Dedicated Host

Ba lý do thật sự cần Dedicated Host: | Lý do | Chi tiết | |---|---| | Giấy phép tính theo socket hoặc core vật lý | Windows Server, SQL Server, Oracle | | Yêu cầu tuân thủ đòi biết vị trí vật lý | | | Cần đặt instance vào cùng một máy chủ | affinity |

Ba đặc điểm của Dedicated Host: | Đặc điểm | Chi tiết | |---|---| | Host affinity | instance luôn khởi động lại trên cùng host | | Host recovery | tự chuyển sang host mới khi hỏng | | Host resource group | quản lý nhiều host cho BYOL |

Ba cách trả tiền cho Dedicated Host: | Cách | Chi tiết | |---|---| | On-Demand | theo giờ | | Reserved | cam kết 1–3 năm, giảm giá | | Savings Plans | không áp cho Dedicated Host |

Các mô hình mua EC2 — bảng nhắc lại: | Mô hình | Tiết kiệm | Phần cứng | |---|---|---| | On-Demand | 0% | dùng chung | | Savings Plans / RI | tới 72% | dùng chung | | Spot | tới 90% | dùng chung | | Dedicated Instance | — | riêng cho tài khoản | | Dedicated Host | — | máy chủ vật lý riêng |

Ba lưu ý về chi phí Dedicated Instance: | Lưu ý | Chi tiết | |---|---| | Phụ phí ~10% so với instance thường | tuỳ loại | | Cộng phí Dedicated Per-Region | ~2 USD/giờ mỗi Region đang chạy dedicated | | Reserved Instance áp được | giảm giá vẫn hưởng |

Dòng giữa hay bị bỏ sót khi tính chi phí:

Phí Dedicated Per-Region tính MỘT LẦN mỗi Region
    → dù chạy 1 hay 100 dedicated instance
        ↓
    Chạy ít instance dedicated thì phí này chiếm tỷ lệ lớn

Ba yêu cầu tuân thủ hay dẫn tới single-tenant: | Yêu cầu | Chi tiết | |---|---| | HIPAA | thường không bắt buộc dedicated | | PCI DSS | tuỳ diễn giải | | Chính sách nội bộ | ← lý do phổ biến nhất |

Lưu ý: AWS khẳng định phần cứng dùng chung vẫn đáp ứng hầu hết chuẩn tuân thủ — dedicated thường là yêu cầu chính sách nội bộ hơn là yêu cầu pháp lý.

Ba lưu ý khi dùng tenancy: | Lưu ý | Chi tiết | |---|---| | Đặt ở cấp instance linh hoạt hơn cấp VPC | | | VPC dedicated ép MỌI instance | không đổi ngược được | | Một số loại instance không hỗ trợ dedicated | kiểm tra trước |

Ba lựa chọn cách ly khác: | Lựa chọn | Mức cách ly | |---|---| | Tài khoản AWS riêng | cách ly mạnh nhất về mặt quản trị | | VPC riêng | cách ly mạng | | Dedicated Instance | cách ly phần cứng |

Ba lưu ý về Nitro: | Lưu ý | Chi tiết | |---|---| | Hệ thống Nitro cách ly ở tầng phần cứng | | | AWS công bố kiến trúc bảo mật của Nitro | | | Nitro Enclaves cho dữ liệu cực nhạy cảm | |

Nitro Enclaves đáng biết:

Môi trường thực thi cách ly, không có lưu trữ,
  không có mạng ngoài, không có truy cập tương tác
    → kể cả người có quyền root trên instance
      cũng KHÔNG vào được enclave
        ↓
    Bảo vệ dữ liệu y tế ở mức cao hơn dedicated hardware

Và một lời khuyên: hãy xác nhận yêu cầu single-tenant đến từ đâu trước khi chọn. Nếu đó là chính sách nội bộ chứ không phải quy định bắt buộc, tài liệu bảo mật của hệ thống Nitro thường đủ để thuyết phục bộ phận tuân thủ — và khoản chênh lệch chi phí giữa phần cứng dùng chung và dedicated là đáng kể ở quy mô lớn.

Đáp án

D — Tạo Origin Access Identity (OAI) và cập nhật bucket policy của S3.

Vì sao đúng

Đề nêu yêu cầu rõ: người dùng chỉ truy cập được bucket QUA CloudFront, không truy cập trực tiếp.

Cơ chế:
    ① Tạo một danh tính đặc biệt (OAI) cho CloudFront
    ② Bucket policy CHỈ cho phép danh tính đó
    ③ Bật Block Public Access trên bucket
        ↓
    Gọi thẳng URL của S3 → Access Denied
    Gọi qua CloudFront → CloudFront ký request bằng OAI → được phép

Bucket policy tương ứng:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1ABC123"},
   "Action": "s3:GetObject",
   "Resource": "arn:aws:s3:::trang-tinh/*"}]}

Và bật Block Public Access:

aws s3api put-public-access-block --bucket trang-tinh   --public-access-block-configuration   BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Ba lợi ích của mẫu này: | Lợi ích | Chi tiết | |---|---| | Bucket hoàn toàn riêng tư | không có đường truy cập trực tiếp | | Kiểm soát tập trung ở CloudFront | WAF, signed URL, geo restriction | | Chi phí egress thấp hơn | CloudFront rẻ hơn S3 trực tiếp |

Và điểm mấu chốt về vì sao phải làm việc này:

Bucket công khai + CloudFront:
    → người dùng vẫn gọi thẳng URL của S3 được
    → BỎ QUA mọi kiểm soát ở CloudFront:
        ✗ không qua WAF
        ✗ không qua signed URL
        ✗ không qua giới hạn địa lý
        ✗ không hưởng giá egress rẻ

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

• **C. Tạo bucket policy chỉ cho phép IAM role gắn vào CloudFront distribution — đây là phương án gần nhất vì cũng dùng bucket policy để giới hạn, nhưng CloudFront distribution KHÔNG có IAM role gắn vào: nó dùng OAI (hoặc OAC) làm cơ chế danh tính, không phải instance profile hay execution role.
• **A. Làm cho bucket S3 công khai — ngược hoàn toàn với yêu cầu: bucket công khai nghĩa là ai cũng gọi thẳng được, bỏ qua CloudFront.
• **B. Cập nhật security group của bucket S3 để chỉ cho phép từ security group của CloudFront — S3 KHÔNG có security group: đó là khái niệm của VPC, áp cho ENI. S3 dùng bucket policy và IAM.

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

Đáp án là OAI, nhưng AWS đã thay nó bằng OAC từ tháng 8/2022 và khuyến nghị KHÔNG dùng OAI cho thiết kế mới.

Ba hạn chế của OAI khiến AWS thay nó:
    ✗ không dùng được với bucket mã hoá SSE-KMS
    ✗ không hỗ trợ tải lên qua CloudFront
    ✗ không hoạt động ở các Region ra mắt sau 2022

Cấu hình OAC:

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

Và bucket policy dùng service principal thay vì danh tính OAI:

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

(Đáp án D vẫn đúng theo các phương án cho sẵn — OAI vẫn hoạt động, chỉ là không nên dùng cho thiết kế mới.)

Ghi nhớ

Ba cách bảo vệ origin S3 phía sau CloudFront: | Cách | Trạng thái | |---|---| | Origin Access Control (OAC) | khuyến nghị | | Origin Access Identity (OAI) | legacy | | Bucket công khai | ❌ không bao giờ |

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

Dòng giữa là bẫy: dùng website endpoint làm origin thì không dùng được OAC/OAI, buộc phải để bucket công khai.

Ba tính năng bảo vệ nội dung của CloudFront: | Tính năng | Việc | |---|---| | Signed URL | một URL cho một tệp, có hạn | | Signed cookie | nhiều tệp cùng lúc | | Geo restriction | chặn theo quốc gia | | Field-level encryption | mã hoá trường nhạy cảm |

Signed URL và signed cookie — chọn cái nào:

Signed URL:    tải một tệp cụ thể (ví dụ một video)
Signed cookie: truy cập nhiều tệp (ví dụ cả thư viện ảnh)

Ba lợi ích của việc dùng CloudFront cho nội dung tĩnh: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp toàn cầu | đệm ở edge | | Giảm tải origin | | | Egress RẺ HƠN so với S3 trực tiếp | |

Ba cấu hình nên có: | Cấu hình | Chi tiết | |---|---| | Chuyển hướng HTTP sang HTTPS | ViewerProtocolPolicy | | Nén tự động | gzip, brotli | | Cache policy phù hợp | CachingOptimized cho tệp tĩnh |

Ba chính sách dựng sẵn: | Chính sách | Việc | |---|---| | CachingOptimized | đệm tối đa cho nội dung tĩnh | | CachingDisabled | cho API và tải lên | | CachingOptimizedForUncompressedObjects | |

Ba lưu ý về vô hiệu hoá cache: | Lưu ý | Chi tiết | |---|---| | 1.000 đường dẫn miễn phí mỗi tháng | sau đó tính phí | | Dùng phiên bản trong tên tệp thay vì invalidation | app.a1b2c3.js | | Invalidation mất vài phút | |

Cách thứ hai tốt hơn:

Đổi tên tệp mỗi lần build (có hash nội dung)
    → URL mới → không cần vô hiệu hoá cache
    → và người dùng nhận bản mới ngay

Ba lưu ý về bảo mật bổ sung: | Biện pháp | Chi tiết | |---|---| | AWS WAF trên distribution | lọc tấn công | | Response headers policy | thêm HSTS, CSP | | Chứng chỉ ACM ở us-east-1 | cho tên miền tuỳ chỉnh |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp = đệm không hiệu quả | | 4xxErrorRate | thường là quyền hoặc khoá sai | | OriginLatency | origin chậm |

Và một lời khuyên: hãy dùng OAC thay vì OAI cho mọi thiết lập mới. Nếu bucket của bạn dùng SSE-KMS — điều rất phổ biến ngày nay — thì OAI đơn giản là không hoạt động, và triệu chứng sẽ là lỗi 403 mà bucket policy trông hoàn toàn đúng.

Đáp án

A và D.

• A — Spot Instance là năng lực EC2 dư, tiết kiệm tới 90% so với On-Demand, có thể bị thu hồi với thông báo 2 phút
• D — Spot fleet gồm một tập Spot Instance và tuỳ chọn có cả On-Demand Instance để đạt dung lượng mục tiêu

Vì sao đúng

A — mô tả chính xác Spot Instance:

Spot Instance:
    ✓ dùng năng lực DƯ của AWS
    ✓ rẻ hơn On-Demand tới 90%
    ✓ AWS thu hồi khi cần năng lực, báo trước 2 PHÚT

Con số 2 phút là chi tiết hay được hỏi:

curl -s http://169.254.169.254/latest/meta-data/spot/instance-action

404 → chưa bị thu hồi
JSON có action và time → đã có thông báo, còn ~2 phút

D — Spot fleet CÓ THỂ gồm cả On-Demand:

Spot fleet / EC2 Fleet:
    → khai TARGET CAPACITY
    → chia thành phần Spot và phần On-Demand
        ↓
    OnDemandTargetCapacity: phần đảm bảo
    SpotTargetCapacity:     phần rẻ

Đây là điểm phân biệt với phương án E:

{"TargetCapacitySpecification": {
   "TotalTargetCapacity": 20,
   "OnDemandTargetCapacity": 4,
   "SpotTargetCapacity": 16,
   "DefaultTargetCapacityType": "spot"}}

4 máy On-Demand làm nền đảm bảo
    + 16 máy Spot cho phần còn lại
        ↓
    Fleet KHÔNG chỉ có Spot — đó là lý do E sai

Và trong Auto Scaling group, cơ chế tương đương là mixed instances policy:

{"InstancesDistribution": {
   "OnDemandBaseCapacity": 4,
   "OnDemandPercentageAboveBaseCapacity": 0,
   "SpotAllocationStrategy": "price-capacity-optimized"}}

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

• **E. Spot fleet CHỈ gồm Spot Instance — đây là phương án gần nhất và chỉ khác D ở một từ, nhưng đó là từ quyết định: fleet tuỳ chọn thêm On-Demand để đảm bảo phần dung lượng nền.
• **B. Spot FLEET là năng lực EC2 dư bị thu hồi với thông báo 2 phút — nhầm khái niệm: Spot Instance mới là năng lực dư. Spot fleet là một tập hợp instance được quản lý, không phải một loại năng lực.
• **C. Spot fleet cho phép yêu cầu Spot Instance trong 1–6 giờ để tránh bị gián đoạn — mô tả Spot blocks (defined duration), một tính năng ĐÃ NGỪNG: AWS không còn nhận khách hàng mới cho Spot blocks từ cuối 2021. Và nó vốn là tính năng của Spot request, không phải của fleet.

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

Phương án C nhắc tới "Spot blocks" (Spot Instances with a defined duration) — tính năng AWS đã ngừng cung cấp.

Spot blocks cho phép giữ Spot Instance 1–6 giờ không bị thu hồi
    → AWS ngừng nhận khách hàng mới từ tháng 12/2021
        ↓
    Ngày nay muốn đảm bảo không bị gián đoạn:
        → dùng On-Demand hoặc Capacity Reservation
        → hoặc thiết kế ứng dụng chịu được thu hồi

Đây là lý do phương án C sai theo cả hai nghĩa: nó gán sai tính năng cho Spot fleet, và tính năng đó không còn tồn tại.

Ghi nhớ

Spot Instance và Spot fleet — bảng phân biệt: | | Spot Instance | Spot fleet / EC2 Fleet | |---|---|---| | Là gì | MỘT instance dùng năng lực dư | TẬP HỢP instance quản lý theo dung lượng mục tiêu | | Gồm On-Demand | ❌ | ✅ tuỳ chọn | | Nhiều loại instance | một | nhiều loại, nhiều AZ |

Ba thành phần của EC2 Fleet: | Thành phần | Việc | |---|---| | Launch template | cấu hình gốc | | Overrides | các loại instance và subnet thay thế | | Target capacity | tổng dung lượng cần, chia Spot/On-Demand |

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 | ít bị thu hồi nhất | | lowest-price | rẻ nhất, hay bị thu hồi | | diversified | trải đều qua các pool |

Ba cơ chế xử lý thu hồi: | Cơ chế | Chi tiết | |---|---| | Thông báo trước 2 phút | qua metadata hoặc EventBridge | | 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 |

Bắt thông báo bằng EventBridge:

{"source": ["aws.ec2"],
 "detail-type": ["EC2 Spot Instance Interruption Warning"]}

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 | | | Linh hoạt về thế hệ và cỡ | |

Ba trường hợp phù hợp với Spot: | Trường hợp | Chi tiết | |---|---| | Xử lý theo lô, phân tích dữ liệu | | | CI/CD và kiểm thử | | | Container stateless | Fargate Spot, EKS |

Ba trường hợp KHÔNG dùng Spot: | Trường hợp | Lý do | |---|---| | Database sản xuất | mất dữ liệu | | Ứng dụng giữ trạng thái trong bộ nhớ | | | Tải phải chạy liên tục không đứt | |

Ba cách đảm bảo năng lực khi cần: | Cách | Chi tiết | |---|---| | On-Demand Capacity Reservation | giữ chỗ ở một AZ cụ thể | | Phần On-Demand trong fleet | ← đáp án D | | Reserved Instance với capacity reservation | |

Capacity Reservation đáng biết:

aws ec2 create-capacity-reservation   --instance-type m5.large --instance-platform Linux/UNIX   --availability-zone ap-northeast-1a --instance-count 10

Giữ chỗ năng lực dù chưa chạy instance
    → tính phí như đang chạy
        ↓
    Dùng cho sự kiện quan trọng biết trước

Ba lưu ý về Spot price: | Lưu ý | Chi tiết | |---|---| | Từ 2017, giá thay đổi DẦN theo cung cầu | không còn đấu giá đột biến | | Không cần đặt max price | mặc định là giá On-Demand | | Xem lịch sử giá để đánh giá | |

aws ec2 describe-spot-price-history   --instance-types m5.large --product-descriptions "Linux/UNIX"   --start-time 2026-08-01 --max-items 20

Ba lưu ý về Spot với container: | Dịch vụ | Hỗ trợ Spot | |---|---| | ECS trên EC2 | ✅ qua ASG | | Fargate Spot | ✅ rẻ hơn ~70% | | EKS | ✅ qua managed node group |

Và một lời khuyên: hãy luôn đặt một phần On-Demand làm nền trong fleet, đừng chạy 100% Spot cho tải phục vụ người dùng. Một đợt thiếu năng lực Spot có thể thu hồi toàn bộ đội máy trong vài phút — và phần nền On-Demand là thứ duy nhất giữ dịch vụ sống qua khoảnh khắc đó.

Đáp án

C và E.

• C — enableDnsHostnames
• E — enableDnsSupport

Vì sao đúng

Private hosted zone của Route 53 chỉ hoạt động khi VPC bật cả hai thuộc tính DNS này.

enableDnsSupport:
    → VPC dùng máy chủ DNS của AWS (địa chỉ .2 trong dải VPC)
    → nếu TẮT: không phân giải được tên nào, kể cả private hosted zone

enableDnsHostnames:
    → instance được cấp tên DNS
    → và VPC hỗ trợ đầy đủ tính năng phân giải tên riêng
        ↓
    Thiếu MỘT trong hai → private hosted zone KHÔNG hoạt động

Bật:

aws ec2 modify-vpc-attribute --vpc-id vpc-abc --enable-dns-support
aws ec2 modify-vpc-attribute --vpc-id vpc-abc --enable-dns-hostnames

Kiểm tra trạng thái:

aws ec2 describe-vpc-attribute --vpc-id vpc-abc --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-abc --attribute enableDnsHostnames

Tạo private hosted zone:

aws route53 create-hosted-zone   --name noibo.vidu.com   --caller-reference $(date +%s)   --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abc   --hosted-zone-config PrivateZone=true

Và mặc định của hai thuộc tính: | Cách tạo VPC | enableDnsSupport | enableDnsHostnames | |---|---|---| | VPC mặc định của tài khoản | true | true | | VPC tự tạo | true | false ⚠ |

Dòng cuối là nguyên nhân sự cố phổ biến:

Tạo VPC mới bằng CLI hoặc CloudFormation
    → enableDnsHostnames MẶC ĐỊNH LÀ FALSE
        ↓
    Private hosted zone không phân giải được
    → và không có thông báo lỗi nào rõ ràng

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

• A. enableDnsDomain — đây là phương án gần nhất vì tên nghe rất giống thuộc tính thật, nhưng nó không tồn tại: VPC chỉ có hai thuộc tính DNS là enableDnsSupport và enableDnsHostnames.
• B. enableVpcSupport — không phải thuộc tính có thật.
• D. enableVpcHostnames — cũng không tồn tại; tên đúng là enableDnsHostnames.

Ghi nhớ

Hai thuộc tính DNS của VPC — bảng phải thuộc: | Thuộc tính | Việc | Mặc định (VPC tự tạo) | |---|---|---| | enableDnsSupport | dùng máy chủ DNS của AWS trong VPC | true | | enableDnsHostnames | cấp tên DNS cho instance | false |

Ba tính năng cần cả hai thuộc tính: | Tính năng | Chi tiết | |---|---| | Route 53 private hosted zone | ← câu này | | Private DNS của interface VPC endpoint | | | Tên DNS công khai của instance | |

Địa chỉ máy chủ DNS trong VPC:

Địa chỉ cơ sở của VPC + 2
    → VPC 10.0.0.0/16 → DNS ở 10.0.0.2
    → hoặc dùng địa chỉ dành riêng 169.254.169.253

Ba loại hosted zone của Route 53: | Loại | Phạm vi | |---|---| | Public hosted zone | Internet công cộng | | Private hosted zone | CHỈ trong VPC đã liên kết | | — | một tên miền có thể có cả hai (split-horizon DNS) |

Split-horizon DNS đáng biết:

vidu.com — public zone  → trỏ tới ALB công khai
vidu.com — private zone → trỏ tới IP riêng trong VPC
        ↓
    Cùng tên miền, khác kết quả tuỳ người hỏi từ đâu
    → private zone THẮNG khi hỏi từ trong VPC

Ba đặc điểm của private hosted zone: | Đặc điểm | Chi tiết | |---|---| | Liên kết với một hoặc NHIỀU VPC | kể cả khác Region | | Liên kết VPC ở tài khoản khác được | cần uỷ quyền | | Không phân giải được từ ngoài VPC | |

Liên kết thêm VPC:

aws route53 associate-vpc-with-hosted-zone   --hosted-zone-id Z1ABC   --vpc VPCRegion=us-east-1,VPCId=vpc-def

Ba cách phân giải DNS từ on-premises: | Cách | Chi tiết | |---|---| | Route 53 Resolver inbound endpoint | on-premises hỏi vào AWS | | Route 53 Resolver outbound endpoint | AWS hỏi ra on-premises | | Resolver rule | định tuyến truy vấn theo tên miền |

Đây là cách giải quyết DNS lai:

Máy tại chỗ cần phân giải noibo.vidu.com (private zone)
    → tạo inbound endpoint trong VPC
    → máy chủ DNS tại chỗ chuyển tiếp truy vấn tới đó

Ba lưu ý khi tạo VPC bằng IaC: | Lưu ý | Chi tiết | |---|---| | Khai rõ EnableDnsHostnames: true | mặc định là false | | Khai rõ EnableDnsSupport: true | cho chắc chắn | | Kiểm tra sau khi tạo | |

Resources:
  VPCChinh:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true

Ba triệu chứng khi thiếu thuộc tính DNS: | Triệu chứng | Nguyên nhân | |---|---| | Tên trong private zone không phân giải | thiếu enableDnsHostnames | | VPC endpoint private DNS không hoạt động | cùng lý do | | Instance không có tên DNS | cùng lý do |

Ba lưu ý về Route 53 Resolver: | Lưu ý | Chi tiết | |---|---| | Có sẵn trong mọi VPC | không phải bật | | Endpoint tính phí theo giờ và theo truy vấn | | | Query logging ghi mọi truy vấn DNS | hữu ích cho bảo mật |

Query logging đáng bật:

aws route53resolver create-resolver-query-log-config   --name log-dns --destination-arn <arn-log-group>

Ghi lại mọi truy vấn DNS từ VPC
    → phát hiện được malware gọi tới tên miền lạ

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Hosted zone | ~0,50 USD/tháng | | Truy vấn | ~0,40 USD mỗi triệu | | Resolver endpoint | ~0,125 USD/giờ mỗi ENI |

Và một lời khuyên: hãy kiểm tra enableDnsHostnames đầu tiên khi private hosted zone không hoạt động. Nó mặc định là false với mọi VPC bạn tự tạo, và triệu chứng là tên miền đơn giản không phân giải được — không có lỗi, không có cảnh báo, chỉ là NXDOMAIN.

Đáp án

D — Provisioned IOPS SSD (io1 hoặc io2).

Vì sao đúng

Đề nêu yêu cầu cụ thể: EBS Multi-Attach, và tính năng này chỉ hỗ trợ một họ volume duy nhất.

EBS Multi-Attach:
    ✓ io1
    ✓ io2 và io2 Block Express
    ✗ gp2, gp3
    ✗ st1, sc1
        ↓
    Không có lựa chọn nào khác

Gắn một volume vào nhiều instance:

aws ec2 create-volume --availability-zone ap-northeast-1a   --size 500 --volume-type io2 --iops 20000 --multi-attach-enabled

aws ec2 attach-volume --volume-id vol-0abc --instance-id i-0aaa --device /dev/sdf
aws ec2 attach-volume --volume-id vol-0abc --instance-id i-0bbb --device /dev/sdf

⚠ Và điều kiện quan trọng nhất: hệ thống tệp phải CLUSTER-AWARE.

Gắn cùng volume vào hai instance với ext4 hoặc XFS:
    → mỗi máy cache metadata riêng
    → cả hai cùng ghi vào cùng khối
        ↓
    HỎNG hệ thống tệp, mất dữ liệu
        ↓
    Multi-Attach chỉ cho phép gắn — nó KHÔNG điều phối việc ghi

Hệ thống tệp dùng được: | Loại | Ví dụ | |---|---| | Cluster file system | GFS2, OCFS2, Veritas CFS | | Ứng dụng tự quản lý I/O | Oracle RAC | | Truy cập ở mức khối thô | không qua file system |

Ba giới hạn của Multi-Attach: | Giới hạn | Giá trị | |---|---| | Số instance tối đa | 16 | | Phạm vi | CÙNG một Availability Zone | | Loại instance | chỉ Nitro |

Đề nói rõ "in the same Availability Zone" — khớp với giới hạn thứ hai.

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

• **B. General-purpose SSD (gp2/gp3) — đây là phương án gần nhất và là loại volume phổ biến nhất, nhưng nó KHÔNG hỗ trợ Multi-Attach: tính năng này chỉ có ở họ io.
• **A. Throughput Optimized HDD (st1) — không hỗ trợ Multi-Attach, và IOPS rất thấp.
• **C. Cold HDD (sc1) — cũng không hỗ trợ, và là loại chậm nhất.

Ghi nhớ

Các loại EBS và Multi-Attach — bảng phải thuộc: | Loại | Multi-Attach | |---|---| | io2, io2 Block Express | ✅ | | io1 | ✅ | | gp3, gp2 | ❌ | | st1, sc1 | ❌ |

Ba giới hạn của Multi-Attach: | Giới hạn | Chi tiết | |---|---| | Tối đa 16 instance | | | CÙNG Availability Zone | không xuyên AZ | | Chỉ instance dựa trên Nitro | |

⚠ Ba lưu ý bắt buộc khi dùng Multi-Attach: | Lưu ý | Chi tiết | |---|---| | PHẢI dùng cluster file system | ext4/XFS sẽ HỎNG dữ liệu | | Không hỗ trợ khởi động từ volume đó | | | Bật I/O fencing nếu ứng dụng hỗ trợ | tránh split-brain |

Ba lựa chọn lưu trữ chia sẻ — bảng so sánh: | Lựa chọn | Giao thức | Nhiều AZ | Dễ dùng | |---|---|---|---| | EBS Multi-Attach | khối | ❌ một AZ | khó — cần cluster FS | | EFS | NFS (POSIX) | ✅ | dễ nhất | | FSx for Lustre | Lustre | một AZ | vừa | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | ✅ | vừa | | S3 | object | ✅ | dễ (cần sửa mã) |

Với hầu hết trường hợp cần chia sẻ dữ liệu, EFS đơn giản hơn Multi-Attach rất nhiều.

Ba trường hợp thật sự cần Multi-Attach: | Trường hợp | Lý do | |---|---| | Oracle RAC | đòi lưu trữ khối chia sẻ | | Ứng dụng cluster cũ chuyển lên đám mây | không sửa được kiến trúc | | Cần độ trễ thấp nhất của lưu trữ khối | |

Ba đặc điểm của io2 so với io1: | Đặc điểm | io1 | io2 | |---|---|---| | Độ bền | 99,8–99,9% | 99,999% | | IOPS mỗi GB | 50 | 500 | | Giá | — | BẰNG io1 |

io2 tốt hơn io1 ở mọi mặt với cùng giá — không có lý do chọn io1 cho thiết kế mới.

io2 Block Express còn mạnh hơn: | Chỉ số | Giá trị | |---|---| | IOPS tối đa | 256.000 | | Thông lượng | 4.000 MB/giây | | Dung lượng | tới 64 TiB |

Ba lưu ý về hiệu năng khi nhiều instance cùng dùng: | Lưu ý | Chi tiết | |---|---| | IOPS được CHIA SẺ giữa các instance | không nhân lên | | Cấp đủ IOPS cho tổng nhu cầu | | | Băng thông EBS của instance cũng là trần | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | io2 tính phí dung lượng CỘNG phí IOPS | ~0,065 USD mỗi IOPS-tháng | | 20.000 IOPS ≈ 1.300 USD/tháng | chỉ phần IOPS | | Multi-Attach không tính phí thêm | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | VolumeQueueLength | cao liên tục = thiếu IOPS | | VolumeReadOps + VolumeWriteOps | IOPS thực tế | | VolumeIdleTime | |

Ba cách kiểm tra trước khi triển khai: | Việc | Chi tiết | |---|---| | Xác nhận ứng dụng hỗ trợ lưu trữ chia sẻ | | | Chọn và cấu hình cluster file system | | | Thử với dữ liệu không quan trọng trước | |

Và một lời khuyên: hãy kiểm tra xem EFS có đáp ứng được nhu cầu không trước khi chọn Multi-Attach. Multi-Attach đòi hệ thống tệp cluster, giới hạn trong một AZ, và một sai sót cấu hình dẫn thẳng tới hỏng dữ liệu — trong khi EFS cho chia sẻ POSIX qua nhiều AZ mà không có rủi ro nào trong số đó.

Đáp án

A và B.

• A — RDS tự động kích hoạt chuyển đổi sang standby khi database chính hỏng vì bất kỳ lý do gì
• B — RDS áp bản vá hệ điều hành bằng cách bảo trì standby trước, thăng cấp standby thành primary, rồi bảo trì primary cũ (nay trở thành standby mới)

Vì sao đúng

A — chuyển đổi là TỰ ĐỘNG:

RDS phát hiện primary không phản hồi
    → tự thăng cấp standby
    → cập nhật bản ghi DNS của endpoint
        ↓
    Thời gian: thường 60–120 giây
    → KHÔNG cần can thiệp thủ công

B — mô tả chính xác quy trình bảo trì luân phiên:

① Vá lỗi hệ điều hành trên STANDBY (primary vẫn phục vụ)
② Chuyển đổi: standby đã vá → thành primary mới
③ Vá lỗi trên primary cũ → thành standby mới
        ↓
    Thời gian ngừng chỉ bằng thời gian CHUYỂN ĐỔI,
    không phải thời gian vá lỗi

Đây là lợi ích lớn của Multi-AZ mà nhiều người không biết:

Single-AZ: vá lỗi = ngừng suốt quá trình vá (có thể vài phút)
Multi-AZ:  vá lỗi = ngừng chỉ trong lúc chuyển đổi (~60 giây)

Bật Multi-AZ:

aws rds modify-db-instance --db-instance-identifier db-chinh   --multi-az --apply-immediately

Và thử chuyển đổi:

aws rds reboot-db-instance --db-instance-identifier db-chinh   --force-failover

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

• **D. Cập nhật được sao chép BẤT ĐỒNG BỘ sang standby để giữ đồng bộ — đây là phương án gần nhất và chỉ sai một từ, nhưng đó là từ quyết định: Multi-AZ sao chép ĐỒNG BỘ. Đó là lý do RPO bằng 0 — mọi giao dịch đã commit đều có ở standby. (Read replica mới là bất đồng bộ.)
• **C. Với automated backup, I/O bị tạm dừng trên PRIMARY vì backup không lấy từ standby — ngược với thực tế: với Multi-AZ, backup được lấy từ STANDBY chính là để tránh treo I/O trên primary. (Với Single-AZ thì I/O có thể bị treo trong giây lát.)
• **E. Standby của Multi-AZ có thể phục vụ đọc để mở rộng — sai: standby của Multi-AZ instance KHÔNG phục vụ bất kỳ lưu lượng nào. Muốn mở rộng đọc phải dùng read replica.

Ghi nhớ

Bốn đặc điểm của RDS Multi-AZ — bảng phải thuộc: | Đặc điểm | Đúng/Sai | |---|---| | Sao chép ĐỒNG BỘ | ✅ | | Chuyển đổi TỰ ĐỘNG | ✅ | | Standby phục vụ đọc | ❌ (Multi-AZ instance) | | Backup lấy từ standby | ✅ |

Multi-AZ và Read Replica — bảng phân biệt: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | RPO | 0 | giây tới phút | | Chuyển đổi | TỰ ĐỘNG | thủ công (promote) | | Phục vụ đọc | ❌ | ✅ | | Phạm vi | cùng Region | cùng hoặc khác Region |

Hai kiểu triển khai Multi-AZ: | Kiểu | Đặc điểm | |---|---| | Multi-AZ DB instance | 1 standby, KHÔNG phục vụ đọc, chuyển đổi 60–120 giây | | Multi-AZ DB cluster | 2 standby CÓ phục vụ đọc, chuyển đổi dưới 35 giây |

Multi-AZ DB cluster hỗ trợ MySQL và PostgreSQL — nếu dùng nó thì phương án E sẽ đúng.

Ba tình huống kích hoạt chuyển đổi: | Tình huống | Chi tiết | |---|---| | Primary hỏng | phần cứng hoặc phần mềm | | AZ mất kết nối | | | Bảo trì có kế hoạch | ← đáp án B |

Ba loại bảo trì và tác động: | Loại | Multi-AZ giảm ngừng | |---|---| | Vá lỗi hệ điều hành | ✅ luân phiên ← đáp án B | | Đổi cỡ instance | ✅ | | Nâng cấp phiên bản ENGINE | ❌ cả hai cùng lúc |

Dòng cuối là ngoại lệ quan trọng — nâng cấp engine vẫn gây ngừng.

Ba đặc điểm của automated backup: | Đặc điểm | Chi tiết | |---|---| | Snapshot hằng ngày + transaction log | PITR trong 1–35 ngày | | Với Multi-AZ, lấy từ STANDBY | không ảnh hưởng primary | | BỊ XOÁ khi xoá instance | trừ final snapshot |

Manual snapshot khác hẳn:

Automated backup: xoá theo instance, giữ tối đa 35 ngày
Manual snapshot:  giữ VÔ THỜI HẠN, sống sót khi xoá instance
        ↓
    Với dữ liệu quan trọng, nên có cả hai

Ba việc Multi-AZ KHÔNG bảo vệ: | Không bảo vệ | Cách bảo vệ | |---|---| | Lỗi con người (xoá nhầm bảng) | PITR | | Thảm hoạ cấp Region | cross-Region replica hoặc backup | | Dữ liệu hỏng do ứng dụng | PITR |

Ba yêu cầu với ứng dụng để chịu được chuyển đổi: | Yêu cầu | Chi tiết | |---|---| | Logic thử lại kết nối | | | KHÔNG cache DNS quá lâu | JVM là ca hay gặp | | Connection pool kiểm tra sức khoẻ | |

Ba cách giảm tác động của chuyển đổi: | Cách | Chi tiết | |---|---| | RDS Proxy | giảm thời gian ngừng tới 66% | | Multi-AZ DB cluster | chuyển đổi dưới 35 giây | | Aurora | thường dưới 30 giây |

Ba lưu ý về maintenance window: | Lưu ý | Chi tiết | |---|---| | Đặt vào giờ thấp điểm | | | Xem bản vá đang chờ | describe-pending-maintenance-actions | | Áp sớm được nếu muốn chủ động | |

aws rds apply-pending-maintenance-action   --resource-identifier <arn-db>   --apply-action system-update --opt-in-type immediate

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Multi-AZ tốn GẤP ĐÔI chi phí instance | | | Không tính phí truyền dữ liệu giữa primary và standby | | | Đáng giá cho mọi database sản xuất | |

Và một lời khuyên: hãy nhớ rằng backup của Multi-AZ được lấy từ standby. Đây là một trong những khác biệt kỹ thuật cụ thể hay được hỏi, và nó cũng là lý do thực tế để bật Multi-AZ ngay cả khi bạn chưa lo về sẵn sàng — nó loại bỏ hẳn ảnh hưởng của việc sao lưu lên hiệu năng của database đang phục vụ.

Đáp án

A — Dùng AWS Batch xử lý công việc ảnh, điều phối luồng bằng AWS Step Functions, lưu tệp đầu ra vào Amazon S3.

Vì sao đúng

Đề nêu bốn yêu cầu, và bộ ba này đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Xử lý khối lượng lớn công việc biến đổi ảnh | AWS Batch quản lý hàng đợi và năng lực | | Tự co giãn, không quản máy chủ | Batch tự cấp và thu hồi năng lực | | Điều phối thứ tự tác vụ và trạng thái công việc | Step Functions | | Tệp đầu ra lớn | S3, không giới hạn dung lượng |

AWS Batch giải quyết đúng bài toán xử lý theo lô:

AWS Batch tự lo:
    ✓ hàng đợi công việc có ưu tiên
    ✓ chọn loại instance phù hợp
    ✓ cấp phát và thu hồi năng lực tự động
    ✓ thử lại khi công việc thất bại
    ✓ hỗ trợ Spot để tiết kiệm
        ↓
    Bạn chỉ định nghĩa CÔNG VIỆC, không quản hạ tầng

Và Step Functions lo phần điều phối:

"improve workflow automation to handle TASK SEQUENCING
 and JOB STATE TRANSITIONS"
        ↓
    Step Functions:
        ✓ máy trạng thái trực quan
        ✓ xử lý lỗi và thử lại khai báo được
        ✓ chạy song song, rẽ nhánh điều kiện
        ✓ tích hợp sẵn với AWS Batch

Định nghĩa luồng:

{"StartAt": "TienXuLy",
 "States": {
   "TienXuLy": {
     "Type": "Task",
     "Resource": "arn:aws:states:::batch:submitJob.sync",
     "Parameters": {"JobDefinition": "tien-xu-ly",
                    "JobName": "tien-xu-ly", "JobQueue": "hang-doi-anh"},
     "Next": "BienDoi"},
   "BienDoi": {
     "Type": "Task",
     "Resource": "arn:aws:states:::batch:submitJob.sync",
     "Parameters": {"JobDefinition": "bien-doi-anh",
                    "JobName": "bien-doi", "JobQueue": "hang-doi-anh"},
     "Retry": [{"ErrorEquals": ["States.ALL"], "MaxAttempts": 3,
                "BackoffRate": 2.0}],
     "End": true}}}

.sync là chi tiết quan trọng — Step Functions chờ job Batch hoàn tất trước khi sang bước tiếp theo.

Và vì sao S3 chứ không phải EBS:

Tệp đầu ra LỚN, khối lượng tăng nhanh
    → S3 không giới hạn dung lượng
    → rẻ hơn EBS nhiều lần
    → mọi công việc ở mọi AZ đều truy cập được

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

• **D. EKS với worker node EC2 tự quản + SQS + lưu vào EBS — đây là phương án gần nhất vì cũng là kiến trúc xử lý theo lô hợp lệ, nhưng nó có công vận hành cao nhất: phải quản lý cụm Kubernetes, vá node, nâng cấp phiên bản. Và EBS không phù hợp cho tệp đầu ra lớn dùng chung.
• **C. Lambda + EC2 Spot xử lý, lưu vào Amazon FSx — Lambda giới hạn 15 phút không phù hợp cho biến đổi ảnh lớn, và trộn hai mô hình tính toán làm kiến trúc phức tạp không cần thiết.
• **B. ASG với đội máy TĨNH + Step Functions, lưu vào EBS — "static fleet" đi ngược yêu cầu tự co giãn, và EBS không phải kho dùng chung.

Ghi nhớ

Ba dịch vụ xử lý theo lô của AWS — bảng phải thuộc: | Dịch vụ | Đặc điểm | |---|---| | AWS Batch | hàng đợi công việc + tự quản năng lực ← câu này | | AWS Lambda | ngắn (dưới 15 phút), sự kiện | | Amazon EMR | phân tích dữ liệu lớn (Spark, Hadoop) | | ECS/EKS tự dựng | linh hoạt nhất, công vận hành cao nhất |

Từ khoá nhận diện:

"batch jobs", "queue with priorities", "no infrastructure management" → AWS Batch "workflow orchestration", "state transitions", "task sequencing" → Step Functions "event-driven, short tasks" → Lambda

Bốn khái niệm của AWS Batch: | Khái niệm | Việc | |---|---| | Compute environment | loại và số lượng năng lực (EC2, Fargate, Spot) | | Job queue | hàng đợi có độ ưu tiên | | Job definition | container image, vCPU, bộ nhớ, biến môi trường | | Job | một lần chạy |

Ba loại compute environment: | Loại | Đặc điểm | |---|---| | Managed EC2 | Batch tự cấp và thu hồi instance | | Managed Fargate | hoàn toàn serverless | | Unmanaged | bạn tự quản |

Fargate là lựa chọn ít công vận hành nhất:

{"type": "MANAGED", "computeResources": {
   "type": "FARGATE", "maxvCpus": 256,
   "subnets": ["subnet-a","subnet-c"],
   "securityGroupIds": ["sg-abc"]}}

Và Spot giảm chi phí đáng kể:

{"type": "SPOT", "bidPercentage": 100,
 "allocationStrategy": "SPOT_CAPACITY_OPTIMIZED"}

Xử lý ảnh theo lô chịu được gián đoạn
    → Batch tự thử lại job bị thu hồi
        ↓
    Tiết kiệm tới 90%

Ba tính năng của Step Functions: | Tính năng | Chi tiết | |---|---| | Retry và Catch khai báo | không viết mã xử lý lỗi | | Map state | xử lý song song nhiều phần tử | | Tích hợp trực tiếp với 200+ dịch vụ AWS | |

Distributed Map rất mạnh cho xử lý ảnh hàng loạt:

{"Type": "Map", "ItemProcessor": {"ProcessorConfig": {"Mode": "DISTRIBUTED"}},
 "ItemReader": {"Resource": "arn:aws:states:::s3:listObjectsV2",
                "Parameters": {"Bucket": "anh-dau-vao"}},
 "MaxConcurrency": 1000}

Đọc danh sách object từ S3
    → xử lý song song tới 10.000 nhánh
        ↓
    Không phải tự viết logic chia việc

Hai loại workflow của Step Functions: | Loại | Đặc điểm | |---|---| | Standard | tới 1 năm, đúng một lần, có lịch sử đầy đủ | | Express | tới 5 phút, thông lượng rất cao, rẻ hơn nhiều |

Với xử lý ảnh chạy lâu, Standard là lựa chọn đúng.

Ba lưu ý về job definition: | Lưu ý | Chi tiết | |---|---| | Dùng container image trong ECR | | | Khai đúng vCPU và bộ nhớ | ảnh hưởng chi phí và tốc độ | | Đặt timeout | tránh job treo tốn tiền |

Ba lưu ý về hàng đợi ưu tiên: | Lưu ý | Chi tiết | |---|---| | Nhiều hàng đợi trỏ tới cùng compute environment | | | Priority cao hơn được lập lịch trước | | | Dùng để tách khách VIP và khách thường | |

Ba lưu ý về S3 cho tệp đầu ra: | Lưu ý | Chi tiết | |---|---| | Multipart upload cho tệp lớn | | | Lifecycle chuyển tệp cũ sang lớp rẻ | | | AbortIncompleteMultipartUpload | dọn phần dở dang |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Số job ở trạng thái RUNNABLE | tồn đọng — thiếu năng lực | | Tỷ lệ job FAILED | | | Thời gian từ submit tới hoàn tất | |

Ba lựa chọn thay thế cho biến đổi ảnh: | Lựa chọn | Khi nào | |---|---| | AWS Batch | ← câu này, tệp lớn, chạy lâu | | Lambda | ảnh nhỏ, dưới 15 phút | | S3 Object Lambda | biến đổi khi ĐỌC, không lưu bản thứ hai |

Và một lời khuyên: hãy dùng Fargate làm compute environment nếu công việc không cần GPU hay ổ cục bộ lớn. Nó bỏ hẳn phần quản lý instance, và với yêu cầu "least operational overhead" thì đó là khác biệt thật — bạn không còn phải nghĩ tới AMI, vá lỗi, hay kích thước máy nữa.