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

Tìm thấy 1221 câu.

Câu 21 Domain - Design Solutions for Organizational Complexity

An IT consultancy company has multiple offices located in San Francisco, Frankfurt, Tokyo, and Manila. The company is using AWS Organizations to easily manage its several AWS accounts which are being used by its regional offices and subsidiaries. A new AWS account was recently added to a specific organizational unit (OU) which is responsible for the overall systems administration. The solutions architect noticed that the account is using a root-created Amazon ECS Cluster with an attached service-linked role. For regulatory purposes, the solutions architect created a custom SCP that would deny the new account from performing certain actions in relation to using ECS. However, after applying the policy, the new account could still perform the actions that it was supposed to be restricted from doing.

Which of the following is the most likely reason for this problem?

A
SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs.
B
The default SCP grants all permissions attached to every root, OU, and account. To apply stricter permissions, this policy is required to be modified.
C
There is an SCP attached to a higher-level OU that permits the actions of the service-linked role. This permission would therefore be inherited by the current OU, and override the SCP placed by the administrator.
D
The ECS service is being run outside the jurisdiction of the organization. SCPs affect only the principals that are managed by accounts that are part of the organization.

Xem giải thích

Đáp án

A — SCP không áp cho service-linked role. Service-linked role cho phép các dịch vụ AWS tích hợp với Organizations và không bị SCP hạn chế.

Vì sao đúng

Đề mô tả một hiện tượng cụ thể: SCP đã gắn nhưng tài khoản vẫn thực hiện được thao tác ECS. Và chi tiết quyết định nằm ngay trong đề: "root-created ECS Cluster with an attached service-linked role".

⚠ Service-linked role là một trong ba ngoại lệ của SCP: | Ngoại lệ | Chi tiết | |---|---| | Management account | SCP KHÔNG áp cho nó | | Service-linked role | SCP KHÔNG áp cho nó | | Hành động ngoài phạm vi Organizations | |

Vì sao AWS thiết kế như vậy:

Service-linked role là vai trò do CHÍNH DỊCH VỤ dùng
để thực hiện công việc nội bộ
        ↓
    Ví dụ: AWSServiceRoleForECS gọi EC2 API
      để quản lý ENI cho task
        ↓
    Nếu SCP chặn được nó
    → dịch vụ AWS ngừng hoạt động theo cách
      không ai lường trước được

Nhận diện service-linked role:

arn:aws:iam::123456789012:role/aws-service-role/
  ecs.amazonaws.com/AWSServiceRoleForECS
        ↓
    Đường dẫn `/aws-service-role/` là dấu hiệu
    → không sửa được trust policy
    → không gắn được policy tuỳ ý

aws iam list-roles \
  --path-prefix /aws-service-role/ \
  --query "Roles[].RoleName" --output table

⚠ Nhưng SCP VẪN áp cho người dùng gọi API tạo cụm:

Người dùng gọi `ecs:CreateCluster`
    → SCP CHẶN được
        ↓
    Nhưng công việc nội bộ mà ECS tự làm
      qua service-linked role
    → SCP KHÔNG chặn

Cách kiểm soát đúng: | Muốn chặn | Dùng gì | |---|---| | Người dùng tạo/sửa/xoá tài nguyên ECS | SCP áp cho principal người dùng | | Chính dịch vụ ECS hoạt động | không chặn được — và không nên chặn |

⚠ Nếu thật sự cần ngăn ECS hoạt động thì phải xoá tài nguyên:

Xoá cụm ECS
    → service-linked role không còn gì để làm
        ↓
    Chứ không phải cố chặn vai trò đó

Ba lợi ích của việc hiểu ngoại lệ này: | Lợi ích | Chi tiết | |---|---| | Không mất thời gian sửa SCP vốn đã đúng | | | Thiết kế chính sách nhắm đúng principal | | | Tránh cố chặn thứ không chặn được | |

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

**C. Có SCP ở OU cấp cao hơn cho phép hành động, quyền đó kế thừa xuống và ghi đè SCP của quản trị viên — hiểu sai cơ chế SCP: quyền hiệu lực là GIAO của mọi cấp, và một Deny ở bất kỳ đâu là chặn; không có chuyện Allow ở cấp trên ghi đè Deny ở cấp dưới.
**B. SCP mặc định FullAWSAccess cấp mọi quyền nên phải sửa nó — FullAWSAccess chỉ là chính sách cơ sở; Deny trong SCP mới luôn thắng dù FullAWSAccess còn gắn. Đây là mô hình deny list bình thường và hoạt động đúng.
**D. Dịch vụ ECS chạy ngoài phạm vi tổ chức — cụm ECS nằm trong chính tài khoản thành viên đó, hoàn toàn trong phạm vi tổ chức.

Ghi nhớ

⚠ Ba quy tắc SCP phải thuộc: | Quy tắc | Chi tiết | |---|---| | SCP KHÔNG cấp quyền | chỉ giới hạn quyền tối đa | | Quyền hiệu lực = GIAO của mọi cấp | Deny ở đâu cũng là chặn | | Ba ngoại lệ | management account, service-linked role, ngoài phạm vi |

⚠ Đây là điều nhiều người hiểu sai nhất:

"Tôi gắn SCP Allow ở OU con để mở lại quyền"
    → KHÔNG hoạt động
        ↓
    "SCP ở OU cha Allow nên ghi đè Deny ở OU con"
    → CŨNG KHÔNG — Deny luôn thắng

Từ khoá nhận diện:

"SCP applied but action still allowed" → kiểm service-linked role hoặc management account "restrict actions across accounts" → SCP "limit max permissions of a role" → permissions boundary "grant permissions" → IAM policy

Ba loại vai trò IAM hay bị lẫn: | Loại | Đặc điểm | |---|---| | Service role | bạn tạo, dịch vụ đảm nhận, bạn sửa được | | Service-linked role | AWS định nghĩa, KHÔNG sửa được, SCP không áp | | Cross-account role | tài khoản khác đảm nhận |

⚠ Service role thì SCP CÓ áp:

Vai trò bạn tạo cho Lambda hay EC2
    → là principal bình thường trong tài khoản
    → SCP áp đầy đủ
        ↓
    Chỉ service-linked role (đường dẫn
      /aws-service-role/) mới miễn nhiễm

Ba lưu ý về gỡ lỗi SCP: | Lưu ý | Chi tiết | |---|---| | Lỗi chỉ hiện AccessDenied, không nói do SCP | | | CloudTrail ghi hành động bị từ chối | | | Kiểm chính sách hiệu lực bằng API | |

aws organizations describe-effective-policy \
  --policy-type SERVICE_CONTROL_POLICY \
  --target-id 222222222222

Ba lưu ý về management account: | Lưu ý | Chi tiết | |---|---| | SCP KHÔNG áp cho nó, kể cả gắn ở root | | | Đừng chạy tải sản xuất ở đó | | | Giữ nó sạch, chỉ để quản trị tổ chức | |

⚠ Đây là lý do quan trọng nhất để tách management account:

Mọi hàng rào bạn dựng đều không áp cho nó
    → tài nguyên chạy ở đó nằm ngoài kiểm soát
        ↓
    Chiếm được management account = chiếm cả tổ chức

Ba chiến lược viết SCP: | Chiến lược | Cách làm | |---|---| | Deny list | giữ FullAWSAccess, thêm Deny — an toàn | | Allow list | gỡ FullAWSAccess, chỉ Allow thứ cần | | Kết hợp theo OU | mỗi OU một mức |

Ba lưu ý về thiết kế OU: | Lưu ý | Chi tiết | |---|---| | Thiết kế theo MỨC KIỂM SOÁT | | | Đừng gắn SCP hạn chế ở ROOT | | | OU riêng cho onboarding và sandbox | |

Ba cách bổ sung SCP: | Cách | Việc | |---|---| | IAM policy | quyền của từng principal | | Permissions boundary | trần quyền của một vai trò | | Resource policy | ai chạm được tài nguyên |

⚠ Permissions boundary hữu ích khi uỷ quyền tạo vai trò:

Cho phép đội tự tạo IAM role
    → nhưng ép mọi role họ tạo phải có boundary
        ↓
    Họ không tạo được vai trò quyền cao hơn boundary

{"Effect": "Deny", "Action": "iam:CreateRole", "Resource": "*",
 "Condition": {"StringNotEquals":
   {"iam:PermissionsBoundary":
     "arn:aws:iam::123456789012:policy/RanhGioiChuan"}}}

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | Kích thước SCP | 5.120 byte | | SCP gắn mỗi thực thể | 5 | | Độ sâu OU | 5 cấp |

Ba lưu ý về Control Tower: | Lưu ý | Chi tiết | |---|---| | Guardrail bắt buộc không gỡ được | | | Gắn SCP ở OU, không ở root | | | Kiểm tra tuân thủ tự động | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem chính sách hiệu lực của tài khoản | | | Liệt kê service-linked role đang có | | | Thử hành động bằng vai trò NGƯỜI DÙNG | |

Và một lời khuyên: hãy luôn kiểm tra xem principal thực hiện hành động có phải service-linked role không trước khi nghi ngờ SCP viết sai. Đây là ngoại lệ được thiết kế có chủ ý và không có cách nào vượt qua — thời gian bỏ ra để sửa chính sách sẽ hoàn toàn lãng phí.

Câu 22 Chọn nhiều đáp án Domain - Accelerate Workload Migration and Modernization

A company uses Lightweight Directory Access Protocol (LDAP) for its employee authentication and authorization. The company plans to release a mobile app that can be installed on employee’s smartphones. The mobile application will allow users to have federated access to AWS resources. Due to strict security and compliance requirements, the mobile application must use a custom-built solution for user authentication. It must also use IAM roles for granting user permissions to AWS resources. The Solutions Architect was tasked to create a solution that meets these requirements.

Which of the following options should the Solutions Architect implement to enable authentication and authorization for the application? (Select TWO.)

A
Build a custom OpenID Connect-compatible solution in combination with AWS IAM Identity Center to create authentication and authorization functionality for the application.
B
Build a custom LDAP connector using Amazon API Gateway with AWS Lambda function for user authentication. Use Amazon DynamoDB to store user authorization tokens. Write another Lambda function that will validate user authorization requests based on the token stored on DynamoDB.
C
Build a custom SAML-compatible solution to handle authentication and authorization. Configure the solution to use LDAP for user authentication and use SAML assertion to perform authorization to the IAM identity provider.
D
Build a custom OpenID Connect-compatible solution for the user authentication functionality. Use Amazon Cognito Identity Pools for authorizing access to AWS resources.
E
Build a custom SAML-compatible solution for user authentication. Leverage AWS IAM Identity Center for authorizing access to AWS resources.

Xem giải thích

Đáp án

C và D — Xây giải pháp tương thích SAML dùng LDAP để xác thực và dùng SAML assertion để phân quyền qua IAM identity provider; hoặc xây giải pháp tương thích OpenID Connect cho xác thực và dùng Cognito Identity Pools để cấp quyền truy cập tài nguyên AWS.

Vì sao đúng

Đề nêu ba ràng buộc, và cả hai lựa chọn đều thoả: | Ràng buộc | Cách đáp ứng | |---|---| | Giải pháp TỰ XÂY cho xác thực | cả SAML lẫn OIDC đều cho phép tự triển khai | | Dùng IAM role để cấp quyền | cả hai đều đổi ra credential AWS tạm | | Ứng dụng di động federated access | cả hai đều là chuẩn liên kết danh tính |

⚠ Hai chuẩn liên kết danh tính mà AWS hỗ trợ: | Chuẩn | Cách hoạt động với AWS | |---|---| | SAML 2.0 | sts:AssumeRoleWithSAML | | OpenID Connect | sts:AssumeRoleWithWebIdentity |

⚠ LDAP KHÔNG nói chuyện trực tiếp với AWS được:

AWS IAM không hiểu giao thức LDAP
    → phải có một lớp trung gian
        ↓
    Lớp đó phát hành SAML assertion hoặc OIDC token
    → chính là "giải pháp tự xây" mà đề nói

Đường C — SAML:

Ứng dụng di động → giải pháp tự xây
    → xác thực với LDAP
    → phát hành SAML assertion
        ↓
    sts:AssumeRoleWithSAML
    → credential AWS tạm

Đăng ký SAML identity provider:

aws iam create-saml-provider \
  --name NhaCungCapNoiBo \
  --saml-metadata-document file://metadata.xml

Trust policy cho vai trò:

{"Effect": "Allow",
 "Principal": {"Federated":
   "arn:aws:iam::123456789012:saml-provider/NhaCungCapNoiBo"},
 "Action": "sts:AssumeRoleWithSAML",
 "Condition": {"StringEquals":
   {"SAML:aud": "https://signin.aws.amazon.com/saml"}}}

Đường D — OIDC + Cognito Identity Pool:

Ứng dụng di động → giải pháp OIDC tự xây
    → xác thực với LDAP, phát hành ID token
        ↓
    Cognito Identity Pool đổi token lấy credential
    → sts:AssumeRoleWithWebIdentity ở bên dưới

aws cognito-identity create-identity-pool \
  --identity-pool-name kho-danh-tinh \
  --no-allow-unauthenticated-identities \
  --open-id-connect-provider-arns \
    arn:aws:iam::123456789012:oidc-provider/dinh-danh.congty.vn

⚠ Với ứng dụng DI ĐỘNG, OIDC thường phù hợp hơn SAML:

SAML dựa trên trao đổi XML qua trình duyệt
    → thiết kế cho web SSO doanh nghiệp
        ↓
OIDC dựa trên JSON và OAuth 2.0
    → thiết kế cho ứng dụng di động và API
    → thư viện client sẵn có cho iOS/Android

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có credential AWS nào nhúng trong ứng dụng | | | Credential tạm tự hết hạn | | | Quyền quản lý bằng IAM role | |

⚠ Vì sao "không nhúng credential" là bắt buộc:

Ứng dụng di động chạy trên thiết bị của người dùng
    → mọi thứ trong gói cài đặt đều đọc được
        ↓
    Access key nhúng vào = rò rỉ chắc chắn
    → chỉ credential tạm mới an toàn

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

**E. SAML tự xây cho xác thực + IAM Identity Center để phân quyền — đây là phương án gần nhất và IAM Identity Center là dịch vụ thật, nhưng nó được thiết kế cho truy cập của NHÂN VIÊN vào console và CLI, không phải cho ứng dụng di động của người dùng cuối lấy credential lập trình.
**A. OIDC tự xây kết hợp IAM Identity Center — cùng vấn đề: Identity Center không phải cơ chế cấp credential cho ứng dụng di động.
**B. Xây LDAP connector bằng API Gateway + Lambda, lưu token trong DynamoDB, Lambda khác kiểm token — đây là tự dựng lại một hệ thống xác thực từ đầu: không dùng IAM role như đề yêu cầu, và tự quản lý token là mô hình bảo mật rủi ro.

Ghi nhớ

⚠ Ba API của STS cho liên kết danh tính — bảng phải thuộc: | API | Dùng cho | |---|---| | AssumeRoleWithSAML | nhà cung cấp SAML 2.0 | | AssumeRoleWithWebIdentity | OIDC: Google, Facebook, hoặc tự xây | | AssumeRole | principal AWS đã có credential |

Từ khoá nhận diện:

"custom auth solution + IAM roles for AWS access" → SAML hoặc OIDC + STS "employee SSO to console" → IAM Identity Center "social login for mobile app" → Cognito Identity Pool "user directory with sign-up/sign-in" → Cognito User Pool

⚠ Cognito User Pool vs Identity Pool — nhắc lại: | | User Pool | Identity Pool | |---|---|---| | Việc | xác thực | phân quyền | | Trả về | JWT | credential AWS | | Thư mục người dùng | ✅ | ❌ |

Đề nói phải dùng giải pháp TỰ XÂY để xác thực
    → không dùng User Pool
        ↓
    Identity Pool vẫn dùng được để đổi token
      lấy credential

Ba lưu ý về SAML assertion: | Thuộc tính | Việc | |---|---| | Role | ARN của vai trò và của provider | | RoleSessionName | tên phiên, hiện trong CloudTrail | | SessionDuration | thời hạn credential |

⚠ RoleSessionName quan trọng cho kiểm toán:

Nhiều người dùng cùng đảm nhận một vai trò
    → CloudTrail chỉ thấy tên vai trò
        ↓
    RoleSessionName mang danh tính người dùng
    → biết ai đã làm gì

Ba lưu ý về ánh xạ nhóm LDAP sang vai trò: | Lưu ý | Chi tiết | |---|---| | Nhóm LDAP → nhiều ARN vai trò trong assertion | | | Người dùng chọn vai trò khi có nhiều | | | Quản lý quyền ở LDAP, không ở AWS | |

Ba lưu ý về thời hạn phiên: | Lưu ý | Chi tiết | |---|---| | Mặc định 1 giờ | | | Tối đa 12 giờ (tuỳ vai trò) | | | Client phải tự làm mới | |

aws iam update-role --role-name VaiTroUngDung \
  --max-session-duration 3600

Ba lưu ý về bảo mật trust policy: | Lưu ý | Chi tiết | |---|---| | Giới hạn aud và sub | | | Không để trust policy quá rộng | | | Kiểm tra bằng Access Analyzer | |

⚠ Trust policy lỏng là lỗ hổng nghiêm trọng:

{"Condition": {"StringEquals": {
  "cognito-identity.amazonaws.com:aud": "<id-identity-pool>"},
 "ForAnyValue:StringLike": {
  "cognito-identity.amazonaws.com:amr": "authenticated"}}}

Thiếu điều kiện `aud`
    → identity pool KHÁC cũng đảm nhận được vai trò

Ba lưu ý về phân quyền chi tiết: | Cách | Chi tiết | |---|---| | Biến chính sách ${aws:userid} | | | dynamodb:LeadingKeys cho DynamoDB | | | Tiền tố S3 theo danh tính | |

{"Effect": "Allow", "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho/${cognito-identity.amazonaws.com:sub}/*"}

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lần AssumeRole* | | | Cảnh báo cho phiên bất thường | | | Theo dõi IP nguồn của phiên | |

Ba lưu ý về vòng đời: | Lưu ý | Chi tiết | |---|---| | Người rời tổ chức → tắt ở LDAP | | | Credential đang hoạt động vẫn còn tới khi hết hạn | | | Đặt thời hạn ngắn để thu hồi nhanh hơn | |

⚠ Thu hồi không tức thì là đặc tính của credential tạm:

Tắt tài khoản ở LDAP
    → không phát hành token mới được nữa
        ↓
    Nhưng credential đã cấp vẫn dùng tới lúc hết hạn
    → cần chặn ngay thì thêm điều kiện Deny theo
      thời điểm vào chính sách của vai trò

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập thử, xem credential nhận được | | | Kiểm tra quyền đúng phạm vi | | | Xem CloudTrail ghi đúng RoleSessionName | |

Và một lời khuyên: hãy chọn OIDC thay vì SAML khi làm ứng dụng di động. SAML được thiết kế cho luồng SSO qua trình duyệt và việc nhồi nó vào ứng dụng native luôn cồng kềnh — còn OIDC có thư viện sẵn cho cả iOS lẫn Android và làm việc tự nhiên với Cognito Identity Pool.

Câu 23 Domain - Continuous Improvement for Existing Solutions

A stocks brokerage firm hosts its legacy application on Amazon EC2 in a private subnet of its Amazon VPC. The application is accessed by the employees from their corporate laptops through a proprietary desktop program. The company network is peered with the AWS Direct Connect (DX) connection to provide a fast and reliable connection to the private EC2 instances inside the VPC. To comply with the strict security requirements of financial institutions, the firm is required to encrypt its network traffic that flows from the employees' laptops to the resources inside the VPC.

Which of the following solution will comply with this requirement while maintaining the consistent network performance of Direct Connect?

A
Using the current Direct Connect connection, create a new private virtual interface and input the network prefixes that you want to advertise. Create a new site-to-site VPN connection to the VPC over the Internet. Configure the employees’ laptops to connect to this VPN.
B
Using the current Direct Connect connection, create a new public virtual interface and input the network prefixes that you want to advertise. Create a new site-to-site VPN connection to the VPC over the Internet. Configure the employees’ laptops to connect to this VPN.
C
Using the current Direct Connect connection, create a new public virtual interface and input the network prefixes that you want to advertise. Create a new site-to-site VPN connection to the VPC with the BGP protocol using the DX connection. Configure the company network to route employee traffic to this VPN.
D
Using the current Direct Connect connection, create a new private virtual interface and input the network prefixes that you want to advertise. Create a new site-to-site VPN connection to the VPC with the BGP protocol using the DX connection. Configure the company network to route employee traffic to this VPN.

Xem giải thích

Đáp án

C — Trên kết nối Direct Connect hiện có, tạo một public virtual interface và khai các dải mạng cần quảng bá; tạo Site-to-Site VPN tới VPC dùng BGP, chạy TRÊN chính đường DX; định tuyến lưu lượng nhân viên qua VPN đó.

Vì sao đúng

Đề nêu hai yêu cầu mâu thuẫn nhau ở vẻ ngoài, và phương án này giải quyết cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | MÃ HOÁ lưu lượng từ laptop tới VPC | IPsec VPN mã hoá | | Giữ hiệu năng ỔN ĐỊNH của Direct Connect | VPN chạy TRÊN đường DX, không qua Internet |

⚠ Direct Connect KHÔNG mã hoá theo mặc định — đây là điều nhiều người hiểu nhầm:

"Đường riêng" ≠ "được mã hoá"
    → DX là kênh riêng nhưng dữ liệu đi dạng THÔ
        ↓
    Quy định của ngành tài chính thường
      đòi mã hoã đường truyền
    → phải chồng thêm một lớp

⚠ Và vì sao phải là PUBLIC virtual interface:

Site-to-Site VPN kết nối tới endpoint CÔNG KHAI
của AWS (Virtual Private Gateway)
        ↓
    Private VIF chỉ tới được IP riêng tư trong VPC
    → KHÔNG tới được endpoint VPN công khai
        ↓
    Public VIF cho phép tới endpoint công khai
      của AWS QUA đường DX

Đây chính là lý do phương án D sai.

Dựng public VIF:

aws directconnect create-public-virtual-interface \
  --connection-id dxcon-abc \
  --new-public-virtual-interface '{
    "virtualInterfaceName":"vif-cong-khai",
    "vlan":101,"asn":65000,
    "amazonAddress":"175.45.176.2/30",
    "customerAddress":"175.45.176.1/30",
    "routeFilterPrefixes":[{"cidr":"203.0.113.0/24"}]}'

Rồi dựng VPN qua đó:

aws ec2 create-vpn-connection --type ipsec.1 \
  --customer-gateway-id cgw-abc \
  --vpn-gateway-id vgw-abc \
  --options '{"StaticRoutesOnly": false}'

⚠ Kiến trúc kết quả:

Laptop nhân viên
    → mạng công ty
        ↓
    Đường Direct Connect (public VIF)
        ↓
    Đường hầm IPsec tới Virtual Private Gateway
        ↓
    VPC — EC2 trong subnet riêng tư

⚠ Vì sao đây gọi là "Direct Connect + VPN":

Lưu lượng đi HOÀN TOÀN trên đường DX
    → không chạm Internet công cộng
    → độ trễ và băng thông ổn định như DX
        ↓
    Nhưng được bọc trong IPsec
    → thoả yêu cầu mã hoá

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mã hoá đầu cuối | | | Hiệu năng ổn định của DX | | | Dùng lại hạ tầng đã có | |

⚠ Đánh đổi: VPN giới hạn băng thông mỗi đường hầm:

Site-to-Site VPN: ~1,25 Gbps mỗi đường hầm
    → đường DX 10 Gbps không tận dụng hết
        ↓
    Cần thông lượng cao hơn:
    → nhiều đường hầm với ECMP qua Transit Gateway
    → hoặc dùng MACsec (chỉ trên DX 10/100 Gbps)

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

**D. Private VIF + VPN qua DX với BGP — đây là phương án gần nhất và chỉ sai một chi tiết, nhưng chi tiết đó khiến nó không chạy: private VIF chỉ tới được IP riêng tư trong VPC, còn endpoint của Site-to-Site VPN là địa chỉ công khai của AWS; phải dùng public VIF.
**A. Private VIF + VPN qua Internet — VPN qua Internet mã hoá được nhưng mất hoàn toàn tính ổn định của Direct Connect; đề nói rõ phải giữ hiệu năng nhất quán.
**B. Public VIF + VPN qua Internet — vế VIF đúng nhưng VPN vẫn đi qua Internet; đường DX không được dùng tới, nên yêu cầu về hiệu năng không được đáp ứng.

Ghi nhớ

⚠ Ba loại virtual interface của Direct Connect — bảng phải thuộc: | Loại | Tới đâu | |---|---| | Private VIF | VPC qua VGW hoặc DX gateway (IP riêng tư) | | Public VIF | endpoint CÔNG KHAI của AWS (S3, DynamoDB, VPN) | | Transit VIF | Transit Gateway |

⚠ Cách nhớ ngắn nhất:

Đích là IP riêng tư trong VPC     → Private VIF
Đích là dịch vụ công khai của AWS → Public VIF
Đích là Transit Gateway           → Transit VIF

Từ khoá nhận diện:

"encrypt traffic over Direct Connect, keep performance" → public VIF + VPN over DX "reach S3 privately over DX" → public VIF (hoặc interface endpoint) "connect VPC over DX" → private VIF "many VPCs over DX" → transit VIF + Transit Gateway

⚠ MACsec là lựa chọn mã hoá khác: | Tiêu chí | VPN over DX | MACsec | |---|---|---| | Tầng mã hoá | tầng 3 (IPsec) | tầng 2 | | Băng thông | ~1,25 Gbps mỗi hầm | đầy đủ tốc độ cổng | | Yêu cầu | không | cổng DX 10/100 Gbps chuyên dụng | | Phạm vi | tới VPC | chỉ trên đoạn DX |

MACsec mã hoá đoạn từ router bạn tới router AWS
    → nhanh hơn nhiều, không giảm băng thông
        ↓
    Nhưng chỉ bảo vệ đoạn đó, không phải end-to-end

Ba lưu ý về tính sẵn sàng của DX: | Lưu ý | Chi tiết | |---|---| | Một kết nối DX KHÔNG phải HA | | | Hai kết nối ở hai địa điểm khác nhau | | | Hoặc DX + VPN qua Internet làm dự phòng | |

⚠ BGP tự ưu tiên DX khi cả hai cùng lên:

DX và VPN dự phòng cùng quảng bá cùng prefix
    → BGP chọn DX (AS path ngắn hơn)
        ↓
    DX đứt → tự chuyển sang VPN
    → đây là kiến trúc dự phòng chuẩn

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | BGP động được khuyến nghị hơn tuyến tĩnh | | | Dùng AS_PATH prepending để ưu tiên đường | | | Local preference điều khiển chiều ra | |

Ba lưu ý về băng thông VPN: | Lưu ý | Chi tiết | |---|---| | ~1,25 Gbps mỗi đường hầm | | | Giới hạn là mỗi LUỒNG, không phải tổng | | | ECMP với Transit Gateway gộp nhiều hầm | |

⚠ Một luồng TCP không vượt được 1,25 Gbps:

Truyền một tệp lớn = một luồng
    → tối đa ~1,25 Gbps dù có bao nhiêu hầm
        ↓
    Nhiều luồng song song mới tận dụng được ECMP

Ba lưu ý về MTU: | Lưu ý | Chi tiết | |---|---| | IPsec thêm overhead, giảm MSS hiệu dụng | | | Bật MSS clamping trên thiết bị | | | Không làm thì tải tệp lớn treo | |

⚠ Đây là lỗi rất khó chẩn đoán:

Ping được, SSH được, nhưng tải tệp lớn treo
    → gói lớn bị rơi do MTU
        ↓
    Triệu chứng "một phần hoạt động" luôn đáng nghi MTU

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cổng DX theo giờ | | | Phí truyền dữ liệu ra qua DX rẻ hơn Internet | | | Phí kết nối VPN ~0,05 USD/giờ | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | TunnelState của VPN | cả hai hầm phải lên | | ConnectionState của DX | | | ConnectionBpsEgress/Ingress | |

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-abc \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status]" \
  --output table

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Ghi tài liệu kiến trúc mã hoá | | | Chứng minh dữ liệu không đi Internet | | | Lưu bằng chứng cấu hình cho kiểm toán | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | traceroute xác nhận đi qua DX | | | Kiểm tra cả hai đường hầm VPN lên | | | Bắt gói xác nhận lưu lượng đã mã hoá | |

Và một lời khuyên: hãy nói rõ với bên tuân thủ rằng Direct Connect không mã hoá. Nhiều tổ chức giả định "đường riêng thì an toàn" và bỏ qua bước này suốt nhiều năm — cho tới lần kiểm toán đầu tiên phát hiện dữ liệu tài chính đang đi trên dây ở dạng không mã hoá.

Câu 24 Domain - Design for New Solutions

A company is developing an online voting application for a photo competition. The infrastructure is deployed in AWS using CloudFormation. The application accepts high-quality images of each contestant and stores them in S3 then records the information about the image as well as the contestant's profile in RDS. After the competition, the CloudFormation stack is not used anymore, and to save costs, the stack can be terminated. The manager instructed the solutions architect to back up the RDS database and the S3 bucket so the data can still be used even after the CloudFormation template is deleted.

Which of the following options is the MOST suitable solution to fulfill this requirement?

A
Set the DeletionPolicy to retain on both the RDS and S3 resource types on the CloudFormation template.
B
Set the DeletionPolicy on the RDS resource to snapshot and set the S3 bucket to retain.
C Set the DeletionPolicy for the RDS instance to snapshot and then enable S3 bucket replication on the source bucket to a destination bucket to maintain a copy of all the S3 objects.
D Set the DeletionPolicy on the S3 bucket to snapshot.

Xem giải thích

Đáp án

B — Đặt DeletionPolicy cho tài nguyên RDS là Snapshot, và cho bucket S3 là Retain.

Vì sao đúng

Đề cần giữ lại dữ liệu sau khi xoá CloudFormation stack, và mỗi loại tài nguyên có chính sách phù hợp riêng: | Tài nguyên | DeletionPolicy | Vì sao | |---|---|---| | RDS | Snapshot | chụp ảnh rồi xoá instance — không trả tiền máy | | S3 bucket | Retain | S3 KHÔNG hỗ trợ Snapshot |

⚠ Đây là chi tiết kỹ thuật quyết định — không phải mọi tài nguyên đều hỗ trợ Snapshot: | Hỗ trợ Snapshot | Không hỗ trợ | |---|---| | AWS::RDS::DBInstance | AWS::S3::Bucket | | AWS::RDS::DBCluster | AWS::DynamoDB::Table (dùng Retain) | | AWS::EC2::Volume | hầu hết tài nguyên khác | | AWS::ElastiCache::CacheCluster | | | AWS::Redshift::Cluster | | | AWS::Neptune::DBCluster | |

Đây là lý do phương án D sai hoàn toàn.

Mẫu CloudFormation:

Resources:
  CsdlThiSanh:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Snapshot
    UpdateReplacePolicy: Snapshot
    Properties:
      Engine: postgres
      DBInstanceClass: db.t4g.medium
      AllocatedStorage: 100
      StorageEncrypted: true

  KhoAnhThiSanh:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      BucketName: anh-cuoc-thi-2026
      VersioningConfiguration:
        Status: Enabled

⚠ Đừng quên UpdateReplacePolicy:

DeletionPolicy: áp khi XOÁ STACK
UpdateReplacePolicy: áp khi cập nhật buộc THAY THẾ tài nguyên
        ↓
    Đổi một thuộc tính bất biến của RDS
    → CloudFormation tạo mới và xoá cũ
    → không có UpdateReplacePolicy = mất dữ liệu

Vì sao Snapshot hợp cho RDS còn Retain thì không:

Retain cho RDS: instance TIẾP TỤC CHẠY sau khi xoá stack
    → vẫn tính tiền máy, tiền lưu trữ, tiền Multi-AZ
        ↓
Snapshot: chụp ảnh rồi xoá instance
    → chỉ trả tiền lưu trữ snapshot — rẻ hơn nhiều
    → khôi phục lại được bất cứ lúc nào

⚠ Đề nói rõ mục tiêu là TIẾT KIỆM:

"After the competition, the stack can be terminated
 to save costs"
        ↓
    Giữ RDS chạy (Retain) là ngược mục tiêu
    → Snapshot đúng ý đồ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dữ liệu CSDL còn nguyên trong snapshot | | | Ảnh trong S3 còn nguyên | | | Không còn tài nguyên nào tính tiền theo giờ | |

⚠ Bucket S3 được giữ lại sẽ nằm NGOÀI quản lý của CloudFormation:

DeletionPolicy: Retain
    → CloudFormation "quên" bucket đó
        ↓
    Muốn xoá sau này phải làm thủ công
    → và tên bucket bị chiếm, không tạo lại được
      với cùng tên trong stack mới

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

**A. Đặt Retain cho CẢ RDS lẫn S3 — đây là phương án gần nhất và giữ được dữ liệu, nhưng RDS instance tiếp tục chạy và tiếp tục tính tiền; đề nói rõ mục tiêu là tiết kiệm chi phí sau cuộc thi.
**C. Snapshot cho RDS và bật S3 replication sang bucket đích — replication chỉ chép object sang bucket khác, nhưng bucket nguồn vẫn bị CloudFormation xoá (mặc định là Delete); và bucket có object thì lệnh xoá thất bại, làm hỏng cả quá trình xoá stack.
**D. Đặt Snapshot cho bucket S3 — S3 không hỗ trợ Snapshot; CloudFormation sẽ báo lỗi khi kiểm tra mẫu.

Ghi nhớ

⚠ Ba giá trị của DeletionPolicy — bảng phải thuộc: | Giá trị | Hành vi | |---|---| | Delete | mặc định — xoá tài nguyên | | Retain | giữ tài nguyên, bỏ khỏi quản lý của stack | | Snapshot | chụp ảnh rồi xoá — chỉ vài loại tài nguyên |

⚠ Có một ngoại lệ đáng nhớ về mặc định:

Hầu hết tài nguyên: mặc định Delete
        ↓
    Nhưng AWS::RDS::DBCluster và một số loại
      mặc định là Snapshot
    → luôn khai tường minh cho chắc

Từ khoá nhận diện:

"keep data after stack deletion, save costs" → Snapshot cho CSDL, Retain cho S3 "keep resource running" → Retain "prevent accidental deletion" → termination protection + stack policy

⚠ Ba lớp bảo vệ khác nhau: | Lớp | Chống gì | |---|---| | DeletionPolicy | mất dữ liệu khi xoá stack | | Termination protection | xoá stack ngoài ý muốn | | Stack policy | cập nhật làm thay thế tài nguyên |

aws cloudformation update-termination-protection \
  --stack-name stack-cuoc-thi --enable-termination-protection

Stack policy bảo vệ tài nguyên khỏi cập nhật:

{"Statement": [
  {"Effect": "Allow", "Action": "Update:*",
   "Principal": "*", "Resource": "*"},
  {"Effect": "Deny", "Action": "Update:Replace",
   "Principal": "*", "Resource": "LogicalResourceId/CsdlThiSanh"}]}

Ba lưu ý về xoá bucket S3: | Lưu ý | Chi tiết | |---|---| | CloudFormation KHÔNG xoá bucket còn object | | | Stack sẽ FAILED ở bước đó | | | Phải làm rỗng bucket trước | |

⚠ Đây là nguyên nhân xoá stack thất bại phổ biến nhất:

Bucket có object
    → DeleteBucket thất bại
    → stack kẹt ở DELETE_FAILED
        ↓
    Dùng Retain, hoặc custom resource làm rỗng bucket

Ba lưu ý về snapshot RDS: | Lưu ý | Chi tiết | |---|---| | Snapshot cuối có tên do CloudFormation đặt | | | Snapshot thủ công tồn tại tới khi bạn xoá | | | Tính phí lưu trữ theo dung lượng thật | |

Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | restore-db-instance-from-db-snapshot | | | Endpoint mới, khác endpoint cũ | | | Phải khai lại parameter group và security group | |

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier csdl-khoi-phuc \
  --db-snapshot-identifier <ten-snapshot> \
  --db-instance-class db.t4g.medium

Ba lưu ý về tài nguyên bị Retain: | Lưu ý | Chi tiết | |---|---| | Nằm ngoài quản lý của stack | | | Tên bucket bị chiếm vĩnh viễn | | | Import lại vào stack mới được | |

⚠ CloudFormation import cho phép đưa tài nguyên trở lại:

aws cloudformation create-change-set \
  --stack-name stack-moi --change-set-type IMPORT \
  --resources-to-import file://tai-nguyen.json \
  --template-body file://mau.yaml

Ba lưu ý về đặt tên tài nguyên: | Lưu ý | Chi tiết | |---|---| | Đặt tên cứng cho bucket = khó tạo lại stack | | | Để CloudFormation tự sinh tên thì linh hoạt hơn | | | Nhưng tên tự sinh khó nhận biết | |

Ba lưu ý về nested stack: | Lưu ý | Chi tiết | |---|---| | DeletionPolicy áp cho từng tài nguyên | | | Xoá stack cha xoá cả stack con | | | Retain ở stack con vẫn có hiệu lực | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoá stack ở môi trường thử | | | Kiểm tra snapshot RDS tồn tại | | | Kiểm tra bucket còn nguyên object | |

aws rds describe-db-snapshots --snapshot-type manual \
  --query "DBSnapshots[].[DBSnapshotIdentifier,Status,SnapshotCreateTime]" \
  --output table

Và một lời khuyên: hãy luôn khai cả UpdateReplacePolicy cùng với DeletionPolicy. Bảo vệ dữ liệu khi xoá stack là bước hiển nhiên, nhưng phần lớn các vụ mất dữ liệu thật lại xảy ra khi một lần cập nhật vô hại buộc CloudFormation thay thế tài nguyên — và lúc đó DeletionPolicy không có tác dụng gì.

Câu 25 Domain - Continuous Improvement for Existing Solutions

A company runs several clusters of Amazon EC2 instances in AWS. An unusual API activity and port scanning in the VPC have been identified by the security team. They noticed that there are multiple port scans being triggered to the EC2 instances from a specific IP address. To fix the issue immediately, the solutions architect has decided to simply block the offending IP address. The solutions architect is also instructed to fortify their existing cloud infrastructure security from the most frequently occurring network and transport layer DDoS attacks.

Which of the following is the most suitable method to satisfy the above requirement in AWS?

A
Change the Windows Firewall settings to deny access from the IP address block. Use Amazon GuardDuty to detect potentially compromised instances or reconnaissance by attackers, and AWS Systems Manager Patch Manager to properly apply the latest security patches to all of your instances.
B
Deny access from the IP Address block in the Network ACL. Use AWS Shield Advanced to protect your cloud resources.
C
Block the offending IP address using Route 53. Use Amazon Macie to automatically discover, classify, and protect sensitive data in AWS, including DDoS attacks.
D
Deny access from the IP Address block by adding a specific rule to all of the Security Groups. Use a combination of AWS WAF and AWS Config to protect your cloud resources against common web attacks.

Xem giải thích

Đáp án

B — Từ chối dải IP đó trong Network ACL, và dùng AWS Shield Advanced bảo vệ tài nguyên đám mây.

Vì sao đúng

Đề nêu hai yêu cầu tách bạch, và mỗi cái có một công cụ đúng: | Yêu cầu | Công cụ | |---|---| | Chặn NGAY một địa chỉ IP cụ thể | NACL — cơ chế duy nhất có quy tắc DENY | | Chống tấn công DDoS tầng MẠNG và TRUYỀN TẢI | Shield Advanced |

⚠ Security group KHÔNG CÓ quy tắc deny — đây là điều phải thuộc:

Security group chỉ có quy tắc ALLOW
    → mặc định là từ chối tất cả
        ↓
    Muốn chặn MỘT IP cụ thể trong khi
      vẫn cho phép phần còn lại
    → security group không diễn đạt được
        ↓
    NACL có deny rule → làm được

Đây chính là lý do phương án D sai.

Chặn bằng NACL:

aws ec2 create-network-acl-entry \
  --network-acl-id acl-abc \
  --rule-number 50 \
  --protocol -1 \
  --rule-action deny \
  --cidr-block 203.0.113.0/24 \
  --ingress

⚠ Số thứ tự quy tắc quyết định thứ tự xét:

NACL xét quy tắc theo SỐ TĂNG DẦN
    → dừng ở quy tắc khớp ĐẦU TIÊN
        ↓
    Quy tắc deny phải có số NHỎ HƠN
      quy tắc allow tương ứng
    → đặt số 50 nếu allow ở số 100

⚠ NACL là STATELESS — phải nhớ chiều ra:

Security group: stateful, phản hồi tự được phép
        ↓
NACL: stateless
    → chặn chiều vào KHÔNG tự chặn chiều ra
    → và mở chiều vào phải mở cả dải cổng
      tạm (1024-65535) ở chiều ra

Shield Advanced cho DDoS tầng 3 và 4:

aws shield subscribe-to-proactive-engagement \
  --proactive-engagement-status ENABLED

aws shield create-protection \
  --name bao-ve-alb --resource-arn <arn-alb>

⚠ Đề nói rõ "tầng mạng và tầng truyền tải" — đó là tầng 3/4: | Tầng | Tấn công điển hình | Công cụ | |---|---|---| | 3/4 (mạng, truyền tải) | SYN flood, UDP reflection | Shield | | 7 (ứng dụng) | SQL injection, XSS, HTTP flood | WAF |

Đề hỏi tầng 3/4 → Shield
    → WAF là câu trả lời cho tầng 7
    → đây là lý do phương án D sai ở vế thứ hai

Ba lợi ích của Shield Advanced: | Lợi ích | Chi tiết | |---|---| | Phát hiện và giảm thiểu DDoS quy mô lớn | | | Đội phản ứng DDoS (DRT) hỗ trợ 24/7 | | | Hoàn phí chi phí mở rộng do bị tấn công | |

⚠ Vế thứ ba đáng giá hơn người ta nghĩ:

Bị DDoS → ASG mở rộng lên hàng trăm máy
    → hoá đơn tăng vọt
        ↓
    Shield Advanced hoàn lại khoản đó
    → với tấn công lớn, khoản này vượt cả phí thuê bao

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

**D. Thêm quy tắc deny vào tất cả security group và dùng WAF + Config — sai hai lần: security group không có quy tắc deny, và WAF bảo vệ tầng 7 chứ không phải tầng 3/4 như đề yêu cầu.
**A. Đổi cấu hình Windows Firewall trên từng máy + GuardDuty + Patch Manager — đây là phương án gần nhất về mặt cũng chặn được IP, nhưng sửa tường lửa trên từng máy là công việc lặp lại và dễ sót; và GuardDuty phát hiện chứ không chống DDoS.
**C. Chặn IP bằng Route 53 và dùng Macie chống DDoS — Route 53 là DNS, không có cơ chế chặn IP; và Macie quét dữ liệu nhạy cảm trong S3, hoàn toàn không liên quan tới DDoS.

Ghi nhớ

⚠ Security group vs NACL — bảng phải thuộc: | Tiêu chí | Security group | NACL | |---|---|---| | Cấp độ | ENI (máy) | subnet | | Trạng thái | stateful | stateless | | Quy tắc DENY | ❌ KHÔNG có | ✅ CÓ | | Xét quy tắc | tất cả cùng lúc | theo số, dừng ở khớp đầu | | Tham chiếu SG khác | ✅ | ❌ chỉ CIDR |

⚠ Đây là câu hỏi kinh điển và chỉ có một cách trả lời:

"Chặn một IP cụ thể"
    → LUÔN LUÔN là NACL (hoặc WAF, hoặc Network Firewall)
    → KHÔNG BAO GIỜ là security group

Từ khoá nhận diện:

"block a specific IP address" → NACL deny rule "network/transport layer DDoS" → Shield "application layer attacks, SQLi, XSS" → WAF "detect compromised instances" → GuardDuty "filter traffic between VPCs" → Network Firewall

⚠ Shield Standard vs Advanced: | Tiêu chí | Standard | Advanced | |---|---|---| | Giá | MIỄN PHÍ, tự bật | ~3.000 USD/tháng | | Bảo vệ | tầng 3/4 cơ bản | tầng 3/4/7 nâng cao | | Đội DRT | ❌ | ✅ | | Hoàn phí mở rộng | ❌ | ✅ | | Báo cáo chi tiết | ❌ | ✅ |

⚠ Shield Standard đã BẬT SẴN cho mọi khách hàng — không phải kích hoạt gì.

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Tối đa 20 quy tắc mỗi chiều (tăng tới 40) | | | Áp cho CẢ SUBNET | | | Stateless — nhớ mở dải cổng tạm | |

⚠ Giới hạn 20 quy tắc là ràng buộc thật:

Muốn chặn hàng trăm IP
    → NACL không đủ chỗ
        ↓
    Dùng AWS WAF IP set (tới 10.000 CIDR)
    → hoặc Network Firewall

Ba lựa chọn chặn IP quy mô lớn: | Công cụ | Số IP | |---|---| | NACL | 20-40 quy tắc | | WAF IP set | tới 10.000 CIDR | | Network Firewall | rất lớn, có Suricata rules |

aws wafv2 create-ip-set --name danh-sach-chan \
  --scope REGIONAL --ip-address-version IPV4 \
  --addresses 203.0.113.0/24 198.51.100.5/32

Ba lưu ý về GuardDuty (bổ trợ): | Lưu ý | Chi tiết | |---|---| | Phát hiện port scan tự động | | | Recon:EC2/PortProbeUnprotectedPort | | | Kết hợp EventBridge để tự chặn | |

⚠ Mẫu tự động hoá phản ứng:

GuardDuty phát hiện port scan
    → EventBridge bắt sự kiện
    → Lambda thêm IP vào NACL hoặc WAF IP set
        ↓
    Chặn trong vài giây thay vì vài giờ

Ba lưu ý về Shield Advanced: | Lưu ý | Chi tiết | |---|---| | Cam kết 1 năm | | | Áp cho cả tổ chức qua Firewall Manager | | | Bảo vệ CloudFront, ALB, NLB, EIP, Route 53 | |

Ba lưu ý về kiến trúc chống DDoS: | Lưu ý | Chi tiết | |---|---| | Đặt CloudFront trước ứng dụng | edge hấp thụ | | Giấu IP gốc, chỉ cho CloudFront gọi | | | Auto Scaling để hấp thụ tải | |

⚠ Kiến trúc quan trọng hơn dịch vụ bảo vệ:

Ứng dụng phơi IP thật ra Internet
    → Shield bảo vệ được nhưng khó hơn nhiều
        ↓
    Đặt sau CloudFront/Global Accelerator
    → tấn công bị hấp thụ ở edge toàn cầu

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | DDoSDetected của Shield | | | VPC Flow Logs thấy gói REJECT | | | CloudWatch alarm cho lưu lượng bất thường | |

Ba lưu ý về ứng phó: | Việc | Chi tiết | |---|---| | Có runbook cho tình huống DDoS | | | Biết cách liên hệ DRT (nếu có Advanced) | | | Diễn tập trước khi cần | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra NACL entry đã áp | | | Xem Flow Logs có gói REJECT từ IP đó | | | Xác nhận Shield đang bảo vệ đúng tài nguyên | |

aws ec2 describe-network-acls --network-acl-ids acl-abc \
  --query "NetworkAcls[0].Entries[?RuleAction=='deny']"

Và một lời khuyên: hãy nhớ rằng security group không bao giờ chặn được một địa chỉ cụ thể. Đây là câu hỏi xuất hiện liên tục trong đề thi lẫn thực tế, và câu trả lời luôn là NACL, WAF hoặc Network Firewall — ba cơ chế duy nhất trên AWS có khái niệm "từ chối tường minh".

Câu 26 Domain - Design Solutions for Organizational Complexity

A multinational financial company has a suite of web applications hosted in multiple VPCs in various AWS regions. As part of their security compliance, the company’s Solutions Architect has been tasked to set up a logging solution to track all of the changes made to their AWS resources in all regions, which host their enterprise accounting systems. The company is using different AWS services such as Amazon EC2 instances, Amazon S3 buckets, CloudFront web distributions, and AWS IAM. The logging solution must ensure the security, integrity, and durability of your log data in order to pass the compliance requirements. In addition, it should provide an event history of your AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command-line tools, and API calls.

In this scenario, which of the following options is the best solution to use?

A
Create a new Amazon CloudWatch trail in a new S3 bucket using the AWS CLI and also pass both the --is-multi-region-trail and --include-global-service-events parameters then encrypt log files using KMS encryption. Enable Multi-Factor Authentication (MFA) Delete on the S3 bucket and ensure that only authorized users can access the logs by configuring the bucket policies.
B
Create a new Amazon CloudWatch trail in a new S3 bucket using the AWS CLI and also pass the --include-global-service-events parameter then encrypt log files using KMS encryption. Enable Multi-Factor Authentication (MFA) Delete on the S3 bucket and ensure that only authorized users can access the logs by configuring the bucket policies.
C
Create a new AWS CloudTrail trail in a new S3 bucket using the AWS CLI and also pass both the --is-multi-region-trail and --include-global-service-events parameters then encrypt log files using KMS encryption. Enable Multi-Factor Authentication (MFA) Delete on the S3 bucket and ensure that only authorized users can access the logs by configuring the bucket policies.
D
Create a new AWS CloudTrail trail in a new S3 bucket using the AWS CLI and also pass the --no-include-global-service-events and --is-multi-region-trail parameter then encrypt log files using KMS encryption. Enable Multi-Factor Authentication (MFA) Delete on the S3 bucket and ensure that only authorized users can access the logs by configuring the bucket policies.

Xem giải thích

Đáp án

C — Tạo một AWS CloudTrail trail mới trong bucket S3 mới bằng CLI, truyền cả --is-multi-region-trail lẫn --include-global-service-events, mã hoá log bằng KMS, bật MFA Delete trên bucket và giới hạn truy cập bằng bucket policy.

Vì sao đúng

Đề nêu bốn yêu cầu, và chỉ phương án này thoả cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Theo dõi thay đổi ở MỌI Region | --is-multi-region-trail | | Gồm cả IAM và CloudFront | --include-global-service-events | | Lịch sử API từ console, SDK, CLI | CloudTrail ghi tất cả | | Bảo mật, toàn vẹn, bền vững của log | KMS + MFA Delete + bucket policy |

⚠ Hai cờ này giải quyết hai vấn đề KHÁC NHAU: | Cờ | Việc | |---|---| | --is-multi-region-trail | ghi sự kiện ở MỌI Region | | --include-global-service-events | ghi sự kiện của dịch vụ TOÀN CẦU |

Dịch vụ toàn cầu: IAM, Organizations, CloudFront,
                  Route 53, STS
        ↓
    Sự kiện của chúng phát ra ở us-east-1
    → cần cờ riêng để đưa vào trail

Đề nhắc rõ CloudFront và IAM — chính là hai dịch vụ toàn cầu, nên thiếu cờ thứ hai là bỏ sót đúng thứ nhạy cảm nhất.

Lệnh đầy đủ:

aws cloudtrail create-trail --name duong-mon-tuan-thu \
  --s3-bucket-name log-cloudtrail-tap-trung \
  --is-multi-region-trail \
  --include-global-service-events \
  --enable-log-file-validation \
  --kms-key-id <arn-khoa>

aws cloudtrail start-logging --name duong-mon-tuan-thu

⚠ --enable-log-file-validation là thứ đáp ứng yêu cầu "toàn vẹn":

CloudTrail tạo tệp digest ký số mỗi giờ
    → chứa hash của các tệp log
        ↓
    Ai sửa hoặc xoá log → validate phát hiện ra

aws cloudtrail validate-logs --trail-arn <arn> \
  --start-time 2026-08-01T00:00:00Z

Ba lớp bảo vệ log: | Lớp | Chống gì | |---|---| | Mã hoá KMS | đọc trộm log | | MFA Delete | xoá phiên bản object | | Bucket policy | truy cập trái phép |

⚠ MFA Delete chỉ bật được bằng credential ROOT:

aws s3api put-bucket-versioning \
  --bucket log-cloudtrail-tap-trung \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

Đây là một trong số rất ít việc BẮT BUỘC dùng root
    → và cần bật versioning trước

⚠ Nhưng Object Lock thường tốt hơn MFA Delete:

aws s3api put-object-lock-configuration \
  --bucket log-cloudtrail-tap-trung \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}'

Object Lock chế độ COMPLIANCE:
    → KHÔNG AI xoá được, kể cả root
    → không cần thao tác MFA thủ công
        ↓
    Phải bật lúc TẠO bucket

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không Region nào bị bỏ sót | | | IAM và CloudFront được ghi lại | | | Log không sửa được, không xoá được | |

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

**D. CloudTrail với --no-include-global-service-events và --is-multi-region-trail — đây là phương án gần nhất và đúng ở vế đa Region, nhưng cờ --no-include-global-service-events loại bỏ chính xác IAM và CloudFront mà đề nhắc tới.
**A và B. Tạo "Amazon CloudWatch trail" — không tồn tại khái niệm này; CloudWatch không có trail. Đây là lỗi tên dịch vụ. (Phương án B còn thiếu cả cờ đa Region.)

Ghi nhớ

⚠ Hai cờ của CloudTrail — bảng phải thuộc: | Cờ | Thiếu nó thì mất gì | |---|---| | --is-multi-region-trail | sự kiện ở các Region khác | | --include-global-service-events | IAM, CloudFront, Route 53, Organizations, STS |

⚠ Kẻ tấn công thường hoạt động ở Region ít dùng:

Trail chỉ ghi một Region
    → tạo tài nguyên ở Region khác không bị ghi
        ↓
    Đây là kỹ thuật né tránh phổ biến
    → luôn bật multi-region

Từ khoá nhận diện:

"track changes in all Regions including IAM/CloudFront" → cả hai cờ "log integrity" → log file validation "prevent log deletion" → Object Lock hoặc MFA Delete "who changed configuration" → Config (bổ sung cho CloudTrail)

⚠ CloudTrail và Config trả lời hai câu hỏi khác nhau:

CloudTrail: "AI đã gọi API gì"
Config:     "tài nguyên ĐANG ở trạng thái nào,
             đã đổi ra sao"
        ↓
    Tuân thủ đầy đủ thường cần CẢ HAI

Ba loại sự kiện CloudTrail: | Loại | Mặc định | Ghi gì | |---|---|---| | Management | BẬT, miễn phí (trail đầu) | control plane | | Data | TẮT, có phí | s3:GetObject, lambda:Invoke | | Insights | TẮT, có phí | bất thường về tần suất |

Ba lưu ý về organization trail: | Lưu ý | Chi tiết | |---|---| | Tạo từ management account | | | Ghi log MỌI tài khoản thành viên | | | Thành viên KHÔNG tắt được | |

aws cloudtrail create-trail --name duong-mon-to-chuc \
  --s3-bucket-name log-tap-trung \
  --is-organization-trail --is-multi-region-trail \
  --include-global-service-events

Ba lưu ý về tài khoản chứa log: | Lưu ý | Chi tiết | |---|---| | Bucket log ở TÀI KHOẢN RIÊNG | | | Quyền rất hạn chế ở tài khoản đó | | | Chiếm tài khoản chính vẫn không xoá được log | |

⚠ Đây là nguyên tắc thiết kế quan trọng nhất:

Log nằm cùng tài khoản bị chiếm
    → kẻ tấn công xoá được
        ↓
    Tài khoản log riêng + Object Lock
    → bằng chứng còn nguyên

Ba lưu ý về cảnh báo: | Sự kiện | Vì sao nguy hiểm | |---|---| | StopLogging | tắt ghi log | | DeleteTrail | | | PutEventSelectors | thu hẹp phạm vi ghi |

{"source": ["aws.cloudtrail"],
 "detail": {"eventName": ["StopLogging","DeleteTrail",
                          "UpdateTrail","PutEventSelectors"]}}

Ba cách truy vấn log: | Cách | Đặc điểm | |---|---| | Console Event history | chỉ 90 ngày, chỉ management | | Athena trên bucket | rẻ nhất | | CloudTrail Lake | SQL, giữ tới 10 năm |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Trail đầu tiên (management) miễn phí | | | Trail thứ hai trở đi tính phí | | | Data event tính theo sự kiện — có thể rất lớn | |

Ba lưu ý về lifecycle của bucket log: | Lưu ý | Chi tiết | |---|---| | Chuyển sang Glacier sau 90 ngày | | | Giữ theo yêu cầu tuân thủ | | | Object Lock chặn xoá trước hạn | |

Ba lưu ý về KMS cho log: | Lưu ý | Chi tiết | |---|---| | Key policy phải cho CloudTrail dùng khoá | | | Người đọc log cần kms:Decrypt | | | Bật S3 Bucket Key giảm phí | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo tài nguyên ở Region khác, tìm trong log | | | Đổi một IAM policy, tìm sự kiện đó | | | Chạy validate-logs | |

aws cloudtrail get-trail-status --name duong-mon-tuan-thu \
  --query "[IsLogging,LatestDeliveryTime]"

Và một lời khuyên: hãy kiểm chứng trail bằng cách đổi một IAM policy rồi đi tìm sự kiện đó. IAM là dịch vụ toàn cầu, nên nếu bạn tìm thấy nó trong log thì cờ --include-global-service-events đã bật đúng — còn nếu không, bạn vừa phát hiện một lỗ hổng ngay ở chỗ nhạy cảm nhất.

Câu 27 Domain - Design Solutions for Organizational Complexity

A company has just launched a new central employee registry application that contains all of the public employee registration information of each staff of the company. The application has a microservices architecture running in Docker in a single AWS Region. The management teams from other departments who have their servers located in different VPCs need to connect to the central repository application to continue their work. The Solutions Architect must ensure that the traffic to the application does not traverse the public Internet. The IT Security team must also be notified of any denied requests and be able to view the corresponding source IP.

How will the Architect implement the architecture of the new application given these circumstances?

A
Link each of the teams' VPCs to the central VPC using VPC Peering. Create VPC Flow Logs on each VPC to capture rejected traffic requests, including the source IPs, that will be delivered to an Amazon CloudWatch Logs group. Set up a CloudWatch Logs subscription that streams the log data to the IT Security account.
B
Set up a Transit VPC by using third-party marketplace VPN appliances running on an On-Demand Amazon EC2 instance that dynamically routes the VPN connections to the virtual private gateways (VGWs) attached to each VPC. Set up an AWS Config rule on each VPC to capture rejected traffic requests, including the source IPs, that will be delivered to an Amazon CloudWatch Logs group. Set up a CloudWatch Logs subscription that streams the log data to the IT Security account.
C
Set up an IPSec Tunnel between the central VPC and each of the teams' VPCs. Create VPC Flow Logs on each VPC to capture rejected traffic requests, including the source IPs, that will be delivered to an Amazon CloudWatch Logs group. Create a CloudWatch Logs subscription that streams the log data to the IT Security account.
D
Use AWS Direct Connect to create a dedicated connection between the central VPC and each of the teams' VPCs. Enable the VPC Flow Logs on each VPC to capture rejected traffic requests, including the source IPs, that will be delivered to a CloudWatch Logs group. Set up an Amazon CloudWatch Logs subscription that streams the log data to the IT Security account.

Xem giải thích

Đáp án

A — Nối VPC của từng đội với VPC trung tâm bằng VPC Peering; bật VPC Flow Logs trên mỗi VPC để bắt các yêu cầu bị từ chối kèm IP nguồn, đổ vào CloudWatch Logs; dùng subscription đẩy log sang tài khoản của đội bảo mật.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu lượng KHÔNG đi qua Internet công cộng | VPC Peering — mạng riêng của AWS | | Bắt yêu cầu bị TỪ CHỐI kèm IP nguồn | VPC Flow Logs có action=REJECT và srcaddr | | Đội bảo mật xem được | CloudWatch Logs subscription xuyên tài khoản |

⚠ Flow Logs là nguồn duy nhất trong bốn phương án ghi được yêu cầu bị từ chối:

Bản ghi flow log:
    srcaddr dstaddr srcport dstport protocol
    packets bytes ACTION log-status
        ↓
    `action` là ACCEPT hoặc REJECT
    → đúng thứ đội bảo mật cần

Tạo flow log ở cấp VPC:

aws ec2 create-flow-logs \
  --resource-type VPC --resource-ids vpc-abc \
  --traffic-type REJECT \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flow-logs \
  --deliver-logs-permission-arn <arn-role> \
  --max-aggregation-interval 60

⚠ --traffic-type REJECT lọc ngay ở nguồn:

Ghi ALL: khối lượng rất lớn, phần lớn là ACCEPT
        ↓
    Chỉ cần REJECT → lọc ngay
    → giảm mạnh chi phí nạp log

Đẩy log sang tài khoản bảo mật:

aws logs put-subscription-filter \
  --log-group-name /vpc/flow-logs \
  --filter-name toi-doi-bao-mat \
  --filter-pattern "" \
  --destination-arn <arn-destination-tai-khoan-bao-mat>

⚠ Cross-account subscription cần một "destination" ở phía nhận:

# Ở tài khoản bảo mật
aws logs put-destination \
  --destination-name nhan-flow-log \
  --target-arn <arn-kinesis-stream> \
  --role-arn <arn-role>

aws logs put-destination-policy \
  --destination-name nhan-flow-log \
  --access-policy file://chinh-sach.json

⚠ Vì sao VPC Peering chứ không phải giải pháp khác:

Ứng dụng nằm trong MỘT Region
    → số VPC không quá lớn
        ↓
    Peering đơn giản nhất, không phí giờ
    → lưu lượng đi trên mạng xương sống AWS

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có gì đi qua Internet | | | Không phí giờ như Transit Gateway | | | Log tập trung ở tài khoản bảo mật | |

⚠ Nhưng peering KHÔNG bắc cầu — cần nhớ giới hạn:

VPC A ↔ trung tâm, VPC B ↔ trung tâm
    → A KHÔNG nói chuyện được với B
        ↓
    Đề chỉ cần các đội tới VPC trung tâm
    → peering đủ
        ↓
    Nếu các đội cũng cần gọi nhau
    → phải dùng Transit Gateway

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

**C. Dựng IPSec tunnel giữa VPC trung tâm và từng VPC — đây là phương án gần nhất và cũng giữ lưu lượng riêng tư nếu dựng đúng, nhưng tự dựng đường hầm IPsec giữa các VPC là công việc thủ công lớn, giới hạn băng thông, và có máy chủ VPN phải vận hành; peering làm sẵn tất cả.
**B. Transit VPC với thiết bị VPN bên thứ ba trên EC2 và dùng AWS Config bắt yêu cầu bị từ chối — kiến trúc transit VPC là mẫu đã lỗi thời (thay bằng Transit Gateway); và Config theo dõi cấu hình tài nguyên, nó không ghi lưu lượng mạng bị từ chối.
**D. Dùng Direct Connect giữa các VPC — Direct Connect nối trung tâm dữ liệu tại chỗ với AWS, không nối VPC với VPC.

Ghi nhớ

⚠ Ba cách nối VPC — bảng phải thuộc: | Cách | Bắc cầu | Phí giờ | Quy mô | |---|---|---|---| | VPC Peering | ❌ | không | 2-3 VPC | | Transit Gateway | ✅ | có | hàng nghìn | | PrivateLink | không áp dụng | có | một DỊCH VỤ |

⚠ PrivateLink đáng cân nhắc cho đúng bài này:

Đề nói các đội cần TRUY CẬP MỘT ỨNG DỤNG
    → không cần thấy toàn bộ mạng của nhau
        ↓
    PrivateLink phơi bày đúng một dịch vụ
    → và CIDR chồng lấn cũng không sao

Công thức số kết nối full mesh: n × (n-1) / 2

Ở đây là hình sao, không phải mesh
    → n VPC đội × 1 kết nối tới trung tâm
    → tuyến tính, không bùng nổ

Từ khoá nhận diện:

"traffic must not traverse the internet" → peering, PrivateLink, hoặc TGW "log rejected requests with source IP" → VPC Flow Logs "send logs to another account" → CloudWatch Logs subscription "connect on-premises to AWS" → Direct Connect / VPN

Ba cấp của VPC Flow Logs: | Cấp | Bao phủ | |---|---| | VPC | mọi ENI, gồm cả ENI tạo sau | | Subnet | mọi ENI trong subnet | | Network interface | chỉ ENI đó |

⚠ Cấp VPC bền nhất cho giám sát lâu dài:

Cấu hình theo ENI cụ thể
    → ENI mới (ASG thêm máy) không được ghi
        ↓
    Cấp VPC tự bao gồm mọi thứ

Ba trường quan trọng của flow log: | Trường | Ý nghĩa | |---|---| | action | ACCEPT hoặc REJECT | | srcaddr | IP nguồn — đề yêu cầu | | log-status | OK, NODATA, SKIPDATA |

⚠ SKIPDATA nghĩa là bản ghi bị BỎ:

Lưu lượng quá lớn trong cửa sổ tổng hợp
    → AWS bỏ bớt bản ghi
        ↓
    Flow Logs KHÔNG đảm bảo đầy đủ 100%
    → không dùng làm bằng chứng tuyệt đối

Ba đích của flow log: | Đích | Khi nào | |---|---| | CloudWatch Logs | cần cảnh báo và subscription | | S3 | rẻ nhất, phân tích bằng Athena | | Kinesis Data Firehose | đưa sang hệ thống khác |

⚠ S3 rẻ hơn nhiều cho khối lượng lớn:

CloudWatch Logs tính phí nạp cao
    → VPC bận sinh hàng chục GB mỗi ngày
        ↓
    S3 + Athena rẻ hơn nhiều lần
    → nhưng subscription chỉ có ở CloudWatch Logs

Ba lưu ý về subscription xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | Cần destination ở tài khoản nhận | | | Destination trỏ tới Kinesis hoặc Firehose | | | Destination policy cho phép tài khoản gửi | |

Ba lưu ý về peering: | Lưu ý | Chi tiết | |---|---| | CIDR KHÔNG được chồng lấn | | | Phải thêm route ở CẢ HAI bên | | | Tham chiếu SG hoạt động trong cùng Region | |

⚠ Thiếu route một chiều là lỗi phổ biến:

Thêm route ở VPC A, quên VPC B
    → gói tin sang được nhưng không về được
        ↓
    Kết nối treo tới timeout
    → trông như lỗi security group

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Security group tham chiếu SG của VPC kia | | | Chỉ mở đúng cổng ứng dụng cần | | | NACL nếu cần chặn IP cụ thể | |

Ba lưu ý về gỡ lỗi: | Công cụ | Việc | |---|---| | Reachability Analyzer | chỉ ra chặn ở đâu | | Flow Logs | thấy gói REJECT | | describe-route-tables | kiểm tuyến |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ping từ VPC đội tới VPC trung tâm | | | Cố tình gọi cổng bị chặn, tìm REJECT trong log | | | Xác nhận log tới tài khoản bảo mật | |

aws ec2 create-network-insights-path \
  --source i-doi-a --destination i-trung-tam \
  --protocol tcp --destination-port 443

Và một lời khuyên: hãy cấu hình Flow Logs ở cấp VPC chứ đừng theo từng ENI. Auto Scaling và load balancer thêm bớt network interface liên tục, nên một danh sách ENI đúng hôm nay sẽ bỏ sót lưu lượng vào tuần sau — và bạn không có cách nào biết ngoài việc đi đối chiếu lại.

Câu 28 Chọn nhiều đáp án Domain - Design Solutions for Organizational Complexity

A company has a fitness tracking app that accompanies its smartwatch. The primary customers are North American and Asian users. The application is read-heavy as it pings the servers at regular intervals for user-authorization. The company wants the infrastructure to have the following capabilities:

- The application must be fault-tolerant to problems in any Region.

- The database writes must be highly-available in a single Region.

- The application tier must be able to read the database on multiple Regions.

- The application tier must be resilient in each Region.

- Relational database semantics must be reflected in the application.

Which of the following options must the Solutions Architect implement to meet the company requirements? (Select TWO.)

A
Deploy the application tier on an Auto Scaling group of EC2 instances for each Region. Create an RDS for MySQL database on each region. Configure the application to perform read/write operations on the local RDS. Enable Multi-AZ failover support for the EC2 Auto Scaling group and the RDS database. Enable cross-Region replication for the database servers.
B
Deploy the application tier on an Auto Scaling group of EC2 instances for each Region. Create an RDS for MySQL database on each region. Configure the application to perform read/write operations on the local RDS. Enable cross-Region replication for the database servers. Create snapshots of the application and database servers regularly. Store the snapshots in Amazon S3 buckets in both regions.
C
Create a geoproximity routing policy on Amazon Route 53 to control traffic and direct users to their closest regional endpoint. Combine this with a multivalue answer routing policy with health checks to direct users to a healthy region at any given time.
D
Create a geolocation routing policy on Amazon Route 53 to point the global users to their designated regions. Combine this with a failover answer routing policy with health checks to direct users to a healthy region at any given time.
E
Deploy the application tier on an Auto Scaling group of EC2 instances for each Region in an active-active configuration. Create a cluster of Amazon Aurora global database in both Regions. Configure the application to use the in-Region Aurora database endpoint for the read/write operations. Create snapshots of the application servers regularly. Store the snapshots in Amazon S3 buckets in both regions.

Xem giải thích

Đáp án

D và E — Dùng geolocation routing của Route 53 đưa người dùng về Region tương ứng, kết hợp failover routing với health check; và triển khai tầng ứng dụng trên ASG ở mỗi Region theo cấu hình active-active, dùng Aurora Global Database với endpoint trong Region cho thao tác đọc/ghi.

Vì sao đúng

Đề nêu năm yêu cầu, và cặp này thoả từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Chịu được sự cố ở BẤT KỲ Region nào | active-active + failover routing | | GHI sẵn sàng cao trong MỘT Region | Aurora Global — một writer | | ĐỌC được ở NHIỀU Region | Aurora Global — replica đọc mỗi Region | | Tầng ứng dụng bền ở mỗi Region | ASG đa AZ | | Giữ ngữ nghĩa CSDL QUAN HỆ | Aurora, không phải DynamoDB |

⚠ Yêu cầu thứ hai là chi tiết tinh tế nhất:

"Database writes must be highly-available
 in a SINGLE Region"
        ↓
    Đề KHÔNG đòi ghi ở nhiều Region
    → chỉ đòi ghi sẵn sàng cao trong một Region
        ↓
    Đây chính xác là mô hình của Aurora Global Database

Dựng Aurora Global Database:

aws rds create-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --source-db-cluster-identifier <arn-cum-chinh>

aws rds create-db-cluster \
  --db-cluster-identifier cum-chau-a \
  --engine aurora-postgresql \
  --global-cluster-identifier cum-toan-cau \
  --region ap-southeast-1

⚠ Ứng dụng dùng endpoint TRONG Region cho ĐỌC:

Ứng dụng đọc nhiều (đề nói "read-heavy")
    → đọc từ replica trong chính Region
    → độ trễ vài mili giây
        ↓
    Ghi vẫn đi về Region chính
    → chấp nhận được vì ghi ít hơn nhiều

Geolocation + failover routing:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{
    "Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"ung-dung.vidu.com","Type":"A",
      "SetIdentifier":"bac-my",
      "GeoLocation":{"ContinentCode":"NA"},
      "AliasTarget":{"HostedZoneId":"<id-alb-my>",
        "DNSName":"alb-my.us-east-1.elb.amazonaws.com",
        "EvaluateTargetHealth":true}}}]}'

⚠ Vì sao geolocation chứ không phải geoproximity: | Kiểu | Cách hoạt động | |---|---| | Geolocation | theo VỊ TRÍ ĐỊA LÝ của người dùng | | Geoproximity | theo KHOẢNG CÁCH tới tài nguyên, có bias |

Đề nói "point the global users to their
        DESIGNATED regions"
        ↓
    "Được chỉ định" = theo châu lục
    → geolocation đúng hơn

⚠ Và vì sao failover routing chứ không phải multivalue: | Kiểu | Hành vi khi hỏng | |---|---| | Failover | chuyển sang bản ghi phụ đã định | | Multivalue | trả về nhiều IP, client tự chọn |

Multivalue trả tối đa 8 bản ghi khoẻ
    → client chọn ngẫu nhiên
    → KHÔNG kiểm soát được người dùng đi đâu
        ↓
    Failover: xác định rõ Region dự phòng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đọc độ trễ thấp ở mọi Region | | | Region hỏng thì chuyển tự động | | | Giữ nguyên ngữ nghĩa quan hệ | |

⚠ Aurora Global Database cho RPO ~1 giây, RTO dưới 1 phút:

aws rds failover-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --target-db-cluster-identifier <arn-cum-chau-a>

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

**C. Geoproximity routing kết hợp multivalue answer với health check — đây là phương án gần nhất và cũng là hai kiểu định tuyến thật, nhưng không kết hợp được geoproximity với multivalue trên cùng một bản ghi, và multivalue không cho kiểm soát Region dự phòng như đề cần.
**A và B. RDS for MySQL ở mỗi Region với ứng dụng đọc/ghi vào RDS ĐỊA PHƯƠNG và nhân bản xuyên Region — mô hình này tạo ra nhiều writer độc lập, dẫn tới xung đột dữ liệu mà RDS không giải quyết được; và đề nói rõ ghi phải sẵn sàng cao trong MỘT Region, không phải nhiều.

Ghi nhớ

⚠ Bảy kiểu định tuyến của Route 53 — bảng phải thuộc: | Kiểu | Chọn theo | |---|---| | Simple | một bản ghi | | Weighted | tỷ lệ phần trăm | | Latency | độ trễ mạng thấp nhất | | Failover | chính/phụ theo health check | | Geolocation | VỊ TRÍ người dùng | | Geoproximity | khoảng cách tới tài nguyên, có bias | | Multivalue | nhiều IP khoẻ, client chọn |

⚠ Latency vs Geolocation — khác biệt cốt lõi:

Latency: đo độ trễ MẠNG thật
    → có thể gửi người ở Việt Nam sang Singapore
      nếu đường tới đó nhanh hơn
        ↓
Geolocation: theo bản đồ
    → người ở châu Á LUÔN về Region châu Á
    → dùng khi có yêu cầu pháp lý về địa lý

Từ khoá nhận diện:

"send users to their designated region" → geolocation "lowest network latency" → latency-based "primary and standby region" → failover "relational, multi-Region read" → Aurora Global Database "write in multiple Regions" → DynamoDB Global Tables

⚠ Kết hợp nhiều kiểu bằng bản ghi lồng nhau:

Bản ghi geolocation trỏ tới
    → một bản ghi failover (chính/phụ)
        ↓
    Route 53 cho phép "alias tới bản ghi khác
      trong cùng hosted zone"
    → xếp tầng được nhiều chính sách

Ba giới hạn của Aurora Global Database: | Giới hạn | Chi tiết | |---|---| | Chỉ MỘT cụm ghi | | | Tới 5 vùng phụ | | | Vùng phụ chỉ đọc tới khi thăng cấp | |

⚠ Write forwarding giúp ứng dụng đơn giản hơn:

SET aurora_replica_read_consistency = 'SESSION';

Vùng phụ nhận lệnh ghi rồi chuyển về vùng chính
    → ứng dụng dùng MỘT endpoint duy nhất
    → độ trễ ghi cao hơn nhưng mã đơn giản hơn

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Kiểm từ nhiều nơi trên thế giới | | | Endpoint phải công khai, hoặc dùng CloudWatch alarm | | | Calculated health check gộp nhiều điều kiện | |

⚠ EvaluateTargetHealth cho alias record:

Đặt true
    → Route 53 tự dùng health của ALB
    → không cần tạo health check riêng

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp = chuyển nhanh hơn | | | 60 giây là mức thường dùng cho failover | | | TTL cao làm RTO thực tế dài hơn | |

Ba thứ phải chuẩn bị ở mỗi Region: | Thứ | Hậu quả nếu quên | |---|---| | AMI đã copy | ASG không khởi động nổi | | Chứng chỉ ACM | ACM theo Region | | Hạn ngạch tài khoản | không mở rộng đủ |

⚠ Và kiểm tra năng lực gánh 100% tải:

Hai Region, mỗi bên 50% lưu lượng
    → một Region hỏng
        ↓
    Region còn lại phải chịu 100%
    → nếu không đủ thì cũng sập theo

Ba lưu ý về ASG đa AZ: | Lưu ý | Chi tiết | |---|---| | min-size ít nhất bằng số AZ | | | Health check type ELB | | | Trải ít nhất 2 AZ mỗi Region | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | AuroraGlobalDBReplicationLag | RPO thực tế | | Route 53 health check status | | | Độ trễ p99 theo Region | |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | failover-global-cluster không mất dữ liệu | | | Diễn tập ít nhất 2 lần/năm | | | Đo RTO của TOÀN BỘ kiến trúc | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn DNS từ nhiều châu lục | | | Tắt một Region, xem chuyển đúng | | | Đo độ trễ nhân bản Aurora | |

Và một lời khuyên: hãy đọc kỹ xem đề đòi ghi ở MỘT Region hay NHIỀU Region. Đây là câu hỏi phân biệt Aurora Global Database với DynamoDB Global Tables, và nó cũng là ranh giới giữa một kiến trúc chạy được với một kiến trúc có xung đột dữ liệu không thể giải quyết.

Câu 29 Domain - Continuous Improvement for Existing Solutions

A graphics design startup is using multiple Amazon S3 buckets to store high-resolution media files for their various digital artworks. After securing a partnership deal with a leading media company, the two parties shall be sharing digital resources with one another as part of the contract. The media company frequently performs multiple object retrievals from the S3 buckets every day, which increased the startup's data transfer costs.

As the Solutions Architect, what should you do to help the startup lower their operational costs?

A
Provide cross-account access for the media company, which has permissions to access contents in the S3 bucket. Cross-account retrieval of S3 objects is charged to the account that made the request.
B
Create a new billing account for the social media company by using AWS Organizations. Apply SCPs on the organization to ensure that each account has access only to its own resources and each other's S3 buckets.
C
Advise the media company to create their own S3 bucket. Then run the aws s3 sync s3://sourcebucket s3://destinationbucket command to copy the objects from their S3 bucket to the other party's S3 bucket. In this way, future retrievals can be made on the media company's S3 bucket instead.
D
Enable the Requester Pays feature in all of the startup's S3 buckets to make the media company pay the cost of the data transfer from the buckets.

Xem giải thích

Đáp án

D — Bật tính năng Requester Pays trên toàn bộ bucket S3 của startup để công ty truyền thông trả chi phí truyền dữ liệu khi họ tải object.

Vì sao đúng

Đề nêu một vấn đề chi phí rất cụ thể: đối tác tải nhiều object mỗi ngày, và startup đang trả tiền cho việc đó.

⚠ Mặc định, CHỦ BUCKET trả mọi chi phí:

Ai tải object cũng được
    → chủ bucket trả:
      → phí lưu trữ
      → phí request
      → phí truyền dữ liệu ra
        ↓
    Đối tác dùng càng nhiều, startup trả càng nhiều

⚠ Requester Pays đảo ngược điều đó:

Bật Requester Pays
    → NGƯỜI GỌI trả phí request và phí truyền dữ liệu
    → chủ bucket chỉ còn trả phí LƯU TRỮ
        ↓
    Chi phí đi theo người dùng

Bật:

aws s3api put-bucket-request-payment \
  --bucket kho-tac-pham \
  --request-payment-configuration Payer=Requester

⚠ Người gọi PHẢI khai tường minh rằng họ chấp nhận trả:

aws s3api get-object --bucket kho-tac-pham \
  --key anh/tac-pham-01.psd anh-tai-ve.psd \
  --request-payer requester

Thiếu `--request-payer requester`
    → nhận lỗi 403 Access Denied
        ↓
    Đây là cơ chế bảo vệ: không ai vô tình
      bị tính tiền

Ba điều kiện của Requester Pays: | Điều kiện | Chi tiết | |---|---| | Người gọi phải XÁC THỰC | không có truy cập ẩn danh | | Phải khai x-amz-request-payer | | | Chủ bucket vẫn trả phí lưu trữ | |

⚠ Yêu cầu ẩn danh bị chặn hoàn toàn:

Bật Requester Pays
    → mọi truy cập ẩn danh bị từ chối
        ↓
    Vì phải biết TÍNH TIỀN CHO AI
    → đây cũng là một lợi ích bảo mật phụ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chi phí truyền dữ liệu chuyển sang đối tác | | | Không phải nhân bản dữ liệu | | | Không đổi kiến trúc gì | |

⚠ Đối tác cũng cần quyền IAM để đọc bucket:

Requester Pays quyết định AI TRẢ TIỀN
    → không quyết định AI ĐƯỢC PHÉP
        ↓
    Vẫn phải có bucket policy cấp quyền
      cho tài khoản đối tác

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::222222222222:root"},
 "Action": ["s3:GetObject", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::kho-tac-pham",
              "arn:aws:s3:::kho-tac-pham/*"]}

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

**A. Cấp cross-account access và cho rằng "truy xuất xuyên tài khoản được tính cho bên gọi" — đây là phương án gần nhất và nghe rất hợp lý, nhưng nó sai về mặt sự thật: truy cập xuyên tài khoản thông thường vẫn tính phí cho chủ bucket. Chỉ Requester Pays mới đổi được điều đó.
**C. Chép object sang bucket của đối tác bằng aws s3 sync — nhân đôi lưu trữ, phải đồng bộ liên tục, và chính lần chép đó cũng tính phí truyền dữ liệu cho startup.
**B. Tạo tài khoản thanh toán riêng bằng Organizations và dùng SCP — SCP giới hạn quyền, không chuyển chi phí; và đưa hai công ty khác nhau vào cùng một tổ chức là mô hình quản trị sai.

Ghi nhớ

⚠ Ba mô hình chi phí S3 — bảng phải thuộc: | Mô hình | Ai trả phí truyền | |---|---| | Mặc định | chủ bucket | | Requester Pays | người gọi | | Cross-account thông thường | vẫn là chủ bucket |

⚠ Đây là điều hay bị hiểu nhầm nhất:

"Tài khoản khác gọi thì họ trả tiền"
    → SAI
        ↓
    Chủ bucket trả, trừ khi bật Requester Pays

Từ khoá nhận diện:

"partner downloads a lot, reduce my transfer cost" → Requester Pays "share data publicly, I pay" → mặc định "replicate to partner's bucket" → S3 Replication (tốn gấp đôi lưu trữ) "share access, not cost" → bucket policy

Ba trường hợp Requester Pays phù hợp: | Trường hợp | Chi tiết | |---|---| | Chia sẻ dữ liệu với đối tác | | | Bộ dữ liệu mở cho nghiên cứu | | | Nhà cung cấp dữ liệu tính phí người dùng | |

⚠ Nhiều bộ dữ liệu công khai lớn dùng mô hình này:

Registry of Open Data on AWS
    → một số bộ dữ liệu bật Requester Pays
        ↓
    Nhà cung cấp không phải trả cho hàng nghìn
      người tải về

Ba lưu ý về hành vi API: | Thao tác | Chi tiết | |---|---| | GET, LIST | cần --request-payer requester | | PUT | người ghi trả phí request | | Truy cập ẩn danh | bị TỪ CHỐI hoàn toàn |

⚠ Ứng dụng của đối tác phải sửa mã:

s3.get_object(Bucket='kho-tac-pham',
              Key='anh/tac-pham-01.psd',
              RequestPayer='requester')

Đây là chi phí chuyển đổi phải báo trước
    → mọi SDK đều hỗ trợ tham số này

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | CloudFront KHÔNG hỗ trợ Requester Pays | | | Phải truy cập trực tiếp S3 | | | Cân nhắc kỹ nếu cần CDN | |

⚠ Đây là giới hạn quan trọng:

Muốn vừa có CDN vừa chuyển chi phí
    → không làm được với Requester Pays
        ↓
    Phải chọn: CDN (chủ trả) hoặc
                truy cập trực tiếp (người gọi trả)

Ba cách giảm chi phí truyền dữ liệu khác: | Cách | Chi tiết | |---|---| | VPC endpoint nếu đối tác cũng ở AWS | miễn phí trong cùng Region | | S3 Cross-Region Replication | đối tác đọc bản gần họ | | Nén dữ liệu trước khi lưu | |

⚠ Nếu đối tác cũng dùng AWS cùng Region:

Truyền dữ liệu giữa S3 và EC2 CÙNG Region
    → MIỄN PHÍ
        ↓
    Chi phí lớn thường đến từ truyền RA INTERNET
    → hỏi đối tác họ đang ở đâu

Ba lưu ý về theo dõi chi phí: | Việc | Cách | |---|---| | Cost Explorer lọc theo usage type | | | DataTransfer-Out-Bytes là khoản chính | | | S3 Storage Lens phân tích mẫu truy cập | |

Ba lưu ý về ghi log truy cập: | Lưu ý | Chi tiết | |---|---| | S3 server access log ghi ai tải gì | | | CloudTrail data event chi tiết hơn, đắt hơn | | | Hữu ích để đối chiếu hoá đơn với đối tác | |

Ba lưu ý về pháp lý: | Lưu ý | Chi tiết | |---|---| | Thoả thuận rõ ai trả chi phí gì | | | Báo trước khi bật để đối tác sửa mã | | | Bật đột ngột làm hỏng ứng dụng của họ | |

⚠ Bật Requester Pays là thay đổi PHÁ VỠ TƯƠNG THÍCH:

Ứng dụng đối tác đang gọi bình thường
    → bật lên là mọi lời gọi trả 403
        ↓
    Phải phối hợp thời điểm chuyển đổi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi không có header | phải 403 | | Gọi có header | phải thành công | | Kiểm tra hoá đơn tháng sau | |

aws s3api get-bucket-request-payment --bucket kho-tac-pham

Và một lời khuyên: hãy báo trước cho đối tác trước khi bật Requester Pays. Đây là thay đổi phá vỡ tương thích: mọi lời gọi hiện có của họ sẽ trả về 403 cho tới khi mã được sửa để thêm header — và một buổi chiều ứng dụng của đối tác ngừng hoạt động sẽ tốn hơn nhiều so với khoản bạn vừa tiết kiệm.

Câu 30 Domain - Continuous Improvement for Existing Solutions

A company hosts its multi-tiered web application on a fleet of Auto Scaling EC2 instances spread across two Availability Zones. The Application Load Balancer is in the public subnets and the Amazon EC2 instances are in the private subnets. After a few weeks of operations, the users are reporting that the web application is not working properly. Upon testing, the Solutions Architect found that the website is accessible and the login is successful. However, when the “find a nearby store” function is clicked on the website, the map loads only about 50% of the time when the page is refreshed. This function involves a third-party RESTful API call to a maps provider. Amazon EC2 NAT instances are used for these outbound API calls.

Which of the following options are the MOST likely reason for this failure and the recommended solution?

A
One of the subnets in the VPC has a misconfigured Network ACL that blocks outbound traffic to the third-party provider. Update the network ACL to allow this connection and configure IAM permissions to restrict these changes in the future.
B
This error is caused by failed NAT instance in one of the public subnets. Use NAT Gateways instead of EC2 NAT instances to ensure availability and scalability.
C
This error is caused by an overloaded NAT instance in one of the subnets. Scale the EC2 NAT instances to larger-sized instances to ensure that they can handle the growing traffic.
D
The error is caused by a failure in one of their availability zones in the VPC of the third-party provider. Contact the third-party provider support hotline and request for them to fix it.

Xem giải thích

Đáp án

B — Lỗi do một NAT instance ở một trong các subnet công khai bị hỏng; dùng NAT Gateway thay cho NAT instance để có tính sẵn sàng và khả năng mở rộng.

Vì sao đúng

Đề cho một manh mối rất đặc trưng: bản đồ tải được khoảng 50% số lần.

⚠ Con số 50% chỉ thẳng vào kiến trúc hai AZ:

Ứng dụng trải hai Availability Zone
    → mỗi AZ có một NAT instance riêng
        ↓
    Một NAT instance hỏng
    → máy ở AZ đó không gọi được API bên ngoài
    → máy ở AZ kia vẫn gọi được
        ↓
    ALB chia đều lưu lượng
    → khoảng 50% request thất bại

Vì sao đăng nhập vẫn được:

Đăng nhập chỉ dùng tài nguyên TRONG VPC
    → không cần ra Internet
        ↓
    Chỉ chức năng "tìm cửa hàng gần nhất"
      mới gọi API bản đồ bên ngoài
    → đúng triệu chứng đề mô tả

⚠ NAT instance là cách CŨ, có nhiều điểm yếu: | Điểm yếu | Chi tiết | |---|---| | Một máy đơn lẻ — không tự phục hồi | | | Băng thông giới hạn theo cỡ máy | | | Phải tự vá hệ điều hành | | | Phải tắt source/destination check | |

NAT Gateway giải quyết cả bốn:

for az in a b; do
  eip=$(aws ec2 allocate-address --domain vpc \
        --query AllocationId --output text)
  nat=$(aws ec2 create-nat-gateway \
        --subnet-id subnet-cong-khai-$az \
        --allocation-id $eip \
        --query NatGateway.NatGatewayId --output text)
  aws ec2 create-route --route-table-id rtb-rieng-tu-$az \
    --destination-cidr-block 0.0.0.0/0 --nat-gateway-id $nat
done

⚠ Vẫn phải một NAT Gateway MỖI AZ:

NAT Gateway do AWS quản lý và tự dự phòng
    → nhưng vẫn nằm TRONG MỘT AZ
        ↓
    Một cái dùng chung cho hai AZ
    → AZ chứa nó hỏng = cả hai mất Internet
    → và trả phí truyền dữ liệu liên AZ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AWS tự thay thành phần hỏng | | | Tự mở rộng từ 5 Gbps tới 100 Gbps | | | Không phải vá gì | |

⚠ Vì sao không phải "quá tải" (phương án C):

Quá tải cho triệu chứng CHẬM DẦN
hoặc lỗi ngẫu nhiên rải rác
        ↓
    Con số 50% ổn định chỉ ra một AZ
      hỏng hoàn toàn
    → không phải vấn đề năng lực

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

**C. NAT instance quá tải, cần đổi sang máy lớn hơn — đây là phương án gần nhất và cũng đổ lỗi cho NAT instance, nhưng quá tải cho triệu chứng khác: chậm dần, lỗi rải rác, không phải đúng 50%. Và đổi cỡ máy không giải quyết được vấn đề sẵn sàng.
**A. Một NACL cấu hình sai chặn lưu lượng ra — có thể gây triệu chứng tương tự, nhưng NACL là cấu hình tĩnh: nó sẽ hỏng ngay từ đầu, không phải "sau vài tuần vận hành" như đề nói.
**D. Sự cố ở AZ của nhà cung cấp bản đồ — nếu vậy thì lỗi sẽ ảnh hưởng mọi request, không phải đúng một nửa; và không giải thích được vì sao chỉ ứng dụng này gặp vấn đề.

Ghi nhớ

⚠ NAT Gateway vs NAT instance — bảng phải thuộc: | Tiêu chí | NAT Gateway | NAT instance | |---|---|---| | Quản lý | AWS | bạn | | Sẵn sàng | tự dự phòng trong AZ | tự dựng | | Băng thông | 5 → 100 Gbps tự động | theo cỡ máy | | Vá hệ điều hành | không cần | cần | | Security group | KHÔNG gắn được | gắn được | | Bastion / port forwarding | ❌ | ✅ |

⚠ NAT instance chỉ còn hợp lý trong hai trường hợp:

1. Cần port forwarding hoặc dùng làm bastion
2. Lưu lượng rất nhỏ và muốn tiết kiệm tối đa
        ↓
    Còn lại: NAT Gateway

Từ khoá nhận diện:

"works about 50% of the time, two AZs" → một thành phần ở một AZ hỏng "NAT instance" → cân nhắc đổi sang NAT Gateway "outbound internet from private subnet" → NAT Gateway mỗi AZ "IPv6 outbound" → egress-only internet gateway

⚠ Mẫu chẩn đoán "một nửa số lần" rất đáng nhớ:

Triệu chứng ~50% trong kiến trúc 2 AZ
    → gần như luôn là một AZ có vấn đề
        ↓
    ~33% trong kiến trúc 3 AZ
    → cùng một mẫu

Ba cách xác nhận giả thuyết: | Cách | Chi tiết | |---|---| | So log lỗi theo AZ | | | VPC Flow Logs xem gói từ AZ nào bị rơi | | | Thử curl từ máy ở từng AZ | |

aws ec2 describe-instances \
  --filters Name=tag:Name,Values=nat-* \
  --query "Reservations[].Instances[].[InstanceId,
    Placement.AvailabilityZone,State.Name]" --output table

Ba lưu ý về NAT instance nếu buộc phải dùng: | Lưu ý | Chi tiết | |---|---| | Tắt source/destination check | | | Đặt trong ASG với min=max=1 mỗi AZ | | | Script tự cập nhật route khi thay máy | |

aws ec2 modify-instance-attribute \
  --instance-id i-abc --no-source-dest-check

Ba khoản chi phí NAT Gateway: | Khoản | Giá tham khảo | |---|---| | Phí giờ | ~0,045 USD/giờ | | Phí xử lý dữ liệu | ~0,045 USD/GB | | Nhân số AZ | |

⚠ Giảm phí bằng VPC endpoint: | Endpoint | Loại | Phí | |---|---|---| | S3, DynamoDB | Gateway | miễn phí | | SSM, ECR, Secrets Manager | Interface | có phí |

Lưu lượng tới dịch vụ AWS không nên đi qua NAT
    → tạo endpoint là tiết kiệm ngay

Ba giới hạn của NAT Gateway: | Giới hạn | Giá trị | |---|---| | ~55.000 kết nối đồng thời mỗi đích | | | Vượt thì ErrorPortAllocation | | | Không gắn security group | |

Ba lưu ý về Elastic IP: | Lưu ý | Chi tiết | |---|---| | Mỗi NAT Gateway một EIP | | | EIP là IP đi ra — đối tác đưa vào allowlist | | | Nhiều NAT = nhiều IP phải khai | |

⚠ Đây là chi tiết liên quan tới đề:

Nhà cung cấp bản đồ có thể yêu cầu allowlist IP
    → thay NAT instance bằng NAT Gateway
      = ĐỔI IP đi ra
        ↓
    Phải báo trước cho họ, nếu không
      lỗi sẽ chuyển từ 50% thành 100%

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ErrorPortAllocation | cạn cổng | | PacketsDropCount | | | BytesOutToDestination | |

Ba lưu ý về thử lại ở ứng dụng: | Lưu ý | Chi tiết | |---|---| | Gọi API bên ngoài phải có thử lại | | | Exponential backoff và jitter | | | Circuit breaker cho phụ thuộc hay lỗi | |

⚠ Ứng dụng tốt sẽ che được sự cố kiểu này:

Thử lại tự động
    → request thất bại ở AZ hỏng được thử lại
    → có thể rơi vào máy ở AZ khoẻ
        ↓
    Người dùng không thấy lỗi
    → nhưng vẫn phải sửa nguyên nhân gốc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl ra Internet từ máy ở từng AZ | | | Kiểm tra route table mỗi subnet riêng tư | | | Xác nhận có NAT Gateway ở mọi AZ | |

Và một lời khuyên: hãy nhớ mẫu chẩn đoán "một nửa số lần". Trong kiến trúc hai vùng sẵn sàng, một tỷ lệ lỗi ổn định quanh 50% gần như luôn có nghĩa là một thành phần chỉ tồn tại ở một vùng đã hỏng — và đó là câu hỏi đầu tiên nên đặt ra trước khi đi tìm nguyên nhân nào phức tạp hơn.

Trang 3 / 123 — tổng 1221 câu hỏi