Ngân hàng đề — AWS Certified SysOps Administrator Associate

Đáp án

D — Bật AURORA AUTO SCALING để co giãn SỐ LƯỢNG REPLICA, và sửa ứng dụng dùng READER ENDPOINT.

Vì sao đúng

Đề có ba manh mối, và cả ba đều chỉ về cùng một hướng: mở rộng năng lực ĐỌC theo chiều ngang.

⚠ Manh mối thứ nhất — tải BIẾN ĐỘNG, có đỉnh khó đoán:

"usage is highly variable with unpredictable spikes"
        ↓
    → cần cơ chế TỰ CO GIÃN
    → Aurora Auto Scaling thêm/bớt replica
      theo CPU hoặc số kết nối

⚠ Manh mối thứ hai — cùng một truy vấn HIẾM KHI lặp lại:

"the same query is rarely performed multiple times"
        ↓
    → CACHE gần như VÔ DỤNG
    → tỉ lệ cache hit sẽ rất thấp
        ↓
    → loại hẳn phương án ElastiCache
        ↓
    Đây là câu chốt của cả bài

⚠ Manh mối thứ ba — phần lớn tải là TRUY VẤN (đọc):

"Much of the load is database queries"
        ↓
    → tải ĐỌC, không phải tải GHI
    → chia được qua nhiều replica
        ↓
    Reader endpoint tự cân bằng tải
    qua MỌI replica đang có
        ↓
    → replica mới do Auto Scaling tạo ra
      TỰ ĐỘNG được đưa vào
    → ứng dụng không phải biết gì

⚠ Vì sao phải sửa ứng dụng dùng reader endpoint:

Ứng dụng đang gọi CLUSTER (writer) ENDPOINT
        ↓
    → mọi truy vấn dồn vào node GHI
    → thêm bao nhiêu replica cũng vô ích
        ↓
    Tách đường đọc sang READER ENDPOINT
        ↓
    → tải đọc mới thật sự được chia
    → đây là phần "update the application"
      trong phương án đúng

Xem thêm câu #11823 (lô 127): cùng giải pháp thêm Aurora Replica để chia tải đọc, ở đó là thao tác thủ công một lần; ở đây là tự động co giãn. Khoá nhất quán.

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

• A (dựng ElastiCache để cache truy vấn) — đây là phương án gần nhất và thường là câu trả lời đúng cho các đề tương tự, nhưng đề đã cố ý loại nó: "cùng một truy vấn hiếm khi được thực hiện nhiều lần". Cache chỉ có giá trị khi dữ liệu được đọc lại — ở đây tỉ lệ hit sẽ gần bằng không.

• C (Aurora Auto Scaling để co giãn KÍCH THƯỚC instance) — Aurora Auto Scaling co giãn SỐ LƯỢNG REPLICA, không co giãn cỡ instance. Đây là điểm phân biệt trực tiếp với phương án D.

• B (tạo mảng RAID 0 cho các instance của cụm Aurora) — bạn không quản lý lưu trữ của Aurora: tầng lưu trữ do AWS lo, tự mở rộng, 6 bản sao trên 3 AZ. Không có đĩa nào để cấu hình RAID.

Ghi nhớ

⚠ Aurora Auto Scaling — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Co giãn cái gì | SỐ LƯỢNG read replica (tối đa 15) | | KHÔNG co giãn | kích thước instance, và node ghi | | Dựa trên | CPUUtilization trung bình hoặc DatabaseConnections trung bình | | Replica mới | tự vào READER ENDPOINT | | Điều kiện | ứng dụng phải dùng reader endpoint | | Cấu hình | min/max replica, giá trị mục tiêu, thời gian chờ |

Từ khoá nhận diện:

"tải đọc biến động, cần tự co giãn" → Aurora Auto Scaling replica + reader endpoint "truy vấn lặp lại nhiều" → ElastiCache "truy vấn HIẾM KHI lặp lại" → cache vô dụng — thêm replica "tải ghi cao" → đổi cỡ node ghi, hoặc phân mảnh "tải khó đoán, không muốn chọn cỡ" → Aurora Serverless v2

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải có được chia không | DatabaseConnections theo TỪNG instance | | Auto Scaling có chạy không | describe-scalable-targets, và sự kiện của cụm | | Truy vấn nào nặng | Performance Insights → Top SQL |

Và một việc nên làm trước khi tăng số replica: kiểm tra ứng dụng thực sự đang gọi endpoint nào. Rất nhiều hệ thống thêm replica rồi không thấy cải thiện gì, đơn giản vì mọi kết nối vẫn trỏ tới cluster endpoint — và trong trường hợp đó, thứ bạn vừa mua là những node nhàn rỗi được tính tiền theo giờ.

Đáp án

B và E — Thêm một tuyến trong ROUTE TABLE của subnet trỏ tới internet gateway, VÀ tạo INTERNET GATEWAY rồi gắn vào VPC.

Vì sao đúng

Đề cần kết nối cả hai chiều — vào và ra internet. Đó là định nghĩa của public subnet, và public subnet cần đúng hai thành phần này.

⚠ Điểm mấu chốt — ba điều kiện để một máy ra vào internet được:

1. Internet Gateway gắn vào VPC       ← phương án E
        ↓
2. Route table của subnet có tuyến:
       0.0.0.0/0  →  igw-xxxxx        ← phương án B
        ↓
3. Instance có ĐỊA CHỈ IP CÔNG CỘNG
   (public IP hoặc Elastic IP)
        ↓
    Thiếu bất kỳ điều nào → không ra vào được

⚠ Và hai lớp lọc phải cho phép:

4. Security group: mở cổng cần thiết chiều VÀO
5. Network ACL: mở CẢ HAI chiều
     (nhớ dải cổng tạm 1024-65535 chiều ra)

⚠ Vì sao NAT Gateway không phải câu trả lời:

NAT Gateway
        ↓
    Cho máy ở PRIVATE subnet đi RA internet
        ↓
    NHƯNG chặn hoàn toàn chiều VÀO
        ↓
    Đề cần "cả incoming và outgoing"
        ↓
    → NAT không thoả được vế incoming

Xem thêm câu #11862 (lô 128): gần như cùng một câu hỏi, cùng cặp đáp án — tạo IGW và thêm tuyến route table. Chỉ khác chữ cái vì bộ đề xáo thứ tự phương án (ở đó là B và C, ở đây là B và E). Khoá nhất quán.

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

• D (thêm NAT gateway vào public subnet và cập nhật route table) — đây là phương án gần nhất và NAT đúng là đặt ở public subnet, nhưng NAT chỉ cho chiều RA. Đề đòi cả chiều vào.

• C (gắn Elastic IP vào internet gateway) — IGW không nhận Elastic IP. EIP gắn vào instance, ENI, NAT Gateway hoặc NLB.

• A (gắn địa chỉ RIÊNG vào elastic network interface của máy) — mọi ENI đã có sẵn IP riêng; và IP riêng không giúp gì cho việc ra internet — thứ cần là IP công cộng.

Ghi nhớ

⚠ Public subnet ↔ Private subnet — bảng phải thuộc: | | Public subnet | Private subnet | |---|---|---| | Định nghĩa | route table có 0.0.0.0/0 → IGW | không có tuyến tới IGW | | Ra internet | có (nếu máy có IP công cộng) | chỉ qua NAT Gateway | | Vào từ internet | CÓ | không bao giờ | | Đặt gì ở đây | ALB, NAT Gateway, bastion | máy ứng dụng, CSDL |

Từ khoá nhận diện:

"cần cả vào và ra internet" → IGW + tuyến route table + IP công cộng "ra được nhưng không ai vào được" → NAT Gateway "IPv6, chỉ ra không vào" → Egress-only Internet Gateway "không được ra internet chút nào" → private subnet, không NAT "gọi dịch vụ AWS mà không qua internet" → VPC endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IGW đã gắn chưa | describe-internet-gateways --filters Name=attachment.vpc-id,... | | Subnet có phải public không | đọc route table, tìm 0.0.0.0/0 → igw- | | Máy ra được chưa | trên máy: curl https://checkip.amazonaws.com |

Và một sai lầm rất hay gặp khi tự dựng VPC lần đầu: tạo Internet Gateway rồi quên thêm tuyến vào route table. Console không báo lỗi gì, mọi thứ trông như đã xong, và triệu chứng duy nhất là mọi kết nối ra ngoài đều timeout — thứ dễ bị đổ nhầm cho security group hơn là cho một dòng còn thiếu trong bảng định tuyến.

Đáp án

D — Tạo bucket policy cho phép ĐỌC CÔNG KHAI với MỌI ĐỐI TƯỢNG trong bucket.

Vì sao đúng

Điểm mấu chốt nằm ở một chi tiết trong đề: origin dùng S3 STATIC WEBSITE ENDPOINT, chứ không phải REST endpoint.

⚠ Điểm mấu chốt — hai loại endpoint của S3 hành xử KHÁC HẲN:

S3 REST endpoint
    bucket.s3.<region>.amazonaws.com
        ↓
    → CloudFront dùng được ORIGIN ACCESS CONTROL (OAC)
    → bucket giữ RIÊNG TƯ hoàn toàn
    → chỉ CloudFront đọc được

S3 STATIC WEBSITE endpoint   ← đề này
    bucket.s3-website-<region>.amazonaws.com
        ↓
    → CloudFront coi nó là CUSTOM ORIGIN
    → KHÔNG dùng được OAC / OAI
    → bucket BẮT BUỘC phải cho ĐỌC CÔNG KHAI
        ↓
    Thiếu quyền công khai → 403 Access Denied
    → đúng lỗi trong đề

⚠ Bucket policy cần thiết:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::ten-bucket/*"
}

Chú ý Resource có /*
        ↓
    s3:GetObject là thao tác trên ĐỐI TƯỢNG
    → thiếu /* thì chính sách VÔ TÁC DỤNG
    → đây là điểm phân biệt với phương án A

⚠ Và phải tắt Block Public Access:

Block Public Access bật ở cấp bucket hoặc tài khoản
        ↓
    → bucket policy công khai bị VÔ HIỆU
    → vẫn 403
        ↓
    Phải tắt các cờ liên quan cho bucket đó

⚠ Nhưng vì sao đề lại dùng website endpoint:

Website endpoint có những thứ REST endpoint không có:
        ↓
    - Index document (index.html cho mỗi thư mục)
    - Error document tuỳ chỉnh
    - Redirect rule
        ↓
    → cần các tính năng này thì phải dùng
      website endpoint, và chấp nhận bucket công khai
        ↓
    Nếu KHÔNG cần → dùng REST endpoint + OAC
    → an toàn hơn hẳn

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

• A (bucket policy cho phép đọc công khai BUCKET) — đây là phương án gần nhất và gần đúng hoàn toàn, nhưng sai ở phạm vi: quyền đọc phải áp cho các ĐỐI TƯỢNG (arn:aws:s3:::bucket/*), không phải cho bucket (arn:aws:s3:::bucket). Đây chính là bẫy /* quen thuộc.

• C (gỡ bucket policy mặc định từ chối đọc) — S3 không có bucket policy mặc định nào. Bucket mới tạo không có policy, và mặc định là từ chối mọi truy cập ẩn danh — không phải do một chính sách nào để mà gỡ.

• B (bật mã hoá mặc định bằng khoá do S3 quản lý) — mã hoá không liên quan gì tới quyền truy cập. Lỗi 403 là lỗi quyền.

Ghi nhớ

⚠ Hai loại endpoint S3 làm origin — bảng phải thuộc: | | REST endpoint | Website endpoint | |---|---|---| | Tên miền | bucket.s3.<region>.amazonaws.com | bucket.s3-website-<region>.amazonaws.com | | OAC / OAI | DÙNG ĐƯỢC | KHÔNG | | Bucket riêng tư | CÓ | KHÔNG — phải công khai | | Index document | không | CÓ | | Error document, redirect | không | CÓ | | CloudFront coi là | S3 origin | custom origin | | Khuyến nghị | REST + OAC cho hầu hết trường hợp | |

Từ khoá nhận diện:

"403 với S3 website endpoint làm origin" → bucket phải cho ĐỌC CÔNG KHAI "muốn bucket riêng tư sau CloudFront" → REST endpoint + OAC "cần index.html cho mỗi thư mục" → website endpoint, hoặc CloudFront Function "Resource không có /*" → chính sách vô tác dụng với GetObject "đã có policy công khai mà vẫn 403" → Block Public Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi thẳng S3 có được không | mở URL của bucket — với OAC phải nhận 403 | | Origin là loại nào | get-distribution-config → đọc DomainName của origin | | Block Public Access đang thế nào | get-public-access-block |

Và một lời khuyên nên áp dụng cho gần như mọi website tĩnh mới: dùng REST endpoint kèm OAC thay vì website endpoint. Hai tính năng khiến người ta chọn website endpoint — index document và trang lỗi tuỳ chỉnh — đều thay thế được bằng CloudFront Function và custom error response, và đổi lại bạn có một bucket hoàn toàn riêng tư thay vì một bucket mở ra internet mà chỉ trông chờ vào việc không ai đoán được tên nó.

Đáp án

D — Mua COMPUTE SAVINGS PLANS theo khuyến nghị trong Cost Explorer.

Vì sao đúng

Đề có ba đặc điểm, và chỉ Compute Savings Plans phủ được cả ba.

⚠ Điểm mấu chốt — ba ràng buộc và cách Compute SP đáp ứng:

1. "EC2 On-Demand VÀ Lambda"
        ↓
    Compute Savings Plans áp cho
      EC2 + FARGATE + LAMBDA
        ↓
    → phủ được CẢ HAI loại tải
    → RI và EC2 Instance SP KHÔNG áp cho Lambda

2. "nhiều AWS Region"
        ↓
    Compute SP áp cho MỌI REGION
        ↓
    → không phải mua riêng cho từng Region

3. "mức tiêu thụ ỔN ĐỊNH"
        ↓
    → cam kết dài hạn là hợp lý
    → và Cost Explorer khuyến nghị được
      mức cam kết dựa trên lịch sử thật

⚠ Vì sao dùng khuyến nghị của Cost Explorer thay vì tự đoán:

Cost Explorer → Savings Plans → Recommendations
        ↓
    Phân tích lịch sử dùng thật (7/30/60 ngày)
        ↓
    Đề xuất:
      - mức cam kết mỗi giờ
      - kỳ hạn (1 hay 3 năm)
      - kiểu thanh toán
      - ƯỚC TÍNH số tiền tiết kiệm
        ↓
    → dựa trên DỮ LIỆU, không phải cảm tính
    → và nó tự tính mức an toàn
      để không bị lãng phí cam kết

⚠ Nguyên tắc chọn mức cam kết:

Cam kết theo mức chi tiêu THẤP NHẤT
mà bạn CHẮC CHẮN sẽ dùng
        ↓
    Phần vượt lên → vẫn tính giá On-Demand
        ↓
    → cam kết thấp mà dùng hết
      LUÔN tốt hơn cam kết cao rồi lãng phí

Xem thêm câu #11897 (cùng lô): cũng chọn Compute Savings Plans, ở đó lý do là sắp chuyển sang Fargate. Khoá nhất quán — Compute SP là lựa chọn khi tải trải trên nhiều loại dịch vụ tính toán.

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

• B (EC2 Instance Savings Plans theo khuyến nghị Cost Explorer) — đây là phương án gần nhất và cũng dùng đúng công cụ khuyến nghị, nhưng EC2 Instance SP khoá vào MỘT họ máy trong MỘT Region và KHÔNG áp cho Lambda. Đề có cả Lambda và nhiều Region.

• A (Convertible Reserved Instances dựa trên chỉ số CloudWatch) — Convertible RI linh hoạt hơn Standard RI nhưng vẫn chỉ áp cho EC2, không áp cho Lambda. Và CloudWatch không phải công cụ để quyết định mua sắm — đó là việc của Cost Explorer.

• C (Standard Reserved Instances dựa trên chỉ số CloudWatch) — kém linh hoạt nhất: khoá vào loại máy, Region và AZ; không áp cho Lambda; và cũng dùng sai công cụ phân tích.

Ghi nhớ

⚠ Phạm vi áp dụng của các cam kết — bảng phải thuộc: | Cơ chế | Áp cho | Linh hoạt | |---|---|---| | Compute Savings Plans | EC2 + FARGATE + LAMBDA, mọi Region, mọi họ máy | cao nhất | | EC2 Instance Savings Plans | một họ máy, một Region | trung bình | | Convertible RI | EC2, đổi được loại máy | trung bình | | Standard RI | EC2, cố định loại máy | thấp nhất | | Mức giảm | Compute ~66% ↔ EC2 Instance / Standard RI ~72% | đánh đổi linh hoạt lấy giảm giá |

Từ khoá nhận diện:

"có cả Lambda / Fargate" → Compute Savings Plans "nhiều Region" → Compute Savings Plans "một họ máy cố định, một Region" → EC2 Instance SP (giảm sâu hơn) "cần bảo đảm CÓ máy" → Capacity Reservation hoặc Zonal RI "quyết định mua sắm dựa trên gì" → Cost Explorer recommendations

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nên cam kết bao nhiêu | Cost Explorer → Savings Plans recommendations | | Đã dùng hết chưa | utilization report | | Còn chi tiêu nào chưa phủ | coverage report |

Và một sai lầm rất tốn kém mà thứ tự công việc có thể tránh được: mua Savings Plans trước khi right-sizing. Nếu đội máy đang lớn hơn mức cần thiết, một cam kết ba năm sẽ khoá luôn sự lãng phí đó lại — và bạn sẽ mất động lực tối ưu, vì giảm mức dùng xuống chỉ khiến tỉ lệ sử dụng cam kết tụt đi chứ không tiết kiệm thêm đồng nào.

Đáp án

A — Tạo một accelerator trong AWS GLOBAL ACCELERATOR và cập nhật bản ghi DNS.

Vì sao đúng

Hai chi tiết trong đề loại hết các phương án khác: giao thức là SFTP (không phải HTTP), và load balancer là Network Load Balancer (tầng 4).

⚠ Điểm mấu chốt — CloudFront chỉ làm HTTP/HTTPS:

SFTP chạy trên TCP cổng 22
        ↓
    KHÔNG phải HTTP
        ↓
    → CloudFront KHÔNG dùng được
    → và cũng không có gì để CACHE
      (SFTP là truyền tệp có phiên, có trạng thái)
        ↓
GLOBAL ACCELERATOR
        ↓
    Hoạt động ở TẦNG 4 — mọi giao thức TCP/UDP
        ↓
    → đúng loại lưu lượng của đề

⚠ Global Accelerator cải thiện bằng cách nào:

Người dùng châu Âu
        ↓
    Vào MẠNG AWS ngay tại điểm hiện diện gần nhất
      (chỉ vài mili giây)
        ↓
    Từ đó đi trên ĐƯỜNG TRỤC RIÊNG của AWS
    tới NLB ở Hoa Kỳ
        ↓
    → tránh phần lớn chặng đường internet công cộng
    → ít mất gói, đường ổn định hơn
    → cải thiện cả ĐỘ TRỄ lẫn ĐỘ ỔN ĐỊNH
        ↓
    Đúng hai thứ đề yêu cầu

⚠ Và nó cho thêm hai IP tĩnh anycast:

Global Accelerator cấp 2 ĐỊA CHỈ IP TĨNH
        ↓
    → client SFTP thường cấu hình bằng IP
      hoặc bằng tên miền cố định
    → không phụ thuộc DNS TTL
        ↓
    Sau này muốn thêm endpoint ở Region châu Âu
        ↓
    → chỉ thêm vào accelerator
    → KHÔNG phải đổi gì phía client

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

• D (tạo Network Load Balancer mới ở một Region châu Âu) — đây là phương án gần nhất và thực sự giảm độ trễ, nhưng nó đòi triển khai cả một bản sao ứng dụng ở Region đó: máy chủ, dữ liệu, đồng bộ trạng thái. Rất nhiều công so với việc bật một accelerator.

• B (tạo CloudFront distribution) — CloudFront chỉ phục vụ HTTP/HTTPS, không chuyển tiếp được SFTP.

• C (tạo Auto Scaling group ở một Region châu Âu) — chỉ thêm máy, không có gì đưa lưu lượng tới đó; và cũng vướng đúng vấn đề nhân bản dữ liệu như phương án D.

Ghi nhớ

⚠ CloudFront ↔ Global Accelerator — bảng phải thuộc: | | CloudFront | Global Accelerator | |---|---|---| | Giao thức | CHỈ HTTP/HTTPS | MỌI TCP/UDP | | Cache | CÓ | KHÔNG | | IP tĩnh | không (dùng tên miền) | CÓ — 2 IP anycast | | Failover đa Region | qua origin group | nhanh, khoảng 30 giây | | Tính tiền | dữ liệu ra + request | phí cố định mỗi giờ + dữ liệu | | Dùng khi | web, ảnh, video, API HTTP | game, VoIP, IoT, SFTP, MQTT |

Từ khoá nhận diện:

"TCP/UDP không phải HTTP" → Global Accelerator "cần IP TĨNH" → Global Accelerator hoặc NLB "nội dung tĩnh, người dùng toàn cầu" → CloudFront "failover đa Region nhanh hơn DNS" → Global Accelerator "tải LÊN S3 chậm từ xa" → Transfer Acceleration

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cải thiện thật không | đo độ trễ từ châu Âu trước và sau | | Endpoint có khoẻ không | Global Accelerator console → Endpoint health | | Lưu lượng đi đâu | flow log của accelerator |

Và một lựa chọn đáng đưa ra bàn cùng lúc: AWS Transfer Family thay cho việc tự chạy SFTP trên EC2. Nó là dịch vụ SFTP được quản lý, ghi thẳng vào S3, dùng IAM để phân quyền — nên ngoài việc giải quyết độ trễ bằng Global Accelerator, bạn còn bỏ được cả một đội máy chủ phải vá và phải theo dõi.

Đáp án

A và E — Dùng SAI tên DNS hoặc sai endpoint của CSDL, VÀ nguồn kết nối chưa được cho phép trong luật INGRESS của security group của CSDL.

Vì sao đúng

Hai nguyên nhân này chiếm phần lớn các ca "ứng dụng không kết nối được RDS" trong thực tế.

⚠ Nguyên nhân thứ nhất — sai endpoint:

Endpoint RDS có dạng:
    ten-db.abc123xyz.ap-southeast-1.rds.amazonaws.com
        ↓
    Rất dài, dễ chép thiếu, dễ nhầm giữa
    các môi trường
        ↓
    Và với Aurora còn có NHIỀU endpoint:
      cluster (writer), reader, instance
        ↓
    → dùng nhầm reader endpoint để GHI
      → lỗi read-only
    → dùng nhầm endpoint của môi trường khác
      → không kết nối được

⚠ Nguyên nhân thứ hai — security group chiều VÀO:

Security group của RDS
        ↓
    Mặc định inbound: KHÔNG CHO GÌ
        ↓
    Phải có luật:
      Type: MySQL/Aurora (3306)
      Source: sg-của-máy-ứng-dụng
        ↓
    Thiếu luật này → kết nối TIMEOUT
        ↓
    Thực hành tốt: nguồn là SECURITY GROUP
    của ứng dụng, không phải một dải CIDR
      → máy mới tự động được phép

⚠ Vì sao chiều EGRESS không phải nguyên nhân:

Security group có TRẠNG THÁI (stateful)
        ↓
    Kết nối vào đã được chấp nhận
      → phản hồi TỰ ĐỘNG được đi ra
        ↓
    Và outbound của security group
      MẶC ĐỊNH cho phép TẤT CẢ
        ↓
    → phương án C sai vì lý do này

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

• C (nguồn chưa được cho phép trong luật EGRESS của security group của CSDL) — đây là phương án gần nhất và chỉ sai một từ: phải là INGRESS. Security group là stateful, và outbound mặc định đã mở hết.

• B (CSDL vẫn đang được tạo nên chưa kết nối được) — đề nói rõ "sau khi bảo đảm ứng dụng và CSDL đã triển khai đầy đủ", nên tình huống này đã bị loại.

• D (instance CSDL không có Elastic IP) — RDS trong private subnet KHÔNG cần và KHÔNG nên có IP công cộng. Ứng dụng cũng nằm trong VPC nên kết nối bằng IP riêng.

Ghi nhớ

⚠ Danh sách kiểm tra kết nối ứng dụng → RDS — bảng phải thuộc: | Bước | Kiểm tra | |---|---| | 1 | Endpoint có đúng không — chép nguyên văn từ console | | 2 | SG của RDS có luật inbound cho SG của ứng dụng ở cổng CSDL | | 3 | NACL của cả hai subnet — cả hai chiều, nhớ cổng tạm | | 4 | Route table — hai subnet có định tuyến tới nhau | | 5 | Cùng VPC không, hay cần peering / Transit Gateway | | 6 | Thông tin đăng nhập và tên database | | 7 | PubliclyAccessible — nếu gọi từ ngoài VPC |

Từ khoá nhận diện:

"kết nối CSDL thất bại" → security group inbound và endpoint, trước tiên "timeout" → SG, NACL, route table "connection refused" → tới được máy nhưng không ai nghe cổng đó "access denied for user" → mạng OK, sai thông tin đăng nhập "read-only" → đang gọi READER endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đúng chưa | describe-db-instances --query '...Endpoint.Address' | | SG cho phép gì | describe-security-groups — đọc JSON, đừng nhìn console | | Mạng có thông không | nc -zv từ chính máy ứng dụng |

Và một cách tách bạch vấn đề rất nhanh khi gặp lỗi kết nối: chạy nc -zv <endpoint> 3306 từ máy ứng dụng trước khi động vào bất cứ thứ gì. Nếu lệnh đó thành công thì tầng mạng hoàn toàn ổn và bạn nên đi tìm ở phía chuỗi kết nối hoặc thông tin đăng nhập; nếu nó treo rồi timeout thì vấn đề nằm ở security group, NACL hoặc định tuyến — và bạn vừa loại được một nửa số nghi phạm trong vài giây.

Đáp án

A và C — Dùng Cache-Control max-age để tăng thời gian đối tượng nằm trong cache, VÀ sửa cache behavior để chỉ chuyển tiếp những cookie, query string và header THẬT SỰ CẦN.

Vì sao đúng

Tỉ lệ cache hit dưới 20% gần như luôn có đúng hai nguyên nhân, và hai phương án đúng chữa đúng hai nguyên nhân đó.

⚠ Nguyên nhân thứ nhất — TTL quá ngắn:

Đối tượng hết hạn quá nhanh
        ↓
    → CloudFront phải hỏi lại origin liên tục
        ↓
    Cách chữa:
      origin gửi header
        Cache-Control: max-age=86400
      hoặc đặt Default TTL / Max TTL
      trong cache policy
        ↓
    → đối tượng nằm lại edge lâu hơn

⚠ Nguyên nhân thứ hai — KHOÁ CACHE quá chi tiết (quan trọng hơn):

CloudFront tạo MỘT MỤC CACHE RIÊNG cho
mỗi tổ hợp khoá cache
        ↓
    Khoá cache gồm: đường dẫn + những
    header/cookie/query string được khai
        ↓
    Chuyển tiếp TẤT CẢ cookie
        ↓
    → mỗi người dùng có cookie phiên khác nhau
    → MỖI NGƯỜI một mục cache riêng
    → tỉ lệ hit gần bằng 0
        ↓
    Chuyển tiếp query string theo dõi quảng cáo
      ?utm_source=..., ?fbclid=...
        ↓
    → mỗi liên kết chia sẻ là một mục cache mới
        ↓
    Cách chữa: CHỈ khai những thứ THẬT SỰ
    làm thay đổi nội dung phản hồi

⚠ Phân biệt hai chính sách — điểm hay nhầm nhất:

CACHE POLICY
        ↓
    Quyết định KHOÁ CACHE và TTL
    → ảnh hưởng TRỰC TIẾP tới tỉ lệ hit

ORIGIN REQUEST POLICY
        ↓
    Quyết định thứ gì được CHUYỂN XUỐNG ORIGIN
    → KHÔNG nằm trong khoá cache
        ↓
    → cần một header ở origin (ví dụ User-Agent
      để ghi log) nhưng KHÔNG muốn nó tạo
      biến thể cache?
      → đưa vào ORIGIN REQUEST POLICY

Xem thêm câu #11876 (lô 128): cùng chủ đề CloudFront cache cho nội dung tĩnh.

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

• B (giới hạn phương thức HTTP chỉ còn GET và HEAD) — đây là phương án gần nhất vì CloudFront chỉ cache GET và HEAD thật. Nhưng việc cho phép thêm POST/PUT không làm giảm tỉ lệ hit: các request đó vốn đã không được cache, và chúng cũng không tạo ra biến thể cache nào.

• D (giảm origin response timeout để nhiều đối tượng được trả về từ cache hơn) — hiểu sai cơ chế: timeout quyết định CloudFront chờ origin bao lâu trước khi báo lỗi, không liên quan gì tới việc cache.

• E (đổi viewer protocol policy sang redirect HTTP → HTTPS) — cải thiện bảo mật, hoàn toàn không ảnh hưởng tới tỉ lệ cache hit.

Ghi nhớ

⚠ Những gì làm giảm tỉ lệ cache hit — bảng phải thuộc: | Nguyên nhân | Cách chữa | |---|---| | Chuyển tiếp TẤT CẢ cookie | chỉ khai cookie thật sự cần | | Chuyển tiếp TẤT CẢ query string | chỉ khai tham số ảnh hưởng nội dung | | Chuyển tiếp nhiều header | bỏ User-Agent, Accept-Language nếu không cần | | TTL quá ngắn | tăng max-age, đặt Default TTL | | Origin gửi Cache-Control: no-cache | sửa ở origin | | Nội dung thật sự cá nhân hoá | không cache được — dùng Lambda@Edge hoặc tách đường dẫn |

Từ khoá nhận diện:

"cache hit thấp" → khoá cache quá chi tiết, và TTL quá ngắn "cần header ở origin nhưng không muốn biến thể cache" → origin request policy "nội dung mới không hiện ra" → invalidation, hoặc tên tệp có mã băm "phí origin cao" → tăng cache hit, và Origin Shield "nội dung động, không cache được" → TTL 0 nhưng vẫn hưởng đường trục AWS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ hit hiện tại | chỉ số CacheHitRate | | Vì sao miss | header X-Cache trong phản hồi, và x-edge-result-type trong access log | | Khoá cache đang gồm những gì | get-cache-policy |

Và một cách chẩn đoán rất nhanh khi tỉ lệ hit thấp: mở access log và nhóm theo URL đầy đủ kèm query string. Nếu bạn thấy cùng một tệp xuất hiện hàng trăm lần với các tham số theo dõi khác nhau, thủ phạm đã lộ diện — và cách sửa chỉ là loại những tham số đó khỏi khoá cache, không cần đụng tới bất kỳ thứ gì ở origin.

Đáp án

C — Chạy truy vấn CLOUDWATCH LOGS INSIGHTS dùng lệnh stats và hàm count.

Vì sao đúng

Log đã nằm sẵn trong CloudWatch Logs, và Logs Insights là công cụ truy vấn dành riêng cho chúng — truy vấn được nhiều log group cùng lúc.

⚠ Điểm mấu chốt — Logs Insights có ngôn ngữ truy vấn riêng:

fields @timestamp, @message
| filter @message like /ERROR/
| parse @message "ERROR: * -" as loaiLoi
| stats count(*) as soLuong by loaiLoi
| sort soLuong desc
        ↓
    stats ... by ...  → NHÓM và ĐẾM
        ↓
    Chọn NHIỀU log group cùng lúc
    → đúng yêu cầu "across all the log groups"

⚠ Vì sao nó hợp với Lambda:

Mỗi hàm Lambda ghi vào log group riêng
    /aws/lambda/<ten-ham>
        ↓
    Logs Insights chọn được nhiều log group
    bằng mẫu tên
        ↓
    → một truy vấn duy nhất bao quát
      toàn bộ ứng dụng
        ↓
    Và có sẵn các trường đặc thù của Lambda:
      @requestId, @duration, @billedDuration,
      @maxMemoryUsed, @initDuration

⚠ Các lệnh Logs Insights cần thuộc:

fields   → chọn trường hiển thị
filter   → lọc theo điều kiện
parse    → TÁCH trường từ văn bản log
stats    → NHÓM và tính toán
sort     → sắp xếp
limit    → giới hạn số dòng
        ↓
Hàm hay dùng:
  count(), sum(), avg(), min(), max(),
  percentile(), count_distinct()

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

• B (tìm kiếm CloudWatch Logs dùng từ khoá groupby và hàm count) — đây là phương án gần nhất và rất dễ nhầm, nhưng tính năng tìm kiếm cơ bản của CloudWatch Logs chỉ khớp chuỗi, không có groupby và không tổng hợp được. Từ khoá đúng là stats ... by ... trong Logs Insights.

• D (truy vấn Athena với SELECT và GROUP BY) — Athena truy vấn dữ liệu trên S3. Muốn dùng thì phải xuất log từ CloudWatch sang S3 trước — thêm một bước không cần thiết khi Logs Insights làm được ngay.

• A (truy vấn Amazon RDS) — log không nằm trong CSDL quan hệ nào.

Ghi nhớ

⚠ Công cụ truy vấn log — bảng phải thuộc: | Công cụ | Dữ liệu ở đâu | Dùng khi | |---|---|---| | CloudWatch Logs Insights | CloudWatch Logs | truy vấn nhanh, nhiều log group | | Athena | S3 | khối lượng RẤT lớn, log lịch sử, SQL | | OpenSearch | cụm OpenSearch | tìm kiếm toàn văn, dashboard phong phú | | Metric filter | CloudWatch Logs | biến mẫu log thành CHỈ SỐ để đặt alarm | | CloudWatch Logs search | CloudWatch Logs | chỉ khớp chuỗi, không tổng hợp |

Từ khoá nhận diện:

"đếm và nhóm log" → Logs Insights với stats ... by ... "log đã ở S3" → Athena "cảnh báo khi số lỗi vượt ngưỡng" → metric filter + alarm "tìm kiếm toàn văn, dashboard" → OpenSearch "log của nhiều tài khoản" → cross-account observability, hoặc gom về một nơi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn có đúng không | thử trên khoảng thời gian ngắn trước | | Có bỏ sót log group nào không | chọn theo mẫu tên, ví dụ /aws/lambda/ | | Có nên chuyển sang Athena không | nếu quét quá nhiều dữ liệu mỗi lần |

Và một thay đổi nhỏ ở phía ứng dụng làm mọi truy vấn về sau dễ hơn rất nhiều: ghi log dưới dạng JSON có cấu trúc. Khi ấy Logs Insights tự nhận ra từng trường và bạn viết được stats count(*) by errorType ngay lập tức — thay vì phải vật lộn với một biểu thức parse mỗi lần định dạng thông báo lỗi thay đổi một chút.

Đáp án

B — Chính sách định tuyến theo VỊ TRÍ ĐỊA LÝ (geolocation routing policy).

Vì sao đúng

Đề mô tả một yêu cầu theo vùng địa lý cụ thể: người dùng châu Âu đi tới eu-central-1, mọi người còn lại đi tới us-east-1.

⚠ Điểm mấu chốt — geolocation định tuyến theo VỊ TRÍ, không theo tốc độ:

Route 53 xem vị trí của người truy vấn DNS
        ↓
    Khớp theo: CHÂU LỤC / QUỐC GIA / BANG (chỉ Hoa Kỳ)
        ↓
    Cấu hình cho đề này:
      Continent = Europe  →  eu-central-1
      Default             →  us-east-1
        ↓
    → đúng hai quy tắc đề mô tả
    → "mọi người còn lại" chính là bản ghi DEFAULT

⚠ Bản ghi Default là bắt buộc phải có:

Không khai Default
        ↓
    Người dùng ở vùng chưa được khai
    → Route 53 KHÔNG TRẢ LỜI
    → client nhận NXDOMAIN
        ↓
    Và một số resolver không xác định
    được vị trí → cũng rơi vào Default
        ↓
    → thiếu Default là mất luôn
      những người dùng ngoài châu Âu

⚠ Vì sao KHÔNG chọn latency-based ở đây:

Latency-based routing
        ↓
    Chọn Region có ĐỘ TRỄ THẤP NHẤT đo được
        ↓
    → tối ưu HIỆU NĂNG
    → nhưng KHÔNG bảo đảm người châu Âu
      luôn về eu-central-1
        ↓
    Đề nói "crucial that European users are
    directed to eu-central-1"
        ↓
    → đây là yêu cầu VỊ TRÍ, mang tính
      quy định/kinh doanh
    → geolocation mới bảo đảm được

Xem thêm câu #11855 (lô 128): cũng chọn geolocation routing, ở đó kết hợp thêm DNS failover với health check gắn vào alarm của ALB. Khoá nhất quán.

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

• C (geoproximity routing policy) — đây là phương án gần nhất và cũng dựa trên địa lý, nhưng nó định tuyến theo KHOẢNG CÁCH tới tài nguyên, có thêm bias để kéo giãn hoặc thu hẹp vùng phục vụ. Nó không khai được theo châu lục hay quốc gia, nên không diễn đạt được ràng buộc "người châu Âu" một cách rõ ràng. (Và nó đòi bật Route 53 Traffic Flow.)

• A (latency routing policy) — tối ưu độ trễ, không bảo đảm ràng buộc theo vùng.

• D (multivalue answer routing policy) — trả về nhiều bản ghi khoẻ mạnh một cách ngẫu nhiên, hoàn toàn không xét vị trí.

Ghi nhớ

⚠ Bảy kiểu định tuyến Route 53 — bảng phải thuộc: | Kiểu | Dùng khi | |---|---| | Simple | một bản ghi, không điều kiện | | Weighted | chia theo TỈ LỆ — canary, A/B testing | | Latency-based | Region có ĐỘ TRỄ THẤP NHẤT — tối ưu hiệu năng | | Geolocation | theo VỊ TRÍ người dùng — tuân thủ, nội dung theo vùng | | Geoproximity | theo KHOẢNG CÁCH, có bias | | Failover | chính / dự phòng (active-passive) | | Multivalue answer | trả nhiều IP khoẻ mạnh |

Từ khoá nhận diện:

"người dùng ở CHÂU ÂU phải về Region châu Âu" → geolocation "độ trễ thấp nhất", "hiệu năng tốt nhất" → latency-based "dữ liệu phải ở lại trong nước" → geolocation, BẮT BUỘC "kéo giãn vùng phục vụ của một Region" → geoproximity với bias "chia 10% sang phiên bản mới" → weighted

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng vùng X nhận gì | test-dns-answer với --resolver-ip của vùng đó | | Có bản ghi Default không | list-resource-record-sets — tìm GeoLocation: {CountryCode: "*"} | | Failover có chạy không | tắt tạm target ở một Region, xem DNS đổi |

Và một cấu hình rất dễ quên khi dùng geolocation: luôn tạo bản ghi Default. Route 53 chỉ trả lời cho những vị trí khớp một quy tắc cụ thể — người dùng ở một quốc gia bạn chưa khai, hoặc một resolver mà Route 53 không xác định được vị trí, sẽ nhận NXDOMAIN thay vì được đưa về Region mặc định. Đây là loại lỗi chỉ lộ ra khi có người dùng thật ở đúng vùng bạn chưa nghĩ tới.

Đáp án

A — Cấu hình chế độ UNLIMITED cho các instance.

Vì sao đúng

Đề có một triệu chứng rất đặc trưng, và nó chỉ có một lời giải thích: CPU thấp (<30%) mà hiệu năng vẫn kém, và Auto Scaling không kích hoạt.

⚠ Điểm mấu chốt — instance burstable chạy bằng CPU CREDIT:

Họ T (t2, t3, t3a, t4g) là BURSTABLE
        ↓
    Mỗi instance có một mức CPU CƠ SỞ
      (ví dụ t3.medium: 20% mỗi vCPU)
        ↓
    Chạy DƯỚI mức cơ sở → TÍCH LUỸ credit
    Chạy TRÊN mức cơ sở → TIÊU credit
        ↓
    HẾT CREDIT (chế độ standard)
        ↓
    → CPU bị GIỚI HẠN CỨNG về mức cơ sở
    → máy chậm hẳn
    → nhưng CloudWatch báo CPU ~20-30%
      vì đó là TRẦN mới, không phải mức nhàn rỗi
        ↓
    → ASG không thấy CPU > 60% → KHÔNG co giãn
    → đúng y hệt mô tả của đề

⚠ Vì sao triệu chứng xuất hiện "vài giờ sau khi bắt đầu":

Khuyến mãi gửi đi → tải tăng
        ↓
    Vài giờ đầu: còn credit tích luỹ
    → máy chạy nhanh, mọi thứ bình thường
        ↓
    Credit cạn dần rồi HẾT
        ↓
    → đúng lúc "a couple of hours into these events"
    → người dùng bắt đầu báo chậm
        ↓
    Đây là dấu vân tay của bài toán CPU credit

⚠ Chế độ Unlimited giải quyết thế nào:

Unlimited mode
        ↓
    Khi hết credit, instance VẪN chạy trên
    mức cơ sở
        ↓
    Phần vượt được tính thành SURPLUS CREDIT
        ↓
    - Bù lại bằng credit tích luỹ trong 24 giờ tới,
      hoặc
    - Bị TÍNH THÊM TIỀN theo giờ vCPU
        ↓
    → không bao giờ bị bóp CPU nữa
    → mặc định đã BẬT với t3/t3a/t4g,
      nhưng t2 thì mặc định là standard

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

• B (tạo CloudFront distribution cho Auto Scaling group) — đây là phương án gần nhất và giảm tải thật nếu có nhiều nội dung tĩnh, nhưng nó không chạm tới nguyên nhân gốc: máy vẫn bị bóp CPU khi hết credit, và mọi request động vẫn chậm.

• C (thêm ELB và bật health check của ELB) — đề đã có Auto Scaling group; health check không liên quan tới hiệu năng CPU.

• D (dùng instance tối ưu cho EBS) — EBS-optimized cải thiện I/O của đĩa, không liên quan tới CPU credit. Và hầu hết loại máy hiện nay đã EBS-optimized mặc định.

Ghi nhớ

⚠ Instance burstable — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Họ máy | t2, t3, t3a, t4g | | Cơ chế | CPU credit — chạy dưới mức cơ sở thì tích, trên thì tiêu | | Standard mode | hết credit → BỊ BÓP về mức cơ sở | | Unlimited mode | vẫn chạy nhanh, tính thêm tiền nếu cần | | Mặc định | t2: standard; t3/t3a/t4g: unlimited | | Chỉ số cần theo dõi | CPUCreditBalance, CPUSurplusCreditBalance |

Từ khoá nhận diện:

"CPU thấp mà vẫn chậm, ASG không co giãn" → CẠN CPU CREDIT "chậm sau vài giờ tải cao" → credit cạn dần "instance họ T" → luôn nghĩ tới CPU credit "tải ổn định và cao" → chuyển sang họ M hoặc C "cần biết trước khi hết credit" → alarm trên CPUCreditBalance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị cạn credit không | vẽ CPUCreditBalance trong khung giờ sự cố | | Đang ở chế độ nào | describe-instance-credit-specifications | | Có bị tính thêm tiền không | CPUSurplusCreditsCharged, và Cost Explorer |

Và một bài học rút ra từ chính triệu chứng của đề: chỉ số CPU thấp không có nghĩa là máy đang nhàn rỗi. Với instance burstable, con số 25% có thể là trần cứng mà máy không được phép vượt qua — và mọi chính sách co giãn dựa trên CPU sẽ mù hoàn toàn trước tình trạng đó. Đây cũng là lý do nhiều đội chọn ALBRequestCountPerTarget làm chỉ số co giãn: nó phản ánh tải thật, không phụ thuộc vào việc CPU có đang bị bóp hay không.