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

Tìm thấy 1221 câu.

Câu 141 Domain - Continuous Improvement for Existing Solutions

A company has recently released a new mobile game. With the boost in marketing, the mobile game suddenly became viral. The registration webpage is bombarded with user registrations from around the world. The registration website is hosted on a fleet of Amazon EC2 instances created as an Auto Scaling group. This cluster is behind an Application Load Balancer to balance the user traffic. The website contains static content that is loaded differently depending on the user’s device type. With the sudden increase in user traffic, the fleet of Amazon EC2 instances experienced high CPU usage and users are reporting sluggishness on the website.

Which of the following options should the Solutions Architect implement to improve the website response time?

  1. A

    Use a Network Load Balancer (NLB) instead of an ALB to distribute the user traffic. Create a dedicated Auto Scaling group for the different device types. Configure the NLB to parse the User-Agent HTTP header to route the users to the appropriate EC2 Auto Scaling groups.
  2. B

    Create an Amazon S3 bucket to host the static contents. Set this bucket as the origin for an Amazon CloudFront distribution. Write a Lambda@Edge function to parse the User-Agent HTTP header and serve the appropriate contents based on the user’s device type.
  3. C

    Create a dedicated Auto Scaling group for the different device types and create separate Application Load Balancers (ALB) for each group. Create an Amazon Route 53 entry to route the users to the appropriate ALB depending on their User-Agent HTTP header.
  4. D

    Create an Amazon S3 bucket to host the static contents. Set this bucket as the origin for an Amazon CloudFront distribution. Configure CloudFront to deliver different contents depending on the user’s User-Agent HTTP header.
Xem giải thích

Đáp án

**B — Tạo bucket S3 chứa nội dung tĩnh, đặt làm origin cho CloudFront, và viết hàm Lambda@Edge đọc header User-Agent để phục vụ nội dung phù hợp với loại thiết bị.

Vì sao đúng

Đề nêu hai vấn đề, và phương án này lo cả hai: | Vấn đề | Cách giải | |---|---| | EC2 quá tải CPU vì phục vụ nội dung tĩnh | chuyển tĩnh sang S3 + CloudFront | | Nội dung khác nhau theo loại thiết bị | Lambda@Edge đọc User-Agent |

⚠ Chuyển nội dung tĩnh khỏi EC2 là biện pháp có tác dụng lớn nhất:

Instance vừa chạy logic vừa phục vụ
  ảnh, CSS, JS
        ↓
    Phần lớn CPU tiêu vào việc mà
      S3 làm miễn phí và tốt hơn
        ↓
    Tách ra: EC2 chỉ lo phần động
    → và CloudFront cache phần tĩnh
      ở biên

⚠ Và CloudFront có sẵn header thiết bị — không cần tự phân tích:

CloudFront-Is-Mobile-Viewer
CloudFront-Is-Tablet-Viewer
CloudFront-Is-Desktop-Viewer
CloudFront-Is-SmartTV-Viewer
        ↓
    Bốn header này CloudFront tự sinh
      từ User-Agent
    → dùng chúng thay vì tự viết
      logic phân loại

Cache policy dùng header thiết bị:

{"ParametersInCacheKeyAndForwardedToOrigin": {
  "HeadersConfig": {
    "HeaderBehavior": "whitelist",
    "Headers": {"Quantity": 3, "Items": [
      "CloudFront-Is-Mobile-Viewer",
      "CloudFront-Is-Tablet-Viewer",
      "CloudFront-Is-Desktop-Viewer"]}},
  "CookiesConfig": {"CookieBehavior": "none"},
  "QueryStringsConfig": {"QueryStringBehavior": "none"}}}

⚠ Vì sao dùng ba header này thay vì User-Agent thô:

`User-Agent` có hàng chục nghìn giá trị
  khác nhau
        ↓
    Đưa vào cache key
    → mỗi biến thể là một mục cache riêng
    → tỷ lệ trúng cache gần bằng 0
        ↓
    Ba header true/false
    → tối đa vài tổ hợp
    → cache hiệu quả

Đây là điểm phân biệt quan trọng nhất giữa B và D.

Hàm Lambda@Edge:

exports.handler = async (su_kien) => {
  const yeu_cau = su_kien.Records[0].cf.request;
  const header = yeu_cau.headers;
  let thu_muc = 'may-tinh';
  if (header['cloudfront-is-mobile-viewer']?.[0].value === 'true')
    thu_muc = 'di-dong';
  else if (header['cloudfront-is-tablet-viewer']?.[0].value === 'true')
    thu_muc = 'may-tinh-bang';
  yeu_cau.uri = `/${thu_muc}${yeu_cau.uri}`;
  return yeu_cau;
};

⚠ Đặt hàm ở ORIGIN REQUEST, không phải viewer request: | Trigger | Chạy khi | Chi phí | |---|---|---| | Viewer request | MỌI yêu cầu | cao | | Origin request | chỉ khi cache trượt | thấp hơn nhiều |

Việc viết lại URL chỉ cần làm khi
  đi lấy từ origin
        ↓
    Cache trúng thì đã có đúng nội dung
    → không cần chạy hàm

⚠ Và CloudFront Functions còn rẻ hơn nếu đủ dùng:

Việc ở đây chỉ là đọc header và
  sửa đường dẫn
        ↓
    CloudFront Functions làm được
    → rẻ hơn khoảng 6 lần Lambda@Edge
        ↓
    Nhưng Functions chỉ chạy ở
      viewer request/response
    → cân nhắc theo lưu lượng thật

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | CPU của EC2 giảm mạnh | | | Nội dung phục vụ từ điểm gần người dùng | | | Logic phân loại chạy ở biên, không tốn round-trip | |

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

  • **D. Cùng kiến trúc S3 + CloudFront nhưng cấu hình CloudFront phân phối nội dung khác nhau theo header User-Agent — đây là phương án gần nhất và ý tưởng đúng, nhưng CloudFront không có cơ chế "chọn nội dung khác nhau" chỉ bằng cấu hình; đưa User-Agent thô vào cache key làm tỷ lệ trúng cache sụp đổ vì header đó có hàng chục nghìn biến thể.
  • **C. Tạo ASG riêng cho mỗi loại thiết bị với ALB riêng và Route 53 định tuyến theo User-Agent — Route 53 định tuyến ở tầng DNS, nó không nhìn thấy header HTTP nào; và nhân ba hạ tầng là đi ngược mục tiêu giảm tải.
  • **A. Dùng NLB thay ALB và cho NLB phân tích header User-Agent — NLB làm việc ở tầng 4, nó không đọc được header HTTP.

Ghi nhớ

⚠ Bốn tuỳ chọn tính toán ở biên — bảng phải thuộc: | Tuỳ chọn | Chạy ở | Giới hạn | |---|---|---| | CloudFront Functions | viewer request/response | dưới 1ms, JS giới hạn, không gọi mạng | | Lambda@Edge | cả bốn trigger | tới 5 hoặc 30 giây, gọi mạng được | | Cache policy | cấu hình thuần | không có logic | | Origin request policy | cấu hình thuần | quyết định gửi gì tới origin |

Từ khoá nhận diện:

"different content per device type" → header CloudFront-Is-*-Viewer "rewrite URL at the edge" → CloudFront Functions hoặc Lambda@Edge "authenticate at the edge" → Lambda@Edge viewer request "route by HTTP header" → ALB listener rule, KHÔNG phải Route 53

⚠ ALB cũng định tuyến theo header được:

aws elbv2 create-rule --listener-arn <arn> --priority 10 \
  --conditions '[{"Field":"http-header",
    "HttpHeaderConfig":{"HttpHeaderName":"User-Agent",
      "Values":["*Mobile*"]}}]' \
  --actions Type=forward,TargetGroupArn=<arn-tg-di-dong>

Nhưng ở đây tách tĩnh khỏi động
  mới là biện pháp giải quyết
  vấn đề CPU

Ba lưu ý về cache key: | Lưu ý | Chi tiết | |---|---| | Càng ít thành phần, tỷ lệ trúng càng cao | | | Chỉ đưa vào thứ THẬT SỰ đổi nội dung | | | Cookie phiên trong cache key phá hỏng cache | |

⚠ Tách cache policy khỏi origin request policy:

Cache policy: cái gì vào CACHE KEY
Origin request policy: cái gì GỬI TỚI origin
        ↓
    Origin cần `User-Agent` để ghi log
    → đưa vào origin request policy
    → KHÔNG đưa vào cache key

Ba lưu ý về Lambda@Edge: | Lưu ý | Chi tiết | |---|---| | Phải triển khai ở us-east-1 | | | Chỉ dùng phiên bản đánh số | | | Log nằm ở Region gần người dùng | |

Ba lưu ý về S3 làm origin: | Lưu ý | Chi tiết | |---|---| | Dùng OAC để bucket không công khai | | | Đặt Cache-Control dài cho tệp có mã băm | | | Bật nén ở CloudFront | |

Ba lưu ý về đo lường: | Chỉ số | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả cache | | OriginLatency | origin có phải nút thắt không | | CPU của EC2 | đã giảm chưa |

⚠ Phải bật chỉ số bổ sung mới thấy CacheHitRate:

aws cloudfront create-monitoring-subscription \
  --distribution-id <id> \
  --monitoring-subscription \
    RealtimeMetricsSubscriptionConfig={RealtimeMetricsSubscriptionStatus=Enabled}

Ba lưu ý về ảnh thích ứng: | Lưu ý | Chi tiết | |---|---| | Phục vụ ảnh nhỏ hơn cho di động | | | Dùng WebP hoặc AVIF nếu trình duyệt hỗ trợ | | | Đây thường là phần nặng nhất của trang | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl với User-Agent di động và máy tính | | | Xem header X-Cache có trúng cache không | | | Theo dõi CPU của EC2 trước và sau | |

Và một lời khuyên: hãy dùng các header CloudFront-Is-*-Viewer thay vì tự phân tích User-Agent. Chúng có ít giá trị nên cache vẫn hiệu quả, và bạn không phải bảo trì một danh sách chuỗi trình duyệt vốn thay đổi mỗi lần có thiết bị mới ra đời.

Câu 142 Domain - Design for New Solutions

An electronics and communications company in Japan has several VPCs in the AWS cloud. It uses NAT instances to allow multiple EC2 instances from the private subnet to initiate connections to the Internet while also restricting any requests coming from the outside network. However, there are numerous incidents where the NAT instance is not available, which affects the batch processing of critical applications.

Which is the most suitable solution that provides better availability and bandwidth to the current infrastructure with minimal administrative effort?

  1. A

    Launch two large NAT instances in two separate public subnets and add a route from the private subnet to each NAT instance to make it more fault-tolerant and highly available.
  2. B

    Launch a larger NAT instance with the enhanced networking feature enabled to improve the availability and performance of the NAT device.
  3. C

    Create a NAT gateway then specify its corresponding subnet and Elastic IP address. Update the route tables of the private subnet to point the Internet traffic to the NAT gateway.
  4. D

    Create an egress-only Internet gateway. Update the route tables of the private subnet to point the Internet traffic to the egress-only Internet gateway.
Xem giải thích

Đáp án

**C — Tạo NAT gateway, chỉ định subnet và Elastic IP cho nó, rồi cập nhật bảng định tuyến của subnet riêng tư để lưu lượng Internet đi qua NAT gateway.

Vì sao đúng

Đề nêu một vấn đề và ba tiêu chí, và NAT gateway thắng ở cả ba: | Tiêu chí | NAT instance | NAT gateway | |---|---|---| | Tính sẵn sàng | tự lo — một máy là một điểm hỏng | AWS lo, dư thừa trong AZ | | Băng thông | theo loại instance | tới 100 Gbps, tự co giãn | | Công sức quản trị | vá lỗi, giám sát, thay máy | gần như bằng 0 |

⚠ Đây là lý do NAT instance không nên dùng cho hệ thống sản xuất:

NAT instance là một EC2 bình thường
    → phải tự vá hệ điều hành
    → phải tự theo dõi và thay khi hỏng
    → phải tắt `source/dest check`
        ↓
    Và nó vẫn là MỘT máy
    → hỏng là toàn bộ subnet riêng
      mất đường ra

Tạo NAT gateway:

aws ec2 allocate-address --domain vpc
aws ec2 create-nat-gateway \
  --subnet-id subnet-cong-khai-1a \
  --allocation-id eipalloc-abc \
  --connectivity-type public

Cập nhật bảng định tuyến:

aws ec2 create-route \
  --route-table-id rtb-subnet-rieng-1a \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-abc

⚠ NAT gateway phải nằm trong subnet CÔNG KHAI:

NAT trong subnet riêng tư
    → chính nó không ra được Internet
        ↓
    Subnet của NAT phải có tuyến
      0.0.0.0/0 → Internet gateway
    → đây là lỗi cấu hình phổ biến nhất

⚠ Và NAT gateway chỉ dư thừa TRONG một AZ:

NAT gateway ở AZ-a
    → AZ-a hỏng là subnet riêng ở
      AZ-b và AZ-c cũng mất đường ra
        ↓
    Đúng cách: MỘT NAT gateway
      mỗi AZ
    → mỗi bảng định tuyến trỏ tới
      NAT trong cùng AZ

AZ-a: subnet riêng → NAT-a → IGW
AZ-b: subnet riêng → NAT-b → IGW
AZ-c: subnet riêng → NAT-c → IGW
        ↓
    Mất một AZ không ảnh hưởng hai AZ kia
    → và tránh phí truyền liên AZ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AWS lo vá lỗi và sẵn sàng | | | Băng thông tự co giãn tới 100 Gbps | | | Không có gì để giám sát ngoài chi phí | |

⚠ Đổi lại là chi phí — và nó không nhỏ:

Phí theo GIỜ chạy
    + phí theo GB xử lý
        ↓
    Đội máy tải nhiều dữ liệu qua NAT
    → hoá đơn NAT có khi lớn hơn
      chi phí EC2

⚠ Giảm chi phí bằng VPC endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-rieng-1a rtb-rieng-1b

Gateway endpoint cho S3 và DynamoDB:
  MIỄN PHÍ
        ↓
    Lưu lượng tới hai dịch vụ này
      không qua NAT nữa
    → thường là phần lớn nhất
      của hoá đơn NAT

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

  • **A. Dựng hai NAT instance lớn ở hai subnet công khai và thêm tuyến từ subnet riêng tới mỗi cái — đây là phương án gần nhất và thật sự cải thiện tính sẵn sàng, nhưng bảng định tuyến không cân bằng tải giữa hai tuyến cùng đích; và vẫn phải tự vá, tự giám sát, tự viết script chuyển đổi.
  • **B. Dùng NAT instance lớn hơn có enhanced networking — tăng băng thông nhưng vẫn là một điểm hỏng duy nhất, và vẫn là công sức quản trị.
  • **D. Tạo egress-only Internet gateway — dịch vụ này chỉ dành cho IPv6; với IPv4 thì không dùng được.

Ghi nhớ

⚠ Bốn cổng ra Internet — bảng phải thuộc: | Cổng | Dùng cho | |---|---| | Internet gateway | subnet công khai, hai chiều | | NAT gateway | subnet riêng IPv4, chỉ đi ra | | Egress-only IGW | subnet riêng IPv6, chỉ đi ra | | VPC endpoint | tới dịch vụ AWS, không qua Internet |

Từ khoá nhận diện:

"private subnet needs outbound IPv4" → NAT gateway "private subnet needs outbound IPv6" → egress-only IGW "reduce NAT cost for S3 traffic" → gateway endpoint "filter outbound by URL" → proxy hoặc Network Firewall

Ba lưu ý về NAT gateway: | Lưu ý | Chi tiết | |---|---| | Một cái mỗi AZ cho sẵn sàng cao | | | Cần Elastic IP | | | Không gắn security group được | |

⚠ Điểm cuối hay gây bất ngờ:

NAT gateway KHÔNG có security group
    → kiểm soát bằng SG của chính
      instance phía sau
    → và bằng NACL của subnet

Ba lưu ý về hạn ngạch: | Lưu ý | Chi tiết | |---|---| | Tối đa 55.000 kết nối đồng thời tới mỗi đích | | | Vượt: lỗi ErrorPortAllocation | | | Chia tải sang nhiều NAT nếu chạm trần | |

⚠ Chỉ số cần theo dõi:

aws cloudwatch put-metric-alarm \
  --alarm-name nat-het-cong --namespace AWS/NATGateway \
  --metric-name ErrorPortAllocation \
  --statistic Sum --period 300 --threshold 0 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=NatGatewayId,Value=nat-abc

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Phí giờ + phí GB xử lý | | | Gateway endpoint cho S3/DynamoDB miễn phí | | | Interface endpoint có phí nhưng thường rẻ hơn NAT | |

⚠ Phân tích chi phí NAT bằng flow log:

SELECT dstaddr, SUM(bytes) AS tong
FROM vpc_flow_logs
WHERE interface_id = '<eni-cua-nat>'
GROUP BY dstaddr ORDER BY tong DESC LIMIT 20

Thấy đích nào chiếm nhiều băng thông nhất
    → thường là S3, ECR, hoặc kho gói
        ↓
    Tạo endpoint cho chúng
    → giảm hoá đơn ngay

Ba lưu ý về NAT instance (khi nào vẫn dùng): | Trường hợp | Lý do | |---|---| | Môi trường thử nghiệm rất nhỏ | rẻ hơn | | Cần chức năng thêm (proxy, lọc) | NAT gateway không lọc được | | Ngoài ra: luôn dùng NAT gateway | |

Ba lưu ý về bảng định tuyến: | Lưu ý | Chi tiết | |---|---| | Mỗi subnet gắn đúng một bảng | | | Tuyến local không xoá được | | | Tiền tố dài nhất thắng | |

Ba lưu ý về IPv6: | Lưu ý | Chi tiết | |---|---| | IPv6 không cần NAT | | | Egress-only IGW cho chiều ra | | | Mọi địa chỉ IPv6 đều định tuyến công khai | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl ra Internet từ instance riêng tư | | | Kiểm mỗi AZ có NAT riêng | | | Xem BytesOutToDestination để biết chi phí | |

Và một lời khuyên: hãy tạo gateway endpoint cho S3 và DynamoDB ngay khi dựng VPC. Chúng miễn phí, mất hai phút để tạo, và thường cắt phần lớn nhất của hoá đơn NAT — khoản mà đa số chỉ phát hiện ra sau vài tháng nhìn vào bảng chi phí.

Câu 143 Domain - Design Solutions for Organizational Complexity

A telecommunications company has several Amazon EC2 instances inside an AWS VPC. To improve data leak protection, the company wants to restrict the internet connectivity of its EC2 instances. The EC2 instances that are launched on a public subnet should be able to access product updates and patches from the Internet. The packages are accessible through the third-party provider via their URLs. The company wants to explicitly deny any other outbound connections from the VPC instances to hosts on the Internet.

Which of the following options would the solutions architect consider implementing to meet the company requirements?

  1. A Move all instances from the public subnets to the private subnets. Additionally, remove the default routes from your routing tables and replace them instead with routes that specify your package locations.
  2. B Use network ACL rules that allow network access to your specific package destinations. Add an implicit deny for all other cases.
  3. C You can use a forward web proxy server in your VPC and manage outbound access using URL-based rules. Default routes are also removed.
  4. D Create security groups with the appropriate outbound access rules that will let you retrieve software packages from the Internet.
Xem giải thích

Đáp án

**C — Dùng máy chủ proxy web chuyển tiếp trong VPC, quản lý truy cập ra bằng luật theo URL, và gỡ bỏ tuyến mặc định khỏi bảng định tuyến.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ proxy đáp ứng được cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Instance ở subnet công khai vẫn lấy được bản vá | proxy cho phép URL của nhà cung cấp | | Gói cài đặt truy cập qua URL | proxy lọc theo tên miền | | CHẶN TƯỜNG MINH mọi kết nối ra khác | http_access deny all + gỡ tuyến mặc định |

⚠ Hai vế của giải pháp phải đi cùng nhau:

Chỉ có proxy
    → ứng dụng bỏ qua biến proxy
      và đi thẳng qua Internet gateway
        ↓
    Chỉ gỡ tuyến mặc định
    → không ra được Internet chút nào,
      kể cả URL hợp lệ
        ↓
    Cả hai: proxy là lối ra DUY NHẤT
      và nó lọc theo URL

⚠ Và security group không làm được điều đề yêu cầu: | Cơ chế | Lọc theo | |---|---| | Security group | IP, cổng — KHÔNG có deny | | NACL | IP, cổng — có deny | | Proxy | TÊN MIỀN, đường dẫn |

Đề nói gói cài đặt truy cập
  "thông qua URL"
        ↓
    URL trỏ tới CDN, IP đổi liên tục
    → danh sách IP không bao giờ đúng lâu
    → phải lọc ở tầng tên miền

Đây là lý do phương án B và D sai.

Cấu hình Squid:

acl mien_cho_phep dstdomain .nhacungcap.com
acl mien_cho_phep dstdomain .cdn-goi-cai-dat.net
acl SSL_ports port 443
acl Safe_ports port 80 443

http_access deny !Safe_ports
http_access allow mien_cho_phep
http_access deny all
http_port 3128

Gỡ tuyến mặc định của subnet ứng dụng:

aws ec2 delete-route --route-table-id rtb-ung-dung \
  --destination-cidr-block 0.0.0.0/0

⚠ Nhưng đề nói instance nằm ở subnet CÔNG KHAI:

Subnet công khai theo định nghĩa
  có tuyến 0.0.0.0/0 → Internet gateway
        ↓
    Gỡ tuyến đó: instance vẫn nhận
      lưu lượng VÀO qua Elastic IP
      hoặc ALB
    → nhưng không tự đi RA được
        ↓
    Đây chính là điều đề muốn

Ép dùng proxy:

cat >> /etc/environment <<'EOF'
http_proxy=http://proxy.noi-bo:3128
https_proxy=http://proxy.noi-bo:3128
no_proxy=169.254.169.254,localhost,.amazonaws.com
EOF

⚠ no_proxy phải có 169.254.169.254:

Instance metadata đi qua proxy
    → SDK không lấy được credential
      của vai trò IAM
        ↓
    Ứng dụng mất quyền gọi mọi
      dịch vụ AWS, không rõ lý do

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lọc được theo tên miền chứ không phải IP | | | Ghi log mọi kết nối ra | | | Đổi danh sách không phải sửa hạ tầng | |

⚠ Và log của proxy là giá trị lớn không kém việc chặn:

Mỗi kết nối ra đều có bản ghi:
  ai gọi, đi đâu, lúc nào, bao nhiêu byte
        ↓
    Phát hiện được rò rỉ dữ liệu
    → và biết ứng dụng nào đang gọi
      dịch vụ ngoài mà không ai khai

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

  • **A. Chuyển toàn bộ instance sang subnet riêng tư, gỡ tuyến mặc định và thay bằng tuyến trỏ tới vị trí gói cài đặt — đây là phương án gần nhất và phần gỡ tuyến mặc định đúng hướng, nhưng "tuyến trỏ tới vị trí gói" nghĩa là định tuyến theo IP, mà URL của nhà cung cấp trỏ tới CDN với IP đổi liên tục; và chuyển instance sang subnet riêng làm hỏng khả năng nhận lưu lượng vào.
  • **B. Dùng network ACL cho phép tới đích cụ thể và deny phần còn lại — NACL làm việc ở tầng 3/4, nó không hiểu URL.
  • **D. Tạo security group với quy tắc đi ra phù hợp — security group chỉ lọc theo IP và cổng, và không có quy tắc deny; không diễn tả được "chặn tường minh mọi thứ khác".

Ghi nhớ

⚠ Bốn cách kiểm soát lưu lượng ra — bảng phải thuộc: | Cách | Lọc theo | Ai vận hành | |---|---|---| | Security group | IP, cổng | AWS | | NACL | IP, cổng, có deny | AWS | | Proxy chuyển tiếp | tên miền, đường dẫn | bạn | | AWS Network Firewall | tên miền, luật Suricata | AWS |

⚠ Network Firewall là câu trả lời hiện đại cho bài toán này:

Cùng khả năng lọc theo tên miền
    → nhưng là dịch vụ quản lý
    → không phải tự vá và tự lo HA
        ↓
    Đề viết theo mẫu proxy vốn có
      trước khi dịch vụ này ra đời

Luật danh sách cho phép của Network Firewall:

{"RulesSourceList": {
  "Targets": [".nhacungcap.com", ".cdn-goi-cai-dat.net"],
  "TargetTypes": ["TLS_SNI", "HTTP_HOST"],
  "GeneratedRulesType": "ALLOWLIST"}}

Từ khoá nhận diện:

"explicitly deny all other outbound" → proxy hoặc Network Firewall "restrict by URL" → không phải security group "deny a specific IP" → NACL "inspect with third-party appliance" → GWLB

Ba lưu ý về proxy tự dựng: | Lưu ý | Chi tiết | |---|---| | Đặt sau ALB nội bộ, trong ASG | | | Trải nhiều AZ | | | Một proxy là một điểm hỏng chí tử | |

⚠ Proxy chết là mọi thứ dừng:

Không cập nhật được, không gọi
  API bên ngoài, không tải gói
        ↓
    Luôn dựng ít nhất hai
    → và theo dõi sức khoẻ chủ động

Ba lưu ý về HTTPS: | Lưu ý | Chi tiết | |---|---| | Proxy đọc được SNI mà không giải mã | | | Chặn theo tên miền là đủ cho hầu hết yêu cầu | | | Lọc theo đường dẫn cần giải mã (MITM) | |

⚠ Giải mã TLS ở proxy là quyết định lớn:

Phải cài CA riêng lên mọi client
    → tăng độ phức tạp và rủi ro
        ↓
    Và proxy thấy toàn bộ nội dung
      lưu lượng
    → chỉ làm khi thật sự bắt buộc

Ba lưu ý về VPC endpoint: | Lưu ý | Chi tiết | |---|---| | Lưu lượng tới dịch vụ AWS không cần qua proxy | | | Gateway endpoint cho S3 và DynamoDB miễn phí | | | Giảm tải cho proxy rất nhiều | |

⚠ Và endpoint policy là lớp kiểm soát thêm:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bucket-cua-cong-ty/*"}]}

Chỉ cho phép truy cập bucket của
  chính công ty
    → chặn việc đẩy dữ liệu sang
      bucket S3 của người khác

Ba lưu ý về ghi log: | Lưu ý | Chi tiết | |---|---| | Log proxy đẩy lên CloudWatch Logs | | | VPC Flow Logs bổ sung ở tầng mạng | | | Cảnh báo khi có nhiều yêu cầu bị chặn | |

Ba lưu ý về bảo trì danh sách: | Lưu ý | Chi tiết | |---|---| | Đưa danh sách vào Parameter Store | | | Tự nạp lại khi có thay đổi | | | Rà soát định kỳ, gỡ mục không còn dùng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl tới URL được phép — phải thông | | | curl tới URL khác — phải bị chặn | | | Bỏ biến proxy rồi thử — cũng phải bị chặn | |

Và một lời khuyên: hãy kiểm chứng bằng cách bỏ biến môi trường proxy rồi thử ra Internet. Nếu vẫn thông thì bạn chưa có kiểm soát nào — bạn chỉ có một quy ước mà mọi tiến trình đều được tự do phớt lờ.

Câu 144 Domain - Continuous Improvement for Existing Solutions

A company runs a popular blogging platform that is hosted on AWS. Bloggers from all around the world upload millions of entries per month, and the average blog entry size is 300 KB. The access rate to blog entries drops to a negligible level six months after publishing and after a year, bloggers rarely access a blog. The blog entries have a high update rate during the first 3 months after the blogger has published it and this drops to no updates after 6 months. The company wants to use CloudFront to improve the load times of the blogging platform.

Which of the following is an ideal cloud implementation for this scenario?

  1. A Store two copies of each entry in two different S3 buckets, and let each bucket have its own CloudFront distribution where S3 access is permitted to that CloudFront identity only.
  2. B You can use one S3 source bucket that is partitioned according to the month a blog entry was submitted, and store the entry in that partition. Create a CloudFront distribution with access permissions to S3 and is restricted only to it.
  3. C Create a CloudFront distribution and set the Restrict Viewer Access Forward Query string to true with a minimum TTL of 0.
  4. D Create two different CloudFront distributions: one with US-Europe price class for your US/Europe users and another one with all edge locations included for your remaining users.
Xem giải thích

Đáp án

**B — Dùng một bucket S3 phân vùng theo tháng đăng bài, lưu mỗi bài vào phân vùng tương ứng; tạo phân phối CloudFront có quyền truy cập S3 và giới hạn chỉ mình nó đọc được.

Vì sao đúng

Đề cho ba dữ kiện về vòng đời bài viết, và phương án này khai thác đúng chúng: | Dữ kiện | Ý nghĩa | |---|---| | Cập nhật nhiều trong 3 tháng đầu, sau 6 tháng không đổi | TTL khác nhau theo tuổi bài | | Gần như không ai đọc sau 1 năm | chuyển lớp lưu trữ theo tuổi | | Hàng triệu bài, trung bình 300 KB | cần cách nhóm theo thời gian |

⚠ Phân vùng theo tháng cho phép áp chính sách theo tuổi:

bai-viet/2026/08/bai-abc.html
        ↓
    Lifecycle rule theo tiền tố
    → bài cũ tự chuyển sang lớp rẻ
        ↓
    Cache behavior theo mẫu đường dẫn
    → bài cũ có TTL rất dài

Vòng đời theo tuổi:

{"Rules": [{
  "ID": "bai-viet-theo-tuoi",
  "Status": "Enabled",
  "Filter": {"Prefix": "bai-viet/"},
  "Transitions": [
    {"Days": 180, "StorageClass": "STANDARD_IA"},
    {"Days": 365, "StorageClass": "GLACIER_IR"}]}]}

⚠ Chọn Glacier Instant Retrieval chứ không phải Flexible:

Bài cũ "hiếm khi" được đọc
    → nhưng khi có người đọc thì
      phải hiện ra ngay
        ↓
    Flexible mất 3-5 giờ
    → trang blog không chờ được
    → Instant Retrieval: mili giây

Cache behavior theo tuổi bài:

{"CacheBehaviors": {"Items": [
  {"PathPattern": "bai-viet/2026/08/*",
   "DefaultTTL": 300, "MaxTTL": 3600},
  {"PathPattern": "bai-viet/*",
   "DefaultTTL": 2592000, "MaxTTL": 31536000}]}}

⚠ Thứ tự cache behavior quan trọng — cụ thể hơn phải đứng trước:

CloudFront khớp theo THỨ TỰ khai
    → mẫu chung `bai-viet/*` đứng trước
    → sẽ nuốt hết, mẫu tháng hiện tại
      không bao giờ khớp
        ↓
    Luôn đặt mẫu cụ thể lên trên

⚠ Và "300 KB mỗi bài, hàng triệu bài" là lý do dùng MỘT bucket:

Hạn ngạch mặc định: 100 bucket
  mỗi tài khoản (tăng lên 1.000)
        ↓
    Không có lý do kỹ thuật nào để
      chia nhiều bucket
    → tiền tố trong một bucket là
      cách phân vùng đúng

Đây là lý do phương án A sai — nó nhân đôi lưu trữ mà không được gì.

Origin Access Control:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::blog-bai-viet/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABC"}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bài mới cập nhật nhanh, bài cũ cache lâu | | | Chi phí lưu trữ giảm theo tuổi bài | | | Một bucket, một phân phối — đơn giản | |

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

⚠ Lý do lịch sử của việc "phân vùng" S3 đã không còn đúng.

Trước tháng 7/2018, S3 chia hiệu năng theo tiền tố và AWS khuyến nghị đặt chuỗi ngẫu nhiên ở đầu khoá để trải đều tải:

Cách cũ: 3f2a-bai-viet.html
    → tránh điểm nóng
        ↓
    Nay: S3 tự động mở rộng
      3.500 PUT và 5.500 GET
      mỗi giây MỖI TIỀN TỐ
    → không cần ngẫu nhiên hoá nữa

Nên phân vùng theo tháng vẫn đúng, nhưng vì lý do khác: | Lý do | Còn đúng không | |---|---| | Hiệu năng, tránh điểm nóng | KHÔNG còn cần | | Áp lifecycle rule theo tuổi | CÓ | | Áp cache behavior theo tuổi | CÓ | | Dễ liệt kê và quản lý | CÓ |

Đề viết theo tư duy cũ
    → nhưng đáp án vẫn đúng
    → chỉ khác lý do

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

  • **A. Lưu hai bản ở hai bucket khác nhau, mỗi bucket một phân phối CloudFront — đây là phương án gần nhất và có OAI/OAC đúng, nhưng nhân đôi chi phí lưu trữ mà không mang lại lợi ích nào; và phải tự giữ hai bản đồng bộ.
  • **D. Tạo hai phân phối với price class khác nhau cho Mỹ/châu Âu và phần còn lại — price class là công cụ tiết kiệm chi phí bằng cách bỏ bớt điểm biên; nó không cải thiện thời gian tải và không liên quan tới mẫu truy cập theo tuổi bài.
  • **C. Bật Restrict Viewer Access và Forward Query String = true với TTL tối thiểu 0 — cả ba cấu hình đều đi ngược mục tiêu: hạn chế người xem không phải yêu cầu, chuyển tiếp query string làm phình cache key, và TTL 0 nghĩa là gần như không cache gì.

Ghi nhớ

⚠ Ba yếu tố quyết định tỷ lệ trúng cache — bảng phải thuộc: | Yếu tố | Ảnh hưởng | |---|---| | TTL | lớn nhất | | Cache key | rất lớn — cookie và query string phá hỏng cache | | Nén | bản nén cũng được cache |

⚠ Vì sao Forward Query String = true là lựa chọn tệ:

`?utm_source=facebook`, `?ref=twitter`
    → cùng một bài viết
        ↓
    Mỗi biến thể là một mục cache riêng
    → cùng nội dung lưu hàng chục lần
    → và mỗi lần đầu đều gọi origin

Từ khoá nhận diện:

"content updated then rarely changes" → TTL theo tuổi "rarely accessed after a year" → lifecycle sang lớp rẻ "only accessible through CloudFront" → OAC "reduce CDN cost by geography" → price class

Ba lưu ý về lớp lưu trữ: | Lớp | Thời gian lưu tối thiểu | Lấy dữ liệu | |---|---|---| | Standard | không | ngay | | Standard-IA | 30 ngày | ngay, có phí truy xuất | | Glacier Instant Retrieval | 90 ngày | mili giây | | Glacier Deep Archive | 180 ngày | 12-48 giờ |

⚠ Object nhỏ không nên chuyển lớp:

Object dưới 128 KB
    → chuyển sang IA không tiết kiệm
    → vì bị tính như 128 KB
        ↓
    Bài viết 300 KB thì được
    → nhưng ảnh thumbnail thì không

Ba lưu ý về Intelligent-Tiering: | Lưu ý | Chi tiết | |---|---| | Tự chuyển lớp theo mẫu truy cập thật | | | Không có phí truy xuất | | | Có phí giám sát nhỏ mỗi object | |

⚠ Với hàng triệu object nhỏ, phí giám sát đáng kể:

Phí theo SỐ object, không theo dung lượng
    → hàng triệu bài viết
        ↓
    Tính thử trước khi chọn
    → lifecycle rule cố định có khi rẻ hơn

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | Cache behavior khớp theo thứ tự khai | | | Xoá cache tốn phí sau 1.000 đường dẫn/tháng | | | Đổi tên tệp tốt hơn xoá cache | |

Ba lưu ý về bài viết được cập nhật: | Lưu ý | Chi tiết | |---|---| | TTL ngắn cho bài mới | | | Hoặc xoá cache khi tác giả sửa | | | Hoặc đưa mã phiên bản vào URL | |

⚠ Xoá cache có chủ đích khi tác giả bấm lưu:

aws cloudfront create-invalidation \
  --distribution-id <id> \
  --paths "/bai-viet/2026/08/bai-abc.html"

Cho phép đặt TTL dài cho MỌI bài
    → và chỉ xoá cache khi thật sự sửa
        ↓
    Tốt hơn là để TTL ngắn cho
      cả một tháng bài viết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem header X-Cache có trúng cache không | | | Theo dõi CacheHitRate | | | Kiểm bài cũ đã chuyển lớp lưu trữ | |

Và một lời khuyên: hãy đặt TTL dài và xoá cache có chủ đích khi nội dung thay đổi, thay vì để TTL ngắn cho mọi thứ. TTL ngắn là cách trả tiền cho origin mỗi vài phút để phòng một thay đổi hiếm khi xảy ra — trong khi một lệnh xoá cache lúc tác giả bấm lưu giải quyết đúng vấn đề đó.

Câu 145 Domain - Design for New Solutions

An e-commerce company is running a three-tier application on AWS. The application includes a web tier as frontend, an application tier as backend, and the database tier that stores the transactions and users' data. The database is currently hosted on an extra-large instance with 128 GB of memory. For the company’s business continuity and disaster recovery plan, the Solutions Architect must ensure a Recovery Time Objective (RTO) of 5 minutes and a Recovery Point Objective (RPO) of 1 hour on the backup site in the event that the application goes down. There is also a requirement for the backup site to be at least 250 miles away from the primary site.

Which of the following solutions must the Solutions Architect implement to meet the company’s disaster recovery requirements while keeping the cost at a minimum?

  1. A

    Use a pilot light strategy for the backup region. Configure the primary database to replicate data to a large standby instance in the backup region. In case of a disaster, vertically resize the database instance to meet the full demand. Create an AWS CloudFormation template to quickly provision the same web servers, application servers, and load balancers on the backup region. Update the Amazon Route 53 records to point to the backup region.
  2. B

    Create a frequently scheduled backup of the application and database that will be stored on an Amazon S3 bucket. Configure Amazon S3 Cross-Region Replication (CRR) on the bucket to copy the backups to another region. In case of disaster, use an AWS CloudFormation template to quickly replicate the same resources to the backup region and restore the data from the S3 bucket.
  3. C

    Use a multi-region strategy for the backup region to comply with the tight RTO and RPO requirements. Create a fully functional web, application, and database tier on the backup region with the same capacity as the primary region. Set the database on the backup region on standby mode. In case of disaster, update the Amazon Route 53 record to point to the backup region.
  4. D

    On the backup region, create a scaled-down version of the fully functional environment with one EC2 instance of the web server and application server in their own Auto Scaling groups behind Application Load Balancers. Create a standby database instance that replicates data from the primary database. In case of disaster, scale the instances to meet the demand and update the Amazon Route 53 record to point to the backup region.
Xem giải thích

Đáp án

**D — Ở Region dự phòng, dựng phiên bản thu nhỏ của môi trường đầy đủ: mỗi tầng web và ứng dụng có một EC2 trong Auto Scaling group riêng sau Application Load Balancer, cùng một instance CSDL dự phòng nhân bản từ CSDL chính. Khi có sự cố thì mở rộng số máy và cập nhật bản ghi Route 53.

Vì sao đúng

Đề cho ba con số, và chỉ một chiến lược khớp cả ba: | Yêu cầu | Con số | Suy ra | |---|---|---| | RTO | 5 phút | hạ tầng phải CHẠY SẴN | | RPO | 1 giờ | nhân bản CSDL là đủ | | Khoảng cách | tối thiểu 400 km | Region khác | | Chi phí tối thiểu | | không chạy công suất đầy |

⚠ RTO 5 phút loại bỏ mọi phương án phải dựng hạ tầng lúc sự cố:

CloudFormation dựng lại từ đầu
    → vài phút cho stack
    + vài phút khởi động instance
    + thời gian khôi phục CSDL
        ↓
    Không có cách nào xong trong 5 phút

Đây là lý do phương án A và B sai.

⚠ Đây là chiến lược Warm Standby — bảng bốn chiến lược phải thuộc: | Chiến lược | Hạ tầng dự phòng | RTO | |---|---|---| | Backup & Restore | không có gì | giờ | | Pilot Light | chỉ CSDL chạy | chục phút | | Warm Standby | MỌI TẦNG chạy quy mô nhỏ | phút | | Multi-Site | công suất đầy đủ | gần 0 |

Warm Standby: mọi thành phần đã chạy
    → chỉ cần MỞ RỘNG, không cần DỰNG
        ↓
    Đây là điểm khác biệt cốt lõi
      với Pilot Light

Nhân bản CSDL xuyên Region:

aws rds create-db-instance-read-replica \
  --db-instance-identifier replica-dr \
  --source-db-instance-identifier arn:aws:rds:us-east-1:111122223333:db:csdl-chinh \
  --db-instance-class db.r6g.large \
  --region us-west-2

⚠ Chú ý instance dự phòng nhỏ hơn instance chính:

Chính: 128 GB RAM
    → dự phòng: cỡ nhỏ hơn nhiều
        ↓
    Khi sự cố: thay đổi cỡ (vertical resize)
    → mất vài phút nhưng vẫn trong RTO
        ↓
    Đây là chỗ tiết kiệm chi phí lớn nhất

Chuyển đổi bằng Route 53:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{"Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"app.congty.com","Type":"A",
      "SetIdentifier":"chinh","Failover":"PRIMARY",
      "HealthCheckId":"<hc>",
      "AliasTarget":{"HostedZoneId":"<zone-alb-chinh>",
        "DNSName":"<dns-alb-chinh>","EvaluateTargetHealth":true}}}]}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đáp ứng RTO 5 phút vì hạ tầng đã sẵn | | | Rẻ hơn nhiều so với chạy công suất đầy | | | Kiểm thử được thường xuyên vì môi trường luôn tồn tại | |

⚠ Lợi ích thứ ba đáng nói riêng:

Backup & Restore: diễn tập tốn công
  và ít khi làm
        ↓
    Warm Standby: môi trường luôn ở đó
    → chuyển một phần lưu lượng thật
      sang để kiểm chứng định kỳ

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

  • **A. Dùng chiến lược Pilot Light, chỉ nhân bản CSDL sang một instance dự phòng lớn, khi sự cố thì đổi cỡ và dùng CloudFormation dựng lại web và ứng dụng — đây là phương án gần nhất và nhân bản CSDL hoàn toàn đúng, nhưng dựng tầng web và ứng dụng từ CloudFormation lúc sự cố không thể xong trong 5 phút.
  • **C. Dùng chiến lược multi-region với công suất ĐẦY ĐỦ ở Region dự phòng — đáp ứng được RTO nhưng đắt gấp đôi; đề nhấn mạnh "chi phí tối thiểu".
  • **B. Sao lưu định kỳ vào S3 có Cross-Region Replication, khi sự cố thì dựng lại bằng CloudFormation và khôi phục dữ liệu — đây là Backup & Restore, RTO tính bằng giờ.

Ghi nhớ

⚠ Cách chọn chiến lược từ RTO — bảng phải thuộc:

RTO giờ - ngày   → Backup & Restore
RTO chục phút    → Pilot Light
RTO phút         → Warm Standby
RTO gần 0        → Multi-Site

Từ khoá nhận diện:

"RTO minutes, minimise cost" → Warm Standby "scaled-down but functional" → Warm Standby "only the database replicated" → Pilot Light "same capacity in both Regions" → Multi-Site

⚠ Yêu cầu khoảng cách tối thiểu là dấu hiệu bắt buộc dùng Region khác:

Multi-AZ: các AZ cách nhau vài chục km
    → không đạt yêu cầu 400 km
        ↓
    Chỉ Region khác mới đủ xa
    → và đây là yêu cầu tuân thủ
      phổ biến trong ngành tài chính

Ba lưu ý về nhân bản CSDL xuyên Region: | Dịch vụ | Cách | |---|---| | RDS | cross-region read replica | | Aurora | Global Database, độ trễ dưới 1 giây | | DynamoDB | global table, ghi được ở mọi Region |

⚠ Aurora Global Database cho RPO tốt hơn nhiều:

Read replica thường: độ trễ vài giây
  tới vài phút
        ↓
    Aurora Global: nhân bản ở tầng lưu trữ
    → độ trễ dưới 1 giây
    → RTO chuyển đổi dưới 1 phút

Ba lưu ý về Warm Standby: | Lưu ý | Chi tiết | |---|---| | ASG đặt min nhỏ nhưng max đủ lớn | | | Kiểm hạn ngạch ở Region dự phòng | | | AMI và container image phải có sẵn ở đó | |

⚠ Hạn ngạch là bẫy hay gặp nhất khi diễn tập DR:

Region chính chạy 50 instance
    → Region phụ chưa bao giờ quá 2
        ↓
    Hạn ngạch vCPU vẫn ở mức mặc định
    → lúc cần thì không mở rộng nổi
    → xin tăng hạn ngạch TRƯỚC

Ba lưu ý về chuyển đổi: | Lưu ý | Chi tiết | |---|---| | Route 53 failover phụ thuộc TTL | | | Global Accelerator chuyển nhanh hơn | | | Thăng cấp read replica là thao tác một chiều | |

⚠ Thăng cấp replica không quay lại được:

aws rds promote-read-replica \
  --db-instance-identifier replica-dr

Replica thành instance độc lập
    → mất liên kết với instance gốc
        ↓
    Muốn quay về Region chính
    → phải dựng lại chiều nhân bản ngược
    → lên kế hoạch cho cả chiều về

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Instance dự phòng cỡ nhỏ, đổi cỡ khi cần | | | Chỉ chạy một máy mỗi tầng khi bình thường | | | Reserved Instance cho phần chạy thường trực | |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Diễn tập ít nhất mỗi quý | | | Đo RTO và RPO thật, ghi lại | | | Dùng Fault Injection Service mô phỏng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuyển thật sang Region dự phòng và bấm giờ | | | Đo độ trễ nhân bản CSDL | | | Thử mở rộng ASG lên công suất đầy | |

Và một lời khuyên: hãy đo thời gian đổi cỡ instance CSDL trước khi tin rằng RTO 5 phút là khả thi. Đó thường là bước dài nhất trong toàn bộ quy trình chuyển đổi, và nó là con số duy nhất bạn không đoán được nếu chưa từng thực hiện.

Câu 146 Domain - Continuous Improvement for Existing Solutions

A company hosts its main web application on the AWS cloud which is composed of web servers and database servers. To ensure high availability, the web servers are deployed on an Auto Scaling group of Amazon EC2 instances across multiple Availability Zones with an Application Load Balancer in front. For the database, it is deployed on a Multi-Availability Zone configuration in Amazon RDS. During the RDS maintenance window, the operating system of the primary DB instance undergoes software patching that triggers the failover process.

What would happen to the database during failover?

  1. A The IP address of the primary DB instance is switched to the standby DB instance.
  2. B The canonical name record (CNAME) is changed from the primary database to standby database.
  3. C The RDS DB instance will automatically reboot.
  4. D A new DB instance will be created and immediately replace the primary database.
Xem giải thích

Đáp án

**B — Bản ghi CNAME được đổi từ CSDL chính sang CSDL dự phòng.

Vì sao đúng

Cơ chế chuyển đổi của RDS Multi-AZ hoạt động hoàn toàn ở tầng DNS:

Endpoint: csdl.abc123.ap-southeast-1.rds.amazonaws.com
    → là một bản ghi CNAME
        ↓
    Bình thường trỏ tới instance chính
        ↓
    Chuyển đổi: RDS đổi CNAME
      sang instance dự phòng
    → ứng dụng vẫn dùng CÙNG một tên

⚠ Điểm mấu chốt: instance dự phòng LUÔN TỒN TẠI, không phải tạo mới:

Multi-AZ dựng sẵn hai instance
    → chính ở AZ-a, dự phòng ở AZ-b
    → nhân bản ĐỒNG BỘ giữa hai bên
        ↓
    Chuyển đổi chỉ là đổi CNAME
    → không tạo instance nào
    → đây là lý do phương án D sai

⚠ Và IP KHÔNG được chuyển sang máy khác:

Hai instance có IP riêng biệt
    → không có việc "chuyển IP"
        ↓
    Đây là lý do phương án A sai
    → và cũng là lý do phải dùng
      endpoint DNS, không dùng IP

Kiểm tra endpoint:

dig +short csdl.abc123.ap-southeast-1.rds.amazonaws.com

⚠ Hệ quả quan trọng nhất: ứng dụng phải làm mới cache DNS:

JVM mặc định cache DNS VĨNH VIỄN
  khi có SecurityManager
        ↓
    Chuyển đổi xong, CNAME đã đổi
    → ứng dụng vẫn kết nối vào
      IP cũ đã chết
    → treo cho tới khi khởi động lại

Cấu hình cho Java:

java.security.Security.setProperty(
    "networkaddress.cache.ttl", "60");
java.security.Security.setProperty(
    "networkaddress.cache.negative.ttl", "0");

Buộc chuyển đổi để kiểm thử:

aws rds reboot-db-instance \
  --db-instance-identifier csdl-chinh --force-failover

⚠ Thời gian chuyển đổi và những gì xảy ra:

Thường 60-120 giây
    → trong lúc đó kết nối bị ngắt
        ↓
    Ứng dụng phải có logic thử lại
    → không có: người dùng thấy lỗi

Bốn nguyên nhân gây chuyển đổi: | Nguyên nhân | Ghi chú | |---|---| | Mất AZ chứa instance chính | | | Hỏng instance chính | | | Vá lỗi hệ điều hành | đúng tình huống trong đề | | Đổi cỡ instance | |

⚠ Vá lỗi trên Multi-AZ diễn ra theo trình tự khéo léo:

1. Vá instance DỰ PHÒNG trước
2. Chuyển đổi sang bản vừa vá
3. Vá instance cũ (nay là dự phòng)
        ↓
    Gián đoạn chỉ bằng MỘT lần
      chuyển đổi
    → thay vì thời gian vá cả hai

Ba lợi ích của Multi-AZ: | Lợi ích | Chi tiết | |---|---| | Tự động, không cần ai can thiệp | | | Nhân bản đồng bộ nên RPO bằng 0 | | | Vá lỗi ít gián đoạn | |

⚠ RDS Proxy giảm mạnh tác động của chuyển đổi:

Proxy giữ pool kết nối
    → chuyển đổi xảy ra phía sau proxy
        ↓
    Ứng dụng gần như không thấy gián đoạn
    → AWS công bố giảm thời gian
      chuyển đổi thấy được tới hơn 60%

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

  • **C. Instance RDS sẽ tự khởi động lại — đây là phương án gần nhất và có xảy ra việc khởi động lại instance chính, nhưng đó không phải điều xảy ra với CSDL khi chuyển đổi: dịch vụ tiếp tục trên instance dự phòng, chứ không phải chờ instance cũ khởi động lại.
  • **A. IP của instance chính được chuyển sang instance dự phòng — hai instance có IP riêng; RDS không di chuyển IP.
  • **D. Một instance mới được tạo và thay thế ngay instance chính — instance dự phòng đã tồn tại sẵn, không có việc tạo mới.

Ghi nhớ

⚠ Multi-AZ và Read Replica — bảng phải thuộc: | Tiêu chí | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | CO GIÃN ĐỌC | | Nhân bản | đồng bộ | bất đồng bộ | | Đọc từ bản kia | KHÔNG | có | | Chuyển đổi | tự động | thủ công (thăng cấp) | | Cùng Region | bắt buộc | có thể khác Region |

Từ khoá nhận diện:

"what happens during failover" → CNAME đổi "survive AZ failure, no data loss" → Multi-AZ "offload read queries" → read replica "survive Region failure" → cross-region replica hoặc Aurora Global

Ba lưu ý về Multi-AZ DB cluster: | Tiêu chí | Multi-AZ instance | Multi-AZ DB cluster | |---|---|---| | Số bản | 1 chính + 1 dự phòng | 1 writer + 2 reader | | Đọc từ bản phụ | không | CÓ | | Chuyển đổi | 60-120 giây | dưới 35 giây | | Engine | hầu hết | MySQL, PostgreSQL |

Ba lưu ý về kết nối ứng dụng: | Lưu ý | Chi tiết | |---|---| | Luôn dùng endpoint DNS | | | Đặt TTL cache DNS ngắn | | | Có logic thử lại khi mất kết nối | |

Ba lưu ý về những gì Multi-AZ KHÔNG bảo vệ: | Không bảo vệ khỏi | Cần gì | |---|---| | Xoá nhầm dữ liệu | PITR | | Mất cả Region | cross-region replica | | Lỗi logic của ứng dụng | sao lưu |

⚠ Điểm đầu là hiểu nhầm phổ biến nhất:

`DROP TABLE` trên instance chính
    → nhân bản ĐỒNG BỘ ngay sang
      bản dự phòng
        ↓
    Cả hai đều mất bảng
    → Multi-AZ không phải sao lưu

Ba lưu ý về sự kiện RDS: | Lưu ý | Chi tiết | |---|---| | Đăng ký sự kiện qua SNS | | | Sự kiện Multi-AZ failover ghi rõ thời điểm | | | Dùng để đo thời gian chuyển đổi thật | |

aws rds create-event-subscription \
  --subscription-name canh-bao-csdl \
  --sns-topic-arn <arn> \
  --source-type db-instance \
  --event-categories availability failover

Ba lưu ý về cửa sổ bảo trì: | Lưu ý | Chi tiết | |---|---| | Đặt vào giờ ít người dùng | | | Bật auto-minor-version-upgrade | | | Nâng phiên bản chính phải kiểm thử trước | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buộc chuyển đổi và bấm giờ | | | Xem ứng dụng có tự kết nối lại | | | dig endpoint trước và sau để thấy CNAME đổi | |

Và một lời khuyên: hãy buộc chuyển đổi một lần ở môi trường thật và quan sát ứng dụng. Phần AWS lo luôn hoạt động — thứ hỏng gần như luôn là ứng dụng của bạn, vốn đang giữ chặt một địa chỉ IP không còn tồn tại.

Câu 147 Domain - Continuous Improvement for Existing Solutions

A company runs a popular photo-sharing site hosted on the AWS cloud. There are user complaints about the frequent downtime of the site considering the hefty price for using their service. The company is using a MySQL RDS instance to record user details and other data analytics. A standard S3 storage class bucket is used to store the photos and user metadata, which are frequently accessed only in the first month. The website is also capable of immediately retrieving the images no matter how long they were stored. The RDS instance is always affected and sometimes goes down when there is a problem in the Availability Zone. The solutions architect was tasked to analyze the current architecture and to solve the user complaints about the website. In addition, the solutions architect should also implement a system that automatically discovers, classifies, and protects personally identifiable information (PII) data in the Amazon S3 bucket.

Which of the following options offers the BEST solution for this scenario?

  1. A

    Use Amazon Inspector to automatically discover, classify, and protect personally identifiable information (PII) data in the Amazon S3 bucket. Use a lifecycle policy in S3 to move the old photos to Amazon S3 Glacier Deep Archive after a month. Re-configure the existing database to use RDS Multi-AZ Deployments.
  2. B

    Use Amazon Inspector to automatically discover, classify, and protect personally identifiable information (PII) data in the Amazon S3 bucket. Replace the S3 Standard bucket with an Infrequent Access storage class. Re-configure the existing database to use RDS Read Replicas.
  3. C

    Use Amazon Macie to automatically discover, classify, and protect personally identifiable information (PII) data in the Amazon S3 bucket. Replace the S3 bucket with EBS Volumes and use Redshift instead of RDS.
  4. D

    Use Amazon Macie to automatically discover, classify, and protect personally identifiable information (PII) data in the Amazon S3 bucket. Use a lifecycle policy in S3 to move the old photos to Infrequent Access storage class after a month. Re-configure the existing database to use RDS Multi-AZ Deployments.
Xem giải thích

Đáp án

**D — Dùng Amazon Macie để tự động phát hiện, phân loại và bảo vệ dữ liệu cá nhân trong bucket S3; dùng lifecycle policy chuyển ảnh cũ sang lớp Infrequent Access sau một tháng; và cấu hình lại CSDL sang RDS Multi-AZ.

Vì sao đúng

Đề nêu ba vấn đề, và phương án này giải từng cái: | Vấn đề | Cách giải | |---|---| | RDS chết khi có sự cố ở AZ | Multi-AZ, tự chuyển đổi | | Ảnh chỉ hay xem trong tháng đầu | lifecycle sang IA | | Cần phát hiện dữ liệu cá nhân trong S3 | Macie |

⚠ Macie là dịch vụ DUY NHẤT quét NỘI DUNG object tìm dữ liệu nhạy cảm:

Inspector: quét lỗ hổng phần mềm của
  EC2, ECR, Lambda
    → không mở object S3 ra đọc
        ↓
    Macie: đọc bên trong object
    → tìm số thẻ, hộ chiếu, thông tin
      cá nhân

Đây là lý do phương án A và B sai.

⚠ Và một dữ kiện trong đề quyết định lớp lưu trữ:

"có thể lấy ảnh NGAY LẬP TỨC
  dù lưu bao lâu"
        ↓
    Glacier Deep Archive: 12-48 giờ
    → vi phạm thẳng yêu cầu này
        ↓
    Standard-IA: lấy ngay, rẻ hơn Standard

Đây là lý do phương án A sai dù nó có Multi-AZ đúng.

Vòng đời chuyển sang IA:

{"Rules": [{
  "ID": "anh-cu-sang-ia",
  "Status": "Enabled",
  "Filter": {"Prefix": "anh/"},
  "Transitions": [
    {"Days": 30, "StorageClass": "STANDARD_IA"}]}]}

⚠ Nhưng IA có hai chi phí ẩn phải biết:

1. Thời gian lưu TỐI THIỂU 30 ngày
   → xoá sớm vẫn tính đủ 30 ngày
        ↓
2. Phí TRUY XUẤT mỗi GB
   → ảnh bỗng viral, ai cũng xem
   → phí truy xuất có thể vượt
     phần tiết kiệm

⚠ Với mẫu truy cập khó đoán, Intelligent-Tiering an toàn hơn:

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket kho-anh --id auto-tier \
  --intelligent-tiering-configuration '{
    "Id":"auto-tier","Status":"Enabled",
    "Tierings":[{"Days":90,"AccessTier":"ARCHIVE_ACCESS"}]}'

Tự chuyển lớp theo mẫu truy cập THẬT
    → KHÔNG có phí truy xuất
        ↓
    Chỉ có phí giám sát nhỏ mỗi object
    → cân nhắc nếu có hàng chục triệu ảnh

Bật Multi-AZ:

aws rds modify-db-instance \
  --db-instance-identifier csdl-anh \
  --multi-az --apply-immediately

Bật Macie:

aws macie2 enable-macie
aws macie2 create-classification-job \
  --job-type SCHEDULED \
  --schedule-frequency '{"dailySchedule":{}}' \
  --name quet-du-lieu-ca-nhan \
  --s3-job-definition '{"bucketDefinitions":[
    {"accountId":"111122223333","buckets":["kho-anh"]}]}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Website không chết khi mất một AZ | | | Chi phí lưu trữ giảm sau tháng đầu | | | Vẫn lấy ảnh ngay lập tức ở mọi lớp | |

⚠ Và Multi-AZ giải quyết đúng lời phàn nàn của người dùng:

Đề nói "website hay chết, mà giá dịch vụ
  thì đắt"
        ↓
    Nguyên nhân: RDS một AZ
    → sự cố AZ là mất dịch vụ
        ↓
    Multi-AZ: tự chuyển trong 1-2 phút

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

  • **A. Dùng Inspector phát hiện dữ liệu cá nhân, lifecycle sang Glacier Deep Archive, và RDS Multi-AZ — đây là phương án gần nhất và phần Multi-AZ hoàn toàn đúng, nhưng Inspector không quét nội dung S3, và Deep Archive mất 12-48 giờ để lấy — vi phạm yêu cầu "lấy ảnh ngay lập tức".
  • **B. Dùng Inspector, đổi bucket sang IA, và dùng read replica — Inspector sai vai trò, và read replica là cơ chế co giãn đọc chứ không phải sẵn sàng cao.
  • **C. Dùng Macie đúng, nhưng thay S3 bằng EBS và thay RDS bằng Redshift — EBS không thay được S3 cho kho ảnh chia sẻ, và Redshift là kho dữ liệu phân tích chứ không phải CSDL giao dịch.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật và phạm vi — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | Macie | "có dữ liệu nhạy cảm nào trong S3 không?" | | GuardDuty | "có ai đang tấn công không?" | | Inspector | "có lỗ hổng phần mềm nào không?" | | Shield | "chống DDoS" |

Từ khoá nhận diện:

"discover and classify PII in S3" → Macie "retrieve immediately regardless of age" → KHÔNG dùng Glacier Flexible/Deep "database goes down when AZ has issues" → Multi-AZ "unpredictable access pattern" → Intelligent-Tiering

⚠ Bảng lớp lưu trữ và thời gian lấy — phải thuộc: | Lớp | Thời gian lấy | Lưu tối thiểu | |---|---|---| | Standard | ngay | không | | Standard-IA | ngay | 30 ngày | | Glacier Instant Retrieval | mili giây | 90 ngày | | Glacier Flexible Retrieval | 1 phút - 12 giờ | 90 ngày | | Glacier Deep Archive | 12-48 giờ | 180 ngày |

Câu hỏi có chữ "immediately" hoặc
  "milliseconds"
        ↓
    Chỉ Standard, IA, hoặc
      Glacier Instant Retrieval

Ba lưu ý về Macie: | Lưu ý | Chi tiết | |---|---| | Tính phí theo GB quét | | | Giới hạn phạm vi theo tiền tố để giảm chi phí | | | Phát hiện đẩy sang EventBridge được | |

⚠ Giới hạn phạm vi quét:

{"scoping": {"includes": {"and": [{
  "simpleScopeTerm": {"comparator": "STARTS_WITH",
    "key": "OBJECT_KEY", "values": ["metadata/"]}}]}}}

Ảnh không chứa dữ liệu cá nhân dạng văn bản
    → chỉ quét thư mục metadata
    → giảm chi phí nhiều lần

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Object dưới 128 KB không nên chuyển | | | Có phí chuyển lớp mỗi object | | | Kết hợp với việc dọn phiên bản cũ | |

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Bản dự phòng không phục vụ đọc | | | Chi phí gấp đôi | | | Bật được trên instance đang chạy | |

Ba lưu ý về hiệu năng ảnh: | Lưu ý | Chi tiết | |---|---| | CloudFront trước S3 cho người dùng toàn cầu | | | Bản thu nhỏ sinh bằng Lambda | | | Đặt Cache-Control dài cho ảnh | |

Ba lưu ý về bảo mật bucket ảnh: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access | | | Dùng OAC nếu phục vụ qua CloudFront | | | Bật versioning chống ghi đè nhầm | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buộc chuyển đổi Multi-AZ, đo thời gian | | | Kiểm ảnh cũ đã sang lớp IA | | | Xem phát hiện của Macie có gì bất ngờ không | |

Và một lời khuyên: hãy đọc kỹ cụm "lấy ngay lập tức" trong đề trước khi chọn lớp lưu trữ. Đó là một câu ngắn nhưng nó loại thẳng Glacier Flexible và Deep Archive — hai lựa chọn trông rẻ nhất và vì thế hấp dẫn nhất.

Câu 148 Domain - Design for New Solutions

A company wants to improve data protection for the sensitive information stored on its AWS account - both in transit and at rest. Data protection in transit simply means that the data should be secured while it travels to and from Amazon S3. Data protection at rest means that the stored data on disk must be secured in Amazon S3 data centers. You can protect data in transit by using SSL or by using client-side encryption. To secure data at rest, you can choose from a variety of available Server-Side Encryption in S3.

Which of the following best describes how Amazon S3-Managed Keys (SSE-S3) encryption method works?

  1. A

    In SSE-S3, you will be able to manage the KMS keys and Amazon S3 manages the encryption for reading and writing objects in your S3 bucket.
  2. B SSE-S3 provides separate permissions to use an API key that provides added protection against unauthorized access of your objects in S3.
  3. C In SSE-S3, a randomly generated data encryption key is returned which is used by the client to encrypt the object data.
  4. D SSE-S3 provides strong multi-factor encryption in which each object is encrypted with a unique key. It also encrypts the key itself with a master key that it rotates regularly.
Xem giải thích

Đáp án

**D — SSE-S3 mã hoá mỗi object bằng một khoá riêng, rồi mã hoá chính khoá đó bằng một khoá chủ được xoay định kỳ.

Vì sao đúng

Đây là mô tả của mã hoá phong bì (envelope encryption), cơ chế nền tảng của SSE-S3:

Mỗi object: một khoá dữ liệu RIÊNG
    → khoá đó mã hoá nội dung object
        ↓
    Khoá dữ liệu lại được mã hoá
      bằng KHOÁ CHỦ
    → và lưu cạnh object
        ↓
    AWS xoay khoá chủ định kỳ

⚠ Vì sao mã hoá phong bì được dùng thay vì mã hoá thẳng:

Mã hoá thẳng bằng khoá chủ
    → phải gửi toàn bộ dữ liệu tới
      nơi giữ khoá
    → chậm và không co giãn
        ↓
    Phong bì: chỉ gửi khoá dữ liệu
      (vài chục byte) đi mã hoá
    → dữ liệu mã hoá tại chỗ

⚠ Và "mỗi object một khoá" là biện pháp giới hạn thiệt hại:

Một khoá cho cả bucket
    → lộ khoá là lộ mọi object
        ↓
    Mỗi object một khoá
    → lộ một khoá chỉ mất một object

Bật mã hoá mặc định cho bucket:

aws s3api put-bucket-encryption --bucket kho-du-lieu \
  --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm": "AES256"}}]}'

⚠ Từ tháng 1/2023, SSE-S3 bật MẶC ĐỊNH cho mọi object mới:

Trước đây phải khai tường minh
    → nay mọi object tự động mã hoã
        ↓
    Không tính phí thêm
    → không ảnh hưởng hiệu năng
    → câu hỏi kiểu "làm sao mã hoá S3"
      nay bớt ý nghĩa hơn trước

Ba loại mã hoá phía máy chủ — bảng phải thuộc: | Loại | Ai giữ khoá chủ | Kiểm soát | |---|---|---| | SSE-S3 | AWS hoàn toàn | không có | | SSE-KMS | KMS, bạn đặt chính sách | ai giải mã được | | SSE-C | BẠN gửi khoá theo mỗi request | hoàn toàn |

⚠ Chọn SSE-KMS khi cần kiểm soát và ghi nhận:

SSE-S3: không biết ai giải mã object nào
        ↓
    SSE-KMS: CloudTrail ghi mỗi lời gọi
      `Decrypt`
    → biết ai đọc gì, lúc nào
    → và thu hồi quyền bằng key policy

⚠ Nhưng SSE-KMS có chi phí và hạn ngạch:

Mỗi object gọi KMS một lần
    → bucket lưu lượng cao tốn đáng kể
    → và có thể chạm hạn ngạch KMS
        ↓
    Bật S3 Bucket Key: giảm tới 99%
      số lời gọi KMS

aws s3api put-bucket-encryption --bucket kho-du-lieu \
  --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm": "aws:kms",
       "KMSMasterKeyID": "<arn>"},
      "BucketKeyEnabled": true}]}'

Ba lợi ích của SSE-S3: | Lợi ích | Chi tiết | |---|---| | Miễn phí, không phải cấu hình gì | | | Không ảnh hưởng hiệu năng | | | Dùng AES-256, chuẩn công nghiệp | |

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

  • **C. Trong SSE-S3, một khoá mã hoá dữ liệu sinh ngẫu nhiên được TRẢ VỀ cho client để client mã hoá nội dung — đây là phương án gần nhất và mô tả đúng mã hoá phong bì, nhưng đó là cách hoạt động của mã hoá phía client với KMS (GenerateDataKey); với SSE-S3 thì mọi việc mã hoá diễn ra phía máy chủ, client không nhận khoá nào.
  • **A. Trong SSE-S3, bạn quản lý khoá KMS còn S3 lo việc mã hoá — SSE-S3 không dùng KMS và bạn không quản lý khoá nào; đó là mô tả của SSE-KMS.
  • **B. SSE-S3 cung cấp quyền riêng để dùng một API key bảo vệ thêm — không có khái niệm "API key" nào trong SSE-S3.

Ghi nhớ

⚠ Bốn cách mã hoá dữ liệu trên S3 — bảng phải thuộc: | Cách | Mã hoá ở đâu | |---|---| | SSE-S3 | máy chủ, khoá của AWS | | SSE-KMS | máy chủ, khoá trong KMS | | SSE-C | máy chủ, khoá do client gửi | | Client-side | client, trước khi tải lên |

Từ khoá nhận diện:

"each object encrypted with a unique key" → mã hoá phong bì "audit who decrypted" → SSE-KMS "AWS must never see the key" → client-side hoặc SSE-C "reduce KMS cost on S3" → S3 Bucket Key

Ba lưu ý về mã hoá phong bì: | Lưu ý | Chi tiết | |---|---| | Khoá dữ liệu mã hoá nội dung | | | Khoá chủ mã hoá khoá dữ liệu | | | Chỉ khoá dữ liệu đi qua mạng, không phải dữ liệu | |

Ba lưu ý về SSE-C: | Lưu ý | Chi tiết | |---|---| | Bạn gửi khoá theo MỖI request | | | AWS không lưu khoá | | | Mất khoá là mất dữ liệu vĩnh viễn | |

⚠ Bắt buộc mã hoá bằng bucket policy:

{"Effect": "Deny", "Principal": "*",
 "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-du-lieu/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Chặn mọi lần tải lên không mã hoá
    → không phụ thuộc việc client
      nhớ khai đúng

Ba lưu ý về mã hoá khi truyền: | Lưu ý | Chi tiết | |---|---| | Luôn dùng HTTPS | | | Bắt buộc bằng aws:SecureTransport | | | Khác hoàn toàn với mã hoá khi lưu | |

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-du-lieu",
              "arn:aws:s3:::kho-du-lieu/*"],
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Ba lưu ý về KMS: | Lưu ý | Chi tiết | |---|---| | Key policy quyết định ai dùng khoá | | | Cần cả IAM policy lẫn key policy | | | Bật xoay khoá tự động hằng năm | |

⚠ Xoay khoá KMS không mã hoá lại dữ liệu cũ:

Xoay khoá: sinh vật liệu khoá mới
    → dữ liệu mới dùng vật liệu mới
        ↓
    Dữ liệu cũ vẫn giải mã được
      bằng vật liệu cũ
    → KMS giữ mọi phiên bản

Ba lưu ý về đổi cách mã hoá: | Lưu ý | Chi tiết | |---|---| | Đổi cấu hình chỉ áp cho object MỚI | | | Object cũ giữ nguyên cách mã hoá cũ | | | Dùng S3 Batch Operations để mã hoá lại | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | head-object xem header mã hoá | | | Thử tải lên không mã hoá — phải bị từ chối | | | Kiểm CloudTrail có ghi lời gọi KMS không | |

aws s3api head-object --bucket kho-du-lieu --key tep.pdf \
  --query 'ServerSideEncryption'

Và một lời khuyên: hãy chọn SSE-KMS thay vì SSE-S3 khi bạn cần trả lời câu hỏi "ai đã đọc tệp này". Cả hai đều mã hoá tốt như nhau, nhưng chỉ một trong hai để lại dấu vết trong CloudTrail — và đó thường là thứ kiểm toán viên thật sự hỏi.

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

A finance company plans to launch a new website to allow users to view tutorials that promote the proper usage of the mobile app. The website contains static media files that are stored on a private Amazon S3 bucket while the dynamic contents are hosted on an AWS Fargate cluster. The Fargate tasks are accepting traffic behind an Application Load Balancer (ALB). To improve user experience, the static and dynamic content are placed behind an Amazon CloudFront distribution. An Amazon Route 53 Alias record has already been created to point the website URL to the CloudFront distribution. The company wants to ensure that access to both static and dynamic content is done through CloudFront only.

Which of the following options should the Solutions Architect implement to meet this requirement? (Select TWO.)

  1. A

    Create a network ACL that will allow connections from CloudFront only. Associate the NACL to the Application Load Balancer subnets.
  2. B

    Use CloudFront to add a custom header to all origin requests. Using AWS WAF, create a web rule that denies all requests without this custom header. Associate the web ACL to the Application Load Balancer.
  3. C

    Use CloudFront to add a custom header to all origin requests. Using AWS WAF, create a web rule that denies all requests without this custom header. Associate the web ACL to the CloudFront distribution.
  4. D

    Create a special CloudFront user called an origin access control (OAC) and associate it with your distribution. Configure the S3 bucket policy to only access from the OAC.
  5. E

    Configure the S3 bucket ACL to block all access except requests coming from the CloudFront distribution.
Xem giải thích

Đáp án

**B và D — Cho CloudFront thêm một header tuỳ chỉnh vào mọi yêu cầu tới origin, dùng AWS WAF tạo luật từ chối mọi yêu cầu không có header đó và gắn web ACL vào Application Load Balancer; đồng thời tạo origin access control (OAC) gắn vào phân phối và sửa bucket policy chỉ cho OAC đọc.

Vì sao đúng

Đề có hai origin khác nhau, và mỗi origin cần một cơ chế riêng: | Origin | Cơ chế bảo vệ | |---|---| | Bucket S3 (nội dung tĩnh) | OAC + bucket policy | | ALB trước Fargate (nội dung động) | header bí mật + WAF |

⚠ Vì sao ALB không dùng được OAC:

OAC chỉ hoạt động với origin là
  dịch vụ AWS hỗ trợ SigV4
    → S3, Lambda URL, MediaStore
        ↓
    ALB không kiểm chữ ký SigV4
    → phải dùng cách khác

⚠ Và cách đó là header bí mật — cơ chế chuẩn của AWS:

CloudFront thêm header vào mọi
  yêu cầu tới origin
    → `X-Origin-Verify: <chuoi-bi-mat>`
        ↓
    WAF trên ALB: không có header đó
      thì chặn
        ↓
    Người dùng gọi thẳng ALB
    → không biết chuỗi bí mật
    → bị chặn

Thêm header ở CloudFront:

{"Origins": {"Items": [{
  "Id": "alb-fargate",
  "DomainName": "alb-abc.ap-southeast-1.elb.amazonaws.com",
  "CustomHeaders": {"Quantity": 1, "Items": [{
    "HeaderName": "X-Origin-Verify",
    "HeaderValue": "<chuoi-ngau-nhien-dai>"}]},
  "CustomOriginConfig": {"OriginProtocolPolicy": "https-only"}}]}}

Luật WAF trên ALB:

aws wafv2 create-web-acl --name chi-cho-cloudfront \
  --scope REGIONAL --default-action Block={} \
  --rules '[{"Name":"ChoQuaNeuCoHeader","Priority":1,
    "Statement":{"ByteMatchStatement":{
      "FieldToMatch":{"SingleHeader":{"Name":"x-origin-verify"}},
      "PositionalConstraint":"EXACTLY",
      "SearchString":"<chuoi-ngau-nhien-dai>",
      "TextTransformations":[{"Priority":0,"Type":"NONE"}]}},
    "Action":{"Allow":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"header"}}]'

⚠ default-action Block là phần quan trọng:

Mặc định Allow rồi thêm luật Block
    → phải liệt kê hết cách tấn công
        ↓
    Mặc định BLOCK, chỉ Allow khi
      có header đúng
    → an toàn theo mặc định

⚠ Và WAF phải gắn vào ALB, KHÔNG phải CloudFront:

Gắn vào CloudFront: chặn ở tầng CDN
    → nhưng yêu cầu đi THẲNG tới ALB
      không qua CloudFront chút nào
        ↓
    Không bị chặn
    → đây là lý do phương án C sai

OAC cho bucket S3:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::media-tinh/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn":
     "arn:aws:cloudfront::111122223333:distribution/E1ABC"}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cả hai origin đều chỉ nhận từ CloudFront | | | WAF ở ALB còn lọc được tấn công tầng 7 | | | Bucket hoàn toàn riêng tư | |

⚠ Nhớ xoay chuỗi bí mật định kỳ:

Chuỗi rò rỉ qua log hoặc mã nguồn
    → ai cũng bỏ qua được CloudFront
        ↓
    Lưu trong Secrets Manager
    → Lambda xoay định kỳ và cập nhật
      cả CloudFront lẫn WAF

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

  • **C. Thêm header tuỳ chỉnh ở CloudFront rồi tạo luật WAF gắn vào chính phân phối CloudFront — đây là phương án gần nhất và chỉ khác một chỗ gắn, nhưng web ACL ở CloudFront không nhìn thấy yêu cầu đi thẳng vào ALB; header phải được kiểm tra ở ALB mới có tác dụng.
  • **A. Tạo network ACL chỉ cho phép kết nối từ CloudFront, gắn vào subnet của ALB — dải IP của CloudFront gồm hàng trăm khối và thay đổi liên tục; NACL cũng có giới hạn số quy tắc, không quản lý nổi.
  • **E. Cấu hình bucket ACL chặn mọi truy cập trừ CloudFront — ACL của S3 không diễn tả được điều kiện đó; AWS cũng khuyến nghị tắt ACL và dùng bucket policy.

Ghi nhớ

⚠ Bảo vệ origin theo loại — bảng phải thuộc: | Origin | Cơ chế | |---|---| | S3 | OAC + bucket policy | | ALB / EC2 | header bí mật + WAF | | API Gateway | header bí mật hoặc resource policy | | Lambda function URL | OAC (hỗ trợ từ 2024) |

Từ khoá nhận diện:

"only accessible through CloudFront, S3 origin" → OAC "only accessible through CloudFront, ALB origin" → custom header + WAF "restrict by viewer" → signed URL / cookie "block by country" → geo restriction

⚠ Có thể siết thêm bằng danh sách tiền tố quản lý:

aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing

AWS duy trì prefix list cho IP của
  CloudFront hướng origin
    → dùng trong security group của ALB
    → AWS tự cập nhật khi IP đổi
        ↓
    Kết hợp với header bí mật
    → hai lớp độc lập

Ba lưu ý về header bí mật: | Lưu ý | Chi tiết | |---|---| | Chuỗi phải dài và ngẫu nhiên | | | Lưu trong Secrets Manager | | | Xoay định kỳ bằng Lambda | |

Ba lưu ý về OAC: | Lưu ý | Chi tiết | |---|---| | Thay thế OAI đã cũ | | | Hỗ trợ bucket mã hoá SSE-KMS | | | Bucket policy phải có AWS:SourceArn | |

⚠ Với bucket SSE-KMS cần thêm quyền trong key policy:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "kms:Decrypt", "Resource": "*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "<arn-phan-phoi>"}}}

Thiếu: CloudFront trả 403 dù
  bucket policy đã đúng

Ba lưu ý về WAF: | Lưu ý | Chi tiết | |---|---| | Scope REGIONAL cho ALB, CLOUDFRONT cho phân phối | | | Scope CLOUDFRONT phải tạo ở us-east-1 | | | Bật logging để điều tra | |

Ba lưu ý về nhiều origin: | Lưu ý | Chi tiết | |---|---| | Cache behavior chọn origin theo đường dẫn | | | Mỗi origin có cấu hình riêng | | | Origin group cho failover | |

Ba lưu ý về Fargate phía sau: | Lưu ý | Chi tiết | |---|---| | Task đặt trong subnet riêng tư | | | Security group chỉ nhận từ SG của ALB | | | Không cần IP công khai | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl thẳng DNS của ALB — phải bị chặn | | | curl URL S3 trực tiếp — phải 403 | | | curl qua CloudFront — phải 200 | |

Và một lời khuyên: hãy kiểm chứng bằng cách gọi thẳng vào DNS của ALB. Đó là bài kiểm tra duy nhất chứng minh header bí mật đang hoạt động — và cũng là điều gần như không ai thử sau khi cấu hình xong, vì trang web qua CloudFront trông vẫn hoàn hảo.

Câu 150 Domain - Accelerate Workload Migration and Modernization

A company is running 150 virtual machines (VMs) using 40 TB of storage on its on-premises data center. The company wants to migrate its whole environment to AWS within the next three months. The VMs are mainly used during business hours only, so these can be taken offline, but some are mission-critical, which means that the downtime needs to be minimized. Since upgrading the Internet connection is quite costly for the company, the on-premises network administrator provisioned only a 12 Mbps Internet bandwidth for the migration. The Solutions Architect must design a cost-effective plan to complete the migration within the target time frame.

Which of the following options should the Solutions Architect implement to fulfill the requirements?

  1. A

    Use AWS Application Migration Service to migrate the mission-critical virtual machines to AWS. Request an AWS Snowball device and transfer the exported non-mission-critical VMs to it. Once the VMs are on Amazon S3, import the VMs into Amazon EC2 instances using the VM Import/Export service.
  2. B

    Create an export of your virtual machines during out of office hours. Use the AWS Transfer service to securely upload the VMs to Amazon S3 using the SFTP protocol. Import the VMs into Amazon EC2 instances using the VM Import/Export service.
  3. C

    Deploy the AWS Agentless Discovery connector on the company VMware vCenter to assess each application. With the information gathered, refactor each application to run on AWS services or using AWS Marketplace solutions.
  4. D

    Request for a 1 Gbps AWS Direct Connect connection from the on-premises data center to AWS. Create a private virtual interface on Direct Connect. Migrate the virtual machines to AWS using the AWS Application Migration Service (AWS MGN).
Xem giải thích

Đáp án

**A — Dùng AWS Application Migration Service (MGN) cho các máy ảo quan trọng, và xin AWS Snowball để chuyển các máy ảo không quan trọng đã xuất ra tệp; sau khi dữ liệu lên S3 thì nhập thành EC2 bằng VM Import/Export.

Vì sao đúng

Đề cho đủ số liệu để tính, và phép tính quyết định mọi thứ:

40 TB qua đường 12 Mbps
    → 40 × 8.000.000 / 12 giây
    ≈ 26.700.000 giây
    ≈ 308 NGÀY chạy hết công suất
        ↓
    Hạn ba tháng
    → mạng KHÔNG khả thi cho toàn bộ

Đây là lý do phương án B sai hoàn toàn.

⚠ Và Direct Connect cũng không cứu được:

Thời gian cung cấp DX: hàng tuần
  tới hàng tháng
        ↓
    Cộng thời gian chuyển dữ liệu
    → khó vừa hạn ba tháng
        ↓
    Và đề nói nâng băng thông
      "quá tốn kém"
    → DX 1 Gbps còn đắt hơn

Đây là lý do phương án D sai.

⚠ Chiến lược đúng là chia đôi theo mức độ quan trọng:

Máy quan trọng (ít gián đoạn được)
    → MGN nhân bản liên tục qua mạng
    → cutover khi đã sẵn sàng
        ↓
    Máy không quan trọng (tắt được)
    → xuất ra tệp, chép vào Snowball
    → gửi thiết bị đi

⚠ Vì sao MGN vẫn dùng được dù băng thông thấp:

MGN nhân bản ở mức KHỐI, liên tục
    → chỉ gửi phần THAY ĐỔI sau lần
      đồng bộ đầu
        ↓
    Vài máy quan trọng có thể vừa
      băng thông 12 Mbps
    → phần lớn dung lượng đi bằng
      Snowball

Cài agent MGN:

sudo python3 aws-replication-installer-init.py \
  --region ap-southeast-1 \
  --aws-access-key-id <id> --aws-secret-access-key <key>

Đặt hàng Snowball:

aws snowball create-job --job-type IMPORT \
  --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::may-ao-xuat"}]}' \
  --address-id <id-dia-chi> \
  --snowball-type EDGE_STORAGE_OPTIMIZED \
  --shipping-option SECOND_DAY

Nhập máy ảo thành AMI:

aws ec2 import-image --disk-containers \
  '[{"Description":"may-chu-01","Format":"vmdk",
     "UserBucket":{"S3Bucket":"may-ao-xuat",
                   "S3Key":"may-chu-01.vmdk"}}]'

⚠ VM Import/Export có ràng buộc phải biết trước:

Cần vai trò `vmimport` với trust policy
  cho `vmie.amazonaws.com`
    + hỗ trợ VMDK, VHD, VHDX, OVA, RAW
    + không hỗ trợ mọi hệ điều hành
        ↓
    Kiểm danh sách hỗ trợ TRƯỚC
      khi xuất 150 máy

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Vừa hạn ba tháng | | | Máy quan trọng gián đoạn tối thiểu | | | Không phải nâng cấp đường truyền | |

⚠ Và Snowball không chiếm băng thông sản xuất:

Chuyển qua mạng: 12 Mbps dùng hết
    → nhân viên không làm việc nổi
        ↓
    Snowball: chép qua LAN nội bộ
    → đường Internet vẫn rảnh

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

  • **D. Xin Direct Connect 1 Gbps và dùng MGN chuyển toàn bộ — đây là phương án gần nhất và MGN là công cụ đúng, nhưng thời gian cung cấp Direct Connect thường tính bằng tuần tới tháng, và đề nói rõ nâng băng thông là "quá tốn kém".
  • **B. Xuất máy ảo ngoài giờ làm việc và tải lên S3 bằng AWS Transfer (SFTP) — vẫn đi qua đường 12 Mbps; phép tính cho ra hơn 300 ngày.
  • **C. Cài Agentless Discovery connector rồi refactor từng ứng dụng — refactor 150 máy trong ba tháng là bất khả thi, và Discovery chỉ khảo sát chứ không di chuyển gì.

Ghi nhớ

⚠ Công thức chọn giữa mạng và thiết bị vật lý:

Thời gian (ngày) = Dung lượng (TB) × 8.000
                   / (Băng thông Mbps × 86.400 / 1.000)
        ↓
    Kết quả lớn hơn thời hạn cho phép
    → dùng Snowball
Dung lượng 100 Mbps 1 Gbps 10 Gbps
10 TB ~10 ngày ~1 ngày vài giờ
100 TB ~100 ngày ~10 ngày ~1 ngày
500 TB không khả thi ~50 ngày ~5 ngày

Từ khoá nhận diện:

"limited bandwidth, large dataset, deadline" → Snowball "minimise downtime for critical servers" → MGN "assess before migrating" → Application Discovery Service "ongoing sync over network" → DataSync

Ba lưu ý về MGN: | Lưu ý | Chi tiết | |---|---| | Nhân bản liên tục ở mức khối | | | Kiểm thử nhiều lần không ảnh hưởng nguồn | | | Cutover khi đã kiểm thử xong | |

⚠ Kiểm thử không ảnh hưởng nguồn là điểm mạnh nhất của MGN:

Nhân bản vẫn chạy
    → khởi động instance kiểm thử
      từ bản sao
        ↓
    Kiểm thử bao nhiêu lần cũng được
    → hệ thống thật không hề biết

Ba lưu ý về Snowball Edge: | Lưu ý | Chi tiết | |---|---| | Storage Optimized khoảng 80 TB dùng được | | | Mã hoá bằng KMS, khoá không nằm trên thiết bị | | | Nhiều phiên sao chép song song để nhanh | |

⚠ Ba khuyến nghị tăng thông lượng khi chép vào Snowball:

1. Nhiều phiên sao chép song song
2. Nhiều máy khách cùng lúc
3. Gộp tệp nhỏ thành tệp lớn
        ↓
    Nút thắt là CPU máy khách
      (do mã hoá), không phải đĩa

Ba lưu ý về VM Import/Export: | Lưu ý | Chi tiết | |---|---| | Cần vai trò vmimport | | | Kiểm danh sách hệ điều hành hỗ trợ | | | Gỡ phần mềm ảo hoá trước khi xuất | |

Ba lưu ý về lập kế hoạch di chuyển: | Lưu ý | Chi tiết | |---|---| | Khảo sát bằng Application Discovery Service | | | Nhóm theo ứng dụng, không theo máy lẻ | | | Di chuyển cả cụm phụ thuộc cùng lúc | |

⚠ Chia nhầm đợt gây độ trễ khủng khiếp:

Máy web lên cloud, CSDL còn tại chỗ
    → mỗi truy vấn đi vòng qua
      đường 12 Mbps
        ↓
    Trang cần 50 truy vấn
    → cộng dồn thành hàng giây

Ba lưu ý về thời gian: | Lưu ý | Chi tiết | |---|---| | Đặt Snowball sớm — vận chuyển mất ngày | | | Chờ xác nhận nhập xong mới xoá bản gốc | | | Chừa thời gian kiểm thử trước cutover | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối chiếu số máy ảo và dung lượng sau khi nhập | | | Khởi động thử vài AMI đã nhập | | | Đo thời gian nhân bản của MGN cho máy quan trọng | |

Và một lời khuyên: hãy làm phép tính băng thông trước khi bàn tới bất cứ phương án nào. Con số 40 TB trên đường 12 Mbps ra hơn ba trăm ngày — và phép tính một dòng đó loại thẳng một nửa số lựa chọn trước khi bạn kịp đọc hết chúng.