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

Tìm thấy 1221 câu.

Câu 41 Domain - Design Solutions for Organizational Complexity

A media company hosts its entire infrastructure on the AWS cloud. There is a requirement to copy information to or from the shared resources from another AWS account. The solutions architect has to provide the other account access to several AWS resources such as Amazon S3, AWS KMS, and Amazon ES in the form of a list of AWS account ID numbers. In addition, the user in the other account should still work in the trusted account and there is no need to give up his or her user permissions in place of the role permissions. The solutions architect must also set up a solution that continuously assesses, audits, and monitors the policy configurations.

Which of the following is the MOST suitable type of policy that you should use in this scenario?

  1. A

    Set up a service-linked role with an identity-based policy. Use AWS Systems Manager rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.
  2. B

    Set up cross-account access with a resource-based Policy. Use AWS Config rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.
  3. C

    Set up a service-linked role with a service control policy. Use AWS Systems Manager rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.
  4. D

    Set up cross-account access with a user-based policy configuration. Use AWS Config rules to periodically audit changes to the IAM policy and monitor the compliance of the configuration.
Xem giải thích

Đáp án

B — Thiết lập truy cập xuyên tài khoản bằng resource-based policy; dùng AWS Config rules định kỳ kiểm toán thay đổi của chính sách và giám sát tuân thủ.

Vì sao đúng

Đề nêu bốn dữ kiện, và mỗi cái loại bớt phương án: | Dữ kiện | Kết luận | |---|---| | Cấp quyền bằng DANH SÁCH account ID | đặc trưng của resource-based policy | | Trên S3, KMS, OpenSearch | ba dịch vụ đều hỗ trợ resource-based policy | | Người dùng GIỮ NGUYÊN quyền của họ, không phải đổi vai trò | resource-based, không phải assume role | | Cần đánh giá và giám sát cấu hình liên tục | AWS Config |

⚠ Vế thứ ba là chi tiết phân biệt quan trọng nhất:

Cross-account ROLE (assume role):
    → người dùng ĐÁNH ĐỔI quyền hiện có
      lấy quyền của vai trò
    → mất quyền cũ trong phiên đó
        ↓
Resource-based policy:
    → người dùng GIỮ NGUYÊN quyền của mình
    → và được thêm quyền trên tài nguyên đó

Đề nói rõ: "the user should still work in the trusted account and there is no need to give up his or her user permissions in place of the role permissions" — đây là mô tả chính xác của resource-based policy.

Bucket policy cấp quyền xuyên tài khoản:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChoPhepTaiKhoanDoiTac",
   "Effect": "Allow",
   "Principal": {"AWS": [
     "arn:aws:iam::222222222222:root",
     "arn:aws:iam::333333333333:root"]},
   "Action": ["s3:GetObject", "s3:PutObject"],
   "Resource": "arn:aws:s3:::kho-chia-se/*"}]}

⚠ Cấp quyền xuyên tài khoản cần CẢ HAI phía:

Bucket policy ở tài khoản SỞ HỮU: cho phép
    +
IAM policy ở tài khoản GỌI: cho phép
        ↓
    Thiếu một bên là bị từ chối

KMS key policy cũng vậy:

{"Sid": "ChoPhepTaiKhoanKhacDung",
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::222222222222:root"},
 "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
 "Resource": "*"}

⚠ Bucket mã hoá SSE-KMS cần cả hai policy:

Bucket policy cho phép nhưng key policy không
    → AccessDenied mà thông báo KHÔNG nhắc gì tới KMS
        ↓
    Người gỡ lỗi soi bucket policy vốn đã đúng

AWS Config giám sát chính sách:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "kiem-tra-bucket-khong-cong-khai",
  "Source": {"Owner":"AWS",
             "SourceIdentifier":"S3_BUCKET_PUBLIC_READ_PROHIBITED"}}'

⚠ Vì sao Config chứ không phải Systems Manager:

Config: ghi lại LỊCH SỬ CẤU HÌNH của tài nguyên
    → biết policy đã đổi lúc nào, từ gì sang gì
    → có quy tắc tuân thủ dựng sẵn
        ↓
Systems Manager: quản lý INSTANCE
    → không biết gì về IAM policy hay bucket policy

Đây là lý do phương án A và C sai ở vế thứ hai.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Người dùng không phải đổi vai trò | | | Cấp quyền theo danh sách account ID đơn giản | | | Config theo dõi mọi thay đổi chính sách | |

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

  • **D. Truy cập xuyên tài khoản với user-based policy + Config — đây là phương án gần nhất và vế giám sát hoàn toàn đúng, nhưng identity-based policy một mình không cấp được quyền xuyên tài khoản: tài nguyên ở tài khoản khác phải có resource-based policy cho phép.
  • **A. Service-linked role với identity-based policy + Systems Manager rules — service-linked role là vai trò do chính dịch vụ AWS dùng, không phải cơ chế chia sẻ tài nguyên; và Systems Manager không kiểm toán IAM policy.
  • **C. Service-linked role với service control policy + Systems Manager — SCP giới hạn quyền chứ không cấp quyền, và nó chỉ áp trong tổ chức; hai công cụ đều sai vai trò.

Ghi nhớ

⚠ Identity-based vs Resource-based policy — bảng phải thuộc: | Tiêu chí | Identity-based | Resource-based | |---|---|---| | Gắn vào | user, group, role | tài nguyên | | Có trường Principal | ❌ | ✅ | | Xuyên tài khoản một mình | ❌ | ✅ (với một số dịch vụ) | | Giữ quyền gốc của người dùng | — | ✅ |

⚠ Ba dịch vụ hỗ trợ truy cập xuyên tài khoản CHỈ bằng resource policy: | Dịch vụ | Chi tiết | |---|---| | S3 | bucket policy | | KMS | key policy | | SQS, SNS, Lambda | resource policy | | OpenSearch | access policy |

Với các dịch vụ khác (EC2, RDS...)
    → phải dùng cross-account ROLE
    → không có resource policy

Từ khoá nhận diện:

"user keeps their own permissions, list of account IDs" → resource-based policy "user assumes a role in another account" → cross-account role "audit configuration changes over time" → AWS Config "restrict what accounts can do" → SCP

⚠ Cross-account role vs resource policy — khi nào dùng cái nào:

Resource policy: đơn giản, giữ quyền gốc
    → hợp khi chỉ chia sẻ vài tài nguyên
        ↓
Cross-account role: kiểm soát chi tiết hơn
    → hợp khi cần cấp nhiều quyền,
      hoặc dịch vụ không có resource policy
    → và có ExternalId chống confused deputy

Ba lưu ý về Principal: | Giá trị | Nghĩa | |---|---| | arn:aws:iam::111111111111:root | MỌI principal trong tài khoản đó | | arn:aws:iam::111111111111:role/TenVaiTro | chỉ vai trò đó | | * | mọi người — nguy hiểm |

⚠ :root không có nghĩa là "người dùng root":

`:root` trong Principal nghĩa là
"uỷ quyền cho TÀI KHOẢN đó tự quyết định ai được dùng"
        ↓
    Tài khoản kia vẫn phải cấp IAM policy
      cho user cụ thể
    → đây là mô hình uỷ quyền hai tầng

Ba lưu ý về giới hạn kích thước: | Chính sách | Trần | |---|---| | Bucket policy | 20 KB | | KMS key policy | 32 KB | | IAM managed policy | 6 KB |

⚠ Liệt kê nhiều account ID có thể chạm trần:

Hàng chục tài khoản trong Principal
    → policy phình to
        ↓
    Dùng `aws:PrincipalOrgID` nếu tất cả
      trong cùng tổ chức
    → một dòng thay cho cả danh sách

Ba quy tắc Config nên bật: | Quy tắc | Kiểm tra | |---|---| | s3-bucket-policy-grantee-check | ai được cấp quyền | | s3-bucket-public-read-prohibited | | | iam-policy-no-statements-with-admin-access | |

Ba lưu ý về IAM Access Analyzer: | Lưu ý | Chi tiết | |---|---| | Phát hiện tài nguyên chia sẻ ra NGOÀI | | | Phạm vi ORGANIZATION giảm nhiễu | | | Kiểm chứng policy trước khi áp | |

aws accessanalyzer create-analyzer \
  --analyzer-name phan-tich-to-chuc --type ORGANIZATION

⚠ Access Analyzer bổ sung cho Config:

Config: chính sách có tuân thủ quy tắc không
Access Analyzer: chính sách có cho phép
                 truy cập ngoài dự kiến không
        ↓
    Hai góc nhìn khác nhau, nên bật cả hai

Ba lưu ý về ExternalId: | Lưu ý | Chi tiết | |---|---| | Chống tấn công confused deputy | | | Bắt buộc khi bên thứ ba đảm nhận vai trò | | | Chỉ áp cho cross-account role, không cho resource policy | |

Ba lưu ý về kiểm toán: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi thay đổi policy | | | Config lưu lịch sử cấu hình | | | Cảnh báo khi policy bị sửa | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử truy cập từ tài khoản đối tác | | | Chạy Access Analyzer | | | Xem lịch sử cấu hình trong Config | |

aws configservice get-resource-config-history \
  --resource-type AWS::S3::Bucket --resource-id kho-chia-se

Và một lời khuyên: hãy nhớ rằng cấp quyền xuyên tài khoản luôn cần chính sách ở CẢ HAI phía. Bucket policy cho phép là điều kiện cần, nhưng người dùng ở tài khoản kia vẫn phải có IAM policy tương ứng — và một nửa số lỗi AccessDenied xuyên tài khoản đến từ việc chỉ làm một trong hai.

Câu 42 Domain - Design for New Solutions

A company uses computer simulations for modeling weather patterns in a certain country. The simulations generate terabytes of data, which is stored in a MySQL 8.0 database that runs in an Amazon EC2 instance. A Ruby on Rails application is hosted on a separate EC2 instance to process the data. The current database size is 16 TiB and is expected to grow as more complex simulations are created continuously. The facility wants to re-architect its infrastructure to be highly scalable and highly available as they need to run the application reliably 24x7.

Which of the following is the MOST cost-effective solution that can satisfy the above requirements?

  1. A

    Configure your application tier to run on an Auto Scaling group of smaller sized EC2 instances behind an Application Load Balancer. Purchase reserved EC2 instances for fixed capacity and let the Auto Scaling instances run on demand. Migrate the MySQL database to an Amazon RDS MySQL instance with Multi-AZ enabled. Adjust the RDS Storage volume manually as demand increases.
  2. B

    Purchase Reserved Amazon EC2 instances for the application instance and database instances to save costs. Create an EC2 Auto Scaling group with Multi-AZ configuration behind a load balancer for the application tier. Implement a “source-replica” setup for your database tier. Use Logical Volume Management on the database instances to easily attach new EBS volumes and expand the file system.
  3. C

    Configure your application tier to run on an Auto Scaling group of smaller sized EC2 instances behind an Application Load Balancer. Purchase Reserved EC2 instances for fixed capacity and let the Auto Scaling instances run on demand. Migrate the MySQL database to Amazon Aurora. Create a read-replica on another Availability Zone of the Aurora instance for high availability.
  4. D

    Convert the application tier to Lambda@Edge functions for high availability, scalability, and cost-effectiveness. Migrate the MySQL database to an Amazon RDS MySQL instance with Multi-AZ enabled. Enable storage autoscaling on the RDS instance.
Xem giải thích

Đáp án

C — Tầng ứng dụng chạy trên ASG gồm máy nhỏ hơn sau ALB; mua Reserved Instance cho phần năng lực cố định và để phần co giãn chạy On-Demand; chuyển CSDL MySQL sang Amazon Aurora và tạo read replica ở AZ khác.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này thoả từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Co giãn cao | ASG máy nhỏ + Aurora lưu trữ tự mở rộng | | Sẵn sàng cao 24x7 | ALB đa AZ + Aurora replica ở AZ khác | | CSDL 16 TiB và còn lớn thêm | Aurora tự mở rộng tới 128 TB | | TIẾT KIỆM NHẤT | RI cho nền, On-Demand cho đỉnh |

⚠ Aurora tự mở rộng lưu trữ — đây là chi tiết quan trọng nhất:

CSDL 16 TiB và "expected to grow continuously"
        ↓
    RDS MySQL: phải cấp phát dung lượng trước
    → tối đa 64 TiB, và phải theo dõi để tăng
        ↓
    Aurora: lưu trữ tự lớn theo dữ liệu
    → tới 128 TB, không cần cấu hình
    → và tự NHỎ LẠI khi xoá dữ liệu

⚠ Aurora còn nhanh hơn MySQL tiêu chuẩn khoảng 5 lần:

Tách tính toán và lưu trữ
    → tầng lưu trữ phân tán, 6 bản sao trên 3 AZ
        ↓
    Ghi song song, không chờ đồng bộ tuần tự

Chuyển đổi ít gián đoạn:

aws rds create-db-cluster \
  --db-cluster-identifier cum-mo-phong \
  --engine aurora-mysql \
  --replication-source-identifier <arn-rds-mysql>

Tạo Aurora read replica từ RDS MySQL
    → chờ đồng bộ, rồi promote
    → thời gian ngừng chỉ vài phút

Chiến lược mua kết hợp:

Năng lực NỀN (luôn cần) → Reserved Instance
    → giảm tới 72%
        ↓
Năng lực ĐỈNH (thỉnh thoảng) → On-Demand
    → chỉ trả khi dùng

⚠ Máy NHỎ HƠN cho co giãn mịn hơn:

Ít máy lớn: mỗi bước co giãn là một khối lớn
    → thêm một máy = thêm nhiều năng lực thừa
        ↓
Nhiều máy nhỏ: bước co giãn mịn
    → khớp sát với tải thật
    → và mất một máy ảnh hưởng ít hơn

Aurora Replica ở AZ khác:

aws rds create-db-instance \
  --db-instance-identifier doc-1 \
  --db-cluster-identifier cum-mo-phong \
  --db-instance-class db.r6g.4xlarge \
  --engine aurora-mysql \
  --availability-zone ap-southeast-1b

⚠ Aurora Replica vừa phục vụ ĐỌC vừa là mục tiêu FAILOVER:

RDS Multi-AZ: standby KHÔNG đọc được
    → phải thêm read replica riêng
        ↓
Aurora: mỗi replica làm CẢ HAI vai
    → một instance, hai lợi ích

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lưu trữ không bao giờ hết chỗ | | | RI giảm chi phí phần nền | | | Replica vừa mở rộng đọc vừa là dự phòng | |

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

  • **A. ASG máy nhỏ + RI cho nền, nhưng chuyển sang RDS MySQL Multi-AZ — đây là phương án gần nhất và đúng ở phần tầng ứng dụng, nhưng RDS MySQL phải cấp phát dung lượng trước và có trần thấp hơn; với CSDL 16 TiB đang lớn dần thì Aurora phù hợp hơn hẳn.
  • **B. Mua RI cho cả máy ứng dụng lẫn CSDL, tự dựng source-replica và LVM trên EC2 — tự quản lý MySQL trên EC2 là công vận hành lớn nhất; và mua RI cho toàn bộ tầng ứng dụng thì không tận dụng được tính co giãn.
  • **D. Chuyển tầng ứng dụng sang Lambda@Edge — Lambda@Edge có giới hạn rất chặt (5-30 giây, 128 MB-10 GB, không truy cập được VPC ở viewer event); ứng dụng Ruby on Rails xử lý mô phỏng thời tiết hoàn toàn không chạy được ở đó.

Ghi nhớ

⚠ Aurora vs RDS — bảng phải thuộc: | Tiêu chí | Aurora | RDS | |---|---|---| | Lưu trữ | TỰ mở rộng tới 128 TB | cấp trước, tối đa 64 TiB | | Replica | đọc được VÀ là mục tiêu failover | standby không đọc được | | Hiệu năng | ~5 lần MySQL | tiêu chuẩn | | Failover | dưới 30 giây | 60-120 giây | | Chi phí | cao hơn mỗi giờ | thấp hơn |

Từ khoá nhận diện:

"database growing continuously, tens of TB" → Aurora "steady baseline + variable peak" → RI cho nền, On-Demand cho đỉnh "read scaling + HA in one" → Aurora Replica "unpredictable database load" → Aurora Serverless v2

⚠ Ba chiến lược mua kết hợp: | Phần tải | Mô hình mua | |---|---| | Nền chạy 24/7 | Savings Plans hoặc RI | | Đỉnh đoán trước | scheduled scaling + On-Demand | | Tải chịu gián đoạn | Spot |

⚠ Savings Plans thường tốt hơn RI ngày nay:

Compute Savings Plans áp cho EC2 mọi loại,
mọi Region, cả Fargate và Lambda
        ↓
    Cam kết theo SỐ TIỀN mỗi giờ
    → không bao giờ mua sai loại máy

Ba lưu ý về Aurora Serverless v2: | Lưu ý | Chi tiết | |---|---| | Tự tăng giảm ACU theo giây | | | Trộn được với instance provisioned | | | Hợp khi tải mô phỏng thất thường | |

⚠ Với tải mô phỏng thời tiết, Serverless v2 đáng cân nhắc:

Mô phỏng chạy theo đợt, không đều
    → provisioned phải cấp cho lúc cao nhất
        ↓
    Serverless v2 tự lên xuống
    → nhưng đề đã chọn provisioned + RI

Ba lưu ý về Aurora I/O-Optimized: | Lưu ý | Chi tiết | |---|---| | Giá instance và lưu trữ cao hơn | | | Nhưng I/O MIỄN PHÍ | | | Rẻ hơn khi I/O vượt 25% hoá đơn | |

⚠ Dữ liệu mô phỏng thường I/O rất nặng:

Ghi liên tục hàng terabyte
    → phí I/O có thể vượt xa phí instance
        ↓
    I/O-Optimized đáng tính thử

Ba lưu ý về chuyển từ MySQL sang Aurora: | Cách | Gián đoạn | |---|---| | Aurora read replica rồi promote | vài phút | | Snapshot restore | có | | DMS full-load + CDC | rất ít |

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | min-size ít nhất bằng số AZ | | | Target tracking là mặc định tốt | | | Health check type ELB | |

⚠ Ứng dụng phải không trạng thái:

Ruby on Rails lưu session trong bộ nhớ
    → ASG thay máy = người dùng đăng xuất
        ↓
    Đưa session vào ElastiCache
    → hoặc dùng cookie đã ký

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Aurora tới 15 replica | | | Reader endpoint cân bằng tự động | | | Auto scaling cho replica được | |

aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --resource-id cluster:cum-mo-phong \
  --min-capacity 1 --max-capacity 5

Ba lưu ý về promotion tier: | Lưu ý | Chi tiết | |---|---| | Tier thấp = ưu tiên cao khi failover | | | Đặt tier cao cho replica chạy báo cáo nặng | | | Tránh biến máy đang tải nặng thành writer | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | AuroraReplicaLag | độ trễ replica | | VolumeBytesUsed | dung lượng đang dùng | | Performance Insights | truy vấn tốn nhất |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo hiệu năng trước và sau khi chuyển Aurora | | | Thử failover có kế hoạch | | | Xem RI utilization sau một tháng | |

Và một lời khuyên: hãy mua Reserved Instance chỉ cho phần năng lực nền thật sự chạy 24/7. Mua cho toàn bộ đội máy nghe có vẻ tiết kiệm hơn, nhưng nó khoá bạn vào một mức năng lực cố định và triệt tiêu chính lợi ích mà Auto Scaling mang lại — trả tiền cam kết cho những máy chỉ tồn tại vài giờ mỗi ngày.

Câu 43 Domain - Continuous Improvement for Existing Solutions

A top university has launched its serverless online portal using Lambda and API Gateway in AWS that enables its students to enroll, manage their class schedules, and see their grades online. After a few weeks, the portal abruptly stopped working and lost all of its data. The university hired an external cybersecurity consultant and based on the investigation, the outage was due to an SQL injection vulnerability on the portal's login page in which the attacker simply injected the malicious SQL code. You also need to track historical changes to the rules and metrics associated with your firewall.

Which of the following is the most suitable and cost-effective solution to avoid another SQL Injection attack against their infrastructure in AWS?

  1. A

    Create a new Application Load Balancer (ALB) and set up AWS WAF in the load balancer. Place the API Gateway behind the ALB and configure a web access control list (web ACL) in front of the ALB to block requests that contain malicious SQL code. Use AWS Firewall Manager to track changes to your web access control lists (web ACLs) such as the creation and deletion of rules including the updates to the WAF rule configurations.
  2. B

    Use AWS WAF to add a web access control list (web ACL) in front of the API Gateway to block requests that contain malicious SQL code. Use AWS Config to track changes to your web access control lists (web ACLs) such as the creation and deletion of rules including the updates to the WAF rule configurations.
  3. C

    Block the IP address of the attacker in the Network Access Control List of your VPC and then set up a CloudFront distribution. Set up AWS WAF to add a web access control list (web ACL) in front of the CloudFront distribution to block requests that contain malicious SQL code. Use AWS Config to track changes to your web access control lists (web ACLs) such as the creation and deletion of rules including the updates to the WAF rule configurations.
  4. D

    Use AWS WAF to add a web access control list (web ACL) in front of the Lambda functions to block requests that contain malicious SQL code. Use AWS Firewall Manager, to track changes to your web access control lists (web ACLs) such as the creation and deletion of rules including the updates to the WAF rule configurations.
Xem giải thích

Đáp án

B — Dùng AWS WAF gắn một web ACL trực tiếp trước API Gateway để chặn yêu cầu chứa mã SQL độc hại; dùng AWS Config theo dõi thay đổi của web ACL như tạo, xoá quy tắc và cập nhật cấu hình WAF.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này đáp ứng cả hai với ít bộ phận nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Chặn SQL injection | WAF gắn TRỰC TIẾP vào API Gateway | | Theo dõi lịch sử thay đổi quy tắc firewall | AWS Config ghi lịch sử cấu hình |

⚠ WAF gắn TRỰC TIẾP vào API Gateway — không cần ALB hay CloudFront:

API Gateway là một trong các tài nguyên
WAF gắn được vào
        ↓
    Không cần thêm tầng nào ở giữa
    → đây là điều làm phương án B rẻ hơn A và C

Gắn WAF vào API Gateway stage:

aws wafv2 create-web-acl --name acl-cong-sinh-vien \
  --scope REGIONAL --region ap-southeast-1 \
  --default-action Allow={} \
  --rules '[{
    "Name":"ChanSQLi","Priority":1,
    "Statement":{"ManagedRuleGroupStatement":{
      "VendorName":"AWS","Name":"AWSManagedRulesSQLiRuleSet"}},
    "OverrideAction":{"None":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"ChanSQLi"}}]' \
  --visibility-config 'SampledRequestsEnabled=true,
    CloudWatchMetricsEnabled=true,MetricName=aclCongSinhVien'

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

⚠ --scope REGIONAL cho API Gateway, CLOUDFRONT cho CloudFront:

Gắn vào API Gateway, ALB, AppSync → REGIONAL
Gắn vào CloudFront → CLOUDFRONT (tạo ở us-east-1)
        ↓
    Chọn sai scope thì không associate được

⚠ Config là công cụ đúng cho "theo dõi lịch sử thay đổi":

Config ghi lại MỌI phiên bản cấu hình
    → xem web ACL trông thế nào tại bất kỳ
      thời điểm nào trong quá khứ
        ↓
    Đúng yêu cầu "track HISTORICAL changes
      to the rules and metrics"

aws configservice get-resource-config-history \
  --resource-type AWS::WAFv2::WebACL \
  --resource-id <id-web-acl> --limit 10

⚠ Vì sao Config chứ không phải Firewall Manager: | Công cụ | Việc | |---|---| | AWS Config | GHI LỊCH SỬ và kiểm tra tuân thủ | | Firewall Manager | ÁP chính sách WAF cho nhiều tài khoản |

Firewall Manager triển khai và ép quy tắc
    → nó KHÔNG phải công cụ ghi lịch sử
        ↓
    Đây là lý do phương án A và D sai ở vế thứ hai

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không thêm ALB hay CloudFront nào | | | Quy tắc quản lý được AWS cập nhật liên tục | | | Config ghi lại mọi thay đổi | |

⚠ Nhưng WAF là biện pháp giảm thiểu, không phải cách sửa:

WAF chặn payload SQLi đã biết
    → mua thời gian
        ↓
    Cách sửa thật: dùng prepared statement
    → tham số hoá truy vấn, không nối chuỗi

# Sai — dễ bị SQL injection
cursor.execute(f"SELECT * FROM sinh_vien WHERE ma = '{ma}'")

# Đúng — tham số hoá
cursor.execute("SELECT * FROM sinh_vien WHERE ma = %s", (ma,))

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

  • **C. Chặn IP kẻ tấn công trong NACL, dựng CloudFront và gắn WAF vào đó + Config — đây là phương án gần nhất và về kỹ thuật cũng chặn được, nhưng thêm hẳn một CloudFront distribution chỉ để gắn WAF là chi phí và độ phức tạp không cần thiết; đề nói rõ "cost-effective". Và chặn một IP không giải quyết được lỗ hổng.
  • **A. Dựng ALB mới, đặt API Gateway sau ALB, gắn WAF vào ALB + Firewall Manager — thêm ALB là chi phí thừa; mô tả "đặt API Gateway sau ALB" cũng không phải kiến trúc thông thường; và Firewall Manager không ghi lịch sử.
  • **D. Gắn WAF trực tiếp vào Lambda function + Firewall Manager — WAF KHÔNG gắn được vào Lambda; và Firewall Manager sai vai trò.

Ghi nhớ

⚠ Sáu tài nguyên WAF gắn được — bảng phải thuộc: | Gắn được | Không gắn được | |---|---| | CloudFront | Lambda function | | Application Load Balancer | Network Load Balancer | | API Gateway (REST) | EC2 instance | | AppSync | Classic Load Balancer | | Cognito user pool | | | App Runner, Verified Access | |

⚠ HTTP API (API Gateway v2) KHÔNG gắn WAF trực tiếp:

Chỉ REST API gắn được WAF
    → dùng HTTP API thì phải đặt CloudFront phía trước
        ↓
    Đây là một lý do vẫn chọn REST API
      dù đắt hơn

Từ khoá nhận diện:

"block SQL injection on API Gateway, cost-effective" → WAF gắn trực tiếp "track historical config changes" → AWS Config "apply WAF policy across accounts" → Firewall Manager "DDoS layer 3/4" → Shield

⚠ Ba công cụ quản trị WAF hay bị lẫn: | Công cụ | Việc | |---|---| | AWS Config | ghi lịch sử, kiểm tuân thủ | | Firewall Manager | triển khai và ép chính sách | | Security Hub | tổng hợp phát hiện |

Ba nhóm quy tắc quản lý nên bật: | Nhóm | Chống | |---|---| | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesCommonRuleSet | XSS, OWASP cơ bản | | AWSManagedRulesKnownBadInputsRuleSet | payload đã biết |

⚠ Luôn chạy COUNT trước khi BLOCK:

Quy tắc SQLi có thể chặn nhầm truy vấn hợp lệ
    → ví dụ ô tìm kiếm cho nhập dấu nháy
        ↓
    Chạy COUNT vài ngày, xem log, thêm ngoại lệ

Ba lưu ý về cấu hình WAF cho API: | Lưu ý | Chi tiết | |---|---| | Kiểm cả body của POST | | | TextTransformations giải mã trước khi so | | | Rate-based rule chống dò tìm | |

{"Statement": {"SqliMatchStatement": {
  "FieldToMatch": {"Body": {"OversizeHandling": "CONTINUE"}},
  "TextTransformations": [
    {"Priority": 0, "Type": "URL_DECODE"},
    {"Priority": 1, "Type": "HTML_ENTITY_DECODE"},
    {"Priority": 2, "Type": "LOWERCASE"}]}}}

⚠ TextTransformations là phần quan trọng nhất:

Kẻ tấn công mã hoá payload để né bộ lọc
    → %27 thay vì dấu nháy
        ↓
    Không giải mã trước khi so
    → bộ lọc bị vượt qua dễ dàng

Ba lưu ý về ghi log WAF: | Lưu ý | Chi tiết | |---|---| | Log ra Firehose, S3 hoặc CloudWatch Logs | | | Che trường nhạy cảm | | | Athena truy vấn để phân tích | |

aws wafv2 put-logging-configuration --logging-configuration \
  'ResourceArn=<arn-web-acl>,
   LogDestinationConfigs=<arn-log-group>,
   RedactedFields=[{SingleHeader={Name=authorization}}]'

Ba lưu ý về chi phí WAF: | Khoản | Giá tham khảo | |---|---| | Web ACL | ~5 USD/tháng | | Mỗi quy tắc | ~1 USD/tháng | | Mỗi triệu request | ~0,60 USD |

Ba lưu ý về Config cho WAF: | Lưu ý | Chi tiết | |---|---| | Ghi nhận AWS::WAFv2::WebACL và RuleGroup | | | Xem lịch sử cấu hình theo thời gian | | | Config rule kiểm tra WAF đã gắn chưa | |

⚠ Config rule kiểm tra API Gateway có WAF:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName":"api-gateway-phai-co-waf",
  "Source":{"Owner":"AWS",
    "SourceIdentifier":"API_GW_ASSOCIATED_WITH_WAF"}}'

Ba lớp bảo vệ khác cho API serverless: | Lớp | Việc | |---|---| | Throttling ở stage | chống dồn request | | Cognito authorizer | chỉ người đăng nhập | | Prepared statement trong mã | sửa gốc rễ |

Ba lưu ý về khôi phục sau sự cố: | Việc | Chi tiết | |---|---| | Bật point-in-time recovery cho CSDL | | | Sao lưu định kỳ | | | Đề nói "lost all its data" — thiếu sao lưu | |

⚠ Bài học lớn nhất của đề nằm ở đây:

Portal "mất toàn bộ dữ liệu"
    → nghĩa là KHÔNG có sao lưu nào khôi phục được
        ↓
    WAF ngăn lần sau
    → nhưng sao lưu mới là thứ cứu được lần này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi payload SQLi thử | phải bị chặn | | Kiểm tra lưu lượng hợp lệ không bị chặn nhầm | | | Xem lịch sử cấu hình trong Config | |

Và một lời khuyên: hãy bật sao lưu tự động cho cơ sở dữ liệu cùng lúc với việc dựng WAF. Đề mô tả một hệ thống mất sạch dữ liệu sau một cuộc tấn công, và WAF chỉ ngăn được lần tiếp theo — thứ duy nhất có thể cứu được lần đầu tiên là một bản sao lưu mà không ai nghĩ tới cho tới khi cần.

Câu 44 Domain - Continuous Improvement for Existing Solutions

A company is hosting a multi-tier web application in AWS. It is composed of an Application Load Balancer and EC2 instances across three Availability Zones. During peak load, its stateless web servers operate at 95% utilization. The system is set up to use Reserved Instances to handle the steady-state load and On-Demand Instances to handle the peak load. Your manager instructed you to review the current architecture and do the necessary changes to improve the system.

Which of the following provides the most cost-effective architecture to allow the application to recover quickly in the event that an Availability Zone is unavailable during peak load?

  1. A

    Launch a Spot Fleet using a diversified allocation strategy, with Auto Scaling enabled on each AZ to handle the peak load instead of On-Demand instances. Retain the current setup for handling the steady state load.
  2. B

    Use a combination of Spot and On-Demand instances on each AZ to handle both the steady state and peak load.
  3. C

    Launch an Auto Scaling group of Reserved instances on each AZ to handle the peak load. Retain the current setup for handling the steady state load.
  4. D

    Use a combination of Reserved and On-Demand instances on each AZ to handle both the steady state and peak load.
Xem giải thích

Đáp án

A — Dùng Spot Fleet với chiến lược phân bổ diversified, bật Auto Scaling ở mỗi AZ để xử lý tải đỉnh thay cho On-Demand; giữ nguyên cấu hình hiện tại cho tải nền.

Vì sao đúng

Đề nêu ba dữ kiện, và cả ba đều ủng hộ phương án này: | Dữ kiện | Ý nghĩa | |---|---| | Máy web KHÔNG TRẠNG THÁI | chịu được gián đoạn → Spot dùng được | | Đã có RI cho tải nền | giữ nguyên phần đó | | Cần phục hồi nhanh khi mất một AZ lúc cao điểm | diversified trải nhiều pool |

⚠ "Stateless" là từ khoá cho phép dùng Spot:

Máy bị lấy lại → ALB rút khỏi target group
    → request chuyển sang máy khác
    → người dùng không mất gì
        ↓
    Đây là điều kiện DUY NHẤT của Spot

⚠ Chiến lược diversified là chi tiết quyết định khả năng phục hồi: | Chiến lược | Cách hoạt động | |---|---| | lowestPrice | dồn vào pool rẻ nhất — rủi ro cao | | diversified | trải đều nhiều pool | | capacityOptimized | chọn pool có nhiều năng lực nhất |

lowestPrice: mọi máy trong một pool
    → pool đó bị lấy lại = mất TẤT CẢ cùng lúc
        ↓
diversified: trải qua nhiều loại máy và nhiều AZ
    → mất một pool chỉ mất một phần
    → đúng yêu cầu "recover quickly if an AZ
      is unavailable"

Dựng Spot Fleet:

aws ec2 request-spot-fleet --spot-fleet-request-config '{
  "IamFleetRole":"<arn-role>",
  "TargetCapacity":20,
  "AllocationStrategy":"diversified",
  "LaunchSpecifications":[
    {"InstanceType":"m5.large","SubnetId":"subnet-a"},
    {"InstanceType":"m5a.large","SubnetId":"subnet-a"},
    {"InstanceType":"m5.large","SubnetId":"subnet-b"},
    {"InstanceType":"m5a.large","SubnetId":"subnet-b"},
    {"InstanceType":"m5.large","SubnetId":"subnet-c"},
    {"InstanceType":"m5a.large","SubnetId":"subnet-c"}]}'

⚠ Khai NHIỀU loại máy và NHIỀU AZ là điều làm nên diversified:

Chỉ khai một loại máy ở một AZ
    → chiến lược diversified không có gì để trải
        ↓
    Khai 6+ tổ hợp (loại máy × AZ)
    → xác suất mất đồng loạt giảm mạnh

⚠ Vì sao Spot rẻ hơn On-Demand cho tải đỉnh:

Tải đỉnh chỉ tồn tại vài giờ mỗi ngày
    → On-Demand trả giá đầy đủ cho những giờ đó
        ↓
    Spot giảm tới 90%
    → và tải đỉnh chính là thứ chịu được gián đoạn nhất

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giảm tới 90% chi phí phần đỉnh | | | Diversified giảm rủi ro mất đồng loạt | | | RI vẫn lo phần nền ổn định | |

⚠ Đây là mô hình mua ba tầng chuẩn:

Tải nền 24/7        → Reserved Instance (giảm 72%)
Tải đỉnh dự đoán được → Spot (giảm 90%)
Phần đệm an toàn     → On-Demand
        ↓
    Mỗi tầng dùng mô hình rẻ nhất cho đặc tính của nó

⚠ Nhưng phải xử lý cảnh báo bị lấy lại:

curl -s http://169.254.169.254/latest/meta-data/spot/instance-action

AWS báo trước 2 phút
    → rút máy khỏi target group
    → hoàn tất request đang xử lý
        ↓
    Không xử lý = request bị cắt giữa chừng

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

  • **B. Kết hợp Spot và On-Demand ở mỗi AZ cho CẢ tải nền lẫn tải đỉnh — đây là phương án gần nhất và cũng dùng Spot, nhưng nó bỏ đi Reserved Instance vốn đang giảm giá cho tải nền; và dùng Spot cho tải nền chạy 24/7 là rủi ro không cần thiết.
  • **D. Kết hợp Reserved và On-Demand cho cả hai loại tải — đây gần như là cấu hình hiện tại; không cải thiện chi phí gì cho phần đỉnh.
  • **C. Dùng ASG gồm Reserved Instance cho tải đỉnh — RI là mô hình THANH TOÁN, không phải loại máy; và mua RI cho năng lực chỉ dùng vài giờ mỗi ngày là lãng phí lớn nhất trong bốn phương án.

Ghi nhớ

⚠ RI không phải một loại instance — đây là hiểu nhầm phổ biến:

Reserved Instance = cam kết THANH TOÁN
    → không phải một loại máy để khởi chạy
        ↓
    Bạn khởi chạy máy On-Demand bình thường
    → RI tự áp giảm giá cho máy khớp thuộc tính

⚠ Ba chiến lược phân bổ Spot — bảng phải thuộc: | Chiến lược | Ưu tiên | Khi nào | |---|---|---| | lowestPrice | giá thấp nhất | tác vụ ngắn, chịu mất | | diversified | trải đều nhiều pool | cần độ bền | | capacityOptimized | pool nhiều năng lực nhất | khuyến nghị hiện nay | | priceCapacityOptimized | cân bằng cả hai | mặc định tốt nhất |

⚠ priceCapacityOptimized là khuyến nghị mới của AWS:

Cân bằng giữa giá thấp và xác suất bị lấy lại thấp
    → thường tốt hơn cả diversified lẫn lowestPrice
        ↓
    Nhưng không có trong phương án của đề

Từ khoá nhận diện:

"stateless, peak load, cost-effective, survive AZ loss" → Spot Fleet diversified "steady 24/7 load" → Reserved Instance / Savings Plans "cannot be interrupted" → On-Demand "license per socket, compliance" → Dedicated Host

Ba cách xử lý cảnh báo bị lấy lại: | Cách | Chi tiết | |---|---| | Đọc metadata endpoint mỗi 5 giây | | | EventBridge bắt sự kiện EC2 Spot Instance Interruption Warning | | | ASG lifecycle hook | |

{"source": ["aws.ec2"],
 "detail-type": ["EC2 Spot Instance Interruption Warning"]}

⚠ Rebalance recommendation báo SỚM HƠN 2 phút:

AWS đánh giá máy có nguy cơ cao bị lấy lại
    → gửi rebalance recommendation
        ↓
    Chuẩn bị máy thay thế TRƯỚC khi
      cảnh báo 2 phút tới

Ba lưu ý về ASG với Spot (cách hiện đại hơn Spot Fleet): | Lưu ý | Chi tiết | |---|---| | Mixed instances policy trong ASG | | | Trộn On-Demand và Spot theo tỷ lệ | | | OnDemandBaseCapacity giữ nền ổn định | |

{"MixedInstancesPolicy": {
  "InstancesDistribution": {
    "OnDemandBaseCapacity": 4,
    "OnDemandPercentageAboveBaseCapacity": 20,
    "SpotAllocationStrategy": "price-capacity-optimized"},
  "LaunchTemplate": {"Overrides": [
    {"InstanceType":"m5.large"},{"InstanceType":"m5a.large"},
    {"InstanceType":"m6i.large"},{"InstanceType":"m6a.large"}]}}}

⚠ Mixed instances policy của ASG thường tốt hơn Spot Fleet:

Tích hợp sẵn với ASG, ALB, scaling policy
    → và có Capacity Rebalancing
        ↓
    Spot Fleet là API cũ hơn
    → thiết kế mới nên dùng ASG

Ba lưu ý về Capacity Rebalancing: | Lưu ý | Chi tiết | |---|---| | ASG chủ động thay máy có nguy cơ | | | Khởi động máy mới TRƯỚC khi máy cũ bị lấy | | | Giữ được năng lực ổn định hơn | |

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-web \
  --capacity-rebalance

Ba lưu ý về Spot placement score: | Lưu ý | Chi tiết | |---|---| | Đánh giá khả năng đáp ứng của từng Region/AZ | | | Giúp chọn nơi triển khai | | | Miễn phí | |

Ba lưu ý về loại máy đa dạng: | Lưu ý | Chi tiết | |---|---| | Khai 6+ loại tương đương | | | Trộn cả họ Intel, AMD, Graviton | | | Ứng dụng phải chạy được trên mọi loại đã khai | |

⚠ Graviton cần image tương thích ARM:

Khai m6g.large cùng m5.large
    → nếu AMI chỉ có x86 thì máy Graviton không khởi động
        ↓
    Dùng image đa kiến trúc, hoặc tách launch template

Ba lưu ý về theo dõi: | Metric | Ý nghĩa | |---|---| | Tỷ lệ bị lấy lại theo pool | | | GroupInServiceInstances của ASG | | | Spot Instance Advisor cho tần suất lấy lại | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô phỏng bị lấy lại bằng FIS | | | Tắt một AZ, xem năng lực phục hồi | | | So hoá đơn trước và sau | |

aws fis start-experiment --experiment-template-id <id>

Và một lời khuyên: hãy khai ít nhất sáu tổ hợp loại máy và vùng sẵn sàng. Chiến lược diversified chỉ có tác dụng khi có nhiều pool để trải ra — khai một loại máy ở một AZ rồi chọn diversified là đặt tên cho một cấu hình vẫn tập trung toàn bộ rủi ro vào một chỗ.

Câu 45 Domain - Design for New Solutions

An enterprise runs its CMS application on an Auto Scaling group of Amazon EC2 instances behind an Application Load Balancer. The instances are placed on private subnets while the ALB is placed on public subnets. As part of best practices, the AWS Systems Manager Agent is installed on the instances and the AWS Systems Manager Session Manager is used to login into the instances. The EC2 instances send application logs to Amazon CloudWatch Logs.

Upon the deployment of the new application version, the new instances are being marked as unhealthy by the ALB and are being replaced by the Auto Scaling group. For troubleshooting, the solutions architect tries to log in on the unhealthy instances but the instances are getting terminated. The collected logs on CloudWatch Logs do not show definitive errors in the application.

Which of the following options is the quickest way for the solutions architect to troubleshoot the problem?

  1. A

    Go to the Auto Scaling Groups section in the AWS console and suspend the “Terminate” process for the ASG. Log in to one of the unhealthy instances using AWS Systems Manager Session Manager.
  2. B

    Create a temporary Amazon EC2 instance and deploy the new application version. Login to the EC2 instance using the SSH key. Add the instance to the Application Load Balancer to inspect application logs in real-time.
  3. C

    Update the application log setting to have more verbose logging to capture more application logs. Ensure that the Amazon CloudWatch agent is installed and running on the instances.
  4. D

    Select one of the new Amazon EC2 instances and enable EC2 instance termination protection. Gain access to the unhealthy instance using the AWS Systems Manager Session Manager.
Xem giải thích

Đáp án

A — Vào mục Auto Scaling Groups trong console, tạm dừng (suspend) tiến trình Terminate của ASG, rồi đăng nhập vào một máy không khoẻ bằng Systems Manager Session Manager.

Vì sao đúng

Đề mô tả một vòng lặp khiến việc gỡ lỗi không thể tiến hành:

Máy mới bị ALB đánh dấu unhealthy
    → ASG thay máy
        ↓
    Kiến trúc sư đăng nhập vào để xem
    → máy bị kết thúc giữa chừng
        ↓
    Không bao giờ kịp xem gì

⚠ Tạm dừng tiến trình Terminate cắt đúng vòng lặp đó:

aws autoscaling suspend-processes \
  --auto-scaling-group-name asg-cms \
  --scaling-processes Terminate

ASG ngừng kết thúc máy
    → máy không khoẻ NẰM LẠI
    → có thời gian đăng nhập và đọc log tại chỗ

⚠ Và đây là cách NHANH NHẤT — đúng tiêu chí của đề:

Một lệnh, có hiệu lực ngay
    → không phải dựng gì mới
    → không phải chờ triển khai lại

Bảy tiến trình của ASG có thể tạm dừng: | Tiến trình | Việc | |---|---| | Terminate | kết thúc máy — cái cần dừng ở đây | | Launch | khởi chạy máy mới | | HealthCheck | đánh dấu máy không khoẻ | | ReplaceUnhealthy | thay máy không khoẻ | | AZRebalance, AlarmNotification, AddToLoadBalancer | |

⚠ Có thể dừng HealthCheck và ReplaceUnhealthy thay vì Terminate:

Dừng ReplaceUnhealthy: máy hỏng không bị thay
Dừng HealthCheck: ASG không đánh dấu máy nào là hỏng
        ↓
    Cả ba đều cắt được vòng lặp
    → dừng Terminate là trực tiếp nhất

Đăng nhập bằng Session Manager:

aws ssm start-session --target i-abc

⚠ Session Manager hoạt động được ngay cả khi máy nằm ở subnet riêng tư:

Không cần khoá SSH, không cần bastion
    → máy chủ động gọi ra endpoint SSM
        ↓
    Đề nói đã cài SSM Agent — điều kiện đã sẵn

Nhớ bật lại sau khi xong:

aws autoscaling resume-processes \
  --auto-scaling-group-name asg-cms

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Có hiệu lực ngay lập tức | | | Xem được trạng thái thật của máy hỏng | | | Đảo ngược bằng một lệnh | |

⚠ Cần xem gì trên máy đó: | Nơi | Thông tin | |---|---| | Log khởi động ứng dụng | lỗi lúc bật | | curl localhost:<cổng>/health | health check trả về gì | | journalctl -u <dịch-vụ> | dịch vụ có chạy không | | /var/log/cloud-init-output.log | user data có lỗi không |

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

  • **D. Bật termination protection cho một máy mới rồi đăng nhập bằng Session Manager — đây là phương án gần nhất và nghe rất hợp lý, nhưng termination protection KHÔNG ngăn Auto Scaling kết thúc máy; nó chỉ chặn lời gọi TerminateInstances thủ công. ASG dùng cơ chế riêng và vẫn kết thúc máy đó.
  • **C. Tăng mức chi tiết của log ứng dụng — phải sửa mã, triển khai lại, chờ máy mới khởi chạy; chậm hơn nhiều và vẫn có thể không bắt được lỗi xảy ra trước khi logger sẵn sàng.
  • **B. Dựng một máy EC2 tạm rồi thêm vào ALB — mất thời gian dựng, và máy tạo bằng tay có thể khác máy do ASG tạo (khác user data, khác vai trò), nên có khi không tái hiện được lỗi.

Ghi nhớ

⚠ Termination protection KHÔNG áp cho Auto Scaling — bảng phải thuộc: | Cơ chế | Ngăn được gì | |---|---| | EC2 termination protection | lời gọi TerminateInstances THỦ CÔNG | | ASG instance scale-in protection | ASG thu nhỏ (scale-in) | | Suspend Terminate process | MỌI việc kết thúc của ASG |

⚠ Scale-in protection cũng không cứu được máy hỏng health check:

aws autoscaling set-instance-protection \
  --instance-ids i-abc --auto-scaling-group-name asg-cms \
  --protected-from-scale-in

Bảo vệ khỏi THU NHỎ
    → nhưng máy hỏng health check vẫn bị thay
        ↓
    Chỉ suspend process mới ngăn được cả hai

Từ khoá nhận diện:

"instances terminated before I can debug" → suspend Terminate / ReplaceUnhealthy "prevent manual termination" → termination protection "prevent scale-in from removing busy instance" → scale-in protection "finish work before shutdown" → lifecycle hook

⚠ Lifecycle hook là cách bền vững hơn cho môi trường sản xuất:

aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name asg-cms \
  --lifecycle-hook-name giu-de-dieu-tra \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 3600 --default-result CONTINUE

Máy vào trạng thái Terminating:Wait
    → giữ tới một giờ
        ↓
    Tự động hoá: Lambda chụp log ra S3 trước khi tắt
    → không cần ai can thiệp

Ba lưu ý về health check grace period: | Lưu ý | Chi tiết | |---|---| | Quá ngắn = máy bị giết trước khi kịp sẵn sàng | | | Phải bao gồm thời gian ứng dụng khởi động | | | Đây có thể chính là nguyên nhân gốc | |

⚠ Với triển khai phiên bản mới, đây là nghi phạm số một:

Phiên bản mới khởi động chậm hơn 30 giây
    → grace period vẫn giữ nguyên
        ↓
    Máy bị giết ngay trước khi sẵn sàng
    → và log không kịp ghi gì

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-cms \
  --health-check-grace-period 300

Ba nghi phạm khác: | Nghi phạm | Cách kiểm | |---|---| | Health check path sai | gọi thẳng từ máy | | Cổng health check khác cổng ứng dụng | | | Health check chạm phụ thuộc chưa sẵn sàng | |

Ba lưu ý về Session Manager: | Lưu ý | Chi tiết | |---|---| | Cần SSM Agent và instance profile | | | Cần đường ra tới endpoint SSM | | | Ghi log mọi phiên vào CloudTrail và S3 | |

Ba lưu ý về log: | Lưu ý | Chi tiết | |---|---| | Log ứng dụng có thể chưa kịp đẩy lên CloudWatch | | | Đọc trực tiếp trên máy chắc chắn hơn | | | Log của agent nằm ở /var/log/amazon/ | |

⚠ Đây là lý do đề nói "log trên CloudWatch không cho thấy lỗi rõ ràng":

Máy bị kết thúc trước khi agent kịp đẩy log
    → những dòng cuối cùng — quan trọng nhất — bị mất
        ↓
    Đọc tại chỗ mới thấy đủ

Ba lưu ý về triển khai an toàn hơn: | Cách | Chi tiết | |---|---| | Instance refresh với MinHealthyPercentage | | | CodeDeploy blue/green | | | Canary với ALB weighted target group | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi health check endpoint từ chính máy | | | So cấu hình máy mới và máy cũ | | | Xem lịch sử hoạt động của ASG | |

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name asg-cms --max-items 10 \
  --query "Activities[].[StartTime,StatusCode,Description]" --output table

Và một lời khuyên: hãy nhớ bật lại tiến trình đã tạm dừng ngay sau khi gỡ lỗi xong. Một ASG bị treo tiến trình Terminate sẽ không bao giờ dọn máy hỏng nữa — và điều đó chỉ lộ ra vào lần sự cố tiếp theo, khi cơ chế tự phục hồi mà bạn tin tưởng đã bị chính bạn tắt từ nhiều tuần trước.

Câu 46 Domain - Design Solutions for Organizational Complexity

A company has created multiple accounts in AWS to support the rapid growth of its cloud services. The multiple accounts are used to separate their various departments such as finance, human resources, engineering, and many others. Each account is managed by a Systems Administrator which has root access for that specific account only. There is a requirement to centrally manage policies across multiple AWS accounts by allowing or denying particular AWS services for individual accounts, or for groups of accounts.

Which is the most suitable solution that you should implement with the LEAST amount of complexity?

  1. A

    Provide access to externally authenticated users via Identity Federation. Set up an IAM role to specify permissions for users from each department whose identity is federated from your organization or a third-party identity provider.
  2. B

    Use AWS Organizations and Service Control Policies to control the list of AWS services that can be used by each member account.
  3. C

    Set up AWS Organizations and Organizational Units (OU) to connect all AWS accounts of each department. Create a custom IAM Policy to allow or deny the use of certain AWS services for each account.
  4. D

    Connect all departments by setting up cross-account access to each of the AWS accounts of the company. Create and attach IAM policies to your resources based on their respective departments to control access.
Xem giải thích

Đáp án

B — Dùng AWS Organizations và Service Control Policy (SCP) để kiểm soát danh sách dịch vụ AWS mà từng tài khoản thành viên được dùng.

Vì sao đúng

Đề nêu ba yêu cầu, và SCP là công cụ duy nhất đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Quản lý chính sách TẬP TRUNG cho nhiều tài khoản | SCP viết một lần ở tổ chức | | Cho phép hoặc từ chối dịch vụ theo tài khoản hoặc nhóm | gắn SCP vào tài khoản hoặc OU | | ÍT PHỨC TẠP NHẤT | không phải đụng vào từng tài khoản |

⚠ Chi tiết quyết định: mỗi quản trị viên có quyền ROOT trong tài khoản của họ:

Root của tài khoản thành viên
    → bỏ qua MỌI IAM policy
        ↓
    IAM policy không kiểm soát được họ
    → chỉ SCP mới chặn được root của tài khoản thành viên

Đây là lý do các phương án dựa trên IAM policy đều sai.

Gắn SCP:

aws organizations create-policy --name chan-dich-vu-khong-duyet \
  --type SERVICE_CONTROL_POLICY --content file://scp.json

aws organizations attach-policy --policy-id p-abc \
  --target-id ou-tai-chinh

Ví dụ allow list cho một phòng ban:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChiChoPhepDichVuCanThiet",
   "Effect": "Deny",
   "NotAction": [
     "ec2:*", "s3:*", "rds:*", "cloudwatch:*",
     "logs:*", "iam:*", "sts:*", "support:*"],
   "Resource": "*"}]}

⚠ Dùng Deny với NotAction thay vì Allow:

SCP dạng Allow: phải gỡ FullAWSAccess
    → dễ chặn nhầm dịch vụ nội bộ AWS cần
        ↓
    Deny + NotAction: giữ FullAWSAccess
    → an toàn hơn, dễ hiểu hơn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nơi định nghĩa cho mọi tài khoản | | | Tài khoản mới tự động được áp | | | Quản trị viên tài khoản KHÔNG gỡ được | |

⚠ Và hoá đơn hợp nhất là lợi ích kèm theo:

Organizations gộp hoá đơn
    → gộp mức dùng để tính bậc giá
    → chia sẻ RI và Savings Plans
        ↓
    Giải quyết được cả bài toán chi phí

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

  • **C. Dựng Organizations và OU, rồi tạo IAM policy tuỳ chỉnh cho từng tài khoản — đây là phương án gần nhất và dùng đúng Organizations, nhưng nó vẫn phải tạo và gắn IAM policy ở từng tài khoản một; và quản trị viên có quyền root ở đó có thể gỡ ra. Không phải "least complexity".
  • **A. Dùng Identity Federation với IAM role cho từng phòng ban — federation giải bài toán đăng nhập, không giải bài toán giới hạn dịch vụ nào được dùng.
  • **D. Thiết lập cross-account access giữa các phòng ban và gắn IAM policy — cross-account role là cơ chế cấp quyền truy cập, không phải cơ chế giới hạn; và vẫn phải cấu hình ở từng tài khoản.

Ghi nhớ

⚠ Bốn cơ chế kiểm soát quyền — bảng phải thuộc: | Cơ chế | Phạm vi | Cấp quyền | Chặn root thành viên | |---|---|---|---| | SCP | tài khoản trong tổ chức | KHÔNG | ✅ | | IAM policy | user, group, role | có | ❌ | | Permissions boundary | một identity | KHÔNG | ❌ | | Resource policy | tài nguyên | có | tuỳ |

⚠ SCP là cơ chế DUY NHẤT chặn được root của tài khoản thành viên — đây là lý do tồn tại của nó.

Từ khoá nhận diện:

"centrally allow or deny AWS services per account" → SCP "grant permissions to users" → IAM policy "single sign-on for employees" → IAM Identity Center "share resources across accounts" → RAM

⚠ Ba ngoại lệ SCP không áp: | Ngoại lệ | Chi tiết | |---|---| | Management account | SCP KHÔNG áp, kể cả gắn ở root | | Service-linked role | | | Hành động ngoài phạm vi Organizations | |

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

⚠ Allow list rất dễ gây sự cố:

Thiếu một action nhỏ
    → dịch vụ ngừng hoạt động
    → và lỗi chỉ hiện là AccessDenied
        ↓
    Bắt đầu bằng deny list, siết dần

Ba SCP nên có sớm: | SCP | Chặn gì | |---|---| | Chặn tắt CloudTrail, Config, GuardDuty | | | Giới hạn Region được dùng | | | Giới hạn loại instance | |

⚠ SCP giới hạn Region phải loại trừ dịch vụ toàn cầu:

{"Effect": "Deny",
 "NotAction": ["iam:*","organizations:*","route53:*",
               "cloudfront:*","support:*","budgets:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:RequestedRegion": ["ap-southeast-1"]}}}

Quên `iam:*` → không tạo được IAM role nào nữa
    → khoá chính mình ra khỏi khả năng sửa

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

⚠ Gắn SCP ở root làm mất khả năng ngoại lệ:

SCP ở root áp cho MỌI OU
    → OU con không thể cấp lại quyền cha đã Deny
        ↓
    Gắn ở từng OU thay vì ở root

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

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

Ba lưu ý về Organizations: | Lưu ý | Chi tiết | |---|---| | Phải bật ALL features để dùng SCP | | | Consolidated billing một mình không đủ | | | Control Tower dựng sẵn nhiều guardrail | |

aws organizations describe-organization \
  --query "Organization.FeatureSet"

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

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử dịch vụ bị chặn từ tài khoản thành viên | | | Thử bằng chính người dùng root của tài khoản đó | | | Kiểm tra management account không bị áp | |

Và một lời khuyên: hãy thử chính sách bằng người dùng root của một tài khoản thành viên. Đó là kịch bản duy nhất phân biệt SCP với IAM policy, và cũng chính là kịch bản mà đề này đang mô tả — mỗi quản trị viên phòng ban đều có quyền root trong phạm vi của họ.

Câu 47 Domain - Design Solutions for Organizational Complexity

A company is using AWS Organizations to manage their multi-account and multi-region AWS infrastructure. They are currently doing large-scale automation for their key daily processes to save costs. One of these key processes is sharing specified AWS resources, which an organizational account owns, with other AWS accounts of the company using AWS RAM. There is already an existing service which was previously managed by a separate organization account moderator, who also maintained the specific configuration details.

In this scenario, what could be a simple and effective solution that would allow the service to perform its tasks on the organization accounts on the moderator's behalf?

  1. A

    Enable cross-account access with AWS Organizations in the Resource Access Manager Console. Mirror the configuration changes that was performed by the account that previously managed this service.
  2. B

    Configure a service-linked role for AWS RAM and modify the permissions policy to specify what the role can and cannot do. Lastly, modify the trust policy of the role so that other processes can utilize AWS RAM.
  3. C

    Attach an IAM role on the service detailing all the allowed actions that it will be able to perform. Install an SSM agent in each of the worker VMs. Use AWS Systems Manager to build automation workflows that involve the daily key processes.
  4. D

    Use trusted access by running the enable-sharing-with-aws-organization command in the AWS RAM CLI. Mirror the configuration changes that was performed by the account that previously managed this service.
Xem giải thích

Đáp án

D — Dùng trusted access bằng cách chạy lệnh enable-sharing-with-aws-organization trong AWS RAM CLI, rồi tái tạo lại các thay đổi cấu hình mà tài khoản quản lý trước đó đã thực hiện.

Vì sao đúng

Đề mô tả một dịch vụ cần chia sẻ tài nguyên qua RAM trong nội bộ tổ chức, và AWS RAM có đúng một cơ chế cho việc đó.

⚠ enable-sharing-with-aws-organization là lệnh chuyên biệt:

aws ram enable-sharing-with-aws-organization

Lệnh này làm hai việc:
    → bật trusted access giữa RAM và Organizations
    → tạo service-linked role
      AWSServiceRoleForResourceAccessManager
        ↓
    Từ đó RAM chia sẻ được tài nguyên
      cho tài khoản và OU trong tổ chức

⚠ Không bật trusted access thì chỉ chia sẻ được theo ID tài khoản cụ thể:

Chưa bật: chia sẻ cho account ID riêng lẻ
    → mỗi tài khoản phải CHẤP NHẬN lời mời
        ↓
    Đã bật: chia sẻ cho ID tổ chức hoặc OU
    → tài khoản trong tổ chức TỰ ĐỘNG nhận được
    → không cần chấp nhận

Chia sẻ cho cả tổ chức:

aws ram create-resource-share \
  --name chia-se-subnet \
  --resource-arns arn:aws:ec2:ap-southeast-1:111111111111:subnet/subnet-abc \
  --principals o-abc123def4 \
  --allow-external-principals false

⚠ --allow-external-principals false giới hạn trong tổ chức:

Đặt true: chia sẻ được ra ngoài tổ chức
    → cần khi làm việc với đối tác
        ↓
    Đặt false: chỉ trong tổ chức
    → an toàn hơn cho tài nguyên nội bộ

Vì sao "đơn giản và hiệu quả":

Một lệnh CLI bật trusted access
    → rồi tái tạo cấu hình chia sẻ cũ
        ↓
    Không viết mã, không dựng hạ tầng
    → dịch vụ tự làm việc thay người quản lý cũ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tài khoản mới trong tổ chức tự nhận được chia sẻ | | | Không cần bước chấp nhận lời mời | | | Service-linked role do AWS quản lý | |

⚠ Trusted access phải bật từ MANAGEMENT ACCOUNT:

Lệnh chạy ở tài khoản thành viên → bị từ chối
    → chỉ management account (hoặc delegated
      administrator) mới bật được

Uỷ quyền quản trị RAM cho một tài khoản khác:

aws organizations register-delegated-administrator \
  --account-id 222222222222 \
  --service-principal ram.amazonaws.com

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

  • **B. Cấu hình service-linked role cho RAM và sửa permissions policy cùng trust policy — đây là phương án gần nhất và service-linked role thật sự có liên quan, nhưng service-linked role KHÔNG sửa được: AWS định nghĩa sẵn permissions policy và trust policy của nó. Và bạn không tạo nó bằng tay — lệnh enable-sharing-with-aws-organization tạo giúp.
  • **A. Bật cross-account access trong console Resource Access Manager — mô tả gần đúng nhưng thiếu chính xác: việc bật trusted access với Organizations mới là thao tác cần thiết, và đề hỏi cách để dịch vụ tự làm việc thay người.
  • **C. Gắn IAM role cho dịch vụ, cài SSM Agent trên các máy ảo và dùng Systems Manager dựng luồng tự động — Systems Manager quản lý instance; nó không liên quan gì tới việc chia sẻ tài nguyên qua RAM.

Ghi nhớ

⚠ Service-linked role — bảng đặc điểm phải thuộc: | Đặc điểm | Chi tiết | |---|---| | Ai định nghĩa | AWS, không phải bạn | | Sửa permissions policy | KHÔNG được | | Sửa trust policy | KHÔNG được | | SCP áp cho nó | KHÔNG | | Đường dẫn | /aws-service-role/ |

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

Từ khoá nhận diện:

"share resources within the organization via RAM" → enable-sharing-with-aws-organization "let a service act on your behalf" → service-linked role hoặc service role "trusted access between AWS service and Organizations" → enable-aws-service-access "delegate admin of a service to another account" → delegated administrator

⚠ Trusted access áp dụng cho nhiều dịch vụ, không chỉ RAM:

aws organizations enable-aws-service-access \
  --service-principal config.amazonaws.com

Config, CloudTrail, GuardDuty, Security Hub,
Firewall Manager, Backup...
        ↓
    Tất cả đều cần trusted access
      để hoạt động ở cấp tổ chức

Ba nhóm tài nguyên RAM chia sẻ được: | Nhóm | Ví dụ | |---|---| | Mạng | subnet, Transit Gateway, Route 53 Resolver rule | | Tính toán | Capacity Reservation, Dedicated Host | | Khác | License Manager config, Aurora DB cluster |

⚠ RAM KHÔNG chia sẻ được Reserved Instance:

RI được chia sẻ qua CONSOLIDATED BILLING
    → không qua RAM
        ↓
    Đây là nhầm lẫn phổ biến

Ba lưu ý về VPC sharing: | Lưu ý | Chi tiết | |---|---| | Chia sẻ SUBNET, không phải cả VPC | | | Tài khoản nhận chạy tài nguyên trong subnet đó | | | Chủ VPC vẫn quản lý route table và gateway | |

⚠ VPC sharing đơn giản hoá kiến trúc mạng rất nhiều:

Không có: mỗi tài khoản một VPC + peering/TGW
    → CIDR phải lập kế hoạch, phí attachment
        ↓
    Có: mọi tài khoản dùng chung subnet
    → không peering, không TGW, DNS tự nhiên hoạt động

Ba lưu ý về resource share: | Lưu ý | Chi tiết | |---|---| | Principal có thể là account ID, OU, hoặc ID tổ chức | | | Chia sẻ cho ID tổ chức là ít việc nhất | | | Cập nhật principal của share đã có được | |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | RAM có managed permission cho từng loại tài nguyên | | | Customer managed permission cho kiểm soát chi tiết | | | Tài khoản nhận vẫn cần IAM policy tương ứng | |

⚠ Chia sẻ tài nguyên không tự động cấp quyền dùng:

RAM làm tài nguyên HIỆN RA ở tài khoản kia
    → nhưng người dùng ở đó vẫn cần IAM policy
        ↓
    Hai tầng: RAM cho phép tài khoản,
              IAM cho phép người dùng

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi thao tác RAM | | | Cảnh báo khi có share ra ngoài tổ chức | | | Access Analyzer phát hiện chia sẻ ngoài dự kiến | |

Ba lưu ý về gỡ chia sẻ: | Lưu ý | Chi tiết | |---|---| | Gỡ principal khỏi share là mất quyền ngay | | | Tài nguyên đang chạy ở subnet chia sẻ bị ảnh hưởng | | | Kiểm tra trước khi gỡ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra trusted access đã bật | | | Xem danh sách resource share | | | Xác nhận tài khoản thành viên thấy tài nguyên | |

aws organizations list-aws-service-access-for-organization \
  --query "EnabledServicePrincipals[].ServicePrincipal" --output table
aws ram get-resource-shares --resource-owner SELF

Và một lời khuyên: hãy bật trusted access cho mọi dịch vụ cấp tổ chức ngay khi dựng Organizations. RAM, Config, GuardDuty, Backup và nhiều dịch vụ khác đều cần bước này, và phát hiện nó còn thiếu vào giữa lúc triển khai luôn tốn hơn nhiều so với bật sẵn từ đầu.

Câu 48 Domain - Design for New Solutions

A startup is building a web app that lets users post photos of good deeds in their neighborhood with a 143-character caption/article. The developers decided to write the application in ReactJS, a popular javascript framework so that it would run on the broadest range of browsers, mobile phones, and tablets. The app should provide access to Amazon DynamoDB to store the caption. The initial prototype shows that there aren't large spikes in usage.

Which option provides the most cost-effective and scalable architecture for this application?

  1. A

    Configure the ReactJS client with temporary credentials from the Security Token Service using a Token Vending Machine (TVM) to provide signed credentials to an IAM user. This will allow GET and PUT operations to DynamoDB. Serve your web application from an NGINX server hosted in a fleet of EC2 instances that are load-balanced and auto-scaled. Your EC2 instances are configured with an IAM role that allows GET and PUT operations in DynamoDB.
  2. B

    Register the web application with a Web Identity Provider such as Google, Facebook, Amazon, or from any other popular social sites and use the AssumeRoleWithWebIdentity API of STS to generate temporary credentials. Create an IAM role for that web provider and set up permissions for the IAM role to allow GET and PUT operations in Amazon S3 and DynamoDB. Serve your web app out of an S3 bucket enabled as a website.
  3. C

    Register the web application with a Web Identity Provider such as Google, Facebook, Amazon, or any other popular social site. Create an IAM role for that web provider and set up permissions for the IAM role to allow GET and PUT operations in DynamoDB. Serve your web application from an NGINX server hosted on a fleet of EC2 instances, with a load balancer and auto-scaling. Add an IAM role to the EC2 instance to allow GET and PUT operations to DynamoDB tables.
  4. D

    Configure the ReactJS client with temporary credentials from the Security Token Service using a Token Vending Machine (TVM) on an EC2 instance. This will provide signed credentials to an IAM user allowing GET and PUT operations in the DynamoDB table and the S3 bucket. You serve your mobile application out of an S3 bucket enabled as a website.
Xem giải thích

Đáp án

B — Đăng ký ứng dụng với Web Identity Provider (Google, Facebook, Amazon...) và dùng AssumeRoleWithWebIdentity của STS để sinh credential tạm; tạo IAM role cho nhà cung cấp đó với quyền GET và PUT trên S3 và DynamoDB; phục vụ ứng dụng web từ bucket S3 bật static website hosting.

Vì sao đúng

Đề nêu bốn dữ kiện, và cả bốn đều ủng hộ kiến trúc không máy chủ: | Dữ kiện | Ý nghĩa | |---|---| | ReactJS chạy trong TRÌNH DUYỆT | không cần máy chủ ứng dụng | | Cần truy cập DynamoDB | credential tạm qua STS | | Không có đỉnh tải lớn | không cần đội máy chờ sẵn | | Tiết kiệm và co giãn nhất | S3 + DynamoDB, không có EC2 nào |

⚠ Điểm quan trọng nhất: bỏ hẳn tầng máy chủ:

Phương án A và C: đội EC2 chạy NGINX
    → trả tiền 24/7 cho một trang tĩnh
    → phải vá, phải mở rộng, phải giám sát
        ↓
    B: S3 static website + client gọi thẳng DynamoDB
    → không có gì để vận hành
    → không có gì tính tiền lúc rảnh

Luồng xác thực:

1. Người dùng đăng nhập bằng Google/Facebook
    → nhận OIDC token
        ↓
2. Client gọi sts:AssumeRoleWithWebIdentity
    → nhận credential AWS TẠM
        ↓
3. Client gọi thẳng DynamoDB và S3
    → không qua máy chủ trung gian nào

Trust policy cho vai trò:

{"Effect": "Allow",
 "Principal": {"Federated": "accounts.google.com"},
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {"StringEquals": {
   "accounts.google.com:aud": "<client-id>"}}}

⚠ Điều kiện aud là bắt buộc — thiếu nó là lỗ hổng nghiêm trọng:

Không giới hạn `aud`
    → BẤT KỲ ứng dụng Google nào cũng
      đảm nhận được vai trò này
        ↓
    Kẻ tấn công tạo một app Google, lấy token,
      rồi truy cập dữ liệu của bạn

Phân quyền chi tiết tới từng người dùng:

{"Effect": "Allow",
 "Action": ["dynamodb:GetItem","dynamodb:PutItem","dynamodb:Query"],
 "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/BaiViet",
 "Condition": {"ForAllValues:StringEquals": {
   "dynamodb:LeadingKeys": ["${accounts.google.com:sub}"]}}}

⚠ dynamodb:LeadingKeys là thứ làm cho kiến trúc này an toàn:

Client gọi thẳng DynamoDB
    → nhưng CHỈ đọc ghi được item của chính mình
        ↓
    Kiểm soát ở tầng IAM, không phải tầng ứng dụng
    → không có mã máy chủ nào để viết sai

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chi phí gần bằng 0 khi không có người dùng | | | Mở rộng theo S3 và DynamoDB — gần như vô hạn | | | Credential tạm, tự hết hạn | |

⚠ Đề nhắc "S3 và DynamoDB" vì ứng dụng cần cả hai:

Ảnh việc tốt → S3
Chú thích 143 ký tự → DynamoDB
        ↓
    Vai trò phải cấp quyền trên CẢ HAI

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

  • **C. Đăng ký Web Identity Provider và tạo IAM role, nhưng phục vụ ứng dụng từ đội EC2 chạy NGINX có load balancer và auto scaling — đây là phương án gần nhất và phần xác thực đúng, nhưng nó giữ lại toàn bộ tầng máy chủ mà ứng dụng ReactJS không cần; đắt hơn và nhiều việc hơn.
  • **A. Dùng Token Vending Machine cấp credential cho một IAM user và phục vụ từ đội EC2 — TVM là mẫu cũ có trước khi có Web Identity Federation; và cấp credential cho IAM user thay vì vai trò tạm là mô hình kém an toàn hơn.
  • **D. Dùng TVM chạy trên một EC2 instance — vẫn phải vận hành một máy chủ chỉ để cấp token, trong khi STS làm việc đó miễn phí và không cần hạ tầng nào.

Ghi nhớ

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

Từ khoá nhận diện:

"browser/mobile app accesses AWS directly with social login" → AssumeRoleWithWebIdentity "corporate SSO to AWS console" → SAML + IAM Identity Center "user directory with sign-up/sign-in" → Cognito User Pool "exchange social token for AWS credentials" → Cognito Identity Pool

⚠ Cognito Identity Pool là cách dễ hơn để làm cùng việc:

aws cognito-identity create-identity-pool \
  --identity-pool-name kho-danh-tinh \
  --no-allow-unauthenticated-identities \
  --supported-login-providers accounts.google.com=<client-id>

Identity Pool gọi AssumeRoleWithWebIdentity giúp bạn
    → và quản lý nhiều nhà cung cấp trong một chỗ
        ↓
    Về bản chất là cùng cơ chế

Ba lưu ý về S3 static website: | Lưu ý | Chi tiết | |---|---| | Endpoint website chỉ HTTP, không HTTPS | | | Nên đặt CloudFront phía trước | | | CloudFront + OAC giữ bucket riêng tư | |

⚠ Với ứng dụng thật, luôn thêm CloudFront:

S3 website endpoint: http://... — không có TLS
    → đăng nhập qua HTTP là không chấp nhận được
        ↓
    CloudFront: HTTPS miễn phí qua ACM
    → và cache toàn cầu

Ba lưu ý về SPA trên S3: | Lưu ý | Chi tiết | |---|---| | Đường dẫn client-side trả 404 từ S3 | | | Trỏ 404 về index.html với mã 200 | | | Hoặc dùng CloudFront Function viết lại URL | |

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

Ba lưu ý về thiết kế bảng DynamoDB: | Lưu ý | Chi tiết | |---|---| | Partition key = định danh người dùng | | | On-demand cho tải thất thường | | | Chú thích 143 ký tự vừa trong một item | |

⚠ Chế độ on-demand hợp với "không có đỉnh tải lớn":

Provisioned: phải đoán RCU/WCU
    → đoán sai là throttle hoặc trả tiền thừa
        ↓
    On-demand: trả theo request thật
    → hợp với ứng dụng mới chưa biết quy mô

Ba lưu ý về ảnh trong S3: | Lưu ý | Chi tiết | |---|---| | Client tải thẳng lên bằng pre-signed URL hoặc credential tạm | | | Giới hạn tiền tố theo danh tính người dùng | | | Đặt lifecycle cho ảnh cũ | |

{"Effect": "Allow", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::anh-nguoi-dung/${accounts.google.com:sub}/*"}

Ba lưu ý về bảo mật client: | Lưu ý | Chi tiết | |---|---| | KHÔNG nhúng access key vào mã JavaScript | | | Credential tạm là cách duy nhất đúng | | | Bật CORS đúng cho bucket | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi lần AssumeRoleWithWebIdentity | | | Đặt RoleSessionName mang danh tính người dùng | | | Theo dõi ThrottledRequests của DynamoDB | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử đọc item của người dùng khác | phải bị từ chối | | Kiểm tra credential hết hạn đúng | | | Xem CloudTrail ghi đúng danh tính | |

Và một lời khuyên: hãy luôn thêm điều kiện aud vào trust policy của vai trò web identity. Không có nó, bất kỳ ai tạo được một ứng dụng trên cùng nhà cung cấp danh tính đều đảm nhận được vai trò của bạn — và đó là một trong những cấu hình sai nguy hiểm nhất mà vẫn trông hoàn toàn bình thường.

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

A company has launched a company-wide bug bounty program to find and patch up security vulnerabilities in your web applications as well as the underlying cloud resources. As the solutions architect, you are focused on checking system vulnerabilities on AWS resources for DDoS attacks. Due to budget constraints, the company cannot afford to enable AWS Shield Advanced to prevent higher-level attacks.

Which of the following are the best techniques to help mitigate Distributed Denial of Service (DDoS) attacks for cloud infrastructure hosted in AWS? (Select TWO.)

  1. A

    Use S3 as a POSIX-compliant storage instead of EBS Volumes for storing data. Install the SSM agent to all of your instances and use AWS Systems Manager Patch Manager to automatically patch your instances.
  2. B

    Use Reserved EC2 instances to ensure that each instance has the maximum performance possible. Use AWS WAF to protect your web applications from common web exploits that could affect application availability.
  3. C

    Use an Amazon CloudFront distribution for both static and dynamic content of your web applications. Add CloudWatch alerts to automatically look and notify the Operations team for high CPUUtilization and NetworkIn metrics, as well as to trigger Auto Scaling of your EC2 instances.
  4. D

    Add multiple Elastic Network Interfaces to each EC2 instance and use Enhanced Networking to increase the network bandwidth.
  5. E

    Use an Application Load Balancer (ALB) to reduce the risk of overloading your application by distributing traffic across many backend instances. Integrate AWS WAF and the ALB to protect your web applications from common web exploits that could affect application availability.
Xem giải thích

Đáp án

C và E — Dùng CloudFront cho cả nội dung tĩnh lẫn động, kèm CloudWatch alarm theo dõi CPUUtilization và NetworkIn để cảnh báo và kích hoạt Auto Scaling; và dùng ALB phân tán tải qua nhiều máy backend, tích hợp AWS WAF với ALB.

Vì sao đúng

Đề nêu ràng buộc rõ: không đủ ngân sách cho Shield Advanced, nên phải dựa vào kiến trúc và các dịch vụ miễn phí hoặc rẻ.

Kỹ thuật Chống DDoS thế nào
CloudFront hấp thụ tấn công ở EDGE toàn cầu
ALB phân tán tải, tự mở rộng
Auto Scaling thêm năng lực khi bị dồn
WAF lọc tấn công tầng 7

⚠ CloudFront là biện pháp chống DDoS mạnh nhất mà không tốn thêm tiền:

Tấn công tới hàng trăm edge trên thế giới
    → mỗi edge chỉ chịu một phần nhỏ
        ↓
    Origin gần như không thấy gì
    → và Shield Standard bảo vệ chính CloudFront

⚠ Shield Standard đã BẬT SẴN và MIỄN PHÍ cho mọi khách hàng:

Bảo vệ tầng 3/4 tự động cho
CloudFront, Route 53, Global Accelerator, ELB
        ↓
    Không phải bật gì
    → đây là lý do kiến trúc dùng các dịch vụ đó
      đã được bảo vệ cơ bản

Giấu origin sau CloudFront:

aws elbv2 create-rule --listener-arn <arn> --priority 1 \
  --conditions '[{"Field":"http-header",
    "HttpHeaderConfig":{"HttpHeaderName":"X-Origin-Secret",
                        "Values":["chuoi-bi-mat"]}}]' \
  --actions Type=forward,TargetGroupArn=<arn-tg>

⚠ Không giấu origin thì CloudFront vô nghĩa với DDoS:

Kẻ tấn công tìm ra IP thật của ALB
    → tấn công thẳng, bỏ qua CloudFront
        ↓
    Dùng custom header bí mật, hoặc
      managed prefix list của CloudFront

aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing

WAF với rate-based rule:

{"Name": "GioiHanTanSuat", "Priority": 1,
 "Statement": {"RateBasedStatement":
   {"Limit": 2000, "AggregateKeyType": "IP"}},
 "Action": {"Block": {}},
 "VisibilityConfig": {"SampledRequestsEnabled": true,
   "CloudWatchMetricsEnabled": true, "MetricName": "GioiHanTanSuat"}}

⚠ Rate-based rule là công cụ chống DDoS tầng 7 rẻ nhất:

Tấn công HTTP flood từ ít IP
    → rate-based rule chặn tự động
        ↓
    ~1 USD/tháng cho một quy tắc
    → so với ~3.000 USD của Shield Advanced

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hấp thụ ở edge, không tới origin | | | Auto Scaling hấp thụ phần lọt qua | | | WAF lọc tấn công tầng ứng dụng | |

⚠ Cảnh báo NetworkIn là chỉ số phát hiện DDoS sớm:

aws cloudwatch put-metric-alarm --alarm-name luu-luong-bat-thuong \
  --namespace AWS/EC2 --metric-name NetworkIn \
  --dimensions Name=AutoScalingGroupName,Value=asg-web \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 500000000 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

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

  • **B. Dùng Reserved EC2 instance để mỗi máy có hiệu năng tối đa, kèm WAF — đây là phương án gần nhất vì có WAF, nhưng Reserved Instance là mô hình THANH TOÁN, không phải cơ chế hiệu năng hay bảo mật; nó không giúp gì cho việc chống DDoS.
  • **D. Thêm nhiều ENI cho mỗi máy và dùng enhanced networking — tăng băng thông của một máy không chống được tấn công phân tán; DDoS làm cạn năng lực toàn hệ thống, không phải của một card mạng.
  • **A. Dùng S3 thay EBS và Patch Manager vá máy — vá lỗ hổng là việc tốt nhưng không liên quan tới DDoS; và S3 không phải kho POSIX để thay EBS.

Ghi nhớ

⚠ Bốn tầng bảo vệ DDoS trên AWS — bảng phải thuộc: | Tầng | Công cụ | Phí | |---|---|---| | 3/4 cơ bản | Shield Standard | MIỄN PHÍ, tự bật | | 3/4 nâng cao + hỗ trợ | Shield Advanced | ~3.000 USD/tháng | | 7 (HTTP) | WAF | vài USD | | Kiến trúc | CloudFront, ALB, Auto Scaling | theo mức dùng |

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

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

Từ khoá nhận diện:

"mitigate DDoS without Shield Advanced" → CloudFront + ALB + Auto Scaling + WAF "layer 3/4 DDoS" → Shield "HTTP flood, SQLi, XSS" → WAF "detect compromised instances" → GuardDuty

Ba nguyên tắc thiết kế chống DDoS của AWS: | Nguyên tắc | Chi tiết | |---|---| | Giảm bề mặt tấn công | giấu origin, dùng subnet riêng tư | | Sẵn sàng mở rộng | Auto Scaling, ELB, CloudFront | | Biết lưu lượng bình thường | để nhận ra bất thường |

⚠ Vế thứ ba hay bị bỏ qua:

Không biết lưu lượng bình thường là bao nhiêu
    → không đặt được ngưỡng cảnh báo hợp lý
        ↓
    Ngưỡng quá cao: không bao giờ báo
    Ngưỡng quá thấp: báo suốt, không ai đọc

Ba loại tấn công DDoS: | Loại | Tầng | Ví dụ | |---|---|---| | Volumetric | 3/4 | UDP reflection, DNS amplification | | State-exhaustion | 4 | SYN flood | | Application layer | 7 | HTTP flood, Slowloris |

⚠ Tấn công tầng 7 khó chặn nhất:

Request trông giống người dùng thật
    → không phân biệt được bằng luật đơn giản
        ↓
    Cần rate-based rule, CAPTCHA, hoặc
      bot control của WAF

Ba quy tắc WAF nên bật: | Quy tắc | Việc | |---|---| | Rate-based rule | chặn IP gửi quá nhiều | | AWSManagedRulesAmazonIpReputationList | IP xấu đã biết | | AWSManagedRulesBotControlRuleSet | phát hiện bot |

Ba lưu ý về Auto Scaling khi bị tấn công: | Lưu ý | Chi tiết | |---|---| | Mở rộng giúp chịu tải nhưng TỐN TIỀN | | | Đặt max-size là trần chi phí | | | Cảnh báo khi chạm max | |

⚠ Đây là đánh đổi thật khi không có Shield Advanced:

Shield Advanced hoàn phí mở rộng do bị tấn công
    → không có nó thì bạn trả toàn bộ
        ↓
    Đặt max-size ở mức chịu được về tài chính
    → thà chậm còn hơn phá sản

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | Cache cả nội dung động (TTL 0 vẫn qua mạng AWS) | | | Geo restriction chặn vùng không phục vụ | | | Origin failover cho dự phòng | |

Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Được Shield Standard bảo vệ | | | Health check tự rút endpoint hỏng | | | Không phơi IP gốc trong bản ghi DNS | |

Ba lưu ý về ứng phó: | Việc | Chi tiết | |---|---| | Có runbook cho tình huống DDoS | | | Biết cách bật rate-based rule khẩn cấp | | | Liên hệ AWS Support nếu nghiêm trọng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử gọi thẳng ALB | phải bị chặn | | Kiểm tra CacheHitRate của CloudFront | | | Chạy tải giả xem Auto Scaling phản ứng | |

Và một lời khuyên: hãy giấu origin ngay khi đặt CloudFront lên trước nó. Toàn bộ giá trị chống DDoS của CDN biến mất nếu địa chỉ thật của load balancer vẫn nhận kết nối trực tiếp — và địa chỉ đó thường tìm ra chỉ bằng vài phút tra cứu lịch sử DNS.

Câu 50 Domain - Accelerate Workload Migration and Modernization

A company has several virtual machines on its on-premises data center hosting its three-tier web application. The company wants to migrate the application to AWS to take advantage of the benefits of cloud computing. The following are the company requirements for the migration process:

- The virtual machine images from the on-premises data center must be imported to AWS.

- The changes on the on-premises servers must be synchronized to the AWS servers until the production cutover is completed.

- Have minimal downtime during the production cutover.

- The root volumes and data volumes (containing Terabytes of data) of the VMs must be migrated to AWS.

- The migration solution must have minimal operational overhead.

Which of the following options is the recommended solution to meet the company requirements?

  1. A

    Leverage both AWS Application Discovery Service and AWS Migration Hub to group the on-premises VMs as an application. Write an AWS CLI script that uses VM Import/Export to import the VMs as AMIs. Schedule the script to run at regular intervals to synchronize the changes from the on-premises environment to AWS. Launch Amazon EC2 instances based on the images created from VM Import/Export. After successful testing, perform a final virtual machine import before the cutover. Launch new instances based on the updated AMIs.
  2. B

    Create a job on AWS Application Migration Service (MGN) to migrate the virtual machines to AWS. Install the replication agent on each application tier to sync the changes from the on-premises environment to AWS. Launch Amazon EC2 instances based on the replicated VM from AWS MGN. After successful testing, perform a cutover and launch new instances based on the updated AMIs.
  3. C

    Create a job on AWS Application Migration Service (MGN) to migrate the root volumes of the virtual machines to AWS. Import the data volumes using the AWS CLI import-snapshot command. Launch Amazon EC2 instances based on the images created from AWS MGN and attach the imported data volumes. After successful testing, perform a final replication before the cutover. Launch new instances based on the updated AMIs and attach the corresponding data volumes.
  4. D

    Write an AWS CLI script that uses VM Import/Export to migrate the virtual machines. Schedule the script to run at regular intervals to synchronize the changes from the on-premises environment to AWS. Launch Amazon EC2 instances based on the images created from VM Import/Export. After successful testing, re-run the script to perform a final replication before the cutover. Launch new instances based on the updated AMIs.
Xem giải thích

Đáp án

B — Tạo job trên AWS Application Migration Service (MGN) để di chuyển máy ảo; cài replication agent trên từng tầng ứng dụng để đồng bộ thay đổi liên tục; khởi chạy EC2 từ máy ảo đã nhân bản; sau khi kiểm thử thành công thì thực hiện cắt chuyển.

Vì sao đúng

Đề nêu năm yêu cầu, và MGN đáp ứng cả năm: | Yêu cầu | Cách đáp ứng | |---|---| | Nhập ảnh máy ảo từ tại chỗ vào AWS | MGN nhân bản toàn bộ máy | | Đồng bộ thay đổi tới lúc cắt chuyển | replication agent chạy liên tục | | Thời gian ngừng TỐI THIỂU | cắt chuyển chỉ vài phút | | CẢ volume gốc lẫn volume dữ liệu (nhiều TB) | MGN nhân bản mọi đĩa | | CÔNG VẬN HÀNH TỐI THIỂU | không viết script nào |

⚠ MGN nhân bản LIÊN TỤC ở mức khối — đây là điều làm nên tất cả:

VM Import/Export: chụp ảnh MỘT LẦN
    → phải chạy lại để đồng bộ
    → mỗi lần là một lần import đầy đủ
        ↓
MGN: agent nhân bản THAY ĐỔI liên tục
    → dữ liệu ở AWS luôn gần như cập nhật
    → cắt chuyển chỉ mất vài phút

Quy trình MGN:

1. Cài replication agent trên từng máy nguồn
        ↓
2. MGN dựng "staging area" trong VPC của bạn
    → máy nhân bản rẻ tiền + volume EBS
        ↓
3. Nhân bản nền hoàn tất → chuyển sang
   trạng thái "Continuous Data Protection"
        ↓
4. Khởi chạy TEST instance để kiểm thử
    → không ảnh hưởng nhân bản
        ↓
5. Cắt chuyển: khởi chạy CUTOVER instance

Cài agent:

wget -O ./aws-replication-installer-init \
  https://aws-application-migration-service-ap-southeast-1.s3.ap-southeast-1.amazonaws.com/latest/linux/aws-replication-installer-init
sudo ./aws-replication-installer-init \
  --region ap-southeast-1 \
  --aws-access-key-id <key> --aws-secret-access-key <secret>

⚠ Khả năng kiểm thử mà KHÔNG dừng nhân bản là lợi thế lớn:

Khởi chạy test instance
    → chạy từ snapshot của dữ liệu đã nhân bản
    → nhân bản VẪN TIẾP TỤC ở nền
        ↓
    Kiểm thử bao nhiêu lần cũng được
    → rồi mới cắt chuyển thật

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không sửa gì ở ứng dụng nguồn | | | Nhân bản mọi đĩa, mọi hệ điều hành | | | MGN miễn phí 90 ngày mỗi máy chủ | |

⚠ MGN miễn phí trong 90 ngày cho mỗi máy chủ nguồn:

Chỉ trả tiền hạ tầng staging (EC2 nhỏ + EBS)
    → dịch vụ MGN không tính phí trong 90 ngày
        ↓
    Đủ cho hầu hết dự án di chuyển

⚠ Terabyte dữ liệu là chi tiết cần lập kế hoạch băng thông:

Nhân bản nền phải chuyển hết dữ liệu qua mạng
    → nhiều TB có thể mất nhiều ngày
        ↓
    Ước lượng trước, và cân nhắc
      Direct Connect nếu quá chậm

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

  • **C. MGN cho volume gốc nhưng nhập volume dữ liệu bằng import-snapshot — đây là phương án gần nhất và dùng đúng MGN, nhưng nó tách đôi việc một cách vô ích: MGN nhân bản mọi volume, không chỉ volume gốc. Và import-snapshot là thao tác một lần, không đồng bộ liên tục.
  • **D. Viết script CLI dùng VM Import/Export, chạy định kỳ để đồng bộ — VM Import/Export tạo AMI mỗi lần chạy, không nhân bản gia tăng; với nhiều TB thì mỗi lần chạy mất rất lâu, và tự viết script là công vận hành lớn.
  • **A. Dùng Application Discovery Service và Migration Hub để nhóm máy ảo, rồi script VM Import/Export — Discovery Service chỉ khảo sát, Migration Hub chỉ theo dõi tiến độ; cả hai không di chuyển gì, và phần còn lại mắc cùng lỗi với D.

Ghi nhớ

⚠ Bốn công cụ di chuyển — bảng phải thuộc: | Công cụ | Việc | |---|---| | Application Discovery Service | KHẢO SÁT, lập danh mục — không di chuyển | | Migration Hub | THEO DÕI tiến độ — không di chuyển | | Application Migration Service (MGN) | DI CHUYỂN máy chủ, nhân bản liên tục | | Database Migration Service (DMS) | DI CHUYỂN cơ sở dữ liệu |

⚠ AWS Server Migration Service (SMS) đã NGỪNG — thay bằng MGN. Đề cũ còn nhắc SMS; biết để nhận ra nó là phương án lỗi thời.

Từ khoá nhận diện:

"lift and shift servers, minimal downtime, continuous sync" → MGN "migrate database" → DMS (+ SCT nếu đổi engine) "discover on-premises inventory" → Application Discovery Service "track migration progress" → Migration Hub "one-time VM image import" → VM Import/Export

⚠ MGN vs VM Import/Export: | Tiêu chí | MGN | VM Import/Export | |---|---|---| | Nhân bản liên tục | ✅ | ❌ một lần | | Thời gian ngừng | phút | giờ tới ngày | | Kiểm thử trước cắt chuyển | ✅ | phải import lại | | Cần agent | có | không |

Ba chiến lược di chuyển (7R): | Chiến lược | Nghĩa | |---|---| | Rehost | "lift and shift" — MGN | | Replatform | đổi một phần (RDS thay MySQL tự quản) | | Refactor | viết lại kiến trúc | | Repurchase, Retire, Retain, Relocate | |

⚠ Đề này là REHOST thuần tuý:

"Import VM images", "minimal changes"
    → không đổi kiến trúc
    → MGN là công cụ chuẩn cho rehost

Ba giai đoạn của MGN: | Giai đoạn | Chi tiết | |---|---| | Replication | nhân bản nền rồi liên tục | | Testing | khởi chạy test instance | | Cutover | khởi chạy production, dừng nhân bản |

Ba lưu ý về staging area: | Lưu ý | Chi tiết | |---|---| | MGN dựng máy nhỏ và EBS trong VPC của bạn | | | Bạn trả tiền phần đó | | | Xoá tự động sau khi cắt chuyển | |

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Giới hạn được băng thông của agent | | | Nhân bản nền là phần nặng nhất | | | Direct Connect nếu dữ liệu rất lớn | |

⚠ Công thức ước lượng thời gian nhân bản nền:

Thời gian (giờ) = dung lượng (TB) × 1000
                  / (băng thông Mbps × 0,45)
        ↓
    10 TB qua 500 Mbps ≈ 44 giờ

Ba lưu ý về launch template: | Lưu ý | Chi tiết | |---|---| | Cấu hình loại instance, subnet, security group | | | Khác nhau giữa test và cutover | | | Đặt trước để cắt chuyển nhanh | |

Ba lưu ý về post-launch: | Lưu ý | Chi tiết | |---|---| | MGN chạy được action sau khi khởi chạy | | | Cài CloudWatch agent, SSM agent tự động | | | Giảm việc thủ công sau cắt chuyển | |

Ba lưu ý về CSDL: | Lưu ý | Chi tiết | |---|---| | MGN nhân bản được CSDL trên máy ảo | | | Nhưng DMS thường tốt hơn cho CSDL | | | Cân nhắc replatform sang RDS | |

⚠ Nhân bản mức khối cho CSDL đang chạy có rủi ro:

MGN nhân bản đĩa, không hiểu giao dịch
    → CSDL khởi động ở AWS có thể cần crash recovery
        ↓
    Với CSDL, DMS an toàn hơn
    → hoặc dừng CSDL trước khi cắt chuyển

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem trạng thái nhân bản trong console MGN | | | Khởi chạy test instance và kiểm ứng dụng | | | Đo độ trễ nhân bản trước khi cắt chuyển | |

aws mgn describe-source-servers \
  --query "items[].[sourceServerID,dataReplicationInfo.dataReplicationState]" \
  --output table

Và một lời khuyên: hãy khởi chạy test instance ít nhất một lần trước ngày cắt chuyển. Nhân bản báo "healthy" không đồng nghĩa với ứng dụng khởi động được trên AWS — driver, địa chỉ IP cố định, license gắn phần cứng đều là những thứ chỉ lộ ra khi máy thật sự chạy.