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

Đáp án

D — Dùng Application Load Balancer với Auto Scaling group trải nhiều AZ, và Amazon EFS cho lưu trữ dùng chung.

Vì sao đúng

Đề cần một kiến trúc web sẵn sàng cao và co giãn, trong đó nhiều máy chủ cùng đọc ghi một kho tệp.

⚠ EFS là điểm mấu chốt — đây là hệ thống tệp AWS duy nhất mà nhiều EC2 gắn đồng thời một cách tự nhiên:

EBS:  gắn vào MỘT instance tại một thời điểm
      (Multi-Attach chỉ với io1/io2 và cần
       hệ thống tệp cụm — không phải giải pháp thường)
        ↓
EFS:  hàng nghìn instance gắn cùng lúc
      NFS, tự mở rộng, trải nhiều AZ

Dựng EFS:

aws efs create-file-system --performance-mode generalPurpose \
  --throughput-mode elastic --encrypted \
  --tags Key=Name,Value=du-lieu-web

# Mount target trong MỖI AZ
aws efs create-mount-target --file-system-id fs-abc \
  --subnet-id subnet-a --security-groups sg-efs
aws efs create-mount-target --file-system-id fs-abc \
  --subnet-id subnet-b --security-groups sg-efs

⚠ Phải tạo mount target cho MỖI AZ:

Thiếu mount target ở AZ nào
    → instance ở AZ đó không mount được
        ↓
    ASG khởi động máy ở AZ đó → máy hỏng health check

Mount trong user data:

#!/bin/bash
yum install -y amazon-efs-utils
mkdir -p /var/www/du-lieu
echo "fs-abc:/ /var/www/du-lieu efs _netdev,tls,iam 0 0" >> /etc/fstab
mount -a

⚠ tls và iam là hai tuỳ chọn nên luôn bật: | Tuỳ chọn | Việc | |---|---| | tls | mã hoá dữ liệu khi truyền | | iam | xác thực bằng vai trò IAM của instance |

ASG trải nhiều AZ:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name asg-web \
  --launch-template LaunchTemplateName=mau-web,Version='$Latest' \
  --min-size 2 --max-size 20 --desired-capacity 4 \
  --vpc-zone-identifier "subnet-a,subnet-b,subnet-c" \
  --target-group-arns <arn-tg> --health-check-type ELB \
  --health-check-grace-period 300

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một AZ hỏng vẫn phục vụ | | | Tệp nhất quán trên mọi máy | | | EFS tự mở rộng, không cần cấp dung lượng | |

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

• **C. ALB + ASG nhiều AZ nhưng dùng EBS cho lưu trữ dùng chung — đây là phương án gần nhất và đúng ở phần tính toán, nhưng sai ở lưu trữ: một volume EBS không gắn được vào nhiều instance ở nhiều AZ. EBS bị ràng buộc trong một AZ.
• **A. Instance đơn với Elastic IP — không sẵn sàng cao, không co giãn, một điểm hỏng duy nhất.
• **B. Nhiều instance trong MỘT AZ — AZ đó hỏng là mất toàn bộ. "Highly available" luôn có nghĩa nhiều AZ.

Ghi nhớ

⚠ Ba loại lưu trữ AWS — bảng phải thuộc: | Loại | Gắn được | Phạm vi | Giao thức | |---|---|---|---| | EBS | 1 instance (Multi-Attach: 16 nhưng cùng AZ) | một AZ | block | | EFS | hàng nghìn instance | nhiều AZ | NFS | | FSx for Windows | nhiều instance | nhiều AZ | SMB | | S3 | qua API | vùng | HTTP |

Từ khoá nhận diện:

"shared file storage, multiple EC2, Linux" → EFS "shared file storage, Windows, Active Directory" → FSx for Windows "high-performance computing, Lustre" → FSx for Lustre "single instance, low latency block" → EBS "object storage, unlimited" → S3

⚠ Ba trụ cột của sẵn sàng cao trên AWS: | Trụ cột | Cách làm | |---|---| | Nhiều Availability Zone | bắt buộc | | Không có điểm hỏng duy nhất | | | Tự phục hồi | ASG thay máy hỏng |

Ba chế độ throughput của EFS: | Chế độ | Khi nào | |---|---| | Elastic | mặc định, tải không đoán trước | | Provisioned | cần thông lượng ổn định cao | | Bursting | cũ, theo dung lượng |

⚠ Elastic throughput là mặc định tốt — tự lên xuống theo tải, chỉ trả cho phần dùng.

Ba lớp lưu trữ của EFS: | Lớp | Dùng cho | |---|---| | Standard | truy cập thường xuyên | | Infrequent Access (IA) | rẻ hơn ~90%, phí đọc | | Archive | rất ít truy cập |

Lifecycle policy chuyển tự động:

aws efs put-lifecycle-configuration --file-system-id fs-abc \
  --lifecycle-policies \
    '[{"TransitionToIA":"AFTER_30_DAYS"},
      {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Ba lưu ý về hiệu năng EFS: | Lưu ý | Chi tiết | |---|---| | Độ trễ cao hơn EBS | NFS qua mạng | | Không hợp CSDL đòi độ trễ thấp | | | Rất hợp tệp dùng chung, tài sản web | |

⚠ Đừng đặt CSDL trên EFS — dùng RDS hoặc EBS io2.

Ba lưu ý về bảo mật EFS: | Lưu ý | Chi tiết | |---|---| | Security group cho mount target mở cổng 2049 | | | Mã hoá at rest bằng KMS | | | File system policy giới hạn theo IAM | |

{"Statement":[{"Effect":"Deny","Principal":"*",
  "Action":"*","Condition":{"Bool":
    {"elasticfilesystem:AccessedViaMountTarget":"false"}}}]}

Ba lưu ý về EFS Access Point: | Lưu ý | Chi tiết | |---|---| | Ép POSIX user và thư mục gốc | | | Cô lập ứng dụng trên cùng file system | | | Cần thiết khi Lambda dùng EFS | |

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Cần subnet ở ít nhất 2 AZ | | | Health check quyết định máy nào nhận lưu lượng | | | Sticky session nếu ứng dụng có trạng thái | |

⚠ Nhưng tốt nhất là ứng dụng KHÔNG có trạng thái:

Lưu session trong bộ nhớ máy
    → máy bị thay = người dùng đăng xuất
        ↓
    Đưa session vào ElastiCache hoặc DynamoDB

Ba chính sách mở rộng: | Chính sách | Khi nào | |---|---| | Target tracking | mặc định tốt nhất | | Step scaling | cần kiểm soát chi tiết | | Scheduled | tải theo giờ đoán trước được |

aws autoscaling put-scaling-policy --auto-scaling-group-name asg-web \
  --policy-name theo-cpu --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{"TargetValue":60.0,
    "PredefinedMetricSpecification":
      {"PredefinedMetricType":"ASGAverageCPUUtilization"}}'

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | EFS đắt hơn EBS mỗi GB | | | Nhưng chỉ trả cho phần dùng thật | | | Lifecycle sang IA giảm nhiều | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi tệp ở máy A, đọc ở máy B | | | Tắt một AZ, xem còn phục vụ không | | | Kiểm tra mount target đủ mọi AZ | |

aws efs describe-mount-targets --file-system-id fs-abc \
  --query "MountTargets[].[AvailabilityZoneName,LifeCycleState]" \
  --output table

Và một lời khuyên: hãy kiểm tra EFS có mount target ở mọi AZ mà ASG được phép dùng. Thiếu một AZ không gây lỗi lúc dựng — nó chỉ lộ ra vào ngày Auto Scaling quyết định khởi động máy ở đúng AZ đó, và bạn có một máy chạy mà không phục vụ được gì.

Đáp án

A — Dùng CloudFront geographic restriction với danh sách chặn (deny list) và cấu hình thông báo lỗi tuỳ chỉnh.

Vì sao đúng

Đề nêu hai yêu cầu, và geo restriction đáp ứng cả hai bằng cấu hình sẵn có: | Yêu cầu | Cách đáp ứng | |---|---| | Chặn người dùng ở một số quốc gia | deny list theo mã quốc gia | | Hiện thông báo tuỳ chỉnh cho người bị chặn | custom error response cho HTTP 403 |

⚠ Chặn ở tầng edge là chặn ở nơi rẻ nhất và sớm nhất:

Người dùng ở quốc gia bị chặn
    → CloudFront edge từ chối NGAY
        ↓
    Không chạm tới origin
    → không tốn tài nguyên, không tốn phí truyền dữ liệu

Cấu hình deny list:

aws cloudfront update-distribution --id E1ABCDEF --distribution-config '{
  "Restrictions": {
    "GeoRestriction": {
      "RestrictionType": "blacklist",
      "Quantity": 3,
      "Items": ["CU", "IR", "KP"]}},
  ...}'

⚠ Mã quốc gia dùng chuẩn ISO 3166-1 alpha-2 — hai chữ cái: VN, US, JP.

Thông báo tuỳ chỉnh:

{"CustomErrorResponses": {
  "Quantity": 1,
  "Items": [{
    "ErrorCode": 403,
    "ResponsePagePath": "/khong-phuc-vu-khu-vuc.html",
    "ResponseCode": "403",
    "ErrorCachingMinTTL": 300}]}}

⚠ Trang lỗi phải nằm ở nơi KHÔNG bị chặn:

Đặt trang lỗi trong chính distribution bị geo-block
    → người bị chặn cũng không lấy được trang lỗi
        ↓
    Đặt nó ở một origin riêng, hoặc dùng
    CloudFront Function trả nội dung trực tiếp

Blocklist vs allowlist — chọn theo tình huống: | Kiểu | Khi nào | |---|---| | blacklist (deny list) | chặn vài quốc gia, phục vụ phần còn lại | | whitelist (allow list) | chỉ phục vụ vài quốc gia |

Đề nói "chặn ở một số quốc gia" → deny list là đúng.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Miễn phí — nằm sẵn trong CloudFront | | | Chặn ở edge, không tốn tài nguyên gốc | | | Thay đổi bằng một lệnh, không sửa mã | |

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

• **B. Dùng AWS WAF với quy tắc so mã quốc gia — đây là phương án gần nhất và cũng chặn được theo địa lý, nhưng WAF tính phí theo web ACL, theo quy tắc và theo request, trong khi geo restriction của CloudFront miễn phí. Với yêu cầu đơn giản là chặn cả quốc gia thì WAF là dùng dao mổ trâu.
• **C. Dùng Route 53 geolocation routing — geolocation routing chỉ ra một câu trả lời DNS khác, nó không chặn. Người dùng biết địa chỉ IP vẫn truy cập thẳng được.
• **D. Chặn bằng security group của ALB theo dải IP quốc gia — không có danh sách IP theo quốc gia nào bền vững, security group có giới hạn số quy tắc, và duy trì danh sách đó là công vô tận.

Ghi nhớ

⚠ Ba cách kiểm soát theo địa lý — bảng phải thuộc: | Cách | Bản chất | Phí | |---|---|---| | CloudFront geo restriction | CHẶN ở edge | miễn phí | | AWS WAF geo match rule | CHẶN, kết hợp điều kiện khác | có phí | | Route 53 geolocation routing | ĐỊNH TUYẾN, không chặn | phí truy vấn |

⚠ Phân biệt "chặn" và "định tuyến" — bẫy kinh điển:

Route 53 geolocation: trả IP khác nhau theo vị trí
    → dùng để phục vụ nội dung địa phương
    → KHÔNG phải cơ chế bảo mật
        ↓
CloudFront geo restriction: từ chối phục vụ
    → đây mới là chặn

Từ khoá nhận diện:

"block users from specific countries", "custom message" → CloudFront geo restriction "block by country AND rate limit AND SQL injection" → WAF "serve different content by region" → Route 53 geolocation "comply with licensing by country" → geo restriction hoặc WAF

⚠ Khi nào WAF đáng dùng thay geo restriction: | Tình huống | Vì sao WAF | |---|---| | Chặn quốc gia CHỈ ở một số đường dẫn | geo restriction áp cho cả distribution | | Kết hợp nhiều điều kiện | quốc gia + IP + rate | | Cần log chi tiết yêu cầu bị chặn | | | Áp cho ALB hoặc API Gateway | geo restriction chỉ có ở CloudFront |

WAF geo match rule:

{"Name": "ChanQuocGia", "Priority": 1,
 "Statement": {"GeoMatchStatement":
   {"CountryCodes": ["CU", "IR", "KP"]}},
 "Action": {"Block": {"CustomResponse":
   {"ResponseCode": 403,
    "CustomResponseBodyKey": "thong-bao-khu-vuc"}}},
 "VisibilityConfig": {"SampledRequestsEnabled": true,
   "CloudWatchMetricsEnabled": true, "MetricName": "ChanQuocGia"}}

Ba lưu ý về độ chính xác: | Lưu ý | Chi tiết | |---|---| | Dựa trên cơ sở dữ liệu địa lý IP | | | Không chính xác tuyệt đối | | | VPN và proxy vượt qua được | |

⚠ Đây là giới hạn phải nói rõ với bên pháp lý:

Geo restriction đáp ứng yêu cầu "nỗ lực hợp lý"
    → nhưng KHÔNG chống được người cố tình vượt
        ↓
    Cần chặt hơn: xác minh danh tính,
    kiểm tra phương thức thanh toán, số điện thoại

Ba lưu ý về thông báo tuỳ chỉnh: | Lưu ý | Chi tiết | |---|---| | CloudFront trả 403 cho yêu cầu bị chặn | | | Custom error response đổi trang hiển thị | | | Trang lỗi phải truy cập được từ nơi bị chặn | |

⚠ CloudFront Function trả nội dung trực tiếp — không cần origin:

function handler(event) {
  var quocGia = event.viewer.country;
  var danhSachChan = ['CU', 'IR', 'KP'];
  if (danhSachChan.indexOf(quocGia) !== -1) {
    return {
      statusCode: 403,
      statusDescription: 'Forbidden',
      headers: {'content-type': {value: 'text/html; charset=utf-8'}},
      body: '<h1>Dịch vụ chưa phục vụ khu vực của bạn</h1>'
    };
  }
  return event.request;
}

Ba lưu ý về CloudFront-Viewer-Country: | Lưu ý | Chi tiết | |---|---| | CloudFront thêm header mã quốc gia | | | Ứng dụng đọc được để tuỳ biến | | | Phải bật trong origin request policy | |

Ba lưu ý về cache: | Lưu ý | Chi tiết | |---|---| | Thêm quốc gia vào cache key nếu nội dung khác nhau | | | ErrorCachingMinTTL cache trang lỗi | | | Không cache quá lâu nếu danh sách hay đổi | |

Ba lưu ý về áp dụng thay đổi: | Lưu ý | Chi tiết | |---|---| | Cập nhật distribution mất vài phút lan ra edge | | | Trạng thái InProgress → Deployed | | | Không cần invalidation cho geo restriction | |

aws cloudfront get-distribution --id E1ABCDEF \
  --query "Distribution.Status"

Ba lưu ý về theo dõi: | Lưu ý | Chi tiết | |---|---| | Access log có trường quốc gia | | | WAF log chi tiết hơn nếu dùng WAF | | | CloudWatch metric 4xxErrorRate | |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Ghi tài liệu vì sao chặn quốc gia nào | | | Rà lại danh sách định kỳ | | | Lưu bằng chứng đã áp dụng biện pháp | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử qua VPN đặt ở quốc gia bị chặn | | | Kiểm tra trang lỗi hiện đúng | | | Xem access log ghi nhận đúng quốc gia | |

Và một lời khuyên: hãy kiểm tra trang thông báo tuỳ chỉnh có tải được từ chính quốc gia bị chặn. Đặt nó sau cùng một hàng rào geo restriction là lỗi rất dễ mắc, và kết quả là người dùng nhận một trang 403 trống trơn thay vì lời giải thích mà bạn đã viết.

Đáp án

A — Dùng Amazon FSx for Windows File Server cấu hình Multi-AZ.

Vì sao đúng

Đề nêu hai yêu cầu quyết định, và chỉ một dịch vụ đáp ứng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng WINDOWS cần chia sẻ tệp | FSx for Windows dùng giao thức SMB gốc | | Sẵn sàng cao | Multi-AZ với chuyển đổi tự động |

⚠ SMB là giao thức chia sẻ tệp gốc của Windows:

Ứng dụng Windows chờ đợi:
    → đường dẫn UNC (\\may-chu\thu-muc)
    → quyền NTFS ACL
    → xác thực Active Directory
        ↓
    FSx for Windows cung cấp đủ cả ba

Tạo Multi-AZ:

aws fsx create-file-system --file-system-type WINDOWS \
  --storage-capacity 1000 --storage-type SSD \
  --subnet-ids subnet-a subnet-b \
  --security-group-ids sg-fsx \
  --windows-configuration \
    'DeploymentType=MULTI_AZ_1,
     PreferredSubnetId=subnet-a,
     ThroughputCapacity=32,
     ActiveDirectoryId=d-abc123,
     AutomaticBackupRetentionDays=30'

⚠ DeploymentType=MULTI_AZ_1 là chi tiết quyết định:

SINGLE_AZ_1/2: một AZ
    → AZ hỏng = mất truy cập tệp
        ↓
MULTI_AZ_1:    file server chính + dự phòng ở AZ khác
    → dữ liệu nhân bản đồng bộ
    → chuyển đổi tự động trong vài chục giây

Mount từ Windows:

net use Z: \\amznfsxabc123.corp.vidu.com\share /persistent:yes

⚠ Tên DNS không đổi khi chuyển đổi:

Failover xảy ra
    → DNS trỏ sang file server dự phòng
        ↓
    Ứng dụng dùng cùng đường dẫn UNC
    → không phải cấu hình lại gì

Ba tính năng Windows gốc mà FSx có: | Tính năng | Chi tiết | |---|---| | NTFS ACL đầy đủ | phân quyền theo user/group AD | | Shadow Copies (Previous Versions) | người dùng tự khôi phục tệp | | DFS Namespace | gộp nhiều share thành một cây |

Bật shadow copies:

Invoke-Command -ConfigurationName FSxRemoteAdmin `
  -ScriptBlock { Set-FsxShadowStorage -Default }
Invoke-Command -ConfigurationName FSxRemoteAdmin `
  -ScriptBlock { Set-FsxShadowCopySchedule -Default }

⚠ Shadow copies giảm rất nhiều yêu cầu hỗ trợ:

Người dùng xoá nhầm tệp
    → chuột phải → Previous Versions → khôi phục
        ↓
    Không cần gọi quản trị viên, không cần restore backup

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ứng dụng Windows chạy không sửa gì | | | AWS quản lý vá và sao lưu | | | Chuyển đổi tự động khi AZ hỏng | |

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

• **B. Dùng Amazon EFS — đây là phương án gần nhất về mặt "hệ thống tệp dùng chung", nhưng EFS dùng NFS và không hỗ trợ Windows. Đây là giới hạn tuyệt đối, không có cách vòng nào.
• **C. Dùng EBS Multi-Attach — chỉ hỗ trợ io1/io2, chỉ trong một AZ, và đòi hệ thống tệp cụm. Không đáp ứng "sẵn sàng cao" theo nghĩa nhiều AZ.
• **D. Dùng S3 làm kho chia sẻ — S3 là lưu trữ đối tượng, không phải hệ thống tệp; ứng dụng Windows không mount được nó như ổ đĩa mạng một cách tự nhiên.

Ghi nhớ

⚠ Bốn dịch vụ lưu trữ tệp — bảng phải thuộc: | Dịch vụ | Giao thức | Nền tảng | |---|---|---| | EFS | NFS | Linux | | FSx for Windows | SMB | Windows | | FSx for Lustre | Lustre | HPC, ML | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | cả hai | | FSx for OpenZFS | NFS | Linux |

Từ khoá nhận diện:

"Windows application, shared files, SMB" → FSx for Windows "Linux, NFS, shared" → EFS "HPC, machine learning, high throughput" → FSx for Lustre "both Windows and Linux clients" → FSx for NetApp ONTAP "Active Directory integration" → FSx for Windows

⚠ FSx for NetApp ONTAP là lựa chọn khi cần cả hai:

Máy chủ Windows dùng SMB
Máy chủ Linux dùng NFS
        ↓
    CÙNG một tập dữ liệu
    → ONTAP là dịch vụ duy nhất làm được

Ba lưu ý về Active Directory: | Lưu ý | Chi tiết | |---|---| | FSx BẮT BUỘC phải nối AD | | | Dùng AWS Managed Microsoft AD | | | Hoặc nối AD tại chỗ | |

⚠ Không có AD thì không tạo được FSx for Windows — đây là điều kiện tiên quyết mà nhiều người bỏ sót khi lập kế hoạch.

Ba loại lưu trữ FSx: | Loại | Khi nào | |---|---| | SSD | hầu hết trường hợp, độ trễ thấp | | HDD | dữ liệu lớn ít truy cập, rẻ hơn | | Cả hai đều Multi-AZ được | |

Ba lưu ý về throughput capacity: | Lưu ý | Chi tiết | |---|---| | Đo bằng MB/s, chọn khi tạo | | | Thay đổi được sau này | | | Ảnh hưởng cả IOPS và bộ nhớ đệm | |

aws fsx update-file-system --file-system-id fs-abc \
  --windows-configuration ThroughputCapacity=64

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Sao lưu tự động hằng ngày | | | Giữ tối đa 90 ngày | | | AWS Backup quản lý tập trung được | |

⚠ Multi-AZ KHÔNG thay thế sao lưu:

Multi-AZ bảo vệ khỏi hỏng hạ tầng
    → nhưng nhân bản LUÔN CẢ việc xoá nhầm
        ↓
    Xoá tệp ở AZ chính = xoá luôn ở AZ dự phòng
    → cần sao lưu và shadow copies

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Security group mở cổng SMB (445) | | | Cần cả cổng AD (389, 88, 464...) | | | Truy cập từ tại chỗ qua DX hoặc VPN | |

Ba lưu ý về truy cập lai: | Lưu ý | Chi tiết | |---|---| | Máy tại chỗ mount được qua Direct Connect | | | DNS phải phân giải được tên FSx | | | Route 53 Resolver cho DNS lai | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Multi-AZ có độ trễ ghi cao hơn Single-AZ | nhân bản đồng bộ | | Đọc từ file server chính | | | Cân nhắc Single-AZ cho môi trường không quan trọng | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Multi-AZ đắt gấp đôi Single-AZ | dung lượng nhân đôi | | Tính theo GB cấp phát, không theo GB dùng | | | Data deduplication giảm được nhiều | |

⚠ Bật deduplication tiết kiệm đáng kể:

Invoke-Command -ConfigurationName FSxRemoteAdmin `
  -ScriptBlock { Enable-FsxDedup }

Tệp người dùng thường trùng lặp 50-60%
    → deduplication thu hồi phần lớn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mount từ máy Windows, ghi tệp | | | Kiểm tra DeploymentType | phải là MULTI_AZ_1 | | Thử failover có kế hoạch | |

aws fsx describe-file-systems --file-system-ids fs-abc \
  --query "FileSystems[0].WindowsConfiguration.DeploymentType"

Và một lời khuyên: hãy bật shadow copies ngay sau khi tạo file system. Multi-AZ bảo vệ bạn khỏi hỏng hạ tầng nhưng nhân bản trung thành cả những lần xoá nhầm — và shadow copies là thứ duy nhất cho người dùng tự sửa sai mà không cần mở phiếu hỗ trợ.

Đáp án

A — Dùng Gateway Load Balancer với Gateway Load Balancer endpoint trong một VPC kiểm tra (inspection VPC).

Vì sao đúng

Đề cần đưa toàn bộ lưu lượng qua thiết bị bảo mật của bên thứ ba để kiểm tra, một cách trong suốt và co giãn được.

⚠ Gateway Load Balancer sinh ra đúng cho việc này:

GWLB hoạt động ở TẦNG 3 (network layer)
    → trong suốt hoàn toàn với ứng dụng
    → giữ nguyên IP nguồn và IP đích
        ↓
    Thiết bị kiểm tra thấy gói tin GỐC

Kiến trúc:

VPC ứng dụng
    → route table trỏ 0.0.0.0/0 tới GWLB endpoint
        ↓
    GWLB endpoint (PrivateLink)
        → GWLB trong VPC kiểm tra
            → nhóm đích: các thiết bị tường lửa
                ↓
            Thiết bị kiểm tra, trả lại
        → GWLB trả gói tin về
    → tiếp tục tới đích

⚠ Giao thức GENEVE là thứ làm nên tính trong suốt:

GWLB đóng gói gói tin gốc trong GENEVE (cổng 6081)
    → gửi tới thiết bị kiểm tra
        ↓
    Thiết bị gỡ gói, thấy gói tin NGUYÊN VẸN
    → kiểm tra rồi trả lại
        ↓
    Không NAT, không đổi IP, không đổi cổng

Dựng GWLB:

aws elbv2 create-load-balancer --name gwlb-kiem-tra \
  --type gateway --subnets subnet-kiem-tra-a subnet-kiem-tra-b

aws elbv2 create-target-group --name nhom-tuong-lua \
  --protocol GENEVE --port 6081 --vpc-id vpc-kiem-tra \
  --target-type instance --health-check-protocol TCP

Tạo endpoint service và endpoint:

aws ec2 create-vpc-endpoint-service-configuration \
  --gateway-load-balancer-arns <arn-gwlb>

aws ec2 create-vpc-endpoint --vpc-id vpc-ung-dung \
  --service-name com.amazonaws.vpce.ap-southeast-1.vpce-svc-abc \
  --vpc-endpoint-type GatewayLoadBalancer \
  --subnet-ids subnet-ung-dung-a

Định tuyến qua endpoint:

aws ec2 create-route --route-table-id rtb-ung-dung \
  --destination-cidr-block 0.0.0.0/0 \
  --vpc-endpoint-id vpce-abc

⚠ Duy trì phiên (flow stickiness) là điều then chốt:

GWLB gửi CẢ HAI CHIỀU của một luồng
tới CÙNG một thiết bị
    → thiết bị stateful thấy đủ cả yêu cầu và phản hồi
        ↓
    Không có tính chất này thì tường lửa stateful vô dụng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Co giãn thiết bị bằng Auto Scaling | | | Trong suốt — ứng dụng không sửa gì | | | Một VPC kiểm tra dùng chung cho nhiều VPC | |

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

• **D. Dùng Network Load Balancer trước các thiết bị — đây là phương án gần nhất vì NLB cũng ở tầng 4 và giữ được IP nguồn, nhưng NLB là cân bằng tải cho dịch vụ đích, không phải cơ chế chèn thiết bị vào giữa đường đi. Nó không đóng gói GENEVE và không đảm bảo cả hai chiều tới cùng thiết bị.
• **B. Dùng Application Load Balancer — ALB ở tầng 7, kết thúc kết nối và tạo kết nối mới tới đích. Thiết bị kiểm tra sẽ không thấy gói tin gốc, và ALB chỉ xử lý HTTP/HTTPS.
• **C. Dùng NAT gateway để định tuyến qua thiết bị — NAT gateway chỉ dịch địa chỉ cho lưu lượng đi ra, không chèn được thiết bị kiểm tra vào đường đi.

Ghi nhớ

⚠ Bốn loại Elastic Load Balancing — bảng phải thuộc: | Loại | Tầng | Dùng cho | |---|---|---| | Application (ALB) | 7 | HTTP/HTTPS, định tuyến theo đường dẫn | | Network (NLB) | 4 | TCP/UDP, độ trễ cực thấp, IP tĩnh | | Gateway (GWLB) | 3 | chèn thiết bị bảo mật | | Classic (CLB) | 4/7 | cũ, không dùng cho thiết kế mới |

Từ khoá nhận diện:

"third-party security appliance", "transparent inspection" → GWLB "HTTP routing by path or host" → ALB "millions of requests, static IP, TCP" → NLB "managed firewall by AWS" → AWS Network Firewall

⚠ GWLB vs AWS Network Firewall:

GWLB: bạn TỰ chọn và quản lý thiết bị
      (Palo Alto, Fortinet, Check Point...)
    → linh hoạt, dùng lại license và kỹ năng sẵn có
        ↓
Network Firewall: AWS quản lý hoàn toàn
    → ít việc hơn, ít lựa chọn hơn

Ba mô hình kiến trúc kiểm tra: | Mô hình | Chi tiết | |---|---| | VPC kiểm tra tập trung | một VPC, nhiều VPC dùng chung | | Kiểm tra phân tán | mỗi VPC một GWLB endpoint | | Kết hợp Transit Gateway | định tuyến tập trung |

⚠ Mô hình tập trung với Transit Gateway là chuẩn cho tổ chức lớn:

Mọi VPC gắn vào Transit Gateway
    → TGW route table đưa lưu lượng qua VPC kiểm tra
        ↓
    Một chỗ quản lý chính sách bảo mật
    → thêm VPC mới tự động được bảo vệ

Ba loại lưu lượng cần kiểm tra: | Loại | Cách định tuyến | |---|---| | Ra Internet (egress) | route 0.0.0.0/0 tới GWLB endpoint | | Vào từ Internet (ingress) | route ở IGW route table | | Giữa các VPC (east-west) | qua TGW |

⚠ Ingress routing cần route table cho internet gateway:

aws ec2 create-route --route-table-id rtb-igw \
  --destination-cidr-block 10.1.1.0/24 \
  --vpc-endpoint-id vpce-abc

Lưu lượng từ Internet vào cũng bị chuyển qua kiểm tra
    → trước khi chạm tới ALB hay EC2

Ba lưu ý về thiết bị kiểm tra: | Lưu ý | Chi tiết | |---|---| | Phải hỗ trợ GENEVE | không phải thiết bị nào cũng có | | Đặt trong Auto Scaling group | | | Health check quyết định thiết bị nào nhận lưu lượng | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Mỗi bước nhảy thêm độ trễ | | | Chọn cỡ instance đủ mạnh | | | Bật enhanced networking | |

⚠ Cân nhắc phạm vi kiểm tra:

Kiểm tra MỌI gói tin
    → độ trễ và chi phí cao nhất
        ↓
    Cân nhắc chỉ kiểm tra lưu lượng ra Internet
    và lưu lượng giữa các vùng tin cậy khác nhau

Ba lưu ý về tính sẵn sàng: | Lưu ý | Chi tiết | |---|---| | GWLB endpoint mỗi AZ | | | Thiết bị trải nhiều AZ | | | Route table theo AZ trỏ endpoint cùng AZ | |

⚠ Trỏ sang endpoint ở AZ khác gây phí liên AZ và độ trễ thừa:

Subnet ở AZ-a trỏ tới endpoint ở AZ-b
    → gói tin đi vòng qua AZ khác rồi quay lại
        ↓
    Mỗi route table nên trỏ endpoint CÙNG AZ

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí giờ GWLB | | | Phí GLCU xử lý | | | Phí endpoint mỗi giờ mỗi AZ | | | Cộng license thiết bị bên thứ ba | |

Ba lưu ý về gỡ lỗi: | Lưu ý | Chi tiết | |---|---| | VPC Flow Logs ở cả hai VPC | | | Log của chính thiết bị | | | Reachability Analyzer kiểm đường đi | |

Ba lưu ý về vận hành: | Lưu ý | Chi tiết | |---|---| | Cập nhật thiết bị theo kiểu blue/green | | | Kiểm tra fail-open hay fail-closed | | | Diễn tập mất toàn bộ thiết bị | |

⚠ Quyết định fail-open hay fail-closed phải có chủ ý:

Mọi thiết bị hỏng health check
    → GWLB không có đích nào
        ↓
    Lưu lượng BỊ CHẶN (fail-closed)
    → ứng dụng ngừng hoạt động
        ↓
    Đây thường là hành vi ĐÚNG cho bảo mật,
    nhưng phải biết trước và có kế hoạch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem log thiết bị có thấy lưu lượng | | | Kiểm tra IP nguồn giữ nguyên | | | Tắt một thiết bị, xem còn chạy không | |

Và một lời khuyên: hãy diễn tập trường hợp mọi thiết bị kiểm tra cùng hỏng health check. GWLB fail-closed nghĩa là toàn bộ ứng dụng ngừng hoạt động khi tầng bảo mật sập — đó thường là lựa chọn đúng, nhưng nó phải là lựa chọn bạn biết trước chứ không phải phát hiện lúc 3 giờ sáng.

Đáp án

C — Dùng SMB client để mount Amazon FSx for Windows File Server ở cả tại chỗ lẫn trong VPC, kết nối qua Direct Connect.

Vì sao đúng

Đề mô tả tình huống lai: máy chủ tại trung tâm dữ liệu và máy chủ trong AWS cùng cần truy cập một kho tệp Windows, đã có Direct Connect nối hai bên.

⚠ Điểm mạnh là chỉ có MỘT bản dữ liệu:

Giải pháp đồng bộ hai chiều:
    → hai bản, phải giải quyết xung đột
    → luôn có độ trễ
        ↓
FSx mount từ hai phía:
    → một bản duy nhất
    → ai ghi cũng thấy ngay

Mount từ máy chủ trong VPC:

net use Z: \\amznfsxabc123.corp.vidu.com\share /persistent:yes

Mount từ máy chủ tại chỗ — cùng một lệnh:

net use Z: \\amznfsxabc123.corp.vidu.com\share /persistent:yes

⚠ Ba điều kiện để mount từ tại chỗ hoạt động: | Điều kiện | Chi tiết | |---|---| | Đường mạng riêng tư | Direct Connect hoặc VPN | | DNS phân giải được tên FSx | Route 53 Resolver inbound endpoint | | Security group cho phép cổng SMB (445) | |

DNS là chỗ hay hỏng nhất:

Máy tại chỗ hỏi DNS của mình
    → không biết tên amznfsx...
        ↓
    Cần Route 53 Resolver inbound endpoint
    → DNS tại chỗ chuyển tiếp truy vấn vào VPC

Dựng inbound endpoint:

aws route53resolver create-resolver-endpoint \
  --name endpoint-vao --direction INBOUND \
  --security-group-ids sg-resolver \
  --ip-addresses SubnetId=subnet-a SubnetId=subnet-b

Rồi cấu hình DNS tại chỗ chuyển tiếp vùng amazonaws.com (hoặc vùng AD) tới IP của endpoint đó.

⚠ Direct Connect quan trọng vì SMB nhạy với độ trễ:

SMB là giao thức "chatty"
    → nhiều vòng trao đổi cho một thao tác
        ↓
    Qua Internet: độ trễ cao và biến động
    → mở một thư mục lớn mất hàng chục giây
        ↓
    Direct Connect: độ trễ thấp và ổn định

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nguồn dữ liệu, không xung đột | | | Ứng dụng không sửa gì | vẫn là đường dẫn UNC | | AWS quản lý sao lưu và vá | |

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

• **B. Dùng AWS DataSync đồng bộ giữa tại chỗ và FSx — đây là phương án gần nhất và là công cụ đúng cho việc DI CHUYỂN dữ liệu, nhưng nó tạo ra hai bản sao cần đồng bộ định kỳ. Đề cần truy cập đồng thời, không phải nhân bản.
• **A. Dùng Storage Gateway File Gateway với S3 — File Gateway trình bày S3 dưới dạng share, nhưng dữ liệu thực nằm ở S3 với ngữ nghĩa đối tượng; nó không cho khoá tệp và ACL đầy đủ như ứng dụng Windows chờ đợi.
• **D. Dùng EFS mount từ cả hai nơi — EFS dùng NFS, không hỗ trợ Windows.

Ghi nhớ

⚠ Bốn cách kết nối lưu trữ lai — bảng phải thuộc: | Cách | Bản chất | |---|---| | FSx mount từ hai phía | một bản, truy cập đồng thời | | DataSync | sao chép một chiều theo lịch | | Storage Gateway File Gateway | cache tại chỗ, gốc ở S3 | | FSx File Gateway | cache tại chỗ, gốc ở FSx |

Từ khoá nhận diện:

"access same files from on-premises AND AWS" → mount FSx từ cả hai "migrate/copy data to AWS" → DataSync "low-latency local access, data in S3" → File Gateway "on-prem latency to FSx too high" → FSx File Gateway

⚠ FSx File Gateway đáng biết khi độ trễ là vấn đề:

Máy tại chỗ mount thẳng FSx qua DX
    → mỗi thao tác đi qua đường mạng
        ↓
FSx File Gateway đặt tại chỗ
    → cache tệp hay dùng ở local
    → đọc lại rất nhanh

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Băng thông cam kết, độ trễ ổn định | | | Nên có VPN dự phòng | | | Private VIF để tới VPC | |

⚠ Direct Connect một đường KHÔNG phải sẵn sàng cao:

Một kết nối DX đứt
    → mất toàn bộ truy cập tệp
        ↓
    Có VPN dự phòng, hoặc DX thứ hai ở địa điểm khác

Ba lưu ý về Active Directory: | Lưu ý | Chi tiết | |---|---| | FSx cần AD | | | Nối AD tại chỗ hoặc dựng AWS Managed AD có trust | | | Cùng danh tính ở hai bên = quyền nhất quán | |

⚠ Đây là lợi ích lớn ít được nhắc:

Người dùng đăng nhập bằng tài khoản AD
    → cùng quyền NTFS dù truy cập từ đâu
        ↓
    Không phải quản lý hai hệ thống quyền

Ba cổng cần mở: | Cổng | Dịch vụ | |---|---| | 445 | SMB | | 53 | DNS | | 88, 389, 464 | Kerberos, LDAP |

Ba lưu ý về hiệu năng SMB qua WAN: | Lưu ý | Chi tiết | |---|---| | SMB 3.x có multichannel | | | Bật SMB signing ảnh hưởng tốc độ | | | Tệp nhỏ và nhiều là trường hợp xấu nhất | |

Ba lưu ý về sẵn sàng: | Lưu ý | Chi tiết | |---|---| | FSx Multi-AZ cho môi trường sản xuất | | | DNS không đổi khi failover | | | Sao lưu tự động hằng ngày | |

Ba lưu ý về di chuyển dữ liệu ban đầu: | Lưu ý | Chi tiết | |---|---| | DataSync để chuyển lần đầu | | | Giữ nguyên ACL và timestamp | | | Snowball nếu quá lớn | |

⚠ DataSync và mount không loại trừ nhau:

Dùng DataSync CHUYỂN dữ liệu vào FSx lần đầu
    → rồi mount FSx từ cả hai phía
        ↓
    Đúng công cụ cho đúng giai đoạn

aws datasync create-task \
  --source-location-arn <arn-smb-tai-cho> \
  --destination-location-arn <arn-fsx> \
  --options 'PreserveDeletedFiles=PRESERVE,Gid=NONE,Uid=NONE'

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudWatch metric của FSx | | | Theo dõi throughput và độ trễ | | | Cảnh báo khi dung lượng gần đầy | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | FSx theo GB cấp phát | | | Direct Connect phí cổng + truyền dữ liệu | | | Truyền qua DX rẻ hơn qua Internet | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mount từ máy tại chỗ | | | Ghi tệp ở AWS, đọc ở tại chỗ | | | Đo độ trễ mở thư mục lớn | |

Resolve-DnsName amznfsxabc123.corp.vidu.com
Test-NetConnection amznfsxabc123.corp.vidu.com -Port 445

Và một lời khuyên: hãy kiểm tra DNS trước khi kiểm tra bất cứ thứ gì khác khi mount FSx từ tại chỗ. Lỗi hầu như luôn nằm ở chỗ máy tại chỗ không phân giải nổi tên FSx, nhưng triệu chứng lại giống hệt một vấn đề mạng — và bạn sẽ mất cả buổi soi security group đã cấu hình đúng.

Đáp án

D — Chuyển sang Amazon Aurora Serverless cho CSDL.

Vì sao đúng

Đề mô tả CSDL MySQL có tải lên xuống thất thường và khó đoán, cần tự co giãn và tối ưu chi phí mà không đổi engine.

⚠ Aurora Serverless v2 mở rộng theo bước rất mịn:

Đơn vị: ACU (Aurora Capacity Unit) — ~2 GB RAM
    → tăng giảm theo bước 0,5 ACU
        ↓
    Phản ứng trong VÀI GIÂY
    → khác hẳn v1 vốn mất vài chục giây và cần
      "điểm mở rộng" an toàn

Tạo cụm:

aws rds create-db-cluster --db-cluster-identifier cum-ung-dung \
  --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.05.2 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=64 \
  --master-username quantri --manage-master-user-password

aws rds create-db-instance --db-instance-identifier phien-ban-1 \
  --db-cluster-identifier cum-ung-dung \
  --db-instance-class db.serverless --engine aurora-mysql

⚠ Tương thích MySQL nghĩa là không đổi mã:

Cùng driver MySQL
Cùng câu SQL
Cùng công cụ quản trị
        ↓
    Chỉ đổi chuỗi kết nối

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải đoán cỡ instance | | | Chi phí theo mức dùng thật | | | Vẫn có mọi tính năng Aurora | |

⚠ "Mọi tính năng Aurora" là điểm mạnh dễ bị bỏ qua: | Tính năng | Chi tiết | |---|---| | Lưu trữ tự mở rộng tới 128 TB | | | 6 bản sao dữ liệu trên 3 AZ | | | Read replica độ trễ thấp | | | Backtrack quay ngược thời gian | | | Global Database cho DR | |

Trộn serverless và provisioned trong cùng cụm:

Writer:  db.serverless (tải thất thường)
Reader:  db.r6g.large (báo cáo chạy đều)
        ↓
    Aurora cho phép trộn — tối ưu từng vai trò

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

• **C. Dùng RDS for MySQL với storage autoscaling — đây là phương án gần nhất và cũng giữ nguyên MySQL, nhưng storage autoscaling chỉ mở rộng DUNG LƯỢNG ĐĨA, không mở rộng CPU và bộ nhớ. Tải tính toán thất thường vẫn phải tự đổi cỡ instance thủ công.
• **A. Chuyển sang DynamoDB — DynamoDB tự co giãn tốt, nhưng là NoSQL: phải viết lại toàn bộ mô hình dữ liệu và truy vấn. Đề không nói ứng dụng được phép đổi engine.
• **B. Dùng RDS Multi-AZ — Multi-AZ là cơ chế sẵn sàng cao, hoàn toàn không liên quan tới co giãn theo tải; standby của RDS còn không phục vụ đọc.

Ghi nhớ

⚠ Bốn lựa chọn CSDL quan hệ trên AWS — bảng phải thuộc: | Lựa chọn | Co giãn tính toán | Khi nào | |---|---|---| | RDS | thủ công đổi cỡ | tải ổn định, chi phí thấp | | Aurora provisioned | thủ công + auto scaling reader | tải ổn định, hiệu năng cao | | Aurora Serverless v2 | TỰ ĐỘNG theo giây | tải thất thường | | Aurora Limitless | tự động, phân mảnh | quy mô cực lớn |

Từ khoá nhận diện:

"unpredictable workload", "auto-scale compute", "keep MySQL" → Aurora Serverless v2 "storage keeps growing" → RDS storage autoscaling "high availability" → Multi-AZ "read-heavy" → read replica "key-value, single-digit ms" → DynamoDB

⚠ Phân biệt ba loại "auto scaling" cho CSDL:

Storage autoscaling:  chỉ ĐĨA
Read replica autoscaling: thêm bản sao ĐỌC
Serverless v2:        CPU và RAM của writer
        ↓
    Ba thứ khác nhau, giải ba vấn đề khác nhau

Ba lưu ý về ACU: | Lưu ý | Chi tiết | |---|---| | 1 ACU ≈ 2 GB RAM + CPU và mạng tương ứng | | | Min 0 hoặc 0,5, max tới 256 | | | Tính phí theo ACU-giây | |

⚠ Min capacity 0 cho phép tạm dừng hẳn:

Aurora Serverless v2 hỗ trợ scale tới 0
    → CSDL dev không dùng ban đêm = không tốn tiền tính toán
        ↓
    Nhưng lần kết nối đầu sau khi ngủ có độ trễ khởi động
    → không đặt 0 cho môi trường sản xuất

Ba lưu ý về đặt min và max: | Lưu ý | Chi tiết | |---|---| | Min quá thấp → chậm lúc tải tăng đột ngột | | | Max quá thấp → chạm trần, truy vấn xếp hàng | | | Max quá cao → hoá đơn bất ngờ | |

⚠ Đặt CloudWatch alarm cho ServerlessDatabaseCapacity:

aws cloudwatch put-metric-alarm --alarm-name aurora-cham-tran \
  --namespace AWS/RDS --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBClusterIdentifier,Value=cum-ung-dung \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 60 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

Ba khác biệt v1 và v2 (v2 tốt hơn hẳn): | Tiêu chí | v1 | v2 | |---|---|---| | Tốc độ mở rộng | chục giây | giây | | Bước mở rộng | gấp đôi | 0,5 ACU | | Read replica | ❌ | ✅ | | Multi-AZ | hạn chế | ✅ | | Global Database | ❌ | ✅ |

⚠ Dùng v2, không dùng v1 cho mọi thiết kế mới.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính toán theo ACU-giờ | | | Lưu trữ theo GB-tháng | | | I/O tính riêng — trừ khi dùng I/O-Optimized | |

⚠ Aurora I/O-Optimized đáng cân nhắc:

Cấu hình mặc định: trả phí theo số I/O
    → tải I/O nặng có thể chiếm hơn 25% hoá đơn
        ↓
I/O-Optimized: giá tính toán và lưu trữ cao hơn,
               nhưng I/O MIỄN PHÍ
    → rẻ hơn khi I/O chiếm trên 25%

Ba lưu ý về chuyển đổi từ RDS MySQL: | Cách | Chi tiết | |---|---| | Tạo Aurora read replica từ RDS rồi promote | ít gián đoạn nhất | | Snapshot rồi restore sang Aurora | có gián đoạn | | DMS cho di chuyển liên tục | |

aws rds create-db-cluster --db-cluster-identifier cum-moi \
  --engine aurora-mysql \
  --replication-source-identifier <arn-rds-mysql>

Ba lưu ý về kết nối: | Endpoint | Việc | |---|---| | Cluster endpoint | ghi, trỏ tới writer | | Reader endpoint | cân bằng tải giữa reader | | Custom endpoint | nhóm instance tuỳ chọn |

Ba lưu ý về gộp kết nối: | Lưu ý | Chi tiết | |---|---| | RDS Proxy giảm áp lực kết nối | | | Quan trọng khi Lambda gọi CSDL | | | Giữ kết nối qua lúc failover | |

Ba lưu ý về theo dõi: | Metric | Ý nghĩa | |---|---| | ServerlessDatabaseCapacity | ACU đang dùng | | ACUUtilization | tỷ lệ so với max | | Performance Insights | truy vấn nào tốn nhất |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy tải giả, xem ACU tăng | | | Kiểm tra chi phí sau một tháng | | | Xác nhận ứng dụng chạy không sửa mã | |

Và một lời khuyên: hãy đặt max capacity ở mức bạn sẵn sàng trả tiền, không phải mức bạn nghĩ là đủ. Aurora Serverless mở rộng mượt tới đâu thì hoá đơn cũng mượt tới đó — một truy vấn thiếu index chạy trong vòng lặp có thể đẩy cụm lên trần và giữ nó ở đó suốt đêm.

Đáp án

C — Dùng AWS Firewall Manager để cấu hình tập trung các quy tắc AWS WAF trên cả hai Region.

Vì sao đúng

Đề nêu yêu cầu: áp cùng một bộ quy tắc WAF cho tài nguyên ở nhiều Region (và thường là nhiều tài khoản), quản lý tập trung.

⚠ Firewall Manager sinh ra đúng cho bài toán này:

Không có nó:
    → tạo web ACL ở mỗi Region
    → sửa quy tắc = sửa từng nơi
    → tài nguyên mới có thể quên gắn
        ↓
Firewall Manager:
    → viết chính sách MỘT LẦN
    → tự áp cho mọi Region và tài khoản
    → tài nguyên mới TỰ ĐỘNG được bảo vệ

⚠ "Tự động áp cho tài nguyên mới" là giá trị lớn nhất:

Nhóm A dựng ALB mới ở Region thứ hai
    → quên gắn WAF
        ↓
    Firewall Manager phát hiện và gắn tự động
    → hoặc báo là không tuân thủ

Chính sách Firewall Manager:

{"PolicyName": "waf-chuan-toan-to-chuc",
 "SecurityServiceType": "WAFV2",
 "ResourceType": "AWS::ElasticLoadBalancingV2::LoadBalancer",
 "ResourceTags": [{"Key": "MoiTruong", "Value": "san-xuat"}],
 "ExcludeResourceTags": false,
 "RemediationEnabled": true,
 "IncludeMap": {"ORG_UNIT": ["ou-abc-sanxuat"]}}

Ba điều kiện tiên quyết: | Điều kiện | Chi tiết | |---|---| | AWS Organizations bật all features | | | Chỉ định một tài khoản quản trị Firewall Manager | | | Bật AWS Config ở mọi tài khoản và Region | |

aws fms associate-admin-account \
  --admin-account 123456789012

⚠ AWS Config là điều kiện hay bị bỏ sót:

Firewall Manager dựa vào Config để BIẾT có tài nguyên nào
    → Config chưa bật ở Region nào
        ↓
    Region đó vô hình với Firewall Manager
    → chính sách không áp, mà cũng không báo lỗi rõ

Ba loại chính sách Firewall Manager quản được: | Loại | Việc | |---|---| | AWS WAF | quy tắc web ACL | | AWS Shield Advanced | bảo vệ DDoS | | Security group | quy tắc kiểm tra và sửa | | Network Firewall, DNS Firewall | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nơi định nghĩa, mọi nơi áp dụng | | | Tự động khắc phục tài nguyên chưa tuân thủ | | | Báo cáo tuân thủ tập trung | |

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

• **B. Tạo web ACL riêng ở mỗi Region và đồng bộ thủ công — đây là phương án gần nhất và cho ra kết quả tương đương lúc ban đầu, nhưng công vận hành tăng theo số Region, và sai lệch giữa các Region là chuyện chắc chắn xảy ra theo thời gian.
• **A. Dùng AWS Config rules — Config phát hiện vi phạm nhưng không phải công cụ triển khai quy tắc WAF. (Nó là điều kiện tiên quyết của Firewall Manager, không phải giải pháp thay thế.)
• **D. Dùng Systems Manager để đẩy cấu hình — Systems Manager quản lý instance, không quản lý web ACL.

Ghi nhớ

⚠ Ba tầng quản lý bảo mật nhiều tài khoản — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS Organizations | cấu trúc tài khoản, SCP | | Firewall Manager | áp chính sách tường lửa tập trung | | Security Hub | tổng hợp phát hiện bảo mật |

Từ khoá nhận diện:

"same WAF rules across Regions/accounts", "centrally" → Firewall Manager "detect non-compliant resources" → AWS Config "aggregate security findings" → Security Hub "restrict what accounts can do" → SCP "protect one application" → WAF trực tiếp

⚠ WAF có hai phạm vi khác nhau: | Phạm vi | Gắn vào | |---|---| | CLOUDFRONT | CloudFront — tạo ở us-east-1 | | REGIONAL | ALB, API Gateway, AppSync — cùng Region |

Web ACL cho CloudFront BẮT BUỘC tạo ở us-east-1
    → dù distribution phục vụ toàn cầu
        ↓
    Đây là ngoại lệ hay gây nhầm

Ba nhóm quy tắc nên bật: | Nhóm | Việc | |---|---| | AWSManagedRulesCommonRuleSet | OWASP Top 10 cơ bản | | AWSManagedRulesKnownBadInputsRuleSet | mẫu tấn công đã biết | | AWSManagedRulesAmazonIpReputationList | IP xấu đã biết |

⚠ Luôn chạy COUNT trước khi chuyển sang BLOCK:

Bật BLOCK ngay
    → quy tắc quản lý có thể chặn nhầm lưu lượng hợp lệ
        ↓
    Chạy COUNT vài ngày, xem log
    → chỉnh ngoại lệ rồi mới BLOCK

Ba loại quy tắc tự viết: | Loại | Việc | |---|---| | Rate-based | chặn IP gửi quá nhiều | | Geo match | chặn theo quốc gia | | IP set | danh sách cho phép hoặc chặn |

Rate-based rule:

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

Ba lưu ý về chính sách Firewall Manager: | Lưu ý | Chi tiết | |---|---| | Chọn phạm vi bằng OU hoặc tag | | | RemediationEnabled để tự sửa | | | Có thể chỉ báo cáo, không sửa | |

⚠ Cân nhắc bật remediation từ từ:

Bật tự động khắc phục ngay từ đầu
    → có thể gắn WAF vào ứng dụng chưa sẵn sàng
        ↓
    Chạy chế độ báo cáo trước
    → xem danh sách không tuân thủ
    → rồi mới bật khắc phục

Ba lưu ý về chi phí WAF: | Khoản | Giá tham khảo | |---|---| | Web ACL | ~5 USD/tháng | | Mỗi quy tắc | ~1 USD/tháng | | Mỗi triệu request | ~0,60 USD | | Firewall Manager | ~100 USD/tháng mỗi loại chính sách |

Ba lưu ý về logging: | Lưu ý | Chi tiết | |---|---| | Log WAF ra Kinesis Firehose, S3 hoặc CloudWatch | | | Che trường nhạy cảm | | | Athena truy vấn log | |

aws wafv2 put-logging-configuration --logging-configuration \
  'ResourceArn=<arn-web-acl>,
   LogDestinationConfigs=<arn-firehose>,
   RedactedFields=[{SingleHeader={Name=authorization}}]'

Ba lưu ý về Shield Advanced: | Lưu ý | Chi tiết | |---|---| | ~3.000 USD/tháng cho cả tổ chức | | | Có đội phản ứng DDoS | | | Hoàn phí mở rộng do tấn công | |

Ba lưu ý về kiểm thử: | Lưu ý | Chi tiết | |---|---| | Kiểm tra ở môi trường thử trước | | | Xem SampledRequests để hiểu quy tắc nào khớp | | | Đặt alarm cho tỷ lệ chặn tăng đột biến | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem báo cáo tuân thủ của Firewall Manager | | | Tạo ALB mới, xem có được gắn WAF không | | | Gửi yêu cầu độc hại thử | |

aws fms get-compliance-detail --policy-id <id> \
  --member-account 123456789012

Và một lời khuyên: hãy bật AWS Config ở mọi Region trước khi tạo chính sách Firewall Manager. Region thiếu Config không báo lỗi — nó chỉ đơn giản không xuất hiện trong báo cáo tuân thủ, và bạn sẽ tin rằng mọi thứ đã được bảo vệ trong khi cả một Region đang để trống.

Đáp án

B — Dùng Amazon EFS cho lưu trữ dùng chung.

Vì sao đúng

Đề cần nhiều instance cùng đọc ghi một tập dữ liệu với tính nhất quán mạnh — mọi máy phải thấy cùng một nội dung ngay sau khi có máy ghi.

⚠ EFS cung cấp ngữ nghĩa hệ thống tệp POSIX đầy đủ:

Máy A ghi tệp và đóng file handle
    → máy B mở tệp đó
        ↓
    Thấy NGAY nội dung mới
    → đây là read-after-write consistency của NFS

Ba tính chất mà chỉ hệ thống tệp mới có: | Tính chất | Chi tiết | |---|---| | Khoá tệp (file locking) | nhiều tiến trình phối hợp ghi | | Cập nhật một PHẦN tệp | không phải ghi lại cả tệp | | Ngữ nghĩa thư mục | đổi tên nguyên tử, quyền POSIX |

⚠ Đây là khác biệt bản chất với lưu trữ đối tượng:

S3:  object là BẤT BIẾN
     → sửa một byte = ghi lại toàn bộ object
     → không có khoá, không có ghi đồng thời có phối hợp
        ↓
EFS: sửa được từng phần, khoá được, nối thêm được

Dựng và mount:

aws efs create-file-system --performance-mode generalPurpose \
  --throughput-mode elastic --encrypted

aws efs create-mount-target --file-system-id fs-abc \
  --subnet-id subnet-a --security-groups sg-efs

yum install -y amazon-efs-utils
mount -t efs -o tls,iam fs-abc:/ /du-lieu-chung

⚠ Dùng amazon-efs-utils thay vì mount NFS thô: | Lợi ích | Chi tiết | |---|---| | Mã hoá khi truyền bằng tls | | | Xác thực IAM bằng iam | | | Tự chọn tham số mount tối ưu | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hàng nghìn instance mount đồng thời | | | Tự mở rộng, không cần cấp dung lượng | | | Trải nhiều AZ mặc định | |

⚠ "Không cần cấp dung lượng" đúng theo nghĩa đen:

Không có bước chọn kích thước
    → ghi thêm tệp = tự lớn ra
    → xoá tệp = tự nhỏ lại
        ↓
    Chỉ trả tiền cho GB đang lưu

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

• **D. Dùng S3 cho lưu trữ dùng chung — đây là phương án gần nhất và cũng cho nhiều máy truy cập chung, nhưng S3 là lưu trữ đối tượng: không mount như hệ thống tệp, không khoá tệp, không sửa được một phần. Ứng dụng phải viết lại theo API.
• **A. Dùng EBS gắn vào mỗi instance — mỗi volume EBS là kho riêng của một instance; dữ liệu không dùng chung được, và EBS bị ràng buộc trong một AZ.
• **C. Dùng instance store — lưu trữ tạm, mất dữ liệu khi instance dừng, và cũng không dùng chung được.

Ghi nhớ

⚠ Bốn loại lưu trữ EC2 — bảng phải thuộc: | Loại | Dùng chung | Bền vững | |---|---|---| | EFS | có, hàng nghìn máy | ✅ | | EBS | không (Multi-Attach hạn chế) | ✅ | | Instance store | không | ❌ mất khi dừng máy | | S3 | qua API | ✅ |

Từ khoá nhận diện:

"shared file system, multiple instances, POSIX" → EFS "object storage, unlimited, static assets" → S3 "boot volume, database volume" → EBS "temporary scratch, highest IOPS" → instance store

⚠ Instance store có chỗ dùng chính đáng:

Dữ liệu TẠM: cache, scratch space, shuffle của Spark
    → IOPS cao nhất, độ trễ thấp nhất, miễn phí
        ↓
    Nhưng mất khi stop, terminate, hoặc máy hỏng
    → không bao giờ lưu thứ không tái tạo được

Ba chế độ hiệu năng của EFS: | Chế độ | Khi nào | |---|---| | General Purpose | mặc định, độ trễ thấp nhất | | Max I/O | hàng nghìn client, độ trễ cao hơn | | Elastic throughput | mặc định mới, tự lên xuống |

⚠ Chế độ hiệu năng KHÔNG đổi được sau khi tạo — phải tạo file system mới và chuyển dữ liệu.

Ba lớp lưu trữ và lifecycle: | Lớp | Giá tương đối | |---|---| | Standard | 100% | | Infrequent Access | ~8% + phí đọc | | Archive | ~4% + phí đọc cao hơn |

aws efs put-lifecycle-configuration --file-system-id fs-abc \
  --lifecycle-policies \
    '[{"TransitionToIA":"AFTER_30_DAYS"},
      {"TransitionToArchive":"AFTER_90_DAYS"},
      {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

⚠ Lifecycle của EFS tiết kiệm rất nhiều:

Phần lớn dữ liệu tệp không được đọc lại sau 30 ngày
    → chuyển sang IA giảm ~92% chi phí lưu trữ
        ↓
    Ai đọc tới thì tự chuyển lại Standard

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Độ trễ cao hơn EBS | qua mạng | | Thông lượng tăng theo dung lượng (chế độ bursting) | | | Elastic throughput tránh vấn đề đó | |

⚠ Bursting credit là bẫy kinh điển của EFS:

File system nhỏ ở chế độ bursting
    → thông lượng cơ sở rất thấp
    → cạn credit thì chậm thảm hại
        ↓
    Dùng Elastic throughput, hoặc Provisioned

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Security group mở cổng 2049 (NFS) | | | Mã hoá at rest bằng KMS khi tạo | | | File system policy giới hạn theo IAM | |

⚠ Mã hoá at rest chỉ bật được LÚC TẠO — không bật sau được.

Ba lưu ý về EFS Access Point: | Lưu ý | Chi tiết | |---|---| | Ép thư mục gốc riêng cho mỗi ứng dụng | | | Ép POSIX user và group | | | Bắt buộc khi Lambda dùng EFS | |

aws efs create-access-point --file-system-id fs-abc \
  --posix-user 'Uid=1001,Gid=1001' \
  --root-directory 'Path=/ung-dung-a,
    CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=0755}'

Ba trường hợp KHÔNG nên dùng EFS: | Trường hợp | Dùng gì | |---|---| | CSDL quan hệ | RDS hoặc EBS io2 | | Nội dung tĩnh cho web toàn cầu | S3 + CloudFront | | Tệp rất nhiều và rất nhỏ, I/O cực nặng | FSx for Lustre |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | AWS Backup hỗ trợ EFS | | | Bật sao lưu tự động khi tạo | | | Khôi phục vào thư mục mới, không đè | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | BurstCreditBalance | cạn là chậm | | PercentIOLimit | chạm giới hạn General Purpose | | ClientConnections | số client đang mount |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Đắt hơn EBS mỗi GB | | | Nhưng chỉ trả cho phần dùng | | | Elastic throughput tính theo lượng đọc ghi | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi ở máy A, đọc ngay ở máy B | | | Kiểm tra mount target đủ mọi AZ | | | Theo dõi BurstCreditBalance | |

Và một lời khuyên: hãy dùng Elastic throughput thay vì chế độ bursting trừ khi bạn biết chắc mức dùng. Bursting credit cạn dần một cách âm thầm, và triệu chứng là ứng dụng chậm đi sau nhiều tuần chạy tốt — dạng sự cố khó lần ra nhất vì chẳng có gì thay đổi trong mã.

Đáp án

C — Dùng AWS Config để tìm và gắn tag cho tài nguyên chưa có tag, rồi dùng AWS Backup sao lưu theo tag.

Vì sao đúng

Đề nêu hai việc phải làm, và phương án này giải quyết đúng thứ tự: | Việc | Công cụ | |---|---| | Tìm tài nguyên CHƯA có tag | AWS Config rule required-tags | | Sao lưu tài nguyên theo tag | AWS Backup với tag-based resource selection |

⚠ Thứ tự này quan trọng:

AWS Backup chọn tài nguyên theo TAG
    → tài nguyên thiếu tag = KHÔNG được sao lưu
    → và không có cảnh báo nào
        ↓
    Phải bảo đảm tag đầy đủ TRƯỚC
    → Config làm việc đó

Config rule kiểm tra tag:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "bat-buoc-co-tag-sao-luu",
  "Source": {"Owner": "AWS",
             "SourceIdentifier": "REQUIRED_TAGS"},
  "InputParameters": "{\"tag1Key\":\"ChinhSachSaoLuu\"}",
  "Scope": {"ComplianceResourceTypes": [
    "AWS::EC2::Volume", "AWS::RDS::DBInstance",
    "AWS::DynamoDB::Table", "AWS::EFS::FileSystem"]}}'

Tự động gắn tag bằng remediation:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "bat-buoc-co-tag-sao-luu",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-SetRequiredTags",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3,
    "Parameters": {
      "Tags": {"StaticValue": {"Values":
        ["{\"ChinhSachSaoLuu\":\"hang-ngay\"}"]}}}}]'

Backup plan chọn theo tag:

aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "ke-hoach-hang-ngay",
  "Rules": [{
    "RuleName": "sao-luu-hang-ngay",
    "TargetBackupVaultName": "kho-chinh",
    "ScheduleExpression": "cron(0 17 * * ? *)",
    "StartWindowMinutes": 60,
    "CompletionWindowMinutes": 180,
    "Lifecycle": {"MoveToColdStorageAfterDays": 30,
                  "DeleteAfterDays": 365}}]}'

aws backup create-backup-selection --backup-plan-id <id> \
  --backup-selection '{
    "SelectionName": "theo-tag",
    "IamRoleArn": "<arn-role>",
    "ListOfTags": [{"ConditionType": "STRINGEQUALS",
                    "ConditionKey": "ChinhSachSaoLuu",
                    "ConditionValue": "hang-ngay"}]}'

⚠ Chọn theo tag khiến tài nguyên mới tự động được bảo vệ:

Nhóm nào đó tạo volume EBS mới
    → gắn tag ChinhSachSaoLuu=hang-ngay
        ↓
    AWS Backup tự đưa vào kế hoạch
    → không ai phải nhớ thêm bước nào

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nơi quản lý sao lưu mọi dịch vụ | | | Tài nguyên mới tự được bảo vệ | | | Báo cáo tuân thủ tập trung | |

AWS Backup hỗ trợ nhiều dịch vụ: | Dịch vụ | Hỗ trợ | |---|---| | EBS, EC2, RDS, Aurora | ✅ | | DynamoDB, EFS, FSx | ✅ | | S3, Storage Gateway, DocumentDB, Neptune | ✅ |

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

• **A. Dùng AWS Backup với danh sách ARN tài nguyên — đây là phương án gần nhất và cũng sao lưu đúng, nhưng phải cập nhật danh sách bằng tay mỗi khi có tài nguyên mới, và không giải quyết việc tìm tài nguyên chưa có tag.
• **B. Viết script Lambda quét và sao lưu — tự dựng lại thứ AWS Backup đã làm sẵn, thêm mã phải bảo trì, và thiếu các tính năng như vault lock, báo cáo tuân thủ, sao chép xuyên vùng.
• **D. Dùng Data Lifecycle Manager (DLM) — DLM chỉ quản lý snapshot EBS và AMI; không sao lưu được RDS, DynamoDB, EFS như đề yêu cầu.

Ghi nhớ

⚠ Ba công cụ sao lưu trên AWS — bảng phải thuộc: | Công cụ | Phạm vi | |---|---| | AWS Backup | nhiều dịch vụ, tập trung, theo tag | | Data Lifecycle Manager | chỉ EBS snapshot và AMI | | Snapshot thủ công / script | tự làm mọi thứ |

Từ khoá nhận diện:

"centralized backup across services", "by tag" → AWS Backup "EBS snapshots only, automated" → DLM "find non-compliant resources" → AWS Config "prevent backup deletion" → Vault Lock

⚠ AWS Backup Vault Lock là tính năng phải biết:

Chế độ Compliance:
    → KHÔNG AI xoá được bản sao lưu trước hạn
    → kể cả tài khoản gốc, kể cả AWS
        ↓
    Bảo vệ khỏi ransomware và người trong nội bộ

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name kho-chinh \
  --min-retention-days 30 --max-retention-days 365 \
  --changeable-for-days 3

⚠ Cực kỳ cẩn thận với Vault Lock:

Sau `changeable-for-days` (tối thiểu 3 ngày)
    → cấu hình KHÔNG THỂ thay đổi hay gỡ bỏ
        ↓
    Đặt sai retention = trả tiền lưu trữ tới hết hạn
    → thử ở tài khoản không quan trọng trước

Ba lưu ý về chiến lược tag: | Lưu ý | Chi tiết | |---|---| | Định nghĩa chuẩn tag từ đầu | | | Dùng Tag Policy trong Organizations | | | SCP bắt buộc tag khi tạo tài nguyên | |

⚠ SCP chặn tạo tài nguyên thiếu tag là biện pháp mạnh nhất:

{"Effect": "Deny",
 "Action": ["ec2:CreateVolume", "rds:CreateDBInstance"],
 "Resource": "*",
 "Condition": {"Null":
   {"aws:RequestTag/ChinhSachSaoLuu": "true"}}}

Chặn ngay từ đầu
    → không bao giờ có tài nguyên thiếu tag để đi tìm

Ba mức chính sách sao lưu theo tag: | Giá trị tag | Ý nghĩa | |---|---| | hang-ngay | sao lưu ngày, giữ 35 ngày | | hang-tuan | sao lưu tuần, giữ 90 ngày | | quan-trong | ngày + sao chép xuyên vùng, giữ 7 năm |

Ba lưu ý về sao chép xuyên vùng: | Lưu ý | Chi tiết | |---|---| | CopyActions trong backup rule | | | Bảo vệ khỏi sự cố cả một Region | | | Tính phí truyền dữ liệu | |

{"CopyActions": [{
  "DestinationBackupVaultArn":
    "arn:aws:backup:ap-northeast-1:123456789012:backup-vault:kho-dr",
  "Lifecycle": {"DeleteAfterDays": 365}}]}

Ba lưu ý về sao chép xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | Chép sang tài khoản riêng cho sao lưu | | | Tài khoản đó có quyền rất hạn chế | | | Chống được cả trường hợp tài khoản chính bị chiếm | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo GB lưu trữ warm | | | Cold storage rẻ hơn nhiều | | | Phí khôi phục cho một số loại | |

⚠ Lifecycle chuyển sang cold phải chú ý:

Chuyển sang cold storage
    → tối thiểu phải giữ 90 ngày
        ↓
    Xoá sớm vẫn tính đủ 90 ngày
    → không đặt cold cho thứ chỉ giữ 30 ngày

Ba lưu ý về báo cáo: | Lưu ý | Chi tiết | |---|---| | Backup Audit Manager kiểm tra tuân thủ | | | Báo cáo job thành công và thất bại | | | Khung kiểm soát dựng sẵn | |

Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | DIỄN TẬP khôi phục định kỳ | | | Đo thời gian khôi phục thật | | | Bản sao lưu chưa từng khôi phục = chưa chắc dùng được | |

⚠ Đây là điều quan trọng nhất trong toàn bộ chủ đề sao lưu:

Job sao lưu báo thành công mỗi ngày suốt hai năm
    → không ai từng thử khôi phục
        ↓
    Ngày cần đến mới phát hiện thiếu thứ gì đó
    → sao lưu chưa kiểm chứng không phải sao lưu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem danh sách tài nguyên được bảo vệ | | | Tạo tài nguyên mới có tag, xem có vào kế hoạch | | | Khôi phục thử một bản | |

aws backup list-protected-resources \
  --query "Results[].[ResourceArn,ResourceType]" --output table

Và một lời khuyên: hãy đặt lịch diễn tập khôi phục mỗi quý và ghi lại thời gian thực tế. Con số RTO trong tài liệu là ước lượng cho đến khi bạn đo nó — và khoảng cách giữa hai con số đó luôn được phát hiện vào đúng lúc không ai muốn phát hiện.

Đáp án

A — Dùng Amazon Macie. Tạo quy tắc EventBridge lọc loại sự kiện SensitiveData:S3Object/Health từ phát hiện của Macie và kích hoạt thông báo SES tới đội tuân thủ.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái một: | Yêu cầu | Cách đáp ứng | |---|---| | Tự động phát hiện PHI trong S3 | Macie quét và phân loại dữ liệu nhạy cảm | | Loại dữ liệu là thông tin sức khoẻ | SensitiveData:S3Object/Health | | Báo cho đội tuân thủ | EventBridge → SES |

⚠ Macie là dịch vụ DUY NHẤT của AWS quét NỘI DUNG bên trong object S3:

Config, Security Hub, GuardDuty:
    → nhìn cấu hình, nhìn hành vi, nhìn nhật ký
        ↓
Macie:
    → MỞ object ra và đọc bên trong
    → tìm số thẻ tín dụng, hộ chiếu, hồ sơ y tế...

Bật Macie và tạo công việc quét:

aws macie2 enable-macie

aws macie2 create-classification-job \
  --job-type SCHEDULED \
  --schedule-frequency '{"dailySchedule":{}}' \
  --name quet-phi-hang-ngay \
  --s3-job-definition '{"bucketDefinitions":[
    {"accountId":"123456789012","buckets":["ho-so-benh-nhan"]}]}'

⚠ Định danh loại phát hiện phải chọn ĐÚNG: | Loại | Nội dung | |---|---| | SensitiveData:S3Object/Health | hồ sơ y tế, mã bảo hiểm sức khoẻ | | SensitiveData:S3Object/Personal | tên, địa chỉ, số định danh cá nhân | | SensitiveData:S3Object/Financial | số thẻ, tài khoản ngân hàng | | SensitiveData:S3Object/Credentials | khoá API, mật khẩu |

Đề nói rõ PHI (protected health information)
    → Health, KHÔNG phải Personal

Quy tắc EventBridge:

{"source": ["aws.macie"],
 "detail-type": ["Macie Finding"],
 "detail": {"type": ["SensitiveData:S3Object/Health"]}}

aws events put-rule --name macie-phat-hien-phi \
  --event-pattern file://mau-su-kien.json

aws events put-targets --rule macie-phat-hien-phi \
  --targets 'Id=1,Arn=<arn-lambda-gui-ses>'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải viết bộ phân loại dữ liệu | Macie có sẵn hơn 100 mẫu | | Chạy theo lịch, tự động hoàn toàn | | | Phát hiện đi thẳng vào EventBridge | |

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

• **C. Dùng Macie nhưng lọc SensitiveData:S3Object/Personal bằng Lambda rồi gửi SNS — đây là phương án gần nhất và dùng đúng dịch vụ, nhưng lọc sai loại dữ liệu: PHI là thông tin sức khoẻ, thuộc nhóm Health. Dùng Personal sẽ bỏ sót đúng thứ cần tìm.
• **B và D. Dùng AWS Security Hub — Security Hub tổng hợp phát hiện bảo mật từ các dịch vụ khác; nó không tự quét nội dung object S3. Lọc theo "High severity" cũng không nói gì về việc có PHI hay không.

Ghi nhớ

⚠ Bốn dịch vụ hay bị lẫn — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Macie | quét NỘI DUNG S3 tìm dữ liệu nhạy cảm | | GuardDuty | phát hiện hành vi đe doạ từ log | | Inspector | quét lỗ hổng của EC2, ECR, Lambda | | Security Hub | tổng hợp phát hiện từ mọi nguồn |

Từ khoá nhận diện:

"detect PII/PHI inside S3 objects" → Macie "unusual API activity, crypto mining, compromised credentials" → GuardDuty "CVE, unpatched software" → Inspector "single pane of glass for findings" → Security Hub

Ba nhóm dữ liệu Macie nhận diện sẵn: | Nhóm | Ví dụ | |---|---| | Thông tin định danh cá nhân | tên, địa chỉ, ngày sinh | | Thông tin tài chính | số thẻ, tài khoản | | Thông tin y tế | mã HCPCS, số bảo hiểm y tế | | Thông tin xác thực | khoá riêng tư, token |

⚠ Định danh tuỳ chỉnh khi mẫu dựng sẵn không đủ:

aws macie2 create-custom-data-identifier \
  --name ma-benh-nhan \
  --regex "BN-[0-9]{8}" \
  --maximum-match-distance 50 \
  --keywords "benh nhan" "ho so"

Mỗi tổ chức có mã định danh riêng
    → mẫu dựng sẵn không biết
    → định danh tuỳ chỉnh lấp chỗ đó

Ba lưu ý về chi phí Macie: | Khoản | Chi tiết | |---|---| | Phí đánh giá bucket theo tháng | rẻ | | Phí quét theo GB | khoản chính | | Quét lại object không đổi tốn tiền vô ích | |

⚠ Giảm chi phí bằng phạm vi quét:

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

Chỉ quét tiền tố có khả năng chứa PHI
    → giảm chi phí nhiều lần

Ba lưu ý về phản ứng tự động: | Bước | Chi tiết | |---|---| | Thông báo (đề này yêu cầu) | SNS hoặc SES | | Cách ly object | Lambda chuyển sang bucket hạn chế | | Gắn tag để theo dõi | |

⚠ Cẩn thận với hành động tự động xoá:

Tự động xoá object bị đánh dấu
    → Macie có dương tính giả
        ↓
    Xoá dữ liệu hợp lệ là thiệt hại không đảo ngược
    → cách ly và báo, đừng xoá

Ba lưu ý về HIPAA: | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc | | Chỉ dùng dịch vụ đủ điều kiện HIPAA | | | Mã hoá at rest và in transit | |

Ba lưu ý về SES: | Lưu ý | Chi tiết | |---|---| | Phải xác minh địa chỉ hoặc tên miền gửi | | | Sandbox chỉ gửi được tới địa chỉ đã xác minh | | | Cần yêu cầu thoát sandbox cho sản xuất | |

⚠ Đây là bẫy triển khai hay gặp:

Dựng xong đường ống, thử thấy chạy
    → nhưng SES còn ở sandbox
        ↓
    Thư chỉ tới được địa chỉ đã xác minh
    → đội tuân thủ thật không nhận được gì

Ba lưu ý về EventBridge: | Lưu ý | Chi tiết | |---|---| | Macie gửi phát hiện tự động, không cần cấu hình | | | Lọc bằng mẫu sự kiện, không cần Lambda | | | Có thể gửi thẳng tới SNS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đặt tệp thử có mẫu PHI giả | | | Xem phát hiện xuất hiện trong Macie | | | Xác nhận đội tuân thủ nhận được thư | |

Và một lời khuyên: hãy giới hạn phạm vi quét bằng tiền tố ngay từ công việc đầu tiên. Macie tính phí theo GB đã quét, và một công việc quét toàn bộ bucket hàng chục terabyte mỗi ngày sẽ tạo ra hoá đơn lớn hơn nhiều so với giá trị của việc quét lại những object chưa hề thay đổi.