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

Tìm thấy 1221 câu.

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

A company plans to migrate its on-premises legacy application to AWS and develop a highly scalable application. Currently, all user requests are sent to the on-premises load balancer which forwards the requests to two Linux servers hosting the legacy application. The database is hosted on two servers in master-master configuration. Since this is an old application, the communication to the database servers is done through static IP addresses and not via DNS names. The license of the application is tied to the MAC address of the network adapter of the Linux server. If the application is to be installed on a new server, it will take about 15 hours for the software vendor to send the new license via email.

Which combination of actions must be done to meet the company requirements? (Select TWO.)

  1. A

    Install the application on an EC2 instance and configure the needed license file. Update the local configuration with the database IP addresses. Use this instance as the base AMI for all instances in the Auto Scaling group.
  2. B

    Create an AWS Lambda function to update the database IP addresses on the Systems Manager Parameter Store. Create an Amazon EC2 bootstrap script that will retrieve the database IP address from SSM Parameter Store. Update the local configuration files with the parameters.
  3. C

    Create an Amazon EC2 bootstrap script that will resolve the database DNS names into IP addresses. Update the local configuration files with the resolved values.
  4. D

    Provision a pool of Elastic Network Interfaces (ENIs). Request a license file for each ENI from the software vendor. Store the license files inside an Amazon EC2 instance and create a base AMI from this EC2 instance. Use bootstrap scripts to configure license keys and attach the corresponding ENI when provisioning EC2 instances.
  5. E

    Provision a pool of Elastic Network Interfaces (ENIs). Request a license file for each ENI from the software vendor. Store the license files on an Amazon S3 bucket and use bootstrap scripts to retrieve an unused license file and attach corresponding ENI when provisioning EC2 instances.
Xem giải thích

Đáp án

**B và E — Tạo hàm Lambda cập nhật địa chỉ IP của CSDL vào Systems Manager Parameter Store, và viết script khởi động EC2 lấy IP đó từ Parameter Store rồi cập nhật tệp cấu hình cục bộ; đồng thời chuẩn bị sẵn một nhóm Elastic Network Interface (ENI), xin giấy phép cho từng ENI, lưu tệp giấy phép trên bucket S3 và dùng script khởi động lấy một giấy phép chưa dùng rồi gắn ENI tương ứng khi tạo instance.

Vì sao đúng

Đề nêu hai ràng buộc kỳ lạ, và mỗi đáp án lo một cái: | Ràng buộc | Cách giải | |---|---| | Ứng dụng nối CSDL bằng IP tĩnh, không dùng DNS | Parameter Store + script khởi động | | Giấy phép gắn với địa chỉ MAC, xin mới mất 15 giờ | nhóm ENI có giấy phép chuẩn bị sẵn |

⚠ Địa chỉ MAC nằm ở ENI, không ở instance:

Mỗi ENI có một địa chỉ MAC cố định
    → gắn ENI vào instance nào thì
      instance đó có MAC đó
        ↓
    Chuẩn bị sẵn 20 ENI
    → xin 20 giấy phép trước
        ↓
    ASG tạo instance mới
    → gắn một ENI chưa dùng
    → giấy phép khớp ngay lập tức

⚠ Và đây là điều làm Auto Scaling khả thi với ứng dụng khoá theo MAC:

Không có nhóm ENI
    → mỗi lần ASG tạo máy mới
    → phải chờ 15 GIỜ xin giấy phép
        ↓
    Không co giãn được chút nào

Tạo nhóm ENI trước:

for i in $(seq 1 20); do
  aws ec2 create-network-interface \
    --subnet-id subnet-abc \
    --groups sg-ung-dung \
    --description "ENI-giay-phep-$i" \
    --tag-specifications \
      "ResourceType=network-interface,Tags=[{Key=TrangThai,Value=chua-dung}]"
done

Script khởi động lấy giấy phép và gắn ENI:

#!/bin/bash
ENI=$(aws ec2 describe-network-interfaces \
  --filters Name=tag:TrangThai,Values=chua-dung \
            Name=status,Values=available \
  --query 'NetworkInterfaces[0].NetworkInterfaceId' --output text)

INSTANCE=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
aws ec2 attach-network-interface \
  --network-interface-id "$ENI" \
  --instance-id "$INSTANCE" --device-index 1

MAC=$(aws ec2 describe-network-interfaces \
  --network-interface-ids "$ENI" \
  --query 'NetworkInterfaces[0].MacAddress' --output text)

aws s3 cp "s3://kho-giay-phep/${MAC}.lic" /opt/ung-dung/license.lic

⚠ Và S3 là nơi đúng để lưu giấy phép — đây là điểm phân biệt với phương án D:

Nhúng giấy phép vào AMI (phương án D)
    → AMI phải dựng lại mỗi khi
      thêm ENI mới
        ↓
    S3: thêm giấy phép là tải lên
      một tệp
    → AMI không đổi

⚠ Và địa chỉ IP CSDL phải lấy động, không nhúng vào AMI:

Nhúng IP vào AMI (phương án A)
    → CSDL đổi IP là phải dựng
      lại AMI
        ↓
    Parameter Store: cập nhật một
      tham số
    → mọi instance mới lấy giá trị mới

Cập nhật IP bằng Lambda:

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

def handler(su_kien, ngu_canh):
    ip_moi = lay_ip_csdl_hien_tai()
    ssm.put_parameter(
        Name='/ung-dung/ip-csdl',
        Value=','.join(ip_moi),
        Type='StringList', Overwrite=True)

Script khởi động đọc tham số:

IP_CSDL=$(aws ssm get-parameter \
  --name /ung-dung/ip-csdl \
  --query 'Parameter.Value' --output text)
sed -i "s/DB_HOSTS=.*/DB_HOSTS=${IP_CSDL}/" /opt/ung-dung/config.ini

⚠ Và vì sao KHÔNG dùng DNS (phương án C):

Đề nói RÕ: ứng dụng nối CSDL
  bằng IP TĨNH, không dùng DNS
        ↓
    "Phân giải DNS thành IP rồi ghi
      vào cấu hình" nghe hợp lý
    → nhưng CSDL master-master
      tự quản không có tên DNS nào
        ↓
    Phải lấy IP từ nguồn khác

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Auto Scaling hoạt động dù giấy phép khoá theo MAC | | | Đổi IP CSDL không phải dựng lại AMI | | | Thêm giấy phép chỉ cần tải tệp lên S3 | |

⚠ Nhưng phải xử lý việc trả ENI về nhóm:

Instance bị thu hồi
    → ENI tự gỡ ra (nếu không đặt
      `DeleteOnTermination`)
        ↓
    Nhưng tag `TrangThai` vẫn là
      "dang-dung"
    → phải dùng lifecycle hook để
      đặt lại tag

aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name asg-ung-dung \
  --lifecycle-hook-name tra-eni \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 300

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

  • **D. Chuẩn bị nhóm ENI, xin giấy phép cho từng ENI, lưu tệp giấy phép TRONG một EC2 rồi tạo AMI từ đó — đây là phương án gần nhất và ý tưởng nhóm ENI hoàn toàn đúng, nhưng nhúng giấy phép vào AMI nghĩa là mỗi lần thêm ENI mới phải dựng lại AMI; lưu trên S3 linh hoạt hơn hẳn.
  • **A. Cài ứng dụng lên một EC2, cấu hình giấy phép và IP CSDL, rồi dùng làm AMI gốc cho toàn bộ ASG — mọi instance sẽ dùng CÙNG một giấy phép (cùng MAC là không thể), và IP CSDL bị đóng băng trong AMI.
  • **C. Script khởi động phân giải tên DNS của CSDL thành IP rồi ghi vào cấu hình — đề nói rõ hệ thống không dùng DNS cho CSDL.

Ghi nhớ

⚠ Ba cách cấu hình động cho instance mới — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Parameter Store | giá trị cấu hình, miễn phí (Standard) | | Secrets Manager | bí mật, có xoay tự động | | AppConfig | cấu hình đổi lúc CHẠY, có triển khai dần |

Từ khoá nhận diện:

"license tied to MAC address" → nhóm ENI chuẩn bị sẵn "static IP, no DNS" → Parameter Store + user data "config that changes at runtime" → AppConfig "secret with rotation" → Secrets Manager

Ba lưu ý về ENI: | Lưu ý | Chi tiết | |---|---| | MAC address cố định theo ENI | | | Gắn được vào instance đang chạy | | | Chỉ trong CÙNG một AZ | |

⚠ Ràng buộc AZ là điều phải tính khi thiết kế:

ENI ở AZ-a chỉ gắn được vào
  instance ở AZ-a
        ↓
    ASG trải ba AZ
    → phải có nhóm ENI ở MỖI AZ
    → và script phải chọn đúng AZ

AZ=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
ENI=$(aws ec2 describe-network-interfaces \
  --filters Name=availability-zone,Values=$AZ \
            Name=status,Values=available \
            Name=tag:TrangThai,Values=chua-dung \
  --query 'NetworkInterfaces[0].NetworkInterfaceId' --output text)

Ba lưu ý về đua tranh khi lấy ENI: | Lưu ý | Chi tiết | |---|---| | Hai instance khởi động cùng lúc có thể chọn cùng ENI | | | attach-network-interface sẽ thất bại ở cái thứ hai | | | Phải thử lại với ENI khác | |

⚠ Vòng lặp thử lại là bắt buộc:

for i in $(seq 1 5); do
  if aws ec2 attach-network-interface \
       --network-interface-id "$ENI" \
       --instance-id "$INSTANCE" --device-index 1; then
    break
  fi
  sleep 5
  ENI=$(chon_eni_khac)
done

Ba lưu ý về Parameter Store: | Lưu ý | Chi tiết | |---|---| | StringList cho danh sách IP | | | Standard miễn phí, tối đa 4 KB | | | Instance cần IAM role có quyền đọc | |

Ba lưu ý về user data: | Lưu ý | Chi tiết | |---|---| | Chạy một lần khi khởi động lần đầu | | | Đọc được từ instance metadata — đừng đặt bí mật | | | Log ở /var/log/cloud-init-output.log | |

Ba lưu ý về ứng dụng cũ trên cloud: | Vấn đề | Cách xử lý | |---|---| | Khoá theo MAC | nhóm ENI | | Khoá theo IP | Elastic IP hoặc IP cố định trên ENI | | Khoá theo hostname | đặt hostname trong user data |

Ba lưu ý về lifecycle hook: | Lưu ý | Chi tiết | |---|---| | Chạy trước khi instance bị thu hồi | | | Dùng để trả tài nguyên về nhóm | | | Phải gọi complete-lifecycle-action khi xong | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Cảnh báo khi số ENI rảnh xuống thấp | | | Theo dõi instance khởi động thất bại | | | Xin thêm giấy phép TRƯỚC khi cạn | |

⚠ Đây là cảnh báo quan trọng nhất:

Hết ENI rảnh
    → ASG tạo instance nhưng ứng dụng
      không chạy được
        ↓
    Xin giấy phép mất 15 giờ
    → cảnh báo khi còn 5 ENI rảnh,
      không phải khi hết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cho ASG tạo một máy mới, xem có gắn ENI và lấy giấy phép | | | Đổi IP trong Parameter Store, tạo máy mới, kiểm cấu hình | | | Thu hồi một máy, xem ENI có trở về nhóm | |

Và một lời khuyên: hãy đặt cảnh báo trên số ENI còn rảnh với ngưỡng đủ rộng. Xin giấy phép mất mười lăm giờ, nên ngày bạn phát hiện hết ENI là ngày ASG đã không mở rộng được suốt cả một chu kỳ tải cao điểm.

Câu 252 Domain - Continuous Improvement for Existing Solutions

A software development company based in New Jersey has tasked the solutions architect to design the network architecture for their new enterprise resource planning (ERP) system in AWS. The new system should allow access to business managers and analysts over the Internet, whether they are in their hotel rooms, cafes, or elsewhere. However, the ERP system should not be publicly accessible by anyone over the Internet but only by authorized personnel.

Which of the following network design meets the above requirements while minimizing deployment and operational costs?

  1. A Establish an AWS Direct Connect connection and create a private interface to your VPC. Create a public subnet and place your app servers in it.
  2. B Establish an IPsec VPN connection and provide the users with the configuration details. Create a public subnet in your VPC, and place your application servers in it.
  3. C Establish an SSL VPN solution in a public subnet of your VPC. Install and configure SSL VPN client software on all the workstations/laptops of the users who need access to the ERP system. Create a private subnet in your VPC and place your application servers behind it.
  4. D Deploy the ERP system behind an Elastic Load Balancer with an SSL certificate to allow HTTPS connections.
Xem giải thích

Đáp án

**C — Dựng giải pháp SSL VPN trong subnet công khai của VPC; cài phần mềm SSL VPN client lên mọi máy trạm và laptop của người dùng cần truy cập; tạo subnet riêng tư và đặt máy chủ ứng dụng phía sau nó.

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 | |---|---| | Truy cập từ khách sạn, quán cà phê, bất kỳ đâu | VPN client trên từng máy | | KHÔNG ai truy cập được công khai | máy chủ trong subnet riêng tư | | Rẻ nhất về triển khai và vận hành | VPN client rẻ hơn Direct Connect nhiều |

⚠ "Từ khách sạn, quán cà phê" nghĩa là VPN kiểu CLIENT:

Site-to-Site VPN (phương án B)
    → nối MẠNG với MẠNG
        ↓
    Người dùng ở khách sạn
    → máy của họ không thuộc mạng
      nào đã nối
        ↓
    Cần phần mềm VPN trên từng máy

⚠ Và Direct Connect (phương án A) hoàn toàn sai bối cảnh:

DX nối TRUNG TÂM DỮ LIỆU với AWS
    → không nối được từng máy trạm
        ↓
    Và chi phí cao nhất trong
      bốn phương án
    → đề hỏi cách RẺ NHẤT

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

Đề nói: "hệ thống KHÔNG được truy
  cập công khai bởi bất kỳ ai"
        ↓
    Subnet công khai có tuyến tới
      Internet gateway
    → đó là thiết kế sai chủ đích

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

⚠ Và ELB với chứng chỉ SSL (phương án D) chỉ mã hoá, không hạn chế:

HTTPS bảo vệ dữ liệu trên đường
  truyền
        ↓
    Nhưng ai cũng gọi tới ELB được
    → mã hoá KHÔNG phải kiểm soát
      truy cập

Kiến trúc:

Máy trạm người dùng (bất kỳ đâu)
    ↓ SSL VPN
Subnet CÔNG KHAI: endpoint VPN
    ↓
Subnet RIÊNG TƯ: máy chủ ERP
    ↓
Không có đường vào từ Internet

⚠ 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=directory-service-authentication,\
ActiveDirectory={DirectoryId=d-abc} \
  --connection-log-options Enabled=true,CloudwatchLogGroup=/vpn/ket-noi \
  --split-tunnel

⚠ --split-tunnel giảm chi phí đáng kể: | 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 |

Full tunnel: người dùng xem video
  cũng đi vòng qua AWS
    → tốn băng thông và tiền
        ↓
    Split tunnel: chỉ ERP đi qua VPN

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Máy chủ hoàn toàn không lộ ra Internet | | | Người dùng truy cập từ bất kỳ đâu | | | Rẻ hơn nhiều so với Direct Connect | |

⚠ Và AWS Verified Access là hướng hiện đại hơn:

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 theo danh tính và
      trạng thái thiết bị
    → truy cập ứng dụng qua trình
      duyệt, không cần VPN client

aws ec2 create-verified-access-endpoint \
  --verified-access-group-id vagr-abc \
  --endpoint-type load-balancer \
  --attachment-type vpc \
  --domain-certificate-arn <arn> \
  --application-domain erp.congty.com

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

  • **B. Dựng IPsec VPN và cung cấp thông tin cấu hình cho người dùng, đặ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 ở khách sạn.
  • **A. Dựng Direct Connect với private interface, đặt máy chủ ở subnet công khai — DX nối trung tâm dữ liệu, không nối máy trạm cá nhân; và đắt nhất.
  • **D. Triển khai ERP sau ELB có chứng chỉ SSL cho phép HTTPS — HTTPS mã hoá đường truyền nhưng ai cũng truy cập được; không đáp ứng yêu cầu "không 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 | Chi phí | |---|---|---| | Client VPN | từng máy trạm, ở bất kỳ đâu | vừa | | Site-to-Site VPN | nối mạng với mạng | thấp | | Direct Connect | trung tâm dữ liệu, băng thông cao | cao | | Verified Access | ứng dụng qua trình duyệt, zero-trust | vừa |

Từ khoá nhận diện:

"from hotel rooms, cafes, anywhere" → Client VPN "connect two networks" → Site-to-Site VPN "not publicly accessible" → subnet riêng tư "HTTPS only" → mã hoá, KHÔNG phải kiểm soát truy cập

⚠ 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 việc instance có
  IP công khai hay không
    → phụ thuộc BẢNG ĐỊNH TUYẾN

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

⚠ 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 AD hoặc SAML để tận dụng MFA | | | Thu hồi chứng chỉ khi nhân viên nghỉ | |

Ba lưu ý về phân quyền: | Lưu ý | Chi tiết | |---|---| | authorize-client-vpn-ingress theo nhóm | | | Nhóm khác nhau tới được subnet khác nhau | | | Một endpoint, nhiều mức quyền | |

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 lưu ý về Session Manager: | Lưu ý | Chi tiết | |---|---| | Cho truy cập SHELL, không cần VPN | | | Nhưng không phục vụ ứng dụng web | | | Bổ sung, không thay thế VPN | |

⚠ Phân biệt hai nhu cầu:

Quản trị viên cần shell vào máy
    → Session Manager
        ↓
    Người dùng cần dùng ứng dụng web
    → VPN hoặc Verified Access

Ba lưu ý về Verified Access: | Lưu ý | Chi tiết | |---|---| | Không cần cài client nào | | | Đánh giá theo danh tính và thiết bị | | | Ghi log mọi quyết định cho phép hay từ chối | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử truy cập ERP 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à instance ở đó chỉ cách việc lộ ra Internet đúng một lần ai đó gán nhầm Elastic IP.

Câu 253 Domain - Continuous Improvement for Existing Solutions

A global data analytics firm has various data centers from different countries all over the world. The staff are regularly uploading analytics, financial, and regulatory files of each of their respective data centers to a web portal deployed in AWS, which uses an S3 bucket named global-analytics-reports-bucket to durably store the data. The staff download various reports from a CloudFront distribution which uses the global-analytics-reports-bucket S3 bucket as the origin. The security team noticed that the staff are using both the CloudFront link and the direct Amazon S3 URLs to download the reports. The security team sees this as a security risk and they recommended implementing a way to prevent anyone from bypassing CloudFront and using the direct Amazon S3 URLs.

Which of the following options should the solutions architect implement to meet the above requirement?

  1. A 1. In your CloudFront distribution, use a custom SSL instead of the default SSL. 2. Remove anyone else's permission to use Amazon S3 URLs to read the objects.
  2. B

    1. Create a special CloudFront user called an origin access identity (OAI) and associate it with your CloudFront distribution.

    2. Give the origin access identity permission to read the objects in your bucket.

    3. Remove anyone else's permission to use Amazon S3 URLs to read the objects.
  3. C 1. Set up a field-level encryption configuration in the CloudFront distribution. 2. Remove anyone else's permission to use Amazon S3 URLs to read the objects.
  4. D 1. Configure the distribution to use Signed URLs. 2. Create a special CloudFront user called an origin access identity (OAI). 3. Give the origin access identity permission to read the objects in your bucket.
Xem giải thích

Đáp án

**B — Tạo một origin access identity (OAI) và gắn vào phân phối CloudFront; cấp cho OAI đó quyền đọc object trong bucket; và gỡ quyền của mọi người khác dùng URL S3 để đọc object.

Vì sao đúng

Đề nêu một yêu cầu duy nhất, và ba bước trong phương án này là quy trình chuẩn:

1. Tạo danh tính đặc biệt cho CloudFront
        ↓
2. Chỉ danh tính đó được đọc bucket
        ↓
3. Gỡ mọi quyền công khai khác
        ↓
    Kết quả: URL S3 trực tiếp trả 403,
      URL CloudFront trả 200

⚠ Bước 3 là bước quyết định — thiếu nó thì hai bước đầu vô nghĩa:

Tạo OAI và cấp quyền cho nó
    → nhưng bucket vẫn công khai
        ↓
    URL S3 trực tiếp vẫn dùng được
    → không giải quyết vấn đề gì

Bucket policy chỉ cho OAI đọc:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS":
    "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1ABC"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::global-analytics-reports-bucket/*"}]}

Chặn mọi truy cập công khai:

aws s3api put-public-access-block \
  --bucket global-analytics-reports-bucket \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

⚠ Và signed URL (phương án D) giải quyết bài toán KHÁC:

Signed URL: hạn chế AI được xem
    → mỗi link có chữ ký và hạn dùng
        ↓
    Đề chỉ hỏi: ngăn người dùng
      BỎ QUA CloudFront
    → không hỏi hạn chế người xem
        ↓
    Thêm signed URL là giải quyết
      vấn đề không được hỏi

⚠ Và phương án D còn thiếu bước gỡ quyền công khai:

Có OAI + signed URL
    → nhưng bucket vẫn công khai
        ↓
    Vẫn bỏ qua CloudFront được

⚠ Và field-level encryption (phương án C) hoàn toàn khác:

Mã hoá ở mức trường: mã hoá dữ liệu
  nhạy cảm mà NGƯỜI DÙNG GỬI LÊN
  qua biểu mẫu
        ↓
    Không liên quan tới việc hạn chế
      truy cập object

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bucket hoàn toàn riêng tư | | | Mọi truy cập đi qua CloudFront | | | Có log và cache ở tầng CloudFront | |

⚠ Và đi qua CloudFront còn cho ba thứ khác:

1. Cache ở biên — nhanh hơn cho
   nhân viên toàn cầu
        ↓
2. Log truy cập tập trung
        ↓
3. Gắn được WAF nếu cần

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

⚠ OAI đã bị thay thế bởi Origin Access Control (OAC).

AWS ra mắt OAC năm 2022 và khuyến nghị dùng nó cho mọi thiết kế mới:

Tiêu chí OAI (cũ) OAC (nay)
Bucket mã hoá SSE-KMS KHÔNG hỗ trợ CÓ
Phương thức chỉ GET/HEAD cả PUT, POST, DELETE
Mọi Region hạn chế có
Ký yêu cầu SigV4 hạn chế SigV4 đầy đủ
Được khuyến nghị không CÓ 
Đề nói bucket lưu báo cáo tài chính
  và tuân thủ
        ↓
    Loại dữ liệu này thường mã hoá
      bằng SSE-KMS
    → OAI KHÔNG đọc được
        ↓
    Trong tình huống thật, phải
      dùng OAC

Bucket policy với OAC:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::global-analytics-reports-bucket/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn":
     "arn:aws:cloudfront::111122223333:distribution/E1ABC"}}}

⚠ Và điều kiện AWS:SourceArn là phần bắt buộc với OAC:

Principal chỉ là "cloudfront.amazonaws.com"
    → nghĩa là MỌI phân phối CloudFront
      của MỌI khách hàng AWS
        ↓
    Không có `AWS:SourceArn`
    → ai đó tạo phân phối trỏ vào
      bucket của bạn là đọc được

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

  • **D. Cấu hình phân phối dùng Signed URL, tạo OAI và cấp quyền đọc cho nó — đây là phương án gần nhất và có OAI đúng, nhưng nó thiếu bước gỡ quyền công khai nên URL S3 trực tiếp vẫn dùng được; và signed URL giải quyết vấn đề "ai được xem" chứ không phải "bỏ qua CloudFront".
  • **A. Dùng chứng chỉ SSL tuỳ chỉnh thay chứng chỉ mặc định rồi gỡ quyền công khai — chứng chỉ SSL liên quan tới tên miền và mã hoá, không liên quan tới việc CloudFront đọc bucket.
  • **C. Cấu hình field-level encryption rồi gỡ quyền công khai — mã hoá ở mức trường dành cho dữ liệu người dùng gửi lên qua biểu mẫu.

Ghi nhớ

⚠ Ba cơ chế bảo vệ nội dung qua CloudFront — bảng phải thuộc: | Cơ chế | Chặn gì | |---|---| | OAC (hoặc OAI) | truy cập THẲNG vào S3 | | Signed URL / cookie | người không được cấp quyền | | Geo restriction | theo quốc gia |

Từ khoá nhận diện:

"prevent bypassing CloudFront" → OAC + gỡ quyền công khai "only specific users can view" → signed URL "whole content library for subscribers" → signed cookie "encrypt form data at the edge" → field-level encryption

Ba lưu ý về OAC: | Lưu ý | Chi tiết | |---|---| | SigningBehavior: always cho hầu hết trường hợp | | | Hỗ trợ cả origin không phải S3 | | | Bucket policy phải có AWS:SourceArn | |

⚠ Với bucket SSE-KMS cần thêm quyền trong KEY POLICY:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "kms:Decrypt", "Resource": "*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "<arn-phan-phoi>"}}}

Thiếu: CloudFront trả 403 dù
  bucket policy đã đúng
    → và thông báo lỗi không nói gì
      về KMS

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 cản trở OAC | | | Bật mặc định cho bucket tạo từ 2023 | |

Ba lưu ý về S3 website endpoint: | Lưu ý | Chi tiết | |---|---| | OAC KHÔNG dùng được với website endpoint | | | Website endpoint luôn công khai và chỉ HTTP | | | Dùng REST endpoint để có OAC | |

⚠ Cần index.html tự động cho thư mục con:

function handler(su_kien) {
  var yeu_cau = su_kien.request;
  if (yeu_cau.uri.endsWith('/'))
    yeu_cau.uri += 'index.html';
  return yeu_cau;
}

Website endpoint làm sẵn việc này
    → nhưng mất OAC
        ↓
    REST endpoint + CloudFront Functions
    → có cả hai

Ba lưu ý về ghi nhật ký: | Lưu ý | Chi tiết | |---|---| | CloudFront standard log vào S3 | | | CloudTrail data event cho tầng S3 | | | Biết ai tải báo cáo nào, lúc nào | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | TTL dài cho báo cáo không đổi | | | Bật nén cho tệp văn bản | | | Origin Shield nếu nhân viên trải nhiều châu lục | |

Ba lưu ý về chuyển từ OAI sang OAC: | Lưu ý | Chi tiết | |---|---| | Tạo OAC mới và gắn vào origin | | | Cập nhật bucket policy | | | Gỡ OAI cũ sau khi kiểm chứng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl URL S3 trực tiếp — phải 403 | | | curl URL CloudFront — phải 200 | | | Kiểm bucket không còn quyền công khai nào | |

Và một lời khuyên: hãy dùng OAC thay vì OAI cho mọi thiết kế mới. Chúng giải quyết cùng một bài toán, nhưng chỉ OAC đọc được bucket mã hoá bằng SSE-KMS — và với dữ liệu tài chính hay tuân thủ thì mã hoá bằng khoá riêng gần như luôn là yêu cầu.

Câu 254 Domain - Continuous Improvement for Existing Solutions

A big fast-food chain in Asia is planning to implement a location-based alert on their existing mobile app. If a user is in proximity to one of its restaurants, an alert will be shown on the user’s mobile phone. The notification needs to happen in less than a minute while the user is still in the vicinity. Currently, the mobile app has 10 million users in the Philippines, China, Korea, and other Asian countries.

Which one of the following AWS architecture is the most suitable option for this scenario?

  1. A

    Establish connectivity with mobile carriers using AWS Direct Connect. Set up an API on all EC2 instances to receive the location data from the mobile app via the carrier's GPS connection. Use RDS to store the data and fetch relevant offers from the restaurant. The EC2 instances will communicate with mobile carriers to send alerts to the mobile app.
  2. B

    The mobile app will send the real-time location data using Amazon Kinesis. Set up an API which uses an Application Load Balancer and an Auto Scaling group of EC2 instances to retrieve the relevant offers from a DynamoDB table. Use Amazon Lambda and SES to push the notification to the mobile app.
  3. C

    The mobile app will send device location to an SQS endpoint. Set up an API that utilizes an Application Load Balancer and an Auto Scaling group of EC2 instances, which will retrieve the relevant offers from DynamoDB. Use Amazon SNS to send offers to the mobile app.
  4. D Set up an API that uses an Application Load Balancer and an Auto Scaling group of EC2 instances. The mobile app will send the user's location data to the API web service. Use DynamoDB to store and retrieve relevant offers on the nearest restaurant. Configure the EC2 instances to push alerts to the mobile app.
Xem giải thích

Đáp án

**C — Ứng dụng di động gửi vị trí thiết bị tới một endpoint SQS; dựng API dùng Application Load Balancer và Auto Scaling group EC2 để lấy ưu đãi phù hợp từ DynamoDB; và dùng Amazon SNS đẩy ưu đãi về ứng dụng.

Vì sao đúng

Đề nêu bốn ràng buộc, và phương án này khớp từng cái: | Ràng buộc | Cách đáp ứng | |---|---| | 10 triệu người dùng gửi vị trí | SQS làm bộ đệm cho lượng ghi lớn | | Thông báo trong dưới một phút | SNS đẩy trực tiếp tới thiết bị | | Tra cứu ưu đãi theo vị trí | DynamoDB, độ trễ mili giây | | Nhiều quốc gia châu Á | kiến trúc co giãn được |

⚠ SNS là dịch vụ DUY NHẤT đẩy thông báo tới ứng dụng di động:

SNS Mobile Push hỗ trợ FCM (Android),
  APNs (iOS)
        ↓
    Đẩy thông báo tới thiết bị
      trong vài giây
        ↓
    SES gửi EMAIL — không phải
      thông báo đẩy

Đây là lý do phương án B sai — nó dùng SES.

⚠ Và hàng đợi là thứ chịu được 10 triệu người dùng gửi vị trí:

Gửi thẳng vào API
    → đỉnh tải đập vào tầng ứng dụng
    → mất dữ liệu vị trí khi quá tải
        ↓
    SQS: nhận ngay, xếp hàng
    → tầng xử lý làm theo tốc độ
      của mình

Đây là lý do phương án D yếu hơn — không có bộ đệm nào.

Đẩy thông báo:

aws sns publish --target-arn <arn-endpoint-thiet-bi> \
  --message '{"GCM":"{\"notification\":
    {\"title\":\"Uu dai gan ban\",
     \"body\":\"Giam 20% tai chi nhanh Quan 1\"}}"}' \
  --message-structure json

Đăng ký thiết bị:

aws sns create-platform-endpoint \
  --platform-application-arn <arn-fcm> \
  --token <token-thiet-bi>

⚠ Và DynamoDB với chỉ mục địa lý là cách tra cứu nhanh:

Khoá phân vùng = ô lưới địa lý
  (geohash)
    → khoá sắp xếp = mã chi nhánh
        ↓
    Truy vấn một ô lưới
    → trả về mọi chi nhánh trong đó
    → độ trễ mili giây

⚠ Geohash là kỹ thuật chuẩn cho tra cứu theo vị trí:

Toạ độ (10.7769, 106.7009)
    → geohash "w3gvk8"
        ↓
    Chi nhánh gần nhau có geohash
      giống nhau ở các ký tự đầu
    → truy vấn theo tiền tố

⚠ Và ràng buộc "dưới một phút" là chỗ phải tính:

Ứng dụng gửi vị trí → SQS
    ↓ (vài giây)
EC2 kéo và tra cứu DynamoDB
    ↓ (mili giây)
SNS đẩy thông báo
    ↓ (vài giây)
Thiết bị nhận
        ↓
    Tổng: dưới một phút với biên
      an toàn rộng

⚠ Nhưng phải co giãn theo độ dài hàng đợi:

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

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hàng đợi hấp thụ đỉnh tải vị trí | | | SNS đẩy thông báo tới cả iOS lẫn Android | | | DynamoDB tra cứu nhanh ở mọi quy mô | |

⚠ Và Direct Connect tới nhà mạng (phương án A) là kiến trúc không tồn tại:

"Nối với nhà mạng di động bằng
  Direct Connect để nhận dữ liệu
  GPS"
        ↓
    Ứng dụng lấy GPS từ CHÍNH thiết bị
    → không qua nhà mạng
        ↓
    Và không có cơ chế nào để EC2
      "nói chuyện với nhà mạng để
      gửi thông báo"

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

⚠ Amazon Pinpoint và Amazon Location Service là công cụ hiện đại cho bài toán này.

Nhu cầu Dịch vụ hiện nay
Thông báo đẩy có phân khúc Amazon Pinpoint
Theo dõi vị trí và geofence Amazon Location Service
Tính khoảng cách, tìm điểm gần Location Service Places API

⚠ Location Service có geofencing dựng sẵn:

aws location put-geofence \
  --collection-name chi-nhanh \
  --geofence-id chi-nhanh-q1 \
  --geometry Circle="{Center=[106.7009,10.7769],Radius=200}"

Thiết bị vào vùng geofence
    → Location Service phát sự kiện
      EventBridge
        ↓
    Không phải tự viết logic tính
      khoảng cách
    → và không phải tự dựng chỉ mục
      địa lý trong DynamoDB

⚠ Và Pinpoint hơn SNS Mobile Push ở ba điểm: | Tiêu chí | SNS Mobile Push | Pinpoint | |---|---|---| | Gửi thông báo đẩy | có | có | | Phân khúc người dùng | không | CÓ | | Thống kê mở, bấm | không | CÓ | | Đa kênh (SMS, email, in-app) | một phần | đầy đủ |

Ứng dụng khuyến mãi cần biết ai
  đã mở thông báo
    → Pinpoint
        ↓
    SNS chỉ gửi, không đo được
      hiệu quả

Đáp án C vẫn là lựa chọn đúng trong bốn phương án, nhưng thiết kế thật ngày nay sẽ dùng Location Service cộng Pinpoint.

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

  • **D. Dựng API với ALB và ASG EC2, ứng dụng gửi vị trí thẳng tới API, dùng DynamoDB, và EC2 tự đẩy cảnh báo về ứng dụng — đây là phương án gần nhất và phần API cùng DynamoDB đúng, nhưng thiếu bộ đệm cho 10 triệu người dùng, và EC2 không tự đẩy thông báo tới thiết bị di động được; phải qua SNS hoặc Pinpoint.
  • **B. Gửi vị trí qua Kinesis, dùng ALB và ASG lấy ưu đãi từ DynamoDB, dùng Lambda và SES đẩy thông báo — Kinesis là lựa chọn hợp lý, nhưng SES gửi email chứ không đẩy thông báo tới ứng dụng.
  • **A. Nối với nhà mạng bằng Direct Connect, nhận GPS qua nhà mạng, dùng RDS, và EC2 "nói chuyện với nhà mạng" để gửi cảnh báo — mô tả một kiến trúc không tồn tại.

Ghi nhớ

⚠ Bốn dịch vụ nhắn tin và vai trò — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | SNS | ĐẨY thông báo tới nhiều đích | | SQS | hàng đợi, đệm tải | | SES | gửi EMAIL | | Pinpoint | thông báo có phân khúc và thống kê |

Từ khoá nhận diện:

"push notification to mobile app" → SNS Mobile Push hoặc Pinpoint "buffer high volume writes" → SQS "send email" → SES "geofencing, location tracking" → Amazon Location Service

Ba lưu ý về SNS Mobile Push: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ FCM, APNs, ADM, Baidu | | | Endpoint hỏng phải dọn định kỳ | | | Định dạng thông điệp khác nhau theo nền tảng | |

⚠ Endpoint hỏng tích tụ nếu không dọn:

try:
    sns.publish(TargetArn=arn, Message=tin)
except sns.exceptions.EndpointDisabledException:
    xoa_endpoint(arn)

Người dùng gỡ ứng dụng
    → token không còn hợp lệ
    → SNS đánh dấu Disabled
        ↓
    Không dọn: danh sách phình mãi

Ba lưu ý về DynamoDB cho dữ liệu vị trí: | Lưu ý | Chi tiết | |---|---| | Geohash làm khoá phân vùng | | | On-demand cho tải khó đoán | | | TTL tự xoá vị trí cũ | |

⚠ TTL rất quan trọng với dữ liệu vị trí:

10 triệu người dùng gửi vị trí
  liên tục
        ↓
    Không xoá: bảng phình vô hạn
    → TTL 24 giờ giữ bảng nhỏ

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Standard cho thông lượng vô hạn | | | Long polling giảm chi phí | | | Co giãn ASG theo backlog per instance | |

Ba lưu ý về quyền riêng tư: | Lưu ý | Chi tiết | |---|---| | Dữ liệu vị trí là dữ liệu cá nhân nhạy cảm | | | Mã hoá khi lưu và khi truyền | | | Xin phép người dùng rõ ràng | |

⚠ Đây là rủi ro tuân thủ thật sự:

Lịch sử vị trí của 10 triệu người
    → thuộc phạm vi luật bảo vệ
      dữ liệu ở nhiều nước
        ↓
    Chỉ giữ trong thời gian cần thiết
    → và cho người dùng tắt được

Ba lưu ý về độ trễ: | Lưu ý | Chi tiết | |---|---| | Đo từ lúc gửi tới lúc thiết bị nhận | | | Hàng đợi dồn là nguyên nhân chậm chính | | | Cảnh báo trên tuổi thông điệp cũ nhất | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian từ gửi vị trí tới nhận thông báo | | | Đẩy tải cao, xem hàng đợi có dồn | | | Thử nhận thông báo trên cả iOS và Android | |

Và một lời khuyên: hãy cân nhắc Amazon Location Service thay vì tự dựng chỉ mục địa lý trong DynamoDB. Geofencing, tính khoảng cách và phát sự kiện khi thiết bị vào vùng đều là tính năng có sẵn — còn tự làm nghĩa là tự bảo trì cả thuật toán geohash lẫn logic xác định "gần".

Câu 255 Domain - Design for New Solutions

A consumer goods company runs its e-commerce website entirely on its on-premises data center with high-resolution photos and videos. Due to the unprecedented growth of their popular product, they are expecting an increase in incoming traffic to their website across the globe in the coming days. The CTO requested to urgently do the necessary architectural changes to be able to handle the demand. The solutions architect suggested migrating the application to AWS, but the CTO decided that they need at least 3 months to implement a hybrid cloud architecture.

What could the solutions architect do with the current on-premises website to help offload some of the traffic and scale out to meet the demand in a cost-effective way?

  1. A

    Use AWS Transit Gateway to establish a dedicated connection with the on-premises website and to manage and configure the servers with AWS App Runner to meet the demand.
  2. B

    Rehost the website to an S3 bucket with website hosting enabled. Create a CloudFront distribution with the S3 endpoint as the origin. Set up Origin Shield and launch a CloudFront Function to offload the DNS to AWS to handle CloudFront traffic.
  3. C

    Launch a CloudFront web distribution with the URL of the on-premises web application as the origin. Offload the DNS to AWS to handle CloudFront traffic.
  4. D

    Replicate the current web infrastructure of the on-premises website on AWS. Offload the DNS to Route 53 and configure weight-based DNS routing to send 50% of the traffic to AWS.
Xem giải thích

Đáp án

**C — Dựng một phân phối CloudFront với URL của ứng dụng web tại chỗ làm origin, và chuyển DNS sang AWS để xử lý lưu lượng CloudFront.

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:

CTO nói cần ÍT NHẤT BA THÁNG
  để dựng kiến trúc lai
        ↓
    Nhưng lưu lượng tăng "trong
      vài ngày tới"
        ↓
    Phải làm được ngay bây giờ
    → không phải dự án di chuyển

⚠ CloudFront với custom origin làm được trong vài ngày:

Origin không nhất thiết 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 hiện có
        ↓
    Không đụng một dòng nào của
      ứng dụng

Cấu hình custom origin:

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

⚠ Và đề nói website có ảnh và video ĐỘ PHÂN GIẢI CAO — đây là dữ kiện quyết định:

Ảnh và video chiếm phần lớn
  dung lượng mỗi trang
        ↓
    Chúng gần như không đổi
    → cache được với TTL rất dài
        ↓
    Phần lớn lưu lượng không bao giờ
      chạm tới máy chủ tại chỗ

Cache behavior theo loại nội dung:

{"CacheBehaviors": {"Items": [
  {"PathPattern": "/media/*", "TargetOriginId": "web-tai-cho",
   "CachePolicyId": "<ttl-mot-nam>", "Compress": false},
  {"PathPattern": "/gio-hang/*", "TargetOriginId": "web-tai-cho",
   "CachePolicyId": "<khong-cache>"}]},
 "DefaultCacheBehavior": {"TargetOriginId": "web-tai-cho"}}

⚠ Và CloudFront giúp cả nội dung KHÔNG cache được:

1. TLS chấm dứt ở biên gần người dùng
   → bắt tay nhanh hơn nhiều
        ↓
2. Đi tiếp trên mạng xương sống AWS
   → nhanh hơn Internet công cộng
        ↓
3. Kết nối keepalive tới origin
   → bớt số kết nối mới phải mở

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

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 video
        ↓
    Có Shield: chỉ MỘT yêu cầu tới
      origin
    → giảm mạnh tải cho đường truyền
      tại chỗ

{"OriginShield": {"Enabled": true,
                  "OriginShieldRegion": "ap-southeast-1"}}

⚠ Và phương án B đòi dựng lại toàn bộ website:

"Rehost website lên S3 với website
  hosting"
        ↓
    Website thương mại điện tử có
      giỏ hàng, thanh toán
    → cần logic phía máy chủ
        ↓
    S3 chỉ phục vụ nội dung TĨNH
    → mất chức năng, không phải
      "thay đổi kiến trúc gấp"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Triển khai trong vài ngày, kịp đợt tăng tải | | | Không đụng vào hệ thống hiện có | | | Shield Standard chống DDoS miễn phí đi kèm | |

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

CloudFront giảm tải cho nội dung
  tĩnh
        ↓
    Trang giỏ hàng và thanh toán
      vẫn gọi CSDL tại chỗ
    → đó là chỗ sẽ gãy trước
        ↓
    Chạy thử tải trước ngày cao điểm

⚠ Và phải 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 đó
        ↓
    Người dùng gọi thẳng origin
    → bị chặn
        ↓
    Nếu không: lưu lượng vẫn đập
      thẳng vào máy chủ

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

  • **B. Chuyển website sang bucket S3 với website hosting, CloudFront với S3 làm origin, bật Origin Shield và CloudFront Function — đây là phương án gần nhất và có CloudFront cùng Origin Shield đúng, nhưng chuyển website thương mại điện tử sang S3 tĩnh là mất chức năng giỏ hàng và thanh toán; và đó là dự án lớn chứ không phải thay đổi gấp.
  • **D. Nhân bản toàn bộ hạ tầng lên AWS và dùng Route 53 weighted routing chia 50% lưu lượng — đây chính là dự án ba tháng mà CTO đã nói là không kịp.
  • **A. Dùng Transit Gateway để nối với website tại chỗ và App Runner quản lý máy chủ — Transit Gateway là dịch vụ mạng nội bộ, không phân phối nội dung; và App Runner chạy container trên AWS, không quản lý máy chủ tại chỗ.

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:

"offload traffic quickly, no time to migrate" → CloudFront trước hệ thống hiện có "on-premises origin" → custom origin "reduce origin load" → TTL dài, Origin Shield "static website only" → S3 website hosting

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

Ba lưu ý về Origin Shield: | Lưu ý | Chi tiết | |---|---| | Thêm một tầng cache khu vực | | | Chọn Region gần origin nhất | | | Có phí nhưng đáng với origin yếu | |

⚠ Chọn Region cho Origin Shield:

Origin ở trung tâm dữ liệu tại Việt Nam
    → chọn ap-southeast-1
        ↓
    Chọn Region xa
    → thêm một chặng độ trễ vô ích

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 |

⚠ Nếu origin không gửi header cache:

Đặt `DefaultTTL` dài trong
  cache policy
        ↓
    Không phải sửa máy chủ tại chỗ
    → CloudFront tự quyết định
      thời gian cache

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 phá hỏng cache | | | Tách cache policy khỏi origin request policy | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Truyền qua CloudFront rẻ hơn từ origin | | | Phần đã cache không tính truyền từ origin | | | Price class giới hạn được phạm vi điểm biên | |

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 | | 5xxErrorRate | origin có đang chết không |

⚠ Phải bật chỉ số bổ sung mới thấy CacheHitRate:

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

Ba lưu ý về bước tiếp theo: | Bước | Thời điểm | |---|---| | CloudFront ngay bây giờ | giải quyết đợt tăng tải | | Chuyển nội dung tĩnh sang S3 | vài tuần sau | | Di chuyển ứng dụng và CSDL | theo kế hoạch ba tháng |

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 cao điểm | |

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

Câu 256 Domain - Continuous Improvement for Existing Solutions

A fintech startup has several resources provisioned on the AWS cloud. The majority of the company’s compute clusters are composed of an Application Load Balancer (ALB) in front of an Auto Scaling group of On-Demand Amazon EC2 instances. To lower down the overall cost, the management wants to have one EC2 instance terminated whenever the overall CPU utilization of the cluster is at 15% or lower.

Which of the following options should the solutions architect implement for a cost-effective and scalable architecture that satisfies the company requirement?

  1. A Use AWS Lambda triggers to send a notification to the Auto Scaling group when the CPU utilization is less than 15% to kick off the scaling in policy to remove the EC2 instance.
  2. B Use scheduled actions in the Auto Scaling configuration to automatically terminate EC2 instances when the CPU Utilization hits below 15%.
  3. C Use CloudWatch for the monitoring and configure the scaling in policy of the Auto Scaling group to terminate one EC2 instance when the CPU Utilization is 15% or below.
  4. D Configure a monitoring script that sends out an email using SNS when the CPU utilization is less than 15% so the administrator can manually remove an EC2 instance.
Xem giải thích

Đáp án

**C — Dùng CloudWatch để giám sát và cấu hình chính sách scale-in của Auto Scaling group thu hồi một EC2 khi mức sử dụng CPU đạt 15% hoặc thấp hơn.

Vì sao đúng

Đề mô tả đúng một chức năng có sẵn của Auto Scaling:

ASG đã có sẵn cơ chế co giãn
  theo chỉ số CloudWatch
        ↓
    Không cần Lambda, không cần
      script, không cần ai bấm nút
        ↓
    Khai một chính sách là xong

⚠ ASG tự đăng ký chỉ số và tự hành động:

CloudWatch alarm kích hoạt
    → ASG nhận sự kiện
    → thu hồi instance theo chính sách
      thu hồi đã cấu hình
        ↓
    Toàn bộ trong một dịch vụ

Chính sách theo bước:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-ung-dung \
  --policy-name thu-nho-khi-cpu-thap \
  --policy-type StepScaling \
  --adjustment-type ChangeInCapacity \
  --step-adjustments \
    MetricIntervalUpperBound=0,ScalingAdjustment=-1

Gắn với alarm:

aws cloudwatch put-metric-alarm \
  --alarm-name cpu-duoi-15 \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=AutoScalingGroupName,Value=asg-ung-dung \
  --statistic Average --period 300 --threshold 15 \
  --comparison-operator LessThanOrEqualToThreshold \
  --evaluation-periods 3 \
  --alarm-actions <arn-chinh-sach>

⚠ evaluation-periods 3 tránh co giãn dao động:

Kiểm tra một chu kỳ rồi thu hồi
    → CPU dao động tự nhiên
    → thu hồi rồi lại thêm liên tục
        ↓
    Ba chu kỳ liên tiếp dưới ngưỡng
    → chắc chắn tải thật sự thấp

⚠ Và scheduled action (phương án B) hoạt động theo GIỜ, không theo chỉ số:

`put-scheduled-update-group-action`
    → đặt công suất vào một MỐC
      THỜI GIAN
        ↓
    Không có cách nào cho nó phản
      ứng theo CPU
    → "scheduled action khi CPU
      dưới 15%" là thứ không tồn tại

⚠ Và Lambda gửi thông báo tới ASG (phương án A) là làm vòng:

CloudWatch alarm đã gọi thẳng được
  chính sách co giãn
        ↓
    Chèn Lambda vào giữa
    → thêm một chỗ hỏng
    → thêm mã phải bảo trì

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không viết dòng mã nào | | | Tự động, không cần ai trực | | | Dùng đúng cơ chế có sẵn của ASG | |

⚠ Nhưng target tracking thường tốt hơn step scaling:

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

Target tracking: chỉ khai MỤC TIÊU
    → ASG tự tính thêm bớt bao nhiêu
        ↓
    Step scaling: phải tự thiết kế
      từng bậc
    → nhiều việc hơn, dễ sai hơn

⚠ Và phải đặt MinSize để không thu hồi hết máy:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-ung-dung \
  --min-size 2 --max-size 20

Không có min: ASG thu hồi tới
  còn 0 máy
        ↓
    Đêm không ai truy cập
    → CPU 0%
    → không còn máy nào phục vụ
      sáng hôm sau

⚠ Và cooldown tránh thu hồi liên tiếp:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-ung-dung \
  --default-cooldown 300

Thu hồi một máy
    → CPU của các máy còn lại tăng
        ↓
    Chờ 300 giây rồi mới đánh giá lại
    → tránh thu hồi quá tay

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

  • **A. Dùng Lambda gửi thông báo tới ASG khi CPU dưới 15% để kích hoạt chính sách scale-in — đây là phương án gần nhất và kết quả cuối cùng giống nhau, nhưng CloudWatch alarm gọi thẳng được chính sách co giãn; chèn Lambda vào giữa là thêm mã và thêm chỗ hỏng không cần thiết.
  • **B. Dùng scheduled action để tự thu hồi EC2 khi CPU dưới 15% — scheduled action đặt công suất theo mốc thời gian, không phản ứng theo chỉ số.
  • **D. Viết script gửi email qua SNS để quản trị viên tự gỡ instance — thủ công, không co giãn, và trái với yêu cầu tự động.

Ghi nhớ

⚠ Bốn loại chính sách co giãn — bảng phải thuộc: | Chính sách | Cách hoạt động | |---|---| | Target tracking | giữ chỉ số ở mức mục tiêu — đơn giản nhất | | Step scaling | thêm bớt theo bậc tuỳ mức vượt ngưỡng | | Simple scaling | một hành động mỗi lần, có cooldown | | Scheduled | theo LỊCH, không theo chỉ số |

Từ khoá nhận diện:

"terminate instance when CPU is low" → scale-in policy của ASG "scale at a specific time" → scheduled action "recurring daily pattern" → predictive scaling "keep CPU at 50%" → target tracking

Ba lưu ý về chính sách thu hồi: | Chính sách | ASG thu hồi máy nào | |---|---| | Default | cân bằng AZ, rồi máy có launch config cũ nhất | | OldestInstance | máy chạy lâu nhất | | NewestInstance | máy mới nhất | | ClosestToNextInstanceHour | máy sắp hết giờ tính phí |

⚠ OldestInstance hữu ích khi thay AMI:

Muốn thay dần máy cũ bằng AMI mới
    → đặt chính sách thu hồi
      `OldestInstance`
        ↓
    Mỗi lần thu nhỏ là bớt một
      máy cũ

Ba lưu ý về lifecycle hook: | Lưu ý | Chi tiết | |---|---| | Chạy trước khi instance bị thu hồi | | | Dùng để hoàn tất việc đang xử lý | | | Phải gọi complete-lifecycle-action khi xong | |

⚠ Thiếu lifecycle hook là cắt việc giữa chừng:

ASG thu hồi máy đang xử lý request
    → người dùng nhận lỗi
        ↓
    Lifecycle hook: rút khỏi target
      group, chờ kết nối xong
    → rồi mới thu hồi

Ba lưu ý về deregistration_delay: | Lưu ý | Chi tiết | |---|---| | ALB chờ trước khi gỡ target | | | Mặc định 300 giây | | | Đặt bằng thời gian request dài nhất | |

Ba lưu ý về giám sát chi phí: | Công cụ | Việc | |---|---| | Cost Explorer | xu hướng chi phí theo dịch vụ | | Compute Optimizer | gợi ý loại instance đúng | | Savings Plan | giảm giá cho phần tải nền |

⚠ Thu nhỏ đúng cách chỉ là một nửa việc tối ưu chi phí:

Co giãn tốt nhưng dùng loại
  instance sai
        ↓
    Compute Optimizer phân tích
      chỉ số thật
    → gợi ý loại rẻ hơn cho cùng
      hiệu năng

Ba lưu ý về chỉ số co giãn: | Chỉ số | Phù hợp khi | |---|---| | ASGAverageCPUUtilization | tải phụ thuộc CPU | | ALBRequestCountPerTarget | tải phụ thuộc số request | | Chỉ số tuỳ chỉnh | tải phụ thuộc hàng đợi hoặc thứ khác |

⚠ CPU không phải lúc nào cũng là chỉ số đúng:

Ứng dụng chờ I/O nhiều
    → CPU thấp nhưng đã quá tải
        ↓
    Co giãn theo CPU sẽ thu hồi máy
      đúng lúc cần thêm
    → dùng số request hoặc độ trễ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giảm tải nhân tạo, xem ASG có thu nhỏ | | | Kiểm không thu hồi xuống dưới MinSize | | | Xem có dao động thêm-bớt liên tục không | |

Và một lời khuyên: hãy dùng target tracking thay vì step scaling trừ khi có lý do cụ thể. Nó chỉ cần một con số mục tiêu, tự tính toán số máy cần thêm bớt, và tránh được phần lớn lỗi thiết kế bậc mà step scaling hay gặp.

Câu 257 Domain - Continuous Improvement for Existing Solutions

A company launched a high-performance computing (HPC) application inside the VPC of its AWS account. The application is composed of hundreds of private EC2 instances running in a cluster placement group, which allows the instances to communicate with each other at network speeds of up to 10 Gbps. There is also a custom cluster controller EC2 instance that closely controls and monitors the system performance of each instance. The cluster controller has the same instance type and AMI as the other instances. It is configured with a public IP address and runs outside the placement group. The Solutions Architect has been tasked to improve the network performance between the controller instance and the EC2 instances in the placement group.

Which option provides the MOST suitable solution that the Architect must implement to satisfy the requirement while maintaining low-latency network performance?

  1. A

    Attach an Elastic IP address to the custom cluster controller instance to increase its network capability to 10 Gbps.
  2. B

    Terminate the custom cluster controller EC2 instance and stop all of the running instances in the existing placement group. Move the cluster controller instance to the existing placement group and restart all of the instances.
  3. C

    Terminate the custom cluster controller instance and re-launch it to the existing placement group. Attach an Elastic Network Adapter (ENA) to the cluster controller instance to increase its network performance. Change the placement strategy of the placement group to Spread.
  4. D

    Stop the custom cluster controller instance and move it to the existing placement group.
Xem giải thích

Đáp án

**D — Dừng instance cluster controller rồi chuyển nó vào placement group đã có.

Vì sao đúng

Đề hỏi cách cải thiện hiệu năng mạng giữa controller và cụm, và có đúng một cách:

Instance nằm NGOÀI cluster placement
  group
        ↓
    Không được đặt gần các instance
      khác về mặt vật lý
    → độ trễ cao hơn, băng thông
      thấp hơn
        ↓
    Đưa nó VÀO group là xong

⚠ Và AWS cho phép chuyển instance ĐANG DỪNG vào placement group:

aws ec2 stop-instances --instance-ids i-controller

aws ec2 modify-instance-placement \
  --instance-id i-controller \
  --group-name nhom-cum-hpc

aws ec2 start-instances --instance-ids i-controller

⚠ Đây là điều nhiều người không biết — tưởng phải tạo lại instance:

`modify-instance-placement` hoạt động
  với instance đã DỪNG
        ↓
    Không phải thu hồi và tạo lại
    → giữ nguyên volume, IP riêng,
      cấu hình
        ↓
    Đây là lý do phương án B và C
      làm thừa việc

⚠ Và KHÔNG cần dừng các instance khác:

Phương án B nói phải "dừng toàn bộ
  instance trong placement group"
        ↓
    Không cần
    → chỉ dừng instance cần chuyển
        ↓
    Với cụm HPC hàng trăm máy
    → dừng hết là gián đoạn rất lớn

⚠ Và Elastic IP không liên quan gì tới băng thông:

Elastic IP: địa chỉ công khai tĩnh
    → không ảnh hưởng tốc độ mạng
        ↓
    "Gắn EIP để tăng lên 10 Gbps"
      là mô tả sai hoàn toàn

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

⚠ Và đổi sang Spread placement group là đi ngược mục tiêu: | Loại | Đặt ở đâu | Dùng cho | |---|---|---| | Cluster | cùng rack, GẦN nhau | HPC, độ trễ thấp | | Spread | phần cứng RIÊNG BIỆT | chịu lỗi, ít instance | | Partition | nhóm phân vùng riêng | HDFS, Cassandra |

Spread cố tình TÁCH các instance ra
    → tăng độ trễ giữa chúng
        ↓
    Ngược hẳn với "duy trì hiệu năng
      độ trễ thấp"

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

⚠ Và ENA đã có sẵn trên hầu hết instance hiện đại:

Elastic Network Adapter là driver
  mạng tiêu chuẩn
        ↓
    Mọi loại instance thế hệ mới
      đều bật sẵn
    → "gắn thêm ENA" không phải
      thao tác có ý nghĩa

⚠ Nhưng phải nhớ ràng buộc của cluster placement group:

Chỉ trong MỘT vùng sẵn sàng
    → mọi instance phải cùng AZ
        ↓
    Controller ở AZ khác
    → không chuyển vào được
    → phải tạo lại ở đúng AZ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giữ nguyên instance, volume và cấu hình | | | Không đụng tới các instance khác | | | Chỉ gián đoạn thời gian khởi động lại một máy | |

⚠ Và có thể đặt controller trong group mà vẫn có IP công khai:

Đề nói controller có IP công khai
    → placement group không ảnh hưởng
      địa chỉ IP
        ↓
    Instance trong cluster placement
      group vẫn gán được Elastic IP

⚠ Và với HPC nên cân nhắc EFA thay vì ENA thường:

ENA: đi qua ngăn xếp TCP/IP của
  hệ điều hành
        ↓
    EFA: OS bypass — ứng dụng nói
      thẳng với phần cứng mạng
    → độ trễ thấp hơn nhiều
        ↓
    Nhưng chỉ ứng dụng dùng Libfabric
      (MPI, NCCL) mới hưởng lợi

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

  • **B. Thu hồi controller và DỪNG TOÀN BỘ instance trong placement group, chuyển controller vào rồi khởi động lại tất cả — đây là phương án gần nhất và kết quả cuối cùng đúng, nhưng không cần dừng các instance khác; và thu hồi controller là mất dữ liệu cùng cấu hình không cần thiết.
  • **C. Thu hồi controller và tạo lại trong placement group, gắn ENA, đổi chiến lược sang Spread — ENA đã có sẵn, và Spread cố tình tách các instance ra, làm tăng độ trễ.
  • **A. Gắn Elastic IP để "tăng năng lực mạng lên 10 Gbps" — địa chỉ IP không ảnh hưởng băng thông.

Ghi nhớ

⚠ Ba loại placement group — bảng phải thuộc: | Loại | Mục đích | Ràng buộc | |---|---|---| | Cluster | độ trễ thấp, băng thông cao | MỘT AZ | | Spread | cô lập lỗi tối đa | tối đa 7 instance mỗi AZ | | Partition | nhóm theo phân vùng | tối đa 7 phân vùng mỗi AZ |

Từ khoá nhận diện:

"low latency between instances" → cluster placement group "maximum fault isolation" → spread placement group "HDFS, Cassandra, Kafka" → partition placement group "MPI workload" → cluster placement group + EFA

Ba lưu ý về cluster placement group: | Lưu ý | Chi tiết | |---|---| | Chỉ trong một AZ | | | Khởi chạy hết instance cùng lúc để chắc đủ chỗ | | | Nên dùng cùng loại instance | |

⚠ Khởi chạy dần dễ bị InsufficientCapacity:

Khởi chạy 100 máy hôm nay
    → thêm 900 máy tuần sau
        ↓
    Rack đó có thể không còn chỗ
    → xin cả nghìn trong một lời gọi

Ba thao tác với placement group: | Thao tác | Điều kiện | |---|---| | Chuyển instance VÀO group | instance phải DỪNG | | Chuyển instance RA khỏi group | instance phải DỪNG | | Đổi loại placement group | KHÔNG được — phải tạo group mới |

aws ec2 modify-instance-placement \
  --instance-id i-abc --group-name ""

Chuỗi rỗng: gỡ instance khỏi
  placement group

Ba lưu ý về EFA: | Lưu ý | Chi tiết | |---|---| | Chỉ hỗ trợ một số loại instance | | | Cần cài Libfabric và EFA driver | | | Security group phải mở toàn bộ với chính nó | |

⚠ Security group của EFA là chỗ hay cấu hình thiếu:

aws ec2 authorize-security-group-ingress \
  --group-id sg-hpc --protocol -1 --source-group sg-hpc
aws ec2 authorize-security-group-egress \
  --group-id sg-hpc --protocol -1 --source-group sg-hpc

EFA dùng giao thức riêng, không
  phải TCP hay UDP
        ↓
    Không mở toàn bộ với chính nhóm
    → EFA không hoạt động
    → và lỗi rất khó lần

Ba lưu ý về băng thông mạng: | Lưu ý | Chi tiết | |---|---| | Băng thông phụ thuộc LOẠI instance | | | Instance nhỏ có băng thông burst | | | Cluster placement group cho băng thông tối đa giữa các máy | |

⚠ Băng thông của instance là trần cứng:

Loại instance nhỏ: 5 Gbps
    → đặt trong cluster placement group
      cũng không vượt được
        ↓
    Muốn 10 Gbps hay hơn
    → phải chọn loại instance đủ lớn

Ba lưu ý về HPC trên AWS: | Thành phần | Lựa chọn | |---|---| | Mạng | EFA + cluster placement group | | Lưu trữ | FSx for Lustre | | Điều phối | AWS ParallelCluster + Slurm |

Ba lưu ý về giám sát mạng: | Chỉ số | Ý nghĩa | |---|---| | NetworkIn / NetworkOut | băng thông đang dùng | | NetworkPacketsIn | số gói, quan trọng với gói nhỏ | | Benchmark MPI | đo độ trễ thật giữa các node |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ trước và sau khi chuyển vào group | | | Kiểm instance đã ở đúng placement group | | | Chạy benchmark băng thông giữa controller và node | |

Và một lời khuyên: hãy nhớ rằng modify-instance-placement hoạt động với instance đang dừng. Rất nhiều người tưởng phải thu hồi và tạo lại instance để đưa nó vào placement group — trong khi chỉ cần dừng, đổi, rồi khởi động lại là giữ nguyên được mọi thứ.

Câu 258 Domain - Continuous Improvement for Existing Solutions

An enterprise is in the process of integrating the systems of the smaller companies it has acquired in the past few months. The company wants to create an AWS Landing Zone that will allow hundreds of new employees to use their corporate credentials to log in to the AWS Console. The company is using a Microsoft Active Directory (AD) service for user authentication and has an AWS Direct Connect connection to AWS. The newly acquired companies come from a wide range of engineering fields so it is required that the solution will be able to federate third-party services and providers as well as custom applications.

Which of the following implementations will meet the company requirements with the LEAST amount of management overhead?

  1. A

    Create an Active Directory Federation Services (AD FA) with SAML 2.0 to connect the company Active Directory to AWS. Configure the AD FS to use Regex with the AD naming convention for the security group. This will allow federation on all AWS accounts. Configure single sign-on integrations for third party applications by adding them to the AD FS server.
  2. B

    Connect the company on-premises Active Directory using the AWS Directory Service AD connector to create a single sign-on experience for users. Configure IAM and service roles to enable federation support. Configure single sign-on integrations for connections with third-party applications.
  3. C

    Configure AWS IAM Identity Center with AWS Organizations to manage SSO access and permissions on AWS. Set up a two-way forest trust relationship between the AWS Directory service and the company Active Directory to allow users to use their corporate credentials when logging in to AWS. Leverage on the third-party integration support of AWS IAM Identity Center.
  4. D

    Create an Active Directory Federation Services (AD FS) portal page with the company branding. Integrate third-party applications on this portal with SAML 2.0 support. Use single sign-on with the AD FS to connect the company Active Directory to AWS. Configure the Identity Provider (IdP) to use form-based authentication with the portal page.
Xem giải thích

Đáp án

**C — Cấu hình AWS IAM Identity Center với AWS Organizations để quản lý truy cập SSO và quyền trên AWS; thiết lập quan hệ tin cậy hai chiều giữa AWS Directory Service và Active Directory của công ty để nhân viên dùng tài khoản công ty đăng nhập; và tận dụng hỗ trợ tích hợp bên thứ ba của IAM Identity Center.

Vì sao đúng

Đề nêu ba yêu cầu, và Identity Center khớp cả ba với ít công nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Hàng trăm nhân viên dùng tài khoản công ty đăng nhập AWS | Identity Center + tin cậy AD | | Liên kết với dịch vụ bên thứ ba và ứng dụng riêng | Identity Center làm IdP cho ứng dụng ngoài | | Ít công quản lý nhất | dịch vụ quản lý, không tự dựng AD FS |

⚠ Identity Center làm được CẢ HAI chiều — đây là điểm mấu chốt:

Chiều vào: nhân viên đăng nhập AWS
  bằng tài khoản AD
        ↓
    Chiều ra: Identity Center làm
      IdP cho ứng dụng SaaS
      (Salesforce, Slack, Box...)
      và ứng dụng SAML tự viết
        ↓
    Một dịch vụ cho cả hai

⚠ Và AD FS (phương án A, D) là dịch vụ phải TỰ VẬN HÀNH:

AD FS chạy trên máy chủ Windows
    → phải dựng, vá lỗi, làm HA
    → phải quản chứng chỉ ký
        ↓
    Và chứng chỉ đó hết hạn là
      TOÀN BỘ tổ chức mất đăng nhập

⚠ Và AD Connector (phương án B) KHÔNG lập được quan hệ tin cậy: | Loại thư mục | Tin cậy với AD tại chỗ | |---|---| | AWS Managed Microsoft AD | CÓ — forest trust | | AD Connector | KHÔNG — chỉ chuyển tiếp yêu cầu | | Simple AD | không |

Đề đòi quan hệ tin cậy
    → phải là Managed Microsoft AD
        ↓
    AD Connector chỉ là proxy
      xác thực

Lập quan hệ tin cậy:

aws ds create-trust \
  --directory-id d-1234567890 \
  --remote-domain-name tai-cho.congty.com \
  --trust-password '<mat-khau-tin-cay>' \
  --trust-direction Two-Way \
  --trust-type Forest \
  --conditional-forwarder-ip-addrs 10.0.0.10 10.0.0.11

⚠ conditional-forwarder-ip-addrs là chi tiết hay bị quên:

Managed AD phải phân giải được
  tên miền tại chỗ
        ↓
    Thiếu forwarder: tin cậy lập xong
      mà không đăng nhập được
    → lỗi rất khó lần

Chỉ định AD làm nguồn danh tính:

aws sso-admin ... # qua console: Identity source → Active Directory

Tạo permission set và gán:

aws sso-admin create-permission-set \
  --instance-arn <arn> --name KyThuatVien \
  --session-duration PT8H

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

⚠ Permission set là thứ tiết kiệm công nhất:

Tự dựng SAML federation
    → mỗi tài khoản một SAML provider
    → mỗi vai trò một trust policy
        ↓
    30 tài khoản × 8 nhóm quyền
    → 240 vai trò phải bảo trì
        ↓
    Identity Center: 8 permission set
    → gán cho nhóm ở tài khoản cần

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Miễn phí, AWS lo vận hành | | | Một nguồn danh tính cho cả AWS lẫn ứng dụng ngoài | | | Cổng đăng nhập chung liệt kê mọi tài khoản | |

⚠ Và aws sso login thay hẳn access key trong CLI:

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

Không còn tệp credentials chứa khoá
    → mở trình duyệt, đăng nhập, xong
    → credential tạm hết hạn theo phiên

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

  • **A. Dựng AD FS với SAML 2.0 nối AD công ty với AWS, dùng Regex theo quy ước đặt tên nhóm AD, và tích hợp SSO cho ứng dụng bên thứ ba trên máy chủ AD FS — đây là phương án gần nhất và là kiến trúc chuẩn TRƯỚC KHI có Identity Center, nhưng nó đòi tự dựng và vận hành máy chủ AD FS, tự quản chứng chỉ ký và tự làm HA; công quản lý cao hơn hẳn.
  • **D. Dựng cổng AD FS có thương hiệu công ty, tích hợp ứng dụng bên thứ ba với SAML, dùng xác thực dạng biểu mẫu — cùng gánh nặng vận hành AD FS, cộng thêm việc tự xây và bảo trì giao diện cổng.
  • **B. Dùng AD Connector tạo trải nghiệm SSO, cấu hình IAM role và service role — AD Connector không lập được quan hệ tin cậy, và không làm IdP cho ứng dụng bên thứ ba.

Ghi nhớ

⚠ Ba lựa chọn Directory Service — bảng phải thuộc: | Lựa chọn | Bản chất | Tin cậy được | |---|---|---| | Managed Microsoft AD | AD thật do AWS chạy | CÓ | | AD Connector | proxy tới AD tại chỗ | không | | Simple AD | Samba, tương thích một phần | không |

Từ khoá nhận diện:

"corporate credentials, least management overhead" → IAM Identity Center "trust relationship with on-premises AD" → Managed Microsoft AD "proxy authentication, no directory in cloud" → AD Connector "application end users" → Cognito

⚠ Ba nguồn danh tính của Identity Center: | Nguồn | Trường hợp | |---|---| | Thư mục có sẵn | không có IdP | | Active Directory | có AD tại chỗ hoặc Managed AD | | IdP bên ngoài | Okta, Entra ID, Ping |

Ba lưu ý về quan hệ tin cậy: | Lưu ý | Chi tiết | |---|---| | Forest trust, không phải external trust | | | Cần conditional forwarder cho DNS | | | Một chiều đủ và an toàn hơn hai chiều | |

⚠ Hai chiều có rủi ro đáng cân nhắc:

Hai chiều: AD tại chỗ cũng TIN CẬY
  môi trường AWS
        ↓
    Tài khoản bị chiếm trong AWS
    → thành đường vào mạng nội bộ
        ↓
    Một chiều (AWS tin AD tại chỗ)
      đủ cho việc đăng nhập

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

Ba lưu ý về ABAC với Identity Center: | Lưu ý | Chi tiết | |---|---| | Truyền thuộc tính AD thành thẻ phiên | | | Một permission set cho nhiều phòng ban | | | Giảm mạnh số permission set phải quản | |

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

Ba lưu ý về ứng dụng bên thứ ba: | Lưu ý | Chi tiết | |---|---| | Identity Center làm IdP SAML 2.0 | | | Có danh mục ứng dụng SaaS dựng sẵn | | | Ứng dụng tự viết dùng SAML hoặc OIDC | |

Ba lưu ý về MFA: | Lưu ý | Chi tiết | |---|---| | Bắt buộc ở tầng AD hoặc Identity Center | | | Ưu tiên WebAuthn hơn TOTP | | | Áp cho mọi permission set quyền cao | |

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

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

Ba lưu ý về kết nối tới AD tại chỗ: | Lưu ý | Chi tiết | |---|---| | Đề nói đã có Direct Connect — dùng nó | | | Mở đủ cổng AD giữa hai bên | | | AD tại chỗ sập là không ai đăng nhập được | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập bằng tài khoản AD tại chỗ | | | Khoá tài khoản đó, thử lại — phải bị từ chối | | | Kiểm aws ds describe-trusts thấy tin cậy đã lập | |

Và một lời khuyên: hãy lập quan hệ tin cậy một chiều thay vì hai chiều trừ khi có lý do rõ ràng. Chiều "AWS tin cậy AD tại chỗ" là đủ cho việc đăng nhập — còn chiều ngược lại biến mọi tài khoản AWS bị chiếm thành một đường vào mạng nội bộ của công ty.

Câu 259 Domain - Design Solutions for Organizational Complexity

An AWS Partner company hosts all its infrastructure on the AWS cloud. All resources are currently deployed in the us-east-1 region. The company plans to expand its business to include deployments in Europe and Asia. The solutions architect has been tasked to provision the needed resources on multiple regions across multiple AWS accounts under the company’s AWS Organization.

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

  1. A

    Use AWS Organizations to centrally manage the deployment of AWS CloudFormation template from the central account. Use AWS Control Tower as an orchestration layer deploying resources across multiple accounts and regions.
  2. B

    Write infrastructure-as-code to maintain consistency. Create nested stacks with AWS CloudFormation templates and use global parameters to specify which target region and accounts to provision the needed resources.
  3. C

    Write infrastructure-as-code to maintain consistency. Create AWS CloudFormation templates and create IAM policies to control multiple accounts. Use regional parameters when deploying CloudFormation templates across multiple regions to provision the needed resources.
  4. D

    Write infrastructure-as-code to maintain consistency. Use AWS Organizations to centrally orchestrate the deployment of AWS CloudFormation template from the central account. Use CloudFormation StackSets to simplify permissions and automatic provisioning of resources across multiple regions and accounts.
Xem giải thích

Đáp án

**D — Viết hạ tầng dạng mã để giữ tính nhất quán; dùng AWS Organizations điều phối tập trung việc triển khai template CloudFormation từ tài khoản trung tâm; và dùng CloudFormation StackSets để đơn giản hoá phân quyền và tự động cấp phát tài nguyên trên nhiều Region và nhiều tài khoản.

Vì sao đúng

Đề nêu đúng một bài toán, và StackSets là dịch vụ được thiết kế cho nó:

Triển khai cùng một template lên
  NHIỀU TÀI KHOẢN × NHIỀU REGION
        ↓
    CloudFormation thường: một stack
      cho một tài khoản, một Region
        ↓
    StackSets: một lần khai
    → AWS tự tạo stack ở mọi nơi

⚠ Và chế độ SERVICE_MANAGED là thứ "đơn giản hoá phân quyền":

Chế độ `SELF_MANAGED`: phải tự tạo
  vai trò IAM ở TỪNG tài khoản đích
        ↓
    Chế độ `SERVICE_MANAGED`:
      Organizations lo phân quyền
    → không phải tạo vai trò nào

Tạo stack set:

aws cloudformation create-stack-set \
  --stack-set-name ha-tang-toan-cau \
  --template-body file://template.yaml \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --capabilities CAPABILITY_NAMED_IAM

Triển khai ra nhiều tài khoản và Region:

aws cloudformation create-stack-instances \
  --stack-set-name ha-tang-toan-cau \
  --deployment-targets OrganizationalUnitIds=ou-abc \
  --regions us-east-1 eu-west-1 ap-southeast-1 \
  --operation-preferences \
    MaxConcurrentPercentage=25,FailureTolerancePercentage=5

⚠ auto-deployment là chi tiết quan trọng:

Công ty mở tài khoản mới trong OU
    → tự động nhận stack
        ↓
    Không phải nhớ triển khai
      thủ công
    → không có tài khoản nào
      lọt lưới

⚠ Và operation-preferences bảo vệ khi triển khai rộng:

`MaxConcurrentPercentage 25`: triển
  khai 25% tài khoản một lúc
        ↓
    `FailureTolerancePercentage 5`:
      quá 5% lỗi thì DỪNG
        ↓
    Template hỏng không lan ra
      toàn tổ chức

⚠ Và nested stack (phương án B) KHÔNG triển khai xuyên tài khoản:

Nested stack: một stack tạo ra
  stack con
        ↓
    Nhưng tất cả nằm trong CÙNG
      một tài khoản và Region
    → không có "global parameter"
      nào chọn tài khoản đích

⚠ Và IAM policy (phương án C) không phải cơ chế triển khai:

IAM policy kiểm soát AI được làm GÌ
    → không tạo hay triển khai
      tài nguyên nào
        ↓
    Và "regional parameter" không
      phải cơ chế của CloudFormation
      để chọn Region triển khai

⚠ Và Control Tower (phương án A) là công cụ khác:

Control Tower: dựng landing zone,
  guardrail, Account Factory
        ↓
    Nó KHÔNG phải "lớp điều phối
      triển khai tài nguyên"
    → nó dùng StackSets bên dưới
      cho phần đó

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một template cho mọi tài khoản và Region | | | Tài khoản mới tự được phủ | | | Không phải tạo vai trò IAM ở từng nơi | |

⚠ Và tham số theo Region xử lý khác biệt giữa các nơi:

aws cloudformation create-stack-instances \
  --stack-set-name ha-tang-toan-cau \
  --deployment-targets OrganizationalUnitIds=ou-abc \
  --regions eu-west-1 \
  --parameter-overrides \
    ParameterKey=MaAnh,ParameterValue=ami-eu-abc

AMI ID khác nhau ở mỗi Region
    → ghi đè tham số cho từng Region
        ↓
    Hoặc dùng Parameter Store với
      cùng tên tham số ở mọi Region

⚠ Và Mappings là cách khác cho khác biệt theo Region:

Mappings:
  AnhTheoRegion:
    us-east-1: {MaAnh: ami-0abc}
    eu-west-1: {MaAnh: ami-0def}
    ap-southeast-1: {MaAnh: ami-0ghi}
Resources:
  MayChu:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !FindInMap [AnhTheoRegion, !Ref 'AWS::Region', MaAnh]

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

  • **A. Dùng Organizations quản lý tập trung việc triển khai template và dùng Control Tower làm lớp điều phối triển khai tài nguyên xuyên tài khoản và Region — đây là phương án gần nhất và Control Tower thật sự dùng StackSets bên dưới, nhưng bản thân nó là công cụ dựng landing zone và guardrail, không phải cơ chế triển khai tài nguyên ứng dụng.
  • **B. Dùng nested stack với "global parameter" chỉ định tài khoản và Region đích — nested stack chỉ hoạt động trong một tài khoản và một Region; không có tham số nào chọn tài khoản đích.
  • **C. Tạo template CloudFormation và IAM policy để kiểm soát nhiều tài khoản, dùng "regional parameter" khi triển khai — IAM policy không triển khai tài nguyên; và cơ chế được mô tả không tồn tại.

Ghi nhớ

⚠ Hai chế độ quyền của StackSets — bảng phải thuộc: | Chế độ | Phân quyền | |---|---| | SELF_MANAGED | tự tạo vai trò ở tài khoản quản trị và từng tài khoản đích | | SERVICE_MANAGED | Organizations lo, không tạo vai trò nào |

Từ khoá nhận diện:

"deploy to multiple accounts and Regions" → StackSets "new accounts automatically covered" → auto-deployment "landing zone with guardrails" → Control Tower "nested stacks" → một tài khoản, một Region

Ba lưu ý về StackSets: | Lưu ý | Chi tiết | |---|---| | Triển khai theo OU hoặc danh sách tài khoản | | | Đặt FailureTolerance để dừng khi lỗi | | | MaxConcurrent kiểm soát tốc độ triển khai | |

⚠ Triển khai toàn tổ chức mà không giới hạn là rủi ro lớn:

Template có lỗi
    → triển khai đồng thời lên
      50 tài khoản
        ↓
    Cả tổ chức cùng hỏng
    → luôn đặt FailureTolerance thấp

Ba lưu ý về thứ tự Region: | Lưu ý | Chi tiết | |---|---| | RegionOrder quyết định Region nào trước | | | Đặt Region ít quan trọng lên đầu | | | Phát hiện lỗi trước khi tới Region chính | |

--operation-preferences \
  RegionOrder=ap-southeast-1,eu-west-1,us-east-1

Ba lưu ý về drift: | Lưu ý | Chi tiết | |---|---| | StackSets phát hiện drift trên mọi stack instance | | | Ai đó sửa tay ở một tài khoản là thấy ngay | | | Chạy định kỳ | |

aws cloudformation detect-stack-set-drift \
  --stack-set-name ha-tang-toan-cau

Ba lưu ý về Control Tower: | Lưu ý | Chi tiết | |---|---| | Dựng landing zone theo thực hành tốt | | | Account Factory tạo tài khoản chuẩn hoá | | | Customizations for Control Tower dùng StackSets | |

⚠ Control Tower và StackSets bổ sung cho nhau:

Control Tower: dựng cấu trúc tổ chức,
  guardrail, tài khoản mới
        ↓
    StackSets: triển khai tài nguyên
      ứng dụng lên các tài khoản đó
        ↓
    Không phải chọn một trong hai

Ba lưu ý về khác biệt giữa Region: | Cách | Chi tiết | |---|---| | Mappings trong template | bảng tra theo Region | | parameter-overrides | ghi đè khi tạo stack instance | | Parameter Store | cùng tên tham số, giá trị khác nhau |

⚠ Parameter Store là cách sạch nhất:

Parameters:
  MaAnh:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /ung-dung/ami-moi-nhat

Mỗi Region có tham số cùng tên
    → template không cần biết
      Region nào

Ba lưu ý về dịch vụ không có ở mọi Region: | Lưu ý | Chi tiết | |---|---| | Kiểm dịch vụ có sẵn ở Region đích | | | Dùng Conditions để bỏ qua tài nguyên | | | Hoặc tách thành stack set riêng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Triển khai lên một OU thử trước | | | Kiểm mọi tài khoản và Region đã có stack | | | Thêm một tài khoản mới, xem có tự nhận stack | |

Và một lời khuyên: hãy đặt FailureTolerancePercentage thấp và RegionOrder bắt đầu từ Region ít quan trọng nhất. StackSets triển khai lên hàng chục tài khoản chỉ bằng một lệnh — nghĩa là một template hỏng cũng lan ra hàng chục tài khoản chỉ bằng một lệnh.

Câu 260 Domain - Design for New Solutions

A leading media company in the country is building a voting system for a popular singing competition show on national TV. The viewers who watch the performances can visit the company’s dynamic website to vote for their favorite singer. After the show has finished, it is expected that the site will receive millions of visitors who would like to cast their votes. Web visitors should log in using their social media accounts and then submit their votes. The webpage will display the winner after the show, as well as the vote total for each singer. The solutions architect is tasked to build the voting site and ensure that it can handle the rapid influx of incoming traffic in the most cost-effective way possible.

Which of the following architecture should you use to meet the requirement?

  1. A Use a CloudFront web distribution and an Application Load balancer in front of an Auto Scaling group of EC2 instances. The servers will first authenticate the user using IAM and then process the user's vote which will then be stored to RDS.
  2. B

    Use a CloudFront web distribution and an Application Load Balancer in front of an Auto Scaling group of EC2 instances. Use Amazon Cognito for user authentication. The web servers will process the user's vote and pass the result in an SQS queue. Set up an IAM Role to grant the EC2 instances permissions to write to the SQS queue. A group of EC2 instances will then retrieve and process the items from the queue. Finally, store the results in a DynamoDB table.
  3. C Use a CloudFront web distribution and deploy the website using S3 hosting feature. Write a custom NodeJS application to authenticate the user using STS and AssumeRole API. Setup an IAM Role to grant permission to store the user's vote to a DynamoDB table.
  4. D Use a CloudFront web distribution and an Application Load Balancer in front of an Auto Scaling group of EC2 instances. Develop a custom authentication service using STS and AssumeRoleWithSAML API. The servers will process the user's vote and store the result in a DynamoDB table.
Xem giải thích

Đáp án

**B — Dùng CloudFront và Application Load Balancer trước Auto Scaling group EC2; dùng Amazon Cognito xác thực người dùng; máy chủ web xử lý phiếu bầu rồi đẩy kết quả vào hàng đợi SQS; gán IAM Role cho EC2 để ghi vào hàng đợi; và một nhóm EC2 khác lấy và xử lý các mục từ hàng đợi.

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 | |---|---| | Đăng nhập bằng tài khoản mạng xã hội | Cognito | | Hàng triệu phiếu đổ về sau chương trình | SQS làm bộ đệm | | Rẻ nhất | không dự phòng công suất cho đỉnh |

⚠ Cognito là dịch vụ DUY NHẤT của AWS làm liên kết danh tính mạng xã hội:

Người xem bấm "Đăng nhập bằng
  Facebook"
    → Cognito user pool nhận token
      của Facebook
        ↓
    Trả về token của chính nó
    → không phải tự viết luồng OAuth

⚠ Và IAM (phương án A) KHÔNG dùng để xác thực người dùng cuối:

IAM: quản lý danh tính cho người
  vận hành và dịch vụ AWS
        ↓
    Hàng triệu người xem truyền hình
    → không thể tạo IAM user cho
      từng người
        ↓
    IAM có hạn ngạch số user và
      không thiết kế cho việc này

⚠ Và hàng đợi là thứ chịu được đợt bỏ phiếu đột ngột:

Chương trình kết thúc
    → hàng triệu người bỏ phiếu
      trong vài phút
        ↓
    Ghi thẳng vào CSDL: quá tải,
      mất phiếu
        ↓
    SQS: nhận ngay, xếp hàng
    → tầng xử lý đếm phiếu theo
      tốc độ của mình

⚠ Và ghi phiếu là thao tác chấp nhận được BẤT ĐỒNG BỘ:

Người bỏ phiếu nhận "đã ghi nhận"
    → kết quả công bố sau chương trình
        ↓
    Không cần thấy tổng phiếu thay
      đổi ngay lập tức
    → đây là điều làm hàng đợi
      phù hợp

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

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

⚠ Và IAM Role trên EC2 là cách đúng để ghi vào SQS:

Không nhúng access key vào máy chủ
    → instance profile cấp credential
      tạm
        ↓
    Tự xoay, không có gì để rò rỉ

{"Effect": "Allow",
 "Action": "sqs:SendMessage",
 "Resource": "arn:aws:sqs:*:*:hang-doi-phieu-bau"}

⚠ Và chống bỏ phiếu trùng là yêu cầu nghiệp vụ quan trọng:

bang.put_item(
    Item={'idNguoiDung': ma, 'caSi': lua_chon},
    ConditionExpression='attribute_not_exists(idNguoiDung)')

SQS Standard có thể giao trùng
    → và người dùng có thể bấm
      nhiều lần
        ↓
    Điều kiện này bảo đảm mỗi người
      một phiếu

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không mất phiếu nào khi đỉnh tải | | | Cognito lo toàn bộ việc đăng nhập mạng xã hội | | | CloudFront phục vụ trang và kết quả từ biên | |

⚠ Và CloudFront cache trang kết quả rất hiệu quả:

Hàng triệu người xem cùng một
  trang kết quả
        ↓
    TTL 30 giây
    → origin chỉ nhận 2 yêu cầu
      mỗi phút
    → thay vì hàng triệu

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

  • **D. CloudFront + ALB + ASG, tự viết dịch vụ xác thực dùng STS và AssumeRoleWithSAML, ghi kết quả vào DynamoDB — đây là phương án gần nhất và DynamoDB là lựa chọn hợp lý cho lượng ghi lớn, nhưng AssumeRoleWithSAML dành cho liên kết doanh nghiệp, không phải đăng nhập mạng xã hội; và thiếu bộ đệm cho đỉnh tải.
  • **A. CloudFront + ALB + ASG, máy chủ xác thực người dùng bằng IAM rồi ghi vào RDS — IAM không dùng để xác thực hàng triệu người dùng cuối; và RDS không chịu được đợt ghi đột ngột.
  • **C. CloudFront + website tĩnh trên S3, viết ứng dụng NodeJS tự xác thực bằng STS AssumeRole, ghi vào DynamoDB — trang tĩnh không chạy được ứng dụng NodeJS phía máy chủ; và AssumeRole không phải API cho đăng nhập mạng xã hội.

Ghi nhớ

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

Từ khoá nhận diện:

"log in with social media accounts" → Cognito "millions of votes in minutes" → SQS làm bộ đệm "corporate SAML login" → AssumeRoleWithSAML "cost-effective for traffic spike" → hàng đợi, không dự phòng công suất

⚠ Hai loại pool của Cognito: | Loại | Trả lời | |---|---| | User pool | "anh là ai?" — thư mục và đăng nhập | | Identity pool | "anh làm được gì trên AWS?" |

Ba lưu ý về Cognito: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ Google, Facebook, Apple, Amazon | | | Hosted UI tuỳ biến giao diện được | | | ALB xác thực Cognito ngay tại tầng cân bằng tải | |

⚠ ALB xác thực Cognito bỏ được mã xác thực trong ứng dụng:

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

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Standard: thông lượng vô hạn, có thể trùng | | | Giữ thông điệp tới 14 ngày | | | Co giãn consumer theo backlog per instance | |

Ba lưu ý về chống gian lận bỏ phiếu: | Lưu ý | Chi tiết | |---|---| | Ghi id người dùng cùng phiếu | | | ConditionExpression chặn bỏ phiếu trùng | | | Giới hạn tần suất bằng WAF rate-based rule | |

⚠ WAF rate-based rule chặn bot bỏ phiếu hàng loạt:

{"Statement":{"RateBasedStatement":{
  "Limit":100,"AggregateKeyType":"IP"}},
 "Action":{"Block":{}}}

Ba lưu ý về hiển thị kết quả: | Lưu ý | Chi tiết | |---|---| | Tổng phiếu cập nhật định kỳ, không thời gian thực | | | Cache trang kết quả với TTL ngắn | | | DynamoDB atomic counter để cộng dồn | |

bang.update_item(
    Key={'caSi': ten},
    UpdateExpression='ADD tongPhieu :m',
    ExpressionAttributeValues={':m': 1})

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | Co giãn trước theo lịch chương trình | | | Warm pool rút ngắn thời gian sẵn sàng | | | Trải nhiều AZ | |

⚠ Scheduled scaling rất hợp với sự kiện biết trước:

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name asg-bo-phieu \
  --scheduled-action-name truoc-chuong-trinh \
  --start-time 2026-09-15T13:00:00Z \
  --min-size 20 --desired-capacity 20

Chương trình phát lúc 14:00
    → mở rộng từ 13:00
    → không phải chờ ASG phản ứng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tải cao, đếm số phiếu vào CSDL | | | Kiểm không có phiếu nào đếm hai lần | | | Thử đăng nhập bằng cả Google và Facebook | |

Và một lời khuyên: hãy dùng scheduled scaling cho sự kiện có lịch phát sóng cố định. Auto Scaling phản ứng theo chỉ số luôn chậm hơn đợt tải đổ về sau khi chương trình kết thúc — còn mở rộng trước một giờ thì không có gì phải phản ứng cả.