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

Tìm thấy 1221 câu.

Câu 221 Domain - Continuous Improvement for Existing Solutions

A company stores confidential files on an Amazon S3 bucket. There was a recent production incident in the company in which the files that are stored in an S3 bucket were accidentally made public. This has caused data leakage that affected the company revenue. The management has instructed the solutions architect to come up with a solution to safeguard the S3 bucket. The solution should only allow private files to be uploaded to the S3 bucket and no file should have a public read or public write access.

Which of the following options should the solutions architect implement to meet the above requirements with MINIMAL effort?

  1. A

    Set up AWS Organizations and create a new Service Control Policy (SCP) that will deny public objects from being uploaded to the Amazon S3 bucket. Attach the SCP to the AWS account.
  2. B

    Set up a policy that restricts all s3:PutObject actions of the user to have a private canned ACL only which prohibits any public access to the uploaded objects.
  3. C

    Use the s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited managed rules in AWS Config to restrict all users from uploading publicly accessible and writable files to the S3 bucket.
  4. D

    Enable Amazon S3 Block Public Access in the S3 bucket.
Xem giải thích

Đáp án

**D — Bật Amazon S3 Block Public Access trên bucket.

Vì sao đúng

Đề hỏi cách đạt yêu cầu với CÔNG SỨC TỐI THIỂU, và đây là một công tắc duy nhất:

Bốn tuỳ chọn trong một lời gọi API
    → chặn mọi đường công khai
        ↓
    Không viết chính sách nào
    → không dựng dịch vụ nào
    → có hiệu lực NGAY LẬP TỨC

Bật đầy đủ:

aws s3api put-public-access-block --bucket tai-lieu-mat \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

⚠ Bốn tuỳ chọn làm bốn việc khác nhau — bảng phải thuộc: | Tuỳ chọn | Tác dụng | |---|---| | BlockPublicAcls | CHẶN việc ĐẶT ACL công khai mới | | IgnorePublicAcls | BỎ QUA mọi ACL công khai ĐÃ CÓ | | BlockPublicPolicy | CHẶN việc đặt bucket policy công khai | | RestrictPublicBuckets | chặn truy cập công khai qua policy đã có |

Hai cái đầu lo ACL
    → hai cái sau lo bucket policy
        ↓
    Bật cả bốn mới phủ hết

⚠ Và IgnorePublicAcls là thứ sửa được sự cố ĐÃ XẢY RA:

Tệp đã bị đặt public read
    → `IgnorePublicAcls` bỏ qua
      ACL đó ngay
        ↓
    Không phải đi sửa từng object
    → hiệu lực tức thì cho cả bucket

⚠ Bật ở mức TÀI KHOẢN còn mạnh hơn:

aws s3control put-public-access-block \
  --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

Áp cho MỌI bucket, kể cả bucket
  tạo trong tương lai
        ↓
    Không ai tạo được bucket công khai
      trong tài khoản này

⚠ Vì sao các phương án khác tốn công hơn: | Phương án | Công sức | |---|---| | SCP | dựng Organizations, viết chính sách, gắn OU | | IAM policy giới hạn canned ACL | viết chính sách cho từng người dùng | | Config rule | bật Config, cấu hình quy tắc, viết remediation |

⚠ Và Config chỉ PHÁT HIỆN, không CHẶN:

`s3-bucket-public-read-prohibited`
    → báo bucket đã công khai
        ↓
    Nhưng nó đã công khai rồi
    → dữ liệu có thể đã bị đọc
        ↓
    Block Public Access CHẶN
      từ đầu

Đây là lý do phương án C yếu hơn.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một lời gọi API, hiệu lực ngay | | | Phủ cả ACL lẫn bucket policy | | | Sửa được cả tình trạng đã công khai | |

⚠ Nhưng Block Public Access KHÔNG chặn mọi đường rò rỉ:

Nó chỉ chặn truy cập CÔNG KHAI
    → không chặn bucket policy cấp
      quyền cho một tài khoản AWS khác
        ↓
    Rò rỉ qua chia sẻ xuyên tài khoản
    → cần IAM Access Analyzer để
      phát hiện

Bật Access Analyzer:

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

⚠ Và nên tắt ACL hoàn toàn — đây là khuyến nghị hiện tại của AWS:

aws s3api put-bucket-ownership-controls \
  --bucket tai-lieu-mat \
  --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

`BucketOwnerEnforced`: ACL bị vô hiệu
  hoàn toàn
        ↓
    Mọi quyền chỉ qua bucket policy
      và IAM
    → bớt hẳn một cơ chế có thể
      cấu hình sai

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

  • **B. Lập chính sách buộc mọi s3:PutObject phải dùng canned ACL riêng tư — đây là phương án gần nhất và thật sự ngăn được object công khai mới, nhưng nó không xử lý object đã công khai, phải gắn cho từng người dùng, và không chặn được bucket policy công khai.
  • **C. Dùng quy tắc Config s3-bucket-public-read-prohibited và s3-bucket-public-write-prohibited — Config phát hiện chứ không chặn; dữ liệu có thể đã bị đọc trước khi quy tắc báo.
  • **A. Dựng Organizations và SCP từ chối tải lên object công khai — SCP là công cụ mạnh nhưng đòi dựng Organizations nếu chưa có; và SCP không diễn tả được điều kiện về ACL của object một cách đầy đủ.

Ghi nhớ

⚠ Bốn tầng kiểm soát truy cập S3 — bảng phải thuộc: | Tầng | Tác dụng | |---|---| | Block Public Access | chặn cứng mọi đường công khai | | Bucket policy | cấp/từ chối theo principal và điều kiện | | IAM policy | cấp quyền cho danh tính | | ACL | cơ chế cũ, nên tắt |

Từ khoá nhận diện:

"prevent public access, minimal effort" → Block Public Access "detect public buckets" → Config rule hoặc Access Analyzer "prevent across all accounts" → SCP hoặc Block Public Access mức tài khoản "shared with another AWS account" → IAM Access Analyzer

Ba lưu ý về Block Public Access: | Lưu ý | Chi tiết | |---|---| | Bật ở cả mức tài khoản và bucket | | | Không ảnh hưởng OAC của CloudFront | | | Mặc định BẬT cho bucket tạo từ 2023 | |

⚠ Điểm cuối là thay đổi quan trọng:

Từ tháng 4/2023, bucket mới
    → Block Public Access BẬT
      mặc định
    → và ACL bị vô hiệu mặc định
        ↓
    Bucket cũ vẫn giữ cấu hình cũ
    → phải rà lại và bật thủ công

Ba lưu ý về ACL: | Lưu ý | Chi tiết | |---|---| | AWS khuyến nghị TẮT hoàn toàn | | | BucketOwnerEnforced vô hiệu ACL | | | Mọi quyền chuyển sang bucket policy | |

Ba lưu ý về phục vụ nội dung công khai đúng cách: | Lưu ý | Chi tiết | |---|---| | CloudFront + OAC, bucket vẫn riêng tư | | | Pre-signed URL cho truy cập tạm | | | KHÔNG bao giờ mở bucket ra công khai | |

⚠ Bucket công khai gần như không bao giờ là câu trả lời đúng:

Cần phục vụ nội dung cho Internet
    → CloudFront với OAC
        ↓
    Bucket vẫn riêng tư hoàn toàn
    → và có cache, có WAF, có
      chứng chỉ

Ba lưu ý về phát hiện: | Công cụ | Việc | |---|---| | IAM Access Analyzer | tài nguyên chia sẻ ra ngoài | | Config rule | bucket vi phạm chuẩn | | Macie | dữ liệu nhạy cảm trong bucket |

Ba lưu ý về phòng ngừa ở tầng tổ chức: | Lưu ý | Chi tiết | |---|---| | SCP chặn s3:PutBucketPublicAccessBlock với giá trị false | | | Control Tower có guardrail sẵn | | | Kết hợp với Block Public Access mức tài khoản | |

{"Effect": "Deny",
 "Action": "s3:PutAccountPublicAccessBlock",
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::*:role/QuanTriBaoMat"}}}

Ba lưu ý về xử lý sau sự cố: | Lưu ý | Chi tiết | |---|---| | Kiểm CloudTrail data event xem ai đã tải về | | | Bật versioning để khôi phục nếu bị sửa | | | Rà soát mọi bucket khác cùng lúc | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl URL công khai của một object — phải 403 | | | Thử đặt bucket policy công khai — phải bị từ chối | | | Chạy Access Analyzer xem còn chia sẻ nào không | |

Và một lời khuyên: hãy bật Block Public Access ở mức tài khoản chứ đừng chỉ ở bucket. Sự cố rò rỉ tiếp theo sẽ đến từ một bucket ai đó tạo vội vào thứ sáu — và cấu hình mức tài khoản là thứ duy nhất phủ được cả những bucket chưa tồn tại.

Câu 222 Domain - Continuous Improvement for Existing Solutions

A world-renowned logistics company runs its global enterprise e-commerce platform on the AWS cloud. The company has built a multi-tier web application running in a VPC that uses an Elastic Load Balancer in front of both the web tier and the app tier, with static assets served directly from an Amazon S3 bucket. It uses a combination of Amazon RDS and DynamoDB for the dynamic data and then archiving nightly into an Amazon S3 bucket for further processing with Amazon Elastic MapReduce. After a routine audit, the company found questionable log entries and suspected that someone is attempting to gain unauthorized access to the system. The solutions architect has been tasked to improve the security of the architecture from DDoS, SQL injection, and HTTP flood attacks as well as from bad bots (content scrapers).

Which of the following approach provides the MOST suitable and scalable solution to protect the infrastructure from these kinds of security attacks?

  1. A

    Create an identical application stack that acts as a standby environment in another AWS region by using an AWS CloudFormation template. Use AWS CloudFormation StackSets to deploy the new stack and configure the security groups as well as network ACLs of the EC2 instances. Use Amazon Macie to protect the data stored in the Amazon S3 bucket. Create a Route 53 failover routing policy and configure an active-passive failover.
  2. B

    Insert the identified suspect's source IP as an explicit inbound deny to the network ACL rules of the web tier's subnet. Set up AWS Config to periodically audit the network ACLs and ensure that the blacklisted IP addresses are always in place.
  3. C

    Establish an AWS Direct Connect (DX) connection to the VPC through a Direct Connect partner. Configure Internet connectivity to filter the traffic in hardware Web Application Firewall (WAF) and then reroute the traffic through the DX connection into the application. Use the company's wide area network (WAN) to send traffic over the DX connection.
  4. D

    Set up AWS WAF and AWS Shield Advanced on all web endpoints. Launch AWS WAF rules against SQL injection and other common web exploits.
Xem giải thích

Đáp án

**D — Triển khai AWS WAF và AWS Shield Advanced trên mọi điểm cuối web, và bật luật WAF chống SQL injection cùng các lỗ hổng web phổ biến.

Vì sao đúng

Đề liệt kê bốn loại tấn công, và hai dịch vụ này phủ đủ: | Tấn công | Dịch vụ | |---|---| | DDoS (tầng 3/4) | Shield Advanced | | SQL injection | WAF | | HTTP flood | WAF rate-based rule | | Bot cào nội dung | WAF Bot Control |

⚠ Không có dịch vụ nào phủ cả bốn — phải dùng cả hai:

Shield: chống DDoS thể tích và
  giao thức
    → không hiểu nội dung HTTP
        ↓
    WAF: hiểu HTTP, lọc theo mẫu
      và tần suất
    → không chống được flood
      tầng mạng

Luật WAF phủ ba loại tấn công tầng 7:

aws wafv2 create-web-acl --name bao-ve-ung-dung \
  --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"}},
    {"Name":"ChanBot","Priority":3,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesBotControlRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"bot"}}]'

⚠ Rate-based rule là thứ duy nhất chặn được HTTP flood:

HTTP flood: yêu cầu hoàn toàn hợp lệ,
  chỉ là quá nhiều
        ↓
    Không có mẫu tấn công nào để khớp
    → chỉ chặn được theo TẦN SUẤT
        ↓
    2.000 yêu cầu trong 5 phút từ
      một IP là bất thường

⚠ Và Bot Control phân loại bot theo mục đích: | Nhóm bot | Xử lý | |---|---| | Bot tìm kiếm hợp pháp | cho qua | | Bot cào nội dung | chặn | | Bot không khai báo | thử thách |

Đề nói rõ "bad bots (content scrapers)"
    → đây là nhóm Bot Control
      xử lý được

⚠ Shield Advanced cho ba thứ Shield Standard không có: | 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ó |

Đề nói cần "bảo vệ có khả năng
  mở rộng"
    → Advanced có SRT hỗ trợ
      trong lúc tấn công

Bật bảo vệ:

aws shield create-protection \
  --name bao-ve-cloudfront \
  --resource-arn <arn-phan-phoi>

aws shield associate-drt-role \
  --role-arn arn:aws:iam::111122223333:role/DRTRole

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phủ cả bốn loại tấn công đề nêu | | | WAF không tính phí thêm khi có Shield Advanced | | | Có đội ứng cứu của AWS hỗ trợ | |

⚠ Và điểm cuối đáng nói riêng:

Shield Advanced: 3.000 USD/tháng
    → nhưng WAF đi kèm không tính
      phí riêng
        ↓
    Với hệ thống thương mại điện tử
      toàn cầu, chi phí này nhỏ hơn
      nhiều so với một giờ ngừng
      dịch vụ

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

  • **A. Dựng stack dự phòng ở Region khác bằng CloudFormation StackSets, dùng Macie bảo vệ dữ liệu S3 và Route 53 failover — đây là phương án gần nhất và là kiến trúc DR hợp lệ, nhưng DR không chống được tấn công: kẻ tấn công sẽ tấn công cả Region dự phòng; và Macie phát hiện dữ liệu nhạy cảm, không chống SQL injection.
  • **B. Thêm IP nghi vấn vào network ACL và dùng Config kiểm tra định kỳ — chặn từng IP không co giãn với DDoS phân tán từ hàng nghìn nguồn; và NACL không hiểu SQL injection.
  • **C. Dựng Direct Connect rồi lọc lưu lượng qua WAF phần cứng tại chỗ — đưa lưu lượng Internet vòng qua trung tâm dữ liệu rồi mới vào AWS là kiến trúc ngược, tốn kém và tạo thêm điểm hỏng.

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ì | |---|---|---| | DNS | Route 53 | tấn công tầng DNS | | 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, bot, HTTP flood |

Từ khoá nhận diện:

"SQL injection, XSS" → WAF "DDoS with notification" → Shield Advanced "content scrapers, bad bots" → WAF Bot Control "HTTP flood" → WAF rate-based rule

Ba nhóm luật quản lý nên bật: | Nhóm | Chặn gì | |---|---| | AWSManagedRulesCommonRuleSet | OWASP phổ biến | | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesKnownBadInputsRuleSet | payload đã biết là độc |

⚠ Luôn chạy Count trước khi Block:

{"OverrideAction": {"Count": {}}}

Bật Block ngay
    → luật quản lý chặn nhầm
      lưu lượng hợp lệ
        ↓
    Chạy Count vài ngày, đọc log
    → rồi mới chặn thật

Ba lưu ý về Bot Control: | Lưu ý | Chi tiết | |---|---| | Tính phí riêng theo lượt | | | Có nhóm Common và Targeted | | | Targeted dùng cho bot tinh vi, đắt hơn | |

Ba lưu ý về Shield Advanced: | Lưu ý | Chi tiết | |---|---| | Cam kết 1 năm | | | Áp cho cả tổ chức qua Organizations | | | Cấp vai trò SRT TRƯỚC khi cần | |

⚠ Cấp vai trò SRT lúc bình thường:

Đang bị tấn công lúc 3 giờ sáng
    → mới đi làm giấy tờ uỷ quyền
        ↓
    Mất thời gian quý nhất
    → làm trước, mất năm phút

Ba nguyên tắc giảm bề mặt tấn công: | Nguyên tắc | Chi tiết | |---|---| | Đặt origin sau CloudFront | | | Chặn truy cập thẳng vào ALB | | | Chỉ mở cổng thật sự cần | |

⚠ Chặn đường vòng qua CloudFront:

CloudFront thêm header bí mật
    → WAF ở ALB chỉ cho qua yêu cầu
      có header đó
        ↓
    Kẻ tấn công tìm được IP của ALB
    → vẫn bị chặn

Ba lưu ý về WAF logging: | Lưu ý | Chi tiết | |---|---| | Gửi log tới Firehose, S3 hoặc CloudWatch Logs | | | Phân tích để tinh chỉnh luật | | | Che trường nhạy cảm trong log | |

Ba lưu ý về co giãn để hấp thụ: | Lưu ý | Chi tiết | |---|---| | ASG với trần đủ cao | | | Nhưng đặt trần để tránh hoá đơn khổng lồ | | | Shield Advanced hoàn chi phí co giãn do DDoS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi payload SQLi thử — WAF phải chặn | | | Gửi nhiều yêu cầu từ một IP — rate rule phải chặn | | | Xem log WAF có chặn nhầm không | |

Và một lời khuyên: hãy chạy mọi luật quản lý ở chế độ Count trong ít nhất một tuần trước khi bật Block. Luật WAF chặn nhầm không báo lỗi cho bạn — nó báo lỗi cho khách hàng, và bạn chỉ biết khi doanh số giảm mà không rõ lý do.

Câu 223 Domain - Continuous Improvement for Existing Solutions

A company has recently migrated its core application to the AWS Cloud. The application allows users to upload scanned forms through a web application hosted on a fleet of Amazon EC2 instances. The application connects to a backend database hosted on Amazon RDS for PostgreSQL. The user metadata are stored on the database while the scanned forms are stored on an Amazon S3 bucket.

For each uploaded form, the application sends a notification to an Amazon SNS topic to which the team members are subscribed. Then, one of the team members will log in, validate the forms, and manually extracts relevant data from the scanned forms. This information is then submitted to another system using an API. The management wants to improve this process by automation to reduce human effort, increase efficiency and maintain high accuracy.

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

  1. A

    Add another tier to the application by using AWS Step Functions and AWS Lambda to facilitate the different stages of processing. Implement an artificial intelligence and machine learning (AL/ML) service using Amazon Rekognition and Amazon Transcribe to parse information from the scanned forms. Store the output in Amazon DocumentDB. Update the application to parse data from the DocumentDB table and send it to the other system via API call.
  2. B

    Add another tier to the application by deploying an artificial intelligence and machine learning (AL/ML) model trained using Amazon SageMaker service. Use this model to perform optical character recognition (OCR) on the uploaded forms. Store the output in another Amazon S3 bucket. Update the application to parse data from the Amazon S3 bucket and send it to the other system via API call.
  3. C

    Add another tier to the application by using AWS Step Functions and AWS Lambda to facilitate the different stages of processing. Use a combination of Amazon Textract and Amazon Comprehend to perform optical character recognition (OCR) and parse data from the scanned forms. Store the output in another Amazon S3 bucket. Update the application to parse data from the Amazon S3 bucket and send it to the other system via API call.
  4. D

    Add another tier to the application by deploying an open-source optical character recognition (OCR) software on Amazon Elastic Kubernetes (Amazon EKS) to process the uploaded forms. Store the output in another Amazon S3 bucket. Parse the output and send it to an Amazon DynamoDB table. Update the application to get data from the DynamoDB table and send it to the other system via API call.
Xem giải thích

Đáp án

**C — Thêm một tầng xử lý dùng AWS Step Functions và Lambda điều phối các giai đoạn; kết hợp Amazon Textract và Amazon Comprehend để nhận dạng ký tự quang học (OCR) và bóc dữ liệu từ biểu mẫu quét; lưu kết quả vào một bucket S3 khác; và cập nhật ứng dụng đọc dữ liệu từ đó rồi gọi API hệ thống kia.

Vì sao đúng

Đề nêu ba việc mà con người đang làm thủ công, và hai dịch vụ AI lo hai phần khác nhau: | Việc thủ công | Dịch vụ thay thế | |---|---| | Đọc chữ trong biểu mẫu quét | Textract (OCR) | | Hiểu và bóc trường dữ liệu có nghĩa | Comprehend | | Điều phối các bước | Step Functions |

⚠ Textract là dịch vụ DUY NHẤT làm OCR trên biểu mẫu:

Rekognition: nhận diện VẬT THỂ,
  khuôn mặt, cảnh trong ảnh
    → có `DetectText` nhưng chỉ cho
      chữ ngắn trong ảnh
        ↓
    Textract: đọc TÀI LIỆU
    → hiểu bảng, biểu mẫu, cặp
      khoá-giá trị

Đây là lý do phương án A sai — nó dùng Rekognition và Transcribe (vốn để chuyển giọng nói thành văn bản).

⚠ Và Textract hiểu CẤU TRÚC biểu mẫu, không chỉ đọc chữ:

import boto3
textract = boto3.client('textract')
kq = textract.analyze_document(
    Document={'S3Object': {'Bucket': 'bieu-mau', 'Name': khoa}},
    FeatureTypes=['FORMS', 'TABLES'])

`FORMS`: trả về cặp khoá-giá trị
    → "Họ tên: Nguyễn Văn A"
        ↓
    `TABLES`: giữ nguyên cấu trúc bảng
    → đây là thứ OCR thuần không làm được

⚠ Với tài liệu nhiều trang phải dùng API bất đồng bộ:

job = textract.start_document_analysis(
    DocumentLocation={'S3Object':
        {'Bucket': 'bieu-mau', 'Name': khoa}},
    FeatureTypes=['FORMS'],
    NotificationChannel={'SNSTopicArn': arn_sns,
                         'RoleArn': arn_vai_tro})

`analyze_document` đồng bộ: một trang
    → `start_document_analysis`: nhiều
      trang, chạy nền
    → báo qua SNS khi xong

⚠ Và Comprehend bóc thực thể mà Textract không hiểu:

Textract cho ra văn bản có cấu trúc
    → nhưng không biết đâu là tên
      thuốc, đâu là chẩn đoán
        ↓
    Comprehend: nhận diện thực thể
    → và Comprehend Medical cho
      lĩnh vực y tế

Máy trạng thái điều phối:

{"StartAt": "TrichXuat",
 "States": {
   "TrichXuat": {
     "Type": "Task",
     "Resource": "arn:aws:states:::lambda:invoke",
     "Parameters": {"FunctionName": "goi-textract",
                    "Payload.$": "$"},
     "Retry": [{"ErrorEquals": ["States.TaskFailed"],
                "IntervalSeconds": 5, "MaxAttempts": 3,
                "BackoffRate": 2.0}],
     "Next": "PhanTich"},
   "PhanTich": {
     "Type": "Task",
     "Resource": "arn:aws:states:::lambda:invoke",
     "Parameters": {"FunctionName": "goi-comprehend"},
     "Next": "GuiSangHeThongKia"},
   "GuiSangHeThongKia": {
     "Type": "Task",
     "Resource": "arn:aws:states:::lambda:invoke",
     "Parameters": {"FunctionName": "goi-api"},
     "Catch": [{"ErrorEquals": ["States.ALL"],
                "Next": "XuLyLoi"}],
     "End": true},
   "XuLyLoi": {"Type": "Fail"}}}

⚠ Step Functions cho ba thứ mà chuỗi Lambda thuần không có:

1. Thấy được biểu mẫu nào đang
   ở bước nào
        ↓
2. Thử lại từng bước với backoff
   mà không viết mã
        ↓
3. Nhánh xử lý lỗi rõ ràng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần huấn luyện mô hình nào | | | Textract chính xác hơn OCR mã nguồn mở | | | Không có máy chủ nào phải vận hành | |

⚠ Và điểm quan trọng nhất: không phải tự huấn luyện:

SageMaker (phương án B): phải chuẩn bị
  dữ liệu gán nhãn, huấn luyện,
  đánh giá, triển khai, theo dõi trôi
        ↓
    Textract: gọi một API
    → AWS đã huấn luyện trên hàng
      triệu tài liệu

⚠ Và Textract có tính năng dành riêng cho biểu mẫu đặc thù:

Amazon Textract Queries
    → hỏi thẳng: "Số hợp đồng là gì?"
        ↓
    Không cần biết vị trí trường
      trên trang
    → hợp với biểu mẫu có nhiều
      định dạng khác nhau

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

  • **B. Triển khai mô hình huấn luyện bằng SageMaker để làm OCR trên biểu mẫu — đây là phương án gần nhất và về lý thuyết làm được, nhưng huấn luyện mô hình OCR từ đầu là dự án nhiều tháng với dữ liệu gán nhãn; đề đòi giảm công sức con người, không phải tăng.
  • **A. Dùng Step Functions và Lambda, nhưng dùng Rekognition và Transcribe để bóc dữ liệu, lưu vào DocumentDB — Transcribe chuyển giọng nói thành văn bản, hoàn toàn sai loại đầu vào; và Rekognition không đọc được biểu mẫu có cấu trúc.
  • **D. Triển khai phần mềm OCR mã nguồn mở trên EKS — phải tự vận hành cụm Kubernetes, tự tinh chỉnh mô hình, và độ chính xác thường kém hơn Textract với biểu mẫu.

Ghi nhớ

⚠ Sáu dịch vụ AI xử lý tài liệu và ngôn ngữ — bảng phải thuộc: | Dịch vụ | Vào | Ra | |---|---|---| | Textract | tài liệu quét, PDF | văn bản, bảng, biểu mẫu | | Rekognition | ảnh, video | vật thể, khuôn mặt, cảnh | | Transcribe | âm thanh | văn bản | | Comprehend | văn bản | thực thể, cảm xúc, chủ đề | | Translate | văn bản | ngôn ngữ khác | | Polly | văn bản | giọng nói |

Từ khoá nhận diện:

"extract data from scanned forms" → Textract "detect objects in images" → Rekognition "speech to text" → Transcribe "understand meaning of text" → Comprehend

⚠ Ba tính năng của Textract — phải phân biệt: | Tính năng | Trả về | |---|---| | DetectDocumentText | chỉ văn bản thô | | AnalyzeDocument với FORMS | cặp khoá-giá trị | | AnalyzeDocument với TABLES | cấu trúc bảng | | AnalyzeExpense | hoá đơn, biên lai | | AnalyzeID | giấy tờ tuỳ thân |

Ba lưu ý về Comprehend: | Lưu ý | Chi tiết | |---|---| | Nhận diện thực thể có sẵn | | | Custom entity recognition cho lĩnh vực riêng | | | Comprehend Medical cho y tế | |

⚠ Comprehend Medical hợp với biểu mẫu y tế:

comprehend_medical = boto3.client('comprehendmedical')
kq = comprehend_medical.detect_entities_v2(Text=van_ban)

Nhận diện thuốc, liều lượng,
  chẩn đoán, triệu chứng
        ↓
    Và tự phát hiện thông tin
      định danh bệnh nhân

Ba lưu ý về Step Functions: | Lưu ý | Chi tiết | |---|---| | Standard cho quy trình dài, có bước chờ | | | Express cho thông lượng cao, dưới 5 phút | | | Tích hợp trực tiếp nhiều dịch vụ, không cần Lambda | |

Ba lưu ý về xử lý lỗi: | Cơ chế | Việc | |---|---| | Retry | thử lại với backoff | | Catch | chuyển sang nhánh xử lý lỗi | | DLQ | giữ tài liệu không xử lý được |

⚠ Tài liệu chất lượng kém là ca phải xử lý:

Bản quét mờ, nghiêng, viết tay
    → Textract trả độ tin cậy thấp
        ↓
    Đặt ngưỡng: dưới X% thì chuyển
      cho người xem
    → giữ được độ chính xác cao
      mà vẫn tự động hoá phần lớn

Ba lưu ý về A2I (Augmented AI): | Lưu ý | Chi tiết | |---|---| | Đưa ca độ tin cậy thấp cho người duyệt | | | Tích hợp sẵn với Textract | | | Kết quả người duyệt dùng để cải thiện | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Textract tính theo TRANG | | | AnalyzeDocument đắt hơn DetectDocumentText | | | Chỉ bật FORMS/TABLES khi cần | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Biểu mẫu có thể chứa dữ liệu cá nhân | | | Mã hoá bucket đầu vào và đầu ra | | | Comprehend có tính năng che PII | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử trên mẫu biểu mẫu thật, so với người làm | | | Đo tỷ lệ ca phải chuyển cho người | | | Kiểm chi phí trên số trang thật | |

Và một lời khuyên: hãy đặt ngưỡng độ tin cậy và giữ một luồng cho người duyệt các ca khó. Tự động hoá 90% với độ chính xác cao có giá trị hơn nhiều so với tự động hoá 100% với những sai sót lặng lẽ — nhất là khi đầu ra được gửi thẳng sang một hệ thống khác qua API.

Câu 224 Domain - Design for New Solutions

A company has recently finished developing a web application that will soon be put into production. Before it is transferred into the production environment, a final test run must be conducted. Only the employees can access the web app - either from the corporate network or from the Internet. The manager instructed the solutions architect to ensure that the EC2 instance hosting the application server will not be exposed to the Internet.

Which of the following options is the recommended implementation to fulfill the company requirements?

  1. A

    1. Configure SSL VPN on the public subnet of your VPC.

    2. Install an SSL VPN client software on all employee workstations.

    3. Create a private subnet in your VPC and place your application servers in it.
  2. B

    1. Launch an Elastic Load Balancer for your EC2 instances that terminates SSL to them.

    2. Create a public subnet in your VPC and launch your application servers in it.
  3. C

    1. Use AWS Direct Connect to hook up your employee workstations to the VPC via a private interface.

    2. Create a public subnet and place your application servers in it.
  4. D

    1. Use IPsec VPN that would allow your employees to access the network of your application servers. 

    2. Create a public subnet in your VPC and launch your application servers in it.
Xem giải thích

Đáp án

**A — Cấu hình SSL VPN trên subnet công khai của VPC, cài phần mềm SSL VPN client lên máy trạm của nhân viên, và tạo subnet riêng tư đặt các máy chủ ứng dụng vào đó.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | EC2 không lộ ra Internet | subnet riêng tư, không có IP công khai | | Nhân viên truy cập từ mạng công ty | VPN từ máy trạm | | Và từ Internet | SSL VPN client chạy ở bất kỳ đâu |

⚠ Điểm mấu chốt: "từ Internet" nghĩa là từ máy trạm bất kỳ, không phải từ mạng công ty:

IPsec site-to-site VPN
    → nối MẠNG với MẠNG
        ↓
    Nhân viên làm việc ở nhà
    → máy của họ không thuộc mạng nào
      đã nối
        ↓
    Cần VPN kiểu CLIENT
    → phần mềm trên từng máy trạm

Đây là lý do phương án D yếu hơn — IPsec thường dùng cho site-to-site.

⚠ Và mọi phương án đặt máy chủ ở subnet CÔNG KHAI đều sai:

Đề nói rõ: "instance không được
  lộ ra Internet"
        ↓
    Subnet công khai có tuyến tới
      Internet gateway
    → dù không gán IP công khai,
      đó vẫn là thiết kế sai chủ đích

Đây là lý do phương án B, C và D đều sai ở vế thứ hai.

Kiến trúc:

Máy trạm nhân viên (bất kỳ đâu)
    ↓ SSL VPN
Subnet CÔNG KHAI: endpoint VPN
    ↓
Subnet RIÊNG TƯ: máy chủ ứng dụng
    ↓
Không có tuyến nào ra Internet
  (hoặc chỉ qua NAT cho cập nhật)

⚠ AWS Client VPN là dịch vụ quản lý cho đúng việc này:

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

⚠ --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

Gắn subnet và cấp quyền:

aws ec2 associate-client-vpn-target-network \
  --client-vpn-endpoint-id cvpn-abc \
  --subnet-id subnet-cong-khai

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

⚠ access-group-id cho phép phân quyền theo nhóm:

Nhóm "QA" chỉ tới được subnet
  môi trường thử
    → nhóm "Vận hành" tới được
      cả subnet sản xuất
        ↓
    Một endpoint VPN, nhiều mức
      quyền khác nhau

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Máy chủ hoàn toàn không lộ ra Internet | | | Nhân viên truy cập từ bất kỳ đâu | | | Ghi log mọi kết nối | |

⚠ Và có lựa chọn còn đơn giản hơn nếu chỉ cần truy cập máy chủ:

Systems Manager Session Manager
    → shell vào EC2 không cần VPN,
      không cần cổng mở
        ↓
    Nhưng đề nói nhân viên dùng
      ỨNG DỤNG WEB
    → cần truy cập cổng HTTP,
      không chỉ shell

⚠ Hoặc dùng ALB nội bộ với xác thực:

ALB internal trong subnet riêng
    + AWS Verified Access
        ↓
    Truy cập ứng dụng qua trình duyệt
      với xác thực zero-trust
    → không cần VPN client nào

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

  • **D. Dùng IPsec VPN cho nhân viên truy cập mạng máy chủ ứng dụng, và đặt máy chủ ở subnet công khai — đây là phương án gần nhất và VPN là hướng đi đúng, nhưng đặt máy chủ ở subnet công khai vi phạm thẳng yêu cầu; và IPsec thường dùng cho kết nối site-to-site chứ không phải từng máy trạm.
  • **B. Dùng ELB chấm dứt SSL và đặt máy chủ ở subnet công khai — ELB đứng trước không làm máy chủ bớt lộ ra nếu chúng ở subnet công khai; và ELB internet-facing chính là lộ ứng dụng ra Internet.
  • **C. Dùng Direct Connect nối máy trạm nhân viên vào VPC, đặt máy chủ ở subnet công khai — Direct Connect nối trung tâm dữ liệu với AWS, không nối từng máy trạm; và vẫn đặt máy chủ ở subnet công khai.

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 | | Session Manager | shell vào EC2, không cần VPN |

Từ khoá nhận diện:

"employees from corporate network AND Internet" → Client VPN "connect two networks" → Site-to-Site VPN "shell access without bastion" → Session Manager "browser access with zero trust" → Verified Access

⚠ Subnet công khai và riêng tư — định nghĩa chính xác: | Loại | Định nghĩa | |---|---| | Công khai | bảng định tuyến CÓ tuyến tới Internet gateway | | Riêng tư | KHÔNG có tuyến đó |

Không phụ thuộc vào việc instance
  có IP công khai hay không
    → phụ thuộc BẢNG ĐỊNH TUYẾN

Ba lưu ý về AWS Client VPN: | Lưu ý | Chi tiết | |---|---| | Xác thực bằng chứng chỉ, AD hoặc SAML | | | Tính phí theo giờ endpoint và giờ kết nối | | | Split tunnel giảm chi phí và băng thông | |

⚠ Chi phí Client VPN gồm hai phần:

Phí endpoint theo giờ mỗi subnet
  đã gắn
    + phí theo giờ mỗi kết nối
      đang hoạt động
        ↓
    Gắn nhiều subnet để có HA
    → nhân phí endpoint 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ề sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | Gắn endpoint vào ít nhất hai subnet ở hai AZ | | | Client tự kết nối lại khi một AZ hỏng | | | Client CIDR phải đủ lớn cho số người dùng | |

⚠ Client CIDR không đổi được sau khi tạo:

Chọn /22 cho 1.000 người dùng
    → sau này cần 5.000
        ↓
    Phải tạo endpoint MỚI
    → chọn dải rộng ngay từ đầu

Ba lưu ý về AWS Verified Access: | Lưu ý | Chi tiết | |---|---| | Truy cập ứng dụng qua trình duyệt, không cần VPN | | | Đánh giá theo danh tính và trạng thái thiết bị | | | Ghi log mọi quyết định cho phép hay từ chối | |

⚠ Đây là hướng hiện đại thay cho VPN:

VPN: vào được mạng là vào được
  mọi thứ trong đó
        ↓
    Verified Access: kiểm tra từng
      yêu cầu, từng ứng dụng
    → nguyên tắc zero-trust

Ba lưu ý về subnet riêng tư: | Lưu ý | Chi tiết | |---|---| | Cần NAT gateway nếu máy chủ phải cập nhật | | | VPC endpoint cho dịch vụ AWS, tránh NAT | | | Không gán IP công khai | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử truy cập ứng dụng từ Internet — phải không thông | | | Kết nối VPN rồi thử lại — phải thông | | | Kiểm bảng định tuyến của subnet ứng dụng | |

Và một lời khuyên: hãy kiểm tra bảng định tuyến chứ đừng chỉ nhìn xem instance có IP công khai không. Một subnet có tuyến tới Internet gateway vẫn là subnet công khai — và một instance ở đó chỉ cách việc lộ ra Internet đúng một lần ai đó gán nhầm Elastic IP.

Câu 225 Domain - Design Solutions for Organizational Complexity

A company uses Amazon WorkSpaces to improve the productivity and security of its remote workers. Hundreds of remote workers log in to the virtual desktop service using the Amazon WorkSpaces client application on a regular basis. Users have reported that they cannot log in to their virtual desktops even though they have the correct credentials.

Upon investigation, the Solutions Architect discovered that the filesystem storing the user profiles has reached its capacity, which is the reason why users cannot establish a new session in Amazon WorkSpaces. The environment is configured with a 10 TB Amazon FSx for Windows File Server file system to store the user profiles.

Which of the following options should the Solutions Architect implement to solve the issue and prevent it from happening again?

  1. A

    Create an Amazon CloudWatch Alarm using the FreeStorageCapacity metric to monitor the file system. Once triggered, use AWS Steps Functions as the target. Run the Steps Function to create a new Amazon FSx for Windows File Server file system and migrate the user profiles.
  2. B

    Create an Amazon CloudWatch Alarm to monitor the FreeStorageCapacity metric of the file system. Write an AWS Lambda Function to increase the capacity of the Amazon FSx for Windows File Server file system using the update-file-system command. Utilize Amazon EventBridge to invoke this Lambda function when the metric threshold is reached.
  3. C

    From the Amazon FSx console, select the desired file system to edit its attributes. Enable the option Dynamically Allocate to allow the file system to scale depending on the size of the data stored. This will present a large capacity drive to Amazon WorkSpaces clients and will grow automatically as users add more data to their profiles.
  4. D

    Create a new Amazon FSx for Windows File Server file system with a larger capacity. Create a script to copy all user profiles to the new file system. Create an Amazon CloudWatch metric to monitor the FreeStorageCapacity of the filesystem and send a notification via Amazon SNS before it reaches capacity.
Xem giải thích

Đáp án

**B — Tạo CloudWatch Alarm theo dõi chỉ số FreeStorageCapacity của hệ thống tệp; viết hàm Lambda tăng dung lượng FSx bằng lệnh update-file-system; và dùng EventBridge gọi hàm đó khi alarm chạm ngưỡng.

Vì sao đúng

Đề nêu hai việc, và phương án này khớp cả hai: | Việc | Cách đáp ứng | |---|---| | Sửa sự cố hiện tại | tăng dung lượng ngay | | Ngăn tái diễn | alarm + tự động tăng khi sắp đầy |

⚠ FSx for Windows tăng dung lượng ĐƯỢC mà không gián đoạn:

`update-file-system` với dung lượng
  lớn hơn
        ↓
    Hệ thống tệp vẫn phục vụ trong
      lúc mở rộng
    → người dùng không bị ngắt phiên
        ↓
    Đây là lý do không cần tạo
      hệ thống tệp mới và chép dữ liệu

Tăng dung lượng:

aws fsx update-file-system --file-system-id fs-abc \
  --storage-capacity 15360

⚠ Nhưng có ba ràng buộc phải nhớ:

1. Chỉ TĂNG được, không giảm
        ↓
2. Mỗi lần tăng ít nhất 10%
        ↓
3. Phải chờ 6 giờ giữa hai lần tăng

⚠ Ràng buộc thứ ba ảnh hưởng thiết kế tự động hoá:

Hàm Lambda gọi liên tục khi
  alarm còn kêu
        ↓
    Lần thứ hai trong 6 giờ sẽ lỗi
    → phải kiểm trạng thái trước
      khi gọi

Hàm Lambda kiểm tra trước khi tăng:

import boto3
fsx = boto3.client('fsx')

def handler(su_kien, ngu_canh):
    fs = fsx.describe_file_systems(
        FileSystemIds=[MA_FS])['FileSystems'][0]
    dang_cap_nhat = [u for u in fs.get('AdministrativeActions', [])
                     if u['AdministrativeActionType']
                        == 'FILE_SYSTEM_UPDATE'
                     and u['Status'] in ('PENDING', 'IN_PROGRESS')]
    if dang_cap_nhat:
        return
    moi = int(fs['StorageCapacity'] * 1.3)
    fsx.update_file_system(FileSystemId=MA_FS,
                           StorageCapacity=moi)

Alarm trên dung lượng còn trống:

aws cloudwatch put-metric-alarm \
  --alarm-name fsx-sap-day \
  --namespace AWS/FSx --metric-name FreeStorageCapacity \
  --dimensions Name=FileSystemId,Value=fs-abc \
  --statistic Minimum --period 300 --threshold 1099511627776 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 2

⚠ Chú ý đơn vị của FreeStorageCapacity là BYTE:

1 TB = 1.099.511.627.776 byte
    → đặt ngưỡng bằng số byte
        ↓
    Nhầm đơn vị là alarm không bao giờ
      kêu, hoặc kêu liên tục

⚠ Và tuỳ chọn "Dynamically Allocate" trong phương án C KHÔNG tồn tại:

FSx for Windows không có chế độ
  tự mở rộng theo dữ liệu
        ↓
    Phải gọi API tăng dung lượng
    → đây là lý do phải tự động hoá

⚠ Nhưng thông lượng cũng nên tăng theo:

aws fsx update-file-system --file-system-id fs-abc \
  --windows-configuration ThroughputCapacity=64

Tăng dung lượng mà giữ nguyên
  thông lượng
        ↓
    Nhiều người dùng hơn trên cùng
      băng thông
    → chậm dần dù không đầy đĩa

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không gián đoạn phiên người dùng | | | Không phải chép dữ liệu sang nơi khác | | | Tự động, không cần ai trực | |

⚠ Và nên xử lý nguyên nhân gốc song song:

Hồ sơ người dùng phình mãi
    → tăng dung lượng là chữa triệu chứng
        ↓
    Đặt hạn ngạch cho từng người dùng
    → và bật Data Deduplication

Enable-FSxDedup -FileSystemId fs-abc

Khử trùng lặp trên hồ sơ người dùng
    → thường tiết kiệm 30-60%
    → vì nhiều người có cùng tệp

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

  • **D. Tạo hệ thống tệp mới lớn hơn, viết script chép toàn bộ hồ sơ sang, và alarm gửi thông báo SNS trước khi đầy — đây là phương án gần nhất và giải quyết được sự cố, nhưng chép 10 TB hồ sơ người dùng gây gián đoạn dài; và thông báo SNS chỉ báo cho người, không tự sửa.
  • **A. Alarm trên FreeStorageCapacity rồi dùng Step Functions tạo hệ thống tệp mới và di chuyển hồ sơ — cùng vấn đề: tạo mới và chép dữ liệu là thao tác nặng, trong khi FSx tăng dung lượng tại chỗ được.
  • **C. Bật tuỳ chọn "Dynamically Allocate" trong console FSx — tuỳ chọn này không tồn tại.

Ghi nhớ

⚠ Ba chỉ số quan trọng của FSx for Windows — bảng phải thuộc: | Chỉ số | Cảnh báo khi | |---|---| | FreeStorageCapacity | dưới ngưỡng an toàn | | ClientConnections | gần trần của thông lượng | | DataReadBytes / DataWriteBytes | chạm trần thông lượng |

Từ khoá nhận diện:

"file system full, WorkSpaces cannot log in" → tăng dung lượng FSx "scale storage automatically" → alarm + Lambda + update-file-system "Windows ACLs, AD integration" → FSx for Windows "reduce storage usage" → deduplication, user quota |

Ba ràng buộc khi tăng dung lượng FSx: | Ràng buộc | Chi tiết | |---|---| | Chỉ tăng, không giảm | | | Tối thiểu 10% mỗi lần | | | Chờ 6 giờ giữa hai lần | |

⚠ Không giảm được nghĩa là đừng tăng quá tay:

Tăng từ 10 TB lên 50 TB "cho chắc"
    → trả tiền 50 TB mãi mãi
        ↓
    Tăng dần theo nhu cầu
    → và bật deduplication trước

Ba lưu ý về Data Deduplication: | Lưu ý | Chi tiết | |---|---| | Chạy nền, không ảnh hưởng nhiều | | | Hiệu quả nhất với hồ sơ người dùng | | | Đặt lịch chạy ngoài giờ cao điểm | |

Ba lưu ý về hạn ngạch người dùng: | Lưu ý | Chi tiết | |---|---| | Đặt hạn ngạch mềm để cảnh báo | | | Hạn ngạch cứng để chặn | | | Ngăn một người dùng làm đầy cả hệ thống | |

Set-FSxUserQuotas -FileSystemId fs-abc `
  -Domain congty.local -QuotaType Default `
  -WarningLimit 40GB -Limit 50GB

Ba lưu ý về thông lượng: | Lưu ý | Chi tiết | |---|---| | Chọn riêng, không theo dung lượng | | | Tăng được sau khi tạo | | | Hồ sơ roaming tạo nhiều I/O nhỏ | |

Ba lưu ý về WorkSpaces và FSx: | Lưu ý | Chi tiết | |---|---| | FSlogix hoặc hồ sơ roaming lưu trên FSx | | | Hệ thống tệp đầy là không ai đăng nhập được | | | Đây chính là triệu chứng trong đề | |

⚠ Vì sao đầy đĩa lại chặn ĐĂNG NHẬP:

Người dùng đăng nhập
    → Windows nạp hồ sơ từ FSx
    → và cần ghi tệp tạm
        ↓
    Không ghi được
    → phiên không tạo được
    → lỗi hiện ra là "không đăng nhập
      được", không phải "đĩa đầy"

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | FSx tự sao lưu hằng ngày | | | Sao lưu cũng chiếm dung lượng tính phí | | | AWS Backup quản lý tập trung được | |

Ba lưu ý về giám sát chủ động: | Lưu ý | Chi tiết | |---|---| | Đặt ngưỡng ở 20-25% còn trống, không phải 5% | | | Cần thời gian cho việc tăng dung lượng | | | Theo dõi xu hướng tăng, không chỉ giá trị hiện tại | |

⚠ Ngưỡng quá sát là vô dụng:

Cảnh báo khi còn 5%
    → tăng dung lượng mất vài phút
      tới vài chục phút
        ↓
    Hồ sơ tiếp tục phình trong lúc đó
    → có thể đầy trước khi xong

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kích hoạt alarm thủ công, xem Lambda có chạy | | | Kiểm dung lượng tăng đúng và không gián đoạn | | | Xem tỷ lệ tiết kiệm sau khi bật deduplication | |

Và một lời khuyên: hãy bật deduplication và đặt hạn ngạch người dùng song song với việc tự động tăng dung lượng. Tự động mở rộng giải quyết triệu chứng rất tốt, nhưng nếu không ai giới hạn được thứ đang phình ra thì hoá đơn lưu trữ cũng tự động tăng theo, mãi mãi.

Câu 226 Domain - Continuous Improvement for Existing Solutions

A company develops cloud-native applications and uses AWS CloudFormation templates for deploying applications in AWS. The application artifacts and templates are stored in an Amazon S3 bucket with versioning enabled. The developers use Amazon EC2 instances that have integrated development (IDE) to download, modify, and re-upload the artifacts on the S3 bucket. The unit testing is done locally on the EC2 instances. The company wants to improve the existing deployment process with a CI/CD pipeline to help the developers be more productive. The following requirements need to be satisfied:

- Utilize GitHub as the code repository for application and CloudFormation templates.

- Have automated testing and security scanning for the generated artifacts.

- Receive a notification when unit testing fails.

- Ability to turn on/off application features and dynamically customize the deployment as part of CI/CD.

- The Lead Developer must approve changes before deploying applications to production.

Which of the following options should the solutions architect implement to meet the company's requirements?

  1. A

    Use AWS CodeArtifact to store generated artifacts. AWS scans the artifacts for common vulnerabilities and allows custom actions to run the unit tests. Create an Amazon CloudWatch rule that will send Amazon SNS alerts when unit testing fails. Use different Docker images for choosing different application features. Add a manual approval stage on the pipeline for the Lead Developer’s approval prior to production deployment.
  2. B

    Create a Jenkins job to run tests and security scans on the generated artifacts. Create an Amazon EventBridge rule that will send Amazon SES alerts when unit testing fails. Use AWS CloudFormation with nested stacks to allow turning on/off of application features. Add an AWS Lambda function to the pipeline to allow approval from the Lead Developer prior to production deployment.
  3. C

    Create an AWS CodeBuild job to run tests and security scans on the generated artifacts. Create an Amazon EventBridge rule that will send Amazon SNS alerts when unit testing fails. Create AWS Cloud Development Kit (AWS CDK) constructs with a manifest file to turn on/off features of the AWS CDK app. Add a manual approval stage on the pipeline for the Lead Developer’s approval prior to production deployment.
  4. D

    Write an AWS Lambda function to run unit tests and security scans on the generated artifacts. Add another Lambda trigger on the next pipeline stage to notify the developers if the unit testing fails. Create AWS Amplify plugins to allow turning on/off of application features. Add an AWS SES action on the pipeline to send an approval message to the Lead Developer prior to production deployment.
Xem giải thích

Đáp án

**C — Tạo một công việc AWS CodeBuild chạy kiểm thử và quét bảo mật trên artifact; tạo quy tắc EventBridge gửi cảnh báo SNS khi kiểm thử đơn vị thất bại; dùng AWS CDK construct với tệp manifest để bật/tắt tính năng của ứng dụng; và thêm giai đoạn duyệt tay cho Lead Developer trước khi triển khai sản xuất.

Vì sao đúng

Đề liệt kê năm yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | GitHub làm kho mã | CodePipeline nối GitHub qua CodeStar Connections | | Kiểm thử và quét bảo mật tự động | CodeBuild | | Thông báo khi kiểm thử thất bại | EventBridge + SNS | | Bật/tắt tính năng, tuỳ chỉnh triển khai | CDK + manifest | | Lead Developer duyệt trước sản xuất | giai đoạn duyệt tay |

⚠ "Manual approval stage" là tính năng có sẵn của CodePipeline:

Không phải viết Lambda hay gửi
  email thủ công
        ↓
    CodePipeline dừng pipeline
    → gửi thông báo SNS
    → chờ người bấm duyệt hoặc từ chối

Cấu hình giai đoạn duyệt:

{"name": "DuyetSanXuat",
 "actions": [{
   "name": "ChoLeadDeveloper",
   "actionTypeId": {"category": "Approval",
                    "owner": "AWS",
                    "provider": "Manual", "version": "1"},
   "configuration": {
     "NotificationArn": "<arn-sns>",
     "CustomData": "Duyet trien khai san xuat",
     "ExternalEntityLink": "<link-bao-cao-kiem-thu>"}}]}

⚠ Đây là lý do phương án B và D sai:

B: dùng Lambda để "cho phép duyệt"
    → tự dựng lại thứ đã có
        ↓
    D: dùng SES gửi thư duyệt
    → không có cơ chế nào dừng
      pipeline chờ trả lời email

⚠ Và CodeBuild là dịch vụ đúng cho kiểm thử, không phải Lambda:

Lambda: tối đa 15 phút, môi trường
  hạn chế
        ↓
    CodeBuild: môi trường build đầy đủ,
      cài được công cụ bất kỳ
    → và tích hợp sẵn vào pipeline

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

Buildspec chạy kiểm thử và quét:

version: 0.2
phases:
  install:
    commands:
      - npm ci
      - pip install cfn-lint checkov
  build:
    commands:
      - npm test
      - npx cdk synth
      - cfn-lint cdk.out/*.template.json
      - checkov -d cdk.out/ --framework cloudformation
reports:
  ket-qua-test:
    files: ['junit.xml']
    file-format: JUNITXML

⚠ Phần reports cho CodeBuild hiểu kết quả kiểm thử:

Không có nó: build chỉ pass hay fail
        ↓
    Có: thấy từng test case, tỷ lệ
      thành công, xu hướng theo thời gian

Cảnh báo khi kiểm thử thất bại:

{"source": ["aws.codebuild"],
 "detail-type": ["CodeBuild Build State Change"],
 "detail": {"build-status": ["FAILED"],
   "project-name": ["kiem-thu-ung-dung"]}}

⚠ Và CDK context với manifest là cách bật/tắt tính năng:

{"context": {
  "tinhNang": {
    "thanhToanMoi": true,
    "goiYSanPham": false}}}

const bat = this.node.tryGetContext('tinhNang');
if (bat.thanhToanMoi) {
  new HamThanhToanMoi(this, 'ThanhToanMoi');
}

⚠ CDK cho phép dùng cấu trúc điều khiển thật:

CloudFormation: `Conditions` với
  cú pháp JSON hạn chế
        ↓
    CDK: `if`, vòng lặp, hàm
    → biểu diễn logic bật/tắt
      phức tạp dễ hơn nhiều

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mọi bước đều dùng dịch vụ có sẵn | | | Không viết mã điều phối nào | | | CDK cho logic bật/tắt tính năng linh hoạt | |

⚠ Nối GitHub bằng CodeStar Connections:

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

Không dùng OAuth token cá nhân
    → kết nối do AWS quản lý
    → thu hồi được tập trung

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

  • **A. Dùng CodeArtifact lưu artifact và cho rằng "AWS quét lỗ hổng và cho chạy custom action để kiểm thử"; dùng CloudWatch rule gửi cảnh báo; dùng Docker image khác nhau để bật/tắt tính năng — đây là phương án gần nhất và có giai đoạn duyệt tay đúng, nhưng CodeArtifact là kho gói phụ thuộc, nó không chạy kiểm thử; và dùng image Docker riêng cho từng tổ hợp tính năng không co giãn.
  • **B. Dùng Jenkins chạy kiểm thử, SES gửi cảnh báo, nested stack để bật/tắt tính năng, và Lambda cho việc duyệt — Jenkins là dịch vụ phải tự vận hành; và Lambda không thay được giai đoạn duyệt tay có sẵn.
  • **D. Dùng Lambda chạy kiểm thử và quét bảo mật, Lambda khác thông báo, Amplify plugin bật/tắt tính năng, và SES gửi thư duyệt — Lambda giới hạn 15 phút và không phải môi trường build; và không có cơ chế dừng pipeline chờ email.

Ghi nhớ

⚠ Sáu dịch vụ trong bộ công cụ phát triển của AWS — 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 lên đích | | CodeArtifact | kho gói phụ thuộc | | CodeCommit | kho mã Git (ngừng nhận khách mới) | | CodeGuru | rà soát mã và hiệu năng |

Từ khoá nhận diện:

"run tests and security scans" → CodeBuild "approval before production" → manual approval stage "store dependency packages" → CodeArtifact "toggle features per deployment" → CDK context hoặc parameter

Ba lưu ý về CodePipeline: | Lưu ý | Chi tiết | |---|---| | Giai đoạn duyệt tay là action có sẵn | | | Nối GitHub qua CodeStar Connections | | | Mỗi giai đoạn có thể có nhiều action song song | |

Ba lưu ý về CodeBuild: | Lưu ý | Chi tiết | |---|---| | Buildspec khai các bước | | | Cache phụ thuộc để build nhanh hơn | | | Chạy trong VPC nếu cần truy cập tài nguyên riêng | |

⚠ Cache giảm mạnh thời gian build:

cache:
  paths:
    - 'node_modules/**/*'
    - '/root/.m2/**/*'

Ba công cụ quét bảo mật trong pipeline: | Công cụ | Quét gì | |---|---| | cfn-lint, cfn-guard | template hạ tầng | | checkov, tfsec | cấu hình sai về bảo mật | | Inspector, ECR scan | lỗ hổng trong image |

Ba lưu ý về CDK: | Lưu ý | Chi tiết | |---|---| | Sinh ra CloudFormation | | | Context và tham số cho cấu hình theo môi trường | | | cdk diff xem trước thay đổi | |

⚠ cdk diff tương đương change set:

cdk diff MoiTruongSanXuat

Hiện rõ tài nguyên nào bị thay thế
    → đọc kỹ trước khi `cdk deploy`

Ba lưu ý về feature flag: | Cách | Đặc điểm | |---|---| | CDK context | quyết định lúc triển khai | | AppConfig | đổi lúc CHẠY, không cần triển khai | | Biến môi trường | đơn giản, phải triển khai lại |

⚠ AWS AppConfig là công cụ chuyên cho feature flag:

Bật tính năng cho 10% người dùng
    → theo dõi chỉ số
    → tự quay lui nếu lỗi tăng
        ↓
    Không phải triển khai lại
      ứng dụng

Ba lưu ý về thông báo: | Lưu ý | Chi tiết | |---|---| | EventBridge bắt sự kiện của mọi dịch vụ Code* | | | SNS gửi email, SMS, Slack qua Chatbot | | | Ghi rõ build nào, commit nào trong thông báo | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy một commit làm hỏng test, xem có cảnh báo | | | Kiểm pipeline dừng ở giai đoạn duyệt | | | Thử bật/tắt một tính năng qua manifest | |

Và một lời khuyên: hãy dùng giai đoạn duyệt tay có sẵn của CodePipeline thay vì tự dựng bằng Lambda hay email. Nó dừng pipeline đúng chỗ, ghi lại ai đã duyệt và lúc nào, và không có trạng thái nào phải tự quản lý — ba thứ mà mọi giải pháp tự viết đều phải làm lại từ đầu.

Câu 227 Domain - Continuous Improvement for Existing Solutions

A company is running its new web application on a test environment in its on-premises data center. The stateful application is running on a single web server and it connects to a MySQL database that is hosted on a separate server. In a few weeks, the web application is scheduled to be released to the general public and the company is worried about its scalability. The user traffic will be unpredictable so it has been decided to migrate the web application and database to AWS. The company wants to use the Amazon EC2 service for hosting the web application, Amazon Aurora for the database, and Elastic Load Balancing for load distribution.

Which of the following solutions will allow the web and database tier to scale along with user traffic?

  1. A

    Create an Amazon Aurora MySQL database instance. Create an Aurora Replica and enable Aurora Auto Scaling for the replica. Create an Auto Scaling group of Amazon EC2 instances placed behind a Network Load Balancer with the least outstanding request (LOR) routing algorithm. Ensure that the sticky sessions feature is enabled for the NLB.
  2. B

    Create an Amazon Aurora MySQL database instance and enable Aurora Auto Scaling for the master database. Create an Auto Scaling group of Amazon EC2 instances placed behind an Application Load Balancer with the round-robin routing algorithm. Ensure that the sticky sessions feature is enabled for the ALB.
  3. C

    Create an Amazon Aurora MySQL database instance and enable Aurora Auto Scaling for the master database. Create an Auto Scaling group of Amazon EC2 instances placed behind a Network Load Balancer with the least outstanding request (LOR) routing algorithm. Ensure that the sticky sessions feature is enabled for the NLB.
  4. D

    Create an Amazon Aurora MySQL database instance. Create an Aurora Replica and enable Aurora Auto Scaling for the replica. Create an Auto Scaling group of Amazon EC2 instances placed behind an Application Load Balancer with the round-robin routing algorithm. Ensure that the sticky sessions feature is enabled for the ALB.
Xem giải thích

Đáp án

**D — Tạo instance Aurora MySQL, tạo Aurora Replica và bật Aurora Auto Scaling cho REPLICA; tạo Auto Scaling group EC2 sau một Application Load Balancer với thuật toán round-robin, và bật sticky session trên ALB.

Vì sao đúng

Đề có hai điểm phải khớp cùng lúc, và chỉ một phương án khớp cả hai: | Điểm | Đúng phải là | |---|---| | Aurora Auto Scaling áp cho | REPLICA, không phải master | | Loại cân bằng tải | ALB (tầng 7, có sticky session) |

⚠ Aurora Auto Scaling chỉ thêm bớt REPLICA — không đụng writer:

Aurora Auto Scaling: thêm reader
  khi tải đọc tăng
        ↓
    KHÔNG có cơ chế nào tự co giãn
      instance writer
    → writer phải đổi cỡ thủ công
      hoặc dùng Aurora Serverless
        ↓
    "Enable Aurora Auto Scaling for
      the master" là thứ không tồn tại

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

Cấu hình Aurora Auto Scaling:

aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --resource-id cluster:cum-ung-dung \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --min-capacity 1 --max-capacity 8

aws application-autoscaling put-scaling-policy \
  --service-namespace rds \
  --resource-id cluster:cum-ung-dung \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --policy-name theo-cpu --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 60.0,
    "PredefinedMetricSpecification":
      {"PredefinedMetricType": "RDSReaderAverageCPUUtilization"}}'

⚠ Chú ý ReadReplicaCount — tên chiều co giãn đã nói rõ:

`rds:cluster:ReadReplicaCount`
    → chỉ có chiều này
    → không có chiều nào cho writer

⚠ Và ứng dụng "stateful" đòi sticky session:

Đề nói ứng dụng có trạng thái
    → phiên người dùng nằm trên
      một instance cụ thể
        ↓
    Không có sticky session
    → mỗi yêu cầu đi tới máy khác
    → mất phiên

Bật sticky session trên ALB:

aws elbv2 modify-target-group-attributes \
  --target-group-arn <arn-tg> \
  --attributes \
    Key=stickiness.enabled,Value=true \
    Key=stickiness.type,Value=lb_cookie \
    Key=stickiness.lb_cookie.duration_seconds,Value=86400

⚠ Nhưng sticky session là giải pháp tình thế, không phải thiết kế đúng:

Instance bị thu hồi
    → người dùng gắn với nó mất phiên
        ↓
    Và tải phân bố lệch: máy cũ
      giữ nhiều phiên, máy mới trống
        ↓
    Đúng ra: lưu phiên trong
      ElastiCache hoặc DynamoDB
    → rồi tắt sticky session

⚠ Và thuật toán định tuyến — đây là điểm dễ nhầm: | Load balancer | Thuật toán có sẵn | |---|---| | ALB | round-robin, least outstanding requests | | NLB | flow hash (không đổi được) |

"Least outstanding request" là
  thuật toán của ALB
        ↓
    Phương án A và C gán nó cho NLB
    → NLB không có tuỳ chọn thuật toán

⚠ Và NLB không phù hợp cho ứng dụng web có phiên:

NLB tầng 4: không đọc HTTP
    → sticky session của nó dựa
      trên IP nguồn
        ↓
    Nhiều người dùng sau cùng một NAT
    → cùng IP → cùng một instance
    → phân bố lệch nghiêm trọng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tầng web co giãn theo lưu lượng | | | Tầng đọc CSDL co giãn theo tải | | | Phiên người dùng không bị mất | |

⚠ Và Aurora còn cho reader endpoint tự cân bằng:

Không phải tự quản danh sách replica
    → ứng dụng gọi reader endpoint
        ↓
    Aurora phân phối qua các replica
      đang có
    → gồm cả replica vừa được
      auto scaling thêm vào

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

  • **A. Tạo Aurora Replica và bật Aurora Auto Scaling cho replica (đúng), nhưng dùng NLB với thuật toán least outstanding request và sticky session trên NLB — đây là phương án gần nhất và phần Aurora hoàn toàn đúng, nhưng NLB không có tuỳ chọn thuật toán định tuyến, và sticky session của NLB dựa trên IP nguồn nên phân bố rất lệch.
  • **B. Bật Aurora Auto Scaling cho MASTER và dùng ALB round-robin với sticky session — Aurora Auto Scaling không áp cho writer.
  • **C. Bật Aurora Auto Scaling cho master và dùng NLB — sai cả hai vế.

Ghi nhớ

⚠ Ba cách co giãn CSDL trên AWS — bảng phải thuộc: | Cách | Co giãn gì | |---|---| | Aurora Auto Scaling | số REPLICA đọc | | Aurora Serverless v2 | công suất của CẢ writer lẫn reader | | Đổi cỡ instance | thủ công, có gián đoạn ngắn |

⚠ Aurora Serverless v2 là câu trả lời khi tải ghi cũng khó đoán:

aws rds create-db-cluster \
  --db-cluster-identifier cum-serverless \
  --engine aurora-mysql \
  --serverlessv2-scaling-configuration \
    MinCapacity=0.5,MaxCapacity=16

Công suất tính bằng ACU, co giãn
  trong vài giây
        ↓
    Áp cho cả writer
    → đây là thứ Aurora Auto Scaling
      không làm được

Từ khoá nhận diện:

"scale read traffic" → Aurora Replica + Auto Scaling "scale write traffic" → Aurora Serverless v2 hoặc đổi cỡ "stateful application" → sticky session, hoặc tốt hơn là phiên ngoài "HTTP routing algorithm" → ALB, không phải NLB

⚠ ALB và NLB — bảng phải thuộc: | Tiêu chí | ALB | NLB | |---|---|---| | Tầng | 7 (HTTP) | 4 (TCP/UDP) | | Thuật toán | round-robin, LOR | flow hash, cố định | | Sticky session | cookie | IP nguồn | | Định tuyến theo đường dẫn | có | không |

Ba lưu ý về sticky session của ALB: | Loại | Đặc điểm | |---|---| | lb_cookie | ALB tự sinh cookie, tối đa 7 ngày | | app_cookie | dùng cookie của chính ứng dụng |

⚠ app_cookie linh hoạt hơn:

ALB theo cookie phiên của ứng dụng
    → phiên hết hạn thì stickiness
      cũng hết
        ↓
    Đồng bộ với vòng đời phiên thật

Ba lưu ý về ứng dụng stateless: | Lưu ý | Chi tiết | |---|---| | Lưu phiên trong ElastiCache hoặc DynamoDB | | | Tắt sticky session sau đó | | | Tải phân bố đều và thu hồi máy không mất gì | |

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | Tới 15 replica | | | Cluster endpoint cho ghi, reader endpoint cho đọc | | | Độ trễ nhân bản thường dưới 100ms | |

⚠ Ứng dụng phải tự định tuyến đọc/ghi:

Gọi cluster endpoint cho mọi thứ
    → replica nằm không, không giúp gì
        ↓
    Phải tách: ghi qua cluster endpoint,
      đọc qua reader endpoint
    → hoặc dùng RDS Proxy

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | health-check-type ELB | | | Trải nhiều AZ | | | Target tracking theo số request mỗi target | |

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-web \
  --policy-name theo-request --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 1000.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "<alb>/<target-group>"}}'

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | AuroraReplicaLag | replica có theo kịp không | | DatabaseConnections | gần trần chưa | | TargetResponseTime | tầng web có chậm không |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tải đọc, xem replica có tự thêm | | | Thu hồi một instance, xem người dùng có mất phiên | | | Kiểm tải phân bố giữa các target | |

Và một lời khuyên: hãy chuyển phiên người dùng ra ngoài instance rồi tắt sticky session. Sticky session giữ ứng dụng stateful chạy được trên nhiều máy, nhưng nó biến mọi lần thu hồi instance thành một nhóm người dùng bị đăng xuất — và với ASG thì thu hồi instance là chuyện xảy ra hằng ngày.

Câu 228 Domain - Design for New Solutions

A multinational investment bank has multiple cloud architectures across the globe. The company has a VPC in the US East region for their East Coast office and another VPC in the US West for their West Coast office. There is a requirement to establish a low latency, high-bandwidth connection between their on-premises data center in Texas and both of their VPCs in AWS.

Which of the following options should the solutions architect implement to achieve the requirement in a cost-effective manner?

  1. A

    Set up two separate VPC peering connections for the two VPCs and for the on-premises data center.
  2. B

    Establish a Direct Connect connection between the VPC in US East region and the on-premises data center in Texas, and then establish another Direct Connect connection between the VPC in US West region and the on-premises data center.
  3. C

    Set up an AWS VPN managed connection between the VPC in US East region and the on-premises data center in Texas.
  4. D

    Set up an AWS Direct Connect Gateway with two virtual private gateways. Launch and connect the required Private Virtual Interfaces to the Direct Connect Gateway.
Xem giải thích

Đáp án

**D — Dựng một AWS Direct Connect Gateway với hai virtual private gateway, rồi tạo và nối các private virtual interface cần thiết vào Direct Connect Gateway đó.

Vì sao đúng

Đề nêu hai yêu cầu, và Direct Connect Gateway giải quyết đúng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Kết nối riêng tới VPC ở HAI Region | DXGW nối một DX tới nhiều VPC xuyên Region | | Tiết kiệm chi phí | MỘT kết nối DX thay vì hai |

⚠ Direct Connect Gateway là dịch vụ TOÀN CẦU:

Một kết nối DX vật lý ở Texas
    → nối vào DXGW
        ↓
    DXGW nối tới VGW của VPC
      ở us-east và us-west
        ↓
    Không cần kéo cáp riêng cho
      từng Region

⚠ Đây là lý do phương án B tốn kém gấp đôi:

Hai kết nối Direct Connect riêng
    → hai lần phí cổng theo giờ
    → hai lần công lắp đặt
    → hai lần thời gian chờ cung cấp
        ↓
    Trong khi một DX + DXGW làm
      được cùng việc

Tạo Direct Connect Gateway:

aws directconnect create-direct-connect-gateway \
  --direct-connect-gateway-name dxgw-cong-ty \
  --amazon-side-asn 64512

Nối VGW của từng VPC:

aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id <id-dxgw> \
  --virtual-gateway-id vgw-us-east

aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id <id-dxgw> \
  --virtual-gateway-id vgw-us-west

Tạo private VIF trỏ tới DXGW:

aws directconnect create-private-virtual-interface \
  --connection-id dxcon-abc \
  --new-private-virtual-interface '{
    "virtualInterfaceName":"vif-toan-cong-ty",
    "vlan":101, "asn":65000,
    "directConnectGatewayId":"<id-dxgw>",
    "addressFamily":"ipv4"}'

⚠ Chú ý: dùng directConnectGatewayId chứ không phải virtualGatewayId:

Nối thẳng VIF vào một VGW
    → chỉ tới được MỘT VPC
        ↓
    Nối vào DXGW
    → tới được mọi VPC đã gắn
      vào gateway đó

⚠ Nhưng DXGW có một hạn chế quan trọng:

Hai VPC cùng gắn vào DXGW
    → cả hai tới được trung tâm
      dữ liệu
        ↓
    Nhưng KHÔNG nói chuyện được
      với nhau qua DXGW
    → cần VPC peering hoặc
      Transit Gateway

⚠ Và VPN (phương án C) không đáp ứng "độ trễ thấp, băng thông cao":

VPN đi qua Internet công cộng
    → độ trễ thay đổi theo tình trạng
      Internet
    → mỗi tunnel tối đa khoảng
      1,25 Gbps
        ↓
    Đề đòi "low latency, high-bandwidth"
    → Direct Connect

⚠ Và VPC peering (phương án A) không nối được với mạng tại chỗ:

Peering nối VPC với VPC
    → trung tâm dữ liệu không phải VPC
        ↓
    Không có cách nào peering với
      mạng tại chỗ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một kết nối vật lý phục vụ nhiều Region | | | Chi phí bằng khoảng một nửa hai DX riêng | | | Thêm VPC mới chỉ cần gắn thêm VGW | |

⚠ Nhưng một DX vẫn là MỘT điểm hỏng:

Cáp đứt hoặc thiết bị hỏng
    → mất kết nối tới cả hai Region
        ↓
    Mẫu chuẩn: DX chính + VPN
      dự phòng
    → hoặc hai DX ở hai vị trí

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

  • **B. Dựng hai kết nối Direct Connect riêng, một tới VPC us-east và một tới VPC us-west — đây là phương án gần nhất và hoàn toàn chạy được, nhưng tốn gấp đôi chi phí và công lắp đặt so với một DX cộng Direct Connect Gateway; đề hỏi cách tiết kiệm chi phí.
  • **C. Dựng VPN quản lý giữa VPC us-east và trung tâm dữ liệu — VPN đi qua Internet nên không đạt "độ trễ thấp, băng thông cao"; và nó chỉ nối một Region.
  • **A. Dựng hai kết nối VPC peering cho hai VPC và cho trung tâm dữ liệu — peering chỉ nối VPC với VPC; không nối được mạng tại chỗ.

Ghi nhớ

⚠ Ba cách nối một DX tới nhiều VPC — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Nhiều private VIF | mỗi VIF một VPC, cùng Region | | Direct Connect Gateway | nhiều VPC, NHIỀU REGION | | Transit VIF + Transit Gateway | nhiều VPC, có bắc cầu giữa chúng |

⚠ DXGW và Transit Gateway — khác biệt cốt lõi: | Tiêu chí | DXGW | Transit VIF + TGW | |---|---|---| | VPC nói chuyện với nhau | KHÔNG | CÓ | | Xuyên Region | có | có (TGW peering) | | Chi phí | DXGW miễn phí | TGW tính phí attachment |

Chỉ cần VPC tới trung tâm dữ liệu
    → DXGW, miễn phí
        ↓
    Cần VPC nói chuyện với nhau nữa
    → Transit Gateway

Từ khoá nhận diện:

"one DX to VPCs in multiple Regions" → Direct Connect Gateway "VPCs must also talk to each other" → Transit Gateway "low latency, high bandwidth, private" → Direct Connect "quick and cheap connection" → Site-to-Site VPN

Ba lưu ý về Direct Connect Gateway: | Lưu ý | Chi tiết | |---|---| | Dịch vụ toàn cầu, không thuộc Region nào | | | Miễn phí, chỉ trả tiền DX và truyền dữ liệu | | | Tối đa 10 VGW mỗi DXGW | |

Ba lưu ý về private VIF: | Lưu ý | Chi tiết | |---|---| | Mỗi VIF một VLAN | | | Nối tới VGW hoặc DXGW | | | Cần BGP với ASN của khách hàng | |

⚠ ASN phải khác nhau giữa hai bên:

`amazon-side-asn` của DXGW
    ≠ ASN phía khách hàng
        ↓
    Trùng nhau: phiên BGP không lên

Ba lưu ý về dự phòng: | Mức | Cấu hình | |---|---| | Tối thiểu | một DX + VPN dự phòng | | Cao | hai DX cùng vị trí | | Tối đa | hai DX ở hai vị trí khác nhau |

⚠ Mẫu DX + VPN dự phòng:

BGP mặc định ưu tiên DX hơn VPN
    → DX đứt: tự chuyển sang VPN
        ↓
    Chậm hơn nhưng không mất
      kết nối

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Kết nối chuyên dụng: 1, 10, 100 Gbps | | | Hosted connection: từ 50 Mbps | | | LAG gộp nhiều kết nối thành một | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | DX KHÔNG mã hoá theo mặc định | | | Chạy VPN qua DX nếu cần | | | Hoặc MACsec với kết nối chuyên dụng | |

⚠ Đây là hiểu nhầm phổ biến:

"Đường riêng nên an toàn"
    → riêng về định tuyến
    → nhưng dữ liệu ở dạng RÕ
        ↓
    Yêu cầu tuân thủ đòi mã hoá
    → phải thêm lớp

Ba lưu ý về chi phí truyền dữ liệu: | Lưu ý | Chi tiết | |---|---| | Truyền ra qua DX rẻ hơn qua Internet | | | Phí cổng theo giờ dù không dùng | | | Truyền dữ liệu tính theo Region đích | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm phiên BGP lên với cả hai VGW | | | ping từ trung tâm dữ liệu tới cả hai VPC | | | Xem tuyến đã lan truyền vào bảng định tuyến | |

Và một lời khuyên: hãy dùng Direct Connect Gateway ngay cả khi hiện tại chỉ có một VPC. Nó miễn phí, không thêm độ trễ, và tránh cho bạn việc phải dựng lại virtual interface khi VPC thứ hai xuất hiện — điều gần như chắc chắn sẽ xảy ra.

Câu 229 Domain - Continuous Improvement for Existing Solutions

A company has a large collection of user-submitted stock photos. An AWS Lambda function processes and extracts metadata from these photos to make a searchable catalog. The metadata is extracted depending on several rules and the output is sent to an Amazon ElastiCache for Redis cluster. The metadata extraction is done in several batches and the whole process takes about 45 minutes to complete. Whenever there is a change in the metadata extraction rules, the update process is triggered manually before the extraction process starts. As the stock photo submissions are steadily growing, the company wants to reduce the metadata extraction time for its catalog.

Which of the following options should the Solutions Architect implement to reduce the time for the metadata extraction process?

  1. A

    Split the single Lambda function that processes the photos into several functions dedicated for each type of metadata. Associate the Lambda functions to an AWS Batch compute environment. Write another Lambda function that will retrieve the list of photos for processing and send each item to the job queue in the AWS Batch compute environment.
  2. B

    Split the single Lambda function that processes the photos into several functions dedicated for each type of metadata. Write another Lambda function that will retrieve the list of photos for processing and send each item to an Amazon SQS queue. Configure all the Lambda extraction functions to subscribe to this SQS queue with higher batch size.
  3. C

    Split the single Lambda function that processes the photos into several functions dedicated for each type of metadata. Create a workflow on AWS Step Functions that will run multiple Lambda functions in parallel. Create another workflow that will retrieve the list of photos for processing and execute the metadata extraction workflow for each photo.
  4. D

    Split the single Lambda function that processes the photos into several functions dedicated for each type of metadata. Create a workflow on AWS Step Functions that will run multiple Lambda functions in parallel. Write another Lambda function that will retrieve the list of photos for processing and send each item to an Amazon SQS queue. Set this SQS queue as the input for the Step Functions workflow.
Xem giải thích

Đáp án

**C — Tách hàm Lambda đơn lẻ thành nhiều hàm, mỗi hàm lo một loại metadata; tạo luồng Step Functions chạy nhiều hàm SONG SONG; và tạo một luồng khác lấy danh sách ảnh rồi thực thi luồng trích xuất cho từng ảnh.

Vì sao đúng

Đề nêu một vấn đề rất cụ thể, và phương án này song song hoá ở hai cấp:

Cấp 1: nhiều loại metadata của
  CÙNG một ảnh chạy song song
        ↓
    Cấp 2: nhiều ẢNH được xử lý
      song song
        ↓
    45 phút giảm xuống còn thời gian
      của loại metadata chậm nhất

⚠ Trạng thái Parallel chạy nhiều nhánh cùng lúc:

{"StartAt": "TrichXuatSongSong",
 "States": {
   "TrichXuatSongSong": {
     "Type": "Parallel",
     "Branches": [
       {"StartAt": "Exif",
        "States": {"Exif": {"Type": "Task",
          "Resource": "<arn-ham-exif>", "End": true}}},
       {"StartAt": "MauSac",
        "States": {"MauSac": {"Type": "Task",
          "Resource": "<arn-ham-mau>", "End": true}}},
       {"StartAt": "NhanDien",
        "States": {"NhanDien": {"Type": "Task",
          "Resource": "<arn-ham-nhan-dien>", "End": true}}}],
     "Next": "GopKetQua"}}}

⚠ Và trạng thái Map xử lý nhiều ảnh song song:

{"XuLyDanhSachAnh": {
  "Type": "Map",
  "ItemsPath": "$.danhSachAnh",
  "MaxConcurrency": 100,
  "Iterator": {
    "StartAt": "GoiLuongTrichXuat",
    "States": {"GoiLuongTrichXuat": {
      "Type": "Task",
      "Resource": "arn:aws:states:::states:startExecution.sync:2",
      "Parameters": {
        "StateMachineArn": "<arn-luong-trich-xuat>",
        "Input": {"anh.$": "$"}},
      "End": true}}},
  "End": true}}

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

{"Type": "Map",
 "ItemProcessor": {
   "ProcessorConfig": {"Mode": "DISTRIBUTED",
                       "ExecutionType": "EXPRESS"}},
 "ItemReader": {
   "Resource": "arn:aws:states:::s3:listObjectsV2",
   "Parameters": {"Bucket": "kho-anh", "Prefix": "chua-xu-ly/"}},
 "MaxConcurrency": 10000}

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

⚠ Vì sao SQS (phương án B và D) không giải quyết được vấn đề:

Hàng đợi phân phối VIỆC
    → nhưng không điều phối
      THỨ TỰ và PHỤ THUỘC
        ↓
    Nhiều hàm cùng đăng ký một
      hàng đợi
    → mỗi thông điệp chỉ MỘT hàm
      nhận được
        ↓
    Không phải "mọi loại metadata
      chạy trên cùng một ảnh"

Đây là lỗi cốt lõi của phương án B.

⚠ Và AWS Batch (phương án A) không nhận Lambda làm job:

Batch chạy job trong CONTAINER
  trên EC2 hoặc Fargate
        ↓
    Không có khái niệm "gắn hàm
      Lambda vào compute environment
      của Batch"

⚠ Và Step Functions thấy được tiến độ — điều quan trọng khi debug:

Chuỗi Lambda gọi nhau
    → không biết ảnh nào đang
      ở bước nào
        ↓
    Step Functions: sơ đồ trực quan
      cho từng lần chạy
    → thấy ngay nhánh nào chậm
      hoặc lỗi

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Song song ở hai cấp, giảm mạnh thời gian | | | Thử lại từng nhánh độc lập | | | Thấy rõ tiến độ và điểm nghẽn | |

⚠ Nhưng phải chú ý giới hạn phía sau:

Song song 10.000 hàm cùng lúc
    → chạm hạn ngạch đồng thời
      của Lambda
        ↓
    Và ElastiCache nhận hàng nghìn
      kết nối cùng lúc
    → đặt `MaxConcurrency` hợp lý

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

  • **D. Tách hàm, tạo luồng Step Functions chạy song song, nhưng dùng Lambda đẩy ảnh vào SQS rồi đặt SQS làm đầu vào của luồng — đây là phương án gần nhất và phần Step Functions song song hoàn toàn đúng, nhưng SQS không kích hoạt Step Functions trực tiếp được; phải có Lambda hoặc EventBridge Pipes ở giữa, và trạng thái Map đã làm được việc phân phối mà không cần hàng đợi.
  • **B. Tách hàm rồi cho mọi hàm cùng đăng ký một hàng đợi SQS với batch size lớn — mỗi thông điệp SQS chỉ được một consumer nhận; không có cách nào để mọi loại metadata cùng chạy trên cùng một ảnh.
  • **A. Gắn các hàm Lambda vào compute environment của AWS Batch — Batch chạy container, không chạy hàm Lambda.

Ghi nhớ

⚠ Ba kiểu song song hoá trên AWS — bảng phải thuộc: | Kiểu | Công cụ | |---|---| | Nhiều bước KHÁC NHAU cùng lúc | Step Functions Parallel | | Cùng một bước trên NHIỀU mục | Step Functions Map | | Nhiều consumer độc lập lấy việc | SQS + nhiều worker |

Từ khoá nhận diện:

"run multiple functions in parallel" → Parallel state "process each item in a list" → Map state "tens of thousands of items" → Distributed Map "one worker per message" → SQS

⚠ Map và Parallel — khác biệt cốt lõi:

`Parallel`: các NHÁNH khác nhau,
  định nghĩa cứng trong máy trạng thái
        ↓
    `Map`: CÙNG một nhánh, chạy
      trên mỗi phần tử của mảng
    → số lần chạy phụ thuộc dữ liệu

Ba lưu ý về Step Functions: | Lưu ý | Chi tiết | |---|---| | Standard: 1 năm, lịch sử đầy đủ, tính theo bước | | | Express: 5 phút, thông lượng cao, tính theo thời gian | | | Tích hợp trực tiếp hơn 200 dịch vụ | |

⚠ Chọn Express cho luồng con trong Distributed Map:

Hàng nghìn lần chạy mỗi phút
    → Standard tính theo bước chuyển
      trạng thái, rất tốn
        ↓
    Express tính theo thời gian và
      bộ nhớ
    → rẻ hơn nhiều ở quy mô này

Ba lưu ý về xử lý lỗi: | Cơ chế | Việc | |---|---| | Retry | thử lại với backoff | | Catch | chuyển sang nhánh lỗi | | ToleratedFailurePercentage | cho phép một tỷ lệ mục thất bại |

⚠ ToleratedFailurePercentage rất hữu ích với xử lý hàng loạt:

{"ToleratedFailurePercentage": 5}

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

Ba lưu ý về giới hạn đồng thời: | Giới hạn | Chi tiết | |---|---| | MaxConcurrency của Map | kiểm soát số nhánh cùng lúc | | Reserved concurrency của Lambda | bảo vệ hàm khác | | Kết nối tới ElastiCache | có trần theo loại node |

Ba lưu ý về ElastiCache làm đích: | Lưu ý | Chi tiết | |---|---| | Redis xử lý lệnh tuần tự trên một luồng | | | Ghi hàng loạt bằng pipeline nhanh hơn nhiều | | | Cân nhắc DynamoDB nếu cần bền vững | |

⚠ Metadata trong cache là quyết định đáng xem lại:

ElastiCache: bộ nhớ tạm
    → mất node là mất danh mục
        ↓
    Metadata đã tốn 45 phút để sinh
    → nên nằm ở nơi bền vững
    → DynamoDB hoặc OpenSearch

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | ExecutionTime | luồng chậm dần không | | ExecutionsFailed | có lỗi không | | Throttles của Lambda | chạm đồng thời chưa |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử trên một lô nhỏ, đo thời gian | | | Xem sơ đồ trực quan tìm nhánh chậm nhất | | | Theo dõi Throttles khi tăng MaxConcurrency | |

Và một lời khuyên: hãy tăng MaxConcurrency dần dần và quan sát các tầng phía sau. Song song hoá dịch chuyển nút thắt chứ không xoá bỏ nó — và nút thắt mới thường là hạn ngạch Lambda hoặc số kết nối tới kho dữ liệu, chứ không phải chính luồng xử lý.

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

A company recently launched its new e-commerce platform that is hosted on its on-premises data center. The web servers connect to a MySQL database. The e-commerce platform is quickly gaining popularity, and the management is worried that the on-premises servers won’t be able to keep up with user traffic in the coming months. They decided to migrate the entire application to AWS to take advantage of the scalability of the cloud. The following are required for this migration:

- Improve the security of the application.

- Increase the reliability and availability of the application.

- Reduce the latency between the users and the application.

- Reduce the maintenance overhead after the migration to the cloud.

Which combination of options should the Solutions Architect implement to meet the company's requirements? (Select TWO.)

  1. A

    Create an Auto Scaling of Amazon EC2 instances spread in two Availability Zones to host the web servers. To reduce the latency when serving content, create an AWS Global Accelerator endpoint. Migrate the database to an Amazon RDS MySQL instance.
  2. B

    Create an Auto Scaling of Amazon EC2 instances spread in two Availability Zones to host the web servers and the highly available MySQL database cluster in a master and slave configuration.
  3. C

    Create an Amazon S3 bucket to store and host the static contents. To reduce the latency when serving content, set this bucket as the origin for an Amazon CloudFront distribution. Create AWS WAF rules to block common web exploits.
  4. D

    Create an Amazon S3 bucket to store the static contents and enable website hosting. To reduce the latency when serving content, enable S3 Transfer Acceleration. Create AWS WAF rules to block common web exploits.
  5. E

    Create an Auto Scaling of Amazon EC2 instances spread in two Availability Zones to host the web servers. Use an Amazon RDS for MySQL with Multi-AZ enabled as the database.
Xem giải thích

Đáp án

**C và E — Tạo bucket S3 lưu nội dung tĩnh, đặt làm origin cho CloudFront, và tạo luật WAF chặn các lỗ hổng web phổ biến; đồng thời tạo Auto Scaling group EC2 trải hai vùng sẵn sàng cho máy chủ web, dùng RDS for MySQL có Multi-AZ làm CSDL.

Vì sao đúng

Đề nêu bốn yêu cầu, và hai đáp án cùng nhau phủ đủ: | Yêu cầu | Đáp án | |---|---| | Tăng bảo mật | WAF (C) | | Tăng độ tin cậy và sẵn sàng | ASG nhiều AZ + Multi-AZ (E) | | Giảm độ trễ cho người dùng | CloudFront (C) | | Giảm công vận hành sau khi di chuyển | RDS quản lý (E) |

⚠ Điểm phân biệt giữa C và D là cách phục vụ nội dung tĩnh: | Cách | Tác dụng | |---|---| | S3 + CloudFront (C) | cache ở biên toàn cầu, GIẢM độ trễ tải về | | S3 + Transfer Acceleration (D) | tăng tốc TẢI LÊN, không phải tải về |

Transfer Acceleration tối ưu cho
  việc TẢI LÊN từ xa
        ↓
    Người mua hàng TẢI VỀ nội dung
    → CloudFront mới đúng

⚠ Và điểm phân biệt giữa E và A là cách giảm độ trễ: | Cách | Phù hợp với | |---|---| | CloudFront | HTTP/HTTPS, có cache | | Global Accelerator | TCP/UDP, IP tĩnh, KHÔNG cache |

Trang thương mại điện tử: nội dung
  tĩnh chiếm phần lớn lưu lượng
        ↓
    CloudFront cache được chúng
    → Global Accelerator không cache
      gì cả
        ↓
    Với web thì CloudFront hiệu quả
      hơn nhiều

⚠ Và phương án B giữ nguyên gánh nặng vận hành:

"MySQL cluster tự quản lý theo
  cấu hình master-slave"
        ↓
    Phải tự vá, tự sao lưu, tự
      viết cơ chế chuyển đổi
    → trái với yêu cầu "giảm công
      bảo trì sau khi di chuyển"

Bật Multi-AZ:

aws rds create-db-instance \
  --db-instance-identifier csdl-thuong-mai \
  --db-instance-class db.r6g.large \
  --engine mysql --multi-az \
  --backup-retention-period 7 \
  --storage-encrypted

⚠ Multi-AZ cho ba thứ cùng lúc:

1. Nhân bản ĐỒNG BỘ — RPO bằng 0
        ↓
2. Chuyển đổi tự động trong 1-2 phút
        ↓
3. Vá lỗi không gián đoạn dài
   (vá bản dự phòng trước rồi chuyển)

CloudFront với hai origin:

{"Origins": {"Items": [
  {"Id": "s3-tinh", "DomainName": "tinh.s3.ap-southeast-1.amazonaws.com",
   "S3OriginConfig": {"OriginAccessIdentity": ""},
   "OriginAccessControlId": "<id-oac>"},
  {"Id": "alb-dong", "DomainName": "<dns-alb>",
   "CustomOriginConfig": {"OriginProtocolPolicy": "https-only"}}]},
 "CacheBehaviors": {"Items": [
   {"PathPattern": "/tinh/*", "TargetOriginId": "s3-tinh",
    "CachePolicyId": "<ttl-dai>"}]},
 "DefaultCacheBehavior": {"TargetOriginId": "alb-dong"}}

Luật WAF:

aws wafv2 create-web-acl --name bao-ve-thuong-mai \
  --scope CLOUDFRONT --default-action Allow={} \
  --rules '[{"Name":"OWASP","Priority":1,
    "Statement":{"ManagedRuleGroupStatement":{
      "VendorName":"AWS","Name":"AWSManagedRulesCommonRuleSet"}},
    "OverrideAction":{"Count":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"owasp"}}]'

⚠ Bắt đầu bằng Count rồi mới chuyển sang Block:

Bật chặn ngay
    → luật quản lý chặn nhầm
      lưu lượng hợp lệ
        ↓
    Với trang bán hàng: chặn nhầm
      = mất doanh thu
    → chạy Count vài ngày, đọc log

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nội dung tĩnh phục vụ từ điểm gần người dùng | | | Chịu được mất một AZ ở cả hai tầng | | | AWS lo vá lỗi và sao lưu CSDL | |

⚠ Và OAC giữ bucket riêng tư:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::noi-dung-tinh/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "<arn-phan-phoi>"}}}

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

  • **A. ASG trải hai AZ cho máy chủ web, dùng Global Accelerator giảm độ trễ, và chuyển CSDL sang RDS MySQL — đây là phương án gần nhất và phần ASG cùng RDS hoàn toàn đúng, nhưng Global Accelerator không cache nội dung; với trang thương mại điện tử có nhiều ảnh sản phẩm thì CloudFront hiệu quả hơn nhiều. Và nó thiếu Multi-AZ.
  • **D. S3 lưu nội dung tĩnh với website hosting và bật Transfer Acceleration — Transfer Acceleration tăng tốc tải lên, không giúp gì cho người dùng tải về.
  • **B. ASG trải hai AZ cho cả máy chủ web lẫn cụm MySQL tự quản lý master-slave — giữ nguyên gánh nặng vận hành CSDL, trái với yêu cầu.

Ghi nhớ

⚠ Bốn cách giảm độ trễ — bảng phải thuộc: | Cách | Phù hợp với | |---|---| | CloudFront | HTTP, có cache, nội dung tĩnh nhiều | | Global Accelerator | TCP/UDP, IP tĩnh, không cache | | Multi-Region | cả ứng dụng ở gần người dùng | | ElastiCache | giảm truy vấn CSDL lặp lại |

Từ khoá nhận diện:

"reduce latency for content" → CloudFront "faster uploads from far away" → S3 Transfer Acceleration "static IP, non-HTTP" → Global Accelerator "reduce maintenance overhead" → dịch vụ quản lý |

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

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 | | | Chi phí gấp đôi | |

⚠ Multi-AZ không phải read replica:

Cần chia tải đọc
    → thêm read replica
        ↓
    Multi-AZ chỉ để sẵn sàng cao
    → hai thứ khác nhau, dùng cả hai
      nếu cần cả hai

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | Trải ít nhất hai AZ, nên ba | | | ALB phải gắn đủ AZ mà ASG dùng | | | health-check-type ELB | |

Ba lưu ý về WAF: | Lưu ý | Chi tiết | |---|---| | Gắn vào CloudFront cho lưu lượng toàn cầu | | | Scope CLOUDFRONT phải tạo ở us-east-1 | | | Bật logging để tinh chỉnh luật | |

Ba lưu ý về tách nội dung tĩnh: | Lưu ý | Chi tiết | |---|---| | Ảnh sản phẩm chiếm phần lớn dung lượng trang | | | Đưa lên S3 giảm mạnh tải cho EC2 | | | TTL dài với tệp có mã băm trong tên | |

⚠ Đây là biện pháp có tác dụng lớn nhất:

EC2 vừa chạy logic vừa phục vụ ảnh
    → phần lớn CPU tiêu vào việc
      mà S3 làm tốt hơn
        ↓
    Tách ra: EC2 chỉ lo phần động

Ba lưu ý về di chuyển CSDL: | Lưu ý | Chi tiết | |---|---| | DMS với full-load-and-cdc để ít gián đoạn | | | Kiểm thử kỹ trước khi cắt chuyển | | | Giữ đường lui trong vài ngày đầu | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | CSDL trong subnet riêng tư | | | Security group tham chiếu SG khác | | | Bật mã hoá khi lưu cho RDS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian tải trang từ nhiều châu lục | | | Buộc chuyển đổi Multi-AZ và bấm giờ | | | Gửi payload thử — WAF phải chặn | |

Và một lời khuyên: hãy tách nội dung tĩnh ra S3 trước khi làm bất cứ tối ưu nào khác. Với trang thương mại điện tử, ảnh sản phẩm thường chiếm hơn 80% dung lượng mỗi trang — và chuyển chúng sang S3 với CloudFront giải quyết cùng lúc cả độ trễ lẫn tải cho máy chủ ứng dụng.