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

Đáp án

D — Thiết lập một Virtual Private Gateway (VGW).

Vì sao đúng

Đề mô tả một môi trường đã bảo mật và hỏi thêm gì để có mã hoá: | Hiện trạng | Vấn đề | |---|---| | Đã gỡ Internet Gateway | không có đường ra Internet | | Đã dựng Direct Connect | có kết nối riêng | | Cần thêm MÃ HOÁ | DX KHÔNG mã hoá mặc định |

⚠ Đây là điều phải nhớ về Direct Connect:

DX là đường VẬT LÝ RIÊNG, không đi qua Internet
    → nhưng dữ liệu KHÔNG được mã hoá
        ↓
    "Riêng tư" không đồng nghĩa với "được mã hoá"

Vì sao VGW là câu trả lời:

Muốn mã hoá trên DX → chạy một VPN IPsec BÊN TRÊN nó
    → VPN cần một điểm cuối phía AWS
        ↓
    Điểm cuối đó chính là Virtual Private Gateway
    → (hoặc Transit Gateway cho kiến trúc lớn hơn)

Kiến trúc kết quả:

Trung tâm dữ liệu
    │
    │ Direct Connect (public VIF)
    ▼
Đường hầm IPsec VPN  ◀── mã hoá ở đây
    │
    ▼
Virtual Private Gateway ── VPC

Dựng VGW và VPN trên DX:

aws ec2 create-vpn-gateway --type ipsec.1
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-abc --vpc-id vpc-abc

aws ec2 create-customer-gateway --type ipsec.1   --public-ip 203.0.113.10 --bgp-asn 65000

aws ec2 create-vpn-connection --type ipsec.1   --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc

⚠ Và một chi tiết kỹ thuật quan trọng:

VPN over Direct Connect cần một PUBLIC VIF
    → vì điểm cuối VPN của AWS có địa chỉ công khai
        ↓
    Lưu lượng vẫn đi trên đường DX riêng
    → không ra Internet
    → nhưng dùng địa chỉ công khai để thiết lập tunnel

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mã hoá IPsec cho dữ liệu trên DX | | | Vẫn giữ băng thông và độ trễ của DX | | | Không cần Internet Gateway | |

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

• **A. Bật mã hoá IPsec trên chính kết nối Direct Connect — đây là phương án gần nhất và nghe hợp lý nhất, nhưng DX không có công tắc mã hoá nào. Mã hoá phải được thêm bằng một lớp bên trên: VPN IPsec, hoặc MACsec (chỉ với cổng chuyên dụng và ở một số DX location).
• **B. Thiết lập BGP với mã hoá — BGP là giao thức định tuyến, nó trao đổi thông tin về đường đi. Nó không mã hoá dữ liệu người dùng. (BGP có xác thực MD5/TCP-AO nhưng đó là bảo vệ chính phiên BGP, không phải dữ liệu.)
• **C. Cấu hình Direct Connect Gateway — DX Gateway dùng để nối một DX tới VPC ở nhiều vùng. Nó là công cụ định tuyến, hoàn toàn không liên quan tới mã hoá.

Ghi nhớ

⚠ Bảng mã hoá của các kết nối lai — phải thuộc: | Kết nối | Mã hoá mặc định | |---|---| | Site-to-Site VPN | ✅ IPsec | | Direct Connect | ❌ KHÔNG | | DX + VPN | ✅ | | DX với MACsec | ✅ (tầng 2, cổng chuyên dụng) |

Từ khoá nhận diện:

"Direct Connect" + "add encryption" → VPN qua DX (cần VGW hoặc TGW) "encrypt at layer 2 on DX" → MACsec "connect DX to VPCs in multiple Regions" → Direct Connect Gateway

Ba thành phần của Site-to-Site VPN: | Thành phần | Ở đâu | |---|---| | Customer Gateway (CGW) | đại diện thiết bị phía bạn | | Virtual Private Gateway (VGW) | điểm cuối phía AWS ← câu này | | VPN Connection | hai tunnel IPsec |

⚠ VGW và Transit Gateway — khi nào dùng cái nào: | | Virtual Private Gateway | Transit Gateway | |---|---|---| | Gắn với | MỘT VPC | nhiều VPC | | ECMP (gộp băng thông tunnel) | ❌ | ✅ | | Bắc cầu | ❌ | ✅ | | Chi phí | thấp hơn | phí attachment |

Ba loại VIF của Direct Connect: | Loại | Nối tới | |---|---| | Private VIF | VPC qua VGW | | Public VIF | dịch vụ AWS công khai — VÀ endpoint VPN | | Transit VIF | Transit Gateway (cần DX ≥ 1 Gbps) |

⚠ VPN over DX dùng PUBLIC VIF — đây là chi tiết hay bị nhầm.

Ba đặc điểm của MACsec: | Đặc điểm | Chi tiết | |---|---| | Mã hoá ở tầng 2 | | | Chỉ với cổng chuyên dụng (10/100 Gbps) | | | Chỉ ở một số DX location | |

MACsec và VPN over DX — so sánh: | | MACsec | VPN over DX | |---|---|---| | Tầng | 2 | 3 | | Ảnh hưởng thông lượng | gần như không | có (xử lý IPsec) | | Điều kiện | cổng chuyên dụng, location hỗ trợ | mọi DX | | Băng thông | đầy đủ | giới hạn ~1,25 Gbps mỗi tunnel |

⚠ Giới hạn băng thông của VPN là đánh đổi thật:

DX 10 Gbps nhưng chạy VPN bên trên
    → mỗi tunnel tối đa ~1,25 Gbps
        ↓
    Muốn nhiều hơn: dùng Transit Gateway với ECMP
    → gộp nhiều tunnel song song

Ba mức phục hồi của DX: | Mức | Cấu hình | |---|---| | Development/Test | 1 kết nối, 1 location | | High Resiliency | 2 kết nối, 2 location | | Maximum Resiliency | 2 kết nối ở mỗi trong 2 location |

Ba lưu ý về bảo mật cho VPC không có IGW: | Lưu ý | Chi tiết | |---|---| | Dùng VPC endpoint để gọi dịch vụ AWS | | | Gateway endpoint cho S3 và DynamoDB (miễn phí) | | | Interface endpoint cho dịch vụ khác | |

Ba lớp mã hoá nên có: | Lớp | Công cụ | |---|---| | Đường mạng | VPN IPsec hoặc MACsec | | In transit tới dịch vụ | TLS | | At rest | KMS |

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | Dùng BGP thay static route | tự chuyển khi đường chết | | AS path prepending để ưu tiên đường | | | BFD để phát hiện nhanh | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra tunnel UP | describe-vpn-connections | | Bắt gói xem có được mã hoá không | | | Đo thông lượng thực tế | so với trước khi bật VPN |

Và một lời khuyên: hãy đo lại thông lượng sau khi bật VPN trên Direct Connect. Mã hoá IPsec có chi phí xử lý và mỗi tunnel bị giới hạn khoảng 1,25 Gbps — nếu bạn vừa trả tiền cho một đường 10 Gbps, đó là con số nên biết trước khi kiến trúc phụ thuộc vào nó.

Đáp án

C — Dùng Route 53 latency routing policy đưa học viên tới vùng có độ trễ mạng thấp nhất, và dùng internet-facing Application Load Balancer phân phối lưu lượng tới EC2 trong mỗi vùng.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | EC2 ở nhiều AZ trong NHIỀU VÙNG | ALB mỗi vùng + Route 53 giữa các vùng | | Học viên tới vùng GẦN NHẤT | latency routing | | Tính sẵn sàng cao | ALB đa AZ + health check của Route 53 | | Định tuyến hiệu quả | hai tầng: giữa vùng và trong vùng |

Hai tầng định tuyến:

Tầng 1 — giữa các vùng:  Route 53 latency-based
    → học viên ở Việt Nam → vùng Singapore
    → học viên ở Đức     → vùng Ireland

Tầng 2 — trong một vùng: Application Load Balancer
    → phân phối tới EC2 ở các AZ
        ↓
    Mỗi tầng giải quyết một mức

⚠ Vì sao latency chứ không phải geolocation hay geoproximity:

Đề nói "geographically closest" nhưng thực chất muốn HIỆU NĂNG
    → latency routing đo ĐỘ TRỄ MẠNG THẬT
        ↓
    Gần về địa lý ≠ nhanh về mạng
    → đường cáp và peering quyết định, không phải khoảng cách

Ba chính sách dễ lẫn — bảng phân biệt: | Chính sách | Chọn theo | |---|---| | Latency-based | độ trễ MẠNG đo được ← câu này | | Geolocation | quốc gia/châu lục của người dùng | | Geoproximity | khoảng cách địa lý, có bias điều chỉnh |

Cấu hình latency record:

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"hoc.vidu.com","Type":"A",
      "SetIdentifier":"singapore","Region":"ap-southeast-1",
      "HealthCheckId":"hc-sg",
      "AliasTarget":{"HostedZoneId":"Z1","DNSName":"alb-sg...",
                     "EvaluateTargetHealth":true}}},
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"hoc.vidu.com","Type":"A",
      "SetIdentifier":"ireland","Region":"eu-west-1",
      "HealthCheckId":"hc-ie",
      "AliasTarget":{"HostedZoneId":"Z2","DNSName":"alb-ie...",
                     "EvaluateTargetHealth":true}}}]}'

⚠ EvaluateTargetHealth và health check cho tính sẵn sàng cao:

Vùng Singapore hỏng
    → health check thất bại
    → Route 53 ngừng trả bản ghi đó
    → học viên châu Á được đưa sang Ireland
        ↓
    Không có health check thì vẫn gửi người dùng vào vùng chết

Vì sao ALB chứ không phải NLB:

Nền tảng học trực tuyến phục vụ nội dung qua HTTP/HTTPS
    → ALB hiểu HTTP: định tuyến theo path, sticky session,
      health check theo đường dẫn ứng dụng
        ↓
    NLB ở tầng 4, không có những khả năng đó

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

• **D. Dùng geolocation routing với ALB — đây là phương án gần nhất và cũng đưa người dùng tới vùng "gần", nhưng geolocation định tuyến theo quốc gia, không theo hiệu năng. Nó dùng cho tuân thủ và bản quyền nội dung; và người dùng ở quốc gia không được khai sẽ không khớp bản ghi nào nếu thiếu bản ghi mặc định.
• **A. Dùng geoproximity routing với Network Load Balancer — geoproximity dựa trên khoảng cách địa lý chứ không phải độ trễ, và NLB ở tầng 4 không phù hợp cho nền tảng web. Ngoài ra mô tả "phân phối trong mỗi Availability Zone" là cách nói không chính xác — load balancer phân phối giữa các AZ.
• **B. Dùng weighted routing — chia lưu lượng theo tỷ lệ cố định, hoàn toàn không quan tâm vị trí người dùng. Nó dùng cho triển khai từng phần (canary), không phải tối ưu độ trễ.

Ghi nhớ

⚠ Bảy chính sách định tuyến Route 53 — phải thuộc: | Chính sách | Chọn theo | Dùng cho | |---|---|---| | Simple | một đích | cơ bản | | Weighted | tỷ lệ % | triển khai canary, A/B test | | Latency-based | độ trễ mạng | hiệu năng đa vùng ← câu này | | Failover | health check | DR chính/phụ | | Geolocation | quốc gia | bản quyền, tuân thủ | | Geoproximity | khoảng cách + bias | điều chỉnh tỷ lệ theo vùng | | Multivalue answer | tới 8 bản ghi khoẻ | thay thế cân bằng tải đơn giản |

Từ khoá nhận diện:

"lowest latency", "best performance" → latency-based "users in a specific country must see specific content" → geolocation "shift 10% of traffic" → weighted "primary and standby Region" → failover "static IP + fast failover + UDP" → Global Accelerator (không phải Route 53)

⚠ Route 53 latency và Global Accelerator — khi nào dùng cái nào: | | Route 53 latency | Global Accelerator | |---|---|---| | Cơ chế | DNS | anycast IP | | Bị ảnh hưởng bởi DNS cache | ✅ có | ❌ không | | Tốc độ chuyển vùng | phụ thuộc TTL | vài chục giây | | Chi phí | gần như miễn phí | phí cố định + GB | | Giao thức | mọi | TCP, UDP |

Route 53 latency đủ tốt cho hầu hết ứng dụng web
    → Global Accelerator khi cần chuyển vùng nhanh
      hoặc cần IP tĩnh

Ba lưu ý về latency routing: | Lưu ý | Chi tiết | |---|---| | AWS đo độ trễ từ dữ liệu thật, cập nhật liên tục | | | Mỗi bản ghi gắn với một VÙNG AWS | | | Kết hợp health check để có failover | |

⚠ TTL ảnh hưởng trực tiếp tới thời gian chuyển:

Health check phát hiện trong 90 giây
    → TTL 300 giây → client vẫn dùng kết quả cũ thêm 5 phút
        ↓
    Đặt TTL 60 giây cho bản ghi có health check

Ba lưu ý về geolocation: | Lưu ý | Chi tiết | |---|---| | Luôn tạo bản ghi mặc định (*) | cho vị trí không khớp | | Độ chính xác phụ thuộc cơ sở dữ liệu IP | | | VPN làm sai lệch kết quả | |

Vế đầu là lỗi hay gặp:

Chỉ khai bản ghi cho Việt Nam và Đức
    → người dùng ở Nhật không khớp bản ghi nào
    → nhận lỗi NXDOMAIN
        ↓
    Luôn có một bản ghi Default

Ba đặc điểm của ALB: | Đặc điểm | Chi tiết | |---|---| | Tầng 7 — hiểu HTTP | | | Trải nhiều AZ, cross-zone MẶC ĐỊNH BẬT và miễn phí | | | Định tuyến theo path, host, header, query | |

Ba lưu ý về tính sẵn sàng trong mỗi vùng: | Lưu ý | Chi tiết | |---|---| | ASG trải qua ít nhất 2-3 AZ | | | health-check-type ELB cho ASG | | | CSDL cũng phải đa AZ | |

Ba lưu ý về nội dung tĩnh: | Lưu ý | Chi tiết | |---|---| | Video và tài liệu nên qua CloudFront | | | Giảm tải cho ALB và EC2 | | | Rẻ hơn phục vụ trực tiếp | |

Với nền tảng học trực tuyến, đây là cải thiện lớn:

Video bài giảng chiếm phần lớn băng thông
    → phục vụ qua CloudFront từ S3
    → chỉ phần động đi qua ALB
        ↓
    Giảm cả chi phí lẫn độ trễ

Ba lưu ý về dữ liệu đa vùng: | Lưu ý | Chi tiết | |---|---| | CSDL phải sao chép giữa vùng | Aurora global database | | Hoặc tách dữ liệu theo vùng | | | S3 Cross-Region Replication cho nội dung | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phân giải DNS từ nhiều khu vực | | | Tắt một vùng, xem có chuyển không | | | Đo độ trễ thực tế phía người dùng | |

# Kiểm tra Route 53 trả gì cho một vị trí
aws route53 test-dns-answer --hosted-zone-id Z123   --record-name hoc.vidu.com --record-type A   --resolver-ip 8.8.8.8

Và một lời khuyên: hãy luôn gắn health check vào bản ghi latency-based. Không có nó, Route 53 vẫn vui vẻ gửi học viên tới vùng có độ trễ thấp nhất — kể cả khi vùng đó đã ngừng phục vụ, vì độ trễ của một máy chủ chết luôn rất thấp.

Đáp án

D — Dùng AWS Snowball.

Vì sao đúng

Đề cho đủ số liệu để tính, và phép tính cho ra câu trả lời: | Dữ kiện | Con số | |---|---| | Dữ liệu | 30 TB | | Thời hạn | 20 ngày | | Đường truyền | 25 Mbps | | Chỉ được dùng | 50% băng thông = 12,5 Mbps |

Tính thử:

30 TB = 30.000 GB = 240.000 Gb = 240.000.000 Mb

240.000.000 Mb ÷ 12,5 Mbps = 19.200.000 giây
19.200.000 ÷ 86.400 = 222 NGÀY
        ↓
    Cần 222 ngày, chỉ có 20 ngày
    → chậm hơn 11 lần so với yêu cầu

Đây là con số quyết định — mọi phương án truyền qua mạng đều thất bại.

Snowball giải quyết thế nào:

1. Đặt thiết bị (1 cái đủ cho 30 TB)
2. AWS gửi tới trung tâm dữ liệu (~2-5 ngày)
3. Chép dữ liệu qua mạng NỘI BỘ (không đụng Internet)
4. Gửi trả AWS (~2-5 ngày)
5. AWS nạp vào S3 (~1-2 ngày)
        ↓
    Tổng khoảng 10-14 ngày — nằm trong hạn 20 ngày

Đặt hàng:

aws snowball create-job --job-type IMPORT   --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::kho-du-lieu"}]}'   --address-id ADID123 --snowball-type EDGE_S   --shipping-option EXPRESS   --role-arn <arn-role> --kms-key-arn <arn-khoa>

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | KHÔNG dùng băng thông Internet nào | thoả ràng buộc 50% | | Mã hoá AES-256, khoá trong KMS | | | Rẻ hơn nâng cấp đường truyền | |

⚠ Quy tắc ước lượng nhanh cho kỳ thi:

Thời gian (ngày) ≈ Dung lượng (TB) × 8.000.000
                   ÷ (Băng thông Mbps × 86.400)

Đơn giản hơn:
    → mất hơn MỘT TUẦN  → cân nhắc Snowball
    → mất hơn MỘT THÁNG → chắc chắn Snowball

Và tính thời gian vận chuyển vào kế hoạch:

Snowball không tức thì
    → 10-14 ngày trọn chu trình là bình thường
        ↓
    Với hạn 20 ngày thì vừa đủ — nhưng phải đặt hàng NGAY

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

• **B. Dùng AWS DataSync — đây là phương án gần nhất vì DataSync đúng là công cụ di chuyển dữ liệu chuyên dụng và nhanh hơn rsync nhiều, nhưng nó vẫn truyền qua đường mạng. Với 12,5 Mbps thì dù giao thức tối ưu đến đâu cũng không rút được 222 ngày xuống 20.
• **C. Dùng AWS Storage Gateway — cũng truyền qua mạng, cùng vấn đề băng thông. Và Storage Gateway là công cụ cho truy cập liên tục có cache, không phải để di chuyển một lần.
• **A. Dùng Site-to-Site VPN — VPN chỉ tạo đường hầm mã hoá trên chính đường Internet 25 Mbps đó. Không thêm băng thông nào, và IPsec còn tốn thêm chi phí xử lý.

Ghi nhớ

⚠ Ba thiết bị họ Snow — bảng phải thuộc: | Thiết bị | Dung lượng dùng được | |---|---| | Snowcone | 8-14 TB — nhỏ nhất, xách tay | | Snowball Edge Storage Optimized | ~80 TB ← phổ biến nhất | | Snowball Edge Compute Optimized | ~28 TB + GPU | | Snowmobile | tới 100 PB — xe container |

Từ khoá nhận diện:

"limited bandwidth" + "deadline" + hàng chục TB → Snowball "exabyte scale" → Snowmobile "ongoing sync over network" → DataSync "continuous access with cache" → Storage Gateway

Ba công cụ di chuyển dữ liệu — bảng chọn nhanh: | Công cụ | Khi nào | |---|---| | Snow family | lượng lớn, mạng kém, một lần | | DataSync | định kỳ, mạng đủ tốt | | Storage Gateway | truy cập liên tục |

Ba đặc điểm bảo mật của Snowball: | Đặc điểm | Chi tiết | |---|---| | Mã hoá AES-256, khoá trong KMS | | | Khoá KHÔNG lưu trên thiết bị | | | Vỏ chống phá, có TPM | |

Vế thứ hai đáng nhớ:

Thiết bị bị mất trên đường vận chuyển
    → không ai đọc được dữ liệu
    → khoá giải mã nằm trong KMS của bạn

Ba cách chép dữ liệu lên thiết bị: | Cách | Đặc điểm | |---|---| | AWS OpsHub | giao diện đồ hoạ, dễ nhất | | Snowball Client (CLI) | | | S3 Adapter | dùng lệnh aws s3 cp quen thuộc |

Ba lưu ý để chép nhanh: | Lưu ý | Chi tiết | |---|---| | Chép song song nhiều luồng | | | Nối cổng 10 GbE hoặc nhanh hơn | | | Tệp nhỏ chậm hơn nhiều — gom lại nếu được | |

⚠ Ba mốc thời gian phải tính vào kế hoạch: | Mốc | Thời gian điển hình | |---|---| | Vận chuyển tới nơi | 2-5 ngày | | Chép dữ liệu | tuỳ dung lượng và mạng nội bộ | | Vận chuyển về + nạp vào S3 | 3-7 ngày |

Ba lưu ý về dữ liệu thay đổi trong lúc chờ: | Lưu ý | Chi tiết | |---|---| | Dữ liệu mới sinh ra chưa nằm trên thiết bị | | | Dùng DataSync đồng bộ phần chênh lệch sau | | | Phần chênh lệch nhỏ nên mạng kém vẫn kham được | |

Đây là mô hình kết hợp chuẩn:

Snowball chở khối lượng lớn ban đầu
    → DataSync đồng bộ phần thay đổi qua mạng
        ↓
    Vừa nhanh vừa không bỏ sót dữ liệu mới

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí thuê thiết bị theo ngày | có số ngày miễn phí | | Phí vận chuyển | | | KHÔNG tính phí data transfer IN vào AWS | |

Ba lưu ý về Snowball Edge Compute: | Lưu ý | Chi tiết | |---|---| | Chạy được EC2 và Lambda tại chỗ | | | Hữu ích cho môi trường ngắt kết nối | | | Có tuỳ chọn GPU | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Theo dõi trạng thái job trong console | | | Kiểm tra số object trong S3 sau khi nạp | | | So với báo cáo của job | |

aws snowball describe-job --job-id JID123   --query "JobMetadata.[JobState,SnowballCapacityPreference]"

Và một lời khuyên: hãy luôn làm phép tính băng thông trước khi chọn công cụ. Câu hỏi kiểu này luôn cho đủ con số, và phép chia đơn giản sẽ cho biết ngay lời giải là truyền qua mạng hay chuyển bằng thiết bị vật lý — không cần cân nhắc thêm gì về tính năng của từng dịch vụ.

Đáp án

C — Chuyển cụm Aurora thành Aurora global database, cấu hình sao chép xuyên vùng và managed failover.

Vì sao đúng

Đề nêu bốn yêu cầu, và Aurora global database thoả hết với công ít nhất: | Yêu cầu | Cách đáp ứng | |---|---| | RPO dưới 5 phút | độ trễ sao chép thường DƯỚI 1 GIÂY | | RTO không quá 15 phút | managed failover thường dưới 1 phút | | ÍT công vận hành nhất | AWS lo toàn bộ việc sao chép và chuyển đổi | | Chuyển đổi với cấu hình tối thiểu | một lệnh API |

Vì sao "managed failover" là cụm từ quan trọng:

Aurora global database có hai kiểu chuyển đổi:
    → Managed planned failover: AWS điều phối toàn bộ
      (đồng bộ nốt dữ liệu, đổi vai trò, cấu hình lại sao chép)
    → Detach and promote: thủ công hơn, dùng khi vùng chính đã chết
        ↓
    "Managed" nghĩa là không phải viết script điều phối

Chuyển đổi:

aws rds create-global-cluster   --global-cluster-identifier cum-thanh-toan-toan-cau   --source-db-cluster-identifier arn:aws:rds:ap-southeast-1:...:cluster:cum-chinh

aws rds create-db-cluster --db-cluster-identifier cum-dr   --global-cluster-identifier cum-thanh-toan-toan-cau   --engine aurora-mysql --region ap-northeast-1

aws rds create-db-instance --db-instance-identifier dr-1   --db-cluster-identifier cum-dr --db-instance-class db.r6g.2xlarge   --engine aurora-mysql --region ap-northeast-1

Thực hiện chuyển đổi có kế hoạch:

aws rds failover-global-cluster   --global-cluster-identifier cum-thanh-toan-toan-cau   --target-db-cluster-identifier arn:aws:rds:ap-northeast-1:...:cluster:cum-dr

Vì sao RPO đạt được dễ dàng:

Aurora global database sao chép ở TẦNG LƯU TRỮ
    → không qua binlog, không qua ứng dụng
    → độ trễ điển hình dưới 1 giây
        ↓
    Yêu cầu RPO 5 phút là rất rộng rãi

Ba lợi ích khác: | Lợi ích | Chi tiết | |---|---| | Cụm phụ phục vụ ĐỌC ngay khi bình thường | không nằm không | | Tới 5 vùng phụ | | | Diễn tập được mà không mất dữ liệu | |

Vế cuối là giá trị vận hành lớn:

Managed planned failover không mất dữ liệu
    → chuyển sang vùng DR, chạy một thời gian, rồi chuyển về
        ↓
    Đây là cách diễn tập DR an toàn nhất
    → và là cách duy nhất biết RTO thật của bạn

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

• **D. Tạo Aurora read replica ở ap-northeast-1 và promote thủ công khi có sự cố — đây là phương án gần nhất và cũng có sao chép xuyên vùng, nhưng nó kém ở hai điểm: read replica xuyên vùng của Aurora MySQL dùng binlog (độ trễ cao hơn nhiều, RPO kém hơn), và promote thủ công nghĩa là phải có người trực — vi phạm "MOST operational efficiency".
• **B. Tạo cụm mới ở ap-northeast-1 và dùng AWS DMS sao chép — DMS là công cụ di chuyển và chuyển đổi CSDL, không phải cơ chế DR. Phải quản lý replication instance, theo dõi task, và độ trễ cao hơn nhiều.
• **A. Dùng S3 Cross-Region Replication sao chép bản sao lưu rồi khôi phục khi cần — đây là mẫu Backup & Restore: RTO tính bằng giờ (phải restore cả cụm từ snapshot), RPO bằng khoảng cách giữa hai lần sao lưu. Không đạt cả hai chỉ tiêu.

Ghi nhớ

⚠ Aurora Global Database và Cross-Region Read Replica — bảng phải thuộc: | | Global Database | Cross-Region Read Replica | |---|---|---| | Cơ chế | tầng lưu trữ chuyên dụng | binlog | | RPO | thường < 1 giây | chục giây - phút | | RTO khi promote | < 1 phút | nhiều phút | | Managed failover | ✅ | ❌ thủ công | | Ảnh hưởng cụm chính | gần như không | có tải binlog |

Từ khoá nhận diện:

"RPO seconds, RTO minutes" + Aurora → Aurora Global Database "managed failover" → global database (đây là tên tính năng) "RTO hours, lowest cost" → Backup & Restore "migrate between database engines" → DMS

Bốn chiến lược DR — bảng phải thuộc: | Chiến lược | RTO | RPO | |---|---|---| | Backup & Restore | giờ - ngày | giờ | | Pilot Light | chục phút | phút - giây | | Warm Standby | phút | giây | | Multi-Site Active-Active | gần 0 | gần 0 |

RTO 15 phút + RPO 5 phút
    → nằm ở mức Warm Standby cho tầng dữ liệu
    → Aurora Global Database đáp ứng thoải mái

Hai kiểu chuyển đổi của global database: | Kiểu | Khi nào | Mất dữ liệu | |---|---|---| | Managed planned failover | vùng chính CÒN SỐNG | không | | Detach and promote | vùng chính đã chết | có thể mất vài giây |

Ba đặc điểm của Aurora Global Database: | Đặc điểm | Chi tiết | |---|---| | Tới 5 vùng phụ | | | Cụm phụ chỉ đọc cho tới khi được đôn lên | | | Write forwarding (Aurora MySQL) | ghi ở vùng phụ chuyển tiếp về chính |

Write forwarding đáng biết:

aws rds modify-db-cluster --db-cluster-identifier cum-dr   --enable-global-write-forwarding

Ứng dụng ở vùng phụ ghi được
    → Aurora chuyển lệnh ghi về cụm chính
        ↓
    Đơn giản hoá ứng dụng đa vùng
    → nhưng độ trễ ghi cao hơn

⚠ Ba thứ khác cũng phải chuẩn bị ở vùng DR: | Thứ | Vì sao | |---|---| | AMI, ảnh container | tầng ứng dụng phải khởi động được | | Chứng chỉ ACM | ACM theo vùng | | Hạn ngạch tài khoản | vùng chưa dùng thường quota thấp |

Vế cuối là chỗ hay vấp:

CSDL chuyển đổi thành công trong 1 phút
    → nhưng ASG không khởi động nổi máy vì chạm quota
        ↓
    RTO thực tế bị quyết định bởi tầng chậm nhất

Ba cách phát hiện sự cố: | Cách | Chi tiết | |---|---| | EventBridge bắt sự kiện RDS | | | CloudWatch alarm | | | Route 53 health check | |

Ba lưu ý về ứng dụng khi failover: | Lưu ý | Chi tiết | |---|---| | Endpoint CSDL thay đổi | dùng Route 53 CNAME hoặc Secrets Manager | | Kết nối đang mở bị ngắt | ứng dụng phải thử lại | | Connection pool phải xử lý được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Cụm phụ tính phí instance đầy đủ | | | Phí sao chép theo lượng thay đổi | | | Cụm phụ có thể chạy 1 instance nhỏ | tăng khi cần |

Ba việc phải làm định kỳ: | Việc | Tần suất | |---|---| | Diễn tập managed planned failover | 2 lần/năm | | Đo RTO và RPO thực tế | mỗi lần diễn tập | | Kiểm tra hạn ngạch vùng DR | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | AuroraGlobalDBReplicationLag | RPO thực tế | | AuroraGlobalDBRPOLag | | | AuroraGlobalDBDataTransferBytes | |

Và một lời khuyên: hãy đo RPO thực tế bằng metric AuroraGlobalDBReplicationLag, đừng dựa vào con số "dưới một giây" trong tài liệu. Với tải ghi nặng của hệ thống thanh toán, độ trễ sao chép có thể tăng vào giờ cao điểm — và đó chính là lúc bạn có nhiều khả năng cần tới nó nhất.

Đáp án

A —

"Sid": "PutUpdateDeleteOnOrders",
"Effect": "Allow",
"Action": ["dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem"],
"Resource": "arn:aws:dynamodb:us-east-1:227392126428:table/Orders"

Vì sao đúng

Đề yêu cầu đặc quyền tối thiểu, và phương án này siết cả hai chiều: | Chiều | Cách siết | |---|---| | Hành động | chỉ 3 hành động được liệt kê rõ | | Tài nguyên | chỉ bảng Orders, không phải mọi bảng |

Bốn phương án khác nhau đúng ở hai trục này: | Phương án | Action | Resource | Đánh giá | |---|---|---|---| | A | 3 hành động cụ thể | table/Orders | ✅ chặt nhất | | B | 3 hành động cụ thể | table/* — MỌI bảng | quá rộng về tài nguyên | | C | Deny dynamodb:* | table/Orders | không cấp quyền gì | | D | Allow dynamodb:* | table/Orders | quá rộng về hành động |

Vì sao C sai về bản chất:

IAM policy MẶC ĐỊNH là từ chối mọi thứ
    → thêm một câu Deny không cấp thêm quyền nào
        ↓
    Lambda vẫn không ghi được vào bảng
    → hàm không chạy được

Vì sao D quá rộng:

dynamodb:* bao gồm:
    → DeleteTable  (xoá cả bảng!)
    → UpdateTable  (đổi cấu hình)
    → Scan, Query  (đọc toàn bộ dữ liệu)
        ↓
    Đề nói rõ "No other actions should be allowed"

Vì sao B quá rộng:

table/* nghĩa là MỌI bảng trong tài khoản và vùng đó
    → Lambda ghi được vào bảng của hệ thống khác
        ↓
    Một lỗi lập trình hoặc một cuộc tấn công
    có thể ảnh hưởng dữ liệu không liên quan

Policy hoàn chỉnh:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "PutUpdateDeleteOnOrders",
   "Effect": "Allow",
   "Action": ["dynamodb:PutItem","dynamodb:UpdateItem","dynamodb:DeleteItem"],
   "Resource": "arn:aws:dynamodb:us-east-1:227392126428:table/Orders"}]}

Gắn vào execution role:

aws iam put-role-policy --role-name VaiTroLambdaDonHang   --policy-name GhiBangOrders --policy-document file://policy.json

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

• **B. Cùng ba hành động nhưng Resource là table/* — đây là phương án gần nhất và đúng hoàn toàn về hành động, nhưng nó cấp quyền trên mọi bảng DynamoDB trong tài khoản và vùng đó. Với đặc quyền tối thiểu, phải giới hạn tới đúng tài nguyên cần.
• **D. Allow dynamodb:* trên bảng Orders — cho phép cả DeleteTable, Scan, UpdateTable và mọi hành động khác. Đề nói rõ chỉ được put, update, delete item.
• **C. Deny dynamodb:* trên bảng Orders — không cấp quyền nào cả. IAM mặc định từ chối, nên một câu Deny chỉ làm chắc chắn hơn việc từ chối; hàm Lambda sẽ hoàn toàn không ghi được.

Ghi nhớ

⚠ Nguyên tắc gốc của IAM:

Mặc định là TỪ CHỐI. Phải Allow tường minh mới có quyền. Deny tường minh THẮNG mọi Allow.

Ba trục của đặc quyền tối thiểu: | Trục | Siết bằng | |---|---| | Hành động (Action) | liệt kê cụ thể, không dùng * | | Tài nguyên (Resource) | ARN cụ thể, không dùng * | | Điều kiện (Condition) | thêm ràng buộc |

Từ khoá nhận diện:

"LEAST privileged access" → Action cụ thể + Resource cụ thể "no other actions" → không dùng service:* "only this table" → ARN đầy đủ

⚠ Cấu trúc ARN của DynamoDB:

arn:aws:dynamodb:<vùng>:<tài-khoản>:table/<tên-bảng>
                                    ↓
    Thêm /index/<tên-index> cho GSI
    Thêm /stream/<timestamp> cho stream

Ba trường hợp cần thêm quyền trên index:

{"Effect":"Allow","Action":"dynamodb:Query",
 "Resource":["arn:aws:dynamodb:us-east-1:227392126428:table/Orders",
             "arn:aws:dynamodb:us-east-1:227392126428:table/Orders/index/*"]}

Truy vấn qua GSI cần quyền trên CẢ bảng lẫn index
    → chỉ khai bảng thì Query trên GSI bị từ chối

Ba nhóm hành động DynamoDB: | Nhóm | Hành động | |---|---| | Item (dữ liệu) | PutItem, GetItem, UpdateItem, DeleteItem, Query, Scan | | Bảng (cấu hình) | CreateTable, DeleteTable, UpdateTable, DescribeTable | | Stream | GetRecords, GetShardIterator, DescribeStream |

⚠ dynamodb:* gộp cả ba nhóm — đó là lý do nó quá rộng.

Ba điều kiện IAM hữu ích cho DynamoDB: | Điều kiện | Việc | |---|---| | dynamodb:LeadingKeys | giới hạn theo giá trị partition key | | dynamodb:Attributes | giới hạn thuộc tính được truy cập | | dynamodb:Select | ép trả về thuộc tính cụ thể |

LeadingKeys là công cụ mạnh cho đa người dùng:

{"Effect":"Allow","Action":["dynamodb:GetItem","dynamodb:PutItem"],
 "Resource":"arn:aws:dynamodb:us-east-1:...:table/Orders",
 "Condition":{"ForAllValues:StringEquals":
   {"dynamodb:LeadingKeys":["${www.amazon.com:user_id}"]}}}

Mỗi người dùng chỉ đọc ghi được item có partition key
là chính id của họ
    → một bảng phục vụ nhiều người dùng an toàn

Ba nơi gắn quyền cho Lambda: | Nơi | Việc | |---|---| | Execution role | quyền Lambda gọi dịch vụ AWS ← câu này | | Resource-based policy | ai được gọi Lambda | | Permissions boundary | trần quyền tối đa |

Ba công cụ kiểm chứng: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử trước khi áp | | IAM Access Analyzer | sinh policy từ CloudTrail thật | | CloudTrail | xem lệnh bị từ chối |

⚠ Access Analyzer sinh policy là tính năng rất hữu ích:

aws accessanalyzer start-policy-generation   --policy-generation-details '{"principalArn":"<arn-role>"}'   --cloud-trail-details '{"trails":[{"cloudTrailArn":"<arn-trail>",
    "regions":["us-east-1"],"allRegions":false}],
    "accessRole":"<arn-role-doc>",
    "startTime":"2026-08-01T00:00:00Z"}'

Nó đọc CloudTrail xem role THỰC SỰ dùng những gì
    → sinh ra policy đặc quyền tối thiểu
        ↓
    Cách chính xác nhất để siết một policy quá rộng

Ba lỗi phổ biến trong IAM policy: | Lỗi | Hậu quả | |---|---| | Dùng Resource: "*" cho tiện | quá rộng | | Dùng service:* cho Action | quá rộng | | Nhầm ARN bảng và ARN item | AccessDenied khó hiểu |

Ba lưu ý khi siết policy đang chạy: | Lưu ý | Chi tiết | |---|---| | Xem CloudTrail 30 ngày để biết dùng gì | | | Áp ở môi trường dev trước | | | Theo dõi lỗi AccessDenied sau khi áp | |

Và một lời khuyên: hãy dùng IAM Access Analyzer sinh policy từ CloudTrail thay vì tự đoán danh sách hành động. Nó cho biết chính xác role đã gọi những API nào trong khoảng thời gian bạn chọn — và kết quả gần như luôn ngắn hơn nhiều so với policy mà người ta viết bằng tay "cho chắc".

Đáp án

B — Bật tính năng Requester Pays trên bucket S3 của bên cung cấp nội dung.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể, và Requester Pays là tính năng sinh ra đúng cho nó: | Yêu cầu | Cách đáp ứng | |---|---| | Đối tác ở vùng khác tải dữ liệu về | phí truyền dữ liệu ra là khoản lớn nhất | | Bên cung cấp muốn GIẢM chi phí truyền | chuyển phí sang bên tải về |

Requester Pays hoạt động thế nào:

Bình thường: chủ bucket trả MỌI phí
    → lưu trữ + request + truyền dữ liệu ra
        ↓
Bật Requester Pays: chủ bucket chỉ trả LƯU TRỮ
    → người tải trả phí request và phí truyền dữ liệu

Bật tính năng:

aws s3api put-bucket-request-payment   --bucket kho-tai-nguyen-hoc-tap   --request-payment-configuration Payer=Requester

⚠ Bên tải phải khai rõ họ chấp nhận trả:

aws s3api get-object --bucket kho-tai-nguyen-hoc-tap   --key bai-giang/chuong1.mp4 chuong1.mp4   --request-payer requester

Thiếu --request-payer requester
    → request bị từ chối với lỗi 403
        ↓
    Đây là cơ chế xác nhận: không ai vô tình bị tính tiền

Ba đặc điểm quan trọng: | Đặc điểm | Chi tiết | |---|---| | Người tải phải có tài khoản AWS và xác thực | | | KHÔNG cho phép truy cập ẩn danh | | | Chủ bucket vẫn trả phí lưu trữ | |

Vế thứ hai là hệ quả quan trọng:

Bật Requester Pays
    → mọi request ẩn danh bị từ chối
        ↓
    Bucket không còn phục vụ nội dung công khai được
    → phù hợp khi đối tác đã có tài khoản AWS (đúng như đề)

Ba trường hợp Requester Pays hợp lý: | Trường hợp | Chi tiết | |---|---| | Chia sẻ tập dữ liệu lớn cho đối tác | ← câu này | | Dữ liệu mở cho cộng đồng nghiên cứu | | | Nội dung mà bên tải hưởng lợi chính | |

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

• **C. Thiết lập Cross-Region Replication sang bucket của đối tác — đây là phương án gần nhất vì đối tác sẽ tải từ bucket cùng vùng của họ, nhưng bên cung cấp phải trả phí sao chép xuyên vùng cho TOÀN BỘ dữ liệu, kể cả phần đối tác không bao giờ đọc. Với vài TB thì đắt hơn hẳn.
• **A. Chuyển bucket sang S3 Standard-IA — Standard-IA giảm phí lưu trữ, nhưng đề hỏi về phí truyền dữ liệu. Và Standard-IA còn thêm phí lấy dữ liệu mỗi GB — làm chi phí tăng lên khi đối tác đọc nhiều.
• **D. Dùng S3 Transfer Acceleration — tăng tốc độ truyền nhưng tính THÊM phí mỗi GB. Nó làm chi phí tăng, không giảm.

Ghi nhớ

⚠ Bốn thành phần của hoá đơn S3 — bảng phải thuộc: | Thành phần | Ai trả (bình thường) | Với Requester Pays | |---|---|---| | Lưu trữ | chủ bucket | chủ bucket | | Request (GET, PUT, LIST) | chủ bucket | người yêu cầu | | Truyền dữ liệu RA | chủ bucket | người yêu cầu | | Truyền dữ liệu VÀO | miễn phí | miễn phí |

Từ khoá nhận diện:

"reduce data transfer costs when others download" → Requester Pays "reduce storage costs" → lớp lưu trữ + lifecycle "faster uploads from far away" → Transfer Acceleration "serve content globally, cheaper" → CloudFront

⚠ CloudFront cũng là cách giảm phí truyền — nhưng khác mục tiêu:

Data transfer từ S3 SANG CloudFront: MIỄN PHÍ
    → phục vụ qua CloudFront thường rẻ hơn S3 trực tiếp
        ↓
    Nhưng chủ bucket VẪN TRẢ phí truyền của CloudFront
    → Requester Pays chuyển hẳn chi phí sang bên kia

Ba lưu ý khi bật Requester Pays: | Lưu ý | Chi tiết | |---|---| | Truy cập ẩn danh bị chặn hoàn toàn | | | Người tải phải khai --request-payer requester | | | Không áp dụng cho CloudFront | |

Vế thứ ba đáng nhớ:

Bucket bật Requester Pays không dùng làm origin
cho CloudFront được (CloudFront không gửi header đó)
        ↓
    Phải chọn: hoặc Requester Pays, hoặc phân phối qua CDN

Ba cách chia sẻ dữ liệu cho bên thứ ba: | Cách | Ai trả phí truyền | |---|---| | Requester Pays | bên tải | | Bucket policy cross-account | chủ bucket | | Presigned URL | chủ bucket | | S3 Access Point cross-account | chủ bucket |

Bucket policy cho đối tác:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::444455556666:root"},
 "Action": ["s3:GetObject", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::kho-tai-nguyen-hoc-tap",
              "arn:aws:s3:::kho-tai-nguyen-hoc-tap/*"]}

Requester Pays quyết định AI TRẢ TIỀN
Bucket policy quyết định AI ĐƯỢC TRUY CẬP
        ↓
    Cần cả hai

Ba cách giảm phí truyền dữ liệu nói chung: | Cách | Chi tiết | |---|---| | CloudFront | S3 → CloudFront miễn phí | | VPC endpoint | truy cập nội bộ không qua NAT | | Requester Pays | chuyển phí sang bên tải |

⚠ Ba mức phí truyền dữ liệu cần biết: | Loại | Phí | |---|---| | Vào AWS (IN) | miễn phí | | Ra Internet (OUT) | cao nhất | | Giữa vùng | trung bình | | Giữa AZ trong vùng | thấp | | Trong cùng AZ (IP riêng) | miễn phí |

Ba lưu ý về lớp lưu trữ và phí lấy dữ liệu: | Lớp | Phí lấy dữ liệu | |---|---| | Standard | không | | Intelligent-Tiering | không | | Standard-IA, One Zone-IA | có | | Glacier | có (cao hơn) |

Điều này quan trọng khi dữ liệu được đọc nhiều:

Chuyển sang IA để giảm phí lưu trữ
    → nhưng đối tác đọc thường xuyên
    → phí lấy dữ liệu vượt khoản tiết kiệm
        ↓
    Dùng S3 Storage Class Analysis để quyết định bằng số liệu

Ba công cụ phân tích chi phí: | Công cụ | Việc | |---|---| | Cost Explorer tách theo usage type | thấy rõ phí nào là chính | | S3 Storage Lens | phân bố dữ liệu | | S3 Storage Class Analysis | gợi ý chuyển tầng |

Ba lưu ý về theo dõi sau khi bật: | Lưu ý | Chi tiết | |---|---| | Bật server access log hoặc CloudTrail | biết ai tải gì | | Xác nhận hoá đơn giảm ở mục data transfer | | | Thông báo cho đối tác về thay đổi | |

Vế cuối rất quan trọng về vận hành:

Bật Requester Pays mà không báo trước
    → mọi script của đối tác lập tức nhận 403
        ↓
    Họ phải sửa mã thêm --request-payer requester
    → thông báo trước và cho thời gian chuyển đổi

Và một lời khuyên: hãy báo cho đối tác trước ít nhất một tuần khi bật Requester Pays. Đây là thay đổi phá vỡ tương thích ngược — mọi công cụ đang tải dữ liệu sẽ dừng ngay lập tức với lỗi 403, và thông báo lỗi đó không hề gợi ý rằng nguyên nhân là một cài đặt thanh toán.

Đáp án

D — Bật S3 Object Lock trên các object cần thiết và đặt chế độ compliance.

Vì sao đúng

Đề nêu hai yêu cầu, và Object Lock chế độ compliance đáp ứng chính xác: | Yêu cầu | Cách đáp ứng | |---|---| | Tài liệu nhạy cảm không được XOÁ hay SỬA | Object Lock chặn cả hai | | Trong một khoảng thời gian CỐ ĐỊNH | retention period |

Hai chế độ của Object Lock — bảng phân biệt: | Chế độ | Ai gỡ được trước hạn | |---|---| | Governance | người có quyền s3:BypassGovernanceRetention | | Compliance | KHÔNG AI — kể cả tài khoản root |

Đề nói "protected from deletion or modification
        for a FIXED period of time"
    → yêu cầu tuân thủ nghiêm ngặt
        ↓
    Compliance mode là chế độ không có ngoại lệ

Đặt retention cho object:

aws s3api put-object-retention   --bucket kho-tai-lieu-tuan-thu --key hop-dong/2026-001.pdf   --retention '{"Mode":"COMPLIANCE",
                "RetainUntilDate":"2033-08-30T00:00:00Z"}'

Hoặc đặt retention mặc định cho cả bucket:

aws s3api put-object-lock-configuration   --bucket kho-tai-lieu-tuan-thu   --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}'

⚠ Object Lock phải bật LÚC TẠO bucket:

aws s3api create-bucket --bucket kho-tai-lieu-tuan-thu   --object-lock-enabled-for-bucket   --create-bucket-configuration LocationConstraint=ap-southeast-1

Bucket đã tồn tại KHÔNG bật Object Lock qua API được
    → phải liên hệ AWS Support
        ↓
    Và Object Lock BẮT BUỘC versioning phải bật

Ba đặc điểm trong thời gian khoá: | Đặc điểm | Chi tiết | |---|---| | Không xoá được phiên bản đó | | | Không ghi đè được | ghi mới tạo phiên bản mới | | Không rút ngắn được retention | chỉ kéo DÀI thêm |

Vế thứ ba là điều làm compliance mode thực sự nghiêm:

Đặt nhầm 100 năm thay vì 7 năm ở chế độ COMPLIANCE
    → KHÔNG rút ngắn được
    → không xoá được object
        ↓
    Chỉ còn cách xoá cả tài khoản AWS
    → thử ở bucket không quan trọng trước

Và legal hold là cơ chế bổ sung:

aws s3api put-object-legal-hold   --bucket kho-tai-lieu-tuan-thu --key hop-dong/2026-001.pdf   --legal-hold Status=ON

Legal hold KHÔNG có thời hạn
    → giữ vô thời hạn cho tới khi được gỡ
        ↓
    Dùng cho tranh chấp pháp lý
    → hoạt động độc lập với retention period

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

• **A. Kích hoạt Object Lock chế độ compliance TRÊN BUCKET, cấu hình "WORM policy" — đây là phương án gần nhất và về ý tưởng thì đúng, nhưng cách diễn đạt không khớp cách AWS hoạt động: bật Object Lock ở cấp bucket chỉ cho phép dùng tính năng; retention phải được đặt (mặc định hoặc theo từng object). Và không có thứ gọi là "WORM policy" như một cấu hình riêng.
• **B. Bucket có versioning và lifecycle tự xoá phiên bản cũ — versioning giữ lịch sử nhưng không ngăn ai xoá, và lifecycle chủ động xoá — ngược hẳn mục tiêu bảo vệ.
• **C. Dùng AWS Backup tạo "bản sao lưu bất biến" — AWS Backup có Vault Lock cho bản sao lưu, nhưng đề yêu cầu bảo vệ chính các object trong S3, không phải một bản sao của chúng.

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

Phương án A và D rất gần nhau, và khác biệt đáng được nói rõ vì bản thân Object Lock cần cả hai cấp:

Object Lock luôn có hai bước: | Bước | Cấp | Bắt buộc | |---|---|---| | Bật Object Lock | BUCKET, lúc TẠO | ✅ | | Đặt retention (mode + thời hạn) | OBJECT (hoặc mặc định cấp bucket) | ✅ |

Chỉ bật ở bucket mà không đặt retention
    → không object nào được bảo vệ
Chỉ có retention mà bucket chưa bật Object Lock
    → không đặt được
        ↓
    Cả hai phương án A và D đều mô tả một nửa sự thật

Vì sao D được chọn: nó nói rõ việc đặt chế độ compliance trên các object cần thiết — tức là bước thực sự tạo ra bảo vệ. Phương án A dùng cụm "WORM policy" không tương ứng với tính năng nào có thật.

Ghi nhớ

⚠ Ba cơ chế bảo vệ dữ liệu S3 — bảng phải thuộc: | Cơ chế | Bảo vệ khỏi | Gỡ được không | |---|---|---| | Object Lock — Governance | xoá nhầm | có, nếu đủ quyền | | Object Lock — Compliance | xoá cố ý | KHÔNG AI | | Legal hold | xoá trong tranh chấp | có, nếu đủ quyền | | MFA Delete | xoá nhầm | cần MFA | | Versioning | ghi đè | không ngăn xoá |

Từ khoá nhận diện:

"cannot be deleted or modified, fixed period, regulatory" → Object Lock compliance "protect from accidental deletion, admin can override" → governance mode "indefinite hold for litigation" → legal hold "recover accidentally deleted snapshots" → Recycle Bin (cho EBS)

Ba điều kiện tiên quyết của Object Lock: | Điều kiện | Chi tiết | |---|---| | Bật LÚC TẠO bucket | không bật sau qua API được | | Versioning phải bật | và không tắt được nữa | | Áp cho từng PHIÊN BẢN object | |

Ba cách đặt retention: | Cách | Chi tiết | |---|---| | Default retention của bucket | áp cho object mới | | Đặt lúc PUT object | header x-amz-object-lock-* | | Đặt sau bằng put-object-retention | |

aws s3api put-object --bucket kho-tai-lieu-tuan-thu   --key hop-dong/2026-002.pdf --body hop-dong.pdf   --object-lock-mode COMPLIANCE   --object-lock-retain-until-date 2033-08-30T00:00:00Z

⚠ Ba điều Object Lock KHÔNG làm: | Điều | Chi tiết | |---|---| | Không ngăn TẠO phiên bản mới | chỉ khoá phiên bản đã có | | Không ngăn xoá cả bucket nếu rỗng | | | Không thay thế sao lưu | vẫn cần bản sao |

Vế đầu là điểm hay gây hiểu nhầm:

Object bị khoá vẫn "ghi đè" được
    → nhưng thực chất là tạo PHIÊN BẢN MỚI
    → phiên bản cũ vẫn nguyên vẹn và được bảo vệ
        ↓
    Đây chính là mô hình WORM với versioning

Ba lưu ý về governance mode: | Lưu ý | Chi tiết | |---|---| | Cần s3:BypassGovernanceRetention để gỡ | | | Phải thêm header x-amz-bypass-governance-retention: true | | | Dùng khi cần cửa thoát hiểm | |

aws s3api delete-object --bucket kho --key tai-lieu.pdf   --version-id abc123 --bypass-governance-retention

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Object bị khoá VẪN tính phí lưu trữ | | | Không xoá được = chi phí cố định suốt thời hạn | | | Dùng lifecycle chuyển sang lớp rẻ | Glacier vẫn khoá được |

⚠ Kết hợp Object Lock với lifecycle:

{"Rules":[{"ID":"chuyen-tang-nhung-van-khoa","Status":"Enabled","Filter":{},
  "Transitions":[{"Days":90,"StorageClass":"GLACIER"}]}]}

Object vẫn bị khoá, chỉ chuyển sang lớp rẻ hơn
    → lifecycle KHÔNG xoá được object đang bị khoá

Ba lựa chọn tương đương ở dịch vụ khác: | Dịch vụ | Cơ chế | |---|---| | AWS Backup | Vault Lock (compliance mode) | | EBS snapshot | Recycle Bin (khôi phục, không phải WORM) | | CloudTrail | log file validation |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử xoá một object bị khoá | phải bị từ chối | | Kiểm tra retention date đúng | | | Thử với tài khoản root | compliance mode vẫn chặn |

aws s3api get-object-retention --bucket kho-tai-lieu-tuan-thu   --key hop-dong/2026-001.pdf

Và một lời khuyên: hãy thử compliance mode trên một bucket bỏ đi với thời hạn một ngày trước khi áp cho dữ liệu thật. Đây là một trong số rất ít cấu hình của AWS mà bạn không thể hoàn tác bằng bất kỳ cách nào — và một con số nhập nhầm sẽ khoá dữ liệu và hoá đơn của bạn trong nhiều năm.

Đáp án

C — Cấu hình Amazon CloudWatch Container Insights trên chính cụm EKS đang chạy, xem metric và log trong CloudWatch console.

Vì sao đúng

Đề nêu bốn yêu cầu, và Container Insights được thiết kế chính xác cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Cụm EKS đang chạy, kiến trúc microservice | bật trên cụm hiện có, không di chuyển | | Thu thập, TỔNG HỢP, TÓM TẮT metric và log | Container Insights làm cả ba | | Bảng điều khiển TẬP TRUNG | CloudWatch console có sẵn dashboard | | Xem CPU/RAM theo NAMESPACE, SERVICE, POD | đúng các chiều Container Insights cung cấp |

Vế cuối là điểm quyết định:

"CPU and memory utilization for EKS NAMESPACES,
 SERVICES, and PODS"
        ↓
    Đây chính là các chiều (dimension) mà
    Container Insights tự tổng hợp
    → CloudWatch Agent thuần chỉ cho metric ở cấp NODE

Bật Container Insights:

aws eks create-addon --cluster-name cum-cung-ung   --addon-name amazon-cloudwatch-observability   --service-account-role-arn <arn-role>

Hoặc cài bằng manifest:

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml

Hai thành phần được cài: | Thành phần | Việc | |---|---| | CloudWatch Agent (DaemonSet) | thu thập metric | | Fluent Bit (DaemonSet) | thu thập log container |

Các metric được tổng hợp sẵn:

namespace = ContainerInsights
    → node_cpu_utilization
    → pod_cpu_utilization
    → pod_memory_utilization
    → service_number_of_running_pods
    → namespace_number_of_running_pods
        ↓
    Với chiều: ClusterName, Namespace, Service, PodName

Truy vấn log bằng Logs Insights:

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "san-xuat"
| filter log like /ERROR/
| sort @timestamp desc
| limit 50

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không di chuyển tải sang dịch vụ khác | | | Dashboard dựng sẵn theo cụm, namespace, pod | | | Metric và log ở cùng một nơi | |

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

• **A. Chạy CloudWatch Agent thuần trong cụm EKS — đây là phương án gần nhất và thực sự thu thập được metric, nhưng agent thuần cho metric ở cấp node và cấp hệ điều hành, không tự tổng hợp theo namespace, service, pod của Kubernetes. Container Insights chính là lớp bổ sung làm việc đó.
• **B. Chuyển container sang ECS rồi bật Container Insights — giải quyết được việc giám sát nhưng đòi di chuyển toàn bộ tải từ EKS sang ECS. Công sức khổng lồ cho một yêu cầu về khả năng quan sát, trong khi Container Insights hỗ trợ EKS trực tiếp.
• **D. Dùng AWS X-Ray và truy vấn bằng Elasticsearch — X-Ray là công cụ theo dõi dấu vết yêu cầu (tracing), cho biết một request đi qua những dịch vụ nào và chậm ở đâu. Nó không cung cấp metric CPU và bộ nhớ.

Ghi nhớ

⚠ Ba trụ cột của khả năng quan sát — bảng phải thuộc: | Trụ cột | Công cụ AWS | Trả lời câu hỏi | |---|---|---| | Metric | CloudWatch, Container Insights | "tài nguyên dùng bao nhiêu?" | | Log | CloudWatch Logs, Fluent Bit | "chuyện gì đã xảy ra?" | | Trace | AWS X-Ray, ADOT | "request chậm ở bước nào?" |

Từ khoá nhận diện:

"CPU/memory by namespace, pod, service" → Container Insights "which service is slow in a request chain" → X-Ray "search log content" → CloudWatch Logs Insights "Prometheus metrics" → Amazon Managed Service for Prometheus

Ba nền tảng Container Insights hỗ trợ: | Nền tảng | Hỗ trợ | |---|---| | Amazon EKS | ✅ | | Amazon ECS | ✅ | | Kubernetes tự quản trên EC2 | ✅ |

Ba nhóm metric của Container Insights: | Nhóm | Ví dụ | |---|---| | Cụm | cluster_node_count, cluster_failed_node_count | | Node | node_cpu_utilization, node_filesystem_utilization | | Pod / Service / Namespace | pod_cpu_utilization, pod_memory_utilization |

⚠ Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính phí theo SỐ metric tuỳ chỉnh | nhiều pod = nhiều metric | | Cộng phí nạp và lưu log | | | Cụm lớn có thể tốn đáng kể | |

Ba cách giảm chi phí: | Cách | Chi tiết | |---|---| | Đặt retention cho log group | mặc định là vô thời hạn | | Lọc log ở Fluent Bit trước khi gửi | | | Chỉ bật cho namespace quan trọng | |

aws logs put-retention-policy   --log-group-name /aws/containerinsights/cum-cung-ung/application   --retention-in-days 30

⚠ Retention mặc định là "Never expire" — đây là nguồn chi phí ẩn phổ biến.

Ba lựa chọn giám sát khác cho EKS: | Lựa chọn | Khi nào | |---|---| | Amazon Managed Prometheus + Managed Grafana | đã quen hệ sinh thái Prometheus | | Container Insights | muốn tích hợp sẵn AWS ← câu này | | Bên thứ ba (Datadog, New Relic) | đã dùng sẵn |

Prometheus + Grafana đáng biết:

Nhiều đội Kubernetes đã có sẵn PromQL và dashboard Grafana
    → Amazon Managed Prometheus nhận scrape từ cụm
    → Managed Grafana vẽ dashboard
        ↓
    Không phải vận hành Prometheus server

Ba log group Container Insights tạo ra: | Log group | Nội dung | |---|---| | /aws/containerinsights/<cụm>/application | log của container | | /aws/containerinsights/<cụm>/host | log hệ điều hành node | | /aws/containerinsights/<cụm>/dataplane | log của kubelet, containerd |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Node role cần CloudWatchAgentServerPolicy | | | Hoặc dùng IRSA cho service account | | | IRSA an toàn hơn | quyền gắn vào pod, không phải node |

IRSA là thực hành tốt:

eksctl create iamserviceaccount --name cloudwatch-agent   --namespace amazon-cloudwatch --cluster cum-cung-ung   --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy   --approve

Ba metric quan trọng nhất cần đặt alarm: | Metric | Ý nghĩa | |---|---| | pod_cpu_utilization gần giới hạn | pod sắp bị throttle | | pod_memory_utilization gần giới hạn | pod sắp bị OOMKilled | | cluster_failed_node_count | node hỏng |

⚠ OOMKilled là sự cố im lặng nhất trong Kubernetes:

Pod vượt memory limit → kernel giết ngay
    → không có log lỗi từ ứng dụng
    → pod khởi động lại
        ↓
    Chỉ thấy qua metric bộ nhớ và sự kiện Kubernetes

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra DaemonSet chạy trên mọi node | | | Xem metric xuất hiện trong CloudWatch | sau vài phút | | Thử một truy vấn Logs Insights | |

Và một lời khuyên: hãy đặt retention cho log group ngay khi bật Container Insights. Log của một cụm Kubernetes bận rộn tích tụ rất nhanh, và mặc định "không bao giờ hết hạn" nghĩa là bạn sẽ trả tiền cho log của năm nay trong suốt phần đời còn lại của tài khoản AWS.

Đáp án

A — Mua Standard Reserved Instance cho các máy chạy liên tục từ thứ Ba tới Chủ nhật, và dùng Scheduled Reserved Instance cho các máy chạy 8 giờ vào thứ Hai.

Vì sao đúng theo đáp án nguồn

Đề mô tả hai mẫu tải khác nhau, và lập luận của đáp án là ghép mỗi mẫu với một mô hình thanh toán: | Mẫu tải | Đặc điểm | Mô hình | |---|---|---| | Thứ Ba - Chủ nhật, liên tục | ổn định, biết trước | Standard RI — giảm giá cao nhất | | Thứ Hai, 8 giờ | theo lịch cố định, không được gián đoạn | Scheduled RI |

Vì sao Spot bị loại:

Đề nói rõ CẢ HAI mẫu tải "cannot tolerate interruptions"
    → Spot bị thu hồi với 2 phút báo trước
        ↓
    Loại ngay phương án B và D

Vì sao Standard RI cho phần chạy liên tục: | Loại RI | Giảm giá | Linh hoạt | |---|---|---| | Standard RI | tới ~72% | thấp — không đổi họ instance | | Convertible RI | tới ~54% | cao — đổi được họ, OS, tenancy |

Tải ổn định, không cần đổi loại máy
    → Standard RI cho mức giảm cao nhất
        ↓
    Convertible chỉ đáng khi cần linh hoạt

Đây là lý do loại phương án C và D — chúng dùng Convertible cho phần lẽ ra nên dùng Standard.

Mua Standard RI:

aws ec2 describe-reserved-instances-offerings   --instance-type m6i.large --product-description "Linux/UNIX"   --offering-class standard --offering-type "All Upfront"   --min-duration 31536000 --max-duration 31536000

aws ec2 purchase-reserved-instances-offering   --reserved-instances-offering-id <id> --instance-count 10

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

Đáp án A đúng theo khoá, nhưng có một điểm quan trọng người học phải biết:

⚠ AWS đã NGỪNG Scheduled Reserved Instances.

Scheduled RI không còn mua mới được
    → AWS ngừng nhận đơn hàng mới
        ↓
    Câu hỏi này phản ánh danh mục sản phẩm cũ

Ba lựa chọn thay thế cho tải theo lịch hiện nay: | Lựa chọn | Chi tiết | |---|---| | On-Demand + EventBridge Scheduler | bật máy trước giờ, tắt sau | | On-Demand Capacity Reservation theo lịch | đảm bảo có máy | | Savings Plans | giảm giá cho cả phần chạy theo lịch |

Cách làm hiện đại cho phần thứ Hai:

# Bật máy 8 giờ sáng thứ Hai
aws scheduler create-schedule --name bat-may-thu-hai   --schedule-expression "cron(0 8 ? * MON *)"   --schedule-expression-timezone "Asia/Ho_Chi_Minh"   --flex-time-window Mode=OFF   --target '{"Arn":"arn:aws:scheduler:::aws-sdk:autoscaling:setDesiredCapacity",
    "RoleArn":"<arn-role>",
    "Input":"{\"AutoScalingGroupName\":\"asg-thu-hai\",\"DesiredCapacity\":10}"}'

Chỉ trả tiền 8 giờ mỗi tuần với giá On-Demand
    → hoặc phủ bằng Compute Savings Plans để giảm giá

⚠ Và Savings Plans thường là câu trả lời tốt hơn RI cho câu hỏi kiểu này ngày nay: | | Reserved Instance | Savings Plans | |---|---|---| | Cam kết | loại instance cụ thể | số tiền mỗi giờ | | Linh hoạt | thấp (Standard) | cao | | Áp cho Fargate và Lambda | ❌ | ✅ (Compute SP) | | Mức giảm tối đa | ~72% | ~72% |

Compute Savings Plans giảm giá tương đương Standard RI
    → mà linh hoạt hơn nhiều
        ↓
    Với thiết kế mới, hầu như luôn nên chọn Savings Plans

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

• **C. Standard RI cho phần liên tục + Convertible RI cho 8 giờ thứ Hai — đây là phương án gần nhất vì nửa đầu đúng và Convertible RI không bị gián đoạn, nhưng RI (cả Standard lẫn Convertible) là cam kết 24/7 trong 1-3 năm. Mua RI cho một tải chạy 8 giờ mỗi tuần nghĩa là trả tiền cho 160 giờ để dùng 8 giờ.
• **B. Spot cho 8 giờ thứ Hai — vi phạm trực tiếp yêu cầu "cannot tolerate interruptions".
• **D. Convertible RI cho phần liên tục + Spot cho thứ Hai — sai cả hai vế: Convertible giảm giá ít hơn Standard cho tải ổn định, và Spot bị gián đoạn.

Ghi nhớ

⚠ Bốn mô hình thanh toán EC2 — bảng phải thuộc: | Mô hình | Giảm giá | Gián đoạn | Cam kết | |---|---|---|---| | On-Demand | 0% | ❌ | không | | Savings Plans | tới ~72% | ❌ | số tiền/giờ, 1-3 năm | | Reserved Instance | tới ~72% | ❌ | loại máy, 1-3 năm | | Spot | tới ~90% | ✅ 2 phút báo trước | không |

Từ khoá nhận diện:

"steady 24/7 + cannot be interrupted" → Standard RI hoặc Savings Plans "fault-tolerant, can be interrupted" → Spot "need to change instance family later" → Convertible RI hoặc Compute SP "guarantee capacity" → On-Demand Capacity Reservation hoặc zonal RI

⚠ Ba loại Savings Plans: | Loại | Giảm | Linh hoạt | |---|---|---| | Compute Savings Plans | tới ~66% | mọi vùng, mọi họ, cả Fargate và Lambda | | EC2 Instance Savings Plans | tới ~72% | cố định họ và vùng | | SageMaker Savings Plans | | cho ML |

⚠ Bảng đảm bảo năng lực — hay bị nhầm: | Lựa chọn | Giảm giá | Đảm bảo năng lực | |---|---|---| | Zonal RI | ✅ | ✅ | | Regional RI | ✅ | ❌ | | Savings Plans | ✅ | ❌ | | On-Demand Capacity Reservation | ❌ | ✅ |

Ba tuỳ chọn thanh toán RI: | Tuỳ chọn | Mức giảm | |---|---| | All Upfront | cao nhất | | Partial Upfront | trung bình | | No Upfront | thấp nhất |

Ba cách tối ưu cho tải theo lịch: | Cách | Chi tiết | |---|---| | EventBridge Scheduler bật/tắt | ← cách hiện đại | | ASG scheduled action | | | Instance Scheduler solution của AWS | |

ASG scheduled action cho mẫu tải của đề:

aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-san-xuat   --scheduled-action-name bat-thu-hai   --recurrence "0 8 * * MON" --desired-capacity 10   --time-zone "Asia/Ho_Chi_Minh"

aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-san-xuat   --scheduled-action-name tat-thu-hai   --recurrence "0 16 * * MON" --desired-capacity 0   --time-zone "Asia/Ho_Chi_Minh"

⚠ Luôn khai --time-zone:

Không khai → ASG hiểu là UTC
    → "0 8" thành 15 giờ chiều giờ Việt Nam

Ba công cụ phân tích chi phí: | Công cụ | Việc | |---|---| | Cost Explorer RI/SP recommendations | gợi ý mua bao nhiêu | | AWS Compute Optimizer | đúng cỡ máy | | Trusted Advisor | tài nguyên nhàn rỗi |

Ba lưu ý khi mua cam kết dài hạn: | Lưu ý | Chi tiết | |---|---| | Đúng cỡ máy TRƯỚC khi mua | không mua RI cho máy quá to | | Mua phủ tải NỀN, không phủ đỉnh | | | Xem lại mức phủ hằng quý | |

Vế đầu quan trọng:

Mua RI 3 năm cho một loại instance quá lớn
    → khoá luôn cả sự lãng phí trong 3 năm
        ↓
    Chạy Compute Optimizer trước khi cam kết

Và một lời khuyên: khi thiết kế hệ thống thật hôm nay, hãy bắt đầu bằng Compute Savings Plans thay vì Reserved Instance. Chúng cho mức giảm tương đương nhưng không khoá bạn vào một loại instance cụ thể — và điều đó rất đáng giá khi AWS ra thế hệ máy mới rẻ hơn giữa chu kỳ cam kết ba năm của bạn.

Đáp án

B — Dùng AWS Storage Gateway file gateway cung cấp một hệ thống tệp truy cập được tại chỗ, dữ liệu được sao chép lên đám mây, rồi phân tích trên AWS.

Vì sao đúng

Đề nêu ba yêu cầu, và File Gateway thoả cả ba cùng lúc: | Yêu cầu | Cách đáp ứng | |---|---| | **Ứng dụng tại chỗ ghi vào hệ thống tệp mount bằng NFS | File Gateway xuất NFS | | Dữ liệu phải truy cập được TẠI CHỖ | share cục bộ có cache | | EC2 trên AWS phân tích dữ liệu đó | mỗi tệp thành một object S3 |

Vế thứ ba là điểm quyết định:

File Gateway lưu mỗi tệp thành MỘT OBJECT S3 bình thường
    → EC2 trên AWS đọc thẳng từ S3
    → Athena, Glue, EMR đều truy vấn được
        ↓
    Volume Gateway lưu dạng snapshot EBS
    → phải khôi phục thành volume mới đọc được

Đây chính là lý do loại cả A và C.

Triển khai:

aws storagegateway create-nfs-file-share   --client-token $(uuidgen) --gateway-arn <arn-gateway>   --location-arn arn:aws:s3:::du-lieu-phan-tich   --role <arn-role> --client-list 192.168.1.0/24   --default-storage-class S3_STANDARD

Ứng dụng mount như bình thường:

sudo mount -t nfs -o nolock,hard   10.0.1.50:/du-lieu-phan-tich /mnt/du-lieu

Ứng dụng không cần sửa mã
    → vẫn ghi bằng open()/write()

Và phân tích trên AWS:

CREATE EXTERNAL TABLE du_lieu_san_xuat (...)
STORED AS PARQUET
LOCATION 's3://du-lieu-phan-tich/';

SELECT ngay, sum(so_luong) FROM du_lieu_san_xuat GROUP BY ngay;

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ứng dụng tại chỗ không đổi gì | vẫn là NFS share | | Dữ liệu tự lên S3, sẵn sàng phân tích | | | Cache cục bộ cho tệp hay dùng | |

Ba dịch vụ phân tích dùng được ngay: | Dịch vụ | Việc | |---|---| | Amazon Athena | truy vấn SQL trực tiếp trên S3 | | AWS Glue | ETL và danh mục dữ liệu | | Amazon EMR | Spark, Hadoop trên lượng lớn |

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

• **C. Dùng volume gateway chế độ cached sao lưu lưu trữ cục bộ lên đám mây rồi phân tích — đây là phương án gần nhất vì cũng đưa dữ liệu lên AWS và cũng có cache, nhưng nó sai giao diện và sai định dạng: volume gateway xuất iSCSI (khối), không phải NFS; và dữ liệu lưu dạng snapshot EBS nên EC2 không đọc trực tiếp được — phải tạo volume từ snapshot trước.
• **A. Dùng volume gateway chế độ stored chụp snapshot định kỳ — cùng vấn đề giao diện iSCSI và định dạng snapshot. Thêm nữa, stored mode giữ toàn bộ dữ liệu tại chỗ, không giải quyết việc mở rộng dung lượng.
• **D. Dùng tape gateway sao lưu rồi phân tích — Tape Gateway lưu dạng băng ảo cho mục đích sao lưu dài hạn. Lấy dữ liệu ra là quy trình khôi phục băng, hoàn toàn không phù hợp cho phân tích thường xuyên.

Ghi nhớ

⚠ Bốn chế độ Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Dữ liệu trên AWS | |---|---|---| | S3 File Gateway | NFS, SMB | object S3 — đọc trực tiếp được ← câu này | | FSx File Gateway | SMB | FSx for Windows | | Volume Gateway | iSCSI (khối) | snapshot EBS | | Tape Gateway | iSCSI VTL | băng ảo trong S3/Glacier |

⚠ Khác biệt cốt lõi để chọn nhanh:

Dữ liệu sau này có cần ĐỌC TRỰC TIẾP trên AWS không?
    → CÓ  → File Gateway (object S3)
    → KHÔNG, chỉ để khôi phục → Volume hoặc Tape Gateway

Từ khoá nhận diện:

"NFS/SMB locally" + "analyze in AWS" → S3 File Gateway "iSCSI block volumes" → Volume Gateway "replace physical tape library" → Tape Gateway "migrate data once" → DataSync

Hai chế độ Volume Gateway (để phân biệt): | Chế độ | Dữ liệu chính | |---|---| | Cached | S3, cache nóng tại chỗ | | Stored | TẠI CHỖ toàn bộ, snapshot lên S3 |

Ba đặc điểm của File Gateway: | Đặc điểm | Chi tiết | |---|---| | Mỗi tệp thành MỘT object S3 | | | Ghi vào share → đẩy lên S3 bất đồng bộ | | | Cache tối thiểu 150 GB | |

⚠ Ba lưu ý về nhất quán: | Lưu ý | Chi tiết | |---|---| | Object ghi thẳng vào S3 KHÔNG tự hiện trong share | | | Phải gọi RefreshCache | | | Hoặc đặt CacheStaleTimeoutInSeconds | |

aws storagegateway refresh-cache --file-share-arn <arn> --recursive

Điều này quan trọng khi có luồng hai chiều:

EC2 xử lý xong ghi kết quả vào S3
    → ứng dụng tại chỗ không thấy tệp mới
        ↓
    Phải RefreshCache, hoặc đặt timeout tự làm mới

Ba cách triển khai gateway: | Cách | Khi nào | |---|---| | Máy ảo (VMware, Hyper-V, KVM) | có hạ tầng ảo hoá | | Hardware Appliance | không có tài nguyên ảo hoá | | EC2 | tải chạy trên AWS |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitPercent | trải nghiệm đọc | | CachePercentUsed | cache đầy | | FilesFailingUpload | tệp lỗi |

Ba lưu ý về định dạng cho phân tích: | Lưu ý | Chi tiết | |---|---| | Parquet rẻ hơn CSV nhiều khi truy vấn | | | Phân vùng theo ngày | nam=/thang=/ngay= | | Gộp tệp nhỏ thành tệp lớn | |

⚠ Nhiều tệp nhỏ là vấn đề ở cả hai đầu:

File Gateway: tệp nhỏ đẩy lên chậm hơn
Athena:       nhiều object nhỏ làm truy vấn chậm và tốn hơn
        ↓
    Gộp lại nếu ứng dụng cho phép

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Chuyển dữ liệu cũ sang IA hoặc Glacier | | | Nhưng dữ liệu ở Glacier không truy vấn trực tiếp | | | Giữ dữ liệu đang phân tích ở Standard | |

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Đặt giới hạn tải lên theo giờ | | | Đồng bộ ban đầu tốn nhiều | | | Cân nhắc Snowball cho lượng lớn ban đầu | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest bằng KMS | | | Truyền qua TLS | | | client-list giới hạn IP mount được | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi tệp qua share, kiểm tra trên S3 | | | Chạy một truy vấn Athena | | | Đo thời gian đọc tệp cũ | |

Và một lời khuyên: hãy hỏi ngay từ đầu "dữ liệu này sau có cần đọc trực tiếp trên AWS không". Đó là câu hỏi phân loại giữa File Gateway và Volume Gateway, và chọn nhầm nghĩa là dữ liệu nằm trong snapshot EBS — vẫn an toàn, nhưng mỗi lần muốn phân tích lại phải khôi phục thành volume và gắn vào một EC2.