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

Đáp án

A — Cấu hình ứng dụng gửi header Set-Cookie cho người xem và kiểm soát truy cập bằng signed cookie.

Vì sao đúng

Chi tiết quyết định nằm ở một từ trong đề: thành viên cần tải TẤT CẢ các tệp trong bucket. Đó là ranh giới giữa signed URL và signed cookie.

⚠ Điểm mấu chốt: signed URL cấp quyền cho MỘT đối tượng, signed cookie cấp quyền cho cả một nhóm:

Signed URL
        ↓
    Mỗi URL ký cho đúng một đường dẫn
        ↓
    Muốn cho tải 500 tệp → phải sinh 500 URL
        ↓
Signed cookie
        ↓
    Một cookie kèm policy có thể phủ cả một mẫu đường dẫn (/thanh-vien/*)
        ↓
    Trình duyệt tự gửi kèm cookie cho mọi request khớp
        ↓
    → người dùng duyệt và tải tự do trong phạm vi được cấp

Đây cũng là lý do signed cookie hợp khi bạn không muốn đổi URL hiện có — quan trọng nếu trang đã có sẵn nhiều liên kết.

# Ứng dụng đặt ba cookie sau khi xác thực thành viên
# CloudFront-Policy, CloudFront-Signature, CloudFront-Key-Pair-Id

⚠ Signed cookie đi kèm ràng buộc về tên miền:

Cookie gắn với domain
        ↓
    CloudFront distribution và trang web nên dùng chung tên miền gốc
        ↓
    → nếu không, trình duyệt không gửi cookie kèm request tới CloudFront

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

• C (sinh signed URL có hạn cho người dùng đã xác thực) — đây là phương án gần nhất và nó thật sự là cơ chế bảo vệ nội dung đúng đắn của CloudFront. Nhưng nó không hợp với yêu cầu "download all files": mỗi signed URL chỉ có giá trị cho một object, nên ứng dụng phải sinh một URL riêng cho từng tệp mỗi lần người dùng muốn tải. Với một thư viện tài liệu, điều đó vừa tốn công vừa làm hỏng trải nghiệm duyệt nội dung. Signed URL hợp khi bạn phát một liên kết tải cụ thể — ví dụ một hoá đơn, một bản báo cáo.

• B (dùng OAI để chỉ cho người dùng của CloudFront distribution truy cập bucket) — OAI khoá bucket lại chỉ cho CloudFront, nhưng nó không phân biệt được ai là thành viên và ai không. Sau khi bật OAI, mọi người truy cập qua CloudFront đều tải được như nhau. Đây là bước cần thiết nhưng chưa đủ, và không phải câu trả lời cho yêu cầu hạn chế theo tư cách thành viên.

• D (tạo behavior trong CloudFront chuyển tiếp request tới bucket theo path pattern) — chỉ là cấu hình định tuyến. Nó quyết định request đi tới origin nào, hoàn toàn không kiểm soát ai được truy cập.

Ghi nhớ

⚠ Hai cơ chế nội dung riêng tư của CloudFront — bảng phải thuộc: | | Signed URL | Signed cookie | |---|---|---| | Phạm vi | một object | nhiều object theo mẫu đường dẫn | | Phải đổi URL | có | không | | Hợp với | tải một tệp cụ thể | truy cập cả thư viện nội dung | | Với RTMP (cũ) | chỉ signed URL | — |

Từ khoá nhận diện:

"download ALL files" → signed cookie "một tệp cụ thể, liên kết có hạn" → signed URL "OAI" → khoá bucket cho CloudFront, KHÔNG phân biệt người dùng "path pattern behavior" → định tuyến, không phải kiểm soát truy cập cần cả hai lớp → OAI/OAC khoá origin + signed cookie kiểm soát người dùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Không có cookie có bị chặn không | mở URL bằng trình duyệt ẩn danh — phải nhận 403 | | Cookie có được gửi kèm không | tab Network của trình duyệt, xem header Cookie | | Bucket có khoá chưa | curl thẳng vào URL S3 — phải AccessDenied |

Và một lời khuyên: hãy đặt thời hạn cookie ngắn và gia hạn khi người dùng còn hoạt động, thay vì cấp một cookie sống nhiều ngày. Signed cookie cho quyền truy cập cả một kho nội dung, nên nếu nó bị sao chép — người dùng chia sẻ, thiết bị bị mất, một tiện ích trình duyệt đọc được — thì người cầm nó tải được toàn bộ thư viện cho tới khi hết hạn. Không có cách nào thu hồi một cookie đã ký ngoài việc xoay khoá ký, mà điều đó làm mất hiệu lực cookie của mọi thành viên cùng lúc. Thời hạn ngắn là cơ chế thu hồi duy nhất bạn thực sự có.

Đáp án

B — Tái cấu trúc ứng dụng thành các hàm AWS Lambda; dùng AWS Step Functions để điều phối.

Vì sao đúng

Đề nêu ba yêu cầu và một dữ kiện quan trọng: mỗi thành phần xử lý dữ liệu trong vài giây.

⚠ Điểm mấu chốt: Step Functions thay thế chính xác thứ mà các script batch đang làm — điều phối có trạng thái:

Script batch cũ
        ↓
    Gọi thành phần 1, chờ, kiểm kết quả, gọi thành phần 2...
    Tự xử lý lỗi, tự thử lại, tự ghi nhận đang ở bước nào
        ↓
Step Functions
        ↓
    Máy trạng thái khai báo bằng JSON: bước nào, rẽ nhánh ra sao,
    thử lại thế nào, lỗi thì đi đâu
        ↓
    → toàn bộ logic điều phối thành cấu hình, có giao diện xem trực quan

{
  "StartAt": "TrichXuat",
  "States": {
    "TrichXuat": {"Type": "Task", "Resource": "arn:...:ham-trich-xuat",
                  "Retry": [{"ErrorEquals": ["States.TaskFailed"], "MaxAttempts": 3}],
                  "Next": "BienDoi"},
    "BienDoi":  {"Type": "Task", "Resource": "arn:...:ham-bien-doi", "End": true}
  }
}

⚠ Chọn Express workflow khi tần suất cao và mỗi lần chạy ngắn: | Loại | Thời gian tối đa | Tính tiền | |---|---|---| | Standard | 1 năm | theo số bước chuyển trạng thái | | Express | 5 phút | theo thời gian chạy và bộ nhớ — rẻ hơn nhiều ở tần suất cao |

Với các thành phần chỉ mất vài giây, Express thường rẻ hơn đáng kể.

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

• D (tái cấu trúc thành container trên Fargate, dùng Step Functions điều phối) — đây là phương án gần nhất và nó đúng hoàn toàn về mặt kiến trúc: Step Functions điều phối được Fargate task, và đây là mẫu hợp lệ. Nhưng nó thua về chi phí với chính hình thái tải của đề. Mỗi thành phần chỉ chạy vài giây, trong khi một Fargate task mất hàng chục giây chỉ để khởi động, và tính tiền theo giây với mức tối thiểu một phút. Lambda khởi động trong mili giây và tính tiền theo mili giây — đúng thứ hợp với tác vụ ngắn. Đề hỏi "most cost-effectively", nên đây là điểm quyết định.

• C (container trên ECS, dùng SQS để tách rời các thành phần) — hai vấn đề. SQS tách rời chứ không điều phối: nó không biết thứ tự các bước, không rẽ nhánh, không thử lại theo logic nghiệp vụ, không cho biết một luồng đang ở đâu. Đề đòi "fully coordinated", và đó là việc của Step Functions. Container cũng nặng hơn cần thiết cho tác vụ vài giây.

• A (Lambda, dùng EventBridge để tự động hoá) — đúng phần Lambda nhưng sai công cụ điều phối. EventBridge định tuyến sự kiện — nó rất tốt để nối các hệ thống theo kiểu phát và nhận, nhưng nó không giữ trạng thái của một quy trình: không biết bước nào đã xong, không thử lại theo bước, không rẽ nhánh có điều kiện. Một chuỗi nhiều bước phụ thuộc nhau cần máy trạng thái.

Ghi nhớ

⚠ Bốn dịch vụ nối các thành phần — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Step Functions | điều phối có trạng thái: thứ tự, rẽ nhánh, thử lại, xử lý lỗi | | EventBridge | định tuyến sự kiện theo luật, không giữ trạng thái | | SQS | hàng đợi, tách rời tốc độ | | SNS | phát tán một sự kiện tới nhiều nơi |

Từ khoá nhận diện:

"fully coordinated" / "orchestrate" → Step Functions "decouple" → SQS "route events" → EventBridge tác vụ chỉ vài giây → Lambda rẻ hơn Fargate "batch scripts coordinating components" → đó chính là mô tả của Step Functions

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luồng đang ở đâu | biểu đồ trực quan trong console Step Functions | | Bước nào hay hỏng | chỉ số ExecutionsFailed theo state | | Chi phí có hợp lý không | so Standard và Express với tần suất thật |

Và một lời khuyên: hãy so chi phí Standard và Express workflow bằng chính tần suất thật của bạn trước khi chọn. Với một quy trình chạy vài lần mỗi ngày, Standard rẻ hơn và cho lịch sử đầy đủ để gỡ lỗi. Với một quy trình chạy hàng trăm nghìn lần mỗi ngày — điều rất dễ xảy ra khi bạn thay các script batch bằng một luồng cho mỗi bản ghi — Standard tính tiền theo từng bước chuyển trạng thái, và con số đó nhân lên rất nhanh. Khoảng cách giữa hai lựa chọn có thể là hàng chục lần, và nó chỉ hiện ra trên hoá đơn tháng đầu tiên sau khi lên production.

Đáp án

B, E — hai thay đổi để chuyển vùng thật sự xảy ra khi cơ sở dữ liệu ở một Region hỏng:

• E — Viết health check tuỳ chỉnh xác minh truy cập được endpoint cơ sở dữ liệu ở mỗi Region; thêm health check đó vào latency-based routing policy.
• B — Đặt Evaluate Target Health thành Yes trên các latency alias record của cả hai Region.

Vì sao đúng

Cuộc thử nghiệm thất bại vì Route 53 không biết gì về sức khoẻ của cơ sở dữ liệu. Nó chỉ thấy ALB, và ALB vẫn khoẻ.

⚠ Điểm mấu chốt: health check phải kiểm tra thứ THẬT SỰ quyết định ứng dụng có phục vụ được hay không:

Health check mặc định trỏ vào ALB
        ↓
    ALB trả 200 vì web server vẫn chạy
        ↓
    Nhưng ứng dụng không kết nối được cơ sở dữ liệu
        ↓
    → Route 53 thấy "khoẻ", không chuyển vùng
        ↓
    → người dùng vẫn bị gửi tới Region hỏng và nhận lỗi

Health check phải gọi một endpoint chạm tới cơ sở dữ liệu:

# /health-sau — endpoint kiểm tra sâu
def health():
    try:
        db.execute("SELECT 1")
        return "OK", 200
    except Exception:
        return "DB unavailable", 503

Vì sao cần cả Evaluate Target Health (B). Với alias record trỏ tới ALB, tuỳ chọn này bảo Route 53 xét sức khoẻ của đích khi quyết định trả về bản ghi nào. Không bật thì Route 53 trả về bản ghi bất kể tình trạng.

⚠ Health check của Route 53 gọi từ nhiều nơi trên thế giới — endpoint phải cho phép chúng:

Route 53 health checker gọi từ nhiều Region
        ↓
    Security group hoặc WAF chặn chúng
        ↓
    → health check báo unhealthy dù ứng dụng hoàn toàn khoẻ
        ↓
    → phải cho phép dải IP của health checker (có prefix list riêng)

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

• C (đổi sang failover routing policy với cấu hình active-active, viết health check xác minh truy cập ALB ở mỗi Region) — đây là phương án gần nhất và nó cũng thêm health check. Nhưng nó hỏng ở hai điểm. Thứ nhất, health check của nó chỉ kiểm tới ALB — đúng cái đang không phát hiện được sự cố cơ sở dữ liệu, nên vấn đề gốc còn nguyên. Thứ hai, đổi sang failover policy làm mất định tuyến theo độ trễ mà công ty đang cố ý dùng để tối ưu hiệu năng cho người dùng toàn cầu; latency-based routing kết hợp health check đã đủ để đạt cả hai mục tiêu.

• D (đặt Evaluate Target Health thành Yes trên các FAILOVER alias record) — mô tả một thứ không tồn tại trong cấu hình hiện tại: công ty đang dùng latency-based routing, không có failover alias record nào. Bản thân việc bật Evaluate Target Health là đúng, nhưng phải bật trên đúng loại bản ghi đang dùng.

• A (viết health check truy vấn AWS Service Dashboard API để xác minh dịch vụ RDS khoẻ ở mỗi Region) — sai nguồn thông tin. Service Health Dashboard phản ánh tình trạng dịch vụ của AWS ở mức Region, không phản ánh cụm RDS của bạn. Một cơ sở dữ liệu bị chặn truy cập, hết kết nối, hay hỏng do lỗi cấu hình sẽ không xuất hiện ở đó chút nào.

Ghi nhớ

⚠ Bốn loại health check của Route 53 — bảng phải thuộc: | Loại | Kiểm gì | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới một địa chỉ | | Calculated | gộp kết quả nhiều health check khác | | CloudWatch alarm | theo trạng thái của một alarm — linh hoạt nhất | | Recovery control | dùng với Application Recovery Controller |

Từ khoá nhận diện:

"chuyển vùng không xảy ra" → health check không kiểm đúng thứ cần kiểm alias record trỏ tới tài nguyên AWS → bật Evaluate Target Health "health check kiểm tới ALB" khi vấn đề ở CSDL → chưa đủ sâu "Service Health Dashboard API" → SAI, đó là tình trạng dịch vụ AWS không phải của bạn đổi sang failover policy khi đang cần định tuyến theo độ trễ → mất mục tiêu hiệu năng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Health check có nhạy không | làm hỏng thật phụ thuộc và bấm giờ tới lúc DNS đổi | | Route 53 đang trả về gì | dig <ten-mien> từ nhiều nơi | | Health checker có bị chặn không | kiểm security group cho phép prefix list của Route 53 |

Và một lời khuyên: hãy diễn tập bằng cách làm hỏng đúng thành phần mà bạn muốn health check phát hiện, không phải làm hỏng thành phần dễ nhất. Đây chính là điều đội kiểm thử trong đề đã làm đúng — họ chặn cơ sở dữ liệu chứ không tắt web server — và nhờ vậy họ tìm ra lỗ hổng thật. Một bài diễn tập tắt EC2 sẽ luôn thành công vì health check trỏ vào ALB bắt được ngay, và bạn sẽ kết luận hệ thống DR hoạt động tốt. Chỉ khi làm hỏng đúng thứ mà health check không nhìn tới, bạn mới biết nó không nhìn tới.

Đáp án

D — Tạo SQS queue; cấu hình web server hiện có publish vào queue; dùng EC2 trong Auto Scaling group đọc và xử lý tệp; co giãn theo độ dài hàng đợi; lưu tệp đã xử lý trong S3.

Vì sao đúng

Một con số trong đề loại thẳng Lambda: mỗi tệp mất tới 1 giờ để xử lý.

⚠ Điểm mấu chốt: Lambda có trần 15 phút — không có cách nào lách:

Tệp cần 1 giờ xử lý
        ↓
    Lambda dừng ở 15 phút, ném timeout
        ↓
    → phương án A và B bất khả thi ngay từ đầu
        ↓
    → tác vụ dài cần EC2, ECS/Fargate, hoặc AWS Batch

Vì sao co giãn theo độ dài hàng đợi. Đây là chỉ số đúng cho tải kiểu này: CPU của các máy đang xử lý luôn cao (chúng đang bận cả giờ), nên co giãn theo CPU sẽ không phản ánh khối lượng còn tồn.

# Chỉ số nên dùng: số tin nhắn chờ chia cho số instance
aws autoscaling put-scaling-policy --policy-type TargetTrackingScaling \
  --target-tracking-configuration file://theo-hang-doi.json

⚠ Visibility timeout phải dài hơn thời gian xử lý, nếu không tệp bị xử lý nhiều lần:

Visibility timeout mặc định 30 giây, thời gian xử lý 1 giờ
        ↓
    Tin nhắn hiện lại trong hàng đợi khi máy vẫn đang xử lý
        ↓
    Máy khác nhận cùng tin nhắn đó
        ↓
    → cùng một tệp bị xử lý nhiều lần, không có lỗi nào báo
        ↓
    → đặt visibility timeout ≥ thời gian xử lý tối đa, hoặc gọi
      ChangeMessageVisibility định kỳ trong lúc xử lý

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

• B (SQS queue — đúng; nhưng gọi Lambda để xử lý tệp, lưu vào S3) — đây là phương án gần nhất và hai phần ba của nó chính xác: SQS là hàng đợi đúng, S3 là kho lưu đúng và rẻ hơn EFS. Nó chỉ sai ở tầng tính toán: Lambda tối đa 15 phút, trong khi tệp cần tới 1 giờ. Không có cấu hình nào nâng được trần đó. Đây là bẫy hay vì mọi thứ khác đều là lựa chọn tốt, và người đọc nhanh dễ bỏ qua con số "1 hour" trong đề.

• A (Amazon MQ queue, Lambda xử lý, lưu vào EFS) — ba chỗ kém hơn. Amazon MQ chạy trên broker instance tính tiền 24/7 — đắt hơn SQS vốn tính theo request, và MQ sinh ra để giữ tương thích với ứng dụng cũ dùng JMS/AMQP, không phải cho hệ thống mới. Lambda vẫn vướng trần 15 phút. Và EFS đắt hơn S3 nhiều lần cho việc lưu tệp.

• C (Amazon MQ, tạo EC2 mới khi có tin nhắn, lưu vào EFS, tắt máy sau khi xong) — tự viết lại Auto Scaling bằng tay: phải tự phát hiện có tin nhắn, tự khởi động máy, tự tắt. Cộng với chi phí broker MQ và EFS.

Ghi nhớ

⚠ Bốn lựa chọn tính toán theo thời gian chạy — bảng phải thuộc: | Thời gian mỗi tác vụ | Lựa chọn | |---|---| | Dưới 15 phút | Lambda | | Vài phút tới vài giờ | ECS/Fargate, hoặc EC2 + Auto Scaling | | Job tính toán nặng theo lô | AWS Batch | | Rất dài, cần điều phối nhiều bước | Step Functions gọi các tác vụ trên |

Từ khoá nhận diện:

"up to 1 hour to process" → loại Lambda ngay "queue length varies by time of day" → co giãn theo độ dài hàng đợi "Amazon MQ" cho hệ thống mới → đắt, dùng cho tương thích ứng dụng cũ "EFS" để lưu tệp đã xử lý → S3 rẻ hơn nhiều "tạo EC2 mới rồi tắt" thủ công → đó là việc của Auto Scaling

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có xử lý trùng không | so số tệp vào với số kết quả ra | | Hàng đợi có tồn đọng không | ApproximateAgeOfOldestMessage | | Máy có co về 0 ngoài giờ không | lịch sử Auto Scaling |

Và một lời khuyên: hãy gọi ChangeMessageVisibility định kỳ trong lúc xử lý, thay vì đặt một visibility timeout thật dài ngay từ đầu. Đặt timeout một giờ nghe an toàn, nhưng nó có mặt trái: nếu máy xử lý chết giữa chừng, tin nhắn đó nằm im một giờ trước khi có máy khác nhận lại — nghĩa là một tệp bị kẹt rất lâu mà không ai biết. Gia hạn định kỳ trong lúc còn sống cho bạn cả hai: tin nhắn không bị nhận trùng khi đang xử lý, và quay lại hàng đợi rất nhanh khi máy xử lý biến mất.

Đáp án

B — Dựng API bằng API Gateway và Lambda; dùng S3 host tài nguyên web tĩnh; tạo CloudFront distribution với bucket S3 làm origin; dùng Amazon Cognito cho việc quản lý và xác thực người dùng.

Vì sao đúng

Đề nêu bốn yêu cầu, và một chi tiết dễ bỏ qua quyết định giữa B và C: bảo vệ DDoS cơ bản.

⚠ Điểm mấu chốt: Shield Standard bảo vệ DDoS tự động và miễn phí — nhưng nó phát huy mạnh nhất khi có CloudFront ở phía trước:

CloudFront + Shield Standard
        ↓
    Hấp thụ tấn công tầng 3/4 tại điểm biên, trước khi chạm hạ tầng của bạn
    Mạng biên có dung lượng rất lớn, phân tán toàn cầu
        ↓
    → đây là "baseline DDoS protection" mà đề nói tới, không tốn thêm tiền
        ↓
WAF (phương án C)
        ↓
    Lọc tầng 7 theo nội dung — chống SQLi, XSS, bot
        ↓
    → hữu ích, nhưng KHÔNG phải cơ chế chống DDoS cơ bản, và tính phí riêng

Vì sao Cognito. Đề nói người dùng đăng nhập bằng social IdP như Google và Amazon. Cognito user pool hỗ trợ sẵn các nhà cung cấp đó, xử lý luồng OAuth, quản lý token — không phải viết dòng nào.

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

• C (API Gateway + Lambda, S3 host web tĩnh, tạo AWS WAF Web ACL để giảm thiểu tấn công DDoS, Cognito) — đây là phương án gần nhất và ba phần tư của nó giống hệt đáp án đúng. Nó khác ở hai điểm: không có CloudFront, và dùng WAF làm biện pháp chống DDoS. Thiếu CloudFront nghĩa là không đạt yêu cầu độ trễ thấp cho khách toàn cầu — nội dung tĩnh phục vụ thẳng từ một Region. Và WAF là công cụ lọc tầng 7, không phải cơ chế hấp thụ DDoS; Shield Standard đi kèm CloudFront mới là "baseline DDoS protection". Đây là bẫy đòi phân biệt WAF với Shield.

• A (API bằng container ECS sau CloudFront, dùng Secrets Manager cho chức năng xác thực người dùng) — hai lỗi. ECS không phải serverless theo nghĩa đề yêu cầu (kể cả Fargate cũng là container phải quản lý định nghĩa). Và Secrets Manager lưu bí mật, không phải dịch vụ quản lý người dùng — nó không đăng ký, không đăng nhập, không liên kết social IdP.

• D (container Fargate ở nhiều Region sau ALB, Route 53 latency-based routing, Cognito) — đạt được độ trễ thấp nhưng không serverless và phức tạp hơn nhiều: triển khai đa Region cho một ứng dụng web mới là mức đầu tư lớn, trong khi CloudFront đạt cùng mục tiêu với một distribution duy nhất.

Ghi nhớ

⚠ Bốn lớp bảo vệ và vai trò thật — bảng phải thuộc: | Lớp | Chống gì | Chi phí | |---|---|---| | Shield Standard | DDoS tầng 3/4, tự động | miễn phí, bật sẵn | | Shield Advanced | DDoS lớn, có đội hỗ trợ và bảo vệ chi phí | trả phí tháng | | WAF | tấn công tầng 7 theo nội dung | theo web ACL và request | | CloudFront | phân tán tải, là nơi Shield phát huy | theo lưu lượng |

Từ khoá nhận diện:

"baseline DDoS protection" → CloudFront + Shield Standard "fully serverless" → S3, CloudFront, API Gateway, Lambda, Cognito, DynamoDB "social IdP như Google, Amazon" → Cognito user pool "WAF để chống DDoS" → SAI vai trò, WAF lọc tầng 7 "Secrets Manager cho xác thực người dùng" → LUÔN SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nội dung có được cache không | CacheHitRate của CloudFront | | Đăng nhập social có chạy không | thử luồng OAuth với từng IdP | | Bucket có khoá chưa | curl thẳng URL S3 — phải AccessDenied |

Và một lời khuyên: hãy đặt CloudFront trước cả nội dung tĩnh lẫn API, không chỉ trước S3. Nhiều thiết kế chỉ đưa phần tĩnh qua CloudFront rồi để API Gateway phơi trực tiếp — và như vậy phần dễ bị tấn công nhất lại là phần không được mạng biên bảo vệ. Đưa API qua cùng một distribution cho bạn cả Shield Standard lẫn khả năng gắn WAF ở một chỗ, và còn cho phép cache những phản hồi GET lặp lại. Không có gì trong hệ thống nhắc bạn về khoảng hở đó, vì cả hai đường đều hoạt động hoàn hảo cho tới ngày có người thật sự nhắm vào bạn.

Đáp án

B — Cấu hình một instance Amazon RDS với cross-Region read replica ở Region khác; khi Region chính hỏng thì thăng cấp read replica thành cơ sở dữ liệu chính.

Vì sao đúng

Hai chỉ tiêu của đề — RPO dưới 5 phút và RTO dưới 15 phút — cùng với yêu cầu chi phí thấp nhất dẫn tới một lựa chọn duy nhất.

⚠ Điểm mấu chốt: sao chép liên tục cho RPO tính bằng giây; snapshot theo chu kỳ thì RPO bằng chính chu kỳ đó:

Cross-Region read replica
        ↓
    Sao chép bất đồng bộ liên tục, độ trễ thường vài giây
        ↓
    → RPO đạt được dễ dàng dưới 5 phút

Snapshot mỗi 5 phút (phương án C)
        ↓
    Với 15 TB, một chu kỳ snapshot KHÔNG xong trong 5 phút
        ↓
    Snapshot sau chồng lên snapshot trước chưa hoàn thành
        ↓
    → RPO thực tế tệ hơn nhiều so với con số mong muốn

aws rds create-db-instance-read-replica \
  --db-instance-identifier du-phong-tokyo \
  --source-db-instance-identifier arn:aws:rds:ap-southeast-1:...:db:chinh \
  --region ap-northeast-1

# khi sự cố
aws rds promote-read-replica --db-instance-identifier du-phong-tokyo

⚠ Promote là thao tác MỘT CHIỀU — sau đó replica trở thành cụm độc lập:

Promote read replica
        ↓
    Liên kết sao chép với nguồn bị cắt vĩnh viễn
        ↓
    → không quay lại được; muốn khôi phục cấu hình cũ phải dựng replica mới
        ↓
    → vì thế alarm kích hoạt chuyển vùng phải đủ chặt, tránh báo động giả

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

• A (Aurora ở Region chính và một cụm Aurora riêng ở Region phụ, dùng DMS sao chép liên tục giữa hai cụm) — đây là phương án gần nhất và DMS với CDC thật sự sao chép liên tục được, nên về lý thuyết đạt RPO. Nhưng nó là đường vòng đắt đỏ: bạn phải trả tiền cho replication instance của DMS chạy 24/7 cộng với cụm Aurora thứ hai, và phải giám sát thêm một thành phần có thể hỏng. Aurora vốn đã có Global Database làm đúng việc đó ở tầng lưu trữ, nhanh hơn và không cần thành phần trung gian. Với yêu cầu "minimizing costs", dùng DMS để nối hai cụm cùng engine là chọn công cụ sai.

• C (Aurora với snapshot mỗi 5 phút, sao chép snapshot sang Region phụ, khôi phục khi có sự cố) — hỏng cả hai chỉ tiêu. Snapshot của 15 TB không hoàn thành trong 5 phút, và khôi phục từ snapshot mất hàng chục phút tới hàng giờ — vượt xa RTO 15 phút.

• D (RDS với read replica trong CÙNG Region) — không đáp ứng yêu cầu cốt lõi: đề đòi chuyển vùng sang Region dự phòng. Một replica cùng Region không bảo vệ được trước sự cố ở mức Region.

Ghi nhớ

⚠ Bốn cách sao chép cơ sở dữ liệu sang Region khác — bảng phải thuộc: | Cách | RPO | RTO | |---|---|---| | RDS cross-Region read replica | vài giây | vài phút (promote) | | Aurora Global Database | ~1 giây | dưới 1 phút | | Sao chép snapshot | bằng chu kỳ chụp | hàng chục phút tới giờ | | DMS với CDC | vài giây | vài phút — nhưng thêm thành phần phải vận hành |

Từ khoá nhận diện:

"RPO dưới 5 phút" → sao chép liên tục, loại snapshot "RTO dưới 15 phút" + 15 TB → loại khôi phục từ snapshot "cost-effective failover to another Region" → read replica, không phải DMS "read replica cùng Region" khi cần chuyển vùng → không bảo vệ được sự cố Region Aurora + đa Region → Global Database, không phải DMS |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ sao chép | chỉ số ReplicaLag | | RTO thật | diễn tập promote, bấm giờ | | Ứng dụng có đổi endpoint được không | thử đổi và chạy toàn bộ luồng nghiệp vụ |

Và một lời khuyên: hãy diễn tập chuyển vùng trên một bản sao, và nhớ rằng promote là thao tác không đảo ngược. Đây là điểm khác biệt lớn giữa diễn tập DR cho cơ sở dữ liệu và cho các tầng khác: bạn có thể tắt bật máy chủ web bao nhiêu lần cũng được, nhưng mỗi lần promote một read replica là bạn vĩnh viễn cắt nó khỏi nguồn và phải dựng lại từ đầu — với 15 TB, việc dựng lại đó mất hàng giờ và tốn băng thông xuyên Region. Vì thế hãy diễn tập trên một replica dựng riêng cho mục đích đó, chứ đừng dùng chính replica đang bảo vệ production.

Đáp án

B — Tạo pipeline trong CodePipeline với giai đoạn triển khai dùng chiến lược blue/green; theo dõi ứng dụng và nếu có vấn đề thì kích hoạt lùi lại thủ công qua CodeDeploy.

Vì sao đúng

Đề đòi hai thứ: triển khai nhanh với downtime tối thiểu, và lùi lại nhanh khi có lỗi. Blue/green là chiến lược duy nhất đạt cả hai.

⚠ Điểm mấu chốt: blue/green cho ECS đổi TARGET GROUP của ALB — không phải thay task tại chỗ:

Target group xanh dương đang nhận tải
        ↓
    CodeDeploy dựng task set mới với image mới, đăng ký vào target group xanh lá
        ↓
    Chờ health check của target group mới qua
        ↓
    Đổi listener của ALB sang target group xanh lá
        ↓
    → chuyển tức thì, không có task nào vừa phục vụ vừa bị thay
    → có sự cố thì đổi ngược listener trong vài giây

CodeDeploy còn cho bake time — giữ cả hai task set trong một khoảng để theo dõi trước khi dọn cái cũ:

{
  "deploymentConfigName": "CodeDeployDefault.ECSCanary10Percent5Minutes",
  "blueGreenDeploymentConfiguration": {
    "terminateBlueInstancesOnDeploymentSuccess": {
      "action": "TERMINATE", "terminationWaitTimeInMinutes": 60
    }
  }
}

⚠ Đừng đặt terminationWaitTimeInMinutes bằng 0 để tiết kiệm:

Dọn task set cũ ngay sau khi chuyển
        ↓
    Mất khả năng lùi lại chỉ sau vài giây
        ↓
    Nhiều lỗi chỉ lộ ra sau khi đủ lưu lượng thật đi qua
        ↓
    → giữ ít nhất 30–60 phút

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

• C (dùng CloudFormation tạo stack test và production; theo dõi và nếu có vấn đề thì đẩy bản cập nhật khác) — đây là phương án gần nhất và có môi trường test riêng là thực hành tốt. Nhưng nó không đáp ứng yêu cầu lùi lại nhanh: "push another code update" nghĩa là viết bản sửa, build, chạy lại pipeline — trong khi sự cố đang diễn ra trên ứng dụng quan trọng. Đó là cách chậm nhất để phản ứng, và nó đòi bạn phải biết nguyên nhân trước khi khắc phục được. Blue/green cho phép quay về trạng thái tốt đã biết mà không cần hiểu gì cả.

• D (chiến lược in-place; nếu có vấn đề thì đẩy bản cập nhật khác) — in-place thay task tại chỗ, nên có khoảng dịch vụ suy giảm trong lúc triển khai, và lùi lại phải triển khai lại từ đầu. Vi phạm cả hai yêu cầu.

• A (dùng AWS OpsWorks với in-place deployment) — hai vấn đề. OpsWorks không triển khai ECS — nó là công cụ quản lý cấu hình dựa trên Chef/Puppet cho máy chủ. Và nó đã ngừng hoạt động từ tháng 5/2024. Cộng thêm nhược điểm của in-place.

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

⚠ AWS OpsWorks đã ngừng hoạt động từ 26/5/2024:

Phương án A nhắc tới OpsWorks
        ↓
    Nó vốn đã sai vì OpsWorks không triển khai ECS
        ↓
    → nhưng cũng là dấu hiệu tuổi đời của bộ đề; công cụ thay thế là CodeDeploy

Ghi nhớ

⚠ Ba kiểu triển khai cho ECS — bảng phải thuộc: | Kiểu | Cơ chế | Lùi lại | |---|---|---| | Rolling update (mặc định của ECS) | thay dần task theo minimumHealthyPercent | chậm | | Blue/green qua CodeDeploy | đổi target group của ALB | vài giây | | External | tự quản lý task set bằng API | tuỳ bạn |

Từ khoá nhận diện:

"minimum downtime" + "quickly roll back" → blue/green "push another code update" để khắc phục → SAI, đó không phải lùi lại "in-place" khi đòi không downtime → SAI "OpsWorks" cho ECS → SAI, và dịch vụ đã ngừng ECS + blue/green → CodeDeploy, không phải ECS rolling update

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lùi lại có nhanh không | diễn tập trong môi trường thử | | Task set cũ còn bao lâu | kiểm terminationWaitTimeInMinutes | | Health check có đủ sâu không | endpoint phải chạm tới phụ thuộc quan trọng |

Và một lời khuyên: hãy gắn CloudWatch alarm vào deployment group để CodeDeploy tự lùi lại, thay vì dựa vào việc con người bấm nút. Phương án đúng của đề nói "trigger a manual rollback", và điều đó chấp nhận được — nhưng khả năng quay về trong vài giây chỉ có giá trị nếu ai đó nhận ra vấn đề trong vài giây. Với một bản phát hành lúc nửa đêm, hoặc một lỗi biểu hiện thành tỷ lệ giao dịch thất bại tăng thêm hai phần trăm, con người không phải cơ chế phát hiện đáng tin. Một alarm thì có, và nó không cần ai thức.

Đáp án

B — Chạy EC2 trong private subnet với tuyến đi ra qua NAT gateway đặt ở public subnet; gán Elastic IP cho NAT gateway để nhà cung cấp API đưa vào danh sách cho phép.

Vì sao đúng

Đề đòi một địa chỉ IP công cộng duy nhất cho toàn bộ lưu lượng đi ra, và không được sửa ứng dụng. NAT gateway đáp ứng cả hai một cách tự nhiên.

⚠ Điểm mấu chốt: NAT gateway ghi đè IP nguồn ở tầng mạng — trong suốt hoàn toàn với ứng dụng:

EC2 trong private subnet gọi API bên ngoài
        ↓
    Tuyến 0.0.0.0/0 trỏ tới NAT gateway
        ↓
    NAT gateway thay IP nguồn bằng Elastic IP của chính nó
        ↓
    → nhà cung cấp API luôn thấy đúng một địa chỉ
    → ứng dụng không cần biết, không cần cấu hình proxy

Đây là điểm phân biệt với các phương án dùng proxy: chúng đòi đặt biến môi trường HTTP_PROXY, tức là sửa cấu hình ứng dụng — trái yêu cầu của đề.

aws ec2 create-nat-gateway --subnet-id subnet-public-1a \
  --allocation-id eipalloc-abc123

aws ec2 create-route --route-table-id rtb-private \
  --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-abc123

⚠ Mỗi NAT gateway có Elastic IP riêng — nhiều AZ nghĩa là nhiều IP phải whitelist:

Dựng NAT gateway ở mỗi AZ để chịu lỗi
        ↓
    Mỗi cái một Elastic IP khác nhau
        ↓
    Nhà cung cấp chỉ cho phép MỘT địa chỉ
        ↓
    → phải chọn: một NAT gateway (một IP, mất AZ đó là mất đường ra)
      hoặc thương lượng để whitelist nhiều địa chỉ

Với ràng buộc "a single source public IP address per customer" của đề, một NAT gateway là lựa chọn bắt buộc.

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

• A (EC2 trong private subnet, đặt tham số HTTP_PROXY trỏ tới EC2 proxy ở public subnet, gán Elastic IP cho proxy) — đây là phương án gần nhất và nó thật sự cho ra một IP nguồn duy nhất. Nhưng nó đòi sửa cấu hình ứng dụng để trỏ vào proxy, trong khi đề nói rõ "without making modifications to the company's application". Nó cũng thêm một EC2 phải vá, giám sát và tự lo tính sẵn sàng — trong khi NAT gateway là dịch vụ có quản lý. Chi tiết HTTP_PROXY (thay vì HTTPS_PROXY) còn không khớp với việc API dùng HTTPS.

• C (EC2 trong public subnet, đặt HTTPS_PROXY và NO_PROXY trỏ tới EC2 proxy) — cùng vấn đề phải sửa cấu hình ứng dụng, cộng thêm việc đặt máy ứng dụng vào public subnet — kém an toàn hơn và không cần thiết.

• D (EC2 trong public subnet với internet gateway, gán Elastic IP cho internet gateway) — sai về kỹ thuật. Internet gateway không có Elastic IP — nó là một thành phần VPC không có địa chỉ. Và nếu mỗi EC2 trong public subnet có Elastic IP riêng thì nhà cung cấp thấy nhiều IP khác nhau, đúng thứ ràng buộc của đề cấm.

Ghi nhớ

⚠ Bốn cách kiểm soát IP nguồn khi đi ra Internet — bảng phải thuộc: | Cách | Sửa ứng dụng | IP nguồn | |---|---|---| | NAT gateway | không | Elastic IP của NAT | | NAT instance | không | Elastic IP của instance | | Proxy (Squid, v.v.) | có — phải cấu hình proxy | IP của proxy | | EC2 có Elastic IP riêng | không | mỗi máy một IP |

Từ khoá nhận diện:

"single source public IP" + không sửa ứng dụng → NAT gateway với Elastic IP "HTTP_PROXY / HTTPS_PROXY" → đòi sửa cấu hình ứng dụng "Elastic IP cho internet gateway" → LUÔN SAI, IGW không có IP EC2 trong public subnet với IP riêng → nhiều IP nguồn khác nhau cần IP tĩnh cho lưu lượng ĐI VÀO → NLB với Elastic IP, hoặc Global Accelerator

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IP nguồn thật là gì | từ EC2 chạy curl https://checkip.amazonaws.com | | Có đi qua NAT không | kiểm route table của private subnet | | Lưu lượng qua NAT bao nhiêu | chỉ số BytesOutToDestination |

Và một lời khuyên: hãy chạy curl https://checkip.amazonaws.com từ chính EC2 để xác nhận IP nguồn, thay vì suy luận từ sơ đồ mạng. Đây là phép thử một dòng cho một thứ rất dễ sai âm thầm: nếu subnet của máy vô tình có route tới internet gateway thay vì NAT gateway, và máy có IP công cộng, thì mọi thứ vẫn chạy hoàn hảo — chỉ là nhà cung cấp API thấy một địa chỉ khác. Lỗi đó không xuất hiện cho tới khi bên kia bật danh sách cho phép, và lúc đó bạn sẽ đi tìm nguyên nhân trong cấu hình của họ.

Đáp án

A — Đưa các tài khoản thành viên vào một OU duy nhất; tạo SCP từ chối truy cập tập dịch vụ đó và gắn vào OU.

Vì sao đúng

Đề đòi hạn chế các tài khoản thành viên hiện có một cách hiệu quả nhất. SCP gắn ở OU là công cụ đúng, và chỗ gắn là điểm phân biệt với phương án D.

⚠ Điểm mấu chốt: SCP gắn ở ROOT áp cho toàn tổ chức, nhưng KHÔNG áp cho management account — nên gắn ở root là thừa và gây hiểu nhầm:

Gắn SCP ở root
        ↓
    Phủ mọi OU và mọi tài khoản thành viên
    Nhưng management account MIỄN NHIỄM
        ↓
    → về hiệu lực thì giống gắn ở OU chứa các thành viên
    → nhưng gắn ở root khiến mọi tài khoản TƯƠNG LAI, kể cả những tài khoản
      lẽ ra được miễn trừ, đều dính — mất chỗ để tạo ngoại lệ
        ↓
Gắn ở một OU cụ thể
        ↓
    Phạm vi rõ ràng, và còn nguyên nhánh khác để đặt ngoại lệ sau này

aws organizations create-organizational-unit --parent-id r-abc --name ThanhVien
aws organizations move-account --account-id 444455556666 \
  --source-parent-id r-abc --destination-parent-id ou-abc-1

aws organizations attach-policy --policy-id p-chan-dich-vu --target-id ou-abc-1

⚠ SCP đặt TRẦN, không cấp quyền — vẫn cần IAM policy để người dùng làm được việc:

SCP Deny → chặn tuyệt đối, không tầng nào bên dưới cởi được
SCP Allow → chỉ mở trần, không tự cấp quyền cho ai
        ↓
    → quyền hiệu dụng = giao của SCP và IAM policy

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

• D (tạo SCP từ chối tập dịch vụ và gắn vào ROOT của tổ chức) — đây là phương án gần nhất và về hiệu lực tức thời thì gần như tương đương. Nhưng gắn ở root là lựa chọn kém linh hoạt hơn: nó phủ mọi nhánh của tổ chức, mãi mãi, nên khi sau này có một đơn vị cần ngoại lệ hợp lệ, bạn không có cách nào tạo ngoại lệ — vì Deny ở root không thể bị ghi đè ở tầng dưới. Gắn ở OU giữ được khả năng đó bằng cách đặt tài khoản ngoại lệ vào một nhánh khác. Với một chính sách bảo mật sẽ tồn tại lâu dài, đó là khác biệt đáng kể.

• B (tạo IAM policy trong từng tài khoản từ chối truy cập, gắn vào một IAM group và thêm mọi user vào group) — không hiệu quả và không đáng tin. Phải lặp lại ở từng tài khoản, và người dùng có quyền quản trị trong tài khoản đó có thể gỡ nó ra. SCP thì họ không đụng tới được.

• C (tạo IAM role trong mỗi tài khoản thành viên với policy từ chối, tạo user ở management account, yêu cầu người dùng assume role) — phức tạp hơn nhiều, và vẫn có cùng điểm yếu: role có thể bị sửa từ trong chính tài khoản đó. Nó cũng đổi cả mô hình truy cập chỉ để đạt một hạn chế.

Ghi nhớ

⚠ Bốn quy tắc SCP — bảng phải thuộc: | Quy tắc | Hệ quả | |---|---| | SCP đặt trần, không cấp quyền | vẫn cần IAM policy | | Quyền hiệu dụng = giao của mọi SCP từ root xuống | thêm tầng chỉ thu hẹp | | Deny tường minh không thể ghi đè ở tầng dưới | ngoại lệ phải nằm ở nhánh khác | | Không áp cho management account | thử nghiệm ở đó luôn "qua" |

Từ khoá nhận diện:

"restrict services across member accounts" → SCP "MOST efficiently" → một chính sách gắn ở OU "IAM policy trong từng tài khoản" → lặp lại nhiều lần, và gỡ được gắn SCP ở root → hiệu lực tương tự nhưng mất khả năng tạo ngoại lệ cần ngoại lệ về sau → luôn gắn ở OU, không gắn ở root

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP nào đang áp cho tài khoản | list-policies-for-target lặp lên tới root | | SCP có chặn thật không | thử hành động trong chính tài khoản thành viên | | Ai bị chặn nhầm | CloudTrail, lọc errorCode = AccessDenied |

Và một lời khuyên: hãy thử SCP trong một tài khoản thành viên, không bao giờ trong management account. Đây là lỗi im lặng kinh điển với Organizations: SCP không áp cho management account, nên mọi phép thử chạy ở đó đều thành công. Bạn kết luận chính sách chưa có hiệu lực và đi sửa nó, hoặc tệ hơn, kết luận nó không hoạt động và bỏ đi — trong khi nó đang chặn đúng mọi tài khoản khác. Không có thông báo nào giải thích sự khác biệt; lệnh chỉ đơn giản là chạy được.

Đáp án

A, E — hai bước cho môi trường phân tích cách ly hoàn toàn với Internet và dùng khoá do công ty kiểm soát:

• A — Cấu hình cụm EMR dùng AWS CloudHSM cho mã hoá at rest; dựng gateway VPC endpoint cho S3.
• E — Cấu hình bucket policy cho phép truy cập bằng điều kiện aws:sourceVpce khớp id của S3 endpoint.

Vì sao đúng

Hai ràng buộc của đề rất chặt: cách ly hoàn toàn khỏi Internet mọi lúc, và khoá do chính công ty kiểm soát và cung cấp.

⚠ Điểm mấu chốt: "keys controlled and provided by the company" là ngôn ngữ của CloudHSM, không phải KMS:

AWS KMS
        ↓
    AWS vận hành hạ tầng khoá; bạn kiểm soát chính sách nhưng
    khoá nằm trong dịch vụ dùng chung của AWS
        ↓
AWS CloudHSM
        ↓
    HSM chuyên dụng trong VPC của bạn, đạt FIPS 140-2 Level 3
    AWS KHÔNG truy cập được vật liệu khoá
        ↓
    → đây mới là "controlled and provided by the company"

Vì sao gateway endpoint và điều kiện aws:sourceVpce. Gateway endpoint cho S3 giữ lưu lượng trong mạng AWS — không cần NAT, không cần internet gateway. Bucket policy khoá chiều ngược lại:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::du-lieu-phan-tich", "arn:aws:s3:::du-lieu-phan-tich/*"],
  "Condition": {"StringNotEquals": {"aws:sourceVpce": "vpce-0abc123"}}
}

⚠ CloudHSM nằm TRONG VPC của bạn — nên không cần endpoint gì để tới nó:

KMS là dịch vụ công cộng → cần interface endpoint nếu không có đường ra
CloudHSM là các ENI trong chính subnet của bạn → truy cập trực tiếp
        ↓
    → đây là lý do phương án A chỉ cần endpoint cho S3

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

• B (dùng KMS managed CMK cho mã hoá at rest; gateway endpoint cho S3 và interface endpoint cho KMS) — đây là phương án gần nhất và về mặt kỹ thuật nó hoàn toàn chạy được: interface endpoint cho KMS đúng là cách truy cập KMS mà không ra Internet. Nhưng nó không đáp ứng câu "keys that are controlled and provided by the company". Với KMS, kể cả customer managed key, hạ tầng khoá vẫn do AWS vận hành — bạn kiểm soát chính sách chứ không cung cấp và giữ vật liệu khoá. Khi đề dùng đúng cụm từ đó, câu trả lời là CloudHSM.

• D (KMS CMK; gateway endpoint cho S3 và NAT gateway để truy cập KMS) — vi phạm thẳng yêu cầu cách ly: NAT gateway là đường ra Internet. Đề nói "fully isolated from the internet at all times".

• C (bucket policy chỉ cho phép cụm EMR truy cập) — mơ hồ và không đủ. Một cụm EMR không phải một principal đơn lẻ; muốn giới hạn thì phải theo IAM role của cụm hoặc theo VPC endpoint. Và phương án này không nói gì tới mã hoá — một nửa yêu cầu của đề.

Ghi nhớ

⚠ KMS so với CloudHSM — bảng phải thuộc: | | AWS KMS | AWS CloudHSM | |---|---|---| | Ai vận hành hạ tầng khoá | AWS | bạn | | AWS truy cập được vật liệu khoá | không, nhưng dịch vụ dùng chung | không, HSM chuyên dụng | | Chuẩn | FIPS 140-2 Level 3 (HSM nền) | FIPS 140-2 Level 3, HSM riêng | | Vị trí | dịch vụ công cộng | ENI trong VPC của bạn | | Tích hợp dịch vụ AWS | rất sâu, gần như mọi dịch vụ | hạn chế hơn, qua custom key store | | Chi phí | thấp | cao — trả theo giờ mỗi HSM |

Từ khoá nhận diện:

"keys controlled and provided by the company" → CloudHSM "fully isolated from the internet" → VPC endpoint, KHÔNG dùng NAT "aws:sourceVpce" → khoá bucket theo endpoint cụ thể "NAT gateway" khi đòi cách ly hoàn toàn → LUÔN SAI yêu cầu tuân thủ FIPS 140-2 Level 3 với HSM riêng → CloudHSM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đường ra Internet nào không | kiểm route table không có tuyến tới IGW hay NAT | | Bucket có chặn nguồn khác không | thử truy cập từ ngoài VPC — phải bị từ chối | | Endpoint có hoạt động không | từ EMR chạy aws s3 ls và kiểm route |

Và một lời khuyên: hãy kiểm route table của mọi subnet trong VPC, không chỉ subnet chứa EMR. Yêu cầu "cách ly hoàn toàn khỏi Internet" là ràng buộc ở mức VPC, và nó bị phá vỡ bởi bất kỳ subnet nào có tuyến tới internet gateway hoặc NAT gateway — kể cả một subnet được dựng cho mục đích khác và đã bị quên. Không có màn hình nào tổng hợp "VPC này có ra Internet được không"; câu trả lời nằm rải rác trong từng route table, và một tuyến sót lại đủ để vô hiệu hoá toàn bộ thiết kế cách ly.