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

Tìm thấy 2194 câu.

Câu 751 Design Cost-Optimized Architectures

The development team at a company manages a Python based nightly process with a runtime of 30 minutes. The process can withstand any interruptions in its execution and start over again. The process currently runs on the on-premises infrastructure and it needs to be migrated to AWS.

Which of the following options do you recommend as the MOST cost-effective solution?

  1. A

    Run on Amazon EMR
  2. B

    Run on a Spot Instance with a persistent request type
  3. C

    Run on an Application Load Balancer
  4. D

    Run on AWS Lambda
Xem giải thích

Đáp án

B — Chạy trên Spot Instance với persistent request.

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba dẫn tới Spot: | Đặc điểm | Kết luận | |---|---| | Chạy 30 PHÚT | loại Lambda (trần 15 phút) | | CHỊU ĐƯỢC gián đoạn, chạy lại từ đầu | Spot hoàn toàn phù hợp | | TIẾT KIỆM CHI PHÍ NHẤT | Spot rẻ hơn tới 90% |

Con số 30 phút là điểm loại trừ đầu tiên:

AWS Lambda: thời gian chạy tối đa 15 PHÚT
    → tiến trình 30 phút KHÔNG chạy được
        ↓
    Đây là giới hạn cứng, không nâng được

Và "chịu được gián đoạn, chạy lại từ đầu" là điều kiện của Spot:

"can withstand any interruptions in its execution and START OVER AGAIN"
        ↓
    Spot bị thu hồi → chạy lại từ đầu
    → không mất gì
        ↓
    Đúng mô tả tải phù hợp với Spot

Và "persistent request" là chi tiết quan trọng:

One-time Spot request:
    → instance bị thu hồi → yêu cầu KẾT THÚC
    → không tự khởi động lại

Persistent Spot request:
    → instance bị thu hồi → yêu cầu VẪN CÒN
    → tự khởi động instance mới khi có năng lực
        ↓
    Tiến trình hằng đêm tự chạy lại mà không cần can thiệp

Tạo persistent request:

aws ec2 request-spot-instances   --instance-count 1 --type persistent   --instance-interruption-behavior terminate   --launch-specification file://cau-hinh.json

Và ba hành vi khi bị gián đoạn: | Hành vi | Chi tiết | |---|---| | terminate | chấm dứt — mặc định | | stop | dừng, giữ EBS, khởi động lại sau | | hibernate | lưu RAM, tiếp tục từ chỗ dừng |

stop và hibernate chỉ dùng được với persistent request.

Và với tiến trình hằng đêm, nên kết hợp với lịch:

EventBridge Scheduler kích hoạt lúc 2 giờ sáng
    → khởi động Spot Instance chạy tiến trình
    → xong thì tự chấm dứt
        ↓
    Chỉ trả tiền ~30 phút mỗi đêm

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

  • **D. Chạy trên AWS Lambda — đây là phương án gần nhất vì Lambda thật sự rất rẻ cho tác vụ ngắn, nhưng nó vượt giới hạn cứng 15 phút: tiến trình 30 phút không chạy hết được, sẽ bị cắt giữa chừng.
  • **A. Chạy trên Amazon EMR — quá nặng và đắt: EMR là nền tảng xử lý dữ liệu lớn với cụm Hadoop/Spark, dùng cho một script Python đơn lẻ là lãng phí lớn.
  • **C. Chạy trên Application Load Balancer — hoàn toàn không phải nơi chạy mã: ALB phân phối lưu lượng, nó không thực thi chương trình nào.

Ghi nhớ

Giới hạn thời gian chạy của các dịch vụ tính toán — bảng phải thuộc: | Dịch vụ | Thời gian tối đa | |---|---| | AWS Lambda | 15 phút | | AWS Fargate | không giới hạn | | EC2 | không giới hạn | | AWS Batch | không giới hạn | | Step Functions Standard | 1 năm | | Step Functions Express | 5 phút |

Con số 15 phút của Lambda là điểm loại trừ hay được dùng trong đề thi.

Ba đặc điểm của Spot request: | Loại | Hành vi khi bị thu hồi | |---|---| | One-time | yêu cầu kết thúc | | Persistent | tự khởi động lại khi có năng lực |

Ba hành vi khi gián đoạn: | Hành vi | Yêu cầu | |---|---| | terminate | mặc định, dùng với cả hai loại | | stop | chỉ persistent, giữ EBS root | | hibernate | chỉ persistent, giữ cả RAM |

Hibernate rất hữu ích cho tải chạy lâu:

Tiến trình chạy 25 phút thì bị thu hồi
    → hibernate lưu RAM vào EBS
    → khởi động lại tiếp tục TỪ CHỖ DỪNG
        ↓
    Không phải chạy lại 25 phút đó

Ba điều kiện dùng Spot: | Điều kiện | Đề có? | |---|---| | Stateless hoặc lưu trạng thái ra ngoài | ✅ | | Chịu được gián đoạn | ✅ nói rõ | | Nhiều loại instance thay thế | cần cấu hình |

Các mô hình mua EC2 — nhắc lại: | Mô hình | Tiết kiệm | Rủi ro | |---|---|---| | On-Demand | 0% | không | | Savings Plans / RI | tới 72% | cam kết dài hạn | | Spot | tới 90% | bị thu hồi |

Ba cơ chế xử lý thu hồi: | Cơ chế | Chi tiết | |---|---| | Thông báo trước 2 phút | metadata /spot/instance-action | | Rebalance recommendation | cảnh báo sớm hơn | | Persistent request | ← câu này, tự khởi động lại |

Kiểm tra thông báo trong script:

while true; do
  if curl -s -f http://169.254.169.254/latest/meta-data/spot/instance-action >/dev/null; then
    echo "Sap bi thu hoi — luu trang thai"
    aws s3 cp /tmp/tien-do.json s3://kho-trang-thai/
    break
  fi
  sleep 5
done &

Ba yếu tố tăng khả năng có Spot: | Yếu tố | Chi tiết | |---|---| | Nhiều loại instance | quan trọng nhất | | Nhiều AZ | | | Chạy vào giờ thấp điểm | ← tiến trình hằng đêm có lợi thế này |

Ba lựa chọn chạy tác vụ theo lịch: | Lựa chọn | Đặc điểm | |---|---| | EventBridge Scheduler + EC2 Spot | ← câu này | | AWS Batch với Spot | tự quản hàng đợi và năng lực | | ECS scheduled task trên Fargate Spot | container |

AWS Batch đáng cân nhắc:

aws batch submit-job --job-name tien-trinh-hang-dem   --job-queue hang-doi-spot --job-definition xu-ly-python

Batch tự lo:
    ✓ khởi động instance khi có việc
    ✓ tắt khi xong
    ✓ THỬ LẠI khi Spot bị thu hồi
        ↓
    Ít việc phải tự dựng hơn Spot request thủ công

Ba lưu ý về EventBridge Scheduler: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ cron và rate expression | | | Có múi giờ và lịch linh hoạt | | | Gọi trực tiếp API của AWS | không cần Lambda trung gian |

aws scheduler create-schedule --name chay-hang-dem   --schedule-expression "cron(0 2 * * ? *)"   --schedule-expression-timezone "Asia/Ho_Chi_Minh"   --flexible-time-window Mode=OFF   --target '{"Arn":"arn:aws:scheduler:::aws-sdk:batch:submitJob",
             "RoleArn":"<arn-role>","Input":"{...}"}'

Ba cách giảm chi phí thêm: | Cách | Tiết kiệm | |---|---| | Graviton (ARM) | ~20% | | Kích thước instance vừa đủ | | | Tự chấm dứt khi xong | không để máy chạy không |

Ba lưu ý về xem giá Spot: | Lưu ý | Chi tiết | |---|---| | Giá thay đổi dần theo cung cầu | không đấu giá đột biến | | Không cần đặt max price | mặc định là giá On-Demand | | Xem lịch sử để chọn loại instance ổn định | |

aws ec2 describe-spot-price-history --instance-types m6i.large   --product-descriptions "Linux/UNIX" --max-items 10

Và một lời khuyên: hãy cân nhắc AWS Batch thay vì tự quản Spot request. Nó xử lý sẵn việc thử lại khi bị thu hồi, tự tắt máy khi xong, và ghi lại lịch sử mỗi lần chạy — ba thứ mà một persistent Spot request đơn lẻ để bạn tự lo, và thường bị bỏ qua cho tới đêm đầu tiên tiến trình không chạy mà không ai biết.

Câu 752 Chọn nhiều đáp án Design High-Performing Architectures

A company's real-time streaming application is running on AWS. As the data is ingested, a job runs on the data and takes 30 minutes to complete. The workload frequently experiences high latency due to large amounts of incoming data. A solutions architect needs to design a scalable and serverless solution to enhance performance.

Which combination of steps should the solutions architect take? (Select two)

  1. A

    Provision Amazon EC2 instances in an Auto Scaling group to process the data
  2. B

    Set up AWS Database Migration Service (AWS DMS) to ingest the data
  3. C

    Set up AWS Lambda with AWS Step Functions to process the data
  4. D

    Set up Amazon Kinesis Data Streams to ingest the data
  5. E

    Set up AWS Fargate with Amazon ECS to process the data
Xem giải thích

Đáp án

D và E.

  • D — Dùng Amazon Kinesis Data Streams để nạp dữ liệu
  • E — Dùng AWS Fargate với Amazon ECS để xử lý dữ liệu

Vì sao đúng

Đề nêu ba ràng buộc, và cặp Kinesis + Fargate đáp ứng cả ba: | Ràng buộc | Cơ chế | |---|---| | Ứng dụng luồng thời gian thực | Kinesis nạp với độ trễ dưới một giây | | Job chạy 30 PHÚT | loại Lambda — Fargate không giới hạn thời gian | | Serverless và co giãn | cả hai đều serverless |

Con số 30 phút là điểm loại trừ quyết định:

AWS Lambda: trần 15 PHÚT
    → job 30 phút KHÔNG chạy được
        ↓
    Đây là lý do phương án C sai

Và Fargate là lựa chọn serverless không giới hạn thời gian:

AWS Fargate:
    ✓ không quản máy chủ
    ✓ KHÔNG giới hạn thời gian chạy
    ✓ co giãn theo số task
    ✓ trả theo vCPU-giây và GB-giây
        ↓
    Đúng "scalable and serverless" mà vẫn chạy được 30 phút

Kiến trúc:

Nguồn dữ liệu
    ↓ PutRecords
Kinesis Data Streams (on-demand)
    ↓ KCL consumer
ECS trên Fargate — task xử lý 30 phút
    ↓
S3 / DynamoDB (kết quả)

Và co giãn ECS theo độ sâu luồng:

aws application-autoscaling put-scaling-policy   --service-namespace ecs   --resource-id service/cum-xu-ly/dich-vu-xu-ly   --scalable-dimension ecs:service:DesiredCount   --policy-name theo-do-tre --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 60000,
    "CustomizedMetricSpecification": {
      "MetricName":"GetRecords.IteratorAgeMilliseconds",
      "Namespace":"AWS/Kinesis","Statistic":"Maximum",
      "Dimensions":[{"Name":"StreamName","Value":"luong-du-lieu"}]}}'

Co giãn theo IteratorAgeMilliseconds — phản ánh trực tiếp việc consumer có theo kịp không.

Và Kinesis on-demand tự co giãn phía nạp:

aws kinesis create-stream --stream-name luong-du-lieu   --stream-mode-details StreamMode=ON_DEMAND

Đề nói "high latency due to LARGE AMOUNTS of incoming data" — on-demand loại bỏ nút thắt shard.

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

  • **C. Dùng Lambda với Step Functions để xử lý — đây là phương án gần nhất và là kiến trúc serverless đẹp, nhưng nó vướng giới hạn 15 phút của Lambda: job chạy 30 phút không hoàn thành được trong một lần gọi. (Chia nhỏ job thành nhiều bước Lambda là cách vòng, nhưng đòi tái cấu trúc mà đề không nêu.)
  • **A. Dùng EC2 trong Auto Scaling group — không phải serverless: phải quản lý AMI, vá lỗi, kích thước instance. Đề yêu cầu rõ giải pháp serverless.
  • **B. Dùng AWS DMS để nạp dữ liệu — sai công cụ: DMS di chuyển và sao chép database, không phải dịch vụ nạp luồng dữ liệu thời gian thực từ ứng dụng.

Ghi nhớ

Giới hạn thời gian chạy — bảng phải thuộc: | Dịch vụ | Tối đa | |---|---| | AWS Lambda | 15 phút | | AWS Fargate | không giới hạn | | AWS Batch | không giới hạn | | EC2 | không giới hạn |

Câu hỏi nào nêu thời gian xử lý trên 15 phút là loại ngay Lambda.

Ba lựa chọn tính toán serverless: | Lựa chọn | Đặc điểm | |---|---| | Lambda | sự kiện, dưới 15 phút, khởi động nhanh | | Fargate | container, không giới hạn thời gian | | App Runner | ứng dụng web container, đơn giản nhất |

Fargate và Lambda — bảng phân biệt: | | Lambda | Fargate | |---|---|---| | Thời gian chạy | 15 phút | không giới hạn | | Khởi động | mili giây | vài chục giây | | Bộ nhớ | tới 10 GB | tới 120 GB | | Đóng gói | ZIP hoặc container | container | | Trả tiền | GB-giây | vCPU-giây và GB-giây |

Ba dịch vụ nạp luồng dữ liệu: | Dịch vụ | Đặc điểm | |---|---| | Kinesis Data Streams | thời gian thực, nhiều consumer, phát lại được | | Kinesis Data Firehose | nạp vào đích, độ trễ ~60 giây | | Amazon MSK | Kafka được quản lý |

Hai chế độ dung lượng của Kinesis: | Chế độ | Đặc điểm | |---|---| | Provisioned | khai shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn tới 200 MB/giây ← phù hợp với đề |

Ba metric của Kinesis cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAgeMilliseconds | consumer tụt lại bao xa — dùng để co giãn | | WriteProvisionedThroughputExceeded | throttle phía ghi | | IncomingRecords | lượng bản ghi |

Metric đầu là chỉ báo tốt nhất cho vấn đề trong đề:

"workload frequently experiences HIGH LATENCY"
        ↓
    IteratorAgeMilliseconds tăng
    → consumer xử lý chậm hơn tốc độ ghi
        ↓
    Cần thêm task Fargate

Ba cách đọc từ Kinesis: | Cách | Đặc điểm | |---|---| | KCL (Kinesis Client Library) | quản lý checkpoint và cân bằng shard | | Lambda event source mapping | được quản lý, giới hạn 15 phút | | SDK trực tiếp | linh hoạt nhất |

KCL đáng dùng với Fargate:

KCL tự lo:
    ✓ theo dõi vị trí đọc (checkpoint trong DynamoDB)
    ✓ chia shard giữa các worker
    ✓ xử lý khi shard tách hoặc gộp
        ↓
    Thêm task Fargate → KCL tự phân bổ lại shard

Ba cấu hình task Fargate: | Cấu hình | Chi tiết | |---|---| | CPU và bộ nhớ | 0,25–16 vCPU, 0,5–120 GB | | Ephemeral storage | 20–200 GB | | Fargate Spot | rẻ hơn ~70% |

Fargate Spot phù hợp nếu job chạy lại được:

{"capacityProviderStrategy": [
  {"capacityProvider": "FARGATE", "base": 1, "weight": 1},
  {"capacityProvider": "FARGATE_SPOT", "weight": 4}]}

Một task On-Demand làm nền, phần còn lại dùng Spot.

Ba lưu ý khi xử lý luồng bằng task chạy lâu: | Lưu ý | Chi tiết | |---|---| | Checkpoint thường xuyên | task bị dừng không mất nhiều việc | | Xử lý được tín hiệu SIGTERM | dọn dẹp trước khi tắt | | Đặt stopTimeout đủ dài | mặc định 30 giây |

Ba lựa chọn thay thế cho Fargate: | Lựa chọn | Khi nào | |---|---| | AWS Batch trên Fargate | job theo lô có hàng đợi | | Managed Service for Apache Flink | phân tích luồng theo cửa sổ thời gian | | EMR Serverless | Spark quy mô lớn |

Managed Flink đáng cân nhắc:

Nếu job 30 phút là phép tổng hợp theo cửa sổ:
    → Flink làm việc đó nguyên bản và liên tục
    → không cần chờ 30 phút mới có kết quả
        ↓
    Có thể loại bỏ hẳn độ trễ trong đề

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Fargate tính theo vCPU-giây và GB-giây | | | Kinesis on-demand đắt hơn provisioned khi tải cao ổn định | | | Fargate Spot giảm ~70% | |

Và một lời khuyên: hãy xem lại vì sao job cần tới 30 phút trước khi tối ưu hạ tầng. Nếu đó là phép tổng hợp trên cửa sổ dữ liệu, Managed Service for Apache Flink cho kết quả liên tục thay vì mỗi 30 phút một lần — và khi đó vấn đề độ trễ trong đề biến mất hoàn toàn thay vì chỉ được giảm bớt.

Câu 753 Design Secure Architectures

A digital media firm is scaling its cloud footprint and wants to isolate development, testing, and production workloads using separate AWS accounts. It also wants a centralized approach to managing networking infrastructure such as subnets and gateways, without repeating configurations in every account. Additionally, the solution must enforce security best practices—like mandatory logging and guardrails—when new accounts are created. The firm prefers a low-maintenance, governance-driven setup.

Which solution best meets these goals while minimizing operational overhead?

  1. A

    Use AWS Service Catalog to define pre-approved VPC templates. Launch one VPC per workload account from the catalog, and enforce networking guardrails using AWS Config conformance packs
  2. B

    Use AWS Organizations to create new accounts and a shared networking account with a central VPC. Share the VPC subnets via AWS RAM and rely on service control policies (SCPs) to enforce guardrails manually
  3. C

    Use AWS Control Tower to launch accounts. Deploy separate VPCs in each workload account and centralize security inspection by using Gateway Load Balancers to route traffic through a shared security appliance
  4. D

    Use AWS Control Tower to create and govern accounts. Deploy a centralized VPC in a shared networking account and share its subnets across workload accounts using AWS Resource Access Manager (AWS RAM)
Xem giải thích

Đáp án

D — Dùng AWS Control Tower để tạo và quản trị tài khoản; triển khai VPC tập trung ở một tài khoản mạng dùng chung và chia sẻ subnet cho các tài khoản tải qua AWS Resource Access Manager (RAM).

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án D đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Tách dev, test, prod bằng tài khoản riêng | Control Tower tạo tài khoản | | Quản lý mạng TẬP TRUNG, không lặp cấu hình | VPC dùng chung qua RAM | | Ép log bắt buộc và guardrail khi tạo tài khoản mới | Control Tower control (guardrail) | | Ít bảo trì, hướng quản trị | Control Tower tự động hoá toàn bộ |

VPC sharing là điểm mấu chốt của vế "không lặp cấu hình":

Mỗi tài khoản một VPC riêng:
    → lặp lại subnet, NAT Gateway, route table, endpoint
    → mỗi VPC cần NAT riêng (~32 USD/tháng mỗi cái)
    → phải nối chúng với nhau (peering hoặc TGW)

VPC dùng chung qua RAM:
    → MỘT VPC ở tài khoản mạng
    → chia subnet cho các tài khoản tải
    → tài nguyên của họ chạy TRONG subnet đó
        ↓
    Một bộ NAT Gateway, một bộ VPC endpoint, một bộ route table

Chia sẻ subnet:

aws ram create-resource-share --name chia-se-subnet   --resource-arns arn:aws:ec2:ap-northeast-1:111111111111:subnet/subnet-a                   arn:aws:ec2:ap-northeast-1:111111111111:subnet/subnet-c   --principals arn:aws:organizations::111111111111:ou/o-abc/ou-tai-nguyen

Và mô hình quyền rất rõ ràng: | Vai trò | Quyền | |---|---| | Tài khoản chủ VPC | quản lý VPC, subnet, route table, endpoint | | Tài khoản tham gia | tạo EC2, RDS, ALB trong subnet được chia sẻ | | — | tài khoản tham gia KHÔNG sửa được cấu hình mạng |

Ba lợi ích cụ thể: | Lợi ích | Chi tiết | |---|---| | Tiết kiệm NAT Gateway đáng kể | một bộ thay vì mỗi tài khoản một bộ | | Không cần peering hay Transit Gateway giữa các tài khoản | cùng VPC | | Quản trị mạng ở một chỗ | |

Và Control Tower lo phần guardrail:

Control Tower tự động khi tạo tài khoản mới:
    ✓ CloudTrail tổ chức (log bắt buộc)
    ✓ AWS Config
    ✓ Log lưu tập trung ở tài khoản Log Archive
    ✓ Áp control (preventive và detective)
        ↓
    Đúng "enforce security best practices when new accounts are created"

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

  • **B. Dùng AWS Organizations tạo tài khoản + tài khoản mạng dùng chung + RAM, nhưng guardrail phải áp SCP THỦ CÔNG — đây là phương án gần nhất và kiến trúc mạng hoàn toàn đúng, nhưng nó thiếu phần tự động hoá quản trị: Organizations không tự thiết lập CloudTrail, Config, log tập trung cho tài khoản mới. Control Tower làm việc đó tự động.
  • **C. Control Tower + VPC RIÊNG ở mỗi tài khoản + Gateway Load Balancer kiểm tra tập trung — lặp lại cấu hình mạng, đúng điều đề muốn tránh. Và GWLB giải quyết vấn đề kiểm tra lưu lượng, không phải vấn đề quản lý mạng tập trung.
  • **A. Dùng Service Catalog định nghĩa template VPC, mỗi tài khoản một VPC — vẫn là một VPC mỗi tài khoản: template chỉ làm việc tạo VPC nhất quán hơn, không loại bỏ việc lặp lại hạ tầng.

Ghi nhớ

Ba dịch vụ quản trị đa tài khoản — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS Organizations | nền tảng: tài khoản, OU, SCP, hoá đơn gộp | | AWS Control Tower | thiết lập landing zone TỰ ĐỘNG trên Organizations | | AWS RAM | chia sẻ TÀI NGUYÊN giữa các tài khoản |

Organizations và Control Tower — bảng phân biệt: | | Organizations | Control Tower | |---|---|---| | Tạo tài khoản | ✅ | ✅ qua Account Factory | | SCP | ✅ | ✅ (gọi là control) | | Tự thiết lập CloudTrail, Config | ❌ | ✅ | | Log tập trung | ❌ | ✅ Log Archive account | | Bảng điều khiển tuân thủ | ❌ | ✅ |

Control Tower là Organizations cộng thêm tự động hoá.

Ba tài khoản Control Tower tạo sẵn: | Tài khoản | Việc | |---|---| | Management | quản lý tổ chức | | Log Archive | lưu CloudTrail và Config log của MỌI tài khoản | | Audit | truy cập chỉ đọc cho kiểm toán |

Ba loại control (guardrail): | Loại | Cơ chế | |---|---| | Preventive | SCP — CHẶN hành động | | Detective | Config rule — PHÁT HIỆN vi phạm | | Proactive | CloudFormation hook — chặn trước khi triển khai |

Ba mức bắt buộc: | Mức | Chi tiết | |---|---| | Mandatory | luôn bật, không tắt được | | Strongly recommended | nên bật | | Elective | tuỳ chọn |

Ba tài nguyên chia sẻ được qua RAM: | Tài nguyên | Chi tiết | |---|---| | VPC subnet | ← câu này | | Transit Gateway | | | Route 53 Resolver rule | | | License Manager, Aurora DB cluster, ACM Private CA | |

Ba lưu ý về VPC sharing: | Lưu ý | Chi tiết | |---|---| | Tài khoản tham gia KHÔNG sửa được VPC | chỉ dùng subnet | | Security group tạo trong tài khoản tham gia | nhưng thuộc VPC chung | | Flow log và NAT do tài khoản chủ quản lý | |

Ba mô hình mạng đa tài khoản: | Mô hình | Đặc điểm | |---|---| | VPC dùng chung (RAM) | đơn giản nhất, một VPC ← câu này | | VPC riêng + Transit Gateway | cách ly mạng mạnh hơn, phức tạp hơn | | VPC riêng + peering | không mở rộng được |

Chọn giữa hai mô hình đầu:

VPC dùng chung:
    ✓ ít hạ tầng lặp lại nhất
    ✓ rẻ nhất
    ✗ cách ly mạng yếu hơn (cùng một VPC)

VPC riêng + Transit Gateway:
    ✓ cách ly mạng rõ ràng
    ✗ mỗi VPC cần NAT, endpoint riêng
    ✗ phí attachment TGW (~36 USD/tháng mỗi cái)

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Control Tower | miễn phí, chỉ trả phí dịch vụ bên dưới | | RAM | miễn phí | | Config và CloudTrail | có phí, tăng theo số tài khoản |

Ba việc Control Tower làm khi tạo tài khoản mới: | Việc | Chi tiết | |---|---| | Đưa vào OU đã chọn | kế thừa control | | Bật CloudTrail và Config | gửi log về Log Archive | | Tạo IAM Identity Center permission set | |

Ba lưu ý về cấu trúc OU: | Lưu ý | Chi tiết | |---|---| | Nhóm theo môi trường hoặc theo chức năng | | | SCP áp ở cấp OU | | | Tài khoản Management KHÔNG bị SCP ràng buộc | |

Dòng cuối là lý do không chạy tải trong tài khoản Management.

Ba việc nên làm khi thiết lập: | Việc | Chi tiết | |---|---| | Quy hoạch dải CIDR trước | tránh chồng lấn | | Thiết kế cấu trúc OU trước khi tạo tài khoản | | | Bắt đầu với ít control, mở rộng dần | |

Và một lời khuyên: hãy quy hoạch dải CIDR cho toàn tổ chức trước khi tạo VPC đầu tiên. Dù chọn VPC dùng chung hay Transit Gateway, việc chồng lấn địa chỉ là thứ không sửa được mà không dựng lại — và nó chỉ lộ ra khi bạn cần nối hai mạng lại với nhau, tức là rất lâu sau khi quyết định ban đầu đã bị quên.

Câu 754 Design Cost-Optimized Architectures

A healthcare analytics firm operates a backend application within a private subnet of its VPC. The application is fronted by an Application Load Balancer (ALB) and accesses Amazon S3 to store medical reports. The VPC includes both a NAT gateway and an internet gateway, but the company's strict compliance policy prohibits any data traffic from traversing the internet. The team must redesign the architecture to comply with the security policy and improve cost-efficiency.

Which solution best satisfies these requirements in the most cost-effective manner?

  1. A

    Create an S3 interface VPC endpoint and modify the security group to allow access from the application’s private subnet. Route all S3 traffic through the interface endpoint
  2. B

    Create a gateway VPC endpoint for Amazon S3 and update the route table for the private subnet to direct S3 traffic through the endpoint
  3. C

    Modify the S3 bucket policy to allow requests only from the Elastic IP address associated with the NAT gateway
  4. D

    Create a VPC peering connection with another VPC that has direct access to S3. Forward the S3 API requests through the peered VPC using proxy EC2 instances
Xem giải thích

Đáp án

B — Tạo gateway VPC endpoint cho Amazon S3 và cập nhật route table của private subnet để định tuyến lưu lượng S3 qua endpoint đó.

Vì sao đúng

Đề nêu hai yêu cầu, và gateway endpoint đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | KHÔNG có lưu lượng nào đi qua Internet | lưu lượng đi trong mạng riêng của AWS | | Tiết kiệm chi phí nhất | gateway endpoint MIỄN PHÍ |

Cơ chế:

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

Triển khai:

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-private-a rtb-private-c

Và điểm "cost-effective" rất rõ: | Cách | Chi phí | |---|---| | Gateway endpoint | 0 USD | | Interface endpoint | ~0,01 USD/giờ mỗi AZ + 0,01 USD/GB | | NAT Gateway | ~32 USD/tháng + 0,045 USD/GB |

Phép tính với 5 TB báo cáo y tế mỗi tháng:

Qua NAT Gateway: 32 + (5.000 × 0,045) = 257 USD/tháng
Qua gateway endpoint: 0 USD
        ↓
    Và còn tuân thủ chính sách cấm đi Internet

Và bắt buộc lưu lượng phải qua endpoint:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::bao-cao-y-te",
              "arn:aws:s3:::bao-cao-y-te/*"],
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Chặn MỌI truy cập không qua VPC endpoint
    → kể cả từ Internet với credential hợp lệ
        ↓
    Bằng chứng tuân thủ rõ ràng cho kiểm toán viên

Và sau đó gỡ được NAT Gateway nếu không còn nhu cầu khác — tiết kiệm thêm.

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

  • **A. Tạo INTERFACE VPC endpoint cho S3 và sửa security group — đây là phương án gần nhất và cũng giữ lưu lượng riêng tư, nhưng nó đắt hơn không cần thiết: interface endpoint tính phí theo giờ mỗi AZ cộng phí theo GB, trong khi gateway endpoint hoàn toàn miễn phí. (Interface endpoint chỉ cần khi truy cập S3 từ on-premises qua VPN/DX.)
  • **C. Sửa bucket policy chỉ cho phép Elastic IP của NAT Gateway — lưu lượng VẪN đi qua Internet: NAT chỉ dịch địa chỉ, request vẫn tới endpoint công cộng của S3. Vi phạm chính sách tuân thủ.
  • **D. VPC peering với VPC khác có quyền truy cập S3, chuyển tiếp qua EC2 proxy — phức tạp, đắt và vô lý: mọi VPC đều truy cập S3 được, không cần peering. Và proxy EC2 tạo nút thắt và điểm hỏng mới.

Ghi nhớ

Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ hỗ trợ | 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 + theo GB | | Từ on-premises | ❌ | ✅ qua VPN/DX | | Security group | ❌ | ✅ | | DNS riêng | ❌ | ✅ |

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

Ba lợi ích của VPC endpoint: | Lợi ích | Chi tiết | |---|---| | Lưu lượng KHÔNG ra Internet | ← yêu cầu tuân thủ | | Tiết kiệm phí NAT Gateway | đáng kể với khối lượng lớn | | Kiểm soát bằng endpoint policy | |

Endpoint policy giới hạn thêm:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::bao-cao-y-te/*"}]}

Chỉ cho phép thao tác với đúng bucket cần dùng qua endpoint này.

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ì | | Bucket policy | ai truy cập bucket | | Endpoint policy | những gì đi qua endpoint được phép |

Cả ba đều phải Allow — đây là nguồn của những lỗi "Access Denied" khó hiểu.

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Phải gắn vào ĐÚNG route table của subnet | | | Chỉ hoạt động TRONG Region | không tới bucket ở Region khác | | Không dùng được 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 (ssm, ssmmessages, ec2messages) | interface | | Secrets Manager, KMS, ECR, CloudWatch Logs | interface |

Ba endpoint SSM là bộ bắt buộc nếu dùng Session Manager:

Thiếu một trong ba
    → instance không hiện trong Fleet Manager
    → Session Manager không kết nối được

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

aws cloudtrail lookup-events   --lookup-attributes AttributeKey=EventName,AttributeValue=PutObject   --query 'Events[].CloudTrailEvent' --output text | grep vpcEndpointId

Ba biện pháp bảo mật cho dữ liệu y tế: | Biện pháp | Chi tiết | |---|---| | Mã hoá SSE-KMS với customer managed key | audit việc dùng khoá | | aws:SourceVpce trong bucket policy | ép đi qua endpoint | | CloudTrail data event | ghi mọi thao tác object |

Ba yêu cầu tuân thủ HIPAA liên quan: | Yêu cầu | Cơ chế | |---|---| | Ký BAA với AWS | bắt buộc | | Mã hoá at rest và in transit | KMS + TLS | | Ghi log truy cập | CloudTrail |

Ba lưu ý về NAT Gateway sau khi có endpoint: | Lưu ý | Chi tiết | |---|---| | Vẫn cần nếu ứng dụng gọi API bên ngoài | | | Gỡ được nếu chỉ dùng dịch vụ AWS | thêm interface endpoint | | Kiểm tra Flow Logs xem còn lưu lượng gì đi ra | |

Ba lưu ý về chi phí NAT Gateway: | Khoản | Giá tham khảo | |---|---| | Phí giờ | ~0,045 USD/giờ (~32 USD/tháng) | | Phí xử lý dữ liệu | ~0,045 USD/GB | | Một NAT mỗi AZ cho sẵn sàng cao | nhân lên theo AZ |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BytesProcessed của NAT | giảm mạnh sau khi có endpoint | | VPC Flow Logs | đường đi thực tế | | Chi phí NatGateway-Bytes trong Cost Explorer | |

Và một lời khuyên: hãy thêm điều kiện aws:SourceVpce vào bucket policy ngay sau khi tạo endpoint. Endpoint chỉ cho phép đường đi riêng tư chứ không bắt buộc nó — và với yêu cầu tuân thủ nghiêm ngặt, bạn cần chứng minh rằng không có đường nào khác, chứ không chỉ rằng đường riêng tư có tồn tại.

Câu 755 Chọn nhiều đáp án Design High-Performing Architectures

A company uses Amazon DynamoDB as a data store for various kinds of customer data, such as user profiles, user events, clicks, and visited links. Some of these use-cases require a high request rate (millions of requests per second), low predictable latency, and reliability. The company now wants to add a caching layer to support high read volumes.

As a solutions architect, which of the following AWS services would you recommend as a caching layer for this use-case? (Select two)

  1. A

    Amazon Redshift
  2. B

    Amazon OpenSearch Service
  3. C

    Amazon ElastiCache
  4. D

    Amazon Relational Database Service (Amazon RDS)
  5. E

    Amazon DynamoDB Accelerator (DAX)
Xem giải thích

Đáp án

C và E.

  • C — Amazon ElastiCache
  • E — Amazon DynamoDB Accelerator (DAX)

Vì sao đúng

Đề nêu ba yêu cầu, và cả hai dịch vụ đều là lớp đệm trong bộ nhớ: | Yêu cầu | Cơ chế | |---|---| | Hàng triệu request mỗi giây | cả hai đều là in-memory | | Độ trễ thấp và ĐOÁN ĐƯỢC | micro giây | | Tin cậy | Multi-AZ với replica |

Hai lựa chọn với hai đặc điểm khác nhau: | | DAX | ElastiCache | |---|---|---| | Dùng cho | CHỈ DynamoDB | mọi nguồn dữ liệu | | Sửa mã ứng dụng | chỉ đổi client | phải viết logic đệm | | Vô hiệu hoá cache | TỰ ĐỘNG khi ghi qua DAX | tự lo | | Cấu trúc dữ liệu | chỉ item DynamoDB | phong phú |

DAX là lựa chọn tự nhiên nhất vì dữ liệu đã ở DynamoDB:

# Trước
import boto3
bang = boto3.resource('dynamodb').Table('ho-so-nguoi-dung')

# Sau — CHỈ đổi client
from amazondax import AmazonDaxClient
dax = AmazonDaxClient.resource(endpoint_url='dax://cum.abc.dax-clusters.amazonaws.com')
bang = dax.Table('ho-so-nguoi-dung')

Mọi lời gọi get_item, query, put_item giữ nguyên.

Và ElastiCache linh hoạt hơn cho các trường hợp phức tạp:

Dữ liệu trong đề gồm: hồ sơ người dùng, sự kiện, cú nhấp, liên kết đã xem
        ↓
    Một số cần cấu trúc dữ liệu đặc biệt:
        → sorted set cho bảng xếp hạng
        → set cho danh sách liên kết đã xem
        → counter cho số lần nhấp
        ↓
    DAX không làm được những việc này, Redis thì có

Tạo cụm DAX:

aws dax create-cluster --cluster-name cum-dax   --node-type dax.r5.large --replication-factor 3   --iam-role-arn <arn-role>   --subnet-group-name nhom-subnet --security-group-ids sg-dax

Và ElastiCache:

aws elasticache create-replication-group   --replication-group-id cum-dem --engine redis   --cache-node-type cache.r6g.large --num-cache-clusters 3   --automatic-failover-enabled --multi-az-enabled

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

  • **B. Amazon OpenSearch Service — đây là phương án gần nhất vì cũng phục vụ được truy vấn nhanh, nhưng nó không phải lớp đệm: OpenSearch là công cụ tìm kiếm và phân tích log, độ trễ tính bằng mili giây chứ không phải micro giây, và nó đòi lập chỉ mục dữ liệu.
  • **A. Amazon Redshift — sai loại hoàn toàn: kho dữ liệu phân tích, tối ưu cho truy vấn quét lớn, không phải đệm tra cứu.
  • **D. Amazon RDS — cũng không phải đệm: database quan hệ trên đĩa, chậm hơn nhiều so với in-memory.

Ghi nhớ

Ba dịch vụ đệm của AWS — bảng phải thuộc: | Dịch vụ | Đệm cho | |---|---| | ElastiCache (Redis/Memcached) | mọi nguồn dữ liệu | | DynamoDB Accelerator (DAX) | CHỈ DynamoDB | | CloudFront | nội dung HTTP ở biên |

Từ khoá nhận diện:

"cache for DynamoDB", "minimal code change" → DAX "cache any data source", "rich data structures" → ElastiCache "cache web content globally" → CloudFront

Hai loại cache trong DAX: | Loại | Đệm gì | TTL mặc định | |---|---|---| | Item cache | GetItem, BatchGetItem | 5 phút | | Query cache | Query, Scan | 5 phút |

Query cache bị xoá sạch khi có ghi vào bảng:

Ghi một item bất kỳ
    → toàn bộ query cache của bảng bị vô hiệu
        ↓
    Bảng ghi nhiều → query cache gần như vô dụng
    → nhưng item cache vẫn hiệu quả

Ba lưu ý quan trọng về DAX: | Lưu ý | Chi tiết | |---|---| | Nhất quán CUỐI CÙNG | ConsistentRead=True bỏ qua cache | | Chỉ chạy trong VPC | không gọi từ Internet | | Có phí theo node-giờ | như ElastiCache |

Redis và Memcached — nhắc lại: | | Redis / Valkey | Memcached | |---|---|---| | Cấu trúc dữ liệu | phong phú | chỉ key-value | | Sao chép, Multi-AZ | ✅ | ❌ | | Bền vững | ✅ | ❌ | | Đa luồng | I/O threading | ✅ |

Ba mẫu đệm: | Mẫu | Cơ chế | |---|---| | Lazy loading (cache-aside) | đọc trượt thì nạp | | Write-through | ghi cả hai nơi | | TTL | tự hết hạn |

Ba nguyên nhân cần lớp đệm cho DynamoDB: | Nguyên nhân | Chi tiết | |---|---| | Hot partition | item cụ thể được đọc rất nhiều | | Giảm chi phí RCU | đọc từ cache không tốn RCU | | Giảm độ trễ xuống micro giây | |

Ba giới hạn của DynamoDB liên quan: | Giới hạn | Giá trị | |---|---| | Thông lượng mỗi partition | 3.000 RCU hoặc 1.000 WCU | | Kích thước item | 400 KB | | Số GSI mỗi bảng | 20 |

Dòng đầu là lý do cần DAX cho hot partition:

Tăng RCU của BẢNG không nâng được trần của một PARTITION
    → item nóng vẫn bị throttle
        ↓
    DAX phục vụ item đó từ bộ nhớ, không chạm partition

Ba cách phát hiện hot partition: | Cách | Việc | |---|---| | CloudWatch Contributor Insights | partition key nào bị truy cập nhiều nhất | | ThrottledRequests | bị giới hạn dù bảng còn dung lượng | | ConsumedReadCapacityUnits | |

aws dynamodb update-contributor-insights --table-name ho-so-nguoi-dung   --contributor-insights-action ENABLE

Ba metric của DAX: | Metric | Ý nghĩa | |---|---| | ItemCacheHits và ItemCacheMisses | tỷ lệ trúng | | QueryCacheHits | | | CPUUtilization của node | |

Ba cấu hình cho DAX sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Ít nhất 3 node | trải nhiều AZ | | Subnet group nhiều AZ | | | Security group cổng 8111 (hoặc 9111 cho TLS) | |

Ba lưu ý khi kết hợp cả hai dịch vụ: | Lưu ý | Chi tiết | |---|---| | DAX cho tra cứu item DynamoDB | | | ElastiCache cho dữ liệu tổng hợp và cấu trúc phức tạp | | | Tránh đệm hai lớp cho cùng dữ liệu | khó vô hiệu hoá |

Dòng cuối đáng lưu ý:

Đệm cùng dữ liệu ở cả DAX lẫn ElastiCache
    → phải vô hiệu hoá ở hai nơi khi ghi
    → dễ sinh dữ liệu không nhất quán
        ↓
    Phân chia rõ ràng: mỗi loại dữ liệu một lớp đệm

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | DAX và ElastiCache tính theo node-giờ | | | Nhưng giảm RCU cần thiết của DynamoDB | có thể bù lại | | Reserved node giảm tới 55% | |

Và một lời khuyên: hãy bật Contributor Insights trước khi triển khai lớp đệm. Nó xác nhận vấn đề thật sự là vài item nóng chứ không phải lưu lượng phân bố đều — và nếu là trường hợp thứ hai, việc thiếu dung lượng nằm ở thiết kế khoá chứ không phải ở việc thiếu bộ đệm.

Câu 756 Design Secure Architectures

A global enterprise maintains a hybrid cloud environment and wants to transfer large volumes of data between its on-premises data center and Amazon S3 for backup and analytics workflows. The company has already established a Direct Connect (DX) connection to AWS and wants to ensure high-bandwidth, low-latency, and secure private connectivity without traversing the public internet. The architecture must be designed to access Amazon S3 directly from on-premises systems using this DX connection.

Which configuration should the network engineering team implement to allow direct access to Amazon S3 from the on-premises data center using Direct Connect?

  1. A

    Configure a VPN connection over the public internet to AWS and route S3 traffic through the tunnel instead of using Direct Connect
  2. B

    Provision a Public Virtual Interface (Public VIF) on the Direct Connect connection to access Amazon S3 public IP addresses from the on-premises data center
  3. C

    Use a Private Virtual Interface (Private VIF) on the Direct Connect connection and create a VPC endpoint to route traffic to S3 over the private network
  4. D

    Use a Transit Gateway with Direct Connect Gateway to route on-premises traffic through a VPC and then to Amazon S3 using private IP addressing
Xem giải thích

Đáp án

B — Tạo Public Virtual Interface (Public VIF) trên kết nối Direct Connect để truy cập địa chỉ IP công cộng của Amazon S3 từ trung tâm dữ liệu.

Vì sao đúng

Đề nêu yêu cầu: truy cập S3 TRỰC TIẾP từ on-premises qua Direct Connect, và Public VIF là cơ chế đúng.

S3 là dịch vụ có endpoint CÔNG CỘNG
    → không nằm trong VPC của bạn
        ↓
    Muốn tới nó qua Direct Connect
    → cần Public VIF (giao diện tới dịch vụ công cộng của AWS)

Ba loại virtual interface của Direct Connect: | Loại | Truy cập | |---|---| | Private VIF | tài nguyên trong VPC qua IP RIÊNG | | Public VIF | dịch vụ AWS CÔNG CỘNG (S3, DynamoDB, SQS...) | | Transit VIF | qua Transit Gateway tới nhiều VPC |

Và Public VIF không đi qua Internet:

Public VIF:
    → dùng địa chỉ IP CÔNG CỘNG của S3
    → nhưng lưu lượng đi trên đường RIÊNG của Direct Connect
        ↓
    "Công cộng" nói về không gian địa chỉ,
    KHÔNG nói về đường truyền

Đây là điểm hay gây hiểu lầm nhất về Public VIF.

Tạo Public VIF:

aws directconnect create-public-virtual-interface   --connection-id dxcon-abc   --new-public-virtual-interface '{
    "virtualInterfaceName":"vif-cong-cong",
    "vlan":101, "asn":65000,
    "amazonAddress":"175.45.176.1/30",
    "customerAddress":"175.45.176.2/30",
    "routeFilterPrefixes":[{"cidr":"203.0.113.0/24"}]}'

Và yêu cầu riêng của Public VIF: | Yêu cầu | Chi tiết | |---|---| | Địa chỉ IP công cộng do bạn sở hữu | hoặc AWS cấp | | BGP với ASN công cộng hoặc riêng | | | AWS quảng bá prefix của mọi Region | lọc được bằng BGP community |

Và ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Băng thông cao và ổn định | 1–400 Gbps | | KHÔNG đi qua Internet công cộng | | | 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 Private VIF và tạo VPC endpoint để định tuyến tới S3 qua mạng riêng — đây là phương án gần nhất và nghe rất hợp lý, nhưng nó không hoạt động với gateway endpoint: gateway endpoint cho S3 KHÔNG truy cập được từ on-premises. (Interface endpoint cho S3 thì được — nhưng phương án nói chung chung "VPC endpoint", và cách này tốn phí interface endpoint trong khi Public VIF miễn phí phần đó.)
  • **A. Dùng VPN qua Internet thay vì Direct Connect — đi ngược yêu cầu: đề nói rõ đã có Direct Connect và muốn dùng nó, tránh Internet công cộng.
  • **D. Dùng Transit Gateway với Direct Connect Gateway định tuyến qua VPC rồi tới S3 bằng IP riêng — S3 không có IP riêng: nó là dịch vụ công cộng. Và cách này thêm nhiều tầng không cần thiết.

Ghi nhớ

Ba loại virtual interface — bảng phải thuộc: | Loại | Truy cập | Cần | |---|---|---| | Private VIF | VPC (IP riêng) | Virtual Private Gateway hoặc DX Gateway | | Public VIF | dịch vụ AWS công cộng | IP công cộng, BGP | | Transit VIF | nhiều VPC qua TGW | Direct Connect Gateway |

Từ khoá nhận diện:

"access S3/DynamoDB directly from on-premises over DX" → Public VIF "access EC2/RDS in VPC over DX" → Private VIF "access many VPCs over DX" → Transit VIF

Hai cách truy cập S3 từ on-premises riêng tư: | Cách | Đặc điểm | |---|---| | Public VIF trên Direct Connect | không phí endpoint ← câu này | | Private VIF + Interface endpoint cho S3 | có phí endpoint, dùng IP riêng |

Cách thứ hai đáng biết:

Interface endpoint cho S3 (com.amazonaws.<region>.s3):
    → gán IP RIÊNG trong VPC cho S3
    → truy cập được từ on-premises qua Private VIF
        ↓
    Ưu điểm: dùng IP riêng, kiểm soát bằng security group
    Nhược điểm: có phí giờ và phí theo GB

Ba đặc điểm của Direct Connect: | Đặc điểm | Chi tiết | |---|---| | Băng thông ổn định | 1–400 Gbps | | KHÔNG mã hoá theo mặc định | chạy IPsec VPN lên trên nếu cần | | Mất hàng tuần tới tháng để thiết lập | |

Dòng giữa là điểm hay bị hỏi:

Direct Connect là đường RIÊNG nhưng KHÔNG MÃ HOÁ
    → dữ liệu đi ở dạng bản rõ
        ↓
    Yêu cầu tuân thủ đòi mã hoá → thêm VPN qua DX
    → hoặc dùng MACsec (với một số cổng)

MACsec đáng biết:

MAC Security (IEEE 802.1AE):
    → mã hoá ở tầng 2, trên chính cổng Direct Connect
    → hỗ trợ với cổng 10 Gbps, 100 Gbps chuyên dụng
        ↓
    Mã hoá mà không tốn chi phí xử lý của IPsec

Ba lợi ích chi phí của Direct Connect: | Lợi ích | Chi tiết | |---|---| | Phí truyền dữ liệu ra rẻ hơn | ~0,02 vs ~0,09 USD/GB | | Băng thông ổn định | không phụ thuộc Internet | | Độ trễ thấp và ít biến động | |

Điểm hoà vốn:

Chi phí cố định: phí cổng + phí kết nối nhà cung cấp
Tiết kiệm: (0,09 − 0,02) × số GB mỗi tháng
        ↓
    Vài chục TB egress mỗi tháng thường đã hoà vốn

Ba lưu ý về Public VIF: | Lưu ý | Chi tiết | |---|---| | Cần IP công cộng do bạn sở hữu | hoặc xin AWS cấp /31 hoặc /30 | | AWS quảng bá prefix của MỌI Region | lọc bằng BGP community | | Không truy cập được tài nguyên trong VPC | |

Ba BGP community để lọc prefix: | Community | Phạm vi | |---|---| | 7224:8100 | prefix của Region đó | | 7224:8200 | prefix của châu lục | | Không gắn | mọi prefix toàn cầu |

Chỉ cần truy cập S3 ở ap-northeast-1
    → lọc chỉ nhận community 7224:8100
        ↓
    Bảng định tuyến của router gọn hơn nhiều

Ba lưu ý về sẵn sàng cao với Direct Connect: | Lưu ý | Chi tiết | |---|---| | Một kết nối là điểm hỏng đơn | | | Hai kết nối ở hai vị trí khác nhau | khuyến nghị | | Hoặc DX + Site-to-Site VPN dự phòng | rẻ hơn |

Ba mức khả dụng của AWS: | 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ề Direct Connect Gateway: | Lưu ý | Chi tiết | |---|---| | Nối một DX tới VPC ở NHIỀU Region | | | Miễn phí | | | KHÔNG dùng với Public VIF | chỉ Private và Transit VIF |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ConnectionState | kết nối lên hay xuống | | ConnectionBpsEgress/Ingress | băng thông dùng | | ConnectionErrorCount | lỗi tầng vật lý |

Và một lời khuyên: hãy lọc BGP prefix bằng community 7224:8100 nếu chỉ cần truy cập một Region. Public VIF mặc định nhận toàn bộ prefix công cộng của AWS trên thế giới — hàng nghìn tuyến đường — và router tại chỗ của bạn có thể không đủ bộ nhớ cho bảng định tuyến đó.

Câu 757 Design Resilient Architectures

A financial services firm operates a mission-critical transaction processing platform hosted in the AWS us-east-2 Region. The backend is powered by a MySQL-compatible Amazon Aurora cluster, with high transaction volumes throughout the day. As part of its business continuity planning, the firm has selected us-west-2 as its designated disaster recovery (DR) Region.

The firm has defined strict DR objectives:

Recovery Point Objective (RPO): ≤ 5 minutes

Recovery Time Objective (RTO): ≤ 15 minutes

Leadership has asked for a DR solution that ensures fast cross-regional failover with minimal operational overhead and configuration effort. What do you recommend?

  1. A

    Deploy a separate Aurora cluster in us-west-2, and use scheduled AWS Lambda functions with custom scripts to export and import snapshots from us-east-2 every 5 minutes
  2. B

    Create an Aurora read replica in us-west-2 with equivalent capacity to the primary cluster's writer node in us-east-2. Monitor replication health and configure a manual promotion process for failover
  3. C

    Convert the Aurora cluster to an Aurora global database, with the secondary cluster deployed in us-west-2. Rely on Aurora global database managed failover to meet RTO and RPO objectives
  4. D

    Provision a separate Aurora MySQL-compatible cluster in us-west-2, and configure AWS Database Migration Service (AWS DMS) to replicate data from the primary database to the DR cluster continuously. Perform manual failover during DR events
Xem giải thích

Đáp án

C — Chuyển Aurora cluster thành Aurora Global Database với cluster phụ ở us-west-2, dựa vào managed failover của Global Database để đạt RTO và RPO.

Vì sao đúng

Đề nêu hai mục tiêu định lượng, và Aurora Global Database đáp ứng cả hai với công vận hành thấp nhất: | Mục tiêu | Aurora Global Database | |---|---| | RPO ≤ 5 phút | thường DƯỚI 1 GIÂY | | RTO ≤ 15 phút | managed failover thường dưới 1 phút | | Ít công cấu hình nhất | tính năng dựng sẵn, không viết mã |

Cơ chế sao chép của Aurora Global Database rất đặc biệt:

KHÔNG sao chép qua binlog như MySQL thường
    → sao chép ở TẦNG LƯU TRỮ, dùng hạ tầng riêng của AWS
        ↓
    Độ trễ điển hình dưới 1 giây xuyên Region
    → và KHÔNG ảnh hưởng hiệu năng của cluster chính

Dòng cuối quan trọng: sao chép không tốn tài nguyên CPU của instance chính.

Chuyển đổi:

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

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

Hai kiểu chuyển vùng: | Kiểu | Khi nào | RPO | |---|---|---| | Managed planned failover | có kế hoạch, Region chính còn khoẻ | 0 — không mất dữ liệu | | Failover (unplanned) | Region chính mất | có thể mất vài giây |

Chuyển vùng có kế hoạch:

aws rds failover-global-cluster   --global-cluster-identifier cum-toan-cau   --target-db-cluster-identifier arn:aws:rds:us-west-2:...:cluster:cum-du-phong

AWS tự:
    ✓ đồng bộ nốt dữ liệu
    ✓ đảo vai trò hai cluster
    ✓ giữ nguyên cấu trúc global cluster
        ↓
    Thường dưới một phút

Và Region phụ vẫn hữu ích khi không có sự cố:

Cluster phụ phục vụ ĐỌC cho người dùng khu vực đó
    → không phải tài nguyên nằm chờ vô ích

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

  • **B. Tạo Aurora read replica xuyên Region với cấu hình tương đương, theo dõi và promote THỦ CÔNG — đây là phương án gần nhất và có sao chép xuyên Region, nhưng nó đòi can thiệp tay: phát hiện sự cố, quyết định, rồi promote — quy trình thủ công rất khó đảm bảo RTO 15 phút, nhất là ngoài giờ hành chính.
  • **D. Cluster riêng ở us-west-2 với AWS DMS sao chép liên tục, chuyển vùng thủ công — thêm một hệ thống phải vận hành: DMS cần replication instance, cần theo dõi độ trễ CDC, và vẫn chuyển vùng thủ công.
  • **A. Cluster riêng + Lambda theo lịch xuất và nhập snapshot mỗi 5 phút — không khả thi: chụp và khôi phục snapshot của một database giao dịch cao mất nhiều hơn 5 phút, nên RPO 5 phút không đạt được. Và đây là mã tự viết phải bảo trì.

Ghi nhớ

Bốn chiến lược khôi phục thảm hoạ — bảng phải thuộc: | Chiến lược | RTO | RPO | Chi phí | |---|---|---|---| | Backup & Restore | giờ | giờ | thấp nhất | | Pilot Light | chục phút | phút | thấp | | Warm Standby | phút | giây | vừa | | Multi-Site Active/Active | gần 0 | gần 0 | cao nhất |

Aurora Global Database tương ứng với Warm Standby hoặc Active/Active.

Ba lựa chọn DR cho Aurora: | Lựa chọn | RPO | RTO | |---|---|---| | Aurora Global Database | < 1 giây | < 1 phút (managed failover) | | Cross-Region read replica | giây | phút (promote thủ công) | | Snapshot copy xuyên Region | giờ | giờ |

Ba đặc điểm của Aurora Global Database: | Đặc điểm | Chi tiết | |---|---| | Sao chép ở TẦNG LƯU TRỮ | không dùng binlog | | Tới 5 Region phụ | mỗi Region tới 16 replica đọc | | Không ảnh hưởng hiệu năng cluster chính | |

Ba khái niệm quan trọng: | Khái niệm | Việc | |---|---| | Global cluster | tài nguyên bao ngoài | | Primary cluster | DUY NHẤT được GHI | | Secondary cluster | chỉ đọc, sẵn sàng thăng cấp |

Điểm quan trọng: Aurora Global Database chỉ có MỘT writer.

Write forwarding cho phép cluster phụ nhận lệnh ghi
    → nhưng nó CHUYỂN TIẾP về primary
    → độ trễ vẫn là độ trễ xuyên Region
        ↓
    Không phải kiến trúc multi-writer

Ba lưu ý về managed planned failover: | Lưu ý | Chi tiết | |---|---| | RPO = 0 | đồng bộ nốt trước khi đảo | | Cần Region chính còn HOẠT ĐỘNG | | | Dùng cho bảo trì hoặc diễn tập | |

Và khi Region chính mất hoàn toàn:

aws rds remove-from-global-cluster   --global-cluster-identifier cum-toan-cau   --db-cluster-identifier arn:aws:rds:us-west-2:...:cluster:cum-du-phong

Tách cluster phụ ra thành cluster độc lập
    → nó trở thành cluster ghi được
        ↓
    Nhanh, nhưng phải dựng lại cấu trúc global sau đó

Ba việc cần chuẩn bị ngoài database: | Việc | Chi tiết | |---|---| | Ứng dụng sẵn sàng ở Region phụ | ASG, ALB, AMI | | DNS chuyển vùng được | Route 53 health check hoặc Global Accelerator | | Bí mật và cấu hình sao chép sang | Secrets Manager replication |

Dòng đầu quan trọng:

Database chuyển vùng trong một phút
    → nhưng nếu tầng ứng dụng chưa có ở Region đó
    → RTO thực tế vẫn là hàng giờ
        ↓
    DR là bài toán của CẢ KIẾN TRÚC, không chỉ database

Ba cách chuyển hướng lưu lượng: | Cách | Thời gian | |---|---| | Global Accelerator | ~30 giây, không đụng DNS | | Route 53 failover | phụ thuộc TTL | | Thủ công | chậm nhất |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | AuroraGlobalDBReplicationLag | độ trễ xuyên Region — kiểm chứng RPO | | AuroraGlobalDBRPOLag | RPO thực tế | | AuroraGlobalDBDataTransferBytes | lượng dữ liệu sao chép |

Đặt alarm cho metric đầu:

aws cloudwatch put-metric-alarm --alarm-name do-tre-toan-cau   --metric-name AuroraGlobalDBReplicationLag   --namespace AWS/RDS --statistic Maximum --period 300   --threshold 300000 --comparison-operator GreaterThanThreshold

300.000 mili giây = 5 phút, đúng ngưỡng RPO trong đề.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Instance ở Region phụ tính phí đầy đủ | | | Phí sao chép ~0,20 USD mỗi triệu request I/O | | | Lưu trữ tính ở cả hai Region | |

Ba cách giảm chi phí DR: | Cách | Chi tiết | |---|---| | Cluster phụ cỡ NHỎ HƠN | nâng cỡ khi chuyển vùng | | Headless secondary | cluster phụ KHÔNG có instance nào | | Dùng Aurora Serverless v2 cho Region phụ | |

Headless secondary đáng biết:

Cluster phụ chỉ có lưu trữ, không có instance
    → vẫn nhận sao chép liên tục
    → chỉ trả tiền lưu trữ
        ↓
    Khi cần: thêm instance rồi thăng cấp
    → RTO dài hơn một chút nhưng rẻ hơn nhiều

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | Diễn tập managed planned failover | hàng quý | | Đo RTO và RPO thực tế | mỗi lần diễn tập | | Kiểm tra tầng ứng dụng ở Region phụ | |

Và một lời khuyên: hãy diễn tập chuyển vùng có kế hoạch mỗi quý thay vì chỉ tin vào con số trên tài liệu. Managed failover hoạt động rất đáng tin cậy, nhưng thứ hay hỏng là mọi thứ xung quanh — cấu hình ứng dụng, hạn mức chưa nâng, bí mật chưa sao chép — và chỉ một lần diễn tập thật mới phát hiện được chúng.

Câu 758 Design Resilient Architectures

A media company is relocating its legacy infrastructure to AWS. The on-premises environment consists of multiple virtualized workloads that are tightly coupled to their host operating systems and cannot be containerized or re-architected due to software constraints. Each workload currently runs on a standalone virtual machine. The engineering team plans to run these workloads on Amazon EC2 instances without modifying their core design. The company needs a solution that ensures high availability and fault tolerance in the AWS Cloud.

Which solution will meet these requirements?

  1. A

    Use AWS Backup to schedule hourly backups of each EC2 instance to Amazon S3 in a separate Availability Zone. Create a recovery plan that includes manual restoration of instances from backup in the event of a failure
  2. B

    Containerize the legacy applications and deploy them to Amazon ECS using the Fargate launch type. Define a task for each workload, and use an Application Load Balancer to route traffic across multiple Fargate tasks running in separate Availability Zones
  3. C

    Create Amazon Machine Images (AMIs) for each legacy workload. Use the AMIs to launch Auto Scaling groups with a minimum and maximum capacity of 1 EC2 instance. Place an Application Load Balancer (ALB) in front of the Auto Scaling group to provide routing and health check-based failover.
  4. D

    Generate an Amazon Machine Image (AMI) for each legacy server. Launch two EC2 instances from this AMI, placing one instance in each of two different Availability Zones. Set up a Network Load Balancer (NLB) to route traffic to the instances and to monitor instance health for automatic traffic redirection in case of failure
Xem giải thích

Đáp án

D — Tạo AMI cho mỗi máy chủ cũ, khởi động HAI EC2 instance từ AMI đó ở HAI Availability Zone khác nhau, đặt Network Load Balancer phân phối lưu lượng và theo dõi sức khoẻ để tự chuyển hướng khi có sự cố.

Vì sao đúng

Đề nêu ba ràng buộc, và phương án D đáp ứng cả ba: | Ràng buộc | Cơ chế | |---|---| | KHÔNG container hoá, không tái kiến trúc | AMI từ máy ảo, chạy nguyên trên EC2 | | Sẵn sàng cao | HAI instance ĐANG CHẠY ở HAI AZ | | Chịu lỗi | NLB health check tự chuyển hướng |

Điểm mấu chốt: hai instance ĐANG CHẠY đồng thời.

Một AZ hỏng
    → instance ở AZ đó ngừng
    → NLB phát hiện và rút khỏi vòng phục vụ
    → instance ở AZ còn lại TIẾP TỤC phục vụ
        ↓
    KHÔNG có thời gian chờ khởi động máy mới

Và đây là khác biệt so với phương án C:

ASG với min = max = 1:
    → chỉ có MỘT instance chạy tại một thời điểm
    → máy hỏng → ASG khởi động máy MỚI
    → mất vài phút khởi động + thời gian khởi động ứng dụng
        ↓
    Có phục hồi, nhưng KHÔNG phải sẵn sàng cao
    → có thời gian ngừng thật sự

Triển khai:

aws ec2 create-image --instance-id i-may-ao-cu --name "ung-dung-legacy-v1"

aws ec2 run-instances --image-id ami-0abc --instance-type m5.large   --subnet-id subnet-az-a --count 1
aws ec2 run-instances --image-id ami-0abc --instance-type m5.large   --subnet-id subnet-az-c --count 1

aws elbv2 create-load-balancer --name nlb-legacy --type network   --subnets subnet-az-a subnet-az-c

aws elbv2 register-targets --target-group-arn <arn-tg>   --targets Id=i-0aaa Id=i-0bbb

Và NLB phù hợp với ứng dụng cũ:

Ứng dụng legacy thường KHÔNG phải HTTP
    → có thể dùng giao thức riêng trên TCP
        ↓
    NLB hoạt động ở tầng 4 → không quan tâm giao thức
    → ALB chỉ hỗ trợ HTTP/HTTPS

Nên đổi health check của NLB sang HTTP hoặc TCP có kiểm tra thật:

aws elbv2 modify-target-group --target-group-arn <arn>   --health-check-protocol TCP --health-check-port 8080   --healthy-threshold-count 2 --unhealthy-threshold-count 2   --health-check-interval-seconds 10

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

  • **C. Tạo AMI, dùng ASG với min và max đều bằng 1, đặt ALB phía trước — đây là phương án gần nhất và có cơ chế phục hồi tự động, nhưng nó không phải sẵn sàng cao: chỉ có một instance chạy, nên khi nó hỏng thì dịch vụ ngừng cho tới khi máy thay thế khởi động xong. Đề yêu cầu "high availability AND fault tolerance".
  • **B. Container hoá và triển khai lên ECS Fargate — vi phạm ràng buộc rõ ràng nhất: đề nói các tải "cannot be containerized or re-architected due to software constraints".
  • **A. AWS Backup mỗi giờ vào S3, khôi phục THỦ CÔNG khi có sự cố — RTO rất dài và RPO một giờ: không phải giải pháp sẵn sàng cao mà là kế hoạch khôi phục thảm hoạ cơ bản.

Ghi nhớ

Ba mức bảo vệ — bảng phải thuộc: | Mức | Cơ chế | Thời gian ngừng | |---|---|---| | Backup & Restore | khôi phục thủ công | giờ | | Tự phục hồi (ASG min=1) | khởi động máy mới | phút | | Sẵn sàng cao (nhiều máy đang chạy) | chuyển hướng lưu lượng | gần bằng 0 |

Đề nói "high availability AND fault tolerance" → mức thứ ba.

High availability và Fault tolerance: | | High availability | Fault tolerance | |---|---|---| | Nghĩa | thời gian ngừng RẤT NGẮN | KHÔNG ngừng chút nào | | Cơ chế | nhiều máy, chuyển hướng nhanh | dư thừa hoàn toàn |

Ba cách chạy tải cũ trên AWS: | Cách | Chi tiết | |---|---| | AMI + EC2 (rehost) | ← câu này, không sửa gì | | Application Migration Service (MGN) | sao chép mức khối từ máy ảo | | VM Import/Export | nhập ảnh máy ảo thành AMI |

MGN đáng cân nhắc để tạo AMI ban đầu:

Cài AWS Replication Agent lên máy ảo
    → sao chép liên tục sang AWS
    → khởi động test instance để kiểm thử
    → cutover khi sẵn sàng
        ↓
    Thời gian ngừng tính bằng phút thay vì giờ

Ba cách nhập máy ảo vào AWS: | Cách | Chi tiết | |---|---| | AWS MGN | liên tục, ít ngừng nhất | | VM Import/Export | nhập tệp OVA, VMDK, VHD | | Dựng lại thủ công | chậm nhất |

ALB và NLB — chọn cho ứng dụng cũ: | | ALB | NLB | |---|---|---| | Giao thức | CHỈ HTTP/HTTPS | TCP, UDP, TLS | | Ứng dụng không phải HTTP | ❌ | ✅ | | Giữ IP nguồn | qua header | ✅ nguyên bản | | IP tĩnh | ❌ | ✅ |

Với ứng dụng legacy dùng giao thức riêng, NLB là lựa chọn an toàn.

Ba lưu ý về AMI cho ứng dụng cũ: | Lưu ý | Chi tiết | |---|---| | Kiểm tra IP cứng trong cấu hình | rất hay gặp | | Kiểm tra giấy phép ràng buộc phần cứng | | | Kiểm tra driver và phiên bản hệ điều hành được hỗ trợ | |

Dòng đầu là vấn đề phổ biến nhất:

Ứng dụng cũ thường ghi cứng IP của máy chủ khác
    → sau khi chuyển lên AWS, IP đổi
    → ứng dụng chạy nhưng không kết nối được
        ↓
    Dùng Route 53 private hosted zone thay IP cứng

Ba cấu hình cho sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Hai instance ở hai AZ | ← câu này | | Health check kiểm tra ỨNG DỤNG | không chỉ cổng mở | | Dữ liệu ở kho chia sẻ | EFS, FSx, hoặc RDS |

Dòng cuối quan trọng với ứng dụng cũ:

Hai instance chạy song song
    → nếu mỗi máy giữ dữ liệu riêng trên đĩa
    → hai bản dữ liệu KHÔNG đồng bộ
        ↓
    Phải đưa dữ liệu ra kho chia sẻ
    → hoặc chỉ một máy active (active/passive)

Ba mô hình sẵn sàng cho ứng dụng không co giãn được: | Mô hình | Chi tiết | |---|---| | Active/Active | cả hai phục vụ, cần dữ liệu chia sẻ | | Active/Passive | một máy phục vụ, một chờ | | Auto-recovery | một máy, tự phục hồi |

Ba lưu ý về giấy phép phần mềm cũ: | Lưu ý | Chi tiết | |---|---| | Một số giấy phép ràng buộc theo MAC hoặc host ID | | | Dedicated Host cho giấy phép theo socket/core | | | Kiểm tra điều khoản BYOL trước khi chuyển | |

Ba lưu ý về vá lỗi và bảo trì: | Lưu ý | Chi tiết | |---|---| | Systems Manager Patch Manager | quản lý bản vá tập trung | | Vá luân phiên: rút khỏi NLB → vá → đăng ký lại | | | Runbook AWSEC2-PatchLoadBalancerInstance | tự động hoá |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyHostCount | số máy đang phục vụ | | UnHealthyHostCount | | | ActiveFlowCount | kết nối đang mở |

Đặt alarm khi HealthyHostCount xuống 1:

aws cloudwatch put-metric-alarm --alarm-name chi-con-mot-may   --metric-name HealthyHostCount --namespace AWS/NetworkELB   --dimensions Name=TargetGroup,Value=<id-tg> Name=LoadBalancer,Value=<id-lb>   --statistic Minimum --period 60 --threshold 2   --comparison-operator LessThanThreshold

Và một lời khuyên: hãy kiểm tra ứng dụng có chịu được việc chạy hai bản đồng thời không trước khi triển khai theo mô hình này. Nhiều ứng dụng cũ giả định chỉ có một bản chạy — chúng ghi vào tệp khoá, chạy tác vụ nền theo lịch, hoặc giữ bộ đếm cục bộ — và chạy hai bản sẽ tạo ra lỗi dữ liệu rất khó lần ra.

Câu 759 Design Secure Architectures

A developer has configured inbound traffic for the relevant ports in both the Security Group of the Amazon EC2 instance as well as the network access control list (network ACL) of the subnet for the Amazon EC2 instance. The developer is, however, unable to connect to the service running on the Amazon EC2 instance.

As a solutions architect, how will you fix this issue?

  1. A

    IAM Role defined in the Security Group is different from the IAM Role that is given access in the network access control list (network ACL)
  2. B

    Rules associated with network access control list (network ACL) should never be modified from command line. An attempt to modify rules from command line blocks the rule and results in an erratic behavior
  3. C

    Network access control list (network ACL) are stateful, so allowing inbound traffic to the necessary ports enables the connection. Security Groups are stateless, so you must allow both inbound and outbound traffic
  4. D

    Security Groups are stateful, so allowing inbound traffic to the necessary ports enables the connection. Network access control list (network ACL) are stateless, so you must allow both inbound and outbound traffic
Xem giải thích

Đáp án

D — Security group là STATEFUL, nên chỉ cần cho phép lưu lượng VÀO ở các cổng cần thiết là kết nối hoạt động; network ACL là STATELESS, nên phải cho phép cả chiều VÀO lẫn chiều RA.

Vì sao đúng

Đề mô tả đúng triệu chứng: đã mở cổng ở cả security group lẫn NACL mà vẫn không kết nối được. Nguyên nhân là bản chất stateless của NACL.

Security group — stateful:

Cho phép inbound cổng 443
    → phản hồi đi ra TỰ ĐỘNG được phép
    → KHÔNG cần quy tắc outbound nào
        ↓
    Security group "nhớ" kết nối đã được chấp nhận

Network ACL — stateless:

Cho phép inbound cổng 443 ✓
    → nhưng phản hồi đi ra dùng CỔNG EPHEMERAL (1024–65535)
    → NACL KHÔNG nhớ gì về kết nối vào
    → nếu outbound không cho phép dải cổng đó → phản hồi BỊ CHẶN
        ↓
    Client gửi được request nhưng KHÔNG nhận được trả lời
    → kết nối treo rồi timeout

Đây chính xác là tình huống trong đề.

Sửa — thêm quy tắc outbound cho cổng ephemeral:

aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 100 --protocol tcp   --port-range From=1024,To=65535   --cidr-block 0.0.0.0/0 --rule-action allow --egress

Và chiều ngược lại cũng vậy — khi instance chủ động gọi ra:

# Ra: cho phép tới cổng đích
aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 110 --protocol tcp --port-range From=443,To=443   --cidr-block 0.0.0.0/0 --rule-action allow --egress

# Vào: cho phép phản hồi trên cổng ephemeral
aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 110 --protocol tcp --port-range From=1024,To=65535   --cidr-block 0.0.0.0/0 --rule-action allow --ingress

Dải cổng ephemeral theo hệ thống: | Hệ thống | Dải | |---|---| | Linux hiện đại | 32768–60999 | | Windows | 49152–65535 | | NLB, Lambda | 1024–65535 | | Khuyến nghị mở | 1024–65535 cho an toàn |

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

  • **C. Network ACL là stateful, còn security group là stateless — đây là phương án gần nhất và chỉ khác đáp án đúng ở việc đảo hai tên, nhưng đó là toàn bộ nội dung câu hỏi: security group mới là stateful, NACL là stateless.
  • **B. Quy tắc NACL không được sửa từ dòng lệnh, sửa bằng CLI sẽ khoá quy tắc và gây hành vi thất thường — hoàn toàn bịa đặt: AWS CLI là cách chính thức và được khuyến nghị để quản lý NACL.
  • **A. IAM role khai trong security group khác với IAM role được cấp quyền trong NACL — không có khái niệm nào như vậy: cả security group lẫn NACL đều làm việc với địa chỉ IP và cổng, không hề liên quan tới IAM.

Ghi nhớ

Security group và Network ACL — bảng phải thuộc: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI (từng máy) | SUBNET | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | chỉ Allow | Allow VÀ Deny | | Thứ tự đánh giá | tất cả cùng lúc | theo SỐ, dừng ở quy tắc đầu khớp | | Tham chiếu SG khác | ✅ | ❌ chỉ CIDR | | Mặc định (tự tạo) | chặn inbound, mở outbound | TỪ CHỐI HẾT | | Mặc định (của VPC) | — | cho phép hết |

Bảng này bị hỏi rất nhiều — nên thuộc lòng.

Hai dòng cuối là bẫy lớn:

NACL MẶC ĐỊNH của VPC: cho phép mọi thứ
NACL bạn TỰ TẠO:       từ chối mọi thứ
        ↓
    Gắn NACL tự tạo vào subnet mà quên thêm quy tắc
    = cắt đứt toàn bộ lưu lượng

Ba hệ quả của tính stateless: | Hệ quả | Chi tiết | |---|---| | Phải mở CẢ HAI chiều | ← nguyên nhân trong đề | | Phải biết dải cổng ephemeral | | | Dễ sai và khó gỡ lỗi | |

Ba lý do vẫn dùng NACL: | Lý do | Chi tiết | |---|---| | Có quy tắc DENY | security group không có | | Áp cho cả subnet | không phụ thuộc cấu hình từng máy | | Lớp phòng thủ thứ hai | defense in depth |

Ba trường hợp NACL hữu ích: | Trường hợp | Chi tiết | |---|---| | Chặn một dải IP xấu cụ thể | | | Ngăn subnet nào đó ra Internet | | | Yêu cầu tuân thủ đòi hai lớp kiểm soát | |

Ba đặc điểm của quy tắc NACL: | Đặc điểm | Chi tiết | |---|---| | Đánh số từ 1 đến 32766 | | | Đánh giá theo số TĂNG DẦN | dừng ở quy tắc đầu khớp | | Nên đánh số cách nhau (100, 200, 300) | dễ chèn thêm sau |

Thứ tự sai gây lỗi khó tìm:

Rule 100: DENY 203.0.113.5
Rule 200: ALLOW 0.0.0.0/0
    → IP đó bị chặn ✓

Rule 100: ALLOW 0.0.0.0/0
Rule 200: DENY 203.0.113.5
    → khớp rule 100 trước → KHÔNG bị chặn ✗

Ba bước chẩn đoán khi kết nối bị treo: | Bước | Kiểm tra | |---|---| | ① Security group | cổng và nguồn | | ② NACL | CẢ HAI chiều, gồm cổng ephemeral | | ③ Route table | có đường đi không |

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | chỉ ra CHÍNH XÁC thành phần chặn | | VPC Flow Logs | thấy gói bị REJECT | | nc, telnet | thử thủ công |

Reachability Analyzer là công cụ nhanh nhất:

aws ec2 create-network-insights-path --source i-0client   --destination i-0server --destination-port 443 --protocol tcp
aws ec2 start-network-insights-analysis --network-insights-path-id nip-0abc

Nó nói rõ: "blocked by NACL rule X on subnet Y".

Đọc VPC Flow Log:

2 123456789012 eni-abc 10.0.2.10 10.0.1.5 443 45678 6 1 40 ... REJECT OK
                        ↑ nguồn là SERVER — đây là gói PHẢN HỒI
                                                          ↑
                                        bị chặn ở chiều RA

Nhìn hướng của gói bị REJECT là biết ngay chiều nào thiếu quy tắc.

Ba nguyên tắc thiết kế: | Nguyên tắc | Chi tiết | |---|---| | Dùng security group làm lớp CHÍNH | stateful, dễ hơn nhiều | | NACL chỉ cho quy tắc thô | chặn dải IP xấu | | Nếu dùng NACL, LUÔN mở cổng ephemeral | ← bài học của câu này |

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | Stateful | phản hồi tự động được phép | | Chỉ Allow, không có Deny | | | Tham chiếu SG khác được | ← khuyến nghị cho lưu lượng nội bộ |

Mẫu chuẩn cho ba tầng: | Security group | Inbound | |---|---| | sg-alb | 0.0.0.0/0 cổng 443 | | sg-app | sg-alb | | sg-db | sg-app |

Và một lời khuyên: hãy luôn thêm quy tắc cho dải cổng 1024–65535 ở cả hai chiều khi tạo NACL tuỳ chỉnh. Đây là nguyên nhân số một khiến kết nối bị treo trong VPC, và triệu chứng — request gửi được nhưng không có phản hồi — trông y hệt như một máy chủ đang chết, khiến người ta điều tra sai hướng rất lâu.

Câu 760 Design Cost-Optimized Architectures

A big data analytics company is looking to archive the on-premises data into a POSIX compliant file storage system on AWS Cloud. The archived data would be accessed for just about a week in a year.

As a solutions architect, which of the following AWS services would you recommend as the MOST cost-optimal solution?

  1. A

    Amazon EFS Standard
  2. B

    Amazon S3 Standard
  3. C

    Amazon S3 Standard-IA
  4. D

    Amazon EFS Infrequent Access
Xem giải thích

Đáp án

D — Amazon EFS Infrequent Access.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai cùng dẫn tới EFS IA: | Yêu cầu | Kết luận | |---|---| | Hệ thống tệp TƯƠNG THÍCH POSIX | loại S3 — S3 là object storage | | Truy cập khoảng MỘT TUẦN mỗi năm | loại EFS Standard — dùng lớp IA rẻ hơn nhiều |

Vế đầu là điểm loại trừ quyết định:

"POSIX compliant FILE STORAGE system"
        ↓
    POSIX nghĩa là:
        ✓ cấu trúc thư mục
        ✓ quyền uid/gid, chmod
        ✓ khoá tệp, sửa tại chỗ
        ✓ hard link, symbolic link
        ↓
    S3 KHÔNG có những thứ này — nó là kho object

Và vế thứ hai chọn lớp lưu trữ:

Truy cập ~1 tuần/năm = cực kỳ hiếm
        ↓
    EFS Standard:      ~0,30 USD/GB-tháng
    EFS Standard-IA:   ~0,025 USD/GB-tháng
        ↓
    Rẻ hơn khoảng 12 lần

Bật lifecycle tự chuyển sang IA:

aws efs put-lifecycle-configuration --file-system-id fs-0abc   --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

⚠ Quy tắc thứ hai đáng cân nhắc kỹ:

TransitionToPrimaryStorageClass AFTER_1_ACCESS:
    → tệp được đọc → tự quay về Standard
        ↓
    Với tải đọc một tuần rồi thôi:
        → cả tuần đó tệp nằm ở Standard (đắt hơn)
        → rồi 30 ngày sau mới xuống lại IA
        ↓
    Có thể BỎ quy tắc này để tệp luôn ở IA
    → chấp nhận trả phí truy xuất trong tuần đó

Và có lớp còn rẻ hơn — EFS Archive:

EFS Archive: ~0,008 USD/GB-tháng
    → dành cho dữ liệu truy cập vài lần mỗi NĂM
        ↓
    Khớp chính xác mô tả "một tuần trong một năm"

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

  • **C. Amazon S3 Standard-IA — đây là phương án gần nhất và rẻ hơn EFS IA khoảng một nửa, nhưng nó không phải hệ thống tệp POSIX: S3 là object storage, không có quyền POSIX, không sửa tại chỗ, không khoá tệp. Đề nêu POSIX là yêu cầu rõ ràng.
  • **B. Amazon S3 Standard — cùng vấn đề POSIX, và còn đắt hơn Standard-IA cho dữ liệu hiếm truy cập.
  • **A. Amazon EFS Standard — đúng về POSIX nhưng sai về chi phí: đắt hơn lớp IA khoảng 12 lần, hoàn toàn lãng phí với dữ liệu truy cập một tuần mỗi năm.

Ghi nhớ

Các lớp lưu trữ của EFS — bảng phải thuộc: | Lớp | Giá tham khảo | Phí truy xuất | Số AZ | |---|---|---|---| | Standard | ~0,30 USD/GB | ❌ | ≥3 | | Standard-IA | ~0,025 USD/GB | ✅ ~0,01 USD/GB | ≥3 | | Archive | ~0,008 USD/GB | ✅ cao hơn | ≥3 | | One Zone | rẻ hơn ~47% | ❌ | 1 ⚠ | | One Zone-IA | rẻ nhất | ✅ | 1 ⚠ |

Câu hỏi quyết định giữa EFS và S3: | Câu hỏi | Nếu "có" | |---|---| | Cần POSIX (quyền, khoá tệp, sửa tại chỗ)? | EFS | | Nhiều máy cùng ghi vào cùng tệp? | EFS | | Chỉ đọc ghi cả tệp, sửa được mã? | S3 (rẻ hơn nhiều) |

Từ khoá nhận diện:

"POSIX compliant", "file system", "NFS" → EFS "object storage", "S3 API" → S3 "Windows, SMB" → FSx for Windows "HPC, Lustre" → FSx for Lustre

Ba lớp lưu trữ theo mẫu truy cập: | Tần suất truy cập | Lớp EFS | |---|---| | Hằng ngày | Standard | | Vài lần mỗi tháng | Standard-IA | | Vài lần mỗi NĂM | Archive |

Với "một tuần mỗi năm", Archive là lựa chọn tối ưu nhất — dù đề chỉ đưa ra IA.

Ba chế độ thông lượng của EFS: | Chế độ | Đặc điểm | |---|---| | Elastic (mặc định khuyến nghị) | tự co giãn, trả theo lượng dùng THẬT | | Bursting | theo dung lượng, có credit | | Provisioned | khai trước, tính phí liên tục |

Elastic rất phù hợp với tải kiểu này:

11 tháng không dùng gì → gần như không tốn phí thông lượng
1 tuần dùng nhiều → trả theo lượng đọc thật
        ↓
    Provisioned sẽ tính phí đủ 12 tháng

Hai chế độ hiệu năng: | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | độ trễ thấp nhất | | Max I/O | thông lượng cao hơn, độ trễ cao hơn |

Ba lưu ý về lifecycle của EFS: | Lưu ý | Chi tiết | |---|---| | TransitionToIA từ 1 tới 365 ngày | | | TransitionToPrimaryStorageClass | cân nhắc kỹ với tải theo đợt | | TransitionToArchive từ 90 ngày | |

Ba loại phí của EFS: | Phí | Chi tiết | |---|---| | Lưu trữ | theo lớp | | Truy xuất (IA và Archive) | ~0,01 USD/GB trở lên | | Thông lượng (Elastic) | theo lượng đọc ghi |

Tính điểm hoà vốn:

100 TB dữ liệu, đọc hết 1 lần mỗi năm:
    Standard:  100.000 GB × 0,30 × 12 = 360.000 USD/năm
    IA:        100.000 GB × 0,025 × 12 = 30.000 USD
             + phí truy xuất 100.000 × 0,01 = 1.000 USD
             = 31.000 USD/năm
        ↓
    Tiết kiệm hơn 90%

Ba lưu ý về mount target: | Lưu ý | Chi tiết | |---|---| | Một mount target mỗi AZ | | | Tên DNS tự chọn mount target CÙNG AZ | | | Security group cổng 2049 (NFS) | |

Ba cách đưa dữ liệu từ on-premises vào EFS: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh nhất, có kiểm tra toàn vẹn | | Snowball Edge | dữ liệu rất lớn, băng thông kém | | Copy qua VPN/DX | đơn giản, chậm |

aws datasync create-task   --source-location-arn <arn-nfs-tai-cho>   --destination-location-arn <arn-efs>   --options VerifyMode=POINT_IN_TIME_CONSISTENT

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest bật LÚC TẠO | | | Mã hoá in transit qua tuỳ chọn tls | | | Access Point cách ly từng ứng dụng | |

Ba lựa chọn rẻ hơn nếu bỏ được ràng buộc POSIX: | Lựa chọn | Giá tham khảo | |---|---| | S3 Glacier Instant Retrieval | ~0,004 USD/GB | | S3 Glacier Flexible | ~0,0036 USD/GB | | S3 Glacier Deep Archive | ~0,00099 USD/GB |

Chênh lệch rất lớn — nên xác nhận kỹ ràng buộc POSIX có thật sự bắt buộc không.

Và một lời khuyên: hãy cân nhắc bỏ quy tắc TransitionToPrimaryStorageClass cho loại tải này. Với một tuần truy cập tập trung mỗi năm, việc tự động đưa toàn bộ dữ liệu trở lại Standard sẽ khiến bạn trả giá đắt suốt tháng tiếp theo — trong khi trả một lần phí truy xuất rồi để dữ liệu nằm yên ở IA rẻ hơn nhiều.