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

Tìm thấy 2194 câu.

Câu 1081 AWS Management & Governance

A company stores its application logs in an Amazon CloudWatch Logs log group. A new policy requires the company to store all application logs in Amazon OpenSearch Service (Amazon Elasticsearch Service) in near-real time.

Which solution will meet this requirement with the LEAST operational overhead?

  1. A

    Create an AWS Lambda function. Use the log group to invoke the function to write the logs to Amazon OpenSearch Service (Amazon Elasticsearch Service).
  2. B

    Install and configure Amazon Kinesis Agent on each application server to deliver the logs to Amazon Kinesis Data Streams. Configure Kinesis Data Streams to deliver the logs to Amazon OpenSearch Service (Amazon Elasticsearch Service).
  3. C

    Configure a CloudWatch Logs subscription to stream the logs to Amazon OpenSearch Service (Amazon Elasticsearch Service).
  4. D

    Create an Amazon Kinesis Data Firehose delivery stream. Configure the log group as the delivery stream's source. Configure Amazon OpenSearch Service (Amazon Elasticsearch Service) as the delivery stream's destination.
Xem giải thích

Đáp án

C — Cấu hình một CloudWatch Logs subscription để truyền log sang Amazon OpenSearch Service.

Vì sao đúng

Đề nêu hai yêu cầu, và subscription filter đáp ứng cả hai với ít bộ phận nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Gần thời gian thực | subscription đẩy log ngay khi ghi | | CÔNG VẬN HÀNH ÍT NHẤT | cấu hình một lần trên console, không viết mã |

⚠ CloudWatch Logs có tích hợp OpenSearch dựng sẵn:

Console CloudWatch Logs → chọn log group
    → Actions → "Subscription filters"
    → "Create Amazon OpenSearch Service subscription filter"
        ↓
    AWS tự tạo Lambda trung gian, tự cấp quyền
    → bạn không viết dòng mã nào

Bằng CLI:

aws logs put-subscription-filter \
  --log-group-name /ung-dung/san-xuat \
  --filter-name toi-opensearch \
  --filter-pattern "" \
  --destination-arn <arn-lambda-opensearch> \
  --role-arn <arn-role>

⚠ --filter-pattern "" nghĩa là gửi TẤT CẢ — đề nói "all application logs".

Lọc bớt nếu chỉ cần một phần:

--filter-pattern "?ERROR ?WARN ?Exception"

Gửi mọi dòng log sang OpenSearch
    → cụm phải đủ lớn để nuốt hết
        ↓
    Lọc ở nguồn rẻ hơn nhiều so với
    mở rộng cụm để chứa log không ai đọc

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ thường dưới vài giây | | | Không phải viết và bảo trì mã | | | Tự thử lại khi đích tạm lỗi | |

⚠ Giới hạn quan trọng — mỗi log group tối đa 2 subscription filter:

Muốn gửi cùng log tới OpenSearch VÀ S3 VÀ bên thứ ba
    → chỉ được 2 đích
        ↓
    Gửi tới một Kinesis Data Stream
    → từ đó fan-out ra nhiều nơi

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

⚠ Phương án D cũng là một giải pháp hợp lệ. Kinesis Data Firehose có nhận CloudWatch Logs làm nguồn (qua chính subscription filter) và có giao thẳng sang OpenSearch. Khác biệt thực tế:

Cách Bộ phận Độ trễ
C — subscription trực tiếp ít nhất giây
D — qua Firehose thêm một luồng tối thiểu 60 giây 
"Near-real time" + "least operational overhead"
    → C thắng ở cả hai vế
        ↓
    Nhưng D không sai về mặt kỹ thuật —
    nó thậm chí bền hơn cho khối lượng rất lớn

Nói rõ điều này vì gặp cùng tình huống ngoài đời, Firehose thường là lựa chọn tốt hơn khi khối lượng log lớn: nó có đệm, có chuyển đổi định dạng, và ghi bản sao xuống S3 làm kho dự phòng.

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

  • **D. Dùng Firehose với log group làm nguồn — xem phần trên: đúng về kỹ thuật nhưng thêm một bộ phận và độ trễ tối thiểu 60 giây, thua ở cả hai tiêu chí đề đặt ra.
  • **A. Tự viết Lambda để ghi sang OpenSearch — đúng là subscription filter cũng dùng Lambda bên dưới, nhưng AWS tạo và quản lý hàm đó; tự viết nghĩa là tự bảo trì mã, tự xử lý thử lại, tự lo phân trang.
  • **B. Cài Kinesis Agent trên từng máy chủ — đề nói log đã nằm trong CloudWatch Logs; cài agent trên hàng loạt máy là công vận hành lớn nhất trong bốn phương án.

Ghi nhớ

⚠ Bốn đích của CloudWatch Logs subscription — bảng phải thuộc: | Đích | Dùng cho | |---|---| | Lambda | xử lý tuỳ chỉnh, gồm OpenSearch | | Kinesis Data Streams | fan-out nhiều người tiêu thụ | | Kinesis Data Firehose | giao sang S3, OpenSearch, Splunk | | OpenSearch (qua console) | tích hợp dựng sẵn |

Từ khoá nhận diện:

"logs already in CloudWatch → OpenSearch, near-real time" → subscription filter "logs → S3 for long-term archive" → Firehose hoặc export task "query logs without moving them" → CloudWatch Logs Insights "logs from on-premises servers" → CloudWatch agent

⚠ CloudWatch Logs Insights đáng cân nhắc trước khi chuyển đi đâu cả:

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)

Nếu chỉ cần tìm kiếm và thống kê
    → Insights làm được ngay, không cần cụm nào
        ↓
    Chỉ chuyển sang OpenSearch khi cần
    dashboard phong phú hoặc giữ lâu dài

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudWatch Logs tính theo GB nạp vào | | | Cụm OpenSearch tính theo giờ node | | | Lưu cùng dữ liệu ở hai nơi = trả hai lần | |

⚠ Đây là khoản lãng phí hay gặp:

Log giữ 90 ngày ở CloudWatch Logs
    VÀ 90 ngày ở OpenSearch
        ↓
    Giảm retention CloudWatch xuống 7 ngày
    → giữ dài hạn ở OpenSearch hoặc S3

aws logs put-retention-policy \
  --log-group-name /ung-dung/san-xuat --retention-in-days 7

Ba lưu ý về cụm OpenSearch: | Lưu ý | Chi tiết | |---|---| | Ba node master chuyên dụng cho sản xuất | | | Trải nhiều AZ | | | UltraWarm cho dữ liệu ít truy vấn | |

⚠ UltraWarm giảm chi phí đáng kể:

Dữ liệu nóng (7 ngày):  node nóng, SSD
Dữ liệu ấm (90 ngày):   UltraWarm, lưu ở S3
Dữ liệu lạnh:           Cold storage
        ↓
    Rẻ hơn nhiều lần so với giữ tất cả ở node nóng

Ba lưu ý về Index State Management: | Lưu ý | Chi tiết | |---|---| | Tự chuyển index sang UltraWarm | | | Tự xoá index quá hạn | | | Không có ISM thì đĩa đầy dần rồi cụm đỏ | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Đặt cụm trong VPC, không public | | | Fine-grained access control | | | Mã hoá at rest và node-to-node | |

Ba lưu ý về hạn ngạch subscription: | Hạn ngạch | Giá trị | |---|---| | Subscription filter mỗi log group | 2 | | Thông lượng tối đa | ~10 MB/s mỗi filter | | Vượt thì log bị bỏ | |

⚠ Log bị bỏ vì throttling không có cảnh báo rõ ràng:

Ứng dụng ghi log tăng vọt
    → vượt thông lượng subscription
        ↓
    Log không tới OpenSearch
    → dashboard trống đúng lúc đang có sự cố

Ba lưu ý về theo dõi đường ống: | Việc | Cách | |---|---| | Đặt cảnh báo cho Errors của Lambda trung gian | | | So số dòng log ở hai đầu | | | Theo dõi ClusterStatus của OpenSearch | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một dòng log thử, tìm nó trong OpenSearch | | | Đo độ trễ từ lúc ghi tới lúc tìm được | | | Kiểm tra retention hai bên không trùng nhau | |

Và một lời khuyên: hãy giảm thời gian giữ log ở CloudWatch Logs ngay sau khi đường ống chạy ổn định. Giữ nguyên mặc định "không bao giờ hết hạn" trong khi đã có bản thứ hai ở OpenSearch nghĩa là trả tiền lưu trữ hai lần cho cùng một dữ liệu, và đó là khoản không ai để ý cho tới khi nó đã tích tụ nhiều tháng.

Câu 1082 AWS Security, Identity, & Compliance

A three-tier web application is composed of a front end hosted on an Amazon EC2 instance in public subnet, application middleware hosted on EC2 in a private subnet and a database hosted on an Amazon RDS MySQL database in a private subnet. The database layer should be restricted to only allow incoming connections from the application.

Which of the following options makes sure that database can only be accessed by the application layer?

  1. A

    Create a security group that allows inbound traffic from the security group that is assigned to instances in the private subnets. Attach the security group to the DB instances.
  2. B

    Create a new peering connection between the public subnets and the private subnets. Create a different peering connection between the private subnets and the database subnets.
  3. C

    Create a new route table that excludes the route to the public subnets' CIDR blocks. Associate the route table with the database subnets.
  4. D

    Create a security group that denies inbound traffic from the security group that is assigned to instances in the public subnets. Attach the security group to the DB instances.
Xem giải thích

Đáp án

A — Tạo một security group cho phép lưu lượng vào từ security group đang gắn cho các instance ở subnet riêng tư, rồi gắn security group đó cho DB instance.

Vì sao đúng

Đề cần chỉ tầng ứng dụng chạm được CSDL. Tham chiếu security group là cơ chế chính xác cho việc này.

⚠ Tham chiếu security group bền hơn tham chiếu địa chỉ IP:

Quy tắc theo CIDR: 10.0.2.0/24 được vào cổng 3306
    → mọi thứ trong subnet đó được vào
    → thêm dịch vụ khác vào subnet = nó cũng vào được
        ↓
Quy tắc theo SG:  sg-ung-dung được vào cổng 3306
    → CHỈ máy mang security group đó
    → máy mới tự động được phép, máy khác thì không

Tạo quy tắc:

aws ec2 authorize-security-group-ingress \
  --group-id sg-csdl \
  --protocol tcp --port 3306 \
  --source-group sg-ung-dung

⚠ Điểm mạnh nhất: sống sót qua mọi thay đổi hạ tầng:

Auto Scaling thay máy liên tục
    → IP đổi mỗi lần
        ↓
    Quy tắc theo IP: phải cập nhật mỗi lần — bất khả thi
    Quy tắc theo SG: máy mới mang SG đó, tự được phép

Kiến trúc ba tầng đầy đủ:

sg-web:      vào 443 từ 0.0.0.0/0 (hoặc từ sg-alb)
sg-ung-dung: vào 8080 từ sg-web
sg-csdl:     vào 3306 từ sg-ung-dung
        ↓
    Mỗi tầng chỉ mở cho tầng ngay trước nó
    → tầng web KHÔNG chạm được CSDL

⚠ Vì sao tầng web không vào được CSDL:

sg-csdl chỉ cho phép nguồn là sg-ung-dung
    → máy web mang sg-web, không mang sg-ung-dung
        ↓
    Bị chặn — đúng ý đồ thiết kế

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải bảo trì danh sách IP | | | Ý đồ thiết kế đọc được ngay từ quy tắc | | | Sống sót qua thay máy và mở rộng | |

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

  • **D. Tạo security group TỪ CHỐI lưu lượng vào từ SG của subnet công khai — security group KHÔNG CÓ quy tắc deny. Nó chỉ có quy tắc allow, mặc định là từ chối tất cả. Phương án này mô tả một thứ không tồn tại.
  • **B. Tạo VPC peering giữa các subnet — peering nối hai VPC, không nối các subnet trong cùng một VPC. Các subnet trong một VPC vốn đã định tuyến được tới nhau.
  • **C. Tạo route table loại bỏ đường tới CIDR subnet công khai — định tuyến trong VPC là cục bộ và không gỡ được; mọi route table đều có tuyến local cho CIDR của VPC, và bạn không xoá được nó.

Ghi nhớ

⚠ Security group vs NACL — bảng phải thuộc: | Tiêu chí | Security group | NACL | |---|---|---| | Cấp độ | ENI (máy) | subnet | | Trạng thái | stateful — phản hồi tự được phép | stateless — phải mở cả hai chiều | | Quy tắc deny | KHÔNG có | CÓ | | Xét quy tắc | tất cả cùng lúc | theo số thứ tự, dừng ở khớp đầu | | Tham chiếu SG khác | ✅ | ❌ chỉ CIDR |

⚠ "Security group không có deny" là điều phải thuộc lòng:

Muốn CHẶN một IP cụ thể
    → security group không làm được
        ↓
    Dùng NACL, hoặc AWS WAF, hoặc Network Firewall

Từ khoá nhận diện:

"only the application tier can reach the database" → SG tham chiếu SG "block a specific IP address" → NACL deny rule "stateless filtering at subnet level" → NACL "allow instances to talk to each other" → SG tự tham chiếu chính nó

⚠ SG tham chiếu chính nó — mẫu cho cụm:

aws ec2 authorize-security-group-ingress \
  --group-id sg-cum --protocol tcp --port 7000-7001 \
  --source-group sg-cum

Node trong cụm nói chuyện với nhau
    → mọi node mang cùng SG
    → SG cho phép chính nó

⚠ Giới hạn quan trọng: tham chiếu SG không hoạt động xuyên Region: | Tình huống | Tham chiếu SG | |---|---| | Cùng VPC | ✅ | | VPC peering cùng Region | ✅ | | VPC peering XUYÊN Region | ❌ phải dùng CIDR | | Transit Gateway | ❌ |

Ba lưu ý về tính stateful: | Lưu ý | Chi tiết | |---|---| | Chỉ cần mở chiều VÀO | | | Phản hồi tự động được phép ra | | | Quy tắc ra mặc định cho phép tất cả | |

⚠ Siết luôn quy tắc ra là thực hành tốt:

Mặc định: máy ra được mọi nơi
    → máy bị chiếm sẽ gọi về máy chủ điều khiển
        ↓
    Siết egress: chỉ cho ra tới SG cần thiết
    và tới VPC endpoint

aws ec2 revoke-security-group-egress --group-id sg-ung-dung \
  --protocol -1 --port -1 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-egress --group-id sg-ung-dung \
  --protocol tcp --port 3306 --source-group sg-csdl

Ba lưu ý về hạn ngạch: | Hạn ngạch | Mặc định | |---|---| | Quy tắc mỗi security group | 60 vào + 60 ra | | Security group mỗi ENI | 5 (tăng tới 16) | | Tham chiếu SG tính là một quy tắc | |

⚠ Đây là lý do nữa để dùng tham chiếu SG:

50 máy ứng dụng, quy tắc theo IP
    → 50 quy tắc, gần chạm trần 60
        ↓
    Tham chiếu SG: MỘT quy tắc, không giới hạn số máy

Ba lưu ý về CSDL trong subnet riêng tư: | Lưu ý | Chi tiết | |---|---| | --no-publicly-accessible | | | DB subnet group chỉ gồm subnet riêng tư | | | Không có route ra internet gateway | |

Ba lưu ý về gỡ lỗi kết nối: | Công cụ | Việc | |---|---| | Reachability Analyzer | chỉ ra chặn ở đâu | | VPC Flow Logs | thấy gói bị REJECT | | telnet / nc từ máy ứng dụng | |

aws ec2 create-network-insights-path \
  --source i-ung-dung --destination <id-eni-csdl> \
  --protocol tcp --destination-port 3306

Ba lưu ý về đặt tên: | Lưu ý | Chi tiết | |---|---| | Tên nói rõ vai trò: sg-tang-ung-dung | | | Mô tả cho từng quy tắc | | | Tag theo môi trường và chủ sở hữu | |

⚠ Mô tả quy tắc giúp rất nhiều về sau:

aws ec2 authorize-security-group-ingress --group-id sg-csdl \
  --ip-permissions 'IpProtocol=tcp,FromPort=3306,ToPort=3306,
    UserIdGroupPairs=[{GroupId=sg-ung-dung,
      Description="Tang ung dung truy cap MySQL"}]'

Ba lưu ý về kiểm toán: | Lưu ý | Chi tiết | |---|---| | Config rule restricted-common-ports | | | Cảnh báo khi có quy tắc 0.0.0.0/0 | | | Rà lại định kỳ, xoá quy tắc không dùng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối từ máy ứng dụng | phải được | | Kết nối từ máy web | phải bị chặn | | Chạy Reachability Analyzer | |

Và một lời khuyên: hãy dùng tham chiếu security group ở mọi ranh giới giữa các tầng, không dùng CIDR. Quy tắc theo dải IP đúng vào ngày bạn viết nó và sai dần theo mỗi lần hạ tầng thay đổi — còn quy tắc theo security group diễn đạt đúng điều bạn thật sự muốn nói: "tầng này được gọi tầng kia".

Câu 1083 AWS Networking & Content Delivery

An application has been migrated from on-premises to an Amazon EC2 instance. The migration has failed to an unknown dependency that the application must communicate with an on-premises server using private IP addresses.

Which action should a solutions architect take to quickly provision the necessary connectivity?

  1. A

    Configure a Virtual Private Gateway
  2. B

    Setup an AWS Direct Connect connection
  3. C

    Create an Amazon CloudFront distribution
  4. D

    Create an AWS Transit Gateway
Xem giải thích

Đáp án

A — Cấu hình một Virtual Private Gateway.

Vì sao đúng

Đề nêu hai yêu cầu, và từ khoá quyết định nằm ở vế thứ hai: | Yêu cầu | Cách đáp ứng | |---|---| | Kết nối riêng tư tới máy chủ tại chỗ | Site-to-Site VPN qua Virtual Private Gateway | | NHANH CHÓNG (quickly provision) | dựng trong vài chục phút |

⚠ "Quickly" là từ loại trừ Direct Connect:

Site-to-Site VPN: dựng xong trong ~30 phút
    → chỉ cần cấu hình hai đầu
        ↓
Direct Connect: đặt cổng, kéo cáp chéo,
                phối hợp với nhà cung cấp
    → nhiều TUẦN tới nhiều THÁNG

Virtual Private Gateway là đầu AWS của kết nối VPN:

Trung tâm dữ liệu
    → Customer Gateway (thiết bị của bạn)
        ↓ đường hầm IPsec qua Internet
    Virtual Private Gateway (đầu AWS)
        ↓
    VPC — instance dùng IP riêng tư

Dựng đầy đủ:

aws ec2 create-vpn-gateway --type ipsec.1
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-abc --vpc-id vpc-abc

aws ec2 create-customer-gateway --type ipsec.1 \
  --public-ip 203.0.113.10 --bgp-asn 65000

aws ec2 create-vpn-connection --type ipsec.1 \
  --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc \
  --options '{"StaticRoutesOnly": false}'

⚠ Bật lan truyền tuyến — bước hay bị quên:

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

Không bật: đường hầm UP nhưng không có tuyến nào
    → gói tin không biết đi đâu
        ↓
    Triệu chứng: VPN "hoạt động" mà vẫn không ping được

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dựng nhanh, dùng hạ tầng Internet có sẵn | | | Mã hoá IPsec | | | Hai đường hầm dự phòng sẵn | |

⚠ AWS luôn tạo HAI đường hầm — nhưng phần lớn cấu hình chỉ dùng một:

Hai đường hầm tới hai endpoint khác nhau của AWS
    → cấu hình cả hai ở thiết bị của bạn
        ↓
    Chỉ cấu hình một = mất kết nối khi AWS
      bảo trì endpoint đó

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

  • **B. Thiết lập AWS Direct Connect — đây là phương án gần nhất và cho kết nối riêng tư tốt hơn về lâu dài, nhưng mất nhiều tuần tới nhiều tháng để cung cấp, ngược hẳn với yêu cầu "quickly".
  • **D. Tạo AWS Transit Gateway — Transit Gateway là trung tâm định tuyến giữa nhiều VPC; riêng nó không tạo ra kết nối tới trung tâm dữ liệu. (Nó vẫn cần một VPN hoặc Direct Connect attachment.)
  • **C. Tạo CloudFront distribution — CloudFront là CDN phân phối nội dung ra Internet, không liên quan gì tới kết nối riêng tư hai chiều.

Ghi nhớ

⚠ Bốn cách nối tại chỗ với AWS — bảng phải thuộc: | Cách | Thời gian dựng | Băng thông | Đường đi | |---|---|---|---| | Site-to-Site VPN | ~30 phút | tới 1,25 Gbps mỗi đường hầm | Internet | | Direct Connect | tuần - tháng | 1-100 Gbps | riêng | | DX + VPN | theo DX | cao | riêng + mã hoá | | Client VPN | giờ | theo người dùng | Internet |

Từ khoá nhận diện:

"quickly", "temporary", "immediate connectivity" → Site-to-Site VPN "consistent bandwidth, low latency, dedicated" → Direct Connect "individual users connect from laptops" → Client VPN "connect many VPCs and on-premises" → Transit Gateway

⚠ VGW vs Transit Gateway — khi nào đổi: | Tiêu chí | Virtual Private Gateway | Transit Gateway | |---|---|---| | Số VPC | một VPC | hàng nghìn | | Định tuyến bắc cầu | ❌ | ✅ | | Băng thông tổng | 1,25 Gbps mỗi đường hầm | 50 Gbps | | Phí | không phí giờ | có phí attachment |

Một VPC nối tại chỗ  → VGW đủ và rẻ hơn
Nhiều VPC nối tại chỗ → Transit Gateway

Ba lưu ý về băng thông VPN: | Lưu ý | Chi tiết | |---|---| | ~1,25 Gbps mỗi đường hầm | | | Một luồng TCP không vượt được giới hạn đó | | | ECMP với Transit Gateway gộp nhiều đường hầm | |

⚠ Giới hạn là mỗi LUỒNG, không phải mỗi kết nối:

Một lần truyền tệp lớn = một luồng TCP
    → tối đa ~1,25 Gbps dù có bao nhiêu đường hầm
        ↓
    Nhiều luồng song song mới tận dụng được ECMP

Ba lưu ý về định tuyến: | Lưu ý | Chi tiết | |---|---| | BGP động được khuyến nghị | | | Tuyến tĩnh khi thiết bị không hỗ trợ BGP | | | BGP tự chuyển khi một đường hầm hỏng | |

Ba lưu ý về CIDR: | Lưu ý | Chi tiết | |---|---| | CIDR VPC và tại chỗ KHÔNG được chồng lấn | | | Lập kế hoạch dải IP toàn tổ chức | | | AWS IPAM giúp tránh trùng | |

⚠ Chồng lấn CIDR là lỗi không sửa được bằng cấu hình:

VPC 10.0.0.0/16, tại chỗ cũng 10.0.0.0/16
    → không định tuyến được
        ↓
    Phải đánh số lại một bên — công việc lớn

Ba lưu ý về tính sẵn sàng: | Lưu ý | Chi tiết | |---|---| | Cấu hình CẢ HAI đường hầm | | | Hai Customer Gateway ở hai thiết bị | | | Bật health check và cảnh báo | |

aws cloudwatch put-metric-alarm --alarm-name vpn-duong-ham-down \
  --namespace AWS/VPN --metric-name TunnelState \
  --dimensions Name=VpnId,Value=vpn-abc \
  --statistic Minimum --period 300 --evaluation-periods 1 \
  --threshold 1 --comparison-operator LessThanThreshold \
  --alarm-actions <arn-sns>

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Độ trễ phụ thuộc Internet — biến động | | | Accelerated VPN dùng mạng AWS Global Accelerator | | | MTU 1500 nhưng overhead IPsec làm giảm MSS | |

⚠ Vấn đề MTU gây lỗi rất khó chẩn đoán:

Ping được, SSH được, nhưng tải tệp lớn treo
    → gói lớn bị phân mảnh hoặc rơi
        ↓
    Bật MSS clamping trên thiết bị customer gateway

Ba lưu ý về chuyển sang Direct Connect sau này: | Lưu ý | Chi tiết | |---|---| | Giữ VPN làm dự phòng cho DX | | | BGP tự ưu tiên DX khi cả hai lên | | | Đây là kiến trúc khuyến nghị | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | ~0,05 USD mỗi giờ mỗi kết nối VPN | | | Phí truyền dữ liệu ra | | | Rẻ hơn Direct Connect nhiều ở quy mô nhỏ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra cả hai đường hầm UP | | | Ping bằng IP riêng tư hai chiều | | | Xem route propagation có tuyến tại chỗ | |

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-abc \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status]" \
  --output table

Và một lời khuyên: hãy cấu hình cả hai đường hầm ngay từ đầu, đừng để lần sau. AWS bảo trì các endpoint VPN theo lịch và sẽ báo trước, nhưng thông báo đó chỉ hữu ích nếu bạn có đường hầm thứ hai để chuyển sang — còn nếu không thì nó chỉ là lời báo trước về một lần mất kết nối chắc chắn xảy ra.

Câu 1084 AWS Compute

An application that is being installed on an Amazon EC2 instance requires a persistent block storage volume. The data must be encrypted at rest and regular volume-level backups must be automated.

Which solution options should be used?

  1. A

    Use an encrypted Amazon EC2 instance store and copy the data to another EC2 instance using a cron job and a batch script
  2. B

    Use an encrypted Amazon EBS volume and use Data Lifecycle Manager to automate snapshots
  3. C

    Use server-side encryption on an Amazon S3 bucket and use Cross-Region-Replication to backup on a schedule
  4. D

    Use an encrypted Amazon EFS filesystem and use an Amazon CloudWatch Events rule to start a backup copy of data using AWS Lambda
Xem giải thích

Đáp án

B — Dùng volume EBS đã mã hoá và dùng Data Lifecycle Manager để tự động hoá snapshot.

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 | |---|---| | Lưu trữ khối BỀN VỮNG | EBS — dữ liệu sống qua lần dừng máy | | Mã hoá at rest | mã hoá EBS bằng KMS | | Sao lưu mức volume TỰ ĐỘNG | Data Lifecycle Manager |

⚠ "Persistent block storage" loại ngay ba phương án còn lại:

Block storage = ổ đĩa thô, hệ điều hành tự định dạng
    → EBS và instance store là hai lựa chọn
        ↓
    Instance store KHÔNG bền vững
    → chỉ còn EBS

Tạo volume mã hoá:

aws ec2 create-volume --availability-zone ap-southeast-1a \
  --size 500 --volume-type gp3 \
  --iops 6000 --throughput 250 \
  --encrypted --kms-key-id <arn-khoa>

⚠ Bật mã hoá mặc định cho cả tài khoản — nên làm ngay:

aws ec2 enable-ebs-encryption-by-default
aws ec2 modify-ebs-default-kms-key-id --kms-key-id <arn-khoa>

Từ đó mọi volume mới TỰ ĐỘNG mã hoá
    → không phụ thuộc việc ai đó nhớ tích ô

Chính sách Data Lifecycle Manager:

aws dlm create-lifecycle-policy \
  --description "Snapshot hang ngay cho volume ung dung" \
  --state ENABLED --execution-role-arn <arn-role> \
  --policy-details '{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key": "SaoLuu", "Value": "hang-ngay"}],
    "Schedules": [{
      "Name": "hang-ngay-2h",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS",
                     "Times": ["17:00"]},
      "RetainRule": {"Count": 14},
      "CopyTags": true}]}'

⚠ DLM chọn volume theo TAG, không theo danh sách:

Gắn tag SaoLuu=hang-ngay cho volume mới
    → tự động vào lịch sao lưu
        ↓
    Không ai phải nhớ thêm bước nào

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | DLM miễn phí — chỉ trả tiền snapshot | | | Tự xoá snapshot cũ theo RetainRule | | | Snapshot của volume mã hoá cũng được mã hoá | |

⚠ Mã hoá lan truyền tự động:

Volume mã hoá → snapshot mã hoá
    → volume khôi phục từ snapshot đó cũng mã hoá
    → AMI tạo từ đó cũng mã hoá
        ↓
    Không có chỗ nào dữ liệu bị "rơi ra" dạng thô

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

  • **D. Dùng EFS mã hoá và CloudWatch Events kích hoạt Lambda sao chép — đây là phương án gần nhất vì cũng bền vững và cũng mã hoá, nhưng EFS là lưu trữ TỆP chứ không phải KHỐI; và tự viết Lambda sao lưu là công vận hành trong khi DLM (hoặc AWS Backup) làm sẵn.
  • **A. Dùng instance store mã hoá và cron chép sang máy khác — instance store mất dữ liệu khi máy dừng, vi phạm thẳng yêu cầu "persistent".
  • **C. Dùng S3 với server-side encryption và Cross-Region Replication — S3 là lưu trữ đối tượng, không mount được làm ổ đĩa khối cho ứng dụng.

Ghi nhớ

⚠ Ba loại lưu trữ — bảng phải thuộc: | Loại | Dịch vụ | Bền vững | |---|---|---| | Block (khối) | EBS, instance store | EBS ✅ / store ❌ | | File (tệp) | EFS, FSx | ✅ | | Object (đối tượng) | S3 | ✅ |

Từ khoá nhận diện:

"persistent block storage, single instance" → EBS "shared file system" → EFS / FSx "objects, unlimited, HTTP" → S3 "temporary scratch, highest IOPS" → instance store

⚠ DLM vs AWS Backup — chọn cái nào: | Tiêu chí | DLM | AWS Backup | |---|---|---| | Phạm vi | EBS snapshot, AMI, EBS-backed | nhiều dịch vụ | | Phí dịch vụ | miễn phí | có phí quản lý | | Vault Lock | ❌ | ✅ | | Sao chép xuyên tài khoản | ❌ | ✅ | | Báo cáo tuân thủ | ❌ | ✅ |

Chỉ cần snapshot EBS  → DLM, miễn phí
Cần nhiều dịch vụ và tuân thủ → AWS Backup

Ba loại volume EBS nên biết: | Loại | Dùng cho | |---|---| | gp3 | mặc định — IOPS và throughput đặt độc lập | | io2 Block Express | CSDL đòi IOPS cao nhất | | st1 / sc1 | HDD, dữ liệu tuần tự lớn |

⚠ gp3 rẻ hơn gp2 khoảng 20% và tách rời IOPS khỏi dung lượng:

gp2: IOPS gắn với dung lượng (3 IOPS mỗi GB)
    → cần IOPS cao phải cấp volume lớn thừa
        ↓
gp3: 3000 IOPS cơ bản miễn phí, tăng riêng
    → không phải mua dung lượng thừa

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Tăng dần — chỉ lưu block thay đổi | | | Lưu ở S3 do AWS quản lý, đa AZ | | | Sao chép sang Region khác được | |

⚠ Snapshot khôi phục theo kiểu nạp lười:

Volume mới từ snapshot dùng được NGAY
    → nhưng block chưa nạp thì đọc chậm lần đầu
        ↓
    Cần hiệu năng đầy đủ ngay:
    → bật Fast Snapshot Restore (có phí)

Ba lưu ý về nhất quán: | Lưu ý | Chi tiết | |---|---| | Snapshot là ảnh chụp mức khối | | | Dữ liệu trong bộ đệm ứng dụng chưa được ghi | | | CSDL nên đóng băng I/O hoặc dùng snapshot của RDS | |

⚠ Đây là điểm ít người để ý:

Snapshot volume chứa CSDL đang chạy
    → giống như rút điện máy chủ
        ↓
    Khôi phục có thể phải chạy crash recovery
    → dùng script pre/post của SSM để flush trước

Ba lưu ý về Multi-Attach: | Lưu ý | Chi tiết | |---|---| | Chỉ io1/io2 | | | Tối đa 16 instance, CÙNG một AZ | | | Cần hệ thống tệp cụm | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Instance cũng có giới hạn băng thông EBS riêng | | | Bật EBS-optimized (mặc định trên máy đời mới) | | | Nút thắt có thể ở instance chứ không ở volume | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | Không mã hoá volume ĐANG CÓ trực tiếp được | | | Phải snapshot → chép có mã hoá → tạo volume mới | | | Mã hoá không ảnh hưởng hiệu năng đáng kể | |

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region ap-southeast-1 --encrypted --kms-key-id <arn-khoa>

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Volume tính theo GB CẤP PHÁT, không phải GB dùng | | | Snapshot tính theo dữ liệu thật đã thay đổi | | | Volume không gắn vào máy nào vẫn tính tiền | |

⚠ Volume mồ côi là khoản lãng phí kinh điển:

aws ec2 describe-volumes --filters Name=status,Values=available \
  --query "Volumes[].[VolumeId,Size,CreateTime]" --output table

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xác nhận volume có Encrypted: true | | | Chờ một chu kỳ, xem snapshot xuất hiện | | | Khôi phục thử từ snapshot | |

Và một lời khuyên: hãy bật mã hoá EBS mặc định cho toàn tài khoản thay vì tin vào quy trình. Mã hoá phải quyết định lúc tạo volume và không sửa được sau, nên một lần ai đó quên tích ô sẽ để lại một volume không mã hoá mà cách chữa duy nhất là chép sang volume mới rồi chuyển đổi.

Câu 1085 Chọn nhiều đáp án AWS Networking & Content Delivery

A game development company is planning to build a cloud-based game platform on AWS. The player activity patterns are unpredictable and could remain idle for extended periods. Only players who have purchased the game should have the ability to log in and play.

Which combination of steps will meet these requirements MOST cost-effectively? (Select THREE.)

  1. A

    Use AWS Cognito Identity Pools to handle user authentication.
  2. B

    Implement an AWS Lambda function to fetch player information from Amazon DynamoDB. Establish an Amazon API Gateway endpoint to handle RESTful API calls, directing them to the Lambda function.
  3. C

    Use Amazon S3 static web hosting with HTML, CSS, and JS. Use Amazon CloudFront to distribute the frontend game interface.
  4. D

    Use AWS Cognito User Pools to handle user authentication.
  5. E

    Set up an Amazon Elastic Container Service (Amazon ECS) service behind an Application Load Balancer to fetch player information from Amazon RDS. Establish an Amazon API Gateway endpoint to handle RESTful API calls, directing them to the ECS service.
  6. F

    Leverage AWS Amplify to serve the frontend game interface with HTML, CSS, and JS. Use the integrated Amazon CloudFront configuration for distribution.
Xem giải thích

Đáp án

B, D và F — Lambda lấy thông tin người chơi từ DynamoDB qua API Gateway; Cognito User Pools để xác thực; AWS Amplify phục vụ giao diện với CloudFront tích hợp.

Vì sao đúng

Đề nêu ba đặc điểm, và ba lựa chọn này khớp từng cái: | Đặc điểm | Lựa chọn | |---|---| | Hoạt động thất thường, có lúc rảnh rất lâu | B — serverless, rảnh thì không tốn tiền | | Chỉ ai đã mua game mới đăng nhập được | D — Cognito User Pools xác thực người dùng | | Giao diện web tĩnh, cần phân phối toàn cầu | F — Amplify + CloudFront |

⚠ B — vì sao serverless là lựa chọn tiết kiệm nhất ở đây:

"Idle for extended periods"
    → ECS + ALB + RDS vẫn tính tiền suốt lúc rảnh
        ↓
    Lambda + DynamoDB on-demand + API Gateway
    → 0 người chơi = gần 0 USD

⚠ D — User Pools vs Identity Pools là điểm mấu chốt: | Loại | Việc | |---|---| | User Pools | XÁC THỰC — thư mục người dùng, đăng nhập, đăng ký | | Identity Pools | PHÂN QUYỀN — đổi token lấy credential AWS tạm |

Đề hỏi: "chỉ người đã mua game mới ĐĂNG NHẬP được"
    → đây là xác thực → User Pools
        ↓
    Identity Pools không quản lý danh tính người dùng;
    nó cấp quyền truy cập tài nguyên AWS

Tạo User Pool:

aws cognito-idp create-user-pool --pool-name nguoi-choi \
  --auto-verified-attributes email \
  --policies '{"PasswordPolicy":{"MinimumLength":12,
    "RequireUppercase":true,"RequireNumbers":true,
    "RequireSymbols":true}}' \
  --mfa-configuration OPTIONAL

Gắn authorizer vào API Gateway:

aws apigatewayv2 create-authorizer --api-id abc123 \
  --authorizer-type JWT --name cognito-authorizer \
  --identity-source '$request.header.Authorization' \
  --jwt-configuration 'Audience=<client-id>,
    Issuer=https://cognito-idp.ap-southeast-1.amazonaws.com/<pool-id>'

⚠ F — vì sao Amplify hơn "S3 + CloudFront tự dựng":

Phương án C: S3 static hosting + CloudFront thủ công
    → phải tự dựng bucket, OAC, distribution,
      cache policy, quy trình triển khai
        ↓
Amplify: đã bao gồm CI/CD, CDN, HTTPS, tên miền,
         môi trường preview cho mỗi nhánh
    → ít việc hơn hẳn, cùng kết quả

Triển khai:

amplify init
amplify add hosting   # chọn Amazon CloudFront and S3
amplify publish

⚠ Cả ba mảnh ghép thành một kiến trúc trọn vẹn:

Trình duyệt
    → Amplify (CloudFront) phục vụ HTML/CSS/JS
        ↓
    Đăng nhập bằng Cognito User Pool → nhận JWT
        ↓
    Gọi API Gateway kèm JWT
        → authorizer kiểm token
        → Lambda đọc DynamoDB

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

  • **C. S3 static hosting + CloudFront thủ công — đây là phương án gần nhất với F và cho kết quả tương đương, nhưng phải tự dựng và tự bảo trì đường ống triển khai; Amplify gói sẵn đúng thứ đó.
  • **A. Cognito Identity Pools để xác thực người dùng — sai vai trò: Identity Pools cấp credential AWS, nó không phải thư mục người dùng và không xử lý đăng ký/đăng nhập.
  • **E. ECS sau ALB đọc từ RDS — ALB, task ECS và RDS đều tính tiền suốt thời gian rảnh, mâu thuẫn trực tiếp với "MOST cost-effectively" khi tải thất thường.

Ghi nhớ

⚠ Cognito User Pools vs Identity Pools — bảng phải thuộc: | | User Pools | Identity Pools | |---|---|---| | Việc | xác thực (ai đây?) | phân quyền (được làm gì?) | | Trả về | JWT token | credential AWS tạm | | Dùng với | API Gateway authorizer, ALB | truy cập S3, DynamoDB trực tiếp | | Có thư mục người dùng | ✅ | ❌ |

⚠ Chúng thường dùng CÙNG nhau:

User Pool xác thực → cho JWT
    → Identity Pool đổi JWT lấy credential AWS
        ↓
    Client tải ảnh thẳng lên S3 với quyền giới hạn

Từ khoá nhận diện:

"user sign-up, sign-in, MFA, user directory" → User Pools "temporary AWS credentials for the app" → Identity Pools "host a static frontend with CI/CD" → Amplify "serverless API" → API Gateway + Lambda

Ba lưu ý về DynamoDB cho tải thất thường: | Lưu ý | Chi tiết | |---|---| | Chế độ On-Demand — trả theo request | | | Không có "instance" nào chạy khi rảnh | | | Chuyển sang Provisioned khi tải ổn định | |

aws dynamodb create-table --table-name NguoiChoi \
  --attribute-definitions AttributeName=maNguoiChoi,AttributeType=S \
  --key-schema AttributeName=maNguoiChoi,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

⚠ On-Demand đắt hơn Provisioned khoảng 6-7 lần mỗi request:

Tải thất thường, nhiều lúc rảnh → On-Demand rẻ hơn nhiều
Tải đều 24/7                    → Provisioned rẻ hơn nhiều
        ↓
    Điểm hoà vốn khoảng 15-20% mức sử dụng liên tục

Ba tính năng User Pool nên bật: | Tính năng | Việc | |---|---| | MFA | | | Advanced security | phát hiện credential bị lộ | | Lambda trigger | kiểm tra "đã mua game chưa" |

⚠ Lambda trigger PreAuthentication là chỗ cài luật của đề:

def handler(su_kien, ngu_canh):
    email = su_kien['request']['userAttributes']['email']
    if not da_mua_game(email):
        raise Exception('Tai khoan chua mua game')
    return su_kien

Đề nói "chỉ người đã mua game mới đăng nhập được"
    → Cognito xác thực danh tính
    → trigger kiểm tra quyền sở hữu

Ba lưu ý về chi phí Cognito: | Lưu ý | Chi tiết | |---|---| | Tính theo người dùng hoạt động hằng tháng (MAU) | | | 50.000 MAU đầu miễn phí (đăng nhập trực tiếp) | | | Đăng nhập qua SAML/OIDC tính giá khác | |

Ba lưu ý về Amplify: | Lưu ý | Chi tiết | |---|---| | Tích hợp Git, tự build mỗi lần push | | | Môi trường preview cho mỗi pull request | | | HTTPS và tên miền tuỳ chỉnh sẵn | |

Ba lưu ý về API Gateway: | Lưu ý | Chi tiết | |---|---| | HTTP API rẻ hơn REST API ~70% | | | JWT authorizer dựng sẵn cho Cognito | | | Đặt throttling bảo vệ backend | |

Ba lưu ý về khởi động nguội: | Lưu ý | Chi tiết | |---|---| | Tải thất thường = khởi động nguội thường xuyên | | | Runtime nhẹ khởi động nhanh hơn | | | Provisioned concurrency loại bỏ nhưng tốn tiền cả lúc rảnh | |

⚠ Với game có lúc rảnh dài, đừng bật provisioned concurrency:

Nó giữ môi trường sẵn 24/7
    → mất đúng lợi thế mà đề đang tìm

Ba lưu ý về thiết kế bảng DynamoDB: | Lưu ý | Chi tiết | |---|---| | Thiết kế theo mẫu truy vấn, không chuẩn hoá | | | Khoá phân vùng phải phân tán đều | | | GSI cho mẫu truy vấn khác | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập thử, xem JWT hợp lệ | | | Gọi API không kèm token | phải 401 | | Kiểm tra chi phí trong tuần không có người chơi | |

Và một lời khuyên: hãy cài luật "đã mua game" vào Lambda trigger của Cognito chứ không vào mã ứng dụng. Kiểm tra ở tầng xác thực nghĩa là token chỉ được cấp cho người đủ điều kiện, còn kiểm tra trong ứng dụng nghĩa là ai gọi thẳng API cũng đã cầm sẵn token hợp lệ trong tay.

Câu 1086 AWS Analytics

A global logistics company collects shipment tracking information, which updates every few seconds. The company wishes to perform real-time analysis on these data updates to monitor shipment progress and predict delays, after which they want the data to be ingested into their Amazon S3-based data lake. Which solution will fulfill these requirements with the MOST operational efficiency?

  1. A

    Use Amazon SQS for data ingestion and Amazon EMR for real-time analysis.
  2. B

    Use AWS Direct Connect for data ingestion and Amazon Athena for real-time analysis.
  3. C

    Use Amazon Kinesis Data Streams for data ingestion and AWS Lambda for real-time data analysis.
  4. D

    Use Amazon Kinesis Data Firehose for data ingestion and Amazon Managed Service for Apache Flink for real-time analysis.
Xem giải thích

Đáp án

D — Dùng Kinesis Data Firehose để nhận dữ liệu và Amazon Managed Service for Apache Flink để phân tích thời gian thực.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này đáp ứng cả ba với ít việc vận hành nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Nhận cập nhật vài giây một lần | Firehose tự mở rộng, không cần chỉnh | | Phân tích thời gian thực, dự đoán chậm trễ | Flink xử lý luồng có trạng thái | | Cuối cùng đưa vào data lake trên S3 | Firehose giao thẳng vào S3 |

⚠ Flink là công cụ duy nhất trong bốn phương án làm được phân tích luồng có trạng thái:

Dự đoán chậm trễ cần:
    → cửa sổ thời gian (10 phút gần nhất)
    → so sánh với lịch trình
    → giữ trạng thái theo từng lô hàng
        ↓
    Đây là bài toán xử lý luồng có TRẠNG THÁI
    → Flink sinh ra cho việc này

Ví dụ truy vấn Flink SQL:

CREATE TABLE theo_doi_lo_hang (
  ma_lo        VARCHAR(32),
  vi_tri       VARCHAR(64),
  du_kien_den  TIMESTAMP(3),
  thoi_diem    TIMESTAMP(3),
  WATERMARK FOR thoi_diem AS thoi_diem - INTERVAL '5' SECOND
) WITH ('connector' = 'kinesis', ...);

SELECT ma_lo,
       COUNT(*) AS so_cap_nhat,
       MAX(thoi_diem) AS lan_cuoi
FROM theo_doi_lo_hang
GROUP BY ma_lo, TUMBLE(thoi_diem, INTERVAL '10' MINUTE)
HAVING MAX(thoi_diem) < CURRENT_TIMESTAMP - INTERVAL '30' MINUTE;

⚠ Watermark là khái niệm cốt lõi của xử lý luồng:

Dữ liệu từ hàng nghìn thiết bị tới KHÔNG theo thứ tự
    → bản ghi 10:05 có thể tới sau bản ghi 10:07
        ↓
    Watermark nói: "sau mốc này coi như không còn
    bản ghi cũ hơn nữa" → đóng cửa sổ và tính

Dựng ứng dụng Flink:

aws kinesisanalyticsv2 create-application \
  --application-name phan-tich-lo-hang \
  --runtime-environment FLINK-1_18 \
  --service-execution-role <arn-role> \
  --application-configuration '{
    "FlinkApplicationConfiguration": {
      "ParallelismConfiguration": {
        "ConfigurationType": "CUSTOM",
        "Parallelism": 4, "AutoScalingEnabled": true},
      "CheckpointConfiguration": {"ConfigurationType": "DEFAULT"}}}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không quản lý cụm nào | | | Flink tự lưu checkpoint, khôi phục sau lỗi | | | Firehose gộp bản ghi nhỏ thành tệp lớn cho S3 | |

⚠ Việc gộp bản ghi rất quan trọng cho data lake:

Cập nhật vài giây một lần từ hàng nghìn lô hàng
    → ghi thẳng vào S3 = hàng triệu object nhỏ
        ↓
    Firehose gom thành tệp 128 MB, nén, chuyển Parquet
    → Athena truy vấn nhanh hơn hàng trăm lần

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

  • **C. Kinesis Data Streams để nhận và Lambda để phân tích — đây là phương án gần nhất và cũng là kiến trúc luồng hợp lệ, nhưng Lambda không giữ trạng thái giữa các lần gọi: cửa sổ thời gian và phép so sánh lịch sử phải tự dựng bằng DynamoDB hay ElastiCache. Đề hỏi "MOST operational efficiency" — Flink làm sẵn phần đó.
  • **A. SQS để nhận và EMR để phân tích thời gian thực — SQS là hàng đợi tin nhắn, không phải luồng; EMR là cụm phải quản lý và thiên về xử lý theo lô.
  • **B. Direct Connect để nhận và Athena phân tích thời gian thực — Direct Connect là kết nối mạng, không phải dịch vụ nhận dữ liệu; Athena truy vấn dữ liệu tĩnh trên S3, không phải luồng.

Ghi nhớ

⚠ Bốn dịch vụ luồng của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Kinesis Data Streams | luồng thô, nhiều người tiêu thụ, đọc lại được | | Kinesis Data Firehose | giao vào S3/Redshift/OpenSearch, không quản lý | | Managed Service for Apache Flink | PHÂN TÍCH luồng có trạng thái | | MSK (Kafka) | Kafka được quản lý |

⚠ Managed Service for Apache Flink chính là Kinesis Data Analytics đổi tên (2023).

Từ khoá nhận diện:

"real-time analytics, windowing, anomaly detection" → Flink "deliver stream to S3, no infrastructure" → Firehose "sub-second, replay, multiple consumers" → Data Streams "query data already in S3" → Athena "existing Kafka application" → MSK

⚠ Firehose vs Data Streams — độ trễ là điểm phân biệt: | | Firehose | Data Streams | |---|---|---| | Độ trễ tối thiểu | 60 giây | ~200 ms | | Quản lý shard | không có | có | | Đọc lại dữ liệu cũ | ❌ | ✅ tới 365 ngày |

Ba mẫu kiến trúc luồng phổ biến: | Mẫu | Dùng khi | |---|---| | Firehose → S3 | chỉ cần đưa vào data lake | | Firehose → Flink → S3 | cần phân tích trên đường đi | | Data Streams → nhiều consumer | nhiều hệ thống cùng đọc |

⚠ Flink đọc được từ cả Data Streams lẫn Firehose, và ghi ra nhiều đích:

Nguồn: Kinesis, MSK, S3
Đích:  S3, Kinesis, OpenSearch, DynamoDB, Firehose
        ↓
    Đặt Flink ở giữa, không cần đổi hai đầu

Ba loại cửa sổ của Flink: | Loại | Nghĩa | |---|---| | Tumbling | không chồng lấn: 0-10, 10-20 phút | | Sliding | chồng lấn: 0-10, 5-15 phút | | Session | nhóm theo khoảng nghỉ giữa sự kiện |

Ba lưu ý về checkpoint: | Lưu ý | Chi tiết | |---|---| | Flink lưu trạng thái định kỳ | | | Khôi phục đúng vị trí sau lỗi | | | Cho ngữ nghĩa exactly-once | |

⚠ Không có checkpoint thì mọi trạng thái mất khi ứng dụng khởi động lại:

Đang tính tổng theo cửa sổ 1 giờ
    → ứng dụng lỗi ở phút 55
        ↓
    Không checkpoint: tính lại từ đầu, mất dữ liệu
    Có checkpoint:    tiếp tục từ mốc gần nhất

Ba lưu ý về mở rộng: | Lưu ý | Chi tiết | |---|---| | Parallelism quyết định thông lượng | | | Auto scaling theo mức dùng CPU | | | KPU là đơn vị tính phí |

Ba lưu ý về Firehose: | Lưu ý | Chi tiết | |---|---| | Đặt BufferingHints cân bằng độ trễ và cỡ tệp | | | Bật chuyển đổi sang Parquet | | | Dynamic partitioning theo trường dữ liệu | |

Ba lưu ý về phân vùng S3: | Lưu ý | Chi tiết | |---|---| | Dùng cấu trúc nam=/thang=/ngay= | | | Athena cắt bỏ phân vùng không cần | | | Giảm chi phí truy vấn nhiều lần | |

Ba lưu ý về xử lý bản ghi hỏng: | Lưu ý | Chi tiết | |---|---| | Đặt ErrorOutputPrefix cho Firehose | | | Bản ghi hỏng đi vào tiền tố lỗi, không mất | | | Theo dõi và xử lý định kỳ | |

Ba lưu ý về theo dõi: | Metric | Ý nghĩa | |---|---| | millisBehindLatest | Flink tụt hậu bao lâu | | fullRestarts | ứng dụng khởi động lại nhiều | | DeliveryToS3.Success | Firehose giao có thành công |

⚠ millisBehindLatest tăng đều nghĩa là xử lý chậm hơn dữ liệu tới:

Không tăng parallelism kịp
    → khoảng cách nới rộng mãi
        ↓
    "Thời gian thực" trở thành "chậm nửa tiếng"

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Flink tính theo KPU-giờ | | | Firehose tính theo GB nạp vào | | | S3 và Athena tính riêng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi bản ghi thử, xem tới S3 | | | Theo dõi millisBehindLatest | | | Chạy truy vấn Athena trên dữ liệu vừa đổ | |

Và một lời khuyên: hãy đặt cảnh báo cho millisBehindLatest ngay khi triển khai Flink. Ứng dụng xử lý luồng hiếm khi báo lỗi khi quá tải — nó chỉ tụt lại dần dần, và không ai nhận ra cho tới khi có người hỏi vì sao cảnh báo chậm trễ lại đến sau khi lô hàng đã tới nơi.

Câu 1087 AWS Management & Governance

A large company is currently using multiple AWS accounts as part of its cloud deployment model, and these accounts are currently structured using AWS Organizations. A Solutions Architect has been tasked with limiting access to an Amazon S3 bucket to only users of accounts that are enrolled with AWS Organizations. The Solutions Architect wants to avoid listing the many dozens of account IDs in the Bucket policy, as there are many accounts the frequent changes.

Which strategy meets these requirements with the LEAST amount of effort?

  1. A

    Use AWS Config and AWS Lambda functions to make remediations to the bucket policy as and when new accounts are created and tagged as not being part of AWS Organizations. Update the S3 bucket policy accordingly.
  2. B

    Use Attribute Based Access Control by referencing Tags of accounts which are either enrolled as part of AWS Organizations, or not.
  3. C

    Use the global key of AWS Organizations within a bucket policy using the aws:PrincipalOrgID key to allow access only to accounts which are part of the Organization.
  4. D

    Add all the non-organizational accounts to an Organizational Unit (OU) and attached a Service Control Policy (SCP) which denies access to the specific Amazon S3 bucket.
Xem giải thích

Đáp án

C — Dùng khoá toàn cục aws:PrincipalOrgID trong bucket policy để chỉ cho phép các tài khoản thuộc tổ chức.

Vì sao đúng

Đề nêu ba yêu cầu, và một dòng điều kiện đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Chỉ tài khoản trong Organizations được truy cập | aws:PrincipalOrgID | | KHÔNG liệt kê hàng chục account ID | một điều kiện thay cho cả danh sách | | Tài khoản thay đổi thường xuyên | tự cập nhật, không phải sửa policy |

⚠ Đây là khoá điều kiện sinh ra đúng cho tình huống này:

Thêm tài khoản vào tổ chức → TỰ ĐỘNG được phép
Gỡ tài khoản khỏi tổ chức  → TỰ ĐỘNG mất quyền
        ↓
    Không ai phải nhớ sửa bucket policy

Bucket policy:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChiChoPhepToChuc",
   "Effect": "Allow",
   "Principal": "*",
   "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
   "Resource": ["arn:aws:s3:::kho-chung",
                "arn:aws:s3:::kho-chung/*"],
   "Condition": {
     "StringEquals": {"aws:PrincipalOrgID": "o-abc123def4"}}}]}

⚠ Vì sao liệt kê account ID là lựa chọn tệ ở quy mô này:

Hàng chục tài khoản, thay đổi thường xuyên
    → mỗi lần thay đổi phải sửa policy
    → sửa sai một ký tự = mất quyền cả tổ chức
        ↓
    Và bucket policy có trần 20 KB
    → tổ chức lớn chạm trần thật

Dạng chặt hơn — dùng Deny:

{"Sid": "TuChoiNgoaiToChuc",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-chung",
              "arn:aws:s3:::kho-chung/*"],
 "Condition": {
   "StringNotEquals": {"aws:PrincipalOrgID": "o-abc123def4"},
   "BoolIfExists": {"aws:PrincipalIsAWSService": "false"}}}

⚠ aws:PrincipalIsAWSService là điều kiện phải thêm:

Dịch vụ AWS (CloudTrail, CloudFront...) gọi vào bucket
    → chúng KHÔNG mang aws:PrincipalOrgID
        ↓
    Deny StringNotEquals sẽ chặn luôn chúng
    → CloudTrail ngừng ghi log mà không rõ lý do

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một dòng thay cho danh sách dài | | | Tự theo cấu trúc tổ chức | | | Không chạm trần kích thước policy | |

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

  • **D. Đưa tài khoản ngoài tổ chức vào một OU rồi gắn SCP từ chối — đây là phương án gần nhất về mặt cũng dùng Organizations, nhưng hiểu sai hai điều: tài khoản ngoài tổ chức không nằm trong OU nào của tổ chức bạn, và SCP chỉ áp cho principal TRONG tổ chức — nó không ngăn được người ngoài.
  • **B. Dùng ABAC theo tag của tài khoản — phức tạp hơn nhiều, phải bảo trì tag cho mọi tài khoản, và tag có thể bị bỏ sót; aws:PrincipalOrgID không cần bảo trì gì.
  • **A. Dùng Config + Lambda tự sửa bucket policy khi có tài khoản mới — tự dựng lại thứ AWS đã có sẵn, thêm mã phải bảo trì, và có độ trễ giữa lúc tài khoản được tạo và lúc policy được cập nhật.

Ghi nhớ

⚠ Ba khoá điều kiện của Organizations — bảng phải thuộc: | Khoá | So với | |---|---| | aws:PrincipalOrgID | tổ chức của NGƯỜI GỌI | | aws:PrincipalOrgPaths | OU của người gọi | | aws:ResourceOrgID | tổ chức của TÀI NGUYÊN |

Giới hạn tới một OU cụ thể:

{"Condition": {"ForAnyValue:StringLike": {
  "aws:PrincipalOrgPaths": ["o-abc123def4/r-xyz/ou-sanxuat/*"]}}}

Từ khoá nhận diện:

"only accounts in my organization, avoid listing account IDs" → aws:PrincipalOrgID "only a specific OU" → aws:PrincipalOrgPaths "limit what my accounts can do" → SCP "a few named accounts" → liệt kê Principal

⚠ SCP vs resource policy — khác biệt cốt lõi phải nhớ:

SCP:  giới hạn quyền TỐI ĐA của principal trong tổ chức
      → KHÔNG cấp quyền
      → KHÔNG áp cho người ngoài tổ chức
        ↓
Resource policy: quyết định AI chạm được tài nguyên
      → áp cho MỌI người gọi, trong hay ngoài

Ba lớp bảo vệ bucket: | Lớp | Việc | |---|---| | Block Public Access | chặn mọi cấu hình công khai | | Bucket policy | ai được làm gì | | VPC endpoint policy | giới hạn theo đường mạng |

aws s3api put-public-access-block --bucket kho-chung \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

⚠ Bật Block Public Access ở cấp TÀI KHOẢN, không chỉ cấp bucket:

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

Cấp tài khoản áp cho MỌI bucket, kể cả bucket tạo sau
    → không phụ thuộc ai nhớ bật

Ba lưu ý về truy cập xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | Cần CẢ bucket policy VÀ IAM policy bên gọi | | | Thiếu một bên là bị từ chối | | | KMS key policy cũng phải cho phép | |

⚠ Bucket mã hoá SSE-KMS cần thêm một bước:

Bucket policy cho phép, KMS key policy không
    → AccessDenied mà thông báo không nhắc gì tới KMS
        ↓
    Thêm aws:PrincipalOrgID vào CẢ key policy

Ba lưu ý về giới hạn kích thước: | Chính sách | Trần | |---|---| | Bucket policy | 20 KB | | IAM managed policy | 6 KB | | SCP | 5 KB |

Ba lưu ý về Object Ownership: | Lưu ý | Chi tiết | |---|---| | BucketOwnerEnforced tắt hẳn ACL | khuyến nghị | | Chủ bucket sở hữu mọi object | | | Đơn giản hoá quyền xuyên tài khoản | |

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | IAM Access Analyzer | phát hiện truy cập từ ngoài tổ chức | | Policy Simulator | thử policy trước khi áp | | CloudTrail data events | ai đã đọc object nào |

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

⚠ Analyzer phạm vi ORGANIZATION là công cụ đúng ở đây:

Analyzer phạm vi ACCOUNT coi tài khoản khác
trong cùng tổ chức là "bên ngoài"
    → hàng loạt cảnh báo không phải vấn đề
        ↓
    Phạm vi ORGANIZATION chỉ báo truy cập
    thật sự từ ngoài tổ chức

Ba lưu ý về vận hành: | Lưu ý | Chi tiết | |---|---| | Lưu ID tổ chức vào biến của IaC | | | Rà lại policy khi tái cấu trúc OU | | | Ghi tài liệu vì sao chọn phạm vi này | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử từ tài khoản trong tổ chức | phải được | | Thử từ tài khoản ngoài | phải bị từ chối | | Chạy Access Analyzer | |

Và một lời khuyên: hãy thêm aws:PrincipalIsAWSService khi viết statement Deny theo aws:PrincipalOrgID. Dịch vụ AWS gọi vào bucket không mang khoá tổ chức, nên một chính sách Deny viết đúng ý đồ vẫn có thể chặn luôn CloudTrail hoặc CloudFront — và triệu chứng chỉ là log đột nhiên ngừng xuất hiện.

Câu 1088 AWS Database

A data analytics company is hosting a data lake which consists of data in Amazon S3 and Amazon RDS for PostgreSQL. The company needs a reporting solution that provides data visualization for the latest dataset and includes all the data sources within the data lake. Only the company's management team should have full access to all the visualizations. The rest of the company should have only limited access.

Which solution will meet these requirements?

  1. A

    Create an analysis in Amazon QuickSight. Connect all the data sources and create new datasets. Publish dashboards to visualize the data. Share the dashboards with the appropriate users and groups.
  2. B

    Create an AWS Glue table and crawler for the data in Amazon S3. Use Amazon Athena Federated Query to access data within Amazon RDS for PostgreSQL. Generate reports by using Amazon Athena. Publish the reports to Amazon S3. Use S3 bucket policies to limit access to the reports.
  3. C

    Create an AWS Glue table and crawler for the data in Amazon S3. Create an AWS Glue extract, transform, and load (ETL) job to produce reports. Publish the reports to Amazon S3. Use S3 bucket policies to limit access to the reports.
  4. D

    Create an analysis in Amazon QuickSight. Connect all the data sources and create new datasets. Publish dashboards to visualize the data. Share the dashboards with the appropriate IAM roles.
Xem giải thích

Đáp án

A — Tạo một phân tích trong Amazon QuickSight, nối mọi nguồn dữ liệu, xuất bản dashboard và chia sẻ với người dùng và nhóm phù hợp.

Vì sao đúng

Đề nêu ba yêu cầu, và QuickSight đáp ứng cả ba trong một sản phẩm: | Yêu cầu | Cách đáp ứng | |---|---| | Trực quan hoá dữ liệu mới nhất | QuickSight nối trực tiếp S3 và RDS | | Gồm mọi nguồn trong data lake | một phân tích nối nhiều dataset | | Ban lãnh đạo xem hết, người khác xem hạn chế | chia sẻ theo người dùng và NHÓM |

⚠ Vế cuối là chỗ phân biệt A với D:

QuickSight có hệ thống NGƯỜI DÙNG và NHÓM RIÊNG
    → không dùng IAM role để phân quyền dashboard
        ↓
    Chia sẻ với "nhóm ban lãnh đạo" và "nhóm nhân viên"
    → đúng cơ chế của QuickSight

Tạo nhóm và chia sẻ:

aws quicksight create-group --aws-account-id 123456789012 \
  --namespace default --group-name ban-lanh-dao

aws quicksight create-group-membership --aws-account-id 123456789012 \
  --namespace default --group-name ban-lanh-dao --member-name lan.nguyen

aws quicksight update-dashboard-permissions \
  --aws-account-id 123456789012 --dashboard-id bao-cao-tong \
  --grant-permissions '[{
    "Principal": "arn:aws:quicksight:ap-southeast-1:123456789012:group/default/ban-lanh-dao",
    "Actions": ["quicksight:DescribeDashboard",
                "quicksight:ListDashboardVersions",
                "quicksight:QueryDashboard"]}]'

Nối hai nguồn của data lake: | Nguồn | Cách nối | |---|---| | S3 | qua Athena hoặc tệp manifest | | RDS for PostgreSQL | kết nối trực tiếp trong VPC |

⚠ Cần VPC connection để QuickSight vào được RDS riêng tư:

aws quicksight create-vpc-connection \
  --aws-account-id 123456789012 \
  --vpc-connection-id ket-noi-vpc \
  --name "Ket noi VPC du lieu" \
  --subnet-ids subnet-a subnet-b \
  --security-group-ids sg-quicksight \
  --role-arn <arn-role>

Hai chế độ truy vấn: | Chế độ | Đặc điểm | |---|---| | Direct query | luôn mới nhất, mỗi lần mở đều truy vấn nguồn | | SPICE | nhanh, nhưng là ảnh chụp, phải làm mới |

⚠ Đề nói "latest dataset" — cân nhắc kỹ hai chế độ:

Direct query: dữ liệu luôn mới nhất
    → nhưng mỗi lần mở dashboard tốn truy vấn Athena/RDS
        ↓
SPICE: rất nhanh, không tải nguồn
    → nhưng "mới nhất" chỉ tới lần làm mới gần nhất
        ↓
    Đặt lịch làm mới SPICE mỗi giờ là dung hoà tốt

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không dựng hạ tầng BI nào | | | Phân quyền tới mức hàng và cột | | | Trả tiền theo người dùng, có gói theo phiên | |

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

  • **D. QuickSight nhưng chia sẻ dashboard với IAM role — đây là phương án gần nhất và chỉ sai đúng một chi tiết: QuickSight chia sẻ dashboard với người dùng và nhóm QuickSight, không phải với IAM role. (IAM chỉ dùng để cấp quyền quản trị QuickSight, không phải để phân quyền dashboard.)
  • **B. Glue + Athena Federated Query, xuất báo cáo ra S3, phân quyền bằng bucket policy — cho ra tệp báo cáo tĩnh, không phải trực quan hoá tương tác; và phân quyền theo bucket thô sơ hơn nhiều.
  • **C. Glue ETL sinh báo cáo ra S3 — cũng vậy: không có trực quan hoá, và không nối được RDS mà không thêm bước.

Ghi nhớ

⚠ Bốn công cụ phân tích — bảng phải thuộc: | Công cụ | Việc | |---|---| | QuickSight | trực quan hoá và dashboard | | Athena | SQL đặc biệt trên S3 | | Glue | ETL và catalog | | Redshift | kho dữ liệu quy mô lớn |

Từ khoá nhận diện:

"dashboards, visualization, share with users" → QuickSight "ad-hoc SQL on S3" → Athena "ETL, data catalog, crawler" → Glue "complex joins on terabytes, BI warehouse" → Redshift

⚠ Ba tầng phân quyền của QuickSight: | Tầng | Việc | |---|---| | Dashboard permission | ai xem được dashboard | | Row-level security (RLS) | ai xem được HÀNG nào | | Column-level security (CLS) | ai xem được CỘT nào |

RLS bằng bảng quy tắc:

UserName          | ChiNhanh
------------------|----------
lan.nguyen        | (trống = xem tất cả)
minh.tran         | Ha Noi
hoa.pham          | Da Nang

Cùng một dashboard
    → mỗi người thấy dữ liệu của mình
        ↓
    Không phải tạo dashboard riêng cho từng chi nhánh

⚠ CLS quan trọng cho dữ liệu nhạy cảm:

Cột "luong" chỉ nhóm nhân sự thấy
    → nhóm khác mở cùng dashboard, cột đó ẩn

Ba loại người dùng QuickSight: | Loại | Làm được gì | Giá tham khảo | |---|---|---| | Reader | chỉ xem | ~3 USD/tháng hoặc theo phiên | | Author | tạo phân tích | ~24 USD/tháng | | Admin | quản lý tài khoản | ~28 USD/tháng |

⚠ Gói theo phiên rẻ hơn nhiều cho người xem thỉnh thoảng:

Reader trả theo phiên: ~0,30 USD mỗi phiên 30 phút,
                       trần 5 USD/tháng
        ↓
    Người xem một lần mỗi tuần → rẻ hơn hẳn gói tháng

Ba lưu ý về SPICE: | Lưu ý | Chi tiết | |---|---| | Bộ nhớ đệm trong RAM, rất nhanh | | | Dung lượng tính phí theo GB | | | Làm mới theo lịch hoặc theo sự kiện | |

aws quicksight create-refresh-schedule \
  --aws-account-id 123456789012 --data-set-id bo-du-lieu \
  --schedule '{"ScheduleId":"moi-gio","RefreshType":"FULL_REFRESH",
    "ScheduleFrequency":{"Interval":"HOURLY"}}'

Ba lưu ý về nối RDS: | Lưu ý | Chi tiết | |---|---| | CSDL riêng tư cần VPC connection | | | Security group phải cho phép QuickSight | | | Nên dùng read replica, đừng đánh vào primary | |

⚠ Trỏ dashboard vào CSDL chính là sai lầm hay gặp:

Nhiều người mở dashboard cùng lúc
    → truy vấn nặng đánh vào CSDL sản xuất
        ↓
    Ứng dụng chậm theo
    → dùng read replica, hoặc dùng SPICE

Ba lưu ý về Athena làm nguồn: | Lưu ý | Chi tiết | |---|---| | Mỗi lần mở dashboard là một truy vấn tính tiền | | | Direct query trên Athena có thể tốn bất ngờ | | | SPICE giảm số truy vấn đáng kể | |

Ba lưu ý về tính năng nâng cao: | Tính năng | Việc | |---|---| | QuickSight Q | hỏi bằng ngôn ngữ tự nhiên | | ML Insights | phát hiện bất thường, dự báo | | Embedded analytics | nhúng dashboard vào ứng dụng |

Ba lưu ý về nhúng: | Lưu ý | Chi tiết | |---|---| | Nhúng cho người dùng ẩn danh cần gói capacity | | | Sinh URL nhúng có hạn | | | Kết hợp RLS để tách dữ liệu theo khách hàng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập bằng tài khoản nhân viên thường | xem có bị hạn chế đúng không | | Kiểm tra dữ liệu có mới không | | | Xem chi phí truy vấn nếu dùng Direct query | |

Và một lời khuyên: hãy trỏ QuickSight vào read replica chứ đừng vào CSDL chính. Dashboard được thiết kế để nhiều người mở cùng lúc, và những truy vấn tổng hợp nặng mà nó sinh ra sẽ cạnh tranh tài nguyên trực tiếp với ứng dụng đang phục vụ khách hàng.

Câu 1089 Chọn nhiều đáp án AWS Management & Governance

A software development firm uses AWS to run their compute instances across multiple accounts. These instances are individually billed. The company recently purchased an EC2 Reserved Instance (RI) for an ongoing project. However, due to the completion of that project, a significant number of EC2 instances were decommissioned. The company now wishes to utilize the benefits of their unused Reserved Instance across their other AWS accounts.

Which combination of steps should the company follow to achieve this? (Select TWO.)

  1. A

    Enable Reserved Instance sharing in the billing preferences section of the AWS Management Console for the account that purchased the existing RI.
  2. B

    From the AWS Organizations management account, utilize AWS Resource Access Manager (AWS RAM) to share the Reserved Instance with other accounts.
  3. C

    Enable Reserved Instance sharing in the billing preferences section of the AWS Management Console for the management account.
  4. D

    Use AWS Organizations to establish a new payer account and invite the other accounts to join this organization.
  5. E

    Establish an AWS Organization in the AWS account that purchased the RI and hosts the remaining active EC2 instances. Invite the other AWS accounts to join this organization from the management account.
Xem giải thích

Đáp án

A và E — Bật chia sẻ Reserved Instance trong phần Billing preferences của tài khoản đã mua RI, và lập AWS Organization trong chính tài khoản đó rồi mời các tài khoản khác tham gia.

Vì sao đúng

Đề mô tả nhiều tài khoản tính hoá đơn riêng lẻ và muốn dùng chung một RI chưa dùng hết. Có hai việc phải làm, theo đúng thứ tự:

Bước Việc Vì sao cần
E Lập tổ chức, gộp hoá đơn RI chỉ chia sẻ được TRONG một tổ chức
A Bật RI sharing mặc định đã bật, nhưng phải xác nhận

⚠ Điều kiện tiên quyết: phải có consolidated billing:

Tài khoản tính hoá đơn RIÊNG LẺ
    → mỗi tài khoản là một hoá đơn độc lập
    → RI của tài khoản này không thấy tài khoản kia
        ↓
    Gộp vào một tổ chức
    → hoá đơn hợp nhất
    → RI áp cho mọi tài khoản trong tổ chức

Lập tổ chức và mời:

aws organizations create-organization --feature-set ALL

aws organizations invite-account-to-organization \
  --target Id=234567890123,Type=ACCOUNT \
  --notes "Moi tham gia to chuc de dung chung RI"

Bật chia sẻ RI:

aws ce update-preferences \
  --reservation-sharing '{"Enabled": true}'

⚠ Cách RI được áp trong tổ chức:

1. AWS ưu tiên áp RI cho chính tài khoản đã mua
2. Phần chưa dùng hết được chia cho tài khoản khác
        ↓
    Tài khoản nào có instance khớp thuộc tính
    (loại, vùng, nền tảng, tenancy) thì hưởng

Bốn thuộc tính phải khớp để RI áp được: | Thuộc tính | Chi tiết | |---|---| | Loại instance | m5.large — hoặc cùng họ nếu Regional | | Region hoặc AZ | | | Nền tảng | Linux, Windows, RHEL... | | Tenancy | shared hay dedicated |

⚠ Regional RI linh hoạt hơn Zonal RI: | | Zonal RI | Regional RI | |---|---|---| | Đặt trước năng lực | ✅ | ❌ | | Linh hoạt cỡ máy | ❌ | ✅ trong cùng họ | | Áp cho mọi AZ | ❌ | ✅ |

Regional RI cho m5.large
    → cũng áp được cho 2 × m5.small
    → hoặc một phần của m5.xlarge
        ↓
    Đúng thứ cần khi máy móc thay đổi

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RI không dùng hết không bị lãng phí | | | Giảm giá cho toàn tổ chức | | | Quản lý hoá đơn tập trung | |

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

⚠ Phương án A và C mô tả CÙNG một tài khoản sau khi làm bước E.

Đề chọn E: "lập tổ chức trong chính tài khoản đã mua RI" — tài khoản đó trở thành management account. Vậy thì:

  • A: bật RI sharing ở "tài khoản đã mua RI"
  • C: bật RI sharing ở "management account"

Hai câu này chỉ cùng một tài khoản. Về mặt kỹ thuật, cấu hình RI sharing nằm ở management account, nên C mô tả chính xác hơn về mặt cơ chế, còn A mô tả chính xác hơn về mặt bối cảnh của đề. Không có cách nào phân biệt chúng.

Đây là lỗi soạn đề, không phải chỗ để suy luận
    → nếu gặp đề tương tự, chọn phương án
      nhất quán với các lựa chọn còn lại

Ghi lại điều này vì cách phản ứng đúng khi gặp hai phương án không phân biệt được là nhận ra đề có vấn đề, chứ không phải tự nghi ngờ hiểu biết của mình.

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

  • **C. Bật RI sharing ở management account — xem phần trên: không phân biệt được với A trong bối cảnh đề đã chọn E.
  • **B. Dùng AWS RAM chia sẻ Reserved Instance — RAM không chia sẻ được RI. RAM chia sẻ subnet, Transit Gateway, License Manager configuration, Route 53 Resolver rule... RI được chia sẻ qua consolidated billing, không qua RAM.
  • **D. Lập một tài khoản payer MỚI rồi mời mọi tài khoản vào — chạy được nhưng thừa: tài khoản đã mua RI hoàn toàn làm được management account, tạo thêm một tài khoản là công vô ích.

Ghi nhớ

⚠ Ba mô hình giảm giá cam kết — bảng phải thuộc: | Mô hình | Linh hoạt | Giảm tối đa | |---|---|---| | Standard RI | thấp nhất | ~72% | | Convertible RI | đổi được loại | ~66% | | Compute Savings Plans | cao nhất — mọi loại, vùng, cả Fargate/Lambda | ~66% | | EC2 Instance Savings Plans | một họ, một vùng | ~72% |

⚠ Savings Plans thường là lựa chọn tốt hơn RI ngày nay:

Compute Savings Plans áp cho:
    → EC2 mọi loại, mọi vùng
    → Fargate
    → Lambda
        ↓
    Cam kết theo SỐ TIỀN mỗi giờ, không theo loại máy
    → không bao giờ "mua sai loại"

⚠ Nhưng Savings Plans KHÔNG đặt trước năng lực: | Nhu cầu | Công cụ | |---|---| | Chỉ muốn giảm giá | Savings Plans | | Cần ĐẢM BẢO có máy | Zonal RI hoặc On-Demand Capacity Reservation |

Regional RI và Savings Plans KHÔNG giữ chỗ
    → AZ hết năng lực thì vẫn không khởi động được máy

Từ khoá nhận diện:

"share RI across accounts" → Organizations + consolidated billing "share subnets, Transit Gateway" → AWS RAM "flexible discount across services" → Savings Plans "guarantee capacity in an AZ" → Capacity Reservation

Ba thứ RAM chia sẻ được: | Tài nguyên | Chi tiết | |---|---| | Subnet của VPC | nhiều tài khoản dùng chung VPC | | Transit Gateway | | | License Manager configuration | |

Ba lưu ý về consolidated billing: | Lưu ý | Chi tiết | |---|---| | Gộp mức dùng để tính bậc giá | S3, truyền dữ liệu rẻ hơn | | RI và Savings Plans dùng chung | | | Free tier tính cho cả tổ chức, không nhân lên | |

⚠ Vế thứ ba hay gây bất ngờ:

10 tài khoản trong tổ chức
    → KHÔNG phải 10 suất free tier
    → chỉ một suất cho cả tổ chức

Ba lưu ý về tắt chia sẻ: | Lưu ý | Chi tiết | |---|---| | Tắt được cho từng tài khoản cụ thể | | | Dùng khi muốn RI chỉ phục vụ một dự án | | | Chỉnh trong Billing preferences | |

Ba lưu ý về theo dõi hiệu quả RI: | Báo cáo | Việc | |---|---| | RI utilization report | RI dùng hết bao nhiêu % | | RI coverage report | bao nhiêu máy được RI che | | Savings Plans utilization | tương tự |

aws ce get-reservation-utilization \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY

⚠ Utilization dưới 100% nghĩa là đang mất tiền:

RI utilization 60%
    → 40% số giờ đã trả tiền mà không dùng
        ↓
    Hoặc bật chia sẻ, hoặc bán trên RI Marketplace
    (chỉ Standard RI mới bán được)

Ba lưu ý về RI Marketplace: | Lưu ý | Chi tiết | |---|---| | Chỉ bán được Standard RI trả trước | | | Cần tài khoản ngân hàng ở Mỹ | | | Convertible RI KHÔNG bán được | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem RI utilization sau khi gộp | phải tăng | | Kiểm tra hoá đơn tài khoản con có giảm | | | Xác nhận RI sharing đang bật | |

Và một lời khuyên: hãy xem báo cáo RI utilization mỗi tháng, không phải mỗi năm. Một RI dùng hết 60% đang lặng lẽ mất tiền suốt thời gian còn lại của cam kết, và cách chữa — bật chia sẻ hoặc bán lại — chỉ có giá trị nếu bạn phát hiện khi hợp đồng còn dài chứ không phải lúc sắp hết hạn.

Câu 1090 AWS Compute

A company runs an internal browser-based application. The application runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Amazon EC2 Auto Scaling group across multiple Availability Zones. The Auto Scaling group scales up to 20 instances during work hours, but scales down to 2 instances overnight. Staff are complaining that the application is very slow when the day begins, although it runs well by midmorning

How should the scaling be changed to address the staff complaints and keep costs to a minimum?

  1. A

    Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period
  2. B

    Implement a step scaling action triggered at a lower CPU threshold, and decrease the cooldown period
  3. C

    Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens
  4. D

    Implement a scheduled action that sets the minimum and maximum capacity to 20 shortly before the office opens
Xem giải thích

Đáp án

A — Dùng target tracking kích hoạt ở ngưỡng CPU thấp hơn, và giảm cooldown period.

Vì sao đúng

Đề mô tả triệu chứng rất cụ thể: chậm lúc đầu giờ làm, tốt vào giữa buổi sáng.

Qua đêm: 2 máy
    ↓ 8 giờ sáng, mọi người đăng nhập cùng lúc
    ↓ CPU vọt lên
    ↓ chờ chạm ngưỡng → chờ hết cooldown
    ↓ khởi động máy mới → chờ boot → chờ health check
    ↓ lặp lại vài vòng mới đủ 20 máy
        ↓
    Nhân viên chịu chậm suốt quãng đó

⚠ Hai thay đổi trong phương án A tấn công đúng hai nguyên nhân: | Thay đổi | Giải quyết | |---|---| | Ngưỡng CPU thấp hơn | bắt đầu thêm máy SỚM hơn | | Cooldown ngắn hơn | các đợt thêm máy nối nhau nhanh hơn |

Và giữ được chi phí thấp:

Chỉ thêm máy khi tải thật sự tăng
    → 20 máy chỉ tồn tại lúc cần
        ↓
    Khác với đặt cứng 20 máy từ trước giờ mở cửa

Cấu hình:

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

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-ung-dung \
  --default-cooldown 60 --health-check-grace-period 120

⚠ Target tracking hơn step scaling ở chỗ tự điều chỉnh biên độ:

Step scaling: bạn định nghĩa từng bậc
    → CPU 60-70% thêm 1 máy, 70-80% thêm 2 máy...
    → phải tự đoán và tự bảo trì
        ↓
Target tracking: đặt một mục tiêu
    → ASG tự tính cần thêm bao nhiêu
    → càng xa mục tiêu càng thêm nhiều

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ít cấu hình hơn step scaling | | | Tự phản ứng với mọi mức tải | | | Không trả tiền cho máy dựng sẵn không dùng | |

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

⚠ Phương án C là câu trả lời tự nhiên hơn cho tình huống này ngoài đời.

Đề mô tả một mẫu tải hoàn toàn đoán trước được — mỗi ngày làm việc, đúng giờ mở cửa. Với mẫu như vậy, scheduled scaling là công cụ chuẩn:

Phương án Chi phí Chậm lúc đầu giờ
A — target tracking nhạy hơn thấp nhất giảm nhưng vẫn còn
C — đặt desired = 20 trước giờ mở cao hơn hết hẳn
D — đặt min = max = 20 cao nhất hết hẳn, nhưng khoá luôn cả ngày 
Đề đặt hai tiêu chí: hết chậm VÀ chi phí tối thiểu
    → A thắng ở tiêu chí thứ hai
    → C thắng ở tiêu chí thứ nhất
        ↓
    Đáp án chọn A, tức ưu tiên chi phí

Trong thực tế, cách làm đúng là KẾT HỢP CẢ HAI:

# Scheduled: nâng sàn trước giờ mở cửa
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name asg-ung-dung \
  --scheduled-action-name nang-san-sang \
  --recurrence "45 7 * * MON-FRI" --min-size 10 --max-size 20

# Scheduled: hạ sàn cuối ngày
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name asg-ung-dung \
  --scheduled-action-name ha-san-toi \
  --recurrence "0 19 * * MON-FRI" --min-size 2 --max-size 20

Scheduled đặt SÀN, target tracking lo phần trên
    → có máy sẵn lúc đầu giờ
    → vẫn co giãn theo tải thật

⚠ Và câu trả lời hiện đại nhất không nằm trong bốn phương án — predictive scaling:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-ung-dung \
  --policy-name du-doan --policy-type PredictiveScaling \
  --predictive-scaling-configuration '{
    "MetricSpecifications": [{"TargetValue": 50,
      "PredefinedMetricPairSpecification": {
        "PredefinedMetricType": "ASGCPUUtilization"}}],
    "Mode": "ForecastAndScale",
    "SchedulingBufferTime": 300}'

Học mẫu tải 14 ngày qua
    → tự dự báo và chuẩn bị máy TRƯỚC khi tải tới
        ↓
    Đúng bài toán của đề, không phải đoán giờ bằng tay

Warm pool cũng đáng biết — giữ sẵn máy ở trạng thái đã boot nhưng dừng, nên khởi động chỉ mất vài giây thay vì vài phút.

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

  • **C. Scheduled action đặt desired = 20 trước giờ mở cửa — xem phần trên: giải quyết triệt để chuyện chậm nhưng đắt hơn, vì 20 máy chạy từ trước khi ai cần chúng.
  • **D. Scheduled action đặt min VÀ max = 20 — tệ hơn C: khoá cứng ở 20 máy nên không co giãn xuống được cho tới khi có hành động khác, tốn tiền cả ngày.
  • **B. Step scaling ở ngưỡng thấp hơn — cũng cải thiện, nhưng đòi cấu hình nhiều bậc và phải tự bảo trì; target tracking cho cùng kết quả với ít việc hơn.

Ghi nhớ

⚠ Bốn chính sách mở rộng — bảng phải thuộc: | Chính sách | Khi nào | |---|---| | Target tracking | mặc định tốt nhất — đặt một mục tiêu | | Step scaling | cần kiểm soát biên độ theo từng bậc | | Scheduled | mẫu tải đoán trước theo giờ/ngày | | Predictive | học lịch sử, chuẩn bị TRƯỚC |

Từ khoá nhận diện:

"keep CPU around X%" → target tracking "traffic spikes every weekday at 9am" → scheduled hoặc predictive "slow at start of surge" → warm pool, predictive, hoặc hạ ngưỡng "different action for different severity" → step scaling

Ba yếu tố quyết định tốc độ phản ứng: | Yếu tố | Ảnh hưởng | |---|---| | Chu kỳ metric | 1 phút (detailed) vs 5 phút | | Cooldown / warm-up | thời gian chờ giữa hai đợt | | Thời gian máy sẵn sàng | boot + khởi động ứng dụng |

⚠ Bật detailed monitoring là cải thiện rẻ nhất:

aws ec2 monitor-instances --instance-ids i-abc

Metric 5 phút: phát hiện tải tăng chậm tới 5 phút
    ↓
Metric 1 phút: phát hiện trong 1 phút
    → ~0,30 USD mỗi instance mỗi tháng

Ba cách rút ngắn thời gian máy sẵn sàng: | Cách | Chi tiết | |---|---| | AMI đã cài sẵn ứng dụng | thay vì cài lúc khởi động | | Warm pool | máy đã boot, đang dừng | | Giảm việc trong user data | |

⚠ Warm pool là công cụ ít người dùng nhưng rất hợp bài này:

aws autoscaling put-warm-pool \
  --auto-scaling-group-name asg-ung-dung \
  --min-size 8 --pool-state Stopped

8 máy đã boot xong, đang ở trạng thái Stopped
    → chỉ trả tiền EBS, không trả tiền compute
        ↓
    Cần thì khởi động lại trong vài chục giây
    → nhanh hơn nhiều so với dựng từ AMI

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Dùng ELB thay vì EC2 | | | health-check-grace-period đủ dài | | | Quá ngắn = máy bị giết trước khi kịp sẵn sàng | |

⚠ Grace period quá ngắn tạo vòng lặp chết:

Ứng dụng cần 90 giây để sẵn sàng
Grace period đặt 60 giây
        ↓
    ASG giết máy ở giây 60, dựng máy mới
    → lặp mãi, không bao giờ có máy khoẻ

Ba lưu ý về thu nhỏ: | Lưu ý | Chi tiết | |---|---| | Thu nhỏ chậm hơn mở rộng — có chủ ý | | | Tránh dao động (thrashing) | | | Scale-in protection cho máy có việc dở | |

Ba lưu ý về chính sách kết thúc: | Chính sách | Chọn máy nào để tắt | |---|---| | Default | cân bằng AZ, rồi máy cũ nhất | | OldestInstance | | | NewestInstance | hữu ích khi thử nghiệm |

Ba lưu ý về metric mở rộng: | Metric | Khi nào hợp | |---|---| | CPU | tải tính toán | | ALBRequestCountPerTarget | web — thường tốt hơn CPU | | Metric tuỳ chỉnh | độ sâu hàng đợi |

⚠ Với ứng dụng web, số request mỗi máy thường là tín hiệu tốt hơn CPU:

CPU tăng SAU khi request dồn tới
    → phản ứng luôn trễ một nhịp
        ↓
    Số request là tín hiệu SỚM hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem lịch sử hoạt động của ASG lúc 8h | | | Đo thời gian từ lúc tải tăng tới lúc đủ máy | | | Hỏi lại nhân viên sau một tuần | |

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name asg-ung-dung --max-items 20 \
  --query "Activities[].[StartTime,StatusCode,Description]" --output table

Và một lời khuyên: hãy cân nhắc predictive scaling cho mẫu tải lặp theo ngày làm việc. Hạ ngưỡng và rút cooldown giúp phản ứng nhanh hơn, nhưng vẫn là phản ứng sau khi người dùng đã bắt đầu chịu chậm — còn dự báo thì chuẩn bị máy trước khi họ bấm nút đăng nhập.