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

Tìm thấy 1221 câu.

Câu 371 Chọn nhiều đáp án Design for New Solutions

A leading gaming company runs multiple game platforms that need to store game state, player data, session history, and leaderboards. The company is looking to move to AWS Cloud to scale reliably to millions of concurrent users and requests while ensuring consistently low latency measured in single-digit milliseconds. The engineering team at the company is evaluating multiple in-memory data stores with the ability to power its on-demand, live leaderboard. The company's leaderboard requires high availability, low latency, and real-time processing to deliver customizable user data for the community of its users.

As an AWS Certified Solutions Architect Professional, which of the following solutions would you recommend? (Select two)

A
Develop the leaderboard using AWS Neptune as it meets the in-memory, high availability, low latency requirements
B
Develop the leaderboard using ElastiCache Redis as it meets the in-memory, high availability, low latency requirements
C
Develop the leaderboard using RDS Aurora as it meets the in-memory, high availability, low latency requirements
D
Develop the leaderboard using DynamoDB with DynamoDB Accelerator (DAX) as it meets the in-memory, high availability, low latency requirements
E
Develop the leaderboard using DynamoDB as it meets the in-memory, high availability, low latency requirements

Xem giải thích

Đáp án

**B và D — Dựng bảng xếp hạng bằng ElastiCache Redis, hoặc bằng DynamoDB kết hợp DynamoDB Accelerator (DAX).

Vì sao đúng

Đề nêu bốn yêu cầu, và cả hai đáp án đáp ứng cả bốn: | Yêu cầu | Redis | DynamoDB + DAX | |---|---|---| | Kho dữ liệu TRONG BỘ NHỚ | CÓ | DAX là cache trong bộ nhớ | | Sẵn sàng cao | Multi-AZ với failover | DynamoDB sao chép 3 AZ | | Độ trễ mili giây một chữ số | dưới mili giây | micro giây với DAX | | Xử lý thời gian thực | CÓ | CÓ |

⚠ Điểm mấu chốt: "in-memory" là từ khoá loại bỏ DynamoDB thuần:

DynamoDB một mình lưu trên SSD
        ↓
    Độ trễ mili giây một chữ số
        ↓
    Nhưng nó KHÔNG phải kho trong
      bộ nhớ
        ↓
    Thêm DAX mới thành in-memory

Đây là lý do phương án E sai — nó chỉ nói DynamoDB.

⚠ Và Redis có cấu trúc dữ liệu chuyên cho bảng xếp hạng:

Sorted Set (ZSET)
        ↓
    Mỗi thành viên có một điểm số
        ↓
    Tự sắp xếp theo điểm
    → lấy top N là thao tác O(log N)

ZADD bang-xep-hang 15200 "nguoi-choi-42"
ZADD bang-xep-hang 18900 "nguoi-choi-7"

ZREVRANGE bang-xep-hang 0 9 WITHSCORES
ZREVRANK bang-xep-hang "nguoi-choi-42"
ZINCRBY bang-xep-hang 500 "nguoi-choi-42"

⚠ Và đây là lý do Redis là lựa chọn kinh điển cho bảng xếp hạng:

Lấy top 10: một lệnh
        ↓
    Biết thứ hạng của một người:
      một lệnh
        ↓
    Cộng điểm và tự sắp xếp lại:
      một lệnh
        ↓
    Làm việc này bằng CSDL quan hệ
      cần ORDER BY trên hàng triệu
      dòng

⚠ Và DynamoDB + DAX là lựa chọn thứ hai với ưu thế khác:

DAX: cache trong bộ nhớ đặt trước
  DynamoDB
        ↓
    Đọc trúng cache: micro giây
        ↓
    Và dữ liệu vẫn bền vững trong
      DynamoDB
    → không mất khi cache chết

Tạo cụm DAX:

aws dax create-cluster \
  --cluster-name cache-bang-xep-hang \
  --node-type dax.r5.large \
  --replication-factor 3 \
  --iam-role-arn <arn-role> \
  --subnet-group-name nhom-subnet

⚠ Và DAX trong suốt với ứng dụng — chỉ đổi endpoint:

import amazondax
dax = amazondax.AmazonDaxClient.resource(
    endpoint_url='dax://cache-bang-xep-hang.abc.dax-clusters.amazonaws.com')
bang = dax.Table('diem-nguoi-choi')
bang.get_item(Key={'ma_nguoi_choi': 'NC-42'})

Cùng API với boto3 DynamoDB
        ↓
    Không phải viết lại mã

⚠ Nhưng DAX có hạn chế phải biết: | Hạn chế | Chi tiết | |---|---| | Chỉ tăng tốc ĐỌC | ghi vẫn đi thẳng xuống DynamoDB | | Không hỗ trợ truy vấn có ORDER BY toàn cục | | | Chỉ trong VPC | |

Bảng xếp hạng cần SẮP XẾP toàn cục
        ↓
    DynamoDB không sắp xếp toàn bảng
      được
        ↓
    Phải thiết kế khoá khéo, hoặc
      dùng GSI
    → phức tạp hơn Redis nhiều

⚠ Và vì sao phương án A (Neptune) sai:

Neptune là CSDL ĐỒ THỊ
        ↓
    Cho quan hệ giữa các thực thể:
      bạn bè, đề xuất, phát hiện
      gian lận
        ↓
    Không phải kho trong bộ nhớ
    → và không hợp với bảng xếp hạng

⚠ Và vì sao phương án C (Aurora) sai:

Aurora là CSDL QUAN HỆ, lưu trên đĩa
        ↓
    Không phải in-memory
        ↓
    Và `ORDER BY diem DESC LIMIT 10`
      trên hàng triệu dòng
    → tốn kém, không đạt mili giây
      một chữ số ở quy mô đó

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ dưới mili giây | | | Sorted Set làm sẵn logic xếp hạng | | | Co giãn tới hàng triệu người dùng | |

⚠ Và Redis cần cấu hình đúng để có sẵn sàng cao:

aws elasticache create-replication-group \
  --replication-group-id bang-xep-hang \
  --replication-group-description "bang xep hang" \
  --engine redis --cache-node-type cache.r6g.large \
  --num-node-groups 3 --replicas-per-node-group 2 \
  --automatic-failover-enabled \
  --multi-az-enabled

⚠ Và cần bật bền vững nếu không muốn mất dữ liệu:

Redis mặc định chỉ trong bộ nhớ
        ↓
    Node chết → mất dữ liệu (trừ
      phần đã sao chép sang replica)
        ↓
    Bật snapshot tự động
    → hoặc ghi song song xuống
      DynamoDB làm nguồn sự thật

⚠ Và mẫu kết hợp là kiến trúc thực tế nhất:

DynamoDB: nguồn sự thật, bền vững
        ↓
    Redis: bảng xếp hạng, trong
      bộ nhớ
        ↓
    Ghi vào cả hai
    → Redis chết thì dựng lại từ
      DynamoDB

⚠ Và MemoryDB for Redis là lựa chọn thứ ba đáng biết:

Tương thích Redis
        ↓
    Nhưng ghi bền vững vào transaction
      log đa AZ
        ↓
    Vừa nhanh như Redis vừa bền như
      CSDL
    → không cần kho thứ hai

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

**E. Dựng bảng xếp hạng bằng DynamoDB vì nó đáp ứng yêu cầu in-memory, sẵn sàng cao, độ trễ thấp — đây là phương án gần nhất và DynamoDB thật sự cho độ trễ mili giây một chữ số và sẵn sàng cao, nhưng nó lưu trên SSD chứ không phải trong bộ nhớ; phải thêm DAX mới thoả mãn yêu cầu đó.
**C. Dựng bằng RDS Aurora — CSDL quan hệ lưu trên đĩa, không phải in-memory, và sắp xếp hàng triệu dòng không đạt được độ trễ yêu cầu.
**A. Dựng bằng Neptune — CSDL đồ thị cho quan hệ giữa thực thể, không phải kho trong bộ nhớ.

Ghi nhớ

⚠ Bốn kho dữ liệu trong bộ nhớ trên AWS — bảng phải thuộc: | Dịch vụ | Bền vững | Đặc điểm | |---|---|---| | ElastiCache Redis | snapshot, không phải mọi ghi | cấu trúc dữ liệu phong phú | | ElastiCache Memcached | KHÔNG | đơn giản, đa luồng | | MemoryDB for Redis | CÓ, đa AZ | vừa nhanh vừa bền | | DAX | cache của DynamoDB | trong suốt với API DynamoDB |

Từ khoá nhận diện:

"in-memory leaderboard" → Redis Sorted Set "microsecond reads on DynamoDB" → DAX "durable in-memory database" → MemoryDB "graph relationships" → Neptune

Ba cấu trúc dữ liệu Redis hay dùng: | Cấu trúc | Dùng cho | |---|---| | Sorted Set | bảng xếp hạng, xếp hạng theo điểm | | Hash | hồ sơ người dùng, phiên | | List | hàng đợi, dòng thời gian | | HyperLogLog | đếm số lượng duy nhất xấp xỉ |

⚠ HyperLogLog đếm người chơi duy nhất rất tiết kiệm:

PFADD nguoi-choi-hom-nay "NC-42" "NC-7"
PFCOUNT nguoi-choi-hom-nay

Đếm hàng triệu giá trị duy nhất
        ↓
    Chỉ tốn 12 KB bộ nhớ
        ↓
    Sai số khoảng 0,81%

Ba lưu ý về Redis cluster mode: | Lưu ý | Chi tiết | |---|---| | Chia dữ liệu ra nhiều shard | | | Mỗi shard có primary và replica | | | Lệnh nhiều khoá phải cùng slot | |

⚠ Lệnh nhiều khoá bị hạn chế ở cluster mode:

`ZUNIONSTORE` trên hai sorted set
  ở hai shard
        ↓
    Lỗi CROSSSLOT
        ↓
    Dùng hash tag `{...}` để ép
      cùng slot

ZADD {xep-hang}:tuan 100 "NC-42"
ZADD {xep-hang}:thang 500 "NC-42"

Ba lưu ý về DAX: | Lưu ý | Chi tiết | |---|---| | Chỉ tăng tốc đọc | | | Cache item và cache truy vấn riêng | | | Chỉ dùng được trong VPC | |

Ba lưu ý về DynamoDB cho game: | Lưu ý | Chi tiết | |---|---| | Partition key là mã người chơi | | | GSI cho truy vấn theo điểm | | | On-demand cho tải khó đoán | |

⚠ Bảng xếp hạng trên DynamoDB cần GSI khéo:

Partition key của GSI: một giá trị
  cố định (ví dụ "toan-cau")
        ↓
    Sort key: điểm số
        ↓
    Query GSI với ScanIndexForward=false
    → lấy top N
        ↓
    Nhưng partition key một giá trị
      → phân vùng nóng

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | Redis: Multi-AZ + automatic failover | | | DynamoDB: sao chép 3 AZ sẵn | | | MemoryDB: ghi bền vững đa AZ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ p99 khi lấy top 100 | | | Ép chuyển đổi Redis và đo gián đoạn | | | Kiểm CacheHitRate của DAX | |

Và một lời khuyên: hãy giữ một nguồn sự thật bền vững song song với bảng xếp hạng trong bộ nhớ. Redis rất nhanh nhưng chỉ snapshot định kỳ, nên một sự cố cụm có thể xoá đi hàng giờ điểm số — và với người chơi, mất thứ hạng còn khó chấp nhận hơn là chờ lâu một chút.

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

The engineering team at a retail company has deployed a fleet of EC2 instances under an Auto Scaling group (ASG). The instances under the ASG span two Availability Zones (AZ) within the eu-west-1 region. All the incoming requests are handled by an Application Load Balancer (ALB) that routes the requests to the EC2 instances under the ASG. A planned migration went wrong last week when two instances (belonging to AZ 1) were manually terminated and desired capacity was reduced causing the Availability Zones to become unbalanced. Later that day, another instance (belonging to AZ 2) was detected as unhealthy by the Application Load Balancer's health check.

Which of the following options represent the correct outcomes for the aforesaid events? (Select two)

A
As the Availability Zones got unbalanced, Amazon EC2 Auto Scaling will compensate by rebalancing the Availability Zones. When rebalancing, Amazon EC2 Auto Scaling launches new instances before terminating the old ones, so that rebalancing does not compromise the performance or availability of your application
B
As the Availability Zones got unbalanced, Amazon EC2 Auto Scaling will compensate by rebalancing the Availability Zones. When rebalancing, Amazon EC2 Auto Scaling terminates old instances before launching new instances, so that rebalancing does not cause extra instances to be launched
C
Amazon EC2 Auto Scaling creates a new scaling activity for launching a new instance to replace the unhealthy instance. Later, EC2 Auto Scaling creates a new scaling activity for terminating the unhealthy instance and then terminates it
D
Amazon EC2 Auto Scaling creates a new scaling activity to terminate the unhealthy instance and launch the new instance simultaneously
E
Amazon EC2 Auto Scaling creates a new scaling activity for terminating the unhealthy instance and then terminates it. Later, another scaling activity launches a new instance to replace the terminated instance

Xem giải thích

Đáp án

**A và E — Khi các Availability Zone mất cân bằng, EC2 Auto Scaling khởi động instance MỚI TRƯỚC rồi mới chấm dứt instance cũ, để việc cân bằng lại không ảnh hưởng hiệu năng hay tính sẵn sàng; và với instance bị đánh dấu không khoẻ mạnh, Auto Scaling tạo một hoạt động CHẤM DỨT trước, rồi sau đó mới tạo hoạt động khởi động instance thay thế.

Vì sao đúng

Câu này kiểm tra hai hành vi khác nhau của Auto Scaling, và chúng ngược nhau về thứ tự.

⚠ Hành vi thứ nhất — cân bằng lại AZ: KHỞI ĐỘNG trước:

AZ mất cân bằng
        ↓
    ASG khởi động instance mới ở AZ
      thiếu
        ↓
    CHỜ instance đó vào trạng thái
      InService
        ↓
    RỒI mới chấm dứt instance thừa
      ở AZ kia

Lý do: cân bằng lại là việc TỰ
  NGUYỆN
        ↓
    Không được làm giảm công suất
      đang phục vụ
        ↓
    Nên tạm thời VƯỢT desired
      capacity

Đây là lý do mệnh đề B sai — nó nói chấm dứt trước.

⚠ Hành vi thứ hai — thay thế instance hỏng: CHẤM DỨT trước:

Health check báo instance không
  khoẻ mạnh
        ↓
    ASG CHẤM DỨT nó
        ↓
    Số instance giảm xuống dưới
      desired
        ↓
    Hoạt động co giãn tiếp theo
      khởi động máy thay thế

Lý do: instance hỏng đang gây hại
        ↓
    Giữ nó lại là tiếp tục gửi lưu
      lượng tới chỗ hỏng
        ↓
    Nên loại bỏ NGAY

Đây là lý do mệnh đề C sai — nó nói khởi động trước.

⚠ Và mệnh đề D sai vì hai việc không diễn ra đồng thời:

D nói "một hoạt động co giãn duy
  nhất chấm dứt và khởi động cùng
  lúc"
        ↓
    Thực tế là HAI hoạt động riêng
      biệt
        ↓
    Xem được trong lịch sử hoạt động
      của ASG

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

⚠ Và đây là lý do việc thay thế gây giảm công suất tạm thời:

Instance hỏng bị chấm dứt
        ↓
    Còn N-1 máy phục vụ
        ↓
    Máy mới khởi động, cài đặt,
      qua health check
    → mất vài phút
        ↓
    Trong khoảng đó công suất thấp
      hơn mong muốn

⚠ Và cách giảm ảnh hưởng là đặt min-size có dư:

Cần 6 máy để chịu tải
        ↓
    Đặt desired = 8
        ↓
    Mất một máy vẫn còn 7
    → vẫn đủ trong lúc thay thế

⚠ Và warm pool rút ngắn thời gian thay thế:

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

Giữ sẵn máy đã cài đặt xong ở
  trạng thái Stopped
        ↓
    Cần thì chỉ khởi động — không
      phải cài lại
    → nhanh hơn nhiều

⚠ Và health check kiểu ELB là chi tiết quan trọng:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name doi-ung-dung \
  --health-check-type ELB \
  --health-check-grace-period 300

Mặc định chỉ kiểm tra EC2 status
  check
        ↓
    Ứng dụng treo nhưng máy vẫn chạy
    → ASG không thay thế
        ↓
    Kiểu ELB dùng kết quả health
      check của load balancer

⚠ Và grace period tránh chấm dứt máy đang khởi động:

Máy mới cần 3 phút để khởi động
  ứng dụng
        ↓
    Grace period 60 giây
    → ASG coi nó không khoẻ và
      chấm dứt
        ↓
    Vòng lặp chấm dứt vô tận

⚠ Và AZ Rebalancing có thể tạm dừng:

aws autoscaling suspend-processes \
  --auto-scaling-group-name doi-ung-dung \
  --scaling-processes AZRebalance

Trong lúc triển khai hoặc bảo trì
        ↓
    Tạm dừng để ASG không tự cân
      bằng lại
        ↓
    Nhớ bật lại sau

Ba lợi ích khi hiểu đúng hai hành vi: | Lợi ích | Chi tiết | |---|---| | Biết vì sao số instance tạm thời vượt desired | | | Biết vì sao công suất giảm khi có máy hỏng | | | Lên kế hoạch dung lượng dư phù hợp | |

⚠ Và vượt desired capacity khi cân bằng có giới hạn:

ASG có thể vượt desired capacity
        ↓
    Nhưng KHÔNG vượt `max-size`
        ↓
    Nếu desired = max
    → không cân bằng lại được
    → phải chấm dứt trước

⚠ Đây là lý do nên chừa khoảng giữa desired và max:

desired = 6, max = 6
        ↓
    Không có chỗ cho instance tạm
      thời
        ↓
    desired = 6, max = 10
    → cân bằng lại trơn tru
    → và co giãn ra được

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

**C. Auto Scaling khởi động instance thay thế trước, rồi mới tạo hoạt động chấm dứt instance hỏng — đây là phương án gần nhất và mô tả đúng thứ tự của việc cân bằng AZ, nhưng với instance không khoẻ mạnh thì thứ tự ngược lại: chấm dứt trước để loại bỏ nguồn lỗi.
**B. Khi cân bằng AZ, Auto Scaling chấm dứt instance cũ trước để không phát sinh instance thừa — ngược với hành vi thật; cân bằng lại luôn khởi động trước.
**D. Auto Scaling tạo một hoạt động duy nhất chấm dứt và khởi động đồng thời — thực tế là hai hoạt động riêng biệt, thấy rõ trong lịch sử hoạt động.

Ghi nhớ

⚠ Hai thứ tự ngược nhau của Auto Scaling — bảng phải thuộc: | Tình huống | Thứ tự | |---|---| | Cân bằng lại AZ | khởi động → chấm dứt | | Thay instance không khoẻ | chấm dứt → khởi động | | Instance refresh | tuỳ MinHealthyPercentage |

Từ khoá nhận diện:

"AZ rebalancing" → launch before terminate "unhealthy instance replacement" → terminate then launch "application hangs but instance runs" → health check kiểu ELB "instance terminated right after launch" → grace period quá ngắn

Ba lưu ý về health check: | Kiểu | Kiểm gì | |---|---| | EC2 | status check của hạ tầng và hệ điều hành | | ELB | kết quả health check của target group | | Custom | do bạn đặt bằng API |

⚠ Đặt trạng thái thủ công bằng custom health check:

aws autoscaling set-instance-health \
  --instance-id i-0abc123 \
  --health-status Unhealthy

Ba lưu ý về quá trình co giãn có thể tạm dừng: | Quá trình | Tác dụng khi dừng | |---|---| | Launch | không khởi động máy mới | | Terminate | không chấm dứt máy nào | | AZRebalance | không tự cân bằng AZ | | HealthCheck | không thay máy hỏng | | ReplaceUnhealthy | không thay máy hỏng |

Ba lưu ý về lifecycle hook: | Lưu ý | Chi tiết | |---|---| | Tạm dừng instance ở trạng thái Pending hoặc Terminating | | | Cho phép cài đặt hoặc rút êm | | | Phải gọi complete-lifecycle-action | |

⚠ Lifecycle hook cho việc rút êm:

aws autoscaling put-lifecycle-hook \
  --lifecycle-hook-name rut-em \
  --auto-scaling-group-name doi-ung-dung \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 300

Máy sắp bị chấm dứt
        ↓
    Hook giữ nó lại 5 phút
        ↓
    Hoàn tất yêu cầu đang xử lý,
      đẩy log ra ngoài

Ba lưu ý về chính sách chấm dứt: | Chính sách | Chọn máy nào | |---|---| | Default | AZ nhiều máy nhất, rồi launch config cũ nhất | | OldestInstance | máy chạy lâu nhất | | NewestInstance | máy mới nhất | | ClosestToNextInstanceHour | sắp sang giờ tính phí mới |

Ba lưu ý về instance refresh: | Lưu ý | Chi tiết | |---|---| | Thay toàn bộ đội theo lô | | | MinHealthyPercentage giữ công suất | | | Có checkpoint để dừng và kiểm tra | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | describe-scaling-activities xem thứ tự thật | | | Chấm dứt tay một máy và quan sát | | | Kiểm min-size có đủ dư khi mất một máy | |

Và một lời khuyên: hãy chừa khoảng giữa desired-capacity và max-size. Auto Scaling cần chỗ để khởi động máy mới trước khi bỏ máy cũ khi cân bằng lại các AZ — nếu desired đã bằng max thì nó buộc phải chấm dứt trước, và bạn mất đúng lớp bảo vệ mà cơ chế đó được thiết kế để giữ.

Câu 373 Design Solutions for Organizational Complexity

The world’s largest cable company uses AWS in a hybrid environment to innovate and deploy features for its flagship video product, XFINITY X1, several times a week. The company uses AWS products such as Amazon Virtual Private Cloud (Amazon VPC) and Amazon Direct Connect to deliver the scalability and security needed for rapidly innovating in a hybrid environment. As part of an internal product roadmap, the engineering team at the company has created a private hosted zone and associated it with a virtual private cloud (VPC). However, the domain names remain unresolved, resulting in errors.

As a Solutions Architect Professional, which of the following Amazon VPC configuration options would you use to get the private hosted zone to work?

A
There is a private hosted zone and a Resolver rule that routes traffic to your network for the same domain name resulting in an ambiguous routing rule
B
To use private hosted zones, DNS hostnames and DNS resolution should be enabled for the VPC
C
The private and public hosted zones should not have overlapping namespaces
D
Name server (NS) record and Start Of Authority (SOA) records should have the correct configurations

Xem giải thích

Đáp án

**B — Để dùng được private hosted zone, phải bật DNS hostnames và DNS resolution cho VPC.

Vì sao đúng

Đây là điều kiện tiên quyết mà AWS ghi rõ, và cũng là nguyên nhân phổ biến nhất khi private hosted zone "không hoạt động":

Private hosted zone gắn với VPC
        ↓
    Nhưng VPC chưa bật hai thuộc tính
        ↓
    Route 53 Resolver trong VPC
      không phân giải được
    → tên miền trả về NXDOMAIN

⚠ Hai thuộc tính đó là gì: | Thuộc tính | Tác dụng | |---|---| | enableDnsSupport | bật Route 53 Resolver ở VPC_CIDR + 2 | | enableDnsHostnames | cấp tên DNS công khai cho instance |

Cả hai đều PHẢI bật
        ↓
    Thiếu `enableDnsSupport`:
      không có máy phân giải nào
        ↓
    Thiếu `enableDnsHostnames`:
      private hosted zone không
      hoạt động

Bật hai thuộc tính:

aws ec2 modify-vpc-attribute --vpc-id vpc-abc \
  --enable-dns-support '{"Value": true}'

aws ec2 modify-vpc-attribute --vpc-id vpc-abc \
  --enable-dns-hostnames '{"Value": true}'

Kiểm tra:

aws ec2 describe-vpc-attribute --vpc-id vpc-abc \
  --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-abc \
  --attribute enableDnsHostnames

⚠ Và VPC mặc định bật sẵn cả hai — VPC tự tạo thì không:

VPC mặc định: cả hai đều `true`
        ↓
    VPC tạo bằng CLI hoặc
      CloudFormation:
      enableDnsSupport = true
      enableDnsHostnames = FALSE
        ↓
    Đây là lý do lỗi này rất hay gặp

⚠ Và trong CloudFormation phải khai tường minh:

MangChinh:
  Type: AWS::EC2::VPC
  Properties:
    CidrBlock: 10.0.0.0/16
    EnableDnsSupport: true
    EnableDnsHostnames: true

⚠ Và vì sao ba phương án còn lại là những vấn đề THẬT nhưng không phải nguyên nhân ở đây:

A: private hosted zone và resolver
  rule cùng tên miền → định tuyến
  mơ hồ
        ↓
    Có xảy ra, nhưng đề không nhắc
      tới resolver rule nào
        ↓
C: private và public hosted zone
  trùng namespace
        ↓
    Cũng có xảy ra — gọi là
      split-horizon DNS
    → và thực ra AWS HỖ TRỢ mẫu này

⚠ Split-horizon DNS là mẫu hợp lệ, không phải lỗi:

`cong-ty.vn` có cả public và
  private hosted zone
        ↓
    Trong VPC: dùng bản private
        ↓
    Ngoài VPC: dùng bản public
        ↓
    Đây là thiết kế có chủ đích,
      không phải xung đột

⚠ Nhưng có một quy tắc phải nhớ về split-horizon:

Private hosted zone LUÔN thắng
  trong VPC
        ↓
    Tên miền con không có trong
      private zone
    → KHÔNG rơi về public zone
        ↓
    Trả về NXDOMAIN

Private zone cho `cong-ty.vn`
  chỉ có bản ghi `db.cong-ty.vn`
        ↓
    Truy vấn `www.cong-ty.vn` từ
      trong VPC
    → NXDOMAIN, dù public zone có
        ↓
    Phải thêm bản ghi vào private
      zone

⚠ Và vì sao phương án D không phải nguyên nhân:

D nói bản ghi NS và SOA phải cấu
  hình đúng
        ↓
    Route 53 TỰ TẠO hai bản ghi đó
      khi tạo hosted zone
        ↓
    Với private hosted zone, bản
      ghi NS không có tác dụng gì
    → vì phân giải diễn ra nội bộ
      trong VPC

Tạo private hosted zone:

aws route53 create-hosted-zone \
  --name noi-bo.cong-ty.vn \
  --caller-reference $(uuidgen) \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-abc \
  --hosted-zone-config PrivateZone=true

Gắn thêm VPC:

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123 \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-def

Ba lợi ích của private hosted zone: | Lợi ích | Chi tiết | |---|---| | Tên nội bộ không lộ ra Internet | | | Gắn được với nhiều VPC và nhiều Region | | | Dùng chung với tại chỗ qua Resolver endpoint | |

⚠ Và gắn hosted zone với VPC ở tài khoản khác cần hai bước:

# Tài khoản chủ hosted zone
aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z123 \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-tai-khoan-khac

# Tài khoản chủ VPC
aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123 \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-cua-tai-khoan-khac

Không làm được bằng console
        ↓
    Phải dùng CLI hoặc API

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

**C. Private và public hosted zone không được trùng namespace — đây là phương án gần nhất và trùng namespace thật sự gây ra hành vi bất ngờ, nhưng AWS hỗ trợ mẫu split-horizon DNS có chủ đích; nó không phải điều kiện để private hosted zone hoạt động.
**A. Có private hosted zone và resolver rule cùng tên miền gây định tuyến mơ hồ — là một vấn đề thật, nhưng đề không nhắc tới resolver rule nào.
**D. Bản ghi NS và SOA phải cấu hình đúng — Route 53 tự tạo chúng, và với private hosted zone thì bản ghi NS không được dùng tới.

Ghi nhớ

⚠ Điều kiện để private hosted zone hoạt động:

1. `enableDnsSupport` = true
        ↓
2. `enableDnsHostnames` = true
        ↓
3. Hosted zone đã gắn với VPC
        ↓
4. Instance dùng Route 53 Resolver
     (VPC_CIDR + 2)

Từ khoá nhận diện:

"private hosted zone not resolving" → kiểm hai thuộc tính DNS của VPC "same domain public and private" → split-horizon, hợp lệ "resolve on-premises names" → Resolver outbound endpoint "resolve VPC names from on-premises" → Resolver inbound endpoint

Ba lưu ý về private hosted zone: | Lưu ý | Chi tiết | |---|---| | Chỉ phân giải được từ VPC đã gắn | | | Gắn được với VPC ở Region khác | | | Gắn liên tài khoản cần authorization | |

⚠ Private zone thắng public zone trong VPC:

Truy vấn khớp private zone
        ↓
    Dùng private zone
        ↓
    Không tìm thấy bản ghi trong đó
    → NXDOMAIN
    → KHÔNG rơi về public zone

Ba lưu ý về Route 53 Resolver: | Lưu ý | Chi tiết | |---|---| | Địa chỉ VPC_CIDR + 2 | | | Hoặc 169.254.169.253 | | | Giới hạn 1.024 gói mỗi giây mỗi ENI | |

⚠ Giới hạn đó là bẫy khi tải DNS cao:

Ứng dụng phân giải tên trước MỌI
  lời gọi
        ↓
    Chạm trần 1.024 gói/giây/ENI
        ↓
    Truy vấn DNS bị bỏ, timeout
    → cache DNS ở phía ứng dụng

Ba lưu ý về thứ tự phân giải:

1. Bản ghi trong /etc/hosts
        ↓
2. Private hosted zone của VPC
        ↓
3. Resolver rule (FORWARD)
        ↓
4. DNS công khai

Ba lưu ý về Resolver endpoint: | Loại | Chiều | |---|---| | Inbound | tại chỗ → VPC | | Outbound | VPC → tại chỗ |

Ba lưu ý về chẩn đoán: | Việc | Cách | |---|---| | dig @10.0.0.2 ten.noi-bo.vn | thử trực tiếp Resolver | | Resolver query logging | xem truy vấn và kết quả | | describe-vpc-attribute | kiểm hai thuộc tính DNS |

⚠ Bật query logging rất hữu ích:

aws route53resolver create-resolver-query-log-config \
  --name log-dns \
  --destination-arn <arn-log-group>

Ba lưu ý về VPC endpoint và DNS: | Lưu ý | Chi tiết | |---|---| | Interface endpoint tạo private DNS trong VPC | | | Private DNS cần enableDnsHostnames | | | Tắt private DNS khi dùng endpoint tập trung | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | describe-vpc-attribute cho cả hai thuộc tính | | | dig một tên trong private zone từ EC2 | | | Kiểm hosted zone đã gắn đúng VPC | |

Và một lời khuyên: hãy khai tường minh EnableDnsHostnames: true trong mọi template CloudFormation tạo VPC. Nó mặc định là false cho VPC tự tạo trong khi VPC mặc định lại bật sẵn — nên lỗi này chỉ xuất hiện khi bạn chuyển từ thử nghiệm nhanh sang hạ tầng dạng mã, đúng lúc ít ai nghĩ tới nó nhất.

Câu 374 Chọn nhiều đáp án Design for New Solutions

After a recent DDoS assault, the IT security team of a media company has asked the Security Engineer to revamp the security of the application to prevent future attacks. The website is hosted on an Amazon EC2 instance and data is maintained on Amazon RDS. A large part of the application data is static and this data is in the form of images.

Which of the following steps can be combined to constitute the revamped security model? (Select two)

A
Configure Amazon Inspector with AWS Security Hub to mitigate DDoS attacks by continual scanning that delivers near real-time vulnerability findings
B
Configure the Amazon EC2 instance with an Auto Scaling Group (ASG) to scale in case of a DDoS assault. Front the ASG with AWS Web Application Firewall (AWS WAF) for another layer of security
C
Use Global Accelerator to distribute traffic
D
Use Amazon Route 53 to distribute traffic
E
Move the static content to Amazon S3, and front this with an Amazon CloudFront distribution. Configure another layer of protection by adding AWS Web Application Firewall (AWS WAF) to the CloudFront distribution

Xem giải thích

Đáp án

D và E.

E — Chuyển nội dung tĩnh sang Amazon S3, đặt CloudFront phía trước, và thêm AWS WAF cho CloudFront distribution
D — Dùng Amazon Route 53 để phân phối lưu lượng

Vì sao đúng

Đề mô tả: website trên một EC2 instance, dữ liệu ở RDS, và phần lớn dữ liệu là ảnh tĩnh. Cần chống DDoS.

E — chuyển ảnh sang S3 + CloudFront giải quyết đúng gốc vấn đề:

Trước:  Mọi request ảnh → một EC2 instance
        → tấn công DDoS đánh thẳng vào máy chủ gốc
        → một máy không chịu nổi

Sau:    Request ảnh → CloudFront (hơn 600 điểm biên toàn cầu)
        → hấp thụ tấn công ở BIÊN, phân tán trên hạ tầng của AWS
        → origin gần như không bị chạm tới

Ba lớp bảo vệ mà E mang lại cùng lúc: | Lớp | Chi tiết | |---|---| | CloudFront hấp thụ ở biên | quy mô toàn cầu, tự động có Shield Standard | | WAF trên CloudFront | lọc tầng 7 theo quy tắc | | S3 thay EC2 cho nội dung tĩnh | giảm hẳn tải lên máy chủ gốc |

D — Route 53 là lớp DNS, và nó cũng là một dịch vụ biên có khả năng chống DDoS: | Đặc điểm | Chi tiết | |---|---| | Hạ tầng anycast phân tán toàn cầu | DNS không thành điểm sập | | Có Shield Standard sẵn | miễn phí | | Health check + failover routing | chuyển hướng khi endpoint gặp sự cố |

Nguyên tắc chung mà hai đáp án này thể hiện:

Đẩy lưu lượng ra các dịch vụ BIÊN của AWS (Route 53, CloudFront, Shield, WAF), giảm diện tích phơi ra của tài nguyên gốc.

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

**B. Cấu hình EC2 với Auto Scaling Group để mở rộng khi bị DDoS; đặt WAF trước ASG — đây là phương án gần nhất và sai ở hai điểm: WAF không gắn được vào Auto Scaling group — nó chỉ gắn vào CloudFront, ALB, API Gateway, AppSync. Và mở rộng để chịu tấn công nghĩa là TRẢ TIỀN cho cuộc tấn công — kẻ tấn công đạt được mục tiêu gây thiệt hại tài chính.
**C. Dùng Global Accelerator để phân phối lưu lượng — là dịch vụ biên hợp lệ và có chống DDoS, nhưng nó tối ưu cho TCP/UDP không phải HTTP (game, VoIP, IoT). Với website nhiều ảnh tĩnh, CloudFront là lựa chọn đúng vì nó cache được nội dung — Global Accelerator chỉ định tuyến chứ không cache.
**A. Cấu hình Amazon Inspector với Security Hub để giảm thiểu DDoS bằng cách quét liên tục và đưa ra phát hiện lỗ hổng gần thời gian thực — sai dịch vụ hoàn toàn: Inspector quét lỗ hổng phần mềm (CVE). Nó không liên quan gì tới DDoS.

Ghi nhớ

Ba lớp phòng thủ DDoS trên AWS: | Lớp | Chống | Chi phí | |---|---|---| | Shield Standard | tầng 3/4 phổ biến | MIỄN PHÍ, bật sẵn cho mọi tài khoản | | AWS WAF | tầng 7 theo quy tắc | tính phí | | Shield Advanced | tầng 3/4/7 nâng cao + SRT + bảo vệ chi phí | 3.000 USD/tháng |

Bốn dịch vụ biên có khả năng chống DDoS tốt nhất: | Dịch vụ | Phù hợp | |---|---| | CloudFront | HTTP/HTTPS, nội dung tĩnh và động ← câu này | | Route 53 | DNS ← câu này | | Global Accelerator | TCP/UDP không phải HTTP | | API Gateway (edge-optimized) | REST API |

Bốn nguyên tắc kiến trúc chống DDoS: | Nguyên tắc | Cách làm | |---|---| | Giảm diện tích phơi ra | origin trong private subnet, chỉ nhận từ CloudFront | | Đẩy ra biên | CloudFront, Route 53 | | Mở rộng để hấp thụ | ASG, nhưng cân nhắc chi phí | | Biết khi nào bị tấn công | alarm trên DDoSDetected của Shield Advanced |

Dòng đầu là việc hay bị quên nhất: đặt CloudFront trước nhưng vẫn để ALB hoặc EC2 nhận lưu lượng từ 0.0.0.0/0 thì kẻ tấn công tìm ra IP gốc và bỏ qua toàn bộ lớp bảo vệ. Bịt bằng cách dùng AWS-managed prefix list trong security group:

Security group của origin:
  Nguồn: com.amazonaws.global.cloudfront.origin-facing

Hoặc dùng custom header bí mật mà chỉ CloudFront gửi, kiểm tra ở ALB.

Vì sao "mở rộng để chịu tấn công" là chiến lược tồi: | Vấn đề | Chi tiết | |---|---| | Chi phí tăng theo quy mô tấn công | kẻ tấn công điều khiển hoá đơn của bạn | | Có giới hạn trên | ASG có MaxSize, và hạn mức tài khoản | | Vẫn chuyển lưu lượng độc hại tới ứng dụng | không lọc gì |

(Shield Advanced có bảo vệ chi phí hoàn lại phần scale do tấn công gây ra — nhưng đó là biện pháp bù đắp, không phải giải pháp.)

Và một lợi ích phụ đáng kể của phương án E ngoài bảo mật: chuyển ảnh sang S3 + CloudFront giảm chi phí và tăng tốc độ tải trang cho người dùng thật, kể cả khi không có tấn công nào. Đó là kiểu thay đổi kiến trúc đúng ở nhiều mặt cùng lúc.

Câu 375 Accelerate Workload Migration and Modernization

A solo entrepreneur is working on a new digital media startup and wants to have a hands-on understanding of the comparative pricing for various storage types available on AWS Cloud. The entrepreneur has created a test file of size 5 GB with some random data. Next, he uploads this test file into AWS S3 Standard storage class, provisions an EBS volume (General Purpose SSD (gp2)) with 50 GB of provisioned storage and copies the test file into the EBS volume, and lastly copies the test file into an EFS Standard Storage filesystem. At the end of the month, he analyses the bill for costs incurred on the respective storage types for the test file.

What of the following represents the correct order of the storage charges incurred for the test file on these three storage types?

A
Cost of test file storage on S3 Standard < Cost of test file storage on EBS < Cost of test file storage on EFS
B
Cost of test file storage on EBS < Cost of test file storage on S3 Standard < Cost of test file storage on EFS
C
Cost of test file storage on EFS < Cost of test file storage on S3 Standard < Cost of test file storage on EBS
D
Cost of test file storage on S3 Standard < Cost of test file storage on EFS < Cost of test file storage on EBS

Xem giải thích

Đáp án

**D — Chi phí lưu tệp trên S3 Standard < EFS < EBS.

Vì sao đúng

Câu này có một cái bẫy nằm ở chỗ EBS tính tiền theo dung lượng ĐÃ CẤP PHÁT, không theo dung lượng đã dùng:

Tệp thử 5 GB
        ↓
    S3: tính 5 GB
    EFS: tính 5 GB
    EBS: tính 50 GB (đã cấp phát)
        ↓
    Dù chỉ chứa 5 GB dữ liệu

⚠ Đây là khác biệt căn bản về mô hình tính tiền: | Dịch vụ | Tính theo | |---|---| | S3 | dung lượng THẬT SỰ lưu | | EFS | dung lượng THẬT SỰ lưu | | EBS | dung lượng ĐÃ CẤP PHÁT |

Tính cụ thể (giá xấp xỉ, us-east-1): | Dịch vụ | Đơn giá | Dung lượng tính tiền | Chi phí tháng | |---|---|---|---| | S3 Standard | 0,023 USD/GB | 5 GB | ~0,115 USD | | EFS Standard | 0,30 USD/GB | 5 GB | ~1,50 USD | | EBS gp2 | 0,10 USD/GB | 50 GB | ~5,00 USD |

S3 rẻ nhất
        ↓
    EFS đắt hơn S3 khoảng 13 lần
      trên mỗi GB
        ↓
    EBS đơn giá rẻ hơn EFS
    → nhưng phải trả cho 50 GB
    → tổng cộng đắt nhất

⚠ Và nếu chỉ so ĐƠN GIÁ thì thứ tự khác hẳn:

Đơn giá: S3 (0,023) < EBS (0,10)
  < EFS (0,30)
        ↓
    Tổng chi phí: S3 < EFS < EBS
        ↓
    Khác biệt do EBS phải cấp phát
      trước

Đây là lý do phương án A sai — nó chính là thứ tự theo đơn giá.

⚠ Và đây là bài học vận hành quan trọng:

EBS cấp 50 GB, dùng 5 GB
        ↓
    Trả tiền cho 45 GB không dùng
        ↓
    Rất nhiều volume trong thực tế
      dùng dưới 30% dung lượng
    → khoản lãng phí lớn và âm thầm

Tìm volume dùng ít:

aws cloudwatch get-metric-statistics \
  --namespace CWAgent --metric-name disk_used_percent \
  --dimensions Name=InstanceId,Value=i-0abc \
  --statistics Average --period 86400 \
  --start-time 2026-08-01T00:00:00Z \
  --end-time 2026-09-01T00:00:00Z

CloudWatch không tự biết dung lượng
  đã dùng bên trong volume
        ↓
    Phải cài CloudWatch Agent
    → đây là lý do lãng phí này
      khó phát hiện

⚠ Và EBS còn có khoản phí ẩn khác: | Khoản | Ghi chú | |---|---| | Dung lượng cấp phát | luôn tính, dù dùng hay không | | IOPS (io1/io2, gp3 vượt mức) | tính riêng | | Snapshot | tính theo dữ liệu thay đổi | | Volume không gắn vào máy nào | VẪN TÍNH TIỀN |

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

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

Trạng thái `available` = không gắn
  vào instance nào
        ↓
    Vẫn tính tiền đầy đủ
        ↓
    Xoá instance mà quên xoá volume
    → chúng tích luỹ nhiều năm

⚠ Và EFS đắt nhưng có lớp lưu trữ rẻ hơn: | Lớp EFS | Giá xấp xỉ | |---|---| | Standard | 0,30 USD/GB | | Infrequent Access | 0,016 USD/GB | | Archive | 0,008 USD/GB |

Bật lifecycle policy
        ↓
    Tệp không đọc trong 30 ngày →
      chuyển sang IA
        ↓
    Giảm gần 20 lần
    → nhưng có phí truy cập khi đọc

aws efs put-lifecycle-configuration --file-system-id fs-abc \
  --lifecycle-policies \
    TransitionToIA=AFTER_30_DAYS \
    TransitionToPrimaryStorageClass=AFTER_1_ACCESS

⚠ Và S3 có nhiều lớp rẻ hơn nữa: | Lớp S3 | Giá xấp xỉ | |---|---| | Standard | 0,023 USD/GB | | Standard-IA | 0,0125 USD/GB | | Glacier Instant Retrieval | 0,004 USD/GB | | Glacier Deep Archive | 0,00099 USD/GB |

Ba lợi ích khi hiểu đúng mô hình giá: | Lợi ích | Chi tiết | |---|---| | Chọn đúng dịch vụ cho từng loại dữ liệu | | | Không cấp phát EBS thừa | | | Biết tìm khoản lãng phí ở đâu | |

⚠ Và gp3 rẻ hơn gp2 khoảng 20% cùng dung lượng:

gp2: 0,10 USD/GB
        ↓
    gp3: 0,08 USD/GB
        ↓
    Và gp3 cho 3.000 IOPS miễn phí
    → chuyển sang gp3 gần như luôn
      có lợi

⚠ Nhưng so sánh chi phí thuần không phải cách chọn dịch vụ:

S3: kho object, không mount được
        ↓
    EFS: hệ tệp POSIX chia sẻ nhiều
      máy
        ↓
    EBS: đĩa khối cho một máy, độ
      trễ thấp nhất
        ↓
    Chọn theo NHU CẦU trước, tối ưu
      chi phí sau

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

**A. S3 < EBS < EFS — đây là phương án gần nhất và đúng nếu so ĐƠN GIÁ mỗi GB, nhưng EBS tính tiền theo 50 GB đã cấp phát chứ không phải 5 GB đã dùng, nên tổng chi phí của nó cao nhất.
**B. EBS < S3 < EFS — EBS không thể rẻ hơn S3 ở đây vì phải trả cho gấp mười lần dung lượng.
**C. EFS < S3 < EBS — EFS đắt hơn S3 khoảng 13 lần trên mỗi GB.

Ghi nhớ

⚠ Mô hình tính tiền của ba dịch vụ lưu trữ — bảng phải thuộc: | Dịch vụ | Tính theo | Có phí khác | |---|---|---| | S3 | dung lượng thật + số yêu cầu | truyền ra, chuyển tầng | | EFS | dung lượng thật | thông lượng (provisioned mode) | | EBS | dung lượng CẤP PHÁT | IOPS, snapshot |

Từ khoá nhận diện:

"provisioned capacity" → EBS, trả cho phần cấp không phải phần dùng "pay for what you store" → S3, EFS "cheapest for object storage" → S3 "shared POSIX file system" → EFS (đắt nhất mỗi GB)

Ba lưu ý về tối ưu chi phí EBS: | Cách | Tác dụng | |---|---| | Chuyển gp2 sang gp3 | giảm 20% | | Right-sizing volume | không cấp thừa | | Xoá volume mồ côi và snapshot cũ | loại bỏ lãng phí |

⚠ Snapshot cũng tích luỹ âm thầm:

aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime<`2025-01-01`].[SnapshotId,VolumeSize,StartTime]' \
  --output table

Snapshot tính theo dữ liệu THAY ĐỔI
        ↓
    Nhưng hàng nghìn snapshot cũ vẫn
      cộng dồn
        ↓
    Data Lifecycle Manager tự dọn

Ba lưu ý về tối ưu chi phí S3: | Cách | Tác dụng | |---|---| | Vòng đời chuyển tầng | giảm mạnh cho dữ liệu nguội | | Intelligent-Tiering | tự chuyển, hợp khi không đoán được | | Dọn multipart dở dang | loại bỏ chi phí ẩn |

Ba lưu ý về tối ưu chi phí EFS: | Cách | Tác dụng | |---|---| | Lifecycle sang IA và Archive | giảm tới 20-38 lần | | Chế độ Elastic thay Provisioned | trả theo lượng dùng | | One Zone EFS | rẻ hơn 47%, chỉ một AZ |

Ba công cụ tìm lãng phí: | Công cụ | Việc | |---|---| | Compute Optimizer | đề xuất right-sizing EBS và EC2 | | Trusted Advisor | volume dùng ít, IP không gắn | | S3 Storage Lens | phân bố lớp lưu trữ |

Ba lưu ý về chi phí yêu cầu: | Dịch vụ | Phí yêu cầu | |---|---| | S3 | PUT ~0,005/1.000, GET ~0,0004/1.000 | | EFS | không có (trừ lớp IA có phí truy cập) | | EBS | không có |

⚠ Với hàng triệu tệp nhỏ, phí yêu cầu S3 có thể lớn hơn phí lưu trữ:

10 triệu PUT = 50 USD
        ↓
    10 triệu tệp 10 KB = 100 GB
      = 2,30 USD lưu trữ
        ↓
    Phí yêu cầu gấp 20 lần phí lưu
      trữ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cost Explorer nhóm theo dịch vụ | | | So dung lượng cấp phát với dung lượng dùng | | | Tìm volume trạng thái available | |

Và một lời khuyên: hãy rà soát volume EBS có trạng thái available mỗi quý. Chúng không gắn vào máy nào, không xuất hiện ở đâu trong bảng điều khiển EC2 mà bạn hay nhìn, và vẫn tính tiền đầy đủ cho toàn bộ dung lượng đã cấp phát — tháng này qua tháng khác.

Câu 376 Design for New Solutions

A leading video creation and distribution company has recently migrated to AWS Cloud for digitally transforming its movie business. The company wants to speed up its media distribution process and improve data security while also reducing costs and eliminating errors. The company wants to set up a Digital Cinema Network that would allow it to store content in Amazon S3 as well as to accelerate the online distribution of movies and advertising to theaters in 38 key media markets worldwide. The company also wants to do an accelerated online migration of hundreds of terabytes of files from their on-premises data center to Amazon S3 and then establish a mechanism for low-latency access of the migrated data for ongoing updates from the on-premises applications.

As a Solutions Architect Professional, which of the following would you select as the MOST performant solution for the given use-case?

A
Use S3 Transfer Acceleration to migrate existing data to Amazon S3 and then use DataSync for low latency access to the migrated data for ongoing updates from the on-premises applications
B
Use File Gateway configuration of AWS Storage Gateway to migrate data to Amazon S3 and then use S3 Transfer Acceleration for low latency access to the migrated data for ongoing updates from the on-premises applications
C
Use AWS DataSync to migrate existing data to Amazon S3 and then use File Gateway for low latency access to the migrated data for ongoing updates from the on-premises applications
D
Use AWS DataSync to first migrate existing data to Amazon S3 and then configure low latency access to the migrated data for ongoing updates from the on-premises applications

Xem giải thích

Đáp án

**C — Dùng AWS DataSync để di trú dữ liệu hiện có sang Amazon S3, rồi dùng File Gateway để truy cập dữ liệu đã di trú với độ trễ thấp cho các cập nhật liên tục từ ứng dụng tại chỗ.

Vì sao đúng

Đề mô tả hai giai đoạn với hai nhu cầu khác nhau: | Giai đoạn | Nhu cầu | Công cụ | |---|---|---| | Di trú một lần hàng trăm TB | chuyển nhanh, có kiểm tra | DataSync | | Truy cập liên tục về sau | độ trễ thấp, đọc và ghi | File Gateway |

⚠ Điểm mấu chốt: DataSync và File Gateway giải quyết hai bài toán khác nhau:

DataSync: ĐỒNG BỘ hàng loạt
        ↓
    Tối ưu cho việc chuyển lượng lớn
      nhanh nhất có thể
        ↓
    File Gateway: TRUY CẬP liên tục
        ↓
    Ứng dụng ghi qua NFS/SMB, dữ liệu
      thành object S3, có cache cục bộ

⚠ Và đây là lý do phương án A đảo ngược vai trò:

A dùng S3TA để di trú
        ↓
    Rồi dùng DataSync cho "truy cập
      độ trễ thấp"
        ↓
    DataSync KHÔNG phải công cụ truy
      cập — nó là công cụ đồng bộ
        ↓
    Nó chạy theo lịch, không phục vụ
      đọc/ghi thời gian thực

⚠ Và phương án B cũng đảo ngược:

B dùng File Gateway để DI TRÚ
        ↓
    Rồi dùng S3TA cho truy cập độ
      trễ thấp
        ↓
    File Gateway chuyển được dữ liệu,
      nhưng chậm hơn DataSync nhiều
        ↓
    Và S3TA là để tăng tốc TẢI LÊN,
      không phải để truy cập kiểu
      hệ tệp

Di trú bằng DataSync:

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

aws datasync create-task \
  --source-location-arn <arn-nfs> \
  --destination-location-arn <arn-s3> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,\
TransferMode=CHANGED,BytesPerSecond=-1

⚠ DataSync nhanh hơn công cụ chép thông thường khoảng 10 lần:

Giao thức tối ưu riêng của AWS
        ↓
    Nén, song song, chỉ chuyển phần
      khác biệt
        ↓
    Và có kiểm tra toàn vẹn sẵn
    → đây là lý do nó là công cụ
      DI TRÚ đúng

Dựng File Gateway cho truy cập liên tục:

aws storagegateway create-nfs-file-share \
  --client-token $(uuidgen) \
  --gateway-arn <arn-gateway> \
  --location-arn arn:aws:s3:::kho-phim \
  --role <arn-role> \
  --client-list 192.168.0.0/16 \
  --squash RootSquash

⚠ Và File Gateway có cache cục bộ — đây là nguồn của "độ trễ thấp":

Ứng dụng đọc tệp
        ↓
    Có trong cache → nhanh như đĩa
      cục bộ
        ↓
    Không có → kéo từ S3
    → chậm hơn, nhưng rồi vào cache

⚠ Và tệp ghi qua File Gateway trở thành object S3 ĐỌC ĐƯỢC:

Mỗi tệp = một object S3
        ↓
    Truy cập được bằng API S3
        ↓
    CloudFront phục vụ thẳng từ đó
    → đúng nhu cầu phân phối phim
      tới rạp toàn cầu

⚠ Và đây là lý do File Gateway hơn Volume Gateway ở đây: | Kiểu | Dữ liệu trên S3 | |---|---| | File Gateway | object đọc được | | Volume Gateway | snapshot EBS, không đọc trực tiếp |

Đề cần phân phối nội dung từ S3
  tới 38 thị trường
        ↓
    Phải đọc được object
    → File Gateway

⚠ Và vì sao phương án D không đầy đủ:

D dùng DataSync để di trú
        ↓
    Rồi "cấu hình truy cập độ trễ
      thấp"
        ↓
    Không nói cấu hình BẰNG CÁCH NÀO
        ↓
    Thiếu vế thứ hai của giải pháp

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Di trú nhanh nhất có thể | | | Truy cập liên tục không đổi ứng dụng | | | Dữ liệu là object S3, phân phối được ngay | |

⚠ Và CloudFront hoàn thiện bức tranh phân phối:

Nội dung nằm trên S3
        ↓
    CloudFront phân phối tới 38 thị
      trường
        ↓
    Rạp tải phim từ điểm biên gần
      nhất
    → đây là "tăng tốc phân phối
      trực tuyến"

⚠ Và cần chú ý khi dùng cả DataSync lẫn File Gateway trên cùng bucket:

DataSync ghi thẳng vào S3
        ↓
    File Gateway KHÔNG tự biết
        ↓
    Client NFS không thấy tệp mới
    → phải gọi `RefreshCache`

aws storagegateway refresh-cache \
  --file-share-arn <arn-share> --recursive

⚠ Và có thể tự động hoá việc làm mới cache:

S3 event notification khi có object
  mới
        ↓
    Lambda gọi `RefreshCache`
        ↓
    Nhưng với thư mục rất lớn thì
      thao tác này tốn thời gian
    → gọi theo tiền tố cụ thể

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

**A. Dùng S3 Transfer Acceleration để di trú rồi DataSync cho truy cập độ trễ thấp — đây là phương án gần nhất và cả hai công cụ đều liên quan tới việc chuyển dữ liệu, nhưng vai trò bị đảo: DataSync là công cụ đồng bộ theo lịch, không phải cơ chế truy cập liên tục.
**B. Dùng File Gateway để di trú rồi S3TA cho truy cập độ trễ thấp — cũng đảo vai trò; File Gateway chuyển dữ liệu chậm hơn DataSync, và S3TA chỉ tăng tốc tải lên chứ không cho truy cập kiểu hệ tệp.
**D. Dùng DataSync để di trú rồi "cấu hình truy cập độ trễ thấp" — vế đầu đúng nhưng vế sau không nêu cơ chế nào.

Ghi nhớ

⚠ Bốn công cụ chuyển và truy cập dữ liệu — bảng phải thuộc: | Công cụ | Vai trò | |---|---| | DataSync | đồng bộ hàng loạt, theo lịch | | File Gateway | truy cập liên tục qua NFS/SMB | | Transfer Family | đối tác gửi tệp qua SFTP | | Snow Family | chuyển ngoại tuyến |

Từ khoá nhận diện:

"migrate then keep accessing" → DataSync + File Gateway "one-time bulk transfer" → DataSync "low-latency access to S3 data from on-premises" → File Gateway "accelerate uploads from far away" → S3TA

Ba lưu ý về DataSync: | Lưu ý | Chi tiết | |---|---| | Cần agent khi nguồn ở tại chỗ | | | Có kiểm tra toàn vẹn sẵn | | | Giới hạn băng thông được | |

⚠ Hai chế độ kiểm tra: | Chế độ | Kiểm gì | |---|---| | POINT_IN_TIME_CONSISTENT | so toàn bộ đích với nguồn — chậm nhất, chắc nhất | | ONLY_FILES_TRANSFERRED | chỉ tệp vừa chuyển | | NONE | không kiểm |

Ba lưu ý về File Gateway: | Lưu ý | Chi tiết | |---|---| | Cache tối thiểu 150 GB | | | Mỗi tệp là một object S3 | | | Ghi thẳng vào S3 cần RefreshCache | |

Ba lưu ý về hiệu năng gateway: | Chỉ số | Ý nghĩa | |---|---| | CachePercentUsed | cache sắp đầy chưa | | CachePercentDirty | chưa lên S3 bao nhiêu | | CloudBytesUploaded | tốc độ đẩy lên |

Ba lưu ý về vòng đời S3: | Lưu ý | Chi tiết | |---|---| | Glacier Flexible/Deep: gateway KHÔNG đọc được | | | Glacier Instant Retrieval: đọc được ngay | | | Cẩn thận khi đặt luật chuyển tầng | |

⚠ Đây là bẫy thật với File Gateway:

Luật vòng đời chuyển tệp cũ sang
  Glacier
        ↓
    Client NFS đọc tệp đó
    → lỗi hoặc treo
        ↓
    Dùng Glacier Instant Retrieval
      nếu vẫn cần đọc

Ba lưu ý về phân phối nội dung: | Lớp | Việc | |---|---| | S3 | kho gốc | | CloudFront | phân phối toàn cầu | | Signed URL | kiểm soát ai tải được |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá khi truyền (TLS) mặc định | | | SSE-S3 hoặc SSE-KMS trên bucket | | | Giới hạn client-list theo CIDR | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So số tệp và dung lượng sau khi DataSync xong | | | Ghi một tệp qua gateway, kiểm nó xuất hiện trong S3 | | | Đọc tệp cũ và đo độ trễ khi cache miss | |

Và một lời khuyên: hãy gọi RefreshCache sau mỗi lần DataSync ghi vào bucket mà File Gateway đang phục vụ. Gateway giữ danh mục riêng của nó và không biết gì về những object được ghi thẳng vào S3 — nên tệp vừa di trú xong sẽ không xuất hiện với client NFS cho tới khi bạn bảo nó nhìn lại.

Câu 377 Chọn nhiều đáp án Design for New Solutions

An automobile company helps more than 20 million web and mobile users browse automobile dealer inventory, read vehicle reviews, and consume other automobile-related content by leveraging its library of 50 million vehicle photos uploaded by auto dealers. The company is planning a key update with even better image quality and faster load times on the company's website as well as mobile apps but the existing image-handling solution based on Cloudera MapReduce clusters is not the right tool for the job. The company now wants to switch to a serverless solution on AWS Cloud. As part of this process, the engineering team has been studying various best practices for serverless solutions. They intend to use AWS Lambda extensively and are looking at the salient features to consider when using Lambda as the backbone for the serverless architecture.

As a Solutions Architect Professional, which of the following would you identify as key considerations for a serverless architecture? (Select three)

A
If you intend to reuse code in more than one Lambda function, you should consider creating a Lambda Layer for the reusable code
B
Lambda allocates compute power in proportion to the memory you allocate to your function. AWS, thus recommends to over provision your function time out settings for the proper performance of Lambda functions
C
The bigger your deployment package, the slower your Lambda function will cold-start. Hence, AWS suggests packaging dependencies as a separate package from the actual Lambda package
D
Since Lambda functions can scale extremely quickly, it's a good idea to deploy a CloudWatch Alarm that notifies your team when function metrics such as ConcurrentExecutions or Invocations exceeds the expected threshold
E
Serverless databases and Lambda complement each other and you should install databases on the Lambda functions
F
By default, Lambda functions always operate from an AWS-owned VPC and hence have access to any public internet address or public AWS APIs. Once a Lambda function is VPC-enabled, it will need a route through a NAT gateway in a public subnet to access public resources

Xem giải thích

Đáp án

**A, D và F — Nếu định dùng lại mã ở nhiều hàm Lambda thì tạo Lambda Layer; đặt CloudWatch Alarm báo cho đội khi chỉ số như ConcurrentExecutions hay Invocations vượt ngưỡng; và Lambda mặc định chạy trong VPC do AWS sở hữu nên có Internet, còn khi bật VPC thì cần NAT gateway trong subnet công khai để ra ngoài.

Vì sao đúng

Ba mệnh đề này là ba thực hành nền tảng khi dùng Lambda ở quy mô lớn.

⚠ Mệnh đề A — Lambda Layer cho mã dùng chung:

Nhiều hàm cùng dùng một thư viện
  xử lý ảnh
        ↓
    Đóng gói vào từng hàm
    → gói triển khai lớn, khởi động
      nguội lâu
    → cập nhật thư viện phải triển
      khai lại mọi hàm
        ↓
    Layer: đóng gói một lần, nhiều
      hàm tham chiếu

aws lambda publish-layer-version \
  --layer-name thu-vien-anh \
  --zip-file fileb://layer.zip \
  --compatible-runtimes python3.12

aws lambda update-function-configuration \
  --function-name xu-ly-anh \
  --layers arn:aws:lambda:ap-southeast-1:111122223333:layer:thu-vien-anh:3

⚠ Layer giải nén vào /opt — phải đúng cấu trúc thư mục: | Runtime | Thư mục trong layer | |---|---| | Python | python/ hoặc python/lib/python3.12/site-packages/ | | Node.js | nodejs/node_modules/ | | Java | java/lib/ | | Mọi runtime (nhị phân) | bin/ |

⚠ Mệnh đề D — cảnh báo khi Lambda co giãn quá nhanh:

Lambda co giãn cực nhanh
        ↓
    Một lỗi hoặc một vòng lặp
    → hàng nghìn lời gọi trong vài
      phút
        ↓
    Và mỗi lời gọi đẩy tải xuống
      CSDL, API bên ngoài
        ↓
    Cảnh báo sớm là biện pháp bảo vệ

aws cloudwatch put-metric-alarm \
  --alarm-name lambda-dong-thoi-cao \
  --namespace AWS/Lambda \
  --metric-name ConcurrentExecutions \
  --statistic Maximum --period 60 \
  --evaluation-periods 1 --threshold 800 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

⚠ Và reserved concurrency là biện pháp chặn cứng:

aws lambda put-function-concurrency \
  --function-name xu-ly-anh \
  --reserved-concurrent-executions 200

Cảnh báo cho biết có chuyện
        ↓
    Reserved concurrency NGĂN thiệt
      hại lan rộng
        ↓
    Dùng cả hai

⚠ Mệnh đề F — Lambda và VPC:

Mặc định: hàm chạy trong VPC do
  AWS quản
        ↓
    Có đường ra Internet và tới mọi
      API công khai của AWS
        ↓
    Bật VPC của bạn: hàm mất đường
      ra Internet
    → phải có NAT gateway, hoặc
      VPC endpoint

⚠ Đây là bẫy kinh điển:

Đặt Lambda vào private subnet để
  truy cập RDS
        ↓
    Hàm không gọi được API S3 hay
      DynamoDB nữa
        ↓
    Vì subnet riêng không có đường
      ra
        ↓
    Thêm gateway endpoint cho S3
      và DynamoDB — MIỄN PHÍ
    → hoặc NAT gateway cho phần còn
      lại

⚠ Và đặt Lambda vào subnet CÔNG KHAI cũng không giúp:

Lambda ENI không có IP công khai
        ↓
    Dù ở subnet công khai vẫn không
      ra Internet được
        ↓
    Phải qua NAT gateway ở subnet
      công khai
    → và Lambda nằm ở subnet RIÊNG

⚠ Và vì sao mệnh đề B sai:

B nói AWS khuyến nghị "cấp dư
  TIMEOUT"
        ↓
    Vế đầu đúng: CPU tỷ lệ theo
      bộ nhớ
        ↓
    Nhưng khuyến nghị là điều chỉnh
      BỘ NHỚ, không phải timeout
        ↓
    Timeout dài chỉ khiến hàm lỗi
      chạy lâu hơn và tốn hơn

⚠ Và vì sao mệnh đề C sai:

C nói "đóng gói phụ thuộc thành
  gói RIÊNG với gói Lambda"
        ↓
    Vế đầu đúng: gói lớn khởi động
      nguội lâu hơn
        ↓
    Nhưng Layer KHÔNG giảm thời gian
      khởi động nguội
    → nội dung layer vẫn phải tải
      và giải nén
        ↓
    Layer là để DÙNG LẠI, không phải
      để tối ưu tốc độ

⚠ Và vì sao mệnh đề E vô lý:

E nói "cài cơ sở dữ liệu TRÊN hàm
  Lambda"
        ↓
    Lambda là môi trường thực thi
      tạm thời
        ↓
    Không có trạng thái giữa các
      lời gọi
    → không cài CSDL lên đó được

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mã dùng chung quản một chỗ | | | Phát hiện sớm khi hàm co giãn bất thường | | | Hiểu đúng ràng buộc mạng khi bật VPC | |

⚠ Và Hyperplane ENI làm Lambda trong VPC nhanh hơn nhiều so với trước:

Trước 2019: mỗi môi trường thực thi
  tạo một ENI
        ↓
    Khởi động nguội mất tới 10 giây
        ↓
    Nay: ENI dùng chung, tạo một lần
    → khởi động nguội gần như không
      khác gì ngoài VPC

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

⚠ Mệnh đề C thật ra chứa hai ý, và ý đầu đúng.

"Gói triển khai càng lớn, khởi động
  nguội càng chậm" — ĐÚNG
        ↓
    "Nên đóng gói phụ thuộc riêng"
      — sai nếu hiểu là dùng Layer
        ↓
    Layer không giảm khởi động nguội
    → tổng dung lượng vẫn tính vào
      giới hạn 250 MB (giải nén)

Cách thật sự giảm khởi động nguội: | Cách | Tác dụng | |---|---| | Provisioned concurrency | loại bỏ hẳn | | Giảm kích thước gói | giảm thời gian tải | | Tăng bộ nhớ | CPU mạnh hơn, khởi tạo nhanh hơn | | SnapStart (Java) | giảm tới 90% |

Và mệnh đề F đúng nhưng chưa đầy đủ: VPC endpoint là cách tốt hơn NAT gateway cho việc gọi dịch vụ AWS — gateway endpoint cho S3 và DynamoDB thì miễn phí hoàn toàn.

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

**C. Gói triển khai càng lớn thì khởi động nguội càng chậm, nên AWS khuyến nghị đóng gói phụ thuộc thành gói riêng — đây là phương án gần nhất và vế đầu hoàn toàn đúng, nhưng tách phụ thuộc ra layer không làm giảm thời gian khởi động nguội; layer là cơ chế dùng lại mã.
**B. Lambda cấp CPU tỷ lệ theo bộ nhớ nên AWS khuyến nghị cấp dư timeout — cấp dư bộ nhớ mới là khuyến nghị; timeout dài chỉ làm hàm lỗi tốn kém hơn.
**E. Cài cơ sở dữ liệu lên hàm Lambda — Lambda không có trạng thái bền vững giữa các lời gọi.

Ghi nhớ

⚠ Bốn giới hạn của Lambda phải thuộc: | Giới hạn | Giá trị | |---|---| | Timeout | 15 phút | | Bộ nhớ | 128 MB - 10 GB | | Gói triển khai (giải nén) | 250 MB gồm cả layer | | /tmp | 512 MB - 10 GB |

Từ khoá nhận diện:

"share code across functions" → Lambda Layer "eliminate cold starts" → provisioned concurrency "Lambda in VPC can't reach S3" → thiếu VPC endpoint hoặc NAT "protect downstream from Lambda scaling" → reserved concurrency

Ba lưu ý về Layer: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 layer mỗi hàm | | | Tính vào giới hạn 250 MB | | | Có phiên bản, chia sẻ liên tài khoản được | |

Ba lưu ý về tối ưu bộ nhớ: | Lưu ý | Chi tiết | |---|---| | CPU tỷ lệ tuyến tính theo bộ nhớ | | | Tăng bộ nhớ thường làm RẺ hơn | | | Lambda Power Tuning tìm điểm tối ưu | |

⚠ Vì sao tăng bộ nhớ có thể rẻ hơn:

Giá = GB × giây
        ↓
    512 MB × 4 giây = 2 GB-giây
        ↓
    1024 MB × 1,8 giây = 1,8 GB-giây
    → vừa nhanh hơn vừa rẻ hơn

Ba lưu ý về Lambda trong VPC: | Lưu ý | Chi tiết | |---|---| | Đặt ở private subnet | | | Gateway endpoint cho S3 và DynamoDB — miễn phí | | | NAT gateway cho phần còn lại | |

Ba lưu ý về khởi tạo: | Lưu ý | Chi tiết | |---|---| | Mã ngoài handler chạy một lần mỗi môi trường | | | Tái dùng client SDK và kết nối | | | Init Duration trong dòng REPORT | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | Throttles | bị chặn, mất việc | | ConcurrentExecutions | đang dùng bao nhiêu chỗ | | Duration p99 | đuôi dài do khởi động nguội |

Ba lưu ý về bảo vệ hệ thống phía sau: | Cách | Tác dụng | |---|---| | Reserved concurrency | giới hạn số lời gọi đồng thời | | RDS Proxy | gộp kết nối | | SQS đệm giữa | làm phẳng đỉnh |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy Lambda Power Tuning tìm cấu hình tối ưu | | | Kiểm Init Duration để biết tỷ lệ khởi động nguội | | | Thử gọi S3 từ hàm trong VPC | |

Và một lời khuyên: hãy đặt reserved concurrency cho mọi hàm gọi tới cơ sở dữ liệu. Lambda co giãn nhanh hơn hầu hết hệ thống phía sau chịu được, nên một đỉnh lưu lượng bình thường có thể biến thành sự cố cơ sở dữ liệu — và giới hạn đó là thứ duy nhất đứng giữa hai việc đó.

Câu 378 Design for New Solutions

A web hosting company's CFO recently analyzed the company's monthly bill for the AWS account for the development environment and identified an opportunity to reduce the cost for AWS Elastic Beanstalk infrastructure in use. The CFO in consultation with the CTO has hired you as an AWS Certified Solutions Architect Professional to design a highly available solution that will provision an Elastic Beanstalk environment in the morning and terminate it at the end of the day. The solution should be designed with minimal operational overhead with a focus on minimizing costs. The solution should also facilitate the increased use of Elastic Beanstalk environments among different development teams and must provide a one-stop scheduler solution for all teams to keep the operational costs as low as possible.

Which of the following solution designs will you suggest to address these requirements?

A
Configure the Elastic Beanstalk environment to use custom commands in the EC2 instance user data. Leverage the scheduled action for an Auto Scaling group to scale-out EC2 instances in the morning and scale-in the instance count to 0 to terminate the EC2 instances at the end of the day
B
Leverage the activity task of an AWS Step Function to provision and terminate the Elastic Beanstalk environment. Create a role for the Step Function to allow it to provision and terminate the Elastic Beanstalk environment. Execute the Step Function daily and use the "wait state" to control the start and stop time
C
Provision an EC2 Micro instance. Configure an IAM role with the required Elastic Beanstalk environment permissions and attach it to the instance profile. Create scripts on the instance to provision and terminate the Elastic Beanstalk environment. Set up cron jobs on the instance to execute the scripts
D
Set up separate Lambda functions to provision and terminate the Elastic Beanstalk environment. Configure a Lambda execution role granting the required Elastic Beanstalk environment permissions and assign the role to the Lambda functions. Configure cron expression based Amazon EventBridge events rules to trigger the Lambda functions

Xem giải thích

Đáp án

**D — Dựng hai hàm Lambda riêng để cấp phát và huỷ môi trường Elastic Beanstalk; gán một execution role có quyền cần thiết; và dùng quy tắc EventBridge theo biểu thức cron để kích hoạt hai hàm đó.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Sẵn sàng cao | Lambda và EventBridge đều là dịch vụ quản lý | | Ít việc vận hành nhất | không có máy chủ nào | | Chi phí thấp nhất | chỉ trả cho vài giây chạy mỗi ngày | | Một bộ lập lịch chung cho mọi đội | một cặp Lambda phục vụ nhiều môi trường |

⚠ Điểm mấu chốt: "ít việc vận hành và chi phí thấp nhất" loại phương án C ngay:

C dựng một EC2 Micro chạy cron
        ↓
    Máy đó chạy 24/7 chỉ để gọi
      hai lệnh mỗi ngày
        ↓
    Phải vá hệ điều hành, phải giám
      sát, và nó là điểm hỏng đơn lẻ
        ↓
    Lambda: chạy vài giây, không có
      gì để vá

Hàm cấp phát môi trường:

import boto3, os
eb = boto3.client('elasticbeanstalk')

def tao_moi_truong(event, context):
    for ten in event['danh_sach_moi_truong']:
        eb.create_environment(
            ApplicationName=event['ung_dung'],
            EnvironmentName=ten,
            SolutionStackName=os.environ['NEN_TANG'],
            VersionLabel=event['phien_ban'],
            OptionSettings=[{
                'Namespace': 'aws:autoscaling:asg',
                'OptionName': 'MinSize', 'Value': '1'}])

Hàm huỷ môi trường:

def xoa_moi_truong(event, context):
    for ten in event['danh_sach_moi_truong']:
        eb.terminate_environment(EnvironmentName=ten)

Quy tắc EventBridge theo cron:

aws events put-rule --name tao-moi-truong-sang \
  --schedule-expression "cron(0 1 ? * MON-FRI *)"

aws events put-rule --name xoa-moi-truong-toi \
  --schedule-expression "cron(0 11 ? * MON-FRI *)"

aws events put-targets --rule tao-moi-truong-sang \
  --targets 'Id=1,Arn=<arn-lambda-tao>,
    Input="{\"ung_dung\":\"app-dev\",
             \"danh_sach_moi_truong\":[\"dev-doi-a\",\"dev-doi-b\"]}"'

⚠ Cron của EventBridge dùng UTC — chi tiết hay vấp:

`cron(0 1 ? * MON-FRI *)`
        ↓
    1 giờ sáng UTC = 8 giờ sáng
      giờ Việt Nam
        ↓
    Không có múi giờ trong cron
      của EventBridge cổ điển
        ↓
    EventBridge Scheduler thì CÓ

aws scheduler create-schedule \
  --name tao-moi-truong \
  --schedule-expression "cron(0 8 ? * MON-FRI *)" \
  --schedule-expression-timezone "Asia/Ho_Chi_Minh" \
  --flexible-time-window '{"Mode":"OFF"}' \
  --target '{"Arn":"<arn-lambda>","RoleArn":"<arn-role>"}'

⚠ Và EventBridge Scheduler là dịch vụ mới, hợp hơn cho việc này: | Tiêu chí | EventBridge Rule | EventBridge Scheduler | |---|---|---| | Múi giờ | chỉ UTC | CÓ hỗ trợ | | Số lịch | hạn ngạch rule | hàng triệu | | Lịch một lần | không | CÓ (at()) | | Cửa sổ linh hoạt | không | CÓ |

⚠ Và vì sao phương án A sai — Beanstalk không hỗ trợ scale về 0:

A dùng scheduled action của ASG
  để scale-in về 0
        ↓
    Môi trường Beanstalk có
      `MinSize` tối thiểu là 1
        ↓
    Và scale về 0 không XOÁ môi
      trường
    → vẫn tính phí ELB, EBS, Elastic IP

⚠ Đây là điểm quan trọng: dừng máy không phải xoá môi trường:

Môi trường Beanstalk gồm:
    EC2 + ALB + ASG + security group
    + có thể cả RDS
        ↓
    Scale EC2 về 0
    → ALB vẫn tính phí
    → RDS vẫn chạy
        ↓
    Terminate môi trường mới xoá hết

⚠ Và vì sao phương án B không hợp:

B dùng Step Functions với "wait
  state" để điều khiển giờ bắt đầu
  và kết thúc
        ↓
    Step Functions Standard tính tiền
      theo SỐ CHUYỂN TRẠNG THÁI
        ↓
    Wait state chờ 10 giờ
    → máy trạng thái chạy suốt
        ↓
    Dùng hai lịch cron đơn giản hơn
      nhiều

⚠ Và "activity task" trong phương án B là khái niệm khác:

Activity task: Step Functions chờ
  một WORKER bên ngoài lấy việc
        ↓
    Worker đó phải chạy ở đâu đó
    → lại cần một máy chủ
        ↓
    Ý định của B có lẽ là service
      integration, nhưng nó viết
      là activity

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ nào để vá hay giám sát | | | Chi phí gần như bằng không | | | Một bộ Lambda phục vụ mọi đội | |

⚠ Và mở rộng cho nhiều đội chỉ cần thêm quy tắc:

Mỗi đội một quy tắc EventBridge
        ↓
    Với input JSON riêng
        ↓
    Cùng hai hàm Lambda
    → đây là "one-stop scheduler"
      mà đề yêu cầu

⚠ Và Instance Scheduler là giải pháp AWS dựng sẵn cho bài toán này:

AWS Instance Scheduler (solution
  chính thức)
        ↓
    Dựa trên Lambda + DynamoDB +
      EventBridge
        ↓
    Điều khiển bằng THẺ trên tài
      nguyên
    → không phải sửa lịch khi thêm
      môi trường

aws ec2 create-tags --resources i-0abc \
  --tags Key=Schedule,Value=gio-hanh-chinh

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

**C. Dựng một EC2 Micro với IAM role và cron chạy script cấp phát/huỷ môi trường — đây là phương án gần nhất và thật sự thực hiện được đúng việc, nhưng phải trả tiền và vận hành một máy chủ chạy 24/7 chỉ để gọi hai lệnh mỗi ngày, và nó là điểm hỏng đơn lẻ.
**A. Dùng scheduled action của Auto Scaling group để scale về 0 — Beanstalk có MinSize tối thiểu là 1, và scale EC2 về 0 không xoá ALB hay RDS nên vẫn tốn phí.
**B. Dùng activity task của Step Functions với "wait state" điều khiển giờ — máy trạng thái chạy suốt thời gian chờ, phức tạp và tốn hơn hai lịch cron đơn giản.

Ghi nhớ

⚠ Bốn cách chạy việc theo lịch trên AWS — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | EventBridge Scheduler | hiện đại nhất, có múi giờ, hàng triệu lịch | | EventBridge Rule cron | cổ điển, chỉ UTC | | Systems Manager Automation | luồng nhiều bước trên tài nguyên AWS | | Cron trên EC2 | phải vận hành máy chủ |

Từ khoá nhận diện:

"provision in morning, terminate at night" → Lambda + EventBridge "minimal operational overhead" → serverless, không EC2 "scheduler for all teams" → một Lambda, nhiều quy tắc "timezone-aware schedule" → EventBridge Scheduler

Ba lưu ý về EventBridge Scheduler: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ múi giờ và giờ mùa hè | | | Lịch một lần với at() | | | Gọi thẳng hơn 270 dịch vụ AWS | |

⚠ Gọi thẳng API mà không cần Lambda:

aws scheduler create-schedule --name dung-ec2 \
  --schedule-expression "cron(0 18 ? * MON-FRI *)" \
  --schedule-expression-timezone "Asia/Ho_Chi_Minh" \
  --flexible-time-window '{"Mode":"OFF"}' \
  --target '{"Arn":"arn:aws:scheduler:::aws-sdk:ec2:stopInstances",
             "RoleArn":"<arn-role>",
             "Input":"{\"InstanceIds\":[\"i-0abc\"]}"}'

Ba lưu ý về Elastic Beanstalk: | Lưu ý | Chi tiết | |---|---| | MinSize tối thiểu là 1 | | | Terminate xoá cả ALB và ASG | | | RDS trong môi trường bị xoá theo | |

⚠ Đây là lý do không nên đặt RDS trong môi trường Beanstalk:

RDS gắn với môi trường
        ↓
    Xoá môi trường → xoá CSDL
        ↓
    Tách RDS ra ngoài
    → xoá môi trường tự do

Ba lưu ý về tiết kiệm chi phí môi trường phát triển: | Cách | Tiết kiệm | |---|---| | Tắt ngoài giờ (8/24, 5/7) | ~76% | | Xoá hẳn và dựng lại | ~76% + phí lưu trữ | | Spot Instance | thêm ~70% cho phần chạy |

Ba lưu ý về Lambda execution role: | Lưu ý | Chi tiết | |---|---| | Quyền tối thiểu cho Beanstalk | | | Cần iam:PassRole cho instance profile | | | Ghi log vào CloudWatch | |

Ba lưu ý về theo dõi: | Việc | Cách | |---|---| | Cảnh báo khi hàm lỗi | alarm trên Errors | | Kiểm môi trường đã xoá chưa | query API buổi tối | | Cost Explorer theo thẻ môi trường | |

⚠ Cảnh báo khi hàm huỷ thất bại rất quan trọng:

Hàm huỷ lỗi im lặng
        ↓
    Môi trường chạy suốt đêm và
      cuối tuần
        ↓
    Không ai biết cho tới cuối tháng
    → đặt alarm trên `Errors`

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy tay hai hàm và xem kết quả | | | Kiểm sáng hôm sau môi trường có lên | | | So hoá đơn tháng trước và sau | |

Và một lời khuyên: hãy đặt cảnh báo cho hàm HUỶ môi trường chứ đừng chỉ lo hàm tạo. Khi hàm tạo lỗi thì cả đội biết ngay vì không có môi trường để làm việc — còn khi hàm huỷ lỗi thì mọi thứ chạy bình thường, chỉ có hoá đơn cuối tháng nói cho bạn biết.

Câu 379 Continuous Improvement for Existing Solutions

A stock trading firm uses AWS Cloud for its IT infrastructure. The firm runs several trading-risk simulation applications, developing complex algorithms to simulate diverse scenarios in order to evaluate the financial health of its customers. The firm stores customers' financial records on Amazon S3. The engineering team needs to implement an archival solution based on Amazon S3 Glacier to enforce regulatory and compliance controls on the archived data.

As a Solutions Architect Professional, which of the following solutions would you recommend?

A
Use S3 Glacier to store the sensitive archived data and then use an S3 Access Control List to enforce compliance controls
B
Use S3 Glacier to store the sensitive archived data and then use an S3 lifecycle policy to enforce compliance controls
C
Use S3 Glacier vault to store the sensitive archived data and then use an S3 Access Control List to enforce compliance controls
D
Use S3 Glacier vault to store the sensitive archived data and then use a vault lock policy to enforce compliance controls

Xem giải thích

Đáp án

**D — Dùng S3 Glacier vault để lưu dữ liệu nhạy cảm đã lưu trữ, và dùng vault lock policy để thực thi các kiểm soát tuân thủ.

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ một tổ hợp đáp ứng cả hai: | Yêu cầu | Thành phần | |---|---| | Lưu trữ dựa trên S3 Glacier | Glacier vault | | Thực thi kiểm soát tuân thủ và quy định | vault lock policy |

⚠ Điểm mấu chốt: vault lock là cơ chế WORM không đảo ngược được:

Vault lock policy khoá ở trạng thái
  LOCKED
        ↓
    KHÔNG AI sửa hay xoá được nữa
        ↓
    Kể cả tài khoản gốc, kể cả AWS
        ↓
    Đây chính là "thực thi" theo
      nghĩa tuân thủ

⚠ Và đây là điều phân biệt vault lock với mọi chính sách khác: | Cơ chế | Ai gỡ được | |---|---| | IAM policy | quản trị viên tài khoản | | S3 ACL | chủ object | | Lifecycle policy | quản trị viên tài khoản | | Vault lock (LOCKED) | KHÔNG AI |

Vault lock policy giữ 7 năm:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "cam-xoa-truoc-7-nam",
   "Effect": "Deny",
   "Principal": "*",
   "Action": "glacier:DeleteArchive",
   "Resource": "arn:aws:glacier:ap-southeast-1:111122223333:vaults/ho-so-tai-chinh",
   "Condition": {"NumericLessThan": {
     "glacier:ArchiveAgeInDays": "2555"}}}]}

Quy trình khoá hai bước:

aws glacier initiate-vault-lock \
  --account-id - --vault-name ho-so-tai-chinh \
  --policy file://chinh-sach.json

aws glacier complete-vault-lock \
  --account-id - --vault-name ho-so-tai-chinh \
  --lock-id <id-tu-buoc-tren>

⚠ Có 24 giờ để kiểm chứng trước khi khoá vĩnh viễn:

`initiate-vault-lock` → trạng thái
  InProgress
        ↓
    24 giờ để thử nghiệm chính sách
        ↓
    Đúng → `complete-vault-lock`
      → LOCKED vĩnh viễn
        ↓
    Sai → `abort-vault-lock` → huỷ
        ↓
    Quá 24 giờ không hoàn tất
    → tự huỷ, phải làm lại

⚠ Đây là thiết kế có chủ đích và rất đáng học:

Một chính sách không đảo ngược được
        ↓
    Cần một cửa sổ để phát hiện sai sót
        ↓
    24 giờ đủ để chạy kiểm thử
    → và ngắn đủ để không ai quên

⚠ Và vì sao hai phương án dùng ACL (A, C) sai:

S3 Access Control List
        ↓
    Kiểm soát AI ĐỌC/GHI được
        ↓
    Không có khái niệm "không được
      xoá trong N năm"
        ↓
    Và ACL sửa được bất cứ lúc nào
    → không phải cơ chế tuân thủ

⚠ Và ACL còn không áp cho Glacier vault:

Glacier vault (dịch vụ độc lập)
  không dùng S3 ACL
        ↓
    Nó có vault access policy và
      vault lock policy
        ↓
    Phương án C ghép hai thứ không
      liên quan

⚠ Và vì sao phương án B sai — lifecycle policy không phải kiểm soát tuân thủ:

Lifecycle policy chuyển tầng và
  xoá theo lịch
        ↓
    Nó là công cụ quản lý VÒNG ĐỜI
        ↓
    Quản trị viên sửa hoặc xoá luật
      bất cứ lúc nào
    → không "thực thi" được gì

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không ai xoá được dữ liệu trước hạn | | | Đáp ứng SEC 17a-4, FINRA, CFTC | | | Có cửa sổ 24 giờ để kiểm chứng | |

⚠ Và AWS có báo cáo đánh giá tuân thủ cho vault lock:

Cohasset Associates đánh giá
        ↓
    Xác nhận vault lock đáp ứng
      SEC Rule 17a-4(f)
        ↓
    Báo cáo đó dùng được khi kiểm
      toán

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

⚠ S3 Object Lock là cơ chế hiện hành, còn Glacier vault là dịch vụ cũ.

Tiêu chí	Glacier vault + vault lock	S3 + Object Lock
API	riêng, dùng archive ID	API S3 thông thường
Tên tệp	KHÔNG có	có key đọc được
Chế độ	một chính sách cho cả vault	Governance và Compliance, theo object
Legal hold	không	CÓ
Trạng thái	legacy	hiện hành

S3 Object Lock ở chế độ Compliance:

aws s3api create-bucket --bucket ho-so-tai-chinh \
  --object-lock-enabled-for-bucket

aws s3api put-object-lock-configuration \
  --bucket ho-so-tai-chinh \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {"DefaultRetention": {
      "Mode": "COMPLIANCE", "Years": 7}}}'

⚠ Hai chế độ của Object Lock: | Chế độ | Ai gỡ được | |---|---| | Governance | người có quyền s3:BypassGovernanceRetention | | Compliance | KHÔNG AI, kể cả root |

Chế độ Compliance tương đương
  vault lock
        ↓
    Nhưng linh hoạt hơn: đặt theo
      từng object
        ↓
    Và có legal hold — giữ vô thời
      hạn cho vụ kiện

aws s3api put-object-legal-hold \
  --bucket ho-so-tai-chinh --key ho-so/2026-Q3.pdf \
  --legal-hold Status=ON

Với kiến trúc hiện nay, cách đúng là S3 với lớp Glacier Deep Archive kèm Object Lock chế độ Compliance — vừa có WORM, vừa giữ được tên tệp và dùng API S3 thông thường.

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

**B. Dùng S3 Glacier lưu dữ liệu và S3 lifecycle policy để thực thi kiểm soát tuân thủ — đây là phương án gần nhất và lifecycle policy thật sự quản lý được vòng đời dữ liệu, nhưng nó không thực thi được gì: quản trị viên sửa hoặc xoá luật bất cứ lúc nào.
**C. Dùng Glacier vault và S3 Access Control List — ACL không áp cho Glacier vault, và nó chỉ kiểm soát quyền đọc/ghi chứ không có khái niệm thời hạn giữ.
**A. Dùng S3 Glacier và S3 ACL — cùng vấn đề với C.

Ghi nhớ

⚠ Bốn cơ chế WORM trên AWS — bảng phải thuộc: | Cơ chế | Áp cho | |---|---| | S3 Object Lock (Compliance) | object S3 | | Glacier Vault Lock | vault Glacier (legacy) | | AWS Backup Vault Lock | bản sao lưu | | CloudTrail log file validation | phát hiện sửa đổi, không chặn |

Từ khoá nhận diện:

"enforce compliance controls on archive" → vault lock hoặc Object Lock "nobody can delete, not even root" → Compliance mode "admin can override with special permission" → Governance mode "hold indefinitely for litigation" → legal hold

Ba lưu ý về Vault Lock: | Lưu ý | Chi tiết | |---|---| | Hai bước: initiate rồi complete | | | Cửa sổ kiểm chứng 24 giờ | | | Sau khi LOCKED thì vĩnh viễn | |

⚠ Vault access policy khác vault lock policy: | Loại | Sửa được | |---|---| | Vault access policy | CÓ, bất cứ lúc nào | | Vault lock policy | không, sau khi LOCKED |

Ba lưu ý về S3 Object Lock: | Lưu ý | Chi tiết | |---|---| | Phải bật khi TẠO bucket | | | Yêu cầu versioning | | | Đặt mặc định cho bucket hoặc theo từng object | |

⚠ Không bật được Object Lock cho bucket đã tồn tại:

Phải khai `--object-lock-enabled-for-bucket`
  lúc tạo
        ↓
    Bucket cũ: phải tạo bucket mới
      và chép sang
        ↓
    (AWS có quy trình đặc biệt qua
      Support, nhưng không tự làm
      được)

Ba lưu ý về AWS Backup Vault Lock: | Lưu ý | Chi tiết | |---|---| | Chống xoá bản sao lưu | | | Có chế độ governance và compliance | | | Bảo vệ khỏi mã độc tống tiền | |

⚠ Đây là lớp chống mã độc quan trọng:

Kẻ tấn công chiếm quyền admin
        ↓
    Xoá dữ liệu và xoá luôn bản
      sao lưu
        ↓
    Vault Lock chế độ compliance
    → không xoá được
    → còn đường khôi phục

Ba lưu ý về quy định tài chính: | Quy định | Yêu cầu | |---|---| | SEC 17a-4(f) | lưu trữ WORM, không sửa được | | FINRA 4511 | giữ 6 năm | | CFTC 1.31 | lưu trữ điện tử có kiểm soát |

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Lưu trữ Glacier Deep Archive | rẻ nhất | | Phí tối thiểu 180 ngày | Deep Archive | | Object Lock không tính phí thêm | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử xoá một object trong thời hạn — phải bị từ chối | | | Kiểm chính sách trong 24 giờ trước khi khoá | | | Xác nhận trạng thái là Locked | |

Và một lời khuyên: hãy dùng trọn 24 giờ cửa sổ kiểm chứng để thử mọi thao tác mà chính sách phải chặn. Vault lock ở trạng thái LOCKED là quyết định không đảo ngược được với bất kỳ ai — một chính sách viết sai sẽ khoá dữ liệu của bạn theo cách không ai sửa nổi cho tới khi hết thời hạn giữ.

Câu 380 Design for New Solutions

An e-commerce company has its flagship application hosted on Amazon EC2 instances that are configured in an Auto Scaling group behind a public-facing Application Load Balancer (ALB). The application should only be accessible to users from a specific country. The company also needs the ability to monitor any prohibited requests for further analysis by the security team.

What will you suggest as the most optimal and low-maintenance solution for the given use case?

A
Create a Global Accelerator and attach the WAF to it. Create a rule to block any requests that do not originate from the specified country. Create the Global Accelerator to front the existing ALB
B
Set up an AWS WAF web ACL. Create a rule to block the requests that do not originate from the IP range defined in an IP set containing a list of IP ranges that belong to the specified country. Attach the rule with the web ACL. Attach the web ACL with the ALB
C
Set up an AWS Web Application Firewall (WAF) web ACL. Create a rule to deny any requests that do not originate from the specified country. Attach the rule with the web ACL. Attach the web ACL with the ALB
D
Set up AWS Shield to block any request that does not originate from the specified country. Attach AWS Shield with the ALB

Xem giải thích

Đáp án

**C — Dựng một AWS WAF web ACL, tạo quy tắc từ chối mọi yêu cầu không xuất phát từ quốc gia đã khai, gắn quy tắc vào web ACL và gắn web ACL vào ALB.

Vì sao đúng

Đề nêu hai yêu cầu, và WAF geo match đáp ứng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Chỉ cho phép người dùng từ một quốc gia | geo match statement | | Giám sát yêu cầu bị chặn để phân tích | WAF log và sampled request |

⚠ Điểm mấu chốt: geo match dùng cơ sở dữ liệu GeoIP do AWS duy trì:

WAF tra IP nguồn trong cơ sở dữ
  liệu địa lý
        ↓
    Trả về mã quốc gia hai chữ cái
        ↓
    So với danh sách đã khai
    → AWS lo việc cập nhật dữ liệu
      đó

Quy tắc chỉ cho phép một quốc gia:

{"Name": "chi-cho-phep-viet-nam",
 "Priority": 0,
 "Statement": {"NotStatement": {
   "Statement": {"GeoMatchStatement": {
     "CountryCodes": ["VN"]}}}},
 "Action": {"Block": {}},
 "VisibilityConfig": {
   "SampledRequestsEnabled": true,
   "CloudWatchMetricsEnabled": true,
   "MetricName": "chanNgoaiVietNam"}}

⚠ NotStatement là cách diễn đạt "không phải quốc gia này":

GeoMatchStatement khớp khi Ở TRONG
  danh sách
        ↓
    Bọc bằng NotStatement
    → khớp khi KHÔNG ở trong danh sách
        ↓
    Hành động Block
    → chỉ quốc gia đã khai đi qua

⚠ Và vì sao phương án B kém hơn — duy trì danh sách IP thủ công:

B dùng IP set chứa dải IP của một
  quốc gia
        ↓
    Danh sách IP của một quốc gia
      có hàng nghìn dải
        ↓
    Và thay đổi liên tục
    → phải tự cập nhật mãi mãi
        ↓
    Đề nói "ít bảo trì nhất"

⚠ Và IP set có hạn ngạch: | Hạn ngạch | Giá trị | |---|---| | Địa chỉ mỗi IP set | 10.000 | | Số IP set mỗi tài khoản | 100 |

Một quốc gia lớn có thể có hơn
  10.000 dải IP
        ↓
    Không chứa hết trong một IP set

⚠ Và vì sao phương án A phức tạp không cần thiết:

A đặt Global Accelerator TRƯỚC ALB
  rồi gắn WAF vào Global Accelerator
        ↓
    WAF KHÔNG gắn được vào Global
      Accelerator
        ↓
    WAF gắn vào: CloudFront, ALB,
      API Gateway, AppSync, Cognito,
      App Runner, Verified Access

⚠ Và vì sao phương án D sai — Shield không lọc theo quốc gia:

AWS Shield chống DDoS
        ↓
    Shield Standard: tự động, tầng 3/4
        ↓
    Shield Advanced: thêm bảo vệ
      tầng 7 và đội ứng cứu
        ↓
    Nhưng không có luật lọc theo
      quốc gia
    → đó là việc của WAF

⚠ Và yêu cầu "giám sát yêu cầu bị cấm" được đáp ứng bằng hai cơ chế:

Sampled requests: WAF giữ mẫu
  yêu cầu gần đây trong console
        ↓
    WAF logging: ghi toàn bộ vào
      S3, CloudWatch Logs, hoặc
      Firehose

aws wafv2 put-logging-configuration --logging-configuration '{
  "ResourceArn": "<arn-webacl>",
  "LogDestinationConfigs": ["arn:aws:s3:::aws-waf-logs-ung-dung"],
  "LoggingFilter": {
    "DefaultBehavior": "DROP",
    "Filters": [{
      "Behavior": "KEEP", "Requirement": "MEETS_ANY",
      "Conditions": [{"ActionCondition": {"Action": "BLOCK"}}]}]}}'

⚠ Lọc chỉ ghi yêu cầu bị chặn giảm mạnh chi phí log:

Ghi mọi yêu cầu
        ↓
    Với lưu lượng lớn, đây là khoản
      tiền đáng kể
        ↓
    Chỉ ghi BLOCK
    → đúng thứ đội bảo mật cần phân
      tích

Truy vấn log bằng Athena:

SELECT httprequest.country, httprequest.clientip,
       COUNT(*) AS so_luot
FROM waf_logs
WHERE action = 'BLOCK' AND ngay = '2026-09-01'
GROUP BY httprequest.country, httprequest.clientip
ORDER BY so_luot DESC LIMIT 20;

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AWS lo việc cập nhật dữ liệu địa lý | | | Không phải duy trì danh sách IP nào | | | Log sẵn cho đội bảo mật phân tích | |

⚠ Và nên thử ở chế độ Count trước khi Block:

"Action": {"Count": {}}

Chạy vài ngày ở Count
        ↓
    Xem chỉ số CloudWatch và log
        ↓
    Xác nhận không chặn nhầm khách
      hàng thật
    → rồi mới đổi sang Block

⚠ Nhưng geo match không tuyệt đối:

VPN và proxy làm sai kết quả
        ↓
    Cơ sở dữ liệu GeoIP có sai số
        ↓
    Chặn theo quốc gia là biện pháp
      giảm nhiễu
    → không phải kiểm soát an ninh
      chặt chẽ

⚠ Và cần cấu hình để WAF thấy IP thật khi có CloudFront:

"GeoMatchStatement": {
  "CountryCodes": ["VN"],
  "ForwardedIPConfig": {
    "HeaderName": "X-Forwarded-For",
    "FallbackBehavior": "MATCH"}}

Không cấu hình: WAF trên ALB thấy
  IP của CloudFront
        ↓
    Mọi yêu cầu trông như đến từ Mỹ
    → chặn hết

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

**B. Dựng web ACL với quy tắc chặn yêu cầu không nằm trong dải IP của IP set chứa danh sách IP của quốc gia đó — đây là phương án gần nhất và hoạt động được về mặt kỹ thuật, nhưng phải tự duy trì hàng nghìn dải IP luôn thay đổi, trái với yêu cầu ít bảo trì.
**A. Tạo Global Accelerator và gắn WAF vào nó — WAF không gắn được vào Global Accelerator.
**D. Dùng AWS Shield để chặn yêu cầu không từ quốc gia đã khai — Shield chống DDoS, không có luật lọc theo quốc gia.

Ghi nhớ

⚠ WAF gắn được vào đâu — bảng phải thuộc: | Dịch vụ | Gắn được | |---|---| | CloudFront | CÓ (scope CLOUDFRONT) | | ALB | CÓ (scope REGIONAL) | | API Gateway | CÓ | | AppSync, Cognito, App Runner | CÓ | | NLB | KHÔNG | | Global Accelerator | KHÔNG |

Từ khoá nhận diện:

"allow only one country" → WAF geo match với NotStatement "monitor blocked requests" → WAF logging + sampled requests "DDoS protection" → Shield "WAF on Global Accelerator" → luôn SAI

Ba lưu ý về geo match: | Lưu ý | Chi tiết | |---|---| | Mã quốc gia ISO 3166-1 alpha-2 | | | Dữ liệu GeoIP do AWS duy trì | | | ForwardedIPConfig khi sau CDN | |

Ba lưu ý về thứ tự quy tắc: | Lưu ý | Chi tiết | |---|---| | Priority thấp xét trước | | | Allow và Block kết thúc việc xét | | | Count tiếp tục xét quy tắc sau | |

Ba lưu ý về default action: | Cấu hình | Nghĩa | |---|---| | Allow | cho qua trừ khi có quy tắc Block khớp | | Block | chặn trừ khi có quy tắc Allow khớp |

⚠ Default Block là cách chặt hơn:

DefaultAction: Block
        ↓
    Quy tắc Allow cho geo match VN
        ↓
    Chỉ Việt Nam đi qua
    → và mọi thứ chưa nghĩ tới đều
      bị chặn

Ba lưu ý về WAF logging: | Lưu ý | Chi tiết | |---|---| | Đích: S3, CloudWatch Logs, Firehose | | | Tên phải bắt đầu aws-waf-logs- (Firehose) | | | Lọc để giảm chi phí | |

Ba lưu ý về managed rule: | Nhóm | Chống | |---|---| | CommonRuleSet | OWASP phổ biến | | IPReputationList | IP có tiếng xấu | | BotControl | bot tự động |

Ba lưu ý về chi phí WAF: | Khoản | Giá xấp xỉ | |---|---| | Web ACL | 5 USD/tháng | | Mỗi quy tắc | 1 USD/tháng | | Mỗi triệu yêu cầu | 0,60 USD |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi qua VPN từ nước khác — phải 403 | | | Xem sampled requests trong console | | | Truy vấn log tìm terminatingRuleId | |

Và một lời khuyên: hãy chạy quy tắc ở chế độ Count vài ngày trước khi chuyển sang Block. Cơ sở dữ liệu GeoIP không hoàn hảo, và một tỷ lệ nhỏ khách hàng thật luôn bị nhận diện sai quốc gia — bạn muốn biết con số đó trước khi họ không vào được website.

Trang 38 / 123 — tổng 1221 câu hỏi