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

Tìm thấy 2194 câu.

Câu 821 AWS Networking & Content Delivery

A company needs to connect its on-premises data center network to a new virtual private cloud (VPC). There is a symmetrical internet connection of 100 Mbps in the data center network. The data transfer rate for an on-premises application is multiple gigabytes per day. Processing will be done using an Amazon Kinesis Data Firehose stream.

What should a solutions architect recommend for maximum performance?

  1. A

    Get an AWS Snowball Edge Storage Optimized device. Data must be copied to the device after several days and shipped to AWS for expedited transfer to Kinesis Data Firehose. Repeat as necessary.
  2. B

    Kinesis Data Firehose can be connected to the VPC using AWS PrivateLink. Install a 1 Gbps AWS Direct Connect connection between the on-premises network and AWS. To send data from on-premises to Kinesis Data Firehose, use the PrivateLink endpoint.
  3. C

    Establish an AWS Site-to-Site VPN connection between the on-premises network and the VPC. Set up BGP routing between the customer gateway and the virtual private gateway. Send data to Kinesis Data Firehose using a VPN connection.
  4. D

    Establish a peering connection between the on-premises network and the VPC. Configure routing for the on-premises network to use the VPC peering connection.
Xem giải thích

Đáp án

B — Kết nối Kinesis Data Firehose với VPC bằng AWS PrivateLink; lắp Direct Connect 1 Gbps giữa mạng tại chỗ và AWS; gửi dữ liệu qua PrivateLink endpoint.

Vì sao đúng

Đề cho hai con số, và chúng chỉ ra nút thắt ngay lập tức:

Đường Internet hiện có: 100 Mbps đối xứng
Dữ liệu mỗi ngày: NHIỀU GIGABYTE
        ↓
    100 Mbps ≈ 12,5 MB/giây ≈ ~1 TB mỗi ngày nếu dùng HẾT
    → nhưng đường đó còn phải phục vụ mọi việc khác
        ↓
    Nâng lên Direct Connect 1 Gbps là điều kiện cần

Và PrivateLink là mảnh ghép thứ hai:

Firehose là dịch vụ có endpoint CÔNG CỘNG
    → gửi thẳng qua Internet = không riêng tư, không ổn định
        ↓
    Interface endpoint (PrivateLink) cho Firehose
    → truy cập được từ on-premises QUA Direct Connect

Điểm mấu chốt: chỉ interface endpoint mới dùng được từ on-premises.

Gateway endpoint (S3, DynamoDB): CHỈ trong VPC
Interface endpoint:               dùng được từ on-premises
                                    qua VPN hoặc Direct Connect
        ↓
    Firehose dùng interface endpoint → phù hợp

Triển khai:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --vpc-endpoint-type Interface   --service-name com.amazonaws.ap-northeast-1.kinesis-firehose   --subnet-ids subnet-a subnet-c   --security-group-ids sg-endpoint --private-dns-enabled

Và máy tại chỗ gọi qua Private VIF:

Ứng dụng tại chỗ → Direct Connect (Private VIF)
    → VPC → interface endpoint → Firehose
        ↓
    Toàn bộ đường đi trong mạng riêng

Ba lợi ích của Direct Connect ở đây: | Lợi ích | Chi tiết | |---|---| | Băng thông ổn định 1 Gbps | gấp 10 lần đường hiện có | | Độ trễ thấp và ít biến động | quan trọng với luồng liên tục | | Phí truyền dữ liệu ra RẺ HƠN | ~0,02 vs ~0,09 USD/GB |

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

  • **C. Dựng Site-to-Site VPN với BGP rồi gửi dữ liệu qua đó — đây là phương án gần nhất và dựng nhanh hơn nhiều, nhưng nó vẫn đi qua chính đường Internet 100 Mbps đang có: VPN không tạo thêm băng thông, và độ trễ vẫn biến động theo chất lượng Internet. Đề hỏi "maximum performance".
  • **A. Dùng Snowball Edge chép dữ liệu rồi gửi đi — không phù hợp với luồng LIÊN TỤC: Snowball dùng cho di chuyển một lần, còn đây là dữ liệu phát sinh mỗi ngày. Và Firehose là dịch vụ luồng thời gian thực, không nhận dữ liệu từ thiết bị vận chuyển.
  • **D. Tạo peering connection giữa mạng tại chỗ và VPC — không tồn tại: VPC peering chỉ nối hai VPC, không nối mạng on-premises.

Ghi nhớ

Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ | | Truy cập từ ON-PREMISES | ❌ | ✅ qua VPN/DX | | Chi phí | miễn phí | ~0,01 USD/giờ mỗi AZ |

Dòng giữa là chìa khoá của câu này.

Ba cách kết nối on-premises với AWS: | Cách | Băng thông | Thời gian dựng | |---|---|---| | Site-to-Site VPN | ~1,25 Gbps mỗi tunnel, qua Internet | vài giờ | | Direct Connect | 1–400 Gbps, đường riêng | vài tuần–tháng | | DX + VPN | như DX, có mã hoá | như DX |

Từ khoá nhận diện:

"maximum performance", "consistent bandwidth", "multiple GB per day" → Direct Connect "fastest to set up", "encrypted", "small traffic" → VPN

Ba loại virtual interface của Direct Connect: | Loại | Truy cập | |---|---| | Private VIF | VPC qua IP riêng ← dùng với interface endpoint | | Public VIF | dịch vụ AWS công cộng | | Transit VIF | qua Transit Gateway |

Hai cách truy cập dịch vụ AWS từ on-premises: | Cách | Đặc điểm | |---|---| | Private VIF + interface endpoint | IP riêng, kiểm soát bằng security group ← câu này | | Public VIF | IP công cộng của dịch vụ, không tốn phí endpoint |

Ba dịch vụ luồng của AWS: | Dịch vụ | Đặc điểm | |---|---| | Kinesis Data Streams | giữ 1–365 ngày, nhiều consumer | | Kinesis Data Firehose | nạp vào đích, không giữ lại | | Amazon MSK | Kafka |

Ba đích của Firehose: | Đích | Hỗ trợ | |---|---| | Amazon S3 | ✅ | | Amazon Redshift | ✅ | | OpenSearch Service | ✅ | | Splunk, HTTP endpoint, Snowflake | ✅ | | DynamoDB | ❌ |

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | KHÔNG mã hoá theo mặc định | thêm VPN hoặc MACsec nếu cần | | Một kết nối là điểm hỏng đơn | nên có hai | | Mất hàng tuần tới tháng để dựng | |

Ba mức khả dụng: | Mô hình | SLA | |---|---| | Một kết nối | không có SLA cao | | Hai kết nối cùng vị trí | 99,9% | | Hai kết nối, hai vị trí | 99,99% |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cổng Direct Connect theo giờ | | | Phí truyền dữ liệu ra ~0,02 USD/GB | rẻ hơn Internet | | Interface endpoint ~0,01 USD/giờ mỗi AZ | |

Ba lưu ý về Firehose: | Lưu ý | Chi tiết | |---|---| | Đệm tối thiểu 60 giây | không phải thời gian thực tuyệt đối | | Tự thử lại và co giãn | | | Biến đổi dữ liệu bằng Lambda được | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IncomingBytes của Firehose | lượng nạp | | DeliveryToS3.Success | tỷ lệ giao thành công | | ConnectionState của DX | kết nối lên hay xuống |

Và một lời khuyên: hãy dựng Site-to-Site VPN song song với Direct Connect làm đường dự phòng. Direct Connect mất hàng tuần để lắp và một kết nối duy nhất là điểm hỏng đơn — còn VPN lên trong vài giờ, tốn khoảng 36 USD mỗi tháng, và giữ được luồng dữ liệu chạy khi đường riêng gặp sự cố.

Câu 822 AWS Compute

A financial services company operates multiple internal services across various AWS accounts. The company uses AWS Organizations to manage these accounts and needs a centralized security appliance in a networking account to inspect all inter-service communication between AWS accounts. The solution must ensure secure and efficient routing of traffic through the security appliance.

Which solution will meet these requirements?

  1. A

    Deploy an Application Load Balancer (ALB) in the networking account to route traffic to the security appliance. Configure the service accounts to send traffic to the ALB by using a private link.
  2. B

    Deploy a Network Load Balancer (NLB) in the networking account to route traffic to the security appliance. Configure the service accounts to send traffic to the NLB by using a VPC peering connection.
  3. C

    Deploy interface VPC endpoints in the networking account for each service in the service accounts. Configure the security appliance to inspect traffic sent through the endpoints.
  4. D

    Deploy a Gateway Load Balancer (GWLB) in the networking account to route traffic to the security appliance. Configure the service accounts to send traffic to the GWLB by using a Gateway Load Balancer endpoint in each service account.
Xem giải thích

Đáp án

D — Triển khai Gateway Load Balancer (GWLB) ở tài khoản mạng để định tuyến lưu lượng tới thiết bị bảo mật; các tài khoản dịch vụ gửi lưu lượng qua GWLB endpoint đặt trong mỗi tài khoản.

Vì sao đúng

Đề nêu ba yêu cầu, và GWLB được thiết kế đúng cho bài toán này: | Yêu cầu | Cơ chế | |---|---| | Thiết bị bảo mật TẬP TRUNG ở tài khoản mạng | GWLB đứng trước fleet thiết bị | | Kiểm tra MỌI lưu lượng giữa các tài khoản | GWLB endpoint chèn vào đường đi | | Định tuyến an toàn và hiệu quả | GENEVE giữ nguyên gói tin gốc |

GWLB hoạt động ở tầng 3 và có cơ chế riêng:

GWLB dùng giao thức GENEVE (cổng 6081)
    → ĐÓNG GÓI nguyên vẹn gói tin gốc
    → gửi tới thiết bị bảo mật
    → thiết bị kiểm tra rồi trả lại
        ↓
    Địa chỉ nguồn và đích KHÔNG bị thay đổi
    → thiết bị thấy đúng lưu lượng thật

Và GWLB endpoint là mảnh ghép cho đa tài khoản:

GWLB ở tài khoản MẠNG
    → tạo VPC Endpoint Service
        ↓
Mỗi tài khoản dịch vụ tạo GWLB ENDPOINT trong VPC của mình
    → route table trỏ lưu lượng qua endpoint đó
        ↓
    Lưu lượng tự động đi vòng qua thiết bị bảo mật

Triển khai:

aws elbv2 create-load-balancer --name gwlb-kiem-tra   --type gateway --subnets subnet-a subnet-c

aws ec2 create-vpc-endpoint-service-configuration   --gateway-load-balancer-arns <arn-gwlb> --no-acceptance-required

# Ở mỗi tài khoản dịch vụ
aws ec2 create-vpc-endpoint --vpc-id vpc-dich-vu   --vpc-endpoint-type GatewayLoadBalancer   --service-name com.amazonaws.vpce.ap-northeast-1.vpce-svc-0abc   --subnet-ids subnet-kiem-tra

Và route table chèn endpoint vào đường đi:

aws ec2 create-route --route-table-id rtb-ung-dung   --destination-cidr-block 10.0.0.0/8   --vpc-endpoint-id vpce-0abc

Ba lợi ích của mô hình này: | Lợi ích | Chi tiết | |---|---| | Một fleet thiết bị phục vụ mọi tài khoản | tiết kiệm giấy phép và vận hành | | Trong suốt với ứng dụng | không sửa gì ở tầng ứng dụng | | Co giãn và chịu lỗi tự động | GWLB quản lý fleet |

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

  • **B. Triển khai NLB ở tài khoản mạng, các tài khoản dịch vụ gửi lưu lượng qua VPC peering — đây là phương án gần nhất vì NLB cũng ở tầng 4 và chịu tải cao, nhưng nó không phải thiết bị chèn vào đường đi (bump-in-the-wire): NLB là điểm đến của lưu lượng, không trong suốt. Ứng dụng phải chủ động gửi tới NLB thay vì lưu lượng tự đi qua.
  • **A. Dùng ALB với PrivateLink — ALB chỉ hiểu HTTP/HTTPS, không kiểm tra được lưu lượng ở tầng mạng nói chung.
  • **C. Dùng interface VPC endpoint cho từng dịch vụ — endpoint kiểm soát ĐƯỜNG ĐI tới một dịch vụ cụ thể, nó không phải cơ chế chèn thiết bị kiểm tra vào giữa.

Ghi nhớ

Ba loại load balancer — bảng phải thuộc: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP) | 4 (TCP/UDP) | 3 (IP) | | Vai trò | điểm đến | điểm đến | chèn vào đường đi | | Giao thức riêng | — | — | GENEVE cổng 6081 | | Dùng cho | ứng dụng web | TCP hiệu năng cao | thiết bị bảo mật ảo |

Từ khoá nhận diện:

"security appliance", "traffic inspection", "transparent" → Gateway Load Balancer "HTTP routing" → ALB "static IP, UDP, extreme performance" → NLB

Ba đặc điểm của GWLB: | Đặc điểm | Chi tiết | |---|---| | GENEVE đóng gói gói tin gốc | thiết bị thấy nguồn và đích thật | | Giữ flow stickiness | cùng luồng tới cùng thiết bị | | Health check và co giãn fleet | |

Ba loại thiết bị hay đặt sau GWLB: | Thiết bị | Việc | |---|---| | Firewall của bên thứ ba | Palo Alto, Fortinet, Check Point | | IDS/IPS | phát hiện và ngăn xâm nhập | | Công cụ phân tích lưu lượng | |

Và AWS có lựa chọn thay thế:

AWS Network Firewall:
    → tường lửa được quản lý ở cấp VPC
    → không cần dựng thiết bị hay GWLB
        ↓
    Ít công vận hành hơn nhiều nếu không đòi
      thiết bị của hãng cụ thể

Ba kiến trúc kiểm tra lưu lượng đa tài khoản: | Kiến trúc | Đặc điểm | |---|---| | GWLB + endpoint mỗi VPC | ← câu này, thiết bị của bên thứ ba | | Network Firewall ở VPC kiểm tra tập trung | được quản lý | | Transit Gateway với VPC kiểm tra | định tuyến tập trung |

Mẫu kết hợp phổ biến:

Transit Gateway nối mọi VPC
    → định tuyến qua VPC kiểm tra
    → trong đó có GWLB và thiết bị bảo mật
        ↓
    Mọi lưu lượng giữa các VPC đều bị kiểm tra

Ba lưu ý về GWLB endpoint: | Lưu ý | Chi tiết | |---|---| | Là một loại VPC endpoint riêng | GatewayLoadBalancer | | Đặt trong subnet riêng | subnet kiểm tra | | Route table trỏ tới endpoint | |

Ba lưu ý về thiết kế route: | Lưu ý | Chi tiết | |---|---| | Cần route ở CẢ HAI chiều | đi và về | | Dễ tạo vòng lặp định tuyến | vẽ sơ đồ trước | | Subnet kiểm tra không được trỏ vòng lại chính nó | |

Ba lưu ý về AWS RAM: | Lưu ý | Chi tiết | |---|---| | Chia sẻ Transit Gateway cho tài khoản khác | | | GWLB endpoint service dùng cơ chế PrivateLink | | | RAM miễn phí | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | GWLB thêm một chặng vào đường đi | tăng độ trễ chút ít | | Fleet thiết bị phải đủ lớn | tránh thành nút thắt | | Theo dõi metric của cả GWLB lẫn thiết bị | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyHostCount | số thiết bị đang phục vụ | | ProcessedBytes | lưu lượng qua GWLB | | UnHealthyHostCount | |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | GWLB theo giờ và GLCU | | | GWLB endpoint mỗi AZ mỗi VPC | | | Giấy phép thiết bị của bên thứ ba | thường lớn nhất |

Ba lựa chọn đơn giản hơn nếu không cần thiết bị riêng: | Lựa chọn | Chi tiết | |---|---| | AWS Network Firewall | tường lửa được quản lý | | Security group và NACL | kiểm soát cơ bản | | VPC Flow Logs + GuardDuty | phát hiện, không chặn |

Và một lời khuyên: hãy vẽ sơ đồ định tuyến đầy đủ cả hai chiều trước khi triển khai GWLB. Đây là kiến trúc dễ tạo vòng lặp định tuyến nhất trong AWS, và triệu chứng — gói tin biến mất hoặc quay vòng cho tới hết TTL — rất khó chẩn đoán nếu không có sơ đồ đối chiếu.

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

An Amazon VPC contains several Amazon EC2 instances. The instances need to make API calls to Amazon DynamoDB. A solutions architect needs to ensure that the API calls do not traverse the internet.

How can this be accomplished? (Select TWO.)

  1. A

    Create a route table entry for the endpoint
  2. B

    Create a new DynamoDB table that uses the endpoint
  3. C

    Create a gateway endpoint for DynamoDB
  4. D

    Create an ENI for the endpoint in each of the subnets of the VPC
  5. E

    Create a VPC peering connection between the VPC and DynamoDB
Xem giải thích

Đáp án

A và C.

  • C — Tạo gateway endpoint cho DynamoDB
  • A — Tạo route table entry trỏ tới endpoint đó

Vì sao đúng

Đề yêu cầu lời gọi API tới DynamoDB không đi qua Internet, và gateway endpoint là cơ chế đúng.

Gateway endpoint hỗ trợ ĐÚNG HAI dịch vụ:
    ✓ Amazon S3
    ✓ Amazon DynamoDB
        ↓
    DynamoDB nằm trong danh sách

Và hai đáp án là hai bước bắt buộc của cùng một việc:

C: tạo endpoint
A: thêm route để lưu lượng ĐI QUA nó
        ↓
    Tạo endpoint mà không gắn vào route table
    → lưu lượng vẫn đi ra Internet như cũ

Cơ chế:

AWS thêm vào route table một prefix list:
    pl-ddb (dải IP của DynamoDB trong Region) → vpce-xxxxx
        ↓
    Mọi request tới DynamoDB tự động đi qua endpoint
    → ứng dụng KHÔNG phải sửa gì

Triển khai — một lệnh làm cả hai việc:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-northeast-1.dynamodb   --vpc-endpoint-type Gateway   --route-table-ids rtb-private-a rtb-private-c

Tham số --route-table-ids chính là bước A — AWS tự thêm route vào các bảng đó.

Và gateway endpoint MIỄN PHÍ:

Gateway endpoint:  0 USD
NAT Gateway:       ~32 USD/tháng + 0,045 USD/GB
        ↓
    Vừa riêng tư hơn vừa rẻ hơn

Và endpoint policy giới hạn thêm:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["dynamodb:GetItem","dynamodb:PutItem","dynamodb:Query"],
  "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/du-lieu"}]}

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

  • **D. Tạo ENI cho endpoint trong mỗi subnet của VPC — đây là phương án gần nhất vì mô tả đúng cách INTERFACE endpoint hoạt động, nhưng gateway endpoint không dùng ENI: nó hoạt động qua route table. Với DynamoDB thì gateway endpoint là lựa chọn đúng (và miễn phí).
  • **B. Tạo bảng DynamoDB MỚI dùng endpoint — không phải cách hoạt động: endpoint là cấu hình mạng của VPC, bảng DynamoDB không "thuộc về" endpoint nào.
  • **E. Tạo VPC peering giữa VPC và DynamoDB — không làm được: DynamoDB là dịch vụ được quản lý, không nằm trong VPC nào để peering.

Ghi nhớ

Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Cơ chế | route trong ROUTE TABLE | ENI có IP riêng | | Chi phí | MIỄN PHÍ | ~0,01 USD/giờ mỗi AZ | | Từ on-premises | ❌ | ✅ | | Security group | ❌ | ✅ |

Quy tắc: S3 và DynamoDB dùng gateway endpoint, trừ khi cần truy cập từ on-premises.

Ba bước để endpoint hoạt động: | Bước | Chi tiết | |---|---| | ① Tạo endpoint | chọn dịch vụ và loại | | ② Gắn vào route table | ← bước hay bị quên | | ③ Kiểm tra IAM policy | vẫn cần quyền gọi API |

Ba lợi ích của VPC endpoint: | Lợi ích | Chi tiết | |---|---| | Lưu lượng không ra Internet | | | Tiết kiệm phí NAT Gateway | | | Kiểm soát bằng endpoint policy | |

Ba loại chính sách phải cùng cho phép: | Chính sách | Việc | |---|---| | IAM policy của EC2 role | principal được làm gì | | Endpoint policy | gì đi qua endpoint được phép | | Resource policy (nếu có) | |

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Gắn vào ĐÚNG route table của subnet | | | Chỉ hoạt động TRONG Region | | | Không dùng từ on-premises | |

Ba dịch vụ nên có endpoint trong VPC riêng tư: | Dịch vụ | Loại | |---|---| | S3, DynamoDB | gateway (miễn phí) | | Systems Manager (3 endpoint) | interface | | Secrets Manager, KMS, ECR | interface |

Ba cách kiểm chứng lưu lượng qua endpoint: | Cách | Việc | |---|---| | CloudTrail: trường vpcEndpointId | bằng chứng rõ nhất | | VPC Flow Logs | đích là IP nội bộ | | describe-route-tables | có prefix list |

aws ec2 describe-route-tables --route-table-ids rtb-private-a   --query 'RouteTables[].Routes[?GatewayId!=null]'

Ba lưu ý về DynamoDB Streams: | Lưu ý | Chi tiết | |---|---| | KHÔNG đi qua gateway endpoint | | | Cần interface endpoint riêng | com.amazonaws.<region>.dynamodb-streams | | Chi tiết ít người biết | |

Ba biện pháp bảo mật kết hợp: | Biện pháp | Chi tiết | |---|---| | aws:SourceVpce trong IAM policy | ép đi qua endpoint | | Endpoint policy giới hạn bảng | | | Mã hoá DynamoDB bằng KMS | |

Chính sách ép đi qua endpoint:

{"Effect": "Deny", "Action": "dynamodb:*", "Resource": "*",
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc"}}}

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Gateway endpoint | 0 USD | | Tiết kiệm NAT | 32 USD/tháng + phí GB | | Không có phí truyền dữ liệu qua gateway endpoint | |

Ba việc nên làm khi thiết kế VPC: | Việc | Chi tiết | |---|---| | Tạo gateway endpoint cho S3 và DynamoDB NGAY | miễn phí | | Thêm interface endpoint cho dịch vụ hay dùng | | | Đánh giá xem còn cần NAT Gateway không | |

Và một lời khuyên: hãy truyền --route-table-ids ngay khi tạo endpoint. Tạo endpoint mà quên gắn vào route table là lỗi rất phổ biến, và nó hoàn toàn im lặng — endpoint hiện ra trong console như đã sẵn sàng, nhưng lưu lượng vẫn đi qua NAT Gateway như cũ và bạn vẫn trả phí như trước.

Câu 824 AWS Networking & Content Delivery

A company has two accounts for perform testing and each account has a single VPC: VPC-TEST1 and VPC-TEST2. The operations team require a method of securely copying files between Amazon EC2 instances in these VPCs. The connectivity should not have any single points of failure or bandwidth constraints.

Which solution should a Solutions Architect recommend?

  1. A

    Attach a virtual private gateway to VPC-TEST1 and VPC-TEST2 and enable routing.
  2. B

    Attach a Direct Connect gateway to VPC-TEST1 and VPC-TEST2 and enable routing.
  3. C

    Create a VPC gateway endpoint for each EC2 instance and update route tables.
  4. D

    Create a VPC peering connection between VPC-TEST1 and VPC-TEST2.
Xem giải thích

Đáp án

D — Tạo VPC peering connection giữa VPC-TEST1 và VPC-TEST2.

Vì sao đúng

Đề nêu ba yêu cầu, và VPC peering đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Chép tệp an toàn giữa EC2 ở hai VPC | peering cho kết nối riêng tư trực tiếp | | KHÔNG có điểm hỏng đơn | peering là hạ tầng AWS, dư thừa sẵn | | KHÔNG giới hạn băng thông | peering KHÔNG có trần băng thông |

Vế thứ ba là điểm phân biệt quyết định:

VPC peering:
    → dùng chính hạ tầng mạng của AWS
    → KHÔNG có thiết bị trung gian nào
        ↓
    Băng thông giới hạn bởi chính instance,
      không phải bởi kết nối
        ↓
Transit Gateway: 50 Gbps mỗi attachment
VPN: ~1,25 Gbps mỗi tunnel

Và peering hoạt động xuyên tài khoản:

# Ở tài khoản của VPC-TEST1
aws ec2 create-vpc-peering-connection   --vpc-id vpc-test1   --peer-vpc-id vpc-test2   --peer-owner-id 222222222222

# Ở tài khoản của VPC-TEST2
aws ec2 accept-vpc-peering-connection   --vpc-peering-connection-id pcx-0abc

Và phải thêm route ở CẢ HAI phía:

aws ec2 create-route --route-table-id rtb-test1   --destination-cidr-block 10.2.0.0/16   --vpc-peering-connection-id pcx-0abc

aws ec2 create-route --route-table-id rtb-test2   --destination-cidr-block 10.1.0.0/16   --vpc-peering-connection-id pcx-0abc

Thiếu một chiều là kết nối không hoạt động — lỗi rất hay gặp.

Và security group phải cho phép:

aws ec2 authorize-security-group-ingress --group-id sg-test2   --protocol tcp --port 22 --cidr 10.1.0.0/16

Lưu ý: tham chiếu security group xuyên tài khoản cần peering đã hoạt động — với hai tài khoản khác nhau, dùng CIDR đơn giản hơn.

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

  • **A. Gắn virtual private gateway vào cả hai VPC và bật routing — đây là phương án gần nhất vì VGW cũng là thành phần định tuyến, nhưng nó dùng để nối VPC với ON-PREMISES qua VPN hoặc Direct Connect, không nối hai VPC với nhau.
  • **B. Gắn Direct Connect gateway vào cả hai VPC — cũng là công cụ cho kết nối on-premises: DX Gateway nối một Direct Connect với nhiều VPC, không phải cơ chế nối hai VPC.
  • **C. Tạo VPC gateway endpoint cho mỗi EC2 instance — hiểu sai hoàn toàn: gateway endpoint dùng để truy cập S3 và DynamoDB riêng tư, không nối hai VPC và không gắn với instance.

Ghi nhớ

Ba cách kết nối VPC — bảng phải thuộc: | | VPC Peering | Transit Gateway | PrivateLink | |---|---|---|---| | Bắc cầu | ❌ | ✅ | — | | Băng thông | KHÔNG giới hạn | 50 Gbps mỗi attachment | — | | Số kết nối với n VPC | n(n−1)/2 | n | — | | CIDR chồng lấn | ❌ | ❌ | ✅ | | Chi phí | chỉ phí dữ liệu | phí attachment + dữ liệu | phí endpoint |

Với ĐÚNG HAI VPC, peering là lựa chọn đơn giản và rẻ nhất.

Từ khoá nhận diện:

"two VPCs", "no bandwidth constraints", "no single point of failure" → VPC Peering "many VPCs", "hub and spoke", "connect on-premises too" → Transit Gateway "expose one service", "one-way" → PrivateLink

Ba hạn chế của VPC peering: | Hạn chế | Chi tiết | |---|---| | KHÔNG bắc cầu | A↔B và A↔C không cho B↔C | | CIDR không được chồng lấn | | | Full mesh tăng theo n(n−1)/2 | |

Ba đặc điểm của peering: | Đặc điểm | Chi tiết | |---|---| | Không có thiết bị trung gian | không phải quản lý gì | | Dư thừa sẵn có | không có điểm hỏng đơn | | Xuyên tài khoản và xuyên Region | |

Ba bước bắt buộc: | Bước | Chi tiết | |---|---| | ① Tạo và CHẤP NHẬN peering | hai phía | | ② Thêm route ở CẢ HAI route table | | | ③ Security group cho phép | |

Ba lưu ý về inter-Region peering: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ giữa hầu hết Region | | | Lưu lượng mã hoá tự động | AWS lo | | Tốn phí truyền dữ liệu xuyên Region | |

Ba lưu ý về tham chiếu security group: | Lưu ý | Chi tiết | |---|---| | Tham chiếu SG xuyên VPC được với peering CÙNG Region | | | KHÔNG được với peering XUYÊN Region | dùng CIDR | | Cần bật tuỳ chọn DNS resolution | để phân giải tên riêng |

Bật phân giải DNS qua peering:

aws ec2 modify-vpc-peering-connection-options   --vpc-peering-connection-id pcx-0abc   --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

Ba cách chép tệp giữa EC2: | Cách | Đặc điểm | |---|---| | scp hoặc rsync qua IP riêng | đơn giản nhất | | Qua S3 làm trung gian | không cần peering | | EFS mount cả hai bên | cần peering hoặc cùng VPC |

Cách thứ hai đáng cân nhắc:

Chép qua S3:
    → không cần peering
    → có gateway endpoint thì miễn phí và riêng tư
        ↓
    Nhưng thêm một chặng, và đề hỏi về kết nối trực tiếp

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Peering connection MIỄN PHÍ | | | Truyền dữ liệu cùng AZ qua peering | miễn phí | | Truyền dữ liệu chéo AZ | ~0,01 USD/GB mỗi chiều |

Dòng giữa đáng lưu ý — đặt instance cùng AZ thì chép tệp qua peering không tốn gì.

Ba lỗi thường gặp khi dựng peering: | Lỗi | Triệu chứng | |---|---| | Quên route ở một phía | kết nối một chiều, timeout | | Security group chưa mở | timeout | | CIDR chồng lấn | không tạo được peering |

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | chỉ ra thành phần chặn | | VPC Flow Logs | thấy gói REJECT | | describe-vpc-peering-connections | trạng thái |

Và một lời khuyên: hãy kiểm tra route ở CẢ HAI route table khi peering không hoạt động. Đó là nguyên nhân số một, và triệu chứng — kết nối timeout mà trạng thái peering hiện "active" — dễ khiến người ta đi tìm ở security group trước.

Câu 825 AWS Networking & Content Delivery

A genomics research organization is building an application to analyze large datasets. Raw genomic data is stored in an Amazon S3 bucket, processed by multiple Amazon EC2 instances, and the results are stored in a separate S3 bucket. The application frequently transfers large amounts of data between the EC2 instances during analysis. The organization wants to reduce overall data transfer costs while maintaining efficient data processing.

What should the solutions architect do to achieve this?

  1. A

    Deploy all the EC2 instances in the same Availability Zone to eliminate cross-AZ data transfer charges.
  2. B

    Use Amazon Elastic Fabric Adapter (EFA) to enable high-speed data transfer between EC2 instances, reducing transfer costs.
  3. C

    Use Amazon S3 Transfer Acceleration to optimize the transfer of data between the EC2 instances and the S3 buckets.
  4. D

    Configure an Auto Scaling group to launch the EC2 instances in multiple Regions to distribute the processing workload.
Xem giải thích

Đáp án

A — Triển khai tất cả EC2 instance trong CÙNG một Availability Zone để loại bỏ phí truyền dữ liệu chéo AZ.

Vì sao đúng

Đề nêu vấn đề rõ: chuyển lượng lớn dữ liệu GIỮA CÁC EC2 instance, và muốn giảm chi phí truyền dữ liệu.

EC2 nói chuyện với EC2 qua IP riêng:
    Cùng AZ:   MIỄN PHÍ
    Khác AZ:   ~0,01 USD/GB MỖI CHIỀU
        ↓
    Với "large amounts of data" liên tục, khoản này rất lớn

Phép tính với 100 TB trao đổi mỗi tháng:

Chéo AZ: 100.000 GB × 0,01 × 2 chiều = 2.000 USD/tháng
Cùng AZ: 0 USD
        ↓
    Tiết kiệm toàn bộ khoản đó

Và với tải HPC phân tích gen, cùng AZ còn có lợi ích thứ hai:

Cùng AZ = độ trễ mạng thấp nhất
    → và dùng được cluster placement group
        ↓
    Băng thông giữa các node cao nhất

Cluster placement group:

aws ec2 create-placement-group --group-name nhom-phan-tich --strategy cluster

aws ec2 run-instances --instance-type c6i.8xlarge   --placement GroupName=nhom-phan-tich,AvailabilityZone=ap-northeast-1a   --count 10

⚠ Và đánh đổi phải nêu rõ:

Cùng một AZ = KHÔNG chịu được mất AZ đó
    → mọi instance ngừng cùng lúc
        ↓
    Chấp nhận được với tải PHÂN TÍCH THEO ĐỢT
    (dữ liệu gốc ở S3, chạy lại được)
    → KHÔNG chấp nhận được với dịch vụ phục vụ người dùng

Và nên thêm gateway endpoint cho S3:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-northeast-1.s3   --vpc-endpoint-type Gateway --route-table-ids rtb-abc

Truy cập S3 qua gateway endpoint: MIỄN PHÍ
    → thay vì qua NAT Gateway (0,045 USD/GB)

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

  • **B. Dùng Elastic Fabric Adapter (EFA) để truyền dữ liệu tốc độ cao giữa EC2, "giảm chi phí truyền" — đây là phương án gần nhất vì EFA thật sự là công nghệ đúng cho HPC, nhưng nó KHÔNG giảm chi phí truyền dữ liệu: EFA cải thiện độ trễ và thông lượng, giá truyền dữ liệu vẫn tính như cũ. (EFA đòi cluster placement group, tức là cùng AZ — nên gián tiếp cũng đưa tới cùng AZ, nhưng mệnh đề trong phương án sai.)
  • **C. Dùng S3 Transfer Acceleration giữa EC2 và S3 — sai mục đích và còn TĂNG chi phí: Transfer Acceleration dành cho truyền dữ liệu từ xa qua Internet, và nó tính thêm ~0,04 USD/GB. EC2 và S3 cùng Region vốn đã nhanh và miễn phí.
  • **D. Dùng ASG khởi động EC2 ở NHIỀU REGION — làm chi phí tăng vọt: truyền dữ liệu xuyên Region tốn ~0,02 USD/GB trở lên, đắt hơn cả chéo AZ.

Ghi nhớ

Chi phí truyền dữ liệu của AWS — bảng phải thuộc: | Chiều | Chi phí | |---|---| | VÀO AWS (ingress) | MIỄN PHÍ | | Cùng AZ, qua IP RIÊNG | MIỄN PHÍ | | Cùng AZ, qua IP CÔNG CỘNG | ~0,01 USD/GB mỗi chiều | | Chéo AZ, cùng Region | ~0,01 USD/GB mỗi chiều | | Xuyên Region | ~0,02 USD/GB trở lên | | RA Internet | ~0,09 USD/GB |

Bảng này giải thích trọn vẹn câu hỏi.

Ba cách giảm chi phí truyền dữ liệu: | Cách | Tiết kiệm | |---|---| | Đặt tài nguyên liên quan CÙNG AZ | ← câu này | | Dùng IP RIÊNG, không dùng IP công cộng | | | VPC gateway endpoint cho S3 và DynamoDB | bỏ phí NAT |

Ba đánh đổi của việc dùng một AZ: | Đánh đổi | Chi tiết | |---|---| | Không chịu được mất AZ | | | Chấp nhận được với tải tái tạo được | ← trường hợp này | | KHÔNG chấp nhận được với dịch vụ sản xuất | |

Ba loại placement group: | Loại | Đặc điểm | |---|---| | Cluster | cùng AZ, độ trễ thấp nhất, băng thông cao nhất | | Spread | trải trên phần cứng khác nhau, tối đa 7 instance mỗi AZ | | Partition | nhóm phân vùng, cho HDFS, Cassandra |

Ba loại giao diện mạng — nhắc lại: | Loại | Đặc điểm | |---|---| | ENI | giao diện ảo cơ bản | | ENA | hiệu năng cao, tới 100 Gbps | | EFA | ENA + OS bypass cho HPC |

EFA cải thiện HIỆU NĂNG, không phải CHI PHÍ — đó là điểm phương án B sai.

Ba lưu ý về EFA: | Lưu ý | Chi tiết | |---|---| | KHÔNG tính phí thêm | | | Cần cluster placement group | tức là cùng AZ | | Security group phải TỰ THAM CHIẾU | |

Ba lựa chọn lưu trữ chia sẻ cho HPC: | Lựa chọn | Đặc điểm | |---|---| | FSx for Lustre | thông lượng cao nhất, tích hợp S3 | | EFS | đơn giản hơn, đa AZ | | Instance store | nhanh nhất, không chia sẻ |

FSx for Lustre đáng cân nhắc:

Liên kết bucket S3
    → tự nạp dữ liệu khi node đọc
    → nhiều node chia sẻ cùng file system
        ↓
    Có thể giảm hẳn lượng dữ liệu trao đổi
      trực tiếp giữa các instance

Ba công cụ phân tích chi phí truyền dữ liệu: | Công cụ | Việc | |---|---| | Cost Explorer lọc theo usage type | DataTransfer-Regional-Bytes | | VPC Flow Logs | luồng nào chiếm nhiều nhất | | Cost and Usage Report | chi tiết nhất |

Tìm luồng tốn tiền:

SELECT srcaddr, dstaddr, SUM(bytes)/1073741824 AS gb
FROM vpc_flow_logs WHERE day = '2026-08-30'
GROUP BY srcaddr, dstaddr ORDER BY gb DESC LIMIT 20;

Ba lưu ý khi thiết kế cho HPC: | Lưu ý | Chi tiết | |---|---| | Cùng AZ và cluster placement group | | | Dựng cụm theo đợt rồi xoá | không để chạy không | | Spot cho tải chịu gián đoạn | tiết kiệm tới 90% |

Ba lưu ý về S3 trong kiến trúc này: | Lưu ý | Chi tiết | |---|---| | S3 cùng Region: truyền miễn phí | qua gateway endpoint | | Multipart upload cho tệp lớn | | | Lifecycle cho dữ liệu gốc cũ | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NetworkIn, NetworkOut | lưu lượng mỗi instance | | Chi phí DataTransfer trong Cost Explorer | | | Thời gian hoàn tất job | |

Và một lời khuyên: hãy kiểm tra mục DataTransfer trong Cost Explorer trước khi tối ưu bất cứ thứ gì khác. Với tải phân tích gen trao đổi hàng chục terabyte giữa các node, khoản này thường lớn hơn cả chi phí tính toán — và nó gần như luôn giảm được chỉ bằng việc đặt lại vị trí instance.

Câu 826 AWS Migration & Transfer

A company runs an application in an on-premises data center that collects environmental data from production machinery. The data consists of JSON files stored on network attached storage (NAS) and around 5 TB of data is collected each day. The company must upload this data to Amazon S3 where it can be processed by an analytics application. The data must be transferred securely.

Which solution offers the MOST reliable and time-efficient data transfer?

  1. A

    AWS DataSync over AWS Direct Connect.
  2. B

    Multiple AWS Snowcone devices.
  3. C

    Amazon S3 Transfer Acceleration over the Internet.
  4. D

    AWS Database Migration Service over the Internet.
Xem giải thích

Đáp án

A — AWS DataSync qua AWS Direct Connect.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp DataSync + Direct Connect đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | 5 TB MỖI NGÀY, liên tục | cần đường truyền ổn định, không phải vận chuyển vật lý | | TIN CẬY nhất | DataSync tự thử lại và kiểm tra toàn vẹn | | An toàn | Direct Connect riêng + TLS của DataSync |

Vế đầu loại bỏ Snowcone ngay:

5 TB mỗi NGÀY, đều đặn
    → Snowcone chỉ 8–14 TB mỗi thiết bị
    → phải gửi đi gửi lại liên tục
        ↓
    Snow Family dùng cho DI CHUYỂN MỘT LẦN,
      không cho luồng dữ liệu hằng ngày

Và DataSync là công cụ đúng cho việc chuyển tệp lặp lại:

AWS DataSync:
    ✓ giao thức truyền tối ưu riêng của AWS
    ✓ nhanh hơn công cụ thông thường tới 10 lần
    ✓ kiểm tra toàn vẹn TỰ ĐỘNG mọi tệp
    ✓ chạy theo LỊCH
    ✓ tự thử lại khi lỗi
        ↓
    Đúng "MOST RELIABLE"

Và Direct Connect cho phần "time-efficient":

5 TB mỗi ngày ≈ 58 MB/giây liên tục nếu trải đều
    → cần khoảng 500 Mbps chỉ riêng cho việc này
        ↓
    Đường Internet chia sẻ không đảm bảo được
    → Direct Connect cho băng thông ổn định

Triển khai:

aws datasync create-location-nfs   --server-hostname 192.168.1.100 --subdirectory /du-lieu   --on-prem-config AgentArns=<arn-agent>

aws datasync create-location-s3   --s3-bucket-arn arn:aws:s3:::kho-du-lieu   --s3-config BucketAccessRoleArn=<arn-role>

aws datasync create-task   --source-location-arn <arn-nfs> --destination-location-arn <arn-s3>   --options VerifyMode=POINT_IN_TIME_CONSISTENT,TransferMode=CHANGED   --schedule ScheduleExpression="cron(0 2 * * ? *)"

TransferMode=CHANGED chỉ chuyển tệp mới hoặc đã đổi — quan trọng với việc chạy hằng ngày.

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

  • **C. Dùng S3 Transfer Acceleration qua Internet — đây là phương án gần nhất và thật sự tăng tốc tải lên, nhưng nó kém tin cậy hơn: vẫn đi qua Internet công cộng với băng thông biến động, và không có cơ chế thử lại hay kiểm tra toàn vẹn ở mức tệp như DataSync.
  • **B. Dùng nhiều Snowcone — không phù hợp với luồng hằng ngày: Snowcone chỉ 8–14 TB, và chu kỳ vận chuyển mất nhiều ngày. Với 5 TB mỗi ngày, bạn sẽ luôn chậm hơn tốc độ phát sinh dữ liệu.
  • **D. Dùng Database Migration Service qua Internet — sai công cụ hoàn toàn: DMS di chuyển database, không chuyển tệp JSON trên NAS.

Ghi nhớ

Ba công cụ chuyển dữ liệu lên AWS — bảng phải thuộc: | Công cụ | Phù hợp | |---|---| | AWS DataSync | chuyển TỆP, một lần hoặc theo LỊCH | | AWS Snow Family | di chuyển MỘT LẦN, mạng không đủ | | Storage Gateway | truy cập LIÊN TỤC, có cache |

Từ khoá nhận diện:

"daily transfer", "reliable", "NFS/SMB files" → DataSync "one-time migration", "poor connectivity" → Snowball "on-premises apps need ongoing access" → Storage Gateway

Ba đặc điểm của DataSync: | Đặc điểm | Chi tiết | |---|---| | Nhanh hơn công cụ thông thường tới 10 lần | giao thức riêng | | Kiểm tra toàn vẹn tự động | checksum mọi tệp | | Bảo toàn metadata | quyền, timestamp |

Ba nguồn và đích DataSync hỗ trợ: | Loại | Ví dụ | |---|---| | Tại chỗ | NFS, SMB, HDFS, object storage | | AWS | S3, EFS, FSx (mọi loại) | | Đám mây khác | Azure, Google Cloud |

Ba tuỳ chọn quan trọng của task: | Tuỳ chọn | Chi tiết | |---|---| | TransferMode | CHANGED (chỉ tệp đổi) hoặc ALL | | VerifyMode | kiểm tra toàn vẹn | | PreserveDeletedFiles | giữ hay xoá tệp đã bị xoá ở nguồn |

Quy tắc ước lượng thời gian truyền:

Thời gian (giờ) = Dung lượng (TB) × 8.000 ÷ (Băng thông Mbps × 3,6)
        ↓
    5 TB qua 500 Mbps ≈ 22 giờ — quá sát 24 giờ
    5 TB qua 1 Gbps  ≈ 11 giờ — thoải mái

Ba lựa chọn kết nối: | Cách | Băng thông | Ổn định | |---|---|---| | Internet | tuỳ hợp đồng | thấp | | Site-to-Site VPN | ~1,25 Gbps mỗi tunnel | vừa | | Direct Connect | 1–400 Gbps | cao nhất |

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | KHÔNG mã hoá theo mặc định | DataSync tự dùng TLS | | Mất hàng tuần tới tháng để lắp | | | Phí truyền dữ liệu ra rẻ hơn Internet | |

Dòng đầu đáng lưu ý: DataSync mã hoá dữ liệu trên đường truyền bằng TLS, nên yêu cầu "transferred securely" được đáp ứng dù Direct Connect không tự mã hoá.

Ba cách tăng tốc DataSync: | Cách | Chi tiết | |---|---| | Nhiều agent chạy song song | chia thư mục | | Nhiều task cho các thư mục khác nhau | | | Đặt băng thông tối đa hợp lý | tránh nghẽn |

aws datasync update-task --task-arn <arn>   --options BytesPerSecond=500000000

Ba lưu ý về agent: | Lưu ý | Chi tiết | |---|---| | Triển khai dạng máy ảo tại chỗ | VMware, Hyper-V, KVM | | Hoặc EC2 nếu nguồn ở AWS | | | Không cần agent khi cả hai đầu là dịch vụ AWS | |

Ba lưu ý về hiệu năng với tệp nhỏ: | Lưu ý | Chi tiết | |---|---| | Nhiều tệp nhỏ chậm hơn ít tệp lớn | | | DataSync xử lý song song nhiều tệp | | | Cân nhắc gộp nếu có hàng triệu tệp rất nhỏ | |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | DataSync | ~0,0125 USD/GB chuyển | | Nhập vào AWS | miễn phí phí mạng | | 5 TB/ngày ≈ 62 USD/ngày phí DataSync | đáng cân nhắc |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | FilesTransferred, BytesTransferred | tiến độ | | FilesVerified | kiểm tra toàn vẹn | | CloudWatch Logs của task | lỗi cụ thể |

Ba lựa chọn xử lý sau khi dữ liệu vào S3: | Lựa chọn | Chi tiết | |---|---| | Athena truy vấn JSON trực tiếp | | | Glue biến đổi sang Parquet | rẻ hơn khi truy vấn | | Lambda xử lý theo sự kiện S3 | |

Và một lời khuyên: hãy đặt TransferMode=CHANGED cho task chạy hằng ngày. Nếu để ALL, DataSync sẽ so sánh và chuyển lại toàn bộ 5 TB mỗi đêm dù chỉ một phần nhỏ thay đổi — vừa tốn thời gian vừa tốn phí chuyển dữ liệu một cách hoàn toàn không cần thiết.

Câu 827 Chọn nhiều đáp án AWS Migration & Transfer

A healthcare organization operates multiple applications on virtual machines (VMs) in its on-premises data center. Due to increasing demand for its services, the data center can no longer scale quickly enough to meet business needs. The organization has decided to migrate its non-critical workloads to AWS using a lift-and-shift strategy to expedite the process.

Which combination of steps will meet these requirements? (Select THREE.)

  1. A

    Use AWS Server Migration Service (AWS SMS) to automate the migration of VMs to Amazon EC2 instances.
  2. B

    Stop all operations on the VMs. Perform a cutover by launching the migrated instances in AWS.
  3. C

    Complete the initial data replication from the VMs to AWS. Launch test instances to perform acceptance tests for the workloads.
  4. D

    Use AWS Application Migration Service to replicate the VMs to AWS. Install the AWS Replication Agent on each VM.
  5. E

    Use AWS App Runner to containerize the workloads before migrating them to AWS.
  6. F

    Install the AWS Systems Manager Agent on the VMs to streamline operational management during migration.
Xem giải thích

Đáp án

B, C và D.

  • D — Dùng AWS Application Migration Service (MGN), cài AWS Replication Agent trên mỗi máy ảo
  • C — Hoàn tất sao chép ban đầu, khởi động instance kiểm thử để nghiệm thu
  • B — Dừng máy ảo nguồn và cắt chuyển bằng cách khởi động instance đã di chuyển

Vì sao đúng

Đề nêu chiến lược lift-and-shift để đẩy nhanh tiến độ, và ba bước trên chính là quy trình chuẩn của MGN.

Quy trình ba giai đoạn:

① Cài AWS Replication Agent lên máy ảo nguồn         ← đáp án D
   → sao chép LIÊN TỤC ở mức KHỐI sang AWS
   → nguồn vẫn chạy, KHÔNG gián đoạn

② Khởi động TEST INSTANCE                             ← đáp án C
   → nghiệm thu trên AWS
   → nguồn VẪN chạy và vẫn được sao chép

③ Dừng nguồn và CUTOVER                               ← đáp án B
   → khởi động instance thật
   → chuyển lưu lượng sang

Vì sao MGN phù hợp với lift-and-shift:

Sao chép ở mức KHỐI (block-level)
    → không quan tâm ứng dụng chạy gì
    → không sửa mã, không đóng gói lại
        ↓
    Đúng "lift-and-shift to EXPEDITE the process"

Và thời gian ngừng rất ngắn:

Sao chép liên tục chạy nền nhiều ngày
    → tới lúc cutover, chênh lệch chỉ vài phút
        ↓
    Thời gian ngừng tính bằng phút

Cài agent:

sudo python3 aws-replication-installer-init.py   --region ap-northeast-1   --aws-access-key-id <key> --aws-secret-access-key <secret> --no-prompt

Và giai đoạn kiểm thử là bước không được bỏ qua:

Test instance chạy TÁCH BIỆT
    → subnet và security group riêng
    → nguồn không bị ảnh hưởng
        ↓
    Phát hiện vấn đề về driver, IP cứng, giấy phép
      TRƯỚC khi cutover thật

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

  • **A. Dùng AWS Server Migration Service (AWS SMS) tự động hoá việc di chuyển máy ảo — đây là phương án gần nhất và từng là công cụ đúng, nhưng AWS SMS đã ngừng cung cấp: AWS thay nó bằng Application Migration Service (MGN) từ 2022, và khuyến nghị mọi khách hàng chuyển sang MGN.
  • **E. Dùng AWS App Runner container hoá tải trước khi di chuyển — trái ngược với lift-and-shift: container hoá là tái cấu trúc, tốn nhiều thời gian, đi ngược yêu cầu đẩy nhanh tiến độ.
  • **F. Cài Systems Manager Agent để quản lý vận hành trong lúc di chuyển — hữu ích nhưng không phải bước di chuyển: SSM Agent giúp quản lý máy sau khi đã lên AWS, nó không tham gia vào quá trình sao chép.

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

Phương án A nhắc tới AWS Server Migration Service — dịch vụ đã ngừng.

AWS SMS ngừng nhận khách hàng mới từ 2022
    → thay bằng AWS Application Migration Service (MGN)
        ↓
    MGN dựa trên công nghệ CloudEndure, sao chép mức khối
    → nhanh hơn và ít gián đoạn hơn SMS

Đây là loại phương án "từng đúng" mà đề thi hay giữ lại — nhận ra tên dịch vụ đã lỗi thời là một phần của việc trả lời đúng.

Ghi nhớ

Các công cụ di chuyển của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | AWS Application Migration Service (MGN) | lift-and-shift MÁY CHỦ, mức khối | | AWS Database Migration Service (DMS) | di chuyển DATABASE, có CDC | | AWS DataSync | di chuyển TỆP | | AWS Migration Hub | theo dõi tiến độ tập trung | | Application Discovery Service | khảo sát môi trường nguồn |

Sáu chiến lược di chuyển (6 R): | Chiến lược | Nghĩa | |---|---| | Rehost | lift-and-shift, không sửa gì ← câu này | | Replatform | sửa nhẹ | | Refactor | viết lại cho đám mây | | Repurchase | chuyển sang SaaS | | Retire | bỏ hẳn | | Retain | giữ tại chỗ |

Rehost nhanh nhất — đúng với yêu cầu đẩy nhanh tiến độ.

Ba giai đoạn của MGN: | Giai đoạn | Chi tiết | |---|---| | Replication | agent sao chép liên tục sang staging area | | Test | khởi động instance kiểm thử, nguồn vẫn chạy | | Cutover | chuyển sang thật, dừng nguồn |

Ba đặc điểm của MGN: | Đặc điểm | Chi tiết | |---|---| | Sao chép mức KHỐI, liên tục | | | Hỗ trợ Windows và nhiều bản Linux | | | MIỄN PHÍ 90 ngày mỗi máy chủ | chỉ trả phí tài nguyên AWS |

Ba thành phần trong tài khoản AWS: | Thành phần | Việc | |---|---| | Staging area subnet | chứa replication server và volume tạm | | Replication server | nhận dữ liệu từ agent | | Launch template | cấu hình instance đích |

Ba việc cần chuẩn bị trước: | Việc | Chi tiết | |---|---| | Kết nối mạng từ nguồn tới AWS | cổng 443 và 1500 | | Khảo sát bằng Application Discovery Service | biết máy nào phụ thuộc máy nào | | Lập thứ tự di chuyển theo nhóm ứng dụng | |

Dòng giữa quan trọng:

Ứng dụng thường phụ thuộc lẫn nhau
    → di chuyển một máy mà để máy phụ thuộc lại
    → độ trễ tăng vọt hoặc kết nối đứt
        ↓
    Di chuyển theo NHÓM (application wave)

Ba lưu ý ở giai đoạn kiểm thử: | Lưu ý | Chi tiết | |---|---| | Dùng subnet và security group RIÊNG | | | Kiểm tra IP cứng trong cấu hình | rất hay gặp | | Kiểm tra giấy phép phần mềm | |

Ba lưu ý khi cutover: | Lưu ý | Chi tiết | |---|---| | Chọn giờ thấp điểm | | | Xác nhận độ trễ sao chép gần 0 | | | Giữ nguồn vài ngày để quay lại được | |

Ba việc cần làm sau cutover: | Việc | Chi tiết | |---|---| | Gỡ agent khỏi máy nguồn | | | Dọn staging area | volume tạm tính phí | | Tối ưu kích thước instance | Compute Optimizer |

Dòng cuối hay bị bỏ quên:

MGN tạo instance giống hệt máy ảo nguồn
    → máy ảo tại chỗ thường được cấp thừa
        ↓
    Chạy Compute Optimizer sau 2 tuần và thu nhỏ
    → đây là nơi phần lớn khoản tiết kiệm nằm

Ba lưu ý về chi phí trong lúc di chuyển: | Khoản | Chi tiết | |---|---| | MGN miễn phí 90 ngày mỗi máy | | | Replication server và volume staging tính phí | | | Test instance tính phí như thường | tắt sau kiểm thử |

Và một lời khuyên: hãy chạy giai đoạn kiểm thử nhiều lần chứ không chỉ một. Test instance không ảnh hưởng gì tới nguồn và huỷ đi tạo lại tuỳ ý — mỗi vòng phát hiện thêm một vấn đề, và với ứng dụng cũ thì danh sách đó thường dài hơn dự kiến ban đầu.

Câu 828 AWS Application Integration

An eCommerce application consists of three tiers. The web tier includes EC2 instances behind an Application Load balancer, the middle tier uses EC2 instances and an Amazon SQS queue to process orders, and the database tier consists of an Auto Scaling DynamoDB table. During busy periods customers have complained about delays in the processing of orders. A Solutions Architect has been tasked with reducing processing times.

Which action will be MOST effective in accomplishing this requirement?

  1. A

    Replace the Amazon SQS queue with Amazon Kinesis Data Firehose.
  2. B

    Use Amazon EC2 Auto Scaling to scale out the middle tier instances based on the SQS queue depth.
  3. C

    Add an Amazon CloudFront distribution with a custom origin to cache the responses for the web tier.
  4. D

    Use Amazon DynamoDB Accelerator (DAX) in front of the DynamoDB backend tier.
Xem giải thích

Đáp án

B — Dùng EC2 Auto Scaling mở rộng tầng giữa dựa trên ĐỘ SÂU hàng đợi SQS.

Vì sao đúng

Đề nêu vấn đề rõ: đơn hàng xử lý chậm trong giờ cao điểm, và kiến trúc đã có SQS.

Kiến trúc hiện tại:
    Web tier (ALB + EC2) → SQS → Middle tier (EC2) → DynamoDB
        ↓
    Đã tách rời đúng cách
    → chỉ THIẾU cơ chế thêm máy khi tồn đọng tăng

Và độ sâu hàng đợi là metric đúng:

Co giãn theo CPU:
    → CPU chạm trần rồi mới thêm máy
    → tồn đọng đã lớn, khách đã chờ lâu

Co giãn theo ApproximateNumberOfMessagesVisible:
    → phản ánh trực tiếp LƯỢNG VIỆC CHƯA LÀM
    → thêm máy trước khi CPU bão hoà

Cấu hình:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-xu-ly-don   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 20,
    "CustomizedMetricSpecification": {
      "MetricName":"ApproximateNumberOfMessagesVisible",
      "Namespace":"AWS/SQS","Statistic":"Average",
      "Dimensions":[{"Name":"QueueName","Value":"hang-doi-don-hang"}]}}'

Và metric tốt hơn nữa là "tồn đọng trên mỗi instance":

Backlog per instance = số thông điệp ÷ số instance
        ↓
Mục tiêu = (thời gian chờ chấp nhận được) ÷ (thời gian xử lý mỗi đơn)

Chấp nhận chờ 5 phút, mỗi đơn 15 giây
    → 300 ÷ 15 = 20 đơn mỗi instance

Đây là công thức AWS khuyến nghị chính thức — nó tự thích ứng khi số instance đổi.

Và vì sao ba tầng kia không phải nút thắt: | Tầng | Trạng thái | |---|---| | Web tier | ALB + ASG, không phàn nàn về đây | | SQS | thông lượng gần như vô hạn, không bao giờ nghẽn | | DynamoDB | đã có auto scaling | | Middle tier | ← nút thắt duy nhất |

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

  • **D. Dùng DynamoDB Accelerator (DAX) trước tầng database — đây là phương án gần nhất vì DAX thật sự tăng tốc DynamoDB, nhưng nó giải quyết vấn đề ĐỌC trong khi xử lý đơn hàng chủ yếu là GHI. Và đề nói DynamoDB đã có auto scaling, tức là không phải nút thắt.
  • **A. Thay SQS bằng Kinesis Data Firehose — Firehose không phải hàng đợi công việc: nó đẩy dữ liệu vào S3, Redshift hoặc OpenSearch, không cho EC2 lấy việc ra xử lý.
  • **C. Thêm CloudFront đệm phản hồi cho web tier — sai tầng: vấn đề nằm ở tầng xử lý đơn, không phải ở việc phục vụ trang web. Và phản hồi đặt hàng không đệm được.

Ghi nhớ

Ba metric của SQS dùng để co giãn — bảng phải thuộc: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi ← câu này | | ApproximateAgeOfOldestMessage | việc chờ lâu nhất — chỉ báo trải nghiệm tốt nhất | | ApproximateNumberOfMessagesNotVisible | đang được xử lý |

Metric thứ hai đáng dùng làm cảnh báo:

Số thông điệp lớn mà xử lý nhanh → vẫn ổn
Thông điệp cũ nhất chờ 30 phút → LUÔN là vấn đề

Năm loại scaling policy: | Loại | Khi nào | |---|---| | Target tracking | đơn giản nhất, giữ metric ở mức mục tiêu | | Step scaling | kiểm soát chi tiết | | Simple scaling | cũ, chậm vì cooldown | | Scheduled scaling | tải biết trước theo giờ | | Predictive scaling | tải có chu kỳ |

Từ khoá nhận diện:

"queue depth grows", "processing falls behind" → target tracking theo metric SQS "known peak hours" → scheduled scaling

Ba cấu hình ASG quan trọng: | Cấu hình | Chi tiết | |---|---| | EstimatedInstanceWarmup | bỏ qua máy mới khi tính metric | | MaxSize đủ lớn | chạm trần thì không mở rộng thêm | | Instance scale-in protection | không tắt máy đang bận |

Instance scale-in protection quan trọng với worker:

aws autoscaling set-instance-protection   --auto-scaling-group-name asg-xu-ly-don   --instance-ids i-0abc --protected-from-scale-in

Máy đang xử lý đơn hàng dài
    → ASG chọn nó để thu hẹp
    → đơn hàng bị bỏ dở
        ↓
    Bật bảo vệ khi bắt đầu xử lý, gỡ khi xong

Ba thông số SQS phải đặt đúng: | Thông số | Chi tiết | |---|---| | Visibility timeout ≥ thời gian xử lý dài nhất | | | Long polling (ReceiveMessageWaitTimeSeconds = 20) | giảm chi phí API | | DLQ với maxReceiveCount 3–5 | |

Ba yêu cầu với consumer: | Yêu cầu | Chi tiết | |---|---| | IDEMPOTENT | SQS Standard giao ít nhất một lần | | Chỉ xoá SAU KHI xử lý xong | | | Lifecycle hook để hoàn tất việc trước khi tắt | |

Lifecycle hook bảo vệ công việc đang dở:

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

Ba lựa chọn thay thế cho ASG: | Lựa chọn | Đặc điểm | |---|---| | Lambda đọc từ SQS | tự co giãn, giới hạn 15 phút | | AWS Batch | tự quản hàng đợi và năng lực | | ECS/Fargate co giãn theo SQS | container |

Lambda đáng cân nhắc nếu xử lý ngắn:

aws lambda create-event-source-mapping   --function-name xu-ly-don --event-source-arn <arn-sqs>   --batch-size 10 --scaling-config MaximumConcurrency=200

Lambda tự co giãn theo độ sâu hàng đợi
    → không phải cấu hình scaling policy nào

Ba cách giảm chi phí: | Cách | Tiết kiệm | |---|---| | Spot cho tầng xử lý | tới 90% — việc trong SQS không mất | | Graviton | ~20% | | Kích thước instance đúng nhu cầu | |

Spot rất phù hợp với worker đọc SQS:

Máy bị thu hồi giữa lúc xử lý
    → thông điệp quay lại hàng đợi
    → máy khác nhận và làm lại
        ↓
    Không mất đơn hàng nào

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | trải nghiệm khách hàng | | GroupInServiceInstances | số máy phục vụ | | Số thông điệp trong DLQ | có lỗi |

Ba lưu ý về DynamoDB trong kiến trúc này: | Lưu ý | Chi tiết | |---|---| | Auto scaling có độ trễ vài phút | | | On-demand phản ứng tức thì | đắt hơn khi tải ổn định | | Theo dõi ThrottledRequests | |

Và một lời khuyên: hãy dùng công thức "tồn đọng trên mỗi instance" thay vì một ngưỡng cố định. Mục tiêu "giữ hàng đợi dưới 100 thông điệp" hành xử rất khác khi bạn có 2 máy so với 40 máy — còn công thức chia cho số instance tự thích ứng ở mọi quy mô.

Câu 829 AWS Database

A company runs an application that uses an Amazon RDS PostgreSQL database. The database is currently not encrypted. A Solutions Architect has been instructed that due to new compliance requirements all existing and new data in the database must be encrypted. The database experiences high volumes of changes and no data can be lost.

How can the Solutions Architect enable encryption for the database without incurring any data loss?

  1. A

    Update the RDS DB to Multi-AZ mode and enable encryption for the standby replica. Perform a failover to the standby instance and then delete the unencrypted RDS DB instance.
  2. B

    Create an RDS read replica and specify an encryption key. Promote the encrypted read replica to primary. Update the application to point to the new RDS DB endpoint.
  3. C

    Create a snapshot of the existing RDS DB instance. Create an encrypted copy of the snapshot. Create a new RDS DB instance from the encrypted snapshot and update the application. Use AWS DMS to synchronize data between the source and destination RDS DBs.
  4. D

    Create a snapshot of the existing RDS DB instance. Create an encrypted copy of the snapshot. Create a new RDS DB instance from the encrypted snapshot. Configure the application to use the new DB endpoint.
Xem giải thích

Đáp án

C — Chụp snapshot, tạo bản sao snapshot CÓ MÃ HOÁ, tạo instance mới từ snapshot đó, và dùng AWS DMS đồng bộ dữ liệu giữa database nguồn và đích.

Vì sao đúng

Đề nêu hai ràng buộc, và chỉ phương án C thoả cả hai: | Ràng buộc | Cơ chế | |---|---| | Bật mã hoá cho database đang chạy | snapshot → copy mã hoá → restore | | KHÔNG được mất dữ liệu, tải ghi rất cao | DMS đồng bộ phần chênh lệch |

Vì sao không bật mã hoá trực tiếp được:

RDS chỉ bật mã hoá at rest LÚC TẠO instance
    → KHÔNG bật được cho instance đang chạy
        ↓
    Quy trình bắt buộc:
        snapshot → copy có mã hoá → restore thành instance MỚI

Và vì sao cần DMS:

Snapshot chụp tại thời điểm T
    → restore mất nhiều phút tới hàng giờ
        ↓
    Trong khoảng đó, nguồn NHẬN THÊM rất nhiều thay đổi
    → chuyển thẳng sang instance mới = MẤT toàn bộ phần đó
        ↓
    DMS ở chế độ CDC bắt phần chênh lệch

Quy trình đầy đủ:

# ① Chụp snapshot
aws rds create-db-snapshot --db-instance-identifier db-cu   --db-snapshot-identifier snap-cu

# ② Sao chép CÓ mã hoá
aws rds copy-db-snapshot   --source-db-snapshot-identifier snap-cu   --target-db-snapshot-identifier snap-ma-hoa   --kms-key-id <arn-khoa>

# ③ Khôi phục thành instance mới
aws rds restore-db-instance-from-db-snapshot   --db-instance-identifier db-moi --db-snapshot-identifier snap-ma-hoa

# ④ DMS đồng bộ phần chênh lệch
aws dms create-replication-task   --replication-task-identifier dong-bo   --source-endpoint-arn <arn-db-cu> --target-endpoint-arn <arn-db-moi>   --replication-instance-arn <arn-instance>   --migration-type cdc   --table-mappings file://anh-xa.json

--migration-type cdc chỉ bắt thay đổi — không tải lại toàn bộ vì snapshot đã có dữ liệu gốc.

Và cắt chuyển khi độ trễ gần 0:

Theo dõi CDCLatencyTarget
    → gần 0 → dừng ghi ở nguồn vài giây
    → đổi chuỗi kết nối sang instance mới
        ↓
    Thời gian ngừng tính bằng giây

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

  • **D. Snapshot → copy mã hoá → instance mới, rồi đổi endpoint của ứng dụng — đây là phương án gần nhất và là quy trình mã hoá đúng, nhưng nó MẤT mọi thay đổi phát sinh trong lúc restore: đề nói rõ database có "high volumes of changes" và "no data can be lost". Thiếu bước đồng bộ là thiếu điều kiện quan trọng nhất.
  • **B. Tạo read replica có mã hoá rồi promote — không làm được: read replica của một instance chưa mã hoá cũng không mã hoá được. Mã hoá kế thừa từ instance nguồn.
  • **A. Chuyển sang Multi-AZ và bật mã hoá cho standby rồi chuyển đổi — cũng không làm được: standby luôn có cùng trạng thái mã hoá với primary, không cấu hình riêng được.

Ghi nhớ

Ba nguyên tắc về mã hoá RDS — bảng phải thuộc: | Nguyên tắc | Chi tiết | |---|---| | Chỉ bật được LÚC TẠO instance | không bật sau | | Snapshot và replica KẾ THỪA trạng thái mã hoá | | | KHÔNG gỡ mã hoá được | một chiều |

Dòng giữa giải thích vì sao phương án A và B sai.

Quy trình mã hoá database đang chạy:

① Snapshot
② Copy snapshot VỚI --kms-key-id
③ Restore thành instance MỚI
④ Đồng bộ phần chênh lệch (DMS)
⑤ Cắt chuyển

Ba loại tác vụ của DMS: | Loại | Việc | |---|---| | full-load | dữ liệu hiện có | | cdc | chỉ thay đổi ← dùng ở đây | | full-load-and-cdc | cả hai |

Ba yêu cầu để CDC hoạt động với PostgreSQL: | Yêu cầu | Chi tiết | |---|---| | wal_level = logical | | | max_replication_slots đủ lớn | | | User DMS có quyền replication | |

ALTER SYSTEM SET wal_level = logical;
-- cần khởi động lại instance

Ba lưu ý về sao chép snapshot có mã hoá: | Lưu ý | Chi tiết | |---|---| | Khoá KMS phải ở CÙNG Region với snapshot đích | | | Sao chép xuyên Region cần khoá của Region đích | | | Snapshot đã mã hoá không copy thành không mã hoá | |

Ba lựa chọn khoá KMS: | Loại | Đặc điểm | |---|---| | aws/rds (AWS managed) | mặc định, miễn phí lưu khoá | | Customer managed key | kiểm soát policy, audit, xoay vòng | | — | với yêu cầu tuân thủ, chọn loại thứ hai |

Ba thứ được mã hoá khi bật: | Đối tượng | Mã hoá | |---|---| | Dữ liệu at rest | ✅ | | Automated backup và snapshot | ✅ | | Read replica | ✅ | | Log | ✅ |

Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | Cần replication instance | hoặc DMS Serverless | | Bật validation để so dữ liệu | | | KHÔNG chuyển index, trigger, sequence | tạo riêng |

Bật validation:

aws dms create-replication-task ...   --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}'

Ba metric của DMS cần theo dõi: | Metric | Ý nghĩa | |---|---| | CDCLatencySource | độ trễ đọc từ nguồn | | CDCLatencyTarget | độ trễ ghi vào đích — quyết định lúc cắt chuyển | | CDCIncomingChanges | |

Ba lựa chọn thay thế cho DMS trong bước đồng bộ: | Lựa chọn | Đặc điểm | |---|---| | DMS CDC | ← câu này, được quản lý | | Logical replication của PostgreSQL | tự cấu hình | | Chấp nhận ngừng và không đồng bộ | mất dữ liệu |

Logical replication cũng dùng được:

-- Ở nguồn
CREATE PUBLICATION pub_all FOR ALL TABLES;
-- Ở đích
CREATE SUBSCRIPTION sub_all
  CONNECTION 'host=db-cu ...' PUBLICATION pub_all;

Nhưng DMS ít công cấu hình hơn và có validation sẵn.

Ba lưu ý khi cắt chuyển: | Lưu ý | Chi tiết | |---|---| | Xác nhận CDCLatencyTarget gần 0 | | | Dừng ghi ở nguồn vài giây | | | Đổi chuỗi kết nối hoặc Route 53 CNAME | |

Dùng Route 53 CNAME giúp cắt chuyển nhanh:

Ứng dụng trỏ tới db.noibo.vidu.com (CNAME)
    → đổi CNAME sang endpoint mới
        ↓
    Không phải triển khai lại ứng dụng

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Chạy song song hai instance một thời gian | | | DMS replication instance theo giờ | | | Mã hoá KMS không tính phí thêm cho RDS | chỉ phí lời gọi KMS |

Ba việc cần kiểm tra sau khi chuyển: | Việc | Chi tiết | |---|---| | Xác nhận StorageEncrypted = true | | | Đếm số dòng từng bảng | | | Kiểm tra index và ràng buộc đầy đủ | |

aws rds describe-db-instances --db-instance-identifier db-moi   --query 'DBInstances[].{MaHoa:StorageEncrypted,Khoa:KmsKeyId}'

Và một lời khuyên: hãy dùng Route 53 CNAME cho endpoint database ngay từ bây giờ, kể cả khi chưa cần di chuyển. Nó biến bước cắt chuyển từ "triển khai lại toàn bộ ứng dụng" thành "đổi một bản ghi DNS" — và đó là khác biệt giữa vài giây ngừng và vài chục phút.

Câu 830 AWS Application Integration

A fintech company is modernizing its payments processing system to adopt a serverless microservices architecture. The company wants to decouple its services and implement an event-driven architecture to support a publish/subscribe (pub/sub) model. The system needs to notify multiple downstream services when payment events occur, ensuring scalability and low operational overhead.

Which solution will meet these requirements MOST cost-effectively?

  1. A

    Configure an Amazon EventBridge rule to capture payment events and route them to multiple AWS Lambda functions that handle downstream processing.
  2. B

    Configure an Amazon SNS topic to receive payment events from an AWS Lambda function. Set up multiple subscribers, such as Lambda functions, to process the events.
  3. C

    Use Amazon MQ as a message broker to enable publish/subscribe communication between the payment microservices and the downstream services.
  4. D

    Use Amazon Kinesis Data Firehose to deliver payment events to multiple S3 buckets. Configure downstream services to poll the buckets for event processing.
Xem giải thích

Đáp án

B — Dùng Amazon SNS topic nhận sự kiện thanh toán từ Lambda, đăng ký nhiều subscriber (Lambda) để xử lý.

Vì sao đúng

Đề nêu ba yêu cầu, và SNS đáp ứng cả ba với chi phí thấp nhất: | Yêu cầu | Cơ chế | |---|---| | Mô hình publish/subscribe | SNS là dịch vụ pub/sub thuần tuý | | Thông báo NHIỀU dịch vụ xuôi dòng | fan-out tới nhiều subscriber | | Tiết kiệm chi phí nhất | ~0,50 USD mỗi triệu request |

Cơ chế fan-out:

Lambda xử lý thanh toán → publish MỘT lần vào SNS topic
        ↓
SNS gửi tới MỌI subscriber:
    ├─→ Lambda ghi sổ kế toán
    ├─→ Lambda gửi email xác nhận
    ├─→ Lambda cập nhật kho
    └─→ SQS queue cho hệ thống chậm hơn
        ↓
    Publisher KHÔNG cần biết có bao nhiêu subscriber

Triển khai:

aws sns create-topic --name su-kien-thanh-toan

aws sns subscribe --topic-arn <arn-topic>   --protocol lambda --notification-endpoint <arn-lambda-ke-toan>

aws sns subscribe --topic-arn <arn-topic>   --protocol lambda --notification-endpoint <arn-lambda-email>

Và message filtering giảm xử lý thừa:

aws sns set-subscription-attributes   --subscription-arn <arn-sub>   --attribute-name FilterPolicy   --attribute-value '{"loai_su_kien":["thanh_toan_thanh_cong"]}'

Subscriber chỉ nhận sự kiện khớp bộ lọc
    → không phải viết logic bỏ qua trong Lambda
        ↓
    Tiết kiệm cả tiền lẫn độ phức tạp

Và mẫu SNS + SQS đáng biết:

SNS topic
    ├─→ Lambda (xử lý nhanh)
    └─→ SQS queue → Lambda (xử lý chậm, cần đệm)
        ↓
    SQS giữ thông điệp nếu subscriber tạm hỏng
    → SNS một mình KHÔNG giữ lại

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

  • **A. Dùng EventBridge rule bắt sự kiện thanh toán rồi định tuyến tới nhiều Lambda — đây là phương án gần nhất và hoạt động hoàn toàn tốt, nhưng nó đắt hơn cho mô hình pub/sub thuần: EventBridge tính ~1,00 USD mỗi triệu sự kiện so với ~0,50 USD của SNS, và các tính năng mạnh của nó (schema registry, lọc theo nội dung phức tạp, tích hợp SaaS) không cần thiết ở đây. Đề hỏi "MOST cost-effectively".
  • **C. Dùng Amazon MQ làm message broker — tốn nhất và nhiều công vận hành nhất: phải chọn cỡ broker, trả phí theo giờ dù không có sự kiện, và đề nói rõ muốn kiến trúc serverless.
  • **D. Dùng Firehose đẩy vào nhiều S3 bucket rồi cho dịch vụ polling — không phải event-driven: polling thêm độ trễ và tốn tài nguyên, đi ngược yêu cầu kiến trúc hướng sự kiện.

Ghi nhớ

SNS và EventBridge — bảng phải thuộc: | | Amazon SNS | Amazon EventBridge | |---|---|---| | Mô hình | pub/sub đơn giản | bus sự kiện có định tuyến | | Lọc | theo thuộc tính thông điệp | theo NỘI DUNG sự kiện, mẫu phong phú | | Giá | ~0,50 USD/triệu | ~1,00 USD/triệu | | Số đích mỗi quy tắc | mỗi subscriber riêng | tới 5 target mỗi rule | | Tích hợp SaaS bên thứ ba | ❌ | ✅ | | Schema registry, archive, replay | ❌ | ✅ | | Độ trễ | thấp hơn | vừa |

Quy tắc chọn:

Fan-out đơn giản, cần rẻ và nhanh → SNS Định tuyến phức tạp, sự kiện từ dịch vụ AWS hoặc SaaS, cần phát lại → EventBridge

Ba giao thức subscriber của SNS: | Giao thức | Chi tiết | |---|---| | Lambda | ← câu này | | SQS | để đệm và giữ lại | | HTTP/HTTPS endpoint | | | Email, SMS, mobile push | cho thông báo người dùng | | Kinesis Data Firehose | lưu trữ |

Hai loại SNS topic: | Loại | Đặc điểm | |---|---| | Standard | thông lượng cao, không đảm bảo thứ tự | | FIFO | giữ thứ tự, đúng một lần, chỉ gửi tới SQS FIFO và Lambda |

Với thanh toán cần thứ tự, cân nhắc SNS FIFO:

SNS FIFO topic → SQS FIFO queue
    → đảm bảo thứ tự trong message group
        ↓
    Nhưng thông lượng thấp hơn Standard

⚠ Ba hạn chế của SNS: | Hạn chế | Chi tiết | |---|---| | KHÔNG giữ thông điệp | subscriber lỗi thì mất | | Kích thước thông điệp 256 KB | | | Thử lại theo chính sách, rồi bỏ | |

Dòng đầu là lý do nên chèn SQS:

Lambda subscriber bị throttle
    → SNS thử lại theo chính sách rồi BỎ
        ↓
    SNS → SQS → Lambda: thông điệp nằm trong hàng đợi
    → không mất

Ba cách bảo vệ khỏi mất thông điệp: | Cách | Chi tiết | |---|---| | SNS → SQS → consumer | hàng đợi giữ lại | | Dead-letter queue cho subscription | | | Delivery retry policy | |

Cấu hình DLQ cho subscription:

aws sns set-subscription-attributes   --subscription-arn <arn-sub>   --attribute-name RedrivePolicy   --attribute-value '{"deadLetterTargetArn":"<arn-sqs-dlq>"}'

Ba lưu ý về message filtering: | Lưu ý | Chi tiết | |---|---| | Lọc theo MessageAttributes | mặc định | | Lọc theo BODY được | đặt FilterPolicyScope: MessageBody | | Miễn phí | không tính phí thêm |

Lọc theo body đáng biết:

aws sns set-subscription-attributes --subscription-arn <arn>   --attribute-name FilterPolicyScope --attribute-value MessageBody

Ba mẫu kiến trúc hướng sự kiện: | Mẫu | Dịch vụ | |---|---| | Fan-out | SNS tới nhiều subscriber | | Điểm-tới-điểm có đệm | SQS | | Định tuyến theo nội dung | EventBridge |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest bằng KMS | quan trọng với dữ liệu thanh toán | | Topic policy giới hạn ai publish | | | VPC endpoint cho SNS | truy cập riêng tư |

aws sns set-topic-attributes --topic-arn <arn>   --attribute-name KmsMasterKeyId --attribute-value <arn-khoa>

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | SNS request | ~0,50 USD mỗi triệu | | Giao tới Lambda và SQS | miễn phí | | Giao tới HTTP endpoint | ~0,60 USD mỗi triệu |

Ba lưu ý khi thêm subscriber mới: | Lưu ý | Chi tiết | |---|---| | Publisher KHÔNG phải sửa gì | đó là giá trị của pub/sub | | Dùng filter policy để không nhận sự kiện thừa | | | Thêm DLQ cho mỗi subscription | |

Và một lời khuyên: hãy chèn SQS giữa SNS và các Lambda xử lý quan trọng. SNS không giữ thông điệp, nên một đợt throttle của Lambda có thể làm mất sự kiện thanh toán — và với dữ liệu tài chính, đó là loại mất mát không có cách nào phát hiện sau này.