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

Đáp án

A — Dùng Network Load Balancer cùng Auto Scaling group.

Vì sao đúng

Đề nêu yêu cầu quyết định: cho phép ĐỊA CHỈ IP trong tường lửa của khách hàng.

"clients need to be able to WHITELIST specific IP addresses"
        ↓
    Cần địa chỉ IP TĨNH và ỔN ĐỊNH
        ↓
    NLB là load balancer DUY NHẤT có Elastic IP tĩnh

Gán Elastic IP cho NLB:

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

Một Elastic IP cho MỖI AZ
    → khách hàng cho phép cả hai địa chỉ đó
    → IP KHÔNG BAO GIỜ đổi

Và ASG lo phần co giãn:

NLB:  điểm vào có IP tĩnh
ASG:  thêm bớt instance theo tải
        ↓
    Máy phía sau thay đổi liên tục
    → nhưng IP mà khách hàng thấy KHÔNG đổi

Và NLB là lựa chọn phù hợp cho API tần suất cao: | Đặc điểm | Chi tiết | |---|---| | Hàng triệu request mỗi giây | | | Độ trễ ~100 micro giây | thấp hơn ALB đáng kể | | Giữ IP nguồn của client | với target type instance |

Đăng ký ASG vào target group:

aws autoscaling attach-load-balancer-target-groups   --auto-scaling-group-name asg-api   --target-group-arns <arn-target-group>

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

• **B. Dùng Application Load Balancer cùng ASG — đây là phương án gần nhất và là lựa chọn mặc định cho ứng dụng HTTP, nhưng nó KHÔNG có IP tĩnh: ALB chỉ cho tên DNS, và IP phía sau thay đổi khi AWS co giãn hoặc bảo trì. Không đưa vào danh sách trắng được.
• **C. Dùng Auto Scaling group với Elastic IP cho từng instance — không dùng được: mỗi khi ASG thêm máy mới, sẽ có IP mới mà khách hàng chưa cho phép. Và Elastic IP có hạn mức mặc định 5 mỗi Region.
• **D. Dùng Route 53 với health check trỏ tới các instance — cùng vấn đề: IP thay đổi mỗi khi ASG thay máy, và khách hàng phải cập nhật danh sách liên tục.

Ghi nhớ

Địa chỉ IP của các load balancer — bảng phải thuộc: | Load balancer | Địa chỉ IP | |---|---| | Application Load Balancer | ĐỘNG — CHỈ tên DNS | | Network Load Balancer | Elastic IP TĨNH (một mỗi AZ) ← câu này | | Gateway Load Balancer | qua endpoint | | Global Accelerator | 2 IP anycast TĨNH, TOÀN CẦU |

Hai giải pháp cho yêu cầu IP tĩnh: | Giải pháp | Khi nào | |---|---| | NLB với Elastic IP | một Region ← câu này | | Global Accelerator | nhiều Region, hoặc muốn CHỈ 2 IP |

Global Accelerator đáng cân nhắc nếu mở rộng ra nhiều Region:

NLB: 1 Elastic IP mỗi AZ, mỗi Region
    → 3 AZ × 3 Region = 9 IP phải cho phép

Global Accelerator: 2 IP anycast cho TẤT CẢ
    → khách hàng chỉ cho phép 2 địa chỉ

ALB và NLB — bảng phân biệt: | | ALB | NLB | |---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | | IP tĩnh | ❌ | ✅ Elastic IP | | Định tuyến theo đường dẫn/host | ✅ | ❌ | | WAF | ✅ | ❌ | | Hiệu năng | cao | cực cao, độ trễ micro giây | | Giữ IP nguồn | qua X-Forwarded-For | ✅ nguyên bản | | Xác thực (Cognito, OIDC) | ✅ | ❌ |

Từ khoá nhận diện:

"static IP", "whitelist", "UDP", "extreme performance", "millions of requests" → NLB "path-based routing", "host-based", "WAF", "authentication" → ALB

Ba loại target type của NLB: | Loại | Định tuyến bằng | Giữ IP nguồn | |---|---|---| | instance | IP riêng chính của ENI | ✅ | | ip | địa chỉ IP bạn khai | ❌ (trừ khi bật) | | alb | ALB làm target — kết hợp cả hai | qua header |

Target type alb cho phép có cả hai:

Client → NLB (IP tĩnh) → ALB (định tuyến theo đường dẫn) → target
        ↓
    Vừa có IP tĩnh cho danh sách trắng
    vừa có tính năng tầng 7 của ALB

Đây là mẫu rất hữu ích khi cần cả hai.

Ba đặc điểm của Elastic IP: | Đặc điểm | Chi tiết | |---|---| | Tĩnh, giữ được qua stop/start | | | Hạn mức mặc định 5 mỗi Region | yêu cầu nâng được | | Tính phí khi KHÔNG gắn vào đâu | ~0,005 USD/giờ |

Từ tháng 2/2024, mọi IPv4 công cộng đều tính phí kể cả khi đang dùng.

Ba lưu ý về cross-zone của NLB: | Lưu ý | Chi tiết | |---|---| | Mặc định TẮT | khác ALB | | Bật thì tính phí truyền chéo AZ | | | Tắt thì số target mỗi AZ phải cân bằng | tránh phân phối lệch |

Ba lưu ý về health check của NLB: | Lưu ý | Chi tiết | |---|---| | Mặc định là TCP | chỉ kiểm tra cổng mở | | Nên đổi sang HTTP/HTTPS | kiểm tra ứng dụng thật | | Ngưỡng khoẻ và hỏng đều mặc định 3 | |

Kiểm tra TCP là chưa đủ:

Cổng 8080 mở nhưng ứng dụng đã treo
    → TCP health check vẫn báo khoẻ
    → NLB tiếp tục gửi lưu lượng tới máy hỏng
        ↓
    Health check HTTP tới endpoint thật mới phát hiện được

Ba lưu ý về bảo mật với NLB: | Lưu ý | Chi tiết | |---|---| | NLB nay HỖ TRỢ security group | tính năng mới từ 2023 | | WAF KHÔNG gắn được vào NLB | dùng ALB phía sau nếu cần | | Giữ IP nguồn nghĩa là SG của target thấy IP CLIENT | |

Dòng cuối là chi tiết quan trọng:

NLB target type `instance` giữ IP nguồn
    → security group của target phải cho phép IP CỦA CLIENT
    → KHÔNG phải IP của NLB
        ↓
    Cấu hình sai chỗ này làm mọi kết nối bị chặn

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ActiveFlowCount | số kết nối đang mở | | HealthyHostCount theo AZ | phát hiện lệch | | TCP_Target_Reset_Count | target đóng kết nối bất thường |

Ba việc nên làm khi khách hàng dùng danh sách trắng: | Việc | Chi tiết | |---|---| | Ghi rõ các IP vào tài liệu | | | Báo trước rất lâu nếu buộc phải đổi | | | Cân nhắc Global Accelerator để ổn định lâu dài | |

Và một lời khuyên: hãy cấp phát Elastic IP ở mọi AZ ngay từ đầu, kể cả AZ chưa dùng. Thêm một AZ sau này nghĩa là thêm một IP mà mọi khách hàng phải cập nhật trong tường lửa của họ — và với một số tổ chức, quy trình đó mất hàng tuần.

Đáp án

B — Chuyển volume của cả hai instance từ io1 sang gp2.

Vì sao đúng

Đề cho hai instance với mẫu dùng khác nhau nhưng cùng một kết luận: | Instance | Cấu hình | Mức dùng thật | |---|---|---| | A | io1 với 20.000 IOPS đã cấp | thỉnh thoảng lên tới 15.000, mức nền THẤP | | B | io1 với 60.000 IOPS đã cấp | thỉnh thoảng lên tới 30.000, mức nền THẤP |

Cả hai đều cấp phát QUÁ MỨC:

Instance A: trả tiền cho 20.000, dùng tới 15.000 và chỉ thỉnh thoảng
Instance B: trả tiền cho 60.000, dùng tới 30.000 — thừa một nửa
        ↓
    io1 tính phí theo IOPS ĐÃ CẤP, dùng hay không cũng trả

Và gp2 phù hợp với mẫu "nền thấp, thỉnh thoảng bùng phát":

gp2:
    → baseline 3 IOPS mỗi GB
    → TÍCH LUỸ credit khi dùng dưới baseline
    → BÙNG PHÁT tới 16.000 IOPS khi cần
        ↓
    Đúng mẫu dùng trong đề: nền thấp, đợt cao ngắn

Và chênh lệch giá rất lớn:

io1: ~0,125 USD/GB-tháng + ~0,065 USD mỗi IOPS-tháng
gp2: ~0,10 USD/GB-tháng, KHÔNG tính phí IOPS riêng
        ↓
    60.000 IOPS trên io1 ≈ 3.900 USD/tháng chỉ riêng phần IOPS

Chuyển đổi trực tuyến, không cần ngừng:

aws ec2 modify-volume --volume-id vol-0abc --volume-type gp2
aws ec2 describe-volumes-modifications --volume-ids vol-0abc

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

• **A. Chuyển cả hai sang instance store — đây là phương án gần nhất về mặt hiệu năng (instance store nhanh nhất), nhưng nó KHÔNG BỀN VỮNG: dữ liệu mất khi instance dừng hoặc phần cứng hỏng. Và dung lượng cố định theo loại instance, không đổi được.
• **C. Chuyển A sang instance store, giữ B ở io1 — vẫn có vấn đề mất dữ liệu của instance store, và giữ B ở io1 nghĩa là tiếp tục trả tiền cho 60.000 IOPS trong khi chỉ dùng tới 30.000.
• **D. Chuyển B sang instance store, giữ A ở io1 — cùng hai vấn đề, chỉ đổi vai trò.

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

Câu này phản ánh danh mục volume trước khi có gp3, và gp3 mới là đáp án đúng ngày nay.

AWS ra mắt gp3 từ cuối 2020, và nó tốt hơn gp2 ở gần như mọi mặt: | | gp2 | gp3 | |---|---|---| | Giá lưu trữ | ~0,10 USD/GB-tháng | ~0,08 USD/GB-tháng (rẻ hơn 20%) | | IOPS baseline | 3 IOPS/GB (phụ thuộc dung lượng) | 3.000 IOPS MIỄN PHÍ bất kể dung lượng | | IOPS tối đa | 16.000 | 16.000 | | Thông lượng | 250 MB/giây | 125 MB/giây cơ bản, tới 1.000 MB/giây | | Cấu hình IOPS độc lập với dung lượng | ❌ | ✅ | | Cơ chế credit | có (phức tạp) | không có |

gp3:
    ✓ RẺ HƠN gp2 khoảng 20% cho cùng dung lượng
    ✓ 3.000 IOPS đảm bảo, KHÔNG cần credit
    ✓ tăng IOPS mà không phải tăng dung lượng
        ↓
    AWS khuyến nghị gp3 làm mặc định cho mọi tải mục đích chung

Điểm yếu của gp2 là cơ chế credit: volume nhỏ có baseline thấp, và khi hết credit thì tụt về baseline giữa lúc đang cần. gp3 bỏ hẳn cơ chế này.

(Đáp án B vẫn đúng theo các phương án cho sẵn — gp3 không có trong danh sách.)

Ghi nhớ

Các loại EBS volume — bảng phải thuộc: | Loại | IOPS tối đa | Phù hợp | |---|---|---| | gp3 | 16.000 | mặc định khuyến nghị | | gp2 | 16.000 | thế hệ trước | | io1 | 64.000 | IOPS cao, thế hệ trước | | io2 | 64.000 | độ bền 99,999% | | io2 Block Express | 256.000 | cao nhất | | st1 | thông lượng 500 MB/giây | dữ liệu tuần tự lớn | | sc1 | thông lượng 250 MB/giây | lưu trữ lạnh |

Ba nhóm theo mục đích: | Nhóm | Loại | |---|---| | SSD mục đích chung | gp3, gp2 | | SSD IOPS cao | io2, io1 | | HDD | st1 (thông lượng), sc1 (lạnh) |

Từ khoá nhận diện:

"general purpose", "cost-effective", "moderate IOPS" → gp3 "sustained high IOPS", "critical database" → io2 "big data, sequential, throughput" → st1 "lowest cost, rarely accessed" → sc1

Ba đặc điểm quan trọng của instance store: | Đặc điểm | Chi tiết | |---|---| | Hiệu năng cao nhất | gắn trực tiếp vào máy chủ vật lý | | KHÔNG BỀN VỮNG | mất khi stop, hibernate hoặc hỏng phần cứng | | Không đổi kích thước | theo loại instance |

Instance store phù hợp cho:

✓ bộ đệm, dữ liệu tạm
✓ dữ liệu tái tạo được (bản sao từ nguồn khác)
✓ scratch space cho xử lý
        ↓
    KHÔNG bao giờ dùng cho dữ liệu duy nhất

Ba cách tối ưu chi phí EBS: | Cách | Tiết kiệm | |---|---| | Chuyển gp2 sang gp3 | ~20% | | Bỏ io1/io2 nếu không cần IOPS cao liên tục | rất nhiều | | Xoá volume và snapshot không dùng | |

Chuyển gp2 sang gp3 hàng loạt:

aws ec2 describe-volumes --filters Name=volume-type,Values=gp2   --query 'Volumes[].VolumeId' --output text |   xargs -n1 -I{} aws ec2 modify-volume --volume-id {} --volume-type gp3

Ba metric để đánh giá volume: | Metric | Ý nghĩa | |---|---| | VolumeReadOps + VolumeWriteOps | IOPS thực tế | | BurstBalance | chỉ gp2 — về 0 là tụt về baseline | | VolumeQueueLength | cao liên tục = thiếu IOPS |

VolumeQueueLength là chỉ báo tốt nhất:

Queue length thường xuyên trên 1 mỗi 1.000 IOPS
    → volume không theo kịp
    → cần tăng IOPS
        ↓
    Queue length gần 0 mà IOPS cấp cao
    → đang trả tiền thừa ← tình huống trong đề

Ba thao tác đổi volume trực tuyến: | Thao tác | Có ngừng | |---|---| | Tăng dung lượng | ❌ (phải mở rộng file system sau) | | Đổi loại volume | ❌ | | Đổi IOPS/thông lượng | ❌ | | Giảm dung lượng | KHÔNG làm được |

Sau khi tăng dung lượng phải mở rộng file system:

sudo growpart /dev/nvme0n1 1
sudo resize2fs /dev/nvme0n1p1      # ext4
sudo xfs_growfs /                   # xfs

Ba lưu ý về thay đổi volume: | Lưu ý | Chi tiết | |---|---| | Phải chờ 6 giờ giữa hai lần đổi | trên cùng volume | | Volume ở trạng thái optimizing | hiệu năng có thể giảm tạm thời | | Không giảm được dung lượng | phải tạo volume mới và sao chép |

Ba công cụ phân tích: | Công cụ | Việc | |---|---| | AWS Compute Optimizer | khuyến nghị loại volume theo mức dùng thật | | Cost Explorer | chi phí theo loại volume | | CloudWatch | metric IOPS và thông lượng |

Compute Optimizer phân tích rất đúng cho tình huống này:

Nó xem 14 ngày metric và nói:
    "volume này cấp 60.000 IOPS, đỉnh thật 30.000
     → chuyển sang gp3, tiết kiệm X USD/tháng"

Và một lời khuyên: hãy bật AWS Compute Optimizer và xem mục EBS volume. Với io1 và io2, việc cấp phát quá mức là chuyện rất phổ biến — và vì tiền IOPS được tính riêng, khoản lãng phí thường lớn hơn nhiều so với phần dung lượng lưu trữ mà mọi người hay chú ý.

Đáp án

A, B và C.

• A — Dùng Lambda Layers cho thư viện dùng chung giữa nhiều hàm
• B — Lambda trong VPC truy cập Internet cần NAT Gateway hoặc NAT instance
• C — Tạo CloudWatch alarm cho ConcurrentExecutions và Invocations để phát hiện lỗi

Vì sao đúng

A — Lambda Layers là cơ chế chia sẻ:

Nhiều hàm dùng chung thư viện:
    → đóng gói thư viện thành LAYER
    → nhiều hàm cùng tham chiếu layer đó
        ↓
    ✓ gói triển khai của mỗi hàm nhỏ hơn
    ✓ cập nhật thư viện một chỗ
    ✓ tối đa 5 layer mỗi hàm

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

aws lambda update-function-configuration --function-name xu-ly   --layers arn:aws:lambda:ap-northeast-1:123456789012:layer:thu-vien-chung:1

B — Lambda trong VPC KHÔNG có Internet trực tiếp:

Lambda gắn vào VPC:
    → ENI trong PRIVATE subnet
    → KHÔNG có IP công cộng
        ↓
    Muốn ra Internet: PRIVATE subnet → NAT Gateway → Internet Gateway

⚠ Đặt Lambda vào PUBLIC subnet KHÔNG cho nó ra Internet
    → vì ENI của Lambda không được gán IP công cộng

Đây là hiểu lầm rất phổ biến.

C — hai metric này phát hiện được lỗi thật:

ConcurrentExecutions gần trần tài khoản:
    → hàm bắt đầu bị throttle
    → request bị từ chối

Invocations giảm đột ngột:
    → nguồn kích hoạt đã hỏng
    → sự cố mà không có lỗi nào được ghi

aws cloudwatch put-metric-alarm --alarm-name lambda-gan-tran   --metric-name ConcurrentExecutions --namespace AWS/Lambda   --statistic Maximum --period 60 --threshold 900   --comparison-operator GreaterThanThreshold --evaluation-periods 1

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

• **D. "Gói triển khai càng lớn thì cold start càng chậm, do đó AWS khuyến nghị đóng gói phụ thuộc thành gói RIÊNG với gói Lambda" — đây là phương án gần nhất vì vế đầu hoàn toàn đúng, nhưng vế sau diễn đạt sai khuyến nghị của AWS: AWS khuyến nghị giảm kích thước gói triển khai xuống mức tối thiểu cần thiết, và Layers dùng để tái sử dụng giữa nhiều hàm (đã là đáp án A). "Tách phụ thuộc thành gói riêng" không làm giảm tổng khối lượng phải nạp.
• **E. "AWS khuyến nghị cấp thừa thời gian timeout" — ngược với khuyến nghị thật: AWS khuyến nghị đặt timeout sát với thời gian chạy thực tế. Timeout quá dài khiến hàm treo tiêu tốn tài nguyên và tiền lâu hơn cần thiết, và làm chậm việc phát hiện sự cố.
• **F. "KHÔNG đóng gói Lambda thành container image được" — sai về mặt kỹ thuật: từ tháng 12/2020, Lambda hỗ trợ container image tới 10 GB, gấp nhiều lần giới hạn 250 MB của gói ZIP.

Ghi nhớ

Ba giới hạn kích thước của Lambda — bảng phải thuộc: | Giới hạn | Giá trị | |---|---| | Gói ZIP tải trực tiếp | 50 MB (nén) | | Gói ZIP qua S3 | 250 MB (giải nén, gồm cả layer) | | Container image | 10 GB |

Ba giới hạn thời gian và bộ nhớ: | Giới hạn | Giá trị | |---|---| | Thời gian chạy tối đa | 15 phút | | Bộ nhớ | 128 MB – 10.240 MB | | /tmp | 512 MB – 10.240 MB |

Và bộ nhớ quyết định cả CPU:

Tăng bộ nhớ → tăng CPU tỷ lệ thuận
    → hàm tính toán nhiều chạy nhanh hơn
    → có khi RẺ HƠN dù giá mỗi mili giây cao hơn
        ↓
    Dùng AWS Lambda Power Tuning để tìm điểm tối ưu

Ba cách giảm cold start: | Cách | Chi tiết | |---|---| | Giảm kích thước gói | ít thứ phải nạp | | Provisioned Concurrency | giữ sẵn môi trường — cold start gần như bằng 0 | | SnapStart (Java, .NET, Python) | chụp ảnh môi trường đã khởi tạo |

Ba đặc điểm của Lambda trong VPC: | Đặc điểm | Chi tiết | |---|---| | Cần NAT Gateway để ra Internet | ← đáp án B | | Hyperplane ENI dùng chung | cold start do VPC nay không đáng kể | | Dùng VPC endpoint cho dịch vụ AWS | rẻ hơn NAT |

VPC endpoint tiết kiệm đáng kể:

Lambda trong VPC gọi S3, DynamoDB:
    Qua NAT Gateway:  ~0,045 USD/giờ + 0,045 USD/GB
    Qua Gateway endpoint: MIỄN PHÍ
        ↓
    Gateway endpoint cho S3 và DynamoDB nên luôn có

Ba loại concurrency: | Loại | Chi tiết | |---|---| | Unreserved | dùng chung hạn mức tài khoản (mặc định 1.000) | | Reserved | dành riêng cho một hàm, đồng thời là TRẦN của hàm đó | | Provisioned | môi trường khởi tạo sẵn, có phí riêng |

Reserved concurrency có hai tác dụng:

① Đảm bảo hàm quan trọng luôn có chỗ
② GIỚI HẠN hàm đó không chiếm hết hạn mức tài khoản
        ↓
    Đặt reserved = 0 để TẠM DỪNG một hàm

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Throttles | bị từ chối do hết concurrency | | Errors và DeadLetterErrors | lỗi thực thi | | Duration so với timeout | gần timeout là dấu hiệu xấu | | ConcurrentExecutions | gần trần tài khoản ← đáp án C |

Ba nguyên tắc đặt timeout: | Nguyên tắc | Chi tiết | |---|---| | Sát thời gian chạy thực tế + biên an toàn | | | KHÔNG cấp thừa | ← lý do phương án E sai | | Đo P99 rồi cộng thêm | |

Ba lý do timeout dài có hại:

① Hàm treo chạy đủ timeout mới dừng → tốn tiền
② Chậm phát hiện sự cố
③ Với API Gateway (trần 29 giây), timeout dài hơn là vô nghĩa

Ba đặc điểm của Lambda Layers: | Đặc điểm | Chi tiết | |---|---| | Tối đa 5 layer mỗi hàm | | | Tính vào giới hạn 250 MB | | | Chia sẻ được giữa các tài khoản | |

Ba trường hợp nên dùng container image thay ZIP: | Trường hợp | Lý do | |---|---| | Gói lớn hơn 250 MB | ← lý do chính | | Đã có pipeline container | dùng lại công cụ sẵn có | | Cần thư viện hệ thống phức tạp | |

Ba cách xử lý lỗi: | Cách | Chi tiết | |---|---| | Dead letter queue | SQS hoặc SNS nhận sự kiện thất bại | | Lambda Destinations | đích riêng cho thành công và thất bại | | Retry tự động | 2 lần cho lời gọi bất đồng bộ |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Execution role theo quyền tối thiểu | | | Bí mật trong Secrets Manager | không đặt trong biến môi trường thô | | Mã hoá biến môi trường bằng KMS | |

Và một lời khuyên: hãy đặt alarm cho Throttles trước cả Errors. Throttle không sinh ra lỗi trong mã của bạn — request đơn giản bị từ chối ở tầng Lambda — nên nó là loại sự cố dễ diễn ra âm thầm nhất, và thường chỉ được phát hiện khi người dùng phàn nàn.

Đáp án

C — Bật caching ở tầng API Gateway cho các endpoint đó, đặt TTL 24 giờ.

Vì sao đúng

Đề nêu ba yêu cầu, và caching của API Gateway đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Chấp nhận dữ liệu cũ tới 24 giờ | TTL 24 giờ | | Giảm lời gọi Lambda và truy vấn DynamoDB | request trúng cache KHÔNG gọi backend | | Thay đổi TỐI THIỂU với kiến trúc hiện có | một công tắc trên stage, KHÔNG sửa mã |

Vế thứ ba là điểm phân biệt quyết định:

API Gateway caching:
    → bật ở cấp STAGE
    → không sửa một dòng mã Lambda nào
    → không thêm dịch vụ nào vào kiến trúc
        ↓
    Đúng "minimal changes to the existing architecture"

Bật cache:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod   --patch-operations     op=replace,path=/cacheClusterEnabled,value=true     op=replace,path=/cacheClusterSize,value=0.5

Và đặt TTL cho từng method:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod   --patch-operations     op=replace,path=/~1bao-cao/GET/caching/enabled,value=true     op=replace,path=/~1bao-cao/GET/caching/ttlInSeconds,value=86400

86400 giây = 24 giờ, đúng yêu cầu.

Và bật cache theo từng endpoint là quan trọng:

Chỉ bật cho endpoint dữ liệu ÍT ĐỔI
    → endpoint dữ liệu thời gian thực KHÔNG bật
        ↓
    Không làm hỏng phần còn lại của API

Kết quả về chi phí:

Request trúng cache:
    ✗ không gọi Lambda   → không tốn phí thực thi
    ✗ không đọc DynamoDB → không tốn RCU
    ✓ chỉ trả phí cache cluster theo giờ
        ↓
    Với dữ liệu 24 giờ mới đổi một lần, tỷ lệ trúng rất cao

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

• **A. Đặt CloudFront trước API Gateway với TTL 24 giờ — đây là phương án gần nhất và thực sự đệm được, nhưng nó thêm một dịch vụ vào kiến trúc: phải tạo distribution, cấu hình origin, xử lý tên miền và chứng chỉ. API Gateway đã có cache dựng sẵn, dùng nó là thay đổi tối thiểu hơn hẳn.
• **D. Dùng ElastiCache và sửa Lambda để kiểm tra cache trước — đòi SỬA MÃ: phải viết logic kiểm tra cache, nạp khi trượt, xử lý lỗi kết nối. Và Lambda vẫn được gọi mỗi request nên chỉ tiết kiệm phần DynamoDB.
• **B. Bật DynamoDB DAX — cũng chỉ tiết kiệm một phần: Lambda vẫn chạy mỗi request. Và DAX đòi Lambda phải nằm trong VPC (DAX chỉ truy cập được từ VPC), là thay đổi kiến trúc đáng kể.

Ghi nhớ

Bốn tầng đệm cho API serverless — bảng cần thuộc: | Tầng | Tiết kiệm được | Sửa mã | |---|---|---| | CloudFront | Lambda + DynamoDB + API Gateway | ❌ | | API Gateway cache | Lambda + DynamoDB | ❌ ← câu này | | ElastiCache trong Lambda | chỉ DynamoDB | ✅ | | DAX | chỉ DynamoDB | ít |

Quy tắc: đệm càng gần client càng tiết kiệm nhiều.

Từ khoá nhận diện:

"minimal changes", "API Gateway already exists" → API Gateway cache "global users", "reduce latency worldwide" → CloudFront "need rich data structures" → ElastiCache

Ba đặc điểm của API Gateway cache: | Đặc điểm | Chi tiết | |---|---| | Bật ở cấp STAGE | rồi tinh chỉnh theo method | | TTL 0–3600 giây mặc định, tối đa 3600 | | | Kích thước 0,5 GB – 237 GB | |

Lưu ý quan trọng về TTL tối đa:

API Gateway cache TTL tối đa là 3600 giây (1 giờ)
    → KHÔNG đặt được 86400 giây trực tiếp
        ↓
    Với yêu cầu 24 giờ, cần CloudFront phía trước
    hoặc chấp nhận làm mới mỗi giờ

(Đề chấp nhận "up to 24 hours old" — dữ liệu làm mới mỗi giờ vẫn thoả điều kiện đó, chỉ là không tận dụng hết mức cho phép.)

Ba tham số của cache key: | Tham số | Chi tiết | |---|---| | Query string | khai cái nào tham gia cache key | | Header | ví dụ Accept-Language | | Path parameter | |

Cache key sai gây hai vấn đề:

Quá ít tham số: người dùng A thấy dữ liệu của người dùng B
Quá nhiều tham số: tỷ lệ trúng cache thấp
        ↓
    Chỉ đưa vào tham số THỰC SỰ làm đổi kết quả

Ba cách vô hiệu hoá cache: | Cách | Chi tiết | |---|---| | Chờ TTL hết hạn | đơn giản nhất | | Header Cache-Control: max-age=0 | cần quyền IAM execute-api:InvalidateCache | | Flush toàn bộ cache của stage | |

aws apigateway flush-stage-cache --rest-api-id abc123 --stage-name prod

Ba lưu ý về bảo mật cache: | Lưu ý | Chi tiết | |---|---| | Mã hoá dữ liệu cache | tuỳ chọn, nên bật | | KHÔNG đệm dữ liệu riêng tư theo người dùng | trừ khi cache key gồm định danh | | Giới hạn quyền vô hiệu hoá cache | tránh bị lạm dụng |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Cache tính theo GIỜ theo kích thước | 0,5 GB ~0,02 USD/giờ | | Tiết kiệm phí Lambda và DynamoDB | thường bù lại nhiều lần | | Đo tỷ lệ trúng để đánh giá | |

Ba metric của API Gateway: | Metric | Ý nghĩa | |---|---| | CacheHitCount | số request được phục vụ từ cache | | CacheMissCount | | | Latency | giảm rõ khi cache hiệu quả |

Tính tỷ lệ trúng:

CacheHitCount / (CacheHitCount + CacheMissCount)
    → dưới 50% với dữ liệu ít đổi: cache key quá chi tiết

Hai loại API Gateway — bảng phân biệt: | | REST API | HTTP API | |---|---|---| | Cache dựng sẵn | ✅ | ❌ | | Giá | cao hơn | rẻ hơn ~70% | | Tính năng | đầy đủ | tối giản | | WAF, usage plan | ✅ | ❌ |

HTTP API rẻ hơn nhưng KHÔNG có cache — đây là điểm cần biết khi chọn loại API.

Ba cách giảm chi phí API serverless: | Cách | Tiết kiệm | |---|---| | Đệm ở API Gateway hoặc CloudFront | ← câu này | | Tối ưu bộ nhớ Lambda | Power Tuning | | DynamoDB on-demand hoặc provisioned đúng mức | |

Ba lưu ý khi đệm dữ liệu báo cáo: | Lưu ý | Chi tiết | |---|---| | Xác nhận nghiệp vụ chấp nhận dữ liệu cũ | ← đề đã nói rõ | | Ghi rõ độ tươi trong phản hồi | header hoặc trường trong body | | Có cách buộc làm mới khi cần | |

Và một lời khuyên: hãy thêm một header cho biết dữ liệu được sinh lúc nào vào phản hồi. Với dữ liệu cũ tới 24 giờ, người dùng cần biết họ đang xem số liệu của thời điểm nào — và không có thông tin đó, một báo cáo cũ trông y hệt một báo cáo mới.

Đáp án

A — Rule host-based với *.example.com sẽ khớp test.example.com và CHỈ nó.

Vì sao đúng

Đây là bài toán về cách khớp ký tự đại diện của host condition trong ALB.

Mẫu: *.example.com
    → dấu * khớp MỘT NHÃN (label) bất kỳ ở vị trí đầu
    → và nhãn đó phải TỒN TẠI

Xét từng host trong đề: | Host | Khớp *.example.com? | Lý do | |---|---|---| | test.example.com | ✅ | test khớp * | | example.com | ❌ | không có nhãn con nào | | EXAMPLE.COM | ❌ | cùng lý do — không có nhãn con | | test.example.org | ❌ | tên miền gốc khác |

Vì sao example.com không khớp:

*.example.com đòi CÓ MỘT nhãn trước example.com
    → example.com KHÔNG có nhãn nào ở vị trí đó
        ↓
    Muốn khớp cả hai phải khai HAI điều kiện:
        example.com
        *.example.com

Đây là lỗi cấu hình rất phổ biến:

aws elbv2 create-rule --listener-arn <arn> --priority 10   --conditions '[{"Field":"host-header",
                  "HostHeaderConfig":{"Values":["example.com","*.example.com"]}}]'   --actions Type=forward,TargetGroupArn=<arn-tg>

Khai cả hai giá trị trong cùng một condition — chúng là quan hệ HOẶC.

Và về chữ hoa chữ thường:

Host condition của ALB KHÔNG phân biệt hoa thường
    → nếu mẫu là *.EXAMPLE.COM thì test.example.com vẫn khớp
        ↓
    EXAMPLE.COM không khớp là vì THIẾU NHÃN CON,
    không phải vì viết hoa

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

• **D. Khớp test.example.com và example.com — đây là phương án gần nhất và là điều nhiều người tưởng, nhưng * đòi phải có một nhãn: example.com không có nhãn con nên không khớp.
• **B. Khớp test.example.com và EXAMPLE.COM — cùng lỗi, chỉ khác cách viết hoa. Việc không khớp là do thiếu nhãn con, không phải do chữ hoa.
• **C. Khớp test.example.com và test.example.org — tên miền gốc khác hẳn: * chỉ thay cho nhãn đầu tiên, phần example.com phải khớp chính xác.

Ghi nhớ

Quy tắc ký tự đại diện trong host condition của ALB — bảng phải thuộc: | Mẫu | Khớp | KHÔNG khớp | |---|---|---| | *.example.com | a.example.com, test.example.com | example.com, a.b.example.com* | | example.com | example.com (không phân biệt hoa thường) | a.example.com | | *.*.example.com | a.b.example.com | a.example.com |

(Thực tế * của ALB có thể khớp nhiều nhãn trong một số trường hợp, nhưng quy tắc an toàn để nhớ là * thay cho một nhãn và nhãn đó phải tồn tại.)

Ba đặc điểm của host condition: | Đặc điểm | Chi tiết | |---|---| | KHÔNG phân biệt hoa thường | | | Tối đa 128 ký tự | | | Ký tự cho phép | chữ, số, -, ., *, ? |

? khớp đúng MỘT ký tự — ít dùng hơn *.

Bốn loại condition của ALB rule: | Loại | Ví dụ | |---|---| | host-header | *.example.com ← câu này | | path-pattern | /api/* | | http-header | header tuỳ ý | | query-string | ?version=2 | | source-ip | dải CIDR | | http-request-method | POST |

Ba lưu ý về thứ tự rule: | Lưu ý | Chi tiết | |---|---| | Đánh giá theo PRIORITY tăng dần | số nhỏ trước | | Rule ĐẦU TIÊN khớp sẽ thắng | không xét tiếp | | Default action chạy khi không rule nào khớp | |

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

Priority 10: *.example.com → target group A
Priority 20: api.example.com → target group B
        ↓
    api.example.com khớp rule 10 TRƯỚC
    → không bao giờ tới rule 20
        ↓
    Rule CỤ THỂ phải có priority NHỎ hơn rule tổng quát

Ba giới hạn của ALB rule: | Giới hạn | Giá trị | |---|---| | Số rule mỗi listener | 100 | | Số condition mỗi rule | 5 | | Số giá trị mỗi condition | 5 |

Ba lưu ý về chứng chỉ với tên miền đại diện: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ *.example.com KHÔNG bao gồm example.com | cùng quy tắc | | Phải thêm example.com vào SAN | | | ACM cho phép khai cả hai trong một chứng chỉ | |

aws acm request-certificate --domain-name example.com   --subject-alternative-names "*.example.com"   --validation-method DNS

Đây là cùng một cái bẫy ở tầng chứng chỉ — và nó gây lỗi TLS chứ không phải lỗi định tuyến.

Ba cách phục vụ nhiều tên miền trên một ALB: | Cách | Chi tiết | |---|---| | Host-based rule | ← câu này | | SNI với nhiều chứng chỉ | tối đa 25 chứng chỉ mỗi listener | | Nhiều listener trên cổng khác nhau | |

Ba loại action của rule: | Action | Việc | |---|---| | forward | chuyển tới target group | | redirect | chuyển hướng HTTP → HTTPS | | fixed-response | trả nội dung cố định | | authenticate-cognito, authenticate-oidc | xác thực |

Chuyển hướng HTTP sang HTTPS:

aws elbv2 create-rule --listener-arn <arn-http> --priority 1   --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/*"]}}]'   --actions '[{"Type":"redirect","RedirectConfig":
    {"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Ba cách kiểm chứng rule: | Cách | Việc | |---|---| | curl với header Host | thử trực tiếp | | Access log của ALB | xem target group nào nhận | | Console: xem rule theo thứ tự | |

curl -H "Host: test.example.com" http://<dns-cua-alb>/
curl -H "Host: example.com" http://<dns-cua-alb>/

Cách này thử được rule mà không cần đụng tới DNS.

Ba lưu ý khi thiết kế rule: | Lưu ý | Chi tiết | |---|---| | Khai cả tên miền gốc VÀ đại diện | ← bài học của câu này | | Rule cụ thể đứng trước rule tổng quát | | | Có default action hợp lý | thường là trang lỗi |

Và một lời khuyên: hãy thử cả tên miền gốc lẫn tên miền con bằng curl -H "Host: ..." sau khi tạo rule. Cái bẫy này im lặng — mọi thứ hoạt động cho tên miền con và không có lỗi nào cho tới khi ai đó gõ tên miền gốc và nhận về default action.

Đáp án

C và D.

• C — Cấu hình lifecycle chuyển tệp có tiền tố finance/statements/ sang S3 Standard-IA sau 45 ngày
• D — Chuyển mọi tệp sang S3 Glacier Flexible Retrieval sau 180 ngày

Vì sao đúng

Đề nêu hai quy tắc, và hai đáp án ánh xạ chính xác: | Quy tắc trong đề | Đáp án | |---|---| | Tệp finance/statements/: sau 45 ngày ít truy cập | C — Standard-IA cho tiền tố đó | | Mọi tệp sau 180 ngày: hiếm truy cập, có thể mất vài giờ để lấy | D — Glacier Flexible Retrieval |

Và "có thể chờ vài giờ" là chi tiết chọn đúng lớp Glacier:

"can tolerate a RETRIEVAL DELAY OF SEVERAL HOURS"
        ↓
    Glacier Flexible Retrieval:
        Standard retrieval: 3–5 giờ  ← khớp
        Bulk retrieval:     5–12 giờ

Và yêu cầu "chịu được mất một AZ" loại bỏ One Zone:

"data must remain RESILIENT IN THE EVENT OF AN AZ FAILURE"
        ↓
    One Zone-IA lưu ở CHỈ MỘT AZ
    → AZ đó hỏng là mất dữ liệu
        ↓
    Phải dùng Standard-IA (3 AZ trở lên)

Quy tắc lifecycle đầy đủ:

{"Rules": [
  {"ID": "bao-cao-tai-chinh-45-ngay",
   "Status": "Enabled",
   "Filter": {"Prefix": "finance/statements/"},
   "Transitions": [{"Days": 45, "StorageClass": "STANDARD_IA"}]},
  {"ID": "moi-thu-180-ngay",
   "Status": "Enabled",
   "Filter": {},
   "Transitions": [{"Days": 180, "StorageClass": "GLACIER"}]}]}

Hai quy tắc phối hợp với nhau:

Ngày 0–44:    Standard
Ngày 45–179:  Standard-IA (chỉ finance/statements/)
Ngày 180+:    Glacier Flexible Retrieval (mọi tệp)

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

• **A. Chuyển tệp finance/statements/ sang S3 One Zone-IA sau 45 ngày — đây là phương án gần nhất và rẻ hơn Standard-IA khoảng 20%, nhưng nó vi phạm yêu cầu chịu lỗi AZ: One Zone-IA chỉ lưu ở một AZ, đúng điều đề cấm.
• **E. Chuyển mọi tệp sang S3 Glacier Deep Archive sau 180 ngày — thời gian lấy quá lâu: Deep Archive mất 12 giờ (Standard) tới 48 giờ (Bulk). Đề nói "several hours", không nói "một tới hai ngày".
• **B. Chuyển tệp finance/statements/ sang S3 Intelligent-Tiering sau 45 ngày — không sai nhưng không tối ưu: Intelligent-Tiering dùng khi mẫu truy cập KHÔNG đoán trước được. Ở đây đề đã nói rõ sau 45 ngày là ít truy cập, nên chuyển thẳng sang Standard-IA rẻ hơn (không tốn phí giám sát mỗi object).

Ghi nhớ

Các lớp lưu trữ S3 — bảng phải thuộc: | Lớp | Số AZ | Thời gian lấy | Giá tham khảo | |---|---|---|---| | Standard | ≥3 | tức thì | ~0,023 USD/GB | | Intelligent-Tiering | ≥3 | tức thì | ~0,023 + phí giám sát | | Standard-IA | ≥3 | tức thì | ~0,0125 USD/GB | | One Zone-IA | 1 ⚠ | tức thì | ~0,01 USD/GB | | Glacier Instant Retrieval | ≥3 | mili giây | ~0,004 USD/GB | | Glacier Flexible Retrieval | ≥3 | 1 phút – 12 giờ | ~0,0036 USD/GB | | Glacier Deep Archive | ≥3 | 12–48 giờ | ~0,00099 USD/GB |

Ba tuỳ chọn lấy dữ liệu của Glacier Flexible Retrieval: | Tuỳ chọn | Thời gian | |---|---| | Expedited | 1–5 phút | | Standard | 3–5 giờ ← khớp "several hours" | | Bulk | 5–12 giờ, rẻ nhất |

Và của Deep Archive: | Tuỳ chọn | Thời gian | |---|---| | Standard | 12 giờ | | Bulk | 48 giờ |

Từ khoá nhận diện — rất hay được hỏi:

"AZ failure resilience", "durable" → KHÔNG dùng One Zone-IA "retrieval in minutes to hours" → Glacier Flexible Retrieval "retrieval within 12+ hours", "lowest cost", "7-10 years" → Deep Archive "unpredictable access pattern" → Intelligent-Tiering "millisecond access but rarely used" → Glacier Instant Retrieval

Ba ràng buộc của lifecycle: | Ràng buộc | Chi tiết | |---|---| | Standard-IA và One Zone-IA: tối thiểu 30 ngày | không chuyển sớm hơn | | Object nhỏ hơn 128 KB: không tự chuyển sang IA | | | Thời gian lưu tối thiểu tính phí | IA 30 ngày, Glacier 90, Deep Archive 180 |

Dòng cuối rất quan trọng về chi phí:

Xoá object khỏi Glacier trước 90 ngày
    → vẫn tính phí đủ 90 ngày
        ↓
    Đừng chuyển sang Glacier dữ liệu sắp bị xoá

Ba loại phí của lớp lưu trữ lạnh: | Phí | Chi tiết | |---|---| | Lưu trữ | thấp | | Truy xuất theo GB | có ở IA và Glacier | | Yêu cầu (request) | cao hơn Standard |

Chi phí ẩn của lớp lạnh:

Standard-IA: ~0,01 USD/GB phí truy xuất
    → đọc thường xuyên thì ĐẮT HƠN Standard
        ↓
    Chỉ chuyển dữ liệu THỰC SỰ ít đọc

Ba cách xác định dữ liệu nào nên chuyển: | Cách | Việc | |---|---| | S3 Storage Lens | tổng quan mức dùng và khuyến nghị | | S3 Storage Class Analysis | phân tích mẫu truy cập theo tuổi | | CloudWatch metric | |

Storage Class Analysis nên chạy trước khi đặt lifecycle:

aws s3api put-bucket-analytics-configuration --bucket kho-du-lieu   --id phan-tich-tai-chinh --analytics-configuration file://cau-hinh.json

Nó cho biết dữ liệu bao nhiêu ngày tuổi thì thực sự ngừng được đọc.

Ba thành phần của quy tắc lifecycle: | Thành phần | Chi tiết | |---|---| | Filter | prefix, tag, hoặc kích thước object | | Transitions | chuyển lớp theo số ngày | | Expiration | xoá sau số ngày |

Lọc theo tag rất linh hoạt:

{"Filter": {"And": {"Prefix": "finance/",
                    "Tags": [{"Key": "luu-tru", "Value": "dai-han"}]}}}

Ba quy tắc lifecycle nên có ở mọi bucket: | Quy tắc | Lợi ích | |---|---| | AbortIncompleteMultipartUpload | dọn phần tải dở — chi phí ẩn phổ biến | | Xoá version cũ sau N ngày | với bucket bật versioning | | Xoá delete marker mồ côi | |

{"ID": "don-phan-do-dang", "Status": "Enabled", "Filter": {},
 "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}

Phần tải dở dang không hiện trong danh sách object nhưng vẫn tính phí — đây là khoản lãng phí âm thầm rất hay gặp.

Ba lưu ý về Intelligent-Tiering: | Lưu ý | Chi tiết | |---|---| | Phí giám sát ~0,0025 USD mỗi 1.000 object | | | KHÔNG có phí truy xuất | ưu điểm lớn | | Không phù hợp với nhiều object nhỏ | phí giám sát vượt tiền tiết kiệm |

Ba lưu ý khi thiết kế lifecycle: | Lưu ý | Chi tiết | |---|---| | Kiểm tra yêu cầu tuân thủ trước | có thể cấm xoá | | Chạy thử trên tiền tố nhỏ | | | Theo dõi chi phí sau khi áp dụng | xác nhận tiết kiệm thật |

Và một lời khuyên: hãy kiểm tra tỷ lệ object nhỏ hơn 128 KB trước khi đặt lifecycle sang IA. Những object đó không được chuyển và vẫn nằm ở Standard — nếu bucket chủ yếu là tệp nhỏ, khoản tiết kiệm thực tế sẽ thấp hơn nhiều so với con số bạn tính từ tổng dung lượng.

Đáp án

B — Dùng S3 Object Lock ở chế độ Compliance cho dữ liệu loại A; dùng S3 Glacier Vault Lock cho dữ liệu loại B.

Vì sao đúng

Đề nêu hai loại dữ liệu với hai yêu cầu khác nhau, và mỗi loại có công cụ riêng: | Loại | Yêu cầu | Công cụ | |---|---|---| | A | giữ 6 tháng, không ai sửa hay xoá được, KỂ CẢ root | Object Lock chế độ Compliance | | B | giữ 10 năm, không ai xoá được | Glacier Vault Lock |

Chế độ Compliance là mấu chốt cho loại A:

S3 Object Lock có HAI chế độ:
    Governance: người có quyền đặc biệt VẪN xoá được
    Compliance: KHÔNG AI xoá được, kể cả tài khoản ROOT
        ↓
    Đề nói "cannot be overwritten or deleted by ANY USER,
    INCLUDING THE ROOT USER" → phải là Compliance

Cấu hình Object Lock:

# Bật lúc TẠO bucket — không bật sau được
aws s3api create-bucket --bucket du-lieu-loai-a   --object-lock-enabled-for-bucket   --create-bucket-configuration LocationConstraint=ap-northeast-1

aws s3api put-object-lock-configuration --bucket du-lieu-loai-a   --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":180}}}'

Và Glacier Vault Lock cho loại B:

Vault Lock policy:
    → khoá chính sách của vault
    → sau khi hoàn tất khoá, KHÔNG SỬA ĐƯỢC NỮA
        ↓
    Phù hợp cho lưu trữ 10 năm với yêu cầu tuân thủ

Và quy trình khoá có hai bước có chủ đích:

① initiate-vault-lock  → chính sách ở trạng thái NHÁP, có 24 giờ để thử
② complete-vault-lock  → KHOÁ VĨNH VIỄN
        ↓
    24 giờ đó là cơ hội duy nhất để phát hiện chính sách sai

aws glacier initiate-vault-lock --account-id - --vault-name kho-10-nam   --policy file://chinh-sach.json
# Thử nghiệm trong 24 giờ...
aws glacier complete-vault-lock --account-id - --vault-name kho-10-nam   --lock-id <lock-id>

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

• **D. Dùng Object Lock chế độ GOVERNANCE cho A, Glacier Vault Lock cho B — đây là phương án gần nhất và đúng hoàn toàn ở vế B, nhưng nó sai ở vế A: chế độ Governance cho phép người có quyền s3:BypassGovernanceRetention xoá được, trong khi đề nói rõ kể cả root cũng không được.
• **A. Dùng Object Lock Governance cho A, S3 Lifecycle cho B — hai lỗi: Governance không đủ mạnh cho A, và lifecycle chỉ chuyển lớp lưu trữ, không ngăn ai xoá dữ liệu B.
• **C. Dùng S3 Lifecycle cho A và Object Lock Compliance cho B — đảo ngược: lifecycle không có tính bất biến nào cho A, và tuy Object Lock Compliance dùng được cho B, việc đảo hai công cụ khiến A hoàn toàn không được bảo vệ.

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

Đáp án dùng S3 Glacier Vault Lock — đây là dịch vụ Glacier NGUYÊN BẢN, khác với lớp lưu trữ Glacier của S3.

Hai thứ dễ nhầm: | | S3 Glacier (dịch vụ nguyên bản) | Lớp lưu trữ Glacier của S3 | |---|---|---| | Khái niệm | vault, archive | bucket, object | | API | API riêng của Glacier | API của S3 | | Khoá tuân thủ | Vault Lock | Object Lock |

AWS hiện khuyến nghị dùng lớp lưu trữ Glacier của S3 thay vì dịch vụ Glacier nguyên bản, vì nó dùng chung API và công cụ với S3. Với dữ liệu loại B ngày nay, cách làm được khuyến nghị là:

Bucket có Object Lock Compliance, retention 10 năm
    + lifecycle chuyển sang Glacier Deep Archive
        ↓
    Cùng mức bất biến, mà quản lý bằng API của S3

(Đáp án B vẫn đúng theo các phương án cho sẵn — Vault Lock là cơ chế bất biến hợp lệ cho Glacier.)

Ghi nhớ

Hai chế độ của S3 Object Lock — bảng phải thuộc: | | Governance | Compliance | |---|---|---| | Người có quyền đặc biệt xoá được | ✅ (s3:BypassGovernanceRetention) | ❌ | | Root xoá được | ✅ | ❌ | | Rút ngắn thời gian giữ | ✅ | ❌ | | Phù hợp | bảo vệ nội bộ | tuân thủ pháp lý |

Từ khoá nhận diện:

"including the root user", "cannot be deleted by anyone", "WORM", "SEC 17a-4" → Compliance "protect from accidental deletion", "admins can override" → Governance

Ba cách khai thời gian giữ: | Cách | Chi tiết | |---|---| | Default retention của bucket | áp cho object mới | | Retention của từng object | ghi đè mặc định | | Legal hold | giữ VÔ THỜI HẠN cho tới khi gỡ |

Legal hold là cơ chế riêng:

Legal hold:
    → không có thời hạn
    → độc lập với retention period
    → gỡ được bởi người có quyền s3:PutObjectLegalHold
        ↓
    Dùng khi có tranh chấp pháp lý cần giữ chứng cứ

Ba điều kiện bắt buộc của Object Lock: | Điều kiện | Chi tiết | |---|---| | Bật LÚC TẠO bucket | không bật sau được cho bucket cũ | | Versioning phải bật | Object Lock bảo vệ từng version | | Áp cho VERSION cụ thể | version mới vẫn ghi được |

Dòng đầu là hạn chế quan trọng nhất — quên bật lúc tạo thì phải tạo bucket mới và di chuyển dữ liệu.

Dòng cuối là hành vi cần hiểu rõ:

Object bị khoá không SỬA hay XOÁ được
    → nhưng GHI ĐÈ tạo ra VERSION MỚI
    → version cũ vẫn còn nguyên và vẫn bị khoá
        ↓
    Tính bất biến được đảm bảo ở cấp VERSION

Ba đặc điểm của Glacier Vault Lock: | Đặc điểm | Chi tiết | |---|---| | Chính sách khoá VĨNH VIỄN sau khi hoàn tất | không sửa được | | 24 giờ để thử trước khi khoá | giai đoạn InProgress | | Huỷ được TRONG 24 giờ đó | abort-vault-lock |

Ba biện pháp bảo vệ dữ liệu bổ sung: | Biện pháp | Chống lại | |---|---| | Versioning | ghi đè và xoá nhầm | | MFA Delete | xoá version cần thiết bị MFA | | Replication sang tài khoản khác | mất cả tài khoản |

MFA Delete chỉ bật được bằng credential của root:

aws s3api put-bucket-versioning --bucket kho-quan-trong   --versioning-configuration Status=Enabled,MFADelete=Enabled   --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

Ba lưu ý về chi phí với dữ liệu bất biến: | Lưu ý | Chi tiết | |---|---| | KHÔNG xoá được nghĩa là TRẢ TIỀN đủ thời hạn | | | Kết hợp lifecycle chuyển sang lớp rẻ | Deep Archive cho 10 năm | | Tính trước tổng chi phí 10 năm | |

100 TB × 10 năm:
    S3 Standard:    ~2.760.000 USD
    Deep Archive:   ~119.000 USD
        ↓
    Chênh lệch rất lớn với lưu trữ dài hạn

Ba lưu ý khi triển khai Object Lock: | Lưu ý | Chi tiết | |---|---| | THỬ trên bucket nhỏ trước | Compliance không rút ngắn được | | Tính đúng thời hạn theo yêu cầu pháp lý | | | Ghi rõ vào tài liệu tuân thủ | |

Dòng đầu đặc biệt quan trọng:

Đặt nhầm retention 10 năm thay vì 6 tháng ở chế độ Compliance
    → KHÔNG SỬA ĐƯỢC
    → trả tiền lưu trữ suốt 10 năm
        ↓
    Không có cách nào hoàn tác, kể cả AWS Support

Ba tiêu chuẩn tuân thủ liên quan: | Tiêu chuẩn | Yêu cầu | |---|---| | SEC Rule 17a-4(f) | WORM cho hồ sơ tài chính | | FINRA | tương tự | | CFTC | tương tự |

AWS đã được đánh giá bởi bên thứ ba là Object Lock chế độ Compliance đáp ứng các tiêu chuẩn này.

Và một lời khuyên: hãy thử toàn bộ quy trình trên một bucket thử nghiệm với retention vài ngày trước khi áp cho dữ liệu thật. Chế độ Compliance không có nút hoàn tác — và một tham số sai ở đây tạo ra khoản chi phí và ràng buộc kéo dài đúng bằng thời hạn bạn đã gõ nhầm.

Đáp án

C — Cấu hình instance RDS dùng SSL cho dữ liệu trên đường truyền.

Vì sao đúng

Đề nêu vấn đề rõ: đã mã hoá at rest bằng KMS, nhưng kiểm toán viên yêu cầu bảo vệ in transit.

Hai loại mã hoá — hai cơ chế hoàn toàn khác nhau:
    At rest:    dữ liệu nằm trên đĩa   → KMS, đã có ✓
    In transit: dữ liệu chạy trên mạng → TLS/SSL, ĐANG THIẾU

Bật bắt buộc TLS cho RDS:

# PostgreSQL / SQL Server: tham số rds.force_ssl
aws rds modify-db-parameter-group --db-parameter-group-name nhom-tham-so   --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot"

# MySQL / MariaDB: require_secure_transport
aws rds modify-db-parameter-group --db-parameter-group-name nhom-tham-so   --parameters "ParameterName=require_secure_transport,ParameterValue=ON,ApplyMethod=immediate"

Và phía ứng dụng phải xác minh chứng chỉ:

jdbc:postgresql://db.abc.ap-northeast-1.rds.amazonaws.com:5432/thanhtoan
  ?ssl=true&sslmode=verify-full
  &sslrootcert=/opt/certs/global-bundle.pem

verify-full là chế độ đúng: | Chế độ | Kiểm tra | |---|---| | require | chỉ mã hoá — KHÔNG xác minh chứng chỉ | | verify-ca | xác minh chứng chỉ do CA tin cậy ký | | verify-full | xác minh CA VÀ tên máy chủ — chống giả mạo |

Chỉ dùng require là vẫn có lỗ hổng:

require: mã hoá nhưng không kiểm tra danh tính máy chủ
    → kẻ tấn công chen giữa vẫn thiết lập được TLS
    → đọc được toàn bộ dữ liệu
        ↓
    Với dữ liệu thanh toán, verify-full là bắt buộc

Tải chứng chỉ gốc của AWS:

curl -o global-bundle.pem   https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

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

• **A. Bật mã hoá at rest cho RDS instance — đây là phương án gần nhất vì nó cũng là mã hoá, nhưng đề đã nói rõ at rest ĐÃ CÓ: "the database is encrypted at rest using AWS KMS". Vấn đề là in transit.
• **B. Dùng AWS Certificate Manager cấp chứng chỉ cho RDS — không phải cách hoạt động: RDS tự cấp và quản lý chứng chỉ máy chủ của nó (rds-ca-rsa2048-g1). ACM cấp chứng chỉ cho ALB, CloudFront, API Gateway — không cho RDS.
• **D. Bật Multi-AZ cho instance — giải quyết vấn đề khác: Multi-AZ là cơ chế sẵn sàng cao, hoàn toàn không liên quan tới mã hoá.

Ghi nhớ

Hai loại mã hoá — bảng phải thuộc: | Loại | Bảo vệ | Cơ chế của RDS | |---|---|---| | At rest | dữ liệu trên đĩa, snapshot, replica | KMS, bật LÚC TẠO | | In transit | dữ liệu trên mạng | TLS/SSL ← câu này |

Câu hỏi nào nói "đã mã hoá at rest, cần bảo vệ thêm" thì đáp án là in transit.

Ba tham số bắt buộc TLS theo engine: | Engine | Tham số | |---|---| | PostgreSQL | rds.force_ssl = 1 | | SQL Server | rds.force_ssl = 1 | | MySQL / MariaDB | require_secure_transport = ON | | Oracle | SQLNET.SSL_VERSION |

Ba chế độ xác minh TLS của client: | Chế độ | Mã hoá | Xác minh CA | Xác minh tên máy chủ | |---|---|---|---| | require | ✅ | ❌ | ❌ | | verify-ca | ✅ | ✅ | ❌ | | verify-full | ✅ | ✅ | ✅ |

Ba lưu ý về chứng chỉ của RDS: | Lưu ý | Chi tiết | |---|---| | RDS tự cấp và xoay vòng | không dùng ACM | | Chứng chỉ CÓ HẠN — phải cập nhật | | | Dùng global bundle cho mọi Region | đơn giản nhất |

Dòng giữa là sự cố hay gặp:

Chứng chỉ CA của RDS hết hạn
    → mọi kết nối verify-full THẤT BẠI
    → ứng dụng ngừng kết nối được database
        ↓
    AWS báo trước rất lâu, nhưng cần theo dõi và cập nhật

aws rds modify-db-instance --db-instance-identifier db-thanh-toan   --ca-certificate-identifier rds-ca-rsa2048-g1 --apply-immediately

Ba lưu ý về mã hoá at rest của RDS: | Lưu ý | Chi tiết | |---|---| | Chỉ bật được LÚC TẠO | không bật sau cho instance đang chạy | | Muốn mã hoá instance cũ: snapshot → copy có mã hoá → restore | | | Snapshot và read replica kế thừa mã hoá | |

Quy trình mã hoá instance đã có:

aws rds create-db-snapshot --db-instance-identifier db-cu   --db-snapshot-identifier snap-cu
aws rds copy-db-snapshot --source-db-snapshot-identifier snap-cu   --target-db-snapshot-identifier snap-ma-hoa   --kms-key-id <arn-khoa>
aws rds restore-db-instance-from-db-snapshot   --db-instance-identifier db-moi --db-snapshot-identifier snap-ma-hoa

Ba lớp bảo mật cho RDS: | Lớp | Cơ chế | |---|---| | Mạng | private subnet, security group, KHÔNG public | | Truyền tải | TLS bắt buộc ← câu này | | Lưu trữ | KMS | | Danh tính | IAM authentication hoặc mật khẩu trong Secrets Manager |

Ba biện pháp bổ sung cho dữ liệu thanh toán: | Biện pháp | Chi tiết | |---|---| | IAM database authentication | không dùng mật khẩu tĩnh | | Secrets Manager với xoay vòng tự động | | | Database Activity Streams | ghi mọi truy vấn |

IAM database authentication:

aws rds generate-db-auth-token --hostname db.abc.rds.amazonaws.com   --port 5432 --username ung_dung --region ap-northeast-1

Token có hạn 15 phút
    → không có mật khẩu dài hạn nào để bị lộ

Ba cách kiểm chứng TLS đang được dùng: | Cách | Lệnh | |---|---| | PostgreSQL | SELECT ssl FROM pg_stat_ssl WHERE pid = pg_backend_pid(); | | MySQL | SHOW STATUS LIKE 'Ssl_cipher'; | | Từ ngoài | openssl s_client -connect db:5432 -starttls postgres |

Ba lưu ý khi bật force_ssl: | Lưu ý | Chi tiết | |---|---| | Cần KHỞI ĐỘNG LẠI với PostgreSQL | tham số pending-reboot | | Client cũ không hỗ trợ TLS sẽ bị TỪ CHỐI | kiểm tra trước | | Thử ở môi trường staging trước | |

Dòng giữa gây gián đoạn nếu không chuẩn bị:

Bật force_ssl
    → mọi kết nối không dùng TLS bị từ chối ngay
    → ứng dụng cũ chưa cấu hình TLS NGỪNG HOẠT ĐỘNG
        ↓
    Cập nhật client TRƯỚC, bật force_ssl SAU

Ba tiêu chuẩn yêu cầu mã hoá in transit: | Tiêu chuẩn | Yêu cầu | |---|---| | PCI DSS | bắt buộc cho dữ liệu thẻ | | HIPAA | cho dữ liệu y tế | | GDPR | biện pháp kỹ thuật phù hợp |

Và một lời khuyên: hãy kiểm chứng bằng pg_stat_ssl sau khi cấu hình, đừng chỉ tin vào chuỗi kết nối. Nhiều driver âm thầm rơi về kết nối không mã hoá khi cấu hình TLS có vấn đề — và bạn sẽ thấy ứng dụng chạy bình thường trong khi dữ liệu thanh toán vẫn đi qua mạng dưới dạng bản rõ.

Đáp án

C — Cho phép security group của Application Load Balancer trong security group của các EC2 instance.

Vì sao đúng

Đề nêu yêu cầu chính xác: chỉ ALB được truy cập EC2, và cách đúng là tham chiếu security group.

Security group của EC2:
    Inbound: cổng 443, nguồn = SECURITY GROUP CỦA ALB
        ↓
    ✓ Chỉ lưu lượng từ ENI mang security group đó được vào
    ✓ Mọi nguồn khác bị chặn

aws ec2 authorize-security-group-ingress --group-id sg-ec2   --protocol tcp --port 443 --source-group sg-alb

Và tham chiếu security group tốt hơn dùng CIDR: | Ưu điểm | Chi tiết | |---|---| | Tự thích ứng khi ALB đổi IP | không phải sửa gì | | Chính xác hơn dải CIDR của subnet | subnet còn tài nguyên khác | | Diễn đạt đúng ý định | "cho phép từ ALB", không phải "từ dải IP này" |

Vì sao dùng CIDR của subnet là sai:

Cho phép 10.0.1.0/24 (subnet chứa ALB)
    → mọi tài nguyên trong subnet đó đều vào được
    → không chỉ ALB
        ↓
    Vi phạm nguyên tắc quyền tối thiểu

Và ALB đổi IP thường xuyên:

ALB co giãn theo tải
    → AWS thêm bớt node
    → IP riêng của các node THAY ĐỔI
        ↓
    Danh sách CIDR cứng sẽ hỏng

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

• **A. Thu hồi security group hiện tại của các EC2 và tạo lại đúng quy tắc — đây là phương án gần nhất vì mục tiêu tương tự, nhưng nó là cách diễn đạt vòng vo và gây gián đoạn: chỉ cần sửa quy tắc của security group hiện có, không cần thu hồi và tạo lại. Và thu hồi giữa chừng làm đứt kết nối đang chạy.
• **B. Cho phép security group của EC2 trong security group của ALB — ngược chiều: quy tắc inbound của ALB kiểm soát ai gọi được vào ALB (là người dùng Internet), không kiểm soát việc ALB gọi tới EC2.
• **D. Cho phép dải CIDR của subnet chứa ALB trong security group của EC2 — quá rộng: mọi tài nguyên trong subnet đó vào được, và IP có thể đổi.

Ghi nhớ

Mẫu chuẩn cho kiến trúc ba tầng — bảng phải thuộc: | Security group | Inbound cho phép | |---|---| | sg-alb | 0.0.0.0/0 cổng 443 (từ Internet) | | sg-ec2 | sg-alb cổng ứng dụng | | sg-rds | sg-ec2 cổng database |

Mỗi tầng chỉ cho phép tầng ngay trước nó — đây là mẫu được hỏi rất nhiều.

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | STATEFUL | phản hồi tự động được phép, không cần rule outbound | | CHỈ có Allow | không có Deny | | Tham chiếu SG khác được | ← khuyến nghị |

Tính stateful là điểm quan trọng:

Cho phép inbound cổng 443 từ sg-alb
    → phản hồi đi ra TỰ ĐỘNG được phép
    → KHÔNG cần thêm rule outbound
        ↓
    Khác hẳn NACL (stateless, phải mở cả hai chiều)

Security group và NACL — bảng phân biệt: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI | SUBNET | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | chỉ Allow | Allow và Deny | | Thứ tự | đánh giá tất cả | theo số thứ tự | | Tham chiếu SG khác | ✅ | ❌ chỉ CIDR | | Mặc định | chặn inbound, mở outbound | mở cả hai chiều |

Ba nguồn có thể khai trong rule: | Nguồn | Ví dụ | |---|---| | Security group | sg-abc123 ← khuyến nghị | | Dải CIDR | 10.0.0.0/16 | | Prefix list | pl-abc (dịch vụ AWS hoặc tự tạo) |

Prefix list rất tiện:

# Cho phép từ CloudFront (prefix list do AWS quản lý)
aws ec2 authorize-security-group-ingress --group-id sg-alb   --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,
                    PrefixListIds=[{PrefixListId=pl-58a04531}]'

AWS tự cập nhật dải IP của CloudFront — không phải theo dõi thủ công.

Ba giới hạn của security group: | Giới hạn | Giá trị | |---|---| | Số rule mỗi SG | 60 inbound + 60 outbound | | Số SG mỗi ENI | 5 (nâng lên 16 được) | | Tổng rule mỗi ENI | 1.000 |

Ba lưu ý về tham chiếu security group: | Lưu ý | Chi tiết | |---|---| | Chỉ trong CÙNG VPC | hoặc VPC đã peering | | Không tham chiếu xuyên Region | | | Tham chiếu vòng được | A cho phép B, B cho phép A |

Ba trường hợp phải dùng CIDR thay vì SG: | Trường hợp | Lý do | |---|---| | Nguồn ngoài VPC | Internet, on-premises | | Nguồn ở VPC chưa peering | | | Dịch vụ không có SG | |

Ba lưu ý về ALB và security group: | Lưu ý | Chi tiết | |---|---| | ALB BẮT BUỘC có security group | | | NLB nay CŨNG hỗ trợ | tính năng mới từ 2023 | | Health check cũng đi từ SG của ALB | cùng quy tắc |

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

Health check của ALB đi từ chính node của ALB
    → mang security group của ALB
        ↓
    Cho phép sg-alb là đủ cho CẢ lưu lượng lẫn health check

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | chỉ ra thành phần nào chặn | | VPC Flow Logs | thấy gói bị REJECT | | describe-security-groups | xem quy tắc hiện tại |

Ba nguyên tắc thiết kế security group: | Nguyên tắc | Chi tiết | |---|---| | Một SG cho một VAI TRÒ | web, app, db | | Tham chiếu SG thay vì CIDR trong VPC | | | Đặt tên và mô tả rõ ràng | sg-web-tier-prod |

Ba lỗi cấu hình phổ biến: | Lỗi | Hậu quả | |---|---| | Mở 0.0.0.0/0 cho cổng 22 hoặc 3389 | bị quét và tấn công liên tục | | Cho phép CIDR của cả VPC | quá rộng | | Quên mở cổng health check | target unhealthy |

Thay SSH mở ra Internet bằng Session Manager:

aws ssm start-session --target i-0abc123

✓ KHÔNG cần mở cổng 22
✓ không cần bastion host
✓ có log đầy đủ trong CloudTrail

Và một lời khuyên: hãy rà soát định kỳ các security group có rule 0.0.0.0/0 ngoài cổng 80 và 443. Chúng thường là tàn dư của một lần gỡ lỗi vội vàng, và không có gì nhắc bạn dọn chúng đi — AWS Config có rule dựng sẵn để phát hiện đúng loại này.

Đáp án

A, B và F.

• A — Cho phép BẤT KỲ địa chỉ IP nào truy cập cổng 80
• B — Cho phép địa chỉ IP 192.0.2.1 truy cập cổng 22
• F — Quy tắc INBOUND của security group được cấu hình

Vì sao đúng

Đây là bài đọc hiểu cấu hình. Xét từng quy tắc trong bảng:

Quy tắc 1 — HTTP:

Type: HTTP | Protocol: TCP | Port range: 80 | Source: 0.0.0.0/0
        ↓
    0.0.0.0/0 = MỌI địa chỉ IPv4
    → bất kỳ ai trên Internet đều gọi được cổng 80
        ↓
    Đáp án A ✓

Quy tắc 2 — SSH:

Type: SSH | Protocol: TCP | Port range: 22 | Source: 192.0.2.1/32
        ↓
    /32 = ĐÚNG MỘT địa chỉ
    → chỉ 192.0.2.1 mới SSH được
        ↓
    Đáp án B ✓

Và đây là quy tắc INBOUND:

"Source" là cột chỉ NGUỒN
    → quy tắc inbound quy định AI ĐƯỢC VÀO

Nếu là outbound thì cột sẽ là "Destination"
        ↓
    Đáp án F ✓

Bảng tóm tắt tiền tố CIDR: | Tiền tố | Số địa chỉ | Nghĩa | |---|---|---| | /32 | 1 | đúng một máy | | /24 | 256 | một subnet nhỏ | | /16 | 65.536 | một VPC điển hình | | /0 | toàn bộ | mọi địa chỉ |

Và cấu hình này là mẫu chuẩn cho web server:

Cổng 80 mở cho tất cả:  đúng — web server phục vụ công khai
Cổng 22 chỉ một IP:     đúng — quản trị từ một địa chỉ tin cậy

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

• **E. Cho phép bất kỳ IP nào truy cập cổng 22 — đây là phương án gần nhất vì nó nói đúng về cổng 22, nhưng sai về nguồn: nguồn là 192.0.2.1/32, chỉ một địa chỉ. (Và mở SSH cho 0.0.0.0/0 là lỗi bảo mật nghiêm trọng.)
• **D. Cho phép địa chỉ 192.0.2.1 truy cập cổng 80 — đảo hai quy tắc: cổng 80 mở cho 0.0.0.0/0, cổng 22 mới giới hạn ở địa chỉ đó.
• **C. Đây là quy tắc OUTBOUND — cột "Source" cho biết đây là inbound; outbound dùng cột "Destination".

Ghi nhớ

Đọc quy tắc security group — bảng phải thuộc: | Cột | Nghĩa | |---|---| | Type | dịch vụ dựng sẵn (SSH, HTTP, HTTPS) | | Protocol | TCP, UDP, ICMP | | Port range | cổng hoặc dải cổng | | Source | có cột này = quy tắc INBOUND | | Destination | có cột này = quy tắc OUTBOUND |

Ba cổng phổ biến: | Cổng | Dịch vụ | |---|---| | 22 | SSH (Linux) | | 80 | HTTP | | 443 | HTTPS | | 3389 | RDP (Windows) | | 3306 | MySQL | | 5432 | PostgreSQL | | 1433 | SQL Server | | 1521 | Oracle | | 2049 | NFS (EFS) | | 6379 | Redis | | 27017 | MongoDB |

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | STATEFUL | phản hồi tự động được phép | | CHỈ có Allow | không có Deny | | Mặc định: chặn inbound, mở outbound | |

Ba loại nguồn khai được: | Nguồn | Ví dụ | |---|---| | Dải CIDR | 0.0.0.0/0, 192.0.2.1/32 | | Security group khác | sg-abc123 | | Prefix list | pl-abc |

Ba nguyên tắc bảo mật cho quy tắc inbound: | Nguyên tắc | Chi tiết | |---|---| | KHÔNG mở 22 hoặc 3389 cho 0.0.0.0/0 | bị quét liên tục | | Web mở 80/443 cho tất cả là bình thường | | | Tham chiếu SG cho lưu lượng nội bộ | |

Cách thay thế SSH mở ra ngoài: | Cách | Chi tiết | |---|---| | Systems Manager Session Manager | KHÔNG cần mở cổng nào | | EC2 Instance Connect Endpoint | qua endpoint riêng | | Bastion host | truyền thống, vẫn phải mở một cổng |

aws ssm start-session --target i-0abc123

✓ không mở cổng 22
✓ không cần key pair
✓ mọi phiên đều có log trong CloudTrail
✓ kiểm soát bằng IAM

Đây là cách được AWS khuyến nghị hiện nay.

Ba lưu ý về 0.0.0.0/0: | Lưu ý | Chi tiết | |---|---| | Nghĩa là MỌI địa chỉ IPv4 | | | IPv6 dùng ::/0 riêng | phải khai riêng | | Chỉ dùng cho dịch vụ công khai | |

Dòng giữa là chi tiết hay bị quên:

Cho phép 0.0.0.0/0 KHÔNG cho phép IPv6
    → nếu instance có IPv6, phải thêm ::/0
        ↓
    Ngược lại: chặn IPv4 mà quên IPv6 là để hở

Ba công cụ rà soát security group: | Công cụ | Việc | |---|---| | AWS Config rule | phát hiện SG mở cổng nhạy cảm | | Security Hub | tổng hợp phát hiện | | Trusted Advisor | kiểm tra bảo mật cơ bản |

AWS Config có rule dựng sẵn:

restricted-ssh                    → SG mở cổng 22 cho 0.0.0.0/0
restricted-common-ports           → các cổng phổ biến khác
vpc-sg-open-only-to-authorized-ports

Ba lưu ý khi gỡ lỗi kết nối: | Bước | Kiểm tra | |---|---| | ① Security group | cổng và nguồn đúng chưa | | ② NACL | stateless — cần mở cả hai chiều | | ③ Route table | có đường đi không |

NACL hay bị quên vì nó stateless:

Security group cho phép inbound 443 ✓
NACL cho phép inbound 443 ✓
    nhưng NACL KHÔNG cho phép outbound cổng ephemeral (1024-65535)
        ↓
    Phản hồi không ra được → kết nối treo

Ba lưu ý về quy tắc outbound: | Lưu ý | Chi tiết | |---|---| | Mặc định mở hết (0.0.0.0/0) | | | Thắt chặt được cho môi trường nhạy cảm | | | Nhớ mở cho VPC endpoint và DNS | nếu thắt chặt |

Và một lời khuyên: hãy thay mọi rule SSH mở ra Internet bằng Session Manager. Nó bỏ hẳn nhu cầu mở cổng 22, không cần quản lý key pair, và mỗi phiên đều có bản ghi trong CloudTrail — ba lợi ích mà cách cho phép một địa chỉ IP cố định không có được, vì địa chỉ đó vẫn có thể bị dùng bởi bất kỳ ai ngồi sau nó.