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

Đáp án

C — Cấu hình AWS Transit Gateway giữa các tài khoản, gắn Direct Connect vào transit gateway rồi định tuyến lưu lượng về trung tâm dữ liệu.

Vì sao đúng

Đề nêu ba yêu cầu, và Transit Gateway là cách duy nhất thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Đã có DX nối trung tâm dữ liệu với một VPC | tái dùng chính kết nối đó | | Nhiều tài khoản mới cần cùng truy cập | transit gateway chia sẻ qua RAM | | Nhanh, rẻ, ÍT CÔNG VẬN HÀNH NHẤT | một trung tâm định tuyến duy nhất |

Vấn đề nếu không có Transit Gateway:

Mỗi VPC nối riêng tới Direct Connect Gateway
    → mỗi cái một private VIF
    → mỗi tài khoản mới lại thêm cấu hình
        ↓
    Và DX chỉ hỗ trợ tối đa 50 private VIF mỗi kết nối
    → không mở rộng được

Có Transit Gateway:

      Trung tâm dữ liệu
            │ Direct Connect
      Direct Connect Gateway
            │ transit VIF
      ┌─────▼──────┐
      │  Transit   │◀── chia sẻ qua AWS RAM
      │  Gateway   │
      └─┬───┬───┬──┘
        │   │   │
      VPC-A VPC-B VPC-C   (ở các tài khoản khác nhau)
        ↓
    Tài khoản mới → gắn VPC vào TGW → xong

Chia sẻ Transit Gateway qua AWS RAM:

aws ram create-resource-share --name chia-se-tgw   --resource-arns arn:aws:ec2:ap-southeast-1:111122223333:transit-gateway/tgw-abc   --principals ou-root-xyz789 --allow-external-principals false

Tài khoản mới gắn VPC vào:

aws ec2 create-transit-gateway-vpc-attachment   --transit-gateway-id tgw-abc --vpc-id vpc-moi   --subnet-ids subnet-a subnet-b

Gắn Direct Connect Gateway vào TGW:

aws ec2 create-transit-gateway-direct-connect-gateway-attachment   --transit-gateway-id tgw-abc --direct-connect-gateway-id dxgw-123

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một kết nối DX dùng chung cho mọi tài khoản | | | Định tuyến tập trung, dễ kiểm soát | | | Thêm tài khoản chỉ là một attachment | |

Vế thứ hai đáng nhấn mạnh:

Transit Gateway route table cho phép PHÂN ĐOẠN
    → VPC sản xuất và VPC thử nghiệm dùng bảng khác nhau
    → cả hai ra được trung tâm dữ liệu
    → nhưng KHÔNG thấy nhau
        ↓
    Cách ly bằng cấu hình, không cần thêm hạ tầng

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

• **D. Tạo VPN giữa mỗi tài khoản mới và VPC có Direct Connect — đây là phương án gần nhất vì cũng tái dùng kết nối DX, nhưng nó chồng chất công vận hành: mỗi tài khoản một VPN riêng, mỗi cái phải cấu hình BGP và bảng định tuyến, và lưu lượng phải nhảy qua VPC trung gian. Số kết nối tăng theo cấp số nhân.
• **B. Tạo một Direct Connect riêng cho mỗi tài khoản mới — đắt và chậm nhất: DX mất hàng tuần tới hàng tháng để cung cấp, và mỗi kết nối là một khoản phí cổng riêng. Ngược hẳn "quickly and cost-effectively".
• **A. Cấu hình VPC endpoint trong VPC có DX — sai công cụ: VPC endpoint dùng để truy cập dịch vụ AWS (S3, DynamoDB) mà không qua Internet. Nó không định tuyến lưu lượng về máy chủ tại chỗ.

Ghi nhớ

Ba cách nối nhiều VPC — bảng phải thuộc: | Cách | Mở rộng | Đặc điểm | |---|---|---| | VPC Peering | kém — n(n-1)/2 kết nối | KHÔNG bắc cầu | | Transit Gateway | tốt — trung tâm hình sao | có định tuyến ← câu này | | PrivateLink | tốt | chỉ một dịch vụ, một chiều |

Từ khoá nhận diện:

"multiple accounts" + "Direct Connect" + "least overhead" → Transit Gateway "expose one service to other VPCs" → PrivateLink "two VPCs only" → VPC Peering

⚠ VPC Peering không bắc cầu — điều phải thuộc:

A ↔ B và B ↔ C
    → A KHÔNG nói chuyện được với C
        ↓
    Muốn 10 VPC nối đủ → 45 kết nối peering
    → đó là lý do Transit Gateway tồn tại

Ba loại attachment của Transit Gateway: | Loại | Nối tới | |---|---| | VPC attachment | VPC | | VPN attachment | Site-to-Site VPN | | Direct Connect Gateway attachment | DX ← câu này | | Peering attachment | TGW ở vùng khác |

Ba đặc điểm của Transit Gateway route table: | Đặc điểm | Chi tiết | |---|---| | Nhiều bảng định tuyến trên một TGW | phân đoạn mạng | | Association: attachment dùng bảng nào | | | Propagation: attachment quảng bá route vào bảng nào | |

Hai khái niệm association và propagation hay bị lẫn:

Association:  "lưu lượng TỪ attachment này tra bảng nào"
Propagation:  "route CỦA attachment này xuất hiện ở bảng nào"
        ↓
    Cấu hình sai một trong hai → gói đi được một chiều

Ba giới hạn cần biết: | Giới hạn | Con số | |---|---| | VPC attachment mỗi TGW | 5.000 | | Băng thông mỗi VPC attachment | ~50 Gbps | | Route mỗi bảng | 10.000 |

Ba lưu ý về Direct Connect Gateway: | Lưu ý | Chi tiết | |---|---| | Toàn cầu — nối VPC ở nhiều vùng | | | KHÔNG cho VPC nói chuyện với nhau qua nó | | | Transit VIF cần DX ≥ 1 Gbps | |

Dòng cuối là ràng buộc kỹ thuật hay bị bỏ sót:

Transit VIF (để nối TGW) yêu cầu kết nối DX từ 1 Gbps trở lên
    → DX 200 Mbps hosted connection KHÔNG dùng transit VIF được
        ↓
    Phải kiểm tra băng thông trước khi thiết kế

Ba lưu ý về AWS RAM: | Lưu ý | Chi tiết | |---|---| | Chia sẻ TGW cho OU hoặc tài khoản | | | Bên nhận phải chấp nhận (trừ trong cùng tổ chức) | | | Chủ sở hữu vẫn quản lý route table | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí theo GIỜ cho mỗi attachment | nhân với số VPC | | Phí theo GB dữ liệu xử lý | | | Vẫn rẻ hơn nhiều DX riêng lẻ | |

Ba việc kiểm chứng: | Việc | Công cụ | |---|---| | Kiểm tra route đã lan chưa | search-transit-gateway-routes | | Thử đường đi | Reachability Analyzer | | Bật TGW Flow Logs | |

aws ec2 search-transit-gateway-routes   --transit-gateway-route-table-id tgw-rtb-abc   --filters "Name=state,Values=active"

Ba mẫu kiến trúc thường gặp: | Mẫu | Chi tiết | |---|---| | Hình sao (hub-and-spoke) | ← câu này | | Phân đoạn theo môi trường | prod và dev bảng riêng | | VPC kiểm tra tập trung | mọi lưu lượng qua firewall |

Và một lời khuyên: hãy dựng bảng định tuyến phân đoạn ngay từ đầu, dù ban đầu chỉ có vài VPC. Chuyển từ một bảng dùng chung sang mô hình phân đoạn khi đã có hàng chục attachment là việc phải làm cẩn thận từng bước để không cắt đứt kết nối đang chạy — còn làm từ đầu thì chỉ là một dòng cấu hình.

Đáp án

C — Amazon EC2 instance store.

Vì sao đúng

Đề nêu bốn dữ kiện, và chỉ instance store thoả cái quan trọng nhất: | Dữ kiện | Ý nghĩa | |---|---| | CSDL phân tán trên nhiều EC2 | | | Dữ liệu ĐÃ nhân bản sang mọi node | mất một máy KHÔNG mất dữ liệu | | Cần lưu trữ KHỐI | loại EFS và S3 | | Độ trễ thấp, tới vài TRIỆU giao dịch/giây mỗi máy | chỉ instance store đạt được |

Vế thứ hai là chìa khoá:

Instance store là ổ NVMe gắn TRỰC TIẾP vào máy chủ vật lý
    → dữ liệu MẤT khi instance dừng hoặc bị chấm dứt
        ↓
    Thường đó là nhược điểm chí mạng
    → nhưng ở đây CSDL đã tự nhân bản
    → mất một node không sao, node mới đồng bộ lại

Vế thứ tư loại EBS: | Loại lưu trữ | IOPS tối đa mỗi volume | |---|---| | gp3 | 16.000 | | io2 Block Express | 256.000 | | Instance store NVMe | hàng TRIỆU |

"several million transactions per second per server"
    → EBS io2 Block Express tối đa 256.000 IOPS
    → còn cách xa hàng triệu
        ↓
    Chỉ ổ NVMe cục bộ mới đạt tới ngưỡng đó

Vì sao instance store nhanh hơn hẳn:

EBS:            EC2 ──── mạng ──── tầng lưu trữ EBS
                → luôn có độ trễ mạng, dù rất nhỏ

Instance store: EC2 ──── bus PCIe ──── ổ NVMe cùng máy
                → không qua mạng
                    ↓
                Độ trễ tính bằng micro giây

Các họ instance có NVMe cục bộ lớn: | Họ | Đặc điểm | |---|---| | i4i, i3en | tối ưu cho I/O — CSDL NoSQL | | im4gn, is4gen | dựa trên Graviton | | d3, d3en | dung lượng lớn (HDD) |

Ba lưu ý khi dùng: | Lưu ý | Chi tiết | |---|---| | Phải format và mount sau khi khởi động | | | Dữ liệu mất khi stop hoặc terminate | | | KHÔNG mất khi reboot | |

Vế thứ ba là chi tiết hay bị nhầm:

Reboot   → dữ liệu instance store CÒN
Stop     → MẤT (máy chuyển sang phần cứng khác khi start lại)
Terminate → MẤT
Hỏng phần cứng → MẤT

Mount trong user data:

#!/bin/bash
mkfs -t xfs /dev/nvme1n1
mkdir -p /var/lib/csdl
mount /dev/nvme1n1 /var/lib/csdl

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

• **B. Amazon EBS — đây là phương án gần nhất và là lựa chọn mặc định đúng cho hầu hết CSDL, nhưng nó không đạt được ngưỡng hiệu năng đề nêu: io2 Block Express tối đa 256.000 IOPS mỗi volume, còn đề đòi hàng triệu giao dịch mỗi giây. Và tính bền vững của EBS ở đây là thừa vì CSDL đã tự nhân bản.
• **A. Amazon EFS — sai loại lưu trữ: EFS là hệ thống tệp qua NFS, không phải lưu trữ khối. Và độ trễ NFS qua mạng cao hơn nhiều bậc so với yêu cầu.
• **D. Amazon S3 — lưu trữ object qua HTTP API, không mount làm ổ đĩa được, và độ trễ tính bằng mili giây. Hoàn toàn không phù hợp cho tầng lưu trữ của một CSDL giao dịch.

Ghi nhớ

Ba loại lưu trữ — bảng phải thuộc: | Loại | Dịch vụ | Giao diện | |---|---|---| | Khối (block) | EBS, instance store | ổ đĩa thô | | Tệp (file) | EFS, FSx | NFS, SMB | | Object | S3 | HTTP API |

Từ khoá nhận diện:

"millions of IOPS", "lowest latency", "data replicated by app" → instance store "persistent block storage", "survives stop" → EBS "shared across instances" → EFS hoặc FSx

EBS và instance store — bảng phân biệt: | | EBS | Instance store | |---|---|---| | Bền vững | ✅ tồn tại độc lập | ❌ mất khi stop | | Hiệu năng | tới 256.000 IOPS | hàng triệu | | Snapshot | ✅ | ❌ | | Gắn lại máy khác | ✅ | ❌ | | Chi phí | tính riêng | đã gồm trong giá instance |

Dòng cuối là lợi ích chi phí ít người để ý — instance store không tính phí thêm.

Bốn loại EBS volume: | Loại | IOPS tối đa | Dùng cho | |---|---|---| | gp3 | 16.000 | mặc định, đa dụng | | io2 Block Express | 256.000 | CSDL đòi hỏi cao | | st1 | thông lượng | log, dữ liệu tuần tự | | sc1 | thấp nhất | lưu trữ nguội |

Ba trường hợp dùng instance store: | Trường hợp | Chi tiết | |---|---| | CSDL phân tán tự nhân bản | Cassandra, MongoDB, Elasticsearch ← câu này | | Cache và dữ liệu tạm | | | Buffer, scratch space cho xử lý | |

Điểm chung: dữ liệu MẤT ĐƯỢC.

Ba câu hỏi phải trả lời trước khi chọn instance store: | Câu hỏi | Nếu "không" thì đừng dùng | |---|---| | Ứng dụng có tự nhân bản dữ liệu không? | | | Mất một node có tự phục hồi không? | | | Có chấp nhận đồng bộ lại khi thay máy không? | |

Ba lưu ý vận hành với CSDL phân tán: | Lưu ý | Chi tiết | |---|---| | Trải node qua nhiều AZ | | | Hệ số nhân bản ≥ 3 | | | Có quy trình thay node tự động | |

Vế thứ ba đáng nói:

Node chết → dữ liệu trên instance store mất hết
    → node mới phải đồng bộ lại TOÀN BỘ từ node khác
        ↓
    Với vài TB dữ liệu, việc này mất hàng giờ
    → và trong lúc đó cụm chạy với ít bản sao hơn
    → phải tính vào kế hoạch năng lực

Ba lưu ý về hiệu năng NVMe: | Lưu ý | Chi tiết | |---|---| | Chạy pre-warm trước khi đo | ổ mới có hiệu năng khác | | Dùng nhiều ổ với RAID 0 nếu cần thêm | | | Chọn filesystem hợp (XFS thường tốt) | |

Ba cách sao lưu khi dùng instance store: | Cách | Chi tiết | |---|---| | Dựa vào nhân bản của chính CSDL | | | Xuất snapshot định kỳ ra S3 | | | Gắn thêm một EBS volume cho backup | |

Vế thứ hai là điều bắt buộc phải có:

Nhân bản bảo vệ khỏi mất MỘT node
    → KHÔNG bảo vệ khỏi xoá nhầm bảng
    → không bảo vệ khỏi lỗi ứng dụng ghi sai dữ liệu
        ↓
    Vẫn phải có bản sao lưu ra S3

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Độ trễ đĩa trong OS | CloudWatch không thấy instance store | | Số node sống trong cụm | | | Tiến độ đồng bộ khi thay node | |

Dòng đầu quan trọng:

CloudWatch KHÔNG có metric cho instance store
    → phải cài CloudWatch Agent lấy từ OS
        ↓
    Khác với EBS vốn có sẵn VolumeReadOps, VolumeWriteOps

Và một lời khuyên: hãy đo thời gian đồng bộ lại một node bằng dữ liệu thật trước khi lên production. Con số đó quyết định bạn cần bao nhiêu bản sao — nếu thay một node mất sáu giờ thì hệ số nhân bản 2 nghĩa là bạn có sáu giờ không còn dự phòng nào, mỗi lần một máy chết.

Đáp án

B — Sinh một presigned URL và đề nghị nhà cung cấp tải tệp về trước khi URL hết hạn.

Vì sao đúng

Đề nêu ba dữ kiện, và presigned URL khớp chính xác: | Dữ kiện | Cách đáp ứng | |---|---| | Chia sẻ MỘT tệp log 5 GB | URL trỏ đúng một object | | Cho một bên NGOÀI tổ chức | không cần tạo danh tính AWS cho họ | | AN TOÀN NHẤT | quyền hẹp nhất, có thời hạn |

Presigned URL hoạt động thế nào:

Bạn (đã có quyền đọc object) ký một URL
    → URL mang chữ ký, thời hạn, và tên object cụ thể
        ↓
    Ai cầm URL đó tải được ĐÚNG object đó
    → hết hạn thì URL vô dụng

Sinh URL:

aws s3 presign s3://kho-log/loi-nang-cap.log --expires-in 3600

import boto3
url = boto3.client('s3').generate_presigned_url(
    'get_object',
    Params={'Bucket': 'kho-log', 'Key': 'loi-nang-cap.log'},
    ExpiresIn=3600)

Vì sao đây là cách an toàn nhất: | Đặc điểm | Chi tiết | |---|---| | Chỉ MỘT object | không thấy gì khác trong bucket | | Chỉ MỘT hành động (GET) | không ghi, không xoá | | Có HẠN | tự vô hiệu | | Không tạo danh tính lâu dài | không có gì để thu hồi sau |

Vế cuối là điểm mạnh lớn nhất:

Tạo IAM user cho nhà cung cấp:
    → phải nhớ xoá sau khi xong việc
    → quên là một danh tính bên ngoài tồn tại mãi
        ↓
Presigned URL:
    → tự hết hạn, không cần dọn dẹp

Ba lưu ý khi đặt thời hạn: | Lưu ý | Chi tiết | |---|---| | Đặt ĐỦ NGẮN nhưng đủ tải xong 5 GB | | | Ký bằng credential tạm thời thì hạn bị cắt theo credential | | | Tối đa 7 ngày khi ký bằng SigV4 | |

Vế thứ hai là bẫy thực tế:

Ký presigned URL từ một EC2 dùng IAM role
    → credential tạm hết hạn sau vài giờ
    → URL cũng chết theo, dù bạn đặt ExpiresIn = 7 ngày
        ↓
    URL trông hợp lệ nhưng trả 403

Ba việc nên làm kèm theo: | Việc | Chi tiết | |---|---| | Bật S3 server access log hoặc CloudTrail data event | biết ai tải, khi nào | | Xoá tệp log sau khi xong việc | | | Đảm bảo bucket vẫn chặn public access | |

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

• **C. Tạo IAM user cho nhà cung cấp với quyền vào bucket, bắt buộc MFA — đây là phương án gần nhất và an toàn hơn hai phương án còn lại, nhưng nó quá rộng và quá lâu dài: bạn cấp một danh tính thường trực vào tài khoản AWS của mình để chia sẻ đúng một tệp một lần. Danh tính đó phải được quản lý, xoay khoá, và nhớ xoá.
• **A. Tạo access key từ tài khoản quản trị rồi đưa cho nhà cung cấp — nguy hiểm nhất trong bốn phương án: đó là cấp toàn quyền quản trị tài khoản AWS cho một bên ngoài, vĩnh viễn cho tới khi bạn xoay khoá.
• **D. Bật mã hoá mặc định và mở public access rồi đưa URL — mã hoá at rest không liên quan gì tới việc kiểm soát truy cập, và mở public access nghĩa là bất kỳ ai trên Internet cũng tải được tệp log chứa thông tin gỡ lỗi.

Ghi nhớ

Bốn cách chia sẻ object S3 — bảng phải thuộc: | Cách | Phạm vi | Thời hạn | |---|---|---| | Presigned URL | một object, một hành động | có hạn ← an toàn nhất cho việc một lần | | Bucket policy | bucket hoặc tiền tố | thường trực | | IAM role + sts:AssumeRole chéo tài khoản | theo policy | phiên có hạn | | Public access | mọi người | thường trực ❌ |

Từ khoá nhận diện:

"share ONE file with an external party temporarily" → presigned URL "another AWS account needs ongoing access" → cross-account role "anyone on the internet" → public — hầu như luôn sai trong đề thi

Ba đặc điểm của presigned URL: | Đặc điểm | Chi tiết | |---|---| | Mang quyền của NGƯỜI KÝ | không phải của người dùng | | Dùng được cho cả GET và PUT | tải lên có kiểm soát | | Không thu hồi được từng URL | phải đổi quyền hoặc xoá object |

Vế đầu là điều phải hiểu rõ:

Người ký không có quyền đọc object
    → URL sinh ra vẫn hợp lệ về hình thức
    → nhưng trả 403 khi dùng
        ↓
    Và ngược lại: người ký có quyền admin
    → URL mang quyền đó cho object cụ thể

Vế thứ ba là hạn chế cần biết:

Lỡ chia sẻ nhầm presigned URL?
    → không có API nào huỷ riêng URL đó
        ↓
    Cách chữa: xoá object, hoặc thu hồi quyền của
    danh tính đã ký (mọi URL nó ký đều chết theo)

Presigned URL cho tải LÊN:

url = s3.generate_presigned_post(
    Bucket='kho-tai-len', Key='nguoi-dung/${filename}',
    Conditions=[['content-length-range', 0, 10485760]],
    ExpiresIn=600)

Cho phép client tải thẳng lên S3
    → không đi qua máy chủ ứng dụng
    → giới hạn kích thước bằng Conditions

Ba giới hạn thời hạn: | Cách ký | Thời hạn tối đa | |---|---| | IAM user credential dài hạn | 7 ngày | | Credential tạm (role, STS) | theo hạn của credential | | Token của IAM Identity Center | thường ngắn hơn |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | URL chứa chữ ký — coi như mật khẩu | đừng gửi qua kênh không mã hoá | | Có thể xuất hiện trong log proxy | | | Đặt hạn ngắn nhất có thể | |

Ba cách theo dõi việc tải: | Cách | Chi tiết | |---|---| | CloudTrail data event cho S3 | ghi từng lần GetObject | | S3 server access log | rẻ hơn, độ trễ cao hơn | | CloudFront log nếu qua CDN | |

aws cloudtrail put-event-selectors --trail-name trail-chinh   --advanced-event-selectors '[{"Name":"Log S3 data events",
    "FieldSelectors":[{"Field":"eventCategory","Equals":["Data"]},
    {"Field":"resources.type","Equals":["AWS::S3::Object"]}]}]'

Ba lưu ý khi chia sẻ tệp lớn: | Lưu ý | Chi tiết | |---|---| | 5 GB tải một lần được | giới hạn PUT một lần là 5 GB | | Đặt hạn đủ cho đường truyền chậm | | | Cân nhắc nén trước | log nén rất tốt |

Vế cuối rất đáng làm:

Log văn bản nén gzip thường còn 10-20% kích thước
    → 5 GB thành khoảng 700 MB
        ↓
    Tải nhanh hơn, hạn ngắn hơn, rẻ hơn

Ba việc nên làm sau khi xong: | Việc | Chi tiết | |---|---| | Xoá tệp log khỏi bucket | | | Kiểm tra CloudTrail xem có ai khác tải không | | | Đặt lifecycle tự xoá log cũ | |

Và một lời khuyên: hãy nén và đặt hạn theo tốc độ mạng thật của bên nhận, đừng mặc định một giờ. Một URL 5 GB hết hạn giữa chừng buộc họ tải lại từ đầu, và bạn sẽ nhận được email xin URL mới vào lúc bạn đang làm việc khác — cùng một tệp, cùng một rủi ro, chỉ thêm một vòng nữa.

Đáp án

A — Áp quy tắc giữ lại (retention rule) cho EBS snapshot trong Recycle Bin, giữ 7 ngày trước khi xoá vĩnh viễn.

Vì sao đúng

Đề nêu ba yêu cầu, và Recycle Bin là tính năng sinh ra đúng cho tình huống này: | Yêu cầu | Cách đáp ứng | |---|---| | Ngăn xoá nhầm | snapshot bị xoá vào thùng rác, khôi phục được | | KHÔNG giữ vô thời hạn | tự xoá vĩnh viễn sau 7 ngày | | ÍT công phát triển nhất | một quy tắc, không viết mã |

Vấn đề thực sự trong đề:

Script dọn dẹp xoá NHẦM toàn bộ snapshot
    → không phải lỗi phân quyền (script được phép xoá)
    → không phải thiếu lịch sao lưu
        ↓
    Vấn đề là: xoá xong KHÔNG lấy lại được
    → cần một mạng an toàn cho thao tác xoá

Recycle Bin làm đúng việc đó:

Snapshot bị xoá
    → KHÔNG biến mất
    → chuyển sang thùng rác, giữ theo thời hạn đã đặt
        ↓
    Trong 7 ngày: khôi phục bằng một lệnh
    Sau 7 ngày: xoá vĩnh viễn tự động

Tạo quy tắc:

aws rbin create-rule --retention-period   RetentionPeriodValue=7,RetentionPeriodUnit=DAYS   --resource-type EBS_SNAPSHOT   --description "Giu snapshot 7 ngay truoc khi xoa han"

Khôi phục snapshot lỡ xoá:

aws rbin list-rules --resource-type EBS_SNAPSHOT
aws ec2 list-snapshots-in-recycle-bin
aws ec2 restore-snapshot-from-recycle-bin --snapshot-id snap-abc123

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không sửa script, không sửa quyền | script vẫn chạy như cũ | | Không giữ vô thời hạn | tránh chi phí tích luỹ | | Áp cho MỌI cách xoá | script, console, hay người dùng |

Vế đầu là lý do đây là "ít công nhất":

Không phải sửa script (dễ sinh lỗi mới)
Không phải đổi IAM policy (có thể chặn nhầm việc hợp lệ)
    → chỉ bật một tính năng ở tầng nền

Lọc theo tag để chỉ bảo vệ snapshot quan trọng:

aws rbin create-rule --retention-period   RetentionPeriodValue=7,RetentionPeriodUnit=DAYS   --resource-type EBS_SNAPSHOT   --resource-tags ResourceTagKey=moi-truong,ResourceTagValue=production

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

• **C. Dùng Data Lifecycle Manager tạo snapshot với quy tắc giữ tự động — đây là phương án gần nhất và là công cụ tốt để QUẢN LÝ vòng đời snapshot, nhưng nó không giải quyết vấn đề đề nêu: DLM quản lý snapshot do chính nó tạo, còn một script bên ngoài vẫn xoá được chúng, và xoá rồi vẫn mất luôn.
• **B. Đổi IAM policy từ chối xoá snapshot cho mọi người — chặn được thao tác xoá, nhưng vi phạm yêu cầu thứ hai: không ai xoá được nghĩa là snapshot tích tụ vô thời hạn, chi phí tăng mãi. Và nó cũng chặn luôn việc dọn dẹp hợp lệ.
• **D. Chép snapshot sang vùng khác hằng ngày kèm chính sách giữ — đây là biện pháp khôi phục thảm hoạ, không phải chống xoá nhầm. Chi phí truyền và lưu trữ nhân đôi, và nếu script cũng chạy ở vùng kia thì vẫn mất.

Ghi nhớ

Ba cơ chế bảo vệ khỏi xoá nhầm — bảng phải thuộc: | Cơ chế | Áp cho | Đặc điểm | |---|---|---| | Recycle Bin | EBS snapshot, AMI | khôi phục trong thời hạn ← câu này | | S3 Versioning + MFA Delete | object S3 | giữ phiên bản cũ | | AWS Backup Vault Lock | bản sao lưu | WORM, không ai xoá được |

Từ khoá nhận diện:

"accidental deletion" + "not retain indefinitely" → Recycle Bin "compliance, nobody can delete" → Backup Vault Lock "automate snapshot creation and retention" → Data Lifecycle Manager

Ba loại tài nguyên Recycle Bin hỗ trợ: | Tài nguyên | Hỗ trợ | |---|---| | EBS snapshot | ✅ | | AMI (EBS-backed) | ✅ | | RDS snapshot | ❌ (dùng cơ chế khác) |

Hai kiểu quy tắc: | Kiểu | Phạm vi | |---|---| | Region-level (mọi tài nguyên) | tất cả snapshot trong vùng | | Tag-level | chỉ snapshot có tag khớp |

Ba đặc điểm quan trọng: | Đặc điểm | Chi tiết | |---|---| | Thời hạn giữ: 1 ngày tới 1 năm | | | Snapshot trong thùng rác VẪN TÍNH PHÍ lưu trữ | | | Khôi phục xong thì trở lại bình thường | |

Vế thứ hai là điều phải cân nhắc:

Thùng rác không miễn phí
    → giữ 7 ngày nghĩa là trả thêm tối đa 7 ngày lưu trữ
        ↓
    Đặt thời hạn theo thời gian THỰC TẾ để phát hiện sự cố
    → 7 ngày thường là đủ; 1 năm là lãng phí

Ba lưu ý về AMI trong Recycle Bin: | Lưu ý | Chi tiết | |---|---| | AMI bị xoá vào thùng rác ở trạng thái disabled | | | Snapshot nền của AMI cũng được giữ | | | Khôi phục AMI phải bật lại (enable-image) | |

Ba việc nên làm cùng lúc: | Việc | Chi tiết | |---|---| | Sửa script dùng bộ lọc chặt chẽ hơn | | | Chạy script ở chế độ thử trước | in ra thay vì xoá | | Gắn tag giu-lai cho snapshot quan trọng | |

Vế thứ hai đáng làm ngay:

# Chế độ thử: chỉ in ra danh sách sẽ xoá
aws ec2 describe-snapshots --owner-ids self   --query "Snapshots[?StartTime<'$NGUONG'].[SnapshotId,StartTime,Description]"   --output table

Chạy vài ngày ở chế độ in ra
    → đọc kỹ danh sách
    → rồi mới bật xoá thật

Ba nguyên nhân script dọn dẹp xoá nhầm: | Nguyên nhân | Chi tiết | |---|---| | Bộ lọc ngày sai định dạng | so chuỗi thay vì so ngày | | Truy vấn trả rỗng → xoá tất cả | | | Quên lọc theo tag hoặc chủ sở hữu | |

Dòng thứ hai là mẫu lỗi kinh điển:

# NGUY HIỂM: nếu biến rỗng, câu lệnh xoá mọi thứ
for s in $(aws ec2 describe-snapshots --filters "$BOLOC" ...); do
    aws ec2 delete-snapshot --snapshot-id "$s"
done

$BOLOC rỗng → describe trả về TẤT CẢ snapshot
    → vòng lặp xoá sạch
        ↓
    Luôn kiểm tra biến lọc không rỗng trước khi chạy

Ba lưu ý về Data Lifecycle Manager (để phân biệt): | Lưu ý | Chi tiết | |---|---| | Tự TẠO snapshot theo lịch | | | Tự XOÁ theo số lượng hoặc tuổi | | | Chọn tài nguyên theo tag | |

DLM và Recycle Bin bổ sung cho nhau:

DLM:          tự động tạo và dọn snapshot đúng cách
Recycle Bin:  mạng an toàn khi có gì đó xoá sai
        ↓
    Dùng cả hai là kiến trúc đầy đủ

Ba lưu ý về chi phí snapshot: | Khoản | Chi tiết | |---|---| | Tính theo dữ liệu THAY ĐỔI (incremental) | | | Xoá snapshot cũ không giảm nhiều như tưởng | | | Archive tier rẻ hơn cho snapshot giữ lâu | |

Vế thứ hai hay gây bất ngờ:

Snapshot là incremental
    → xoá snapshot giữa chuỗi, dữ liệu của nó
      được giữ lại cho các snapshot sau
        ↓
    Chi phí không giảm tương ứng với số snapshot đã xoá

Và một lời khuyên: hãy kiểm tra ngay hôm nay xem script dọn dẹp của bạn xử lý trường hợp truy vấn trả về rỗng thế nào. Gần như mọi sự cố xoá hàng loạt đều bắt đầu từ một bộ lọc không khớp gì cả — và một dòng kiểm tra "nếu danh sách rỗng thì thoát" ngăn được đúng loại tai nạn mà Recycle Bin phải đi dọn.

Đáp án

D — Dùng Amazon Aurora Serverless v2, bật tự co giãn và cấu hình sao lưu tự động giữ 7 ngày.

Vì sao đúng

Đề nêu năm yêu cầu, và Aurora Serverless v2 khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Dữ liệu CÓ CẤU TRÚC | CSDL quan hệ | | GIAO DỊCH giữa dữ liệu liên quan | ACID, khoá ngoại, JOIN | | Co giãn động cho đợt tăng KHÔNG ĐOÁN ĐƯỢC | tự co giãn theo giây | | Sao lưu tự động | có sẵn, khôi phục theo thời điểm | | Ít công vận hành, tiết kiệm nhất | được quản lý hoàn toàn |

Hai từ khoá quyết định:

"transactions between related data"
    → cần khoá ngoại, JOIN, ACID nhiều bảng
    → CSDL QUAN HỆ, không phải NoSQL

"unpredictable traffic spikes"
    → không đoán trước để cấp phát
    → co giãn tự động, trả theo mức dùng
        ↓
    Giao của hai điều kiện = Aurora Serverless v2

Cấu hình:

aws rds create-db-cluster --db-cluster-identifier ung-dung-the-thao   --engine aurora-postgresql --engine-mode provisioned   --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=32   --backup-retention-period 7 --storage-encrypted

aws rds create-db-instance --db-instance-identifier writer-1   --db-cluster-identifier ung-dung-the-thao   --db-instance-class db.serverless --engine aurora-postgresql

ACU co giãn thế nào:

1 ACU ≈ 2 GB RAM + CPU tương ứng
    → tăng giảm theo bước 0,5 ACU
    → phản ứng trong VÀI GIÂY
        ↓
    Giờ cao điểm: lên 20 ACU
    Đêm khuya:    xuống 0,5 ACU
    → trả tiền theo mức đang dùng, tính theo giây

Sao lưu tự động của Aurora: | Đặc điểm | Chi tiết | |---|---| | Liên tục, ghi vào S3 | | | Khôi phục về BẤT KỲ giây nào trong khoảng giữ | | | Không ảnh hưởng hiệu năng | |

Vế thứ ba là điều đặc biệt của Aurora:

RDS truyền thống: chụp snapshot có thể gây độ trễ I/O
Aurora:           sao lưu ở tầng lưu trữ phân tán
        ↓
    Sao lưu liên tục mà không ảnh hưởng CSDL

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

• **B. Dùng DynamoDB on-demand với Point-in-Time Recovery — đây là phương án gần nhất về khả năng co giãn và chi phí, và PITR đúng là sao lưu tự động, nhưng nó thất bại ở yêu cầu giao dịch: DynamoDB có transaction nhưng giới hạn 100 item mỗi lần và không có JOIN hay khoá ngoại. Đề nói rõ "structured data" và "transactions between related data".
• **C. RDS MySQL Multi-AZ với provisioned IOPS — chạy được nhưng không co giãn theo tải: instance cố định, provisioned IOPS trả tiền cho mức cao nhất 24/7. Và "sao lưu tự động vào Glacier Flexible Retrieval" không phải cách RDS hoạt động — sao lưu tự động do RDS quản lý, không chọn lớp lưu trữ được.
• **A. CSDL mã nguồn mở trên EC2 Spot trong ASG — Spot bị thu hồi với 2 phút báo trước, hoàn toàn không phù hợp cho tầng CSDL. Và tự quản lý CSDL trên EC2 là công vận hành cao nhất trong bốn phương án.

Ghi nhớ

Quy trình chọn CSDL — ba câu hỏi theo thứ tự: | Câu hỏi | Nếu có | |---|---| | 1. Cần JOIN, khoá ngoại, giao dịch nhiều bảng? | → quan hệ | | 2. Tải biến động không đoán được? | → Serverless | | 3. Cần đọc toàn cầu độ trễ thấp? | → global database |

Từ khoá nhận diện:

"relational" + "unpredictable spikes" → Aurora Serverless v2 "key-value", "millions of requests", "single-digit ms" → DynamoDB "steady predictable workload" → RDS provisioned + Reserved Instance

⚠ Bảng phân biệt Aurora Serverless v1 và v2: | | v1 | v2 | |---|---|---| | Bước co giãn | nhân đôi | 0,5 ACU | | Tốc độ | chục giây | vài giây | | Về 0 khi rảnh | ✅ (có khởi động lạnh) | tối thiểu 0,5 ACU | | Read replica | ❌ | ✅ | | Multi-AZ | hạn chế | ✅ | | Global database | ❌ | ✅ |

Với ứng dụng phục vụ người dùng thật, v2 là lựa chọn đúng — v1 có khởi động lạnh hàng chục giây.

Ba đặc điểm sao lưu của Aurora: | Đặc điểm | Chi tiết | |---|---| | Retention 1-35 ngày | | | PITR về bất kỳ giây nào | | | Backtrack (chỉ Aurora MySQL): tua ngược tại chỗ | |

Backtrack đáng biết vì nó rất nhanh:

PITR:      tạo cụm MỚI từ bản sao lưu → mất nhiều phút
Backtrack: TUA NGƯỢC chính cụm đang chạy → vài giây tới phút
        ↓
    Hữu ích khi lỡ chạy một câu UPDATE sai

Ba tham số cần đặt đúng: | Tham số | Lưu ý | |---|---| | MinCapacity | đủ giữ cache nóng | | MaxCapacity | trần chi phí và hiệu năng | | backup-retention-period | 7 ngày theo đề |

MinCapacity quá thấp gây vấn đề thật:

Min 0,5 ACU → khoảng 1 GB RAM cho buffer pool
    → truy vấn đọc từ đĩa nhiều
    → chậm cho tới khi co giãn kịp
        ↓
    Đặt min đủ chứa tập dữ liệu nóng

Ba cách tối ưu chi phí thêm: | Cách | Chi tiết | |---|---| | Aurora I/O-Optimized | nếu I/O > 25% hoá đơn | | RDS Proxy gộp kết nối | giảm ACU cần thiết | | Reader riêng cho truy vấn nặng | |

Ba lưu ý về Aurora I/O-Optimized: | Lưu ý | Chi tiết | |---|---| | Giá ACU và lưu trữ cao hơn | | | KHÔNG tính phí I/O | | | Đổi qua lại được mỗi 30 ngày | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ServerlessDatabaseCapacity | ACU thực dùng | | ACUUtilization | có chạm trần không | | DatabaseConnections | |

Ba lưu ý về tải nặng đọc: | Lưu ý | Chi tiết | |---|---| | Thêm reader instance | co giãn độc lập | | Dùng reader endpoint | cân bằng tự động | | Cân nhắc ElastiCache cho dữ liệu nóng | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá at rest lúc TẠO | không bật sau được | | Đặt trong subnet riêng tư | | | Dùng Secrets Manager cho mật khẩu | có xoay tự động |

Ba việc nên làm sau một tháng chạy: | Việc | Chi tiết | |---|---| | Xem đồ thị ACU thật | điều chỉnh min/max | | So chi phí với provisioned tương đương | | | Bật Performance Insights tìm truy vấn nặng | |

Và một lời khuyên: hãy đặt MaxCapacity ở mức bạn thực sự sẵn sàng trả tiền, chứ không phải mức cao nhất có thể. Serverless co giãn để cứu bạn khỏi đợt tăng tải, nhưng một truy vấn viết sai gây quét toàn bảng cũng đẩy ACU lên trần — và trần đó chính là hoá đơn của bạn cuối tháng.

Đáp án

D — Sửa Auto Scaling group để dùng bốn instance ở mỗi trong hai Availability Zone.

Vì sao đúng

Đề nêu ba ràng buộc, và chỉ một phương án thoả cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | Tám máy web trong MỘT AZ | điểm hỏng đơn lẻ | | Cần tính sẵn sàng cao | trải qua nhiều AZ | | KHÔNG sửa ứng dụng | chỉ đổi hạ tầng |

Điểm hỏng nằm ở đâu:

Trước:  ALB → ASG 8 máy → tất cả trong AZ-a
            ↓
    AZ-a hỏng → 0 máy sống → ứng dụng chết

Sau:    ALB → ASG 8 máy → 4 ở AZ-a, 4 ở AZ-b
            ↓
    AZ-a hỏng → còn 4 máy → ứng dụng vẫn phục vụ

Sửa bằng một lệnh, giữ nguyên tổng số máy:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-web   --vpc-zone-identifier "subnet-az-a,subnet-az-b"   --min-size 8 --desired-capacity 8 --max-size 16

Và ALB phải bật ở cả hai AZ:

aws elbv2 set-subnets --load-balancer-arn <arn>   --subnets subnet-pub-a subnet-pub-b

Ba đặc điểm: | Đặc điểm | Chi tiết | |---|---| | Chi phí KHÔNG tăng | vẫn 8 máy | | Không đụng tới mã ứng dụng | | | ASG tự cân bằng lại giữa các AZ | |

Vế đầu đáng nhấn mạnh: đây là cải thiện tính sẵn sàng miễn phí — chỉ trải cùng số máy ra rộng hơn.

Nhưng có một điều cần tính:

Mất một trong hai AZ = mất 50% năng lực
    → 8 máy còn 4
        ↓
    Nếu 8 máy là mức cần thiết cho tải đỉnh
    → phải để max-size đủ cao để ASG bù lại
    → hoặc dùng BA AZ (mất 1 chỉ còn thiếu 33%)

Vì sao ba AZ tốt hơn hai: | Số AZ | Mất 1 AZ còn | Dự phòng cần | |---|---|---| | 2 AZ | 50% | +100% | | 3 AZ | 67% | +50% |

Đề chỉ đưa lựa chọn hai AZ, nhưng trong thực tế ba AZ là khuyến nghị của AWS.

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

• **B. ASG dùng bốn instance ở mỗi trong hai SUBNET — đây là phương án gần nhất và rất dễ chọn nhầm, nhưng hai subnet có thể nằm trong CÙNG một AZ. Subnet là cấu trúc logic; chỉ khi hai subnet ở hai AZ khác nhau mới có dự phòng. Phương án D nói rõ "Availability Zones", nên nó chính xác còn B thì không đảm bảo gì.
• **A. ASG dùng bốn instance ở mỗi trong hai Region — một ASG không trải qua nhiều vùng được. Phải dựng hai bộ hạ tầng riêng cộng Route 53, phức tạp hơn nhiều mức đề cần.
• **C. Tạo launch template để tạo nhanh máy ở vùng khác — đây là khôi phục thủ công, không phải tính sẵn sàng cao. Vẫn có thời gian ngừng khi AZ hỏng, và cần người can thiệp.

Ghi nhớ

Ba tầng dự phòng — bảng phải thuộc: | Tầng | Bảo vệ khỏi | Công | |---|---|---| | Nhiều AZ trong một Region | hỏng một trung tâm dữ liệu | thấp ← câu này | | Nhiều Region | thảm hoạ cả vùng | cao | | Nhiều tài khoản | sự cố quản trị | cao |

Từ khoá nhận diện:

"single Availability Zone" + "highly available" → trải nhiều AZ "no modifications to the application" → chỉ đổi hạ tầng "Region-wide outage" → mới cần đa Region

⚠ Phân biệt subnet và AZ — chính là bẫy của câu này: | Khái niệm | Quan hệ | |---|---| | Availability Zone | một hoặc nhiều trung tâm dữ liệu riêng biệt | | Subnet | thuộc ĐÚNG MỘT AZ | | Quan hệ | một AZ có thể chứa NHIỀU subnet |

"Hai subnet" KHÔNG đảm bảo "hai AZ"
    → hai subnet trong cùng AZ-a vẫn cùng chết
        ↓
    Đây là lý do B sai còn D đúng

Kiểm tra subnet thuộc AZ nào:

aws ec2 describe-subnets   --query "Subnets[].[SubnetId,AvailabilityZone,CidrBlock]" --output table

Ba yêu cầu để ASG đa AZ chạy đúng: | Yêu cầu | Chi tiết | |---|---| | Mỗi AZ có subnet riêng | | | ALB bật ở cùng các AZ | | | Ứng dụng không giữ trạng thái cục bộ | |

Vế thứ ba là chỗ hay gãy:

Session lưu trong bộ nhớ máy
    → người dùng bị chuyển máy → mất đăng nhập
        ↓
    Chuyển session sang ElastiCache hoặc DynamoDB
    → hoặc bật sticky session (giải pháp tạm)

Ba loại health check của ASG: | Loại | Kiểm tra | |---|---| | EC2 (mặc định) | chỉ trạng thái máy | | ELB | ứng dụng có trả lời không | | Custom | qua API |

aws autoscaling update-auto-scaling-group --auto-scaling-group-name asg-web   --health-check-type ELB --health-check-grace-period 300

Vì sao phải đổi sang ELB:

Kiểu EC2: ứng dụng treo mà máy vẫn "running"
    → ASG không thay máy
    → ALB vẫn gửi request tới máy hỏng
        ↓
    Kiểu ELB mới phát hiện được

Ba đặc điểm của AZRebalance: | Đặc điểm | Chi tiết | |---|---| | Tự cân lại khi phân bố lệch | | | Khởi động máy MỚI trước khi tắt máy cũ | | | Có thể tạm vượt desired capacity | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Trải máy ra nhiều AZ: MIỄN PHÍ | | | ALB cross-zone: KHÔNG tính phí | NLB thì có | | Lưu lượng giữa AZ của ứng dụng: có phí | |

Ba tầng cần kiểm tra, không chỉ tầng web: | Tầng | Cách làm đa AZ | |---|---| | Web / ứng dụng | ASG + ALB đa AZ | | CSDL | RDS Multi-AZ hoặc Aurora | | NAT Gateway | một cái mỗi AZ |

Vế cuối hay bị bỏ sót:

NAT Gateway chỉ ở AZ-a
    → AZ-a hỏng → máy ở AZ-b mất đường ra Internet
        ↓
    Tầng web sống nhưng không gọi được API bên ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem phân bố instance theo AZ | describe-auto-scaling-groups | | Tắt hết máy một AZ, xem còn phục vụ không | | | Kiểm tra session còn giữ được không | |

aws autoscaling describe-auto-scaling-groups   --auto-scaling-group-names asg-web   --query "AutoScalingGroups[0].Instances[].[InstanceId,AvailabilityZone,HealthStatus]"   --output table

Và một lời khuyên: hãy kiểm tra describe-subnets trước khi tin rằng mình đã đa AZ. Rất nhiều VPC được dựng nhanh có hai, ba subnet đều nằm trong cùng một AZ — sơ đồ kiến trúc trông hoàn toàn đúng, và điều đó chỉ lộ ra vào ngày AZ đó gặp sự cố.

Đáp án

C — Cấu hình CloudFront distribution cho S3 bucket để tăng tốc tải xuống, và bật S3 Transfer Acceleration để tăng tốc tải lên.

Vì sao đúng

Đề nêu hai chiều lưu lượng, và mỗi chiều có công cụ riêng: | Chiều | Công cụ | Cơ chế | |---|---|---| | Tải XUỐNG (xem video) | CloudFront | cache ở edge gần người dùng | | Tải LÊN (đăng video) | S3 Transfer Acceleration | đi qua mạng xương sống AWS |

Vì sao CloudFront không giải quyết được việc tải lên:

CloudFront là mạng phân phối nội dung — tối ưu cho ĐỌC
    → cache bản sao ở edge
        ↓
    Tải lên không có gì để cache
    → mỗi tệp là duy nhất, đi thẳng về origin

S3 Transfer Acceleration làm gì:

Không có TA:  client ──── Internet công cộng ────▶ S3 bucket
              → qua nhiều nhà mạng, độ trễ và mất gói cao

Có TA:        client ──▶ edge location gần nhất
                        │
                        └── mạng XƯƠNG SỐNG AWS ──▶ S3 bucket
              → chặng dài đi trên mạng riêng của AWS

Bật Transfer Acceleration:

aws s3api put-bucket-accelerate-configuration   --bucket video-toan-cau --accelerate-configuration Status=Enabled

Rồi dùng endpoint riêng:

Bình thường:  video-toan-cau.s3.ap-southeast-1.amazonaws.com
Tăng tốc:     video-toan-cau.s3-accelerate.amazonaws.com

import boto3
from botocore.config import Config
s3 = boto3.client('s3', config=Config(s3={'use_accelerate_endpoint': True}))
s3.upload_file('video.mp4', 'video-toan-cau', 'nguoi-dung/video.mp4')

CloudFront cho chiều tải xuống:

aws cloudfront create-distribution --origin-domain-name   video-toan-cau.s3.ap-southeast-1.amazonaws.com   --default-root-object index.html

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đổi kiến trúc | vẫn một bucket, một vùng | | Hai chiều đều nhanh hơn | | | Bật bằng cấu hình, không viết mã | |

Vế đầu là lý do đây là "ít công nhất":

Không nhân bản bucket
Không đổi ứng dụng (chỉ đổi endpoint)
Không dựng máy chủ nào
    ↓
    Hai thao tác cấu hình

Công cụ đo hiệu quả của Transfer Acceleration:

AWS cung cấp công cụ so sánh tốc độ tại
s3-accelerate-speedtest.s3-accelerate.amazonaws.com
    → cho biết TA nhanh hơn bao nhiêu phần trăm từ vị trí của bạn
        ↓
    Nếu không nhanh hơn thì AWS KHÔNG TÍNH PHÍ lần truyền đó

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

• **D. CloudFront cho tải xuống, dùng CloudFront cho cả tải lên, và nhân bản bucket sang nhiều vùng — đây là phương án gần nhất về mặt cải thiện cả hai chiều, nhưng nó phức tạp hơn nhiều lần: phải quản lý nhiều bucket, nhiều quy tắc nhân bản, và tự viết logic chuyển hướng người dùng tới bucket gần nhất. Đề đòi "LEAST implementation effort".
• **A. Dùng Global Accelerator cho S3 bucket — Global Accelerator không hỗ trợ S3 làm endpoint. Nó nhắm tới ALB, NLB, EC2 và Elastic IP. Với S3, công cụ tương đương là Transfer Acceleration.
• **B. Chuyển sang EC2 ở nhiều vùng với ALB và Global Accelerator — thay đổi kiến trúc lớn nhất: bỏ static website trên S3 để tự vận hành máy chủ ở nhiều vùng. Ngược hẳn yêu cầu về công triển khai.

Ghi nhớ

Ba dịch vụ tăng tốc của AWS — bảng phải thuộc: | Dịch vụ | Tối ưu cho | Endpoint | |---|---|---| | CloudFront | ĐỌC nội dung tĩnh (cache) | tên miền phân phối | | S3 Transfer Acceleration | GHI vào S3 từ xa | s3-accelerate | | Global Accelerator | TCP/UDP tới ALB, NLB, EC2 | 2 IP tĩnh anycast |

Từ khoá nhận diện:

"slow uploads to S3 from around the world" → Transfer Acceleration "slow downloads / static content" → CloudFront "non-HTTP protocol", "static IP", "fast regional failover" → Global Accelerator

⚠ Global Accelerator KHÔNG hỗ trợ S3 — đây là điểm khiến phương án A sai.

CloudFront và Global Accelerator — bảng phân biệt: | | CloudFront | Global Accelerator | |---|---|---| | Có cache | ✅ | ❌ | | Giao thức | HTTP/HTTPS | TCP và UDP | | IP | thay đổi | 2 IP tĩnh anycast | | Chuyển vùng khi hỏng | qua origin group | rất nhanh (không phụ thuộc DNS) |

Ba đặc điểm của S3 Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Dùng chính mạng edge của CloudFront | | | Chỉ tính phí khi THỰC SỰ nhanh hơn | | | Tên bucket không được chứa dấu chấm | |

Vế thứ ba là ràng buộc kỹ thuật:

Bucket tên "video.cong-ty.com"
    → KHÔNG bật Transfer Acceleration được
        ↓
    Vì endpoint tăng tốc dùng chứng chỉ wildcard
    → dấu chấm trong tên phá vỡ việc khớp tên miền

Ba trường hợp Transfer Acceleration đáng dùng: | Trường hợp | Chi tiết | |---|---| | Người dùng ở xa vùng chứa bucket | ← câu này | | Tệp lớn, thường xuyên | | | Đường truyền qua nhiều nhà mạng | |

Và trường hợp KHÔNG đáng:

Người dùng ở cùng vùng với bucket
    → TA không giúp gì, thậm chí chậm hơn một chút
        ↓
    Dùng công cụ so tốc độ để kiểm chứng trước

Ba cách tối ưu tải lên khác: | Cách | Chi tiết | |---|---| | Multipart upload | chia tệp lớn, tải song song | | Presigned URL | client tải thẳng, không qua máy chủ | | CloudFront với PUT | có hỗ trợ nhưng không tối ưu bằng TA |

Multipart upload đáng bật cho video:

from boto3.s3.transfer import TransferConfig
cau_hinh = TransferConfig(multipart_threshold=8*1024*1024,
                          max_concurrency=10,
                          multipart_chunksize=8*1024*1024)
s3.upload_file('video.mp4', 'video-toan-cau', 'v/1.mp4', Config=cau_hinh)

Ba lưu ý cho CloudFront với video: | Lưu ý | Chi tiết | |---|---| | Dùng OAC (không phải OAI đã cũ) | | | Bật range request cho tua video | | | Đặt TTL dài — video không đổi | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | TA tính phí thêm mỗi GB tải lên | | | CloudFront rẻ hơn S3 trực tiếp cho tải xuống | S3 → CloudFront miễn phí | | Chọn price class hợp với phân bố khách | |

Dòng thứ hai là điều nhiều người không biết:

Data transfer từ S3 SANG CloudFront: MIỄN PHÍ
    → phục vụ qua CloudFront thường RẺ HƠN
      phục vụ thẳng từ S3

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Tỷ lệ cache hit của CloudFront | thấp là cấu hình sai | | BytesUploaded của S3 | | | Thời gian tải lên trung bình phía client | |

Ba lỗi làm hỏng tỷ lệ cache hit: | Lỗi | Hậu quả | |---|---| | Forward mọi cookie | mỗi khách một bản cache | | Forward mọi query string | ?t=123 tách cache | | TTL quá ngắn | |

Và một lời khuyên: hãy chạy công cụ so tốc độ của S3 Transfer Acceleration từ các khu vực có nhiều người dùng trước khi bật nó. TA tính phí theo GB và chỉ đáng tiền khi thực sự nhanh hơn — với người dùng gần vùng chứa bucket, bạn sẽ trả thêm cho một cải thiện bằng không.

Đáp án

A — Cấu hình AWS Storage Gateway file gateway.

Vì sao đúng

Đề nêu ba dữ kiện, và file gateway khớp cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | File share trên Windows Server dùng NAS | file gateway xuất SMB | | Cần GIẢM diện tích trung tâm dữ liệu | dữ liệu chuyển lên S3 | | Giảm chi phí lưu trữ | S3 rẻ hơn NAS, có lifecycle |

Vì sao file gateway chứ không phải chép thẳng lên S3:

Chép thẳng lên S3:
    → người dùng Windows mất file share quen thuộc
    → phải đổi cách làm việc, đổi ứng dụng
        ↓
File gateway:
    → vẫn là một share SMB như cũ
    → phía sau là S3
    → người dùng không biết gì đã thay đổi

Cấu hình:

aws storagegateway create-smb-file-share   --client-token $(uuidgen) --gateway-arn <arn-gateway>   --location-arn arn:aws:s3:::kho-tai-lieu   --role <arn-role> --authentication ActiveDirectory   --default-storage-class S3_STANDARD_IA

Và lifecycle giảm chi phí thêm:

{"Rules": [{"ID":"giam-chi-phi","Status":"Enabled","Filter":{},
  "Transitions":[
    {"Days":90,"StorageClass":"GLACIER_IR"},
    {"Days":365,"StorageClass":"DEEP_ARCHIVE"}]}]}

Ba lợi ích cho mục tiêu của đề: | Lợi ích | Chi tiết | |---|---| | Chỉ giữ cache tại chỗ, không giữ toàn bộ | giảm phần cứng | | Dung lượng S3 gần như vô hạn | hết lo chạm trần | | Mỗi tệp là object S3 bình thường | dùng được lifecycle |

Vế đầu là cách đề đáp ứng "giảm diện tích trung tâm dữ liệu":

NAS vài TB → thay bằng một máy ảo gateway với đĩa cache vài trăm GB
    → gỡ bỏ tủ đĩa NAS
        ↓
    Diện tích, điện, làm mát đều giảm

Và tệp nóng vẫn nhanh:

Tệp trong cache  → tốc độ mạng LAN
Tệp không trong cache → tải từ S3 khi mở
        ↓
    Người dùng thường chỉ đụng tới tệp gần đây

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

• **D. Cấu hình Storage Gateway ở chế độ volume gateway — đây là phương án gần nhất vì cũng là Storage Gateway và cũng đẩy dữ liệu lên AWS, nhưng nó sai giao diện: volume gateway xuất iSCSI (khối), còn đây là một file share SMB. Và dữ liệu volume gateway lưu dạng snapshot EBS, không phải object S3 đọc trực tiếp được.
• **B. Tạo S3 bucket và gateway endpoint — gateway endpoint dùng để tài nguyên trong VPC truy cập S3 mà không qua Internet. Nó không cho máy chủ tại chỗ mount một file share, và không có cache.
• **C. Tạo EFS và dùng IPsec VPN — EFS dùng NFS (Linux), không phải SMB cho Windows, không nối được Active Directory, và NFS qua VPN Internet có độ trễ rất cao. EFS cũng đắt hơn S3 nhiều lần.

Ghi nhớ

Bốn chế độ Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Dùng cho | |---|---|---| | S3 File Gateway | NFS, SMB | file share lên S3 ← câu này | | FSx File Gateway | SMB | truy cập FSx for Windows từ tại chỗ | | Volume Gateway | iSCSI (khối) | ổ đĩa | | Tape Gateway | iSCSI VTL | thay băng từ |

Từ khoá nhận diện:

"Windows file share", "SMB", "reduce data center footprint" → S3 File Gateway "block storage", "iSCSI" → Volume Gateway "full SMB features, Windows-native" → FSx for Windows File Server

⚠ Phân biệt File Gateway và FSx for Windows — hai câu trả lời rất khác nhau: | | S3 File Gateway | FSx for Windows | |---|---|---| | Dữ liệu nằm ở | S3 (object) | hệ thống tệp Windows thật | | Chạy ở đâu | tại chỗ (có cache) | trên AWS | | Mục đích | đẩy dữ liệu lên đám mây | thay thế file server | | Chi phí lưu trữ | rẻ (S3) | cao hơn |

Đề nói "giảm diện tích trung tâm dữ liệu VÀ giảm chi phí lưu trữ"
    → File Gateway đưa dữ liệu sang S3 (rẻ nhất)
    → còn giữ được truy cập tại chỗ có cache

Ba cách triển khai gateway: | Cách | Khi nào | |---|---| | Máy ảo (VMware, Hyper-V, KVM) | có sẵn 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 đặc điểm của SMB file share: | Đặc điểm | Chi tiết | |---|---| | Nối được Active Directory | dùng lại phân quyền hiện có | | Hoặc dùng người dùng khách | đơn giản hơn | | Hỗ trợ ACL của Windows | |

Vế đầu quan trọng cho môi trường doanh nghiệp — người dùng đăng nhập bằng chính tài khoản AD đang có.

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

Vế đầu là lợi thế lớn:

Tệp thành object S3 bình thường
    → dùng được lifecycle, replication, Athena, Macie
        ↓
    Volume Gateway thì dữ liệu chỉ đọc được qua gateway

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 RefreshCache | | CacheStaleTimeoutInSeconds tự làm mới | | | Nhiều gateway cùng bucket dễ xung đột | |

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

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

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

Ba bước di chuyển dữ liệu ban đầu: | Bước | Việc | |---|---| | Dựng gateway, tạo SMB share | | | Dùng robocopy hoặc DataSync chép từ NAS sang share | | | Chuyển người dùng sang share mới rồi gỡ NAS | |

robocopy \\nas-cu\tailieu \\gateway\tailieu /E /COPYALL /R:1 /W:1 /MT:32

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ S3 theo lớp | | | Phí gateway theo lượng dữ liệu ghi | | | Phí lấy dữ liệu khi cache miss với lớp IA | |

Dòng cuối đáng cân nhắc:

Đặt lớp mặc định Standard-IA cho rẻ
    → nhưng mỗi cache miss phải trả phí lấy dữ liệu
        ↓
    Nếu người dùng hay mở lại tệp cũ,
    S3 Standard rồi lifecycle sau 90 ngày lại rẻ hơn

Ba việc kiểm chứng sau khi chuyển: | Việc | Cách | |---|---| | Ghi tệp qua share, xem nó lên S3 chưa | | | Kiểm tra phân quyền AD còn đúng không | | | Đo thời gian mở tệp cũ | |

Và một lời khuyên: hãy giữ NAS cũ ở chế độ chỉ đọc thêm vài tuần sau khi chuyển. Việc so sánh số tệp và tổng dung lượng chỉ cho biết dữ liệu đã sang đủ; điều bạn thực sự cần biết là phân quyền có sang đúng không — và chuyện đó chỉ lộ ra khi ai đó mở một thư mục mà lẽ ra họ không được vào.

Đáp án

A — Chuyển file share sang Amazon FSx for Windows File Server.

Vì sao đúng

Đề nêu bốn dữ kiện, và FSx for Windows là lựa chọn duy nhất khớp hết: | Dữ kiện | Cách đáp ứng | |---|---| | Máy chủ web chạy Windows | FSx for Windows dùng SMB — giao thức gốc của Windows | | EC2 Windows ở NHIỀU AZ | FSx Multi-AZ | | Thay thế NAS file share | FSx là hệ thống tệp thật | | BỀN VỮNG và CHỊU LỖI NHẤT | Multi-AZ + sao lưu tự động |

Vì sao SMB là ràng buộc quyết định:

Máy chủ Windows mount file share qua SMB
    → EFS chỉ hỗ trợ NFS
    → dùng NFS trên Windows là con đường đầy khổ sở
        ↓
    FSx for Windows nói đúng ngôn ngữ của Windows

Tạo FSx Multi-AZ:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 500 --storage-type SSD   --subnet-ids subnet-az-a subnet-az-b   --windows-configuration     'DeploymentType=MULTI_AZ_1,PreferredSubnetId=subnet-az-a,
     ThroughputCapacity=32,ActiveDirectoryId=d-1234567890,
     AutomaticBackupRetentionDays=30'

Multi-AZ hoạt động thế nào:

AZ-a: file server chính  ──sao chép đồng bộ──▶  AZ-b: standby
        ↓
    AZ-a hỏng → FSx tự chuyển sang standby
    → tên DNS giữ nguyên
    → máy chủ web không cần đổi gì

Mount từ máy chủ web:

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

Ba lý do đây là lựa chọn bền vững nhất: | Lý do | Chi tiết | |---|---| | Sao chép đồng bộ giữa hai AZ | | | Sao lưu hằng ngày tự động, giữ tới 90 ngày | | | AWS lo vá lỗi và bảo trì | |

Ba tính năng Windows gốc mà FSx giữ nguyên: | Tính năng | Chi tiết | |---|---| | ACL của Windows và tích hợp AD | | | Shadow Copies (Previous Versions) | người dùng tự khôi phục tệp | | Deduplication và quota | |

Shadow Copies đáng bật:

Set-FSxShadowStorage -Default
Set-FSxShadowCopySchedule -Default

Người dùng chuột phải vào tệp → "Restore previous versions"
    → tự khôi phục bản cũ mà không cần gọi IT

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

• **C. Chuyển sang Amazon EFS — đây là phương án gần nhất vì cũng là hệ thống tệp chia sẻ, đa AZ, rất bền, nhưng nó dùng NFS chứ không phải SMB. Với máy chủ Windows, đó là sai giao thức: mất tích hợp Active Directory, mất ACL Windows, và cần cấu hình phức tạp mới mount được.
• **B. Chuyển sang AWS Storage Gateway — Storage Gateway là cầu nối cho hạ tầng TẠI CHỖ, nhưng ở đây máy chủ web đã nằm trên AWS. Đặt một gateway giữa EC2 và S3 là thêm một tầng vô ích, thêm một điểm hỏng, và kém bền hơn FSx Multi-AZ.
• **D. Chuyển sang Amazon EBS — EBS gắn vào một instance tại một thời điểm, không chia sẻ được cho nhiều máy chủ web ở nhiều AZ. Và một EBS volume nằm trong đúng một AZ.

Ghi nhớ

Bốn dịch vụ FSx — bảng phải thuộc: | Dịch vụ | Giao thức | Dùng cho | |---|---|---| | FSx for Windows File Server | SMB | Windows, AD, ACL ← câu này | | FSx for Lustre | Lustre | HPC, ML, thông lượng cực cao | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức | | FSx for OpenZFS | NFS | di chuyển từ ZFS |

Từ khoá nhận diện:

"Windows", "SMB", "Active Directory" → FSx for Windows "Linux", "NFS", "POSIX" → EFS "HPC", "parallel", "hundreds of GB/s" → FSx for Lustre "on-premises servers need cloud storage" → Storage Gateway

Hai chế độ triển khai FSx for Windows: | Chế độ | Đặc điểm | SLA | |---|---|---| | Single-AZ | rẻ hơn, một AZ | 99,9% | | Multi-AZ | standby ở AZ khác, tự chuyển | 99,99% ← đề cần |

Ba yêu cầu để dựng FSx for Windows: | Yêu cầu | Chi tiết | |---|---| | Active Directory | AWS Managed AD hoặc AD tự quản | | Subnet ở hai AZ (Multi-AZ) | | | Security group mở cổng SMB (445) và AD | |

Vế đầu là ràng buộc bắt buộc:

FSx for Windows PHẢI nối vào một Active Directory
    → không có AD thì không tạo được file system
        ↓
    Chưa có AD: dùng AWS Managed Microsoft AD
    Đã có AD tại chỗ: nối qua DX/VPN, hoặc dùng AD Connector

Ba loại lưu trữ FSx: | Loại | Đặc điểm | |---|---| | SSD | độ trễ thấp, cho tải nóng | | HDD | rẻ hơn, cho dữ liệu nguội | | — | đổi từ HDD sang SSD được |

Ba lưu ý về throughput capacity: | Lưu ý | Chi tiết | |---|---| | Đặt theo tải thật, tăng giảm được | | | Ảnh hưởng cả IOPS và băng thông | | | Tăng throughput có thời gian gián đoạn ngắn | |

Ba đặc điểm sao lưu: | Đặc điểm | Chi tiết | |---|---| | Tự động hằng ngày, giữ 0-90 ngày | | | Sao lưu thủ công giữ vô thời hạn | | | Lưu trong S3 do AWS quản lý | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Multi-AZ có độ trễ ghi cao hơn Single-AZ | sao chép đồng bộ | | Bật deduplication tiết kiệm nhiều | tệp Windows trùng nhiều | | DFS Namespaces gộp nhiều file system | vượt giới hạn dung lượng |

Bật deduplication:

Enable-FSxDedup -FileSystemPath \\amznfsxabc.corp.vidu.com\share

Tệp Office, cài đặt phần mềm, ảnh máy ảo trùng lặp nhiều
    → thường tiết kiệm 50-60% dung lượng

Ba cách di chuyển dữ liệu từ NAS: | Cách | Khi nào | |---|---| | AWS DataSync | lượng lớn, giữ ACL | | robocopy /COPYALL | lượng nhỏ, kiểm soát chi tiết | | Snowball | lượng rất lớn, mạng kém |

DataSync là lựa chọn tốt nhất vì nó giữ được metadata NTFS:

aws datasync create-task --source-location-arn <nas>   --destination-location-arn <fsx>   --options '{"PreserveDeletedFiles":"PRESERVE","SecurityDescriptorCopyFlags":"OWNER_DACL_SACL"}'

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Multi-AZ đắt gần gấp đôi Single-AZ | | | Throughput capacity tính riêng | | | Deduplication giảm chi phí lưu trữ thật | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mount từ máy chủ ở cả hai AZ | | | Kiểm tra ACL còn đúng sau khi chép | | | Ép chuyển đổi dự phòng để đo thời gian | |

Và một lời khuyên: hãy kiểm tra quyền NTFS trên một mẫu thư mục nhạy cảm ngay sau khi chép xong, đừng chỉ so số tệp. Công cụ nào cũng báo "đã chép đủ", nhưng nếu cờ giữ security descriptor không được bật thì mọi thư mục sẽ kế thừa quyền của thư mục gốc — và một file share mà ai cũng đọc được là một sự cố im lặng.

Đáp án

D — Tạo Auto Scaling group từ AMI của ứng dụng, dùng launch template cấu hình co giãn theo CPU utilization, và gắn Application Load Balancer phân phối lưu lượng.

Vì sao đúng

Đề nêu bốn dữ kiện, và ASG + ALB giải quyết đúng từng cái: | Dữ kiện | Cách đáp ứng | |---|---| | Một EC2 On-Demand duy nhất | điểm hỏng đơn lẻ + trần năng lực | | Ứng dụng KHÔNG GIỮ TRẠNG THÁI | co giãn ngang được ngay | | Lỗi 5xx khi tải cao | thêm máy khi CPU tăng | | Tiết kiệm nhất | bớt máy khi tải giảm |

Vế thứ hai là điều làm phương án này khả thi:

Ứng dụng stateless
    → mọi máy xử lý được mọi request
    → không cần session affinity
        ↓
    Đây là điều kiện lý tưởng cho co giãn ngang

Vì sao co giãn NGANG chứ không phải DỌC:

Dọc (đổi sang máy to hơn):
    → có trần cứng (loại instance lớn nhất)
    → phải KHỞI ĐỘNG LẠI để đổi
    → vẫn một điểm hỏng
        ↓
Ngang (thêm máy):
    → gần như không có trần
    → không gián đoạn
    → nhiều máy = chịu được hỏng một máy

Cấu hình:

aws ec2 create-launch-template --launch-template-name mau-ung-dung   --launch-template-data '{"ImageId":"ami-abc123","InstanceType":"t3.medium",
    "IamInstanceProfile":{"Name":"vai-tro-ung-dung"}}'

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-xu-ly   --launch-template LaunchTemplateName=mau-ung-dung,Version='$Latest'   --min-size 2 --max-size 20 --desired-capacity 2   --vpc-zone-identifier "subnet-a,subnet-b,subnet-c"   --target-group-arns <arn-target-group> --health-check-type ELB

Chính sách co giãn theo CPU:

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

Vì sao đây là phương án tiết kiệm nhất: | Lý do | Chi tiết | |---|---| | Chỉ trả cho số máy đang cần | tải thấp thì ít máy | | Không giữ máy dự phòng chạy không | | | Không phải viết lại ứng dụng | |

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

• **A. Tạo AMI rồi triển khai hai máy On-Demand cố định sau ALB — đây là phương án gần nhất và giải quyết được điểm hỏng đơn lẻ, nhưng nó không co giãn: hai máy là con số cố định, đợt tăng lớn hơn vẫn gây lỗi 5xx, còn lúc rảnh vẫn trả tiền cho cả hai. Đề đòi "scale AUTOMATICALLY".
• **B. Tăng kích thước instance theo lịch và dùng Route 53 phân phối sang máy ở vùng khác — co giãn dọc theo lịch không hợp với đợt tăng đột biến không đoán trước, và một instance ở vùng khác là kiến trúc phức tạp mà không giải quyết được vấn đề năng lực.
• **C. Viết lại thành serverless bằng Lambda + SQS + DynamoDB — kiến trúc này rất tốt về lâu dài, nhưng đề hỏi cách xử lý vấn đề hiện tại: đây là viết lại toàn bộ ứng dụng, công sức lớn nhất trong bốn phương án và có rủi ro cao.

Ghi nhớ

Hai kiểu co giãn — bảng phải thuộc: | Kiểu | Cách làm | Trần | |---|---|---| | Ngang (scale out/in) | thêm/bớt MÁY | gần như không ← ưu tiên | | Dọc (scale up/down) | đổi máy to/nhỏ hơn | loại instance lớn nhất |

Từ khoá nhận diện:

"stateless" + "traffic spikes" + "cost-effective" → ASG + ALB "single instance at 100% CPU" → cần co giãn "scale vertically" → khi ứng dụng KHÔNG chạy song song được

Ba thành phần bắt buộc của giải pháp: | Thành phần | Việc | |---|---| | AMI hoặc launch template | định nghĩa máy trông thế nào | | Auto Scaling group | quyết định có bao nhiêu máy | | Application Load Balancer | phân phối request |

⚠ Launch template thay thế launch configuration: | | Launch template | Launch configuration | |---|---|---| | Trạng thái | hiện hành | AWS không còn khuyến nghị | | Phiên bản | ✅ có versioning | ❌ bất biến | | Mixed instance policy | ✅ | ❌ | | Spot + On-Demand trộn | ✅ | ❌ |

Bốn kiểu chính sách co giãn: | Kiểu | Khi nào | |---|---| | Target tracking | mặc định nên dùng | | Step scaling | cần kiểm soát từng bậc | | Simple scaling | kiểu cũ | | Scheduled | tải biết trước |

Ba metric hay dùng để co giãn: | Metric | Phù hợp khi | |---|---| | ASGAverageCPUUtilization | tải nặng CPU ← câu này | | ALBRequestCountPerTarget | phản ứng nhanh hơn CPU | | ApproximateNumberOfMessagesVisible | có hàng đợi SQS |

Metric thứ hai đáng cân nhắc hơn:

CPU là chỉ báo TRỄ — lên tới ngưỡng thì người dùng đã chờ rồi
Số request trên mỗi target tăng NGAY khi lưu lượng tăng
        ↓
    Với ứng dụng web, request-per-target thường tốt hơn

Ba tham số quan trọng: | Tham số | Lưu ý | |---|---| | min-size | đủ chịu tải nền và dự phòng AZ | | max-size | trần chi phí, đặt đủ cao | | health-check-type ELB | không dùng EC2 |

Vế cuối đáng nhắc lại:

Health check kiểu EC2 chỉ xem máy có chạy không
    → ứng dụng treo mà máy vẫn "running"
    → ASG không thay, ALB vẫn gửi request → 5xx tiếp tục
        ↓
    Kiểu ELB mới thấy được ứng dụng hỏng

Ba cách giảm chi phí thêm: | Cách | Chi tiết | |---|---| | Mixed instance policy với Spot | rẻ tới 70-90% | | Savings Plans cho phần tải nền | | | Right-size loại instance | Compute Optimizer gợi ý |

Chiến lược trộn Spot và On-Demand:

{"MixedInstancesPolicy": {
  "InstancesDistribution": {
    "OnDemandBaseCapacity": 2,
    "OnDemandPercentageAboveBaseCapacity": 20,
    "SpotAllocationStrategy": "price-capacity-optimized"},
  "LaunchTemplate": {"Overrides": [
    {"InstanceType":"t3.medium"},{"InstanceType":"t3a.medium"},
    {"InstanceType":"t2.medium"}]}}}

2 máy On-Demand làm nền, phần tăng thêm 80% dùng Spot
    → ứng dụng stateless nên chịu được Spot bị thu hồi
        ↓
    Đây là cách tiết kiệm nhất cho đúng bài này

Ba lưu ý về thời gian phản ứng: | Lưu ý | Chi tiết | |---|---| | AMI có sẵn ứng dụng — đừng cài lúc khởi động | | | health-check-grace-period đủ cho khởi động | | | Warm pool nếu khởi động chậm | |

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Trải qua các AZ giống ASG | | | Health check trỏ đúng đường dẫn nhẹ | | | Deregistration delay hợp lý | |

Ba metric theo dõi sau khi triển khai: | Metric | Ý nghĩa | |---|---| | HTTPCode_Target_5XX_Count | lỗi còn không | | TargetResponseTime | trải nghiệm thật | | GroupInServiceInstances | ASG có phản ứng không |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử tải để xem ASG có scale không | | | Chấm dứt một máy, xem ASG thay không | | | Kiểm tra ứng dụng thật sự stateless | |

Và một lời khuyên: hãy kiểm chứng "stateless" bằng cách tắt một máy giữa lúc có người đang dùng, đừng chỉ tin vào mô tả. Rất nhiều ứng dụng được gọi là không giữ trạng thái vẫn ghi tệp tạm hoặc giữ session trong bộ nhớ — và điều đó chỉ lộ ra khi Auto Scaling bắt đầu thay máy.