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

Đáp án

**D — Di trú cơ sở dữ liệu sang Amazon Aurora MySQL; triển khai ứng dụng trong Auto Scaling group các instance EC2 đứng sau Application Load Balancer; lưu phiên trong ElastiCache for Redis có replication group.

Vì sao đúng

Đề có ba yêu cầu, và mỗi phần của đáp án lo một cái: | Yêu cầu | Thành phần | |---|---| | Vẫn dùng truy vấn SQL | Aurora MySQL | | Độ tin cậy cao nhất + hiệu năng tốt hơn | Aurora + ASG + ALB | | Ứng dụng có trạng thái | Redis có replication group |

⚠ Điểm mấu chốt: Aurora tách lưu trữ khỏi tính toán:

Lớp lưu trữ trải trên 3 AZ
        ↓
    Mỗi AZ giữ 2 bản sao
        ↓
    Tổng 6 bản sao dữ liệu
        ↓
    Chịu được mất cả một AZ + một bản
      sao nữa mà không mất dữ liệu

Bảng so sánh với RDS MySQL: | | RDS MySQL Multi-AZ | Aurora MySQL | |---|---|---| | Số bản sao dữ liệu | 2 (chính + dự phòng) | 6 trên 3 AZ | | Thời gian chuyển đổi | 60-120 giây | thường dưới 30 giây | | Số read replica | tối đa 5 | tối đa 15 | | Độ trễ replica | giây | thường dưới 100 ms | | Thông lượng | cơ sở | tới 5 lần MySQL thường |

⚠ Và vì sao phương án B chưa đủ tốt:

B dùng RDS MySQL Multi-AZ
        ↓
    Đúng về mặt sẵn sàng
        ↓
    Nhưng đề nói "độ tin cậy TỐI ĐA"
      và "hiệu năng TỐT HƠN"
        ↓
    Aurora hơn ở cả hai

⚠ Và điểm chí mạng của B nằm ở Memcached:

B lưu phiên trong ElastiCache for
  Memcached
        ↓
    Memcached KHÔNG sao chép dữ liệu
        ↓
    Node hỏng → mọi phiên trên node đó
      MẤT
        ↓
    Người dùng bị đăng xuất
    → trái với "độ tin cậy tối đa"

Bảng Redis và Memcached: | | Memcached | Redis | |---|---|---| | Sao chép | không | có | | Bền vững | không | có (AOF, snapshot) | | Chuyển đổi tự động | không | có (Multi-AZ) | | Kiểu dữ liệu | chỉ chuỗi | list, set, hash, sorted set | | Hợp với | cache thuần | phiên, hàng đợi, xếp hạng |

⚠ Và phiên đăng nhập là dữ liệu KHÔNG được mất:

Cache sản phẩm mất → tính lại được
        ↓
    Phiên đăng nhập mất → người dùng
      bị đá ra
        ↓
    Giỏ hàng mất → mất đơn hàng
    → phiên cần bền vững, không phải
      cache thuần

Dựng replication group:

aws elasticache create-replication-group \
  --replication-group-id phien-ung-dung \
  --replication-group-description "Luu phien dang nhap" \
  --engine redis --cache-node-type cache.r7g.large \
  --num-node-groups 1 --replicas-per-node-group 2 \
  --automatic-failover-enabled \
  --multi-az-enabled \
  --at-rest-encryption-enabled \
  --transit-encryption-enabled

⚠ Và automatic-failover-enabled là thứ biến replica thành sẵn sàng cao:

Có replica mà không bật failover
        ↓
    Node chính hỏng → phải chuyển đổi
      thủ công
        ↓
    Bật lên → tự thăng cấp replica
    → thường dưới 60 giây

⚠ Và vì sao phương án A sai — DocumentDB không nói SQL:

A di trú sang DocumentDB
        ↓
    DocumentDB tương thích MongoDB
        ↓
    API là truy vấn tài liệu, không
      phải SQL
        ↓
    Đề nói "phải tiếp tục hỗ trợ truy
      vấn SQL"
    → loại ngay

⚠ Và A còn dùng NLB cho ứng dụng web:

NLB làm việc ở tầng 4
        ↓
    Không định tuyến theo đường dẫn
        ↓
    Không có sticky session dựa trên
      cookie ứng dụng
        ↓
    Ứng dụng web nên dùng ALB

⚠ Và vì sao phương án C sai nghiêm trọng:

C lưu phiên trong Amazon Neptune
        ↓
    Neptune là CSDL ĐỒ THỊ
        ↓
    Dùng cho quan hệ mạng xã hội, đề
      xuất, phát hiện gian lận
        ↓
    Lưu phiên trong đó là dùng sai
      hoàn toàn

⚠ Và C dùng read replica thay Multi-AZ:

Read replica giúp CHIA TẢI ĐỌC
        ↓
    Nó KHÔNG tự chuyển đổi khi chính
      hỏng
        ↓
    Phải thăng cấp thủ công
        ↓
    → không phải giải pháp sẵn sàng
      cao

⚠ Và đây là phân biệt phải nhớ: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | chia tải đọc | | Sao chép | đồng bộ | bất đồng bộ | | Đọc được không | không (bản dự phòng) | có | | Chuyển đổi | tự động | thủ công |

Aurora gộp cả hai:
        ↓
    Reader instance vừa phục vụ đọc
        ↓
    Vừa là ứng viên thăng cấp tự động

Dựng cụm Aurora:

aws rds create-db-cluster \
  --db-cluster-identifier cum-ban-hang \
  --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.05.2 \
  --master-username quantri \
  --manage-master-user-password \
  --backup-retention-period 14 \
  --storage-encrypted --deletion-protection

aws rds create-db-instance \
  --db-instance-identifier cum-ban-hang-1 \
  --db-cluster-identifier cum-ban-hang \
  --engine aurora-mysql --db-instance-class db.r6g.large

aws rds create-db-instance \
  --db-instance-identifier cum-ban-hang-2 \
  --db-cluster-identifier cum-ban-hang \
  --engine aurora-mysql --db-instance-class db.r6g.large \
  --promotion-tier 1

⚠ Và --manage-master-user-password để Secrets Manager tự quản:

Không phải tự nghĩ mật khẩu
        ↓
    Không phải lưu ở đâu
        ↓
    Tự xoay vòng theo lịch
    → và không bao giờ xuất hiện trong
      lịch sử lệnh

⚠ Và Aurora có hai endpoint phải dùng đúng:

Writer endpoint → luôn trỏ node chính
        ↓
    Reader endpoint → cân bằng tải giữa
      các replica
        ↓
    Ứng dụng dùng writer cho mọi thứ
    → lãng phí toàn bộ replica

⚠ Và di trú bằng DMS để giảm thời gian ngừng:

aws dms create-replication-task \
  --replication-task-identifier di-tru-mysql \
  --source-endpoint-arn <arn-mysql-tai-cho> \
  --target-endpoint-arn <arn-aurora> \
  --migration-type full-load-and-cdc \
  --table-mappings file://anh-xa.json

⚠ Và ứng dụng phải chịu được việc instance biến mất:

Auto Scaling group thay instance bất
  kỳ lúc nào
        ↓
    Trạng thái lưu trên đĩa cục bộ →
      mất
        ↓
    Đó là lý do phiên phải ra ngoài
    → và tệp tải lên phải vào S3

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | 6 bản sao dữ liệu trên 3 AZ | | | Phiên sống sót qua sự cố node | | | Tầng web co giãn theo tải | |

⚠ Và nên bật Aurora Auto Scaling cho reader:

aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --resource-id cluster:cum-ban-hang \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --min-capacity 1 --max-capacity 8

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

• **B. RDS MySQL Multi-AZ + ALB + ElastiCache for Memcached — đây là phương án gần nhất và phần CSDL và cân bằng tải đều hợp lý, nhưng Memcached không sao chép dữ liệu nên node hỏng là mất phiên; và Aurora vượt RDS Multi-AZ về cả độ tin cậy lẫn hiệu năng.
• **C. RDS MySQL read replica + ALB + lưu phiên trong Neptune — read replica không tự chuyển đổi, và Neptune là cơ sở dữ liệu đồ thị, không phải nơi lưu phiên.
• **A. DocumentDB + NLB + Redis — DocumentDB không hỗ trợ SQL, trái với yêu cầu rõ ràng của đề.

Ghi nhớ

⚠ Bốn lựa chọn CSDL quan hệ được quản lý — bảng phải thuộc: | Lựa chọn | Chọn khi | |---|---| | Aurora | cần hiệu năng và độ bền cao nhất | | RDS Multi-AZ | đủ dùng, rẻ hơn | | RDS Multi-AZ DB cluster | cần hai replica đọc được + chuyển đổi nhanh | | RDS Single-AZ | chỉ cho môi trường thử nghiệm |

Từ khoá nhận diện:

"maximum reliability, better performance, SQL" → Aurora "store sessions reliably" → Redis có replication group "MongoDB compatible" → DocumentDB "graph relationships" → Neptune

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | 6 bản sao trên 3 AZ | | | Tối đa 15 reader | | | Writer và reader endpoint riêng | |

Ba lưu ý về Redis: | Lưu ý | Chi tiết | |---|---| | Bật automatic-failover mới có sẵn sàng cao | | | Bật mã hoá khi truyền và khi lưu | | | Đặt TTL cho khoá phiên | |

Ba lưu ý về Memcached: | Lưu ý | Chi tiết | |---|---| | Không sao chép, không bền vững | | | Đa luồng, đơn giản | | | Chỉ hợp làm cache thuần | |

Ba lưu ý về ứng dụng có trạng thái: | Lưu ý | Chi tiết | |---|---| | Đưa phiên ra kho ngoài | | | Tệp tải lên vào S3 | | | Đừng dựa vào sticky session làm giải pháp chính | |

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Định tuyến tầng 7 | | | Health check theo HTTP | | | Tích hợp WAF và Cognito | |

Ba lưu ý về di trú: | Lưu ý | Chi tiết | |---|---| | DMS full load + CDC giảm thời gian ngừng | | | Bật data validation | | | Thử ứng dụng trên Aurora trước khi cắt chuyển | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ép chuyển đổi Aurora, đo thời gian | | | Tắt một node Redis, kiểm phiên còn không | | | Kiểm ứng dụng có gọi reader endpoint không | |

Và một lời khuyên: hãy kiểm tra ứng dụng có thật sự dùng reader endpoint không sau khi chuyển sang Aurora. Rất nhiều lần di trú kết thúc với một cụm có bốn reader nhàn rỗi trong khi node chính quá tải — vì chuỗi kết nối chỉ được đổi ở một chỗ duy nhất, và đó là writer endpoint.

Đáp án

**D — Dựng bảng DynamoDB mới với chế độ on-demand; dùng gateway VPC endpoint cho DynamoDB để ứng dụng có kết nối riêng tư và được mã hoá tới bảng.

Vì sao đúng

Đề có ba ràng buộc, và đáp án khớp cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | EC2 trong subnet riêng tư, không có Internet | gateway endpoint | | Kết nối tới CSDL phải mã hoá | DynamoDB chỉ nhận HTTPS | | Co giãn theo tải bất thường | chế độ on-demand |

⚠ Điểm mấu chốt: DynamoDB dùng GATEWAY endpoint, không phải interface endpoint:

Chỉ hai dịch vụ có gateway endpoint:
        ↓
    Amazon S3
    Amazon DynamoDB
        ↓
    Mọi dịch vụ khác dùng interface
      endpoint (PrivateLink)

Bảng phân biệt hai loại endpoint: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ hỗ trợ | chỉ S3 và DynamoDB | hầu hết dịch vụ | | Cơ chế | route trong route table | ENI có IP riêng tư | | Chi phí | MIỄN PHÍ | theo giờ + theo GB | | Truy cập từ ngoài VPC | không | có (qua DX/VPN) | | Security group | không gắn được | gắn được |

⚠ Và gateway endpoint miễn phí — điểm rất đáng nhớ:

Gateway endpoint: 0 đồng
        ↓
    Interface endpoint: ~7,3 USD/tháng
      mỗi AZ + 0,01 USD/GB
        ↓
    Với S3 và DynamoDB
    → luôn ưu tiên gateway endpoint

⚠ Và S3 giờ CŨNG có interface endpoint — khi nào cần:

Truy cập S3 từ TẠI CHỖ qua Direct
  Connect
        ↓
    Gateway endpoint không dùng được
      (chỉ trong VPC)
        ↓
    → phải dùng interface endpoint
        ↓
    DynamoDB cũng có interface
      endpoint từ 2024, cùng lý do

Tạo gateway endpoint:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-abc \
  --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.ap-southeast-1.dynamodb \
  --route-table-ids rtb-rieng-tu-1 rtb-rieng-tu-2 \
  --policy-document file://chinh-sach-endpoint.json

⚠ Và phải khai ĐÚNG route table của subnet riêng tư:

Gateway endpoint hoạt động bằng cách
  thêm route
        ↓
    Đích là prefix list của dịch vụ
        ↓
    Khai nhầm route table → subnet đó
      không dùng được endpoint
    → và lỗi là "hết thời gian chờ",
      không phải "từ chối"

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu-1 \
  --query 'RouteTables[0].Routes[?DestinationPrefixListId!=null]'

Chính sách endpoint giới hạn phạm vi:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": "*",
   "Action": ["dynamodb:GetItem", "dynamodb:PutItem",
              "dynamodb:Query", "dynamodb:UpdateItem"],
   "Resource": "arn:aws:dynamodb:ap-southeast-1:111122223333:table/du-lieu-ung-dung"}]}

⚠ Và mã hoá đường truyền là mặc định, không phải tuỳ chọn:

Mọi endpoint của DynamoDB chỉ nhận
  HTTPS
        ↓
    Không có phiên bản HTTP
        ↓
    → yêu cầu "kết nối phải mã hoá"
      tự động thoả

⚠ Và mã hoá khi lưu cũng bật mặc định từ 2018:

Mọi bảng DynamoDB đều mã hoá khi lưu
        ↓
    Không tắt được
        ↓
    Chọn được khoá:
      - khoá do AWS sở hữu (miễn phí)
      - khoá do AWS quản (`aws/dynamodb`)
      - khoá của khách hàng (CMK)

⚠ Và chế độ on-demand hợp với tải bất thường:

Đề nói "tải đột biến hoặc không đoán
  trước được"
        ↓
    Provisioned: phải đoán trước công
      suất
        ↓
    Đoán thấp → throttle
    → đoán cao → trả tiền thừa
        ↓
    On-demand: trả theo yêu cầu thật

aws dynamodb create-table \
  --table-name du-lieu-ung-dung \
  --attribute-definitions AttributeName=khoa,AttributeType=S \
  --key-schema AttributeName=khoa,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --sse-specification Enabled=true,SSEType=KMS

⚠ Và on-demand vẫn có trần — cần biết:

Bảng on-demand khởi đầu chịu được
  4.000 ghi và 12.000 đọc mỗi giây
        ↓
    Tự nhân đôi trần khi tải tăng
        ↓
    Nhưng cần khoảng 30 phút để thích
      nghi
        ↓
    Tải tăng đột ngột gấp nhiều lần
    → vẫn bị throttle trong lúc chờ

⚠ Và có thể đặt trần rõ ràng từ 2024:

aws dynamodb update-table --table-name du-lieu-ung-dung \
  --on-demand-throughput MaxReadRequestUnits=20000,MaxWriteRequestUnits=10000

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

C dùng interface endpoint cho DynamoDB
        ↓
    Về mặt kỹ thuật giờ có tồn tại
        ↓
    Nhưng gateway endpoint là lựa chọn
      chuẩn và MIỄN PHÍ
        ↓
    Interface endpoint tính phí giờ
    → không phải lựa chọn tốt nhất

⚠ Và vì sao phương án A sai — DocumentDB KHÔNG có gateway endpoint:

A dùng gateway VPC endpoint cho
  DocumentDB
        ↓
    Chỉ S3 và DynamoDB có gateway
      endpoint
        ↓
    → cấu hình này không tạo được

⚠ Và DocumentDB còn không cần endpoint:

DocumentDB chạy TRONG VPC của bạn
        ↓
    Nó có ENI trong subnet của bạn
        ↓
    Truy cập qua mạng riêng tư sẵn
    → không cần VPC endpoint gì cả

⚠ Và DocumentDB cũng không có chế độ on-demand:

A nói "DocumentDB với on-demand
  capacity"
        ↓
    DocumentDB tính tiền theo instance
      -giờ
        ↓
    Có DocumentDB Elastic Clusters co
      giãn theo shard
        ↓
    Nhưng không phải "on-demand
      capacity" kiểu DynamoDB

⚠ Và vì sao phương án B không tốt bằng:

B dùng DocumentDB provisioned có auto
  scaling + interface endpoint
        ↓
    Nguồn là MongoDB dạng khoá–giá trị
        ↓
    Dùng DocumentDB là giữ nguyên API
        ↓
    Nhưng đề nhấn mạnh "co giãn theo
      tải bất thường"
    → DynamoDB on-demand phản ứng
      nhanh hơn nhiều so với việc thêm
      instance

Bảng chọn giữa DynamoDB và DocumentDB: | Nhu cầu | Chọn | |---|---| | Dùng như khoá–giá trị | DynamoDB | | Cần API MongoDB, truy vấn phức tạp | DocumentDB | | Co giãn tức thì theo tải | DynamoDB on-demand | | Không muốn viết lại mã | DocumentDB |

⚠ Và phải nhớ: chuyển sang DynamoDB LÀ phải sửa mã:

Đề nói CSDL dùng như khoá–giá trị
        ↓
    Đó là gợi ý DynamoDB phù hợp
        ↓
    Nhưng lời gọi MongoDB phải viết
      lại thành lời gọi DynamoDB
    → đây là cái giá không được nói ra
      trong đề

Ba lợi ích của đáp án: | Lợi ích | Chi tiết | |---|---| | Endpoint miễn phí | | | Không cần NAT gateway để gọi DynamoDB | | | Co giãn tức thì, không quản công suất | |

⚠ Và bỏ được NAT gateway là khoản tiết kiệm lớn:

NAT gateway: ~0,045 USD/giờ + 0,045
  USD/GB
        ↓
    Ứng dụng ghi nhiều vào DynamoDB
        ↓
    Phí xử lý dữ liệu qua NAT cộng dồn
      rất nhanh
    → gateway endpoint bỏ hẳn khoản
      này

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

• **C. DynamoDB on-demand + interface VPC endpoint — đây là phương án gần nhất và hoạt động được, nhưng gateway endpoint là lựa chọn chuẩn cho DynamoDB và hoàn toàn miễn phí, còn interface endpoint tính phí theo giờ mỗi AZ cộng phí theo GB.
• **B. DocumentDB provisioned có auto scaling + interface endpoint — DocumentDB chạy sẵn trong VPC nên không cần endpoint, và việc thêm instance phản ứng chậm hơn nhiều so với on-demand của DynamoDB.
• **A. DocumentDB + gateway VPC endpoint — chỉ S3 và DynamoDB có gateway endpoint; cấu hình này không tồn tại.

Ghi nhớ

⚠ Hai dịch vụ có gateway endpoint — bảng phải thuộc: | Dịch vụ | Loại endpoint | |---|---| | S3 | gateway (miễn phí) hoặc interface | | DynamoDB | gateway (miễn phí) hoặc interface | | Mọi dịch vụ khác | chỉ interface |

Từ khoá nhận diện:

"private access to DynamoDB, no internet" → gateway endpoint "access S3 from on-premises" → interface endpoint "unpredictable spiky workload" → on-demand "MongoDB compatible" → DocumentDB

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Phải gắn vào đúng route table | | | Không gắn security group | | | Không dùng được từ ngoài VPC | |

Ba lưu ý về chính sách endpoint: | Lưu ý | Chi tiết | |---|---| | Giới hạn tài nguyên gọi được qua endpoint | | | Mặc định cho phép tất cả | | | Kết hợp với aws:SourceVpce trong chính sách IAM | |

Ba lưu ý về DynamoDB on-demand: | Lưu ý | Chi tiết | |---|---| | Trần khởi đầu 4.000 ghi / 12.000 đọc mỗi giây | | | Cần ~30 phút để thích nghi tải mới | | | Đặt được trần tối đa để kiểm soát chi phí | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | DynamoDB chỉ nhận HTTPS | | | Mã hoá khi lưu bật mặc định, không tắt được | | | Dùng CMK nếu cần kiểm soát khoá | |

Ba lưu ý về chi phí mạng: | Lưu ý | Chi tiết | |---|---| | Gateway endpoint miễn phí | | | Bỏ được NAT gateway cho lưu lượng S3/DynamoDB | | | Interface endpoint tính theo giờ mỗi AZ | |

Ba lưu ý khi chuyển từ MongoDB: | Lưu ý | Chi tiết | |---|---| | DynamoDB đòi viết lại mã truy cập | | | Thiết kế khoá phân vùng quyết định hiệu năng | | | Không có JOIN, phải thiết kế lại mô hình | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi DynamoDB từ instance riêng tư | | | Kiểm route table có prefix list của DynamoDB | | | Xoá NAT gateway thử — DynamoDB vẫn phải gọi được | |

Và một lời khuyên: hãy kiểm tra endpoint đã gắn vào đúng route table của subnet riêng tư trước khi kết luận là nó không hoạt động. Gateway endpoint gắn nhầm route table không báo lỗi gì — ứng dụng chỉ đơn giản là hết thời gian chờ khi gọi DynamoDB, và triệu chứng đó trông y hệt như thiếu quyền IAM.

Đáp án

**D — Tạm dừng tiến trình Terminate của Auto Scaling group; dùng Session Manager đăng nhập vào một instance bị đánh dấu không khoẻ và phân tích log hệ thống.

Vì sao đúng

Vấn đề rất cụ thể: instance bị kết thúc trước khi kịp điều tra. Chỉ có một tiến trình chịu trách nhiệm cho việc kết thúc.

⚠ Điểm mấu chốt: tạm dừng đúng tiến trình gây ra vấn đề:

ALB đánh dấu instance không khoẻ
        ↓
    ASG nhận tín hiệu qua tiến trình
      `HealthCheck`
        ↓
    ASG kết thúc instance qua tiến
      trình `Terminate`
        ↓
    → dừng `Terminate` là instance
      còn nguyên để điều tra

aws autoscaling suspend-processes \
  --auto-scaling-group-name asg-ung-dung \
  --scaling-processes Terminate

Bảy tiến trình của Auto Scaling group: | Tiến trình | Việc | |---|---| | Launch | khởi chạy instance mới | | Terminate | kết thúc instance | | HealthCheck | kiểm tra sức khoẻ và đánh dấu | | ReplaceUnhealthy | kết thúc rồi thay instance hỏng | | AZRebalance | cân bằng lại giữa các AZ | | AlarmNotification | nhận cảnh báo co giãn | | ScheduledActions | hành động theo lịch |

⚠ Và ReplaceUnhealthy cũng cần cân nhắc dừng:

Dừng `Terminate` thôi
        ↓
    `ReplaceUnhealthy` vẫn muốn thay
      instance
        ↓
    Nhưng nó phải gọi `Terminate` để
      làm việc đó
        ↓
    → dừng `Terminate` là đủ chặn

⚠ Và vì sao phương án A sai — dừng Launch không cứu được instance:

A dừng tiến trình `Launch`
        ↓
    ASG không khởi chạy instance MỚI
        ↓
    Nhưng instance hỏng vẫn bị kết thúc
        ↓
    Kết quả tệ hơn: mất instance để
      điều tra VÀ không có máy thay thế
    → công suất giảm nhanh hơn

⚠ Và vì sao phương án C chỉ đúng một nửa:

C dừng `HealthCheck`
        ↓
    ASG ngừng ĐÁNH DẤU instance là
      không khoẻ
        ↓
    Instance đã bị đánh dấu TRƯỚC ĐÓ
      vẫn bị kết thúc
        ↓
    → chỉ ngăn ca mới, không cứu ca
      đang diễn ra

⚠ Và C còn dùng sai công cụ đăng nhập:

C dùng EC2 Instance Connect
        ↓
    Instance Connect đẩy khoá SSH tạm
      rồi kết nối qua SSH
        ↓
    Cần đường mạng tới cổng 22
        ↓
    Instance nằm trong subnet RIÊNG TƯ
    → không kết nối được từ ngoài

Bảng phân biệt ba cách vào instance: | Cách | Cần gì | |---|---| | SSH thường | cổng 22 mở, khoá, đường mạng | | EC2 Instance Connect | cổng 22 mở, đường mạng tới instance | | Instance Connect Endpoint | endpoint trong VPC, không cần IP công khai | | Session Manager | SSM Agent + quyền IAM, KHÔNG cần cổng nào |

⚠ Và Session Manager là cách duy nhất trong bốn phương án hợp với subnet riêng tư:

SSM Agent chủ động gọi RA tới
  Systems Manager
        ↓
    Kết nối đi ra, không phải đi vào
        ↓
    Không cần mở cổng 22
    → không cần IP công khai
    → không cần bastion host

aws ssm start-session --target i-abc123

⚠ Nhưng subnet riêng tư vẫn cần đường ra tới Systems Manager:

Qua NAT gateway
        ↓
    Hoặc qua ba interface endpoint:
      com.amazonaws.<region>.ssm
      com.amazonaws.<region>.ssmmessages
      com.amazonaws.<region>.ec2messages
        ↓
    Thiếu một trong ba → phiên không
      mở được

for dv in ssm ssmmessages ec2messages; do
  aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
    --vpc-endpoint-type Interface \
    --service-name com.amazonaws.ap-southeast-1.$dv \
    --subnet-ids subnet-a subnet-b \
    --security-group-ids sg-endpoint \
    --private-dns-enabled
done

⚠ Và ssmmessages là cái hay bị quên nhất:

Chỉ tạo endpoint `ssm`
        ↓
    Instance hiện ra trong danh sách
      managed instance
        ↓
    Nhưng `start-session` thất bại
        ↓
    Vì kênh phiên đi qua `ssmmessages`
    → triệu chứng gây hiểu lầm nhất

⚠ Và instance cần instance profile có quyền:

aws iam attach-role-policy \
  --role-name vai-tro-ec2 \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

⚠ Và vì sao phương án B không hoạt động:

B bật termination protection cho
  instance
        ↓
    Termination protection chỉ chặn
      lời gọi `TerminateInstances`
      TRỰC TIẾP
        ↓
    Auto Scaling group KHÔNG bị nó
      chặn
    → ASG vẫn kết thúc instance bình
      thường

⚠ Và đây là hiểu lầm rất phổ biến — phải nhớ:

Termination protection ≠ bảo vệ khỏi
  Auto Scaling
        ↓
    Muốn ASG không kết thúc một
      instance cụ thể
        ↓
    → dùng instance scale-in protection

aws autoscaling set-instance-protection \
  --auto-scaling-group-name asg-ung-dung \
  --instance-ids i-abc123 \
  --protected-from-scale-in

⚠ Nhưng scale-in protection cũng KHÔNG chặn việc thay instance hỏng:

Scale-in protection chỉ chặn kết thúc
  do THU NHỎ QUY MÔ
        ↓
    Instance bị đánh dấu không khoẻ
      vẫn bị thay
        ↓
    → vẫn phải dừng tiến trình
      `Terminate`

Bảng ba cơ chế bảo vệ dễ lẫn: | Cơ chế | Chặn được gì | |---|---| | Termination protection | lời gọi API trực tiếp | | Scale-in protection | kết thúc do thu nhỏ quy mô | | Tạm dừng Terminate | mọi kết thúc do ASG |

⚠ Và có cách tốt hơn cho lần sau: lifecycle hook:

aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name asg-ung-dung \
  --lifecycle-hook-name giu-lai-de-dieu-tra \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 3600 \
  --default-result CONTINUE

Instance sắp bị kết thúc
        ↓
    Chuyển sang trạng thái
      `Terminating:Wait`
        ↓
    Dừng ở đó tối đa một giờ
        ↓
    Đủ thời gian thu thập log tự động
    → và không phải can thiệp tay

⚠ Và cách bền vững nhất: đẩy log ra ngoài ngay từ đầu:

CloudWatch Agent gửi log hệ thống
        ↓
    `/var/log/messages`, `/var/log/cloud-init-output.log`
        ↓
    Instance chết → log vẫn còn
    → không bao giờ phải giữ instance
      lại nữa

{"logs": {"logs_collected": {"files": {"collect_list": [
  {"file_path": "/var/log/cloud-init-output.log",
   "log_group_name": "/ec2/khoi-dong",
   "log_stream_name": "{instance_id}"},
  {"file_path": "/var/log/ung-dung/loi.log",
   "log_group_name": "/ec2/ung-dung",
   "log_stream_name": "{instance_id}"}]}}}}

⚠ Và đừng quên khôi phục tiến trình sau khi điều tra xong:

aws autoscaling resume-processes \
  --auto-scaling-group-name asg-ung-dung \
  --scaling-processes Terminate

Quên khôi phục
        ↓
    Instance hỏng không bao giờ được
      thay
        ↓
    Công suất giảm dần
    → và ASG trông như vẫn hoạt động
      bình thường

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giữ được instance ở đúng trạng thái lỗi | | | Vào được dù nằm trong subnet riêng tư | | | Có ghi log phiên để kiểm toán | |

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

• **C. Tạm dừng HealthCheck + dùng EC2 Instance Connect — đây là phương án gần nhất và dừng HealthCheck thật sự ngăn được ca đánh dấu mới, nhưng instance đã bị đánh dấu trước đó vẫn bị kết thúc; và Instance Connect cần đường mạng tới cổng 22, không dùng được với subnet riêng tư.
• **A. Tạm dừng Launch — không ngăn được việc kết thúc, lại còn khiến công suất giảm nhanh hơn vì không có máy thay thế.
• **B. Bật termination protection — chỉ chặn lời gọi TerminateInstances trực tiếp, không chặn Auto Scaling group.

Ghi nhớ

⚠ Bốn cách giữ instance để điều tra — bảng phải thuộc: | Cách | Hiệu quả | |---|---| | Tạm dừng Terminate | chặn mọi kết thúc do ASG | | Lifecycle hook | giữ tối đa 1 giờ, tự động | | Scale-in protection | chỉ chặn thu nhỏ quy mô | | Termination protection | KHÔNG chặn ASG |

Từ khoá nhận diện:

"instances terminated before investigation" → suspend Terminate "private subnet, no bastion" → Session Manager "collect data before termination" → lifecycle hook "logs lost when instance dies" → CloudWatch Agent

Ba lưu ý về Session Manager: | Lưu ý | Chi tiết | |---|---| | Không cần mở cổng nào | | | Cần AmazonSSMManagedInstanceCore | | | Ghi log phiên vào S3 hoặc CloudWatch | |

Ba endpoint cần cho Session Manager trong subnet riêng tư:

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages

Ba lưu ý về lifecycle hook: | Lưu ý | Chi tiết | |---|---| | Chặn ở Pending:Wait hoặc Terminating:Wait | | | Heartbeat tối đa 100 giờ | | | complete-lifecycle-action để đi tiếp sớm | |

Ba lưu ý về health check: | Loại | Kiểm gì | |---|---| | EC2 | trạng thái instance | | ELB | health check của target group | | Grace period | thời gian bỏ qua sau khi khởi chạy |

⚠ Grace period quá ngắn gây vòng lặp chết:

Ứng dụng cần 5 phút để khởi động
        ↓
    Grace period 300 giây vừa đủ
        ↓
    Bản mới khởi động chậm hơn
    → bị giết trước khi sẵn sàng
    → ASG dựng máy mới, lặp lại mãi

Ba lưu ý về ghi log: | Lưu ý | Chi tiết | |---|---| | Đẩy log ra ngoài trước khi cần | | | Bao gồm cloud-init-output.log | | | Đặt log stream theo instance id | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm suspended-processes trong describe-auto-scaling-groups | | | Mở phiên Session Manager thử | | | Nhớ khôi phục tiến trình sau khi xong | |

Và một lời khuyên: hãy kiểm tra cloud-init-output.log trước tiên khi instance bị đánh dấu không khoẻ sau một lần phát hành. Log ứng dụng thường không có gì vì ứng dụng chưa kịp khởi động — nguyên nhân thật hay nằm ở một script khởi tạo thất bại, và đó là tệp duy nhất ghi lại chuyện đó.

Đáp án

**C — Storage Gateway không tự cập nhật cache khi tải tệp thẳng lên Amazon S3; hãy thực hiện thao tác RefreshCache để thấy thay đổi trên file share.

Vì sao đúng

File gateway giữ một bản kê nội dung của bucket. Bản kê đó chỉ cập nhật khi có thay đổi đi qua gateway.

⚠ Điểm mấu chốt: hai đường ghi vào cùng một bucket:

Đường 1: client → file share → gateway
                                → S3
        ↓
    Gateway biết mọi thay đổi
        ↓
Đường 2: ai đó → API S3 trực tiếp → S3
        ↓
    Gateway KHÔNG biết gì
    → cache lệch với thực tế

⚠ Và triệu chứng rất cụ thể:

Tệp đã xoá trên S3
        ↓
    Vẫn hiện trên file share
        ↓
    Mở ra → lỗi
        ↓
    Tệp mới thêm trên S3
        ↓
    Không thấy trên file share

Gọi làm mới cache:

aws storagegateway refresh-cache \
  --file-share-arn arn:aws:storagegateway:ap-southeast-1:111122223333:share/share-ABC \
  --folder-list "/" \
  --recursive true

⚠ Và RefreshCache là bất đồng bộ:

Lệnh trả về ngay
        ↓
    Việc quét chạy nền
        ↓
    Bucket lớn → mất khá lâu
        ↓
    Theo dõi bằng thông báo hoàn tất

aws storagegateway describe-notification-configuration \
  --file-share-arn <arn-share>

⚠ Và làm mới đệ quy trên bucket lớn rất tốn:

`--recursive true` từ gốc
        ↓
    Liệt kê MỌI object
        ↓
    Hàng triệu object → nhiều lời gọi
      `ListObjects`
        ↓
    Tốn tiền và tốn thời gian
    → chỉ làm mới đúng thư mục cần

aws storagegateway refresh-cache \
  --file-share-arn <arn-share> \
  --folder-list "/du-lieu/2026/09" \
  --recursive false

⚠ Và vì sao phương án B sai — không có ResetCache cho việc này:

B nói dùng `ResetCache`
        ↓
    `ResetCache` có tồn tại, nhưng nó
      XOÁ SẠCH đĩa cache
        ↓
    Dùng khi đĩa cache hỏng
        ↓
    Và nó LÀM MẤT dữ liệu chưa tải
      lên S3
    → thao tác nguy hiểm, không phải
      thao tác làm mới

Bảng phân biệt hai thao tác: | Thao tác | Làm gì | Rủi ro | |---|---|---| | RefreshCache | quét S3, cập nhật bản kê | không | | ResetCache | xoá sạch đĩa cache | mất dữ liệu chưa tải lên |

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

A nói versioning gây lỗi cache
        ↓
    Versioning không liên quan tới
      việc gateway biết hay không biết
      thay đổi
        ↓
    Và tắt versioning làm mất khả năng
      khôi phục khi xoá nhầm
    → chữa sai bệnh, lại bỏ mất một
      lớp bảo vệ

⚠ Và vì sao phương án D sai:

D nói sửa bucket policy để cache tự
  làm mới
        ↓
    Không có quyền nào bật được hành
      vi đó
        ↓
    Đây là giới hạn thiết kế, không
      phải vấn đề quyền

⚠ Và có cách tự động hoá: bật tự làm mới theo lịch:

aws storagegateway update-nfs-file-share \
  --file-share-arn <arn-share> \
  --cache-attributes CacheStaleTimeoutInSeconds=300

Gateway tự làm mới bản kê khi nó cũ
  hơn ngưỡng
        ↓
    Tối thiểu 300 giây
        ↓
    Đánh đổi: làm mới thường xuyên →
      nhiều lời gọi `ListObjects` →
      tốn tiền

⚠ Và cách phản ứng nhanh hơn: kích hoạt theo sự kiện S3:

S3 Event Notification khi có object
  mới
        ↓
    → Lambda gọi `RefreshCache` cho
      đúng thư mục đó
        ↓
    Cập nhật trong vài giây
    → và không quét toàn bộ bucket

import boto3, os

sgw = boto3.client('storagegateway')

def handler(su_kien, ngu_canh):
    thu_muc = set()
    for ban_ghi in su_kien['Records']:
        khoa = ban_ghi['s3']['object']['key']
        thu_muc.add('/' + os.path.dirname(khoa))
    sgw.refresh_cache(
        FileShareARN=os.environ['ARN_SHARE'],
        FolderList=sorted(thu_muc),
        Recursive=False)

⚠ Và có giới hạn tần suất gọi RefreshCache:

Không gọi liên tục được
        ↓
    Gọi quá dày → bị throttle
        ↓
    Gom các sự kiện lại rồi gọi một
      lần
    → dùng SQS làm bộ đệm là cách hay

⚠ Và bản chất vấn đề: file gateway không phải hệ thống tệp hai chiều:

Nó là lớp truy cập S3 kiểu tệp
        ↓
    Nguồn sự thật là S3
        ↓
    Nhưng gateway giữ bản kê riêng
        ↓
    → thiết kế nên chọn MỘT đường ghi

Ba mẫu dùng đúng: | Mẫu | Có cần làm mới | |---|---| | Chỉ ghi qua gateway | không | | Ghi qua S3, đọc qua gateway | có, luôn cần | | Ghi cả hai đường | có, và dễ xung đột |

⚠ Và ghi cả hai đường có rủi ro mất dữ liệu:

Client ghi tệp qua gateway (đang
  trong cache, chưa lên S3)
        ↓
    Cùng lúc ai đó ghi đè cùng khoá
      trên S3
        ↓
    Gateway tải bản của nó lên
        ↓
    → ghi đè bản kia, không cảnh báo

⚠ Và cần biết độ trễ tải lên:

aws cloudwatch get-metric-statistics \
  --namespace AWS/StorageGateway \
  --metric-name CachePercentDirty \
  --dimensions Name=GatewayId,Value=sgw-abc \
  --statistics Average --period 300 \
  --start-time 2026-09-01T00:00:00Z \
  --end-time 2026-09-01T12:00:00Z

`CachePercentDirty` cao
        ↓
    Nhiều dữ liệu chưa lên S3
        ↓
    Băng thông không đủ hoặc ghi quá
      nhanh
    → và đó là lúc `ResetCache` sẽ
      gây mất dữ liệu thật

Ba lợi ích của RefreshCache: | Lợi ích | Chi tiết | |---|---| | Không mất dữ liệu | | | Làm mới được từng thư mục | | | Tự động hoá được bằng sự kiện S3 | |

⚠ Và cân nhắc Mountpoint for Amazon S3 nếu chỉ cần đọc:

Mountpoint đọc thẳng từ S3
        ↓
    Không có cache bản kê
        ↓
    Luôn thấy trạng thái hiện tại
        ↓
    Nhưng không hỗ trợ đầy đủ POSIX
    → hợp với đọc tuần tự, không hợp
      với chia sẻ tệp truyền thống

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

• **B. Storage Gateway không tự cập nhật cache; thực hiện ResetCache — đây là phương án gần nhất và nửa đầu chẩn đoán hoàn toàn đúng, nhưng ResetCache xoá sạch đĩa cache và làm mất mọi dữ liệu chưa kịp tải lên S3; thao tác đúng là RefreshCache.
• **A. Tắt versioning trên bucket — versioning không liên quan tới việc gateway biết hay không biết thay đổi, và tắt nó bỏ mất một lớp bảo vệ.
• **D. Sửa bucket policy để cho phép cache tự làm mới — không có quyền nào bật được hành vi đó; đây là giới hạn thiết kế, không phải vấn đề quyền.

Ghi nhớ

⚠ Bốn điều về cache của file gateway — bảng phải thuộc: | Điều | Chi tiết | |---|---| | Ghi qua gateway | cache tự đúng | | Ghi thẳng vào S3 | phải RefreshCache | | RefreshCache | an toàn, bất đồng bộ | | ResetCache | xoá sạch, mất dữ liệu chưa tải lên |

Từ khoá nhận diện:

"changes made directly in S3 not visible" → RefreshCache "cache disk failed" → ResetCache "automate cache refresh" → S3 event → Lambda "read-only access to S3 as files" → Mountpoint for S3

Ba lưu ý về RefreshCache: | Lưu ý | Chi tiết | |---|---| | Bất đồng bộ, có thông báo hoàn tất | | | Làm mới theo thư mục để tiết kiệm | | | Có giới hạn tần suất gọi | |

Ba lưu ý về CacheStaleTimeout: | Lưu ý | Chi tiết | |---|---| | Tối thiểu 300 giây | | | Đặt ngắn → nhiều lời gọi ListObjects | | | Không có nghĩa là làm mới tức thì | |

Ba lưu ý về thiết kế: | Lưu ý | Chi tiết | |---|---| | Chọn một đường ghi duy nhất | | | Ghi hai đường dễ ghi đè lẫn nhau | | | S3 là nguồn sự thật | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | CachePercentDirty | dữ liệu chưa lên S3 | | CachePercentUsed | đĩa cache còn chỗ không | | CloudBytesUploaded | lượng đã tải lên |

Ba lưu ý về đĩa cache: | Lưu ý | Chi tiết | |---|---| | Tối thiểu 150 GB | | | Nên bằng ~20% dữ liệu hay dùng | | | Thêm được, không bớt được | |

Ba lưu ý về loại gateway: | Loại | Dùng cho | |---|---| | File gateway (S3) | NFS/SMB trên S3 | | FSx File Gateway | cache của FSx Windows | | Volume, Tape gateway | iSCSI, sao lưu băng từ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thêm tệp qua API S3, gọi refresh, kiểm file share | | | Xem CachePercentDirty trước khi thao tác nguy hiểm | | | Đo thời gian refresh trên thư mục lớn | |

Và một lời khuyên: hãy kiểm tra CachePercentDirty trước khi chạy bất kỳ thao tác nào nhắc tới chữ "reset". Chỉ số đó cho biết còn bao nhiêu dữ liệu chưa kịp lên S3 — và đó chính xác là phần sẽ biến mất vĩnh viễn nếu bạn chọn nhầm thao tác.

Đáp án

**A — Dùng AWS WAF làm tuyến phòng thủ đầu tiên bảo vệ API của API Gateway khỏi khai thác độc hại và tấn công DDoS; cài Amazon Inspector trên instance EC2 để kiểm lỗ hổng; cấu hình Amazon GuardDuty để GIÁM SÁT mọi nỗ lực truy cập trái phép.

Vì sao đúng

Ba dịch vụ, ba việc khác nhau, và mỗi cái ở đúng chỗ: | Dịch vụ | Việc | |---|---| | WAF | chặn yêu cầu độc hại ở tầng 7 | | Inspector | tìm lỗ hổng phần mềm trên EC2 | | GuardDuty | PHÁT HIỆN hành vi đe doạ |

⚠ Điểm mấu chốt: GuardDuty PHÁT HIỆN, không CHẶN:

GuardDuty phân tích:
    - CloudTrail
    - VPC Flow Logs
    - DNS logs
    - S3 data events
        ↓
    Sinh ra "finding"
        ↓
    Và DỪNG ở đó
    → nó không đứng trên đường đi của
      gói tin nào cả

Đây là khác biệt duy nhất giữa
  phương án A và B:
        ↓
    A viết "monitor"  → ĐÚNG
    B viết "block"    → SAI

⚠ Và vì sao GuardDuty không thể chặn:

Nó đọc log
        ↓
    Log được ghi SAU khi sự việc xảy
      ra
        ↓
    Độ trễ tính bằng phút
        ↓
    → về mặt kiến trúc không thể chặn
      theo thời gian thực

Bảng phân biệt: chặn hay phát hiện: | Dịch vụ | Vị trí | Chặn được | |---|---|---| | WAF | trên đường đi | có | | Shield | trên đường đi | có | | Network Firewall | trên đường đi | có | | Security group / NACL | trên đường đi | có | | GuardDuty | ngoài đường đi | không | | Inspector | ngoài đường đi | không | | Config | ngoài đường đi | không |

⚠ Nhưng GuardDuty NỐI được với hành động chặn:

GuardDuty sinh finding
        ↓
    EventBridge bắt được
        ↓
    Lambda thêm IP vào WAF IP set
        ↓
    → chặn được, nhưng là do WAF chặn
    → không phải GuardDuty

aws events put-rule --name phan-ung-guardduty \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {"severity": [{"numeric": [">=", 7]}]}}'

import boto3, os

waf = boto3.client('wafv2')

def handler(su_kien, ngu_canh):
    ip = su_kien['detail']['service']['action'] \
        .get('networkConnectionAction', {}) \
        .get('remoteIpDetails', {}).get('ipAddressV4')
    if not ip:
        return
    hien_tai = waf.get_ip_set(Name='chan-tu-dong', Scope='REGIONAL',
                             Id=os.environ['ID_IPSET'])
    dia_chi = hien_tai['IPSet']['Addresses']
    moi = f'{ip}/32'
    if moi in dia_chi:
        return
    waf.update_ip_set(Name='chan-tu-dong', Scope='REGIONAL',
                      Id=os.environ['ID_IPSET'],
                      Addresses=dia_chi + [moi],
                      LockToken=hien_tai['LockToken'])

⚠ Và LockToken là chi tiết bắt buộc của WAFv2:

Mọi lệnh cập nhật WAFv2 cần
  `LockToken` từ lần đọc gần nhất
        ↓
    Đây là cơ chế khoá lạc quan
        ↓
    Hai tiến trình sửa cùng lúc → cái
      sau bị từ chối
    → phải đọc lại rồi thử lại

⚠ Và vì sao phương án C sai — Network Firewall không gắn vào API Gateway:

C nói bật Network Firewall trên API
  Gateway và EC2
        ↓
    Network Firewall làm việc ở tầng
      VPC
        ↓
    Nó lọc lưu lượng đi qua subnet
        ↓
    API Gateway là dịch vụ toàn cục,
      không nằm trong VPC của bạn
    → không gắn được

⚠ Và Network Firewall cũng không tìm lỗ hổng:

C nói nó "kiểm tra lỗ hổng"
        ↓
    Network Firewall lọc lưu lượng
        ↓
    Nó không quét phần mềm cài trên
      máy
    → đó là việc của Inspector

Bảng ba loại firewall trên AWS: | Firewall | Tầng | Gắn vào | |---|---|---| | WAF | 7 (HTTP) | CloudFront, ALB, API Gateway, AppSync | | Network Firewall | 3-7 | subnet trong VPC | | Security group | 3-4 | ENI |

⚠ Và vì sao phương án D đảo ngược vai trò:

D nói "cài GuardDuty trên EC2 để
  đánh giá lỗ hổng"
        ↓
    GuardDuty không cài trên máy nào
        ↓
    Nó là dịch vụ đọc log, không có
      agent
        ↓
    Và nó không quét lỗ hổng
    → hai sai lầm trong một câu

⚠ Và Inspector mới là cái có agent:

Inspector dùng SSM Agent
        ↓
    Đọc danh sách gói phần mềm đã cài
        ↓
    Đối chiếu với cơ sở dữ liệu CVE
        ↓
    → báo lỗ hổng kèm mức nghiêm trọng
      và cách vá

aws inspector2 enable --resource-types EC2 ECR LAMBDA

⚠ Và Inspector giờ quét được cả không cần agent:

Agentless scanning cho EC2
        ↓
    Chụp snapshot EBS rồi quét
        ↓
    Không cần cài gì trên instance
        ↓
    Hợp với máy không cài được SSM
      Agent

Gắn WAF vào API Gateway:

aws wafv2 create-web-acl \
  --name bao-ve-api --scope REGIONAL \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=baoVeApi \
  --rules file://luat.json

aws wafv2 associate-web-acl \
  --web-acl-arn <arn-web-acl> \
  --resource-arn arn:aws:apigateway:ap-southeast-1::/restapis/abc123/stages/prod

⚠ Và --scope REGIONAL là bắt buộc cho API Gateway: | Scope | Dùng cho | |---|---| | CLOUDFRONT | chỉ CloudFront, phải tạo ở us-east-1 | | REGIONAL | ALB, API Gateway, AppSync, Cognito |

Ba nhóm luật quản lý nên bật:

AWSManagedRulesCommonRuleSet
AWSManagedRulesKnownBadInputsRuleSet
AWSManagedRulesAmazonIpReputationList

⚠ Và rate-based rule là thứ chống DDoS tầng ứng dụng:

{"Name": "chan-flood",
 "Priority": 10,
 "Statement": {"RateBasedStatement": {
   "Limit": 2000,
   "AggregateKeyType": "IP"}},
 "Action": {"Block": {}},
 "VisibilityConfig": {"SampledRequestsEnabled": true,
   "CloudWatchMetricsEnabled": true, "MetricName": "chanFlood"}}

⚠ Và WAF chống được DDoS tầng 7, Shield chống tầng 3/4:

Shield Standard: miễn phí, tự bật cho
  CloudFront, Route 53, ELB
        ↓
    Chống SYN flood, UDP reflection
        ↓
    WAF: chống HTTP flood, bot
        ↓
    → hai tầng khác nhau, cần cả hai

⚠ Và API cũ trên EC2 cũng bảo vệ được bằng WAF:

Đặt ALB trước instance EC2
        ↓
    Gắn cùng web ACL vào ALB
        ↓
    → API cũ được bảo vệ như API mới
    → đề không nói điều này nhưng đây
      là việc nên làm

Ba lợi ích của tổ hợp: | Lợi ích | Chi tiết | |---|---| | Chặn ở tầng 7 trước khi tới ứng dụng | | | Biết máy đang chạy phần mềm có lỗ hổng nào | | | Phát hiện hành vi bất thường qua log | |

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

• **B. Giống A nhưng nói GuardDuty "chặn" các nỗ lực truy cập trái phép — đây là phương án gần nhất và chỉ khác một từ, nhưng GuardDuty là dịch vụ phát hiện dựa trên phân tích log, nằm ngoài đường đi của lưu lượng nên không chặn được gì; muốn chặn phải nối nó với WAF hoặc security group qua EventBridge.
• **C. Bật Network Firewall trên API Gateway và EC2 để kiểm lỗ hổng và chống DDoS — Network Firewall gắn vào subnet trong VPC, không gắn được vào API Gateway, và nó lọc lưu lượng chứ không quét lỗ hổng.
• **D. CloudFront chống khai thác + cài GuardDuty trên EC2 đánh giá lỗ hổng — GuardDuty không có agent cài trên máy và không quét lỗ hổng.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật và vị trí của chúng — bảng phải thuộc: | Dịch vụ | Trên đường đi | Việc | |---|---|---| | WAF | có | chặn yêu cầu HTTP xấu | | Shield | có | chống DDoS tầng 3/4 | | GuardDuty | không | phát hiện qua log | | Inspector | không | quét lỗ hổng phần mềm |

Từ khoá nhận diện:

"GuardDuty blocks" → LUÔN SAI "protect API Gateway from exploits" → WAF scope REGIONAL "find CVEs on EC2" → Inspector "auto-block IPs from findings" → GuardDuty → EventBridge → WAF

Ba lưu ý về WAF: | Lưu ý | Chi tiết | |---|---| | CLOUDFRONT scope phải tạo ở us-east-1 | | | Rate-based rule chống HTTP flood | | | Bật nhóm luật quản lý trước khi tự viết | |

Ba lưu ý về GuardDuty: | Lưu ý | Chi tiết | |---|---| | Không cần agent, đọc log sẵn có | | | Bật ở mọi Region đang dùng | | | Nối EventBridge để phản ứng tự động | |

Ba lưu ý về Inspector: | Lưu ý | Chi tiết | |---|---| | Quét EC2, container ECR, Lambda | | | Có cả chế độ không cần agent | | | Network Reachability không cần agent | |

Ba lưu ý về Network Firewall: | Lưu ý | Chi tiết | |---|---| | Gắn vào subnet trong VPC | | | Luật kiểu Suricata | | | Lọc được cả tên miền ra ngoài | |

Ba lưu ý về phản ứng tự động: | Lưu ý | Chi tiết | |---|---| | Lọc theo severity trước khi hành động | | | LockToken bắt buộc khi sửa WAFv2 | | | Có cơ chế gỡ chặn sau thời gian | |

⚠ Chặn vĩnh viễn theo IP là bẫy:

IP bị chặn nằm trong IP set mãi mãi
        ↓
    IP đó được cấp lại cho người khác
        ↓
    Khách hàng thật bị chặn
    → luôn có TTL cho mục chặn tự động

Ba lưu ý về nhiều tầng phòng thủ: | Tầng | Dịch vụ | |---|---| | Biên | Shield + WAF + CloudFront | | Mạng | security group, NACL, Network Firewall | | Máy | Inspector, SSM Patch Manager |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi yêu cầu SQL injection thử — WAF phải chặn | | | Xem list-findings của Inspector | | | Tạo finding mẫu của GuardDuty để thử luồng cảnh báo | |

Và một lời khuyên: hãy tạo finding mẫu bằng create-sample-findings để kiểm thử toàn bộ luồng phản ứng. Rất nhiều đội chỉ phát hiện ra rằng quy tắc EventBridge lọc sai hoặc Lambda thiếu quyền vào đúng lúc có sự cố thật — và đó là thời điểm tệ nhất để phát hiện.

Đáp án

**C và E — Tạo quy tắc RA (outbound) trong security group của EC2 dùng TCP cổng 3306, đích là security group của MySQL; và tạo quy tắc VÀO (inbound) trong security group của MySQL dùng TCP cổng 3306, nguồn là security group của EC2.

Vì sao đúng

Đề nói rõ hai security group hiện không có quy tắc nào cả — cả vào lẫn ra. Đó là chi tiết quyết định.

⚠ Điểm mấu chốt: security group mặc định cho phép MỌI lưu lượng RA:

Tạo security group mới
        ↓
    Inbound: rỗng (chặn hết)
    Outbound: cho phép tất cả
        ↓
    Nhưng đề nói outbound cũng RỖNG
        ↓
    → ai đó đã xoá quy tắc mặc định
    → phải khai lại tường minh

⚠ Và vì thế câu này cần HAI quy tắc, không phải một:

Bình thường chỉ cần inbound của CSDL
        ↓
    Vì outbound của EC2 đã mở sẵn
        ↓
    Ở đây outbound rỗng
    → phải mở đường ra cho EC2 nữa

Luồng gói tin đầy đủ:

Ứng dụng gọi CSDL
        ↓
1. Ra khỏi EC2 → security group EC2
     kiểm OUTBOUND
        ↓
2. Tới CSDL → security group MySQL
     kiểm INBOUND
        ↓
3. Phản hồi về → cả hai chiều được
     cho phép TỰ ĐỘNG (stateful)

⚠ Và đây là lý do các phương án về cổng phù du đều sai:

B và D khai quy tắc cho dải cổng phù
  du
        ↓
    Đó là cách nghĩ của NACL
        ↓
    Security group là STATEFUL
        ↓
    Phản hồi tự được cho phép
    → khai cổng phù du là mở rộng
      quyền không cần thiết

Bảng so sánh: | | Security Group | Network ACL | |---|---|---| | Trạng thái | stateful | stateless | | Cần khai cổng phù du | KHÔNG | CÓ | | Loại quy tắc | chỉ Allow | Allow và Deny | | Phạm vi | ENI | subnet |

⚠ Và vì sao phương án A sai về chiều:

A tạo quy tắc RA trên security group
  của MySQL, đích là EC2
        ↓
    CSDL không chủ động gọi ứng dụng
        ↓
    Phản hồi đã được cho phép tự động
        ↓
    → quy tắc này không cần và ngược
      luồng

Tạo hai quy tắc đúng:

aws ec2 authorize-security-group-egress \
  --group-id sg-may-chu-ung-dung \
  --ip-permissions '[{
    "IpProtocol": "tcp", "FromPort": 3306, "ToPort": 3306,
    "UserIdGroupPairs": [{"GroupId": "sg-csdl-mysql",
      "Description": "Goi MySQL"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-csdl-mysql \
  --ip-permissions '[{
    "IpProtocol": "tcp", "FromPort": 3306, "ToPort": 3306,
    "UserIdGroupPairs": [{"GroupId": "sg-may-chu-ung-dung",
      "Description": "Tu tang ung dung"}]}]'

⚠ Và tham chiếu security group chặt hơn khai dải CIDR:

Khai `10.0.1.0/24`
        ↓
    Mọi thứ trong subnet đó vào được
        ↓
    Kể cả instance không thuộc tầng
      ứng dụng
        ↓
    Tham chiếu `sg-may-chu-ung-dung`
    → chỉ ENI gắn đúng group đó

⚠ Và nó tự đúng khi Auto Scaling thay instance:

Instance mới khởi chạy
        ↓
    Có IP khác
        ↓
    Nhưng gắn cùng security group
        ↓
    → quy tắc vẫn áp, không phải sửa
      gì

⚠ Và tham chiếu chéo hai chiều tạo ra vòng phụ thuộc khi dựng bằng IaC:

sg-ung-dung tham chiếu sg-csdl
        ↓
    sg-csdl tham chiếu sg-ung-dung
        ↓
    CloudFormation không tạo được
        ↓
    → tạo hai security group rỗng
      trước
    → rồi thêm quy tắc bằng tài nguyên
      riêng

Resources:
  SgUngDung:
    Type: AWS::EC2::SecurityGroup
    Properties: {GroupDescription: Tang ung dung, VpcId: !Ref Vpc}
  SgCsdl:
    Type: AWS::EC2::SecurityGroup
    Properties: {GroupDescription: Tang CSDL, VpcId: !Ref Vpc}
  ChoPhepVaoCsdl:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !Ref SgCsdl
      IpProtocol: tcp
      FromPort: 3306
      ToPort: 3306
      SourceSecurityGroupId: !Ref SgUngDung
  ChoPhepRaUngDung:
    Type: AWS::EC2::SecurityGroupEgress
    Properties:
      GroupId: !Ref SgUngDung
      IpProtocol: tcp
      FromPort: 3306
      ToPort: 3306
      DestinationSecurityGroupId: !Ref SgCsdl

⚠ Và xoá quy tắc outbound mặc định có hệ quả rộng:

Outbound rỗng nghĩa là EC2 không gọi
  được:
      - Systems Manager (mất Session
        Manager)
      - CloudWatch (mất log và metric)
      - S3, Secrets Manager
      - kho gói phần mềm để vá
        ↓
    → phải khai từng đường ra cần
      thiết

Bộ quy tắc outbound thực tế cho tầng ứng dụng:

# Tới CSDL
--ip-permissions IpProtocol=tcp,FromPort=3306,ToPort=3306,\
UserIdGroupPairs='[{GroupId=sg-csdl-mysql}]'

# Tới VPC endpoint của SSM, S3...
--ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,\
PrefixListIds='[{PrefixListId=pl-s3}]'

⚠ Và prefix list là cách gọn để khai đích là dịch vụ AWS:

aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.ap-southeast-1.s3

Thay vì khai hàng chục dải IP
        ↓
    Khai một prefix list
        ↓
    AWS tự cập nhật khi dải IP đổi

⚠ Và nên đặt mô tả cho mọi quy tắc:

`Description` cho biết vì sao quy tắc
  tồn tại
        ↓
    Sáu tháng sau không ai dám xoá
      quy tắc không rõ mục đích
    → và security group cứ phình ra

⚠ Và có công cụ tìm quy tắc thừa:

aws ec2 describe-security-group-rules \
  --filters Name=group-id,Values=sg-abc

Đối chiếu với VPC Flow Log
        ↓
    Quy tắc không có lưu lượng nào
      khớp trong 90 ngày
    → ứng viên để xoá

Ba lợi ích của cách này: | Lợi ích | Chi tiết | |---|---| | Đúng nguyên tắc đặc quyền tối thiểu | | | Tự đúng khi instance thay đổi | | | Đọc là hiểu ngay kiến trúc tầng | |

⚠ Và mẫu ba tầng chuẩn nên thuộc:

sg-alb:  vào 443 từ 0.0.0.0/0
         ra 80 tới sg-ung-dung
        ↓
sg-ung-dung: vào 80 từ sg-alb
             ra 3306 tới sg-csdl
        ↓
sg-csdl: vào 3306 từ sg-ung-dung
         ra: không có gì

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

• **B. Quy tắc RA trên security group của EC2 dùng dải cổng phù du — đây là phương án gần nhất và cách nghĩ về cổng phù du là đúng với NACL, nhưng security group là stateful nên phản hồi được cho phép tự động; khai dải cổng phù du chỉ mở rộng quyền không cần thiết.
• **D. Quy tắc RA trên security group của MySQL dùng dải cổng phù du — sai cả chiều lẫn cách hiểu về stateful.
• **A. Quy tắc RA trên security group của MySQL cổng 3306 tới EC2 — CSDL không chủ động gọi ứng dụng ở cổng 3306; quy tắc này ngược luồng.

Ghi nhớ

⚠ Bốn điều về security group — bảng phải thuộc: | Điều | Chi tiết | |---|---| | Stateful | phản hồi tự được cho phép | | Chỉ có Allow | không có Deny | | Mặc định outbound mở | inbound đóng | | Tham chiếu được group khác | trong cùng VPC hoặc VPC peering |

Từ khoá nhận diện:

"least privilege between tiers" → tham chiếu security group, cổng dịch vụ "ephemeral port range" → NACL, KHÔNG phải security group "no rules configured currently" → phải khai cả outbound "instances change IP" → tham chiếu security group

Ba lưu ý về tham chiếu security group: | Lưu ý | Chi tiết | |---|---| | Chỉ cùng VPC hoặc VPC đã peering | | | Không qua Transit Gateway | | | Tự đúng khi ENI thêm bớt | |

Ba lưu ý về outbound: | Lưu ý | Chi tiết | |---|---| | Mặc định cho phép tất cả | | | Xoá đi thì mất luôn đường tới SSM, CloudWatch | | | Dùng prefix list cho dịch vụ AWS | |

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | Quy tắc mỗi security group | 60 vào, 60 ra | | Security group mỗi ENI | 5 (nâng tới 16) | | Tổng quy tắc mỗi ENI | 1.000 |

Ba lưu ý về IaC: | Lưu ý | Chi tiết | |---|---| | Tham chiếu chéo gây vòng phụ thuộc | | | Tách quy tắc thành tài nguyên riêng | | | Luôn đặt Description | |

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Stateless — phải khai cả hai chiều | | | Cần dải cổng phù du cho phản hồi | | | Đánh giá theo số thứ tự | |

Ba lưu ý về rà soát: | Lưu ý | Chi tiết | |---|---| | Đối chiếu quy tắc với Flow Log | | | Config rule cảnh báo 0.0.0.0/0 | | | Xoá quy tắc không còn lưu lượng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối từ EC2 tới CSDL — phải được | | | Kết nối từ máy khác trong subnet — phải hỏng | | | Chạy Reachability Analyzer | |

Và một lời khuyên: hãy nhớ rằng "cổng phù du" là dấu hiệu của NACL chứ không phải security group. Đề bài hay đưa phương án nhắc tới dải cổng phù du để thử xem bạn có nắm được tính stateful hay không — và trong security group, mọi quy tắc liên quan tới cổng phù du đều là quy tắc thừa.

Đáp án

**B — Dùng AWS Direct Connect kết hợp site-to-site VPN để dựng kết nối giữa trung tâm dữ liệu và AWS Cloud.

Vì sao đúng

Đề đòi bốn tính chất cùng lúc, và chỉ tổ hợp này đủ cả bốn: | Tính chất | Ai lo | |---|---| | Riêng, không đi Internet công cộng | Direct Connect | | Độ trễ thấp và ổn định | Direct Connect | | Thông lượng cao | Direct Connect | | ĐƯỢC MÃ HOÁ | VPN chạy trên Direct Connect |

⚠ Điểm mấu chốt: Direct Connect KHÔNG mã hoá:

Direct Connect là kết nối vật lý
  riêng
        ↓
    Lưu lượng không đi qua Internet
      công cộng
        ↓
    Nhưng nó là dữ liệu THÔ trên dây
        ↓
    → riêng tư ≠ được mã hoá

Ai chạm được vào đường truyền vật lý
        ↓
    Đọc được nội dung
        ↓
    Với dữ liệu tuân thủ quy định
    → phải mã hoá bằng cách nào đó

⚠ Và đây là lý do phương án A không đủ:

A chỉ dùng Direct Connect
        ↓
    Có riêng tư, độ trễ thấp, thông
      lượng cao
        ↓
    Nhưng đề nói rõ "được mã hoá"
    → thiếu đúng một tính chất

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

C chỉ dùng site-to-site VPN
        ↓
    Có mã hoá IPsec
        ↓
    Nhưng chạy trên Internet công cộng
        ↓
    Độ trễ dao động theo tình trạng
      mạng
        ↓
    Và mỗi đường hầm giới hạn ~1,25
      Gbps
    → không phải "thông lượng cao, độ
      trễ thấp"

Bảng so sánh ba lựa chọn: | | Direct Connect | VPN | DX + VPN | |---|---|---|---| | Mã hoá | không | có | có | | Độ trễ | thấp, ổn định | dao động | thấp, ổn định | | Thông lượng | tới 100 Gbps | ~1,25 Gbps mỗi đường hầm | cao | | Thời gian lắp đặt | tuần tới tháng | phút | tuần tới tháng | | Chi phí | cao | thấp | cao |

⚠ Và đề đã nói trước rằng thời gian lắp đặt không phải vấn đề:

"Đội đã dành đủ thời gian cho chi phí
  vận hành của việc dựng kết nối này"
        ↓
    → loại bỏ lý do "Direct Connect
      mất nhiều tuần"
    → câu này chỉ hỏi về tính chất kỹ
      thuật

Cách dựng VPN trên Direct Connect:

1. Dựng Direct Connect với PUBLIC VIF
        ↓
2. Public VIF cho phép tới các endpoint
     công khai của AWS
        ↓
3. Dựng site-to-site VPN tới virtual
     private gateway
        ↓
4. Lưu lượng VPN đi qua đường Direct
     Connect, không qua Internet

aws directconnect create-public-virtual-interface \
  --connection-id dxcon-abc \
  --new-public-virtual-interface \
    virtualInterfaceName=vif-cong-khai,vlan=101,asn=65000,\
addressFamily=ipv4,amazonAddress=175.45.1.1/30,customerAddress=175.45.1.2/30

aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-abc \
  --vpn-gateway-id vgw-abc \
  --options TunnelOptions='[{},{}]'

⚠ Và có cách hiện đại hơn: MACsec ngay trên Direct Connect:

MACsec mã hoá ở tầng 2
        ↓
    Trên chính liên kết vật lý
        ↓
    Không thêm chặng nào, không giảm
      thông lượng đáng kể
        ↓
    Hỗ trợ trên cổng chuyên dụng 10,
      100 và 400 Gbps

aws directconnect associate-mac-sec-key \
  --connection-id dxcon-abc \
  --ckn <chuoi-ckn> --cak <chuoi-cak>

Bảng hai cách mã hoá Direct Connect: | | VPN trên DX | MACsec | |---|---|---| | Tầng | 3 (IPsec) | 2 (Ethernet) | | Thông lượng | giới hạn bởi đường hầm | gần như đầy cổng | | Yêu cầu | customer gateway | cổng chuyên dụng hỗ trợ MACsec | | Phạm vi | tới VPC | tới điểm Direct Connect |

MACsec chỉ bảo vệ đoạn từ router của
  bạn tới điểm hiện diện của AWS
        ↓
    VPN bảo vệ trọn đường tới VPC
    → hai phạm vi khác nhau

⚠ Và VPN trên DX có cái giá về thông lượng:

Mỗi đường hầm IPsec ~1,25 Gbps
        ↓
    Direct Connect 10 Gbps
        ↓
    Muốn dùng hết → nhiều đường hầm +
      ECMP qua Transit Gateway

aws ec2 create-transit-gateway-vpn-attachment \
  --transit-gateway-id tgw-abc \
  --vpn-connection-id vpn-abc

Transit Gateway hỗ trợ ECMP
        ↓
    Chia tải qua nhiều đường hầm
        ↓
    Virtual private gateway KHÔNG hỗ
      trợ ECMP cho VPN
    → đây là lý do thực tế để chọn TGW

⚠ Và vì sao phương án D sai — Transit Gateway không phải kết nối:

D nói dùng VPC transit gateway để dựng
  kết nối
        ↓
    Transit Gateway là bộ định tuyến
      trung tâm
        ↓
    Nó KHÔNG tự tạo đường tới trung
      tâm dữ liệu
        ↓
    Vẫn cần VPN hoặc Direct Connect
      gắn vào nó
    → nó là thành phần trong kiến
      trúc, không phải giải pháp kết
      nối

⚠ Và nên có VPN dự phòng cho Direct Connect:

Direct Connect đứt (đứt cáp, bảo trì)
        ↓
    Không có dự phòng → mất kết nối
      hoàn toàn
        ↓
    Dựng VPN qua Internet làm đường
      phụ
        ↓
    BGP tự chuyển sang khi DX mất

Ưu tiên đường:
    - DX quảng bá tuyến cụ thể hơn
    - hoặc dùng AS_PATH prepending
      trên VPN
    → VPN chỉ được dùng khi DX chết

⚠ Và SLA của Direct Connect phụ thuộc số kết nối: | Cấu hình | SLA | |---|---| | Một kết nối | không có SLA | | Hai kết nối, cùng vị trí | 99,9% | | Hai kết nối, hai vị trí | 99,99% |

⚠ Và ba loại virtual interface phải phân biệt: | VIF | Tới đâu | |---|---| | Private VIF | VPC qua virtual private gateway hoặc DX gateway | | Public VIF | endpoint công khai của AWS (S3, DynamoDB, endpoint VPN) | | Transit VIF | Transit Gateway qua DX gateway |

Muốn dựng VPN trên DX
        ↓
    Phải dùng PUBLIC VIF
        ↓
    Vì endpoint VPN của AWS là địa chỉ
      công khai
    → đây là chi tiết hay bị bỏ sót

Ba lợi ích của DX + VPN: | Lợi ích | Chi tiết | |---|---| | Riêng tư và được mã hoá | | | Độ trễ ổn định | | | Đáp ứng yêu cầu tuân thủ về mã hoá đường truyền | |

⚠ Và chi phí truyền dữ liệu ra qua DX rẻ hơn nhiều:

Truyền ra Internet: ~0,09 USD/GB
        ↓
    Truyền ra qua Direct Connect:
      ~0,02 USD/GB
        ↓
    Với lượng lớn
    → riêng khoản này đã bù được phí
      cổng

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

• **A. Chỉ dùng Direct Connect — đây là phương án gần nhất và đáp ứng ba trong bốn yêu cầu, nhưng Direct Connect không mã hoá dữ liệu; nó chỉ đảm bảo lưu lượng không đi qua Internet công cộng.
• **C. Chỉ dùng site-to-site VPN — có mã hoá nhưng chạy trên Internet nên độ trễ dao động, và mỗi đường hầm giới hạn khoảng 1,25 Gbps.
• **D. Dùng Transit Gateway — là bộ định tuyến trung tâm, không tự tạo được đường kết nối tới trung tâm dữ liệu.

Ghi nhớ

⚠ Bốn tính chất của các kiểu kết nối lai — bảng phải thuộc: | Kiểu | Riêng | Mã hoá | Thông lượng | |---|---|---|---| | Direct Connect | có | không | cao | | VPN | không | có | ~1,25 Gbps/đường hầm | | VPN trên DX | có | có | giới hạn bởi đường hầm | | DX + MACsec | có | có (tầng 2) | gần đầy cổng |

Từ khoá nhận diện:

"private, low latency AND encrypted" → DX + VPN "Direct Connect is encrypted" → LUÔN SAI "encrypt at line rate on DX" → MACsec "connect many VPCs and on-premises" → Transit Gateway

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Không mã hoá | | | Một kết nối không có SLA | | | Phí truyền ra rẻ hơn Internet nhiều | |

Ba loại VIF: | VIF | Dùng cho | |---|---| | Private | tới VPC | | Public | tới dịch vụ công khai, và để dựng VPN trên DX | | Transit | tới Transit Gateway |

Ba lưu ý về VPN: | Lưu ý | Chi tiết | |---|---| | Mỗi kết nối có hai đường hầm | | | Virtual private gateway không hỗ trợ ECMP | | | Transit Gateway hỗ trợ ECMP | |

Ba lưu ý về MACsec: | Lưu ý | Chi tiết | |---|---| | Mã hoá tầng 2 | | | Cần cổng chuyên dụng hỗ trợ | | | Chỉ bảo vệ tới điểm hiện diện của AWS | |

Ba lưu ý về dự phòng: | Lưu ý | Chi tiết | |---|---| | Luôn có đường phụ | | | Hai vị trí DX cho SLA 99,99% | | | VPN qua Internet là dự phòng rẻ | |

Ba lưu ý về định tuyến: | Lưu ý | Chi tiết | |---|---| | BGP quyết định đường ưu tiên | | | Tuyến cụ thể hơn thắng | | | AS_PATH prepending để hạ ưu tiên | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ và jitter thực tế | | | Ngắt DX thử, xem có chuyển sang VPN không | | | Bắt gói tin xác nhận đã mã hoá | |

Và một lời khuyên: hãy thử ngắt Direct Connect trong cửa sổ bảo trì để xác nhận VPN dự phòng thật sự nhận tải. Cấu hình BGP trông đúng trên giấy rất thường xuyên không hoạt động khi cần — thường vì tuyến quảng bá qua VPN bị lọc mất, và điều đó chỉ lộ ra khi đường chính đã chết.

Đáp án

**C — Thêm hành động kms:GenerateDataKey vào chính sách IAM.

Vì sao đúng

Câu này kiểm tra hiểu biết về mã hoá phong bì — cách KMS thật sự hoạt động.

⚠ Điểm mấu chốt: KMS KHÔNG mã hoá dữ liệu lớn:

`kms:Encrypt` chỉ nhận tối đa 4 KB
        ↓
    Object trên S3 thường lớn hơn
      nhiều
        ↓
    → không thể dùng KMS mã hoá trực
      tiếp

Mã hoá phong bì hoạt động thế nào:

1. Client gọi `GenerateDataKey`
        ↓
2. KMS trả về HAI thứ:
     - khoá dữ liệu dạng THÔ (plaintext)
     - khoá dữ liệu đã MÃ HOÁ (ciphertext)
        ↓
3. Client dùng khoá thô mã hoá tệp
        ↓
4. Client XOÁ khoá thô khỏi bộ nhớ
        ↓
5. Client lưu tệp đã mã hoá + khoá đã
     mã hoá

Giải mã ngược lại:

1. Đọc khoá đã mã hoá kèm theo tệp
        ↓
2. Gọi `kms:Decrypt` với khoá đó
        ↓
3. KMS trả khoá thô
        ↓
4. Dùng nó giải mã tệp

⚠ Và đó là lý do chính sách thiếu ĐÚNG một hành động:

`kms:Decrypt` đã có → ĐỌC được
        ↓
    `kms:Encrypt` đã có → nhưng chỉ
      dùng cho dữ liệu dưới 4 KB
        ↓
    Thiếu `kms:GenerateDataKey`
    → không tạo được khoá dữ liệu để
      GHI

Triệu chứng khớp chính xác đề bài:
        ↓
    Lấy object → thành công
    Tải lên object → "forbidden"

Chính sách đầy đủ:

{"Sid": "KMS",
 "Effect": "Allow",
 "Action": ["kms:Decrypt",
            "kms:Encrypt",
            "kms:GenerateDataKey",
            "kms:DescribeKey"],
 "Resource": "arn:aws:kms:us-west-1:111122223333:key/keyid-12345"}

⚠ Và kms:DescribeKey cũng nên có:

SDK gọi `DescribeKey` để biết loại
  khoá và thuật toán
        ↓
    Thiếu → một số luồng thất bại
        ↓
    Nó chỉ đọc siêu dữ liệu, không lộ
      khoá
    → thêm vào là an toàn

⚠ Và vì sao ba phương án còn lại sai: | Phương án | Vấn đề | |---|---| | kms:GetKeyPolicy | đọc chính sách khoá, không liên quan mã hoá | | kms:GetPublicKey | chỉ dùng cho khoá bất đối xứng | | kms:GetDataKey | KHÔNG TỒN TẠI |

⚠ Và kms:GetDataKey là bẫy kinh điển:

Nghe rất hợp lý
        ↓
    Nhưng API thật tên là
      `GenerateDataKey`
        ↓
    Vì KMS TẠO RA khoá mới mỗi lần
        ↓
    Không phải "lấy" một khoá có sẵn
    → cái tên phản ánh đúng hành vi

Ba biến thể của GenerateDataKey: | API | Trả về | |---|---| | GenerateDataKey | khoá thô + khoá đã mã hoá | | GenerateDataKeyWithoutPlaintext | CHỈ khoá đã mã hoá | | GenerateDataKeyPair | cặp khoá bất đối xứng |

⚠ Và WithoutPlaintext dùng khi mã hoá xảy ra ở chỗ khác:

Tiến trình A chuẩn bị khoá cho tiến
  trình B
        ↓
    A không cần biết khoá thô
        ↓
    → giảm phạm vi lộ khoá

Ví dụ mã hoá phía client:

import boto3, os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

kms = boto3.client('kms')
s3 = boto3.client('s3')

def tai_len(duong_dan, bucket, khoa, arn_cmk):
    kq = kms.generate_data_key(KeyId=arn_cmk, KeySpec='AES_256')
    khoa_tho = kq['Plaintext']
    khoa_ma_hoa = kq['CiphertextBlob']
    try:
        aes = AESGCM(khoa_tho)
        nonce = os.urandom(12)
        with open(duong_dan, 'rb') as f:
            ma_hoa = aes.encrypt(nonce, f.read(), None)
        s3.put_object(Bucket=bucket, Key=khoa,
                      Body=nonce + ma_hoa,
                      Metadata={'khoa-ma-hoa':
                                khoa_ma_hoa.hex()})
    finally:
        khoa_tho = None

⚠ Và phải xoá khoá thô khỏi bộ nhớ ngay sau khi dùng:

Giữ khoá thô lâu
        ↓
    Nó có thể lọt vào core dump, log,
      swap
        ↓
    → toàn bộ ý nghĩa của mã hoá
      phong bì là giảm thời gian khoá
      tồn tại ở dạng thô

⚠ Và với mã hoá phía SERVER thì quyền cần khác:

SSE-KMS: S3 gọi KMS thay bạn
        ↓
    Vẫn cần `GenerateDataKey` và
      `Decrypt` trong chính sách của
      người gọi
        ↓
    Vì S3 dùng credential của người
      đó

Bảng ba kiểu mã hoá với KMS trên S3: | Kiểu | Ai mã hoá | Quyền cần | |---|---|---| | SSE-S3 | S3, khoá của AWS | không cần quyền KMS | | SSE-KMS | S3, khoá KMS | GenerateDataKey + Decrypt | | Client-side | ứng dụng | GenerateDataKey + Decrypt |

⚠ Và key policy cũng phải cho phép, không chỉ chính sách IAM:

KMS khác hầu hết dịch vụ khác
        ↓
    Key policy là bắt buộc
        ↓
    Chính sách IAM một mình KHÔNG đủ
        ↓
    → phải cho phép ở CẢ HAI nơi

{"Sid": "ChoPhepDungKhoa",
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::111122223333:role/vai-tro-ung-dung"},
 "Action": ["kms:Encrypt", "kms:Decrypt",
            "kms:GenerateDataKey", "kms:DescribeKey"],
 "Resource": "*"}

⚠ Hoặc key policy uỷ quyền cho IAM:

{"Sid": "ChoPhepIamQuyetDinh",
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
 "Action": "kms:*",
 "Resource": "*"}

Câu này thường bị hiểu nhầm là "cho
  root toàn quyền"
        ↓
    Thật ra nó nghĩa là: uỷ quyền
      quyết định cho chính sách IAM
      của tài khoản
    → không có nó thì IAM policy vô
      tác dụng với khoá này

⚠ Và kms:ViaService giới hạn khoá chỉ dùng qua một dịch vụ:

{"Condition": {"StringEquals": {
  "kms:ViaService": "s3.us-west-1.amazonaws.com"}}}

Khoá chỉ dùng được khi gọi qua S3
        ↓
    Người có quyền không tự gọi KMS
      trực tiếp được
    → thu hẹp phạm vi rất hiệu quả

⚠ Và có S3 Bucket Key giảm chi phí KMS rất nhiều:

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

Không bật: mỗi object một lời gọi KMS
        ↓
    Bật: một khoá cấp bucket dùng lại
      trong thời gian ngắn
        ↓
    Giảm tới 99% lời gọi KMS
    → và KMS tính tiền theo lời gọi

Ba lợi ích của mã hoá phong bì: | Lợi ích | Chi tiết | |---|---| | Mã hoá được dữ liệu lớn tuỳ ý | | | Khoá gốc không bao giờ rời KMS | | | Mỗi object một khoá dữ liệu riêng | |

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

• **A. kms:GetKeyPolicy — đây là phương án gần nhất về mặt "nghe như quyền còn thiếu", nhưng nó chỉ cho đọc chính sách của khoá, không liên quan gì tới việc mã hoá dữ liệu.
• **B. kms:GetPublicKey — chỉ áp dụng cho khoá bất đối xứng; ở đây dùng khoá đối xứng để mã hoá phong bì.
• **D. kms:GetDataKey — API này không tồn tại; tên đúng là GenerateDataKey.

Ghi nhớ

⚠ Bốn hành động KMS cần cho mã hoá phong bì — bảng phải thuộc: | Hành động | Dùng khi | |---|---| | GenerateDataKey | GHI dữ liệu | | Decrypt | ĐỌC dữ liệu | | DescribeKey | SDK hỏi loại khoá | | Encrypt | chỉ cho dữ liệu dưới 4 KB |

Từ khoá nhận diện:

"can read but not write encrypted objects" → thiếu GenerateDataKey "kms:GetDataKey" → API KHÔNG TỒN TẠI "encrypt data larger than 4 KB" → mã hoá phong bì "reduce KMS costs on S3" → S3 Bucket Key

Ba lưu ý về KMS: | Lưu ý | Chi tiết | |---|---| | Encrypt giới hạn 4 KB | | | Khoá gốc không bao giờ rời KMS | | | Tính tiền theo lời gọi API | |

Ba lưu ý về key policy: | Lưu ý | Chi tiết | |---|---| | Bắt buộc, IAM policy một mình không đủ | | | Uỷ quyền cho IAM bằng principal root | | | kms:ViaService giới hạn theo dịch vụ | |

Ba lưu ý về mã hoá phong bì: | Lưu ý | Chi tiết | |---|---| | Xoá khoá thô ngay sau khi dùng | | | Lưu khoá đã mã hoá kèm dữ liệu | | | WithoutPlaintext khi mã hoá ở nơi khác | |

Ba lưu ý về S3 và KMS: | Lưu ý | Chi tiết | |---|---| | SSE-KMS cần quyền KMS của người gọi | | | Bucket Key giảm tới 99% lời gọi | | | Khoá phải cùng Region với bucket | |

Ba lưu ý về hạn ngạch: | Hạn ngạch | Giá trị mặc định | |---|---| | GenerateDataKey mỗi giây | hàng chục nghìn, tuỳ Region | | Vượt | ThrottlingException | | Giảm tải | Bucket Key hoặc cache khoá dữ liệu |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lời gọi KMS | | | Cảnh báo khi có nhiều AccessDenied | | | Theo dõi chi phí theo khoá | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử tải lên một object thật | | | Đọc CloudTrail xem hành động nào bị từ chối | | | Kiểm cả key policy lẫn IAM policy | |

Và một lời khuyên: hãy đọc CloudTrail để biết chính xác hành động nào bị từ chối thay vì đoán. Sự kiện AccessDenied của KMS ghi rõ tên API và ARN khoá — điều đó biến một buổi chiều thử sai thành một phút sửa chính sách, và nó cũng cho biết vấn đề nằm ở IAM policy hay ở key policy.

Đáp án

**B, E và F — Dùng AWS Organizations với các Organizational Unit Security, Infrastructure, Workloads, Suspended, Exceptions; cấu hình AWS Budgets alert chuyển tài khoản sang OU Exceptions khi vượt ngưỡng, dùng SCP hạn chế tài nguyên trong OU đó, và dùng OU Suspended cho tài khoản chờ kiểm toán; chỉ định một tài khoản làm delegated administrator của GuardDuty, tạo SNS topic ở đó cho đội bảo mật.

Vì sao đúng

Ba yêu cầu, ba mệnh đề: | Yêu cầu | Mệnh đề | |---|---| | Tổ chức nhiều tài khoản theo đơn vị | B — OU | | Theo dõi chi phí và chặn khi vượt ngưỡng | E — Budgets + SCP | | Phát hiện và phản ứng đe doạ toàn tổ chức | F — GuardDuty delegated admin |

⚠ Điểm mấu chốt thứ nhất: OU và SCP là hai thứ KHÁC NHAU:

OU: cấu trúc cây để NHÓM tài khoản
        ↓
    SCP: chính sách GẮN VÀO OU
        ↓
    Không có khái niệm "tổ chức tài
      khoản vào các SCP"
    → đó là lỗi của mệnh đề A

A viết: "Organize the accounts into
  the following SCPs: Security,
  Infrastructure..."
        ↓
    Sai về mặt khái niệm
        ↓
    Và còn viết "grant permissions by
      using SCP guardrails"
    → SCP KHÔNG cấp quyền

⚠ Và năm OU trong mệnh đề B là cấu trúc AWS khuyến nghị: | OU | Chứa gì | |---|---| | Security | tài khoản log, audit, security tooling | | Infrastructure | mạng chung, CI/CD, kho ảnh | | Workloads | tài khoản chạy ứng dụng | | Suspended | tài khoản đã ngừng dùng, chờ xử lý | | Exceptions | tài khoản có ngoại lệ chính sách |

⚠ Và OU Suspended có SCP chặn gần như mọi thứ:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChanMoiThu",
   "Effect": "Deny",
   "NotAction": ["support:*", "iam:GetAccountSummary",
                 "ce:*", "budgets:*"],
   "Resource": "*"}]}

Chuyển tài khoản vào OU này
        ↓
    Mọi tài nguyên mới bị chặn
        ↓
    Tài nguyên cũ vẫn chạy (SCP không
      xoá gì)
    → đúng nghĩa "giữ lại để kiểm
      toán"

⚠ Điểm mấu chốt thứ hai: AWS Budgets là công cụ đặt ngưỡng, Cost Explorer thì không:

Cost Explorer: công cụ PHÂN TÍCH và
  trực quan hoá chi phí
        ↓
    Không đặt ngưỡng, không cảnh báo
        ↓
    AWS Budgets: đặt ngân sách và
      cảnh báo
    → đó là lỗi của mệnh đề C

Bảng ba dịch vụ chi phí: | Dịch vụ | Việc | |---|---| | Cost Explorer | xem và phân tích chi phí quá khứ | | Budgets | đặt ngưỡng, cảnh báo, hành động | | Cost Anomaly Detection | phát hiện chi phí bất thường bằng học máy |

Tạo ngân sách:

aws budgets create-budget --account-id 111122223333 \
  --budget '{
    "BudgetName": "ngan-sach-phat-trien",
    "BudgetLimit": {"Amount": "5000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"}' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"},
    "Subscribers": [{"SubscriptionType": "SNS",
      "Address": "<arn-sns>"}]}]'

⚠ Và FORECASTED cảnh báo sớm hơn ACTUAL: | Loại | Kích hoạt khi | |---|---| | ACTUAL | chi phí thật đã vượt ngưỡng | | FORECASTED | dự báo cuối kỳ sẽ vượt |

Chỉ dùng `ACTUAL` 100%
        ↓
    Biết được khi tiền đã tiêu
        ↓
    Thêm `FORECASTED` 100% và
      `ACTUAL` 80%
    → có thời gian phản ứng

⚠ Và Budgets Actions làm được nhiều hơn chỉ gửi thư:

aws budgets create-budget-action \
  --account-id 111122223333 \
  --budget-name ngan-sach-phat-trien \
  --notification-type ACTUAL \
  --action-type APPLY_SCP_POLICY \
  --action-threshold ActionThresholdValue=100,ActionThresholdType=PERCENTAGE \
  --definition '{"ScpActionDefinition": {
    "PolicyId": "p-han-che",
    "TargetIds": ["ou-abc-11111111"]}}' \
  --execution-role-arn <arn-role> \
  --approval-model AUTOMATIC \
  --subscribers '[{"SubscriptionType":"SNS","Address":"<arn-sns>"}]'

Bốn loại hành động của Budgets:

APPLY_IAM_POLICY   → gắn chính sách
                     hạn chế
APPLY_SCP_POLICY   → gắn SCP vào OU
RUN_SSM_DOCUMENTS  → tắt EC2 hoặc RDS

⚠ Và approval-model quyết định có tự động hay không: | Giá trị | Hành vi | |---|---| | AUTOMATIC | thực hiện ngay khi vượt ngưỡng | | MANUAL | chờ người duyệt |

Môi trường phát triển → `AUTOMATIC`
        ↓
    Môi trường sản xuất → `MANUAL`
    → tự động chặn sản xuất là tự gây
      sự cố

⚠ Điểm mấu chốt thứ ba: GuardDuty có delegated administrator:

aws guardduty enable-organization-admin-account \
  --admin-account-id 222233334444

Một tài khoản quản GuardDuty cho cả
  tổ chức
        ↓
    Xem mọi finding ở một chỗ
        ↓
    Một SNS topic duy nhất
    → đội bảo mật đăng ký một lần

Bật tự động cho tài khoản mới:

aws guardduty update-organization-configuration \
  --detector-id <id-detector> \
  --auto-enable-organization-members ALL

⚠ Và vì sao mệnh đề D kém hơn hẳn:

D bật GuardDuty ở TỪNG tài khoản
        ↓
    Tạo SNS topic ở MỖI tài khoản
        ↓
    Đội bảo mật phải đăng ký hàng chục
      topic
        ↓
    Thêm tài khoản mới → thêm topic
      mới, phải nhớ đăng ký
    → không mở rộng được

Và tệ hơn:
        ↓
    Không có cái nhìn tổng thể
        ↓
    Một cuộc tấn công trải qua nhiều
      tài khoản
    → nhìn rời rạc thì không thấy được
      liên hệ

⚠ Và delegated administrator có ở nhiều dịch vụ — nên dùng nhất quán:

GuardDuty, Security Hub, Config,
  Inspector, Macie, IAM Access
  Analyzer, Firewall Manager, Backup
        ↓
    Đều chỉ định được tài khoản quản
      trị
        ↓
    Thường trỏ về cùng một tài khoản
      Security
    → tài khoản quản lý không nên
      chạy gì

aws organizations register-delegated-administrator \
  --account-id 222233334444 \
  --service-principal guardduty.amazonaws.com

⚠ Và tài khoản quản lý miễn nhiễm SCP — lý do phải tách:

SCP không áp cho tài khoản quản lý
        ↓
    Chạy tải ở đó = chạy ngoài mọi
      guardrail
        ↓
    → tài khoản quản lý chỉ để quản
      tổ chức

Ba lợi ích của kiến trúc này: | Lợi ích | Chi tiết | |---|---| | Chi phí có trần cứng mỗi tài khoản | | | Phát hiện đe doạ tập trung một chỗ | | | Tài khoản chờ kiểm toán bị đóng băng an toàn | |

⚠ Và nên bật Cost Anomaly Detection bên cạnh Budgets:

aws ce create-anomaly-monitor \
  --anomaly-monitor '{
    "MonitorName": "giam-sat-toan-to-chuc",
    "MonitorType": "DIMENSIONAL",
    "MonitorDimension": "SERVICE"}'

Budgets bắt việc VƯỢT NGƯỠNG
        ↓
    Anomaly Detection bắt việc TĂNG
      ĐỘT NGỘT
        ↓
    Chi phí tăng gấp ba nhưng vẫn
      dưới ngân sách
    → chỉ Anomaly Detection thấy

⚠ Và chuyển tài khoản giữa các OU là thao tác tức thì:

aws organizations move-account \
  --account-id 333344445555 \
  --source-parent-id ou-workloads \
  --destination-parent-id ou-exceptions

SCP mới áp gần như ngay lập tức
        ↓
    Không cần khởi động lại gì
        ↓
    Nhưng credential tạm đã cấp vẫn
      sống tới khi hết hạn

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

• **C. Dùng Cost Explorer alert để chuyển tài khoản sang OU Exceptions — đây là phương án gần nhất và phần OU Exceptions/Suspended và SCP hoàn toàn đúng, nhưng Cost Explorer là công cụ phân tích, không đặt ngưỡng cảnh báo được; đó là việc của AWS Budgets.
• **D. Bật GuardDuty ở từng tài khoản với SNS topic riêng mỗi nơi — hoạt động được nhưng không mở rộng: đội bảo mật phải đăng ký hàng chục topic và mất cái nhìn tổng thể.
• **A. Tổ chức tài khoản vào các SCP và cấp quyền bằng SCP guardrail — SCP là chính sách gắn vào OU chứ không phải đơn vị tổ chức, và SCP không cấp quyền cho ai.

Ghi nhớ

⚠ Bốn khái niệm Organizations — bảng phải thuộc: | Khái niệm | Là gì | |---|---| | OU | nhóm tài khoản trong cây | | SCP | chính sách trần quyền gắn vào OU/tài khoản | | Delegated administrator | tài khoản quản một dịch vụ cho cả tổ chức | | Tài khoản quản lý | gốc tổ chức, miễn nhiễm SCP |

Từ khoá nhận diện:

"organize accounts into SCPs" → LUÔN SAI "alert when budget threshold reached" → AWS Budgets "analyze past spending" → Cost Explorer "GuardDuty across the organization" → delegated administrator

Ba lưu ý về OU: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 tầng dưới gốc | | | SCP kế thừa xuống dưới | | | Chuyển tài khoản giữa OU là tức thì | |

Ba lưu ý về Budgets: | Lưu ý | Chi tiết | |---|---| | FORECASTED cảnh báo sớm hơn ACTUAL | | | Actions gắn được SCP hoặc chạy SSM document | | | AUTOMATIC cho dev, MANUAL cho sản xuất | |

Ba lưu ý về GuardDuty: | Lưu ý | Chi tiết | |---|---| | Bật auto-enable cho tài khoản mới | | | Bật ở mọi Region đang dùng | | | Nối EventBridge để phản ứng tự động | |

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | Đặt trần, không cấp quyền | | | Không áp cho tài khoản quản lý | | | Không áp cho service-linked role | |

Ba lưu ý về tài khoản quản lý: | Lưu ý | Chi tiết | |---|---| | Không chạy tải sản xuất ở đó | | | Bật MFA cho root | | | Uỷ quyền dịch vụ bảo mật cho tài khoản khác | |

Ba lưu ý về theo dõi chi phí: | Lưu ý | Chi tiết | |---|---| | Bật cost allocation tag | | | Budgets cho ngưỡng, Anomaly Detection cho đột biến | | | Xem chi phí theo OU trong Cost Explorer | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuyển một tài khoản thử sang OU Suspended | | | Vượt ngưỡng ngân sách thử ở tài khoản sandbox | | | Kiểm mọi tài khoản đã bật GuardDuty | |

Và một lời khuyên: hãy đặt approval-model là MANUAL cho mọi ngân sách chạm tới tài khoản sản xuất. Một hành động tự động gắn SCP hạn chế khi vượt ngân sách nghe rất hợp lý cho môi trường phát triển, nhưng áp nhầm vào sản xuất thì nó biến một vấn đề tài chính thành một sự cố ngừng dịch vụ.

Đáp án

**A — Dùng lớp lưu trữ S3 Intelligent-Tiering để lưu tệp video; cấu hình bucket đó làm origin của một CloudFront distribution để phân phối nội dung tới khách hàng.

Vì sao đúng

Đề mô tả đúng bài toán mà Intelligent-Tiering sinh ra để giải: | Đặc điểm | Ý nghĩa | |---|---| | Xem nhiều lúc mới tải lên | cần tầng nóng | | Rất ít xem sau 6-8 tháng | nên xuống tầng lạnh | | Nhưng phải truy cập được NGAY | không dùng lớp cần khôi phục |

⚠ Điểm mấu chốt: Intelligent-Tiering không có phí lấy dữ liệu:

Standard-IA: rẻ hơn khi lưu
        ↓
    Nhưng tính 0,01 USD/GB khi đọc
        ↓
    Video 10 GB → 0,10 USD mỗi lượt
      xem
        ↓
    Một video cũ bất ngờ được xem
      nhiều
    → hoá đơn tăng vọt

Intelligent-Tiering: không phí lấy
  dữ liệu ở bất kỳ tầng nào
        ↓
    Chỉ có phí giám sát nhỏ
    → an toàn khi mẫu truy cập khó
      đoán

Năm tầng của Intelligent-Tiering: | Tầng | Chuyển sau | Truy cập | |---|---|---| | Frequent Access | mặc định | tức thì | | Infrequent Access | 30 ngày không đọc | tức thì | | Archive Instant Access | 90 ngày không đọc | tức thì | | Archive Access (tuỳ chọn) | 90-730 ngày | cần khôi phục | | Deep Archive Access (tuỳ chọn) | 180-730 ngày | cần khôi phục |

⚠ Và ba tầng đầu đều TỨC THÌ — đó là điều quyết định:

Đề nói "phải truy cập được ngay khi
  cần"
        ↓
    Ba tầng tự động đều tức thì
        ↓
    Hai tầng lưu trữ sâu là TUỲ CHỌN,
      mặc định TẮT
    → không bật thì không bao giờ phải
      khôi phục

Bật Intelligent-Tiering:

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket kho-video --id cau-hinh-mac-dinh \
  --intelligent-tiering-configuration '{
    "Id": "cau-hinh-mac-dinh",
    "Status": "Enabled",
    "Filter": {"Prefix": "video/"},
    "Tierings": [
      {"Days": 90, "AccessTier": "ARCHIVE_ACCESS"},
      {"Days": 180, "AccessTier": "DEEP_ARCHIVE_ACCESS"}]}'

⚠ Nhưng ở đây KHÔNG nên bật hai tầng lưu trữ sâu:

Chúng đòi khôi phục trước khi đọc
        ↓
    Trái với "truy cập được ngay"
        ↓
    → chỉ đặt lớp lưu trữ là
      `INTELLIGENT_TIERING` và để mặc
      định

aws s3 cp video.mp4 s3://kho-video/video/ \
  --storage-class INTELLIGENT_TIERING

⚠ Và phí giám sát chỉ đáng kể với object nhỏ:

0,0025 USD mỗi 1.000 object mỗi tháng
        ↓
    Video 10 GB → phí giám sát không
      đáng gì
        ↓
    Nhưng hàng triệu tệp nhỏ vài KB
    → phí giám sát vượt cả tiền tiết
      kiệm

⚠ Và object dưới 128 KB không được chuyển tầng:

Chúng luôn ở tầng Frequent Access
        ↓
    Và từ 2023 không bị tính phí giám
      sát nữa
        ↓
    → dùng Intelligent-Tiering cho tệp
      nhỏ không hại, chỉ là không lợi

⚠ Và vì sao phương án B sai — EFS không phải origin của CloudFront:

B dùng EFS làm origin của CloudFront
        ↓
    CloudFront nhận origin là S3 hoặc
      endpoint HTTP
        ↓
    EFS là hệ thống tệp NFS
        ↓
    → không trỏ thẳng được
    → phải có máy chủ web đứng giữa

⚠ Và EFS đắt hơn S3 nhiều lần cho video: | Kho | Giá xấp xỉ mỗi GB-tháng | |---|---| | S3 Standard | 0,023 USD | | S3 Standard-IA | 0,0125 USD | | EFS Standard | 0,30 USD | | EFS IA | 0,016 USD |

Video là dữ liệu chỉ đọc, không cần
  POSIX
        ↓
    Đưa vào EFS là trả gấp 13 lần cho
      tính năng không dùng tới

⚠ Và vì sao phương án C sai — EFS không có Intelligent-Tiering:

C nói "EFS Intelligent-Tiering storage
  class"
        ↓
    EFS có lifecycle management chuyển
      sang IA và Archive
        ↓
    Nhưng không có lớp tên
      "Intelligent-Tiering"
    → và vẫn phải có EC2 phục vụ nội
      dung

⚠ Và vì sao phương án D không giải quyết vấn đề:

D dùng MediaConvert + MediaPackage
        ↓
    MediaConvert chuyển mã video
        ↓
    MediaPackage đóng gói cho streaming
        ↓
    Đề hỏi về CHI PHÍ LƯU TRỮ
    → hai dịch vụ này không giảm chi
      phí lưu trữ, mà còn thêm chi phí
      xử lý

⚠ Và MediaPackage không lấy nguồn từ S3 theo cách D mô tả:

MediaPackage nhận nguồn từ
  MediaLive hoặc từ packaging group
        ↓
    Không phải "endpoint phân phối nội
      dung từ S3"
    → mô tả sai kiến trúc

Kiến trúc đúng:

Video tải lên
    ↓
S3 Intelligent-Tiering
    ↓  (origin)
CloudFront + OAC
    ↓
1 triệu người dùng

⚠ Và CloudFront là phần tiết kiệm lớn nhất mà đề không nói rõ:

Truyền dữ liệu ra từ S3: ~0,09 USD/GB
        ↓
    Truyền từ CloudFront: ~0,085
      USD/GB và giảm theo bậc
        ↓
    Nhưng quan trọng hơn: S3 → CloudFront
      MIỄN PHÍ
        ↓
    Cache hit cao → phần lớn lưu lượng
      không chạm S3

1 triệu người xem video 1 GB
        ↓
    Không có CloudFront: 1 PB từ S3
        ↓
    Có CloudFront, cache hit 95%:
      S3 chỉ phục vụ 50 TB
    → và phần đó miễn phí

⚠ Và video lớn nên bật range request:

Người xem tua giữa video
        ↓
    Trình phát gửi range request
        ↓
    CloudFront cache từng phần
        ↓
    Không phải tải cả 10 GB

⚠ Và nên dùng OAC để chặn truy cập thẳng vào S3:

Bucket riêng tư hoàn toàn
        ↓
    Chỉ CloudFront đọc được
        ↓
    Muốn giới hạn theo người dùng
    → thêm signed URL hoặc signed
      cookie

aws cloudfront create-key-group \
  --key-group-config '{
    "Name": "nhom-khoa-hoc-vien",
    "Items": ["<id-public-key>"]}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tự xuống tầng rẻ, không phí lấy dữ liệu | | | Luôn truy cập tức thì | | | CloudFront cắt phần lớn chi phí truyền | |

⚠ Và nên đo trước bằng Storage Lens:

aws s3control get-storage-lens-configuration \
  --account-id 111122223333 --config-id mac-dinh

Xem phân bố theo tuổi object
        ↓
    Bao nhiêu phần trăm không được
      đọc quá 30 ngày
    → ước lượng được khoản tiết kiệm
      trước khi bật

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

• **B. EFS Standard chuyển sang EFS Standard-IA bằng lifecycle, CloudFront lấy từ EFS — đây là phương án gần nhất và EFS thật sự có chuyển tầng tự động, nhưng CloudFront không nhận EFS làm origin, và EFS đắt hơn S3 nhiều lần cho dữ liệu chỉ đọc.
• **C. EFS Intelligent-Tiering + EC2 phục vụ qua CloudFront — EFS không có lớp tên Intelligent-Tiering, và phải nuôi EC2 chỉ để phục vụ tệp tĩnh.
• **D. MediaConvert + MediaPackage — hai dịch vụ này lo chuyển mã và đóng gói video, không giảm chi phí lưu trữ mà còn thêm chi phí xử lý.

Ghi nhớ

⚠ Bốn lớp lưu trữ cho dữ liệu truy cập không đều — bảng phải thuộc: | Lớp | Phí lấy | Truy cập | |---|---|---| | Intelligent-Tiering | không | tức thì (3 tầng đầu) | | Standard-IA | 0,01 USD/GB | tức thì | | Glacier Instant Retrieval | 0,03 USD/GB | tức thì | | Glacier Flexible | có | phút tới giờ |

Từ khoá nhận diện:

"unpredictable access pattern" → Intelligent-Tiering "immediately accessible when needed" → loại mọi lớp cần khôi phục "1 million users, video" → CloudFront "known access pattern" → lifecycle rule sang IA

Ba lưu ý về Intelligent-Tiering: | Lưu ý | Chi tiết | |---|---| | Không có phí lấy dữ liệu | | | Có phí giám sát mỗi object | | | Hai tầng lưu trữ sâu là tuỳ chọn, mặc định tắt | |

Ba lưu ý về object nhỏ: | Lưu ý | Chi tiết | |---|---| | Dưới 128 KB không chuyển tầng | | | Không bị tính phí giám sát | | | Hàng triệu tệp nhỏ thì cân nhắc gộp lại | |

Ba lưu ý về CloudFront với video: | Lưu ý | Chi tiết | |---|---| | S3 → CloudFront miễn phí | | | Bật range request cho tệp lớn | | | Signed URL để giới hạn người xem | |

Ba lưu ý về EFS: | Lưu ý | Chi tiết | |---|---| | Đắt hơn S3 nhiều lần | | | Không làm origin của CloudFront được | | | Chỉ dùng khi cần POSIX và nhiều máy cùng ghi | |

Ba lưu ý về chi phí truyền: | Lưu ý | Chi tiết | |---|---| | Truyền ra Internet là khoản lớn nhất với video | | | CloudFront giảm giá theo bậc dung lượng | | | Cache hit cao là đòn bẩy lớn nhất | |

Ba lưu ý về đo lường: | Công cụ | Việc | |---|---| | Storage Lens | phân bố theo lớp và tuổi | | S3 Inventory | danh sách object đầy đủ | | Cost Explorer theo usage type | tách phí lưu và phí truyền |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem phân bố tầng sau 30 và 90 ngày | | | Đo tỷ lệ cache hit của CloudFront | | | So hoá đơn trước và sau khi bật | |

Và một lời khuyên: hãy đừng bật hai tầng lưu trữ sâu của Intelligent-Tiering cho nội dung phục vụ người dùng cuối. Chúng tiết kiệm thật, nhưng đổi lại object phải khôi phục trước khi đọc — và với một video mà học viên vừa bấm phát, "chờ vài giờ" là câu trả lời không tồn tại.