Ngân hàng đề — AWS Certified Advanced Networking Specialty

Đáp án

B và D — dùng điều kiện Host trong listener của ALB, cho cả dạng ký tự đại diện *.shopping.com lẫn tên miền chính shopping.com

Vì sao đúng

Ba địa chỉ trong đề — mobile.shopping.com, web.shopping.com, api.shopping.com — chỉ khác nhau ở phần tên miền con, tức là ở header Host của yêu cầu HTTP.

ALB hoạt động ở tầng 7 nên đọc được header đó, và host condition trong listener rule cho phép định tuyến từng tên miền tới một target group riêng:

Host = mobile.shopping.com  →  target group cho di động
Host = web.shopping.com     →  target group cho máy tính
Host = api.shopping.com     →  target group cho API

Hai phương án đúng bổ sung cho nhau: B dùng ký tự đại diện *.shopping.com để bắt các tên miền con, D bắt chính shopping.com — vì mẫu *.shopping.com không khớp với tên miền gốc.

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

• A. Dùng điều kiện Path (đường dẫn) — path condition khớp phần sau tên miền (/mobile, /api); ở đây các dịch vụ phân biệt nhau bằng tên miền con, không bằng đường dẫn. Đây là phương án nhiễu chính.
• E. Dùng thành phần Path của hành động Redirect — redirect chuyển hướng trình duyệt sang URL khác, không định tuyến tới target group.
• C — cùng loại điều kiện Host nhưng mẫu tên miền bị lỗi ký tự, không phải mẫu hợp lệ.

Đáp án

B — Triển khai hạ tầng VPC bằng AWS CloudFormation, dùng custom resource để xin một dải CIDR chưa dùng từ dịch vụ IPAM bên ngoài

Vì sao đúng

Bài toán có hai phần, và phải giải cả hai:

• Tự động hoá việc tạo VPC theo chuẩn → CloudFormation là công cụ hạ tầng dưới dạng mã của AWS, bảo đảm mọi VPC được tạo giống nhau.
• Bảo đảm dải CIDR là duy nhất → đây mới là phần khó. CloudFormation không tự biết dải nào đã dùng ở đâu, nên phải hỏi một hệ thống giữ trạng thái toàn cục — chính là IPAM.

Custom resource là cơ chế để CloudFormation gọi ra ngoài: khi chạy stack, nó gọi một hàm Lambda, hàm này hỏi IPAM cấp một dải chưa dùng, và giá trị trả về được dùng làm CIDR cho VPC. IPAM ghi nhận dải đó đã cấp, nên lần sau không cấp trùng.

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

• D. Dùng hàm nội tại Fn::Cidr — hàm này chia nhỏ một dải đã có thành các subnet; nó không biết gì về những dải mà các stack khác đã dùng. Đây là bẫy chính vì tên hàm nghe đúng việc.
• C. Dùng AWS CLI với cờ --dry-run — dry-run chỉ kiểm tra quyền IAM, không kiểm tra xem dải CIDR có bị trùng ở nơi khác không.
• A. Dùng AWS OpsWorks — OpsWorks là dịch vụ quản lý cấu hình máy chủ (Chef, Puppet), không phải công cụ khai báo hạ tầng mạng.

Đáp án

D — Route 53 Resolver inbound endpoint + private hosted zone + bản ghi CNAME trỏ tới tên DNS của EFS + luật chuyển tiếp trên DNS tại chỗ

Vì sao đúng

Bốn mảnh ghép, mỗi mảnh giải một yêu cầu:

Hai chi tiết dễ sai nằm ở loại hosted zone và loại bản ghi.

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

• C và *B. Dùng public hosted zone — sai về bản chất: EFS mount target chỉ có IP riêng, công bố chúng trong vùng công khai vừa vô dụng vừa để lộ cấu trúc mạng nội bộ. C là phương án nhiễu chính vì mọi phần khác đều đúng.
• B còn dùng outbound endpoint, tức là sai chiều: outbound để AWS hỏi ra ngoài, còn ở đây mạng tại chỗ hỏi vào.
• *A. Dùng bản ghi PTR — PTR dùng cho phân giải ngược (từ IP ra tên); ở đây cần chiều thuận, tức là CNAME.

Đáp án

*B — Sửa security group của máy chủ ứng dụng để chỉ cho phép lưu lượng vào cổng 80 từ security group của ELB

Vì sao đúng

Gốc rễ vấn đề nằm ở cấu hình hiện tại: cổng 80 đang mở cho 0.0.0.0/0. Nghĩa là client cấu hình sai có thể gọi thẳng vào địa chỉ của một máy chủ ứng dụng, bỏ qua ELB — và đó là lý do một máy duy nhất bị quá tải trong khi ELB vẫn chia đều lưu lượng cho phần còn lại.

Cách sửa đúng là chỉ chấp nhận lưu lượng đến từ ELB. Security group hỗ trợ điều này rất gọn: nguồn của luật có thể là security group của ELB thay vì một dải IP:

Luật vào của SG máy chủ ứng dụng:
  Cổng 80, nguồn = sg-xxxxx (security group của ELB)

Cách khai theo security group còn có ưu điểm tự thích ứng: node của ELB đổi địa chỉ IP theo thời gian, nhưng luật vẫn đúng vì nó tham chiếu theo nhóm chứ không theo IP.

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

• D. Sửa NACL để chỉ cho phép cổng 80 từ ELB — không làm được: NACL chỉ khai được dải IP, nó không tham chiếu được security group. Mà IP của ELB thì thay đổi. Đây là bẫy chính.
• A. Huỷ instance bị ảnh hưởng cho Auto Scaling tạo máy mới — chỉ chữa triệu chứng: client cấu hình sai sẽ lại dồn vào máy khác.
• C. Xoá ELB rồi tạo lại — không đụng gì tới nguyên nhân.

Đáp án

*A — Bộ phận đó trả phí AWS Direct Connect Data Out

Vì sao đúng

Hai dữ kiện trong đề quyết định câu trả lời:

• Tài khoản mới không nằm trong nhóm thanh toán hợp nhất của tổ chức → nó tự trả hoá đơn của mình.
• Dữ liệu ra khỏi EC2 đi qua private virtual interface của Direct Connect → tính theo biểu giá Direct Connect Data Out, không phải biểu giá Internet.

Nguyên tắc chung: phí truyền dữ liệu ra được tính cho tài khoản sở hữu tài nguyên gửi dữ liệu. Instance EC2 nằm trong VPC của bộ phận, nên hoá đơn về bộ phận đó.

Đây cũng là lý do biểu giá Direct Connect đáng chú ý: Data Out qua Direct Connect rẻ hơn đáng kể so với đi qua Internet — thường là một trong những lý do chính khiến việc đầu tư Direct Connect có lợi về tài chính.

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

• C. Công ty trả phí Direct Connect Data Out — sai vì tài khoản không thuộc nhóm thanh toán hợp nhất; nếu có thì hoá đơn mới dồn về tài khoản mẹ. Đây là phương án nhiễu chính, và chi tiết phân biệt nằm đúng ở câu đầu của đề.
• B và D. Phí Internet Data Out — sai biểu giá: lưu lượng đi qua private VIF của Direct Connect, không ra Internet.

Đáp án

A, C và F — VPC có virtual private gateway, public virtual interface trên Direct Connect, và đường hầm IPsec giữa customer gateway với virtual private gateway

Vì sao đúng

Đề đòi bảo mật và toàn vẹn dữ liệu khi truyền, mà Direct Connect không mã hoá. Vì vậy phải chồng VPN IPsec lên trên Direct Connect — và cấu hình đó có một yêu cầu dễ sai:

Trung tâm dữ liệu
    │  Direct Connect + PUBLIC VIF    (để tới được endpoint VPN công cộng của AWS)
    ▼
Đường hầm IPsec  ────▶  Virtual Private Gateway
    │                    (VPN kết thúc ở đây, dữ liệu đã được mã hoá)
    ▼
              VPC

• C. Phải là public VIF — vì endpoint của Site-to-Site VPN nằm ở địa chỉ IP công cộng của AWS. Private VIF đi thẳng vào VPC nên không tới được endpoint đó.
• A. VPC có virtual private gateway — đầu kết thúc VPN phía AWS.
• F. Đường hầm IPsec giữa customer gateway và VGW — dùng dịch vụ VPN được quản lý của AWS, đây là phần "tiết kiệm nhất" mà đề yêu cầu.

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

• B. Private virtual interface — không tới được endpoint VPN công cộng, như vừa nêu. Đây là bẫy chính vì private VIF là lựa chọn quen thuộc khi nói tới "truy cập VPC".
• *E. IPsec giữa customer gateway và một VPN phần mềm chạy trên EC2 — làm được, nhưng bạn phải tự vận hành, tự bảo đảm sẵn sàng, tự vá lỗi, và trả tiền instance. Kém tiết kiệm hơn dịch vụ được quản lý.
• D. VPC có internet gateway — không cần thiết, và đi ngược mô hình kết nối riêng.

Đáp án

A — Cấu hình ELB với listener TCP, để instance ứng dụng tự kết thúc SSL, cấu hình RDS dùng SSL và cấp quyền kèm REQUIRE SSL

Vì sao đúng

Yêu cầu là mã hoá đầu cuối, nghĩa là không đoạn nào trên đường đi được để dữ liệu ở dạng rõ:

Client ══TLS══▶ ELB (listener TCP: chuyển tiếp nguyên vẹn, KHÔNG giải mã)
       ══TLS══▶ Instance ứng dụng (kết thúc TLS tại đây)
       ══TLS══▶ RDS MySQL (kết nối SSL, bắt buộc bằng REQUIRE SSL)

Ba mảnh đều cần thiết:

• Listener TCP — ELB chỉ chuyển tiếp byte ở tầng 4, không giải mã; nhờ vậy đoạn từ client tới máy chủ ứng dụng được mã hoá liền mạch.
• Instance tự kết thúc SSL — nơi duy nhất dữ liệu được giải mã là chính máy chủ ứng dụng.
• REQUIRE SSL ở tầng cấp quyền của MySQL — đây là phần quan trọng và hay bị quên: cấu hình SSL cho RDS chỉ cho phép kết nối mã hoá, còn REQUIRE SSL mới bắt buộc nó. Không có nó thì một ứng dụng cấu hình sai vẫn kết nối được ở dạng rõ mà chẳng ai biết.

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

• C và D. Đưa việc mã hoá về cho ELB đảm nhiệm (offload) — nghĩa là ELB giải mã rồi gửi tiếp; đoạn từ ELB tới instance thành dạng rõ, phá vỡ mã hoá đầu cuối. Cả hai còn nói cài chứng chỉ SSL lên RDS, điều không làm được — RDS dùng chứng chỉ do AWS quản lý.
• B. Listener HTTP — ELB xử lý ở tầng 7 dưới dạng không mã hoá, hỏng ngay từ chặng đầu.

Đáp án

C — Chiều ra; giao thức TCP; đích 169.254.169.254; cổng đích 80

Vì sao đúng

Ba tham số của luật đều có lý do:

• Chiều ra (outbound) — chính instance là bên khởi tạo yêu cầu tới dịch vụ metadata; đây không phải kết nối đi vào.
• Địa chỉ 169.254.169.254 — địa chỉ link-local cố định, giống nhau ở mọi instance EC2 tại mọi Region.
• Cổng 80 (HTTP) — dịch vụ metadata phục vụ qua HTTP thường, không phải HTTPS.

Điểm cuối hay gây bất ngờ, nhưng nó hợp lý: địa chỉ link-local không bao giờ rời khỏi máy chủ vật lý, nên không có đoạn mạng nào để nghe lén; TLS ở đây chỉ thêm chi phí mà không thêm bảo vệ.

Đây cũng là đường mà IAM role của instance cấp thông tin xác thực tạm thời — nên chặn nó là làm hỏng mọi lời gọi SDK dùng role.

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

• D. Chiều ra, cổng 443 — đúng chiều, sai cổng; dịch vụ metadata không lắng nghe trên 443. Đây là phương án nhiễu chính.
• A và B. Chiều vào — sai chiều; và B còn dùng UDP, trong khi metadata là HTTP trên TCP.

Đáp án

A — Bật VPC Flow Logs cho các elastic network interface của instance, lọc theo lưu lượng bị từ chối, và đẩy log vào CloudWatch Logs

Vì sao đúng

Yêu cầu là ghi lại các kết nối client thất bại, và giải pháp gọn nhất gồm hai lựa chọn:

• Bật flow log ở mức network interface — đúng phạm vi đề yêu cầu. Không cần đụng gì tới kiến trúc hiện tại.
• Lọc theo hành động REJECT — flow log cho phép chọn chỉ ghi lưu lượng bị từ chối. Đây là đòn bẩy chi phí lớn nhất: nếu ghi ALL thì mọi kết nối thành công cũng vào log, mà chúng chiếm phần lớn khối lượng.

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

• B và C. Chuyển instance sang một VPC riêng — hoàn toàn không cần thiết: flow log bật được ở mức network interface, không bắt buộc phải ở mức VPC. Việc di chuyển gây gián đoạn dịch vụ và tốn công mà chẳng thêm giá trị nào. Riêng điều này đã loại cả hai.
• D. Đẩy log qua Kinesis Data Firehose rồi vào S3 — hoạt động được, nhưng thêm một dịch vụ nữa vào đường ống và thêm phí Firehose. Với khối lượng đã được lọc chỉ còn REJECT, đẩy thẳng vào CloudWatch Logs là đường ngắn hơn và ít thành phần hơn.

Ghi chú

Nếu khối lượng log rất lớn và bạn cần lưu trữ lâu dài, hướng Firehose sang S3 lại trở nên kinh tế hơn — S3 rẻ hơn CloudWatch Logs cho việc giữ dữ liệu nhiều tháng. Ở câu này, việc lọc chỉ giữ REJECT đã thu nhỏ khối lượng nên đường trực tiếp thắng.

Đáp án

D — Gán một chứng chỉ từ ACM có chứa tất cả các tên miền cần thiết, rồi gắn vào CloudFront distribution

Vì sao đúng

Đây là ràng buộc quan trọng nhất cần nhớ: mỗi CloudFront distribution chỉ gắn được đúng một chứng chỉ SSL.

Vì vậy muốn phục vụ nhiều CNAME qua HTTPS trên cùng một distribution, chứng chỉ đó phải bao trùm tất cả các tên miền, bằng một trong hai cách:

• Chứng chỉ SAN — liệt kê nhiều tên miền trong trường Subject Alternative Name.
• Chứng chỉ ký tự đại diện — *.example.com bao mọi tên miền con một cấp.

Hai chi tiết cần nhớ khi làm thật: chứng chỉ ACM dùng cho CloudFront bắt buộc phải tạo ở Region us-east-1, bất kể nội dung phục vụ ở đâu; và chứng chỉ công cộng của ACM miễn phí, tự gia hạn.

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

• C. Gắn nhiều chứng chỉ, mỗi CNAME một cái — không làm được vì giới hạn một chứng chỉ mỗi distribution. Đây là bẫy chính.
• B. Tạo chứng chỉ tuỳ chỉnh trong IAM qua Console — kho chứng chỉ của IAM là cơ chế cũ, và không tải lên được qua Console (chỉ qua CLI hoặc API). ACM mới là dịch vụ đúng.
• A. Tạo signed URL riêng cho từng tên miền — signed URL kiểm soát ai được xem nội dung, hoàn toàn không liên quan tới chứng chỉ SSL.