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

Tìm thấy 1221 câu.

Câu 191 Domain - Design for New Solutions

A startup currently runs a web application on an extra-large Amazon EC2 instance. The application allows users to upload and download various pdf files from a private Amazon S3 bucket using a pre-signed URL. The web application checks if the file being requested actually exists in the S3 bucket before generating the URL.

In this scenario, how should the solutions architect configure the web application to access the Amazon S3 bucket securely?

  1. A

    1. Create an IAM user with the appropriate permissions allowing access and listing of all of the objects of the S3 bucket. Associate the EC2 instance with the IAM user.

    2. Program your web application to retrieve the user credentials from the EC2 instance metadata.
  2. B

    1. Create an IAM role with a policy that allows listing of the objects in the S3 bucket. Launch the EC2 instance with the IAM role.

    2. Program your web application to retrieve the temporary security credentials from the EC2 instance user data.
  3. C

    1. Store your access keys inside the EC2 instance.

    2. Program your web application to retrieve the AWS credentials from the instance to interact with the objects in the S3 bucket.
  4. D

    1. Create an IAM role with a policy that allows listing and uploading of the objects in the S3 bucket. Launch the EC2 instance with the IAM role.

    2. Program your web application to retrieve the temporary security credentials from the EC2 instance metadata.
Xem giải thích

Đáp án

**D — Tạo IAM role có chính sách cho phép liệt kê và tải lên object trong bucket, khởi chạy EC2 với vai trò đó; lập trình ứng dụng lấy credential bảo mật tạm thời từ instance METADATA.

Vì sao đúng

Đề mô tả hai thao tác ứng dụng cần làm, và điều đó quyết định quyền: | Thao tác | Quyền cần | |---|---| | Kiểm tra tệp có tồn tại trong bucket không | s3:ListBucket | | Người dùng tải lên qua pre-signed URL | s3:PutObject |

⚠ Phương án B chỉ cấp quyền LIỆT KÊ — thiếu quyền tải lên:

Ứng dụng sinh pre-signed URL cho
  `PutObject`
        ↓
    URL kế thừa quyền của người KÝ
    → vai trò chỉ có ListBucket
    → URL sinh ra không tải lên được

⚠ Và phương án B nói sai nguồn credential:

Credential của vai trò nằm ở
  instance METADATA
        ↓
    User data là script khởi động
      do BẠN viết
    → không chứa credential nào

Chính sách với quyền tối thiểu:

{"Version": "2012-10-17", "Statement": [
  {"Effect": "Allow",
   "Action": "s3:ListBucket",
   "Resource": "arn:aws:s3:::tai-lieu-pdf"},
  {"Effect": "Allow",
   "Action": ["s3:PutObject", "s3:GetObject"],
   "Resource": "arn:aws:s3:::tai-lieu-pdf/*"}]}

⚠ Hai ARN khác nhau — đây là lỗi phổ biến nhất với S3:

`s3:ListBucket` áp cho BUCKET
    → ARN KHÔNG có `/*`
        ↓
    `s3:PutObject` áp cho OBJECT
    → ARN CÓ `/*`
        ↓
    Nhầm chỗ này là nguyên nhân
      số một của lỗi AccessDenied

Kiểm tra tệp tồn tại và sinh URL:

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

def sinh_url_tai_len(khoa):
    try:
        s3.head_object(Bucket='tai-lieu-pdf', Key=khoa)
        raise ValueError('Tep da ton tai')
    except s3.exceptions.ClientError as e:
        if e.response['Error']['Code'] != '404':
            raise
    return s3.generate_presigned_url('put_object',
        Params={'Bucket': 'tai-lieu-pdf', 'Key': khoa},
        ExpiresIn=900)

⚠ head_object cần quyền s3:GetObject, không phải ListBucket:

`head_object`: kiểm tra MỘT object
    → cần `s3:GetObject`
        ↓
    `list_objects_v2`: liệt kê bucket
    → cần `s3:ListBucket`
        ↓
    Chọn API nào thì cấp quyền tương ứng

⚠ Và head_object trả 403 thay vì 404 khi thiếu quyền ListBucket:

Không có `s3:ListBucket`
    → object không tồn tại vẫn trả 403
      thay vì 404
        ↓
    Ứng dụng không phân biệt được
      "không có" với "không được phép"
    → cấp cả hai quyền

⚠ Credential lấy từ metadata, không phải user data:

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có khoá tĩnh nào tồn tại | | | Credential tự xoay trước khi hết hạn | | | CloudTrail ghi rõ vai trò nào thao tác | |

⚠ Và bắt buộc IMDSv2:

aws ec2 modify-instance-metadata-options \
  --instance-id i-abc --http-tokens required \
  --http-put-response-hop-limit 1

IMDSv1: một GET là lấy được credential
    → lỗ hổng SSRF trong ứng dụng web
      đủ để đánh cắp
        ↓
    IMDSv2: bắt buộc PUT lấy token trước

⚠ Chú ý thời hạn của pre-signed URL ký bằng vai trò:

Credential tạm của vai trò có hạn
    → URL KHÔNG sống lâu hơn credential
        ↓
    Đặt `ExpiresIn` dài hơn thời gian
      còn lại của credential
    → URL vẫn chết sớm

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

  • **B. Tạo IAM role với chính sách chỉ cho phép liệt kê object, khởi chạy EC2 với vai trò đó, lấy credential từ user data — đây là phương án gần nhất và phần vai trò IAM hoàn toàn đúng hướng, nhưng thiếu quyền tải lên nên pre-signed URL cho PutObject sẽ không dùng được; và credential nằm ở metadata chứ không phải user data.
  • **A. Tạo IAM user rồi "gắn EC2 với IAM user" — không có khái niệm gắn IAM user vào EC2; chỉ vai trò qua instance profile mới gắn được.
  • **C. Lưu access key ngay trên EC2 để ứng dụng đọc — khoá tĩnh nằm trên đĩa, phải xoay tay, ai đọc được máy là lấy được.

Ghi nhớ

⚠ Hai nguồn thông tin trên EC2 — bảng phải thuộc: | Nguồn | Chứa gì | Ai đặt | |---|---|---| | Instance metadata | thông tin instance + CREDENTIAL vai trò | AWS | | Instance user data | script khởi động | bạn |

Từ khoá nhận diện:

"application on EC2 needs S3 access" → IAM role + instance profile "where do credentials come from" → instance metadata "check if object exists" → head_object, cần GetObject "list objects in bucket" → s3:ListBucket, ARN không có /*

⚠ Bảng quyền S3 hay bị nhầm: | Hành động | ARN | |---|---| | s3:ListBucket | arn:aws:s3:::bucket | | s3:GetObject | arn:aws:s3:::bucket/* | | s3:PutObject | arn:aws:s3:::bucket/* | | s3:GetBucketLocation | arn:aws:s3:::bucket |

Ba lưu ý về pre-signed URL: | Lưu ý | Chi tiết | |---|---| | Kế thừa quyền của người KÝ | | | Không thu hồi được URL đã phát | | | Đặt hạn ngắn nhất dùng được | |

⚠ Dùng generate_presigned_post để giới hạn tải lên:

url = s3.generate_presigned_post(
    Bucket='tai-lieu-pdf', Key='tai-len/${filename}',
    Fields={'Content-Type': 'application/pdf'},
    Conditions=[['content-length-range', 0, 20971520],
                {'Content-Type': 'application/pdf'}],
    ExpiresIn=900)

Không giới hạn kích thước và loại tệp
    → ai có URL đều tải lên bất kỳ thứ gì
    → kể cả tệp 5 GB

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

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Chỉ cấp API thật sự dùng | | | Giới hạn theo tiền tố nếu được | | | IAM Access Analyzer sinh chính sách từ CloudTrail | |

{"Effect": "Allow", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::tai-lieu-pdf/tai-len/*"}

Ba lưu ý về bảo mật bucket: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access | | | Bắt buộc HTTPS bằng bucket policy | | | Bật versioning chống ghi đè nhầm | |

Ba lưu ý về gỡ lỗi quyền: | Công cụ | Việc | |---|---| | aws sts get-caller-identity | xem đang dùng danh tính nào | | IAM Policy Simulator | kiểm quyền trước khi triển khai | | CloudTrail | xem lời gọi bị từ chối vì lý do gì |

Ba lưu ý về ứng dụng không phải EC2: | Môi trường | Cơ chế | |---|---| | ECS | task role | | Lambda | execution role | | EKS | IRSA hoặc Pod Identity | | Máy tại chỗ | IAM Roles Anywhere |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sinh URL rồi tải lên thử ngay | | | Thử ghi vào bucket khác — phải bị từ chối | | | Kiểm IMDSv2 đã bắt buộc chưa | |

Và một lời khuyên: hãy liệt kê chính xác những API mà ứng dụng gọi trước khi viết chính sách IAM. Phần lớn lỗi "AccessDenied" khó hiểu không đến từ việc thiếu quyền lớn, mà từ một hành động phụ như ListBucket mà không ai nghĩ tới cho tới khi nó hỏng.

Câu 192 Domain - Continuous Improvement for Existing Solutions

A leading aerospace engineering company is experiencing high growth and demand on their highly available and fault-tolerant cloud services platform that is hosted in AWS. The technical lead of your team has asked you to virtually extend two existing on-premises data centers into AWS cloud to support an online flight-tracking service that is used by a lot of airline companies. The online service heavily depends on existing, on-premises resources located in multiple data centers and static content that is served from an S3 bucket. To meet the requirement, you launched a dual-tunnel VPN connection between your CGW and VGW.

In this scenario, which component of your cloud architecture represents a potential single point of failure, which you should consider changing to make the solution more highly available?

  1. A Create a second Virtual Gateway in a different AZ and a Customer Gateway in a different data center. Create another dual-tunnel connection to ensure high-availability and fault-tolerance.
  2. B Set up a NAT Gateway in a different data center and set up another dual-tunnel VPN connection.
  3. C Create another Virtual Gateway in a different AZ and create another dual-tunnel VPN connection.
  4. D Create another Customer Gateway in a different data center and set up another dual-tunnel VPN connection.
Xem giải thích

Đáp án

**D — Tạo thêm một Customer Gateway ở trung tâm dữ liệu khác và dựng thêm một kết nối VPN hai tunnel.

Vì sao đúng

Đề hỏi thành phần nào là điểm hỏng duy nhất, và câu trả lời nằm ở chỗ AWS lo gì và bạn lo gì: | Thành phần | Ai vận hành | Dư thừa sẵn | |---|---|---| | Virtual Private Gateway (VGW) | AWS | CÓ, dư thừa nhiều AZ | | Hai tunnel VPN | AWS | CÓ, hai đường độc lập | | Customer Gateway (CGW) | BẠN | KHÔNG — một thiết bị |

VGW đã dư thừa, hai tunnel đã dư thừa
    → phần còn lại là CGW
        ↓
    Đó là thiết bị vật lý ở trung tâm
      dữ liệu của bạn
    → nó hỏng là mất kết nối

⚠ Và đề nói rõ có HAI trung tâm dữ liệu:

"Mở rộng hai trung tâm dữ liệu
  hiện có vào AWS"
        ↓
    Nhưng chỉ dựng một kết nối VPN
    → CGW ở một trung tâm
        ↓
    Trung tâm đó mất điện hoặc
      thiết bị hỏng
    → toàn bộ kết nối đứt

⚠ VGW dư thừa sẵn — không thêm được:

AWS quản lý VGW
    → nó đã chạy trên nhiều AZ
        ↓
    Một VPC chỉ gắn được MỘT VGW
    → phương án A và C mô tả việc
      không làm được

Tạo Customer Gateway thứ hai:

aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --public-ip 198.51.100.20 \
  --bgp-asn 65000 \
  --tag-specifications \
    'ResourceType=customer-gateway,Tags=[{Key=Name,Value=cgw-trung-tam-2}]'

aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-moi \
  --vpn-gateway-id vgw-abc \
  --options TunnelOptions='[{},{}]'

⚠ Kết quả là bốn tunnel từ hai địa điểm:

Trung tâm 1: CGW-1 → 2 tunnel → VGW
Trung tâm 2: CGW-2 → 2 tunnel → VGW
        ↓
    Mất một thiết bị: còn 2 tunnel
    Mất cả một trung tâm: còn 2 tunnel
        ↓
    Đây là cấu hình AWS khuyến nghị

⚠ BGP là điều kiện để chuyển đổi tự động:

VPN tĩnh: phải sửa tuyến bằng tay
  khi một đường chết
        ↓
    BGP: tự phát hiện đường chết
      và chuyển sang đường còn lại
    → trong vài chục giây

Bật lan truyền tuyến:

aws ec2 enable-vgw-route-propagation \
  --route-table-id rtb-abc --gateway-id vgw-abc

⚠ Và điều khiển đường ưu tiên bằng BGP:

Quảng bá tiền tố cụ thể hơn từ
  đường muốn ưu tiên
        ↓
    Hoặc dùng AS path prepending
      để làm đường kia kém hấp dẫn
    → kiểm soát được lưu lượng đi
      theo đường nào

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chịu được mất một thiết bị hoặc cả một địa điểm | | | BGP tự chuyển đổi, không cần can thiệp | | | Tận dụng hai trung tâm dữ liệu đã có | |

⚠ Nhưng VPN có trần băng thông phải biết:

Mỗi tunnel tối đa khoảng 1,25 Gbps
    → dịch vụ theo dõi chuyến bay
      với lượng người dùng lớn
        ↓
    Cân nhắc Direct Connect nếu
      băng thông là vấn đề
    → và giữ VPN làm đường dự phòng

⚠ Và nội dung tĩnh trên S3 nên đi đường khác:

Đề nói nội dung tĩnh phục vụ từ S3
    → lưu lượng đó KHÔNG cần đi
      qua VPN
        ↓
    Người dùng truy cập S3 trực tiếp
      hoặc qua CloudFront
    → VPN chỉ cho lưu lượng tới
      tài nguyên tại chỗ

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

  • **C. Tạo thêm Virtual Gateway ở AZ khác và dựng thêm kết nối hai tunnel — đây là phương án gần nhất và ý tưởng thêm dự phòng là đúng, nhưng VGW là dịch vụ quản lý đã dư thừa sẵn; và một VPC chỉ gắn được một VGW, không có khái niệm "VGW ở một AZ".
  • **A. Tạo VGW thứ hai ở AZ khác và CGW ở trung tâm khác — phần CGW đúng nhưng phần VGW mô tả việc không làm được.
  • **B. Dựng NAT Gateway ở trung tâm dữ liệu khác và thêm kết nối VPN — NAT gateway là dịch vụ trong VPC của AWS, không đặt được ở trung tâm dữ liệu; và nó không liên quan tới VPN.

Ghi nhớ

⚠ Bốn thành phần của Site-to-Site VPN — bảng phải thuộc: | Thành phần | Ở đâu | Ai lo dự phòng | |---|---|---| | Virtual Private Gateway | phía AWS | AWS | | Customer Gateway | phía bạn | BẠN | | VPN connection | giữa hai bên | AWS cho 2 tunnel | | Thiết bị VPN vật lý | phía bạn | BẠN |

Từ khoá nhận diện:

"single point of failure in VPN setup" → Customer Gateway "AWS side redundancy" → VGW đã dư thừa sẵn "higher bandwidth, consistent latency" → Direct Connect "connect many VPCs to on-premises" → Transit Gateway

⚠ Bốn mức dự phòng cho kết nối lai — bảng phải thuộc: | Mức | Cấu hình | |---|---| | Thấp nhất | một VPN, một CGW | | Trung bình | hai VPN, hai CGW ở hai địa điểm | | Cao | Direct Connect + VPN dự phòng | | Cao nhất | hai DX ở hai địa điểm + VPN dự phòng |

Ba lưu ý về hai tunnel: | Lưu ý | Chi tiết | |---|---| | Mỗi kết nối VPN luôn có hai tunnel | | | Hai tunnel tới hai endpoint khác nhau của AWS | | | Cấu hình CẢ HAI trên thiết bị CGW | |

⚠ Nhiều người chỉ cấu hình một tunnel:

Thiết bị CGW chỉ dựng tunnel 1
    → AWS bảo trì endpoint đó
        ↓
    Mất kết nối hoàn toàn
    → dù AWS đã cung cấp đường thứ hai

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Thời gian cung cấp tính bằng tuần tới tháng | | | Một kết nối vẫn là một điểm hỏng | | | VPN làm đường dự phòng cho DX là mẫu chuẩn | |

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

DX là đường chính (BGP ưu tiên cao)
    + VPN dự phòng
        ↓
    DX đứt: BGP tự chuyển sang VPN
    → chậm hơn nhưng không mất kết nối

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | Cần ASN cho phía khách hàng | | | Tự phát hiện và chuyển đường | | | AS path prepending điều khiển ưu tiên | |

Ba lưu ý về Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Thay VGW khi có nhiều VPC | | | Nhận cả VPN lẫn Direct Connect | | | Có bảng định tuyến để phân đoạn | |

⚠ Với nhiều VPC thì TGW là lựa chọn đúng:

Mỗi VPC một VGW và một VPN riêng
    → số kết nối tăng theo số VPC
        ↓
    TGW: một điểm nối, mọi VPC
      gắn vào

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | TunnelState | tunnel đang lên hay xuống | | TunnelDataIn / TunnelDataOut | lưu lượng qua từng tunnel | | Cảnh báo khi có tunnel xuống | |

aws cloudwatch put-metric-alarm \
  --alarm-name tunnel-xuong --namespace AWS/VPN \
  --metric-name TunnelState --statistic Minimum \
  --period 300 --threshold 1 \
  --comparison-operator LessThanThreshold \
  --dimensions Name=VpnId,Value=vpn-abc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt một tunnel, xem lưu lượng có chuyển | | | Tắt cả một CGW, xem địa điểm kia tiếp quản | | | Đo thời gian chuyển đổi thật | |

Và một lời khuyên: hãy cấu hình cả hai tunnel trên thiết bị Customer Gateway của bạn, kể cả khi một cái đã đủ dùng. AWS bảo trì luân phiên các endpoint VPN, và một cấu hình chỉ dùng một tunnel sẽ mất kết nối vào đúng lúc AWS làm việc bảo trì hoàn toàn bình thường.

Câu 193 Domain - Continuous Improvement for Existing Solutions

A cryptocurrency startup owns multiple AWS accounts which are all linked under AWS Organizations. Due to the financial nature of the business, the DevOps lead has been instructed by the CTO to prepare for IT auditing activities to meet industry compliance requirements.

Which of the following provides the most durable and secure logging solution that can be used to track changes made to all of the company’s AWS resources globally?

  1. A 1. Launch a new CloudTrail trail using the AWS console with an existing S3 bucket to store the logs and with the "Apply trail to all regions" checkbox enabled. 2. Enable MFA Delete on the S3 bucket.
  2. B 1. Launch a new CloudTrail with one new S3 bucket to store the logs. 2. Configure SNS to send log file delivery notifications to your management system. 3. Enable MFA Delete and Log Encryption on the S3 bucket.
  3. C

    1. Launch a new CloudTrail trail using the AWS console with one new S3 bucket to store the logs and with the "Enable for all accounts in my organization" checkbox enabled.

    2. Enable MFA Delete and Log Encryption on the S3 bucket.
  4. D

    1. Launch three new CloudTrail trails using three new S3 buckets to store the logs for the AWS Management console, for AWS SDKs, and for the AWS CLI.

    2. Enable MFA Delete and Log Encryption on the S3 bucket.
Xem giải thích

Đáp án

**C — Tạo một CloudTrail trail mới với một bucket S3 mới và bật tuỳ chọn "Enable for all accounts in my organization"; bật MFA Delete và mã hoá log trên bucket đó.

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 | |---|---| | Theo dõi thay đổi trên MỌI tài khoản | organization trail | | Toàn cầu (mọi Region) | organization trail tự áp mọi Region | | Bền vững và an toàn nhất | bucket mới + MFA Delete + mã hoá |

⚠ Organization trail là lựa chọn duy nhất phủ được toàn tổ chức:

Trail thường: chỉ tài khoản tạo ra nó
    → 20 tài khoản = 20 trail phải quản
        ↓
    Organization trail: tạo MỘT lần
      ở tài khoản quản lý
    → tự áp cho mọi tài khoản thành viên
    → kể cả tài khoản mới tham gia

⚠ Và tài khoản con KHÔNG tắt được nó:

Trail thường ở tài khoản con
    → quản trị viên tài khoản đó
      tắt được
        ↓
    Organization trail: chỉ tài khoản
      quản lý sửa được
    → đây là điều kiểm toán cần

Tạo organization trail:

aws cloudtrail create-trail --name trail-to-chuc \
  --s3-bucket-name log-kiem-toan-moi \
  --is-organization-trail \
  --is-multi-region-trail \
  --include-global-service-events \
  --enable-log-file-validation \
  --kms-key-id <arn-khoa-kms>

aws cloudtrail start-logging --name trail-to-chuc

⚠ --enable-log-file-validation là yêu cầu bắt buộc với kiểm toán:

Sinh tệp digest ký số cho mỗi giờ log
    → chứng minh log không bị sửa
        ↓
    Không có nó: log chỉ là tệp text
      trong S3
    → ai có quyền ghi đều sửa được

Kiểm chứng tính toàn vẹn:

aws cloudtrail validate-logs \
  --trail-arn <arn> --start-time 2026-08-01T00:00:00Z

⚠ Bucket MỚI là chi tiết quan trọng — không dùng bucket có sẵn:

Bucket có sẵn có thể đã có chính sách
  cho nhiều người ghi và xoá
        ↓
    Log kiểm toán cần bucket riêng
      với chính sách chặt
    → và lý tưởng nhất là ở
      TÀI KHOẢN RIÊNG

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

⚠ MFA Delete có ràng buộc đặc biệt:

Chỉ bật được bằng TÀI KHOẢN GỐC
    + chỉ bật được qua CLI, không
      qua bảng điều khiển
        ↓
    Và bucket phải bật versioning trước

aws s3api put-bucket-versioning --bucket log-kiem-toan-moi \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 123456"

⚠ Nhưng S3 Object Lock mạnh hơn MFA Delete: | Cơ chế | Bảo vệ | |---|---| | MFA Delete | cần mã MFA để xoá phiên bản | | Object Lock Governance | gỡ được với quyền đặc biệt | | Object Lock Compliance | KHÔNG ai gỡ được, kể cả root |

Yêu cầu tuân thủ ngành tài chính
    → Object Lock chế độ compliance
    → đây là biện pháp mạnh nhất

aws s3api put-object-lock-configuration \
  --bucket log-kiem-toan-moi \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":
      {"Mode":"COMPLIANCE","Years":7}}}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một trail cho toàn tổ chức, không sót tài khoản nào | | | Tài khoản con không tắt được | | | Log mã hoá và chống xoá | |

⚠ Và tài khoản mới tự động được phủ:

Công ty mở tài khoản mới
    → tự động nằm trong organization trail
        ↓
    Không phải nhớ tạo trail cho nó
    → đây là điều 20 trail riêng lẻ
      không làm được

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

  • **A. Tạo trail với bucket S3 CÓ SẴN và bật "Apply trail to all regions", bật MFA Delete — đây là phương án gần nhất và "mọi Region" là đúng, nhưng nó chỉ phủ một tài khoản chứ không phải cả tổ chức; và dùng bucket có sẵn cho log kiểm toán là rủi ro.
  • **B. Tạo trail với bucket mới, cấu hình SNS thông báo giao tệp log, bật MFA Delete và mã hoá — thiếu phần quan trọng nhất: nó không phải organization trail nên không phủ mọi tài khoản.
  • **D. Tạo ba trail riêng cho bảng điều khiển, SDK và CLI — CloudTrail không phân chia theo cách gọi; mọi thao tác đều là lời gọi API và được ghi trong cùng một trail.

Ghi nhớ

⚠ Ba loại trail — bảng phải thuộc: | Loại | Phạm vi | |---|---| | Trail một Region | một tài khoản, một Region | | Trail đa Region | một tài khoản, mọi Region | | Organization trail | MỌI tài khoản, mọi Region |

Từ khoá nhận diện:

"all accounts in the organization" → organization trail "prove logs were not tampered" → log file validation + Object Lock "who did what, when" → CloudTrail "what did the resource look like" → AWS Config

⚠ Hai loại sự kiện CloudTrail — phải thuộc: | Loại | Ví dụ | Mặc định | |---|---|---| | Management | CreateBucket, RunInstances | BẬT, miễn phí bản đầu | | Data | GetObject, PutItem, Invoke | TẮT, tính phí |

Câu hỏi "ai đã ĐỌC tệp này"
    → cần DATA event
        ↓
    Chỉ bật cho tài nguyên nhạy cảm
      vì chi phí

Ba lưu ý về bảo vệ log: | Lưu ý | Chi tiết | |---|---| | Bucket log ở TÀI KHOẢN RIÊNG | | | Object Lock chế độ compliance | | | Chỉ cho ghi, không cho xoá | |

⚠ Tài khoản riêng là biện pháp quan trọng nhất:

Log nằm cùng tài khoản bị xâm nhập
    → kẻ tấn công xoá luôn dấu vết
        ↓
    Tài khoản log riêng, chỉ nhận ghi
    → mất tài khoản chính vẫn còn
      bằng chứng

Ba lưu ý về mã hoá log: | Lưu ý | Chi tiết | |---|---| | SSE-KMS với khoá riêng | | | Key policy kiểm soát ai giải mã được | | | Log mã hoá vẫn validate được | |

Ba lưu ý về CloudTrail Lake: | Lưu ý | Chi tiết | |---|---| | Truy vấn SQL sẵn, không cần dựng Athena | | | Giữ tới 10 năm | | | Hợp với yêu cầu lưu trữ dài hạn | |

SELECT userIdentity.arn, eventName, eventTime, sourceIPAddress
FROM <kho-du-lieu>
WHERE eventName IN ('StopLogging', 'DeleteTrail')
ORDER BY eventTime DESC;

Ba thao tác nên cảnh báo ngay: | Thao tác | Ý nghĩa | |---|---| | StopLogging | có người tắt ghi nhận | | DeleteTrail | có người xoá trail | | ConsoleLogin với root | dùng tài khoản gốc |

{"source": ["aws.cloudtrail"],
 "detail-type": ["AWS API Call via CloudTrail"],
 "detail": {"eventName": ["StopLogging", "DeleteTrail",
                          "PutEventSelectors"]}}

Ba lưu ý về SCP bảo vệ trail: | Lưu ý | Chi tiết | |---|---| | Chặn cloudtrail:StopLogging ở mọi tài khoản | | | Chặn xoá bucket log | | | Áp cho cả quản trị viên tài khoản | |

{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging",
            "cloudtrail:DeleteTrail",
            "cloudtrail:UpdateTrail"],
 "Resource": "arn:aws:cloudtrail:*:*:trail/trail-to-chuc"}

Ba lưu ý về giữ log: | Lưu ý | Chi tiết | |---|---| | Lifecycle chuyển log cũ sang Glacier | | | Nhưng giữ ở lớp lấy được nhanh nếu cần điều tra | | | Ghi rõ chính sách giữ trong tài liệu tuân thủ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy validate-logs xem log toàn vẹn | | | Thử tắt trail từ tài khoản con — phải bị từ chối | | | Kiểm tài khoản mới có tự được phủ không | |

Và một lời khuyên: hãy đặt bucket log ở một tài khoản mà không ai trong đội vận hành có quyền ghi hay xoá. Ghi nhận nằm cùng chỗ với thứ nó ghi nhận chỉ có giá trị cho tới khi chỗ đó bị chiếm — và đó chính là lúc bạn cần nó nhất.

Câu 194 Domain - Design for New Solutions

A small telecommunications company has recently adopted a hybrid cloud architecture with AWS. They are storing static files of their on-premises web application on a 5 TB gateway-stored volume in AWS Storage Gateway, which is attached to the application server via an iSCSI interface. As part of their disaster recovery plan, they should be able to run the web application on AWS in case their on-premises network encountered any technical issues.

Which of the following options is the MOST suitable solution that you should implement?

  1. A

    Generate an EBS snapshot of the static content from the AWS Storage Gateway service. Afterward, restore it to an EBS volume that you can then attach to the EC2 instance where the application server is hosted.
  2. B For the static content, create an EFS file system from the AWS Storage Gateway service and mount it to the EC2 instance where the application server is hosted.
  3. C

    Restore the static content from an AWS Storage Gateway to an S3 bucket and link it to the EC2 instance where the app server is running.
  4. D Restore the static content by attaching the AWS Storage Gateway to the EC2 instance that hosts the application server.
Xem giải thích

Đáp án

**A — Tạo ảnh chụp EBS của nội dung tĩnh từ AWS Storage Gateway, sau đó khôi phục thành một volume EBS và gắn vào EC2 chạy máy chủ ứng dụng.

Vì sao đúng

Đề mô tả gateway-stored volume, và đặc tính của nó quyết định câu trả lời:

Chế độ stored: dữ liệu chính nằm trên
  đĩa cục bộ
    → và được sao lưu bất đồng bộ
      lên S3 dưới dạng EBS SNAPSHOT
        ↓
    Ảnh chụp đó tạo được volume EBS
    → gắn thẳng vào EC2

⚠ Đây là cơ chế mà volume gateway thiết kế sẵn cho DR:

Trung tâm dữ liệu tại chỗ gặp sự cố
    → ảnh chụp đã nằm trên AWS
        ↓
    Tạo volume từ ảnh chụp
    → khởi động EC2, gắn volume
    → ứng dụng chạy trên cloud
        ↓
    Không cần gateway nào ở giữa

Tạo ảnh chụp:

aws storagegateway create-snapshot-from-volume-recovery-point \
  --volume-arn <arn-volume> \
  --snapshot-description "sao luu noi dung tinh hang ngay"

Khôi phục thành volume EBS:

aws ec2 create-volume --snapshot-id snap-abc \
  --availability-zone ap-southeast-1a \
  --volume-type gp3

aws ec2 attach-volume --volume-id vol-moi \
  --instance-id i-may-chu-ung-dung --device /dev/sdf

⚠ Volume tạo từ snapshot dùng được NGAY nhưng nạp lười:

Dữ liệu kéo từ S3 khi lần đầu
  đọc mỗi khối
    → vài lần đọc đầu chậm hơn
        ↓
    Bật Fast Snapshot Restore
      để hết hiện tượng đó

aws ec2 enable-fast-snapshot-restores \
  --availability-zones ap-southeast-1a \
  --source-snapshot-ids snap-abc

⚠ Và mount volume trên Linux:

lsblk -f
mount /dev/nvme1n1 /var/www/noi-dung-tinh

Volume giữ nguyên hệ thống tệp
  và dữ liệu như ở tại chỗ
    → không phải định dạng lại

⚠ Vì sao gắn thẳng Storage Gateway (phương án D) không hợp:

Gateway là phần mềm chạy trên
  máy ảo hoặc EC2
        ↓
    Nếu mạng tại chỗ đã hỏng
    → gateway ở đó cũng không dùng được
        ↓
    Và dựng gateway mới trên EC2
      rồi kéo dữ liệu
    → chậm hơn nhiều so với tạo
      volume từ ảnh chụp

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dữ liệu sẵn sàng gần như tức thì | | | Không cần dựng gateway lúc khủng hoảng | | | Là cơ chế DR có sẵn của volume gateway | |

⚠ Nhưng phải chú ý RPO của chế độ stored:

Ảnh chụp theo lịch — ví dụ hằng ngày
    → RPO tệ nhất là 24 giờ
        ↓
    Cần RPO ngắn hơn: chụp thường
      xuyên hơn
    → hoặc chuyển sang chế độ cached
      (dữ liệu chính đã trên S3)

Lên lịch chụp tự động:

aws storagegateway update-snapshot-schedule \
  --volume-arn <arn-volume> \
  --start-at 2 --recurrence-in-hours 8 \
  --description "chup 3 lan moi ngay"

⚠ Và ảnh chụp nên sao chép sang Region khác:

Ảnh chụp nằm ở một Region
    → mất Region đó là mất luôn
        ↓
    Data Lifecycle Manager sao chép
      tự động sang Region khác

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

  • **D. Gắn AWS Storage Gateway vào chính EC2 chạy máy chủ ứng dụng để khôi phục nội dung tĩnh — đây là phương án gần nhất và về lý thuyết dựng được gateway trên EC2, nhưng nó chậm hơn hẳn: phải dựng gateway, kích hoạt, nạp cache rồi mới đọc được dữ liệu; trong khi tạo volume từ ảnh chụp là thao tác một bước.
  • **C. Khôi phục nội dung tĩnh từ Storage Gateway vào bucket S3 rồi liên kết với EC2 — ảnh chụp của volume gateway là EBS snapshot, không phải object S3 đọc trực tiếp được; và ứng dụng đang mong đợi một hệ thống tệp.
  • **B. Tạo hệ thống tệp EFS từ dịch vụ Storage Gateway — không có cơ chế nào tạo EFS từ volume gateway; đó là hai dịch vụ không liên quan.

Ghi nhớ

⚠ Hai chế độ của Volume Gateway — bảng phải thuộc: | Chế độ | Dữ liệu chính | Đĩa cục bộ cần | |---|---|---| | Stored | trên đĩa cục bộ | TOÀN BỘ dung lượng | | Cached | trên S3 | chỉ cho cache |

Đề nói "gateway-stored volume 5 TB"
    → toàn bộ 5 TB nằm tại chỗ
    → S3 giữ bản sao lưu

Từ khoá nhận diện:

"stored volume, disaster recovery" → EBS snapshot → volume → EC2 "unlimited capacity, low latency" → cached volume "replace tape library" → Tape Gateway "NFS/SMB share on S3" → File Gateway

Ba lưu ý về ảnh chụp của volume gateway: | Lưu ý | Chi tiết | |---|---| | Lưu thành EBS snapshot thật | | | Tạo volume EBS từ đó và gắn vào EC2 | | | Đây là con đường di chuyển lên cloud | |

⚠ Chụp ảnh khi hệ thống tệp đang ghi:

Ảnh chụp lúc đang ghi
    → crash-consistent
        ↓
    Với nội dung tĩnh thì thường ổn
    → nhưng với CSDL thì phải
      đóng băng trước khi chụp

Ba lưu ý về Fast Snapshot Restore: | Lưu ý | Chi tiết | |---|---| | Bỏ giai đoạn nạp lười | | | Tính phí theo giờ mỗi ảnh chụp mỗi AZ | | | Bật trước khi cần, không phải lúc khủng hoảng | |

Ba lưu ý về rút ngắn RTO: | Lưu ý | Chi tiết | |---|---| | AMI dựng sẵn có ứng dụng cài đặt xong | | | CloudFormation dựng hạ tầng bằng một lệnh | | | Kịch bản khôi phục viết sẵn và diễn tập | |

⚠ Hạ tầng dạng mã rút ngắn RTO nhiều nhất:

Dựng tay lúc khủng hoảng
    → chậm và dễ sai
        ↓
    Một lệnh `create-stack`
    → hạ tầng lên trong vài phút

Ba lưu ý về chi phí ảnh chụp: | Lưu ý | Chi tiết | |---|---| | Ảnh chụp tăng dần, chỉ lưu khối thay đổi | | | Data Lifecycle Manager dọn ảnh cũ | | | Sao chép xuyên Region có phí truyền | |

aws dlm create-lifecycle-policy \
  --description "Chup anh volume gateway" \
  --state ENABLED --execution-role-arn <arn> \
  --policy-details '{
    "ResourceTypes":["VOLUME"],
    "TargetTags":[{"Key":"SaoLuu","Value":"HangNgay"}],
    "Schedules":[{"Name":"hang-ngay",
      "CreateRule":{"Interval":24,"IntervalUnit":"HOURS"},
      "RetainRule":{"Count":30},
      "CrossRegionCopyRules":[{"TargetRegion":"us-west-2",
        "Encrypted":true,"RetainRule":{"Interval":30,
        "IntervalUnit":"DAYS"}}]}]}'

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Ảnh chụp mã hoá nếu volume mã hoá | | | CHAP xác thực kết nối iSCSI | | | Gateway trong subnet riêng tư | |

Ba lưu ý về giám sát gateway: | Chỉ số | Ý nghĩa | |---|---| | UploadBufferPercentUsed | buffer đầy là ứng dụng treo | | CloudBytesUploaded | tốc độ tải lên | | Trạng thái gateway | có kết nối tới AWS không |

Ba lưu ý về diễn tập DR: | Lưu ý | Chi tiết | |---|---| | Khôi phục thử định kỳ và bấm giờ | | | Kiểm dữ liệu sau khi khôi phục có đủ | | | Ghi lại RTO và RPO đo được | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo volume từ ảnh chụp mới nhất, gắn và mount | | | So nội dung với dữ liệu tại chỗ | | | Bấm giờ toàn bộ quá trình khôi phục | |

Và một lời khuyên: hãy khôi phục thử một volume từ ảnh chụp ít nhất mỗi quý. Ảnh chụp chạy đều đặn và báo thành công không có nghĩa là nó dùng được — và ngày bạn phát hiện điều đó không nên là ngày trung tâm dữ liệu gặp sự cố.

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

A leading commercial bank has a hybrid network architecture and is extensively using AWS for its day-to-day operations. The bank uses an Amazon S3 bucket to store sensitive bank records. It has versioning enabled and does not have any encryption. The new solutions architect for the company was asked to implement Server-Side Encryption with Customer-Provided Encryption Keys (SSE-C) for the Amazon S3 bucket to ensure data inside it is secured both at rest and in transit.

Which of the following options should the solutions architect implement to achieve the company requirements? (Select TWO.)

  1. A Only use the S3 console to upload and update objects with SSE-C encryption.
  2. B Use WSS (WebSocket Secure)
  3. C

    For Amazon S3 REST API calls, use the following HTTP Request Headers: x-amz-server-side​-encryption​-customer-algorithm x-amz-server-side​-encryption​-customer-key x-amz-server-side​-encryption​-customer-key-MD5
  4. D

    For presigned URLs, specify the algorithm using the x-amz-server-side​-encryption​-customer-key-MD5 request header
  5. E

    For presigned URLs, specify the algorithm using the x-amz-server-side​-encryption​-customer-algorithm request header
Xem giải thích

Đáp án

**C và E — Với lời gọi REST API của S3, dùng ba header: x-amz-server-side-encryption-customer-algorithm, x-amz-server-side-encryption-customer-key, x-amz-server-side-encryption-customer-key-MD5; và với pre-signed URL, khai thuật toán bằng header x-amz-server-side-encryption-customer-algorithm.

Vì sao đúng

SSE-C là chế độ mà bạn giữ khoá và gửi nó theo từng request, nên mỗi lời gọi phải mang đủ thông tin: | Header | Vai trò | |---|---| | ...customer-algorithm | thuật toán, luôn là AES256 | | ...customer-key | khoá 256-bit mã hoá base64 | | ...customer-key-MD5 | băm MD5 của khoá để S3 kiểm tính toàn vẹn |

⚠ AWS KHÔNG lưu khoá — đây là điểm cốt lõi của SSE-C:

S3 dùng khoá để mã hoá rồi
  XOÁ NÓ KHỎI BỘ NHỚ
        ↓
    Chỉ giữ lại giá trị HMAC để
      kiểm tra khoá lần sau có đúng không
        ↓
    Mất khoá = mất dữ liệu vĩnh viễn

Tải lên với SSE-C:

aws s3api put-object --bucket ho-so-ngan-hang \
  --key bao-cao.pdf --body bao-cao.pdf \
  --sse-customer-algorithm AES256 \
  --sse-customer-key fileb://khoa.bin \
  --sse-customer-key-md5 $(openssl md5 -binary khoa.bin | base64)

⚠ Và phải gửi lại đúng ba header đó khi TẢI VỀ:

Không có khoá: S3 trả 400
    → không có cách nào giải mã
        ↓
    Đây là khác biệt lớn nhất với
      SSE-S3 và SSE-KMS
    → hai loại kia tải về không cần gì

⚠ Với pre-signed URL, cơ chế khác hẳn:

Người tạo URL khai THUẬT TOÁN
  trong URL
        ↓
    Nhưng KHOÁ vẫn phải do người
      dùng URL gửi trong header
        ↓
    Vì khoá không bao giờ được đưa
      vào URL — nó sẽ nằm trong log

url = s3.generate_presigned_url('get_object',
    Params={'Bucket': 'ho-so-ngan-hang', 'Key': 'bao-cao.pdf',
            'SSECustomerAlgorithm': 'AES256'},
    ExpiresIn=900)

Đây là lý do phương án D sai — nó khai ...customer-key-MD5 thay vì ...customer-algorithm.

⚠ Và SSE-C BẮT BUỘC dùng HTTPS:

Khoá đi trong header
    → gửi qua HTTP là lộ khoá
        ↓
    S3 TỪ CHỐI mọi request SSE-C
      không dùng HTTPS
    → đây là cách "mã hoá khi truyền"
      được bảo đảm

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bạn kiểm soát hoàn toàn khoá | | | AWS không bao giờ giữ khoá | | | Không phụ thuộc KMS, không có phí KMS | |

⚠ Nhưng đổi lại là gánh nặng rất lớn:

Phải tự lưu, tự xoay, tự sao lưu khoá
    → mọi ứng dụng đọc object phải
      có khoá
        ↓
    Mất khoá là mất dữ liệu
    → và không dùng được với
      lifecycle chuyển lớp lưu trữ

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

  • **D. Với pre-signed URL, khai thuật toán bằng header ...customer-key-MD5 — đây là phương án gần nhất và header đó có thật trong SSE-C, nhưng nó dùng để gửi băm MD5 của khoá chứ không phải khai thuật toán; khai thuật toán là ...customer-algorithm.
  • **A. Chỉ dùng bảng điều khiển S3 để tải lên và cập nhật object với SSE-C — bảng điều khiển không hỗ trợ SSE-C; phải dùng REST API, CLI hoặc SDK.
  • **B. Dùng WSS (WebSocket Secure) — WebSocket là giao thức cho kết nối hai chiều thời gian thực, hoàn toàn không liên quan tới S3 hay mã hoá object.

Ghi nhớ

⚠ Bốn cách mã hoá object trên S3 — bảng phải thuộc: | Cách | Ai giữ khoá | Gửi khoá theo request | |---|---|---| | SSE-S3 | AWS hoàn toàn | không | | SSE-KMS | KMS, bạn đặt chính sách | không | | SSE-C | BẠN | CÓ, mỗi request | | Client-side | BẠN | không, mã hoá trước khi gửi |

Từ khoá nhận diện:

"customer-provided encryption keys" → SSE-C, ba header "AWS must never store the key" → SSE-C hoặc client-side "audit who decrypted" → SSE-KMS "simplest, no key management" → SSE-S3

Ba lưu ý về SSE-C: | Lưu ý | Chi tiết | |---|---| | Bắt buộc HTTPS | | | Không dùng được từ bảng điều khiển | | | Không dùng được với lifecycle chuyển lớp | |

⚠ Điểm cuối là hạn chế ít người biết:

Chuyển object SSE-C sang Glacier
    → S3 cần khoá để đọc và ghi lại
    → nhưng nó không giữ khoá
        ↓
    Lifecycle transition không hoạt động
      với object SSE-C

Ba lưu ý về xoay khoá SSE-C: | Lưu ý | Chi tiết | |---|---| | Phải tự chép lại object bằng khoá mới | | | copy-object với khoá cũ và khoá mới | | | Không có xoay tự động | |

aws s3api copy-object --bucket ho-so-ngan-hang \
  --key bao-cao.pdf \
  --copy-source ho-so-ngan-hang/bao-cao.pdf \
  --copy-source-sse-customer-algorithm AES256 \
  --copy-source-sse-customer-key fileb://khoa-cu.bin \
  --sse-customer-algorithm AES256 \
  --sse-customer-key fileb://khoa-moi.bin

Ba lưu ý về versioning kèm SSE-C: | Lưu ý | Chi tiết | |---|---| | Mỗi phiên bản có khoá riêng của nó | | | Đọc phiên bản cũ cần đúng khoá lúc đó | | | Phải theo dõi khoá nào cho phiên bản nào | |

⚠ Đây là gánh nặng thật sự khi bật versioning với SSE-C:

Xoay khoá ba lần trong một năm
    → phiên bản cũ vẫn dùng khoá cũ
        ↓
    Phải giữ MỌI khoá cũ
    → mất một cái là mất một
      phiên bản dữ liệu

Ba lưu ý về bắt buộc mã hoá: | Lưu ý | Chi tiết | |---|---| | Bucket policy chặn PUT không mã hoá | | | Điều kiện s3:x-amz-server-side-encryption-customer-algorithm | | | Và điều kiện aws:SecureTransport | |

{"Effect": "Deny", "Principal": "*",
 "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::ho-so-ngan-hang/*",
 "Condition": {"Null":
   {"s3:x-amz-server-side-encryption-customer-algorithm": "true"}}}

Ba lưu ý về khi nào KHÔNG nên chọn SSE-C: | Trường hợp | Lý do | |---|---| | Cần lifecycle chuyển lớp | không hoạt động | | Nhiều ứng dụng cùng đọc | phải phân phối khoá cho tất cả | | Muốn nhật ký giải mã | SSE-KMS cho CloudTrail |

⚠ Với ngân hàng, SSE-KMS thường phù hợp hơn:

Yêu cầu thật sự thường là "chúng tôi
  kiểm soát khoá"
        ↓
    SSE-KMS với khoá do khách hàng
      quản lý đáp ứng được
    → và có CloudTrail ghi ai giải mã
    → không phải tự lo vòng đời khoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải về không gửi khoá — phải lỗi | | | Gửi khoá sai — phải lỗi | | | Thử qua HTTP — phải bị từ chối | |

Và một lời khuyên: hãy cân nhắc thật kỹ trước khi chọn SSE-C thay vì SSE-KMS. Yêu cầu "chúng tôi phải kiểm soát khoá" thường được đáp ứng đầy đủ bởi khoá KMS do khách hàng quản lý — còn SSE-C bắt bạn nhận toàn bộ trách nhiệm lưu trữ, xoay và sao lưu khoá, và mất một khoá nghĩa là mất dữ liệu vĩnh viễn.

Câu 196 Chọn nhiều đáp án Domain - Design Solutions for Organizational Complexity

A leading financial company owns multiple AWS accounts that are consolidated under one AWS Organization. To ensure that tags are always added when users create any resources across all accounts, the solutions architect should enforce the use of centralized resource provisioning tools and infrastructure-as-code templates that apply tags automatically upon resource creation across all account.

Which of the following options are the recommended actions to achieve the company requirements? (Select TWO.)

  1. A

    Set up AWS Config to add the corresponding tags to your resources right from the very moment that they are created.
  2. B

    Set up the CloudFormation Resource Tags property to apply tags to certain resource types upon creation.
  3. C

    Set up AWS Systems Manager Automation to automatically add tags to your provisioned resources.
  4. D

    Set up AWS Service Catalog to tag the provisioned resources with corresponding unique identifiers for portfolio, product, and users.
  5. E

    Set up AWS generated tags by activating it in the Billing and Cost Management console of the member account.
Xem giải thích

Đáp án

**B và D — Dùng thuộc tính Resource Tags của CloudFormation để gắn tag cho các loại tài nguyên khi tạo; và dùng AWS Service Catalog để gắn tag cho tài nguyên đã cấp phát với định danh duy nhất của danh mục, sản phẩm và người dùng.

Vì sao đúng

Đề nêu rõ hai công cụ cần dùng, và hai đáp án chính là hai công cụ đó: | Yêu cầu trong đề | Đáp án | |---|---| | Công cụ cấp phát tài nguyên tập trung | Service Catalog | | Mẫu hạ tầng dạng mã gắn tag tự động | CloudFormation Resource Tags |

⚠ Điểm chung: cả hai gắn tag NGAY LÚC TẠO tài nguyên:

Gắn tag sau khi tạo (Config, Lambda,
  Automation)
    → có khoảng thời gian tài nguyên
      chưa có tag
        ↓
    Trong khoảng đó, báo cáo chi phí
      không quy được về ai
    → và tài nguyên có thể bị bỏ sót

Gắn tag ở cấp stack:

aws cloudformation create-stack --stack-name ung-dung \
  --template-body file://template.yaml \
  --tags Key=TrungTamChiPhi,Value=CC-1234 \
         Key=MaDuAn,Value=DA-5678

⚠ Tag ở cấp stack tự lan xuống MỌI tài nguyên hỗ trợ tag:

Không phải khai tag trong từng
  tài nguyên
        ↓
    CloudFormation tự gắn cho tất cả
    → và tag đó không xoá được
      khỏi tài nguyên riêng lẻ

Gắn tag cho một tài nguyên cụ thể:

Resources:
  CoSoDuLieu:
    Type: AWS::RDS::DBInstance
    Properties:
      Engine: postgres
      Tags:
        - Key: TrungTamChiPhi
          Value: !Ref MaTrungTamChiPhi
        - Key: MaDuAn
          Value: !Ref MaDuAn

⚠ Service Catalog gắn thêm TagOption tự động:

aws servicecatalog create-tag-option \
  --key TrungTamChiPhi --value CC-1234

aws servicecatalog associate-tag-option-with-resource \
  --resource-id port-abc --tag-option-id tag-xyz

Người dùng cấp phát sản phẩm
    → Service Catalog tự gắn TagOption
      của danh mục
    → người dùng KHÔNG bỏ qua được

⚠ Và Service Catalog còn gắn tag định danh tự động:

`aws:servicecatalog:portfolioArn`
`aws:servicecatalog:productArn`
`aws:servicecatalog:provisioningPrincipalArn`
        ↓
    Truy được tài nguyên về đúng
      danh mục, sản phẩm và người tạo

⚠ Nhưng gắn tag thôi chưa đủ — phải BẮT BUỘC bằng SCP:

{"Effect": "Deny", "Action": "rds:CreateDBInstance",
 "Resource": "*",
 "Condition": {"Null":
   {"aws:RequestTag/TrungTamChiPhi": "true"}}}

Người dùng vẫn tạo tài nguyên
  bằng bảng điều khiển
    → SCP chặn nếu thiếu tag
    → hai lớp bổ sung cho nhau

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tag có ngay từ giây đầu tài nguyên tồn tại | | | Người dùng không phải nhớ gắn tag | | | Áp được cho toàn tổ chức qua danh mục dùng chung | |

⚠ Và launch constraint là cơ chế then chốt của Service Catalog:

Người dùng không có quyền tạo RDS
    → nhưng launch constraint cho
      Service Catalog dùng một vai trò
      có quyền
        ↓
    Họ tạo được ĐÚNG sản phẩm trong
      danh mục, với đúng tag
    → và không tạo được gì khác

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

  • **A. Dùng AWS Config để gắn tag ngay từ lúc tài nguyên được tạo — đây là phương án gần nhất và Config có tính năng tự sửa (remediation), nhưng nó là công cụ phát hiện: Config đánh giá sau khi tài nguyên đã tồn tại, không gắn tag "ngay từ giây đầu".
  • **C. Dùng Systems Manager Automation tự gắn tag cho tài nguyên đã cấp phát — cũng là gắn tag sau khi tạo, và phải tự viết và bảo trì runbook.
  • **E. Bật tag do AWS sinh trong bảng điều khiển Billing của tài khoản thành viên — tag do AWS sinh (aws:createdBy) không phải tag nghiệp vụ; và cost allocation tag chỉ bật được ở tài khoản quản lý, không phải tài khoản thành viên.

Ghi nhớ

⚠ Ba nhóm cơ chế quản lý tag — bảng phải thuộc: | Nhóm | Công cụ | Thời điểm | |---|---|---| | Gắn tag lúc tạo | CloudFormation, Service Catalog | ngay lập tức | | Bắt buộc có tag | SCP, IAM policy | chặn lúc tạo | | Phát hiện thiếu tag | Config, Tag Editor | sau khi tạo |

Từ khoá nhận diện:

"apply tags automatically upon creation" → CloudFormation Tags, Service Catalog "prevent creation without tags" → SCP với aws:RequestTag "find and fix untagged resources" → Config hoặc Tag Editor "cost allocation by tag" → kích hoạt cost allocation tag ở tài khoản quản lý

⚠ Ba khoá điều kiện về tag — phải phân biệt: | Khoá | Dùng khi | |---|---| | aws:RequestTag/Khoa | tag đang được gắn trong request | | aws:ResourceTag/Khoa | tag đã có trên tài nguyên | | aws:TagKeys | danh sách khoá tag trong request |

Ba lưu ý về cost allocation tag: | Lưu ý | Chi tiết | |---|---| | Kích hoạt ở tài khoản quản lý | | | Mất tới 24 giờ mới xuất hiện trong báo cáo | | | Không áp ngược cho chi phí quá khứ | |

⚠ Điểm cuối rất quan trọng khi lập kế hoạch:

Kích hoạt tag hôm nay
    → báo cáo chi phí THÁNG TRƯỚC
      vẫn không có tag đó
        ↓
    Kích hoạt sớm, kể cả khi chưa
      dùng tới

Ba lưu ý về Tag Editor: | Lưu ý | Chi tiết | |---|---| | Gắn tag hàng loạt cho tài nguyên đã có | | | Tìm tài nguyên thiếu tag qua nhiều Region | | | Dùng để dọn tồn đọng, không thay cơ chế tự động | |

Ba lưu ý về tag policy của Organizations: | Lưu ý | Chi tiết | |---|---| | Chuẩn hoá tên khoá và giá trị hợp lệ | | | Ngăn costcenter và CostCenter cùng tồn tại | | | Có thể chặn thao tác không tuân thủ | |

{"tags": {"TrungTamChiPhi": {
  "tag_key": {"@@assign": "TrungTamChiPhi"},
  "tag_value": {"@@assign": ["CC-1234", "CC-5678"]},
  "enforced_for": {"@@assign": ["rds:*", "dynamodb:*"]}}}}

⚠ Tag policy giải quyết vấn đề mà SCP không giải quyết:

SCP: bắt buộc CÓ tag
    → nhưng giá trị gì cũng được
        ↓
    Tag policy: chuẩn hoá tên khoá
      và danh sách giá trị hợp lệ
    → báo cáo chi phí mới gộp đúng

Ba lưu ý về Service Catalog: | Lưu ý | Chi tiết | |---|---| | Sản phẩm là CloudFormation template có phiên bản | | | Launch constraint cho người ít quyền tạo tài nguyên | | | Chia sẻ danh mục qua Organizations | |

Ba lưu ý về CloudFormation: | Lưu ý | Chi tiết | |---|---| | Tag cấp stack lan xuống mọi tài nguyên | | | Không phải mọi loại tài nguyên đều hỗ trợ tag | | | StackSets áp cho nhiều tài khoản cùng lúc | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo tài nguyên qua Service Catalog, kiểm tag | | | Thử tạo RDS không có tag — SCP phải chặn | | | Dùng Tag Editor tìm tài nguyên còn thiếu tag | |

Và một lời khuyên: hãy kết hợp gắn tag tự động với SCP bắt buộc chứ đừng chỉ dùng một trong hai. Gắn tag tự động chỉ phủ những tài nguyên đi qua công cụ của bạn — còn SCP phủ cả những cái ai đó tạo tay lúc ba giờ sáng để sửa gấp một sự cố.

Câu 197 Domain - Continuous Improvement for Existing Solutions

A medical firm uses an image analysis application that extracts data from multiple images. The input stream analyzes a batch of images and for each file, it writes the result data to an output stream of files. The number of input files per day grows and peaks for a few hours in a day. The application is hosted on an Amazon EC2 instance with a large EBS volume that hosts the input data, but the results still take almost 20 hours per day to be processed.

Which of the following solutions can be implemented to reduce the processing time and improve the availability of the application?

  1. A Store I/O files in S3 instead and use SQS to facilitate a group of hosts working in parallel. Include the hosts in an auto scaling group that scales accordingly to the number of SNS notifications.
  2. B Store I/O files in an EBS Provisioned IOPS volume, and use SNS to facilitate a group of hosts working in parallel. Include the hosts in an auto scaling group that scales accordingly to the number of SNS notifications.
  3. C Store I/O files in an EBS Provisioned IOPS volume, and use SNS to facilitate a group of hosts working in parallel. Include the hosts in an auto scaling group that scales accordingly to the length of your SQS queue.
  4. D Store I/O files in S3 instead and use SQS to facilitate a group of hosts working in parallel. Include the hosts in an auto scaling group that scales accordingly to the length of your SQS queue.
Xem giải thích

Đáp án

**D — Lưu tệp vào và ra trên S3 thay vì EBS, dùng SQS để nhiều máy chủ làm việc song song, và đặt các máy chủ trong Auto Scaling group co giãn theo ĐỘ DÀI hàng đợi SQS.

Vì sao đúng

Đề nêu ba vấn đề, và phương án này giải cả ba: | Vấn đề | Cách giải | |---|---| | Một EC2 xử lý 20 giờ mỗi ngày | nhiều máy xử lý song song | | Số tệp tăng và có đỉnh vài giờ | ASG co giãn theo hàng đợi | | Tính sẵn sàng kém (một máy) | nhiều máy trên nhiều AZ |

⚠ EBS là nút thắt cốt lõi — nó chỉ gắn được vào MỘT instance:

Dữ liệu nằm trên EBS
    → chỉ máy gắn volume đó đọc được
        ↓
    Không thể có nhiều máy cùng
      xử lý song song
    → đây là nguyên nhân gốc của
      20 giờ xử lý

⚠ S3 mở khoá cho việc song song hoá:

Mọi instance đọc và ghi cùng bucket
    → thêm bao nhiêu máy cũng được
        ↓
    Và S3 không có trần IOPS như EBS
    → hàng nghìn yêu cầu mỗi giây
      mỗi tiền tố

⚠ Và co giãn theo ĐỘ DÀI HÀNG ĐỢI là điểm phân biệt với các phương án khác:

Co giãn theo số thông báo SNS
    → SNS không có "độ dài" nào
    → không có chỉ số để co giãn
        ↓
    SQS có `ApproximateNumberOfMessagesVisible`
    → biết chính xác còn bao nhiêu việc

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

⚠ Nhưng phải tính đúng chỉ số:

Độ dài hàng đợi một mình
    → 1.000 thông điệp là nhiều hay ít?
    → phụ thuộc số máy đang chạy
        ↓
    Chỉ số đúng: hàng chờ / số instance

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

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

Chính sách co giãn:

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

⚠ Và Spot instance rất hợp với mẫu này:

Xử lý ảnh theo lô chịu được gián đoạn
    → thông điệp quay lại hàng đợi
      nếu máy bị thu hồi
        ↓
    Spot rẻ hơn tới 90%
    → giảm chi phí mạnh cho phần
      co giãn theo đỉnh

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Xử lý song song, giảm mạnh thời gian | | | Tự co giãn theo đỉnh tải trong ngày | | | Máy hỏng không mất việc, thông điệp quay lại hàng đợi | |

⚠ Visibility timeout phải dài hơn thời gian xử lý một tệp:

Xử lý một ảnh mất 3 phút,
  timeout 30 giây
        ↓
    Thông điệp hiện lại giữa chừng
    → máy khác xử lý cùng ảnh
    → tốn gấp đôi tài nguyên

⚠ Và S3 event notification bỏ được bước đẩy thông điệp thủ công:

{"QueueConfigurations": [{
  "Events": ["s3:ObjectCreated:*"],
  "Filter": {"Key": {"FilterRules": [
    {"Name": "prefix", "Value": "dau-vao/"}]}},
  "QueueArn": "<arn-hang-doi>"}]}

Tải ảnh lên S3
    → S3 tự đẩy thông điệp vào SQS
    → không cần mã nào ở giữa

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

  • **C. Lưu tệp trên EBS Provisioned IOPS, dùng SNS cho các máy làm việc song song, ASG co giãn theo độ dài hàng đợi SQS — đây là phương án gần nhất và phần co giãn theo hàng đợi hoàn toàn đúng, nhưng EBS chỉ gắn được vào một instance nên không song song hoá được; và nó nói SNS trong khi lại co giãn theo SQS, mâu thuẫn nội tại.
  • **A. Lưu trên S3 và dùng SQS, nhưng ASG co giãn theo số thông báo SNS — phần lưu trữ và hàng đợi đúng, nhưng SNS không có chỉ số "số thông báo đang chờ" để co giãn theo.
  • **B. Lưu trên EBS Provisioned IOPS và dùng SNS — sai cả hai vế: EBS không chia sẻ được, SNS không đệm việc.

Ghi nhớ

⚠ Ba lựa chọn lưu trữ và khả năng chia sẻ — bảng phải thuộc: | Lưu trữ | Nhiều instance dùng chung | |---|---| | EBS | KHÔNG (trừ Multi-Attach, một AZ, io1/io2) | | EFS | có, qua NFS | | S3 | có, qua API |

Từ khoá nhận diện:

"parallel processing, many hosts" → S3 hoặc EFS, KHÔNG phải EBS "scale by queue length" → SQS + backlog per instance "fan out to many subscribers" → SNS "one worker per task" → SQS

⚠ SNS và SQS — bảng phải thuộc: | Tiêu chí | SNS | SQS | |---|---|---| | Mô hình | đẩy, phát tán | kéo, hàng đợi | | Lưu trữ | không lưu | tới 14 ngày | | Chỉ số co giãn | không có | ApproximateNumberOfMessagesVisible |

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

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

Ba lưu ý về S3 cho tệp lớn: | Lưu ý | Chi tiết | |---|---| | Multipart upload cho tệp trên 100 MB | | | Lifecycle dọn upload dở dang | | | Tiền tố riêng cho đầu vào và đầu ra | |

⚠ Upload dở dang là chi phí vô hình:

{"Rules": [{
  "ID": "don-upload-do-dang",
  "Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Upload hỏng giữa chừng
    → các phần đã tải vẫn tính tiền
    → không hiện trong danh sách object

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

⚠ Lifecycle hook tránh cắt việc giữa chừng:

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

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

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

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy nhiều tệp, xem ASG mở rộng | | | Đo tổng thời gian xử lý trước và sau | | | Kiểm không có tệp nào xử lý hai lần | |

Và một lời khuyên: hãy chuyển dữ liệu ra khỏi EBS trước khi nghĩ tới bất cứ tối ưu nào khác. Chừng nào tệp còn nằm trên một volume gắn vào một máy, mọi nỗ lực song song hoá đều bị chặn ở đúng chỗ đó — và tăng IOPS chỉ làm một máy chạy nhanh hơn một chút.

Câu 198 Domain - Design for New Solutions

A leading telecommunications company is moving all of its mission-critical, multi-tier applications to AWS. At present, their architecture is composed of desktop client applications and several servers that are all located in their on-premises data center. The application-tier is using a MySQL database that is hosted on a single VM while both the presentation and business logic layers are distributed across multiple VMs. There has been a lot of reports that their users, who access the applications remotely, are experiencing increased connection latency and slow load times.

Which of the following is the MOST cost-effective solution to improve the uptime of the application with MINIMAL change and improve the overall user experience?

  1. A

    Use Amazon ElastiCache to improve the overall user experience of your desktop applications. Directly migrate the MySQL database from your VM to a DynamoDB database. Host the application and presentation layers in AWS Fargate containers behind an Application Load Balancer.
  2. B

    Use Amazon AppStream 2.0 to centrally manage your desktop applications and improve the overall user experience. Migrate the MySQL database from your VM to Amazon Aurora. Host the application and presentation layers in an Auto Scaling group on EC2 instances behind an Application Load Balancer.
  3. C

    Using Amazon WorkSpaces, set up and allocate a workspace for each user to improve the overall user experience. Migrate the MySQL database from your VM to a self-hosted MySQL database in a large EC2 instance. Host the application and presentation layers in Amazon ECS containers behind an Application Load Balancer.
  4. D

    Set up a new CloudFront web distribution to improve the overall user experience of your desktop applications. Migrate the MySQL database from your VM to a Redshift cluster. Host the application and presentation layers in ECS containers behind a Network Load Balancer.
Xem giải thích

Đáp án

**B — Dùng Amazon AppStream 2.0 để quản lý tập trung ứng dụng desktop và cải thiện trải nghiệm người dùng; chuyển CSDL MySQL sang Amazon Aurora; chạy tầng ứng dụng và trình bày trên Auto Scaling group EC2 sau Application Load Balancer.

Vì sao đúng

Đề mô tả một kiến trúc client-server truyền thống với người dùng ở xa, và nguyên nhân độ trễ nằm ở chính mô hình đó:

Ứng dụng desktop chạy trên máy
  người dùng
    → mỗi thao tác gọi về máy chủ
      qua Internet
        ↓
    Người dùng ở xa: hàng chục lời gọi
      × độ trễ cao
    → trang tải chậm

⚠ AppStream 2.0 đảo ngược mô hình đó:

Ứng dụng chạy trên EC2 TRONG AWS
    → ngay cạnh máy chủ ứng dụng
        ↓
    Chỉ HÌNH ẢNH màn hình được
      truyền về người dùng
    → độ trễ giữa ứng dụng và máy chủ
      gần như bằng 0

⚠ Và đây là điểm phân biệt với WorkSpaces: | Dịch vụ | Cung cấp | |---|---| | AppStream 2.0 | stream một ỨNG DỤNG cụ thể | | WorkSpaces | cả một MÁY TÍNH ẢO cho mỗi người |

Chỉ cần chạy ứng dụng nghiệp vụ
    → AppStream, trả tiền theo phiên
        ↓
    WorkSpaces: mỗi người một máy
      tính đầy đủ, đắt hơn nhiều
    → và nhiều việc quản trị hơn

Đây là lý do phương án C tốn kém hơn.

⚠ Aurora là lựa chọn "ít thay đổi nhất" cho MySQL:

Aurora tương thích MySQL ở tầng
  giao thức
    → ứng dụng không đổi một dòng nào
        ↓
    DynamoDB (phương án A) đòi thiết kế
      lại mô hình dữ liệu
    → Redshift (phương án D) là kho
      phân tích, sai loại tải

Chuyển CSDL bằng DMS:

aws dms create-replication-task \
  --replication-task-identifier chuyen-sang-aurora \
  --migration-type full-load-and-cdc \
  --source-endpoint-arn <arn-mysql-tai-cho> \
  --target-endpoint-arn <arn-aurora> \
  --replication-instance-arn <arn-instance>

⚠ Và Aurora cải thiện luôn tính sẵn sàng mà đề yêu cầu:

MySQL trên MỘT máy ảo
    → máy đó chết là mất dịch vụ
        ↓
    Aurora: sáu bản dữ liệu trên ba AZ
    → chuyển đổi thường dưới 30 giây
    → tới 15 replica cho tải đọc

Tạo fleet AppStream:

aws appstream create-fleet --name fleet-ung-dung \
  --instance-type stream.standard.medium \
  --fleet-type ON_DEMAND \
  --compute-capacity DesiredInstances=20 \
  --vpc-config SubnetIds=subnet-a,subnet-b \
  --image-name anh-ung-dung-nghiep-vu

⚠ Hai loại fleet — chọn theo mẫu sử dụng: | Loại | Đặc điểm | |---|---| | Always-On | khởi động tức thì, trả tiền cả khi rảnh | | On-Demand | rẻ hơn, người dùng chờ 1-2 phút |

Nhân viên dùng suốt giờ làm việc
    → Always-On với scaling theo lịch
        ↓
    Dùng thỉnh thoảng
    → On-Demand

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ứng dụng chạy cạnh máy chủ, hết độ trễ | | | Quản lý tập trung, cập nhật một chỗ | | | Không đổi mã ứng dụng | |

⚠ Và lợi ích thứ hai đáng nói riêng:

Ứng dụng desktop cài trên hàng trăm
  máy nhân viên
    → cập nhật phiên bản là chiến dịch
      hàng tuần
        ↓
    AppStream: cập nhật ảnh một lần
    → mọi người dùng phiên bản mới
      ngay phiên sau

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

  • **C. Dùng Amazon WorkSpaces cấp một máy tính ảo cho mỗi người, chuyển MySQL sang EC2 tự quản lý, chạy ứng dụng trên ECS — đây là phương án gần nhất và WorkSpaces thật sự giải quyết vấn đề độ trễ theo cùng nguyên lý, nhưng cấp cả một máy tính cho mỗi người đắt hơn nhiều so với stream một ứng dụng; và MySQL tự quản lý trên EC2 là bước lùi về vận hành.
  • **A. Dùng ElastiCache cải thiện trải nghiệm ứng dụng desktop và chuyển sang DynamoDB — cache không giải quyết được độ trễ mạng của ứng dụng desktop; và DynamoDB đòi viết lại toàn bộ tầng dữ liệu.
  • **D. Dùng CloudFront cải thiện ứng dụng desktop và chuyển sang Redshift — CloudFront phân phối nội dung web, không tăng tốc ứng dụng desktop; Redshift là kho dữ liệu phân tích.

Ghi nhớ

⚠ Ba dịch vụ desktop và ứng dụng ảo — bảng phải thuộc: | Dịch vụ | Cung cấp | |---|---| | AppStream 2.0 | stream một ứng dụng | | WorkSpaces | máy tính ảo đầy đủ | | WorkSpaces Web | trình duyệt an toàn qua web |

Từ khoá nhận diện:

"desktop application, remote users, latency" → AppStream 2.0 "full virtual desktop per user" → WorkSpaces "minimal change to MySQL" → Aurora hoặc RDS MySQL "rewrite data layer" → DynamoDB

Ba lưu ý về AppStream 2.0: | Lưu ý | Chi tiết | |---|---| | Image Builder dựng ảnh chứa ứng dụng | | | Fleet cấp phiên cho người dùng | | | Stack gắn fleet với chính sách và lưu trữ | |

⚠ Ba khái niệm phải phân biệt:

Image: ảnh chứa ứng dụng đã cài
    ↓
Fleet: đội máy chạy ảnh đó
    ↓
Stack: gắn fleet với người dùng,
       chính sách, home folder

Ba lưu ý về lưu trữ của người dùng: | Lưu ý | Chi tiết | |---|---| | Home folder lưu trên S3 | | | Application settings persistence lưu cấu hình | | | Bật cả hai nếu người dùng cần giữ trạng thái | |

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Fleet đặt trong VPC, cạnh tầng ứng dụng | | | Không cần Internet nếu dùng VPC endpoint | | | Kết nối AD nếu cần đăng nhập bằng tài khoản công ty | |

⚠ Đây là điều làm giải pháp này hiệu quả:

Fleet trong cùng VPC với ALB
  và Aurora
        ↓
    Ứng dụng gọi máy chủ qua mạng
      nội bộ, độ trễ dưới 1ms
    → thay vì qua Internet

Ba lưu ý về chi phí AppStream: | Lưu ý | Chi tiết | |---|---| | Phí instance theo giờ chạy | | | Cộng phí người dùng mỗi tháng | | | Scaling theo lịch giảm chi phí giờ rảnh | |

aws appstream update-fleet --name fleet-ung-dung \
  --compute-capacity DesiredInstances=5

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | Tương thích MySQL ở tầng giao thức | | | Lưu trữ tự mở rộng, sáu bản trên ba AZ | | | Aurora Serverless v2 cho tải khó đoán | |

Ba lưu ý về ASG cho tầng ứng dụng: | Lưu ý | Chi tiết | |---|---| | Trải nhiều AZ | | | health-check-type ELB | | | Ứng dụng phải stateless | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian tải trang qua AppStream so với trước | | | Kiểm phiên AppStream nối được tới ALB nội bộ | | | Đo độ trễ nhân bản Aurora | |

Và một lời khuyên: hãy đặt fleet AppStream trong cùng VPC với tầng ứng dụng. Toàn bộ giá trị của giải pháp nằm ở việc rút ngắn quãng đường giữa ứng dụng và máy chủ — đặt chúng ở hai nơi khác nhau là giữ nguyên vấn đề gốc, chỉ đổi chỗ nó đi.

Câu 199 Domain - Continuous Improvement for Existing Solutions

A company hosts an internal web portal on a fleet of Amazon EC2 instances that allows access to confidential files stored in an encrypted Amazon S3 bucket. Because the files contain sensitive information, the company does not want any files to traverse the public Internet. Bucket access should be restricted to only allow the web portal’s EC2 instances. To comply with the requirements, the Solutions Architect created an Amazon S3 VPC endpoint and associated it with the web portal’s VPC.

Which of the following actions should the Solutions Architect take to fully comply with the company requirements?

  1. A

    Create a VPC endpoint policy that restricts access to the specific Amazon S3 bucket on the current region. Apply an Amazon S3 bucket policy that only allows access from the VPC private subnets. Update the VPC’s Network Access Control List (NACL) to deny other EC2 instances from accessing the gateway prefix list.
  2. B

    Create a VPC endpoint policy that restricts access to the specific Amazon S3 bucket. Create an IAM role that grants access to the S3 bucket and attach it to the application EC2 instances. Apply an Amazon S3 bucket policy that only allows access from the VPC endpoint and those using the IAM role.
  3. C

    Create a VPC endpoint policy that restricts access to the specific Amazon S3 bucket. Apply an Amazon S3 bucket policy that only allows access from the VPC endpoint. Update the VPC’s Network Access Control List (NACL) to deny other EC2 instances from accessing the gateway prefix list.
  4. D

    Apply an Amazon S3 bucket policy that includes the aws:SourceIp condition to deny all access except those coming from the application EC2 instances IP addresses. Update the route table for the VPC to ensure that the VPC endpoint is associated only with the application instances subnets.
Xem giải thích

Đáp án

**B — Tạo VPC endpoint policy giới hạn quyền tới đúng bucket; tạo IAM role cấp quyền vào bucket và gắn vào các EC2 của cổng thông tin; và áp bucket policy chỉ cho phép truy cập từ VPC endpoint đó VÀ từ vai trò IAM đó.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này là phương án duy nhất phủ cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu lượng không đi qua Internet công cộng | VPC endpoint + bucket policy theo endpoint | | Chỉ EC2 của cổng thông tin truy cập được | IAM role + bucket policy theo principal |

⚠ Điểm mấu chốt: chỉ giới hạn theo endpoint là CHƯA ĐỦ:

Bucket policy chỉ cho phép từ
  `aws:SourceVpce`
        ↓
    MỌI instance trong VPC đó
      đều vào được
    → kể cả máy không thuộc cổng thông tin
        ↓
    Đề đòi "chỉ EC2 của cổng thông tin"

Đây là lý do phương án C thiếu một nửa.

⚠ Và VPC endpoint policy khác bucket policy — hai tầng khác nhau: | Chính sách | Kiểm soát | |---|---| | VPC endpoint policy | endpoint này được gọi tới bucket nào | | Bucket policy | bucket này nhận yêu cầu từ đâu, từ ai |

Cả hai phải cùng cho phép
    → quyền hiệu lực là GIAO

VPC endpoint policy:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::tai-lieu-mat/*"}]}

Bucket policy phủ cả hai điều kiện:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Deny", "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::tai-lieu-mat",
               "arn:aws:s3:::tai-lieu-mat/*"],
  "Condition": {
    "StringNotEquals": {
      "aws:SourceVpce": "vpce-abc123",
      "aws:PrincipalArn":
        "arn:aws:iam::111122223333:role/VaiTroCongThongTin"}}}]}

⚠ Chú ý dùng Deny với StringNotEquals chứ không dùng Allow:

`Allow` với điều kiện
    → chỉ mở thêm quyền
    → không chặn đường khác
        ↓
    `Deny` với `StringNotEquals`
    → chặn MỌI thứ không khớp
    → đây mới là cách siết

⚠ Và aws:SourceIp KHÔNG dùng được với gateway endpoint:

Lưu lượng qua gateway endpoint
    → S3 thấy IP riêng tư của VPC,
      không phải IP công khai
        ↓
    Điều kiện `aws:SourceIp` không khớp
    → phải dùng `aws:SourceVpce`
      hoặc `aws:SourceVpc`

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

Tạo gateway endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-rieng-1a rtb-rieng-1b \
  --policy-document file://endpoint-policy.json

⚠ Gateway endpoint hoạt động bằng BẢNG ĐỊNH TUYẾN, không phải ENI:

AWS thêm một tuyến tới prefix list
  của S3 vào bảng định tuyến
        ↓
    Lưu lượng tới S3 đi qua đó
    → không qua Internet gateway
    → và MIỄN PHÍ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lưu lượng không rời mạng AWS | | | Chỉ đúng vai trò và đúng đường vào được | | | Gateway endpoint miễn phí | |

⚠ Và NACL (phương án A, C) không phải công cụ đúng ở đây:

NACL lọc theo IP và cổng
    → không phân biệt được instance
      nào thuộc cổng thông tin
        ↓
    Và chặn prefix list của S3 sẽ
      chặn luôn mọi truy cập S3
      hợp lệ khác trong subnet

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

  • **C. Tạo VPC endpoint policy giới hạn bucket, bucket policy chỉ cho phép từ VPC endpoint, và dùng NACL chặn EC2 khác — đây là phương án gần nhất và phần endpoint policy hoàn toàn đúng, nhưng thiếu điều kiện theo vai trò IAM nên mọi instance trong VPC vẫn vào được; và NACL không phân biệt được instance theo vai trò.
  • **A. Endpoint policy giới hạn bucket trong Region hiện tại, bucket policy cho phép từ subnet riêng tư, cộng NACL — bucket policy không có điều kiện theo subnet; và vẫn thiếu giới hạn theo principal.
  • **D. Bucket policy dùng điều kiện aws:SourceIp chặn mọi thứ trừ IP của EC2 — qua gateway endpoint, S3 không thấy IP công khai nên điều kiện này không khớp.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ | Cơ chế | Phí | |---|---|---|---| | Gateway | S3, DynamoDB | tuyến trong bảng định tuyến | MIỄN PHÍ | | Interface | hầu hết dịch vụ khác | ENI có IP riêng tư | theo giờ + GB |

⚠ Khoá điều kiện cho VPC endpoint — phải thuộc: | Khoá | Nghĩa | |---|---| | aws:SourceVpce | đúng endpoint cụ thể | | aws:SourceVpc | bất kỳ endpoint nào của VPC đó | | aws:PrincipalArn | đúng vai trò hoặc user | | aws:PrincipalOrgID | thuộc tổ chức nào |

Từ khoá nhận diện:

"must not traverse the public Internet" → VPC endpoint "only these instances can access" → IAM role + aws:PrincipalArn "only from this VPC" → aws:SourceVpc hoặc aws:SourceVpce "S3 and DynamoDB, no cost" → gateway endpoint

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Chỉ dùng được trong cùng Region | | | Gắn vào bảng định tuyến, không phải subnet | | | Không dùng được từ mạng tại chỗ qua DX | |

⚠ Điểm cuối là hạn chế quan trọng:

Máy tại chỗ qua Direct Connect
    → KHÔNG dùng được gateway endpoint
        ↓
    Cần interface endpoint (PrivateLink)
      cho S3
    → có phí nhưng dùng được từ tại chỗ

Ba lưu ý về endpoint policy: | Lưu ý | Chi tiết | |---|---| | Mặc định cho phép tất cả | | | Chỉ giới hạn, không cấp quyền | | | Vẫn cần IAM policy cho phép | |

Ba lưu ý về bucket policy: | Lưu ý | Chi tiết | |---|---| | Dùng Deny với StringNotEquals để siết | | | Cẩn thận khoá chính mình ra ngoài | | | Chừa một principal quản trị | |

⚠ Khoá mình ra khỏi bucket là sự cố hay gặp:

{"Condition": {"StringNotEqualsIfExists": {
  "aws:SourceVpce": "vpce-abc",
  "aws:PrincipalArn": [
    "arn:aws:iam::111122223333:role/VaiTroCongThongTin",
    "arn:aws:iam::111122223333:role/QuanTri"]}}}

Không chừa vai trò quản trị
    → không ai sửa được bucket policy nữa
    → phải dùng tài khoản gốc để gỡ

Ba lưu ý về StringNotEqualsIfExists: | Lưu ý | Chi tiết | |---|---| | Bỏ qua điều kiện nếu khoá không tồn tại | | | Tránh chặn nhầm dịch vụ AWS nội bộ | | | An toàn hơn StringNotEquals thuần | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | SSE-KMS cho tài liệu mật | | | Bật S3 Bucket Key giảm chi phí KMS | | | Key policy cũng phải cho vai trò đó dùng khoá | |

⚠ Quên key policy là lỗi hay gặp với SSE-KMS:

Bucket policy đúng, IAM policy đúng
    → vẫn AccessDenied
        ↓
    Vai trò chưa có quyền `kms:Decrypt`
      trong KEY POLICY

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Bật CloudTrail data event cho bucket | | | VPC Flow Logs xem lưu lượng tới S3 | | | IAM Access Analyzer phát hiện chia sẻ ra ngoài | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy cập từ instance khác trong VPC — phải bị từ chối | | | Truy cập từ Internet — phải bị từ chối | | | Truy cập từ EC2 cổng thông tin — phải thành công | |

Và một lời khuyên: hãy kiểm chứng bằng một instance KHÁC trong cùng VPC. Cấu hình chỉ giới hạn theo VPC endpoint trông rất chặt cho tới khi bạn thử từ một máy bất kỳ trong cùng mạng — và nó vào được ngay.

Câu 200 Domain - Design for New Solutions

A startup is building a mobile app and a custom GraphQL API backend that lets people post photos and videos of road potholes, faulty street lights, bridge damages, and other issues in the public infrastructure with 100-character summaries. The data gathered by the system will be used by the department of public works to facilitate fast resolution. The developers used a javascript-based React Native mobile framework so that it would run on various mobile and tablet devices. The app will be connecting to a custom GraphQL API that will be responsible for storing the photos and videos in an Amazon S3 bucket and will also access a DynamoDB table to store the summaries. The developers have recently deployed the mobile app prototype but it was found that there is an availability issue with the custom GraphQL API. To proceed with the project, the team decided to remove the API and instead, re-model the mobile app so that it will directly connect to both DynamoDB and S3 as well as handle user authentication.

Which of the following options provides the most cost-effective and scalable architecture for this project?

  1. A

    1. Set up a web identity federation using the AssumeRole API of STS and register with social identity providers like Amazon, Google, Facebook or any other OpenID Connect (OIDC)-compatible IdP.

    2. Create an IAM user for that provider and set up permissions for the IAM user to allow access to S3 and DynamoDB.

    3. The mobile app will use the AWS access and secret keys to store the photos and videos to an S3 bucket and persist the summaries to the DynamoDB database.
  2. B

    1. Set up a web identity federation using the AssumeRoleWithWebIdentity API of STS and register with social identity providers like Amazon, Google, Facebook or any other OpenID Connect (OIDC)-compatible IdP.

    2. Create an IAM role for that provider and set up permissions for the IAM role to allow access to S3 and DynamoDB.

    3. The mobile app will use the AWS access and secret keys to store the photos and videos to an S3 bucket and persist the summaries to the DynamoDB database.
  3. C

    1. Set up a web identity federation using the AssumeRoleWithWebIdentity API of STS and register with social identity providers like Amazon, Google, Facebook or any other OpenID Connect (OIDC)-compatible IdP.

    2. Create an IAM role for that provider and set up permissions for the IAM role to allow access to S3 and DynamoDB.

    3. The mobile app will use the AWS temporary security credentials to store the photos and videos to an S3 bucket and persist the summaries to the DynamoDB database.
  4. D

    1. Set up a web identity federation using Cognito and social identity providers like Amazon, Google, Facebook or any other OpenID Connect (OIDC)-compatible IdP.

    2. Configure the IAM role in Cognito to allow access to S3 and DynamoDB.

    3. The mobile app will use the AWS access and secret keys to store the photos and videos to an S3 bucket and persist the summaries to the DynamoDB database.
  5. E

    1. Set up a web identity federation using the AssumeRoleWithSAML API of STS and register with social identity providers like Amazon, Google, Facebook or any other OpenID Connect (OIDC)-compatible IdP.

    2. Create an IAM role for that provider and set up permissions for the IAM role to allow access to S3 and DynamoDB.

    3. The mobile app will use the AWS temporary security credentials to store the photos and videos to an S3 bucket and persist the summaries to the DynamoDB database.
Xem giải thích

Đáp án

**C — Dùng web identity federation qua AssumeRoleWithWebIdentity của STS, đăng ký với nhà cung cấp danh tính mạng xã hội hoặc IdP tương thích OIDC; tạo IAM role cho nhà cung cấp đó với quyền vào S3 và DynamoDB; ứng dụng di động dùng credential bảo mật TẠM THỜI để lưu ảnh, video và bản tóm tắt.

Vì sao đúng

Đề có hai điểm phải khớp cùng lúc, và chỉ một phương án khớp cả hai: | Điểm | Đúng phải là | |---|---| | API của STS | AssumeRoleWithWebIdentity | | Ứng dụng dùng gì | credential TẠM THỜI |

⚠ Ba API liên kết của STS — chọn đúng theo loại IdP: | API | Dùng cho | |---|---| | AssumeRoleWithWebIdentity | Google, Facebook, Amazon, OIDC | | AssumeRoleWithSAML | IdP doanh nghiệp nói SAML 2.0 | | AssumeRole | giả nhận vai trò xuyên tài khoản |

Đề nói "social identity providers"
  và "OIDC-compatible"
        ↓
    `AssumeRoleWithWebIdentity`
    → SAML là chuẩn khác, dùng cho
      liên kết doanh nghiệp

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

⚠ Và "access key và secret key" trong ứng dụng di động là lỗi nghiêm trọng:

Ứng dụng nằm trên máy người dùng
    → giải nén APK/IPA là đọc được
      mọi chuỗi
        ↓
    Khoá tĩnh nhúng vào ứng dụng
      = khoá công khai
    → không có cách nào giấu

Đây là lý do phương án A, B và D sai — cả ba đều nói tới access key và secret key.

⚠ Chú ý phương án B và C khác nhau đúng MỘT chi tiết:

B: `AssumeRoleWithWebIdentity` +
   IAM role + "AWS access and secret keys"
        ↓
    C: `AssumeRoleWithWebIdentity` +
       IAM role + "temporary security credentials"
        ↓
    Chỉ khác ở vế cuối
    → nhưng đó là khác biệt giữa
      an toàn và mất an toàn

Luồng đúng:

1. Người dùng đăng nhập Google/Facebook
        ↓
2. Ứng dụng nhận ID token của IdP
        ↓
3. Gọi `AssumeRoleWithWebIdentity`
   kèm token đó
        ↓
4. STS trả credential TẠM (1 giờ)
        ↓
5. Ứng dụng gọi thẳng S3 và DynamoDB

Trust policy của vai trò:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"Federated": "accounts.google.com"},
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {"StringEquals":
    {"accounts.google.com:aud": "<client-id>"}}}]}

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

Không kiểm `aud`
    → BẤT KỲ token Google nào
      cũng giả nhận được vai trò
        ↓
    Kẻ tấn công tạo ứng dụng Google
      của riêng họ
    → và vào được tài nguyên của bạn

Cô lập dữ liệu theo từng người dùng:

{"Effect": "Allow",
 "Action": ["s3:PutObject", "s3:GetObject"],
 "Resource": "arn:aws:s3:::anh-ha-tang/${accounts.google.com:sub}/*"}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có khoá tĩnh trong ứng dụng | | | Credential tự hết hạn sau một giờ | | | Không cần tầng API trung gian | |

⚠ Và bỏ được tầng GraphQL API chính là điều đề muốn:

API tự dựng là điểm hỏng và điểm
  phải vận hành
        ↓
    Ứng dụng gọi thẳng S3 và DynamoDB
    → hai dịch vụ đã sẵn sàng cao sẵn
    → không có gì để sập

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

⚠ Cognito là câu trả lời chuẩn cho bài toán này, và phương án D làm hỏng nó ở vế cuối.

Phương án D bắt đầu đúng — "web identity federation dùng Cognito" — rồi kết thúc bằng "ứng dụng dùng access key và secret key". Cognito identity pool không bao giờ cấp access key tĩnh; nó cấp credential tạm, đúng như phương án C.

Nếu D viết "temporary credentials"
    → nó sẽ là đáp án TỐT NHẤT
        ↓
    Cognito identity pool bọc chính
      `AssumeRoleWithWebIdentity`
    → và thêm quản lý danh tính,
      đồng bộ, guest access

So sánh hai cách: | Tiêu chí | STS trực tiếp | Cognito identity pool | |---|---|---| | Cơ chế bên dưới | AssumeRoleWithWebIdentity | cùng cơ chế | | Nhiều IdP cùng lúc | tự xử lý | có sẵn | | Người dùng khách (chưa đăng nhập) | không | có | | Biến cô lập dữ liệu | <idp>:sub | ${cognito-identity.amazonaws.com:sub} |

Phương án C vẫn là đáp án đúng trong bốn lựa chọn có sẵn, nhưng với hệ thống thật thì Cognito ít việc hơn hẳn.

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

  • **B. AssumeRoleWithWebIdentity + IAM role, nhưng ứng dụng dùng access key và secret key — đây là phương án gần nhất và chỉ khác đáp án đúng ở vế cuối, nhưng API đó trả về credential tạm chứ không phải khoá tĩnh; và nhúng khoá tĩnh vào ứng dụng di động là lỗ hổng.
  • **E. Dùng AssumeRoleWithSAML với nhà cung cấp mạng xã hội — SAML là chuẩn cho liên kết doanh nghiệp; Google và Facebook dùng OIDC.
  • **A. Dùng AssumeRole và tạo IAM user cho nhà cung cấp — sai API, và IAM user nghĩa là khoá tĩnh.
  • **D. Dùng Cognito nhưng ứng dụng dùng access key và secret key — Cognito không cấp khoá tĩnh; xem phần chất lượng câu hỏi.

Ghi nhớ

⚠ Bốn API cấp credential tạm — bảng phải thuộc: | API | Nguồn danh tính | |---|---| | AssumeRole | danh tính AWS khác | | AssumeRoleWithWebIdentity | OIDC: Google, Facebook, Apple | | AssumeRoleWithSAML | IdP doanh nghiệp SAML | | GetFederationToken | identity broker tự dựng |

Từ khoá nhận diện:

"social login, mobile app" → AssumeRoleWithWebIdentity hoặc Cognito "corporate SAML IdP" → AssumeRoleWithSAML "never embed credentials" → credential tạm "guest users without login" → Cognito identity pool

Ba lưu ý về bảo mật ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | Coi mọi thứ trong ứng dụng là công khai | | | Lưu token trong keychain, không trong tệp | | | Xác thực logic quan trọng ở phía máy chủ | |

⚠ Điểm cuối áp dụng cho chính bài toán này:

Ứng dụng ghi thẳng vào DynamoDB
    → ai sửa ứng dụng cũng ghi được
      dữ liệu bất kỳ
        ↓
    Dữ liệu ảnh hưởng người khác
      (ví dụ trạng thái xử lý sự cố)
    → phải qua Lambda kiểm tra

Ba lưu ý về cô lập dữ liệu: | Cách | Chi tiết | |---|---| | S3: tiền tố theo sub | | | DynamoDB: dynamodb:LeadingKeys | | | Chính sách phiên thu hẹp khi giả nhận | |

{"Condition": {"ForAllValues:StringEquals":
  {"dynamodb:LeadingKeys":
    ["${accounts.google.com:sub}"]}}}

Ba lưu ý về thời hạn phiên: | Lưu ý | Chi tiết | |---|---| | Mặc định 1 giờ, tối đa 12 giờ | | | Ứng dụng phải làm mới trước khi hết hạn | | | Bắt lỗi ExpiredToken và thử lại | |

Ba lưu ý về tải tệp lên S3: | Lưu ý | Chi tiết | |---|---| | Tải thẳng, không qua máy chủ trung gian | | | Multipart cho video lớn | | | Giới hạn kích thước trong chính sách | |

Ba lưu ý về DynamoDB cho ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | On-demand cho tải khó đoán | | | Khoá phân vùng theo id người dùng | | | TTL tự xoá dữ liệu tạm | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch ngược ứng dụng, tìm chuỗi giống access key | | | Thử đọc dữ liệu người dùng khác — phải bị từ chối | | | Dùng token hết hạn — phải bị từ chối | |

Và một lời khuyên: hãy đọc kỹ vế cuối của mỗi phương án trong dạng câu hỏi này. Bốn lựa chọn có thể giống nhau ở chín phần mười nội dung, và phần khác biệt duy nhất — "temporary credentials" so với "access and secret keys" — chính là ranh giới giữa kiến trúc an toàn và một ứng dụng phát khoá cho mọi người tải về.