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

Tìm thấy 2194 câu.

Câu 471 Design Secure Architectures

Consider the following policy associated with an IAM group containing several users:

{
    "Version":"2012-10-17",
    "Id":"EC2TerminationPolicy",
    "Statement":[
        {
            "Effect":"Deny",
            "Action":"ec2:*",
            "Resource":"*",
            "Condition":{
                "StringNotEquals":{
                    "ec2:Region":"us-west-1"
                }
            }
        },
        {
            "Effect":"Allow",
            "Action":"ec2:TerminateInstances",
            "Resource":"*",
            "Condition":{
                "IpAddress":{
                    "aws:SourceIp":"10.200.200.0/24"
                }
            }
        }
    ]
}

Which of the following options is correct?

  1. A

    Users belonging to the IAM user group can terminate an Amazon EC2 instance in the us-west-1 region when the EC2 instance's IP address is 10.200.200.200
  2. B

    Users belonging to the IAM user group can terminate an Amazon EC2 instance in the us-west-1 region when the user's source IP is 10.200.200.200
  3. C

    Users belonging to the IAM user group can terminate an Amazon EC2 instance belonging to any region except the us-west-1 region when the user's source IP is 10.200.200.200
  4. D

    Users belonging to the IAM user group cannot terminate an Amazon EC2 instance in the us-west-1 region when the user's source IP is 10.200.200.200
Xem giải thích

Đáp án

B — Người dùng trong nhóm có thể chấm dứt EC2 instance ở Region us-west-1 khi IP NGUỒN CỦA NGƯỜI DÙNG là 10.200.200.200.

Vì sao đúng

Chính sách có hai statement, và phải đọc cả hai cùng lúc:

Statement 1 — DENY mọi thao tác EC2 ngoài us-west-1:

{"Effect": "Deny", "Action": "ec2:*", "Resource": "*",
 "Condition": {"StringNotEquals": {"ec2:Region": "us-west-1"}}}

StringNotEquals: Region KHÁC us-west-1
    → mọi hành động EC2 ở Region khác đều BỊ CHẶN
    → chỉ us-west-1 thoát khỏi Deny này

Statement 2 — ALLOW chấm dứt instance khi IP nguồn khớp:

{"Effect": "Allow", "Action": "ec2:TerminateInstances", "Resource": "*",
 "Condition": {"IpAddress": {"aws:SourceIp": "10.200.200.0/24"}}}

Kết hợp hai statement:

Được chấm dứt instance KHI VÀ CHỈ KHI:
    ① Region = us-west-1        (thoát Deny)
    VÀ
    ② IP nguồn ∈ 10.200.200.0/24 (khớp Allow)

10.200.200.200 nằm trong 10.200.200.0/24 → thoả điều kiện.

Và điểm mấu chốt: aws:SourceIp là IP của NGƯỜI GỌI, không phải của instance.

aws:SourceIp = IP mà REQUEST được gửi đi từ đó
    → IP máy trạm chạy AWS CLI
    → KHÔNG phải IP của instance sắp bị chấm dứt

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

  • **A. Chấm dứt được ở us-west-1 khi IP CỦA INSTANCE là 10.200.200.200 — đây là phương án gần nhất và là bẫy chính: nó đúng về Region nhưng hiểu sai chủ thể của aws:SourceIp. Khoá này nói về người gọi API, không phải về tài nguyên bị tác động.
  • **C. Chấm dứt được ở MỌI Region TRỪ us-west-1 — đảo ngược statement Deny: StringNotEquals với Deny nghĩa là chặn các Region khác, tức là chỉ us-west-1 được phép.
  • **D. KHÔNG chấm dứt được ở us-west-1 khi IP nguồn là 10.200.200.200 — sai: đó chính là trường hợp duy nhất được phép.

Ghi nhớ

Ba quy tắc đánh giá chính sách IAM — phải thuộc:

① Mặc định: TỪ CHỐI ngầm định
② Explicit Allow → cho phép
③ Explicit DENY → TỪ CHỐI, thắng mọi Allow

Và cách đọc chính sách nhiều statement:

Bước 1: có Deny nào khớp không? → có thì DỪNG, từ chối
Bước 2: có Allow nào khớp không? → có thì cho phép
Bước 3: không có gì khớp → từ chối ngầm định

Bốn toán tử điều kiện hay gây nhầm: | Toán tử | Khớp khi | |---|---| | StringEquals | giá trị BẰNG | | StringNotEquals | giá trị KHÁC | | StringLike | khớp có ký tự đại diện * | | Null | khoá có tồn tại hay không |

Mẫu Deny + StringNotEquals là cách chuẩn để giới hạn Region:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:RequestedRegion": ["ap-northeast-1", "ap-southeast-1"]}}}

Đọc là: "chặn mọi thứ nếu Region KHÔNG nằm trong danh sách" — tức là chỉ cho phép danh sách đó.

Hai khoá điều kiện về Region — phân biệt: | Khoá | Phạm vi | |---|---| | ec2:Region | chỉ dịch vụ EC2 ← câu này | | aws:RequestedRegion | toàn cục, mọi dịch vụ |

aws:RequestedRegion là khoá nên dùng — nó áp cho mọi dịch vụ chứ không riêng EC2.

Các khoá điều kiện toàn cục quan trọng: | Khoá | Ý nghĩa | |---|---| | aws:SourceIp | IP CÔNG CỘNG của người gọi | | aws:RequestedRegion | Region của request | | aws:PrincipalArn | ARN của người gọi | | aws:PrincipalOrgID | id Organization | | aws:MultiFactorAuthPresent | có MFA không | | aws:SecureTransport | có HTTPS không | | aws:ResourceTag/<key> | thẻ của tài nguyên | | aws:RequestTag/<key> | thẻ trong request | | aws:ViaAWSService | dịch vụ AWS gọi thay |

Ba cạm bẫy của aws:SourceIp: | Cạm bẫy | Chi tiết | |---|---| | KHÔNG hoạt động qua VPC endpoint | dùng aws:SourceVpce hoặc aws:VpcSourceIp | | KHÔNG áp khi dịch vụ AWS gọi thay bạn | thêm aws:ViaAWSService | | Chỉ khớp IP CÔNG CỘNG | |

Dòng cuối đáng chú ý với câu này: 10.200.200.0/24 là dải IP riêng (RFC 1918). Điều kiện aws:SourceIp với dải riêng chỉ khớp khi request đi qua VPC endpoint và bạn dùng aws:VpcSourceIp — với request qua Internet, IP nguồn luôn là IP công cộng. (Đây là chi tiết kỹ thuật của tình huống thật; câu hỏi vẫn kiểm tra đúng khái niệm.)

Ba nguyên tắc viết chính sách an toàn: | Nguyên tắc | Chi tiết | |---|---| | Đặc quyền tối thiểu | chỉ hành động và tài nguyên thật sự cần | | Dùng Deny cho ranh giới cứng | Deny thắng mọi Allow | | Ghi Sid mô tả rõ | dễ đọc lại sau nhiều tháng |

Và thứ tự xét đầy đủ khi có nhiều tầng:

Organizations SCP → Resource policy → Identity policy
    → Permissions boundary → Session policy
        ↓
    Một tầng Deny là toàn bộ bị từ chối

Ba công cụ kiểm tra chính sách: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử một hành động, xem statement nào quyết định | | IAM Access Analyzer policy validation | phát hiện lỗi cú pháp và quyền quá rộng | | CloudTrail | xem lời gọi thật bị từ chối vì lý do gì |

Và một lời khuyên khi đọc chính sách trong đề thi: hãy đọc Effect và toán tử điều kiện trước tiên. Cặp Deny + StringNotEquals đọc thoáng qua rất giống Allow + StringEquals, và đó là chỗ ra đề thường đặt bẫy — đọc ngược một chữ là chọn sai cả câu.

Câu 472 Design High-Performing Architectures

A Hollywood studio is planning a series of promotional events leading up to the launch of the trailer of its next sci-fi thriller. The executives at the studio want to create a static website with lots of animations in line with the theme of the movie. The studio has hired you as a solutions architect to build a scalable serverless solution.

Which of the following represents the MOST cost-optimal and high-performance solution?

  1. A

    Host the website on an instance in the studio's on-premises data center. Create an Amazon CloudFront distribution with this instance as the custom origin
  2. B

    Host the website on an Amazon EC2 instance. Create a Amazon CloudFront distribution with the Amazon EC2 instance as the custom origin
  3. C

    Host the website on AWS Lambda. Create an Amazon CloudFront distribution with Lambda as the origin
  4. D

    Build the website as a static website hosted on Amazon S3. Create an Amazon CloudFront distribution with Amazon S3 as the origin. Use Amazon Route 53 to create an alias record that points to your Amazon CloudFront distribution
Xem giải thích

Đáp án

D — Xây website tĩnh lưu trên Amazon S3, tạo CloudFront distribution với S3 làm origin, và dùng Route 53 alias record trỏ tới distribution.

Vì sao đúng

Đề nêu ba yêu cầu, và đáp án là lựa chọn duy nhất thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Website TĨNH | S3 static website hosting | | Không máy chủ (serverless) | S3 + CloudFront + Route 53, không có máy nào | | Tiết kiệm nhất và hiệu năng cao | S3 rẻ nhất, CloudFront đệm ở biên |

Vì sao S3 là lựa chọn tối ưu cho nội dung tĩnh:

S3 static website:
    ✓ ~0,023 USD/GB lưu trữ — không có chi phí máy chủ
    ✓ độ bền 11 số 9
    ✓ mở rộng vô hạn, không cần cấu hình gì
    ✓ KHÔNG có gì để vá lỗi hay giám sát

Và CloudFront giải quyết vế hiệu năng:

Nội dung nhiều hoạt hình (ảnh, video, JS, CSS)
    → đệm ở hơn 600 điểm biên toàn cầu
    → người xem tải từ điểm gần nhất
    → giảm phí truyền dữ liệu so với gọi thẳng S3

Route 53 alias record là chi tiết đáng chú ý: | | Alias record | CNAME | |---|---|---| | Dùng ở ĐỈNH tên miền (phim.com) | ✅ | ❌ không được | | Chi phí truy vấn | MIỄN PHÍ khi trỏ tới tài nguyên AWS | tính phí | | Tự cập nhật khi IP đích đổi | ✅ | ✅ |

Cấu hình:

aws s3 website s3://trang-phim --index-document index.html --error-document 404.html

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"phim.com","Type":"A",
    "AliasTarget":{"HostedZoneId":"Z2FDTNDATAQYW2",
                   "DNSName":"d123abc.cloudfront.net",
                   "EvaluateTargetHealth":false}}}]}'

Z2FDTNDATAQYW2 là hosted zone id CỐ ĐỊNH của CloudFront — giống nhau cho mọi distribution.

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

  • **B. Đặt website trên EC2 instance, CloudFront với EC2 làm custom origin — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó vi phạm yêu cầu serverless và đắt hơn nhiều: bạn phải trả tiền EC2 chạy 24/7, vá lỗi hệ điều hành, cấu hình web server, và lo sẵn sàng cao — tất cả chỉ để phục vụ tệp tĩnh.
  • **A. Đặt website trên máy chủ TẠI CHỖ, CloudFront với máy đó làm custom origin — đi ngược hoàn toàn: nó giữ lại toàn bộ gánh nặng hạ tầng, và trung tâm dữ liệu của studio trở thành điểm hỏng duy nhất cho một chiến dịch quảng bá toàn cầu.
  • **C. Đặt website trên AWS Lambda, CloudFront với Lambda làm origin — sai công cụ: Lambda thực thi mã, không phải nơi lưu tệp tĩnh. Phục vụ ảnh và video qua Lambda vừa đắt vừa chậm hơn S3, và mỗi request đều tính tiền thực thi.

Ghi nhớ

Kiến trúc chuẩn cho website tĩnh trên AWS:

Người dùng
    ↓ DNS
Route 53 (alias record)
    ↓
CloudFront (đệm ở biên, TLS, WAF)
    ↓ Origin Access Control
S3 bucket (nội dung tĩnh, KHÔNG công khai)

Ba lợi ích của việc đặt CloudFront trước S3: | Lợi ích | Chi tiết | |---|---| | Hiệu năng | đệm gần người dùng | | Chi phí | truyền từ CloudFront RẺ HƠN từ S3 | | Bảo mật | HTTPS, WAF, và khoá bucket lại bằng OAC |

Origin Access Control khoá bucket không cho truy cập trực tiếp:

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

OAC thay thế OAI (đã lỗi thời) — nó hỗ trợ SSE-KMS và mọi Region.

Lưu ý quan trọng: dùng OAC thì KHÔNG bật S3 static website hosting.

S3 static website endpoint: HTTP công khai, không dùng được OAC
S3 REST API endpoint:       dùng được OAC, bucket riêng tư hoàn toàn
    ↓
    Với OAC, dùng CloudFront Functions để xử lý
    trang mặc định của thư mục con

Ba cấu hình CloudFront cho website tĩnh: | Cấu hình | Chi tiết | |---|---| | Default root object = index.html | truy cập tên miền gốc | | Custom error response 403/404 → index.html | cần cho ứng dụng một trang (SPA) | | Compress objects automatically | Gzip và Brotli |

Ba cách tối ưu cho nội dung nhiều hoạt hình: | Cách | Lợi ích | |---|---| | Đặt mã băm nội dung vào tên tệp | TTL rất dài mà vẫn cập nhật ngay khi đổi | | Nén video và dùng định dạng hiện đại | WebP, AVIF cho ảnh | | Lazy loading | chỉ tải khi cuộn tới |

Mẫu tên tệp có mã băm:

hoat-hinh.a1b2c3d4.js  → TTL 1 năm, không bao giờ phải invalidate
index.html             → TTL ngắn, trỏ tới tệp có mã băm mới

Cách này loại bỏ hẳn nhu cầu invalidation — vốn tốn phí và mất thời gian lan truyền.

Ba lưu ý về chứng chỉ TLS: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ACM cho CloudFront PHẢI ở us-east-1 | yêu cầu bắt buộc | | ACM cấp miễn phí và tự gia hạn | | | Cần xác minh sở hữu tên miền | qua DNS hoặc email |

Dòng đầu là lỗi triển khai hay gặp nhất — chứng chỉ tạo ở Region khác không hiện ra trong danh sách chọn của CloudFront.

Ba lựa chọn khác cho website tĩnh: | Lựa chọn | Đặc điểm | |---|---| | S3 + CloudFront | linh hoạt nhất, kiểm soát đầy đủ ← câu này | | AWS Amplify Hosting | tích hợp CI/CD từ git, đơn giản hơn | | S3 website endpoint đơn thuần | chỉ HTTP, không tên miền tuỳ chỉnh có TLS |

Amplify Hosting đáng cân nhắc cho chiến dịch ngắn hạn:

Amplify:
    ✓ nối thẳng với repo git, tự build và triển khai
    ✓ CDN, TLS, tên miền tuỳ chỉnh dựng sẵn
    ✓ môi trường xem trước cho mỗi nhánh

Với studio cần dựng nhanh nhiều trang quảng bá, đó là lựa chọn ít công hơn nữa.

Ba khoản chi phí của kiến trúc này: | Khoản | Giá tham khảo | |---|---| | Lưu trữ S3 | ~0,023 USD/GB-tháng | | Truyền từ CloudFront | ~0,085 USD/GB (có 1 TB miễn phí mỗi tháng) | | Request CloudFront | ~0,0075 USD/10.000 | | Route 53 hosted zone | 0,50 USD/tháng |

Và AWS Free Tier cho CloudFront khá rộng — 1 TB truyền và 10 triệu request mỗi tháng, đủ cho phần lớn chiến dịch quảng bá quy mô vừa.

Và một lời khuyên: hãy bật CloudFront access log và Real-time logs cho chiến dịch quảng bá. Studio sẽ muốn biết trailer được xem bao nhiêu lần, từ đâu, và vào lúc nào — thông tin đó nằm sẵn trong log và không cần thêm hạ tầng nào để thu thập.

Câu 473 Design Secure Architectures

To improve the performance and security of the application, the engineering team at a company has created an Amazon CloudFront distribution with an Application Load Balancer as the custom origin. The team has also set up an AWS Web Application Firewall (AWS WAF) with Amazon CloudFront distribution. The security team at the company has noticed a surge in malicious attacks from a specific IP address to steal sensitive data stored on the Amazon EC2 instances.

As a solutions architect, which of the following actions would you recommend to stop the attacks?

  1. A

    Create a deny rule for the malicious IP in the Security Groups associated with each of the instances
  2. B

    Create an IP match condition in the AWS WAF to block the malicious IP address
  3. C

    Create a deny rule for the malicious IP in the network access control list (network ACL) associated with each of the instances
  4. D

    Create a ticket with AWS support to take action against the malicious IP
Xem giải thích

Đáp án

B — Tạo IP match condition trong AWS WAF để chặn địa chỉ IP độc hại.

Vì sao đúng

Điểm mấu chốt nằm ở kiến trúc lưu lượng:

Người dùng → CloudFront (có WAF) → ALB → EC2
    ↑
    Điểm vào duy nhất là CloudFront

Và WAF đã được cấu hình sẵn trên CloudFront:

WAF nằm ở ĐIỂM BIÊN, trước mọi thứ khác
    → chặn ở đây thì lưu lượng độc hại KHÔNG BAO GIỜ tới ALB hay EC2
    → tiết kiệm băng thông và tài nguyên
    → chỉ cần thêm một quy tắc, không đụng hạ tầng

Cấu hình IP set và quy tắc chặn:

aws wafv2 create-ip-set --name ip-doc-hai --scope CLOUDFRONT   --region us-east-1 --ip-address-version IPV4   --addresses 203.0.113.45/32

{"Name": "chan-ip-doc-hai", "Priority": 0,
 "Action": {"Block": {}},
 "Statement": {"IPSetReferenceStatement": {"ARN": "<arn-ip-set>"}},
 "VisibilityConfig": {"SampledRequestsEnabled": true,
   "CloudWatchMetricsEnabled": true, "MetricName": "chanIpDocHai"}}

Và cập nhật IP set không cần triển khai lại gì:

aws wafv2 update-ip-set --name ip-doc-hai --scope CLOUDFRONT   --region us-east-1 --id <id> --lock-token <token>   --addresses 203.0.113.45/32 198.51.100.77/32

Có hiệu lực trong vài phút trên toàn bộ mạng biên.

Lưu ý: WAF cho CloudFront phải tạo ở us-east-1 với scope CLOUDFRONT — đây là ràng buộc bắt buộc.

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

  • **C. Tạo quy tắc deny cho IP độc hại trong network ACL của từng instance — đây là phương án gần nhất và NACL thực sự có quy tắc Deny theo IP (khác security group), nhưng nó không hoạt động trong kiến trúc này: lưu lượng tới EC2 đến từ ALB, không phải từ IP của kẻ tấn công. NACL sẽ chỉ thấy IP của ALB. Và nó cũng không chặn được ở tầng biên — lưu lượng độc hại vẫn tiêu tốn băng thông của CloudFront và ALB.
  • **A. Tạo quy tắc deny trong security group — không làm được về mặt kỹ thuật: security group CHỈ có quy tắc Allow, không có Deny. Và cùng vấn đề: security group của EC2 chỉ thấy IP của ALB.
  • **D. Mở ticket với AWS Support để xử lý IP độc hại — quá chậm và không phải quy trình đúng: bạn có công cụ trong tay để chặn ngay lập tức. AWS Support không chặn IP thay bạn.

Ghi nhớ

Bốn tầng lọc lưu lượng — bảng cần thuộc: | Tầng | Cơ chế | Có Deny | Trạng thái | |---|---|---|---| | AWS WAF | tầng 7, ở biên hoặc ALB | ✅ | — | | Network ACL | tầng 3/4, cấp SUBNET | ✅ | stateless | | Security group | tầng 3/4, cấp ENI | ❌ chỉ Allow | stateful | | AWS Shield | chống DDoS | tự động | — |

Security group và NACL — bảng phân biệt: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI (instance) | SUBNET | | Quy tắc | CHỈ Allow | Allow và Deny | | Trạng thái | stateful — trả lời tự động được phép | stateless — phải mở CẢ HAI chiều | | Đánh giá | mọi quy tắc | theo SỐ THỨ TỰ, dừng ở quy tắc đầu khớp | | Tham chiếu security group khác | ✅ | ❌ chỉ CIDR |

Hai dòng cuối là điểm hay bị hỏi: NACL stateless nghĩa là mở cổng 443 vào thì cũng phải mở dải cổng tạm thời (1024–65535) ra, nếu không phản hồi bị chặn.

Và WAF gắn được vào đâu: | Tài nguyên | Scope | Region của Web ACL | |---|---|---| | CloudFront | CLOUDFRONT | BẮT BUỘC us-east-1 | | ALB | REGIONAL | cùng Region với ALB | | API Gateway REST API | REGIONAL | cùng Region | | AppSync, Cognito user pool | REGIONAL | cùng Region | | Network Load Balancer | ❌ không hỗ trợ | — |

Sáu loại statement của WAF: | Statement | Khớp theo | |---|---| | IPSetReferenceStatement | danh sách IP hoặc CIDR ← câu này | | GeoMatchStatement | quốc gia | | RateBasedStatement | số request từ một IP trong 5 phút | | ByteMatchStatement | chuỗi trong header, URI, body | | SqliMatchStatement / XssMatchStatement | SQL injection và XSS | | LabelMatchStatement | nhãn do quy tắc khác gắn |

Rate-based rule là bổ sung quan trọng cho tình huống này:

{"Name": "gioi-han-tan-suat", "Priority": 1,
 "Action": {"Block": {}},
 "Statement": {"RateBasedStatement": {
   "Limit": 2000, "AggregateKeyType": "IP"}}}

Nó tự chặn mọi IP vượt ngưỡng — không phải chờ ai đó phát hiện và thêm vào danh sách bằng tay.

Ba Managed Rule Group nên bật: | Nhóm | Bảo vệ khỏi | |---|---| | AWSManagedRulesCommonRuleSet | OWASP Top 10 cơ bản | | AWSManagedRulesKnownBadInputsRuleSet | payload tấn công đã biết | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu — tự cập nhật | | AWSManagedRulesSQLiRuleSet | SQL injection |

Nhóm thứ ba đặc biệt phù hợp: nó chặn tự động các IP mà AWS đã biết là nguồn tấn công, mà không cần bạn theo dõi từng địa chỉ.

Ba hành động của WAF: | Hành động | Chi tiết | |---|---| | Block | trả về 403, tuỳ chỉnh được nội dung | | Allow | cho qua | | Count | chỉ ĐẾM — dùng để thử nghiệm trước | | CAPTCHA / Challenge | phân biệt người và bot |

Ba việc nên làm khi bị tấn công từ một IP: | Việc | Chi tiết | |---|---| | Chặn IP đó trong WAF ngay | ← câu này | | Bật rate-based rule | chống kẻ tấn công đổi IP | | Xem log WAF để tìm mẫu chung | user-agent, đường dẫn, header |

Và log WAF là công cụ điều tra quan trọng:

aws wafv2 put-logging-configuration --logging-configuration   '{"ResourceArn":"<arn-web-acl>",
    "LogDestinationConfigs":["<arn-firehose-hoac-log-group>"]}'

Nó ghi đầy đủ header, đường dẫn và quy tắc nào đã khớp — thường cho thấy kẻ tấn công dùng một user-agent hoặc mẫu URL đặc trưng, và chặn theo đó hiệu quả hơn chặn từng IP.

Ba lưu ý về AWS Shield: | Mức | Chi tiết | |---|---| | Shield Standard | MIỄN PHÍ, tự động, chống DDoS tầng 3/4 | | Shield Advanced | 3.000 USD/tháng, có đội ứng phó và bảo vệ chi phí | | Tự động | không cần bật gì với Standard |

Và một lời khuyên: hãy chuyển từ chặn từng IP sang rate-based rule càng sớm càng tốt. Kẻ tấn công có tổ chức sẽ đổi IP liên tục, và danh sách chặn thủ công luôn chậm hơn họ một bước — quy tắc theo tần suất thì tự thích ứng mà không cần ai can thiệp.

Câu 474 Chọn nhiều đáp án Design Resilient Architectures

A financial services company runs a Kubernetes-based microservices application in its on-premises data center. The application uses the Advanced Message Queuing Protocol (AMQP) to interact with a message queue. The company is experiencing rapid growth and its on-prem infrastructure cannot scale fast enough. The company wants to migrate the application to AWS with minimal code changes and reduce infrastructure management overhead. The messaging component must continue using AMQP, and the solution should offer high scalability and low operational effort.

Which combination of options will together meet these requirements? (Select two)

  1. A

    Use Amazon Simple Queue Service (Amazon SQS) as the replacement for the AMQP message broker. Refactor the application to use SQS SDKs and polling logic
  2. B

    Deploy the containerized application to Amazon Elastic Kubernetes Service (Amazon EKS) using AWS Fargate to avoid managing EC2 nodes
  3. C

    Replace the current messaging system with Amazon MQ, a fully managed broker that supports AMQP natively. Integrate the application with the Amazon MQ endpoint without modifying the existing message format
  4. D

    Run the application on Amazon EC2 Auto Scaling groups and use a self-hosted RabbitMQ instance on EC2 to preserve AMQP compatibility
  5. E

    Deploy the application to Amazon ECS on EC2, and integrate the messaging workflow using Amazon SNS for asynchronous pub/sub delivery
Xem giải thích

Đáp án

B và C.

  • B — Triển khai ứng dụng container lên Amazon EKS với AWS Fargate để khỏi quản lý EC2 node
  • C — Thay hệ thống nhắn tin bằng Amazon MQ — broker được quản lý, hỗ trợ AMQP nguyên bản

Vì sao đúng

Đề nêu bốn ràng buộc, và hai đáp án chia nhau giải quyết đủ: | Ràng buộc | Giải pháp | |---|---| | Ứng dụng Kubernetes, ÍT thay đổi mã | EKS — cùng manifest, cùng công cụ | | PHẢI tiếp tục dùng AMQP | Amazon MQ hỗ trợ AMQP 0-9-1 nguyên bản | | Mở rộng nhanh | EKS + Fargate tự co giãn | | Ít công quản lý hạ tầng | Fargate không có EC2 node, MQ được quản lý |

C — Amazon MQ là mấu chốt của vế "giữ AMQP":

Amazon MQ hỗ trợ hai engine:
    ✓ Apache ActiveMQ  — AMQP, MQTT, OpenWire, STOMP, JMS
    ✓ RabbitMQ         — AMQP 0-9-1 (chuẩn công nghiệp)
        ↓
    Ứng dụng chỉ đổi CHUỖI KẾT NỐI
    → không sửa mã, không đổi định dạng thông điệp

Và đó chính là điều SQS không làm được:

SQS dùng API RIÊNG của AWS (HTTPS)
    → không nói được AMQP
    → phải VIẾT LẠI toàn bộ phần nhắn tin
        ↓
    Trái với yêu cầu "minimal code changes"

B — EKS với Fargate giữ nguyên khoản đầu tư vào Kubernetes:

Ứng dụng đã chạy trên Kubernetes tại chỗ
    → EKS dùng CÙNG manifest, CÙNG kubectl, CÙNG Helm chart
    → Fargate loại bỏ việc quản lý node
        ↓
    Di chuyển gần như nguyên trạng

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: cum-vi-dich-vu
  region: ap-northeast-1
fargateProfiles:
  - name: mac-dinh
    selectors:
      - namespace: ung-dung

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

  • **A. Dùng SQS thay broker AMQP, tái cấu trúc ứng dụng để dùng SDK và logic polling của SQS — đây là phương án gần nhất vì SQS thực sự là dịch vụ hàng đợi được quản lý và mở rộng tốt hơn, nhưng nó vi phạm ràng buộc rõ ràng nhất: đề nêu "must continue using AMQP" và "minimal code changes". Viết lại toàn bộ tầng nhắn tin là thay đổi lớn.
  • **D. Chạy ứng dụng trên EC2 Auto Scaling với RabbitMQ TỰ CÀI trên EC2 — giữ được AMQP nhưng vi phạm vế công vận hành: bạn phải tự cài, vá lỗi, dựng cụm, cấu hình sao chép và sao lưu cho RabbitMQ — đúng gánh nặng mà công ty muốn bỏ.
  • **E. ECS trên EC2 với SNS cho pub/sub — hai lỗi: SNS không hỗ trợ AMQP, và ECS trên EC2 vẫn phải quản lý node. Ngoài ra, chuyển từ Kubernetes sang ECS là thay đổi lớn về công cụ và quy trình.

Ghi nhớ

Bốn dịch vụ nhắn tin của AWS — bảng cần thuộc: | Dịch vụ | Giao thức | Phù hợp | |---|---|---| | Amazon MQ | AMQP, MQTT, STOMP, OpenWire, JMS | DI CHUYỂN ứng dụng dùng broker chuẩn ← câu này | | Amazon SQS | API riêng của AWS (HTTPS) | ứng dụng mới trên đám mây | | Amazon SNS | API riêng | phát tán thông báo | | Amazon MSK | Kafka | luồng sự kiện quy mô lớn |

Quy tắc nhận diện — rất hay được hỏi:

"existing app uses AMQP/JMS/MQTT/STOMP", "lift and shift", "minimal code change" → Amazon MQ "cloud-native", "new application", "unlimited scale" → SQS "Apache Kafka" → Amazon MSK

Amazon MQ và SQS — bảng phân biệt: | | Amazon MQ | SQS | |---|---|---| | Giao thức chuẩn ngành | ✅ | ❌ | | Mở rộng | giới hạn bởi cỡ broker | gần như vô hạn | | Cần chọn cỡ instance | ✅ có | ❌ không | | Nằm trong VPC | ✅ | ❌ (endpoint công khai) | | Chi phí | theo giờ broker | theo request |

Đánh đổi quan trọng: Amazon MQ dễ di chuyển nhưng không mở rộng vô hạn như SQS — nó vẫn là broker chạy trên instance có kích thước cụ thể. Với công ty đang tăng trưởng nhanh, cần theo dõi và nâng cỡ broker.

Hai engine của Amazon MQ: | Engine | Đặc điểm | |---|---| | RabbitMQ | AMQP 0-9-1, phổ biến nhất, có cụm | | ActiveMQ | nhiều giao thức hơn, hỗ trợ JMS đầy đủ |

Ba kiểu triển khai của Amazon MQ: | Kiểu | Sẵn sàng | |---|---| | Single-instance | không chịu lỗi — chỉ cho dev | | Active/standby (ActiveMQ) | hai AZ, tự chuyển đổi | | Cluster deployment (RabbitMQ) | ba node qua ba AZ |

Với dịch vụ tài chính, cluster ba node là lựa chọn đúng.

Ba chế độ tính toán của EKS: | Chế độ | Bạn quản lý | |---|---| | Managed node group | AWS quản lý vòng đời EC2, bạn vẫn thấy máy | | Self-managed node | bạn quản lý mọi thứ | | Fargate | KHÔNG có node nào — mỗi Pod có tài nguyên riêng ← câu này | | EKS Auto Mode | AWS tự quản lý toàn bộ tính toán |

Ba hạn chế của EKS trên Fargate cần biết: | Hạn chế | Chi tiết | |---|---| | Không hỗ trợ DaemonSet | công cụ giám sát phải chạy kiểu sidecar | | Không dùng được GPU | | | Không mount hostPath hay EBS | chỉ EFS | | Giới hạn tài nguyên | tối đa 16 vCPU, 120 GB |

Dòng thứ nhất đáng lưu ý: nhiều công cụ giám sát và ghi log chạy dạng DaemonSet, và trên Fargate phải đổi cách triển khai.

Ba bước di chuyển Kubernetes từ tại chỗ lên EKS:

① Đẩy image lên Amazon ECR
② Áp lại manifest lên cụm EKS (thường gần như nguyên vẹn)
③ Đổi chuỗi kết nối tới Amazon MQ, RDS, ElastiCache

Ba thứ cần điều chỉnh khi di chuyển: | Thứ | Chi tiết | |---|---| | StorageClass | đổi sang EBS CSI hoặc EFS CSI | | Ingress | đổi sang AWS Load Balancer Controller | | Cấp quyền AWS cho Pod | IRSA hoặc EKS Pod Identity |

Ba biện pháp bảo mật cho dịch vụ tài chính: | Biện pháp | Chi tiết | |---|---| | Amazon MQ trong private subnet | không phơi broker ra Internet | | Mã hoá at rest và in transit | KMS + TLS cho AMQP | | Thông tin đăng nhập trong Secrets Manager | không nhúng trong manifest |

Và Secrets Manager tích hợp với EKS qua CSI driver:

volumes:
  - name: bi-mat
    csi:
      driver: secrets-store.csi.k8s.io
      volumeAttributes:
        secretProviderClass: mq-credentials

Ba metric cần theo dõi cho Amazon MQ: | Metric | Ý nghĩa | |---|---| | QueueSize | thông điệp tồn đọng — consumer không kịp | | CpuUtilization của broker | cần nâng cỡ khi cao | | ChannelCount, ConnectionCount | gần trần thì phải xử lý |

Và một lời khuyên về lộ trình: hãy coi Amazon MQ là bước trung gian, không phải đích cuối. Nó cho phép di chuyển lên đám mây mà không viết lại mã, nhưng nếu tăng trưởng tiếp tục thì SQS hoặc MSK sẽ mở rộng tốt hơn — và chuyển đổi dần từng dịch vụ sau khi đã lên đám mây dễ hơn nhiều so với làm hai việc cùng lúc.

Câu 475 Design Secure Architectures

Which of the following IAM policies provides read-only access to the Amazon S3 bucket mybucket and its content?

  1. A 
    {
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListBucket",
            "s3:GetObject"
         ],
         "Resource":"arn:aws:s3:::mybucket"
      }
   ]
}
  2. B 
    {
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListBucket"
         ],
         "Resource":"arn:aws:s3:::mybucket/*"
      },
      {
         "Effect":"Allow",
         "Action":[
            "s3:GetObject"
         ],
         "Resource":"arn:aws:s3:::mybucket"
      }
   ]
}
  3. C 
    {
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListBucket"
         ],
         "Resource":"arn:aws:s3:::mybucket"
      },
      {
         "Effect":"Allow",
         "Action":[
            "s3:GetObject"
         ],
         "Resource":"arn:aws:s3:::mybucket/*"
      }
   ]
}
  4. D 
    {
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListBucket",
            "s3:GetObject"
         ],
         "Resource":"arn:aws:s3:::mybucket/*"
      }
   ]
}
Xem giải thích

Đáp án

C — Chính sách có hai statement: s3:ListBucket trên arn:aws:s3:::mybucket, và s3:GetObject trên arn:aws:s3:::mybucket/*.

Vì sao đúng

Điểm mấu chốt: hai loại hành động của S3 áp cho hai loại ARN khác nhau.

Bảng phân biệt — nội dung cốt lõi của câu hỏi: | Hành động | Áp cho | ARN | |---|---|---| | s3:ListBucket | BUCKET | arn:aws:s3:::mybucket | | s3:GetObject | OBJECT | arn:aws:s3:::mybucket/* |

Vì sao chúng khác nhau:

ListBucket = "liệt kê nội dung của bucket"
    → thao tác trên chính BUCKET
    → ARN không có phần object

GetObject = "tải một object cụ thể"
    → thao tác trên OBJECT bên trong bucket
    → ARN phải có `/*` để chỉ mọi object

Chính sách đúng đầy đủ:

{"Version": "2012-10-17",
 "Statement": [
   {"Effect": "Allow",
    "Action": ["s3:ListBucket"],
    "Resource": "arn:aws:s3:::mybucket"},
   {"Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::mybucket/*"}]}

Và hậu quả của việc ghép sai:

ListBucket trên "mybucket/*"
    → KHÔNG BAO GIỜ khớp (bucket ARN không có phần sau dấu /)
    → không liệt kê được nội dung

GetObject trên "mybucket"
    → KHÔNG BAO GIỜ khớp (object ARN luôn có phần sau dấu /)
    → không tải được tệp nào

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

  • **D. Cả hai hành động trên arn:aws:s3:::mybucket/* — đây là phương án gần nhất và vế GetObject đúng, nhưng ListBucket trên ARN có /* không bao giờ khớp: người dùng tải được tệp nếu biết chính xác tên, nhưng không liệt kê được bucket — nhận AccessDenied khi chạy aws s3 ls.
  • **A. Cả hai hành động trên arn:aws:s3:::mybucket — ngược lại: liệt kê được nhưng không tải được object nào.
  • **B. ListBucket trên mybucket/* và GetObject trên mybucket — đảo ngược cả hai, nên không hành động nào hoạt động.

Ghi nhớ

Hai loại ARN của S3 — phải thuộc:

Bucket: arn:aws:s3:::ten-bucket
Object: arn:aws:s3:::ten-bucket/duong-dan/tep.txt
        arn:aws:s3:::ten-bucket/*          (mọi object)
        arn:aws:s3:::ten-bucket/anh/*      (object trong một prefix)

Lưu ý: ARN của S3 KHÔNG có phần Region và tài khoản — ba dấu hai chấm liên tiếp.

Bảng hành động S3 và loại ARN: | Hành động | ARN loại | |---|---| | s3:ListBucket | BUCKET | | s3:ListBucketVersions | BUCKET | | s3:GetBucketLocation | BUCKET | | s3:GetBucketPolicy | BUCKET | | s3:GetObject | OBJECT | | s3:PutObject | OBJECT | | s3:DeleteObject | OBJECT | | s3:GetObjectVersion | OBJECT |

Mẹo nhận diện: tên hành động có chữ "Bucket" → ARN bucket; có chữ "Object" → ARN object.

Và s3:ListBucket cần cả cho việc kiểm tra tồn tại:

aws s3 ls s3://mybucket/          → cần ListBucket
aws s3 cp s3://mybucket/a.txt .   → cần GetObject
aws s3 sync s3://mybucket/ ./     → cần CẢ HAI

Thiếu ListBucket thì sync và ls thất bại dù tải từng tệp vẫn được.

Ba chính sách quản lý sẵn hay dùng cho S3: | Chính sách | Quyền | |---|---| | AmazonS3ReadOnlyAccess | đọc MỌI bucket | | AmazonS3FullAccess | toàn quyền MỌI bucket | | Tự viết | giới hạn tới bucket cụ thể ← nên dùng |

Và giới hạn tới một prefix cần thêm điều kiện:

{"Effect": "Allow", "Action": "s3:ListBucket",
 "Resource": "arn:aws:s3:::mybucket",
 "Condition": {"StringLike": {"s3:prefix": ["du-lieu/*"]}}},
{"Effect": "Allow", "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::mybucket/du-lieu/*"}

Điều kiện s3:prefix là cách giới hạn ListBucket xuống một thư mục — vì ARN bucket không diễn đạt được prefix.

Ba khoá điều kiện riêng của S3: | Khoá | Việc | |---|---| | s3:prefix | giới hạn ListBucket theo thư mục | | s3:x-amz-server-side-encryption | bắt buộc mã hoá khi ghi | | s3:x-amz-acl | giới hạn ACL được đặt | | s3:max-keys | giới hạn số kết quả liệt kê |

Ba nguyên tắc viết chính sách S3: | Nguyên tắc | Chi tiết | |---|---| | Không dùng Resource: "*" | giới hạn tới bucket cụ thể | | Tách statement theo loại ARN | ← điểm của câu này | | Chỉ cấp hành động thật sự cần | đọc thì không cần s3:* |

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử s3:ListBucket và s3:GetObject riêng | | IAM Access Analyzer policy validation | cảnh báo ARN không khớp hành động | | CloudTrail | xem lời gọi bị từ chối |

Và Access Analyzer thực sự bắt được lỗi của câu này:

Cảnh báo: "The action s3:ListBucket does not support
           an ARN with an object path"

Nên chạy validation trước khi áp chính sách — nó bắt đúng loại lỗi mà mắt người dễ bỏ qua.

Ba lưu ý về quyền S3 xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | Cần CẢ identity policy LẪN bucket policy | khác với cùng tài khoản | | Bucket mã hoá KMS cần thêm quyền kms:Decrypt | và key policy phải cho phép | | Object do tài khoản khác ghi vào | bật BucketOwnerEnforced |

Và một lời khuyên: hãy kiểm chứng bằng lệnh thật sau khi áp chính sách. Chạy aws s3 ls s3://mybucket/ và aws s3 cp s3://mybucket/mot-tep.txt . — hai lệnh này kiểm tra hai quyền khác nhau, và chính sách sai theo kiểu của câu hỏi này sẽ cho một lệnh chạy được còn lệnh kia thất bại, thay vì hỏng hoàn toàn.

Câu 476 Design Secure Architectures

A health-care solutions company wants to run their applications on single-tenant hardware to meet regulatory guidelines.

Which of the following is the MOST cost-effective way of isolating their Amazon Elastic Compute Cloud (Amazon EC2)instances to a single tenant?

  1. A

    Spot Instances
  2. B

    Dedicated Hosts
  3. C

    Dedicated Instances
  4. D

    On-Demand Instances
Xem giải thích

Đáp án

C — Dedicated Instances.

Vì sao đúng

Đề nêu hai yêu cầu, và Dedicated Instances thoả cả hai: | Yêu cầu | Cơ chế | |---|---| | Phần cứng ĐƠN THUÊ (single-tenant) | Dedicated Instances chạy trên phần cứng chỉ của bạn | | TIẾT KIỆM NHẤT | rẻ hơn Dedicated Hosts đáng kể |

Dedicated Instances và Dedicated Hosts đều cho phần cứng đơn thuê, nhưng khác nhau về chi phí:

Dedicated Instances:
    → trả thêm phụ phí trên giá instance
    → cộng 2 USD/giờ cho mỗi Region đang dùng
    → KHÔNG trả tiền cho phần cứng không dùng

Dedicated Hosts:
    → trả tiền cho CẢ MÁY CHỦ VẬT LÝ theo giờ
    → trả đủ dù chỉ chạy một instance nhỏ

Ví dụ minh hoạ:

Cần 3 instance m5.large đơn thuê:

Dedicated Instances:
    3 × giá m5.large + phụ phí Region
    → trả đúng phần dùng

Dedicated Host cho họ m5:
    → trả giá CẢ MÁY CHỦ (chứa được hàng chục instance)
    → dùng 3 instance thì lãng phí phần lớn

Và Dedicated Instances đáp ứng đủ yêu cầu tuân thủ về đơn thuê:

"single-tenant hardware to meet regulatory guidelines"
    ↓
    → phần cứng không chia sẻ với khách hàng AWS khác
    → Dedicated Instances đảm bảo điều đó

Cách bật:

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

Hoặc đặt ở cấp VPC để mọi instance trong đó đều đơn thuê:

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

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

  • **B. Dedicated Hosts — đây là phương án gần nhất và cũng cho phần cứng đơn thuê, nhưng nó đắt hơn cho tình huống này: bạn trả tiền cho cả máy chủ vật lý. Dedicated Hosts chỉ đáng khi bạn cần thấy và kiểm soát máy chủ vật lý — cho giấy phép phần mềm tính theo lõi hoặc socket (Windows Server, Oracle, SQL Server BYOL).
  • **A. Spot Instances — không đảm bảo đơn thuê: Spot chạy trên phần cứng dùng chung, và còn bị thu hồi bất cứ lúc nào — không phù hợp với ứng dụng y tế.
  • **D. On-Demand Instances — mặc định là phần cứng DÙNG CHUNG (shared tenancy), không đáp ứng yêu cầu về đơn thuê.

Ghi nhớ

Ba mô hình thuê phần cứng của EC2 — bảng phải thuộc: | Mô hình | Phần cứng | Thấy máy chủ vật lý | Chi phí | |---|---|---|---| | Shared (mặc định) | dùng chung với khách hàng khác | ❌ | thấp nhất | | Dedicated Instance | CHỈ của bạn | ❌ không kiểm soát vị trí | trung bình ← câu này | | Dedicated Host | CHỈ của bạn | ✅ thấy socket và lõi vật lý | cao nhất |

Khi nào phải dùng Dedicated Host thay vì Dedicated Instance: | Trường hợp | Lý do | |---|---| | Giấy phép BYOL tính theo LÕI hoặc SOCKET vật lý | cần biết số lõi để tuân thủ giấy phép | | Cần đặt instance lên đúng một máy chủ cụ thể | ái lực máy chủ (host affinity) | | Yêu cầu tuân thủ đòi kiểm soát vị trí vật lý | |

Với ứng dụng y tế chỉ cần "single-tenant hardware", Dedicated Instance là đủ.

Ba khác biệt kỹ thuật: | | Dedicated Instance | Dedicated Host | |---|---|---| | Sau khi stop/start | có thể chuyển sang máy chủ vật lý KHÁC | có thể giữ nguyên máy (affinity) | | Thấy socket và lõi | ❌ | ✅ | | Dùng cho BYOL | ❌ | ✅ | | Tính phí | phụ phí theo Region | theo máy chủ, theo giờ |

Ba cách bật Dedicated Instance: | Cách | Chi tiết | |---|---| | --placement Tenancy=dedicated lúc chạy instance | từng instance | | --instance-tenancy dedicated lúc tạo VPC | mọi instance trong VPC đó | | Trong launch template | áp cho ASG |

Lưu ý về tenancy của VPC:

VPC có instance-tenancy = dedicated:
    → MỌI instance trong đó đều đơn thuê
    → KHÔNG đổi ngược về default được sau khi tạo VPC
        ↓
    → Cân nhắc kỹ, và tách VPC riêng cho tải cần đơn thuê

Ba lưu ý về chi phí Dedicated Instance: | Lưu ý | Chi tiết | |---|---| | Phụ phí ~2 USD/giờ mỗi Region | tính MỘT LẦN dù chạy bao nhiêu instance | | Giá instance cao hơn shared khoảng 10% | | | Có RI và Savings Plans cho Dedicated | giảm giá vẫn áp dụng |

Dòng đầu quan trọng: phụ phí là cố định theo Region, nên chạy càng nhiều instance đơn thuê thì chi phí trung bình mỗi máy càng giảm.

Ba yêu cầu tuân thủ hay đòi đơn thuê: | Yêu cầu | Ngành | |---|---| | HIPAA | y tế ← câu này | | PCI-DSS | thanh toán | | Quy định về chủ quyền dữ liệu | chính phủ |

Lưu ý: HIPAA KHÔNG bắt buộc phần cứng đơn thuê — AWS ký BAA và hỗ trợ HIPAA trên hạ tầng dùng chung. Đơn thuê thường xuất phát từ chính sách nội bộ hoặc yêu cầu của kiểm toán viên, không phải từ chính bản thân quy định.

Ba biện pháp tuân thủ quan trọng hơn cả đơn thuê: | Biện pháp | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc pháp lý cho PHI | | Mã hoá at rest và in transit | KMS + TLS | | Audit trail đầy đủ | CloudTrail, VPC Flow Logs |

Ba lưu ý khi dùng Dedicated Host: | Lưu ý | Chi tiết | |---|---| | Có Host Resource Group để tự động hoá | AWS tự đặt instance lên host | | Host Recovery tự thay máy khi hỏng | nên bật | | Dedicated Host Reservation | giảm giá tới 70% |

Và với BYOL, License Manager giúp theo dõi tuân thủ:

aws license-manager create-license-configuration   --name giay-phep-sql-server --license-counting-type Core   --license-count 64 --license-count-hard-limit

Nó chặn việc chạy instance vượt số lõi đã mua giấy phép — tránh vi phạm hợp đồng phần mềm.

Và một lời khuyên: hãy xác nhận với bộ phận tuân thủ xem yêu cầu thật sự là gì trước khi chọn đơn thuê. Chuyển sang Dedicated Instance làm tăng chi phí đáng kể, và trong nhiều trường hợp yêu cầu thực tế được đáp ứng bằng mã hoá và cách ly mạng — hai thứ rẻ hơn nhiều và thường hiệu quả hơn về mặt bảo mật.

Câu 477 Design Resilient Architectures

A manufacturing company receives unreliable service from its data center provider because the company is located in an area prone to natural disasters. The company is not ready to fully migrate to the AWS Cloud, but it wants a failover environment on AWS in case the on-premises data center fails. The company runs web servers that connect to external vendors. The data available on AWS and on-premises must be uniform.

Which of the following solutions would have the LEAST amount of downtime?

  1. A

    Set up a Amazon Route 53 failover record. Run an AWS Lambda function to execute an AWS CloudFormation template to launch two Amazon EC2 instances. Set up AWS Storage Gateway with stored volumes to back up data to Amazon S3. Set up an AWS Direct Connect connection between a VPC and the data center
  2. B

    Set up a Amazon Route 53 failover record. Execute an AWS CloudFormation template from a script to provision Amazon EC2 instances behind an Application Load Balancer. Set up AWS Storage Gateway with stored volumes to back up data to Amazon S3
  3. C

    Set up a Amazon Route 53 failover record. Run application servers on Amazon EC2 instances behind an Application Load Balancer in an Auto Scaling group. Set up AWS Storage Gateway with stored volumes to back up data to Amazon S3
  4. D

    Set up a Amazon Route 53 failover record. Set up an AWS Direct Connect connection between a VPC and the data center. Run application servers on Amazon EC2 in an Auto Scaling group. Run an AWS Lambda function to execute an AWS CloudFormation template to create an Application Load Balancer
Xem giải thích

Đáp án

C — Đặt Route 53 failover record; chạy máy chủ ứng dụng trên EC2 sau ALB trong Auto Scaling group; dùng Storage Gateway stored volumes sao lưu dữ liệu vào S3.

Vì sao đúng

Đề hỏi giải pháp có ÍT THỜI GIAN NGỪNG NHẤT — và điểm phân biệt nằm ở chỗ hạ tầng đã chạy sẵn hay phải dựng khi sự cố xảy ra.

Ba phương án kia đều phải DỰNG hạ tầng lúc chuyển vùng:

"Run an AWS Lambda function to execute an AWS CloudFormation template
 to launch two Amazon EC2 instances"
    ↓
    Sự cố xảy ra → mới bắt đầu tạo tài nguyên
    → CloudFormation chạy: vài phút
    → EC2 khởi động và cấu hình: vài phút nữa
        ↓
    Thời gian ngừng: HÀNG CHỤC PHÚT

Còn đáp án C có mọi thứ ĐANG CHẠY:

ALB + ASG + EC2 đã hoạt động sẵn ở AWS
    → health check của Route 53 phát hiện trung tâm dữ liệu hỏng
    → chuyển bản ghi DNS sang ALB
        ↓
    Thời gian ngừng: chỉ bằng thời gian phát hiện + TTL của DNS

Đây là mô hình Warm Standby trong bốn chiến lược khôi phục thảm hoạ: | Chiến lược | Trạng thái ở AWS | RTO | |---|---|---| | Backup & Restore | chỉ có dữ liệu | hàng giờ | | Pilot Light | database chạy, ứng dụng TẮT | hàng chục phút | | Warm Standby | mọi thứ CHẠY ở quy mô nhỏ | vài phút ← câu này | | Multi-site active/active | chạy đủ quy mô ở cả hai nơi | gần như bằng 0 |

Và Storage Gateway stored volumes đáp ứng vế "dữ liệu phải đồng nhất":

Stored volume mode:
    → dữ liệu CHÍNH nằm tại chỗ (độ trễ thấp cho ứng dụng)
    → sao lưu BẤT ĐỒNG BỘ lên S3 dưới dạng EBS snapshot
        ↓
    Sự cố → khôi phục volume từ snapshot cho EC2 ở AWS

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

  • **B. Route 53 failover, chạy CloudFormation từ script để cấp EC2 sau ALB, Storage Gateway stored volumes — đây là phương án gần nhất và kiến trúc đích giống hệt đáp án C, nhưng nó dựng hạ tầng LÚC SỰ CỐ: CloudFormation phải chạy, ALB phải khởi tạo (mất vài phút để sẵn sàng), instance phải khởi động. Thêm hàng chục phút ngừng so với việc đã có sẵn.
  • **A. Route 53 failover, Lambda chạy CloudFormation tạo hai EC2, Storage Gateway, và Direct Connect — cùng vấn đề dựng lúc sự cố, và còn thiếu load balancer trước hai instance.
  • **D. Route 53 failover, Direct Connect, EC2 trong ASG, nhưng Lambda chạy CloudFormation để TẠO ALB — vế EC2 đã chạy sẵn là tốt, nhưng ALB phải dựng lúc sự cố: ALB mất vài phút để cấp phát và đăng ký target, cộng thời gian lan truyền DNS của chính ALB.

Ghi nhớ

Bốn chiến lược khôi phục thảm hoạ — bảng phải thuộc: | Chiến lược | Chạy gì ở AWS | RTO | RPO | Chi phí | |---|---|---|---|---| | Backup & Restore | chỉ dữ liệu | giờ | giờ | thấp nhất | | Pilot Light | database chạy, ứng dụng TẮT | chục phút | phút | thấp | | Warm Standby | mọi tầng chạy ở quy mô NHỎ | phút | giây–phút | trung bình | | Multi-site | đủ quy mô, phục vụ thật | gần 0 | gần 0 | cao nhất |

Từ khoá nhận diện:

"LEAST downtime", "scaled-down but running" → Warm Standby "database replicating, servers off" → Pilot Light "restore from backup" → Backup & Restore "active-active", "zero downtime" → Multi-site

Hai khái niệm cốt lõi: | Khái niệm | Nghĩa | |---|---| | RTO (Recovery Time Objective) | bao lâu để hoạt động trở lại | | RPO (Recovery Point Objective) | mất bao nhiêu dữ liệu |

Ba loại Storage Gateway: | Loại | Giao thức | Dữ liệu chính ở đâu | |---|---|---| | File Gateway | NFS, SMB | S3, cache tại chỗ | | Volume Gateway — stored | iSCSI | TẠI CHỖ, sao lưu lên S3 ← câu này | | Volume Gateway — cached | iSCSI | S3, cache tại chỗ | | Tape Gateway | iSCSI VTL | S3 Glacier |

Stored và cached — phân biệt rõ: | | Stored volume | Cached volume | |---|---|---| | Dữ liệu ĐẦY ĐỦ nằm ở | TẠI CHỖ | S3 | | Độ trễ đọc | thấp (đĩa nội bộ) | thấp cho dữ liệu nóng | | Dung lượng tối đa | 512 TB | 1 PB | | Phù hợp | khôi phục thảm hoạ, dữ liệu cần truy cập nhanh tại chỗ | mở rộng dung lượng |

Với tình huống "chưa sẵn sàng chuyển hẳn lên đám mây" như đề, stored volume là lựa chọn đúng — ứng dụng tại chỗ vẫn chạy với hiệu năng đĩa nội bộ.

Ba thành phần của Route 53 failover: | Thành phần | Chi tiết | |---|---| | Bản ghi PRIMARY | trỏ tới trung tâm dữ liệu, có health check | | Bản ghi SECONDARY | trỏ tới ALB ở AWS | | Health check | kiểm tra endpoint chính |

aws route53 create-health-check --caller-reference $(uuidgen)   --health-check-config '{"IPAddress":"203.0.113.10","Port":443,
    "Type":"HTTPS","ResourcePath":"/health",
    "RequestInterval":10,"FailureThreshold":2}'

RequestInterval=10 và FailureThreshold=2 cho phát hiện trong khoảng 20–30 giây — nhanh hơn giá trị mặc định.

Và TTL của bản ghi phải NGẮN:

TTL 300 giây:
    → sau khi Route 53 chuyển, client vẫn dùng IP cũ tới 5 phút

TTL 60 giây:
    → chuyển nhanh hơn nhiều
    → đổi lại: nhiều truy vấn DNS hơn (chi phí nhỏ)

Ba hạn chế của DNS failover: | Hạn chế | Chi tiết | |---|---| | Bộ đệm DNS ở client và ISP | nhiều thiết bị bỏ qua TTL | | Không tức thì | phụ thuộc thời gian phát hiện + TTL | | Java cache vĩnh viễn theo mặc định | networkaddress.cache.ttl = -1 |

Và Global Accelerator là lựa chọn không phụ thuộc DNS:

Global Accelerator: hai IP anycast TĨNH
    → chuyển đích ở tầng mạng
    → không chờ TTL

(Không nằm trong các phương án của đề, nhưng đáng biết cho tình huống thật.)

Ba việc phải làm để warm standby thực sự sẵn sàng: | Việc | Chi tiết | |---|---| | DIỄN TẬP chuyển vùng định kỳ | quan trọng nhất — kế hoạch chưa thử là kế hoạch chưa có | | Giữ AMI và cấu hình đồng bộ | môi trường dự phòng phải chạy được mã hiện tại | | Đảm bảo ASG mở rộng kịp | quy mô nhỏ phải tăng được khi nhận toàn bộ tải |

Dòng cuối là điểm hay bị bỏ sót: warm standby chạy 2 máy, nhưng khi nhận toàn bộ lưu lượng cần 20 máy — nếu ASG không được cấu hình để mở rộng nhanh, hệ thống sẽ sập ngay sau khi chuyển vùng.

Ba cách rút ngắn thời gian mở rộng: | Cách | Chi tiết | |---|---| | Warm pool của ASG | máy đã cấu hình sẵn ở trạng thái Stopped | | AMI có sẵn ứng dụng | không cài đặt lúc khởi động | | Scheduled scaling trước khi chuyển vùng | nếu biết trước |

Và một lời khuyên: hãy diễn tập chuyển vùng ít nhất mỗi quý. Với công ty ở vùng thiên tai, sự cố sẽ đến — và khác biệt giữa "có kế hoạch" và "kế hoạch chạy được" chỉ lộ ra khi thử thật, thường ở những chi tiết nhỏ như chứng chỉ hết hạn hay biến môi trường trỏ sai địa chỉ.

Câu 478 Design Secure Architectures

An enterprise is building a secure business intelligence API using Amazon API Gateway to serve internal users with confidential analytics data. The API must be accessible only from a set of trusted IP addresses that are part of the organization's internal network ranges. No external IP traffic should be able to invoke the API. A solutions architect must design this access control mechanism with the least operational complexity.

What should the architect do to meet these requirements?

  1. A

    Modify the security group that is attached to API Gateway to allow only traffic from specific IP addresses
  2. B

    Deploy the API Gateway resource to an on-premises server using AWS Outposts. Apply host-based firewall rules to filter allowed IPs
  3. C

    Create a resource policy for the API Gateway API that explicitly denies access to all IP addresses except those listed in an allow list
  4. D

    Deploy the API Gateway as a regional API in a public subnet and associate the subnet with a security group that permits inbound traffic only from trusted IP ranges
Xem giải thích

Đáp án

C — Tạo resource policy cho API Gateway từ chối rõ ràng mọi địa chỉ IP trừ những địa chỉ trong danh sách cho phép.

Vì sao đúng

Điểm mấu chốt: API Gateway KHÔNG có security group — nó là dịch vụ được quản lý nằm ngoài VPC của bạn.

API Gateway (regional hoặc edge-optimized):
    → là endpoint do AWS vận hành
    → KHÔNG có ENI trong VPC của bạn
    → KHÔNG gắn security group được
        ↓
    Cơ chế kiểm soát theo IP duy nhất: RESOURCE POLICY

Resource policy cho API Gateway:

{"Version": "2012-10-17",
 "Statement": [
   {"Effect": "Allow",
    "Principal": "*",
    "Action": "execute-api:Invoke",
    "Resource": "execute-api:/*"},
   {"Effect": "Deny",
    "Principal": "*",
    "Action": "execute-api:Invoke",
    "Resource": "execute-api:/*",
    "Condition": {"NotIpAddress": {"aws:SourceIp": [
      "10.100.0.0/16", "203.0.113.0/24"]}}}]}

Cách đọc chính sách này:

Statement 1: cho phép mọi người gọi API
Statement 2: TỪ CHỐI nếu IP KHÔNG nằm trong danh sách
    ↓
    Deny thắng Allow → chỉ IP trong danh sách gọi được

Và cần nhớ: sau khi sửa resource policy phải TRIỂN KHAI LẠI API.

aws apigateway update-rest-api --rest-api-id abc123   --patch-operations op=replace,path=/policy,value="$(cat policy.json)"

aws apigateway create-deployment --rest-api-id abc123 --stage-name prod

Bỏ bước triển khai lại là chính sách không có hiệu lực — và không có thông báo lỗi nào.

Vì sao đây là cách ít phức tạp nhất:

✓ Một tệp JSON, không thêm hạ tầng nào
✓ Chặn ngay tại API Gateway, không tốn tài nguyên backend
✓ Sửa danh sách IP chỉ cần cập nhật chính sách

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

  • **D. Triển khai API Gateway thành regional API trong public subnet và gắn security group cho phép IP tin cậy — đây là phương án gần nhất vì nó nhắc đúng loại endpoint (regional), nhưng nó sai về mặt kỹ thuật: API Gateway không triển khai vào subnet và không gắn security group được. Regional endpoint vẫn là endpoint công khai do AWS quản lý.
  • **A. Sửa security group gắn với API Gateway — cùng lỗi: không tồn tại security group nào gắn với API Gateway.
  • **B. Triển khai API Gateway lên máy chủ tại chỗ qua AWS Outposts và dùng tường lửa host — API Gateway KHÔNG chạy trên Outposts, và giải pháp này phức tạp hơn hẳn so với một chính sách JSON.

Ghi nhớ

Ba loại endpoint của API Gateway — bảng cần thuộc: | Loại | Vị trí | Truy cập | |---|---|---| | Edge-optimized | qua CloudFront | công khai, toàn cầu | | Regional | trong một Region | công khai | | Private | CHỈ qua VPC endpoint | riêng tư hoàn toàn |

Và với yêu cầu "chỉ mạng nội bộ", private endpoint là lựa chọn mạnh hơn:

aws apigateway create-rest-api --name api-noi-bo   --endpoint-configuration types=PRIVATE

{"Effect": "Allow", "Principal": "*",
 "Action": "execute-api:Invoke", "Resource": "execute-api:/*",
 "Condition": {"StringEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Private API chỉ gọi được qua interface VPC endpoint — kín hơn cả việc lọc IP, vì nó không có endpoint công khai nào. (Đề đưa ra danh sách IP tin cậy, nên resource policy là đáp án phù hợp với các phương án cho sẵn.)

Bốn cơ chế kiểm soát truy cập của API Gateway: | Cơ chế | Kiểm soát | |---|---| | Resource policy | AI (theo IP, VPC, tài khoản) gọi được ← câu này | | IAM authorization | principal của AWS | | Lambda authorizer | logic tuỳ ý (token, JWT) | | Cognito user pool | người dùng đã đăng nhập | | API key + usage plan | phân hạn mức cho từng khách hàng |

Và các cơ chế này KẾT HỢP được:

Resource policy (chặn IP ngoài)
    + Cognito authorizer (xác thực người dùng)
        ↓
    Hai lớp độc lập

Ba khoá điều kiện dùng trong resource policy: | Khoá | Việc | |---|---| | aws:SourceIp | IP công cộng của người gọi ← câu này | | aws:SourceVpc | VPC nguồn (cho private API) | | aws:SourceVpce | id VPC endpoint cụ thể |

Lưu ý quan trọng về aws:SourceIp với private API:

Private API gọi từ trong VPC:
    → aws:SourceIp KHÔNG áp dụng như mong đợi
    → phải dùng aws:SourceVpc hoặc aws:SourceVpce

Ba lưu ý về resource policy: | Lưu ý | Chi tiết | |---|---| | PHẢI triển khai lại API sau khi sửa | nếu không, không có hiệu lực | | Deny thắng Allow | như mọi chính sách IAM | | Chỉ áp cho REST API và HTTP API | WebSocket API cũng hỗ trợ |

Dòng đầu là lỗi vận hành phổ biến nhất với resource policy — sửa xong, thử ngay, thấy vẫn vào được, tưởng chính sách sai, trong khi chỉ thiếu bước deploy.

Ba lớp bảo vệ nên có cho API nội bộ nhạy cảm: | Lớp | Chi tiết | |---|---| | Resource policy hoặc private endpoint | giới hạn nguồn | | Xác thực (IAM hoặc Cognito) | xác định danh tính | | AWS WAF | lọc tấn công tầng 7 | | Throttling và usage plan | chống lạm dụng |

Và WAF gắn được vào REST API:

aws wafv2 associate-web-acl --web-acl-arn <arn>   --resource-arn arn:aws:apigateway:ap-northeast-1::/restapis/abc123/stages/prod

Lưu ý: WAF chỉ hỗ trợ REST API, không hỗ trợ HTTP API.

REST API và HTTP API — bảng phân biệt: | | REST API | HTTP API | |---|---|---| | Resource policy | ✅ | ❌ | | AWS WAF | ✅ | ❌ | | Private endpoint | ✅ | ❌ | | Usage plan, API key | ✅ | ❌ | | Caching | ✅ | ❌ | | Chi phí | cao hơn | rẻ hơn ~70% | | Xác thực | IAM, Cognito, Lambda | thêm JWT authorizer |

Với API nội bộ cần resource policy và WAF, REST API là lựa chọn bắt buộc.

Ba lưu ý khi lọc theo IP: | Lưu ý | Chi tiết | |---|---| | IP văn phòng có thể ĐỔI | chính sách hỏng mà không báo trước | | Nhân viên từ xa bị chặn | cần VPN với IP cố định | | Không thay thế được xác thực | IP là lớp bổ sung, không phải danh tính |

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | CloudWatch Logs của API Gateway | xem request bị từ chối và lý do | | Access log với $context.identity.sourceIp | ghi lại IP thật | | CloudTrail | thay đổi cấu hình API |

Và một lời khuyên: hãy bật access log với trường sourceIp ngay từ đầu. Khi người dùng nội bộ báo "không gọi được API", câu hỏi đầu tiên luôn là "họ đến từ IP nào" — và không có log thì bạn chỉ có thể đoán, trong khi chính sách IP là loại cấu hình rất dễ khoá nhầm người dùng hợp lệ.

Câu 479 Design Secure Architectures

A financial services company has developed its flagship application on AWS Cloud with data security requirements such that the encryption key must be stored in a custom application running on-premises. The company wants to offload the data storage as well as the encryption process to Amazon S3 but continue to use the existing encryption key.

Which of the following Amazon S3 encryption options allows the company to leverage Amazon S3 for storing data with given constraints?

  1. A

    Server-Side Encryption with Amazon S3 managed keys (SSE-S3)
  2. B

    Server-Side Encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS)
  3. C

    Server-Side Encryption with Customer-Provided Keys (SSE-C)
  4. D

    Client-Side Encryption with data encryption is done on the client-side before sending it to Amazon S3
Xem giải thích

Đáp án

C — Server-Side Encryption với khoá do khách hàng cung cấp (SSE-C).

Vì sao đúng

Đề nêu hai ràng buộc, và SSE-C là lựa chọn duy nhất thoả cả hai: | Ràng buộc | Cơ chế | |---|---| | Khoá mã hoá phải nằm trong ứng dụng TẠI CHỖ | SSE-C: AWS KHÔNG lưu khoá | | Đẩy việc LƯU TRỮ và MÃ HOÁ sang S3 | S3 thực hiện mã hoá, không phải client |

Cách SSE-C hoạt động:

Client gửi kèm KHOÁ trong header của MỖI request
    ↓ qua HTTPS
S3 dùng khoá đó mã hoá dữ liệu và ghi xuống đĩa
    ↓
S3 XOÁ khoá khỏi bộ nhớ ngay
    → chỉ giữ một giá trị băm HMAC để xác thực lần sau
        ↓
    AWS KHÔNG BAO GIỜ lưu khoá của bạn

Và đọc lại cũng phải gửi đúng khoá đó:

aws s3api put-object --bucket kho-tai-chinh --key du-lieu.dat   --body du-lieu.dat   --sse-customer-algorithm AES256   --sse-customer-key fileb://khoa.bin

aws s3api get-object --bucket kho-tai-chinh --key du-lieu.dat   --sse-customer-algorithm AES256   --sse-customer-key fileb://khoa.bin ket-qua.dat

Vì sao SSE-C khớp chính xác với hai yêu cầu:

"encryption key must be stored in a custom application running on-premises"
    → khoá do BẠN giữ, AWS không lưu → SSE-C ✓

"offload the data storage AS WELL AS the ENCRYPTION PROCESS to S3"
    → S3 làm việc mã hoá → KHÔNG phải client-side ✓
    → nhưng vẫn dùng khoá hiện có ✓

Điểm phân biệt then chốt với client-side encryption:

SSE-C:         client GỬI khoá, S3 MÃ HOÁ
Client-side:   client TỰ MÃ HOÁ rồi mới gửi dữ liệu đã mã hoá
    ↓
    Đề muốn ĐẨY việc mã hoá sang S3 → SSE-C

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

  • **D. Client-Side Encryption, mã hoá ở phía client trước khi gửi lên S3 — đây là phương án gần nhất và cũng cho phép giữ khoá tại chỗ, nhưng nó vi phạm vế thứ hai: đề nói rõ muốn đẩy quá trình mã hoá sang S3. Client-side giữ nguyên gánh nặng mã hoá ở ứng dụng tại chỗ.
  • **B. SSE-KMS — khoá do AWS KMS quản lý, không phải khoá hiện có trong ứng dụng tại chỗ. (KMS có tính năng import key material, nhưng khi đó khoá vẫn nằm trong KMS — không phải "lưu trong ứng dụng tại chỗ".)
  • **A. SSE-S3 — AWS quản lý khoá hoàn toàn, bạn không kiểm soát và không dùng được khoá riêng.

Ghi nhớ

Năm cách mã hoá S3 — bảng phải thuộc: | Cách | Ai giữ khoá | Ai mã hoá | Audit dùng khoá | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | S3 | ❌ | | SSE-KMS | KMS (bạn kiểm soát policy) | S3 | ✅ CloudTrail | | DSSE-KMS | KMS, mã hoá HAI lớp | S3 | ✅ | | SSE-C | BẠN — gửi mỗi request | S3 | ❌ | | Client-side | BẠN hoàn toàn | CLIENT | ❌ |

Từ khoá nhận diện trong đề thi:

"key must stay with us", "offload encryption to S3" → SSE-C "encrypt before sending", "AWS never sees plaintext" → client-side "audit who used the key and when" → SSE-KMS "simplest, AWS manages everything" → SSE-S3

Ba header của SSE-C: | Header | Việc | |---|---| | x-amz-server-side-encryption-customer-algorithm | AES256 | | x-amz-server-side-encryption-customer-key | khoá, mã hoá base64 | | x-amz-server-side-encryption-customer-key-MD5 | băm để S3 kiểm tra khoá không bị hỏng |

Bốn hạn chế quan trọng của SSE-C: | Hạn chế | Chi tiết | |---|---| | BẮT BUỘC dùng HTTPS | khoá đi trong header — HTTP bị S3 từ chối | | Phải gửi khoá ở MỌI request | kể cả HeadObject và CopyObject | | MẤT KHOÁ = MẤT DỮ LIỆU VĨNH VIỄN | AWS không khôi phục được | | Không dùng được S3 Console để tải xuống | console không gửi khoá |

Dòng thứ ba là rủi ro lớn nhất của SSE-C:

AWS KHÔNG lưu khoá
    → mất khoá → dữ liệu thành chuỗi byte vô nghĩa
    → không có cách nào khôi phục
        ↓
    → Sao lưu khoá ở NHIỀU nơi an toàn là bắt buộc

Ba hạn chế vận hành khác: | Hạn chế | Chi tiết | |---|---| | Lifecycle chuyển lớp vẫn hoạt động | S3 giữ được bản mã hoá | | Cross-Region Replication KHÔNG hỗ trợ SSE-C | phải tự sao chép | | S3 Batch Operations hạn chế | nhiều thao tác không dùng được |

Vế thứ hai đáng lưu ý với công ty tài chính — muốn sao lưu xuyên Region thì phải tự viết quy trình.

Ba lựa chọn thay thế nếu SSE-C quá phiền: | Lựa chọn | Đặc điểm | |---|---| | KMS với imported key material | đưa khoá của bạn vào KMS, vẫn kiểm soát vòng đời | | AWS CloudHSM + custom key store | khoá trong HSM riêng, AWS không truy cập được | | Client-side với AWS Encryption SDK | mã hoá ở client, thư viện chuẩn |

KMS custom key store với CloudHSM đáng biết:

Custom key store:
    → khoá nằm trong cụm CloudHSM CỦA BẠN
    → KMS gọi tới HSM để thực hiện phép mã hoá
    → bạn kiểm soát HSM hoàn toàn
        ↓
    Vừa có audit của KMS, vừa giữ được quyền kiểm soát khoá

Với dịch vụ tài chính, đây thường là lựa chọn phù hợp hơn SSE-C về lâu dài.

Ba lưu ý về imported key material của KMS: | Lưu ý | Chi tiết | |---|---| | Bạn có thể đặt hạn dùng cho khoá | tự hết hạn | | Xoá được key material tức thì | dữ liệu thành không đọc được ngay | | KMS KHÔNG tự xoay vòng khoá nhập vào | phải tự làm |

Ba biện pháp bảo vệ kèm theo cho dữ liệu tài chính: | Biện pháp | Chi tiết | |---|---| | Bắt buộc HTTPS bằng bucket policy | aws:SecureTransport | | Versioning và Object Lock | chống xoá và ransomware | | CloudTrail data event | ghi mọi thao tác object-level |

Và bắt buộc SSE-C bằng bucket policy:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-tai-chinh/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption-customer-algorithm": "AES256"}}}

Và một lời khuyên: hãy xây quy trình sao lưu và xoay vòng khoá trước khi đưa SSE-C vào sản xuất. Với SSE-C, xoay vòng khoá nghĩa là đọc lại và ghi lại từng object bằng khoá mới — một thao tác tốn kém mà nếu không lập kế hoạch từ đầu sẽ trở thành rào cản khi chính sách bảo mật yêu cầu đổi khoá định kỳ.

Câu 480 Design Cost-Optimized Architectures

An application is currently hosted on four Amazon EC2 instances (behind Application Load Balancer) deployed in a single Availability Zone (AZ). To maintain an acceptable level of end-user experience, the application needs at least 4 instances to be always available.

As a solutions architect, which of the following would you recommend so that the application achieves high availability with MINIMUM cost?

  1. A

    Deploy the instances in three Availability Zones (AZs). Launch two instances in each Availability Zone (AZ)
  2. B

    Deploy the instances in two Availability Zones (AZs). Launch two instances in each Availability Zone (AZ)
  3. C

    Deploy the instances in two Availability Zones (AZs). Launch four instances in each Availability Zone (AZ)
  4. D

    Deploy the instances in one Availability Zones. Launch two instances in the Availability Zone (AZ)
Xem giải thích

Đáp án

A — Triển khai instance ở BA Availability Zone, mỗi AZ hai instance.

Vì sao đúng

Đây là bài toán tính số máy tối thiểu để chịu được mất một AZ mà vẫn giữ đủ 4 máy phục vụ.

Kiểm tra từng phương án: | Phương án | Tổng số máy | Còn lại khi mất 1 AZ | Đủ 4? | |---|---|---|---| | A. 3 AZ × 2 máy | 6 | 6 − 2 = 4 | ✅ | | B. 2 AZ × 2 máy | 4 | 4 − 2 = 2 | ❌ | | C. 2 AZ × 4 máy | 8 | 8 − 4 = 4 | ✅ nhưng đắt hơn | | D. 1 AZ × 2 máy | 2 | 0 | ❌ |

A và C đều đáp ứng yêu cầu, nhưng A dùng ÍT MÁY HƠN:

A: 6 máy → tiết kiệm 25% so với C
C: 8 máy
    ↓
    Đề hỏi "MINIMUM cost" → chọn A

Vì sao càng nhiều AZ càng tiết kiệm — công thức tổng quát:

Cần N máy phục vụ, chịu được mất 1 AZ, dùng K AZ:
    Số máy mỗi AZ = N ÷ (K − 1)
    Tổng số máy   = N × K ÷ (K − 1)
Số AZ Tổng máy cần (N = 4)
2 AZ 4 × 2 ÷ 1 = 8
3 AZ 4 × 3 ÷ 2 = 6
4 AZ 4 × 4 ÷ 3 ≈ 5,3 → 6

Càng nhiều AZ, phần dung lượng dự phòng càng nhỏ — vì mất một AZ chỉ mất 1/K năng lực thay vì 1/2.

Và đây là lý do AWS khuyến nghị ba AZ cho hầu hết kiến trúc sản xuất.

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

  • **C. Hai AZ, mỗi AZ bốn instance — đây là phương án gần nhất và đáp ứng đúng yêu cầu về sẵn sàng: mất một AZ vẫn còn 4 máy. Nhưng nó dùng 8 máy thay vì 6, đắt hơn 33% cho cùng mức chịu lỗi. Đề hỏi chi phí tối thiểu.
  • **B. Hai AZ, mỗi AZ hai instance — không đủ: mất một AZ chỉ còn 2 máy, dưới mức 4 máy tối thiểu.
  • **D. Một AZ, hai instance — tệ nhất: không có sẵn sàng cao (một AZ hỏng là mất hết), và cũng không đủ 4 máy ngay cả khi bình thường.

Ghi nhớ

Công thức thiết kế N+1 theo AZ — nên thuộc:

Số máy mỗi AZ = (số máy cần phục vụ) ÷ (số AZ − 1)
Máy cần 2 AZ 3 AZ 4 AZ
4 4 mỗi AZ (8) 2 mỗi AZ (6) 2 mỗi AZ (8)
6 6 mỗi AZ (12) 3 mỗi AZ (9) 2 mỗi AZ (8)
12 12 mỗi AZ (24) 6 mỗi AZ (18) 4 mỗi AZ (16)

Quy tắc: ba AZ là điểm cân bằng tốt cho hầu hết trường hợp.

Ba lý do AWS khuyến nghị ba AZ: | Lý do | Chi tiết | |---|---| | Tiết kiệm hơn hai AZ cho cùng mức chịu lỗi | ← câu này | | Nhiều dịch vụ đòi tối thiểu hai, khuyến nghị ba | RDS, ElastiCache, EKS | | Chịu được mất một AZ mà không giảm quá sâu | mất 33% thay vì 50% |

Ba khái niệm về hạ tầng AWS: | Khái niệm | Chi tiết | |---|---| | Availability Zone | một hoặc nhiều trung tâm dữ liệu, cách ly về điện và mạng | | Region | nhóm AZ, thường 3–6 AZ | | Local Zone | mở rộng Region tới thành phố lớn |

Và các AZ trong một Region cách nhau đủ xa để không cùng hỏng, nhưng đủ gần để độ trễ dưới 2ms.

Ba cấu hình ASG cho sẵn sàng cao: | Cấu hình | Giá trị nên dùng | |---|---| | MinSize | đủ chịu tải khi mất một AZ | | Nhiều subnet ở nhiều AZ | ASG tự phân bố đều | | HealthCheckType = ELB | thay máy mà ứng dụng hỏng |

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --launch-template LaunchTemplateName=lt-ung-dung   --min-size 6 --max-size 12 --desired-capacity 6   --vpc-zone-identifier "subnet-a,subnet-b,subnet-c"   --health-check-type ELB --health-check-grace-period 300

ASG tự cân bằng số máy đều giữa các AZ — không cần cấu hình thêm.

Ba cơ chế ASG duy trì phân bố đều: | Cơ chế | Chi tiết | |---|---| | AZ rebalancing | tự cân bằng khi lệch | | Chấm dứt từ AZ có nhiều máy nhất | chính sách mặc định | | Khởi động vào AZ có ít máy nhất | khi mở rộng |

Và khi cân bằng lại, ASG KHỞI ĐỘNG máy mới TRƯỚC rồi mới chấm dứt máy cũ — để không giảm năng lực.

Ba lưu ý về ALB và AZ: | Lưu ý | Chi tiết | |---|---| | ALB cần subnet ở ít nhất HAI AZ | yêu cầu bắt buộc | | Cross-zone load balancing BẬT mặc định với ALB | phân phối đều mọi target | | Chỉ gửi tới target khoẻ mạnh | health check quyết định |

Cross-zone load balancing — khác biệt giữa ALB và NLB: | | ALB | NLB | |---|---|---| | Mặc định | BẬT | TẮT | | Phí truyền chéo AZ | miễn phí | tính phí khi bật |

Ba tầng cần thiết kế đa AZ: | Tầng | Cách | |---|---| | Web/ứng dụng | ASG qua nhiều AZ ← câu này | | Database | RDS Multi-AZ hoặc Aurora (lưu trữ 3 AZ) | | Lưu trữ | S3 (tự đa AZ), EFS Standard (đa AZ) |

Lưu ý: EBS gắn với MỘT AZ — instance ở AZ khác không mount được volume đó.

Ba cách kiểm chứng thiết kế: | Cách | Chi tiết | |---|---| | Thử chấm dứt mọi instance trong một AZ | xem hệ thống có trụ được không | | AWS Fault Injection Service | mô phỏng mất AZ có kiểm soát | | Xem CloudWatch trong lúc thử | độ trễ và tỷ lệ lỗi |

AWS Fault Injection Service đáng dùng:

FIS mô phỏng được:
    ✓ mất kết nối tới một AZ
    ✓ dừng instance hàng loạt
    ✓ tăng độ trễ mạng, tăng CPU
        ↓
    Kiểm chứng thiết kế bằng thực nghiệm thay vì bằng niềm tin

Và một lời khuyên: hãy đặt MinSize bằng đúng số máy cần khi đã mất một AZ, không phải bằng số máy cần lúc bình thường. Trong tình huống này là 6 — nếu đặt 4, ASG sẽ để hệ thống chạy ở mức không chịu nổi việc mất một AZ, và bạn chỉ phát hiện điều đó vào đúng lúc AZ thật sự hỏng.