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

Tìm thấy 1221 câu.

Câu 91 Domain - Design for New Solutions

As part of the Corporate Social Responsibility of the tech company, the development team created an online learning system for a public university. The application architecture uses an Application Load Balancer in front of two On-Demand EC2 instances located in two Availability Zones. The only remaining requirement is to secure the new website with an HTTPS connection.

Which of the following option is the most cost-effective and easiest way to complete the online learning system?

  1. A Generate a Private Certificate in ACM. Configure the Application Load Balancer to use the Private Certificate to handle HTTPS requests.
  2. B Generate a Public Certificate in ACM. Configure the two EC2 instances to use the Public Certificate to handle HTTPS requests.
  3. C Generate a Public Certificate in ACM. Configure the Application Load Balancer to use the Public Certificate to handle HTTPS requests.
  4. D Generate a Private Certificate in ACM. Configure the two EC2 instances to use the Private Certificate to handle HTTPS requests.
Xem giải thích

Đáp án

C — Yêu cầu chứng chỉ công khai từ ACM và gắn vào Application Load Balancer.

Vì sao đúng

Đề cần HTTPS cho ứng dụng web công khai đứng sau ALB, và ACM là cách đúng: | Yêu cầu | Cách đáp ứng | |---|---| | HTTPS cho người dùng Internet | chứng chỉ công khai được trình duyệt tin cậy | | Không tốn công vận hành | ACM miễn phí và tự gia hạn | | Gắn vào tầng cân bằng tải | ALB tích hợp sẵn với ACM |

⚠ Ba đặc tính của chứng chỉ công khai ACM:

1. MIỄN PHÍ khi dùng với dịch vụ tích hợp
   (ALB, NLB, CloudFront, API Gateway)
        ↓
2. TỰ GIA HẠN — không có chuyện hết hạn
   lúc 2 giờ sáng chủ nhật
        ↓
3. KHOÁ RIÊNG không xuất được
   → không rò rỉ ra ngoài được

Yêu cầu chứng chỉ:

aws acm request-certificate \
  --domain-name congty.com \
  --subject-alternative-names '*.congty.com' \
  --validation-method DNS

⚠ Xác thực bằng DNS chứ không bằng email: | Cách | Gia hạn tự động | |---|---| | DNS | CÓ, miễn bản ghi CNAME còn đó | | Email | không — phải bấm link mỗi lần |

Xác thực email: mỗi lần gia hạn phải có
  người bấm vào link trong thư
        ↓
    Ai đó nghỉ việc, hộp thư không ai đọc
    → chứng chỉ hết hạn
    → chọn DNS, luôn luôn

Tạo bản ghi xác thực trong Route 53 tự động:

aws acm describe-certificate --certificate-arn <arn> \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord'

Gắn vào listener của ALB:

aws elbv2 create-listener --load-balancer-arn <arn-alb> \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=<arn-chung-chi> \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=<arn-tg>

⚠ Chuyển hướng HTTP sang HTTPS ở chính ALB:

aws elbv2 create-listener --load-balancer-arn <arn-alb> \
  --protocol HTTP --port 80 \
  --default-actions '[{"Type":"redirect","RedirectConfig":
    {"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Không cần instance nào xử lý việc này
    → ALB chuyển hướng ngay ở tầng của nó

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Miễn phí, không mua chứng chỉ hằng năm | | | Gia hạn tự động, không bao giờ quên | | | Giảm tải mã hoá khỏi instance | |

⚠ Nhưng ACM có ràng buộc về Region phải nhớ:

Chứng chỉ dùng cho ALB/NLB
    → phải cùng Region với load balancer
        ↓
    Chứng chỉ dùng cho CloudFront
    → BẮT BUỘC ở us-east-1
    → dù CloudFront là toàn cầu

Đây là lỗi cấu hình phổ biến nhất với ACM.

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

  • **B. Dùng ACM Private CA phát hành chứng chỉ — đây là phương án gần nhất và ACM Private CA là dịch vụ thật, nhưng chứng chỉ từ CA riêng không được trình duyệt tin cậy; nó dành cho giao tiếp nội bộ, và tốn khoảng 400 USD/tháng cho mỗi CA.
  • **A. Mua chứng chỉ từ nhà cung cấp bên ngoài và tải lên ACM — chạy được, nhưng tốn tiền và không tự gia hạn; phải nhớ mua và tải lên lại mỗi năm.
  • **D. Dùng chứng chỉ tự ký — trình duyệt hiện cảnh báo bảo mật; không dùng được cho ứng dụng công khai.

Ghi nhớ

⚠ Hai loại chứng chỉ ACM — bảng phải thuộc: | Loại | Ai tin cậy | Chi phí | |---|---|---| | Công khai | mọi trình duyệt | miễn phí với dịch vụ tích hợp | | Riêng (Private CA) | chỉ thiết bị đã cài CA gốc | ~400 USD/tháng mỗi CA |

Từ khoá nhận diện:

"public website, HTTPS" → chứng chỉ công khai ACM "internal service mesh, mTLS" → ACM Private CA "certificate for CloudFront" → ACM ở us-east-1 "certificate on EC2 directly" → không xuất được từ ACM, phải mua ngoài

⚠ Điểm cuối là hạn chế quan trọng:

Chứng chỉ công khai ACM KHÔNG xuất được
    → không cài lên EC2 hay máy chủ riêng
        ↓
    Cần chứng chỉ trên chính instance:
    → mua từ nhà cung cấp ngoài
    → hoặc dùng Let's Encrypt
    → hoặc ACM Private CA (nội bộ)

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Xác thực DNS cho gia hạn tự động | | | Hỗ trợ wildcard *.congty.com | | | Tối đa 10 tên miền phụ mỗi chứng chỉ (tăng được) | |

⚠ Wildcard chỉ phủ MỘT cấp:

*.congty.com khớp:
    web.congty.com — CÓ
    api.congty.com — CÓ
        ↓
    a.b.congty.com — KHÔNG
    congty.com     — KHÔNG (phải khai riêng)

Ba lưu ý về SSL policy: | Lưu ý | Chi tiết | |---|---| | Chọn policy có TLS 1.2 trở lên | | | TLS 1.3 nếu client hỗ trợ | | | Bỏ TLS 1.0/1.1 để đạt tuân thủ | |

aws elbv2 describe-ssl-policies \
  --query 'SslPolicies[?contains(Name, `TLS13`)].Name'

Ba lưu ý về mã hoá tới backend: | Lưu ý | Chi tiết | |---|---| | ALB tới target dùng HTTP là phổ biến | | | Cần đầu-cuối: target group giao thức HTTPS | | | ALB không kiểm chứng chỉ của target | |

⚠ Điểm cuối gây bất ngờ:

ALB kết nối HTTPS tới target
    → KHÔNG xác thực chứng chỉ target
        ↓
    Chứng chỉ tự ký trên instance là đủ
    → mục đích chỉ là mã hoá đường truyền,
      không phải xác thực

Ba lưu ý về theo dõi hết hạn: | Lưu ý | Chi tiết | |---|---| | ACM gửi sự kiện EventBridge trước 45 ngày | | | Config rule acm-certificate-expiration-check | | | Chứng chỉ nhập từ ngoài KHÔNG tự gia hạn | |

{"source": ["aws.acm"],
 "detail-type": ["ACM Certificate Approaching Expiration"]}

⚠ Và có một cách gia hạn thất bại âm thầm:

Xoá bản ghi CNAME xác thực sau khi cấp
    → tưởng đã xong việc
        ↓
    ACM không xác thực lại được khi gia hạn
    → chứng chỉ hết hạn
    → GIỮ bản ghi CNAME vĩnh viễn

Ba lưu ý về nhiều tên miền: | Lưu ý | Chi tiết | |---|---| | SAN gộp nhiều tên trong một chứng chỉ | | | Gắn nhiều chứng chỉ vào một listener (SNI) | | | ALB chọn theo tên miền client yêu cầu | |

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ở us-east-1 | | | Chỉ định alternate domain name | | | Bật HTTP/2 và HTTP/3 | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | openssl s_client -connect congty.com:443 | | | Kiểm ngày hết hạn và chuỗi tin cậy | | | Thử HTTP xem có chuyển hướng không | |

Và một lời khuyên: hãy luôn chọn xác thực bằng DNS và đừng bao giờ xoá bản ghi CNAME đó. Chứng chỉ hết hạn là loại sự cố hoàn toàn tránh được, nhưng vẫn xảy ra đều đặn — gần như luôn vì một bản ghi DNS bị dọn đi trong một đợt tổng vệ sinh nào đó.

Câu 92 Domain - Design for New Solutions

A company uses a CloudFormation script to deploy an online voting application. The app is used for a Nature Photography Contest that accepts high-resolution images, stores them in an S3 bucket, and records a 100-character summary about the image in RDS. The Solutions Architect must ensure that the same online voting application can be deployed once again using the same CloudFormation template for succeeding contests in the future. The photography contest will run for just a month and once it has been concluded, there would be nobody using the online voting application anymore until the next contest. As preparation for the upcoming events next year, the 100-character summaries should be kept and the S3 bucket, which contains the high-resolution photos, should remain.

Which of the following options is the recommended action to meet the above requirement?

  1. A

    1. Set the DeletionPolicy on the S3 resource declaration in the CloudFormation template to Retain. 2. Set the RDS resource declaration DeletionPolicy to Snapshot.
  2. B

    For both the RDS and S3 resource types on the CloudFormation template, set the DeletionPolicy to Retain.
  3. C

    1. Set the DeletionPolicy on the S3 resource to Snapshot.  2. Set the DeletionPolicy on the RDS resource to Snapshot.
  4. D

    1. Enable Cross-Region Replication (CRR) in the S3 bucket to maintain a copy of all the S3 objects. 2. Set the DeletionPolicy for the RDS instance to Snapshot.
Xem giải thích

Đáp án

A — Đặt DeletionPolicy: Retain cho bucket S3 và DeletionPolicy: Snapshot cho instance RDS.

Vì sao đúng

Đề cần dữ liệu sống sót khi stack CloudFormation bị xoá, và DeletionPolicy là cơ chế cho đúng việc đó: | Tài nguyên | Chính sách | Kết quả khi xoá stack | |---|---|---| | S3 bucket | Retain | bucket và mọi object ở lại | | RDS instance | Snapshot | chụp ảnh cuối rồi mới xoá instance |

⚠ Vì sao S3 dùng Retain chứ không Snapshot:

`Snapshot` chỉ hỗ trợ tài nguyên
  CÓ khái niệm ảnh chụp:
    RDS, EBS volume, ElastiCache,
    Redshift, Neptune, DocumentDB
        ↓
    S3 không có snapshot
    → khai `Snapshot` cho bucket: template lỗi

Ba giá trị của DeletionPolicy: | Giá trị | Hành vi | |---|---| | Delete | xoá tài nguyên (mặc định) | | Retain | giữ nguyên, gỡ khỏi quản lý của stack | | Snapshot | chụp ảnh rồi xoá |

Template đầy đủ:

Resources:
  KhoDuLieu:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      BucketName: du-lieu-quan-trong

  CoSoDuLieu:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Snapshot
    UpdateReplacePolicy: Snapshot
    Properties:
      Engine: postgres
      DBInstanceClass: db.r6g.large

⚠ UpdateReplacePolicy là thứ hay bị quên và gây mất dữ liệu:

`DeletionPolicy` chỉ áp khi XOÁ STACK
        ↓
    Nhưng sửa một thuộc tính bất biến
      (ví dụ đổi `DBInstanceIdentifier`)
    → CloudFormation TẠO MỚI và XOÁ CŨ
    → lúc đó `UpdateReplacePolicy` mới có tiếng nói
        ↓
    Không khai: mặc định `Delete` → mất dữ liệu
      dù đã cẩn thận đặt `DeletionPolicy: Retain`

⚠ Và Retain có hệ quả cần biết trước:

Bucket ở lại nhưng KHÔNG còn thuộc stack nào
    → tạo lại stack cùng tên bucket
    → LỖI "bucket already exists"
        ↓
    Phải import lại vào stack
    → hoặc đổi tên bucket

Import tài nguyên đã giữ lại:

aws cloudformation create-change-set \
  --stack-name stack-moi \
  --change-set-type IMPORT \
  --resources-to-import '[{
    "ResourceType": "AWS::S3::Bucket",
    "LogicalResourceId": "KhoDuLieu",
    "ResourceIdentifier": {"BucketName": "du-lieu-quan-trong"}}]' \
  --template-body file://template.yaml

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bảo vệ ngay ở tầng template, không dựa vào quy trình | | | Áp cho mọi lần xoá, kể cả xoá nhầm | | | Ảnh chụp RDS đủ để khôi phục hoàn toàn | |

⚠ Thêm một lớp nữa: termination protection cho stack:

aws cloudformation update-termination-protection \
  --stack-name stack-san-xuat \
  --enable-termination-protection

`DeletionPolicy`: bảo vệ TÀI NGUYÊN
    ↓
Termination protection: chặn xoá CẢ STACK
    ↓
Hai lớp độc lập, nên dùng cả hai

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

  • **B. Đặt Retain cho cả hai — đây là phương án gần nhất và cũng giữ được dữ liệu, nhưng RDS instance giữ lại sẽ tiếp tục chạy và tính tiền; Snapshot giữ dữ liệu với chi phí thấp hơn nhiều.
  • **C. Đặt Snapshot cho cả hai — S3 không hỗ trợ Snapshot; template sẽ không hợp lệ.
  • **D. Dùng stack policy để chặn xoá — stack policy chặn cập nhật tài nguyên, nó không kiểm soát điều gì xảy ra khi xoá stack.

Ghi nhớ

⚠ Ba cơ chế bảo vệ trong CloudFormation — bảng phải thuộc: | Cơ chế | Bảo vệ khỏi | |---|---| | DeletionPolicy | xoá stack | | UpdateReplacePolicy | thay thế khi cập nhật | | Stack policy | cập nhật ngoài ý muốn | | Termination protection | xoá cả stack |

Từ khoá nhận diện:

"data must survive stack deletion" → DeletionPolicy "keep database data but not the instance" → Snapshot "prevent stack from being deleted" → termination protection "prevent specific resource from being updated" → stack policy

Ba lưu ý về DeletionPolicy: Snapshot: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ RDS, EBS, ElastiCache, Redshift, Neptune, DocumentDB | | | Ảnh chụp tính phí lưu trữ | | | Tên ảnh chụp sinh tự động | |

⚠ Xoá stack có Snapshot mất nhiều thời gian:

Chụp ảnh CSDL lớn: hàng chục phút
    → stack ở trạng thái DELETE_IN_PROGRESS
        ↓
    Đừng tưởng nó treo
    → theo dõi tiến độ ảnh chụp trong RDS

Ba lưu ý về Retain: | Lưu ý | Chi tiết | |---|---| | Tài nguyên thành "mồ côi", không stack nào quản | | | Vẫn tính tiền như thường | | | Phải dọn thủ công nếu không cần nữa | |

⚠ Tài nguyên mồ côi tích tụ là chi phí ẩn thật sự:

Mỗi lần xoá stack thử nghiệm
    → để lại bucket, volume, instance
        ↓
    Sau một năm: hàng chục tài nguyên
      không ai nhớ của cái gì
    → gắn tag `Stack` để truy nguồn gốc

Ba lưu ý về stack policy: | Lưu ý | Chi tiết | |---|---| | JSON mô tả tài nguyên nào không được cập nhật | | | Áp khi UpdateStack, không áp khi xoá | | | Ghi đè tạm bằng --stack-policy-during-update-body | |

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

Ba lưu ý về thao tác thay thế: | Lưu ý | Chi tiết | |---|---| | Đổi thuộc tính bất biến gây tạo mới | | | Change set cho biết trước có thay thế không | | | Luôn xem change set với stack sản xuất | |

⚠ Change set là công cụ quan trọng nhất trong danh sách này:

aws cloudformation create-change-set \
  --stack-name stack-san-xuat --change-set-name kiem-tra \
  --template-body file://template.yaml

aws cloudformation describe-change-set \
  --stack-name stack-san-xuat --change-set-name kiem-tra \
  --query 'Changes[?ResourceChange.Replacement==`True`]'

Xem trước cái gì sẽ bị THAY THẾ
    → phát hiện mất dữ liệu TRƯỚC khi xảy ra

Ba lưu ý về khôi phục từ ảnh chụp RDS: | Lưu ý | Chi tiết | |---|---| | Tạo instance MỚI, không ghi đè cái cũ | | | Endpoint đổi, phải cập nhật ứng dụng | | | Nhóm tham số và security group phải khai lại | |

Ba lưu ý về S3 khi giữ lại: | Lưu ý | Chi tiết | |---|---| | Bật versioning để chống xoá nhầm object | | | Object Lock cho dữ liệu tuân thủ | | | Vòng đời chuyển sang lớp rẻ hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoá stack thử ở môi trường thấp | | | Kiểm bucket còn và ảnh chụp đã tạo | | | Thử khôi phục từ ảnh chụp đó | |

Và một lời khuyên: hãy khai UpdateReplacePolicy mỗi khi khai DeletionPolicy. Trường hợp mất dữ liệu thực tế hiếm khi đến từ việc xoá stack — người ta cẩn thận với thao tác đó. Nó đến từ một lần cập nhật trông vô hại làm CloudFormation quyết định thay thế tài nguyên.

Câu 93 Domain - Design Solutions for Organizational Complexity

A leading fast-food chain has recently adopted a hybrid cloud infrastructure that extends its data centers into AWS Cloud. The solutions architect has been tasked to allow on-premises users, who are already signed in using their corporate accounts, to manage AWS resources without creating separate IAM users for each of them. This is to avoid having two separate login accounts and memorizing multiple credentials.

Which of the following is the best way to handle user authentication in this hybrid architecture?

  1. A Authenticate through your on-premises SAML 2.0-compliant identity provider (IDP) using STS and AssumeRoleWithWebIdentity to retrieve temporary security credentials, which enables your users to log in to the AWS console using a browser.
  2. B Retrieve AWS temporary security credentials with Web Identity Federation using STS and AssumeRoleWithWebIdentity to enable users to log in to the AWS console.
  3. C

    Authenticate using your on-premises SAML 2.0-compliant identity provider (IDP), retrieve temporary credentials using STS, and grant federated access to the AWS console via the AWS IAM Identity Center.
  4. D

    Integrate the company’s authentication process with Amazon AppFlow and allow Amazon STS to retrieve temporary AWS credentials using OAuth 2.0 to enable your members to log in to the AWS Console.
Xem giải thích

Đáp án

C — Dùng IdP SAML 2.0 tại chỗ liên kết với AWS thông qua STS và IAM Identity Center.

Vì sao đúng

Đề cần nhân viên đăng nhập AWS bằng danh tính doanh nghiệp đã có, và liên kết SAML là cơ chế đúng: | Yêu cầu | Cách đáp ứng | |---|---| | Dùng danh tính đã có tại chỗ | IdP SAML 2.0 là nguồn sự thật | | Không tạo IAM user | STS cấp credential tạm | | Quản lý tập trung nhiều tài khoản | IAM Identity Center |

⚠ Luồng đăng nhập SAML — phải hiểu từng bước:

1. Người dùng vào cổng của IdP
        ↓
2. IdP xác thực (mật khẩu + MFA)
        ↓
3. IdP sinh SAML assertion đã ký
        ↓
4. Trình duyệt POST assertion tới AWS
        ↓
5. AWS gọi `AssumeRoleWithSAML`
   → STS trả credential tạm
        ↓
6. Vào bảng điều khiển với vai trò đã gán

⚠ Điểm mấu chốt: không có credential AWS nào tồn tại lâu dài:

Không có IAM user
    → không có access key
    → không có mật khẩu AWS riêng
        ↓
    Nhân viên nghỉ việc: khoá tài khoản
      ở IdP là xong
    → không phải nhớ dọn ở AWS

Tạo SAML provider:

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

Trust policy của vai trò:

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

⚠ Nhưng IAM Identity Center làm việc này đơn giản hơn nhiều: | Cách | Công sức | |---|---| | SAML federation tự dựng | mỗi tài khoản một SAML provider, mỗi vai trò một trust policy | | IAM Identity Center | nối IdP MỘT LẦN, gán permission set cho mọi tài khoản |

Tổ chức 30 tài khoản, 8 nhóm quyền
    → tự dựng: 240 vai trò phải quản
        ↓
    Identity Center: 8 permission set
    → gán cho nhóm ở tài khoản nào cần

Tạo permission set:

aws sso-admin create-permission-set \
  --instance-arn <arn> \
  --name QuanTriVanHanh \
  --session-duration PT4H

aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn <arn> --permission-set-arn <arn-ps> \
  --managed-policy-arn arn:aws:iam::aws:policy/PowerUserAccess

Gán cho nhóm:

aws sso-admin create-account-assignment \
  --instance-arn <arn> --target-id 444455556666 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn <arn-ps> \
  --principal-type GROUP --principal-id <id-nhom>

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nguồn danh tính, một quy trình nghỉ việc | | | Chính sách mật khẩu và MFA do IdP quyết định | | | Credential tạm, tự hết hạn | |

⚠ Và SCIM tự đồng bộ người dùng:

Thêm người vào nhóm ở IdP
    → SCIM đẩy sang Identity Center
        ↓
    Người đó có quyền ngay
    → không cần thao tác nào ở AWS

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

  • **B. Dùng AD Connector để người dùng đăng nhập — đây là phương án gần nhất và cũng dùng lại danh tính tại chỗ, nhưng AD Connector chủ yếu phục vụ dịch vụ cần thư mục (WorkSpaces, RDS SQL Server); cho đăng nhập bảng điều khiển thì SAML/Identity Center là cách chuẩn.
  • **A. Tạo IAM user cho từng nhân viên — nhân bản danh tính, hai nơi phải quản, và credential tồn tại lâu dài.
  • **D. Dùng Amazon Cognito cho nhân viên — Cognito dành cho người dùng ứng dụng bên ngoài, không phải nhân viên truy cập AWS.

Ghi nhớ

⚠ Bốn dịch vụ danh tính — bảng phải thuộc: | Dịch vụ | Dành cho | |---|---| | IAM Identity Center | nhân viên truy cập AWS | | Cognito | người dùng ứng dụng của bạn | | Directory Service | dịch vụ cần AD thật | | IAM | vai trò cho dịch vụ và ứng dụng |

Từ khoá nhận diện:

"employees sign in with corporate credentials" → IAM Identity Center "app users, social login" → Cognito "WorkSpaces, domain-joined EC2" → Directory Service "SAML 2.0 IdP" → SAML federation hoặc Identity Center

⚠ Hai giao thức liên kết — bảng phải thuộc: | Giao thức | Dùng cho | |---|---| | SAML 2.0 | liên kết doanh nghiệp, đăng nhập bảng điều khiển | | OIDC | ứng dụng web/di động, CI/CD |

Ba lưu ý về AssumeRoleWithSAML: | Lưu ý | Chi tiết | |---|---| | Không cần credential AWS trước đó | | | Thời hạn phiên tối đa 12 giờ | | | Thuộc tính SAML ánh xạ sang thẻ phiên | |

⚠ Thẻ phiên cho phép kiểm soát theo thuộc tính:

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

Người dùng chỉ chạm được tài nguyên
  có tag phòng ban khớp với chính họ
        ↓
    MỘT chính sách cho mọi phòng ban
    → thay vì một chính sách mỗi phòng

Ba lưu ý về IAM Identity Center: | Lưu ý | Chi tiết | |---|---| | Miễn phí | | | Có cổng truy cập liệt kê mọi tài khoản | | | Hỗ trợ CLI qua aws sso login | |

aws configure sso
aws sso login --profile san-xuat

⚠ aws sso login thay thế hoàn toàn access key trong CLI:

Không còn `~/.aws/credentials` chứa khoá
    → mở trình duyệt, đăng nhập, xong
        ↓
    Credential tạm nằm trong cache
    → hết hạn theo phiên

Ba lưu ý về permission set: | Lưu ý | Chi tiết | |---|---| | Định nghĩa một lần, gán nhiều tài khoản | | | Đặt thời hạn phiên phù hợp | | | Chính sách quản lý + chính sách nội tuyến | |

Ba lưu ý về MFA: | Lưu ý | Chi tiết | |---|---| | Bắt buộc ở tầng IdP | | | Hoặc bật MFA của chính Identity Center | | | Ưu tiên WebAuthn hơn TOTP | |

⚠ WebAuthn chống lừa đảo, TOTP thì không:

TOTP: người dùng gõ mã vào trang giả
    → kẻ tấn công dùng lại ngay
        ↓
    WebAuthn: khoá gắn với tên miền
    → trang giả không lấy được chữ ký hợp lệ

Ba lưu ý về kiểm toán: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi tên người dùng liên kết | | | Xem được ai giả nhận vai trò nào | | | Rà soát quyền định kỳ | |

Ba lưu ý về tài khoản gốc: | Lưu ý | Chi tiết | |---|---| | Root vẫn tồn tại và không liên kết được | | | Bật MFA phần cứng cho root | | | Chỉ dùng cho vài thao tác bắt buộc | |

⚠ Đây là điểm hay bị bỏ sót khi triển khai liên kết:

Mọi người dùng qua IdP
    → tưởng đã kiểm soát hết
        ↓
    Root của mỗi tài khoản vẫn đó
    → khoá MFA phần cứng, cất két
    → và cảnh báo mỗi lần root đăng nhập

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập qua cổng IdP vào một tài khoản | | | Khoá tài khoản ở IdP, thử lại — phải bị từ chối | | | Kiểm CloudTrail ghi đúng danh tính | |

Và một lời khuyên: hãy chuyển sang IAM Identity Center ngay cả khi SAML federation tự dựng đang chạy tốt. Số vai trò phải bảo trì tăng theo tích số tài khoản × nhóm quyền — và đó là con số chỉ có tăng, cho tới ngày không ai còn biết vai trò nào đang cấp quyền gì cho ai.

Câu 94 Domain - Design for New Solutions

An e-commerce company is having their annual sale event where buyers will be able to purchase goods at a large discount on their e-commerce website. The e-commerce site will receive millions of visitors in a short period of time when the sale begins. The visitors will first login to the site using either their Facebook or Google credentials and add items to their cart. After purchasing, a page will display the cart items along with the discounted prices. The company needs to build a checkout system that can handle the sudden surge of incoming traffic.

Which of the following is the MOST scalable solution that they should use?

  1. A

    Combine an Elastic Load balancer in front of an Auto Scaling group of web servers with CloudFront for fast delivery. The web servers will first authenticate the users by logging into their social media accounts which are integrated in Amazon Lex, then process the user's purchases and store the cart into a Multi-AZ RDS database.
  2. B

    Use the static website hosting feature of Amazon S3 with the Javascript SDK to authenticate the user login with Amazon Cognito. Set up AWS Global Accelerator to deliver the static content stored in the S3 bucket. Store user purchases in a DynamoDB table and use an IAM Role for managing permissions.
  3. C

    Combine an Elastic Load balancer in front of an Auto Scaling group of web servers with CloudFront for fast delivery. The web servers will first authenticate the users by logging into their social media accounts which are integrated in Amazon Cognito, then process the user's purchases and store them into an SQS queue using IAM Roles for EC2 Instances to gain permissions to the queue. Finally, the items from the queue are retrieved by a set of application servers and stored into a DynamoDB table.
  4. D

    Combine an Elastic Load balancer in front of multiple web servers with CloudFront for fast delivery. The web servers will first authenticate the users by logging into their social media accounts which are integrated in Amazon Cognito. The web servers will process the user's purchases and store them in a DynamoDB table. Use an IAM Role to gain permissions to the DynamoDB table.
Xem giải thích

Đáp án

C — Dùng ELB + Auto Scaling group cho tầng web, CloudFront phân phối nội dung, Cognito xác thực người dùng, và DynamoDB lưu dữ liệu.

Vì sao đúng

Đề mô tả một ứng dụng web toàn cầu có người dùng đăng nhập, và mỗi thành phần lo một tầng: | Tầng | Dịch vụ | Vì sao | |---|---|---| | Phân phối | CloudFront | cache gần người dùng, giảm độ trễ toàn cầu | | Xác thực | Cognito | quản lý người dùng, không tự viết | | Ứng dụng | ELB + ASG | co giãn và chịu lỗi nhiều AZ | | Dữ liệu | DynamoDB | độ trễ thấp ở mọi quy mô |

⚠ Đây là kiến trúc tham chiếu chuẩn cho ứng dụng web trên AWS:

Người dùng
    ↓
CloudFront (cache tĩnh, TLS, WAF)
    ↓
ALB (phân phối, health check)
    ↓
ASG (co giãn theo tải, nhiều AZ)
    ↓
DynamoDB (dữ liệu) + Cognito (danh tính)

⚠ CloudFront không chỉ để cache nội dung tĩnh:

1. Cache tệp tĩnh — giảm tải origin
2. Kết nối TLS chấm dứt ở biên
   → bắt tay nhanh hơn nhiều
3. Đi trên mạng xương sống của AWS
   → nhanh hơn Internet công cộng
        ↓
    Nội dung động cũng hưởng lợi
    → dù không cache được

Bật cache theo hành vi:

aws cloudfront create-distribution --distribution-config '{
  "Origins": {"Quantity": 1, "Items": [{
    "Id": "alb", "DomainName": "alb-abc.ap-southeast-1.elb.amazonaws.com",
    "CustomOriginConfig": {"OriginProtocolPolicy": "https-only"}}]},
  "DefaultCacheBehavior": {
    "TargetOriginId": "alb",
    "ViewerProtocolPolicy": "redirect-to-https",
    "CachePolicyId": "<id-chinh-sach>"},
  "Enabled": true}'

⚠ Cognito lo phần khó nhất của mọi ứng dụng:

Tự viết: lưu mật khẩu, xác nhận email,
  quên mật khẩu, MFA, khoá tài khoản,
  chống dò mật khẩu...
        ↓
    Cognito: có sẵn tất cả
    → và không lưu mật khẩu nào
      trong CSDL của bạn

Bảo vệ tài nguyên bằng authorizer:

aws elbv2 create-rule --listener-arn <arn> --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions '[{"Type":"authenticate-cognito",
    "AuthenticateCognitoConfig": {
      "UserPoolArn":"<arn>", "UserPoolClientId":"<id>",
      "UserPoolDomain":"<domain>"},"Order":1},
    {"Type":"forward","TargetGroupArn":"<arn-tg>","Order":2}]'

⚠ ALB xác thực Cognito ngay tại tầng cân bằng tải:

Không cần viết mã xác thực trong ứng dụng
    → ALB chặn yêu cầu chưa đăng nhập
    → chuyển hướng tới trang đăng nhập Cognito
        ↓
    Ứng dụng nhận header đã có
      thông tin người dùng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi tầng co giãn độc lập | | | Không tự viết phần xác thực | | | Chịu lỗi ở mọi tầng | |

⚠ Và DynamoDB đúng khi mẫu truy cập đơn giản:

Đọc/ghi theo khoá → DynamoDB
        ↓
    Cần join, truy vấn linh hoạt,
      giao dịch phức tạp
    → Aurora
    → chọn theo MẪU TRUY CẬP,
      không theo "cái nào hiện đại hơn"

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

  • **A. Dùng ELB + ASG + RDS, xác thực tự viết trong ứng dụng — đây là phương án gần nhất và hoàn toàn chạy được, nhưng thiếu CloudFront (người dùng toàn cầu chịu độ trễ cao) và tự viết xác thực là phần dễ sai nhất trong bảo mật ứng dụng.
  • **B. Dùng EC2 đơn lẻ với Elastic IP — không co giãn, không chịu lỗi; một máy hỏng là toàn bộ dịch vụ ngừng.
  • **D. Dùng S3 static website cho toàn bộ ứng dụng — chỉ phục vụ nội dung tĩnh, không chạy được logic phía máy chủ mà đề mô tả.

Ghi nhớ

⚠ Bốn tầng của ứng dụng web và lựa chọn từng tầng — bảng phải thuộc: | Tầng | Lựa chọn | |---|---| | Biên | CloudFront, Global Accelerator | | Cân bằng tải | ALB (HTTP), NLB (TCP/UDP) | | Tính toán | EC2+ASG, ECS/Fargate, Lambda | | Dữ liệu | DynamoDB (khoá), Aurora (quan hệ) |

Từ khoá nhận diện:

"global users, low latency" → CloudFront "user sign-up and sign-in" → Cognito "scale automatically" → Auto Scaling group "static IP, non-HTTP" → Global Accelerator

⚠ CloudFront và Global Accelerator — bảng phải thuộc: | Tiêu chí | CloudFront | Global Accelerator | |---|---|---| | Cache | có | không | | Giao thức | HTTP/HTTPS | TCP/UDP | | IP | tên miền | IP tĩnh anycast | | Chuyển đổi Region | origin failover | vài giây |

Ba lưu ý về Auto Scaling: | Lưu ý | Chi tiết | |---|---| | Target tracking đơn giản và hiệu quả nhất | | | Scheduled scaling cho đỉnh biết trước | | | Predictive scaling học từ lịch sử | |

⚠ Warm pool giảm thời gian khởi động:

aws autoscaling put-warm-pool \
  --auto-scaling-group-name asg-web \
  --min-size 5 --pool-state Stopped

Instance đã khởi động và cấu hình xong
    → ở trạng thái Stopped, tính phí rất ít
        ↓
    Cần mở rộng: bật lên trong ~30 giây
    → thay vì 5 phút khởi động từ đầu

Ba lưu ý về Cognito: | Lưu ý | Chi tiết | |---|---| | User pool: thư mục và đăng nhập | | | Identity pool: credential AWS tạm | | | Hosted UI tuỳ biến được | |

Ba lưu ý về DynamoDB: | Lưu ý | Chi tiết | |---|---| | Thiết kế bảng theo mẫu truy cập | | | GSI cho truy vấn theo thuộc tính khác | | | Global table cho nhiều Region | |

⚠ "Thiết kế theo mẫu truy cập" là điều ngược với CSDL quan hệ:

Quan hệ: chuẩn hoá trước, truy vấn sau
        ↓
    DynamoDB: liệt kê MỌI câu hỏi trước
    → rồi mới thiết kế khoá
    → thêm mẫu truy cập mới sau
      thường phải thêm GSI hoặc đổi cấu trúc

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | WAF trước CloudFront | | | Instance trong subnet riêng tư | | | Security group phân tầng | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudWatch cho chỉ số từng tầng | | | X-Ray theo dõi yêu cầu xuyên tầng | | | Synthetics kiểm tra chủ động | |

⚠ Synthetics phát hiện lỗi trước người dùng:

aws synthetics create-canary --name kiem-tra-dang-nhap \
  --schedule Expression='rate(5 minutes)' \
  --runtime-version syn-nodejs-puppeteer-9.0 \
  --artifact-s3-location s3://ket-qua-canary/

Chạy kịch bản đăng nhập thật mỗi 5 phút
    → hỏng là biết ngay
    → không chờ người dùng báo

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Savings Plan cho phần tải nền | | | Spot cho phần co giãn | | | CloudFront giảm chi phí truyền dữ liệu ra | |

⚠ Điểm cuối là khoản tiết kiệm hay bị bỏ qua:

Truyền dữ liệu ra từ EC2/ALB: đắt hơn
    → cùng dữ liệu đi qua CloudFront: rẻ hơn
        ↓
    Và phần đã cache thì không tính
      truyền từ origin chút nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ nhiều châu lục | | | Tắt một AZ, xem dịch vụ còn chạy | | | Đẩy tải xem ASG có mở rộng kịp không | |

Và một lời khuyên: hãy đo thời gian ASG cần để thêm một instance trước khi tin vào nó. Chính sách co giãn nhìn rất yên tâm trên giấy, nhưng nếu instance mất năm phút để sẵn sàng phục vụ thì đợt tăng tải trong ba phút đã kết thúc — cùng với sự kiên nhẫn của người dùng.

Câu 95 Chọn nhiều đáp án Domain - Design for New Solutions

An insurance company collects contributions from its clients and invests them in the stock market. Using the on-premises data center, the company ingests raw data feeds from the stock market, transforms it, and sends it to the internal Apache Kafka cluster for processing. The management wants to send the cluster’s output to Amazon Web Services by building a scalable and near-real-time solution that will provide the stock market data to its web application. The application is a critical production component so the solution needs to have a consistent high-performance network.

Which of the following actions should the solutions architect implement to fulfill the requirements? (Select THREE.)

  1. A

    Fetch the messages from the on-premises Apache Kafka cluster by using a fleet of EC2 instances in an Auto Scaling Group. Send the data into an Amazon Kinesis Data Stream by using Amazon Kinesis Consumer Library.
  2. B

    To have a consistent performance while being cost-effective, configure a Site-to-Site VPN from the on-premises data center to the AWS VPC.
  3. C

    Pull the messages from the on-premises Apache Kafka cluster by using a fleet of Amazon EC2 instances in an Auto Scaling Group. Send the data into an Amazon Kinesis Data Stream by using Amazon Kinesis Producer Library.
  4. D

    To have consistent performance, request for an AWS Direct Connect connection from the on-premises data center to the AWS VPC.
  5. E

    Write a Lambda function to process the Amazon Kinesis data stream and create a WebSocket API in Amazon API Gateway to invoke the function. Send the callback messages to connected clients by using the @connections command for the API.
  6. F

    Write a Lambda function to process the Amazon Kinesis data stream and write a GraphQL API in AWS AppSync to invoke the function. Send the callback messages to connected clients by using the @connections command for the API.
Xem giải thích

Đáp án

C, D và E — Kéo thông điệp từ cụm Kafka tại chỗ bằng đội EC2 trong Auto Scaling group, đẩy vào Kinesis Data Stream bằng Kinesis Producer Library; xin AWS Direct Connect để có hiệu năng mạng ổn định; và viết Lambda xử lý luồng Kinesis, dùng WebSocket API của API Gateway với lệnh @connections để đẩy về client.

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi phương án lo một cái: | Yêu cầu | Cách đáp ứng | |---|---| | Đưa dữ liệu từ Kafka tại chỗ lên AWS | EC2 đọc Kafka + KPL ghi vào Kinesis | | Mạng hiệu năng cao và ỔN ĐỊNH | Direct Connect | | Đẩy dữ liệu gần thời gian thực về web app | WebSocket API |

⚠ Producer hay Consumer Library — đây là chỗ phân biệt C với A:

Đội EC2 ĐỌC từ Kafka
    → rồi GHI vào Kinesis
        ↓
    Ghi vào Kinesis = PRODUCER
    → Kinesis Producer Library (KPL)
        ↓
    KCL là để ĐỌC TỪ Kinesis
    → dùng ở đây là sai chiều

⚠ Và Direct Connect là lựa chọn duy nhất cho "hiệu năng ổn định": | Tiêu chí | Site-to-Site VPN | Direct Connect | |---|---|---| | Đường đi | qua Internet công cộng | đường riêng | | Băng thông | tối đa 1,25 Gbps mỗi tunnel | 1, 10, 100 Gbps | | Độ trễ | thay đổi theo Internet | ổn định | | Chi phí | thấp | cao hơn |

Đề nói "consistent high-performance network"
  cho thành phần sản xuất quan trọng
        ↓
    VPN không cam kết được độ trễ
    → dù phương án B có chữ "cost-effective"

Ghi vào Kinesis bằng KPL:

KinesisProducerConfiguration cauHinh =
    new KinesisProducerConfiguration()
        .setRegion("ap-northeast-1")
        .setRecordMaxBufferedTime(100);
KinesisProducer bo_ghi = new KinesisProducer(cauHinh);
bo_ghi.addUserRecord("luong-chung-khoan", maCoPhieu,
                     ByteBuffer.wrap(duLieu));

⚠ KPL gộp nhiều bản ghi nhỏ thành một lời gọi:

Dữ liệu chứng khoán: rất nhiều bản ghi nhỏ
    → mỗi bản ghi một `PutRecord`
    → chạm giới hạn 1.000 bản ghi/giây/shard
        ↓
    KPL tự gộp (aggregation)
    → hàng nghìn bản ghi trong một lời gọi
    → tăng thông lượng nhiều lần

WebSocket API đẩy dữ liệu về trình duyệt:

import boto3
api = boto3.client('apigatewaymanagementapi',
    endpoint_url='https://<id>.execute-api.<vung>.amazonaws.com/prod')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        du_lieu = ban_ghi['kinesis']['data']
        for ma_ket_noi in danh_sach_ket_noi():
            api.post_to_connection(
                ConnectionId=ma_ket_noi, Data=du_lieu)

⚠ Vì sao WebSocket chứ không phải HTTP polling:

Polling mỗi giây: độ trễ trung bình 500ms
    + hàng nghìn yêu cầu rỗng
        ↓
    WebSocket: máy chủ đẩy ngay khi có dữ liệu
    → độ trễ vài chục mili giây
    → và ít lời gọi hơn rất nhiều

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đổi hệ thống Kafka đang chạy | | | Kinesis làm bộ đệm, xử lý được đỉnh tải | | | Đẩy dữ liệu thẳng về trình duyệt | |

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

  • **F. Dùng AppSync với GraphQL API và lệnh @connections — đây là phương án gần nhất và AppSync thật sự hỗ trợ đăng ký thời gian thực, nhưng lệnh @connections là của WebSocket API trong API Gateway, AppSync dùng cơ chế subscription khác; hai thứ này không lắp lẫn nhau được.
  • **A. Dùng Kinesis Consumer Library để đẩy dữ liệu VÀO Kinesis — sai chiều: KCL dùng để đọc ra khỏi Kinesis.
  • **B. Dùng Site-to-Site VPN cho hiệu năng ổn định — VPN đi qua Internet công cộng, không cam kết được độ trễ.

Ghi nhớ

⚠ KPL và KCL — bảng phải thuộc: | Thư viện | Chiều | Việc chính | |---|---|---| | KPL (Producer) | GHI vào Kinesis | gộp bản ghi, thử lại, ghi bất đồng bộ | | KCL (Consumer) | ĐỌC từ Kinesis | chia shard, lưu checkpoint |

Từ khoá nhận diện:

"consistent, predictable network performance" → Direct Connect "cost-effective connection to on-premises" → Site-to-Site VPN "push data to connected clients" → WebSocket API "write to Kinesis at high rate" → KPL

⚠ Nhưng có lựa chọn còn ít việc hơn cho phần Kafka:

Amazon MSK Connect hoặc MSK Replicator
    → nhân bản Kafka tại chỗ sang MSK
        ↓
    Không cần đội EC2 tự viết
    → và giữ nguyên giao diện Kafka
      cho ứng dụng phía sau

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Mất hàng tuần tới hàng tháng để cung cấp | | | Một kết nối là một điểm hỏng — cần hai | | | VPN làm đường dự phòng cho DX | |

⚠ Mẫu kết hợp DX và VPN là thực hành chuẩn:

DX làm đường chính (BGP ưu tiên cao)
    + VPN làm đường dự phòng
        ↓
    DX đứt: BGP tự chuyển sang VPN
    → chậm hơn nhưng không mất kết nối

Ba loại virtual interface: | Loại | Tới | |---|---| | Private VIF | VPC qua VGW hoặc DX Gateway | | Public VIF | dịch vụ công khai của AWS (S3, DynamoDB) | | Transit VIF | Transit Gateway |

Ba lưu ý về WebSocket API: | Lưu ý | Chi tiết | |---|---| | Ba route mặc định: $connect, $disconnect, $default | | | Lưu ma kết nối vào DynamoDB | | | Kết nối rớt phải dọn khỏi bảng | |

try:
    api.post_to_connection(ConnectionId=ma, Data=d)
except api.exceptions.GoneException:
    xoa_ket_noi(ma)   # client da ngat

Ba lưu ý về Kinesis cho dữ liệu tài chính: | Lưu ý | Chi tiết | |---|---| | Khoá phân vùng theo mã cổ phiếu giữ thứ tự | | | Enhanced fan-out cho độ trễ thấp | | | Theo dõi IteratorAgeMilliseconds | |

Ba lưu ý về Lambda đọc Kinesis: | Lưu ý | Chi tiết | |---|---| | Một lô lỗi chặn cả shard | | | Đặt MaximumRetryAttempts và DLQ | | | ParallelizationFactor tăng đồng thời mỗi shard | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ Kafka tới trình duyệt | | | Kiểm WriteProvisionedThroughputExceeded | | | Ngắt DX thử, xem VPN có tiếp quản | |

Và một lời khuyên: hãy đặt hàng Direct Connect sớm hơn bạn nghĩ là cần. Thời gian cung cấp tính bằng tuần chứ không phải phút, và không có cách nào rút ngắn nó khi dự án đã đến hạn.

Câu 96 Domain - Design for New Solutions

A multinational healthcare company plans to launch a new MedTech information website. The solutions architect decided to use Amazon CloudFormation to deploy a three-tier web application that consists of a web tier, an application tier, and a database tier that will utilize Amazon DynamoDB for storage. The solutions architect must secure any credentials that are used to access the database tier.

Which of the following options will allow the application instances access to the DynamoDB tables without exposing API credentials?

  1. A

    Have the user enter the access and secret keys of an existing IAM User that has permissions to read and write from the DynamoDB table instead of using the Parameter section in the CloudFormation template.
  2. B Create an IAM User in the CloudFormation template and assign permissions to read and write from the DynamoDB table. Then retrieve the values of the access and secret keys using CloudFormation's GetAtt function, and pass them to the application instance through user-data.
  3. C

    Create an IAM Role that grants access to the DynamoDB table. Use the AWS::SSM::Parameter resource that creates an SSM parameter in AWS Systems Manager Parameter Store containing the Amazon Resource Name of the IAM role. Have the instance profile property of the application instance reference the role.
  4. D Create an IAM Role and assign the required permissions to read and write from the DynamoDB table. Have the instance profile property of the application instance reference the role.
Xem giải thích

Đáp án

D — Tạo IAM role có quyền đọc/ghi bảng DynamoDB, và đặt thuộc tính instance profile của instance trỏ tới vai trò đó.

Vì sao đúng

Đề hỏi cách cho instance truy cập DynamoDB mà không lộ credential, và IAM role là câu trả lời duy nhất:

Instance profile gắn vai trò vào EC2
    → EC2 lấy credential TẠM từ
      instance metadata
        ↓
    Credential tự xoay vòng
    → không có khoá nào trong
      template, user-data, hay đĩa

⚠ Ba đặc tính khiến IAM role vượt trội: | Đặc tính | Chi tiết | |---|---| | Credential TẠM, tự hết hạn | | | AWS tự xoay trước khi hết hạn | | | Không có gì để rò rỉ hay phải xoay tay | |

Khai trong CloudFormation:

Resources:
  VaiTroUngDung:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Principal: {Service: ec2.amazonaws.com}
            Action: sts:AssumeRole
      Policies:
        - PolicyName: TruyCapBang
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action: [dynamodb:GetItem, dynamodb:PutItem,
                         dynamodb:Query, dynamodb:UpdateItem]
                Resource: !GetAtt BangDuLieu.Arn

  HoSoInstance:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Roles: [!Ref VaiTroUngDung]

  MayChuUngDung:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref HoSoInstance

⚠ Instance profile là lớp bọc bắt buộc:

IAM role KHÔNG gắn thẳng vào EC2 được
    → phải qua instance profile
        ↓
    Bảng điều khiển tạo ngầm cho bạn
    → nhưng CloudFormation phải khai
      TƯỜNG MINH

SDK tự lấy credential, không cần viết gì:

import boto3
bang = boto3.resource('dynamodb').Table('DonHang')
bang.put_item(Item={'idDonHang': 'DH-001'})

Chuỗi tìm credential của SDK:
    biến môi trường → tệp cấu hình
    → container credential
    → INSTANCE METADATA
        ↓
    Không khai gì thì SDK tự tìm tới
      metadata và dùng vai trò

⚠ Và phải dùng IMDSv2:

aws ec2 modify-instance-metadata-options \
  --instance-id i-abc --http-tokens required \
  --http-endpoint enabled

IMDSv1: một lời gọi GET là lấy được credential
    → lỗ hổng SSRF trong ứng dụng
      đủ để đánh cắp
        ↓
    IMDSv2: bắt buộc PUT lấy token trước
    → chặn được phần lớn tấn công SSRF

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có khoá tĩnh nào tồn tại | | | Sửa quyền là có hiệu lực ngay, không phải triển khai lại | | | CloudTrail ghi rõ vai trò nào gọi API | |

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

  • **C. Tạo IAM role rồi lưu ARN của nó vào Parameter Store và cho instance profile trỏ tới vai trò — đây là phương án gần nhất và phần instance profile hoàn toàn đúng, nhưng bước lưu ARN vào Parameter Store là thừa hoàn toàn: instance không cần biết ARN vai trò của chính nó.
  • **B. Tạo IAM user trong template, lấy access key bằng GetAtt rồi truyền qua user-data — user-data đọc được từ instance metadata và hiện trong bảng điều khiển; đây chính là "lộ credential".
  • **A. Cho người dùng nhập access key và secret key — credential tĩnh, phải xoay tay, và nằm trong lịch sử stack.

Ghi nhớ

⚠ Bốn cách sai điển hình khi cấp quyền cho EC2:

Nhúng khoá vào mã          → rò rỉ qua kho mã
Đặt khoá trong user-data   → đọc được từ metadata
Truyền khoá qua tham số CF → nằm trong lịch sử stack
Ghi khoá vào tệp cấu hình  → ai đọc được đĩa là lấy được
        ↓
    Tất cả đều thay được bằng IAM role

Từ khoá nhận diện:

"without exposing credentials" → IAM role + instance profile "application on EC2 needs AWS access" → IAM role "application needs a database password" → Secrets Manager "on-premises server needs AWS access" → IAM Roles Anywhere

Ba lưu ý về instance profile: | Lưu ý | Chi tiết | |---|---| | Một instance profile chứa đúng một vai trò | | | Gắn/đổi được trên instance đang chạy | | | CloudFormation phải khai tường minh | |

⚠ Đổi vai trò trên instance đang chạy:

aws ec2 replace-iam-instance-profile-association \
  --association-id iip-assoc-abc \
  --iam-instance-profile Name=HoSoMoi

Không cần khởi động lại
    → credential mới có hiệu lực
      trong vài phút

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Chỉ cấp API thật sự dùng | | | Giới hạn Resource theo ARN bảng | | | IAM Access Analyzer sinh chính sách từ CloudTrail | |

aws accessanalyzer start-policy-generation \
  --policy-generation-details \
    principalArn=arn:aws:iam::111122223333:role/VaiTroUngDung

Ba lưu ý về IMDS: | Lưu ý | Chi tiết | |---|---| | Địa chỉ 169.254.169.254 | | | IMDSv2 bắt buộc token, chống SSRF | | | Tắt hẳn nếu instance không cần vai trò | |

Ba lưu ý về DynamoDB và IAM: | Lưu ý | Chi tiết | |---|---| | Giới hạn theo bảng và chỉ mục | | | dynamodb:LeadingKeys cô lập theo dòng | | | dynamodb:Attributes giới hạn cột | |

Ba lưu ý về CloudFormation và bí mật: | Lưu ý | Chi tiết | |---|---| | Không đặt bí mật trong tham số | | | Dùng dynamic reference tới Secrets Manager | | | NoEcho chỉ che hiển thị, không bảo vệ | |

Ba lưu ý về ECS và Lambda: | Dịch vụ | Cơ chế | |---|---| | ECS | task role, không phải instance role | | Lambda | execution role | | EKS | IRSA hoặc Pod Identity |

⚠ Task role và instance role trên ECS là hai thứ khác nhau:

Instance role: quyền của MÁY CHỦ chạy container
    → kéo image, ghi log
        ↓
    Task role: quyền của CHÍNH ứng dụng
    → gọi DynamoDB, S3
        ↓
    Đặt nhầm chỗ: mọi container trên máy
      đó có chung quyền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl metadata xem có credential | | | Thử thao tác ngoài phạm vi — phải bị từ chối | | | Kiểm CloudTrail ghi đúng vai trò | |

Và một lời khuyên: hãy bắt buộc IMDSv2 ở mức tài khoản chứ đừng đặt từng instance. Vai trò IAM chỉ an toàn khi cửa lấy credential được khoá — và một instance sót lại với IMDSv1 là đủ để một lỗ hổng SSRF thông thường trở thành sự cố rò rỉ credential.

Câu 97 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

A company runs a cryptocurrency analytics website and uses a CloudFront distribution with a custom domain name (tutorialsdojo.com) to speed up the loading time of the site. Since the data being distributed are quite confidential, the management instructed the solutions architect to require HTTPS communication between the viewers (web visitors) and the CloudFront distribution. Additionally, it is required to improve the performance by increasing the proportion of your viewer requests that are served from CloudFront edge caches instead of going to your origin servers.

Which of the following are the recommended actions to accomplish the above requirement? (Select TWO.)

  1. A

    Import an SSL/TLS certificate from a third-party certificate authority into a private S3 bucket with versioning and MFA enabled.
  2. B Use an SSL/TLS certificate provided by AWS Certificate Manager (ACM).
  3. C

    Integrate your CloudFront web distribution with Amazon OpenSearch to cache recent requests and improve the performance of your origin servers. Use Kibana to visualize the cache hit-ratio graph in real time.
  4. D

    Configure the CloudFront origin to add a Cache-Control max-age directive to your objects and specify the longest practical value for max-age.
  5. E

    Associate your CloudFront web distribution with Lambda@Edge which provides automatic scalability from a few requests per day to thousands of requests per second.
Xem giải thích

Đáp án

B và D — Dùng chứng chỉ SSL/TLS của AWS Certificate Manager (ACM); và cấu hình origin thêm chỉ thị Cache-Control: max-age với giá trị dài nhất có thể chấp nhận được.

Vì sao đúng

Đề nêu hai yêu cầu tách biệt, và mỗi phương án lo một cái: | Yêu cầu | Cách đáp ứng | |---|---| | Bắt buộc HTTPS giữa người xem và CloudFront | chứng chỉ ACM cho tên miền tuỳ chỉnh | | Tăng tỷ lệ phục vụ từ cache biên | max-age dài |

⚠ ACM là lựa chọn đúng vì ba lý do:

1. MIỄN PHÍ khi dùng với CloudFront
2. TỰ GIA HẠN — không hết hạn bất ngờ
3. Khoá riêng KHÔNG xuất được
        ↓
    Chứng chỉ mua ngoài: tốn tiền,
      phải nhớ gia hạn mỗi năm

⚠ Nhưng có ràng buộc Region tuyệt đối:

Chứng chỉ dùng cho CloudFront
    → BẮT BUỘC ở us-east-1
        ↓
    Dù phân phối là toàn cầu
    → yêu cầu ở Region khác thì
      CloudFront không thấy nó

Đây là lỗi cấu hình phổ biến nhất với CloudFront.

aws acm request-certificate --region us-east-1 \
  --domain-name tutorialsdojo.com \
  --subject-alternative-names '*.tutorialsdojo.com' \
  --validation-method DNS

Bắt buộc HTTPS ở phân phối:

{"DefaultCacheBehavior": {
  "ViewerProtocolPolicy": "redirect-to-https"},
 "ViewerCertificate": {
  "ACMCertificateArn": "<arn>",
  "SSLSupportMethod": "sni-only",
  "MinimumProtocolVersion": "TLSv1.2_2021"}}

⚠ Còn max-age là thứ QUYẾT ĐỊNH tỷ lệ trúng cache:

Origin không gửi Cache-Control
    → CloudFront dùng Default TTL (24 giờ)
        ↓
    Origin gửi max-age=31536000
    → object nằm ở biên gần một năm
    → yêu cầu gần như không bao giờ
      chạm tới origin

Đặt header ở origin S3:

aws s3 cp anh.jpg s3://bucket/ \
  --cache-control "public, max-age=31536000, immutable"

⚠ Ba header điều khiển cache — bảng phải thuộc: | Header | Tác dụng | |---|---| | Cache-Control: max-age | thời gian cache ở CẢ trình duyệt và CloudFront | | Cache-Control: s-maxage | chỉ cho cache dùng chung (CloudFront), đè max-age | | Expires | mốc thời gian tuyệt đối, cách cũ |

`s-maxage` cho phép tách biệt:
    trình duyệt cache 5 phút
    + CloudFront cache 1 ngày
        ↓
    Cache-Control: max-age=300, s-maxage=86400

⚠ Và mẹo dùng max-age dài mà vẫn cập nhật được ngay:

Đặt mã băm nội dung vào tên tệp
    app-a3f9c2.js
        ↓
    Nội dung đổi → tên đổi → URL mới
    → không cần xoá cache bao giờ
    → và đặt max-age=31536000, immutable

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | HTTPS miễn phí và tự gia hạn | | | Giảm mạnh tải lên origin | | | Người dùng nhận nội dung từ điểm gần nhất | |

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

  • **E. Gắn Lambda@Edge vào phân phối — đây là phương án gần nhất và Lambda@Edge có thật và chạy ở biên, nhưng nó không làm tăng tỷ lệ trúng cache; ngược lại, hàm chạy ở viewer request còn chạy trên mọi yêu cầu kể cả yêu cầu trúng cache.
  • **A. Nhập chứng chỉ từ CA bên ngoài vào bucket S3 riêng tư — chứng chỉ dùng cho CloudFront phải nằm trong ACM hoặc IAM certificate store, không phải trong S3.
  • **C. Tích hợp CloudFront với Amazon OpenSearch để cache — OpenSearch là công cụ tìm kiếm và phân tích, nó không phải lớp cache cho CDN.

Ghi nhớ

⚠ Năm yếu tố quyết định tỷ lệ trúng cache — theo mức ảnh hưởng:

1. TTL / max-age — lớn nhất
2. Cache key: bớt header/cookie/query string
3. Nén (Gzip/Brotli) — bản nén cũng được cache
4. Origin Shield — thêm một tầng cache
5. Tách nội dung tĩnh khỏi động

⚠ Cache key rộng làm hỏng cache mà không ai để ý:

Chuyển tiếp TẤT CẢ cookie tới origin
    → mỗi người dùng có cookie phiên riêng
        ↓
    Mỗi người dùng = một mục cache riêng
    → tỷ lệ trúng gần bằng 0
    → chỉ chuyển tiếp cookie THẬT SỰ
      ảnh hưởng nội dung

Chính sách cache tối thiểu:

aws cloudfront create-cache-policy --cache-policy-config '{
  "Name": "tinh-toi-uu",
  "DefaultTTL": 86400, "MaxTTL": 31536000, "MinTTL": 1,
  "ParametersInCacheKeyAndForwardedToOrigin": {
    "EnableAcceptEncodingGzip": true,
    "EnableAcceptEncodingBrotli": true,
    "HeadersConfig": {"HeaderBehavior": "none"},
    "CookiesConfig": {"CookieBehavior": "none"},
    "QueryStringsConfig": {"QueryStringBehavior": "none"}}}'

Từ khoá nhận diện:

"increase cache hit ratio" → max-age dài, cache key hẹp "HTTPS with custom domain" → ACM ở us-east-1 "reduce origin load further" → Origin Shield "restrict access to content" → signed URL/cookie

Ba lưu ý về Origin Shield: | Lưu ý | Chi tiết | |---|---| | Thêm một tầng cache khu vực trước origin | | | Nhiều POP trượt cache chỉ gọi origin một lần | | | Có phí, chọn Region gần origin | |

Ba lưu ý về xoá cache: | Lưu ý | Chi tiết | |---|---| | 1.000 đường dẫn miễn phí mỗi tháng | | | Xoá bằng wildcard /* mất vài phút | | | Đổi tên tệp tốt hơn xoá cache | |

Ba lưu ý về nén: | Lưu ý | Chi tiết | |---|---| | CloudFront tự nén 1 KB tới 10 MB | | | Cần chuyển tiếp Accept-Encoding | | | Brotli nhỏ hơn Gzip khoảng 15-20% | |

Ba lưu ý về chỉ số: | Chỉ số | Ý nghĩa | |---|---| | CacheHitRate | tỷ lệ phục vụ từ biên | | OriginLatency | origin đáp chậm hay nhanh | | 4xxErrorRate / 5xxErrorRate | lỗi phía nào |

⚠ Bật chỉ số bổ sung để thấy CacheHitRate:

aws cloudfront create-monitoring-subscription \
  --distribution-id <id> \
  --monitoring-subscription \
    RealtimeMetricsSubscriptionConfig={RealtimeMetricsSubscriptionStatus=Enabled}

Chỉ số mặc định KHÔNG có tỷ lệ trúng cache
    → phải bật riêng và có phí
        ↓
    Không bật thì tối ưu cache
      mà không đo được kết quả

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | OAC để bucket không cần công khai | | | WAF trước CloudFront cho tầng 7 | | | MinimumProtocolVersion từ TLS 1.2 | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem header X-Cache: Hit from cloudfront | | | Theo dõi CacheHitRate trước và sau | | | Kiểm chứng chỉ bằng openssl s_client | |

Và một lời khuyên: hãy xem lại cache key trước khi nghĩ tới việc kéo dài TTL. Một TTL một năm cũng vô dụng nếu cache key gồm cả cookie phiên — mỗi người dùng khi đó có một bản sao riêng, và cache thực chất không tồn tại.

Câu 98 Domain - Design for New Solutions

A startup is running a data processing application on AWS. The application is hosted on 25 Amazon EC2 On-Demand Instances, distributed across three Availability Zones, and registered with a target group for a Network Load Balancer (NLB).

Reports indicate a sharp decline in performance during high-demand periods, with CPU utilization spiking to 90%-100%. During normal operations, utilization averages only 20%. The application is stateless and needs to ensure consistent response times even during peak traffic.

The company wants to improve application performance while optimizing costs over the next three years.
Which solution is the most cost-effective for addressing this issue?

  1. A

    Replace the On-Demand Instances with a Spot Fleet request type of request. Configure the InstanceInterruptionBehavior to stop and TotalTargetCapacity parameter to 30. Attach the Spot Fleet to the NLB.
  2. B

    Configure an ASG (Auto Scaling Group) and attach it to the Network Load Balancer. Set the capacity to a minimum of 15 instances and a maximum of 25. Purchase Reserved Instances for 15 instances.
  3. C

    Replace the On-Demand Instances with a Spot Fleet request type of request and with EBS-optimized enabled. Set the TotalTargetCapacity parameter to 25 and DefaultTargetCapacityType parameter to Spot. Attach the Spot Fleet to the NLB.
  4. D

    Configure an Auto Scaling group and attach it to the NLB. Set the minimum capacity to 5 instances and the maximum capacity to 30. Purchase Reserved Instances for 5 instances.
Xem giải thích

Đáp án

D — Cấu hình Auto Scaling group gắn vào NLB, đặt công suất tối thiểu 5 và tối đa 30 instance, và mua Reserved Instance cho 5 instance.

Vì sao đúng

Đề cho đủ số liệu để tính, và phương án này khớp với phép tính: | Dữ kiện | Suy ra | |---|---| | 25 instance, bình thường CPU 20% | tải nền chỉ cần ~5 instance | | Cao điểm CPU 90-100% | cần nhiều hơn 25 khi đỉnh | | Ứng dụng stateless | co giãn thoải mái | | Tối ưu chi phí trong 3 năm | RI cho phần nền |

⚠ Phép tính công suất nền:

25 instance chạy ở 20% CPU
    → tổng công việc = 25 × 0,20 = 5 đơn vị
        ↓
    5 instance chạy ở 100%... quá sát
    → nhưng đây là ĐÁY, ASG tự thêm khi tải lên
    → min = 5 là hợp lý

⚠ Và trần 30 giải quyết đúng vấn đề đề nêu:

25 instance ở 90-100% khi cao điểm
    → THIẾU công suất
        ↓
    Trần 25 (phương án B) giữ nguyên
      vấn đề hiệu năng
    → trần 30 mới cho dư địa

Đây là lý do phương án B sai dù nó cũng dùng ASG và RI.

⚠ Mua RI đúng bằng phần ĐÁY, không hơn:

RI/Savings Plan: cam kết 1-3 năm
    → giảm tới 72% so với On-Demand
        ↓
    Nhưng trả tiền dù có dùng hay không
    → mua theo mức TỐI THIỂU luôn chạy
    → phần co giãn để On-Demand hoặc Spot

Cấu hình:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name asg-xu-ly \
  --min-size 5 --max-size 30 --desired-capacity 5 \
  --target-group-arns <arn-tg> \
  --health-check-type ELB --health-check-grace-period 300 \
  --vpc-zone-identifier "subnet-1a,subnet-1b,subnet-1c"

Chính sách co giãn theo CPU:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-xu-ly \
  --policy-name theo-cpu --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 60.0,
    "PredefinedMetricSpecification":
      {"PredefinedMetricType": "ASGAverageCPUUtilization"}}'

⚠ Đặt mục tiêu 60% chứ không phải 90%:

Mục tiêu 90%: ASG chỉ thêm máy khi
  đã gần cạn công suất
        ↓
    Máy mới mất vài phút để sẵn sàng
    → trong lúc đó người dùng chịu chậm
        ↓
    Mục tiêu 60%: có biên để mở rộng kịp

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giải quyết được đỉnh tải (trần 30) | | | Chỉ trả tiền 5 máy khi rảnh thay vì 25 | | | RI giảm mạnh chi phí phần nền | |

⚠ Và Savings Plan linh hoạt hơn RI trong nhiều trường hợp: | Tiêu chí | Reserved Instance | Compute Savings Plan | |---|---|---| | Ràng buộc | họ instance, Region | cam kết USD/giờ | | Áp cho | EC2 | EC2, Fargate, Lambda | | Đổi loại máy | hạn chế | tự do |

Không chắc dùng loại máy nào trong 3 năm
    → Compute Savings Plan
        ↓
    Chắc chắn về loại và Region
    → RI có chiết khấu nhỉnh hơn

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

  • **B. ASG với min 15, max 25 và RI cho 15 — đây là phương án gần nhất và cũng dùng ASG + RI, nhưng trần 25 giữ nguyên vấn đề thiếu công suất khi cao điểm, và min 15 là mua thừa công suất cho giai đoạn tải nhẹ.
  • **A. Dùng Spot Fleet với InstanceInterruptionBehavior=stop, tổng công suất 30 — Spot bị thu hồi bất kỳ lúc nào; đề đòi thời gian phản hồi nhất quán, không hợp với công suất có thể biến mất trong 2 phút.
  • **C. Dùng Spot Fleet toàn bộ 25 instance — cùng vấn đề thu hồi, lại còn giữ nguyên trần 25.

Ghi nhớ

⚠ Ba mô hình mua và chỗ dùng — bảng phải thuộc: | Mô hình | Chiết khấu | Dùng cho | |---|---|---| | Reserved / Savings Plan | tới 72% | tải NỀN luôn chạy | | On-Demand | 0 | phần co giãn khó đoán | | Spot | tới 90% | việc chịu được gián đoạn |

⚠ Mẫu kết hợp cả ba trong một ASG:

MixedInstancesPolicy:
  InstancesDistribution:
    OnDemandBaseCapacity: 5
    OnDemandPercentageAboveBaseCapacity: 50
    SpotAllocationStrategy: price-capacity-optimized

5 máy đầu luôn On-Demand (phủ bằng RI)
    → phần trên: một nửa On-Demand,
      một nửa Spot
        ↓
    Vừa ổn định vừa rẻ

Từ khoá nhận diện:

"consistent response times" → KHÔNG dùng Spot cho phần thiết yếu "steady baseline over 3 years" → RI hoặc Savings Plan "fault-tolerant batch processing" → Spot phù hợp "unpredictable spikes" → ASG với trần cao

Ba lưu ý về Spot: | Lưu ý | Chi tiết | |---|---| | Báo trước 2 phút khi thu hồi | | | Đa dạng loại máy giảm rủi ro | | | price-capacity-optimized là chiến lược tốt nhất hiện nay | |

⚠ Đa dạng loại máy là biện pháp quan trọng nhất với Spot:

Chỉ xin m5.large
    → hết công suất loại đó là mất tất cả
        ↓
    Xin 10 loại tương đương
    → xác suất mất hết cùng lúc rất thấp

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | health-check-type ELB chứ không phải EC2 | | | Warm pool rút ngắn thời gian sẵn sàng | | | Trải trên nhiều AZ | |

Ba chính sách co giãn: | Chính sách | Dùng khi | |---|---| | Target tracking | mặc định, đơn giản nhất | | Scheduled | đỉnh biết trước theo giờ | | Predictive | có chu kỳ, học từ lịch sử |

⚠ Predictive scaling giải quyết vấn đề "thêm máy quá muộn":

Target tracking: phản ứng SAU khi tải lên
    → luôn chậm vài phút
        ↓
    Predictive: học chu kỳ tuần
    → thêm máy TRƯỚC khi đỉnh tới
    → kết hợp cả hai là tốt nhất

Ba lưu ý về NLB: | Lưu ý | Chi tiết | |---|---| | Tầng 4, độ trễ cực thấp | | | Cross-zone MẶC ĐỊNH TẮT | | | Bật cross-zone thì tính phí liên AZ | |

Ba lưu ý về đo lường trước khi tối ưu: | Lưu ý | Chi tiết | |---|---| | Compute Optimizer gợi ý loại máy đúng | | | Cost Explorer cho khuyến nghị RI | | | Xem CPU theo phân vị, không chỉ trung bình | |

⚠ Trung bình che mất bức tranh thật:

CPU trung bình 20%
    → nghe như thừa công suất rất nhiều
        ↓
    Nhưng p99 chạm 100% mỗi ngày
    → đó mới là lúc người dùng thấy chậm
    → định cỡ theo phân vị cao

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tải xem ASG mở rộng kịp không | | | Kiểm mức sử dụng RI trong Cost Explorer | | | Đo thời gian instance mới sẵn sàng | |

Và một lời khuyên: hãy mua cam kết dài hạn chỉ cho phần công suất bạn đã đo được là luôn chạy. Reserved Instance mua thừa không giảm hoá đơn — nó chỉ khoá bạn vào việc trả tiền cho công suất nhàn rỗi suốt ba năm.

Câu 99 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

A company that manages hundreds of AWS client accounts has created a central logging service running on an Auto Scaling group of Amazon EC2 instances. The logging service receives logs from the client AWS accounts through the connectivity provided by AWS PrivateLink. The interface endpoint for this is available on each of the client AWS accounts. The EC2 instances hosting the logging service are spread on multiple subnets with a Network Load Balancer in front to spread the incoming load. Upon testing, the clients are unable to submit logs through the VPC endpoint.

Which of the following solutions will most likely resolve the issue? (Select TWO.)

  1. A

    Ensure that the Auto Scaling group is associated with a launch template that includes the latest Amazon Machine Image (AMI) and that the EC2 instances are using instance types that are optimized for log processing.
  2. B

    Ensure that the security group attached to the EC2 instances hosting the logging service allows inbound traffic from the IP address block of the clients.
  3. C

    Ensure that the security group attached to the EC2 instances hosting the logging service allows inbound traffic from the NLB’s security group. Also, ensure that the security group attached to the NLB allows inbound traffic from the interface endpoint subnet.
  4. D

    Ensure that the NACL associated with the logging service subnet allows communication to and from the NLB subnets. Ensure that the NACL associated with the NLB subnets allows communication to and from the EC2 instances subnets running the logging service.
  5. E

    Ensure that the NACL associated with the logging service subnets allows communication to and from the interface endpoint. Ensure that the NACL associated with the interface endpoint subnet allows communication to and from the EC2 instances running the logging service.
Xem giải thích

Đáp án

**C và D — Bảo đảm security group của EC2 cho phép lưu lượng vào từ security group của NLB, và security group của NLB cho phép lưu lượng vào từ subnet của interface endpoint; đồng thời NACL của subnet dịch vụ log và NACL của subnet NLB cho phép lưu lượng hai chiều với nhau.

Vì sao đúng

Đề mô tả PrivateLink không thông, và hai phương án này lo hai tầng lọc khác nhau trên cùng một đoạn đường:

Interface endpoint (tài khoản khách)
        ↓
    NLB (tài khoản dịch vụ log)
        ↓
    EC2 chạy dịch vụ log

⚠ Điều then chốt: NLB KHÔNG giữ lại IP của client:

Interface endpoint → NLB
    → NLB chuyển tiếp tới target
        ↓
    Với target kiểu instance, NLB giữ IP gốc
    → nhưng lưu lượng qua PrivateLink
      đến từ ENI của endpoint
        ↓
    Cấu hình SG theo "dải IP của khách"
      là không đúng mô hình

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

⚠ Và NACL là stateless — phải mở CẢ HAI chiều:

NACL cho phép vào cổng 443
    → phản hồi đi ra cổng tạm 1024-65535
        ↓
    Không mở dải cổng tạm chiều RA
    → kết nối vẫn timeout
    → đây là bẫy kinh điển của NACL

Quy tắc NACL cho subnet dịch vụ log:

aws ec2 create-network-acl-entry --network-acl-id acl-log \
  --rule-number 100 --protocol tcp --port-range From=443,To=443 \
  --cidr-block 10.0.10.0/24 --rule-action allow --ingress

aws ec2 create-network-acl-entry --network-acl-id acl-log \
  --rule-number 100 --protocol tcp \
  --port-range From=1024,To=65535 \
  --cidr-block 10.0.10.0/24 --rule-action allow --egress

Security group tham chiếu lẫn nhau:

aws ec2 authorize-security-group-ingress \
  --group-id sg-may-chu-log --protocol tcp --port 443 \
  --source-group sg-nlb

⚠ NLB có security group từ tháng 8/2023:

Trước đó: NLB KHÔNG có security group
    → phải mở SG của target theo
      CIDR của subnet NLB
        ↓
    Nay: gán SG cho NLB được
    → và tham chiếu SG đó ở target
    → sạch hơn nhiều

aws elbv2 set-security-groups \
  --load-balancer-arn <arn-nlb> \
  --security-groups sg-nlb

⚠ Nhưng chỉ gán được LÚC TẠO NLB:

NLB tạo trước tháng 8/2023 hoặc tạo
  không kèm SG
        ↓
    KHÔNG thêm SG vào sau được
    → phải tạo NLB mới

Ba lợi ích khi sửa đúng: | Lợi ích | Chi tiết | |---|---| | Mở đúng đoạn đường bị chặn | | | Không phải nới lỏng theo dải IP khách hàng | | | Quy tắc tự cập nhật khi thêm instance | |

⚠ Cách gỡ lỗi có hệ thống cho PrivateLink:

1. Endpoint có ở đúng AZ mà NLB có node không?
2. SG của endpoint có cho ra cổng đích?
3. SG/NACL của subnet NLB?
4. SG/NACL của subnet target?
5. Health check của target group có PASS?
6. Endpoint service có chấp nhận kết nối chưa?

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

  • **E. Bảo đảm NACL của subnet dịch vụ log và subnet của interface endpoint cho phép lưu lượng hai chiều — đây là phương án gần nhất và đúng về mặt logic NACL, nhưng nó bỏ qua chặng NLB ở giữa: lưu lượng không đi thẳng từ endpoint tới EC2, và các subnet đó nằm ở tài khoản khác, không cùng VPC để NACL áp lên nhau.
  • **B. Cho phép lưu lượng vào từ dải IP của khách hàng — qua PrivateLink, lưu lượng đến từ ENI của endpoint chứ không mang IP mạng khách hàng.
  • **A. Kiểm tra AMI và loại instance trong launch template — không liên quan gì tới việc kết nối bị chặn.

Ghi nhớ

⚠ Cách PrivateLink hoạt động — phải hiểu:

Nhà cung cấp: NLB + endpoint service
        ↓
    Người tiêu thụ: interface endpoint
      (ENI có IP TRONG VPC của họ)
        ↓
    Lưu lượng KHÔNG qua Internet,
      KHÔNG qua peering, KHÔNG cần
      định tuyến giữa hai VPC
        ↓
    CIDR chồng lấn cũng không sao

Từ khoá nhận diện:

"expose service to other accounts privately" → PrivateLink "consumers cannot connect through endpoint" → kiểm SG và NACL từng chặng "overlapping CIDR" → PrivateLink "provider must call consumer" → PrivateLink KHÔNG làm được

⚠ Tính một chiều là giới hạn cứng của PrivateLink:

Người tiêu thụ khởi tạo kết nối
    → nhà cung cấp trả lời
        ↓
    Nhà cung cấp KHÔNG gọi ngược được
    → cần hai chiều: dựng hai endpoint
      service ngược nhau

Ba lưu ý về endpoint service: | Lưu ý | Chi tiết | |---|---| | Phải có NLB hoặc GWLB phía sau | | | Danh sách principal được phép | | | Bật AcceptanceRequired để duyệt tay | |

aws ec2 modify-vpc-endpoint-service-permissions \
  --service-id vpce-svc-abc \
  --add-allowed-principals arn:aws:iam::999988887777:root

⚠ Kết nối chờ duyệt là nguyên nhân "không thông" hay bị bỏ qua:

aws ec2 describe-vpc-endpoint-connections \
  --filters Name=vpc-endpoint-state,Values=pendingAcceptance

Bật AcceptanceRequired mà quên duyệt
    → khách hàng thấy endpoint ở trạng thái
      `pendingAcceptance`
    → không có lỗi mạng nào, chỉ là không thông

Ba lưu ý về AZ: | Lưu ý | Chi tiết | |---|---| | Endpoint phải ở AZ mà service có mặt | | | AZ ID khác AZ name giữa các tài khoản | | | Bật cross-zone trên NLB nếu lệch AZ | |

⚠ Tên AZ không giống nhau giữa các tài khoản:

`ap-southeast-1a` ở tài khoản A
    ≠ `ap-southeast-1a` ở tài khoản B
        ↓
    Phải so bằng AZ ID (`apse1-az1`)
    → dùng `describe-availability-zones`

Ba lưu ý về security group: | Lưu ý | Chi tiết | |---|---| | Stateful — chỉ cần mở chiều vào | | | Tham chiếu SG khác thay vì CIDR | | | Endpoint cũng có SG riêng | |

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Stateless — mở cả hai chiều | | | Nhớ dải cổng tạm 1024-65535 | | | Xử lý theo số thứ tự, dừng ở quy tắc khớp đầu | |

Ba công cụ gỡ lỗi: | Công cụ | Việc | |---|---| | Reachability Analyzer | chỉ ra chặng nào chặn | | VPC Flow Logs | thấy REJECT ở đâu | | HealthyHostCount của NLB | target có khoẻ không |

aws ec2 create-network-insights-path \
  --source vpce-abc --destination i-may-chu-log \
  --protocol tcp --destination-port 443

Ba việc kiểm chứng: | Việc | Cách | |---|---| | nc -zv <dns-endpoint> 443 từ máy khách | | | Xem flow log của cả hai subnet | | | Kiểm target group có target khoẻ không | |

Và một lời khuyên: hãy chạy Reachability Analyzer trước khi đọc từng quy tắc bằng mắt. Đường đi PrivateLink có bốn chặng lọc và mỗi chặng có hai tầng — dò tay là cách chắc chắn để bỏ sót đúng cái đang chặn.

Câu 100 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

There was a major incident that occurred in your company wherein the web application that you are supporting unexpectedly went down in the production environment. Upon investigation, it was found that a junior DevOps engineer terminated the EC2 instance in production which caused the disruption of service. Only the Solutions Architects should be allowed to stop or terminate instances in the production environment. You also found out that there are a lot of developers who have full access to your production AWS account.

Which of the following options will fix this security vulnerability in your cloud architecture and prevent this kind of failure from happening again? (Select TWO.)

  1. A

    Attach a PowerUserAccess AWS managed policy to the developers.
  2. B Modify the IAM policy of the developers to require MFA before deleting EC2 instances.
  3. C

    Add tags to the EC2 instances in the production environment and assign the developers a role with a policy that denies terminating the instance based on the tag.
  4. D

    Modify the associated IAM Role assigned to the developers by removing the policy that allows them to terminate EC2 instances in production.
  5. E Replace the Security Group of all of the EC2 instances in Production to prevent developers from accessing it.
Xem giải thích

Đáp án

**C và D — Gắn tag cho các EC2 sản xuất và gán cho lập trình viên vai trò có chính sách từ chối terminate dựa trên tag; đồng thời sửa IAM role của họ, gỡ bỏ chính sách cho phép terminate EC2 sản xuất.

Vì sao đúng

Đề nêu hai việc phải làm, và hai phương án này bổ sung cho nhau: | Việc | Cách làm | |---|---| | Chặn ngay ở tầng chính sách | Deny theo tag môi trường | | Gỡ quyền đang cấp thừa | sửa IAM role, bỏ quyền terminate |

⚠ Deny tường minh LUÔN thắng Allow — đây là nền tảng của IAM:

Chính sách A: Allow ec2:*
Chính sách B: Deny ec2:TerminateInstances
      với điều kiện tag
        ↓
    Kết quả: KHÔNG terminate được
    → dù có bao nhiêu Allow đi nữa

Chính sách Deny theo tag:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Deny",
  "Action": ["ec2:TerminateInstances",
             "ec2:StopInstances"],
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {"StringEquals":
    {"ec2:ResourceTag/MoiTruong": "SanXuat"}}}]}

⚠ Vì sao cần CẢ HAI phương án chứ không chỉ một:

Chỉ gỡ Allow (D):
    → ai đó gán lại chính sách rộng
      là quyền quay lại
        ↓
    Chỉ thêm Deny (C):
    → quyền thừa vẫn nằm đó, áp cho
      mọi tài nguyên không có tag
        ↓
    Cả hai: đặc quyền tối thiểu + lưới an toàn

Gắn tag và bắt buộc gắn tag:

aws ec2 create-tags --resources i-abc \
  --tags Key=MoiTruong,Value=SanXuat

⚠ Nhưng chiến lược dựa vào tag có một lỗ hổng phải bịt:

Lập trình viên có quyền `ec2:CreateTags`
    → đổi tag MoiTruong thành "Dev"
        ↓
    Điều kiện Deny không còn khớp
    → terminate được máy sản xuất
        ↓
    PHẢI chặn luôn việc sửa tag đó

{"Effect": "Deny",
 "Action": ["ec2:CreateTags", "ec2:DeleteTags"],
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"ForAnyValue:StringEquals":
   {"aws:TagKeys": ["MoiTruong"]}}}

⚠ Và giải pháp bền vững nhất là TÁCH TÀI KHOẢN:

Sản xuất và phát triển ở hai tài khoản riêng
    → lập trình viên không có credential
      nào ở tài khoản sản xuất
        ↓
    Không cần chính sách tinh vi nào
    → ranh giới tài khoản là ranh giới
      cô lập mạnh nhất trên AWS

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn ngay, không chờ ai nhớ quy trình | | | Áp cho mọi máy có tag, kể cả máy mới | | | Deny không bị Allow nào ghi đè | |

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

  • **B. Yêu cầu MFA trước khi xoá EC2 — đây là phương án gần nhất và MFA là biện pháp tốt trong nhiều tình huống, nhưng nó chỉ thêm một bước xác thực: kỹ sư vẫn terminate được máy sản xuất, chỉ là sau khi gõ mã.
  • **A. Gắn PowerUserAccess cho lập trình viên — chính sách này vẫn cho phép mọi thao tác EC2 kể cả terminate; nó chỉ chặn thao tác IAM và Organizations.
  • **E. Đổi security group của EC2 sản xuất — security group lọc lưu lượng mạng, nó không liên quan gì tới quyền gọi API terminate.

Ghi nhớ

⚠ Thứ tự đánh giá chính sách IAM — phải thuộc:

1. Deny tường minh   → TỪ CHỐI, dừng luôn
2. SCP không cho phép → từ chối
3. Allow tường minh   → cho phép
4. Không có gì        → từ chối ngầm định

Từ khoá nhận diện:

"prevent specific users from terminating" → Deny theo tag "prevent ANYONE, even admins" → SCP "cap what a role can ever do" → permission boundary "strongest isolation" → tài khoản riêng

⚠ SCP là lớp mạnh hơn cho yêu cầu "chỉ Solutions Architect được phép":

{"Effect": "Deny",
 "Action": ["ec2:TerminateInstances"],
 "Resource": "*",
 "Condition": {"StringNotLike":
   {"aws:PrincipalArn":
     "arn:aws:iam::*:role/KienTrucSu*"}}}

SCP áp cho MỌI principal trong tài khoản
    → kể cả quản trị viên tài khoản
        ↓
    Không ai gỡ được từ bên trong
    → chỉ tài khoản quản lý sửa được

Ba lưu ý về kiểm soát theo tag: | Lưu ý | Chi tiết | |---|---| | ec2:ResourceTag/Khoa cho tài nguyên đã có | | | aws:RequestTag/Khoa cho lúc tạo | | | aws:TagKeys giới hạn khoá được đụng tới | |

⚠ Bắt buộc gắn tag ngay khi tạo:

{"Effect": "Deny", "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"Null":
   {"aws:RequestTag/MoiTruong": "true"}}}

Không có tag môi trường: không tạo được
    → bảo đảm mọi máy đều gắn nhãn
    → chính sách theo tag mới có nghĩa

Ba lưu ý về termination protection: | Lưu ý | Chi tiết | |---|---| | Cờ trên chính instance | | | Không chặn StopInstances | | | Không chặn ASG thu hồi máy | |

aws ec2 modify-instance-attribute --instance-id i-abc \
  --disable-api-termination

⚠ Nhưng đây chỉ là lớp phụ:

Ai có quyền `ec2:ModifyInstanceAttribute`
    → tắt cờ rồi terminate
        ↓
    Chính sách IAM mới là lớp thật
    → cờ này chỉ chống thao tác nhầm

Ba lưu ý về permission boundary: | Lưu ý | Chi tiết | |---|---| | Đặt TRẦN cho một principal cụ thể | | | Cho phép uỷ quyền tạo vai trò an toàn | | | Quyền hiệu lực = giao của boundary và chính sách | |

Ba lưu ý về ghi nhận và cảnh báo: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lời gọi terminate | | | EventBridge cảnh báo ngay khi có | | | Config rule kiểm tra tag còn đúng không | |

{"source": ["aws.ec2"],
 "detail-type": ["AWS API Call via CloudTrail"],
 "detail": {"eventName": ["TerminateInstances"]}}

Ba lưu ý về khôi phục sau sự cố kiểu này: | Lưu ý | Chi tiết | |---|---| | ASG tự dựng lại nếu máy nằm trong nhóm | | | Ảnh chụp EBS để khôi phục dữ liệu | | | Hạ tầng dạng mã dựng lại được từ đầu | |

⚠ Điểm đầu là lý do nên đặt máy sản xuất trong ASG:

Máy đơn lẻ bị terminate: mất hẳn
        ↓
    Máy trong ASG: ASG thấy thiếu
      và tạo lại trong vài phút
    → sự cố thành gián đoạn ngắn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giả nhận vai trò lập trình viên, thử terminate | | | Thử đổi tag môi trường — phải bị từ chối | | | Dùng IAM Policy Simulator kiểm trước | |

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/LapTrinhVien \
  --action-names ec2:TerminateInstances \
  --resource-arns arn:aws:ec2:ap-southeast-1:111122223333:instance/i-abc

Và một lời khuyên: hãy tách môi trường sản xuất sang tài khoản riêng thay vì hoàn thiện mãi bộ chính sách theo tag. Mọi cơ chế dựa vào tag đều phụ thuộc vào việc tag được gắn đúng và không ai sửa được nó — còn ranh giới tài khoản thì không cần ai nhớ điều gì cả.