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

Tìm thấy 1221 câu.

Câu 241 Domain - Design for New Solutions

A tech company uses AWS CloudFormation to deploy a three-tier web application that consists of a web tier, application tier, and database tier. The application will utilize an Amazon DynamoDB table for database storage. All resources will be created using a CloudFormation template.

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

  1. A

    Launch an IAM Role that has the required permissions to read and write from the required DynamoDB table. Associate the Role to the application instances by referencing it to the AWS::IAM::InstanceRoleName Property.
  2. B In the CloudFormation template, use the Parameter section to have the user input the AWS Access and Secret Keys from an already created IAM user that has the permissions required to interact with the DynamoDB table.
  3. C

    Launch an IAM Role that has the required permissions to read and write from the DynamoDB table. Reference the IAM Role as a property inside the AWS::IAM::InstanceProfile of the application instance.
  4. D Launch an IAM user in the CloudFormation template that has permissions to read and write from the DynamoDB table. Use the GetAtt function to retrieve the Access and secret keys and pass them to the web application instance through the use of its instance user-data.
Xem giải thích

Đáp án

**C — Tạo IAM role có quyền đọc và ghi bảng DynamoDB, rồi tham chiếu vai trò đó như một thuộc tính bên trong AWS::IAM::InstanceProfile của instance ứng dụng.

Vì sao đúng

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

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

⚠ Và AWS::IAM::InstanceRoleName trong phương án A KHÔNG TỒN TẠI:

CloudFormation có ba loại tài nguyên
  IAM liên quan:
    `AWS::IAM::Role`
    `AWS::IAM::InstanceProfile`
    `AWS::IAM::Policy`
        ↓
    Không có `InstanceRoleName`
    → và không có thuộc tính nào
      tên như vậy

Template đúng:

Resources:
  VaiTroUngDung:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        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
        ↓
    Bảng điều khiển tạo ngầm
      instance profile cho bạn
        ↓
    CloudFormation phải khai
      TƯỜNG MINH
    → đây là lỗi hay gặp khi
      viết template lần đầu

⚠ Và GetAtt để lấy access key (phương án D) là mẫu sai nghiêm trọng:

`!GetAtt NguoiDung.SecretAccessKey`
    → giá trị này nằm trong
      LỊCH SỬ STACK
        ↓
    Ai xem stack đều lấy được
    → và truyền qua user-data thì
      đọc được từ instance metadata

⚠ Và tham số cho người dùng nhập khoá (phương án B) cũng vậy:

`NoEcho: true` chỉ che trên
  bảng điều khiển
        ↓
    Giá trị vẫn được lưu
    → `describe-stacks` trả về nó

SDK tự lấy credential:

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à phải bắt buộc IMDSv2:

  MayChuUngDung:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref HoSoInstance
      MetadataOptions:
        HttpTokens: required
        HttpPutResponseHopLimit: 1

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 có hiệu lực ngay, không triển khai lại | | | CloudTrail ghi rõ vai trò nào gọi API | |

⚠ Và giới hạn quyền theo ARN của chính bảng:

Resource: !GetAtt BangDuLieu.Arn

Không dùng `Resource: "*"`
    → chỉ bảng này
        ↓
    Và nếu bảng có chỉ mục
    → thêm `!Sub '${BangDuLieu.Arn}/index/*'`

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

  • **A. Tạo IAM role có quyền đọc/ghi bảng và gắn vào instance bằng cách tham chiếu tới thuộc tính AWS::IAM::InstanceRoleName — đây là phương án gần nhất và phần IAM role hoàn toàn đúng, nhưng AWS::IAM::InstanceRoleName không phải loại tài nguyên hay thuộc tính nào của CloudFormation; phải qua AWS::IAM::InstanceProfile.
  • **D. Tạo IAM user trong template, dùng GetAtt lấy access key và secret key rồi truyền qua user-data — user-data đọc được từ instance metadata, và khoá nằm trong lịch sử stack.
  • **B. Dùng phần Parameters để người dùng nhập access key và secret key — giá trị nằm trong lịch sử stack, và NoEcho chỉ che hiển thị.

Ghi nhớ

⚠ Ba tài nguyên IAM trong CloudFormation — bảng phải thuộc: | Tài nguyên | Vai trò | |---|---| | AWS::IAM::Role | vai trò và trust policy | | AWS::IAM::InstanceProfile | lớp bọc để gắn vai trò vào EC2 | | AWS::IAM::Policy | chính sách gắn thêm |

Từ khoá nhận diện:

"without exposing API credentials" → IAM role + instance profile "where credentials come from" → instance metadata "secret in CloudFormation" → dynamic reference tới Secrets Manager "NoEcho" → chỉ che hiển thị, KHÔNG bảo vệ

⚠ Hai nguồn thông tin trên EC2 — phải phân biệt: | Nguồn | Chứa gì | |---|---| | Instance metadata | thông tin instance + CREDENTIAL vai trò | | Instance user data | script khởi động do bạn viết |

Ba lưu ý về instance profile: | Lưu ý | Chi tiết | |---|---| | Một profile chứa đúng một vai trò | | | Đổi được trên instance đang chạy | | | Launch template cũng khai được | |

  MauKhoiChay:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateData:
        IamInstanceProfile:
          Arn: !GetAtt HoSoInstance.Arn

⚠ Trong launch template phải dùng Arn, không phải Ref:

`AWS::EC2::Instance` nhận `!Ref`
  (tên profile)
        ↓
    `LaunchTemplateData` nhận `Arn`
    → nhầm là lỗi triển khai

Ba lưu ý về bí mật trong CloudFormation: | Lưu ý | Chi tiết | |---|---| | Dùng dynamic reference tới Secrets Manager | | | Hoặc để CloudFormation tự sinh mật khẩu | | | KHÔNG bao giờ qua Parameters hay Outputs | |

  BiMatCSDL:
    Type: AWS::SecretsManager::Secret
    Properties:
      GenerateSecretString:
        SecretStringTemplate: '{"username": "quantri"}'
        GenerateStringKey: password
        PasswordLength: 32

⚠ Để CloudFormation tự sinh là cách an toàn nhất:

Không người nào từng nhìn thấy
  mật khẩu
        ↓
    Không nằm trong lịch sử shell,
      ticket hay tin nhắn

Ba lưu ý về IMDSv2: | Lưu ý | Chi tiết | |---|---| | Bắt buộc token qua PUT trước | | | HttpPutResponseHopLimit: 1 chặn container | | | Bật mặc định cho tài khoản mới | |

Ba lưu ý về đặc quyền tối thiểu với DynamoDB: | Lưu ý | Chi tiết | |---|---| | Giới hạn theo ARN 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ề các môi trường khác: | Môi trường | Cơ chế | |---|---| | ECS | task role, không phải instance role | | Lambda | execution role | | EKS | IRSA hoặc Pod Identity |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | aws sts get-caller-identity trên instance | | | Thử ghi vào bảng khác — phải bị từ chối | | | Xem template đã đẩy lên — không được có khoá | |

Và một lời khuyên: hãy khai instance profile tường minh trong mọi template CloudFormation. Bảng điều khiển tạo nó ngầm nên rất dễ quên khi chuyển sang hạ tầng dạng mã — và triệu chứng là instance khởi động bình thường rồi mọi lời gọi AWS đều báo không có credential.

Câu 242 Domain - Continuous Improvement for Existing Solutions

A company has performed a security audit on its existing application. It was determined that the application retrieves the Amazon RDS for MySQL credentials from an encrypted file in an Amazon S3 bucket. To improve the security of the application the following should be implemented on the next application deployment:

  • The database credentials must be randomly generated and stored in a secure AWS managed service.

  • The credentials must be rotated every 90 days.

  • Infrastructure-as-code provisioning of application resources using AWS CloudFormation.

  • For the application deployment, the solutions architect will create a CloudFormation template.

Which of the following options should the solutions architect implement to meet the company’s requirement with the LEAST amount of operational overhead?

  1. A

    Using AWS Secrets Manager, create a secret resource and generate a secure database password. Write an AWS Lambda function to rotate the database password. Create a scheduled rule on Amazon EventBridge to trigger the Lambda function to rotate the database password every 90 days.
  2. B

    Use AWS Secrets Manager, create a secret resource and generate a secure database password. Use Secrets Manager's managed rotation to automatically rotate the database password every 90 days. On AWS CloudFormation, specify the AutomaticallyAfterDays property in RotationRules to set the rotation schedule to 90 days.
  3. C

    On Systems Manager Parameter Store, create a SecureString parameter and generate a secure database password. On AWS CloudFormation, create an AWS KMS resource to rotate the database password every 90 days.
  4. D

    On Systems Manager Parameter Store, create a SecureString parameter and generate a secure database password. Write an AWS Lambda function to rotate the database password. On AWS CloudFormation, specify a resource for Parameter Store RotationSchedule to rotate the password every 90 days.
Xem giải thích

Đáp án

**B — Dùng AWS Secrets Manager tạo một secret và sinh mật khẩu an toàn; dùng xoay tự động có sẵn (managed rotation) của Secrets Manager để đổi mật khẩu mỗi 90 ngày; trong CloudFormation khai thuộc tính AutomaticallyAfterDays trong RotationRules để đặt chu kỳ.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái với ít công nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Mật khẩu sinh ngẫu nhiên, lưu trong dịch vụ quản lý | GenerateSecretString | | Xoay mỗi 90 ngày | managed rotation | | Hạ tầng dạng mã | CloudFormation | | Ít công vận hành nhất | KHÔNG tự viết Lambda |

⚠ Managed rotation là điểm phân biệt cốt lõi:

Trước đây: phải tự viết Lambda
  xoay mật khẩu
        ↓
    Nay: Secrets Manager có sẵn
      cơ chế xoay cho RDS, Aurora,
      Redshift, DocumentDB
        ↓
    Khai `RotationRules` là xong
    → không có mã nào để viết
      hay bảo trì

Đây là lý do phương án A tốn công hơn.

Template đầy đủ:

Resources:
  BiMatCSDL:
    Type: AWS::SecretsManager::Secret
    Properties:
      Name: csdl/san-xuat
      GenerateSecretString:
        SecretStringTemplate: '{"username": "quantri"}'
        GenerateStringKey: password
        PasswordLength: 32
        ExcludeCharacters: '"@/\'

  CoSoDuLieu:
    Type: AWS::RDS::DBInstance
    Properties:
      Engine: mysql
      MasterUsername: !Sub
        '{{resolve:secretsmanager:${BiMatCSDL}:SecretString:username}}'
      MasterUserPassword: !Sub
        '{{resolve:secretsmanager:${BiMatCSDL}:SecretString:password}}'

  GanBiMat:
    Type: AWS::SecretsManager::SecretTargetAttachment
    Properties:
      SecretId: !Ref BiMatCSDL
      TargetId: !Ref CoSoDuLieu
      TargetType: AWS::RDS::DBInstance

  LichXoay:
    Type: AWS::SecretsManager::RotationSchedule
    Properties:
      SecretId: !Ref BiMatCSDL
      HostedRotationLambda:
        RotationType: MySQLSingleUser
        RotationLambdaName: xoay-mat-khau-csdl
      RotationRules:
        AutomaticallyAfterDays: 90

⚠ HostedRotationLambda là cơ chế "không viết mã":

Secrets Manager TỰ dựng hàm xoay
    → dựa trên `RotationType` bạn chọn
        ↓
    `MySQLSingleUser`, `MySQLMultiUser`,
    `PostgreSQLSingleUser`, ...
        ↓
    Không phải viết, không phải
      bảo trì

⚠ SecretTargetAttachment là bước hay bị quên:

Không có nó: secret chứa mật khẩu
  nhưng không biết CSDL nào
        ↓
    Hàm xoay không biết kết nối
      tới đâu
    → xoay thất bại
        ↓
    Attachment thêm host, port,
      dbname vào secret

⚠ Và Parameter Store KHÔNG có xoay tự động:

SecureString mã hoá tốt
    → nhưng không có cơ chế xoay nào
        ↓
    Phương án C nói "tạo tài nguyên
      KMS để xoay mật khẩu"
    → KMS xoay KHOÁ MÃ HOÁ, không
      xoay nội dung được mã hoá

⚠ Và RotationSchedule của Parameter Store (phương án D) không tồn tại:

Parameter Store không có loại
  tài nguyên nào tên như vậy
        ↓
    Chỉ Secrets Manager có
      `AWS::SecretsManager::RotationSchedule`

Ứng dụng lấy mật khẩu:

import boto3, json
sm = boto3.client('secretsmanager')
bi_mat = json.loads(sm.get_secret_value(
    SecretId='csdl/san-xuat')['SecretString'])
ket_noi = ket_noi_csdl(bi_mat['username'], bi_mat['password'])

⚠ Và phải cache, đọc lại khi xác thực thất bại:

Gọi Secrets Manager mỗi truy vấn
    → thêm độ trễ, tốn tiền,
      chạm hạn ngạch
        ↓
    Cache trong bộ nhớ
    + đọc lại khi kết nối bị từ chối
    → dùng thư viện caching chính thức

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không viết dòng mã xoay nào | | | Mật khẩu chưa ai từng nhìn thấy | | | CloudTrail ghi ai đọc bí mật | |

⚠ Và chiến lược hai người dùng an toàn hơn:

`MySQLSingleUser`: đổi mật khẩu
  của chính tài khoản đang dùng
        ↓
    Có khoảng vài giây kết nối mới
      có thể thất bại
        ↓
    `MySQLMultiUser`: luân phiên hai
      tài khoản
    → luôn có một cái hợp lệ

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

  • **A. Dùng Secrets Manager tạo secret, nhưng tự viết Lambda xoay mật khẩu và dùng EventBridge lên lịch 90 ngày — đây là phương án gần nhất và hoàn toàn chạy được, nhưng phải viết và bảo trì hàm xoay cùng lịch chạy; Secrets Manager đã có sẵn cả hai.
  • **C. Dùng Parameter Store SecureString và tạo tài nguyên KMS để xoay mật khẩu — KMS xoay khoá mã hoá, không xoay nội dung; và Parameter Store không có xoay bí mật.
  • **D. Dùng Parameter Store SecureString, tự viết Lambda xoay, và khai RotationSchedule cho Parameter Store — loại tài nguyên đó không tồn tại.

Ghi nhớ

⚠ Secrets Manager và Parameter Store — bảng phải thuộc: | Tiêu chí | Secrets Manager | Parameter Store | |---|---|---| | Xoay tự động | CÓ, có sẵn cho CSDL | không | | Chi phí | ~0,40 USD/bí mật/tháng | Standard miễn phí | | Nhân bản xuyên Region | có sẵn | không | | Kích thước | 64 KB | 4 KB (8 KB Advanced) | | Resource policy | có | không |

Từ khoá nhận diện:

"rotate credentials automatically" → Secrets Manager "least operational overhead" → managed rotation, không tự viết Lambda "configuration values, free" → Parameter Store "no secrets in template" → dynamic reference

⚠ Bốn bước của quy trình xoay — phải hiểu: | Bước | Việc | |---|---| | createSecret | sinh mật khẩu mới, nhãn AWSPENDING | | setSecret | đổi mật khẩu trong CSDL | | testSecret | thử kết nối bằng mật khẩu mới | | finishSecret | AWSPENDING thành AWSCURRENT |

⚠ Cơ chế nhãn làm xoay không gây gián đoạn:

AWSCURRENT: mật khẩu đang dùng
AWSPENDING: mật khẩu mới đang thử
AWSPREVIOUS: mật khẩu trước đó
        ↓
    Chỉ đổi AWSCURRENT sau khi
      mật khẩu mới đã kiểm thử

Ba lưu ý về IAM cho bí mật: | Lưu ý | Chi tiết | |---|---| | Cấp quyền theo ARN từng bí mật | | | Cần cả quyền KMS để giải mã | | | ARN có 6 ký tự ngẫu nhiên ở cuối | |

{"Effect": "Allow",
 "Action": "secretsmanager:GetSecretValue",
 "Resource": "arn:aws:secretsmanager:*:*:secret:csdl/san-xuat-*"}

⚠ Dấu -* ở cuối ARN là bắt buộc:

Secrets Manager thêm 6 ký tự
  ngẫu nhiên vào cuối ARN
        ↓
    ARN không có `-*` sẽ KHÔNG khớp
    → quyền bị từ chối mà nhìn
      chính sách thì thấy đúng

Ba lưu ý về xác thực IAM cho CSDL: | Lưu ý | Chi tiết | |---|---| | RDS MySQL/PostgreSQL hỗ trợ | | | Không có mật khẩu nào để xoay | | | Token có hạn 15 phút | |

⚠ Đây là lựa chọn tốt nhất khi dùng được:

aws rds generate-db-auth-token \
  --hostname csdl.abc.ap-southeast-1.rds.amazonaws.com \
  --port 3306 --username ung_dung

Không có mật khẩu tồn tại
    → không có gì để rò rỉ
    → không có gì để xoay

Ba lưu ý về nhân bản bí mật: | Lưu ý | Chi tiết | |---|---| | Nhân bản sang Region khác cho DR | | | Bản sao tự cập nhật khi bí mật đổi | | | Ứng dụng ở Region phụ đọc bản địa phương | |

aws secretsmanager replicate-secret-to-regions \
  --secret-id csdl/san-xuat \
  --add-replica-regions Region=us-west-2

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Cảnh báo khi xoay thất bại | | | CloudTrail ghi mọi lần đọc bí mật | | | Kiểm ứng dụng có đọc lại sau khi xoay | |

⚠ Xoay thất bại là sự cố im lặng:

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

Không có cảnh báo
    → mật khẩu không được xoay
      trong nhiều tháng
    → mà báo cáo tuân thủ vẫn ghi
      "xoay 90 ngày"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy xoay thủ công, xem ứng dụng còn kết nối | | | Xem template — không được có mật khẩu | | | Kiểm lịch sử xoay trong console | |

Và một lời khuyên: hãy chạy xoay thủ công một lần ngay sau khi cấu hình xong. Xoay tự động chạy lần đầu sau 90 ngày, và nếu có lỗi thì bạn sẽ phát hiện vào đúng lúc ứng dụng đột nhiên không kết nối được — ba tháng sau khi ai đó đã quên mất cấu hình này tồn tại.

Câu 243 Domain - Continuous Improvement for Existing Solutions

A company has adopted cloud-native computing best practices for its infrastructure. The company started using AWS CloudFormation templates for defining its cloud resources, and the templates are hosted in its private GitHub repository. As the developers continuously update the templates, the company has encountered several downtimes caused by misconfigured templates, wrong executions, or the creation of unnecessary environments. The management wants to streamline the process of testing the CloudFormation templates to prevent these errors. The Solutions Architect has been tasked to create an automated solution.

Which of the following options should be implemented to meet the company's requirements?

  1. A

    Write an AWS Lambda function that syncs the private GitHub repository to another Git provider like GitLab or Bitbucket. Using AWS CodeDeploy, create a change set and execute the AWS CloudFormation template. Add an AWS CodeBuild stage on the deployment to build and run test scripts to verify the new stack.
  2. B

    Write an AWS Lambda function that builds any changes committed on the private GitHub repository. Store the generated artifacts on AWS CodeArtifact. Using AWS CodePipeline, create a change set with the new artifact and execute the AWS CloudFormation template. Add a CodeBuild action to run test scripts that verify the new stack.
  3. C

    Create a pipeline in AWS CodePipeline that is triggered automatically for commits on the private GitHub repository. Have the pipeline create a change set and execute the CloudFormation template. Add an AWS CodeBuild stage on the pipeline to build and run test scripts to verify the new stack.
  4. D

    Create a pipeline in AWS CodePipeline that is triggered automatically for commits on the private GitHub repository. Have the pipeline create a change set from the CloudFormation template and execute it using AWS CodeDeploy. Add an AWS CodeBuild stage on the pipeline to build and run test scripts to verify the new stack.
Xem giải thích

Đáp án

**C — Tạo một pipeline trong AWS CodePipeline kích hoạt tự động khi có commit trên kho GitHub riêng tư; cho pipeline tạo change set và thực thi template CloudFormation; và thêm một giai đoạn CodeBuild chạy script kiểm thử để xác minh stack mới.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái bằng dịch vụ đúng vai trò: | Yêu cầu | Cách đáp ứng | |---|---| | Tự động khi có commit | CodePipeline nối GitHub | | Kiểm thử template trước khi áp | change set + CodeBuild | | Ngăn triển khai sai gây gián đoạn | change set cho xem trước |

⚠ CodePipeline triển khai CloudFormation TRỰC TIẾP — không cần CodeDeploy:

CodePipeline có action type
  `AWS CloudFormation`
        ↓
    Chế độ `CHANGE_SET_REPLACE`
      tạo change set
    → chế độ `CHANGE_SET_EXECUTE`
      thực thi nó
        ↓
    CodeDeploy dành cho triển khai
      MÃ ỨNG DỤNG lên EC2, Lambda, ECS
    → không triển khai stack
      CloudFormation

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

Hai action cho change set:

{"name": "TaoChangeSet",
 "actionTypeId": {"category": "Deploy", "owner": "AWS",
                  "provider": "CloudFormation", "version": "1"},
 "configuration": {
   "ActionMode": "CHANGE_SET_REPLACE",
   "StackName": "stack-ung-dung",
   "ChangeSetName": "thay-doi-moi",
   "TemplatePath": "NguonMa::template.yaml",
   "Capabilities": "CAPABILITY_NAMED_IAM",
   "RoleArn": "<arn-vai-tro-cloudformation>"}}

{"name": "ThucThiChangeSet",
 "actionTypeId": {"category": "Deploy", "owner": "AWS",
                  "provider": "CloudFormation", "version": "1"},
 "configuration": {
   "ActionMode": "CHANGE_SET_EXECUTE",
   "StackName": "stack-ung-dung",
   "ChangeSetName": "thay-doi-moi"}}

⚠ Tách hai bước cho phép chèn kiểm tra ở giữa:

Tạo change set
    ↓
CodeBuild đọc change set, kiểm tra
  có tài nguyên nào bị THAY THẾ không
    ↓
Duyệt tay nếu có
    ↓
Thực thi change set

Script kiểm tra thay thế:

aws cloudformation describe-change-set \
  --stack-name stack-ung-dung \
  --change-set-name thay-doi-moi \
  --query 'Changes[?ResourceChange.Replacement==`True`]' \
  --output json > thay-the.json

if [ -s thay-the.json ] && [ "$(cat thay-the.json)" != "[]" ]; then
  echo "CANH BAO: co tai nguyen se bi thay the"
  cat thay-the.json
  exit 1
fi

⚠ Đây là thứ ngăn được sự cố mà đề mô tả:

"Template cấu hình sai gây gián đoạn"
        ↓
    Thay thế nhầm CSDL = mất dữ liệu
    → thay thế launch template =
      thay cả đội máy
        ↓
    Change set cho biết TRƯỚC

Nối GitHub riêng tư:

aws codestar-connections create-connection \
  --provider-type GitHub --connection-name ket-noi-github

⚠ CodeStar Connections thay cho OAuth token cá nhân:

Trước đây: dùng personal access token
    → gắn với một người
    → người đó nghỉ việc là pipeline chết
        ↓
    CodeStar Connections: kết nối do
      AWS quản lý
    → thu hồi được tập trung

⚠ Và đây là lý do không cần đồng bộ sang GitLab (phương án A):

CodePipeline nối GitHub trực tiếp
    → không cần Lambda đồng bộ
      sang nhà cung cấp khác
        ↓
    Đồng bộ thêm một chỗ hỏng
      và một độ trễ

CodeBuild kiểm thử stack sau khi triển khai:

version: 0.2
phases:
  install:
    commands:
      - pip install cfn-lint pytest boto3
  pre_build:
    commands:
      - cfn-lint template.yaml
  build:
    commands:
      - pytest kiem-thu/kiem-tra-stack.py

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mọi bước dùng dịch vụ có sẵn | | | Change set chặn thay thế ngoài ý muốn | | | Kiểm thử tự động sau khi triển khai | |

⚠ Và nên triển khai môi trường thử trước:

Nguồn → Build → Triển khai môi trường thử
    → Kiểm thử tích hợp
        ↓
    → Change set cho sản xuất
    → Duyệt tay
    → Thực thi

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

  • **D. Tạo pipeline kích hoạt bởi commit GitHub, tạo change set từ template và thực thi bằng AWS CodeDeploy, thêm giai đoạn CodeBuild — đây là phương án gần nhất và chỉ khác một chi tiết, nhưng CodeDeploy triển khai mã ứng dụng lên EC2, Lambda hoặc ECS; nó không thực thi change set của CloudFormation.
  • **A. Viết Lambda đồng bộ GitHub riêng tư sang GitLab hoặc Bitbucket, rồi dùng CodeDeploy tạo và thực thi change set — thêm một bước đồng bộ không cần thiết vì CodePipeline nối GitHub trực tiếp; và lại dùng sai CodeDeploy.
  • **B. Viết Lambda build mọi commit, lưu artifact trên CodeArtifact, rồi CodePipeline tạo change set — Lambda không phải môi trường build (giới hạn 15 phút); và CodeArtifact là kho gói phụ thuộc, không phải nơi lưu artifact triển khai.

Ghi nhớ

⚠ Sáu dịch vụ trong bộ công cụ phát triển — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | CodePipeline | điều phối các giai đoạn | | CodeBuild | biên dịch, kiểm thử, quét | | CodeDeploy | triển khai MÃ lên EC2, Lambda, ECS | | CloudFormation | triển khai HẠ TẦNG | | CodeArtifact | kho gói phụ thuộc | | CodeCommit | kho Git (ngừng nhận khách mới) |

⚠ CodeDeploy và CloudFormation — ranh giới rõ ràng:

CodeDeploy: đưa MÃ lên tài nguyên
  ĐÃ CÓ
        ↓
    CloudFormation: TẠO và SỬA
      tài nguyên
        ↓
    Câu hỏi về triển khai template
    → CloudFormation action

Từ khoá nhận diện:

"deploy CloudFormation template in pipeline" → CloudFormation action "deploy application code" → CodeDeploy "preview infrastructure changes" → change set "run tests in pipeline" → CodeBuild

Ba chế độ của CloudFormation action: | Chế độ | Việc | |---|---| | CHANGE_SET_REPLACE | tạo hoặc thay change set | | CHANGE_SET_EXECUTE | thực thi change set | | CREATE_UPDATE | tạo hoặc cập nhật thẳng |

⚠ CREATE_UPDATE bỏ qua bước xem trước:

Nhanh hơn nhưng mất lớp bảo vệ
        ↓
    Dùng cho môi trường thử
    → sản xuất luôn qua change set

Ba lưu ý về change set: | Lưu ý | Chi tiết | |---|---| | Cho biết tài nguyên nào bị THAY THẾ | | | Không thực thi thì không ảnh hưởng gì | | | Đưa vào pipeline làm cổng bắt buộc | |

Ba lưu ý về vai trò của CloudFormation: | Lưu ý | Chi tiết | |---|---| | RoleArn cho CloudFormation quyền tạo tài nguyên | | | Vai trò pipeline chỉ cần quyền gọi CloudFormation | | | Tách hai vai trò là đặc quyền tối thiểu | |

⚠ Tách vai trò là thực hành quan trọng:

Pipeline không cần quyền tạo
  EC2, RDS, IAM
        ↓
    Nó chỉ cần `cloudformation:*` và
      `iam:PassRole`
    → CloudFormation dùng vai trò
      riêng để tạo tài nguyên
        ↓
    Chiếm được pipeline không
      chiếm được cả tài khoản

Ba lưu ý về Capabilities: | Giá trị | Khi nào cần | |---|---| | CAPABILITY_IAM | template tạo tài nguyên IAM | | CAPABILITY_NAMED_IAM | tài nguyên IAM có tên tự đặt | | CAPABILITY_AUTO_EXPAND | template có macro hoặc nested |

⚠ Thiếu capability là lỗi triển khai hay gặp:

Template có `AWS::IAM::Role`
    → CloudFormation từ chối
      nếu không khai capability
        ↓
    Đây là biện pháp bảo vệ có
      chủ đích của AWS

Ba lưu ý về kiểm tra tĩnh: | Công cụ | Bắt gì | |---|---| | cfn-lint | cú pháp, thuộc tính sai | | cfn-guard | vi phạm chính sách | | checkov | cấu hình sai về bảo mật |

Ba lưu ý về stack policy: | Lưu ý | Chi tiết | |---|---| | Chặn cập nhật tài nguyên quan trọng | | | Áp khi UpdateStack, không áp khi xoá | | | Bổ sung cho change set | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy template hỏng, xem pipeline có chặn | | | Xem change set có báo tài nguyên bị thay thế | | | Kiểm kiểm thử tự động chạy sau triển khai | |

Và một lời khuyên: hãy thêm một bước tự động kiểm tra change set và dừng pipeline nếu có tài nguyên bị thay thế. Con người đọc change set sẽ bỏ sót vào lần thứ năm mươi — còn một script kiểm tra thì không bao giờ mệt.

Câu 244 Domain - Design for New Solutions

A company requires regular processing of a massive amount of product catalogs that need to be handled per batch. The data needs to be processed regularly by on-demand workers. The company instructed its solutions architect to design a workflow orchestration system that will enable to reprocess failures and handle multiple concurrent operations.

What is the MOST suitable solution that the solutions architect should implement in order to manage the state of every workflow?

  1. A

    Implement Step Functions to orchestrate batch processing workflows. Use the AWS Management Console to monitor workflow status and manage failure reprocessing.
  2. B

    Set up a workflow using AWS Config and AWS Step Functions in order to orchestrate multiple concurrent workflows. Visualize the status of each workflow using the AWS Management Console. Store the historical data in an Amazon S3 bucket and visualize the data using Amazon QuickSight.
  3. C

    Use Amazon MQ to set up a batch process workflow that handles the processing for a single batch. Develop worker jobs using AWS Lambda functions.
  4. D

    Store workflow data in an Amazon RDS with AWS Lambda functions polling the RDS database instance for status changes. Set up worker Lambda functions to process the next workflow steps, then use Amazon QuickSight to visualize workflow states directly out of RDS.
Xem giải thích

Đáp án

**A — Dùng Step Functions điều phối luồng xử lý theo lô; dùng bảng điều khiển AWS để theo dõi trạng thái luồng và quản lý việc xử lý lại phần thất bại.

Vì sao đúng

Đề nêu ba yêu cầu, và Step Functions là dịch vụ được thiết kế đúng cho cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Điều phối quy trình | máy trạng thái | | Xử lý lại phần thất bại | Retry và Catch | | Nhiều thao tác đồng thời | Map và Parallel | | Quản lý trạng thái từng luồng | lịch sử thực thi có sẵn |

⚠ "Quản lý trạng thái của mọi luồng" là mô tả chính xác của Step Functions:

Chuỗi Lambda gọi nhau
    → không biết lô nào đang ở
      bước nào
        ↓
    Step Functions: mỗi lần chạy
      có lịch sử đầy đủ
    → sơ đồ trực quan cho từng lô

Thử lại tự động:

{"XuLyLo": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Retry": [
    {"ErrorEquals": ["Lambda.ServiceException",
                     "Lambda.TooManyRequestsException"],
     "IntervalSeconds": 2, "MaxAttempts": 6,
     "BackoffRate": 2.0},
    {"ErrorEquals": ["States.TaskFailed"],
     "IntervalSeconds": 5, "MaxAttempts": 3}],
  "Catch": [
    {"ErrorEquals": ["States.ALL"],
     "ResultPath": "$.loi",
     "Next": "GhiNhanLoi"}],
  "Next": "BuocTiepTheo"}}

⚠ Retry có backoff luỹ thừa là thứ không phải viết mã:

`BackoffRate: 2.0`
    → chờ 2, 4, 8, 16, 32, 64 giây
        ↓
    Tự viết logic này trong Lambda
    → hàng chục dòng mã và phải
      kiểm thử

Xử lý nhiều lô đồng thời:

{"XuLyNhieuLo": {
  "Type": "Map",
  "ItemsPath": "$.danhSachLo",
  "MaxConcurrency": 50,
  "ToleratedFailurePercentage": 5,
  "ItemProcessor": {
    "ProcessorConfig": {"Mode": "DISTRIBUTED",
                        "ExecutionType": "STANDARD"},
    "StartAt": "XuLyMotLo",
    "States": {"XuLyMotLo": {
      "Type": "Task",
      "Resource": "<arn-ham>", "End": true}}},
  "End": true}}

⚠ ToleratedFailurePercentage rất hợp với xử lý theo lô:

Vài lô hỏng không nên làm cả
  công việc thất bại
        ↓
    Cho phép 5% lỗi
    → luồng vẫn hoàn tất
    → và ghi lại danh sách lô lỗi
      để chạy lại

⚠ Và Distributed Map cho quy mô rất lớn:

Map thường: tối đa 40 nhánh
  đồng thời
        ↓
    Distributed Map: tới 10.000
    → đọc thẳng danh sách từ S3

Chạy lại phần thất bại:

aws stepfunctions redrive-execution \
  --execution-arn <arn-lan-chay>

⚠ redrive chạy lại CHỈ phần thất bại:

Không phải chạy lại từ đầu
    → chỉ những mục hoặc bước
      đã lỗi
        ↓
    Tiết kiệm thời gian và chi phí
    → đúng yêu cầu "reprocess failures"

⚠ Và Amazon MQ (phương án C) không điều phối gì:

MQ là broker nhắn tin
    → chuyển thông điệp giữa các
      thành phần
        ↓
    Không có khái niệm bước, trạng thái,
      thử lại hay nhánh lỗi
    → phải tự viết toàn bộ logic
      điều phối

⚠ Và polling RDS bằng Lambda (phương án D) là mẫu chống lại:

Lambda gọi mỗi phút hỏi
  "có gì đổi không"
        ↓
    Phần lớn lời gọi trả về rỗng
    → tốn tiền và thêm độ trễ
        ↓
    Và phải tự quản trạng thái
      trong bảng
    → đúng thứ Step Functions
      làm sẵn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thử lại và xử lý lỗi không cần viết mã | | | Thấy được trạng thái từng luồng | | | Chạy lại chỉ phần thất bại | |

⚠ Và AWS Batch là lựa chọn bổ sung cho phần tính toán:

Step Functions điều phối
    → AWS Batch chạy job nặng
      trong container
        ↓
    Step Functions gọi Batch trực tiếp
    → `arn:aws:states:::batch:submitJob.sync`

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

  • **B. Dựng luồng dùng AWS Config và Step Functions, trực quan hoá bằng bảng điều khiển, lưu dữ liệu lịch sử vào S3 và hiển thị bằng QuickSight — đây là phương án gần nhất và có Step Functions đúng, nhưng AWS Config đánh giá tuân thủ cấu hình tài nguyên, nó không tham gia điều phối luồng công việc; và QuickSight là công cụ báo cáo, không cần cho việc theo dõi trạng thái luồng.
  • **C. Dùng Amazon MQ dựng luồng xử lý theo lô và viết worker bằng Lambda — MQ chỉ chuyển thông điệp; toàn bộ logic điều phối, thử lại và theo dõi trạng thái phải tự viết.
  • **D. Lưu dữ liệu luồng trong RDS và cho Lambda polling để phát hiện thay đổi trạng thái — polling tốn kém, thêm độ trễ, và phải tự xây lại toàn bộ cơ chế mà Step Functions có sẵn.

Ghi nhớ

⚠ Bốn công cụ điều phối — bảng phải thuộc: | Công cụ | Dùng khi | |---|---| | Step Functions | quy trình nhiều bước có trạng thái | | EventBridge | định tuyến sự kiện theo luật | | SQS | hàng đợi việc đơn giản | | AWS Batch | tính toán theo lô, hàng nghìn job |

Từ khoá nhận diện:

"workflow orchestration, manage state" → Step Functions "reprocess failures" → Retry, Catch, redrive "multiple concurrent operations" → Map state "batch compute jobs" → AWS Batch

⚠ Hai loại workflow — bảng phải thuộc: | Loại | Thời gian | Tính phí | |---|---|---| | Standard | tới 1 năm | theo bước chuyển trạng thái | | Express | tới 5 phút | theo thời gian và bộ nhớ |

Xử lý lô kéo dài
    → Standard, có lịch sử đầy đủ
        ↓
    Hàng nghìn lần chạy ngắn mỗi phút
    → Express, rẻ hơn nhiều

Ba lưu ý về Retry: | Lưu ý | Chi tiết | |---|---| | Liệt kê lỗi cụ thể trước, States.ALL sau | | | BackoffRate cho backoff luỹ thừa | | | MaxAttempts tránh thử lại vô hạn | |

Ba lưu ý về Catch: | Lưu ý | Chi tiết | |---|---| | ResultPath giữ dữ liệu gốc cùng thông tin lỗi | | | Chuyển sang nhánh ghi nhận hoặc bồi thường | | | Không có Catch thì cả luồng thất bại | |

⚠ ResultPath là chi tiết dễ bỏ sót:

{"Catch": [{"ErrorEquals": ["States.ALL"],
            "ResultPath": "$.loi",
            "Next": "GhiNhanLoi"}]}

Không có `ResultPath`
    → đầu vào bị thay bằng thông
      tin lỗi
    → mất dữ liệu gốc, không biết
      lô nào hỏng

Ba lưu ý về tích hợp trực tiếp: | Lưu ý | Chi tiết | |---|---| | Hơn 200 dịch vụ, không cần Lambda | | | .sync chờ tác vụ hoàn tất | | | .waitForTaskToken chờ tín hiệu bên ngoài | |

{"Resource": "arn:aws:states:::batch:submitJob.sync"}

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | ExecutionsFailed | luồng lỗi | | ExecutionTime | chậm dần không | | ExecutionsTimedOut | có bước treo không |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Standard tính theo bước chuyển | | | Bước chờ KHÔNG tính phí trong lúc chờ | | | Express rẻ hơn cho luồng ngắn tần suất cao | |

Ba lưu ý về thiết kế máy trạng thái: | Lưu ý | Chi tiết | |---|---| | Giữ payload nhỏ — giới hạn 256 KB | | | Dữ liệu lớn để trên S3, truyền tham chiếu | | | Đặt TimeoutSeconds cho mọi bước | |

⚠ Payload quá lớn là lỗi hay gặp:

Truyền cả nội dung tệp qua các bước
    → chạm giới hạn 256 KB
        ↓
    Truyền khoá S3 thay vì nội dung
    → mỗi bước tự đọc từ S3

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cố ý làm một lô lỗi, xem có thử lại | | | Dùng redrive chạy lại phần thất bại | | | Xem sơ đồ trực quan tìm bước chậm nhất | |

Và một lời khuyên: hãy đặt TimeoutSeconds cho mọi bước trong máy trạng thái. Không có nó, một bước treo sẽ giữ cả luồng ở trạng thái đang chạy vô thời hạn — và với workflow Standard thì "vô thời hạn" nghĩa là tối đa một năm.

Câu 245 Domain - Accelerate Workload Migration and Modernization

An analytics company hosts its data processing application on its on-premises data center. Data scientists upload input files through a web portal which then are then stored in the company NAS. For every uploaded file, the web server sends a message to the processing server over a message queue. It could take up to 30 minutes to process each file on the NAS. During business hours, the number of files awaiting processing is significantly higher and it could take a while for the processing servers to catch up. The number of files significantly declines after business hours. The company has tasked the solutions architect to migrate this workload to the AWS cloud.

Which of the following options is the recommended solution while being cost-effective?

  1. A

    Reconfigure the web application to publish messages to a new Amazon MQ queue. Create an auto-scaling group of Amazon EC2 instances to pull messages from the queue and process the files. Store the processed files on an Amazon EFS volume. Power off the EC2 when there are no messages left on the queue.
  2. B

    Reconfigure the web application to publish messages to a new Amazon MQ queue. Write an AWS Lambda function to pull messages from the SQS queue and process the files. Trigger the Lambda function for every new message on the queue. Store the processed files in Amazon EFS
  3. C

    Reconfigure the web application to publish messages to a new Amazon SQS queue. Write an AWS Lambda function to pull messages from the SQS queue and process the files. Trigger the Lambda function for every new message on the queue. Store the processed files on an Amazon S3 bucket.
  4. D

    Reconfigure the web application to publish messages to a new Amazon SQS queue. Create an auto-scaling group of Amazon EC2 instances based on the SQS queue length to pull messages from the queue and process the files. Store the processed files on an Amazon S3 bucket.
Xem giải thích

Đáp án

**D — Cấu hình lại ứng dụng web đẩy thông điệp vào hàng đợi Amazon SQS mới; tạo Auto Scaling group EC2 co giãn theo ĐỘ DÀI hàng đợi SQS để kéo thông điệp và xử lý tệp; lưu tệp đã xử lý vào bucket S3.

Vì sao đúng

Đề cho một dữ kiện quyết định về thời gian xử lý:

Mỗi tệp mất tới 30 PHÚT để xử lý
        ↓
    Lambda tối đa 15 PHÚT
    → KHÔNG dùng được
        ↓
    Đây là lý do phương án B và C sai

⚠ Và ba yêu cầu còn lại đều khớp: | Yêu cầu | Cách đáp ứng | |---|---| | Hàng đợi dài trong giờ làm việc, ngắn ngoài giờ | ASG co giãn theo độ dài hàng đợi | | Thay hệ thống nhắn tin hiện có | SQS | | Thay NAS lưu tệp | S3, rẻ hơn nhiều |

⚠ Co giãn theo độ dài hàng đợi phải tính đúng chỉ số:

`ApproximateNumberOfMessagesVisible`
  một mình
    → 1.000 thông điệp là nhiều hay ít?
    → phụ thuộc số instance đang có
        ↓
    Chỉ số đúng: hàng chờ / số instance
    → gọi là backlog per instance

Đẩy chỉ số tuỳ chỉnh:

import boto3
cw = boto3.client('cloudwatch')
so_tin = lay_do_sau_hang_doi()
so_may = lay_so_instance()
cw.put_metric_data(Namespace='XuLyTep', MetricData=[{
    'MetricName': 'BacklogPerInstance',
    'Value': so_tin / max(so_may, 1)}])

Chính sách co giãn:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-xu-ly-tep \
  --policy-name theo-hang-doi \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 3.0,
    "CustomizedMetricSpecification": {
      "MetricName": "BacklogPerInstance",
      "Namespace": "XuLyTep", "Statistic": "Average"}}'

⚠ Visibility timeout phải dài hơn 30 phút:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes VisibilityTimeout=2400

Timeout ngắn hơn thời gian xử lý
    → thông điệp hiện lại giữa chừng
    → instance khác xử lý CÙNG tệp
        ↓
    Tốn gấp đôi tài nguyên
    → và có thể ghi đè kết quả

⚠ Hoặc gia hạn động trong lúc xử lý:

import threading
def gia_han(url, the, dung_lai):
    while not dung_lai.is_set():
        sqs.change_message_visibility(
            QueueUrl=url, ReceiptHandle=the,
            VisibilityTimeout=600)
        dung_lai.wait(300)

⚠ Và vì sao SQS chứ không phải Amazon MQ:

Amazon MQ: broker tương thích
  ActiveMQ/RabbitMQ
    → chọn khi PHẢI giữ giao thức cũ
      (JMS, AMQP) mà không sửa mã
        ↓
    Đề nói được "cấu hình lại ứng dụng web"
    → SQS đơn giản và rẻ hơn nhiều
    → và không có broker nào phải vận hành

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ngoài giờ làm việc thu về gần 0 máy | | | S3 rẻ hơn NAS rất nhiều | | | Xử lý được việc dài hơn 15 phút | |

⚠ Và Spot instance giảm chi phí thêm rất nhiều:

Xử lý tệp là việc chịu được gián đoạn
    → thông điệp quay lại hàng đợi
      nếu instance bị thu hồi
        ↓
    Spot rẻ hơn tới 90%
    → hợp hoàn hảo với mẫu này

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

  • **A. Đẩy thông điệp vào Amazon MQ, tạo ASG EC2 kéo thông điệp, lưu vào EFS, và tắt EC2 khi hết thông điệp — đây là phương án gần nhất và phần ASG hoàn toàn đúng, nhưng Amazon MQ là broker phải vận hành và đắt hơn SQS mà không mang lại gì thêm; EFS đắt hơn S3 nhiều; và "tắt máy khi hết thông điệp" là làm tay thứ ASG đã tự làm.
  • **C. Đẩy vào SQS nhưng để Lambda xử lý tệp — Lambda tối đa 15 phút, không đủ cho việc mất tới 30 phút.
  • **B. Đẩy vào Amazon MQ rồi để Lambda "kéo từ hàng đợi SQS" — mâu thuẫn nội tại, và Lambda vẫn không đủ thời gian.

Ghi nhớ

⚠ Giới hạn thời gian của các dịch vụ tính toán — bảng phải thuộc: | Dịch vụ | Thời gian tối đa | |---|---| | Lambda | 15 phút | | Fargate | không giới hạn | | EC2 | không giới hạn | | AWS Batch | không giới hạn |

Việc dài hơn 15 phút
    → loại Lambda ngay lập tức
    → đây là bộ lọc đầu tiên

Từ khoá nhận diện:

"takes up to 30 minutes" → KHÔNG dùng Lambda "scale by queue length" → backlog per instance "must keep JMS/AMQP protocol" → Amazon MQ "replace NAS" → S3 hoặc EFS tuỳ mẫu truy cập

⚠ SQS và Amazon MQ — bảng phải thuộc: | Tiêu chí | SQS | Amazon MQ | |---|---|---| | Giao thức | API riêng của AWS | JMS, AMQP, MQTT, STOMP | | Vận hành | hoàn toàn quản lý | quản lý broker, có bản vá | | Co giãn | vô hạn | theo cỡ broker | | Chọn khi | thiết kế mới | di chuyển ứng dụng cũ |

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Visibility timeout dài hơn thời gian xử lý | | | Long polling giảm chi phí lời gọi | | | Dead-letter queue cho thông điệp hỏng | |

Ba lưu ý về xử lý idempotent: | Lưu ý | Chi tiết | |---|---| | SQS Standard có thể giao hơn một lần | | | Ghi kết quả với khoá xác định | | | Kiểm tệp đã xử lý chưa trước khi làm lại | |

Ba lưu ý về S3 so với EFS: | Tiêu chí | S3 | EFS | |---|---|---| | Chi phí mỗi GB | thấp hơn nhiều | cao | | Giao diện | API object | hệ thống tệp POSIX | | Chọn khi | ứng dụng dùng được API | ứng dụng cần đường dẫn tệp |

⚠ Nếu ứng dụng bắt buộc dùng đường dẫn tệp:

Mountpoint for Amazon S3
    → mount bucket như hệ thống tệp
        ↓
    Có chi phí của S3, giao diện
      gần như tệp
    → cân nhắc trước khi chọn EFS

Ba lưu ý về ASG cho tải theo lô: | Lưu ý | Chi tiết | |---|---| | Min bằng 0 khi ngoài giờ cao điểm | | | Dùng Spot với đa dạng loại máy | | | Lifecycle hook để hoàn tất việc trước khi tắt | |

aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name asg-xu-ly-tep \
  --lifecycle-hook-name cho-xu-ly-xong \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 2400

Ba lưu ý về lựa chọn thay thế: | Lựa chọn | Khi nào | |---|---| | AWS Batch | tự quản hàng đợi job, dùng Spot dễ | | Fargate | container, không quản máy chủ | | Lambda | chỉ khi xử lý dưới 15 phút |

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | ApproximateAgeOfOldestMessage | tăng đều | | Độ sâu DLQ | lớn hơn 0 | | Số instance | chạm trần ASG |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy nhiều tệp, xem ASG mở rộng | | | Kiểm ngoài giờ ASG có thu nhỏ | | | Xem có tệp nào bị xử lý hai lần | |

Và một lời khuyên: hãy đặt visibility timeout theo thời gian xử lý CHẬM NHẤT chứ đừng theo trung bình. Một tệp lớn bất thường vượt quá timeout sẽ được xử lý song song bởi hai instance — và chi phí của việc đó không chỉ là tiền máy, mà còn là hai kết quả ghi đè lên nhau.

Câu 246 Domain - Design for New Solutions

A research company hosts its internal applications inside AWS VPCs in multiple AWS Accounts. The internal applications are accessed securely from inside the company network using an AWS Site-to-Site VPN connection. VPC peering connections has been established from the company’s main AWS account to VPCs in other AWS Accounts. The company has recently announced that employees will be allowed to work remotely if they are connected using a VPN. The solutions architect has been tasked to create a scalable and reliable AWS Client VPN solution that employees can use when working remotely.

Which of the following options is the most cost-effective implementation to meet the company requirements with minimal changes to the current setup?

  1. A

    Install the AWS Client VPN on each employee workstation. Create a Client VPN endpoint in each of the AWS accounts. Update each VPC route configuration to allow communication with the internal applications.
  2. B

    Install the AWS Client VPN on the company data center. Create AWS Transit Gateway to connect the main VPC and other VPCs into a single hub. Update the VPC route configurations to allow communication with the internal applications.
  3. C

    Install the AWS Client VPN on each employee workstation. Create a Client VPN endpoint in the same VPC region in the main AWS account. Update the VPC route configurations to allow communication with the internal applications.
  4. D

    Install the AWS Client VPN on the company data center. Configure connectivity between the existing AWS Site-to-Site VPN and client VPN endpoint.
Xem giải thích

Đáp án

**C — Cài AWS Client VPN trên máy trạm của từng nhân viên; tạo một Client VPN endpoint trong cùng Region với VPC ở tài khoản chính; và cập nhật bảng định tuyến của các VPC để cho phép giao tiếp với ứng dụng nội bộ.

Vì sao đúng

Đề nêu ba ràng buộc, và phương án này thoả cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | Nhân viên làm việc từ xa | Client VPN trên từng máy trạm | | Rẻ nhất | MỘT endpoint, không phải mỗi tài khoản một cái | | Ít thay đổi hạ tầng hiện có | tận dụng VPC peering đã có |

⚠ Điểm mấu chốt: VPC peering đã có sẵn nên chỉ cần một endpoint:

Tài khoản chính đã peering với
  mọi VPC khác
        ↓
    Client VPN endpoint ở VPC chính
    → lưu lượng đi qua peering
      tới các VPC còn lại
        ↓
    Không cần endpoint ở từng
      tài khoản

⚠ Và chi phí Client VPN có hai phần — đây là lý do "một endpoint" rẻ hơn nhiều:

Phí endpoint theo GIỜ mỗi subnet
  đã gắn
    + phí theo giờ mỗi kết nối
      đang hoạt động
        ↓
    Mỗi tài khoản một endpoint
      (phương án A)
    → nhân phí endpoint lên số
      tài khoản

Tạo endpoint:

aws ec2 create-client-vpn-endpoint \
  --client-cidr-block 10.100.0.0/16 \
  --server-certificate-arn <arn-chung-chi> \
  --authentication-options \
    Type=federated-authentication,\
FederatedAuthentication={SAMLProviderArn=<arn-saml>} \
  --connection-log-options Enabled=true,CloudwatchLogGroup=/vpn/ket-noi \
  --split-tunnel

Gắn subnet và cấp quyền tới các VPC:

aws ec2 associate-client-vpn-target-network \
  --client-vpn-endpoint-id cvpn-abc \
  --subnet-id subnet-chinh-a

aws ec2 authorize-client-vpn-ingress \
  --client-vpn-endpoint-id cvpn-abc \
  --target-network-cidr 10.1.0.0/16 \
  --authorize-all-groups

⚠ Và phải thêm TUYẾN tường minh tới VPC đã peering:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-abc \
  --destination-cidr-block 10.1.0.0/16 \
  --target-vpc-subnet-id subnet-chinh-a

Peering đã có không đủ
    → Client VPN cần tuyến riêng
      cho mỗi đích
        ↓
    Thiếu tuyến: kết nối được VPN
      nhưng không tới được VPC kia

⚠ Nhưng peering KHÔNG BẮC CẦU — đây là hạn chế phải biết:

VPC chính peering với VPC-A và VPC-B
    → VPC-A và VPC-B KHÔNG nói
      chuyện với nhau
        ↓
    Nhưng ở đây lưu lượng đi từ
      Client VPN (trong VPC chính)
    → tới từng VPC
    → nên peering đủ dùng

⚠ --split-tunnel là lựa chọn quan trọng: | Chế độ | Hành vi | |---|---| | Full tunnel | MỌI lưu lượng đi qua VPN | | Split tunnel | chỉ lưu lượng tới VPC đi qua VPN |

Full tunnel: nhân viên xem video
  cũng đi vòng qua AWS
    → tốn băng thông và tiền
        ↓
    Split tunnel: chỉ truy cập ứng
      dụng nội bộ đi qua

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một endpoint phục vụ mọi VPC | | | Không đổi cấu trúc mạng hiện có | | | Nhân viên làm việc từ bất kỳ đâu | |

⚠ Và Transit Gateway (phương án B) là thay đổi lớn hơn nhiều:

Đề nói "ít thay đổi nhất"
    → dựng TGW nghĩa là gỡ peering,
      gắn lại mọi VPC
        ↓
    TGW đúng khi có RẤT NHIỀU VPC
    → nhưng ở đây peering đã chạy

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

  • **A. Cài Client VPN trên máy trạm và tạo endpoint trong TỪNG tài khoản AWS — đây là phương án gần nhất và hoàn toàn chạy được, nhưng nhân phí endpoint theo giờ lên số tài khoản; đề hỏi cách rẻ nhất.
  • **B. Cài Client VPN tại trung tâm dữ liệu và tạo Transit Gateway gộp các VPC — Client VPN là giải pháp cho từng máy trạm, không cài ở trung tâm dữ liệu; và TGW là thay đổi hạ tầng lớn.
  • **D. Cài Client VPN tại trung tâm dữ liệu và nối Site-to-Site VPN hiện có với Client VPN endpoint — không có cơ chế nào nối hai loại VPN này với nhau như vậy.

Ghi nhớ

⚠ Bốn cách truy cập tài nguyên riêng tư — bảng phải thuộc: | Cách | Dùng cho | |---|---| | Client VPN | từng máy trạm, ở bất kỳ đâu | | Site-to-Site VPN | nối MẠNG với MẠNG | | Direct Connect | nối trung tâm dữ liệu, băng thông cao | | Verified Access | truy cập ứng dụng qua trình duyệt, zero-trust |

Từ khoá nhận diện:

"employees working remotely" → Client VPN "connect two networks" → Site-to-Site VPN "many VPCs, simplify routing" → Transit Gateway "minimal changes to current setup" → tận dụng peering đã có

Ba lưu ý về Client VPN: | Lưu ý | Chi tiết | |---|---| | Xác thực bằng chứng chỉ, AD hoặc SAML | | | Client CIDR không đổi được sau khi tạo | | | Gắn ít nhất hai subnet ở hai AZ cho HA | |

⚠ Client CIDR phải chọn rộng ngay từ đầu:

Chọn /22 cho 1.000 người dùng
    → sau này cần 5.000
        ↓
    Phải tạo endpoint MỚI
    → và cấu hình lại mọi máy trạm

Ba lưu ý về tuyến và quyền: | Cơ chế | Việc | |---|---| | create-client-vpn-route | thêm ĐƯỜNG ĐI tới đích | | authorize-client-vpn-ingress | cho PHÉP nhóm nào tới đích đó | | Cần CẢ HAI | |

⚠ Đây là chỗ hay cấu hình thiếu:

Có tuyến nhưng chưa authorize
    → gói tin biết đường đi
    → nhưng bị từ chối
        ↓
    Có authorize nhưng chưa có tuyến
    → không biết đi đâu

Ba lưu ý về phân quyền theo nhóm: | Lưu ý | Chi tiết | |---|---| | --access-group-id giới hạn theo nhóm AD hoặc SAML | | | Nhóm QA chỉ tới môi trường thử | | | Một endpoint, nhiều mức quyền | |

aws ec2 authorize-client-vpn-ingress \
  --client-vpn-endpoint-id cvpn-abc \
  --target-network-cidr 10.2.0.0/16 \
  --access-group-id <id-nhom-van-hanh>

Ba lưu ý về VPC peering: | Lưu ý | Chi tiết | |---|---| | KHÔNG bắc cầu | | | Cần tuyến ở CẢ HAI phía | | | CIDR không được chồng lấn | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật log kết nối vào CloudWatch | | | Dùng SAML để tận dụng MFA của IdP | | | Thu hồi chứng chỉ khi nhân viên nghỉ | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Phí endpoint theo giờ mỗi subnet gắn | | | Phí theo giờ mỗi kết nối hoạt động | | | Split tunnel giảm băng thông và tiền | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối VPN rồi ping ứng dụng ở VPC khác | | | Kiểm cả tuyến lẫn quyền đã khai đủ | | | Thử ngắt một AZ, xem client nối lại được | |

Và một lời khuyên: hãy chọn dải Client CIDR rộng hơn nhiều so với số nhân viên hiện tại. Nó không đổi được sau khi tạo endpoint — và mở rộng nghĩa là dựng endpoint mới rồi cấu hình lại từng máy trạm một.

Câu 247 Domain - Continuous Improvement for Existing Solutions

A digital media publishing company hired a solutions architect to manage its online portal, which is deployed on a single Amazon EC2 instance. The architecture uses a combination of Reserved EC2 Instances to handle the steady-state load and On-Demand EC2 Instances to handle the peak load. Currently, the web servers operate at 90% utilization during peak load.

Which of the following is the most cost-effective option to enable the online portal to quickly recover in the event of a zone outage?

  1. A

    Create an Auto Scaling group of Spot instances on multiple Availability Zones. Attach an Application Load Balancer to the group.
  2. B

    Launch a Spot Fleet of On-demand and Spot instances across multiple Availability Zones. Attach an Application Load Balancer to the fleet.
  3. C

    Launch a Spot Fleet of Spot instances across multiple Availability Zones. Attach an Application Load Balancer to the fleet.
  4. D

    Create an Auto Scaling group On-Demand instances on multiple Availability Zones. Attach an Application Load Balancer to the group.
Xem giải thích

Đáp án

**B — Khởi chạy một Spot Fleet gồm cả instance On-Demand lẫn Spot trải nhiều vùng sẵn sàng, và gắn Application Load Balancer vào fleet đó.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này là phương án duy nhất thoả cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Phục hồi nhanh khi mất một AZ | trải nhiều AZ + ALB | | Rẻ nhất | kết hợp Spot với On-Demand |

⚠ Điểm mấu chốt: chỉ Spot Fleet mới trộn được HAI loại instance:

`DefaultTargetCapacityType` và
  `OnDemandTargetCapacity`
        ↓
    Một phần công suất chạy On-Demand
      (ổn định)
    → phần còn lại chạy Spot (rẻ)
        ↓
    ASG thường chỉ dùng một loại,
      trừ khi khai MixedInstancesPolicy

⚠ Và trang web sản xuất KHÔNG nên chạy toàn Spot:

Spot bị thu hồi bất kỳ lúc nào,
  báo trước 2 phút
        ↓
    Đề nói web đang chạy ở 90% CPU
      lúc cao điểm
    → mất một phần công suất Spot
      là mất dịch vụ
        ↓
    Phải có phần nền On-Demand

Đây là lý do phương án A và C rủi ro.

Tạo Spot Fleet trộn:

aws ec2 request-spot-fleet --spot-fleet-request-config '{
  "IamFleetRole": "<arn-vai-tro>",
  "TargetCapacity": 20,
  "OnDemandTargetCapacity": 8,
  "DefaultTargetCapacityType": "spot",
  "AllocationStrategy": "priceCapacityOptimized",
  "LaunchTemplateConfigs": [{
    "LaunchTemplateSpecification": {
      "LaunchTemplateId": "lt-abc", "Version": "$Latest"},
    "Overrides": [
      {"InstanceType":"m6i.large","SubnetId":"subnet-1a"},
      {"InstanceType":"m6a.large","SubnetId":"subnet-1b"},
      {"InstanceType":"m5.large","SubnetId":"subnet-1c"}]}]}'

⚠ priceCapacityOptimized là chiến lược phân bổ tốt nhất hiện nay: | Chiến lược | Cách chọn | |---|---| | lowestPrice | rẻ nhất, dễ bị thu hồi | | capacityOptimized | nhóm công suất sâu nhất | | priceCapacityOptimized | cân bằng cả hai — khuyến nghị |

⚠ Và đa dạng loại máy cùng AZ là điều kiện để Spot ổn định:

Chỉ xin m6i.large ở một AZ
    → hết công suất loại đó là
      mất sạch
        ↓
    Nhiều loại × nhiều AZ
    → xác suất mất hết cùng lúc
      rất thấp

⚠ Và "phục hồi nhanh khi mất AZ" đòi trải nhiều AZ:

Đề nói hiện tại chỉ MỘT instance
    → mất AZ đó là mất trang web
        ↓
    Trải ba AZ với ALB
    → mất một AZ, ALB tự ngừng gửi
      lưu lượng tới đó

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phần nền On-Demand bảo đảm dịch vụ không sập | | | Phần Spot giảm mạnh chi phí đỉnh tải | | | Trải nhiều AZ cho khả năng chịu lỗi | |

⚠ Và phải xử lý tín hiệu thu hồi Spot:

import requests
def sap_bi_thu_hoi():
    r = requests.get(
        'http://169.254.169.254/latest/meta-data/spot/instance-action',
        timeout=1)
    return r.status_code == 200

Báo trước 2 phút
    → rút instance khỏi target group
    → hoàn tất request đang xử lý
        ↓
    Không xử lý: người dùng gặp lỗi
      giữa chừng

Ghi nhớ về chất lượng câu hỏi

⚠ Auto Scaling group với Mixed Instances Policy là câu trả lời hiện đại cho bài toán này.

Spot Fleet là dịch vụ ra đời trước; ngày nay AWS khuyến nghị dùng ASG với MixedInstancesPolicy cho hầu hết trường hợp:

MixedInstancesPolicy:
  InstancesDistribution:
    OnDemandBaseCapacity: 8
    OnDemandPercentageAboveBaseCapacity: 25
    SpotAllocationStrategy: price-capacity-optimized
  LaunchTemplate:
    Overrides:
      - InstanceType: m6i.large
      - InstanceType: m6a.large
      - InstanceType: m5.large
Tiêu chí Spot Fleet ASG Mixed Instances
Co giãn theo chỉ số hạn chế đầy đủ
Tích hợp health check ELB hạn chế đầy đủ
Lifecycle hook không có
Được AWS khuyến nghị không CÓ 
Đề chỉ có Spot Fleet và ASG
  một-loại
        ↓
    Trong bốn phương án, B vẫn là
      lựa chọn đúng
    → nhưng thiết kế thật nên dùng
      ASG Mixed Instances

Và một điểm nữa: đề nói hệ thống đang dùng Reserved Instance cho tải nền, nhưng không phương án nào giữ lại chúng. Trong thực tế, RI vẫn áp dụng cho phần On-Demand tương ứng — chúng là mô hình thanh toán, không phải loại instance.

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

  • **A. Tạo Auto Scaling group toàn Spot trải nhiều AZ với ALB — đây là phương án gần nhất và trải nhiều AZ đúng, nhưng chạy toàn Spot cho trang web sản xuất đang ở 90% CPU là rủi ro: một đợt thu hồi lớn là mất dịch vụ.
  • **C. Spot Fleet toàn Spot trải nhiều AZ với ALB — cùng rủi ro, không có phần nền ổn định.
  • **D. ASG toàn On-Demand trải nhiều AZ với ALB — đáp ứng được tính sẵn sàng nhưng đắt nhất; đề hỏi cách rẻ nhất.

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 không gián đoạn được | | Spot | tới 90% | phần chịu được gián đoạn |

Từ khoá nhận diện:

"mix of On-Demand and Spot" → Spot Fleet hoặc ASG Mixed Instances "quickly recover from AZ outage" → nhiều AZ + ELB "most cost-effective" → Spot cho phần co giãn "consistent response time" → KHÔNG dùng Spot cho phần thiết yếu

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 và AZ giảm rủi ro | | | Capacity Rebalancing thay máy trước khi bị thu | |

⚠ Capacity Rebalancing nên bật:

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

EC2 phát tín hiệu "rủi ro thu hồi cao"
    → ASG tạo máy thay thế TRƯỚC
        ↓
    Không phải chờ tới thông báo
      2 phút

Ba lưu ý về ASG nhiều AZ: | Lưu ý | Chi tiết | |---|---| | ALB phải gắn đủ AZ mà ASG dùng | | | health-check-type ELB | | | Ba AZ rẻ hơn hai ở cùng mức chịu lỗi | |

⚠ Vì sao ba AZ rẻ hơn hai:

2 AZ: mỗi AZ gánh 100% tải
    → tổng công suất 200%
        ↓
    3 AZ: mỗi AZ gánh 50%
    → tổng công suất 150%

Ba lưu ý về ứng dụng stateless: | Lưu ý | Chi tiết | |---|---| | Bắt buộc khi dùng Spot | | | Phiên nằm ngoài instance | | | Không lưu gì trên đĩa cục bộ | |

Ba lưu ý về Reserved Instance: | Lưu ý | Chi tiết | |---|---| | Là mô hình THANH TOÁN, không phải loại instance | | | Tự áp cho instance On-Demand khớp | | | Savings Plan linh hoạt hơn RI | |

Ba lưu ý về mức sử dụng: | Lưu ý | Chi tiết | |---|---| | 90% CPU là quá cao cho hệ thống nhiều AZ | | | Mất một AZ là các AZ còn lại quá tải | | | Mục tiêu 50-60% để có biên | |

⚠ Đây là vấn đề đề đang mô tả:

Chạy 90% CPU lúc cao điểm
    → không có biên nào
        ↓
    Thêm một AZ chết
    → tải dồn sang, vượt 100%
    → sập dây chuyền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô phỏng thu hồi Spot bằng FIS | | | Tắt một AZ, xem dịch vụ còn chạy | | | Kiểm mức sử dụng CPU sau khi trải nhiều AZ | |

Và một lời khuyên: hãy dùng ASG với Mixed Instances Policy thay vì Spot Fleet cho hệ thống mới. Nó cho cùng khả năng trộn On-Demand với Spot nhưng có đầy đủ health check, lifecycle hook và chính sách co giãn — ba thứ mà Spot Fleet hoặc thiếu hoặc chỉ hỗ trợ một phần.

Câu 248 Domain - Design for New Solutions

A retail company runs its two-tier e-commerce website on its on-premises data center. The application runs on a LAMP stack behind a load balancing appliance. The operations team uses SSH to login to the application servers to deploy software updates and install patches on the system. The website has been a target of multiple cyber-attacks recently such as:

- Distributed Denial of Service (DDoS) attacks

- SQL Injection attacks

- Dictionary attacks to SSH accounts on the web servers

The solutions architect plans to migrate the whole system to AWS to improve its security and availability. The following approaches are laid out to address the company concerns:

- Fix SQL injection attacks by reviewing existing application code and logic.

- Use the latest Amazon Linux AMIs to ensure that initial security patches are installed.

- Install the AWS Systems Manager agent on the instances to manage OS patching.

Which of the following are additional recommended actions to address the identified attacks while maintaining high availability and security for the application?

  1. A

    Use an Application Load Balancer to spread the load on a cluster of Amazon EC2 instances. Disable remote SSH login to the EC2 instances and use AWS SSM Session Manager instead. Migrate the on-premises MySQL server to an Amazon RDS Multi-AZ instance. Create a CloudFront distribution in front of the application servers, and apply AWS WAF rules for the distribution. Enable AWS Shield Advanced for added protection.
  2. B

    Use an Application Load Balancer to spread the load on a cluster of Amazon EC2 instances. Enable remote SSH login only on a bastion host with limited access from the company IP address. Migrate the on-premises MySQL server to an Amazon RDS Multi-AZ instance. Create a CloudFront distribution in front of the application servers and enable AWS Shield Standard for DDoS protection.
  3. C

    Use an Application Load Balancer to spread the load on a cluster of Amazon EC2 instances. Enable remote SSH login on the EC2 instances but with limited access from the company IP address only. Migrate the on-premises MySQL server to an Amazon RDS Single-AZ instance. Enable AWS Shield Standard to protect the instances from DDoS attacks.
  4. D

    Use an Application Load Balancer to spread the load on a cluster of Amazon EC2 instances. Disable remote SSH login to the EC2 instances and use AWS SSM Session Manager instead. Migrate the on-premises MySQL server to an Amazon RDS Single-AZ instance. Create a CloudFront distribution in front of the application servers, and apply AWS WAF rules for the distribution.
Xem giải thích

Đáp án

**A — Dùng ALB phân tải lên cụm EC2; tắt SSH từ xa và dùng AWS SSM Session Manager thay thế; chuyển MySQL sang RDS Multi-AZ; tạo CloudFront trước máy chủ ứng dụng và áp luật AWS WAF; bật AWS Shield Advanced để chống DDoS nâng cao.

Vì sao đúng

Đề liệt kê ba loại tấn công, và phương án này phủ đủ cả ba: | Tấn công | Biện pháp | |---|---| | DDoS | CloudFront + Shield Advanced | | SQL injection | WAF (cộng với việc sửa mã đã nêu) | | Dò mật khẩu SSH | TẮT SSH, dùng Session Manager |

⚠ Session Manager loại bỏ hoàn toàn bề mặt tấn công SSH:

Bastion host (phương án B)
    → vẫn có cổng 22 mở ra Internet
    → vẫn bị dò mật khẩu, chỉ ít hơn
        ↓
    Session Manager: KHÔNG cổng nào mở
    → không có gì để dò
    → và mọi phiên đều ghi log được

Mở phiên không cần SSH:

aws ssm start-session --target i-abc

Ghi log mọi phiên:

aws ssm update-document --name SSM-SessionManagerRunShell \
  --content '{"schemaVersion":"1.0",
    "inputs":{"s3BucketName":"log-phien-ssm",
              "cloudWatchLogGroupName":"/ssm/phien",
              "cloudWatchEncryptionEnabled":true}}' \
  --document-version '$LATEST'

⚠ Và Shield Advanced khác Shield Standard ở ba điểm: | Tính năng | Standard | Advanced | |---|---|---| | Thông báo khi bị tấn công | KHÔNG | CÓ | | Đội ứng cứu (SRT) | không | có | | Bảo vệ chi phí khi co giãn | không | có | | WAF đi kèm | không | có |

Đề nói công ty ĐANG BỊ tấn công
  DDoS nhiều lần
        ↓
    Cần biết khi nào bị tấn công
    → và cần đội hỗ trợ
    → Shield Advanced

Đây là lý do phương án B và C yếu hơn — cả hai chỉ có Shield Standard.

⚠ Và Multi-AZ là yêu cầu của "duy trì tính sẵn sàng cao":

Single-AZ (phương án C, D)
    → mất AZ đó là mất CSDL
        ↓
    Multi-AZ: nhân bản đồng bộ,
      tự chuyển đổi
    → RPO bằng 0

Luật WAF:

aws wafv2 create-web-acl --name bao-ve-web \
  --scope CLOUDFRONT --default-action Allow={} \
  --rules '[
    {"Name":"ChanSQLi","Priority":1,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesSQLiRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"sqli"}},
    {"Name":"GioiHanTanSuat","Priority":2,
     "Statement":{"RateBasedStatement":{
       "Limit":2000,"AggregateKeyType":"IP"}},
     "Action":{"Block":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"rate"}}]'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không còn cổng SSH nào mở ra Internet | | | WAF chặn SQLi ở tầng biên | | | Shield Advanced có thông báo và đội hỗ trợ | |

⚠ Và phải chặn đường vòng qua CloudFront:

Kẻ tấn công tìm ra IP của ALB
    → đánh thẳng, bỏ qua CloudFront
      và WAF
        ↓
    CloudFront thêm header bí mật
    + WAF ở ALB chỉ cho qua yêu cầu
      có header đó

⚠ Điều kiện tiên quyết của Session Manager:

SSM Agent đang chạy
    + instance profile có
      `AmazonSSMManagedInstanceCore`
    + có đường tới endpoint SSM
        ↓
    Subnet riêng tư: cần ba VPC endpoint
      `ssm`, `ssmmessages`, `ec2messages`

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

  • **B. ALB + cụm EC2, bật SSH chỉ trên bastion host giới hạn theo IP công ty, RDS Multi-AZ, CloudFront với Shield Standard — đây là phương án gần nhất và Multi-AZ cùng bastion đều là thực hành hợp lý, nhưng bastion vẫn để lộ cổng 22 và Shield Standard không có thông báo hay đội ứng cứu; đề nói công ty đang bị DDoS nhiều lần nên cần Advanced.
  • **C. Bật SSH trên chính các EC2 giới hạn theo IP công ty, RDS Single-AZ, chỉ Shield Standard — Single-AZ không đáp ứng "duy trì tính sẵn sàng cao", và thiếu WAF cho SQL injection.
  • **D. Tắt SSH và dùng Session Manager, nhưng RDS Single-AZ và không có Shield Advanced — phần SSH đúng nhưng Single-AZ vi phạm yêu cầu sẵn sàng cao.

Ghi nhớ

⚠ Bốn lớp phòng thủ và tầng tương ứng — bảng phải thuộc: | Lớp | Dịch vụ | Chặn gì | |---|---|---| | Biên | CloudFront | hấp thụ và phân tán | | Tầng 3/4 | Shield | SYN flood, UDP reflection | | Tầng 7 | WAF | SQLi, XSS, HTTP flood | | Truy cập máy chủ | Session Manager | dò mật khẩu SSH |

Từ khoá nhận diện:

"SSH dictionary attacks" → tắt SSH, dùng Session Manager "SQL injection" → WAF + sửa mã "DDoS with notification" → Shield Advanced "maintain high availability" → Multi-AZ

Ba lưu ý về Session Manager: | Lưu ý | Chi tiết | |---|---| | Không cần cổng 22 hay bastion | | | Ghi log mọi phiên vào S3 hoặc CloudWatch | | | Kiểm soát ai vào máy nào bằng IAM | |

⚠ Giới hạn theo tag của instance:

{"Effect": "Allow", "Action": "ssm:StartSession",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringEquals":
   {"ssm:resourceTag/MoiTruong": "Dev"}}}

Người này chỉ vào được máy Dev
    → không vào được máy sản xuất

Ba lưu ý về Shield Advanced: | Lưu ý | Chi tiết | |---|---| | Cam kết 1 năm, 3.000 USD/tháng | | | WAF không tính phí thêm khi có Advanced | | | Cấp vai trò SRT TRƯỚC khi cần | |

Ba lưu ý về WAF: | Lưu ý | Chi tiết | |---|---| | Chạy Count trước khi Block | | | Scope CLOUDFRONT phải tạo ở us-east-1 | | | Bật logging để tinh chỉnh luật | |

⚠ Chạy Count trước là bắt buộc với trang bán hàng:

Bật Block ngay
    → luật quản lý chặn nhầm
      lưu lượng hợp lệ
        ↓
    Chặn nhầm = mất doanh thu
    → và không có lỗi nào hiện ra
      cho bạn

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Nhân bản đồng bộ, RPO bằng 0 | | | Bản dự phòng KHÔNG phục vụ đọc | | | Vá lỗi ít gián đoạn hơn | |

Ba lưu ý về vá lỗi: | Lưu ý | Chi tiết | |---|---| | Patch Manager với baseline | | | Maintenance Windows cho lịch | | | AMI mới thay vì vá tại chỗ với ASG | |

Ba lưu ý về LAMP trên AWS: | Thành phần | Đích | |---|---| | Apache/Nginx + PHP | EC2 trong ASG | | MySQL | RDS Multi-AZ hoặc Aurora | | Tệp tĩnh | S3 + CloudFront |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quét cổng từ Internet — 22 phải đóng | | | Gửi payload SQLi — WAF phải chặn | | | curl thẳng vào ALB — phải bị chặn | |

Và một lời khuyên: hãy bỏ hẳn bastion host thay vì siết nó lại. Một máy có cổng 22 mở ra Internet vẫn là mục tiêu bị dò mật khẩu liên tục dù bạn giới hạn IP đến đâu — còn Session Manager không có cổng nào để dò, và ghi lại mọi lệnh mà người vận hành gõ.

Câu 249 Domain - Continuous Improvement for Existing Solutions

A company has data centers in Europe, Asia, and North America regions. Each data center has a 10Gbps Direct Connect connection to AWS, and the company uses a custom VPN to encrypt traffic between its data center network and AWS. In total, the data centers have about five hundred physical servers that host a mix of Windows and Linux-based applications and database services. The company plans to decommission these data centers and migrate its entire infrastructure to the AWS cloud instead. Separate accounts for staging and launching VMs must be implemented, as well as the ability to do AWS Region-to-Region Amazon VPC stack creation.

Which of the following options is the recommended solution for this migration?

  1. A

    Leverage the Application Discovery Service from AWS. Install the Application Discovery Service agents on each physical server and visualize the infrastructure on the AWS Migration Hub console. Trigger the replication to copy your servers to AWS. After the replication is completed, start the cutover to AWS.
  2. B

    Leverage AWS Outposts service for the migration of physical servers to AWS. Install the Outposts server agent on the data center to incrementally replicate the servers into Amazon Machine Images (AMIs). Deploy the AMIs into Amazon EC2 instances to initiate cutover.
  3. C

    Leverage AWS Storage Gateway for the migration. Install the AWS Storage Gateway software appliance on their on-premises servers and use it to transfer their data to Amazon S3. Once the data is in S3, use Amazon EC2 to create virtual machines that replicate their on-premises infrastructure.
  4. D

    Leverage AWS Application Migration Service (AWS MGN) for the migration. Install the AWS Replication agent on each physical machine to start the replication to the AWS Cloud. Once syncing is completed, launch test instances and initiate cutover to the AWS Cloud.
Xem giải thích

Đáp án

**D — Dùng AWS Application Migration Service (MGN); cài AWS Replication Agent lên từng máy vật lý để bắt đầu nhân bản lên đám mây; khi đồng bộ xong thì khởi chạy instance kiểm thử rồi tiến hành cắt chuyển.

Vì sao đúng

Đề nêu ba yêu cầu, và MGN là dịch vụ được thiết kế đúng cho cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Chuyển 500 máy chủ vật lý (Windows và Linux) | MGN nhân bản ở mức khối, không phụ thuộc hệ điều hành | | Tách tài khoản staging và tài khoản khởi chạy | MGN hỗ trợ staging account riêng | | Dựng VPC ở nhiều Region | MGN chọn được Region và VPC đích |

⚠ MGN nhân bản ở MỨC KHỐI nên chạy được với máy vật lý:

Nhân bản mức khối: sao chép từng
  block của đĩa
        ↓
    Không quan tâm hệ điều hành gì,
      ứng dụng gì
    → chạy được với cả máy vật lý
      lẫn máy ảo

Cài agent:

sudo python3 aws-replication-installer-init.py \
  --region ap-southeast-1 \
  --aws-access-key-id <id> --aws-secret-access-key <key>

⚠ Và MGN dùng một VPC staging riêng — đây chính là "tách tài khoản staging":

Dữ liệu nhân bản đổ vào các
  instance staging rẻ tiền
        ↓
    Chúng nằm ở subnet staging
    → tách khỏi môi trường sản xuất
        ↓
    Khởi chạy instance thật ở
      VPC đích khi cắt chuyển

Cấu hình mẫu nhân bản:

aws mgn update-replication-configuration-template \
  --replication-configuration-template-id <id> \
  --staging-area-subnet-id subnet-staging \
  --replication-server-instance-type t3.small \
  --use-dedicated-replication-server false \
  --ebs-encryption DEFAULT \
  --data-plane-routing PRIVATE_IP

⚠ data-plane-routing PRIVATE_IP tận dụng Direct Connect đã có:

Đề nói mỗi trung tâm dữ liệu có
  Direct Connect 10 Gbps
        ↓
    Định tuyến qua IP riêng
    → dữ liệu nhân bản đi qua DX
    → không qua Internet
    → nhanh hơn và an toàn hơn

⚠ Và kiểm thử KHÔNG ảnh hưởng máy nguồn — điểm mạnh nhất của MGN:

Nhân bản vẫn chạy liên tục
    → khởi động instance kiểm thử
      từ bản sao
        ↓
    Kiểm thử bao nhiêu lần cũng được
    → máy chủ thật không hề biết
        ↓
    Với 500 máy chủ, đây là điều
      không thể thiếu

Khởi chạy instance kiểm thử:

aws mgn start-test --source-server-id s-abc

Cắt chuyển thật:

aws mgn start-cutover --source-server-ids s-abc s-def

⚠ Và Application Discovery Service (phương án A) chỉ KHẢO SÁT:

Discovery Service: thu thập cấu hình,
  hiệu năng, phụ thuộc
        ↓
    Nó KHÔNG nhân bản hay chuyển
      máy chủ nào
    → "trigger the replication" là
      mô tả sai về dịch vụ này

⚠ Nhưng Discovery Service vẫn nên chạy TRƯỚC MGN:

500 máy chủ: không ai biết chính xác
  cái nào gọi cái nào
        ↓
    Discovery vẽ sơ đồ phụ thuộc
    → biết di chuyển cụm nào cùng lúc
        ↓
    Rồi MGN thực hiện việc chuyển

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chạy với cả máy vật lý và máy ảo | | | Kiểm thử không ảnh hưởng nguồn | | | Gián đoạn cắt chuyển chỉ vài phút | |

⚠ Và tận dụng được Direct Connect cho khối lượng lớn:

500 máy chủ với dữ liệu lớn
    → nhân bản lần đầu tốn nhiều
      băng thông
        ↓
    DX 10 Gbps mỗi trung tâm
    → đủ cho việc này
    → và không chiếm băng thông
      Internet sản xuất

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

  • **A. Dùng Application Discovery Service, cài agent lên từng máy, xem hạ tầng trên Migration Hub, rồi kích hoạt nhân bản — đây là phương án gần nhất và Discovery Service thật sự là bước đầu đúng của mọi dự án di chuyển, nhưng nó chỉ khảo sát; nó không có chức năng nhân bản hay cắt chuyển máy chủ.
  • **B. Dùng AWS Outposts và cài "Outposts server agent" để nhân bản máy chủ thành AMI — Outposts là tủ rack phần cứng AWS đặt tại chỗ, không phải công cụ di chuyển; và không có agent nào như vậy.
  • **C. Dùng Storage Gateway chuyển dữ liệu lên S3 rồi tạo máy ảo từ đó — Storage Gateway chuyển dữ liệu, không chuyển máy chủ; và không có cơ chế nào biến dữ liệu S3 thành bản sao máy chủ đang chạy.

Ghi nhớ

⚠ Bốn công cụ di chuyển và vai trò — bảng phải thuộc: | Công cụ | Việc | |---|---| | Application Discovery Service | KHẢO SÁT trước khi di chuyển | | Application Migration Service (MGN) | CHUYỂN máy chủ, lift-and-shift | | DMS | chuyển CSDL | | DataSync | chuyển tệp và thư mục |

Từ khoá nhận diện:

"migrate physical servers" → MGN với Replication Agent "collect configuration and dependency data" → Discovery Service "migrate database" → DMS + SCT "track migration progress" → Migration Hub

⚠ Ba giai đoạn của một dự án di chuyển:

Đánh giá: Discovery Service,
  Migration Evaluator
    ↓
Chuẩn bị: Migration Hub,
  Strategy Recommendations
    ↓
Di chuyển: MGN, DMS, DataSync

Ba lưu ý về MGN: | Lưu ý | Chi tiết | |---|---| | Nhân bản liên tục ở mức khối | | | Kiểm thử nhiều lần không ảnh hưởng nguồn | | | Instance staging rẻ, chỉ để nhận dữ liệu | |

⚠ Chi phí trong lúc nhân bản khá thấp:

Instance staging dùng t3.small
    → chỉ để nhận và ghi dữ liệu
        ↓
    Chi phí chính là lưu trữ EBS
      của bản sao
    → và băng thông truyền

Ba lưu ý về cắt chuyển: | Lưu ý | Chi tiết | |---|---| | Kiểm thử kỹ trước khi cắt | | | Cắt chuyển theo cụm ứng dụng | | | Giữ máy nguồn vài ngày để quay lui | |

⚠ Cắt chuyển theo cụm là nguyên tắc quan trọng nhất:

Máy web lên cloud, CSDL còn tại chỗ
    → mỗi truy vấn đi vòng qua DX
        ↓
    Trang cần 50 truy vấn
    → cộng dồn thành vài giây
    → di chuyển cả cụm cùng lúc

Ba lưu ý về nhiều tài khoản: | Lưu ý | Chi tiết | |---|---| | MGN hỗ trợ tài khoản staging riêng | | | Instance đích khởi chạy ở tài khoản khác | | | Cần vai trò xuyên tài khoản | |

Ba lưu ý về nhiều Region: | Lưu ý | Chi tiết | |---|---| | MGN chọn Region đích cho từng máy chủ | | | CloudFormation StackSets dựng VPC ở nhiều Region | | | Kiểm hạn ngạch ở mọi Region đích | |

⚠ Hạn ngạch là bẫy khi chuyển 500 máy chủ:

Hạn ngạch vCPU mặc định thường thấp
    → 500 máy chủ cần hàng nghìn vCPU
        ↓
    Xin tăng hạn ngạch TRƯỚC
    → và cả hạn ngạch EBS, ENI,
      Elastic IP

Ba lưu ý về định cỡ: | Lưu ý | Chi tiết | |---|---| | Máy tại chỗ thường thừa công suất | | | MGN gợi ý loại instance dựa trên cấu hình | | | Compute Optimizer tinh chỉnh sau khi lên | |

Ba lưu ý về giấy phép: | Lưu ý | Chi tiết | |---|---| | Windows Server: BYOL hoặc license-included | | | License Manager theo dõi số lõi | | | Kiểm điều khoản giấy phép cho cloud | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khởi chạy instance kiểm thử và chạy thử ứng dụng | | | Đo độ trễ nhân bản của từng máy chủ | | | Đếm số máy chủ đã đồng bộ xong | |

Và một lời khuyên: hãy chạy Application Discovery Service trước khi bắt đầu nhân bản bằng MGN. Hai công cụ giải quyết hai bài toán khác nhau — và với 500 máy chủ thì sơ đồ phụ thuộc là thứ quyết định bạn cắt chuyển theo đợt nào, chứ không phải công cụ nhân bản.

Câu 250 Domain - Continuous Improvement for Existing Solutions

A leading insurance company in South East Asia recently deployed a new web portal that enables your users to log in and manage their accounts, view their insurance plans, and pay their monthly premiums. After a few weeks, the solutions architect noticed that there is a significant amount of incoming traffic from a country in which the insurance company does not operate. Later on, it was determined that the same set of IP addresses coming from the unsupported country is sending out massive amounts of requests to your portal which has caused some performance issues on the application.

Which of the following options is the recommended solution to block the series of attacks coming from a set of determined IP ranges?

  1. A Launch a Security Group with explicit deny rules to block the attacking IP addresses.
  2. B Launch the online portal on the private subnet.
  3. C Create an inbound Network Access control list associated with explicit deny rules to block the attacking IP addresses.
  4. D Create a custom route table associated with the web tier and block the attacking IP addresses from the Internet Gateway.
Xem giải thích

Đáp án

**C — Tạo network ACL chiều vào với quy tắc deny tường minh để chặn các địa chỉ IP đang tấn công.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể, và chỉ NACL làm được:

Chặn một tập IP đã xác định
        ↓
    Security group KHÔNG có quy tắc
      DENY — chỉ có ALLOW
        ↓
    NACL có cả allow lẫn deny
    → đây là công cụ duy nhất trong
      bốn phương án chặn được IP

⚠ Đây là khác biệt cơ bản nhất giữa SG và NACL: | Tiêu chí | Security group | Network ACL | |---|---|---| | Quy tắc | CHỈ allow | allow VÀ deny | | Áp ở | ENI (instance) | subnet | | Trạng thái | stateful | stateless | | Xử lý | mọi quy tắc | theo số thứ tự, dừng ở cái khớp đầu |

Đây là lý do phương án A sai — "security group với quy tắc deny tường minh" là thứ không tồn tại.

Thêm quy tắc chặn:

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

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

NACL xử lý theo số TĂNG DẦN
    → dừng ở quy tắc khớp đầu tiên
        ↓
    Quy tắc deny phải có số NHỎ HƠN
      quy tắc allow chung
    → đặt deny ở 50, allow ở 100

⚠ Và NACL là STATELESS — phải nhớ khi thêm quy tắc allow:

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 hỏng

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

⚠ Và Internet Gateway không lọc gì — đây là lý do phương án D sai:

Bảng định tuyến chỉ nói "đi đâu"
    → không nói "ai được đi"
        ↓
    Internet Gateway không có
      cơ chế lọc nào

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn ngay ở tầng subnet, trước khi tới instance | | | Không tốn tài nguyên của instance | | | Áp cho mọi tài nguyên trong subnet | |

Ghi nhớ về chất lượng câu hỏi

⚠ NACL là câu trả lời đúng trong bốn phương án, nhưng không phải công cụ tốt nhất cho tình huống này.

Đề mô tả lưu lượng lớn từ một quốc gia không được hỗ trợ, gây vấn đề hiệu năng — đó là mô tả của tấn công tầng ứng dụng, và AWS có công cụ chuyên cho nó:

Công cụ Ưu điểm so với NACL
WAF geo-match rule chặn theo QUỐC GIA, không phải từng IP
WAF rate-based rule chặn theo tần suất, IP đổi cũng bắt được
CloudFront geo restriction chặn ngay ở biên, không tới VPC 
aws wafv2 create-web-acl --name chan-quoc-gia \
  --scope CLOUDFRONT --default-action Allow={} \
  --rules '[{"Name":"ChanTheoQuocGia","Priority":1,
    "Statement":{"GeoMatchStatement":{
      "CountryCodes":["XX"]}},
    "Action":{"Block":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"geo"}}]'

⚠ Ba giới hạn của NACL trong tình huống này:

1. Hạn ngạch 20 quy tắc mỗi NACL
   (tăng lên 40)
        ↓
2. Kẻ tấn công đổi IP là phải
   thêm quy tắc mới
        ↓
3. Chặn cứng theo IP có thể chặn
   nhầm người dùng thật sau NAT

Với "một tập IP đã xác định" như đề nói thì NACL vẫn hợp lý và là đáp án đúng. Nhưng nếu tấn công tiếp diễn với IP thay đổi, WAF là lựa chọn bền vững hơn.

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

  • **A. Tạo Security Group với quy tắc deny tường minh để chặn IP tấn công — đây là phương án gần nhất và security group thật sự là công cụ lọc lưu lượng, nhưng nó chỉ có quy tắc allow; không có cách nào viết deny trong security group.
  • **B. Đưa cổng thông tin vào subnet riêng tư — làm vậy thì người dùng hợp lệ cũng không truy cập được; đây không phải giải pháp.
  • **D. Tạo bảng định tuyến tuỳ chỉnh và chặn IP tấn công tại Internet Gateway — bảng định tuyến quyết định đường đi, không lọc theo nguồn; Internet Gateway không có cơ chế lọc.

Ghi nhớ

⚠ Bốn cơ chế lọc lưu lượng — bảng phải thuộc: | Cơ chế | Lọc theo | Có deny | |---|---|---| | Security group | IP, cổng, SG khác | KHÔNG | | Network ACL | IP, cổng | CÓ | | WAF | IP, quốc gia, mẫu, tần suất | CÓ | | Network Firewall | tên miền, nội dung, luật Suricata | CÓ |

Từ khoá nhận diện:

"block specific IP addresses" → NACL "block a country" → WAF geo-match hoặc CloudFront geo restriction "too many requests from one IP" → WAF rate-based rule "allow only certain sources" → security group

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Stateless — phải mở cả hai chiều | | | Xử lý theo số thứ tự, dừng ở cái khớp đầu | | | Hạn ngạch 20 quy tắc (tăng lên 40) | |

⚠ Đánh số cách quãng để chèn được về sau:

Đánh 100, 200, 300
    → cần chèn giữa: dùng 150
        ↓
    Đánh liền nhau
    → phải đánh số lại toàn bộ

Ba lưu ý về security group: | Lưu ý | Chi tiết | |---|---| | Stateful — phản hồi tự động được phép | | | Chỉ có allow, muốn chặn thì dùng NACL | | | Tham chiếu SG khác thay vì CIDR | |

Ba lưu ý về WAF: | Lưu ý | Chi tiết | |---|---| | IP set quản lý danh sách IP tập trung | | | Geo-match chặn theo quốc gia | | | Rate-based chặn theo tần suất | |

⚠ IP set dễ bảo trì hơn quy tắc NACL:

aws wafv2 create-ip-set --name ip-bi-chan \
  --scope CLOUDFRONT --ip-address-version IPV4 \
  --addresses 203.0.113.0/24 198.51.100.5/32

Cập nhật một IP set
    → mọi web ACL dùng nó tự thấy
        ↓
    Và chứa tới 10.000 CIDR
    → so với 20-40 quy tắc của NACL

Ba lưu ý về chặn theo IP: | Lưu ý | Chi tiết | |---|---| | Văn phòng và mạng di động dùng chung IP | | | Chặn cứng có thể nuốt người dùng thật | | | Ưu tiên giới hạn tần suất hơn chặn cứng | |

Ba lưu ý về gỡ lỗi: | Công cụ | Việc | |---|---| | VPC Flow Logs | thấy gói bị REJECT ở đâu | | WAF sampled requests | xem yêu cầu bị chặn | | Reachability Analyzer | kiểm đường đi |

Ba lưu ý về kiến trúc phòng thủ: | Lớp | Công cụ | |---|---| | Biên | CloudFront + WAF + Shield | | Subnet | NACL | | Instance | security group |

⚠ Chặn càng sớm càng tốt:

Chặn ở NACL: gói tin đã vào VPC
        ↓
    Chặn ở CloudFront/WAF: chặn ngay
      ở điểm biên
    → không tiêu băng thông vào VPC
    → và không tính phí truyền dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem flow log có REJECT từ IP đó không | | | Kiểm người dùng hợp lệ vẫn truy cập được | | | Theo dõi tải của instance sau khi chặn | |

Và một lời khuyên: hãy chuyển sang WAF với luật geo-match và rate-based nếu tấn công tiếp diễn. Chặn từng IP trong NACL hoạt động cho một danh sách cố định, nhưng kẻ tấn công chỉ cần đổi dải IP là bạn lại phải thêm quy tắc — và hạn ngạch NACL sẽ cạn trước sự kiên nhẫn của họ.