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

Tìm thấy 2194 câu.

Câu 931 AWS Compute

A company’s staff connect from home office locations to administer applications using bastion hosts in a single AWS Region. The company requires a resilient bastion host architecture that requires minimal ongoing operational overhead.

How can a Solutions Architect best meet these requirements?

  1. A

    Create a Network Load Balancer backed by an Auto Scaling group with instances in multiple AWS Regions.
  2. B

    Create a Network Load Balancer backed by an Auto Scaling group with instances in multiple Availability Zones.
  3. C

    Create a Network Load Balancer backed by Reserved Instances in a cluster placement group.
  4. D

    Create a Network Load Balancer backed by the existing servers in different Availability Zones.
Xem giải thích

Đáp án

B — Tạo một Network Load Balancer phía trước một Auto Scaling group có instance ở nhiều Availability Zone.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Bastion host trong MỘT vùng | đa AZ là đủ, không cần đa vùng | | Kiến trúc CÓ KHẢ NĂNG PHỤC HỒI | mất một AZ vẫn còn bastion | | Ít công vận hành liên tục nhất | ASG tự thay máy hỏng |

Vì sao NLB chứ không phải ALB:

Bastion host phục vụ SSH (cổng 22) hoặc RDP (3389)
    → đó là giao thức TCP, không phải HTTP
        ↓
    ALB chỉ xử lý HTTP/HTTPS (tầng 7)
    NLB xử lý TCP/UDP (tầng 4)
    → NLB là lựa chọn đúng

Ba việc ASG mang lại: | Việc | Chi tiết | |---|---| | Máy hỏng được thay tự động | | | Trải qua nhiều AZ | | | Giữ số lượng mong muốn không cần can thiệp | |

Cấu hình:

aws elbv2 create-load-balancer --name nlb-bastion --type network   --scheme internet-facing --subnets subnet-a subnet-b subnet-c

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-bastion   --launch-template LaunchTemplateName=mau-bastion,Version='$Latest'   --min-size 2 --max-size 4 --desired-capacity 2   --vpc-zone-identifier "subnet-a,subnet-b,subnet-c"   --target-group-arns <arn-tg> --health-check-type ELB

⚠ Và một lưu ý quan trọng về NLB với SSH:

NLB giữ nguyên IP NGUỒN của client (mặc định với target kiểu instance)
    → security group của bastion vẫn lọc được theo IP văn phòng
        ↓
    Khác với ALB vốn thay IP nguồn bằng IP của chính nó

Ba lợi ích về vận hành: | Lợi ích | Chi tiết | |---|---| | Một tên DNS cố định cho nhân viên | | | Máy bị thay không ảnh hưởng người dùng | | | NLB có thể gán Elastic IP tĩnh | dễ đưa vào allowlist |

Gán IP tĩnh cho NLB:

aws elbv2 create-load-balancer --name nlb-bastion --type network   --subnet-mappings     SubnetId=subnet-a,AllocationId=eipalloc-1     SubnetId=subnet-b,AllocationId=eipalloc-2

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

  • **A. NLB với ASG có instance ở nhiều VÙNG — đây là phương án gần nhất vì cũng dùng NLB và ASG, nhưng nó không khả thi và quá mức: một ASG không trải qua nhiều vùng được, một NLB cũng vậy. Và đề nói rõ nhân viên làm việc trong một vùng.
  • **D. NLB phía trước các máy chủ hiện có ở các AZ khác nhau — có dự phòng AZ, nhưng không tự phục hồi: máy hỏng thì phải có người dựng lại bằng tay. Đề đòi "minimal ongoing operational overhead".
  • **C. NLB với Reserved Instance trong cluster placement group — Reserved Instance chỉ là mô hình thanh toán, không liên quan tới khả năng phục hồi. Và cluster placement group đặt máy sát nhau trong một AZ, làm giảm dự phòng chứ không tăng.

Ghi nhớ về kiến trúc hiện đại

Đáp án B đúng cho câu hỏi này, nhưng đáng biết rằng AWS hiện khuyến nghị bỏ hẳn bastion host:

AWS Systems Manager Session Manager:

aws ssm start-session --target i-abc123
Lợi ích Chi tiết
KHÔNG cần bastion host nào
KHÔNG mở cổng 22 ra Internet
KHÔNG quản lý khoá SSH
Mọi phiên ghi vào CloudTrail và S3 
Session Manager kết nối qua SSM Agent (chiều RA)
    → instance không cần IP công khai
    → không cần inbound rule nào
        ↓
    Vừa an toàn hơn vừa ít việc hơn bastion

Ba yêu cầu để dùng Session Manager: | Yêu cầu | Chi tiết | |---|---| | SSM Agent cài trên máy | có sẵn trên AMI Amazon | | Instance profile với AmazonSSMManagedInstanceCore | | | VPC endpoint (ssm, ssmmessages, ec2messages) nếu subnet riêng tư | |

Nếu đề hỏi "cách an toàn nhất để truy cập instance", đáp án là Session Manager, không phải bastion.

Ghi nhớ

⚠ Ba loại Elastic Load Balancer — bảng phải thuộc: | Loại | Tầng | Giao thức | |---|---|---| | Application Load Balancer | 7 | HTTP, HTTPS, gRPC | | Network Load Balancer | 4 | TCP, UDP, TLS ← câu này | | Gateway Load Balancer | 3/4 | thiết bị bảo mật bên thứ ba |

Từ khoá nhận diện:

"SSH, RDP, TCP, UDP" → NLB "HTTP routing by path or host" → ALB "static IP address" → NLB (Elastic IP) "secure instance access without bastion" → Session Manager

Ba đặc điểm của NLB: | Đặc điểm | Chi tiết | |---|---| | Độ trễ rất thấp | xử lý ở tầng 4 | | Gán được Elastic IP tĩnh mỗi AZ | | | Giữ IP nguồn của client | với target kiểu instance |

⚠ Ba khác biệt về IP nguồn: | Load balancer | IP nguồn thấy ở target | |---|---| | ALB | IP của ALB (client IP nằm ở X-Forwarded-For) | | NLB, target kiểu instance | IP THẬT của client | | NLB, target kiểu IP | IP của NLB (trừ khi bật preserve) |

Ba lưu ý về cross-zone load balancing: | Load balancer | Mặc định | Phí | |---|---|---| | ALB | BẬT | miễn phí | | NLB | TẮT | có phí khi bật |

Vế thứ hai có thể gây phân bố lệch:

NLB không bật cross-zone
    → mỗi node NLB chỉ gửi tới target trong CÙNG AZ
    → AZ có ít target hơn sẽ nhận tải nặng hơn mỗi máy
        ↓
    Giữ số target cân bằng giữa các AZ,
    hoặc bật cross-zone và chấp nhận phí

Ba lưu ý về bastion nếu vẫn phải dùng: | Lưu ý | Chi tiết | |---|---| | Security group chỉ cho IP văn phòng vào cổng 22 | | | Dùng EC2 Instance Connect thay khoá tĩnh | | | Ghi log phiên đăng nhập | |

Ba lựa chọn thay thế bastion: | Lựa chọn | Đặc điểm | |---|---| | Session Manager | không cổng mở, có audit ← tốt nhất | | EC2 Instance Connect Endpoint | SSH riêng tư không cần bastion | | AWS Client VPN | truy cập cả mạng |

EC2 Instance Connect Endpoint cũng đáng biết:

aws ec2-instance-connect ssh --instance-id i-abc123   --connection-type eice

SSH thẳng vào instance ở subnet riêng tư
    → không có bastion, không có IP công khai

Ba lưu ý về health check của NLB: | Lưu ý | Chi tiết | |---|---| | Kiểm tra TCP hoặc HTTP | | | health-check-type ELB cho ASG | | | Grace period đủ cho khởi động | |

Và một lời khuyên: nếu bạn đang dựng bastion host mới hôm nay, hãy cân nhắc Session Manager trước. Kiến trúc bastion có tính phục hồi tốt vẫn là một nhóm máy chủ phải vá lỗi, phải giám sát và phải mở cổng ra Internet — trong khi giải pháp thay thế không có máy nào cả.

Câu 932 Chọn nhiều đáp án AWS Compute

A company wants to use Amazon Elastic Container Service (Amazon ECS) to run its containerized application in a hybrid environment. The company needs to ensure that the application can scale across both on-premises and AWS environments. It also requires a load balancer to handle HTTP traffic for the new containers that will run in the AWS Cloud.

Which combination of actions will meet these requirements? (Select TWO.)

  1. A

    Set up an ECS cluster that uses the Amazon EC2 launch type for the cloud application containers. Use Amazon ECS Anywhere with an AWS Fargate launch type for the on-premises application containers.
  2. B

    Set up an Application Load Balancer for cloud ECS services.
  3. C

    Set up an ECS cluster that uses the AWS Fargate launch type. Use Fargate for the cloud application containers and the on-premises application containers.
  4. D

    Set up an ECS cluster that uses the AWS Fargate launch type for the cloud application containers. Use an Amazon ECS Anywhere external launch type for the on-premises application containers.
  5. E

    Set up a Network Load Balancer for cloud ECS services.
Xem giải thích

Đáp án

B và D.

  • B — Dựng một Application Load Balancer cho các ECS service chạy trên đám mây
  • D — Dựng ECS cluster dùng Fargate cho container trên đám mây, và ECS Anywhere với launch type EXTERNAL cho container tại chỗ

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Chạy container ở CẢ tại chỗ VÀ trên AWS | ECS Anywhere quản lý cả hai từ một control plane | | Co giãn ở cả hai môi trường | Fargate co giãn trên mây, ECS Anywhere trên máy tại chỗ | | Load balancer xử lý lưu lượng HTTP | ALB — tầng 7, đúng cho HTTP |

ECS Anywhere hoạt động thế nào:

Máy chủ tại chỗ cài SSM Agent + ECS Agent
    → đăng ký vào ECS cluster như một "external instance"
        ↓
    Control plane của ECS trên AWS điều phối
    → nhưng container chạy trên phần cứng của bạn

Đăng ký máy tại chỗ:

aws ssm create-activation --iam-role ecsAnywhereRole   --registration-limit 10 --region ap-southeast-1

# Trên máy tại chỗ:
curl -o ecs-anywhere-install.sh https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh
sudo bash ecs-anywhere-install.sh   --region ap-southeast-1 --cluster cum-lai   --activation-id <id> --activation-code <code>

Chạy task tại chỗ với launch type EXTERNAL:

aws ecs create-service --cluster cum-lai --service-name dich-vu-tai-cho   --task-definition tac-vu-tai-cho:1 --desired-count 3   --launch-type EXTERNAL

Và trên đám mây dùng Fargate:

aws ecs create-service --cluster cum-lai --service-name dich-vu-may   --task-definition tac-vu-may:1 --desired-count 4 --launch-type FARGATE   --network-configuration 'awsvpcConfiguration={
    subnets=[subnet-a,subnet-b],securityGroups=[sg-app],assignPublicIp=DISABLED}'   --load-balancers targetGroupArn=<arn-tg>,containerName=web,containerPort=8080

⚠ Vì sao ALB chứ không phải NLB:

Đề nói rõ: "a load balancer to handle HTTP traffic"
    → HTTP là tầng 7
        ↓
    ALB: định tuyến theo path, host, header; hỗ trợ HTTP/2, gRPC
    NLB: tầng 4, không hiểu HTTP

Ba lợi ích của kiến trúc lai này: | Lợi ích | Chi tiết | |---|---| | Một control plane cho cả hai môi trường | | | Cùng task definition, cùng quy trình triển khai | | | Fargate lo phần đám mây không cần máy chủ | |

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

  • **A. ECS cluster dùng EC2 launch type cho đám mây, và ECS Anywhere với FARGATE launch type cho tại chỗ — đây là phương án gần nhất và nửa đầu chạy được, nhưng nửa sau mô tả một thứ không tồn tại: Fargate là hạ tầng serverless của AWS, không chạy trên máy chủ tại chỗ được. Launch type cho ECS Anywhere là EXTERNAL.
  • **C. ECS cluster dùng Fargate cho CẢ hai môi trường — cùng lỗi: Fargate không chạy tại chỗ. Đây là hiểu nhầm phổ biến nhất về ECS Anywhere.
  • **E. Dựng Network Load Balancer cho ECS service trên đám mây — NLB hoạt động ở tầng 4; đề nói rõ cần xử lý lưu lượng HTTP, nên ALB mới là lựa chọn đúng.

Ghi nhớ

⚠ Bốn launch type của ECS — bảng phải thuộc: | Launch type | Chạy ở đâu | |---|---| | FARGATE | hạ tầng serverless của AWS | | EC2 | EC2 trong tài khoản bạn | | EXTERNAL | máy chủ TẠI CHỖ (ECS Anywhere) ← câu này |

Từ khoá nhận diện:

"hybrid, on-premises + AWS containers" → ECS Anywhere, launch type EXTERNAL "Kubernetes hybrid" → EKS Anywhere hoặc EKS Hybrid Nodes "HTTP traffic" → ALB "TCP/UDP, static IP" → NLB

Ba yêu cầu của ECS Anywhere: | Yêu cầu | Chi tiết | |---|---| | SSM Agent và ECS Agent trên máy tại chỗ | | | Kết nối ra tới AWS | control plane nằm trên AWS | | IAM role qua Systems Manager activation | |

⚠ Ba hạn chế của ECS Anywhere: | Hạn chế | Chi tiết | |---|---| | KHÔNG hỗ trợ awsvpc network mode | dùng bridge hoặc host | | KHÔNG gắn được vào ELB của AWS | ELB không tới được máy tại chỗ | | Không dùng được Service Discovery kiểu VPC | |

Vế thứ hai giải thích cấu trúc của đáp án:

ALB chỉ phục vụ các task chạy trên đám mây
    → task tại chỗ phải dùng load balancer riêng của bạn
        ↓
    Đó là lý do phương án B nói rõ
    "for CLOUD ECS services"

Ba lợi ích của mô hình lai: | Lợi ích | Chi tiết | |---|---| | Một nơi quản lý, một quy trình triển khai | | | Tận dụng phần cứng đã đầu tư | | | Dữ liệu nhạy cảm có thể ở lại tại chỗ | |

Ba lựa chọn lai khác của AWS: | Lựa chọn | Việc | |---|---| | AWS Outposts | phần cứng AWS đặt tại trung tâm dữ liệu của bạn | | EKS Anywhere | Kubernetes tại chỗ | | ECS Anywhere | ← câu này |

⚠ Outposts khác ECS Anywhere ở điểm căn bản:

Outposts:      AWS gửi PHẦN CỨNG của AWS tới chỗ bạn
               → chạy được cả Fargate, EC2, RDS tại chỗ
ECS Anywhere:  chạy trên PHẦN CỨNG CỦA BẠN
               → chỉ điều phối container

Ba đặc điểm của Fargate: | Đặc điểm | Chi tiết | |---|---| | Không quản lý máy chủ | | | Mỗi task một ENI (awsvpc mode) | | | Trả tiền theo vCPU và RAM của task | |

Ba cách co giãn ECS: | Cách | Áp cho | |---|---| | Service Auto Scaling | số TASK — cả Fargate và EC2 | | Cluster Auto Scaling | số EC2 instance (không áp cho Fargate) | | Co giãn thủ công tại chỗ | ECS Anywhere |

⚠ Co giãn tại chỗ có giới hạn thật:

ECS Anywhere KHÔNG tự thêm máy chủ vật lý
    → chỉ co giãn số TASK trên số máy đã đăng ký
        ↓
    Hết năng lực tại chỗ là hết
    → đây là lý do phần tăng đột biến nên đẩy lên Fargate

Ba lưu ý về mạng cho ECS Anywhere: | Lưu ý | Chi tiết | |---|---| | Network mode bridge hoặc host | | | Cần đường ra tới ECS và SSM endpoint | | | Kéo ảnh từ ECR cần xác thực | |

Ba lưu ý về ALB với ECS: | Lưu ý | Chi tiết | |---|---| | Target group kiểu ip với Fargate | | | Health check trỏ đúng đường dẫn | | | Deregistration delay hợp lý | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | ECS Anywhere tính phí theo GIỜ mỗi instance ngoài | | | Fargate tính theo vCPU-giờ và GB-giờ | | | ALB tính theo giờ + LCU | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | aws ecs list-container-instances | máy tại chỗ đã đăng ký chưa | | Kiểm tra task chạy ở đúng launch type | | | Thử ALB tới task trên Fargate | |

aws ecs list-container-instances --cluster cum-lai   --filter "attribute:ecs.capability.external exists"

Và một lời khuyên: hãy coi phần tại chỗ là năng lực cố định và phần Fargate là năng lực co giãn. ECS Anywhere không thêm được máy chủ vật lý cho bạn, nên kiến trúc lai chạy tốt nhất khi tải nền chạy trên phần cứng đã có, còn mọi đợt tăng đột biến được đẩy lên đám mây.

Câu 933 AWS Management & Governance

A security officer requires that access to company financial reports is logged. The reports are stored in an Amazon S3 bucket. Additionally, any modifications to the log files must be detected.

Which actions should a solutions architect take?

  1. A

    Use S3 server access logging on the bucket that houses the reports with the read and write data events and the log file validation options enabled
  2. B

    Use AWS CloudTrail to create a new trail. Configure the trail to log read and write management events on the S3 bucket that houses the reports. Log these events to a new bucket, and enable log file validation
  3. C

    Use AWS CloudTrail to create a new trail. Configure the trail to log read and write data events on the S3 bucket that houses the reports. Log these events to a new bucket, and enable log file validation
  4. D

    Use S3 server access logging on the bucket that houses the reports with the read and write management events and log file validation options enabled
Xem giải thích

Đáp án

C — Dùng AWS CloudTrail tạo một trail mới, cấu hình ghi DATA EVENT (đọc và ghi) trên bucket chứa báo cáo, ghi vào một bucket mới và bật log file validation.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi cái quyết định một phần đáp án: | Yêu cầu | Cách đáp ứng | |---|---| | Ghi log việc TRUY CẬP các báo cáo | CloudTrail DATA EVENT | | Phát hiện mọi SỬA ĐỔI tệp log | log file validation |

⚠ Phân biệt management event và data event — đây là điểm cốt lõi: | Loại | Ghi lại | Ví dụ | |---|---|---| | Management event | thao tác trên chính TÀI NGUYÊN | CreateBucket, PutBucketPolicy, DeleteBucket | | Data event | thao tác trên DỮ LIỆU bên trong | GetObject, PutObject, DeleteObject |

Đề hỏi: ai TRUY CẬP các báo cáo
    → đó là GetObject → DATA EVENT
        ↓
    Management event KHÔNG ghi lại việc ai đọc một tệp
    → đây là lý do B sai còn C đúng

⚠ Data event KHÔNG được bật mặc định — phải khai rõ và có tính phí.

Cấu hình:

aws cloudtrail create-trail --name trail-bao-cao-tai-chinh   --s3-bucket-name kho-log-cloudtrail   --enable-log-file-validation   --is-multi-region-trail

aws cloudtrail put-event-selectors --trail-name trail-bao-cao-tai-chinh   --advanced-event-selectors '[{
    "Name":"Ghi log doc va ghi bao cao",
    "FieldSelectors":[
      {"Field":"eventCategory","Equals":["Data"]},
      {"Field":"resources.type","Equals":["AWS::S3::Object"]},
      {"Field":"resources.ARN","StartsWith":["arn:aws:s3:::kho-bao-cao-tai-chinh/"]}]}]'

aws cloudtrail start-logging --name trail-bao-cao-tai-chinh

Log file validation làm gì:

CloudTrail tạo thêm một tệp DIGEST mỗi giờ
    → chứa mã băm SHA-256 của từng tệp log
    → digest được KÝ bằng khoá riêng của AWS
        ↓
    Sửa một tệp log → mã băm không khớp → phát hiện được
    Xoá một tệp log → thiếu trong digest → phát hiện được
    Sửa cả digest → chữ ký không hợp lệ → phát hiện được

Kiểm chứng:

aws cloudtrail validate-logs   --trail-arn arn:aws:cloudtrail:ap-southeast-1:123456789012:trail/trail-bao-cao-tai-chinh   --start-time 2026-08-01T00:00:00Z

⚠ Và vì sao phải ghi vào MỘT BUCKET MỚI:

Ghi log vào chính bucket chứa báo cáo
    → mỗi lần CloudTrail ghi log lại sinh thêm một data event
    → vòng lặp sinh log vô tận, chi phí bùng nổ
        ↓
    Và người có quyền sửa báo cáo cũng sửa được log

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

  • **B. CloudTrail ghi MANAGEMENT event đọc/ghi trên bucket, bật log file validation — đây là phương án gần nhất và chỉ sai một từ, nhưng đó là từ quyết định: management event ghi lại thao tác trên cấu hình bucket (tạo, xoá, đổi policy), không ghi lại việc ai đọc hay tải một tệp báo cáo.
  • **A. Dùng S3 server access logging với "data event" và log file validation — nhầm tính năng: server access logging không có khái niệm data/management event và không có log file validation. Nó chỉ ghi log dạng văn bản, không có cơ chế phát hiện sửa đổi.
  • **D. S3 server access logging với "management event" và validation — cùng lỗi, và còn sai thêm loại sự kiện.

Ghi nhớ

⚠ CloudTrail và S3 Server Access Log — bảng phải thuộc: | | CloudTrail data event | S3 Server Access Log | |---|---|---| | Định dạng | JSON có cấu trúc | văn bản thuần | | Độ trễ | ~5 phút | vài giờ | | Log file validation | ✅ | ❌ | | Lọc và định tuyến | ✅ event selector | ❌ toàn bộ | | Tích hợp EventBridge | ✅ | ❌ | | Chi phí | tính phí data event | miễn phí (chỉ trả lưu trữ) |

Từ khoá nhận diện:

"log access to objects" + "detect log tampering" → CloudTrail data events + log file validation "who called which AWS API" → CloudTrail management events "free, detailed request logs for S3" → server access logging

Ba loại sự kiện của CloudTrail: | Loại | Mặc định | Phí | |---|---|---| | Management event | BẬT (90 ngày miễn phí trong Event history) | trail đầu tiên miễn phí | | Data event | TẮT | tính phí theo sự kiện | | Insights event | TẮT | tính phí |

Ba tài nguyên hỗ trợ data event: | Tài nguyên | Sự kiện | |---|---| | S3 object | GetObject, PutObject, DeleteObject | | Lambda function | Invoke | | DynamoDB item | GetItem, PutItem... |

Ba đặc điểm của log file validation: | Đặc điểm | Chi tiết | |---|---| | Tệp digest mỗi giờ | chứa băm SHA-256 | | Digest được ký số | | | Phát hiện sửa, xoá, chèn | |

Ba biện pháp bảo vệ bucket log: | Biện pháp | Chi tiết | |---|---| | Bucket RIÊNG, tài khoản riêng nếu được | | | Bật S3 Object Lock chế độ compliance | không ai xoá được | | Bật MFA Delete và versioning | |

Object Lock cho log tuân thủ:

aws s3api put-object-lock-configuration --bucket kho-log-cloudtrail   --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":2555}}}'

Chế độ COMPLIANCE: không ai xoá được trước hạn
    → kể cả tài khoản root
        ↓
    Kết hợp với log file validation là bảo vệ hai lớp

Ba lưu ý về chi phí data event: | Lưu ý | Chi tiết | |---|---| | Tính phí theo SỐ sự kiện | | | Bucket lưu lượng cao sinh chi phí lớn | | | Lọc theo tiền tố để giới hạn phạm vi | |

Lọc theo tiền tố là cách kiểm soát chi phí:

{"Field":"resources.ARN","StartsWith":["arn:aws:s3:::kho-bao-cao/tai-chinh/"]}

Chỉ ghi log thư mục nhạy cảm
    → không ghi mọi object trong bucket

Ba cách phân tích log CloudTrail: | Cách | Việc | |---|---| | Amazon Athena | truy vấn SQL trực tiếp | | CloudWatch Logs + Insights | cảnh báo gần thời gian thực | | Amazon Security Lake | gom và chuẩn hoá đa tài khoản |

Truy vấn ai đã đọc báo cáo:

SELECT eventtime, useridentity.arn, requestparameters
FROM cloudtrail_logs
WHERE eventname = 'GetObject'
  AND json_extract_scalar(requestparameters, '$.bucketName') = 'kho-bao-cao-tai-chinh'
ORDER BY eventtime DESC;

Ba lưu ý khi cấu hình trail: | Lưu ý | Chi tiết | |---|---| | --is-multi-region-trail | bắt cả hoạt động ở vùng khác | | Bật cho toàn tổ chức nếu dùng Organizations | | | Mã hoá log bằng KMS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải một tệp báo cáo, chờ ~5 phút, tìm trong log | | | Chạy validate-logs | | | Kiểm tra bucket log không ai xoá được | |

Và một lời khuyên: hãy để bucket log ở một tài khoản AWS riêng mà đội vận hành ứng dụng không có quyền ghi. Log file validation cho bạn biết log đã bị sửa, nhưng nó không ngăn được việc đó — còn một ranh giới tài khoản thì có.

Câu 934 AWS Database

A company runs a business-critical application in the us-east-1 Region. The application uses an Amazon Aurora MySQL database cluster which is 2 TB in size. A Solutions Architect needs to determine a disaster recovery strategy for failover to the us-west-2 Region. The strategy must provide a recovery time objective (RTO) of 10 minutes and a recovery point objective (RPO) of 5 minutes.

Which strategy will meet these requirements?

  1. A

    Create a cross-Region Aurora MySQL read replica in us-west-2 Region. Configure an Amazon EventBridge rule that invokes an AWS Lambda function that promotes the read replica in us-west-2 when failure is detected.
  2. B

    Recreate the database as an Aurora multi master cluster across the us-east-1 and us-west-2 Regions with multiple writers to allow read/write capabilities from all database instances.
  3. C

    Create a multi-Region Aurora MySQL DB cluster in us-east-1 and us-west-2. Use an Amazon Route 53 health check to monitor us-east-1 and fail over to us-west-2 upon failure.
  4. D

    Recreate the database as an Aurora global database with the primary DB cluster in us-east-1 and a secondary DB cluster in us-west-2. Use an Amazon EventBridge rule that invokes an AWS Lambda function to promote the DB cluster in us-west-2 when failure is detected.
Xem giải thích

Đáp án

D — Dựng lại CSDL thành Aurora global database với cụm chính ở us-east-1 và cụm phụ ở us-west-2, dùng EventBridge rule gọi Lambda để đôn cụm us-west-2 lên khi phát hiện sự cố.

Vì sao đúng

Đề nêu ba chỉ tiêu, và chỉ Aurora global database đạt được: | Chỉ tiêu | Cách đáp ứng | |---|---| | RTO 10 phút | promote cụm phụ thường dưới 1 phút | | RPO 5 phút | độ trễ sao chép thường DƯỚI 1 GIÂY | | Cụm Aurora MySQL 2 TB | global database sao chép ở tầng lưu trữ |

Aurora Global Database sao chép thế nào:

Sao chép ở TẦNG LƯU TRỮ, không qua binlog
    → độ trễ điển hình dưới 1 giây
    → gần như không ảnh hưởng hiệu năng cụm chính
        ↓
    RPO ~1 giây — dư sức đạt yêu cầu 5 phút

Chuyển sang global database:

aws rds create-global-cluster   --global-cluster-identifier cum-toan-cau   --source-db-cluster-identifier arn:aws:rds:us-east-1:...:cluster:cum-chinh

aws rds create-db-cluster --db-cluster-identifier cum-dr   --global-cluster-identifier cum-toan-cau   --engine aurora-mysql --region us-west-2

aws rds create-db-instance --db-instance-identifier dr-instance-1   --db-cluster-identifier cum-dr --db-instance-class db.r6g.2xlarge   --engine aurora-mysql --region us-west-2

Tự động hoá chuyển đổi:

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

def handler(event, context):
    rds.failover_global_cluster(
        GlobalClusterIdentifier='cum-toan-cau',
        TargetDbClusterIdentifier='arn:aws:rds:us-west-2:...:cluster:cum-dr')

⚠ Hai kiểu chuyển đổi — biết cả hai: | Kiểu | Khi nào | Mất dữ liệu | |---|---|---| | Managed planned failover | vùng chính CÒN SỐNG | không | | Failover / detach and promote | vùng chính đã chết | có thể mất vài giây |

Vì sao vẫn cần Lambda:

Aurora Global Database KHÔNG tự chuyển đổi khi mất vùng
    → nó có sao chép sẵn sàng, nhưng việc đôn cụm phụ
      là một quyết định phải kích hoạt
        ↓
    EventBridge phát hiện + Lambda gọi API = tự động hoá

Ba lợi ích khác: | Lợi ích | Chi tiết | |---|---| | Cụm phụ phục vụ ĐỌC ngay khi bình thường | không nằm không | | Tới 5 vùng phụ | | | Diễn tập bằng managed planned failover | không mất dữ liệu |

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

  • **A. Tạo cross-Region Aurora MySQL read replica ở us-west-2 và dùng Lambda đôn lên — đây là phương án gần nhất và hoạt động được, nhưng nó kém hơn ở cả hai chỉ tiêu: read replica xuyên vùng của Aurora MySQL dùng binlog replication, độ trễ tính bằng chục giây tới phút (RPO kém hơn), và việc promote mất nhiều phút hơn (RTO kém hơn). Với 2 TB dữ liệu, khoảng cách này rất rõ.
  • **B. Dựng lại thành Aurora multi-master trải qua us-east-1 và us-west-2 — bất khả thi: Aurora Multi-Master chỉ hoạt động trong một vùng, và AWS đã ngừng tính năng này. Không có cụm multi-master xuyên vùng.
  • **C. Tạo multi-Region Aurora MySQL DB cluster với Route 53 health check — cách gọi "multi-Region cluster" không tồn tại như một tính năng riêng (tính năng đúng tên là global database), và Route 53 chỉ chuyển hướng DNS chứ không đôn cụm CSDL lên làm writer.

Ghi nhớ

⚠ Aurora Global Database và Cross-Region Read Replica — bảng phải thuộc: | | Global Database | Cross-Region Read Replica | |---|---|---| | Cơ chế | tầng lưu trữ chuyên dụng | binlog | | Độ trễ (RPO) | thường < 1 giây | chục giây tới phút | | RTO khi promote | < 1 phút | nhiều phút | | Ảnh hưởng cụm chính | gần như không | có tải binlog | | Số vùng phụ | tới 5 | |

Từ khoá nhận diện:

"RPO seconds" + "RTO minutes" + Aurora → Aurora Global Database "RTO hours", "lowest cost" → Backup & Restore "active-active writes across Regions" → DynamoDB global tables (không phải Aurora)

Bốn chiến lược DR — bảng phải thuộc: | Chiến lược | RTO | RPO | Chi phí | |---|---|---|---| | Backup & Restore | giờ - ngày | giờ | thấp nhất | | Pilot Light | chục phút | phút - giây | thấp | | Warm Standby | phút | giây | trung bình | | Multi-Site Active-Active | gần 0 | gần 0 | cao nhất |

RTO 10 phút + RPO 5 phút
    → nằm giữa Pilot Light và Warm Standby
    → Aurora Global Database phù hợp cho tầng dữ liệu

Hai định nghĩa phải thuộc: | Chỉ số | Nghĩa | |---|---| | RTO | bao lâu để KHÔI PHỤC dịch vụ | | RPO | được phép MẤT bao nhiêu dữ liệu |

Ba đặc điểm của Aurora Global Database: | Đặc điểm | Chi tiết | |---|---| | Tới 5 vùng phụ, mỗi vùng tới 16 read replica | | | Cụm phụ CHỈ ĐỌC cho tới khi được đôn lên | | | Write forwarding (Aurora MySQL) | ghi ở vùng phụ được chuyển tiếp về chính |

Write forwarding đáng biết:

aws rds modify-db-cluster --db-cluster-identifier cum-dr   --enable-global-write-forwarding

Ứng dụng ở vùng phụ ghi được
    → Aurora tự chuyển lệnh ghi về cụm chính
        ↓
    Đơn giản hoá ứng dụng đa vùng
    → nhưng độ trễ ghi cao hơn

Ba cách phát hiện sự cố để kích hoạt: | Cách | Chi tiết | |---|---| | EventBridge rule bắt sự kiện RDS | | | CloudWatch alarm trên metric | | | Route 53 health check | |

aws events put-rule --name phat-hien-su-co-rds   --event-pattern '{"source":["aws.rds"],
    "detail-type":["RDS DB Cluster Event"],
    "detail":{"EventCategories":["failure"]}}'

⚠ Ba thứ khác cũng phải chuẩn bị ở vùng DR: | Thứ | Vì sao | |---|---| | AMI và launch template | tầng ứng dụng phải khởi động được | | Chứng chỉ ACM | ACM theo vùng | | Hạn ngạch tài khoản | vùng chưa dùng thường có quota thấp |

Vế cuối là chỗ hay vấp:

Chuyển đổi thành công ở tầng CSDL
    → nhưng ASG không khởi động nổi 10 máy vì chạm quota
        ↓
    Xin tăng hạn ngạch TRƯỚC, không phải trong lúc sự cố

Ba lưu ý về ứng dụng khi failover: | Lưu ý | Chi tiết | |---|---| | Endpoint CSDL thay đổi | dùng Route 53 CNAME hoặc Secrets Manager | | Kết nối đang mở bị ngắt | ứng dụng phải thử lại | | Connection pool phải xử lý được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Cụm phụ tính phí instance đầy đủ | | | Phí sao chép theo lượng dữ liệu thay đổi | | | Cụm phụ có thể chỉ chạy 1 instance nhỏ | tăng lên khi cần |

Ba việc phải làm định kỳ: | Việc | Tần suất | |---|---| | Diễn tập managed planned failover | ít nhất 2 lần/năm | | Đo RTO và RPO thực tế | mỗi lần diễn tập | | Kiểm tra AMI vùng DR còn mới | mỗi lần phát hành |

Và một lời khuyên: hãy dùng managed planned failover để diễn tập, và làm điều đó thật sự. Aurora cho phép chuyển vai trò giữa hai vùng mà không mất dữ liệu — đó là cách duy nhất để biết con số RTO của bạn là thật hay chỉ là ước lượng trên giấy.

Câu 935 AWS Storage

A company requires a high-performance file system that can be mounted on Amazon EC2 Windows instances and Amazon EC2 Linux instances. Applications running on the EC2 instances perform separate processing of the same files and the solution must provide a file system that can be mounted by all instances simultaneously.

Which solution meets these requirements?

  1. A

    Use Amazon Elastic File System (Amazon EFS) with General Purpose performance mode for the Windows instances and the Linux instances.
  2. B

    Use Amazon FSx for Windows File Server for the Windows instances and the Linux instances.
  3. C

    Use Amazon FSx for Windows File Server for the Windows instances. Use Amazon FSx for Lustre for the Linux instances. Link both Amazon FSx file systems to the same Amazon S3 bucket.
  4. D

    Use Amazon FSx for Windows File Server for the Windows instances. Use Amazon Elastic File System (Amazon EFS) with Max I/O performance mode for the Linux instances.
Xem giải thích

Đáp án

B — Dùng Amazon FSx for Windows File Server cho CẢ instance Windows VÀ instance Linux.

Vì sao đúng

Đề nêu ba yêu cầu, và một hệ thống tệp duy nhất phải phục vụ cả hai loại máy: | Yêu cầu | Cách đáp ứng | |---|---| | Mount được trên CẢ EC2 Windows và Linux | Linux mount SMB được bằng cifs-utils | | Nhiều instance mount ĐỒNG THỜI | SMB hỗ trợ nhiều client | | Hiệu năng cao | FSx SSD, throughput capacity cấu hình được |

⚠ Đây là điểm nhiều người không biết: Linux mount được SMB.

sudo yum install -y cifs-utils
sudo mount -t cifs //amznfsxabc.congty.local/share /du-lieu   -o vers=3.0,sec=krb5,cruid=$(id -u),username=nguoi_dung,domain=CONGTY

FSx for Windows dùng giao thức SMB
    → Windows mount gốc
    → Linux mount qua cifs-utils (có sẵn trong mọi bản phân phối)
        ↓
    Một hệ thống tệp phục vụ cả hai

Còn chiều ngược lại thì KHÔNG:

EFS dùng NFS
    → Linux mount gốc
    → Windows KHÔNG mount NFS một cách thực dụng
      (client NFS của Windows rất hạn chế, không hỗ trợ NFS v4.1
       theo cách EFS yêu cầu)
        ↓
    Đây là lý do phương án A sai

Tạo FSx:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 1000 --storage-type SSD   --subnet-ids subnet-a subnet-b   --windows-configuration     'DeploymentType=MULTI_AZ_1,PreferredSubnetId=subnet-a,
     ThroughputCapacity=64,ActiveDirectoryId=d-1234567890'

Ba lợi ích của một hệ thống tệp duy nhất: | Lợi ích | Chi tiết | |---|---| | Cả hai loại máy thấy CÙNG tệp | đúng yêu cầu đề | | Một nơi quản lý, một nơi sao lưu | | | Không phải đồng bộ giữa hai kho | |

Vế cuối là điều làm phương án C và D sai về bản chất:

Hai hệ thống tệp riêng biệt
    → hai bản sao dữ liệu
    → phải đồng bộ, có độ trễ, có xung đột
        ↓
    Đề nói rõ: "mounted by ALL instances SIMULTANEOUSLY"
    → phải là MỘT hệ thống tệp

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

  • **D. FSx for Windows cho máy Windows, EFS Max I/O cho máy Linux — đây là phương án gần nhất vì mỗi hệ điều hành dùng đúng giao thức gốc của nó, nhưng nó tạo ra HAI hệ thống tệp riêng biệt. Hai nhóm máy sẽ không thấy cùng một tập tệp, vi phạm yêu cầu cốt lõi.
  • **C. FSx for Windows cho Windows, FSx for Lustre cho Linux, cùng liên kết tới một S3 bucket — cùng vấn đề hai hệ thống tệp. Và liên kết S3 chỉ đồng bộ bất đồng bộ, không cho phép hai bên thấy thay đổi của nhau ngay lập tức.
  • **A. Dùng EFS cho cả Windows và Linux — EFS không hỗ trợ Windows. AWS nói rõ EFS chỉ dành cho instance Linux; client NFS của Windows không tương thích theo cách cần thiết.

Ghi nhớ

⚠ Bảng tương thích hệ điều hành — phải thuộc: | Dịch vụ | Giao thức | Linux | Windows | |---|---|---|---| | Amazon EFS | NFS | ✅ | ❌ | | FSx for Windows | SMB | ✅ (cifs-utils) | ✅ | | FSx for Lustre | Lustre | ✅ | ❌ | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | ✅ | ✅ | | FSx for OpenZFS | NFS | ✅ | ❌ |

Từ khoá nhận diện:

"both Windows and Linux" + "same files simultaneously" → FSx for Windows hoặc FSx for ONTAP "Linux only, general purpose" → EFS "HPC, Lustre" → FSx for Lustre

⚠ FSx for NetApp ONTAP cũng là câu trả lời hợp lệ:

ONTAP hỗ trợ ĐA GIAO THỨC gốc:
    → NFS cho Linux
    → SMB cho Windows
    → cùng một volume, cùng dữ liệu
        ↓
    Nếu đề có phương án ONTAP thì đó thường là đáp án tốt hơn
    → vì mỗi bên dùng giao thức gốc của mình

Ba lưu ý khi Linux mount SMB: | Lưu ý | Chi tiết | |---|---| | Cài cifs-utils | | | Ánh xạ UID/GID phù hợp | quyền có thể khác kỳ vọng | | Dùng sec=krb5 để xác thực bằng AD | |

⚠ Ánh xạ quyền là chỗ hay gây bất ngờ:

Windows dùng ACL (SID)
Linux dùng UID/GID và bit quyền POSIX
        ↓
    Tệp do Windows tạo có thể hiện quyền lạ trên Linux
    → dùng tuỳ chọn uid, gid, file_mode, dir_mode khi mount

sudo mount -t cifs //fsx/share /du-lieu   -o vers=3.0,uid=1000,gid=1000,file_mode=0664,dir_mode=0775,...

Ba yêu cầu để dựng FSx for Windows: | Yêu cầu | Chi tiết | |---|---| | Active Directory | Managed AD hoặc AD tự quản | | Subnet ở hai AZ (Multi-AZ) | | | Security group mở SMB (445) và cổng AD | |

⚠ AD là bắt buộc — không có AD thì không tạo được file system.

Hai chế độ triển khai: | Chế độ | SLA | |---|---| | Single-AZ | 99,9% | | Multi-AZ | 99,99% |

Ba yếu tố hiệu năng: | Yếu tố | Chi tiết | |---|---| | ThroughputCapacity | ảnh hưởng cả IOPS và băng thông | | Loại lưu trữ (SSD hay HDD) | | | Multi-AZ có độ trễ ghi cao hơn | sao chép đồng bộ |

Ba tính năng Windows gốc: | Tính năng | Chi tiết | |---|---| | ACL của Windows và tích hợp AD | | | Shadow Copies | người dùng tự khôi phục | | Deduplication | tiết kiệm 50-60% với tệp Office |

Ba lưu ý về EFS (để phân biệt): | Lưu ý | Chi tiết | |---|---| | Chỉ Linux | | | Hai chế độ hiệu năng: General Purpose và Max I/O | | | Max I/O có độ trễ CAO hơn | |

⚠ Max I/O không phải "nhanh hơn":

Max I/O: thông lượng tổng cao hơn nhưng ĐỘ TRỄ MỖI THAO TÁC CAO HƠN
    → chỉ đáng dùng khi có hàng nghìn client đồng thời
        ↓
    Với ứng dụng thông thường, General Purpose nhanh hơn

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | FSx for Windows đắt hơn EFS mỗi GB | | | Multi-AZ đắt gần gấp đôi Single-AZ | | | Deduplication giảm chi phí thật | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo tệp từ Windows, đọc từ Linux | | | Kiểm tra quyền hiển thị hợp lý ở cả hai | | | Đo thông lượng thực tế | |

Và một lời khuyên: hãy kiểm tra kỹ việc ánh xạ quyền trước khi đưa vào sản xuất. Việc Linux mount được SMB là chuyện kỹ thuật đơn giản; thứ thực sự gây rắc rối là một tệp do tiến trình Linux tạo ra lại mang quyền mà ứng dụng Windows không đọc được — và ngược lại.

Câu 936 AWS Networking & Content Delivery

A Solutions Architect is designing a solution for an application that requires very low latency between the client and the backend. The application uses the UDP protocol, and the backend is hosted on Amazon EC2 instances. The solution must be highly available across multiple Regions and users around the world should be directed to the most appropriate Region based on performance.

How can the Solutions Architect meet these requirements?

  1. A

    Deploy an Application Load Balancer in front of the EC2 instances in each Region. Use AWS WAF to direct traffic to the most optimal Regional endpoint.
  2. B

    Deploy a Network Load Balancer in front of the EC2 instances in each Region. Use AWS Global Accelerator to route traffic to the most optimal Regional endpoint.
  3. C

    Deploy an Amazon CloudFront distribution with a custom origin pointing to Amazon EC2 instances in multiple Regions.
  4. D

    Deploy Amazon EC2 instances in multiple Regions. Create a multivalue answer routing record in Amazon Route 53 that includes all EC2 endpoints.
Xem giải thích

Đáp án

B — Triển khai Network Load Balancer trước EC2 ở mỗi vùng, và dùng AWS Global Accelerator định tuyến tới endpoint vùng tối ưu nhất.

Vì sao đúng

Đề nêu bốn yêu cầu, và cặp NLB + Global Accelerator là lựa chọn duy nhất thoả hết: | Yêu cầu | Cách đáp ứng | |---|---| | **Ứng dụng dùng giao thức UDP | NLB và Global Accelerator đều hỗ trợ UDP | | Độ trễ RẤT THẤP | anycast + mạng xương sống AWS | | Sẵn sàng cao qua NHIỀU VÙNG | Global Accelerator health check và chuyển vùng | | Định tuyến theo HIỆU NĂNG | anycast tự chọn đường tốt nhất |

⚠ UDP là ràng buộc loại bỏ gần hết các lựa chọn: | Dịch vụ | Hỗ trợ UDP | |---|---| | Application Load Balancer | ❌ chỉ HTTP/HTTPS | | CloudFront | ❌ chỉ HTTP/HTTPS | | Network Load Balancer | ✅ TCP, UDP, TLS | | Global Accelerator | ✅ TCP và UDP |

Đề nói "The application uses the UDP protocol"
    → loại ngay ALB (phương án A) và CloudFront (phương án C)
        ↓
    Chỉ còn NLB và Global Accelerator

Global Accelerator định tuyến thế nào:

Hai IP TĨNH anycast được quảng bá từ MỌI edge của AWS
    → mạng tự chọn edge gần nhất cho từng người dùng
    → từ edge, lưu lượng đi trên MẠNG XƯƠNG SỐNG AWS
      tới endpoint vùng khoẻ mạnh và gần nhất
        ↓
    Không phụ thuộc DNS cache — định tuyến tất định

Cấu hình:

aws globalaccelerator create-accelerator --name tang-toc-udp   --ip-address-type IPV4 --enabled

aws globalaccelerator create-listener --accelerator-arn <arn>   --protocol UDP --port-ranges FromPort=5000,ToPort=5000   --client-affinity SOURCE_IP

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region ap-southeast-1   --endpoint-configurations EndpointId=<arn-nlb-sg>,Weight=100   --health-check-interval-seconds 10 --threshold-count 3

⚠ --client-affinity SOURCE_IP thường cần cho UDP:

UDP không có khái niệm "kết nối"
    → mỗi gói có thể được định tuyến độc lập
        ↓
    Với ứng dụng giữ trạng thái phiên (game, VoIP),
    dùng SOURCE_IP để cùng một client luôn tới cùng endpoint

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hai IP tĩnh — dễ đưa vào allowlist | | | Chuyển vùng trong vài chục giây, không qua DNS | | | Hiệu năng ổn định hơn Internet công cộng | |

Vế thứ hai là ưu thế lớn so với Route 53:

Route 53 failover: đổi bản ghi DNS
    → client phải chờ TTL hết hạn
    → resolver trung gian có thể giữ kết quả cũ lâu hơn

Global Accelerator: IP KHÔNG đổi
    → chỉ đổi đích phía sau
    → client không cần phân giải lại gì cả

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

  • **D. Triển khai EC2 ở nhiều vùng và tạo bản ghi multivalue answer trong Route 53 — đây là phương án gần nhất vì cũng có dự phòng đa vùng và có health check, nhưng multivalue answer chỉ trả về tối đa 8 bản ghi khoẻ mạnh một cách ngẫu nhiên — nó không chọn theo hiệu năng, và client tự chọn một IP trong danh sách. Không đạt yêu cầu "most appropriate Region based on performance".
  • **A. Application Load Balancer ở mỗi vùng, dùng AWS WAF định tuyến — sai hai chỗ: ALB không hỗ trợ UDP, và WAF là lớp lọc chứ không phải công cụ định tuyến giữa các vùng.
  • **C. CloudFront với custom origin trỏ tới EC2 ở nhiều vùng — CloudFront chỉ xử lý HTTP/HTTPS, không hỗ trợ UDP.

Ghi nhớ

⚠ Bảng hỗ trợ giao thức — phải thuộc: | Dịch vụ | Giao thức | |---|---| | Application Load Balancer | HTTP, HTTPS, gRPC | | Network Load Balancer | TCP, UDP, TLS | | Gateway Load Balancer | tầng 3 (GENEVE) | | CloudFront | HTTP, HTTPS | | Global Accelerator | TCP, UDP |

Từ khoá nhận diện:

"UDP" hoặc "non-HTTP" → NLB + Global Accelerator "static IP addresses" → NLB hoặc Global Accelerator "cache static content globally" → CloudFront "multi-Region + performance routing + fast failover" → Global Accelerator

⚠ CloudFront và Global Accelerator — bảng phân biệt: | | CloudFront | Global Accelerator | |---|---|---| | Có cache | ✅ | ❌ | | Giao thức | HTTP/HTTPS | TCP, UDP | | IP | thay đổi | 2 IP tĩnh anycast | | Failover đa vùng | origin group | rất nhanh, không qua DNS |

Ba đặc điểm của Global Accelerator: | Đặc điểm | Chi tiết | |---|---| | Hai IP tĩnh từ hai network zone khác nhau | | | Hỗ trợ ALB, NLB, EC2, Elastic IP | KHÔNG hỗ trợ S3 | | Health check chủ động tới endpoint | |

Ba tham số điều khiển lưu lượng: | Tham số | Việc | |---|---| | Traffic dial (0-100%) | rút lưu lượng khỏi một vùng | | Endpoint weight | tỷ lệ trong cùng nhóm | | Client affinity | giữ client ở cùng endpoint |

Traffic dial dùng cho triển khai an toàn:

aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn> --traffic-dial-percentage 10

Hai loại accelerator: | Loại | Dùng cho | |---|---| | Standard | định tuyến tới endpoint tối ưu | | Custom routing | ánh xạ cổng tới instance cụ thể — game, VoIP |

Custom routing đáng biết cho ứng dụng UDP:

Ánh xạ deterministic: cổng X luôn tới đúng instance Y
    → hữu ích khi mỗi phiên game gắn với một tiến trình cụ thể

Ba đặc điểm của NLB với UDP: | Đặc điểm | Chi tiết | |---|---| | Hỗ trợ UDP từ 2020 | | | Health check dùng TCP hoặc HTTP | không dùng UDP | | Giữ IP nguồn của client | với target kiểu instance |

⚠ Vế thứ hai là chi tiết quan trọng:

NLB không kiểm tra sức khoẻ bằng UDP
    → phải mở một cổng TCP hoặc HTTP riêng cho health check
        ↓
    Ứng dụng UDP phải có endpoint kiểm tra riêng

Ba chính sách Route 53 dễ lẫn: | Chính sách | Chọn theo | |---|---| | Latency-based | độ trễ đo được — nhưng phụ thuộc DNS cache | | Geolocation | quốc gia người dùng | | Multivalue answer | tới 8 bản ghi khoẻ, NGẪU NHIÊN |

Ba lưu ý về chi phí Global Accelerator: | Khoản | Chi tiết | |---|---| | Phí cố định theo giờ | ~0,025 USD/giờ | | Phí truyền dữ liệu cao cấp theo GB | | | Đắt hơn Route 53 đáng kể | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyEndpointCount | endpoint nào còn sống | | NewFlowCount | lượng kết nối mới | | ProcessedBytesIn/Out | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ nhiều khu vực trước và sau | | | Tắt một vùng, đo thời gian chuyển | | | Ghi lại hai IP tĩnh vào tài liệu | |

Và một lời khuyên: hãy thiết kế health check riêng bằng TCP hoặc HTTP cho ứng dụng UDP ngay từ đầu. Không có cách nào kiểm tra sức khoẻ bằng chính UDP, nên nếu ứng dụng không phơi bày một endpoint kiểm tra khác, load balancer sẽ tiếp tục gửi gói tới một tiến trình đã chết mà không hề biết.

Câu 937 AWS Security, Identity, & Compliance

A media streaming company stores user activity logs in an Amazon S3 bucket. The logs are accessed frequently for real-time analytics and reporting. The company enforces strict encryption requirements for data stored in S3 and currently uses AWS Key Management Service (AWS KMS) for encryption.

The company wants to reduce costs related to encrypting objects in the S3 bucket while maintaining compliance with its encryption requirements and minimizing the number of AWS KMS calls.

Which solution will meet these requirements?

  1. A

    Use server-side encryption with customer-provided encryption keys (SSE-C) and store the keys in AWS Secrets Manager.
  2. B

    Use client-side encryption with AWS KMS customer-managed keys to encrypt the data before uploading it to S3.
  3. C

    Use server-side encryption with Amazon S3 managed keys (SSE-S3) to eliminate AWS KMS usage.
  4. D

    Enable S3 Bucket Key for server-side encryption with AWS KMS keys (SSE-KMS) on the objects to reduce the cost of KMS requests.
Xem giải thích

Đáp án

D — Bật S3 Bucket Key cho mã hoá phía máy chủ bằng khoá KMS (SSE-KMS) trên các object, để giảm chi phí gọi KMS.

Vì sao đúng

Đề nêu ba yêu cầu, và Bucket Key giải quyết đúng cả ba mà không đổi gì khác: | Yêu cầu | Cách đáp ứng | |---|---| | Giữ nguyên yêu cầu mã hoá bằng KMS | vẫn là SSE-KMS | | Giảm chi phí mã hoá | giảm số lần gọi KMS tới 99% | | Giảm SỐ LẦN GỌI KMS | đúng mục đích của tính năng |

⚠ Vấn đề mà Bucket Key giải quyết:

SSE-KMS thông thường:
    mỗi lần GHI object → một lần gọi kms:GenerateDataKey
    mỗi lần ĐỌC object → một lần gọi kms:Decrypt
        ↓
    Log truy cập được đọc THƯỜNG XUYÊN cho phân tích
    → hàng triệu lần gọi KMS mỗi ngày
    → phí KMS có thể vượt cả phí lưu trữ S3

Bucket Key hoạt động thế nào:

S3 gọi KMS MỘT LẦN để lấy một "bucket-level key"
    → dùng khoá đó tạo data key cho nhiều object
    → giữ trong thời gian ngắn
        ↓
    Giảm số lần gọi KMS tới 99%
    → mà vẫn là mã hoá SSE-KMS đầy đủ

Bật cho bucket:

aws s3api put-bucket-encryption --bucket kho-log-hoat-dong   --server-side-encryption-configuration '{
    "Rules":[{
      "ApplyServerSideEncryptionByDefault":{
        "SSEAlgorithm":"aws:kms",
        "KMSMasterKeyID":"arn:aws:kms:ap-southeast-1:...:key/abc-123"},
      "BucketKeyEnabled":true}]}'

Hoặc cho từng object khi tải lên:

aws s3api put-object --bucket kho-log-hoat-dong --key log/2026-08-30.json   --body log.json --server-side-encryption aws:kms   --bucket-key-enabled

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đổi mô hình bảo mật | vẫn SSE-KMS, vẫn có key policy | | Không đổi mã ứng dụng | trong suốt với client | | Giảm cả chi phí lẫn rủi ro chạm giới hạn tần suất KMS | |

Vế thứ ba đáng nhấn mạnh:

KMS có giới hạn tần suất gọi API mỗi vùng
    → tải lớn có thể gặp ThrottlingException
        ↓
    Bucket Key vừa giảm phí vừa tránh bị giới hạn

⚠ Và Bucket Key không áp cho object cũ:

Bật Bucket Key → chỉ áp cho object GHI MỚI sau đó
    → object cũ vẫn dùng cơ chế cũ
        ↓
    Muốn áp cho object cũ: dùng S3 Batch Operations copy tại chỗ

aws s3api copy-object --bucket kho-log --key log/cu.json   --copy-source kho-log/log/cu.json   --server-side-encryption aws:kms --bucket-key-enabled   --metadata-directive COPY

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

  • **C. Dùng SSE-S3 để bỏ hẳn KMS — đây là phương án gần nhất và thực sự rẻ nhất, nhưng nó vi phạm yêu cầu tuân thủ: đề nói công ty "enforces strict encryption requirements" và hiện đang dùng KMS. SSE-S3 không có key policy, không có audit từng lần dùng khoá trong CloudTrail, không xoay khoá theo ý bạn.
  • **B. Dùng client-side encryption với khoá KMS — vẫn gọi KMS cho mỗi object (không giảm số lần gọi), phải sửa toàn bộ ứng dụng, và mất khả năng dùng Athena hay các công cụ phân tích của AWS — đúng thứ mà log phân tích thời gian thực cần.
  • **A. Dùng SSE-C với khoá lưu trong Secrets Manager — phải gửi khoá theo mỗi request, tự quản lý khoá, và mất mọi tính năng audit của KMS. Phức tạp hơn mà không rẻ hơn.

Ghi nhớ

⚠ Bốn lựa chọn mã hoá S3 — bảng phải thuộc: | Lựa chọn | Khoá do ai giữ | Audit trong CloudTrail | Chi phí | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | ❌ | miễn phí | | SSE-KMS | KMS, bạn đặt policy | ✅ | phí gọi KMS | | SSE-C | bạn gửi mỗi request | ❌ | miễn phí | | Client-side | bạn | — | phí KMS |

Từ khoá nhận diện:

"reduce KMS costs while keeping SSE-KMS" → S3 Bucket Key "audit every key use, control key policy" → SSE-KMS "simplest, default" → SSE-S3 "AWS must never see plaintext" → client-side encryption

Ba đặc điểm của S3 Bucket Key: | Đặc điểm | Chi tiết | |---|---| | Giảm gọi KMS tới 99% | | | Chỉ áp cho object GHI MỚI | | | Trong suốt với ứng dụng | không đổi mã |

⚠ Ba lưu ý về CloudTrail khi bật Bucket Key: | Lưu ý | Chi tiết | |---|---| | Số bản ghi KMS trong CloudTrail GIẢM MẠNH | | | Ghi ở cấp BUCKET thay vì cấp object | | | Nếu cần audit từng object thì đây là đánh đổi | |

Yêu cầu tuân thủ đòi biết CHÍNH XÁC object nào được giải mã lúc nào?
    → Bucket Key làm mất chi tiết đó
        ↓
    Đây là điều duy nhất cần cân nhắc trước khi bật

Ba khái niệm KMS cần biết: | Khái niệm | Nghĩa | |---|---| | Envelope encryption | data key mã hoá dữ liệu, KMS mã hoá data key | | GenerateDataKey | API S3 gọi khi ghi | | Decrypt | API S3 gọi khi đọc |

Ba loại khoá KMS: | Loại | Kiểm soát | |---|---| | AWS managed key (aws/s3) | AWS quản lý, xoay hằng năm | | Customer managed key | bạn đặt policy, bật xoay, vô hiệu hoá được | | AWS owned key | không thấy được |

⚠ Bucket Key hoạt động với cả hai loại đầu.

Ba cách giảm chi phí mã hoá thêm: | Cách | Chi tiết | |---|---| | Bật Bucket Key | ← câu này | | Gộp log thành tệp lớn | ít object = ít lần gọi | | Dùng SSE-S3 cho dữ liệu không nhạy cảm | |

Vế thứ hai rất hiệu quả với log:

Ghi mỗi dòng log một object
    → hàng triệu lần gọi KMS
    → cộng hàng triệu PUT request
        ↓
    Gộp theo lô bằng Kinesis Data Firehose
    → vài trăm object thay vì hàng triệu

Ba lưu ý về quyền KMS: | Lưu ý | Chi tiết | |---|---| | Người đọc cần kms:Decrypt | | | Người ghi cần kms:GenerateDataKey | | | Thiếu quyền KMS báo lỗi AccessDenied khó hiểu | |

Vế thứ ba là lỗi hay gặp:

Cấp s3:GetObject nhưng quên kms:Decrypt
    → lỗi AccessDenied nhắc tới KMS
    → dễ tưởng là lỗi quyền S3

Ba lưu ý về chi phí KMS: | Khoản | Chi tiết | |---|---| | Customer managed key: ~1 USD/tháng mỗi khoá | | | Phí theo số lần gọi API | | | Mã hoá S3 không tính phí thêm ngoài KMS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra object mới có x-amz-server-side-encryption-bucket-key-enabled | | | Theo dõi số lần gọi KMS trong CloudWatch | | | So hoá đơn KMS tháng trước và sau | |

aws s3api head-object --bucket kho-log-hoat-dong --key log/moi.json   --query "[ServerSideEncryption,BucketKeyEnabled]"

Và một lời khuyên: hãy bật Bucket Key cho mọi bucket dùng SSE-KMS, ngay cả khi hoá đơn hiện chưa cao. Nó gần như không có nhược điểm ngoài việc audit gộp ở cấp bucket, và nó cũng loại bỏ luôn nguy cơ chạm giới hạn tần suất KMS vào đúng ngày lưu lượng tăng đột biến.

Câu 938 AWS Networking & Content Delivery

A company has created a duplicate of its environment in another AWS Region. The application is running in warm standby mode. There is an Application Load Balancer (ALB) in front of the application. Currently, failover is manual and requires updating a DNS alias record to point to the secondary ALB.

How can a solutions architect automate the failover process?

  1. A

    Create a CNAME record on Amazon Route 53 pointing to the ALB endpoint
  2. B

    Enable an Amazon Route 53 health check
  3. C

    Create a latency based routing policy on Amazon Route 53
  4. D

    Enable an ALB health check
Xem giải thích

Đáp án

B — Bật một Amazon Route 53 health check.

Vì sao đúng

Đề mô tả chính xác thứ đang thiếu: | Hiện trạng | Vấn đề | |---|---| | Đã có bản sao ở vùng thứ hai (warm standby) | hạ tầng sẵn sàng | | Đã có bản ghi DNS alias trỏ tới ALB | | | Chuyển đổi là THỦ CÔNG — phải sửa DNS bằng tay | thiếu cơ chế phát hiện tự động |

Vì sao health check là mảnh ghép còn thiếu:

Route 53 failover routing cần HAI thứ:
    1. Hai bản ghi: PRIMARY và SECONDARY
    2. Một HEALTH CHECK gắn vào bản ghi primary
        ↓
    Thiếu health check → Route 53 không biết khi nào phải chuyển
    → vẫn phải có người sửa DNS bằng tay

Tạo health check:

aws route53 create-health-check --caller-reference $(uuidgen)   --health-check-config '{
    "Type":"HTTPS","ResourcePath":"/health",
    "FullyQualifiedDomainName":"alb-chinh.ap-southeast-1.elb.amazonaws.com",
    "Port":443,"RequestInterval":30,"FailureThreshold":3}'

Rồi gắn vào cặp bản ghi failover:

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"ungdung.vidu.com","Type":"A","SetIdentifier":"chinh",
      "Failover":"PRIMARY","HealthCheckId":"hc-abc123",
      "AliasTarget":{"HostedZoneId":"Z1","DNSName":"alb-chinh...",
                     "EvaluateTargetHealth":true}}},
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"ungdung.vidu.com","Type":"A","SetIdentifier":"phu",
      "Failover":"SECONDARY",
      "AliasTarget":{"HostedZoneId":"Z2","DNSName":"alb-phu...",
                     "EvaluateTargetHealth":true}}}]}'

Cách hoạt động sau khi cấu hình:

Health check thất bại 3 lần liên tiếp (mỗi 30 giây)
    → Route 53 ngừng trả bản ghi PRIMARY
    → tự trả bản ghi SECONDARY
        ↓
    Không cần ai can thiệp

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tự động, không cần người trực | | | Chuyển ngược lại tự động khi vùng chính hồi phục | | | Kết hợp được với CloudWatch alarm | |

⚠ Và có một chi tiết đáng dùng: EvaluateTargetHealth.

Với bản ghi ALIAS trỏ tới ALB:
    → đặt EvaluateTargetHealth = true
    → Route 53 tự dùng trạng thái target của ALB
        ↓
    Không cần health check riêng cho trường hợp đơn giản
    → nhưng health check tường minh cho phép kiểm tra
      một đường dẫn cụ thể của ứng dụng

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

  • **D. Bật một ALB health check — đây là phương án gần nhất và nghe rất giống, nhưng ALB health check chỉ hoạt động BÊN TRONG một vùng: nó quyết định gửi request tới target nào trong target group. Nó không biết gì về ALB ở vùng khác và không đụng tới DNS.
  • **C. Tạo latency-based routing policy — định tuyến theo độ trễ là mô hình active-active: cả hai vùng cùng phục vụ. Đề mô tả warm standby (vùng phụ chỉ chạy khi cần), và latency-based không có khái niệm chính/phụ.
  • **A. Tạo CNAME record trỏ tới endpoint ALB — chỉ là một cách trỏ DNS khác, không thêm cơ chế tự động nào. Và với ALIAS thì CNAME còn kém hơn (không dùng được ở đỉnh tên miền, tính phí truy vấn).

Ghi nhớ

⚠ Ba loại health check của AWS — bảng phải thuộc: | Health check | Phạm vi | Quyết định | |---|---|---| | Route 53 health check | TOÀN CẦU | trả bản ghi DNS nào | | ALB / NLB health check | trong một vùng | gửi request tới target nào | | Auto Scaling health check | trong một ASG | thay instance nào |

Từ khoá nhận diện:

"automatically update DNS to another Region" → Route 53 health check + failover policy "remove unhealthy instance from load balancer" → ELB health check "replace unhealthy instance" → ASG health check

Ba loại Route 53 health check: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới một địa chỉ | | Calculated | gộp kết quả nhiều health check khác | | CloudWatch alarm | theo trạng thái một alarm |

⚠ Loại thứ ba rất hữu ích:

Ứng dụng vẫn trả 200 nhưng CSDL đã hỏng
    → endpoint health check không phát hiện được
        ↓
    Tạo CloudWatch alarm trên metric CSDL
    → gắn health check kiểu alarm vào đó
    → chuyển vùng theo tín hiệu thật

aws route53 create-health-check --caller-reference $(uuidgen)   --health-check-config '{"Type":"CLOUDWATCH_METRIC",
    "AlarmIdentifier":{"Region":"ap-southeast-1","Name":"csdl-hong"},
    "InsufficientDataHealthStatus":"Unhealthy"}'

Calculated health check cũng đáng biết:

Gộp: (ALB khoẻ) VÀ (CSDL khoẻ) VÀ (cache khoẻ)
    → chỉ coi vùng là khoẻ khi mọi tầng đều khoẻ

Ba tham số quyết định thời gian chuyển: | Tham số | Ảnh hưởng | |---|---| | RequestInterval | 30 giây (hoặc 10 giây với fast) | | FailureThreshold | số lần hỏng liên tiếp | | TTL của bản ghi | client cache DNS bao lâu |

⚠ TTL là chỗ hay bị bỏ qua nhất:

Health check phát hiện trong 90 giây (30 × 3)
    → TTL 300 giây → client vẫn dùng IP cũ thêm 5 phút
        ↓
    Thời gian ngừng thực tế gần 7 phút
    → đặt TTL 60 giây cho bản ghi failover

Bảy chính sách định tuyến Route 53: | Chính sách | Dùng cho | |---|---| | Failover | chính/phụ — DR ← câu này | | Latency-based | active-active theo hiệu năng | | Geolocation | theo quốc gia | | Geoproximity | theo khoảng cách, có bias | | Weighted | chia tỷ lệ, triển khai từng phần | | Multivalue answer | tới 8 bản ghi khoẻ | | Simple | một đích |

Ba lưu ý khi dùng failover với ALIAS: | Lưu ý | Chi tiết | |---|---| | EvaluateTargetHealth dùng trạng thái ALB | | | Health check tường minh kiểm tra sâu hơn | | | Dùng cả hai được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Health check trong AWS rẻ hơn ngoài AWS | | | Fast interval (10 giây) đắt hơn | | | Calculated health check tính riêng | |

Ba thứ khác cần chuẩn bị cho warm standby: | Thứ | Vì sao | |---|---| | CSDL đã sao chép sang vùng phụ | | | AMI, ảnh container ở vùng phụ | | | Chứng chỉ ACM ở vùng phụ | ACM theo vùng |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạm ngắt vùng chính, đo thời gian chuyển | | | Kiểm tra chuyển ngược khi hồi phục | | | Đặt alarm khi health check chuyển trạng thái | |

aws cloudwatch put-metric-alarm --alarm-name canh-bao-failover   --namespace AWS/Route53 --metric-name HealthCheckStatus   --dimensions Name=HealthCheckId,Value=hc-abc123   --statistic Minimum --period 60 --evaluation-periods 1   --threshold 1 --comparison-operator LessThanThreshold

Và một lời khuyên: hãy kiểm tra TTL của bản ghi failover ngay sau khi bật health check. Health check có thể phát hiện sự cố trong 30 giây, nhưng một TTL để mặc định ở 300 giây sẽ khiến người dùng vẫn nhìn thấy vùng đã chết thêm nhiều phút nữa — và đó là phần thời gian ngừng mà không có bảng điều khiển nào hiển thị cho bạn.

Câu 939 AWS Networking & Content Delivery

A financial services company needs to set up an Amazon RDS Multi-AZ database to store customer transaction records. The database will serve as the backend for an on-premises financial analysis application. The company requires the on-premises application to connect directly to the RDS database when employees are working from the office.

The company must ensure the connection is established securely and efficiently.

Which solution provides the required connectivity MOST securely?

  1. A

    Create a VPC with two public subnets. Deploy the RDS database in the public subnets. Configure an AWS Direct Connect connection between the on-premises office and the VPC for low-latency access.
  2. B

    Create a VPC with two private subnets. Deploy the RDS database in the private subnets. Establish connectivity between the on-premises office and AWS using AWS Site-to-Site VPN with a customer gateway.
  3. C

    Create a VPC with two private subnets. Deploy the RDS database in the private subnets. Configure RDS security groups to allow the on-premises office IP ranges to access the database directly over the internet.
  4. D

    Create a VPC with two public subnets. Deploy the RDS database in the public subnets. Use AWS Client VPN to establish secure connectivity between employees’ desktops and the database.
Xem giải thích

Đáp án

B — Tạo VPC với hai subnet riêng tư, đặt RDS trong đó, và nối văn phòng với AWS bằng Site-to-Site VPN với customer gateway.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này là lựa chọn an toàn nhất trong bốn: | Yêu cầu | Cách đáp ứng | |---|---| | RDS Multi-AZ lưu giao dịch khách hàng | hai subnet riêng tư ở hai AZ | | Ứng dụng tại chỗ kết nối trực tiếp | VPN nối mạng văn phòng với VPC | | AN TOÀN NHẤT | CSDL không có IP công khai, lưu lượng mã hoá IPsec |

Hai lớp bảo vệ:

Lớp 1: RDS nằm trong subnet RIÊNG TƯ
    → không có IP công khai
    → không có đường nào từ Internet vào

Lớp 2: Site-to-Site VPN
    → đường hầm IPsec mã hoá giữa văn phòng và VPC
    → dữ liệu giao dịch không đi trần qua Internet

Dựng VPN:

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

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-vpn-connection --type ipsec.1   --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc   --options '{"StaticRoutesOnly":false}'

Tạo RDS trong subnet riêng tư:

aws rds create-db-subnet-group --db-subnet-group-name nhom-rieng-tu   --db-subnet-group-description "Subnet rieng tu cho RDS"   --subnet-ids subnet-rieng-a subnet-rieng-b

aws rds create-db-instance --db-instance-identifier csdl-giao-dich   --engine postgres --db-instance-class db.m6g.large   --multi-az --db-subnet-group-name nhom-rieng-tu   --no-publicly-accessible --storage-encrypted   --vpc-security-group-ids sg-csdl

⚠ --no-publicly-accessible là cờ quan trọng nhất:

Đặt publicly-accessible = true
    → RDS nhận một IP CÔNG KHAI
    → dù nằm trong subnet riêng tư
        ↓
    Đây là cấu hình sai rất hay gặp

Security group chỉ cho dải văn phòng:

aws ec2 authorize-security-group-ingress --group-id sg-csdl   --protocol tcp --port 5432 --cidr 192.168.10.0/24

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có bề mặt tấn công từ Internet | | | Lưu lượng mã hoá IPsec | | | Dựng nhanh, chi phí thấp | |

Và VPN có hai đường hầm sẵn:

Mỗi Site-to-Site VPN connection có HAI tunnel
    → ở hai AZ khác nhau phía AWS
    → dự phòng tự động
        ↓
    Nhưng phía customer gateway thường chỉ có MỘT thiết bị
    → đó mới là điểm hỏng đơn lẻ còn lại

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

  • **A. Hai subnet CÔNG KHAI, đặt RDS ở đó, dùng Direct Connect — đây là phương án gần nhất vì Direct Connect cho độ trễ tốt hơn VPN, nhưng đặt CSDL trong subnet công khai là sai nghiêm trọng về bảo mật. Và Direct Connect KHÔNG mã hoá mặc định — đề hỏi "MOST securely".
  • **C. Hai subnet riêng tư, nhưng cho security group mở dải IP văn phòng truy cập QUA INTERNET — mâu thuẫn: nếu truy cập qua Internet thì CSDL phải có đường vào từ Internet, tức không còn riêng tư. Và lưu lượng không được mã hoá ở tầng mạng.
  • **D. Hai subnet công khai với AWS Client VPN — Client VPN đúng là công cụ cho người dùng cá nhân từ xa, nhưng đề nói nhân viên làm việc tại văn phòng, nên Site-to-Site VPN phù hợp hơn. Và vẫn đặt CSDL trong subnet công khai.

Ghi nhớ

⚠ Ba cách nối mạng tại chỗ với AWS — bảng phải thuộc: | Cách | Mã hoá | Băng thông | Thời gian dựng | |---|---|---|---| | Site-to-Site VPN | ✅ IPsec | tới 1,25 Gbps mỗi tunnel | vài giờ | | Direct Connect | ❌ mặc định KHÔNG | 50 Mbps - 400 Gbps | hàng tuần - tháng | | DX + VPN | ✅ | cao | |

⚠ Direct Connect không mã hoá — điều phải nhớ:

DX là đường riêng, không đi qua Internet
    → nhưng dữ liệu KHÔNG được mã hoá
        ↓
    Dữ liệu nhạy cảm cần: VPN chạy trên DX, hoặc MACsec

Từ khoá nhận diện:

"office to AWS" + "most secure" + nhanh → Site-to-Site VPN "consistent bandwidth, low latency" → Direct Connect "individual remote users" → AWS Client VPN "encrypted dedicated connection" → DX + VPN

Ba thành phần của Site-to-Site VPN: | Thành phần | Ở đâu | |---|---| | Customer Gateway (CGW) | đại diện thiết bị phía bạn | | Virtual Private Gateway (VGW) hoặc Transit Gateway | phía AWS | | VPN Connection | hai tunnel IPsec |

Ba lưu ý về dự phòng VPN: | Lưu ý | Chi tiết | |---|---| | Mỗi connection có HAI tunnel | | | Dùng hai thiết bị CGW để bỏ điểm hỏng phía bạn | | | Dùng BGP để tự chuyển đường | |

Ba lưu ý về bảo mật cho RDS: | Lưu ý | Chi tiết | |---|---| | --no-publicly-accessible | | | DB subnet group chỉ gồm subnet riêng tư | | | Bật mã hoá at rest bằng KMS | |

⚠ Mã hoá RDS phải bật LÚC TẠO:

Instance chưa mã hoá KHÔNG bật mã hoá sau được
    → phải snapshot → copy có mã hoá → restore thành instance mới
        ↓
    Có thời gian ngừng — bật ngay từ đầu

Ba lớp mã hoá cho CSDL tài chính: | Lớp | Công cụ | |---|---| | At rest | KMS | | In transit tới CSDL | bắt buộc SSL/TLS | | Đường mạng | IPsec của VPN |

Bắt buộc TLS cho kết nối RDS:

-- PostgreSQL parameter group
rds.force_ssl = 1

Không bật: client kết nối không TLS vẫn được chấp nhận
    → một cấu hình sai ở phía ứng dụng là dữ liệu đi trần

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Standby KHÔNG phục vụ đọc | | | Chuyển đổi tự động 1-2 phút | | | Endpoint DNS giữ nguyên | |

Ba lưu ý về định tuyến: | Lưu ý | Chi tiết | |---|---| | Bật route propagation trên route table | | | CIDR văn phòng không được trùng CIDR VPC | | | Security group cho phép dải văn phòng | |

⚠ CIDR trùng là lỗi chặn hoàn toàn:

Văn phòng dùng 10.0.0.0/16, VPC cũng dùng 10.0.0.0/16
    → không định tuyến được
        ↓
    Phải đổi CIDR một bên, hoặc dùng NAT

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | VPN tính theo giờ mỗi connection | ~0,05 USD/giờ | | Cộng phí truyền dữ liệu ra | | | Rẻ hơn Direct Connect nhiều | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra hai tunnel đều UP | | | telnet <endpoint-rds> 5432 từ văn phòng | | | Xác nhận RDS không có IP công khai | |

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 bật rds.force_ssl cùng lúc với việc dựng VPN. Đường hầm IPsec bảo vệ dữ liệu trên chặng giữa văn phòng và AWS, nhưng chặng cuối từ VPC tới CSDL vẫn cần TLS riêng — và cấu hình mặc định của RDS chấp nhận cả kết nối không mã hoá mà không báo gì.

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

A company has deployed an API in a VPC behind an internal Network Load Balancer (NLB). An application that consumes the API as a client is deployed in a second account in private subnets.

Which architectural configurations will allow the API to be consumed without using the public Internet? (Select TWO.)

  1. A

    Configure a VPC peering connection between the two VPCs. Access the API using the private address
  2. B

    Configure an AWS Direct Connect connection between the two VPCs. Access the API using the private address
  3. C

    Configure a ClassicLink connection for the API into the client VPC. Access the API using the ClassicLink address
  4. D

    Configure a PrivateLink connection for the API into the client VPC. Access the API using the PrivateLink address
  5. E

    Configure an AWS Resource Access Manager connection between the two accounts. Access the API using the private address
Xem giải thích

Đáp án

A và D.

  • A — Cấu hình VPC peering giữa hai VPC, truy cập API bằng địa chỉ riêng
  • D — Cấu hình PrivateLink cho API vào VPC của client, truy cập bằng địa chỉ PrivateLink

Vì sao đúng

Đề hỏi những cấu trúc nào cho phép tiêu thụ API không qua Internet công cộng — và có đúng hai cách: | Cách | Cơ chế | |---|---| | VPC Peering | nối hai VPC ở tầng mạng, đi bằng IP riêng | | PrivateLink | phơi bày NLB dưới dạng endpoint service |

Cả hai đều đi hoàn toàn trên hạ tầng AWS:

VPC Peering:  gói đi trực tiếp giữa hai VPC qua backbone AWS
PrivateLink:  gói đi tới ENI trong chính subnet của client
        ↓
    Không có gói nào chạm Internet trong cả hai trường hợp

VPC Peering (phương án A):

aws ec2 create-vpc-peering-connection   --vpc-id vpc-client --peer-vpc-id vpc-api   --peer-owner-id 111122223333

aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-abc

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

PrivateLink (phương án D):

# Phía cung cấp API
aws ec2 create-vpc-endpoint-service-configuration   --network-load-balancer-arns <arn-nlb-noi-bo> --acceptance-required

# Phía client
aws ec2 create-vpc-endpoint --vpc-id vpc-client   --vpc-endpoint-type Interface   --service-name com.amazonaws.vpce.ap-southeast-1.vpce-svc-abc   --subnet-ids subnet-rieng-a --security-group-ids sg-endpoint

⚠ Hai cách này khác nhau rõ rệt — biết chọn cái nào: | | VPC Peering | PrivateLink | |---|---|---| | Phơi bày | CẢ VPC | CHỈ một dịch vụ | | CIDR trùng nhau | ❌ không được | ✅ được | | Chiều | hai chiều | một chiều (client → API) | | Mở rộng nhiều client | kém — n(n-1)/2 | tốt | | Chi phí | miễn phí (cùng AZ) | phí endpoint theo giờ + GB |

Chỉ có hai VPC, CIDR không trùng, muốn rẻ → Peering
Nhiều client, cần cô lập chặt, CIDR có thể trùng → PrivateLink

Ba lưu ý bắt buộc với peering: | Lưu ý | Chi tiết | |---|---| | Sửa route table ở CẢ HAI VPC | | | Security group cho phép CIDR bên kia | | | CIDR KHÔNG được trùng | |

⚠ Và peering KHÔNG bắc cầu:

A ↔ B và B ↔ C
    → A KHÔNG nói chuyện được với C
        ↓
    Cũng không dùng chung được NAT Gateway,
    Internet Gateway, hay VPN của VPC kia

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

  • **B. Cấu hình Direct Connect giữa hai VPC — sai vai trò dịch vụ: Direct Connect nối trung tâm dữ liệu tại chỗ với AWS. Nó không dùng để nối hai VPC với nhau. (Nối nhiều VPC là việc của Peering, Transit Gateway hoặc PrivateLink.)
  • **C. Cấu hình ClassicLink — dịch vụ đã ngừng: ClassicLink nối EC2-Classic (nền tảng cũ trước VPC) với một VPC. AWS đã ngừng EC2-Classic từ 08/2022, và nó chưa bao giờ dùng để nối hai VPC.
  • **E. Dùng AWS Resource Access Manager để "kết nối hai tài khoản" — RAM dùng để CHIA SẺ TÀI NGUYÊN (subnet, Transit Gateway, license), không tạo ra đường kết nối mạng nào. Chia sẻ subnet qua RAM là một mô hình khác (VPC dùng chung), không phải "kết nối hai VPC".

Ghi nhớ

⚠ Bốn cách kết nối riêng tư giữa VPC — bảng phải thuộc: | Cách | Phơi bày | Bắc cầu | CIDR trùng | |---|---|---|---| | VPC Peering | cả VPC | ❌ | ❌ | | Transit Gateway | cả VPC, có phân đoạn | ✅ | ❌ | | PrivateLink | một dịch vụ | không áp dụng | ✅ | | VPC dùng chung (RAM) | cùng một VPC | — | không áp dụng |

Từ khoá nhận diện:

"two VPCs, private access" → Peering hoặc PrivateLink "expose ONE service, many consumers" → PrivateLink "many VPCs + on-premises" → Transit Gateway "connect data center to AWS" → Direct Connect hoặc VPN

Ba đặc điểm của VPC Peering: | Đặc điểm | Chi tiết | |---|---| | Miễn phí trong cùng AZ | phí cross-AZ và cross-Region | | Hỗ trợ liên vùng và liên tài khoản | | | Không có băng thông giới hạn riêng | |

Ba bước bắt buộc sau khi peering: | Bước | Chi tiết | |---|---| | 1. Chấp nhận kết nối ở VPC bên kia | | | 2. Thêm route ở CẢ HAI route table | | | 3. Sửa security group | |

Bước 2 là chỗ hay quên nhất:

Peering ở trạng thái "active" nhưng không thông
    → gần như luôn là do thiếu route
        ↓
    Peering chỉ tạo ĐƯỜNG; route table mới nói gói đi lối nào

⚠ Security group tham chiếu chéo VPC:

aws ec2 authorize-security-group-ingress --group-id sg-api   --protocol tcp --port 443 --source-group sg-client   --group-owner 222233334444

Tham chiếu security group của VPC bên kia được
    → nhưng CHỈ khi hai VPC cùng vùng
    → liên vùng thì phải dùng CIDR

Ba thành phần của PrivateLink: | Thành phần | Ở đâu | |---|---| | Network Load Balancer | VPC cung cấp | | VPC Endpoint Service | VPC cung cấp | | Interface VPC Endpoint | VPC TIÊU THỤ |

Ba đặc điểm của interface endpoint: | Đặc điểm | Chi tiết | |---|---| | Là một ENI có IP riêng trong subnet | | | Có security group | | | Tính phí theo giờ mỗi AZ + theo GB | |

Ba giới hạn của peering: | Giới hạn | Con số | |---|---| | Peering mỗi VPC | 125 (mặc định 50) | | Không bắc cầu | | | CIDR không trùng | |

Ba lưu ý về Transit Gateway (khi peering không đủ): | Lưu ý | Chi tiết | |---|---| | Bắc cầu được | | | Phân đoạn bằng nhiều route table | | | Tính phí theo attachment và GB | |

Ba lưu ý về DNS giữa hai VPC: | Lưu ý | Chi tiết | |---|---| | Bật enableDnsSupport ở cả hai | | | Bật phân giải DNS cho peering | | | Hoặc chia sẻ private hosted zone | |

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

Ba việc chẩn đoán khi không thông: | Việc | Công cụ | |---|---| | Kiểm tra route table hai bên | | | VPC Reachability Analyzer | chỉ thẳng chỗ chặn | | VPC Flow Logs | xem gói bị REJECT |

aws ec2 create-network-insights-path --source i-client   --destination i-api --destination-port 443 --protocol tcp

Và một lời khuyên: hãy dùng Reachability Analyzer ngay khi kết nối không thông, đừng đọc lại từng route table. Với peering, nguyên nhân gần như luôn nằm ở một trong ba chỗ — route, security group, hoặc NACL — và công cụ này chỉ thẳng vào thành phần đang chặn thay vì bắt bạn đoán.