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

Đáp án

A — Chuyển cụm sang Amazon EKS và database sang Amazon DocumentDB (tương thích MongoDB).

Vì sao đúng

Đề nêu ba ràng buộc, và cặp EKS + DocumentDB là lựa chọn duy nhất thoả cả ba: | Ràng buộc | Cơ chế | |---|---| | Ứng dụng chạy trên KUBERNETES | EKS là Kubernetes được quản lý | | CẤM mọi thay đổi mã nguồn | DocumentDB tương thích API MongoDB — driver cũ dùng nguyên | | Giảm công vận hành | cả hai đều là dịch vụ được quản lý |

Điểm mấu chốt là ràng buộc "không được sửa mã":

Ứng dụng đang dùng driver MongoDB
    ↓
DocumentDB hiểu giao thức của MongoDB
    → đổi chuỗi kết nối là xong
    → KHÔNG sửa một dòng mã nào

Và cụm tự quản lý → EKS là bước chuyển tự nhiên nhất:

Kubernetes tự quản lý:
    bạn lo control plane, etcd, vá lỗi, nâng cấp, sao lưu

EKS:
    AWS lo TOÀN BỘ control plane
    → manifest, Helm chart, kubectl giữ nguyên
    → ứng dụng không biết gì đã đổi

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

• **C. Chuyển sang EKS Anywhere và database sang DynamoDB — đây là phương án gần nhất và có phần Kubernetes đúng, nhưng nó sai ở hai chỗ: EKS Anywhere chạy trên hạ tầng CỦA BẠN — không giảm công vận hành mà còn ngược lại. Và DynamoDB có API hoàn toàn khác MongoDB — chuyển sang đó bắt buộc viết lại toàn bộ tầng truy cập dữ liệu, vi phạm ràng buộc cấm sửa mã.
• **B. Chuyển sang ECS Anywhere và database sang Aurora Serverless — sai cả hai: ECS không phải Kubernetes (phải viết lại toàn bộ định nghĩa triển khai), ECS Anywhere vẫn chạy trên máy của bạn, và Aurora là cơ sở dữ liệu quan hệ — chuyển từ MongoDB sang đó là viết lại mô hình dữ liệu và mọi truy vấn.
• **D. Chuyển sang ECS với image trong ECR và database sang Amazon Neptune — sai cả hai: ECS không phải Kubernetes, và Neptune là cơ sở dữ liệu ĐỒ THỊ dùng Gremlin hoặc SPARQL — khác MongoDB hoàn toàn về cả mô hình lẫn ngôn ngữ truy vấn.

Ghi nhớ

Ánh xạ cơ sở dữ liệu tại chỗ sang dịch vụ AWS — bảng cần thuộc: | Nguồn | Đích tương thích | |---|---| | MongoDB | Amazon DocumentDB | | Cassandra | Amazon Keyspaces | | Redis | ElastiCache for Redis / MemoryDB | | Neo4j (đồ thị) | Amazon Neptune | | MySQL, PostgreSQL | RDS hoặc Aurora | | Oracle, SQL Server | RDS (hoặc chuyển sang Aurora qua SCT) | | Bảng khoá–giá trị tự viết | DynamoDB |

Quy tắc nhận diện: "không được sửa mã" → tìm dịch vụ TƯƠNG THÍCH API, không phải dịch vụ "tương đương chức năng".

Bốn cách chạy container trên AWS: | Cách | Kubernetes | Hạ tầng | |---|---|---| | EKS | ✅ | AWS quản lý control plane ← câu này | | EKS Anywhere | ✅ | CỦA BẠN — tại trung tâm dữ liệu | | ECS | ❌ (riêng của AWS) | AWS | | ECS Anywhere | ❌ | CỦA BẠN |

Hậu tố "Anywhere" luôn có nghĩa là chạy trên hạ tầng của bạn — nó phục vụ nhu cầu lai hoặc yêu cầu dữ liệu phải ở tại chỗ, không phải để giảm công vận hành.

Ba lưu ý về DocumentDB — mức tương thích không phải 100%: | Lưu ý | Chi tiết | |---|---| | Tương thích API MongoDB 3.6, 4.0, 5.0 | không phải mọi tính năng của phiên bản mới nhất | | Không hỗ trợ một số tính năng | ví dụ $where, một số toán tử tổng hợp, map-reduce | | Kiến trúc khác hẳn bên trong | tách compute và storage như Aurora |

Nên kiểm thử trước khi cam kết: AWS có công cụ tương thích quét mã và truy vấn để báo trước tính năng nào không dùng được:

python3 compat.py --uri mongodb://may-chu-cu:27017 --version 5.0

Ba ưu điểm kiến trúc của DocumentDB: | Ưu điểm | Chi tiết | |---|---| | Lưu trữ tự mở rộng tới 128 TB | không phải cấp phát trước | | 6 bản sao dữ liệu qua 3 AZ | độ bền cao | | Tới 15 read replica, độ trễ mili giây | mở rộng đọc dễ dàng | | Sao lưu liên tục vào S3 | point-in-time recovery |

Ba việc phải làm khi di chuyển cụm Kubernetes sang EKS: | Việc | Chi tiết | |---|---| | Thay storage class và ingress controller | EBS CSI driver, AWS Load Balancer Controller | | Chuyển quyền sang IRSA | IAM Roles for Service Accounts thay cho khoá cứng | | Đẩy image lên ECR | hoặc trỏ tới registry hiện có |

Dòng đầu là phần công việc thật sự: manifest ứng dụng thường giữ nguyên được, nhưng các thành phần hạ tầng của cụm (lưu trữ, cân bằng tải, DNS nội bộ) đều phải đổi sang phiên bản dành cho AWS.

Và dùng AWS DMS để chuyển dữ liệu MongoDB sang DocumentDB: DMS hỗ trợ MongoDB làm nguồn và DocumentDB làm đích, với chế độ CDC nên thời gian ngừng chỉ vài phút.

Và một lựa chọn đáng cân nhắc nếu muốn giảm công vận hành hơn nữa: EKS trên Fargate loại bỏ luôn việc quản lý node. Đổi lại, Fargate không hỗ trợ DaemonSet và không dùng được GPU — nên hãy kiểm tra xem cụm hiện tại có phụ thuộc vào những thứ đó không trước khi chọn.

Đáp án

A — Dùng AWS Config rule để phát hiện tài nguyên không tuân thủ quy tắc gắn thẻ.

Vì sao đúng

Đề cần kiểm tra tài nguyên chưa được gắn thẻ, với ÍT CÔNG NHẤT — và AWS Config có sẵn managed rule cho đúng việc đó.

required-tags là rule dựng sẵn, không phải viết mã:

{
  "ConfigRuleName": "bat-buoc-gan-the",
  "Source": {"Owner": "AWS", "SourceIdentifier": "REQUIRED_TAGS"},
  "InputParameters": "{\"tag1Key\":\"MoiTruong\",
                       \"tag2Key\":\"TrungTamChiPhi\",
                       \"tag3Key\":\"ChuSoHuu\"}"
}

Bốn việc AWS Config làm sẵn: | Việc | Chi tiết | |---|---| | Đánh giá LIÊN TỤC | tài nguyên mới được kiểm ngay khi tạo | | Bảng điều khiển tuân thủ | thấy ngay tài nguyên nào vi phạm | | Lịch sử cấu hình | biết tài nguyên thay đổi lúc nào, do ai | | Tự động khắc phục | gắn SSM Automation để tự sửa |

Và dòng cuối là điểm mạnh đáng chú ý:

{"TargetType": "SSM_DOCUMENT",
 "TargetId": "AWS-SetRequiredTags",
 "Automatic": true}

Tài nguyên thiếu thẻ được tự động gắn thẻ mặc định — chuyển từ "phát hiện" sang "tự sửa" mà vẫn không viết dòng mã nào.

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

• **C. Tạo Lambda function chạy kiểm tra tuân thủ, lên lịch bằng EventBridge — đây là phương án gần nhất và hoạt động được, nhưng nó nhiều công hơn hẳn: phải viết mã, xử lý phân trang API cho từng loại tài nguyên, bảo trì khi AWS thêm dịch vụ mới, và tự dựng cơ chế báo cáo. AWS Config đã có tất cả những thứ đó.
• **B. Dùng tag policy trong AWS Organizations và lưu thẻ vào S3 với Object Lock — hiểu sai công cụ: tag policy chuẩn hoá cách viết khoá và giá trị thẻ (ví dụ bắt buộc viết MoiTruong chứ không phải moitruong), nhưng nó không phát hiện tài nguyên KHÔNG có thẻ. Và vế lưu thẻ vào S3 với Object Lock hoàn toàn không liên quan.
• **D. Dùng Service Control Policy (SCP) để phát hiện tài nguyên gắn thẻ sai — sai bản chất: SCP là cơ chế NGĂN CHẶN, nó từ chối hành động chứ không phát hiện hay báo cáo gì. Nó cũng không quét được tài nguyên đã tồn tại.

Ghi nhớ

Bốn công cụ quản trị thẻ — mỗi cái một vai: | Công cụ | Việc | |---|---| | AWS Config rule required-tags | PHÁT HIỆN tài nguyên thiếu thẻ ← câu này | | Tag policy (Organizations) | CHUẨN HOÁ cách viết khoá và giá trị | | SCP với điều kiện aws:RequestTag | NGĂN việc tạo tài nguyên không có thẻ | | Tag Editor | tìm và sửa thẻ hàng loạt |

Ba cái đầu bổ sung nhau, không thay thế nhau:

SCP        → chặn ngay từ đầu (phòng ngừa)
Config     → phát hiện thứ đã lọt qua (phát hiện)
Tag policy → đảm bảo viết đúng chính tả (chuẩn hoá)

SCP bắt buộc gắn thẻ khi tạo tài nguyên:

{"Effect": "Deny",
 "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
 "Resource": "*",
 "Condition": {"Null": {"aws:RequestTag/TrungTamChiPhi": "true"}}}

Đây là biện pháp mạnh nhất — tài nguyên không có thẻ không tạo ra được. Nhưng nó chỉ áp cho tài nguyên mới, nên vẫn cần Config để quét những thứ đã có.

Ba loại rule trong AWS Config: | Loại | Đặc điểm | |---|---| | Managed rule | hơn 300 rule dựng sẵn — không cần viết mã | | Custom rule (Lambda) | logic riêng bằng mã | | Custom Policy rule (Guard) | viết bằng ngôn ngữ Guard, không cần Lambda |

Custom Policy rule là lựa chọn giữa hai cực: mạnh hơn managed rule, nhưng không phải viết và bảo trì Lambda.

Ba cơ chế kích hoạt đánh giá của Config rule: | Cơ chế | Khi nào chạy | |---|---| | Configuration change | ngay khi tài nguyên thay đổi | | Periodic | theo chu kỳ (1, 3, 6, 12, 24 giờ) | | Cả hai | kết hợp |

Với required-tags, chế độ theo thay đổi cấu hình cho phản hồi gần như tức thì — tài nguyên tạo ra thiếu thẻ sẽ hiện là không tuân thủ trong vài phút.

Ba lý do gắn thẻ quan trọng: | Lý do | Chi tiết | |---|---| | Phân bổ chi phí | Cost Explorer nhóm theo thẻ — biết phòng ban nào tiêu bao nhiêu | | Kiểm soát truy cập | IAM policy dùng điều kiện theo thẻ (ABAC) | | Tự động hoá | dừng máy theo thẻ, sao lưu theo thẻ |

Kiểm soát truy cập theo thuộc tính (ABAC) là ứng dụng mạnh mẽ nhất:

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

Một policy duy nhất phục vụ mọi phòng ban — người dùng chỉ thao tác được với tài nguyên mang thẻ khớp với thẻ của chính họ. Không phải viết policy riêng cho từng nhóm.

Lưu ý: để dùng thẻ trong Cost Explorer, phải KÍCH HOẠT khoá thẻ đó trong Billing console mục "Cost allocation tags" — gắn thẻ thôi chưa đủ, và dữ liệu chỉ có từ thời điểm kích hoạt trở đi.

Và một lưu ý về chi phí AWS Config: nó tính phí theo số mục cấu hình được ghi và số lần đánh giá rule. Với tài khoản có rất nhiều tài nguyên thay đổi liên tục, khoản này đáng kể — cân nhắc giới hạn loại tài nguyên được ghi thay vì bật ghi tất cả.

Đáp án

A — Thêm tài khoản của các lập trình viên vào một Organizational Unit (OU) và gắn Service Control Policy (SCP) hạn chế truy cập AWS Config vào OU đó.

Vì sao đúng

Đề cần ngăn lập trình viên xoá hoặc sửa Config rule, với ít công vận hành nhất — và SCP là cơ chế duy nhất làm được điều đó một cách tuyệt đối.

Vì sao SCP mạnh hơn mọi cơ chế IAM thông thường:

SCP là TRẦN QUYỀN của cả tài khoản
    → áp cho MỌI principal trong tài khoản đó
    → kể cả TÀI KHOẢN ROOT của tài khoản thành viên
    → lập trình viên dù có quyền quản trị đầy đủ vẫn KHÔNG vượt qua được

Đây là điểm khác biệt quyết định: nếu chỉ dùng IAM policy, lập trình viên có quyền admin trong tài khoản của mình tự sửa được policy đó. SCP thì họ không đụng tới được — nó nằm ở tài khoản quản lý của Organization.

SCP cần thiết:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Deny",
   "Action": ["config:DeleteConfigRule",
              "config:PutConfigRule",
              "config:DeleteConfigurationRecorder",
              "config:StopConfigurationRecorder",
              "config:DeleteDeliveryChannel"],
   "Resource": "*"}]}

Và mô hình OU khiến việc này mở rộng được:

Tạo OU "TaiKhoanLapTrinhVien"
    → gắn SCP MỘT LẦN
    → mọi tài khoản thêm vào OU tự thừa hưởng
    → thêm lập trình viên mới = thêm tài khoản vào OU

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

• **C. Cấu hình một Config rule ở tài khoản gốc để phát hiện khi Config rule của tài khoản mới bị thay đổi — đây là phương án gần nhất về mặt cũng dùng Config, nhưng nó chỉ PHÁT HIỆN SAU KHI ĐÃ XẢY RA, không ngăn chặn. Đề yêu cầu lập trình viên "unable to remove or modify" — tức là phải chặn được.
• **B. Dùng IAM Role với trust relationship để chặn root user truy cập AWS Config — sai về mặt kỹ thuật: trust relationship quyết định AI ĐƯỢC ĐẢM NHẬN role, nó không hạn chế quyền của root user. Và không có IAM policy nào giới hạn được root của chính tài khoản đó — chỉ SCP làm được.
• **D. Dùng AWS Control Tower để phát hiện thay đổi và gắn trust relationship vào IAM User của từng lập trình viên — nửa đúng nửa sai: Control Tower thực sự dùng SCP cho các guardrail của nó, nhưng phần "gắn trust relationship vào IAM User để ngăn thay đổi" không phải cơ chế có thật. Và giải pháp mô tả nghiêng về phát hiện hơn là ngăn chặn.

Ghi nhớ

SCP so với IAM policy — khác biệt cốt lõi: | | SCP | IAM policy | |---|---|---| | Vai trò | GIỚI HẠN quyền tối đa | CẤP quyền | | Áp cho | tài khoản hoặc OU | user, group, role | | Ảnh hưởng root của tài khoản thành viên | ✅ CÓ | ❌ KHÔNG | | Tự cấp quyền | ❌ không bao giờ | ✅ | | Quản lý ở | tài khoản quản lý của Organization | trong từng tài khoản |

Quy tắc quan trọng: quyền hiệu lực = giao của SCP và IAM policy.

SCP cho phép + IAM cho phép  → ĐƯỢC
SCP cho phép + IAM không     → không được
SCP CHẶN     + IAM cho phép  → KHÔNG ĐƯỢC   ← SCP luôn thắng

Một lưu ý quan trọng: SCP KHÔNG áp cho tài khoản quản lý (management account) — kể cả khi bạn gắn nó vào gốc của Organization. Đó là lý do thực hành tốt khuyên không chạy workload nào trong tài khoản quản lý.

Hai chiến lược viết SCP: | Chiến lược | Cách làm | |---|---| | Deny list (phổ biến) | giữ FullAWSAccess mặc định, thêm SCP Deny cho việc cấm | | Allow list | gỡ FullAWSAccess, chỉ liệt kê thứ cho phép |

Deny list dễ quản lý hơn nhiều — allow list đòi bạn liệt kê mọi hành động của mọi dịch vụ được dùng, và thiếu một cái là ứng dụng hỏng theo cách khó chẩn đoán.

Ba SCP nên có cho tài khoản lập trình viên:

// Chặn việc tắt các dịch vụ giám sát
{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
            "config:DeleteConfigRule", "config:StopConfigurationRecorder",
            "guardduty:DeleteDetector"],
 "Resource": "*"}

// Giới hạn Region được dùng
{"Effect": "Deny", "NotAction": ["iam:*", "organizations:*", "s3:GetBucket*"],
 "Resource": "*",
 "Condition": {"StringNotEquals": {"aws:RequestedRegion": ["ap-southeast-1"]}}}

// Chặn rời khỏi Organization
{"Effect": "Deny", "Action": "organizations:LeaveOrganization", "Resource": "*"}

Giới hạn Region là SCP có giá trị bất ngờ cao: nó vừa kiểm soát chi phí, vừa thu hẹp phạm vi cần giám sát, vừa ngăn kẻ tấn công dựng tài nguyên ở Region xa lạ mà không ai theo dõi.

Ba khái niệm của AWS Organizations: | Khái niệm | Việc | |---|---| | Management account | tài khoản gốc — SCP KHÔNG áp cho nó | | Organizational Unit (OU) | nhóm tài khoản, SCP kế thừa xuống | | Member account | tài khoản thành viên |

Cấu trúc OU điển hình:

Root
├── Security          (log, audit)
├── Infrastructure    (mạng dùng chung)
├── Workloads
│   ├── Production
│   └── Development   ← SCP chặt hơn cho môi trường này
└── Sandbox           ← tài khoản lập trình viên, SCP giới hạn chi phí

AWS Control Tower dựng sẵn cấu trúc này cùng một bộ guardrail được khuyến nghị — nếu tổ chức đang bắt đầu với nhiều tài khoản, nó tiết kiệm rất nhiều công so với tự cấu hình từ đầu.

Và một lời khuyên khi triển khai SCP: luôn thử trên một OU nhỏ trước. SCP quá chặt sẽ phá vỡ những thứ bạn không lường trước, và triệu chứng là lỗi AccessDenied không nói rõ nguyên nhân đến từ SCP hay từ IAM — rất khó chẩn đoán nếu áp một lượt cho cả tổ chức.

Đáp án

A — Triển khai ứng dụng lên Amazon ECS cluster dùng AWS Fargate task.

Vì sao đúng

Đề nêu ba yêu cầu, và Fargate đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng đóng gói thành Docker image trong ECR | Fargate chạy trực tiếp image từ ECR | | Chạy trên dịch vụ compute serverless được quản lý hoàn toàn | Fargate không có máy chủ nào để quản lý | | Cần 5 GB lưu trữ tạm | Fargate cấp 20 GB mặc định, cấu hình tới 200 GB |

Dung lượng lưu trữ tạm của Fargate:

Mặc định:      20 GB
Cấu hình được: 21–200 GB   (nền tảng 1.4.0 trở lên)

{"ephemeralStorage": {"sizeInGiB": 50}}

5 GB nằm thoải mái trong mức mặc định — không cần cấu hình gì thêm.

Và Fargate phù hợp với ứng dụng chạy lâu, xử lý dữ liệu:

Không giới hạn thời gian chạy
Tài nguyên cấu hình linh hoạt (0,25–16 vCPU, 0,5–120 GB RAM)
Mỗi task có ranh giới ảo hoá riêng

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

• **B. Triển khai lên AWS Lambda với container image support, đặt storage của hàm là 5 GB — đây là phương án gần nhất và đáng bàn kỹ (xem ghi chú bên dưới): Lambda có hỗ trợ container image, và từ tháng 3/2022 /tmp cấu hình được tới 10 GB. Điểm khác biệt còn lại là giới hạn 15 phút mỗi lần chạy — nếu tác vụ xử lý dữ liệu vượt quá đó thì Lambda không dùng được.
• **C. Lambda với container image và gắn EFS volume — phức tạp hơn cần thiết: EFS là lưu trữ dùng chung, bền vững, còn đề chỉ cần lưu trữ TẠM cho xử lý dữ liệu. Gắn EFS đòi Lambda phải nằm trong VPC, kéo theo cấu hình mạng, mount target, và độ trễ cao hơn /tmp cục bộ.
• **D. ECS với EC2 worker node và EBS volume 5 GB — vi phạm yêu cầu serverless: EC2 worker node là máy chủ bạn phải cấp phát, vá lỗi và mở rộng. Đề nói rõ "fully managed serverless compute service".

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

Đáp án này phản ánh giới hạn cũ của Lambda. Trước tháng 3/2022, /tmp của Lambda cố định ở 512 MB — nên 5 GB là bất khả thi và Fargate là lựa chọn duy nhất. Hiện nay:

Lambda ephemeral storage: 512 MB – 10.240 MB (cấu hình được)
    → 5 GB HOÀN TOÀN đặt được

Nghĩa là phương án B ngày nay cũng dựng được. Yếu tố phân biệt còn lại là thời gian chạy: Lambda tối đa 15 phút, Fargate không giới hạn. Đề không nói tác vụ chạy bao lâu, nên nếu gặp tình huống này trong thực tế, đó là câu hỏi cần trả lời trước khi chọn.

Ghi nhớ

Lưu trữ tạm của các dịch vụ serverless: | Dịch vụ | Lưu trữ tạm | |---|---| | AWS Lambda (/tmp) | 512 MB – 10 GB (cấu hình được) | | Fargate (ECS/EKS) | 20 GB mặc định, tới 200 GB | | Lambda + EFS | không giới hạn (lưu trữ bền vững, dùng chung) |

Lambda và Fargate — bảng chọn: | | Lambda | Fargate | |---|---|---| | Thời gian chạy tối đa | 15 phút | không giới hạn | | Mô hình | theo sự kiện, khởi động rất nhanh | tác vụ hoặc dịch vụ chạy lâu | | Tính phí | theo mili giây thực thi | theo vCPU-giây và GB-giây | | Khi rảnh | KHÔNG tính phí | task đang chạy vẫn tính phí | | Bộ nhớ tối đa | 10 GB | 120 GB | | vCPU tối đa | ~6 (theo bộ nhớ) | 16 | | Cold start | có | có (chậm hơn, ~30–60 giây) |

Quy tắc chọn:

Ngắn, theo sự kiện, tải rất biến động → Lambda Chạy lâu, cần nhiều tài nguyên, dịch vụ thường trực → Fargate Chạy liên tục, khối lượng ổn định, cần rẻ nhất → ECS/EKS trên EC2 với Savings Plan

Ba lưu ý về Lambda container image: | Lưu ý | Chi tiết | |---|---| | Kích thước image tối đa 10 GB | lớn hơn nhiều so với 250 MB của gói zip | | Phải cài Lambda Runtime Interface Client | image thường không chạy trực tiếp được | | Lưu trong ECR, không phải Docker Hub | ECR cùng Region |

Ba cấu hình quan trọng của Fargate task: | Cấu hình | Chi tiết | |---|---| | Kết hợp CPU và bộ nhớ bị RÀNG BUỘC | không chọn tuỳ ý — ví dụ 1 vCPU chỉ ghép với 2–8 GB RAM | | ephemeralStorage | 21–200 GB nếu cần hơn mặc định | | Nền tảng 1.4.0 trở lên | cần cho nhiều tính năng mới |

Ràng buộc CPU–bộ nhớ hay gây bất ngờ:

0,25 vCPU → 0,5, 1, 2 GB
0,5 vCPU  → 1–4 GB
1 vCPU    → 2–8 GB
2 vCPU    → 4–16 GB
4 vCPU    → 8–30 GB
8 vCPU    → 16–60 GB
16 vCPU   → 32–120 GB

Ba cách giảm chi phí Fargate: | Cách | Mức tiết kiệm | |---|---| | Fargate Spot | tới 70% — cho workload chịu được gián đoạn | | Compute Savings Plan | tới 50% với cam kết 1–3 năm | | Chọn đúng kích thước task | đo mức dùng thật bằng Container Insights |

Fargate Spot rất phù hợp với tác vụ xử lý dữ liệu theo lô — nếu tác vụ chạy lại được từ đầu hoặc từ checkpoint, không có lý do gì trả giá đầy đủ.

Và một lưu ý về lưu trữ tạm trong container: dữ liệu ở đó mất khi task kết thúc. Nếu kết quả xử lý cần giữ lại, hãy ghi lên S3 trước khi task thoát — đây là lỗi hay gặp khi chuyển ứng dụng từ máy chủ truyền thống sang container.

Đáp án

A — Lưu các giá trị dưới dạng tham số kiểu SecureString trong AWS Systems Manager Parameter Store, mã hoá bằng AWS KMS.

Vì sao đúng

Đề nêu hai yêu cầu, và Parameter Store đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Lưu biến ứng dụng có MÃ HOÁ | SecureString mã hoá bằng KMS | | TIẾT KIỆM CHI PHÍ NHẤT | tham số Standard MIỄN PHÍ |

So sánh chi phí — đây là điểm quyết định:

Parameter Store (Standard):
    Lưu tham số:  MIỄN PHÍ (tới 10.000 tham số)
    Lời gọi API:  MIỄN PHÍ (tới 40 lời gọi/giây)
    → chỉ trả phí KMS cho lời gọi giải mã

Secrets Manager:
    ~0,40 USD mỗi bí mật mỗi THÁNG
    + ~0,05 USD mỗi 10.000 lời gọi API

Với danh sách biến mà đề liệt kê — DB hostname, cấu hình môi trường, product key, mật khẩu database — có thể là hàng chục tham số:

50 tham số × 0,40 USD × 12 tháng = 240 USD/năm với Secrets Manager
50 tham số ở Parameter Store Standard = 0 USD

Và SecureString mã hoá thật sự:

aws ssm put-parameter --name "/ung-dung/prod/mat-khau-db"   --value "matkhauthat" --type SecureString --key-id alias/khoa-ung-dung

r = ssm.get_parameter(Name='/ung-dung/prod/mat-khau-db', WithDecryption=True)
mat_khau = r['Parameter']['Value']

Và phần lớn giá trị trong danh sách của đề KHÔNG PHẢI bí mật: DB hostname và cấu hình môi trường là dữ liệu cấu hình thông thường — trả tiền cho Secrets Manager để lưu chúng là lãng phí.

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

• **B. Lưu bằng cách tạo secret trong AWS Secrets Manager, mã hoá bằng KMS — đây là phương án gần nhất và hoàn toàn hợp lệ về mặt kỹ thuật, nhưng nó đắt hơn: khoảng 0,40 USD mỗi bí mật mỗi tháng. Đề hỏi "most cost-effective", và Parameter Store làm được cùng việc với giá 0.
• **C. Lưu vào một tệp trên S3 có bật mã hoá, ứng dụng tải về lúc khởi động — kém an toàn và nhiều công: không có kiểm soát truy cập ở mức từng giá trị, không có phiên bản cho từng tham số, không audit được ai đọc giá trị nào, và phải tự viết logic tải và phân tích tệp.
• **D. Lưu dạng khoá–giá trị trong Systems Manager OpsCenter — sai công cụ: OpsCenter là nơi quản lý sự cố vận hành (OpsItem), không phải kho lưu cấu hình. Và khẳng định "mặc định được mã hoá" không đúng với mục đích sử dụng này.

Ghi nhớ

Parameter Store và Secrets Manager — bảng chọn: | | Parameter Store | Secrets Manager | |---|---|---| | Chi phí | MIỄN PHÍ (Standard) | ~0,40 USD mỗi bí mật mỗi tháng | | Tự động XOAY VÒNG bí mật | ❌ (phải tự viết) | ✅ tích hợp sẵn với RDS, Redshift, DocumentDB | | Sinh mật khẩu ngẫu nhiên | ❌ | ✅ | | Sao chép xuyên Region | ❌ | ✅ | | Chia sẻ xuyên tài khoản | ❌ | ✅ (resource policy) | | Kích thước giá trị | 4 KB (Standard), 8 KB (Advanced) | 64 KB | | Phiên bản | ✅ | ✅ | | Tích hợp CloudFormation | ✅ | ✅ |

Quy tắc chọn:

Cấu hình thông thường, tiết kiệm chi phí → Parameter Store Cần XOAY VÒNG TỰ ĐỘNG mật khẩu database → Secrets Manager Chia sẻ bí mật giữa các tài khoản hoặc Region → Secrets Manager

Xoay vòng tự động là lý do chính đáng nhất để trả tiền cho Secrets Manager:

Secrets Manager + RDS:
    → tự đổi mật khẩu database theo lịch
    → tự cập nhật cả ở RDS lẫn trong bí mật
    → ứng dụng lấy mật khẩu mới ở lần gọi tiếp theo
    → KHÔNG có thời gian ngừng

Với yêu cầu tuân thủ buộc đổi mật khẩu định kỳ, khoản 0,40 USD/tháng là rất xứng đáng.

Ba loại tham số trong Parameter Store: | Loại | Đặc điểm | |---|---| | String | văn bản thường | | StringList | danh sách phân tách bằng dấu phẩy | | SecureString | mã hoá bằng KMS ← câu này |

Hai bậc tham số: | Bậc | Đặc điểm | |---|---| | Standard | miễn phí, tối đa 10.000 tham số, giá trị 4 KB | | Advanced | có phí, 100.000 tham số, giá trị 8 KB, có chính sách hết hạn |

Tổ chức tham số theo cây phân cấp — thực hành quan trọng:

/ung-dung/prod/db-host
/ung-dung/prod/db-password
/ung-dung/staging/db-host

# Lấy CẢ NHÁNH trong một lời gọi
r = ssm.get_parameters_by_path(Path='/ung-dung/prod/',
                                Recursive=True, WithDecryption=True)

Lợi ích lớn nhất: phân quyền IAM theo nhánh.

{"Effect": "Allow", "Action": "ssm:GetParameter*",
 "Resource": "arn:aws:ssm:*:*:parameter/ung-dung/prod/*"}

Ứng dụng ở môi trường prod chỉ đọc được tham số của prod — không chạm tới staging hay ứng dụng khác.

Ba thực hành tốt khi quản lý cấu hình: | Thực hành | Lý do | |---|---| | KHÔNG nhúng bí mật vào mã hoặc image | mã bị lộ là bí mật lộ theo | | Dùng IAM role, không dùng access key | thông tin đăng nhập tự hết hạn | | Cache giá trị trong ứng dụng | giảm lời gọi API và phí KMS | | Bật CloudTrail để audit ai đọc gì | quan trọng cho tuân thủ |

Về caching: đọc tham số ở mỗi request là lãng phí và có thể chạm giới hạn tốc độ. Đọc một lần lúc khởi động, hoặc dùng AWS Parameters and Secrets Lambda Extension — nó cache tự động cho Lambda.

Và một lưu ý về chi phí KMS: SecureString dùng khoá aws/ssm mặc định thì không tính phí lưu khoá, chỉ tính phí lời gọi giải mã (~0,03 USD mỗi 10.000 lời gọi). Dùng khoá tự quản lý thì thêm ~1 USD mỗi khoá mỗi tháng — đổi lại được kiểm soát chính sách khoá và audit chi tiết hơn.

Đáp án

A — Sau khi kiểm thử xong, chụp snapshot của database rồi CHẤM DỨT (terminate) nó; khôi phục từ snapshot khi cần dùng lại.

Vì sao đúng

Đề mô tả mẫu sử dụng rất đặc thù: chỉ chạy hai lần mỗi tuần — nghĩa là database rảnh hơn 90% thời gian.

Phép tính chi phí:

Kiểm thử 2 lần/tuần, mỗi lần khoảng 4 giờ = 8 giờ/tuần
    → 8 / 168 giờ = ~5% thời gian thực sự dùng

Để instance chạy liên tục:
    → trả tiền cho 100% thời gian
    → 95% là lãng phí hoàn toàn

Chấm dứt instance và chỉ giữ snapshot:

Chi phí khi không dùng = chi phí lưu SNAPSHOT
    → snapshot rẻ hơn instance đang chạy RẤT NHIỀU
    → chỉ tính theo dung lượng dữ liệu, không tính compute

Và tính toàn vẹn của bài kiểm thử được giữ nguyên:

Khôi phục từ snapshot → database GIỐNG HỆT lúc chụp
    → cùng dữ liệu, cùng lược đồ, cùng thống kê
    → kết quả kiểm thử so sánh được giữa các lần

Thậm chí còn tốt hơn: mỗi lần khôi phục cho một môi trường sạch và giống nhau, loại bỏ sai lệch tích tụ từ lần kiểm thử trước.

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

• **B. Dừng (stop) database sau khi kiểm thử và bật lại khi cần — đây là phương án gần nhất và có tiết kiệm phần compute, nhưng nó có một hạn chế quyết định: RDS tự động khởi động lại instance đã dừng sau 7 NGÀY. Với lịch chạy hai lần mỗi tuần thì có thể vừa đủ, nhưng bất kỳ tuần nào nghỉ là instance tự bật và tính tiền. Và dừng instance vẫn trả phí lưu trữ đầy đủ cho dung lượng đã cấp, không chỉ dung lượng dữ liệu thật.
• **C. Hạ cấp xuống instance nhỏ hơn — phá hỏng tính toàn vẹn của bài kiểm thử: đề nói rõ đây là kiểm thử hiệu năng trên instance lớn. Chạy trên máy nhỏ hơn cho kết quả không đại diện cho hệ thống thật.
• **D. Dùng mysqldump và phân tích bằng MySQL Workbench trên máy cục bộ — kết quả vô nghĩa: hiệu năng trên máy tính cá nhân không phản ánh gì về hiệu năng trên RDS. Và mất luôn Performance Insights — công cụ mà đề nói họ đang dùng.

Ghi nhớ

Ba trạng thái của RDS instance và chi phí: | Trạng thái | Phí compute | Phí lưu trữ | |---|---|---| | Available (đang chạy) | ✅ đầy đủ | ✅ theo dung lượng đã cấp | | Stopped | ❌ | ✅ VẪN TÍNH đầy đủ | | Đã terminate, còn snapshot | ❌ | ✅ chỉ tính dung lượng SNAPSHOT |

Snapshot rẻ hơn vì nó chỉ tính dữ liệu thật, không tính dung lượng đã cấp — một instance cấp 500 GB nhưng chỉ chứa 50 GB dữ liệu thì snapshot chỉ tính khoảng 50 GB.

Giới hạn 7 ngày của việc dừng RDS — cần nhớ:

Dừng RDS instance
    → sau 7 NGÀY, AWS TỰ ĐỘNG khởi động lại
    → để áp dụng bản vá bảo trì
    → và bắt đầu tính phí trở lại

Muốn dừng lâu hơn thì phải có tự động hoá dừng lại, hoặc dùng cách snapshot + terminate như đáp án.

Ba giới hạn khác của việc dừng RDS: | Giới hạn | Chi tiết | |---|---| | Không dừng được instance có read replica | phải xoá replica trước | | Không dừng được chính read replica | | | Aurora khác: dừng cả cluster, cũng tối đa 7 ngày | |

Ba cách tối ưu chi phí cho môi trường không sản xuất: | Cách | Phù hợp | |---|---| | Snapshot + terminate | dùng rất thưa — vài lần mỗi tuần ← câu này | | Dừng qua đêm và cuối tuần | dùng hằng ngày trong giờ hành chính | | Aurora Serverless v2 | tải rất biến động, tự co giãn theo nhu cầu |

Aurora Serverless v2 đáng cân nhắc cho tình huống này: nó co xuống mức tối thiểu (0,5 ACU) khi rảnh và bung ra khi kiểm thử — không cần tự động hoá gì, và không có giới hạn 7 ngày. Đổi lại, nó không co về 0 nên vẫn có chi phí nền.

Tự động hoá quy trình snapshot + terminate:

# Sau khi kiểm thử xong
aws rds create-db-snapshot --db-instance-identifier db-kiem-thu   --db-snapshot-identifier snap-kiem-thu-$(date +%Y%m%d)
aws rds delete-db-instance --db-instance-identifier db-kiem-thu   --skip-final-snapshot

# Trước lần kiểm thử tiếp theo
aws rds restore-db-instance-from-db-snapshot   --db-instance-identifier db-kiem-thu   --db-snapshot-identifier snap-kiem-thu-20260830   --db-instance-class db.r6g.2xlarge

Lưu ý quan trọng khi khôi phục: instance mới có security group và parameter group MẶC ĐỊNH — phải khai lại tường minh, nếu không ứng dụng kết nối không được:

aws rds modify-db-instance --db-instance-identifier db-kiem-thu   --vpc-security-group-ids sg-0abc123   --db-parameter-group-name pg-kiem-thu --apply-immediately

Và thời gian khôi phục cần tính vào lịch: khôi phục từ snapshot mất từ vài phút tới hàng chục phút tuỳ dung lượng, cộng thêm giai đoạn "làm nóng" khi các khối dữ liệu được nạp lần đầu từ S3. Với kiểm thử hiệu năng, hãy chạy một lượt làm nóng trước khi đo — nếu không, số liệu lần đầu sẽ tệ hơn thực tế.

Ba lưu ý về Performance Insights mà đề đề cập: | Lưu ý | Chi tiết | |---|---| | 7 ngày lưu trữ là MIỄN PHÍ | đủ cho chu kỳ kiểm thử hằng tuần | | Dữ liệu MẤT khi terminate instance | xuất số liệu cần giữ ra trước | | Lưu trữ dài hạn có phí | tới 24 tháng |

Dòng giữa là điều phải nhớ với chiến lược terminate: hãy ghi lại kết quả phân tích (truy vấn tốn kém nhất, chỉ số chờ) vào một nơi bền vững trước khi xoá instance — nếu không, so sánh giữa các đợt kiểm thử sẽ không làm được.

Đáp án

B — Cấu hình HTTP listener HIỆN CÓ để chuyển hướng lưu lượng sang cổng 443.

Vì sao đúng

Đề cho một dữ kiện quyết định: ALB đã nhận HTTP trên cổng 80 và HTTPS trên cổng 443 — nghĩa là listener cổng 80 ĐÃ TỒN TẠI.

Và một cổng chỉ có ĐÚNG MỘT listener:

ALB đã có listener trên cổng 80
    ↓
KHÔNG tạo thêm listener nào trên cổng 80 được
    → sẽ báo lỗi "DuplicateListener"
    ↓
Phải SỬA listener đang có

Đây chính là điểm phân biệt giữa hai phương án nghe rất giống nhau.

Cách sửa: đổi default action của listener 80 thành redirect:

aws elbv2 modify-listener --listener-arn <arn-listener-80>   --default-actions '[{
    "Type": "redirect",
    "RedirectConfig": {
      "Protocol": "HTTPS",
      "Port": "443",
      "Host": "#{host}",
      "Path": "/#{path}",
      "Query": "#{query}",
      "StatusCode": "HTTP_301"}}]'

Ba biến giữ nguyên đường dẫn — quan trọng cho SEO và trải nghiệm: | Biến | Giữ lại | |---|---| | #{host} | tên miền | | #{path} | đường dẫn — người dùng tới đúng trang họ muốn | | #{query} | tham số truy vấn |

Không có ba biến này thì mọi request bị đẩy về trang chủ — mất tham số theo dõi chiến dịch, mất liên kết sâu.

Và chuyển hướng xảy ra ngay tại ALB — request không tới máy chủ ứng dụng, nên không tốn tài nguyên xử lý.

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

• **A. TẠO MỚI listener HTTP trên cổng 80 và thêm redirect action sang HTTPS cổng 443 — đây là phương án gần nhất và nội dung cấu hình hoàn toàn đúng, nhưng nó không thực hiện được: cổng 80 đã có listener rồi, tạo thêm sẽ lỗi. Đây là bẫy dựa trên một chi tiết trong đề bài.
• **C. Tạo listener mới trên cổng 443 và cấu hình nó chuyển hướng HTTP sang HTTPS — sai hai chỗ: cổng 443 cũng đã có listener, và listener 443 chỉ nhận lưu lượng ĐÃ LÀ HTTPS — nó không bao giờ thấy request HTTP để mà chuyển hướng.
• **D. Cấu hình listener 443 thêm redirect action sang HTTP cổng 80 — làm ngược hoàn toàn: nó đẩy lưu lượng an toàn về kênh không mã hoá, giảm bảo mật thay vì tăng.

Ghi nhớ

Nguyên tắc listener của ALB:

Mỗi cổng có ĐÚNG MỘT listener
    → cổng 80 và 443 đã dùng thì phải SỬA, không TẠO MỚI

Bốn loại action của ALB listener: | Action | Việc | |---|---| | forward | chuyển tới target group | | redirect | chuyển hướng HTTP 301 hoặc 302 ← câu này | | fixed-response | trả thẳng nội dung cố định (ví dụ trang bảo trì) | | authenticate-cognito / authenticate-oidc | xác thực người dùng NGAY TẠI ALB |

fixed-response rất hữu ích: trả về trang bảo trì mà không cần bất kỳ máy chủ nào chạy phía sau.

authenticate-oidc là tính năng mạnh ít người biết: ALB tự lo toàn bộ luồng đăng nhập OIDC trước khi chuyển request tới ứng dụng — ứng dụng chỉ đọc header là biết người dùng là ai.

301 và 302 — chọn đúng: | Mã | Ý nghĩa | Dùng khi | |---|---|---| | 301 Moved Permanently | vĩnh viễn — trình duyệt CACHE lại | chuyển HTTP → HTTPS ← câu này | | 302 Found | tạm thời — không cache | chuyển hướng tạm |

301 là lựa chọn đúng cho HTTP → HTTPS: trình duyệt nhớ và tự dùng HTTPS ở các lần sau, giảm hẳn số lần chuyển hướng. Và với SEO, 301 truyền lại giá trị liên kết cho URL mới còn 302 thì không.

Nhưng 301 cũng có mặt trái: trình duyệt cache rất lâu, nên nếu cấu hình sai thì người dùng bị kẹt cho tới khi xoá cache. Thử bằng 302 trước, đổi sang 301 khi đã chắc chắn là cách làm an toàn.

Và bước tiếp theo sau khi có redirect: bật HSTS ở tầng ứng dụng.

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS khiến trình duyệt tự dùng HTTPS ngay từ request ĐẦU TIÊN — kể cả người dùng gõ http://. Redirect vẫn để lại một request HTTP không mã hoá có thể bị nghe lén; HSTS loại bỏ luôn cả request đó.

Lưu ý về includeSubDomains: nó ép mọi tên miền con phải dùng HTTPS trong suốt thời hạn max-age. Nếu có tên miền con nào chưa sẵn sàng cho HTTPS, nó sẽ không truy cập được — và không gỡ nhanh được vì trình duyệt đã ghi nhớ.

Ba phần của một quy tắc listener: | Phần | Ví dụ | |---|---| | Priority | số nhỏ hơn được xét trước | | Condition | host header, đường dẫn, HTTP header, phương thức, IP nguồn | | Action | forward, redirect, fixed-response |

Chuyển hướng chỉ cho MỘT tên miền cụ thể — hữu ích khi ALB phục vụ nhiều tên miền như tình huống của đề:

aws elbv2 create-rule --listener-arn <arn-listener-80> --priority 10   --conditions '[{"Field":"host-header","Values":["ten-mien-moi.com"]}]'   --actions '[{"Type":"redirect","RedirectConfig":
    {"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Ba cấu hình HTTPS nên có cho ALB: | Cấu hình | Lý do | |---|---| | Chuyển hướng HTTP → HTTPS | ← câu này | | Chính sách bảo mật TLS hiện đại | ELBSecurityPolicy-TLS13-1-2-2021-06 | | Chứng chỉ từ ACM | miễn phí và tự động gia hạn |

Và một cách kiểm chứng nhanh sau khi cấu hình:

curl -sI http://ten-mien-moi.com/duong-dan?tham-so=1 | head -3
# HTTP/1.1 301 Moved Permanently
# Location: https://ten-mien-moi.com/duong-dan?tham-so=1

Hãy kiểm tra rằng Location giữ nguyên đường dẫn và tham số — nếu nó trỏ về https://ten-mien-moi.com/ trơn thì bạn đã quên ba biến #{host}, #{path}, #{query}.

Đáp án

B — AWS Storage Gateway.

Vì sao đúng

Đề mô tả nhu cầu rất rõ: hạ tầng tại chỗ sắp hết dung lượng, muốn MỞ RỘNG bằng đám mây — và Storage Gateway sinh ra cho đúng việc đó.

Cách nó hoạt động:

Máy ảo gateway chạy TẠI TRUNG TÂM DỮ LIỆU của bạn
    ↓ phơi ra giao diện quen thuộc (NFS, SMB, hoặc iSCSI)
Ứng dụng tại chỗ dùng như một ổ đĩa hay thư mục mạng bình thường
    ↓ gateway đồng bộ dữ liệu lên AWS
Dữ liệu thật nằm ở S3, S3 Glacier, hoặc EBS snapshot
    ↓ cache cục bộ giữ phần hay truy cập
Đọc dữ liệu nóng vẫn nhanh, dung lượng thì gần như vô hạn

Và đó chính là "extend their storage using the AWS cloud": ứng dụng không biết dữ liệu đang ở đâu, nhưng giới hạn dung lượng vật lý biến mất.

Ba loại gateway cho ba nhu cầu khác nhau: | Loại | Giao diện | Đích | |---|---|---| | File Gateway | NFS, SMB | S3 | | Volume Gateway | iSCSI | S3 dạng EBS snapshot | | Tape Gateway | iSCSI VTL | S3 Glacier |

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

• **C. Amazon Elastic Block Storage (EBS) — đây là phương án gần nhất về mặt cũng là dịch vụ lưu trữ, nhưng nó không dùng được từ tại chỗ: EBS volume chỉ gắn được vào EC2 instance trong cùng AZ. Máy chủ trong trung tâm dữ liệu của bạn không mount EBS được.
• **A. Amazon EC2 — là dịch vụ tính toán, không phải giải pháp lưu trữ. Dựng EC2 rồi tự làm máy chủ tệp là tự xây lại thứ Storage Gateway đã làm sẵn.
• **D. Amazon SQS — hoàn toàn không liên quan: SQS là hàng đợi thông điệp cho việc tách rời các thành phần ứng dụng. Nó không lưu trữ tệp.

Ghi nhớ

Ba loại Storage Gateway — bảng cần thuộc: | Loại | Giao thức | Trường hợp dùng | |---|---|---| | File Gateway | NFS, SMB | chia sẻ tệp, kho dữ liệu, sao lưu | | Volume Gateway | iSCSI | ổ đĩa khối cho ứng dụng | | Tape Gateway | iSCSI VTL | thay thư viện băng từ vật lý |

Từ khoá nhận diện:

"NFS", "SMB", "file share" → File Gateway "iSCSI", "block volume" → Volume Gateway "tape", "backup software", "VTL" → Tape Gateway

Hai chế độ của Volume Gateway: | Chế độ | Dữ liệu chính | Dung lượng mỗi volume | |---|---|---| | Cached | AWS — chỉ cache tại chỗ | tới 32 TB | | Stored | TẠI CHỖ — AWS giữ bản sao lưu | tới 16 TB |

Cached volume đúng nghĩa "mở rộng dung lượng": dữ liệu nằm ở AWS, đĩa cục bộ chỉ để tăng tốc. Stored volume thì ngược lại — dữ liệu vẫn ở tại chỗ, AWS chỉ để phòng hờ.

Với nhu cầu "sắp hết chỗ" của đề, cached volume hoặc file gateway là lựa chọn phù hợp — chúng thực sự chuyển gánh nặng dung lượng sang đám mây.

Các dịch vụ chuyển và truy cập dữ liệu lai — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | Storage Gateway | truy cập LIÊN TỤC — tại chỗ dùng, dữ liệu ở AWS | | AWS DataSync | di chuyển hoặc đồng bộ định kỳ, hiệu năng cao | | AWS Snow Family | khối lượng rất lớn, băng thông hạn chế | | AWS Transfer Family | endpoint SFTP/FTPS/AS2 cho đối tác | | Amazon FSx File Gateway | truy cập FSx for Windows từ tại chỗ với cache |

Storage Gateway và DataSync hay bị nhầm:

DataSync:         DI CHUYỂN dữ liệu (một lần hoặc theo lịch)
Storage Gateway:  TRUY CẬP dữ liệu liên tục (như ổ đĩa mạng)

Chúng thường dùng cùng nhau: DataSync chuyển khối lượng ban đầu (nhanh hơn nhiều), rồi Storage Gateway phục vụ truy cập hằng ngày.

Ba yêu cầu khi triển khai Storage Gateway: | Yêu cầu | Chi tiết | |---|---| | Nền tảng chạy gateway | VMware ESXi, Hyper-V, KVM, EC2, hoặc thiết bị phần cứng của AWS | | Đĩa cục bộ cho cache và upload buffer | kích thước ảnh hưởng trực tiếp tới hiệu năng | | Băng thông tới AWS | đặt được giới hạn theo lịch để không nghẽn giờ làm việc |

Kích thước cache là yếu tố quyết định trải nghiệm: nếu tập dữ liệu hay dùng vượt quá cache, mọi lần đọc đều phải lấy từ S3 và người dùng cảm nhận rõ độ trễ.

Ba lợi ích của mô hình lưu trữ lai: | Lợi ích | Chi tiết | |---|---| | Dung lượng gần như vô hạn | không phải mua thêm đĩa vật lý | | Tận dụng lifecycle của S3 | tự chuyển sang Glacier cho dữ liệu nguội | | Dữ liệu ở AWS dùng được cho dịch vụ khác | Athena, Glue, học máy |

Dòng cuối là lợi ích chiến lược thường bị bỏ qua: một khi dữ liệu nằm ở S3, nó không chỉ được lưu mà còn phân tích được — điều mà đĩa NAS tại chỗ không cho.

Và một lưu ý về chi phí: Storage Gateway tính phí giờ cho gateway cộng chi phí lưu trữ ở đích, và phí truyền dữ liệu ra khỏi AWS khi đọc lại nhiều. Nếu nhu cầu chỉ là chuyển dữ liệu cũ ra khỏi hệ thống tại chỗ một lần, DataSync + S3 lifecycle thường rẻ hơn.

Đáp án

A — Tạo inbound rule trong security group của EC2 instance: Protocol TCP, Port Range 20–21, Source 175.45.116.100/32.

Vì sao đúng

Đề cần cho phép FTP chỉ từ một địa chỉ IP — và ba thành phần của rule đều phải đúng: | Thành phần | Giá trị đúng | Lý do | |---|---|---| | Giao thức | TCP | FTP chạy trên TCP | | Cổng | 20–21 | 21 điều khiển, 20 dữ liệu (chế độ active) | | Nguồn | 175.45.116.100/32 | /32 = đúng MỘT địa chỉ |

/32 là chi tiết quyết định:

175.45.116.100/32  → 1 địa chỉ duy nhất       ✅ đúng yêu cầu
175.45.116.100/0   → MỌI địa chỉ trên Internet ✗ mở toang

/0 bỏ qua hoàn toàn phần địa chỉ — nó khớp với tất cả, hoàn toàn ngược với "should not be accessible publicly".

Và hai cổng của FTP:

Cổng 21: kênh ĐIỀU KHIỂN — lệnh đăng nhập, LIST, RETR, STOR
Cổng 20: kênh DỮ LIỆU (chế độ ACTIVE) — nội dung tệp thật sự

Vì sao dùng security group chứ không phải NACL:

Security group:  áp cho ĐÚNG instance đó, STATEFUL (một rule là đủ)
NACL:            áp cho CẢ SUBNET, STATELESS (phải thêm rule outbound)

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

• **C. Tạo Network ACL inbound rule: TCP, cổng 20–21, Source 175.45.116.100/0, ALLOW — đây là phương án gần nhất về giao thức và cổng, nhưng /0 cho phép toàn bộ Internet. Nó phá huỷ chính yêu cầu của đề.
• **B. Security group: UDP, cổng 20–21 — sai giao thức: FTP dùng TCP. Rule UDP không cho phép kết nối FTP nào.
• **D. Network ACL: UDP, cổng 20–21, Source /0 — sai cả giao thức lẫn phạm vi nguồn.

Ghi nhớ

Ký hiệu CIDR: | Ký hiệu | Số địa chỉ | |---|---| | /32 | 1 — đúng một máy | | /24 | 256 | | /0 | TẤT CẢ — tương đương 0.0.0.0/0 |

Quy tắc nhanh: số càng LỚN thì phạm vi càng HẸP.

FTP active và passive — chi tiết quan trọng mà câu hỏi không nhắc tới: | Chế độ | Kênh dữ liệu | Cổng cần mở | |---|---|---| | Active | máy chủ MỞ kết nối về client từ cổng 20 | 20, 21 | | Passive | client mở kết nối tới cổng cao của máy chủ | 21 + một dải cổng cao |

Trong thực tế, hầu hết client dùng chế độ PASSIVE vì tường lửa phía client thường chặn kết nối vào. Khi đó rule chỉ mở 20–21 là không đủ:

Cần thêm: TCP <dải cổng passive> từ 175.45.116.100/32
    ví dụ 50000–51000, khai trong cấu hình máy chủ FTP:
        pasv_min_port=50000
        pasv_max_port=51000

(Đáp án A vẫn đúng theo bộ đề — nó kiểm tra hiểu biết về giao thức, cổng và ký hiệu CIDR. Nhưng nếu triển khai thật, hãy nhớ dải cổng passive.)

Các cổng thường gặp trong đề thi: | Cổng | Dịch vụ | |---|---| | 20–21 | FTP | | 22 | SSH, SFTP | | 989–990 | FTPS (FTP over SSL) | | 3389 | RDP | | 80 / 443 | HTTP / HTTPS | | 25 / 587 | SMTP | | 53 | DNS |

Và một lưu ý bảo mật quan trọng: FTP truyền mọi thứ dưới dạng VĂN BẢN THUẦN.

Tên đăng nhập, mật khẩu, nội dung tệp — tất cả KHÔNG mã hoá
    → ai nghe lén được đường truyền là đọc được hết

Ba lựa chọn thay thế an toàn hơn: | Lựa chọn | Đặc điểm | |---|---| | SFTP (cổng 22) | FTP qua SSH — mã hoá toàn bộ | | FTPS (cổng 989–990) | FTP qua TLS | | AWS Transfer Family | dịch vụ SFTP/FTPS/AS2 được quản lý, lưu thẳng vào S3 |

AWS Transfer Family đáng cân nhắc nghiêm túc cho tình huống của đề:

Không cần EC2 instance nào để vá lỗi và giám sát
Dữ liệu lưu thẳng vào S3 — bền vững, tự mở rộng
Xác thực bằng IAM, Directory Service, hoặc nhà cung cấp riêng
Sẵn sàng cao dựng sẵn

Nó tính phí theo giờ endpoint cộng phí mỗi GB truyền — đắt hơn tự chạy một máy nhỏ, nhưng loại bỏ toàn bộ công vận hành và rủi ro bảo mật của việc tự quản lý máy chủ FTP.

Ba biện pháp tăng cường nếu vẫn tự chạy FTP server: | Biện pháp | Lý do | |---|---| | Chỉ mở cho IP cụ thể (/32) | ← câu này | | Dùng FTPS thay vì FTP thuần | mã hoá thông tin đăng nhập | | Đặt trong private subnet, vào qua VPN | không phơi ra Internet chút nào | | Ghi log mọi phiên và giám sát | phát hiện truy cập bất thường |

Và một lưu ý về việc khoá theo IP /32: nếu địa chỉ đó do nhà mạng cấp động, rule sẽ ngừng hoạt động khi IP đổi. Với đối tác cố định, hãy yêu cầu họ cung cấp IP tĩnh, hoặc thiết lập VPN site-to-site rồi mở cho dải IP nội bộ.

Đáp án

A — Lưu audit log trong Glacier vault và dùng tính năng Vault Lock.

Vì sao đúng

Đề nêu yêu cầu tuân thủ rất cụ thể: giữ log 5 năm TRƯỚC KHI được phép xoá — và Vault Lock là cơ chế duy nhất thực thi điều đó một cách bất khả xâm phạm.

Cách Vault Lock hoạt động:

① Viết vault lock policy (ví dụ: cấm xoá archive dưới 1825 ngày tuổi)
② Khởi tạo lock → chuyển sang trạng thái InProgress
③ Có 24 GIỜ để kiểm thử policy
④ Hoàn tất lock → chính sách trở nên KHÔNG THỂ THAY ĐỔI VĨNH VIỄN

Sau bước ④, KHÔNG AI sửa hay gỡ được chính sách — kể cả tài khoản root, kể cả AWS.

{"Rule": [{
  "Sid": "giu-log-5-nam",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "glacier:DeleteArchive",
  "Resource": "arn:aws:glacier:...:vaults/kho-audit-log",
  "Condition": {"NumericLessThan":
    {"glacier:ArchiveAgeInDays": "1825"}}}]}

1825 ngày = 5 năm.

Và đây chính là điều mà kiểm toán viên đòi hỏi: WORM (Write Once, Read Many).

Ghi được một lần → đọc bao nhiêu lần cũng được → KHÔNG sửa, KHÔNG xoá
    → đáp ứng SEC 17a-4, FINRA, CFTC và nhiều quy định tài chính khác

Và Glacier còn rẻ nhất cho dữ liệu lưu trữ dài hạn — audit log 5 năm là khối lượng lớn nhưng hiếm khi đọc.

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

• **C. Lưu log trong S3 bucket và bật MFA Delete — đây là phương án gần nhất và cũng làm việc xoá khó hơn, nhưng nó không phải cơ chế bất biến: người có thiết bị MFA vẫn xoá được. Đó là rào cản, không phải ngăn cấm. Với yêu cầu tuân thủ 5 năm, khác biệt này rất quan trọng.
• **B. Lưu trên EBS volume và chụp snapshot hằng tháng — không có cơ chế chống xoá nào: cả volume lẫn snapshot đều xoá được bất cứ lúc nào bởi người có quyền. Và giữ 5 năm dữ liệu trên EBS đắt hơn Glacier rất nhiều.
• **D. Lưu trên EFS và dùng cơ chế khoá tệp của NFSv4 — hiểu sai công cụ: file locking của NFS dùng để điều phối truy cập đồng thời giữa nhiều client, ngăn hai tiến trình ghi đè nhau. Nó không phải cơ chế giữ dữ liệu theo quy định và bị gỡ dễ dàng.

Ghi nhớ

Hai cơ chế WORM của AWS — cần phân biệt: | | Glacier Vault Lock | S3 Object Lock | |---|---|---| | Áp cho | Glacier vault | S3 bucket | | Đơn vị | cả vault, một chính sách | từng object, từng phiên bản | | Chế độ | một loại, khoá vĩnh viễn | Governance và Compliance | | Yêu cầu | — | bucket phải bật VERSIONING | | Truy cập dữ liệu | phải restore (vài phút tới giờ) | tức thì (tuỳ lớp lưu trữ) |

S3 Object Lock có hai chế độ: | Chế độ | Ai vượt qua được | |---|---| | Governance | người có quyền s3:BypassGovernanceRetention | | Compliance | KHÔNG AI — kể cả root |

Compliance mode tương đương Vault Lock về mức độ nghiêm ngặt, nhưng dữ liệu truy cập được ngay thay vì phải restore.

Với thiết kế mới hôm nay, S3 Object Lock ở chế độ Compliance thường là lựa chọn tốt hơn: cùng mức bảo vệ, quản lý theo từng object linh hoạt hơn, và kết hợp được với lifecycle để chuyển sang Glacier tiết kiệm chi phí:

{"Rules": [{
  "Status": "Enabled",
  "Transitions": [{"Days": 90, "StorageClass": "DEEP_ARCHIVE"}]}]}

(Vault Lock vẫn đúng theo bộ đề và vẫn hoạt động tốt; Object Lock ra sau và linh hoạt hơn.)

Hai kiểu giữ dữ liệu trong S3 Object Lock: | Kiểu | Đặc điểm | |---|---| | Retention period | cấm xoá tới một ngày cụ thể | | Legal hold | cấm xoá VÔ THỜI HẠN tới khi gỡ tường minh |

Legal hold dùng cho tranh chấp pháp lý: khi có kiện tụng, dữ liệu liên quan phải giữ dù đã hết thời hạn thông thường.

Ba lớp Glacier — chọn theo tần suất đọc: | Lớp | Truy xuất nhanh nhất | Chi phí lưu trữ | |---|---|---| | Instant Retrieval | mili giây | cao nhất trong nhóm | | Flexible Retrieval | 1–5 phút (Expedited) | vừa | | Deep Archive | 12 giờ | rẻ nhất (~1 USD/TB/tháng) |

Với audit log 5 năm hiếm khi đọc, Deep Archive là lựa chọn kinh tế nhất — chỉ cần chấp nhận chờ 12 giờ trong trường hợp hiếm hoi cần lấy ra.

Ràng buộc thời gian lưu tối thiểu: | Lớp | Tối thiểu | |---|---| | Standard-IA, One Zone-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Deep Archive | 180 ngày |

Ba lưu ý khi triển khai Vault Lock: | Lưu ý | Chi tiết | |---|---| | Kiểm thử kỹ trong 24 giờ InProgress | hoàn tất rồi thì KHÔNG SỬA ĐƯỢC MÃI MÃI | | Chính sách quá chặt sẽ tự làm khó mình | ví dụ cấm xoá 100 năm cho dữ liệu chỉ cần 5 năm | | Vault Lock khác vault access policy | cái sau sửa được bình thường |

Dòng đầu đáng nhấn mạnh: đây là một trong số rất ít thao tác trên AWS không thể hoàn tác. Hãy dùng AbortVaultLock trong 24 giờ nếu phát hiện chính sách sai — sau khi CompleteVaultLock thì không còn đường lùi.

Và một lưu ý về nguồn của audit log: nếu log đến từ CloudTrail, hãy dùng thêm CloudTrail log file validation — nó tạo file digest có chữ ký số cho phép chứng minh log chưa bị sửa đổi kể từ lúc AWS ghi ra. Kết hợp với Object Lock hoặc Vault Lock, bạn có cả tính bất biến lẫn bằng chứng toán học về tính toàn vẹn — đúng thứ kiểm toán viên muốn thấy.