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

Đáp án

A — Tạo read replica có CÙNG năng lực tính toán và CÙNG dung lượng lưu trữ với primary, trỏ truy vấn báo cáo vào replica.

Vì sao đúng

Đề nêu vấn đề rõ: báo cáo phân tích làm chậm database, và yêu cầu tối ưu chi phí.

Nguyên nhân: hai loại tải cạnh tranh cùng một instance
    → truy vấn phân tích quét nhiều dữ liệu, chiếm CPU và I/O
    → truy vấn giao dịch bị chậm theo
        ↓
    Tách chúng ra hai instance

Và vì sao phải CÙNG năng lực:

Truy vấn phân tích là loại NẶNG nhất
    → quét nhiều bảng, tổng hợp, sắp xếp
        ↓
    Replica nhỏ hơn một nửa:
        → báo cáo chạy chậm hơn
        → và replica có thể TỤT LẠI trong việc sao chép
        → dữ liệu báo cáo ngày càng cũ

Và dung lượng lưu trữ BẮT BUỘC bằng nhau:

Read replica chứa BẢN SAO ĐẦY ĐỦ của database
    → không thể chỉ chứa một nửa dữ liệu
        ↓
    RDS KHÔNG cho tạo replica có dung lượng nhỏ hơn primary
    → đây là ràng buộc kỹ thuật, không phải lựa chọn

Điểm này khiến hai phương án "nửa dung lượng" sai về mặt kỹ thuật, không chỉ về hiệu năng.

Tạo replica:

aws rds create-db-instance-read-replica   --db-instance-identifier replica-bao-cao   --source-db-instance-identifier db-thuong-mai   --db-instance-class db.r6g.xlarge

Và replica có parameter group riêng:

aws rds modify-db-instance --db-instance-identifier replica-bao-cao   --db-parameter-group-name pg-phan-tich --apply-immediately

Tối ưu riêng cho truy vấn phân tích:
    → tăng bộ nhớ sắp xếp và join
    → không ảnh hưởng primary

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

• **C. Read replica với NỬA năng lực tính toán và NỬA dung lượng — đây là phương án gần nhất và nghe hợp lý về mặt tiết kiệm, nhưng nó không làm được: RDS không cho phép replica có dung lượng lưu trữ nhỏ hơn primary, vì replica phải chứa toàn bộ dữ liệu.
• **D. Standby trong cấu hình Multi-AZ với cùng năng lực, chạy báo cáo trên standby — sai về mặt kỹ thuật: standby của Multi-AZ KHÔNG phục vụ bất kỳ lưu lượng nào. Nó chỉ chờ để chuyển đổi.
• **B. Standby Multi-AZ nửa năng lực — cùng hai lỗi: standby không đọc được, và Multi-AZ standby luôn cùng cấu hình với primary.

Ghi nhớ

Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Standby/replica phục vụ đọc | ❌ | ✅ | | Chuyển đổi | TỰ ĐỘNG | thủ công (promote) | | Cấu hình | luôn giống primary | chọn cỡ instance riêng được |

Dòng thứ ba là điểm mà hai phương án standby hiểu sai.

Ba ràng buộc của read replica: | Ràng buộc | Chi tiết | |---|---| | Dung lượng lưu trữ ≥ primary | không nhỏ hơn được | | Cỡ instance chọn riêng được | nhưng nên tương đương | | CHỈ ĐỌC | không ghi được |

Ba lý do nên để replica cùng cỡ với primary: | Lý do | Chi tiết | |---|---| | Truy vấn phân tích nặng hơn truy vấn giao dịch | | | Replica nhỏ dễ TỤT LẠI trong sao chép | dữ liệu báo cáo cũ | | Promote được khi cần | nếu primary hỏng |

Dòng giữa đáng chú ý:

Replica phải áp DỤNG MỌI thay đổi của primary
    → replica yếu hơn không theo kịp
    → ReplicaLag tăng dần
        ↓
    Và tải phân tích còn làm nó chậm thêm

Ba số replica tối đa: | Engine | Số replica | |---|---| | RDS MySQL, MariaDB, PostgreSQL | 15 | | Aurora | 15 | | SQL Server | 5 (cần Enterprise Edition) |

Ba trường hợp dùng read replica: | Trường hợp | Chi tiết | |---|---| | Tách tải phân tích | ← câu này | | Mở rộng năng lực đọc | | | Khôi phục thảm hoạ (cross-Region) | |

Ba lưu ý về độ trễ sao chép: | Lưu ý | Chi tiết | |---|---| | Theo dõi ReplicaLag | | | Truy vấn nặng trên replica làm tăng độ trễ | | | Báo cáo thường chấp nhận dữ liệu cũ vài giây | |

Ba lựa chọn khác cho tải phân tích: | Lựa chọn | Khi nào | |---|---| | Read replica | ← câu này, đơn giản nhất | | Amazon Redshift | phân tích quy mô lớn, truy vấn phức tạp | | S3 + Athena | dữ liệu lịch sử |

Redshift đáng cân nhắc nếu tải phân tích lớn:

MySQL tối ưu cho GIAO DỊCH (OLTP)
    → truy vấn quét hàng triệu dòng chạy chậm
        ↓
    Redshift lưu theo CỘT, nén, xử lý song song
    → nhanh hơn hàng chục lần

Và Zero-ETL bỏ hẳn đường ống:

Aurora MySQL → Redshift (zero-ETL integration)
    → dữ liệu tự đồng bộ gần thời gian thực
    → KHÔNG cần DMS hay Glue

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicaLag | replica tụt lại bao xa | | CPUUtilization của primary | xác nhận đã giảm | | ReadIOPS của replica | tải phân tích thật |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Replica tính phí như instance đầy đủ | | | Cùng Region: KHÔNG tốn phí truyền dữ liệu | | | Reserved Instance áp được cho replica | |

Ba việc cần làm sau khi tạo replica: | Việc | Chi tiết | |---|---| | Xác nhận ứng dụng báo cáo đã đổi endpoint | | | Đo CPU của primary trước và sau | | | Đặt alarm cho ReplicaLag | |

Và một lời khuyên: hãy kiểm tra CPUUtilization của primary sau một tuần. Nếu con số không giảm, nghĩa là ứng dụng báo cáo vẫn còn kết nối nào đó trỏ về primary — lỗi rất dễ xảy ra khi hệ thống có nhiều nơi khai chuỗi kết nối.

Đáp án

B, D và E.

• E — Auto Scaling group trải hai AZ với min=1, max=1, desired=1
• B — Tạo Elastic IP và dùng user data script gắn nó vào instance
• D — Gán IAM instance role để thực hiện các lời gọi API cần thiết

Vì sao đúng

Đề nêu ràng buộc rõ: ứng dụng nguyên khối, CHỈ chạy trên MỘT máy chủ, nhưng vẫn muốn tự phục hồi khi mất một AZ.

E — ASG với min=max=desired=1 là mẫu chuẩn cho việc này:

Một instance duy nhất, nhưng ASG trải qua HAI AZ
    → AZ chứa instance hỏng
    → ASG tự khởi động instance mới ở AZ CÒN LẠI
        ↓
    Tự phục hồi mà vẫn giữ đúng MỘT máy

B — Elastic IP giữ địa chỉ không đổi:

Instance mới có IP công cộng MỚI
    → người dùng và DNS trỏ tới địa chỉ cũ
        ↓
    User data gắn lại Elastic IP vào instance mới
    → địa chỉ không đổi qua mỗi lần thay máy

#!/bin/bash
ID=$(curl -s -H "X-aws-ec2-metadata-token: $(curl -sX PUT   http://169.254.169.254/latest/api/token   -H 'X-aws-ec2-metadata-token-ttl-seconds: 60')"   http://169.254.169.254/latest/meta-data/instance-id)
aws ec2 associate-address --instance-id "$ID"   --allocation-id eipalloc-0abc --region ap-northeast-1

D — IAM role là điều kiện để script đó chạy được:

Lệnh associate-address cần quyền ec2:AssociateAddress
    → KHÔNG dùng access key cứng trong script
        ↓
    Gán instance profile với quyền tối thiểu

{"Effect": "Allow",
 "Action": ["ec2:AssociateAddress", "ec2:DescribeAddresses"],
 "Resource": "*"}

Ba đáp án phối hợp thành một cơ chế hoàn chỉnh:

E: ASG phát hiện và thay máy
B: script gắn lại địa chỉ
D: quyền để script làm được việc đó
        ↓
    Thiếu bất kỳ mảnh nào là cơ chế không hoạt động

Và vì sao đây là "cost-efficient nhất":

Một instance duy nhất
    + KHÔNG có load balancer (tiết kiệm ~18 USD/tháng)
        ↓
    Đúng yêu cầu tối ưu chi phí

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

• **C. Tạo Application Load Balancer và target group với instance của ASG — đây là phương án gần nhất và hoạt động được, nhưng nó thêm chi phí không cần thiết: với đúng một instance, ALB chỉ làm nhiệm vụ định tuyến chứ không cân bằng gì, mà tốn ~18 USD/tháng cộng phí LCU. Elastic IP rẻ hơn nhiều.
• **F. ASG với min=1, max=2, desired=2 — vi phạm ràng buộc cốt lõi: đề nói ứng dụng không chạy được ở chế độ phân tán, nên hai instance cùng chạy sẽ gây lỗi dữ liệu.
• **A. Tạo Spot Fleet request — sai loại tải: ứng dụng nguyên khối quan trọng không chịu được việc bị thu hồi bất ngờ.

Ghi nhớ

Mẫu "ASG một instance" — rất đáng nhớ:

min = max = desired = 1, trải nhiều AZ
    ↓
Không phải để CO GIÃN
    → mà để TỰ PHỤC HỒI khi mất máy hoặc mất AZ
        ↓
    Đây là cách rẻ nhất để có tự phục hồi

Ba cách giữ địa chỉ không đổi khi thay máy: | Cách | Chi phí | |---|---| | Elastic IP + user data gắn lại | ~3,6 USD/tháng ← câu này | | Load balancer | ~18 USD/tháng trở lên | | Route 53 cập nhật bản ghi bằng script | ~0,5 USD/tháng + phí truy vấn |

Cách thứ ba cũng dùng được:

aws route53 change-resource-record-sets --hosted-zone-id Z1ABC   --change-batch '{"Changes":[{"Action":"UPSERT",
    "ResourceRecordSet":{"Name":"app.vidu.com","Type":"A","TTL":60,
      "ResourceRecords":[{"Value":"'"$IP"'"}]}}]}'

Nhưng phụ thuộc TTL của DNS — Elastic IP chuyển ngay lập tức.

Ba loại IP của EC2 — nhắc lại: | Loại | Đặc điểm | |---|---| | IP riêng | luôn có | | IPv4 công cộng tự động | thu hồi khi stop/start hoặc thay máy | | Elastic IP | tĩnh, gắn lại được |

Ba cấu hình ASG quan trọng cho mẫu này: | Cấu hình | Chi tiết | |---|---| | vpc-zone-identifier nhiều subnet ở nhiều AZ | | | HealthCheckType = EC2 (không có ELB) | | | HealthCheckGracePeriod đủ dài | chờ user data chạy xong |

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-monolith   --launch-template LaunchTemplateName=lt-monolith,Version='$Latest'   --min-size 1 --max-size 1 --desired-capacity 1   --vpc-zone-identifier "subnet-az-a,subnet-az-c"   --health-check-type EC2 --health-check-grace-period 300

Ba lưu ý về dữ liệu với mẫu này: | Lưu ý | Chi tiết | |---|---| | Dữ liệu KHÔNG được nằm trên đĩa cục bộ | máy mới là đĩa trống | | Dùng EFS cho tệp chia sẻ | trải nhiều AZ | | Dùng RDS Multi-AZ cho database | |

Đây là điểm quan trọng nhất về mặt thiết kế:

ASG thay máy → EBS root volume MỚI
    → mọi thứ ghi trên đĩa cục bộ MẤT
        ↓
    Dữ liệu phải nằm ở EFS, S3, hoặc RDS

Ba lựa chọn cho lưu trữ bền vững: | Lựa chọn | Phù hợp | |---|---| | EFS | tệp chia sẻ, trải nhiều AZ | | S3 | object, rẻ nhất | | RDS Multi-AZ | database |

Ba nội dung nên có trong user data: | Nội dung | Chi tiết | |---|---| | Gắn Elastic IP | ← đáp án B | | Mount EFS | | | Khởi động ứng dụng | |

Ba lưu ý về IAM instance role: | Lưu ý | Chi tiết | |---|---| | KHÔNG dùng access key trong user data | user data đọc được từ metadata | | Quyền tối thiểu | chỉ AssociateAddress | | Giới hạn theo Elastic IP cụ thể nếu được | |

Ba lưu ý về thời gian phục hồi: | Yếu tố | Thời gian | |---|---| | ASG phát hiện máy hỏng | ~2 phút | | Khởi động instance mới | ~1 phút | | User data + khởi động ứng dụng | tuỳ ứng dụng |

Rút ngắn bằng golden AMI:

Nướng ứng dụng và cấu hình vào AMI
    → user data chỉ còn gắn EIP và mount EFS
        ↓
    Thời gian phục hồi giảm đáng kể

Ba lưu ý về giới hạn của mẫu này: | Giới hạn | Chi tiết | |---|---| | CÓ thời gian ngừng khi thay máy | vài phút | | Không phải sẵn sàng cao thật sự | là tự phục hồi | | Chấp nhận được với ứng dụng không phân tán | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | GroupInServiceInstances | phải luôn bằng 1 | | StatusCheckFailed | máy hỏng | | Lịch sử hoạt động của ASG | mỗi lần thay máy |

Và một lời khuyên: hãy thử chấm dứt instance thủ công một lần để đo thời gian phục hồi thật. Cơ chế này chỉ chứng minh được khi chạy thử — và con số bạn đo được là RTO thực tế cần ghi vào tài liệu vận hành, chứ không phải con số ước lượng.

Đáp án

A và D.

• A — Dùng CloudFront signed URL
• D — Dùng CloudFront signed cookie

Vì sao đúng

Đề yêu cầu chỉ giao nội dung cho người đăng ký dịch vụ, và CloudFront có đúng hai cơ chế cho việc này.

Signed URL và signed cookie:
    → nội dung chỉ truy cập được khi có chữ ký hợp lệ
    → chữ ký có HẠN, và ràng buộc được theo IP
        ↓
    Người không đăng ký không tạo được chữ ký
    → và URL bị chia sẻ cũng hết hạn nhanh

Chọn giữa hai cơ chế: | | Signed URL | Signed cookie | |---|---|---| | Phạm vi | MỘT tệp | NHIỀU tệp | | Phù hợp | tải một video cụ thể | cả thư viện nội dung | | Đổi URL gốc | có | không | | Client không hỗ trợ cookie | ✅ dùng được | ❌ |

Với nền tảng streaming, signed cookie thường tiện hơn:

Người dùng đăng nhập
    → server cấp signed cookie
    → mọi tệp video, phụ đề, ảnh bìa đều truy cập được
        ↓
    Không phải ký lại từng URL

Tạo signed URL:

from botocore.signers import CloudFrontSigner
import rsa, datetime

def ky(message):
    return rsa.sign(message, khoa_rieng, 'SHA-1')

signer = CloudFrontSigner('K2ABCDEFG', ky)
url = signer.generate_presigned_url(
    'https://d123.cloudfront.net/video/phim.m3u8',
    date_less_than=datetime.datetime.now() + datetime.timedelta(hours=2))

Và custom policy cho phép ràng buộc thêm:

{"Statement": [{
  "Resource": "https://d123.cloudfront.net/thu-vien/*",
  "Condition": {
    "DateLessThan": {"AWS:EpochTime": 1725000000},
    "IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}}}]}

Và phải chặn truy cập thẳng vào origin:

Không chặn:
    → người dùng gọi thẳng URL của S3
    → BỎ QUA hoàn toàn cơ chế chữ ký
        ↓
    Dùng Origin Access Control (OAC) + Block Public Access

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

• **B. Bắt buộc HTTPS giữa CloudFront và custom origin — đây là phương án gần nhất vì cũng là biện pháp bảo mật thật, nhưng nó bảo vệ dữ liệu TRÊN ĐƯỜNG TRUYỀN, không kiểm soát ai được xem. Người không đăng ký vẫn tải được nội dung, chỉ là qua kênh mã hoá.
• **C. Bắt buộc HTTPS giữa CloudFront và S3 origin — cùng lý do, và với S3 thì CloudFront vốn đã dùng HTTPS.
• **E. Chuyển tiếp request HTTPS tới origin bằng ECDSA hoặc RSA cipher — cũng chỉ là chi tiết về mã hoá đường truyền, không liên quan tới kiểm soát truy cập.

Ghi nhớ

Ba cơ chế bảo vệ nội dung của CloudFront — bảng phải thuộc: | Cơ chế | Kiểm soát | |---|---| | Signed URL | truy cập MỘT tệp, có hạn | | Signed cookie | truy cập NHIỀU tệp, có hạn | | Geo restriction | chặn theo quốc gia | | Origin Access Control | chặn truy cập thẳng vào origin |

Từ khoá nhận diện:

"restrict content to subscribers", "paid users only" → signed URL hoặc signed cookie "block by country" → geo restriction "prevent direct S3 access" → OAC

Ba thành phần để dùng signed URL: | Thành phần | Chi tiết | |---|---| | Key pair (public và private) | tạo bằng OpenSSL | | Public key upload lên CloudFront | nhận key ID | | Key group gắn vào cache behavior | |

openssl genrsa -out khoa-rieng.pem 2048
openssl rsa -pubout -in khoa-rieng.pem -out khoa-cong-khai.pem

aws cloudfront create-public-key --public-key-config   '{"CallerReference":"key1","Name":"khoa-ky","EncodedKey":"..."}'
aws cloudfront create-key-group --key-group-config   '{"Name":"nhom-khoa","Items":["K2ABCDEFG"]}'

Hai loại policy: | Loại | Đặc điểm | |---|---| | Canned policy | chỉ có ngày hết hạn — URL ngắn hơn | | Custom policy | thêm IP, ngày bắt đầu, wildcard trong đường dẫn |

Custom policy cần cho signed cookie theo thư mục — canned policy không dùng wildcard được.

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Khoá riêng KHÔNG bao giờ gửi ra client | ký ở server | | Đặt hạn ngắn | vài phút tới vài giờ | | Ràng buộc IP nếu được | nhưng cẩn thận với mạng di động |

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

Ràng buộc IP với người dùng di động
    → IP đổi khi chuyển mạng
    → phiên xem bị đứt giữa chừng
        ↓
    Với streaming, thường KHÔNG ràng buộc IP

Ba lưu ý khi dùng cho video streaming: | Lưu ý | Chi tiết | |---|---| | HLS/DASH gồm nhiều segment | signed cookie tiện hơn signed URL | | Hạn phải dài hơn thời lượng video | | | Cân nhắc gia hạn cookie giữa chừng | |

Ba cơ chế bảo vệ khác cho nội dung số: | Cơ chế | Chi tiết | |---|---| | Signed URL/cookie | ← câu này | | DRM (qua AWS Elemental MediaPackage) | mã hoá nội dung thật | | Token authentication ở tầng ứng dụng | |

Ba lưu ý về OAC: | Lưu ý | Chi tiết | |---|---| | Thay thế OAI (legacy) | hỗ trợ SSE-KMS | | Bucket giữ Block Public Access | | | Bucket policy cho service principal cloudfront.amazonaws.com | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | 4xxErrorRate | chữ ký sai hoặc hết hạn | | CacheHitRate | hiệu quả đệm | | Access log | ai xem gì |

Ba lưu ý về caching với signed URL: | Lưu ý | Chi tiết | |---|---| | CloudFront đệm theo đường dẫn, KHÔNG theo chữ ký | | | Nên đệm bình thường | chữ ký chỉ kiểm ở edge | | Đừng đưa query string chữ ký vào cache key | |

Dòng đầu là hành vi quan trọng:

Hai người dùng khác nhau, hai chữ ký khác nhau
    → nhưng cùng đường dẫn tệp
        ↓
    CloudFront phục vụ CÙNG bản đệm
    → chữ ký chỉ quyết định CÓ ĐƯỢC PHỤC VỤ hay không

Và một lời khuyên: hãy dùng signed cookie cho nền tảng streaming thay vì signed URL. Một video HLS gồm hàng trăm segment, và ký từng URL segment vừa tốn tài nguyên vừa làm hỏng bộ phát chuẩn — cookie ký một lần cho cả phiên xem là cách duy nhất thực dụng.

Đáp án

A — Lifecycle chuyển sang S3 Standard-Infrequent Access sau 30 ngày, xoá đúng 4 năm sau khi tạo.

Vì sao đúng

Đề nêu bốn ràng buộc, và Standard-IA thoả cả bốn: | Ràng buộc | Kết luận | |---|---| | Truy cập nhiều 30 ngày đầu, giảm hẳn sau đó | chuyển sang IA sau 30 ngày | | Phải LẤY ĐƯỢC NGAY khi cần | loại Glacier Flexible Retrieval | | Dữ liệu quan trọng, cần độ bền cao | loại One Zone-IA | | Giữ đúng 4 năm rồi xoá | expiration 1.460 ngày |

Ràng buộc thứ hai loại Glacier Flexible:

"must remain IMMEDIATELY RETRIEVABLE"
        ↓
    Glacier Flexible Retrieval: 1 phút – 12 giờ
    → KHÔNG tức thì

Ràng buộc thứ ba loại One Zone-IA:

One Zone-IA lưu ở CHỈ MỘT AZ
    → AZ đó mất là MẤT DỮ LIỆU
        ↓
    Dữ liệu thí nghiệm có yêu cầu tuân thủ 4 năm
    → rủi ro không chấp nhận được

Và tệp 10 MB đủ lớn để chuyển sang IA:

Object dưới 128 KB KHÔNG được lifecycle chuyển sang IA
    → 10 MB không vướng giới hạn này

Quy tắc lifecycle:

{"Rules": [{
  "ID": "chuyen-ia-va-xoa-sau-4-nam",
  "Status": "Enabled",
  "Filter": {},
  "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}],
  "Expiration": {"Days": 1460}}]}

Phép tính tiết kiệm với 100 TB:

S3 Standard suốt 4 năm:  ~2.300 USD/tháng
Chuyển sang IA sau 30 ngày: ~1.250 USD/tháng
        ↓
    Tiết kiệm khoảng 46%

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

• **B. Chuyển sang Glacier Instant Retrieval sau 30 ngày — đây là phương án gần nhất và cũng lấy được tức thì (mili giây), nhưng nó phù hợp với mẫu truy cập HIẾM HƠN: GIR có phí truy xuất cao gấp ba lần Standard-IA và thời gian lưu tối thiểu 90 ngày. Với dữ liệu "vẫn được truy cập khi cần", IA an toàn hơn về chi phí.
• **D. Chuyển sang Glacier Flexible Retrieval — vi phạm yêu cầu lấy ngay: mất từ một phút tới 12 giờ.
• **C. Chuyển sang One Zone-IA — rủi ro độ bền: dữ liệu chỉ nằm ở một AZ.

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

Ranh giới giữa Standard-IA và Glacier Instant Retrieval trong câu này khá mỏng, và đáng phân tích kỹ.

Điểm hoà vốn:
    Nếu đọc lại DƯỚI ~13% dữ liệu mỗi tháng → GIR rẻ hơn
    Nếu đọc lại NHIỀU HƠN → Standard-IA rẻ hơn
        ↓
    Đề nói "access rate drops SIGNIFICANTLY" nhưng
    KHÔNG nói con số cụ thể

Cách hiểu hợp lý của đề: "significantly" vẫn hàm ý có truy cập đều đặn (hằng tháng), chứ không phải gần như không bao giờ — và đó là ranh giới AWS dùng để phân biệt hai lớp. Trong thực tế, nên chạy S3 Storage Class Analysis để đo tần suất thật trước khi chọn.

Ghi nhớ

Các lớp lưu trữ S3 — bảng phải thuộc: | Lớp | Số AZ | Thời gian lấy | Lưu tối thiểu | |---|---|---|---| | Standard | ≥3 | tức thì | — | | Standard-IA | ≥3 | tức thì | 30 ngày | | One Zone-IA | 1 ⚠ | tức thì | 30 ngày | | Glacier Instant | ≥3 | mili giây | 90 ngày | | Glacier Flexible | ≥3 | 1 phút – 12 giờ | 90 ngày | | Deep Archive | ≥3 | 12–48 giờ | 180 ngày |

Bốn câu hỏi để chọn lớp: | Câu hỏi | Nếu "có" | |---|---| | Cần lấy TỨC THÌ? | Standard, IA, hoặc Glacier Instant | | Dữ liệu tái tạo được? | One Zone-IA rẻ hơn | | Mẫu truy cập đoán được? | lifecycle; nếu không → Intelligent-Tiering | | Rất hiếm truy cập và chờ được? | Glacier Flexible hoặc Deep Archive |

Ba ràng buộc của lifecycle: | Ràng buộc | Chi tiết | |---|---| | IA tối thiểu 30 ngày | không chuyển sớm hơn | | Object dưới 128 KB không tự chuyển sang IA | | | Xoá sớm vẫn tính phí đủ thời gian tối thiểu | |

Ba quy tắc lifecycle nên có ở mọi bucket: | Quy tắc | Lợi ích | |---|---| | AbortIncompleteMultipartUpload | dọn phần dở dang — chi phí ẩn | | NoncurrentVersionExpiration | với versioning | | ExpiredObjectDeleteMarker | dọn delete marker |

Ba công cụ phân tích: | Công cụ | Việc | |---|---| | S3 Storage Class Analysis | đo mẫu truy cập theo tuổi object | | S3 Storage Lens | tổng quan mọi bucket | | Cost Explorer | chi phí theo lớp |

Storage Class Analysis nên chạy trước:

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

Nó cho biết chính xác sau bao nhiêu ngày dữ liệu ngừng được đọc.

Ba lưu ý về Intelligent-Tiering: | Lưu ý | Chi tiết | |---|---| | KHÔNG có phí truy xuất | ưu điểm lớn nhất | | Phí giám sát ~0,0025 USD/1.000 object | | | Phù hợp khi mẫu truy cập KHÔNG đoán được | |

Với đề này, mẫu truy cập ĐÃ BIẾT (30 ngày), nên lifecycle rẻ hơn Intelligent-Tiering.

Ba lưu ý về yêu cầu tuân thủ: | Lưu ý | Chi tiết | |---|---| | "Đúng 4 năm" có thể là ràng buộc pháp lý | | | Cân nhắc Object Lock nếu cấm xoá sớm | | | Ghi rõ chính sách vào tài liệu | |

Và một lời khuyên: hãy chạy S3 Storage Class Analysis 30 ngày trước khi cố định lựa chọn giữa Standard-IA và Glacier Instant Retrieval. Chênh lệch giữa hai lớp phụ thuộc hoàn toàn vào tần suất đọc thật — và đó là con số duy nhất báo cáo phân tích cho bạn mà phỏng đoán thì không.

Đáp án

D — Dùng EC2 Dedicated Hosts.

Vì sao đúng

Đề nêu từ khoá quyết định: giấy phép ràng buộc theo MÁY CHỦ (server-bound licenses).

Giấy phép kiểu này tính theo:
    → số socket vật lý
    → số core vật lý
    → hoặc định danh của máy chủ
        ↓
    Cần THẤY và KIỂM SOÁT được máy chủ vật lý

Chỉ Dedicated Host cho điều đó:

Dedicated Host:
    ✓ bạn thuê CẢ MÁY CHỦ VẬT LÝ
    ✓ THẤY được số socket và core
    ✓ kiểm soát instance nào chạy trên máy nào
    ✓ có host ID ổn định
        ↓
    Đủ điều kiện để nhà cung cấp giấy phép chấp nhận BYOL

Và Dedicated Instance KHÔNG đủ:

Dedicated Instance:
    → phần cứng dành riêng cho tài khoản của bạn
    → nhưng bạn KHÔNG thấy socket, core, hay host ID
        ↓
    Không chứng minh được với nhà cung cấp giấy phép

Đây là khác biệt cốt lõi giữa hai lựa chọn.

Cấp phát Dedicated Host:

aws ec2 allocate-hosts --instance-type m5.large   --availability-zone ap-northeast-1a --quantity 1   --auto-placement off --host-recovery on

Và khởi động instance lên host đó:

aws ec2 run-instances --image-id ami-0abc --instance-type m5.large   --placement HostId=h-0abc123,Tenancy=host --count 1

Ba tính năng riêng của Dedicated Host: | Tính năng | Việc | |---|---| | Host affinity | instance luôn khởi động lại trên CÙNG host | | Host recovery | tự chuyển sang host mới khi phần cứng hỏng | | Host resource group | quản lý nhiều host cho BYOL |

Host affinity quan trọng với giấy phép:

aws ec2 modify-instance-placement --instance-id i-0abc --affinity host

Giấy phép gắn với host ID
    → instance chuyển sang host khác = vi phạm giấy phép
        ↓
    Affinity đảm bảo nó luôn quay về đúng máy

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

• **C. Dùng Dedicated Instances — đây là phương án gần nhất và cũng cho phần cứng một khách thuê, nhưng nó không cho thấy socket và core vật lý: bạn không kiểm soát được instance chạy trên máy chủ nào. Với giấy phép tính theo socket hoặc core, đó là điều kiện bắt buộc.
• **A. Dùng Reserved Instance — chỉ là mô hình GIÁ: nó giảm chi phí khi cam kết dài hạn, nhưng không thay đổi việc phần cứng có dùng chung hay không.
• **B. Dùng On-Demand Instance — chạy trên phần cứng dùng chung, và không có ưu đãi giá nào.

Ghi nhớ

Dedicated Instance và Dedicated Host — bảng phải thuộc: | | Dedicated Instance | Dedicated Host | |---|---|---| | Phần cứng một khách thuê | ✅ | ✅ | | Thấy socket và core vật lý | ❌ | ✅ | | Kiểm soát vị trí instance | ❌ | ✅ | | Host ID ổn định | ❌ | ✅ | | BYOL theo socket/core | ❌ | ✅ | | Tính phí | theo instance-giờ | theo HOST-giờ |

Quy tắc nhận diện — rất hay được hỏi:

"server-bound licenses", "BYOL", "per-socket/per-core licensing" → Dedicated Host "single-tenant hardware", "compliance", "most cost-effective" → Dedicated Instance

Ba loại giấy phép hay cần Dedicated Host: | Phần mềm | Lý do | |---|---| | Windows Server | tính theo core vật lý | | SQL Server | tính theo core | | Oracle Database | tính theo socket, có quy tắc riêng |

Ba mức tenancy của EC2: | Mức | Nghĩa | |---|---| | default | phần cứng dùng chung | | dedicated | phần cứng riêng cho tài khoản | | host | máy chủ vật lý cụ thể bạn thuê |

Ba cách trả tiền cho Dedicated Host: | Cách | Chi tiết | |---|---| | On-Demand | theo giờ | | Reserved | cam kết 1–3 năm, giảm giá đáng kể | | Savings Plans | KHÔNG áp cho Dedicated Host |

Dòng cuối là chi tiết đáng nhớ.

Ba lưu ý về License Manager: | Lưu ý | Chi tiết | |---|---| | Theo dõi mức dùng giấy phép | | | CHẶN khởi động khi vượt hạn mức | | | Tích hợp với Dedicated Host | |

aws license-manager create-license-configuration   --name giay-phep-sql-server   --license-counting-type Core --license-count 64   --license-count-hard-limit

Vượt số core đã mua
    → AWS TỪ CHỐI khởi động instance
        ↓
    Ngăn vi phạm giấy phép ngoài ý muốn

Ba lưu ý về host recovery: | Lưu ý | Chi tiết | |---|---| | Tự cấp host mới khi phần cứng hỏng | | | Khởi động lại instance trên host đó | | | Không tính phí host cũ trong lúc chuyển | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Trả tiền CẢ MÁY dù chỉ chạy một instance | | | Nên xếp nhiều instance lên một host | tận dụng tối đa | | Reserved Dedicated Host giảm đáng kể | |

Ba lưu ý khi lập kế hoạch: | Lưu ý | Chi tiết | |---|---| | Đếm số core vật lý của loại host | so với giấy phép có | | Kiểm tra điều khoản BYOL với nhà cung cấp | | | Một số phần mềm đòi báo cáo định kỳ | |

Ba lựa chọn khác cho giấy phép: | Lựa chọn | Chi tiết | |---|---| | License Included | giá instance đã gồm giấy phép | | BYOL trên Dedicated Host | ← câu này | | RDS License Included | cho SQL Server, Oracle SE2 |

RDS đáng cân nhắc cho database:

RDS for SQL Server với License Included
    → không phải mang giấy phép sang
    → và không phải quản lý máy chủ
        ↓
    Nhưng chỉ áp cho một số phiên bản

Và một lời khuyên: hãy xác nhận điều khoản BYOL với nhà cung cấp giấy phép trước khi thiết kế. Một số hãng có quy định riêng về việc chạy trên hạ tầng đám mây — và phát hiện điều đó sau khi đã cấp phát hàng chục Dedicated Host là một cuộc đàm phán tốn kém.

Đáp án

B — Amazon SQS temporary queue.

Vì sao đúng

Đề nêu hai từ khoá quyết định: mẫu request-response thông lượng cao và tiết kiệm thời gian phát triển lẫn chi phí triển khai.

Mẫu request-response với SQS:
    → mỗi request cần một hàng đợi phản hồi RIÊNG
    → nếu tạo hàng đợi thật cho mỗi request:
        ✗ chậm (tạo hàng đợi mất thời gian)
        ✗ chạm giới hạn số hàng đợi
        ✗ phải tự dọn dẹp

Temporary queue giải quyết đúng vấn đề đó:

Temporary Queue Client:
    → tạo hàng đợi ẢO (virtual queue) trên MỘT hàng đợi thật
    → nhiều hàng đợi ảo dùng chung một hàng đợi vật lý
    → tự xoá khi không còn dùng
        ↓
    Không phải viết logic quản lý vòng đời hàng đợi

Và đó chính là "saves development time and deployment costs".

Dùng thư viện:

AmazonSQSRequester requester = AmazonSQSRequesterClientBuilder.defaultClient();
Message phanHoi = requester.sendMessageAndGetResponse(
    new SendMessageRequest().withQueueUrl(urlHangDoi).withMessageBody("yeu cau"),
    30, TimeUnit.SECONDS);

Và phía xử lý:

AmazonSQSResponder responder = AmazonSQSResponderClientBuilder.defaultClient();
responder.sendResponseMessage(MessageContent.fromMessage(tinNhan),
    new MessageContent("ket qua"));

Ba lợi ích của virtual queue: | Lợi ích | Chi tiết | |---|---| | Không chạm giới hạn số hàng đợi | nhiều ảo trên một thật | | Tạo gần như tức thì | không gọi API tạo hàng đợi | | Tự dọn dẹp | heartbeat, hết hạn thì xoá |

Và cơ chế bên dưới:

Thông điệp phản hồi mang thuộc tính đặc biệt
    → client lọc theo thuộc tính đó
        ↓
    Một hàng đợi vật lý phục vụ hàng nghìn luồng request-response

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

• **A. Delay queue — đây là phương án gần nhất vì cũng là một loại hàng đợi đặc biệt của SQS, nhưng nó giải quyết vấn đề khác: delay queue hoãn việc giao thông điệp mới trong tối đa 15 phút, không liên quan tới mẫu request-response.
• **C. FIFO queue — giải quyết vấn đề thứ tự và trùng lặp, và còn giới hạn thông lượng (300 hoặc 3.000 thông điệp mỗi giây), đi ngược yêu cầu "high-throughput".
• **D. Dead-letter queue — nhận thông điệp đã thất bại nhiều lần, để điều tra sau. Không liên quan tới request-response.

Ghi nhớ

Bốn khái niệm hàng đợi của SQS — bảng phải thuộc: | Khái niệm | Việc | |---|---| | Delay queue | hoãn giao thông điệp MỚI (0–900 giây) | | Dead-letter queue | nhận thông điệp thất bại | | Temporary queue | hàng đợi ảo cho request-response ← câu này | | FIFO queue | thứ tự và xử lý đúng một lần |

Từ khoá nhận diện:

"request-response", "high throughput", "save development time" → temporary queue "postpone delivery of new messages" → delay queue "handle failed messages" → dead-letter queue "exactly-once, ordered" → FIFO queue

Ba thành phần của Temporary Queue Client: | Thành phần | Việc | |---|---| | AmazonSQSRequester | gửi request và chờ phản hồi | | AmazonSQSResponder | nhận request và trả lời | | AmazonSQSVirtualQueuesClient | quản lý hàng đợi ảo |

Ba đặc điểm của virtual queue: | Đặc điểm | Chi tiết | |---|---| | Nằm TRÊN một hàng đợi thật | không tốn hạn mức hàng đợi | | Có heartbeat và thời gian sống | tự xoá khi bỏ | | Chỉ tồn tại trong bộ nhớ của client | |

Ba giới hạn của SQS: | Giới hạn | Giá trị | |---|---| | Kích thước thông điệp | 256 KB | | Thời gian giữ | 60 giây – 14 ngày | | Số hàng đợi mỗi tài khoản | rất lớn nhưng có hạn |

Hai loại hàng đợi — nhắc lại: | | Standard | FIFO | |---|---|---| | Thông lượng | gần như vô hạn | 300/3.000 msg/giây | | Thứ tự | không đảm bảo | đảm bảo trong group | | Trùng lặp | có thể | đúng một lần |

Ba mẫu nhắn tin phổ biến: | Mẫu | Dịch vụ | |---|---| | Điểm-tới-điểm (một consumer) | SQS | | Phát tán (nhiều subscriber) | SNS, EventBridge | | Request-response | SQS temporary queue ← câu này |

Ba lựa chọn khác cho request-response: | Lựa chọn | Đặc điểm | |---|---| | API Gateway + Lambda | đồng bộ, đơn giản nhất | | SQS temporary queue | bất đồng bộ có phản hồi | | Step Functions với callback | luồng dài |

Step Functions callback pattern đáng biết:

{"Type": "Task",
 "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
 "Parameters": {"QueueUrl": "...",
                "MessageBody": {"TaskToken.$": "$$.Task.Token"}}}

Gửi task token qua SQS
    → hệ thống ngoài xử lý xong gọi SendTaskSuccess
        ↓
    Chờ được tới MỘT NĂM

Ba thông số SQS quan trọng: | Thông số | Mặc định | |---|---| | Visibility timeout | 30 giây | | Message retention | 4 ngày | | Receive wait time | 0 (nên đặt 20) |

Ba lưu ý về long polling: | Lưu ý | Chi tiết | |---|---| | Đặt ReceiveMessageWaitTimeSeconds = 20 | | | Giảm số lời gọi API rỗng | tiết kiệm chi phí | | Temporary Queue Client dùng sẵn | |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Standard queue | ~0,40 USD mỗi triệu request | | FIFO queue | ~0,50 USD mỗi triệu | | — | virtual queue không tính phí riêng |

Ba lưu ý khi dùng thư viện: | Lưu ý | Chi tiết | |---|---| | Hiện có cho Java | amazon-sqs-java-temporary-queues-client | | Cần đóng client đúng cách | để dọn hàng đợi | | Đặt timeout cho việc chờ phản hồi | tránh treo |

Và một lời khuyên: hãy cân nhắc API Gateway với Lambda trước nếu mẫu request-response của bạn thực sự đồng bộ. Temporary queue giải quyết tốt trường hợp hệ thống đã dùng SQS và cần thêm phản hồi — nhưng nếu thiết kế còn mới, một API HTTP đồng bộ đơn giản hơn nhiều và không cần thư viện đặc biệt nào.

Đáp án

D — Tạo gateway endpoint RIÊNG cho S3 và cho DynamoDB, thêm hai mục đích tương ứng vào route table của VPC.

Vì sao đúng

Đề nêu yêu cầu: truy cập riêng tư tới S3 và DynamoDB từ private subnet, và cả hai dịch vụ này đều dùng gateway endpoint.

Gateway endpoint hỗ trợ ĐÚNG HAI dịch vụ:
    ✓ Amazon S3
    ✓ Amazon DynamoDB
        ↓
    Cả hai nhu cầu trong đề đều nằm trong danh sách này

Cơ chế:

Mỗi endpoint thêm một prefix list vào route table:
    pl-s3   → vpce-s3
    pl-ddb  → vpce-ddb
        ↓
    Lưu lượng tới hai dịch vụ tự động đi qua endpoint
    → KHÔNG ra Internet, KHÔNG cần NAT Gateway

Triển khai:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-northeast-1.s3   --vpc-endpoint-type Gateway --route-table-ids rtb-private

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-northeast-1.dynamodb   --vpc-endpoint-type Gateway --route-table-ids rtb-private

Và gateway endpoint MIỄN PHÍ:

Gateway endpoint:  0 USD
Interface endpoint: ~0,01 USD/giờ mỗi AZ + 0,01 USD/GB
NAT Gateway:        ~32 USD/tháng + 0,045 USD/GB
        ↓
    Vừa riêng tư hơn vừa rẻ hơn

Và ứng dụng không phải sửa gì:

Vẫn gọi cùng endpoint của S3 và DynamoDB
    → chỉ đường đi mạng thay đổi
        ↓
    Hoàn toàn trong suốt

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

• **C. Gateway endpoint cho S3 và INTERFACE endpoint cho DynamoDB — đây là phương án gần nhất và đúng hoàn toàn ở vế S3, nhưng nó sai ở vế DynamoDB: DynamoDB hỗ trợ gateway endpoint (miễn phí), và phương án còn nói thêm interface endpoint vào route table — interface endpoint hoạt động qua ENI và DNS, không qua route table.
• **A. Interface endpoint cho cả hai rồi thêm vào route table — hai lỗi: interface endpoint không thêm vào route table, và dùng interface endpoint cho hai dịch vụ có gateway endpoint miễn phí là lãng phí.
• **B. Gateway endpoint cho DynamoDB + Origin Access Identity cho S3 — OAI là cơ chế của CloudFront, hoàn toàn không liên quan tới truy cập riêng tư từ VPC.

Ghi nhớ

Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Cơ chế | route trong ROUTE TABLE | ENI có IP riêng + DNS | | Chi phí | MIỄN PHÍ | ~0,01 USD/giờ mỗi AZ | | Từ on-premises | ❌ | ✅ | | Security group | ❌ | ✅ |

Quy tắc: S3 và DynamoDB dùng gateway endpoint, trừ khi cần truy cập từ on-premises.

Ba lợi ích của VPC endpoint: | Lợi ích | Chi tiết | |---|---| | Lưu lượng không ra Internet | | | Tiết kiệm phí NAT Gateway | | | Kiểm soát bằng endpoint policy | |

Endpoint policy giới hạn thêm:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::kho-anh/*"}]}

Ba loại chính sách phải cùng cho phép: | Chính sách | Việc | |---|---| | IAM policy của EC2 role | principal được làm gì | | Bucket policy / table policy | ai truy cập tài nguyên | | Endpoint policy | gì đi qua endpoint được phép |

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Gắn vào ĐÚNG route table của subnet | | | Chỉ hoạt động TRONG Region | | | Không dùng từ on-premises | |

Ba dịch vụ nên có endpoint trong VPC riêng tư: | Dịch vụ | Loại | |---|---| | S3, DynamoDB | gateway (miễn phí) | | Systems Manager (3 endpoint) | interface | | Secrets Manager, KMS, ECR, CloudWatch Logs | interface |

Ba bước để instance ở private subnet gọi được API AWS: | Bước | Chi tiết | |---|---| | ① Endpoint hoặc NAT Gateway | đường đi mạng | | ② IAM instance profile | quyền | | ③ Security group cho phép 443 | với interface endpoint |

Ba cách kiểm chứng lưu lượng qua endpoint: | Cách | Việc | |---|---| | CloudTrail: trường vpcEndpointId | bằng chứng rõ nhất | | VPC Flow Logs | đích là IP nội bộ | | Kiểm tra route table | có prefix list |

aws ec2 describe-route-tables --route-table-ids rtb-private   --query 'RouteTables[].Routes[?GatewayId!=null]'

Ba biện pháp bảo mật kết hợp: | Biện pháp | Chi tiết | |---|---| | aws:SourceVpce trong bucket policy | ép đi qua endpoint | | Endpoint policy giới hạn tài nguyên | | | Block Public Access ở cấp tài khoản | |

Ba lưu ý về DynamoDB endpoint: | Lưu ý | Chi tiết | |---|---| | Là gateway endpoint, MIỄN PHÍ | | | DAX cần đường khác | DAX chạy trong VPC sẵn | | DynamoDB Streams KHÔNG qua gateway endpoint | cần interface endpoint |

Dòng cuối là chi tiết ít người biết.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Gateway endpoint | 0 USD | | Tiết kiệm NAT | 32 USD/tháng + phí GB | | Không có phí truyền dữ liệu qua gateway endpoint | |

Ba việc nên làm khi thiết kế VPC: | Việc | Chi tiết | |---|---| | Tạo gateway endpoint cho S3 và DynamoDB NGAY | miễn phí, không có lý do không làm | | Thêm interface endpoint cho dịch vụ hay dùng | SSM, KMS | | Đánh giá xem còn cần NAT Gateway không | |

Và một lời khuyên: hãy tạo gateway endpoint cho S3 và DynamoDB trong mọi VPC, kể cả khi chưa dùng tới. Chúng miễn phí, không có tác dụng phụ, và tiết kiệm ngay khoản phí NAT đầu tiên mà một ứng dụng vô tình gọi tới hai dịch vụ đó.

Đáp án

C — Storage class analysis chỉ đưa ra khuyến nghị chuyển từ Standard sang Standard-IA.

Vì sao đúng

Đây là câu kiểm tra giới hạn cụ thể của tính năng.

S3 Storage Class Analysis:
    → phân tích mẫu truy cập theo TUỔI của object
    → đưa ra khuyến nghị chuyển từ:
        S3 Standard → S3 Standard-IA
        ↓
    KHÔNG phân tích cho Glacier, One Zone-IA,
      hay Intelligent-Tiering

Vì sao chỉ có cặp này:

Standard và Standard-IA khác nhau ở MẪU TRUY CẬP
    → và mẫu truy cập là thứ ĐO ĐƯỢC từ log
        ↓
    Còn chọn Glacier hay One Zone là quyết định về
      YÊU CẦU NGHIỆP VỤ (thời gian lấy, độ bền)
    → công cụ không suy ra được từ dữ liệu truy cập

Bật phân tích:

aws s3api put-bucket-analytics-configuration --bucket kho-du-lieu   --id phan-tich-lop-luu-tru   --analytics-configuration '{
    "Id":"phan-tich-lop-luu-tru",
    "StorageClassAnalysis":{"DataExport":{
      "OutputSchemaVersion":"V_1",
      "Destination":{"S3BucketDestination":{
        "Format":"CSV","Bucket":"arn:aws:s3:::bao-cao-phan-tich",
        "Prefix":"phan-tich/"}}}}}'

Và kết quả cho biết: | Cột | Ý nghĩa | |---|---| | Dung lượng theo nhóm tuổi object | 0–14 ngày, 15–29, 30–44... | | Tỷ lệ được truy xuất trong mỗi nhóm | | | Khuyến nghị số ngày nên chuyển sang IA | |

Và cần thời gian để có dữ liệu:

Phân tích cần ít nhất 24–48 giờ để bắt đầu
    → và khoảng 30 ngày để khuyến nghị đáng tin
        ↓
    Không bật hôm nay rồi đọc kết quả ngày mai

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

• **B. Chỉ khuyến nghị từ Standard sang One Zone-IA — đây là phương án gần nhất vì One Zone-IA cũng là lớp truy cập không thường xuyên, nhưng công cụ không khuyến nghị lớp này: việc chấp nhận dữ liệu chỉ nằm ở một AZ là quyết định về độ bền, không phải về mẫu truy cập.
• **A. Chỉ khuyến nghị sang Glacier Deep Archive — không phải phạm vi của công cụ.
• **D. Chỉ khuyến nghị sang Glacier Flexible Retrieval — cũng không phải.

Ghi nhớ

Ba công cụ phân tích lưu trữ S3 — bảng phải thuộc: | Công cụ | Việc | |---|---| | Storage Class Analysis | khuyến nghị Standard → Standard-IA | | S3 Storage Lens | tổng quan MỌI bucket: dung lượng, chi phí, cấu hình | | S3 Inventory | danh sách object và metadata dạng tệp |

Ba công cụ này bổ sung nhau:

Storage Class Analysis: khi nào nên chuyển sang IA
Storage Lens:           bức tranh toàn cảnh và xu hướng
S3 Inventory:           danh sách chi tiết để xử lý hàng loạt

Ba đặc điểm của Storage Class Analysis: | Đặc điểm | Chi tiết | |---|---| | Phân tích theo bucket, prefix, hoặc tag | | | Xuất kết quả ra S3 dạng CSV | | | Cần ~30 ngày để khuyến nghị đáng tin | |

Ba nhóm chỉ số trong báo cáo: | Chỉ số | Ý nghĩa | |---|---| | ObjectAge | nhóm tuổi object | | StorageBytes | dung lượng trong nhóm đó | | DataRetrievedBytes | lượng được đọc lại |

Ba cách dùng kết quả: | Cách | Chi tiết | |---|---| | Đặt lifecycle theo số ngày khuyến nghị | | | Phân tích bằng Athena hoặc QuickSight | | | So sánh giữa các prefix | |

Ba lưu ý về S3 Storage Lens: | Lưu ý | Chi tiết | |---|---| | Dashboard mặc định MIỄN PHÍ | 28 chỉ số | | Advanced metrics có phí | thêm chỉ số bảo vệ dữ liệu và hoạt động | | Xem được toàn TỔ CHỨC | |

Ba chỉ số hữu ích của Storage Lens: | Chỉ số | Ý nghĩa | |---|---| | Phân bố lớp lưu trữ | bao nhiêu ở Standard | | Multipart upload dở dang | chi phí ẩn | | Object không được truy cập | |

Ba lưu ý về S3 Inventory: | Lưu ý | Chi tiết | |---|---| | Xuất hằng ngày hoặc hằng tuần | CSV, ORC, Parquet | | Gồm kích thước, lớp lưu trữ, mã hoá, replication | | | Dùng làm manifest cho S3 Batch Operations | |

S3 Batch Operations kết hợp với Inventory:

Inventory liệt kê mọi object cần xử lý
    → Batch Operations sao chép, đổi lớp, gắn tag hàng loạt
        ↓
    Xử lý được hàng tỷ object

Các lớp lưu trữ — nhắc lại: | Lớp | Thời gian lấy | Lưu tối thiểu | |---|---|---| | Standard | tức thì | — | | Standard-IA | tức thì | 30 ngày | | Intelligent-Tiering | tức thì | — | | Glacier Instant | mili giây | 90 ngày | | Glacier Flexible | 1 phút – 12 giờ | 90 ngày | | Deep Archive | 12–48 giờ | 180 ngày |

Ba trường hợp không cần Storage Class Analysis: | Trường hợp | Lý do | |---|---| | Mẫu truy cập KHÔNG đoán được | dùng Intelligent-Tiering | | Đã biết rõ vòng đời dữ liệu | đặt lifecycle luôn | | Bucket rất nhỏ | tiết kiệm không đáng kể |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Storage Class Analysis | ~0,10 USD mỗi triệu object theo dõi/tháng | | Storage Lens free metrics | miễn phí | | S3 Inventory | ~0,0025 USD mỗi triệu object liệt kê |

Ba việc nên làm định kỳ: | Việc | Tần suất | |---|---| | Xem Storage Lens dashboard | hàng tháng | | Đọc khuyến nghị Storage Class Analysis | hàng quý | | Rà soát lifecycle có còn phù hợp | hàng quý |

Và một lời khuyên: hãy bật Storage Class Analysis ở cấp prefix chứ không phải cả bucket nếu dữ liệu trong bucket có nhiều loại. Một bucket chứa cả log ứng dụng lẫn ảnh sản phẩm sẽ cho ra một con số trung bình không phản ánh đúng loại nào — và lifecycle đặt theo con số đó sẽ sai cho cả hai.

Đáp án

A — Client-side encryption (mã hoá phía client).

Vì sao đúng

Đề nêu ràng buộc quyết định: phải dùng THUẬT TOÁN ĐỘC QUYỀN của công ty.

Mọi hình thức server-side encryption đều do AWS thực hiện
    → AWS dùng AES-256, không dùng thuật toán của bạn
        ↓
    Muốn dùng thuật toán riêng
    → phải mã hoá TRƯỚC KHI dữ liệu rời khỏi ứng dụng

Client-side encryption là cách duy nhất:

Ứng dụng mã hoá bằng thuật toán riêng
    ↓ tải lên
S3 nhận và lưu một khối byte đã mã hoá
    → S3 KHÔNG biết và KHÔNG cần biết nội dung
        ↓
    Toàn quyền kiểm soát thuật toán và khoá

Và điều này cũng nghĩa là: | Hệ quả | Chi tiết | |---|---| | AWS KHÔNG BAO GIỜ thấy dữ liệu rõ | mức bảo vệ cao nhất | | Bạn tự quản lý toàn bộ khoá | trách nhiệm cũng lớn nhất | | Mất khoá = mất dữ liệu vĩnh viễn | AWS không khôi phục được |

Và nên bật SSE-S3 song song:

Client-side encryption bảo vệ nội dung
    + SSE-S3 mã hoá thêm lớp ở tầng lưu trữ (miễn phí)
        ↓
    Không mâu thuẫn, và thoả yêu cầu "mã hoá at rest"
      trong các khung tuân thủ

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Quản lý khoá bằng KMS hoặc CloudHSM | không lưu khoá trong mã | | Có quy trình xoay vòng khoá | và giữ khoá cũ để giải mã | | Lưu metadata về phiên bản thuật toán | cho việc di chuyển sau này |

Dòng cuối rất quan trọng với dữ liệu giữ lâu:

Hợp đồng lưu 10 năm
    → thuật toán và khoá sẽ đổi trong thời gian đó
        ↓
    Ghi phiên bản vào metadata của object
    → biết dùng khoá và thuật toán nào để giải mã

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

• **C. SSE-C (server-side encryption với khoá do khách cung cấp) — đây là phương án gần nhất vì bạn cung cấp khoá, nhưng AWS vẫn thực hiện việc mã hoá bằng AES-256: bạn kiểm soát khoá chứ không kiểm soát thuật toán. Đề đòi thuật toán độc quyền.
• **D. SSE-KMS — AWS mã hoá bằng AES-256, khoá do KMS quản lý. Không dùng thuật toán riêng được.
• **B. SSE-S3 — AWS quản lý cả khoá lẫn thuật toán, ít kiểm soát nhất.

Ghi nhớ

Năm cách mã hoá S3 — bảng phải thuộc: | Cách | Ai mã hoá | Ai giữ khoá | Thuật toán | |---|---|---|---| | SSE-S3 | AWS | AWS | AES-256 | | SSE-KMS | AWS | KMS, bạn kiểm soát policy | AES-256 | | DSSE-KMS | AWS (hai lớp) | KMS | AES-256 | | SSE-C | AWS | BẠN gửi mỗi request | AES-256 | | Client-side | BẠN | BẠN | BẤT KỲ ← câu này |

Từ khoá nhận diện:

"proprietary algorithm", "AWS must never see plaintext" → client-side encryption "we supply the key but AWS encrypts" → SSE-C "audit key usage", "control key policy" → SSE-KMS "simplest" → SSE-S3

Ba đặc điểm của SSE-C: | Đặc điểm | Chi tiết | |---|---| | Gửi khoá trong MỖI request | qua header, bắt buộc HTTPS | | AWS KHÔNG lưu khoá | mất khoá là mất dữ liệu | | Vẫn dùng AES-256 | ← điểm khác client-side |

Ba thư viện mã hoá phía client: | Thư viện | Chi tiết | |---|---| | AWS Encryption SDK | envelope encryption, tích hợp KMS | | Amazon S3 Encryption Client | chuyên cho S3 | | Thư viện riêng | khi cần thuật toán độc quyền |

Envelope encryption là mẫu chuẩn:

① Sinh khoá dữ liệu ngẫu nhiên
② Mã hoá dữ liệu bằng khoá đó
③ Mã hoá KHOÁ DỮ LIỆU bằng khoá gốc (KMS)
④ Lưu cả hai cùng nhau
        ↓
    Chỉ khoá gốc cần bảo vệ tuyệt đối

Ba lựa chọn quản lý khoá: | Lựa chọn | Chi tiết | |---|---| | AWS KMS | được quản lý, có audit | | AWS CloudHSM | HSM riêng, FIPS 140-3 Level 3 | | Tự quản lý | trách nhiệm hoàn toàn |

CloudHSM đáng cân nhắc với hợp đồng pháp lý:

CloudHSM:
    → khoá nằm trong module phần cứng riêng của bạn
    → AWS KHÔNG truy cập được
        ↓
    Một số quy định tài chính đòi mức này

Ba lưu ý về mất khoá: | Lưu ý | Chi tiết | |---|---| | Mất khoá = mất dữ liệu VĨNH VIỄN | | | Sao lưu khoá ở nơi tách biệt | | | Có quy trình khôi phục đã diễn tập | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Mã hoá phía client tốn CPU của ứng dụng | | | Với tệp lớn, cân nhắc mã hoá theo luồng | | | Đệm khoá dữ liệu để giảm lời gọi KMS | |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Ghi rõ thuật toán và độ dài khoá vào tài liệu | | | Có bằng chứng xoay vòng khoá | | | CloudTrail ghi việc dùng khoá KMS | |

Ba biện pháp bổ sung cho hợp đồng nhạy cảm: | Biện pháp | Chi tiết | |---|---| | S3 Object Lock chế độ Compliance | bất biến, chống xoá | | Versioning + MFA Delete | | | CloudTrail data event | ghi mọi thao tác |

Ba lưu ý về S3 Bucket Keys: | Lưu ý | Chi tiết | |---|---| | Chỉ áp cho SSE-KMS | | | Giảm tới 99% lời gọi KMS | | | Không liên quan tới client-side encryption | |

Ba lưu ý khi kết hợp nhiều lớp: | Lớp | Việc | |---|---| | Client-side | thuật toán riêng, nội dung | | SSE-S3 hoặc SSE-KMS | lớp thứ hai ở tầng lưu trữ | | TLS | trên đường truyền |

Và một lời khuyên: hãy ghi phiên bản thuật toán và định danh khoá vào metadata của mỗi object. Hợp đồng pháp lý được lưu nhiều năm, và trong thời gian đó thuật toán lẫn khoá đều sẽ đổi — không có thông tin này, việc giải mã một tệp cũ sau bảy năm sẽ trở thành một cuộc điều tra khảo cổ.

Đáp án

A — Lưu ảnh bằng lớp S3 Intelligent-Tiering.

Vì sao đúng

Đề nêu đúng tình huống mà Intelligent-Tiering được thiết kế cho:

"some images FREQUENTLY accessed, others sit IDLE"
        ↓
    Mẫu truy cập KHÁC NHAU giữa các object
    → và KHÔNG đoán trước được cái nào sẽ nóng
        ↓
    Không đặt được một quy tắc lifecycle chung

Intelligent-Tiering bỏ hẳn việc đoán:

S3 theo dõi truy cập của TỪNG object
    → tự chuyển tầng theo hành vi thật
    → object được đọc lại TỰ QUAY VỀ tầng nóng
        ↓
    Không có tham số nào để đặt sai

Bốn tầng: | Tầng | Chuyển sau | Giá tham khảo | |---|---|---| | Frequent Access | — | ~0,023 USD/GB | | Infrequent Access | 30 ngày không đọc | ~0,0125 USD/GB | | Archive Instant Access | 90 ngày không đọc | ~0,004 USD/GB | | Archive / Deep Archive (tuỳ chọn) | 90/180 ngày | rẻ hơn nữa |

Ba tầng đầu đều truy xuất TỨC THÌ — người dùng không cảm nhận khác biệt.

Và điểm quan trọng nhất: KHÔNG có phí truy xuất.

Standard-IA: rẻ hơn nhưng phí truy xuất ~0,01 USD/GB
    → ảnh bất ngờ được xem nhiều → ĐẮT HƠN Standard

Intelligent-Tiering: KHÔNG phí truy xuất
    → đoán sai cũng không bị phạt

Bật:

aws s3api put-bucket-intelligent-tiering-configuration   --bucket kho-anh --id tu-phan-tang   --intelligent-tiering-configuration '{
    "Id":"tu-phan-tang","Status":"Enabled","Filter":{},
    "Tierings":[{"Days":90,"AccessTier":"ARCHIVE_ACCESS"}]}'

Và ba phương án tự viết đều thua ở cùng một điểm:

Chạy EC2 kiểm tra hằng ngày rồi đổi lớp:
    ✗ trả tiền EC2 24/7
    ✗ phải viết và bảo trì mã
    ✗ mỗi lần đổi lớp tốn phí request
    ✗ chỉ chạy MỘT LẦN mỗi ngày
        ↓
    Intelligent-Tiering làm chính xác việc đó, tự động, rẻ hơn

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

• **D. Viết ứng dụng trên EC2 chạy hằng ngày đổi lớp giữa Standard và Standard-IA — đây là phương án gần nhất vì logic đúng với ý định, nhưng nó tự dựng lại một tính năng đã có: tốn tiền EC2, tốn công bảo trì, và phí request khi đổi lớp hàng loạt có thể vượt khoản tiết kiệm.
• **B. Cùng cách nhưng chuyển sang One Zone-IA — thêm một vấn đề nữa: One Zone-IA chỉ lưu ở một AZ, giảm độ bền.
• **C. Lưu tất cả bằng Standard-IA — sai với phần ảnh được xem nhiều: phí truy xuất khiến những ảnh nóng trở nên đắt hơn cả Standard.

Ghi nhớ

Quy tắc chọn giữa Lifecycle và Intelligent-Tiering: | Tình huống | Chọn | |---|---| | Mẫu truy cập ĐOÁN ĐƯỢC | Lifecycle (rẻ hơn, không phí giám sát) | | Mẫu truy cập KHÔNG đoán được | Intelligent-Tiering ← câu này | | Nhiều bucket, ít nhân lực | Intelligent-Tiering |

Ba đặc điểm của Intelligent-Tiering: | Đặc điểm | Chi tiết | |---|---| | Phí giám sát ~0,0025 USD/1.000 object/tháng | | | KHÔNG có phí truy xuất | ưu điểm lớn nhất | | Object tự quay về tầng nóng khi được đọc | |

Tính điểm hoà vốn:

Phí giám sát: 0,0025 USD mỗi 1.000 object/tháng
Tiết kiệm khi xuống IA: ~0,0105 USD/GB/tháng
        ↓
    Object trung bình phải lớn hơn ~250 KB
        ↓
    Ảnh mạng xã hội (thường vài trăm KB tới vài MB) → phù hợp

Ba trường hợp KHÔNG nên dùng Intelligent-Tiering: | Trường hợp | Lý do | |---|---| | Rất nhiều object NHỎ | phí giám sát vượt tiết kiệm | | Dữ liệu chắc chắn không đọc lại | Deep Archive rẻ hơn nhiều | | Dữ liệu sống dưới 30 ngày | không kịp xuống tầng |

Các lớp lưu trữ S3 — nhắc lại: | Lớp | Số AZ | Phí truy xuất | |---|---|---| | Standard | ≥3 | ❌ | | Intelligent-Tiering | ≥3 | ❌ | | Standard-IA | ≥3 | ✅ | | One Zone-IA | 1 ⚠ | ✅ | | Glacier Instant | ≥3 | ✅ cao |

Ba tuỳ chọn tầng lưu trữ sâu của Intelligent-Tiering: | Tầng | Chuyển sau | Thời gian lấy | |---|---|---| | Archive Instant Access | 90 ngày, TỰ ĐỘNG | tức thì | | Archive Access | 90 ngày, tuỳ chọn | 3–5 giờ | | Deep Archive Access | 180 ngày, tuỳ chọn | 12 giờ |

Hai tầng cuối phải BẬT tường minh — và chúng KHÔNG lấy tức thì được.

Với ảnh mạng xã hội, chỉ nên bật tới Archive Instant Access:

Ảnh cũ vẫn có thể được xem bất ngờ
    → Archive Access mất 3–5 giờ = trải nghiệm hỏng
        ↓
    Archive Instant Access rẻ và vẫn tức thì

Ba công cụ theo dõi: | Công cụ | Việc | |---|---| | S3 Storage Lens | phân bố dung lượng theo tầng | | Cost Explorer | chi phí theo lớp | | CloudWatch metric | |

Ba quy tắc lifecycle nên có kèm: | Quy tắc | Lợi ích | |---|---| | AbortIncompleteMultipartUpload | dọn phần dở dang | | Xoá phiên bản cũ | với versioning | | Xoá delete marker mồ côi | |

Ba cách tối ưu thêm cho kho ảnh: | Cách | Lợi ích | |---|---| | CloudFront trước S3 | đệm ảnh nóng, giảm phí egress | | Nén và đổi cỡ ảnh khi tải lên | giảm dung lượng gốc | | S3 Object Lambda | sinh thumbnail khi đọc |

Ba lưu ý về chi phí egress: | Lưu ý | Chi tiết | |---|---| | Egress từ S3 ~0,09 USD/GB | | | Qua CloudFront RẺ HƠN | | | Với mạng xã hội, egress thường lớn hơn phí lưu trữ | |

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

Tối ưu lớp lưu trữ giảm phí LƯU TRỮ
    → nhưng với kho ảnh được xem nhiều,
      phí TRUYỀN RA mới là khoản lớn nhất
        ↓
    CloudFront giải quyết vế đó

Và một lời khuyên: hãy kiểm tra kích thước object trung bình trước khi bật Intelligent-Tiering. Nếu kho ảnh chủ yếu là thumbnail vài chục KB, phí giám sát sẽ ăn hết phần tiết kiệm — trong trường hợp đó, gộp thumbnail vào một lớp Standard và chỉ áp Intelligent-Tiering cho ảnh gốc là lựa chọn đúng.