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

Tìm thấy 1221 câu.

Câu 171 Domain - Continuous Improvement for Existing Solutions

A company recently developed a web application that processes customer behavioral data and stores the results in a DynamoDB table. The application is expected to receive a high usage load. To ensure that data is not lost when DynamoDB write requests are throttled, the solutions architect must reduce the load taken by the table.

Which of the following is the MOST cost-effective strategy for reducing the load on the DynamoDB table?

  1. A

    Provision more DynamoDB tables to absorb the load.
  2. B

    Provision higher write-capacity units (WCUs) to your DynamoDB table.
  3. C

    Use an SQS queue to decouple messages from the application and the database.
  4. D

    Replicate the DynamoDB table to another AWS region using global tables.
Xem giải thích

Đáp án

**C — Dùng hàng đợi SQS để tách rời thông điệp giữa ứng dụng và cơ sở dữ liệu.

Vì sao đúng

Đề nêu hai yêu cầu, và SQS là lựa chọn duy nhất thoả cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Không mất dữ liệu khi ghi bị chặn | thông điệp nằm trong hàng đợi tới 14 ngày | | Rẻ nhất | SQS rẻ hơn nhiều so với tăng WCU thường trực |

⚠ Đây là mẫu "làm phẳng đỉnh tải" (queue-based load levelling):

Không có hàng đợi: đỉnh tải đập
  thẳng vào DynamoDB
    → vượt WCU → bị chặn → MẤT dữ liệu
        ↓
    Có hàng đợi: thông điệp xếp hàng
    → consumer ghi vào DynamoDB
      theo tốc độ ổn định
    → đỉnh được san phẳng theo thời gian

⚠ Và điều quan trọng nhất: bị chặn KHÔNG còn nghĩa là mất dữ liệu:

Consumer ghi thất bại vì bị chặn
    → không xoá thông điệp khỏi hàng đợi
        ↓
    Visibility timeout hết
    → thông điệp hiện lại
    → thử lại sau

Consumer có xử lý thử lại:

import boto3, time
from botocore.exceptions import ClientError

dynamodb = boto3.resource('dynamodb')
bang = dynamodb.Table('HanhViKhachHang')

def xu_ly(thong_diep):
    try:
        bang.put_item(Item=doc_du_lieu(thong_diep))
        return True
    except ClientError as e:
        if e.response['Error']['Code'] == \
           'ProvisionedThroughputExceededException':
            return False   # khong xoa, se thu lai
        raise

⚠ Vì sao tăng WCU (phương án B) không phải câu trả lời "rẻ nhất":

Đỉnh tải chỉ vài giờ mỗi ngày
    → tăng WCU phải giữ mức đó 24/7
        ↓
    Trả tiền công suất đỉnh suốt ngày
    → trong khi hàng đợi cho phép
      giữ WCU ở mức trung bình

⚠ Và Auto Scaling của DynamoDB phản ứng quá chậm cho đỉnh ngắn:

Đỉnh tải đột ngột trong 5 phút
    → Auto Scaling mất vài phút
      để tăng công suất
        ↓
    Đỉnh đã qua trước khi kịp tăng
    → vẫn bị chặn

Cấu hình hàng đợi:

aws sqs create-queue --queue-name hang-doi-hanh-vi \
  --attributes '{
    "VisibilityTimeout":"300",
    "MessageRetentionPeriod":"1209600",
    "ReceiveMessageWaitTimeSeconds":"20",
    "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"5\"}"}'

⚠ Ba thuộc tính quan trọng: | Thuộc tính | Ý nghĩa | |---|---| | MessageRetentionPeriod: 1209600 | giữ 14 ngày — biên an toàn rất rộng | | ReceiveMessageWaitTimeSeconds: 20 | long polling, giảm chi phí lời gọi | | RedrivePolicy | thông điệp hỏng sang DLQ sau 5 lần |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không mất dữ liệu khi bị chặn | | | Giữ WCU ở mức trung bình, rẻ hơn nhiều | | | Tách rời hai tầng, hỏng một bên không lan | |

⚠ Và ghi theo lô còn hiệu quả hơn:

with bang.batch_writer() as bo_ghi:
    for tin in danh_sach_tin:
        bo_ghi.put_item(Item=doc_du_lieu(tin))

`BatchWriteItem` gom 25 mục một lời gọi
    → ít lời gọi API hơn nhiều
        ↓
    Nhưng KHÔNG giảm WCU tiêu thụ
    → WCU tính theo số mục và kích thước

⚠ Nhưng phải kiểm tra phân bố khoá phân vùng trước:

Tổng WCU rất lớn mà vẫn bị chặn
    → dấu hiệu PHÂN VÙNG NÓNG
        ↓
    WCU chia đều cho các phân vùng
    → khoá lệch làm một phân vùng
      nhận hết tải
        ↓
    Hàng đợi không sửa được lỗi này

aws dynamodb update-contributor-insights \
  --table-name HanhViKhachHang \
  --contributor-insights-action ENABLE

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

  • **B. Cấp WCU cao hơn cho bảng — đây là phương án gần nhất và thật sự giải quyết được việc bị chặn, nhưng nó bắt trả tiền công suất đỉnh suốt 24/7; đề hỏi cách rẻ nhất.
  • **A. Cấp thêm nhiều bảng DynamoDB để chia tải — chia dữ liệu ra nhiều bảng làm ứng dụng phức tạp hơn hẳn, và không giải quyết được việc mất dữ liệu khi bị chặn.
  • **D. Nhân bản bảng sang Region khác bằng global table — global table dành cho sẵn sàng đa Region; nó làm tăng lượng ghi (mỗi ghi được nhân bản) chứ không giảm tải.

Ghi nhớ

⚠ Bốn cách xử lý việc bị chặn ở DynamoDB — bảng phải thuộc: | Cách | Đánh giá | |---|---| | Hàng đợi ở giữa | rẻ nhất, không mất dữ liệu | | Chuyển sang on-demand | đơn giản, đắt hơn mỗi đơn vị | | Tăng WCU thường trực | đắt nhất | | Auto Scaling | phản ứng chậm với đỉnh ngắn |

Từ khoá nhận diện:

"data must not be lost when throttled" → SQS "most cost-effective" → hàng đợi thay vì tăng công suất "unpredictable spikes" → on-demand hoặc hàng đợi "hot partition" → thiết kế lại khoá phân vùng

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í và độ trễ | | | Luôn có dead-letter queue | |

⚠ Visibility timeout đặt sai gây xử lý trùng:

Xử lý mất 5 phút, timeout 30 giây
    → thông điệp hiện lại sau 30 giây
        ↓
    Consumer khác xử lý CÙNG việc
    → ghi trùng vào DynamoDB

Ba lưu ý về xử lý idempotent: | Lưu ý | Chi tiết | |---|---| | SQS Standard có thể giao hơn một lần | | | Dùng khoá xác định khi ghi | | | Hoặc ConditionExpression chống ghi trùng | |

bang.put_item(
    Item=du_lieu,
    ConditionExpression='attribute_not_exists(idSuKien)')

Ba lưu ý về WCU: | Lưu ý | Chi tiết | |---|---| | 1 WCU = 1 KB mỗi giây | | | Mục 3 KB tốn 3 WCU | | | Ghi giao dịch tốn gấp đôi | |

Ba lưu ý về khoá phân vùng: | Lưu ý | Chi tiết | |---|---| | Chọn khoá có độ phân tán cao | | | Tránh khoá theo ngày hoặc trạng thái | | | Contributor Insights tìm phân vùng nóng | |

⚠ Ví dụ khoá tệ và khoá tốt:

Khoá = ngày ("2026-08-31")
    → mọi ghi trong ngày vào một phân vùng
        ↓
    Khoá = idNguoiDung
    → phân tán qua hàng triệu giá trị

Ba lưu ý về Lambda làm consumer: | Lưu ý | Chi tiết | |---|---| | SQS gọi Lambda trực tiếp | | | MaximumConcurrency giới hạn tốc độ ghi | | | Đây là cách điều tiết tải vào DynamoDB | |

aws lambda update-event-source-mapping --uuid <id> \
  --scaling-config MaximumConcurrency=20

⚠ Đây là cơ chế điều tiết rất gọn:

Giới hạn 20 Lambda đồng thời
    → tốc độ ghi vào DynamoDB
      bị chặn ở mức biết trước
        ↓
    Không bao giờ vượt WCU đã cấp
    → hàng đợi hấp thụ phần dư

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | ApproximateAgeOfOldestMessage | tăng đều — consumer không kịp | | WriteThrottleEvents | lớn hơn 0 | | Độ sâu DLQ | lớn hơn 0 |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy đỉnh tải, xem hàng đợi có dồn không | | | Kiểm không còn WriteThrottleEvents | | | Xem DLQ có thông điệp lạ không | |

Và một lời khuyên: hãy kiểm tra phân bố khoá phân vùng trước khi kết luận rằng vấn đề là thiếu công suất. Hàng đợi giải quyết được đỉnh tải nhưng không sửa được phân vùng nóng — và với phân vùng nóng thì tăng bao nhiêu WCU cũng vẫn bị chặn.

Câu 172 Domain - Design for New Solutions

A company has a large Microsoft Windows Server running on a public subnet. There are EC2 instances hosted on a private subnet that allows Remote Desktop Protocol (RDP) connections to the Windows Server via port 3389. These instances enable the Microsoft Administrators to connect to the public servers and troubleshoot any server failures.

The server must always have the latest operating system upgrades to improve security and it must be accessible at any given point in time. The administrators are tasked to refactor the existing solution and manage the server patching activities effectively, even outside the regular maintenance window.

Which of the following provides the LEAST amount of administrative overhead in managing the server?

  1. A

    Launch a hardened machine image from the AWS Marketplace and host the server using AWS CloudShell. Set up the AWS Systems Manager Patch Manager to automatically apply system updates. Use Amazon AppStream 2.0 to act as a bastion host.
  2. B

    Launch the Windows Server on Amazon EC2 instances. Use AWS Systems Manager Patch Manager to manage the patching process for the server. Configure it to automatically apply patches as they become available, ensuring that the server is always up-to-date with the latest operating system upgrades.
  3. C

    Launch an AWS AppSync environment with a single EC2 instance that runs the Windows Server. Set up the environment with a custom AMI to utilize a hardened machine image that can be downloaded from AWS Marketplace. Configure the AWS Systems Manager Patch Manager to automatically apply the OS updates.
  4. D

    Launch the server in Amazon Lightsail with the recommended Amazon AMI. Set up a combination of Amazon EventBridge and AWS Lambda scheduled event to call the Upgrade Operating System API in Amazon Lightsail to apply system updates.
Xem giải thích

Đáp án

**B — Chạy Windows Server trên Amazon EC2, dùng AWS Systems Manager Patch Manager quản lý quy trình vá, cấu hình để tự động áp bản vá khi có, bảo đảm máy chủ luôn cập nhật.

Vì sao đúng

Đề hỏi cách có ít công sức quản trị nhất, và phương án này là phương án duy nhất chỉ dùng dịch vụ đúng vai trò: | Yêu cầu | Cách đáp ứng | |---|---| | Windows Server luôn có bản vá mới nhất | Patch Manager | | Vá được cả ngoài cửa sổ bảo trì thường lệ | Run Command chạy bất kỳ lúc nào | | Ít công sức nhất | dịch vụ quản lý, không tự viết gì |

⚠ Ba phương án còn lại đều ghép sai dịch vụ — đây là dạng câu hỏi kiểm tra sự tỉnh táo: | Phương án | Dịch vụ bị dùng sai | |---|---| | A | CloudShell (shell trên trình duyệt) không "host" máy chủ nào | | C | AppSync (GraphQL API) không phải môi trường chạy EC2 | | D | Lightsail có tự động hoá riêng, không cần Lambda gọi API |

Baseline cho Windows:

aws ssm create-patch-baseline \
  --name baseline-windows \
  --operating-system WINDOWS \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=PRODUCT,Values=[WindowsServer2022]},
      {Key=CLASSIFICATION,Values=[SecurityUpdates,CriticalUpdates]},
      {Key=MSRC_SEVERITY,Values=[Critical,Important]}]},
    ApproveAfterDays=3, ComplianceLevel=CRITICAL}]'

⚠ Bộ lọc của Windows khác Linux: | Khoá lọc | Windows | Linux | |---|---|---| | PRODUCT | WindowsServer2022 | AmazonLinux2 | | Mức độ | MSRC_SEVERITY | SEVERITY | | Phân loại | SecurityUpdates, CriticalUpdates | Security, Bugfix |

Vá ngoài cửa sổ bảo trì:

aws ssm send-command \
  --document-name "AWS-RunPatchBaseline" \
  --targets Key=tag:Vaitro,Values=WindowsQuanTri \
  --parameters 'Operation=Install,RebootOption=RebootIfNeeded'

⚠ RebootOption là tham số phải cân nhắc với Windows: | Giá trị | Hành vi | |---|---| | RebootIfNeeded | tự khởi động lại nếu bản vá đòi | | NoReboot | cài nhưng không khởi động lại |

Windows rất hay đòi khởi động lại
    → `NoReboot`: bản vá cài rồi nhưng
      chưa có hiệu lực
        ↓
    Máy vẫn dễ tổn thương cho tới lúc
      khởi động lại
    → nhớ có kế hoạch khởi động lại

⚠ Và đề nói máy phải "truy cập được mọi lúc" — cần dự phòng:

Một máy Windows duy nhất
    → khởi động lại vì bản vá
    → quản trị viên mất đường vào
        ↓
    Muốn thật sự sẵn sàng cao
    → hai máy sau NLB
    → hoặc chấp nhận gián đoạn ngắn

⚠ Và bastion host nay có lựa chọn tốt hơn:

Đề mô tả một máy Windows public làm
  đường vào cho quản trị viên
        ↓
    Fleet Manager Remote Desktop:
      RDP qua Systems Manager
    → KHÔNG cần IP công khai
    → không cần mở cổng 3389

aws ssm start-session --target i-abc \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3389"],"localPortNumber":["13389"]}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải tự viết cơ chế vá nào | | | Có báo cáo tuân thủ sẵn | | | Vá được bất kỳ lúc nào bằng Run Command | |

Ba điều kiện tiên quyết của SSM: | Điều kiện | Chi tiết | |---|---| | SSM Agent chạy (AMI Windows của AWS có sẵn) | | | Instance profile có AmazonSSMManagedInstanceCore | | | Có đường tới endpoint SSM | |

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

  • **A. Dùng AMI đã gia cố từ Marketplace và host máy chủ bằng AWS CloudShell, dùng Patch Manager, và AppStream 2.0 làm bastion — đây là phương án gần nhất và có Patch Manager đúng, nhưng CloudShell là shell chạy trong trình duyệt để gõ lệnh CLI, nó không chạy được máy chủ nào.
  • **C. Dựng môi trường AWS AppSync với một EC2 chạy Windows Server — AppSync là dịch vụ GraphQL API quản lý, nó không phải nơi chạy EC2.
  • **D. Chạy trên Lightsail và dùng EventBridge + Lambda gọi API "Upgrade Operating System" — Lightsail không có API nào tên như vậy; và tự viết Lambda là nhiều việc hơn Patch Manager.

Ghi nhớ

⚠ Bốn dịch vụ bị dùng sai vai trò trong câu này — nhớ đúng chức năng: | Dịch vụ | Vai trò thật | |---|---| | CloudShell | shell CLI trong trình duyệt | | AppSync | GraphQL API quản lý | | AppStream 2.0 | stream ứng dụng desktop cho người dùng | | Lightsail | VPS đơn giản, giá cố định |

Từ khoá nhận diện:

"patch Windows automatically" → Patch Manager "RDP without public IP" → Fleet Manager hoặc Session Manager port forwarding "least administrative overhead" → dịch vụ quản lý, không tự viết "golden image approach" → EC2 Image Builder

Ba lưu ý về vá Windows: | Lưu ý | Chi tiết | |---|---| | Hay đòi khởi động lại | | | Patch Tuesday: bản vá ra thứ ba tuần hai | | | Kiểm thử ở môi trường thấp trước | |

⚠ Lịch Patch Tuesday nên đưa vào cửa sổ bảo trì:

Microsoft phát hành bản vá tháng
  vào thứ ba tuần thứ hai
        ↓
    Đặt cửa sổ bảo trì vào cuối tuần
      sau đó
    → có vài ngày để cộng đồng
      phát hiện bản vá hỏng

Ba lưu ý về Session Manager: | Lưu ý | Chi tiết | |---|---| | Không cần cổng 22 hay 3389 mở | | | Không cần bastion host | | | Ghi log mọi phiên vào S3 hoặc CloudWatch | |

⚠ Đây là cách thay thế bastion host hoàn toàn:

Bastion: máy công khai, phải vá,
  phải giám sát, là mục tiêu tấn công
        ↓
    Session Manager: không có máy nào
    → và mọi phiên đều ghi log được

Ba lưu ý về EC2 Image Builder: | Lưu ý | Chi tiết | |---|---| | Dựng AMI đã vá theo lịch | | | Có bước kiểm thử tự động | | | Phân phối sang nhiều Region và tài khoản | |

Ba lưu ý về sẵn sàng cao cho Windows: | Lưu ý | Chi tiết | |---|---| | Một máy là một điểm hỏng | | | Đặt trong ASG dù chỉ một instance | | | ASG tự thay khi máy hỏng | |

⚠ ASG với min=max=1 vẫn có giá trị:

Máy hỏng hoặc AZ sập
    → ASG tạo lại ở AZ khác
        ↓
    Không có sẵn sàng cao thật
    → nhưng khôi phục tự động

Ba lưu ý về Fleet Manager: | Lưu ý | Chi tiết | |---|---| | RDP và xem hệ thống tệp qua trình duyệt | | | Xem registry và log của Windows | | | Không cần cài công cụ nào | |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Config rule kiểm trạng thái vá | | | Báo cáo tuân thủ trong Systems Manager | | | Cảnh báo khi có máy không tuân thủ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem báo cáo tuân thủ sau một lần vá | | | Kiểm bản vá thật sự cài trên máy | | | Thử RDP qua Fleet Manager | |

Và một lời khuyên: hãy bỏ hẳn bastion host công khai và dùng Session Manager. Một máy Windows mở cổng 3389 ra Internet là mục tiêu bị dò mật khẩu liên tục — còn Session Manager không có cổng nào để dò, và ghi lại mọi phiên làm việc.

Câu 173 Domain - Continuous Improvement for Existing Solutions

A company has a gaming store platform hosted in its on-premises data center for a whole variety of digital games. The application just experienced downtime last week due to a large burst in web traffic caused by a year-end sale on almost all of the games. Due to the success of the previous promotion, the CEO has planned to do the same in a few weeks, which will drive similar unpredictable bursts in web traffic. The solutions architects are looking to find ways to quickly improve the infrastructure's ability to handle unexpected increases in traffic. The web application is currently made up of a 2-tier web tier which consists of a load balancer and several web app servers, as well as a database tier that hosts an Oracle database.

Which of the following infrastructure changes should the team implement to avoid any further incidences of downtime considering that the new announcement will be done in a few weeks?

  1. A Migrate your environment to AWS by using AWS VM Import to quickly convert your web server into an AMI. Then set up an Auto Scaling group that uses the imported AMI. Also, create an RDS read replica and migrate the Oracle database to an RDS instance through replication.
  2. B Set up an Amazon S3 bucket for website hosting. Migrate your DNS to Route 53 using zone import, and use DNS failover to failover to the hosted website in S3.
  3. C

    Create an AMI that can be used to launch new EC2 web servers. Then create an Auto Scaling group which will use the AMI to scale the web tier. Finally, place an Application Load Balancer to distribute traffic between your on-premises servers and servers running in AWS.
  4. D

    Set up a CloudFront distribution to cache objects from a custom origin to offload traffic from your on-premises environment. Customize your object cache behavior, and choose a time-to-live that will determine how long objects will reside in the cache.
Xem giải thích

Đáp án

**D — Dựng phân phối CloudFront cache nội dung từ một custom origin để giảm tải cho hệ thống tại chỗ; tuỳ chỉnh hành vi cache và chọn thời gian sống (TTL) quyết định object nằm trong cache bao lâu.

Vì sao đúng

Đề có một ràng buộc thời gian rất chặt, và nó loại phần lớn phương án:

Đợt khuyến mãi diễn ra
  "trong vài tuần nữa"
        ↓
    Di chuyển hệ thống lên AWS
    → hàng tháng công sức, rủi ro cao
        ↓
    Đặt CloudFront trước hệ thống
      hiện có
    → làm được trong vài ngày

⚠ Custom origin cho phép CloudFront trỏ thẳng tới máy chủ tại chỗ:

Origin không nhất thiết phải là
  tài nguyên AWS
        ↓
    Bất kỳ endpoint HTTP/HTTPS công khai
      nào cũng làm origin được
    → kể cả trung tâm dữ liệu của bạn

Cấu hình custom origin:

{"Origins": {"Items": [{
  "Id": "may-chu-tai-cho",
  "DomainName": "goc.congty.com",
  "CustomOriginConfig": {
    "HTTPPort": 80, "HTTPSPort": 443,
    "OriginProtocolPolicy": "https-only",
    "OriginReadTimeout": 30,
    "OriginKeepaliveTimeout": 5}}]}}

⚠ Và CloudFront giúp cả ba mặt cùng lúc:

1. CACHE: nội dung tĩnh phục vụ từ biên
   → phần lớn lưu lượng không chạm origin
        ↓
2. TLS ở biên: bắt tay gần người dùng
   → nhanh hơn nhiều
        ↓
3. Kết nối giữ mở tới origin
   → giảm số kết nối mới phải mở

⚠ Điểm thứ ba giúp cả nội dung KHÔNG cache được:

Trang giỏ hàng, trang thanh toán
    → không cache được
        ↓
    Nhưng vẫn đi qua mạng xương sống
      AWS và dùng kết nối đã mở sẵn
    → nhanh hơn Internet công cộng

Cache behavior theo loại nội dung:

{"CacheBehaviors": {"Items": [
  {"PathPattern": "/anh/*", "TargetOriginId": "may-chu-tai-cho",
   "CachePolicyId": "<tinh-ttl-dai>"},
  {"PathPattern": "/gio-hang/*", "TargetOriginId": "may-chu-tai-cho",
   "CachePolicyId": "<khong-cache>"}]}}

⚠ TTL dài cho nội dung tĩnh là chỗ giảm tải lớn nhất:

Ảnh sản phẩm, CSS, JavaScript
    → chiếm phần lớn số yêu cầu
    → gần như không đổi
        ↓
    TTL một năm + mã băm trong tên tệp
    → origin gần như không nhận
      yêu cầu nào cho chúng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Triển khai trong vài ngày, kịp đợt khuyến mãi | | | Không đụng vào hệ thống hiện có | | | Hấp thụ được đỉnh tải bất thường | |

⚠ Và CloudFront còn là lớp chống DDoS miễn phí:

Shield Standard tự động bảo vệ
  mọi phân phối CloudFront
        ↓
    Đỉnh tải bất thường bị phân tán
      qua hàng trăm điểm biên
    → thay vì tập trung vào một
      đường truyền tại chỗ

⚠ Nhưng phải nhớ giới hạn: CSDL vẫn là nút thắt:

CloudFront giảm tải cho tầng WEB
    → nhưng trang động vẫn gọi CSDL
        ↓
    Oracle tại chỗ vẫn có thể quá tải
    → cân nhắc thêm cache ứng dụng
      hoặc read replica

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

  • **A. Di chuyển sang AWS bằng VM Import chuyển máy chủ web thành AMI, dựng ASG, và di chuyển Oracle sang RDS bằng nhân bản — đây là phương án gần nhất và là hướng đi đúng về lâu dài, nhưng di chuyển cả hệ thống gồm CSDL Oracle trong vài tuần là rủi ro rất cao; đề hỏi cách nhanh chóng cải thiện khả năng chịu tải.
  • **C. Tạo AMI và ASG rồi đặt ALB phân phối lưu lượng giữa máy chủ tại chỗ và máy chủ trên AWS — ALB không nhận target ngoài VPC theo cách này (chỉ nhận IP trong VPC hoặc IP tại chỗ qua kết nối riêng, và không đơn giản như mô tả); và vẫn là một dự án lớn.
  • **B. Dựng website tĩnh trên S3 và dùng Route 53 DNS failover sang đó — trang bán hàng cần logic động; chuyển sang trang tĩnh là mất chức năng chứ không phải chịu tải tốt hơn.

Ghi nhớ

⚠ Bốn loại origin của CloudFront — bảng phải thuộc: | Origin | Ghi chú | |---|---| | S3 | dùng OAC để bucket riêng tư | | ALB / EC2 | custom origin | | Máy chủ tại chỗ | custom origin, cần endpoint công khai | | Lambda function URL | hỗ trợ OAC |

Từ khoá nhận diện:

"quickly improve capacity, no time to migrate" → CloudFront trước hệ thống hiện có "on-premises origin" → custom origin "reduce origin load" → TTL dài, cache key hẹp "absorb traffic spikes" → CloudFront + Shield Standard

Ba lưu ý về custom origin: | Lưu ý | Chi tiết | |---|---| | Cần tên miền công khai phân giải được | | | Nên dùng https-only | | | Chặn truy cập thẳng bằng header bí mật | |

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

CloudFront thêm header bí mật
    → tường lửa tại chỗ chỉ nhận
      yêu cầu có header đó
        ↓
    Kẻ tấn công gọi thẳng origin
    → bị chặn

Ba lưu ý về TTL: | Cấp | Ý nghĩa | |---|---| | Origin gửi Cache-Control | origin quyết định | | DefaultTTL | dùng khi origin không gửi gì | | MinTTL / MaxTTL | giới hạn của phân phối |

Ba lưu ý về cache key: | Lưu ý | Chi tiết | |---|---| | Càng ít thành phần, tỷ lệ trúng càng cao | | | Cookie phiên trong cache key phá hỏng cache | | | Tách cache policy khỏi origin request policy | |

⚠ Origin cần header mà cache key không cần:

Origin muốn ghi log `User-Agent`
    → đưa vào ORIGIN REQUEST policy
    → KHÔNG đưa vào cache key
        ↓
    Origin vẫn nhận được header
    → mà cache không bị phân mảnh

Ba lưu ý về Origin Shield: | Lưu ý | Chi tiết | |---|---| | Thêm một tầng cache khu vực | | | Nhiều POP trượt cache chỉ gọi origin một lần | | | Rất hữu ích khi origin ở xa hoặc yếu | |

⚠ Với origin tại chỗ băng thông hạn chế, Origin Shield rất đáng:

Không có Shield: mỗi POP trượt cache
  đều gọi về origin
    → hàng trăm yêu cầu cho cùng một tệp
        ↓
    Có Shield: chỉ một yêu cầu
      tới origin

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả cache | | OriginLatency | origin có phải nút thắt không | | 5xxErrorRate | origin có đang chết không |

Ba lưu ý về đường đi tiếp theo: | Bước | Chi tiết | |---|---| | CloudFront ngay bây giờ | giải quyết đợt khuyến mãi | | Di chuyển tầng web sau | khi có thời gian | | Di chuyển CSDL cuối cùng | rủi ro cao nhất |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo tỷ lệ trúng cache sau vài ngày | | | Theo dõi lưu lượng thật tới origin | | | Chạy thử tải trước ngày khuyến mãi | |

Và một lời khuyên: hãy chạy một đợt kiểm thử tải trước ngày khuyến mãi thật. CloudFront giảm tải rất tốt cho nội dung tĩnh, nhưng trang thanh toán vẫn đi thẳng tới CSDL Oracle tại chỗ — và đó là chỗ sẽ gãy trước, không phải tầng web.

Câu 174 Domain - Continuous Improvement for Existing Solutions

A company has scheduled to launch a promotional sale on its e-commerce platform. The company’s web application is hosted on a fleet of Amazon EC2 instances in an Auto Scaling group. The database tier is hosted on an Amazon RDS for PostgreSQL DB instance. This is a large event so the management expects a sudden spike and unpredictable user traffic for the duration of the event. New users are also expected to register and participate in the event so there will be a lot of database writes during the event. The Solutions Architect has been tasked to create a solution that will ensure all submissions are committed to the database without changing the underlying data model.

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

  1. A

    Create an Amazon ElastiCache for Memcached cluster between the application and database tier. The cache will temporarily store the user submissions until the database is able to commit those entries.
  2. B

    Decouple the application and database tier by creating an Amazon SQS queue between them. Create an AWS Lambda function that picks up the messages on the SQS queue and writes them into the database.
  3. C

    To minimize any changes on the application or the current infrastructure, manually scale the current DB instance to a significantly larger instance size before the event. Choose a larger instance size depending on the anticipated user traffic, and scale down after the event is completed.
  4. D

    Instead of using Amazon RDS, migrate the database to an Amazon DynamoDB table instead. Utilize the built-in automatic scaling in DynamoDB to scale the database based on user traffic.
Xem giải thích

Đáp án

**B — Tách rời tầng ứng dụng và tầng CSDL bằng một hàng đợi Amazon SQS ở giữa; tạo hàm Lambda đọc thông điệp từ hàng đợi và ghi vào cơ sở dữ liệu.

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 | |---|---| | Mọi lượt đăng ký phải được ghi, không mất | SQS giữ thông điệp tới 14 ngày | | Đỉnh tải đột ngột và khó đoán | hàng đợi làm bộ đệm | | KHÔNG đổi mô hình dữ liệu | vẫn ghi vào chính RDS PostgreSQL |

⚠ Ràng buộc "không đổi mô hình dữ liệu" là chìa khoá:

Chuyển sang DynamoDB (phương án D)
    → phải thiết kế lại mô hình dữ liệu
    → phải viết lại mọi truy vấn
        ↓
    Vi phạm thẳng ràng buộc của đề

⚠ Và hàng đợi giải quyết đúng vấn đề của CSDL quan hệ:

RDS có trần số kết nối đồng thời
    → đỉnh tải mở hàng nghìn kết nối
    → CSDL từ chối, người dùng mất
      lượt đăng ký
        ↓
    Hàng đợi: đăng ký được nhận NGAY
    → Lambda ghi vào CSDL theo tốc độ
      CSDL chịu được

Cấu hình hàng đợi:

aws sqs create-queue --queue-name hang-doi-dang-ky \
  --attributes '{
    "VisibilityTimeout":"60",
    "MessageRetentionPeriod":"1209600",
    "ReceiveMessageWaitTimeSeconds":"20",
    "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"5\"}"}'

⚠ Giới hạn số Lambda đồng thời để không làm CSDL nghẹt:

aws lambda update-event-source-mapping --uuid <id> \
  --scaling-config MaximumConcurrency=20

Không giới hạn: Lambda mở hàng nghìn
  kết nối tới RDS
    → chính là vấn đề vừa muốn tránh
        ↓
    Giới hạn 20 đồng thời
    → số kết nối biết trước và ổn định

⚠ Và RDS Proxy còn tốt hơn nữa:

aws rds create-db-proxy --db-proxy-name proxy-dang-ky \
  --engine-family POSTGRESQL \
  --auth '[{"SecretArn":"<arn-bi-mat>","IAMAuth":"REQUIRED"}]' \
  --role-arn <arn> --vpc-subnet-ids subnet-a subnet-b

Proxy giữ pool kết nối dùng chung
    → hàng trăm Lambda dùng chung
      vài chục kết nối tới CSDL
        ↓
    Đây là cách chuẩn cho Lambda
      nói chuyện với RDS

Consumer:

import json, psycopg2

def handler(su_kien, ngu_canh):
    that_bai = []
    ket_noi = lay_ket_noi()
    for ban_ghi in su_kien['Records']:
        try:
            d = json.loads(ban_ghi['body'])
            ghi_dang_ky(ket_noi, d)
        except Exception:
            that_bai.append({'itemIdentifier': ban_ghi['messageId']})
    return {'batchItemFailures': that_bai}

⚠ batchItemFailures là cơ chế báo lỗi từng phần:

Không có nó: một bản ghi lỗi
  làm cả lô quay lại hàng đợi
    → những bản ghi đã ghi thành công
      bị xử lý lại
        ↓
    Có: chỉ bản ghi lỗi quay lại

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không mất lượt đăng ký nào | | | CSDL nhận tải ổn định, không bị nghẹt | | | Không đổi mô hình dữ liệu | |

⚠ Đổi lại: ghi trở thành BẤT ĐỒNG BỘ:

Người dùng bấm "Đăng ký"
    → nhận phản hồi "đã nhận"
    → nhưng chưa chắc đã vào CSDL
        ↓
    Nếu giao diện cần xác nhận ngay
      (ví dụ hiện mã đăng ký)
    → phải thiết kế lại luồng

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

  • **A. Đặt ElastiCache for Memcached giữa ứng dụng và CSDL để giữ tạm lượt đăng ký cho tới khi CSDL ghi được — đây là phương án gần nhất và cũng là một dạng bộ đệm, nhưng Memcached không bền vững: mất node là mất dữ liệu chưa ghi; và cache không có cơ chế thử lại như hàng đợi.
  • **C. Nâng cỡ instance RDS trước sự kiện rồi thu nhỏ sau — phải đoán trước quy mô đỉnh (đề nói khó đoán), tốn tiền cho công suất có thể không dùng tới, và vẫn có trần để chạm.
  • **D. Chuyển sang DynamoDB để dùng auto scaling — vi phạm ràng buộc "không đổi mô hình dữ liệu"; DynamoDB có API và mô hình hoàn toàn khác.

Ghi nhớ

⚠ Bốn cách xử lý đỉnh ghi vào CSDL — bảng phải thuộc: | Cách | Đánh giá | |---|---| | Hàng đợi ở giữa | không mất dữ liệu, tải ổn định | | Nâng cỡ instance | phải đoán trước, tốn tiền | | Read replica | chỉ giúp ĐỌC, không giúp GHI | | Cache | không bền vững, không thay hàng đợi được |

⚠ Read replica KHÔNG giúp gì cho tải ghi:

Đề nói "rất nhiều lượt GHI"
    → read replica chỉ chia tải đọc
        ↓
    Mọi lượt ghi vẫn vào instance chính
    → đây là hiểu nhầm phổ biến

Từ khoá nhận diện:

"all submissions must be committed" → hàng đợi "without changing the data model" → giữ nguyên CSDL, thêm bộ đệm "unpredictable spike" → SQS hoặc on-demand "too many database connections" → RDS Proxy

Ba lưu ý về RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Gộp và tái dùng kết nối | | | Giảm thời gian chuyển đổi Multi-AZ | | | Lấy thông tin đăng nhập từ Secrets Manager | |

⚠ Vì sao Lambda và RDS cần proxy:

Mỗi lượt Lambda mở một kết nối mới
    → hàng nghìn lượt đồng thời
    → hàng nghìn kết nối
        ↓
    PostgreSQL mỗi kết nối là một
      tiến trình — rất tốn bộ nhớ
    → CSDL sập vì hết kết nối

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Standard: thông lượng vô hạn, có thể trùng | | | FIFO: đúng thứ tự, chính xác một lần, có trần | | | Luôn có dead-letter queue | |

⚠ Chọn Standard hay FIFO:

Đăng ký người dùng: không cần thứ tự
    → Standard, thông lượng vô hạn
        ↓
    FIFO có trần 300 tin/giây mỗi nhóm
      (3.000 khi gom lô)
    → chỉ dùng khi thật sự cần thứ tự

Ba lưu ý về xử lý trùng: | Lưu ý | Chi tiết | |---|---| | SQS Standard có thể giao hơn một lần | | | Dùng ràng buộc UNIQUE trong CSDL | | | Hoặc ON CONFLICT DO NOTHING | |

INSERT INTO dang_ky (id_su_kien, email, thoi_gian)
VALUES ($1, $2, $3)
ON CONFLICT (id_su_kien) DO NOTHING;

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | ApproximateAgeOfOldestMessage | tăng đều — consumer không kịp | | DatabaseConnections | gần chạm max_connections | | Độ sâu DLQ | lớn hơn 0 |

⚠ Cảnh báo trên DLQ là thứ hay bị quên:

Hàng đợi chính trống rỗng
    → trông như mọi thứ đều ổn
        ↓
    Trong khi mọi thông điệp
      đang lặng lẽ rơi vào DLQ

Ba lưu ý về trải nghiệm người dùng: | Lưu ý | Chi tiết | |---|---| | Ghi bất đồng bộ: phản hồi "đã nhận" | | | Gửi email xác nhận sau khi ghi xong | | | Hoặc cho tra cứu trạng thái đăng ký | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tải cao, đếm số bản ghi vào CSDL | | | Kiểm không mất thông điệp nào | | | Theo dõi số kết nối tới RDS khi đỉnh | |

Và một lời khuyên: hãy đặt RDS Proxy giữa Lambda và CSDL ngay từ đầu. Hàng đợi giải quyết việc mất dữ liệu, nhưng nếu Lambda co giãn tự do thì nó sẽ mở đủ kết nối để làm nghẹt chính CSDL mà bạn vừa cố bảo vệ.

Câu 175 Domain - Continuous Improvement for Existing Solutions

A company is running a serverless backend API service on AWS. It has several AWS Lambda functions written in Python and an Amazon API Gateway that is configured to invoke the functions. The company wants to secure the API endpoint by ensuring that only authorized IAM users or roles can access the Amazon API Gateway endpoint. The Solutions Architect was also tasked to provide the ability to inspect each request end-to-end to check the latency of the request and to generate service maps.

Which of the following implementation will fulfill the above company requirements?

  1. A

    Generate a new client certificate on Amazon API Gateway. Distribute this certificate to all AWS users or roles that require access to the API endpoint. Ensure that each user will pass the client certification for every request made to the API endpoint. Trace and analyze each user request on API Gateway using Amazon CloudWatch Logs.
  2. B

    Write a separate AWS Lambda function that will act as a custom authorizer. For every call to the API gateway, require the client to pass the access key and secret key. Use the Lambda function to validate the key/secret pair against a valid IAM user. Trace and analyze each user request on API Gateway by using AWS X-Ray.
  3. C

    Configure authorization to use AWS_IAM for the API Gateway method. Create the IAM users or roles that have the execute-api:Invoke permission to the ARN of the API resource. Enable request signing with AWS Signature for every call to the API endpoint. Trace and analyze each user request on API Gateway by using AWS X-Ray.
  4. D

    Ensure that the API Gateway resource is secured by only returning the company’s domain in Access-Control-Allow-Origin headers and enabling Cross-origin resource sharing (CORS). Create the IAM users or roles that have the execute-api:Invoke permission to the ARN of the API resource. Trace and analyze each user request on API Gateway using Amazon CloudWatch Logs.
Xem giải thích

Đáp án

**C — Đặt authorization của method API Gateway thành AWS_IAM, tạo IAM user hoặc role có quyền execute-api:Invoke trên ARN của tài nguyên API, bật ký request bằng AWS Signature cho mọi lời gọi, và dùng AWS X-Ray để theo dõi và phân tích từng request.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi phần lo một cái: | Yêu cầu | Cách đáp ứng | |---|---| | Chỉ IAM user hoặc role được uỷ quyền gọi được API | AWS_IAM authorization + SigV4 | | Kiểm tra request đầu-cuối, đo độ trễ, sinh service map | X-Ray |

⚠ X-Ray là dịch vụ DUY NHẤT sinh service map:

CloudWatch Logs: bản ghi văn bản
    → không biết một request đi qua
      những đâu
        ↓
    X-Ray: theo dõi request qua nhiều
      dịch vụ
    → vẽ sơ đồ quan hệ và độ trễ
      từng chặng

Đây là lý do mọi phương án dùng CloudWatch Logs đều sai.

⚠ Và AWS_IAM là cơ chế xác thực đúng khi người gọi LÀ danh tính AWS:

Người gọi là IAM user hoặc role
    → họ đã có credential AWS
        ↓
    Ký request bằng SigV4
    → API Gateway tự kiểm chữ ký
    → không phải viết mã xác thực nào

Đặt authorization:

aws apigateway update-method \
  --rest-api-id <id> --resource-id <id-tai-nguyen> \
  --http-method POST \
  --patch-operations op=replace,path=/authorizationType,value=AWS_IAM

Chính sách cho người gọi:

{"Effect": "Allow",
 "Action": "execute-api:Invoke",
 "Resource": "arn:aws:execute-api:ap-southeast-1:111122223333:abc123/prod/POST/don-hang"}

⚠ Định dạng ARN của execute-api phải nhớ:

arn:aws:execute-api:<vung>:<tai-khoan>:<api-id>/<stage>/<method>/<duong-dan>
        ↓
    Giới hạn tới từng method và
      từng đường dẫn
    → đặc quyền tối thiểu thật sự

Bật X-Ray trên API Gateway và Lambda:

aws apigateway update-stage --rest-api-id <id> \
  --stage-name prod \
  --patch-operations op=replace,path=/tracingEnabled,value=true

aws lambda update-function-configuration \
  --function-name xu-ly-don-hang \
  --tracing-config Mode=Active

⚠ Phải bật ở CẢ HAI nơi mới có bức tranh đầy đủ:

Chỉ bật ở API Gateway
    → thấy độ trễ tổng
    → không biết Lambda tốn bao lâu
        ↓
    Bật cả hai
    → thấy từng chặng, kể cả lời gọi
      xuống DynamoDB

Ký request bằng SigV4:

import boto3, requests
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest

phien = boto3.Session()
yeu_cau = AWSRequest(method='POST', url=url, data=than)
SigV4Auth(phien.get_credentials(), 'execute-api',
          'ap-southeast-1').add_auth(yeu_cau)
requests.post(url, data=than, headers=dict(yeu_cau.headers))

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải viết mã xác thực nào | | | Credential tạm, tự hết hạn | | | CloudTrail ghi ai gọi API nào | |

⚠ Và X-Ray cho biết chính xác chặng nào chậm:

Người dùng báo API chậm
    → X-Ray service map hiện rõ:
      API Gateway 5ms
      Lambda 40ms
      DynamoDB 800ms  ← đây
        ↓
    Không phải đoán mò giữa các tầng

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

  • **B. Viết một Lambda authorizer tự kiểm access key và secret key người gọi truyền vào, dùng X-Ray theo dõi — đây là phương án gần nhất và có X-Ray đúng, nhưng bắt client gửi secret key trong request là lỗ hổng nghiêm trọng: secret key không bao giờ được truyền đi, chỉ dùng để ký.
  • **A. Sinh client certificate trên API Gateway và phân phát cho người dùng, theo dõi bằng CloudWatch Logs — client certificate của API Gateway dùng để backend xác thực API Gateway, không phải để client xác thực với API; và CloudWatch Logs không sinh service map.
  • **D. Bảo mật bằng cách chỉ trả tên miền công ty trong CORS header, dùng CloudWatch Logs — CORS là cơ chế của trình duyệt, nó không phải biện pháp bảo mật: curl bỏ qua CORS hoàn toàn.

Ghi nhớ

⚠ Bốn cách xác thực trên API Gateway — bảng phải thuộc: | Cách | Dùng khi | |---|---| | AWS_IAM | người gọi là IAM user/role hoặc dịch vụ AWS | | Cognito user pool | người dùng cuối của ứng dụng | | Lambda authorizer | IdP ngoài hoặc logic phức tạp | | API key + usage plan | đo lượng dùng, KHÔNG phải bảo mật |

⚠ API key KHÔNG phải cơ chế bảo mật:

AWS nói rõ: API key dùng để
  ĐO LƯỜNG và GIỚI HẠN TẦN SUẤT
        ↓
    Không dùng làm cơ chế xác thực
    → nó chỉ là một chuỗi trong header

Từ khoá nhận diện:

"only authorized IAM users or roles" → AWS_IAM authorization "trace request end-to-end, service map" → X-Ray "application end users sign in" → Cognito "third-party IdP" → Lambda authorizer

Ba lưu ý về X-Ray: | Lưu ý | Chi tiết | |---|---| | Bật ở mọi tầng để có bức tranh đủ | | | Lấy mẫu (sampling) giảm chi phí | | | Annotation cho phép lọc trace theo khoá | |

⚠ Sampling rule kiểm soát chi phí:

{"FixedRate": 0.05, "ReservoirSize": 1,
 "ServiceName": "*", "HTTPMethod": "*",
 "URLPath": "*", "Priority": 1000}

Ghi 1 request mỗi giây + 5% phần còn lại
    → đủ để thấy xu hướng
    → mà không tốn tiền theo mọi request

Ba lưu ý về SigV4: | Lưu ý | Chi tiết | |---|---| | Secret key KHÔNG bao giờ được gửi đi | | | Chữ ký có hạn 5 phút — đồng hồ phải đúng | | | SDK của AWS tự ký, không phải viết tay | |

⚠ Lệch đồng hồ gây lỗi khó hiểu:

Máy khách lệch giờ hơn 5 phút
    → chữ ký bị coi là hết hạn
        ↓
    Lỗi `SignatureDoesNotMatch`
    → nguyên nhân thật là NTP,
      không phải credential sai

Ba lưu ý về resource policy: | Lưu ý | Chi tiết | |---|---| | Giới hạn theo IP nguồn hoặc VPC endpoint | | | Kết hợp với AWS_IAM | | | API private chỉ gọi được trong VPC | |

{"Effect": "Deny", "Principal": "*",
 "Action": "execute-api:Invoke", "Resource": "<arn>",
 "Condition": {"NotIpAddress":
   {"aws:SourceIp": ["203.0.113.0/24"]}}}

Ba lưu ý về REST API và HTTP API: | Tính năng | REST API | HTTP API | |---|---|---| | AWS_IAM | có | có | | Lambda authorizer | có | có | | API key, usage plan | có | không | | Chi phí | cao hơn | rẻ hơn ~70% |

Ba lưu ý về giám sát: | Công cụ | Việc | |---|---| | X-Ray | độ trễ từng chặng, service map | | CloudWatch metric | Latency, 4XXError, 5XXError | | Access log | bản ghi từng request |

⚠ Phân biệt Latency và IntegrationLatency:

`IntegrationLatency`: thời gian backend
  (Lambda) xử lý
        ↓
    `Latency`: tổng, gồm cả overhead
      của API Gateway
        ↓
    Chênh lệch lớn giữa hai cái
    → vấn đề ở chính API Gateway

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi API không ký — phải 403 | | | Gọi bằng vai trò không có quyền — phải 403 | | | Xem service map trong X-Ray console | |

Và một lời khuyên: hãy bật X-Ray ở mọi tầng chứ đừng chỉ ở API Gateway. Trace chỉ có một chặng cho bạn biết request chậm, nhưng không cho biết chậm ở đâu — và đó chính là câu hỏi duy nhất bạn cần trả lời khi có sự cố.

Câu 176 Domain - Continuous Improvement for Existing Solutions

A company plans to release a public beta of its new video game. The release package is approximately 5GB in size. Based on previous releases and community feedback, millions of users from around the world are expected to download the new game. Currently, the company has a Linux-based website that lists the files which are hosted on its on-premises data center. Public Internet users are able to download the game via the website. However, the company wants a new solution that is cost-effective and will allow faster download performance for its users regardless of their location.

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

  1. A

    Create an Amazon S3 bucket with website hosting enabled and upload the game package on it. Create an Amazon CloudFront distribution with the S3 bucket as the origin. Create an Amazon Route 53 entry pointing to the CloudFront distribution. Publish the Route 53 entry as the download URL to allow users to download the game package.
  2. B

    Host the service on an Auto Scaling group of Amazon EC2 instances. Save the game files on the mounted Amazon EFS volume on each instance. Place the Auto Scaling group behind a Network Load Balancer. Create an Amazon Route 53 entry pointing to the NLB. Publish the Route 53 entry as the download URL to allow users to download the game package.
  3. C

    Create an Amazon S3 bucket with website hosting enabled and upload the game package on it. To improve cost-effectiveness, enable the “Requestor Pays” option for the S3 bucket. Create an Amazon Route 53 entry pointing to the S3 bucket. Publish the Route 53 entry as the download URL to allow users to download the game package.
  4. D

    Host the service on an Auto Scaling group of Amazon EC2 instances. Save the game files on the mounted Amazon EBS volumes on each instance. Place the Auto Scaling group behind an Application Load Balancer. Create an Amazon Route 53 entry pointing to the ALB. Publish the Route 53 entry as the download URL to allow users to download the game package.
Xem giải thích

Đáp án

**A — Tạo bucket S3 bật website hosting và tải gói cài đặt lên, tạo phân phối CloudFront với bucket đó làm origin, tạo bản ghi Route 53 trỏ tới phân phối, và công bố địa chỉ đó làm URL tải về.

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 | |---|---| | Hàng triệu người tải gói 5 GB | S3 + CloudFront, không có máy chủ nào để quá tải | | Nhanh bất kể người dùng ở đâu | CloudFront phân phối từ điểm biên gần nhất | | Rẻ | truyền qua CloudFront rẻ hơn từ S3 hoặc EC2 |

⚠ Đây là bài toán CloudFront sinh ra để giải:

Cùng một tệp 5 GB, hàng triệu lượt tải
    → tỷ lệ trúng cache gần 100%
        ↓
    Tệp được cache ở từng điểm biên
    → origin chỉ phục vụ lần đầu
      cho mỗi điểm biên

⚠ Và chi phí truyền dữ liệu là yếu tố quyết định:

Truyền ra từ S3 trực tiếp: đắt hơn
        ↓
    Truyền qua CloudFront: rẻ hơn
    → và có mức giá bậc thang giảm
      theo khối lượng
        ↓
    Với hàng triệu × 5 GB
    → chênh lệch rất lớn

Cấu hình cache cho tệp lớn:

{"DefaultCacheBehavior": {
  "TargetOriginId": "s3-goi-cai-dat",
  "ViewerProtocolPolicy": "redirect-to-https",
  "CachePolicyId": "<tinh-ttl-dai>",
  "Compress": false}}

⚠ Tắt nén cho tệp cài đặt:

Gói cài đặt thường đã nén sẵn
    → nén lại không giảm được gì
    → chỉ tốn CPU
        ↓
    Và CloudFront chỉ nén tệp
      dưới 10 MB
    → tệp 5 GB không bị nén dù sao

Cache-Control dài:

aws s3 cp game-v1.2.0.zip s3://goi-cai-dat/ \
  --cache-control "public, max-age=31536000, immutable"

⚠ Mã phiên bản trong tên tệp cho phép TTL vĩnh viễn:

`game-v1.2.0.zip`
    → phiên bản mới có tên mới
        ↓
    Không bao giờ phải xoá cache
    → và người dùng không nhận nhầm
      phiên bản cũ

⚠ Và OAC để bucket không công khai:

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

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ nào để quá tải | | | Tải nhanh ở mọi châu lục | | | Chi phí thấp nhất trong các phương án | |

⚠ Và với gói 5 GB nên cân nhắc thêm:

Hỗ trợ HTTP Range request
    → người dùng tải dở, mất mạng
    → tiếp tục được thay vì tải lại
        ↓
    S3 và CloudFront đều hỗ trợ sẵn
    → nhưng trình tải phía client
      phải dùng

⚠ Vì sao "Requester Pays" (phương án C) không hợp:

Requester Pays: người TẢI trả phí
    → nhưng họ phải có tài khoản AWS
      và ký request bằng SigV4
        ↓
    Người chơi game thông thường
      không có tài khoản AWS
    → không tải được

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

  • **C. Bucket S3 bật website hosting với "Requester Pays" và Route 53 trỏ thẳng tới bucket — đây là phương án gần nhất và cũng dùng S3 làm nơi lưu, nhưng Requester Pays đòi người tải phải có tài khoản AWS và ký request; và bỏ CloudFront nghĩa là mất cả tốc độ lẫn mức giá truyền rẻ hơn.
  • **B. Dựng ASG EC2 với EFS sau một NLB — EFS đắt hơn S3 rất nhiều, phải vận hành máy chủ, và không có cache ở biên.
  • **D. Dựng ASG EC2 với EBS sau một ALB — mỗi instance phải có bản sao 5 GB riêng, tốn kém và khó đồng bộ; và vẫn không có phân phối toàn cầu.

Ghi nhớ

⚠ Bốn cách phân phối tệp lớn — bảng phải thuộc: | Cách | Đánh giá | |---|---| | S3 + CloudFront | tốt nhất cho tải công khai quy mô lớn | | S3 trực tiếp | được, nhưng chậm hơn và đắt hơn khi truyền | | EC2 + EBS/EFS | phải vận hành, không co giãn tốt | | S3 Transfer Acceleration | cho UPLOAD, không phải download |

Từ khoá nhận diện:

"millions of downloads worldwide" → CloudFront "faster uploads from far away" → S3 Transfer Acceleration "restrict who can download" → signed URL hoặc signed cookie "requester pays for data transfer" → Requester Pays (cần tài khoản AWS)

Ba lưu ý về CloudFront cho tệp lớn: | Lưu ý | Chi tiết | |---|---| | TTL rất dài, tệp không đổi | | | Origin Shield giảm tải origin thêm | | | Hỗ trợ Range request để tải tiếp | |

⚠ Origin Shield rất đáng với tệp lớn:

Không có Shield: mỗi điểm biên trượt
  cache đều kéo 5 GB từ S3
    → hàng trăm lần × 5 GB
        ↓
    Có Shield: một tầng cache khu vực
    → S3 phục vụ ít lần hơn nhiều

Ba lưu ý về price class: | Price class | Phạm vi | |---|---| | All | mọi điểm biên, đắt nhất | | 200 | bỏ Nam Mỹ, Úc, New Zealand | | 100 | chỉ Bắc Mỹ và châu Âu |

⚠ Đề nói người dùng toàn cầu:

Chọn price class 100 để tiết kiệm
    → người dùng châu Á, Nam Mỹ
      phải đi xa hơn
        ↓
    Với "millions of users around
      the world" thì dùng All

Ba lưu ý về S3: | Lưu ý | Chi tiết | |---|---| | Không có giới hạn số lượt tải | | | Object tối đa 5 TB | | | Multipart upload cho tệp trên 5 GB | |

Ba lưu ý về theo dõi lượt tải: | Lưu ý | Chi tiết | |---|---| | CloudFront standard log vào S3 | | | Real-time log qua Kinesis | | | Phân tích bằng Athena | |

SELECT date, COUNT(*) AS luot_tai, SUM(bytes)/1e12 AS tb
FROM cloudfront_logs
WHERE uri = '/game-v1.2.0.zip'
GROUP BY date ORDER BY date;

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | OAC để bucket riêng tư | | | Bật HTTPS bắt buộc | | | Công bố mã băm để người dùng kiểm tra | |

⚠ Công bố SHA-256 của gói cài đặt:

Người dùng kiểm tra tệp tải về
  có đúng không
        ↓
    Bảo vệ khỏi tệp bị sửa đổi
    → thực hành chuẩn cho phần mềm
      phân phối công khai

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Truyền qua CloudFront rẻ hơn từ S3 | | | Giá bậc thang giảm theo khối lượng | | | Lưu trữ 5 GB là khoản không đáng kể | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải thử từ nhiều châu lục, đo tốc độ | | | Xem header X-Cache có trúng cache không | | | Kiểm URL S3 trực tiếp — phải 403 | |

Và một lời khuyên: hãy đưa số phiên bản vào tên tệp và đặt TTL một năm. Bạn sẽ không bao giờ phải xoá cache, người dùng không bao giờ nhận nhầm bản cũ, và origin gần như không phục vụ yêu cầu nào sau ngày phát hành đầu tiên.

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

A company runs a live flight tracking service hosted on the AWS cloud. The application gets updated every 10 minutes with the latest flight information from every airline. The tracking website has a global audience and uses an Auto Scaling group behind an Elastic Load Balancer and an Amazon RDS database. A simple web interface is hosted as static content on an Amazon S3 bucket. The Auto Scaling group is set to trigger a scale-up event at 90% CPU utilization. The average load time of the web page is around 7 seconds but the management wants to bring it down to less than 3 seconds.

Which combination of options will make the page load time faster in the MOST cost-effective way? (Select TWO.)

  1. A Create a second installation in another region, and utilize Amazon Route 53's latency-based routing feature to direct requests to the appropriate region.
  2. B Have CloudFront enable caching of re-usable content from your website.
  3. C

    Replace your existing Auto Scaling group with the AWS Systems Manager State Manager which provides a more effective way to manage and scale your EC2 instances.
  4. D

    Add a caching layer using Amazon ElastiCache Service to be used for storing sessions and frequent DB queries.
  5. E Scale more frequently by setting the scale up trigger of the Auto Scaling group to 30%.
Xem giải thích

Đáp án

**B và D — Bật CloudFront cache nội dung dùng lại được của website; và thêm một tầng cache bằng Amazon ElastiCache để lưu phiên và các truy vấn CSDL hay lặp lại.

Vì sao đúng

Đề nêu mục tiêu rất cụ thể: giảm thời gian tải từ 7 giây xuống dưới 3 giây, rẻ nhất, và hai đáp án tấn công hai nguồn độ trễ khác nhau: | Nguồn độ trễ | Cách giảm | |---|---| | Khoảng cách địa lý tới người dùng toàn cầu | CloudFront cache ở biên | | Truy vấn CSDL lặp lại | ElastiCache |

⚠ Đề cho một dữ kiện rất hợp với cache:

Dữ liệu chuyến bay cập nhật
  mỗi 10 PHÚT
        ↓
    Trong 10 phút đó, mọi người dùng
      nhận CÙNG một nội dung
    → tỷ lệ trúng cache rất cao
    → TTL 5 phút là an toàn

Cấu hình cache theo loại nội dung:

{"CacheBehaviors": {"Items": [
  {"PathPattern": "/tinh/*", "TargetOriginId": "s3-tinh",
   "CachePolicyId": "<ttl-mot-nam>"},
  {"PathPattern": "/api/chuyen-bay/*", "TargetOriginId": "elb",
   "CachePolicyId": "<ttl-300-giay>"}]}}

⚠ Cache được cả nội dung ĐỘNG khi nó thay đổi theo chu kỳ:

Nhiều người tưởng CloudFront chỉ
  cache tệp tĩnh
        ↓
    API trả dữ liệu chuyến bay
    → TTL 300 giây
    → hàng triệu yêu cầu chỉ thành
      một lời gọi origin mỗi 5 phút

Cache truy vấn CSDL:

import redis, json
cache = redis.Redis(host=diem_cuoi, port=6379, ssl=True)

def lay_chuyen_bay(ma_chuyen):
    khoa = f'chuyen-bay:{ma_chuyen}'
    da_co = cache.get(khoa)
    if da_co:
        return json.loads(da_co)
    du_lieu = truy_van_csdl(ma_chuyen)
    cache.setex(khoa, 300, json.dumps(du_lieu))
    return du_lieu

⚠ Và ElastiCache còn giữ phiên — điều kiện để tầng ứng dụng stateless:

Phiên nằm trong bộ nhớ instance
    → ASG thu hồi máy là mất phiên
    → phải dùng sticky session
      làm tải phân bố lệch
        ↓
    Phiên trong Redis
    → mọi instance dùng chung
    → co giãn thoải mái

⚠ Vì sao hạ ngưỡng co giãn xuống 30% (phương án E) không giải quyết được:

Thêm máy chủ
    → mỗi máy vẫn chạy CÙNG một
      truy vấn CSDL
    → và người dùng vẫn ở xa
        ↓
    Thêm máy làm tăng THÔNG LƯỢNG
    → không giảm ĐỘ TRỄ mỗi yêu cầu
        ↓
    Và tốn tiền hơn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Người dùng toàn cầu nhận nội dung từ điểm gần | | | CSDL nhận ít truy vấn hơn hẳn | | | Rẻ hơn nhiều so với thêm máy chủ | |

⚠ Và cache còn giúp trong lúc CSDL gặp sự cố:

RDS chậm hoặc đang chuyển đổi
    → yêu cầu trúng cache vẫn
      được phục vụ
        ↓
    Sự cố nhỏ không thành gián đoạn
      thấy được

Đo trước và sau:

aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront --metric-name CacheHitRate \
  --dimensions Name=DistributionId,Value=<id> \
  --start-time 2026-08-24T00:00:00Z \
  --end-time 2026-08-31T00:00:00Z \
  --period 86400 --statistics Average

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

  • **A. Dựng bản sao ở Region thứ hai và dùng định tuyến theo độ trễ của Route 53 — đây là phương án gần nhất và thật sự giảm độ trễ cho người dùng ở xa, nhưng nó nhân đôi toàn bộ hạ tầng gồm cả CSDL; đề hỏi cách rẻ nhất và CloudFront đạt được phần lớn lợi ích đó với chi phí nhỏ hơn nhiều.
  • **E. Hạ ngưỡng co giãn của ASG xuống 30% để thêm máy sớm hơn — thêm máy tăng thông lượng nhưng không giảm độ trễ mỗi yêu cầu; và tốn tiền hơn.
  • **C. Thay ASG bằng Systems Manager State Manager để "quản lý và co giãn EC2 hiệu quả hơn" — State Manager giữ cấu hình ở trạng thái mong muốn, nó không co giãn gì cả.

Ghi nhớ

⚠ Ba nguồn độ trễ và cách xử lý — bảng phải thuộc: | Nguồn | Cách giảm | |---|---| | Khoảng cách địa lý | CDN, hoặc đa Region | | Truy vấn CSDL lặp lại | cache trong bộ nhớ | | Tính toán trên máy chủ | thêm máy hoặc tối ưu mã |

Thêm máy chỉ giải quyết nguồn thứ ba
    → và đề nói CPU đang ở 90%
      chỉ khi có đỉnh
        ↓
    Vấn đề chính là hai nguồn đầu

Từ khoá nhận diện:

"global audience, slow page load" → CloudFront "repeated database queries" → ElastiCache "cost-effective" → cache trước khi thêm hạ tầng "session state across instances" → ElastiCache Redis

⚠ Redis và Memcached — bảng phải thuộc: | Tiêu chí | Redis | Memcached | |---|---|---| | Kiểu dữ liệu | phong phú (list, set, sorted set) | chỉ chuỗi | | Bền vững | có | không | | Replica và chuyển đổi | có | không | | Đa luồng | hạn chế | có |

Lưu phiên và cần chịu lỗi
    → Redis
        ↓
    Cache đơn giản, cần đa luồng
    → Memcached

Ba lưu ý về ElastiCache: | Lưu ý | Chi tiết | |---|---| | Luôn đặt TTL cho mọi khoá | | | Bật mã hoá khi truyền và khi lưu | | | Serverless nếu tải khó đoán | |

⚠ Thiếu TTL là nguyên nhân cache đầy bộ nhớ:

Khoá không có hạn
    → tích tụ mãi
        ↓
    Cache đầy, chính sách thu hồi
      xoá cả khoá đang dùng
    → người dùng bị đăng xuất ngẫu nhiên

Ba mẫu cache: | Mẫu | Cách | |---|---| | Cache-aside (lazy loading) | ứng dụng đọc cache, trượt thì đọc CSDL | | Write-through | ghi cả CSDL lẫn cache cùng lúc | | TTL | để dữ liệu tự hết hạn |

⚠ Cache-aside có vấn đề "cache stampede":

Khoá phổ biến hết hạn cùng lúc
    → hàng nghìn yêu cầu cùng trượt cache
    → tất cả cùng gọi CSDL
        ↓
    CSDL nghẹt
    → dùng TTL lệch nhau chút ít
      hoặc khoá phân tán

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | Cache key hẹp thì tỷ lệ trúng cao | | | Bật nén Gzip và Brotli | | | Bật chỉ số bổ sung mới thấy CacheHitRate | |

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

Chuyển tiếp mọi cookie tới origin
    → mỗi người dùng có cookie riêng
        ↓
    Mỗi người dùng = một mục cache riêng
    → tỷ lệ trúng gần bằng 0

Ba lưu ý về đo lường: | Chỉ số | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả cache | | TargetResponseTime của ALB | backend chậm hay nhanh | | CacheHits / CacheMisses của Redis | cache có được dùng không |

Ba lưu ý về thứ tự tối ưu: | Bước | Chi tiết | |---|---| | Đo trước, tìm nguồn độ trễ chính | | | Cache là biện pháp rẻ nhất | | | Thêm hạ tầng là bước cuối | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian tải từ nhiều châu lục | | | Theo dõi tỷ lệ trúng của cả hai tầng cache | | | Xem tải CSDL trước và sau | |

Và một lời khuyên: hãy đo xem thời gian 7 giây đó tiêu vào đâu trước khi thêm bất cứ thứ gì. Với người dùng toàn cầu thì phần lớn thường là thời gian đi lại trên mạng — và đó là thứ không có số lượng máy chủ nào giải quyết được.

Câu 178 Domain - Design for New Solutions

A leading financial company runs its application in an Amazon ECS Cluster. The application processes a large stream of intraday data and stores the generated result in a DynamoDB table. To comply with the financial regulatory policy, the solutions architect was tasked to design a system that detects new entries in the DynamoDB table and then automatically run tests to verify the results using a Lambda function.

Which of the following options can satisfy the company’s requirement with minimal configuration changes?

  1. A

    Set up a DynamoDB stream to detect the new entries and automatically trigger the Lambda function.
  2. B

    Detect the new entries in the DynamoDB table using Systems Manager Automation then automatically invoke the Lambda function for processing.
  3. C

    Migrate the table to Amazon DocumentDB to take advantage of its integration with Amazon EventBridge which can invoke a Lambda function for specific database events.
  4. D

    Run an AWS Lambda function using Amazon SNS as a trigger each time the ECS Cluster successfully processes financial data.
Xem giải thích

Đáp án

**A — Dựng DynamoDB Stream để phát hiện bản ghi mới và tự động kích hoạt hàm Lambda.

Vì sao đúng

Đề nêu ba yêu cầu, và DynamoDB Streams khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Phát hiện bản ghi mới trong bảng | stream ghi lại mọi thay đổi | | Tự động chạy Lambda kiểm tra | Lambda event source mapping | | Ít thay đổi cấu hình nhất | bật một cờ, gắn một trigger |

⚠ DynamoDB Streams là tính năng có sẵn của chính bảng:

Bật stream
    → mọi INSERT, UPDATE, DELETE
      được ghi lại theo thứ tự
        ↓
    Lambda đọc stream đó
    → không cần dịch vụ trung gian nào

Bật stream:

aws dynamodb update-table --table-name KetQuaXuLy \
  --stream-specification \
    StreamEnabled=true,StreamViewType=NEW_IMAGE

⚠ Bốn giá trị StreamViewType — bảng phải thuộc: | Giá trị | Ghi lại | |---|---| | KEYS_ONLY | chỉ khoá chính | | NEW_IMAGE | bản ghi SAU khi đổi | | OLD_IMAGE | bản ghi TRƯỚC khi đổi | | NEW_AND_OLD_IMAGES | cả hai |

Kiểm tra bản ghi mới
    → `NEW_IMAGE` là đủ
        ↓
    Cần so trước và sau (ví dụ
      phát hiện thay đổi bất thường)
    → `NEW_AND_OLD_IMAGES`

Gắn Lambda:

aws lambda create-event-source-mapping \
  --function-name kiem-tra-ket-qua \
  --event-source-arn <arn-stream> \
  --starting-position LATEST \
  --batch-size 100 \
  --maximum-batching-window-in-seconds 5 \
  --maximum-retry-attempts 3 \
  --destination-config '{"OnFailure":{"Destination":"<arn-dlq>"}}'

Hàm xử lý:

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        if ban_ghi['eventName'] != 'INSERT':
            continue
        du_lieu = ban_ghi['dynamodb']['NewImage']
        kiem_tra_tinh_hop_le(du_lieu)

⚠ Phải lọc theo eventName — nếu không sẽ xử lý cả UPDATE:

Stream ghi MỌI thay đổi
    → hàm kiểm tra ghi kết quả lại
      vào cùng bảng
        ↓
    Kích hoạt chính nó
    → VÒNG LẶP VÔ HẠN
        ↓
    Lọc `INSERT`, hoặc ghi kết quả
      sang bảng khác

⚠ Và có thể lọc ngay ở event source, không phải trong mã:

aws lambda create-event-source-mapping \
  --function-name kiem-tra-ket-qua \
  --event-source-arn <arn-stream> \
  --filter-criteria '{"Filters":[{
    "Pattern":"{\"eventName\":[\"INSERT\"]}"}]}'

Lambda không được gọi cho bản ghi
  không khớp
    → không tính tiền cho lượt chạy
      vô ích

⚠ Bẫy nghiêm trọng: một bản ghi hỏng chặn cả shard:

Lambda ném lỗi
    → thử lại cả lô mãi
        ↓
    Shard đó DỪNG HOÀN TOÀN
    → phải đặt `MaximumRetryAttempts`,
      `BisectBatchOnFunctionError`
      và điểm đến khi thất bại

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ bật một cờ và gắn một trigger | | | Giữ đúng thứ tự theo khoá phân vùng | | | Không có dịch vụ trung gian nào | |

⚠ Và có lựa chọn thứ hai đáng biết: Kinesis Data Streams cho DynamoDB: | Tiêu chí | DynamoDB Streams | Kinesis Data Streams | |---|---|---| | Giữ dữ liệu | 24 giờ | tới 365 ngày | | Số consumer | 2 mỗi shard | nhiều, có fan-out | | Thứ tự | đảm bảo theo khoá | có thể trùng và lệch thứ tự |

Cần nhiều hệ thống đọc cùng luồng
  hoặc giữ dữ liệu lâu
    → Kinesis
        ↓
    Một consumer đơn giản
    → DynamoDB Streams

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

  • **C. Chuyển bảng sang DocumentDB để tận dụng tích hợp với EventBridge — đây là phương án gần nhất và DocumentDB có change stream, nhưng chuyển toàn bộ CSDL sang dịch vụ khác là thay đổi rất lớn, ngược hẳn với yêu cầu "ít thay đổi cấu hình nhất".
  • **B. Phát hiện bản ghi mới bằng Systems Manager Automation — Automation là công cụ chạy quy trình vận hành (vá lỗi, khởi động lại máy), nó không theo dõi thay đổi trong bảng DynamoDB.
  • **D. Chạy Lambda với SNS làm trigger mỗi khi cụm ECS xử lý xong — phải sửa mã ứng dụng để publish lên SNS; và nó phát hiện "ứng dụng nói đã xong" chứ không phát hiện bản ghi thật sự vào bảng.

Ghi nhớ

⚠ Bốn cách phản ứng với thay đổi dữ liệu — bảng phải thuộc: | Nguồn | Cơ chế | |---|---| | DynamoDB | DynamoDB Streams | | S3 | event notification hoặc EventBridge | | RDS/Aurora | DMS CDC hoặc Aurora trigger + Lambda | | DocumentDB | change stream |

Từ khoá nhận diện:

"detect new entries in DynamoDB" → DynamoDB Streams "minimal configuration changes" → tính năng sẵn có, không đổi kiến trúc "react to object upload" → S3 event notification "replicate to another Region" → global table (cũng dùng stream)

Ba lưu ý về DynamoDB Streams: | Lưu ý | Chi tiết | |---|---| | Giữ 24 giờ | | | Tối đa 2 consumer mỗi shard | | | Thứ tự đảm bảo trong mỗi khoá phân vùng | |

⚠ Global table cũng dùng stream — chú ý khi đếm consumer:

Bảng có global table
    → nhân bản đã chiếm một consumer
        ↓
    Còn một chỗ cho Lambda của bạn

Ba lưu ý về Lambda đọc stream: | Lưu ý | Chi tiết | |---|---| | starting-position: LATEST hoặc TRIM_HORIZON | | | ParallelizationFactor tăng đồng thời mỗi shard | | | Luôn cấu hình DLQ | |

⚠ TRIM_HORIZON xử lý cả dữ liệu cũ trong stream:

LATEST: chỉ bản ghi từ lúc gắn trở đi
        ↓
    TRIM_HORIZON: từ đầu stream
      (tối đa 24 giờ trước)
    → dùng khi cần xử lý bù

Ba lưu ý về vòng lặp vô hạn: | Lưu ý | Chi tiết | |---|---| | Đừng ghi lại vào chính bảng kích hoạt | | | Lọc theo eventName | | | Hoặc ghi kết quả sang bảng khác | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | IteratorAge | Lambda chậm hơn stream bao nhiêu | | Errors của Lambda | có bản ghi hỏng không | | Độ sâu DLQ | bản ghi nào không xử lý được |

⚠ IteratorAge chạm 24 giờ là mất dữ liệu:

Lambda không theo kịp
    → bản ghi cũ nhất tiến dần
      tới giới hạn 24 giờ
        ↓
    Vượt: bản ghi bị xoá khỏi stream
    → không xử lý được nữa

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Stream tính phí theo lượt đọc | | | Gom lô lớn hơn giảm số lượt Lambda | | | Filter criteria giảm lượt gọi vô ích | |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Ghi kết quả kiểm tra vào bảng riêng | | | Giữ dấu vết cho kiểm toán | | | CloudTrail data event nếu cần biết ai ghi | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chèn một bản ghi, xem Lambda có chạy | | | Theo dõi IteratorAge | | | Kiểm DLQ có bản ghi nào không | |

Và một lời khuyên: hãy cấu hình DLQ và giới hạn số lần thử lại ngay khi gắn Lambda vào stream. Một bản ghi hỏng có thể dừng toàn bộ shard vô thời hạn — và triệu chứng chỉ là dữ liệu ngừng được xử lý, không có lỗi nào nổi lên rõ ràng.

Câu 179 Domain - Continuous Improvement for Existing Solutions

A company has a CRM application that uses a MySQL database hosted in Amazon RDS, and a central data warehouse that runs on Amazon Redshift. There is a batch analytics process that runs every day and reads data from RDS. During the execution of the batch analytics, the RDS utilization spikes up, which results in the CRM application becoming unresponsive. The top management dashboard must also be updated with new data right after the batch analytics processing completes. However, the dashboard is on another system running on-premises and cannot be modified directly. The only way to update the dashboard is to send an email with the new data to the dashboard system via SMTP, which will then be parsed and processed to update the dashboard with the latest data.

How would the solutions architect optimize this scenario to solve performance issues and automate the process as much as possible?

  1. A

    Add read replicas for the RDS database to speed up batch analytics and use Amazon SNS to notify the on-premises system to update the dashboard.
  2. B

    Consider using Amazon Redshift instead of Amazon RDS as the database for the CRM application. Use Amazon SQS to notify the on-premises system to update the dashboard.
  3. C

    Consider using Amazon Redshift as the main OLTP transactional database instead of RDS for the batch analytics and use Redshift Spectrum to run SQL queries directly against Exabytes of structured or unstructured data in S3 without the need for unnecessary data movement. Utilize Amazon SNS to notify the on-premises system to update the dashboard.
  4. D

    Add read replicas for the RDS database to speed up batch analytics and use Amazon SQS to notify the on-premises system to update the dashboard.
Xem giải thích

Đáp án

**A — Thêm read replica cho CSDL RDS để chạy phân tích theo lô, và dùng Amazon SNS thông báo cho hệ thống tại chỗ cập nhật bảng điều khiển.

Vì sao đúng

Đề nêu hai vấn đề, và mỗi phần lo một cái: | Vấn đề | Cách giải | |---|---| | Phân tích theo lô làm CRM treo | read replica gánh tải đọc | | Cập nhật bảng điều khiển qua email SMTP | SNS gửi email được |

⚠ Read replica đúng ở đây vì phân tích chỉ ĐỌC:

Job phân tích quét toàn bộ bảng
    → chiếm hết CPU và I/O của
      instance chính
        ↓
    CRM cùng dùng instance đó
    → trở nên không phản hồi
        ↓
    Chuyển job sang replica
    → CRM không bị ảnh hưởng gì

Tạo replica riêng cho phân tích:

aws rds create-db-read-replica \
  --db-instance-identifier replica-phan-tich \
  --source-db-instance-identifier csdl-crm \
  --db-instance-class db.r6g.2xlarge

⚠ Replica có thể có cỡ KHÁC instance chính:

Job phân tích cần nhiều bộ nhớ
    → replica cỡ lớn hơn
        ↓
    CRM cần ít hơn
    → instance chính giữ nguyên cỡ
        ↓
    Tách bạch hai loại tải hoàn toàn

⚠ Và SNS gửi email trực tiếp — đây là điểm phân biệt với SQS:

SNS: ĐẨY thông điệp tới người nhận
    → hỗ trợ email, SMS, HTTP, Lambda
        ↓
    SQS: hàng đợi, người nhận
      phải tự KÉO về
    → hệ thống tại chỗ không kéo được
      từ hàng đợi

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

Đăng ký email:

aws sns create-topic --name bao-cao-hoan-tat
aws sns subscribe --topic-arn <arn> \
  --protocol email --notification-endpoint bang-dieu-khien@congty.com

⚠ Nhưng đề nói bảng điều khiển đọc email qua SMTP và tự phân tích:

SNS gửi email theo định dạng của nó
    → hệ thống tại chỗ phải phân tích
      được định dạng đó
        ↓
    Bật raw message delivery để
      gửi đúng nội dung mình soạn

aws sns set-subscription-attributes \
  --subscription-arn <arn> \
  --attribute-name RawMessageDelivery \
  --attribute-value true

⚠ Và SES là lựa chọn phù hợp hơn nếu cần kiểm soát định dạng email:

SNS: thông báo, định dạng cố định
        ↓
    SES: email thật, kiểm soát
      hoàn toàn tiêu đề và nội dung
    → hợp hơn khi hệ thống nhận
      phân tích nội dung email

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | CRM không bị ảnh hưởng bởi job phân tích | | | Tự động thông báo, không cần ai bấm nút | | | Không phải sửa hệ thống bảng điều khiển | |

⚠ Nhưng phải chú ý độ trễ nhân bản:

Replica nhân bản BẤT ĐỒNG BỘ
    → job phân tích đọc dữ liệu
      cũ vài giây
        ↓
    Với báo cáo hằng ngày thì
      không sao
    → nhưng phải biết là có

Theo dõi độ trễ:

aws cloudwatch put-metric-alarm \
  --alarm-name replica-tre --namespace AWS/RDS \
  --metric-name ReplicaLag --statistic Average \
  --period 300 --threshold 300 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=DBInstanceIdentifier,Value=replica-phan-tich

⚠ Và job phân tích nặng có thể làm replica tụt lại rất xa:

Replica dùng một luồng để áp
  thay đổi (với MySQL truyền thống)
    → job phân tích chiếm tài nguyên
        ↓
    Độ trễ tăng dần trong lúc chạy job
    → chấp nhận được nếu job chạy đêm

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

  • **D. Thêm read replica nhưng dùng SQS để thông báo cho hệ thống tại chỗ — đây là phương án gần nhất và phần read replica hoàn toàn đúng, nhưng SQS là hàng đợi kiểu kéo: hệ thống bảng điều khiển tại chỗ chỉ nhận email qua SMTP, nó không kéo thông điệp từ SQS được.
  • **C. Dùng Redshift làm CSDL giao dịch chính thay RDS cho CRM — Redshift là kho dữ liệu phân tích, nó xử lý rất kém với thao tác đọc/ghi từng bản ghi của một hệ thống CRM.
  • **B. Chuyển CRM sang Redshift và dùng SQS — sai cả hai vế.

Ghi nhớ

⚠ SNS và SQS — bảng phải thuộc: | Tiêu chí | SNS | SQS | |---|---|---| | Mô hình | ĐẨY (push) | KÉO (pull) | | Đích | email, SMS, HTTP, Lambda, SQS | chỉ consumer tự kéo | | Lưu trữ | không lưu | tới 14 ngày | | Nhiều người nhận | có | một thông điệp một người |

Hệ thống nhận không thể kéo
    → phải ĐẨY tới nó
    → SNS hoặc SES

Từ khoá nhận diện:

"batch analytics slows down the app" → read replica "notify an external system by email" → SNS hoặc SES "decouple, buffer" → SQS "OLTP vs OLAP" → RDS/Aurora vs Redshift

⚠ OLTP và OLAP — bảng phải thuộc: | Tiêu chí | OLTP | OLAP | |---|---|---| | Thao tác | đọc/ghi bản ghi nhỏ | quét lớn, tổng hợp | | Dịch vụ | RDS, Aurora, DynamoDB | Redshift, Athena | | Ví dụ | CRM, đơn hàng | báo cáo xu hướng |

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Nhân bản bất đồng bộ | | | Ứng dụng phải tự định tuyến đọc/ghi | | | Cỡ instance có thể khác instance chính | |

⚠ RDS Proxy tự tách đọc/ghi:

Không phải sửa mã để chọn endpoint
    → proxy định tuyến giúp
        ↓
    Nhưng với job phân tích thì nên
      trỏ THẲNG vào replica
    → để chắc chắn không đụng
      instance chính

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | Độ trễ replica thường dưới 100ms | | | Tới 15 replica | | | Reader endpoint tự cân bằng | |

Ba lưu ý về đưa dữ liệu sang kho phân tích: | Cách | Chi tiết | |---|---| | Zero-ETL Aurora → Redshift | không cần viết pipeline | | DMS CDC | nhân bản liên tục | | Xuất snapshot sang S3 | không đụng CSDL đang chạy |

⚠ Zero-ETL là hướng hiện đại cho bài toán này:

Aurora tự đẩy dữ liệu sang Redshift
    → gần thời gian thực
    → không viết pipeline nào
        ↓
    Phân tích chạy hoàn toàn trên
      Redshift
    → CRM không bị đụng tới

Ba lưu ý về SNS: | Lưu ý | Chi tiết | |---|---| | Người nhận email phải xác nhận đăng ký | | | Filter policy lọc theo thuộc tính | | | Không đảm bảo thứ tự (trừ FIFO) | |

⚠ Bước xác nhận đăng ký hay bị quên:

`subscribe` xong
    → trạng thái `PendingConfirmation`
        ↓
    Phải bấm link trong email xác nhận
    → không bấm: không nhận thông báo nào

Ba lưu ý về xuất báo cáo: | Lưu ý | Chi tiết | |---|---| | Ghi kết quả ra S3 rồi thông báo | | | Đính kèm link thay vì dữ liệu lớn | | | SNS có giới hạn 256 KB mỗi thông điệp | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy job phân tích, xem CRM có chậm không | | | Kiểm email thông báo có tới đúng định dạng | | | Theo dõi ReplicaLag trong lúc chạy job | |

Và một lời khuyên: hãy cân nhắc Zero-ETL sang Redshift nếu job phân tích ngày càng nặng. Read replica giải quyết được vấn đề hôm nay, nhưng một job quét toàn bảng vẫn là tải sai loại cho CSDL giao dịch — và kho dữ liệu chuyên dụng làm việc đó nhanh hơn nhiều lần.

Câu 180 Domain - Continuous Improvement for Existing Solutions

A cryptocurrency trading platform uses a Lambda function which has recently been integrated with DynamoDB Streams as its event source. Whenever there is a new deployment, the incoming traffic to the function must be shifted in two increments using CodeDeploy. Ten percent of the incoming traffic should be shifted to the new version and then the remaining 90 percent should be deployed five minutes later. It is also required to trace the event source that invoked the Lambda function including the downstream calls that the function made.

Which of the following options should the solutions architect implement to satisfy this requirement?

  1. A

    Configure a Linear deployment configuration for your Lambda function and use AWS Config to trace the event source and downstream calls.
  2. B

    Configure an All-at-once deployment configuration for your Lambda function and use AWS Config to trace the event source and downstream calls.
  3. C

    Configure a Canary deployment configuration for your Lambda function. Enable active tracing to integrate AWS X-Ray to your AWS Lambda function. 
  4. D

    Configure a Rolling with additional batch deployment configuration for your Lambda function and use X-Ray to trace the event source and downstream calls.
Xem giải thích

Đáp án

**C — Cấu hình kiểu triển khai Canary cho hàm Lambda; bật active tracing để tích hợp AWS X-Ray vào hàm.

Vì sao đúng

Đề mô tả chính xác một mẫu chuyển lưu lượng, và nó có tên riêng:

Chuyển 10% trước
    → chờ 5 phút
    → chuyển 90% còn lại
        ↓
    Đây là định nghĩa của CANARY

⚠ Ba kiểu triển khai Lambda của CodeDeploy — bảng phải thuộc: | Kiểu | Cách chuyển | |---|---| | Canary | X% trước, chờ, rồi phần còn lại — HAI bước | | Linear | X% mỗi N phút cho tới hết — NHIỀU bước đều nhau | | All-at-once | 100% ngay lập tức |

"Hai increment: 10% rồi 90% sau 5 phút"
    → đúng hai bước
    → Canary, không phải Linear

Cấu hình sẵn có của AWS:

CodeDeployDefault.LambdaCanary10Percent5Minutes
CodeDeployDefault.LambdaCanary10Percent10Minutes
CodeDeployDefault.LambdaLinear10PercentEvery1Minute
CodeDeployDefault.LambdaAllAtOnce

`LambdaCanary10Percent5Minutes` khớp
  chính xác yêu cầu trong đề

Khai trong SAM:

Resources:
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      AutoPublishAlias: san-xuat
      DeploymentPreference:
        Type: Canary10Percent5Minutes
        Alarms:
          - !Ref CanhBaoLoi
        Hooks:
          PreTraffic: !Ref HamKiemThuTruoc
          PostTraffic: !Ref HamKiemThuSau
      Tracing: Active

⚠ Tracing: Active là phần bật X-Ray:

aws lambda update-function-configuration \
  --function-name xu-ly-giao-dich \
  --tracing-config Mode=Active

⚠ Hai chế độ tracing của Lambda: | Chế độ | Hành vi | |---|---| | Active | Lambda tự quyết định lấy mẫu và tạo trace | | PassThrough | chỉ tiếp tục trace nếu người gọi đã bắt đầu |

Nguồn sự kiện là DynamoDB Streams
    → không có trace nào từ trước
        ↓
    Phải dùng `Active` mới có trace
    → đây là lý do đề nói "enable
      active tracing"

⚠ Và X-Ray là dịch vụ DUY NHẤT theo dõi được lời gọi xuống hạ nguồn:

AWS Config: ghi lại CẤU HÌNH tài nguyên
    → không biết gì về luồng request
        ↓
    X-Ray: theo dõi từ nguồn sự kiện
      qua Lambda tới DynamoDB, S3...
    → vẽ service map

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

Bật X-Ray cho SDK trong mã:

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()

@xray_recorder.capture('kiem_tra_giao_dich')
def kiem_tra(du_lieu):
    ...

⚠ patch_all() tự bọc mọi lời gọi boto3:

Mỗi lời gọi DynamoDB, S3, HTTP
    → thành một subsegment riêng
        ↓
    Thấy rõ chặng nào tốn thời gian

⚠ Và alarm là phần làm canary có ý nghĩa:

Không có alarm: chuyển 10% rồi
  chuyển nốt bất kể có lỗi hay không
        ↓
    Có alarm: lỗi tăng trong 5 phút đầu
    → CodeDeploy TỰ QUAY LUI
    → chỉ 10% người dùng bị ảnh hưởng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ 10% lưu lượng chịu rủi ro ban đầu | | | Tự quay lui khi có cảnh báo | | | X-Ray cho biết chặng nào chậm hoặc lỗi | |

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

  • **D. Cấu hình kiểu Rolling with additional batch cho Lambda và dùng X-Ray — đây là phương án gần nhất và có X-Ray đúng, nhưng "rolling with additional batch" là kiểu triển khai của Elastic Beanstalk, không phải của Lambda; Lambda chỉ có Canary, Linear và All-at-once.
  • **A. Cấu hình kiểu Linear và dùng AWS Config — Linear chuyển theo nhiều bước đều nhau, không phải hai bước 10%/90%; và Config ghi cấu hình chứ không theo dõi request.
  • **B. Cấu hình All-at-once và dùng AWS Config — all-at-once chuyển 100% ngay, trái hẳn yêu cầu chuyển hai bước.

Ghi nhớ

⚠ Kiểu triển khai theo dịch vụ — bảng phải thuộc: | Dịch vụ | Các kiểu | |---|---| | Lambda | Canary, Linear, All-at-once | | ECS | Canary, Linear, All-at-once (blue/green) | | EC2/On-premises | In-place, Blue/Green | | Elastic Beanstalk | All-at-once, Rolling, Rolling with additional batch, Immutable, Blue/Green |

Từ khoá nhận diện:

"two increments, wait, then rest" → Canary "equal increments every N minutes" → Linear "trace event source and downstream calls" → X-Ray active tracing "record configuration changes" → AWS Config

Ba lưu ý về alias và version: | Lưu ý | Chi tiết | |---|---| | Chuyển lưu lượng hoạt động trên ALIAS | | | Alias trỏ tới hai version với tỷ lệ | | | $LATEST không dùng cho triển khai | |

aws lambda update-alias --function-name xu-ly-giao-dich \
  --name san-xuat --function-version 12 \
  --routing-config AdditionalVersionWeights={"13"=0.1}

⚠ Nhưng DynamoDB Streams có một hạn chế phải biết:

Event source mapping trỏ tới một
  version hoặc alias CỤ THỂ
        ↓
    Chuyển lưu lượng theo trọng số
      hoạt động với lời gọi ĐỒNG BỘ
    → với nguồn dạng luồng thì
      cơ chế khác
        ↓
    Kiểm chứng kỹ ở môi trường thử

Ba lưu ý về hook: | Hook | Chạy khi | |---|---| | BeforeAllowTraffic | trước khi chuyển lưu lượng | | AfterAllowTraffic | sau khi chuyển xong |

Hook trả về thất bại
    → CodeDeploy dừng và quay lui
        ↓
    Dùng để chạy kiểm thử khói
      tự động

Ba lưu ý về alarm: | Lưu ý | Chi tiết | |---|---| | Đặt alarm trên Errors và Duration | | | Alarm kích hoạt thì tự quay lui | | | Không có alarm thì canary mất phần lớn giá trị | |

Ba lưu ý về X-Ray: | Lưu ý | Chi tiết | |---|---| | Cần quyền xray:PutTraceSegments | | | Sampling giảm chi phí | | | Annotation cho phép lọc trace | |

xray_recorder.put_annotation('maGiaoDich', ma)

⚠ Annotation được đánh chỉ mục, metadata thì không:

Annotation: lọc và tìm kiếm được
    → dùng cho khoá quan trọng
        ↓
    Metadata: chỉ xem, không lọc được
    → dùng cho dữ liệu chi tiết

Ba lưu ý về giám sát triển khai: | Lưu ý | Chi tiết | |---|---| | Theo dõi tỷ lệ lỗi trong giai đoạn canary | | | So độ trễ version cũ và mới | | | Ghi lại lịch sử triển khai | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Triển khai một version có lỗi cố ý, xem có quay lui | | | Kiểm service map trong X-Ray | | | Đếm số lượt chạy trên từng version | |

Và một lời khuyên: hãy luôn gắn alarm vào cấu hình triển khai canary. Không có alarm thì canary chỉ là một khoảng chờ năm phút vô nghĩa — nó vẫn chuyển nốt 90% lưu lượng sang phiên bản hỏng đúng như lịch, không ai ngăn lại.