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

Đáp án

C — Cài AWS DataSync agent trên máy chủ tại chỗ và đồng bộ dữ liệu lên Amazon S3.

Vì sao đúng

Đề nêu bốn dữ kiện, và DataSync khớp từng cái: | Dữ kiện | Cách đáp ứng | |---|---| | Máy chủ NFS tại chỗ | DataSync hỗ trợ NFS | | Sao lưu ĐỊNH KỲ lên S3 | lập lịch bằng cron expression | | ĐỒNG BỘ TỰ ĐỘNG | chỉ chép phần thay đổi | | Lượng dữ liệu NHỎ, TIẾT KIỆM NHẤT | không cần hạ tầng riêng |

⚠ "Small volumes" + "automatic synchronization" là cặp từ khoá:

Lượng nhỏ → không cần Direct Connect hay Snowball
Tự động đồng bộ → cần công cụ có lập lịch và so sánh thay đổi
        ↓
    DataSync đúng cả hai

Cài agent:

aws datasync create-agent \
  --activation-key <khoa-kich-hoat> --agent-name agent-nfs

Tạo location và task:

aws datasync create-location-nfs \
  --server-hostname 192.168.1.100 --subdirectory /du-lieu \
  --on-prem-config AgentArns=<arn-agent>

aws datasync create-task \
  --source-location-arn <arn-nfs> \
  --destination-location-arn <arn-s3> \
  --schedule ScheduleExpression="cron(0 2 * * ? *)" \
  --options '{"VerifyMode":"ONLY_FILES_TRANSFERRED",
              "PreserveDeletedFiles":"PRESERVE",
              "TransferMode":"CHANGED"}'

⚠ TransferMode: CHANGED là mặc định và là điểm tiết kiệm:

Lần đầu: chép toàn bộ
Lần sau: so sánh metadata, CHỈ chép tệp thay đổi
        ↓
    Với sao lưu hằng ngày, lượng chuyển rất nhỏ
    → phí DataSync tính theo GB nên rất rẻ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần hạ tầng mạng riêng | chạy qua Internet | | Kiểm tra toàn vẹn tự động | | | Lập lịch và báo cáo sẵn có | |

⚠ Và lifecycle của S3 giảm chi phí thêm:

{"Rules": [{"ID":"luu-tru-sao-luu","Status":"Enabled","Filter":{},
  "Transitions":[
    {"Days":30,"StorageClass":"STANDARD_IA"},
    {"Days":90,"StorageClass":"GLACIER_IR"}]}]}

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

• **A. Dựng Direct Connect rồi chép dữ liệu lên S3 — đây là phương án gần nhất vì cũng đưa được dữ liệu lên S3, nhưng DX là kết nối riêng đắt tiền với phí cổng theo giờ và thời gian cung cấp hàng tuần. Với "small volumes of data" thì đây là chi phí không tương xứng.
• **D. Dùng AWS Transfer for SFTP đồng bộ dữ liệu — Transfer Family cung cấp endpoint SFTP cho bên ngoài tải lên; nó không tự đồng bộ và tính phí theo giờ endpoint.
• **B. Dùng AWS Glue trích xuất dữ liệu từ NFS và nạp vào S3 — Glue là dịch vụ ETL cho dữ liệu có cấu trúc, không phải công cụ sao lưu tệp. Và nó không kết nối trực tiếp tới NFS tại chỗ.

Ghi nhớ

⚠ Ba công cụ di chuyển dữ liệu — bảng phải thuộc: | Công cụ | Khi nào | |---|---| | AWS DataSync | đồng bộ định kỳ qua MẠNG | | AWS Snow family | lượng lớn, mạng kém, một lần | | AWS Storage Gateway | truy cập LIÊN TỤC có cache |

Từ khoá nhận diện:

"periodic backup", "automatic synchronization", "small volumes" → DataSync "petabytes + limited bandwidth" → Snowball "keep using local file system with cache" → Storage Gateway "provide SFTP endpoint for partners" → Transfer Family

⚠ DataSync và Storage Gateway — bảng phân biệt: | | DataSync | Storage Gateway | |---|---|---| | Mục đích | DI CHUYỂN / đồng bộ | truy cập liên tục | | Cache cục bộ | ❌ | ✅ | | Chạy | theo lịch | liên tục | | Kiểm tra toàn vẹn | ✅ | — |

Ba nguồn DataSync hỗ trợ: | Nguồn | Ghi chú | |---|---| | NFS, SMB tại chỗ | ← câu này | | HDFS | | | Object storage tương thích S3 | | | S3, EFS, FSx | giữa các dịch vụ AWS |

Ba đích DataSync hỗ trợ: | Đích | Ghi chú | |---|---| | Amazon S3 | mọi lớp lưu trữ | | Amazon EFS | | | FSx (Windows, Lustre, ONTAP, OpenZFS) | |

⚠ Ba tham số quan trọng của task: | Tham số | Việc | |---|---| | VerifyMode | kiểm tra toàn vẹn | | PreserveDeletedFiles | giữ hay xoá tệp đã bị xoá ở nguồn | | BytesPerSecond | giới hạn băng thông |

⚠ PreserveDeletedFiles quan trọng với sao lưu:

PRESERVE: tệp bị xoá ở nguồn VẪN CÒN ở S3
    → đúng cho mục đích sao lưu

REMOVE:   xoá theo nguồn
    → đúng cho mục đích đồng bộ gương
        ↓
    Với sao lưu, chọn PRESERVE

Ba chế độ VerifyMode: | Chế độ | Đặc điểm | |---|---| | POINT_IN_TIME_CONSISTENT | kiểm tra toàn bộ — chậm nhất, chắc nhất | | ONLY_FILES_TRANSFERRED | chỉ tệp vừa chép — hợp cho đồng bộ định kỳ | | NONE | nhanh nhất |

Ba yêu cầu tài nguyên cho agent: | Yêu cầu | Con số tối thiểu | |---|---| | vCPU | 4 | | RAM | 32 GB (cho > 20 triệu tệp) | | Đĩa | 80 GB |

⚠ Ba cách agent kết nối tới AWS: | Cách | Đặc điểm | |---|---| | Public service endpoint | qua Internet — đơn giản, rẻ | | VPC endpoint (PrivateLink) | riêng tư, qua DX/VPN | | FIPS endpoint | tuân thủ FIPS |

Đề nói "most cost-effective" và không nói gì về riêng tư
    → public endpoint là đủ

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Nhiều tệp nhỏ chậm hơn ít tệp lớn | | | Đặt giới hạn băng thông trong giờ làm việc | | | Chạy nhiều task song song trên thư mục khác nhau | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí theo GB dữ liệu CHUYỂN | | | Chỉ chép phần thay đổi nên rất rẻ | | | KHÔNG tính phí data transfer IN vào AWS | |

⚠ Ba lưu ý về lớp lưu trữ đích: | Lưu ý | Chi tiết | |---|---| | Chọn lớp ngay khi tạo S3 location | | | Với sao lưu, cân nhắc Standard-IA | | | Nhớ ngưỡng 128 KB của lớp IA | tệp nhỏ bị tính 128 KB |

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::kho-sao-luu \
  --s3-storage-class STANDARD_IA \
  --s3-config BucketAccessRoleArn=<arn-role>

Ba lưu ý về theo dõi: | Lưu ý | Chi tiết | |---|---| | Bật task report tìm tệp lỗi | | | CloudWatch metric FilesTransferred | | | EventBridge rule cảnh báo khi task lỗi | |

aws datasync describe-task-execution --task-execution-arn <arn> \
  --query "[Status,FilesTransferred,BytesTransferred,Result.ErrorCode]"

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Dữ liệu mã hoá TLS khi truyền | | | Bật mã hoá at rest trên S3 | | | IAM role quyền tối thiểu cho task | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử một thư mục nhỏ | | | So số tệp và dung lượng hai bên | | | Kiểm tra lần chạy thứ hai chỉ chép phần thay đổi | |

Và một lời khuyên: hãy đặt PreserveDeletedFiles: PRESERVE cho task sao lưu. Mặc định đó là đúng cho sao lưu, nhưng nếu ai đó nghĩ đây là "đồng bộ" và đổi sang REMOVE thì một lần xoá nhầm ở máy chủ tại chỗ sẽ được nhân bản lên bản sao lưu — biến thứ đáng lẽ bảo vệ bạn thành thứ xoá mất dữ liệu.

Đáp án

A — Nạp dữ liệu vào Kinesis Data Stream, xử lý bằng Lambda, rồi lưu vào DynamoDB.

Vì sao đúng

Đề nêu bốn yêu cầu, và chuỗi này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Hàng nghìn cảm biến, KHỐI LƯỢNG LỚN mỗi giây | Kinesis thiết kế cho luồng thông lượng cao | | GẦN THỜI GIAN THỰC | Kinesis độ trễ dưới giây | | Phản hồi MILI GIÂY | DynamoDB độ trễ một chữ số mili giây | | Lưu để phân tích | DynamoDB, có thể thêm Firehose ra S3 |

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

"near-real time" → Kinesis (không phải SQS)
"millisecond responsiveness" → DynamoDB (không phải Redshift)

⚠ Vì sao Redshift sai:

Redshift là KHO DỮ LIỆU phân tích
    → tối ưu cho truy vấn quét lớn, không cho tra cứu đơn lẻ
    → độ trễ tính bằng giây, không phải mili giây
        ↓
    Đây là lý do loại C và D

⚠ Và vì sao Kinesis hơn SQS ở đây: | | Kinesis Data Streams | SQS | |---|---|---| | Thứ tự | theo partition key | không đảm bảo (Standard) | | Nhiều consumer đọc cùng dữ liệu | ✅ | ❌ | | Đọc lại được | ✅ tới 365 ngày | ❌ xoá sau khi xử lý | | Thông lượng rất cao | ✅ theo shard | ✅ |

Với telemetry IoT, khả năng ĐỌC LẠI rất quan trọng
    → thêm một mô hình phân tích mới
    → chạy lại trên dữ liệu cũ

Tạo stream:

aws kinesis create-stream --stream-name luong-cam-bien \
  --stream-mode-details StreamMode=ON_DEMAND

Gửi dữ liệu với partition key theo cảm biến:

kinesis.put_record(
    StreamName='luong-cam-bien',
    Data=json.dumps(du_lieu),
    PartitionKey=du_lieu['ma_cam_bien'])

Lambda xử lý và ghi vào DynamoDB:

import base64, json, boto3
bang = boto3.resource('dynamodb').Table('DuLieuCamBien')

def handler(event, context):
    with bang.batch_writer() as lo:
        for ban_ghi in event['Records']:
            d = json.loads(base64.b64decode(ban_ghi['kinesis']['data']))
            lo.put_item(Item={
                'ma_cam_bien': d['ma_cam_bien'],
                'thoi_gian': d['thoi_gian'],
                'gia_tri': str(d['gia_tri'])})

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Toàn chuỗi serverless hoặc được quản lý | | | Độ trễ đọc mili giây cho ứng dụng | | | Đọc lại được để phân tích lại | |

⚠ Và nên thêm Firehose để lưu bản thô vào S3:

Kinesis Data Streams
    ├── Lambda → DynamoDB (tra cứu nhanh)
    └── Firehose → S3 (lưu trữ dài hạn, phân tích lớn)
        ↓
    Hai consumer đọc CÙNG dữ liệu

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

• **C. Kinesis Data Stream + Lambda + Redshift — đây là phương án gần nhất vì tầng nạp hoàn toàn đúng, nhưng Redshift không cho phản hồi mili giây: nó là kho dữ liệu cho truy vấn phân tích, không phải cho tra cứu từng bản ghi.
• **B. SQS + Lambda + DynamoDB — DynamoDB đúng, nhưng SQS không giữ dữ liệu sau khi xử lý và không cho nhiều consumer đọc cùng luồng. Với telemetry IoT thì mất khả năng phân tích lại.
• **D. SQS + Lambda + Redshift — sai cả hai vế.

Ghi nhớ

⚠ Ba dịch vụ nạp dữ liệu — bảng phải thuộc: | Dịch vụ | Thứ tự | Đọc lại | Nhiều consumer | |---|---|---|---| | Kinesis Data Streams | theo partition key | ✅ tới 365 ngày | ✅ | | Kinesis Data Firehose | không đảm bảo | ❌ | ❌ | | Amazon SQS | FIFO mới đảm bảo | ❌ | ❌ |

⚠ Bốn CSDL và độ trễ điển hình: | CSDL | Độ trễ đọc | Dùng cho | |---|---|---| | ElastiCache | micro giây | cache | | DynamoDB | một chữ số mili giây | tra cứu theo khoá | | RDS / Aurora | mili giây | truy vấn quan hệ | | Redshift | giây | phân tích quét lớn |

Từ khoá nhận diện:

"millisecond responsiveness" + key-value → DynamoDB "near-real time streaming, high volume" → Kinesis Data Streams "data warehouse, BI, complex analytics" → Redshift "microsecond, cache" → ElastiCache hoặc DAX

⚠ Ba đặc điểm của partition key trong Kinesis: | Đặc điểm | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | | | Thứ tự đảm bảo TRONG một shard | | | Key phân bố kém gây HOT SHARD | |

Giới hạn của một shard: | Chiều | Giới hạn | |---|---| | Ghi vào | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc ra | 2 MB/giây (chia cho mọi consumer) | | Enhanced fan-out | 2 MB/giây mỗi consumer |

⚠ Hai chế độ dung lượng: | Chế độ | Đặc điểm | |---|---| | Provisioned | tự quản shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn, không quản shard |

"Hàng nghìn cảm biến, khối lượng lớn"
    → on-demand tránh phải tính số shard

Ba lưu ý về thiết kế khoá DynamoDB cho IoT: | Lưu ý | Chi tiết | |---|---| | Partition key = mã cảm biến | phân bố đều | | Sort key = timestamp | truy vấn theo dải thời gian | | TTL xoá dữ liệu cũ tự động | |

bang.query(
    KeyConditionExpression=Key('ma_cam_bien').eq('cb-001') &
                           Key('thoi_gian').between(t1, t2))

⚠ TTL cho dữ liệu chuỗi thời gian:

aws dynamodb update-time-to-live --table-name DuLieuCamBien \
  --time-to-live-specification "Enabled=true,AttributeName=het_han"

Xoá MIỄN PHÍ, không tốn WCU
    → nhưng có thể trễ tới 48 giờ

Ba lựa chọn thay thế cho chuỗi thời gian: | Lựa chọn | Đặc điểm | |---|---| | Amazon Timestream | CSDL chuỗi thời gian chuyên dụng | | DynamoDB | ← câu này | | OpenSearch | tìm kiếm và dashboard |

⚠ Timestream đáng biết:

Thiết kế riêng cho dữ liệu chuỗi thời gian
    → tự phân tầng nóng/lạnh
    → có hàm phân tích chuỗi thời gian sẵn
        ↓
    Nhưng đề đưa DynamoDB nên đó là đáp án

Ba lưu ý về Lambda đọc Kinesis: | Lưu ý | Chi tiết | |---|---| | Một Lambda mỗi shard (mặc định) | | | ParallelizationFactor tăng song song | tới 10 | | Lỗi một bản ghi CHẶN cả shard | |

aws lambda update-event-source-mapping --uuid <uuid> \
  --maximum-retry-attempts 3 --bisect-batch-on-function-error \
  --parallelization-factor 4 \
  --destination-config '{"OnFailure":{"Destination":"<arn-sqs-dlq>"}}'

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAge | consumer tụt lại bao xa | | WriteProvisionedThroughputExceeded | hot shard | | DynamoDB ThrottledRequests | |

⚠ IteratorAge tăng dần là dấu hiệu nghiêm trọng:

Consumer không theo kịp tốc độ ghi
    → dữ liệu tụt lại
    → chạm hạn retention là MẤT

Ba lưu ý về AWS IoT Core: | Lưu ý | Chi tiết | |---|---| | Quản lý thiết bị và chứng chỉ | | | Rules engine định tuyến tới Kinesis, DynamoDB | | | Hỗ trợ MQTT — giao thức chuẩn của IoT | |

⚠ Với hàng nghìn cảm biến thật, IoT Core thường đứng trước:

Cảm biến → IoT Core (MQTT, chứng chỉ X.509)
         → Rules engine → Kinesis → Lambda → DynamoDB
        ↓
    IoT Core lo phần xác thực và quản lý thiết bị

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Kinesis on-demand đắt hơn provisioned khi tải ổn định | | | DynamoDB on-demand cho tải không đều | | | TTL xoá dữ liệu cũ miễn phí | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ đầu-cuối | | | Kiểm tra không có hot shard | metric theo shard | | Thử tải ở quy mô thật | |

Và một lời khuyên: hãy thêm một consumer Firehose ghi bản thô vào S3 ngay từ đầu. DynamoDB phục vụ tra cứu nhanh rất tốt, nhưng khi cần phân tích lại toàn bộ lịch sử bằng một mô hình mới, bạn sẽ muốn có dữ liệu gốc trong S3 chứ không phải quét cả một bảng DynamoDB.

Đáp án

C và D.

• C — Tạo một AWS WAF web ACL với cùng danh sách IP như security group của EC2, và gắn nó vào CloudFront distribution
• D — Tạo một origin access identity (OAI) gắn vào distribution, và sửa bucket policy để chỉ OAI đọc được object

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi hành động lo một vế: | Yêu cầu | Hành động | |---|---| | Giới hạn truy cập theo cùng dải IP | C: WAF trên CloudFront | | Nội dung tĩnh chuyển sang S3, không ai vào thẳng | D: OAI khoá bucket |

⚠ Vì sao cần cả hai:

Chỉ làm C:
    → lọc IP ở CloudFront ✓
    → nhưng bucket vẫn có thể truy cập trực tiếp
    → ai biết URL của S3 sẽ bỏ qua WAF hoàn toàn

Chỉ làm D:
    → bucket riêng tư ✓
    → nhưng CloudFront phục vụ cho MỌI IP
        ↓
    Hai vế bổ sung nhau chặt chẽ

⚠ Và vì sao WAF phải gắn vào CloudFront, không phải S3:

AWS WAF gắn được vào:
    → CloudFront, ALB, API Gateway, AppSync,
      Cognito user pool, App Runner, Verified Access
        ↓
    KHÔNG gắn vào S3 bucket được
    → đây là lý do phương án B sai

Tạo IP set và web ACL:

aws wafv2 create-ip-set --name dai-ip-cho-phep --scope CLOUDFRONT \
  --region us-east-1 --ip-address-version IPV4 \
  --addresses "203.0.113.0/24" "198.51.100.0/24"

aws wafv2 create-web-acl --name gioi-han-ip --scope CLOUDFRONT \
  --region us-east-1 \
  --default-action Block={} \
  --rules '[{"Name":"ChoPhepIP","Priority":0,
    "Statement":{"IPSetReferenceStatement":{"ARN":"<arn-ip-set>"}},
    "Action":{"Allow":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"ChoPhepIP"}}]' \
  --visibility-config SampledRequestsEnabled=true,\
CloudWatchMetricsEnabled=true,MetricName=gioiHanIP

⚠ --default-action Block={} là cấu hình đúng cho danh sách cho phép:

Mặc định CHẶN, chỉ Allow các IP trong danh sách
    → an toàn hơn "mặc định Allow rồi Deny các IP xấu"

Bucket policy chỉ cho OAI:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E123ABC"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::noi-dung-tinh/*"}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cùng chính sách IP như trước khi di chuyển | | | Bucket riêng tư hoàn toàn | | | CloudFront tăng tốc nội dung tĩnh | |

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

• **B. Tạo WAF web ACL và gắn vào S3 bucket — đây là phương án gần nhất và có ý tưởng đúng, nhưng WAF không gắn được vào S3. Đó là lý do phải đặt CloudFront phía trước.
• **E. Tạo OAI và sinh presigned URL giới hạn truy cập cho OAI — nhầm khái niệm: presigned URL dùng để cấp quyền tạm cho người dùng, không phải để giới hạn OAI. OAI là danh tính của CloudFront khi gọi S3.
• **A. Gắn security group hiện có vào CloudFront distribution — CloudFront không có security group. Nó là dịch vụ toàn cầu nằm ngoài VPC.

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

Đáp án dùng OAI, đúng theo tài liệu tại thời điểm câu hỏi được viết. Nhưng cần biết:

⚠ AWS đã thay OAI bằng OAC (Origin Access Control) từ 08/2022: | | OAC | OAI | |---|---|---| | Trạng thái | hiện hành, khuyến nghị | cũ | | Bucket mã hoá SSE-KMS | ✅ | ❌ | | Các vùng ra mắt sau 2022 | ✅ | ❌ | | Tải lên (PUT) qua CloudFront | ✅ | ❌ |

aws cloudfront create-origin-access-control \
  --origin-access-control-config \
  'Name=oac-noi-dung,OriginAccessControlOriginType=s3,
   SigningBehavior=always,SigningProtocol=sigv4'

Trong kỳ thi, OAI vẫn là lựa chọn được chấp nhận khi nó là phương án duy nhất diễn đạt đúng ý "khoá bucket chỉ cho CloudFront". Khi dựng hệ thống thật, hãy dùng OAC.

Ghi nhớ

⚠ Ba cách giới hạn truy cập nội dung CloudFront — bảng phải thuộc: | Cách | Giới hạn theo | |---|---| | WAF IP set | địa chỉ IP ← câu này | | Geo restriction | quốc gia | | Signed URL / signed cookie | từng người dùng, có hạn |

Từ khoá nhận diện:

"restrict to a set of IP ranges" → WAF IP set trên CloudFront "restrict by country" → geo restriction "per-user, time-limited access" → signed URL / cookie "only CloudFront can read the bucket" → OAC (hoặc OAI)

⚠ Bốn công cụ lọc và nơi gắn được: | Công cụ | Gắn vào | |---|---| | AWS WAF | CloudFront, ALB, API Gateway, AppSync, Cognito, App Runner | | Security Group | ENI (EC2, RDS, ELB...) | | Network ACL | subnet | | CloudFront geo restriction | distribution |

⚠ S3 KHÔNG gắn được WAF, security group hay NACL.

Ba đặc điểm của IP set: | Đặc điểm | Chi tiết | |---|---| | Chứa tới 10.000 CIDR | | | IPv4 và IPv6 là hai set riêng | | | Cập nhật có hiệu lực trong ~1 phút | |

⚠ Web ACL cho CloudFront phải tạo ở us-east-1 với --scope CLOUDFRONT.

Ba lưu ý khi đặt CloudFront trước S3: | Lưu ý | Chi tiết | |---|---| | Dùng REST endpoint, KHÔNG dùng website endpoint | | | Bật Block Public Access trên bucket | | | ViewerProtocolPolicy: redirect-to-https | |

⚠ Website endpoint không dùng được với OAC/OAI:

S3 website endpoint (s3-website-...) yêu cầu bucket CÔNG KHAI
    → không khoá cho riêng CloudFront được
        ↓
    Phải dùng REST endpoint (s3.amazonaws.com)

Ba lưu ý về signed URL và cookie: | Lưu ý | Chi tiết | |---|---| | Signed URL: một tệp | | | Signed cookie: nhiều tệp cùng lúc | | | Cần key pair và key group | |

Ba lưu ý về geo restriction: | Lưu ý | Chi tiết | |---|---| | Whitelist hoặc blacklist theo quốc gia | | | Chặn ở edge, không tốn tài nguyên phía sau | | | VPN làm sai lệch | |

Ba lưu ý khi bật WAF lần đầu: | Lưu ý | Chi tiết | |---|---| | Bật ở chế độ COUNT trước | | | Đọc sampled request | | | Rồi mới chuyển sang BLOCK | |

⚠ Với danh sách cho phép thì phải cẩn thận hơn:

Default action = Block
    → sai một dải IP là chặn nhầm người dùng thật ngay
        ↓
    Kiểm tra kỹ danh sách trước khi áp
    → và có cách khôi phục nhanh

Ba lưu ý về cache: | Lưu ý | Chi tiết | |---|---| | Nội dung tĩnh đặt TTL dài | | | Đặt tên tệp có mã băm nội dung | | | Bật nén | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Data transfer S3 → CloudFront MIỄN PHÍ | | | WAF tính theo web ACL, rule và request | | | Request bị chặn không tính phí truyền | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi từ IP được phép | phải thành công | | Gọi từ IP khác | phải nhận 403 | | Thử URL S3 trực tiếp | phải bị từ chối |

Và một lời khuyên: hãy thử gọi thẳng URL của S3 sau khi cấu hình xong. Đó là bài kiểm tra duy nhất chứng minh WAF thực sự nằm trên mọi đường đi — một web ACL gắn hoàn hảo vào CloudFront vẫn vô dụng nếu bucket còn một đường vào mà không ai nhớ đã mở.

Đáp án

D — AWS Compute Optimizer.

Vì sao đúng

Đề nêu ba dữ kiện, và Compute Optimizer khớp cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | Cần công cụ AWS gốc GIẢM chi phí | Compute Optimizer đưa khuyến nghị cụ thể | | **Giảm chi tiêu ở các mảng COMPUTE | đúng phạm vi của dịch vụ này | | Cần THÔNG TIN để quyết định giảm ở đâu | báo cáo có ước tính tiết kiệm |

⚠ "Compute" là từ khoá thu hẹp phạm vi:

Cost Explorer: xem chi phí ở MỌI dịch vụ
    → cho biết "tiêu bao nhiêu, ở đâu"
        ↓
Compute Optimizer: phân tích tài nguyên COMPUTE
    → cho biết "PHẢI LÀM GÌ để giảm"
    → kèm ước tính tiết kiệm cụ thể

Bật Compute Optimizer:

aws compute-optimizer update-enrollment-status --status Active

aws compute-optimizer get-ec2-instance-recommendations \
  --query "instanceRecommendations[].[instanceArn,finding,
    recommendationOptions[0].instanceType,
    recommendationOptions[0].estimatedMonthlySavings.value]" \
  --output table

Bốn loại tài nguyên Compute Optimizer phân tích: | Tài nguyên | Khuyến nghị | |---|---| | EC2 instance | loại và cỡ | | Auto Scaling group | loại instance trong nhóm | | EBS volume | loại và IOPS | | Lambda function | bộ nhớ cấp phát | | ECS service on Fargate | vCPU và bộ nhớ |

Ba mức phân loại: | Mức | Nghĩa | |---|---| | Over-provisioned | quá to — LÃNG PHÍ | | Under-provisioned | quá nhỏ — gây nghẽn | | Optimized | vừa đúng |

⚠ Cần ít nhất 14 ngày dữ liệu CloudWatch để có khuyến nghị đáng tin.

Bật Enhanced Infrastructure Metrics để chính xác hơn:

aws compute-optimizer put-recommendation-preferences \
  --resource-type Ec2Instance \
  --enhanced-infrastructure-metrics Active

Mặc định dùng 14 ngày
    → bật enhanced → dùng tới 3 THÁNG
        ↓
    Quan trọng với tải có chu kỳ theo tháng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Khuyến nghị cụ thể kèm số tiền tiết kiệm | | | Miễn phí | | | Có mức rủi ro hiệu năng cho từng lựa chọn | |

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

• **C. AWS Cost Explorer — đây là phương án gần nhất và là công cụ chuẩn để xem chi phí, nhưng nó cho biết tiêu bao nhiêu ở đâu, không cho biết nên đổi máy sang loại nào. Đề nhấn mạnh giảm chi tiêu ở mảng compute và cần insight để quyết định — đó là phạm vi của Compute Optimizer.
• **B. AWS Trusted Advisor — có kiểm tra tài nguyên nhàn rỗi và chưa dùng hết, nhưng kém chi tiết hơn Compute Optimizer về đúng cỡ máy. Và nhiều kiểm tra chỉ có với gói hỗ trợ Business/Enterprise.
• **A. Cost and Usage Reports (CUR) — dữ liệu chi phí thô nhất, chi tiết nhất, xuất ra S3. Rất mạnh nhưng cần tự phân tích bằng Athena hoặc QuickSight — ngược với yêu cầu "easiest way".

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

Đáp án chọn Compute Optimizer, nhưng cần nói rõ vì hai lựa chọn rất gần nhau:

⚠ Cost Explorer cũng có tính năng right-sizing:

Cost Explorer → Rightsizing Recommendations
    → gợi ý dừng hoặc thu nhỏ EC2
        ↓
    Nhưng nó chỉ phủ EC2, và dựa trên Compute Optimizer bên dưới

Cách phân biệt trong đề thi: | Đề nói | Đáp án | |---|---| | "insights into spend", "where is the money going" | Cost Explorer | | "right-size", "reduce compute spend", "recommendations" | Compute Optimizer | | "detailed raw billing data for custom analysis" | Cost and Usage Reports | | "idle resources, security checks" | Trusted Advisor |

Câu này có CẢ "insights" lẫn "compute"
    → hai từ khoá chỉ hai hướng khác nhau
        ↓
    Khoá đáp án chọn "compute" làm từ quyết định

Trong thực tế thì dùng cả hai: Cost Explorer để thấy bức tranh, Compute Optimizer để biết hành động cụ thể.

Ghi nhớ

⚠ Bốn công cụ quản lý chi phí AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | AWS Cost Explorer | xem và phân tích chi phí theo thời gian | | AWS Compute Optimizer | khuyến nghị ĐÚNG CỠ tài nguyên compute | | Cost and Usage Reports | dữ liệu chi phí THÔ, chi tiết nhất | | AWS Budgets | đặt ngân sách và cảnh báo | | Trusted Advisor | kiểm tra tổng hợp (chi phí, bảo mật, hiệu năng) |

⚠ Ba lớp công cụ theo mức chi tiết:

Budgets:          đặt ngưỡng và cảnh báo
Cost Explorer:    xem xu hướng, nhóm theo dịch vụ/tag
CUR:              từng dòng chi phí, tự phân tích
        ↓
Compute Optimizer: hành động cụ thể cho compute

Ba nguồn dữ liệu của Compute Optimizer: | Nguồn | Chi tiết | |---|---| | CloudWatch metric | CPU, mạng, đĩa | | CloudWatch Agent (nếu cài) | bộ nhớ | | Cấu hình tài nguyên | |

⚠ Không cài CloudWatch Agent thì khuyến nghị thiếu chiều bộ nhớ:

EC2 không tự gửi metric RAM
    → Compute Optimizer chỉ dựa trên CPU và mạng
        ↓
    Cài agent để có khuyến nghị đầy đủ

Ba cách tiết kiệm chi phí compute: | Cách | Mức giảm | |---|---| | Đúng cỡ máy (right-size) | thường 20-40% | | Savings Plans hoặc RI | tới ~72% | | Spot cho tải chịu gián đoạn | tới ~90% |

⚠ Thứ tự đúng khi tối ưu chi phí:

1. Xoá tài nguyên không dùng
2. ĐÚNG CỠ tài nguyên còn lại      ← Compute Optimizer
3. Rồi mới mua cam kết dài hạn      ← Savings Plans
        ↓
    Mua RI cho một máy quá to
    → khoá luôn cả sự lãng phí trong 1-3 năm

Ba tính năng của Cost Explorer: | Tính năng | Việc | |---|---| | Xem chi phí theo dịch vụ, tag, tài khoản | | | Dự báo chi phí tương lai | | | Khuyến nghị RI và Savings Plans | |

Ba lưu ý về AWS Budgets: | Lưu ý | Chi tiết | |---|---| | Đặt ngân sách theo chi phí, mức dùng, hoặc RI coverage | | | Cảnh báo qua SNS khi vượt ngưỡng | | | Budget Actions tự động áp SCP khi vượt | |

aws budgets create-budget --account-id 123456789012 \
  --budget '{"BudgetName":"ngan-sach-thang","BudgetLimit":
    {"Amount":"10000","Unit":"USD"},"TimeUnit":"MONTHLY",
    "BudgetType":"COST"}' \
  --notifications-with-subscribers '[{
    "Notification":{"NotificationType":"ACTUAL",
      "ComparisonOperator":"GREATER_THAN","Threshold":80},
    "Subscribers":[{"SubscriptionType":"EMAIL",
      "Address":"tai-chinh@vidu.com"}]}]'

Ba lưu ý về gắn tag để phân bổ chi phí: | Lưu ý | Chi tiết | |---|---| | Kích hoạt cost allocation tag | trong Billing console | | Dùng tag policy để chuẩn hoá | | | Tag mới cần tới 24 giờ mới hiện | |

Ba lưu ý khi áp dụng khuyến nghị: | Lưu ý | Chi tiết | |---|---| | Xem mức rủi ro hiệu năng | | | Thử ở môi trường dev trước | | | Đổi cỡ instance cần khởi động lại | |

Ba lưu ý về Graviton: | Lưu ý | Chi tiết | |---|---| | Rẻ hơn x86 khoảng 20% | | | Compute Optimizer có gợi ý chuyển sang Graviton | | | Kiểm tra ứng dụng chạy được trên ARM | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem báo cáo Compute Optimizer sau 14 ngày | | | So hoá đơn trước và sau khi đổi cỡ | | | Theo dõi metric hiệu năng sau khi thu nhỏ | |

Và một lời khuyên: hãy đúng cỡ tài nguyên TRƯỚC khi mua Savings Plans. Đây là thứ tự mà rất nhiều tổ chức làm ngược — và mua cam kết ba năm cho một đội máy đang quá to nghĩa là bạn khoá luôn sự lãng phí đó lại trong suốt thời hạn cam kết.

Đáp án

C — Tạo một Amazon SQS FIFO queue.

Vì sao đúng

Đề nêu hai yêu cầu, và FIFO queue là lựa chọn duy nhất thoả cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | **Lô tới 1.000 thông điệp mỗi giây | FIFO đạt 3.000/giây khi gộp lô | | Consumer phải nhận ĐÚNG THỨ TỰ | FIFO đảm bảo thứ tự |

⚠ Con số 1.000/giây là chi tiết quan trọng:

FIFO queue mặc định: 300 thông điệp/giây
    → KHÔNG đủ cho 1.000/giây
        ↓
    Nhưng khi GỘP LÔ (10 thông điệp mỗi lần gọi API):
    → 3.000 thông điệp/giây
        ↓
    Đề nói "batches" — đúng cách dùng

Tạo FIFO queue:

aws sqs create-queue --queue-name xu-ly-lo.fifo --attributes '{
  "FifoQueue":"true",
  "ContentBasedDeduplication":"true",
  "VisibilityTimeout":"300"}'

⚠ Tên hàng đợi FIFO BẮT BUỘC kết thúc bằng .fifo.

Gửi theo lô:

import boto3, json
sqs = boto3.client('sqs')

entries = [{
    'Id': str(i),
    'MessageBody': json.dumps(tin),
    'MessageGroupId': tin['nhom'],
    'MessageDeduplicationId': tin['ma']} for i, tin in enumerate(lo[:10])]

sqs.send_message_batch(QueueUrl=URL, Entries=entries)

⚠ MessageGroupId là khái niệm quan trọng nhất:

Thứ tự chỉ đảm bảo TRONG cùng một message group
    → group khác nhau xử lý SONG SONG được
        ↓
    Một group duy nhất  → thứ tự tuyệt đối, KHÔNG song song
    Nhiều group          → song song và vẫn giữ thứ tự trong mỗi group

Và nếu cần thông lượng cao hơn nữa:

aws sqs set-queue-attributes --queue-url $URL --attributes '{
  "FifoThroughputLimit":"perMessageGroupId",
  "DeduplicationScope":"messageGroup"}'

Chuyển giới hạn từ "cả hàng đợi" sang "mỗi message group"
    → high throughput mode: tới 70.000 thông điệp/giây

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thứ tự được đảm bảo | | | Giao ĐÚNG MỘT LẦN | không trùng | | Không có máy chủ nào để quản lý | |

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

• **B. Tạo một SQS Standard queue — đây là phương án gần nhất và có thông lượng không giới hạn, nhưng nó chỉ CỐ GẮNG giữ thứ tự, không đảm bảo, và có thể giao trùng. Đề nêu rõ yêu cầu thứ tự.
• **D. Tạo một SNS topic — SNS là mô hình đẩy, không lưu trữ và không đảm bảo thứ tự (trừ FIFO topic, nhưng phương án không nói vậy).
• **A. Tạo một Step Functions state machine — dịch vụ điều phối quy trình nhiều bước, không phải hàng đợi thông điệp. Và nó có giới hạn tần suất khởi động thấp hơn nhiều so với 1.000/giây.

Ghi nhớ

⚠ SQS Standard và FIFO — bảng phải thuộc: | | Standard | FIFO | |---|---|---| | Thứ tự | cố gắng, KHÔNG đảm bảo | đảm bảo trong message group | | Giao | ít nhất một lần (CÓ THỂ TRÙNG) | đúng một lần | | Thông lượng | không giới hạn | 300/giây (3.000 gộp lô) | | High throughput mode | — | tới 70.000/giây | | Tên hàng đợi | bất kỳ | phải kết thúc .fifo |

⚠ Ba mức thông lượng của FIFO — phải nhớ: | Chế độ | Thông lượng | |---|---| | Mặc định, không gộp lô | 300 thông điệp/giây | | Gộp lô 10 thông điệp | 3.000/giây | | High throughput mode | tới 70.000/giây (theo vùng) |

Từ khoá nhận diện:

"in the correct order", "exactly once" → SQS FIFO "maximum throughput, order doesn't matter" → SQS Standard "multiple consumers, replay" → Kinesis "orchestrate steps with state" → Step Functions

⚠ Kinesis cũng đảm bảo thứ tự — khi nào chọn cái nào: | | SQS FIFO | Kinesis Data Streams | |---|---|---| | Thứ tự theo | message group | partition key | | Sau khi xử lý | thông điệp XOÁ | dữ liệu VẪN CÒN | | Nhiều consumer độc lập | ❌ | ✅ | | Quản lý | không có gì | shard (hoặc on-demand) |

Hai cách chống trùng của FIFO: | Cách | Chi tiết | |---|---| | ContentBasedDeduplication | băm SHA-256 nội dung | | MessageDeduplicationId tường minh | bạn tự đặt |

⚠ Cửa sổ chống trùng là 5 PHÚT:

Gửi cùng MessageDeduplicationId hai lần trong 5 phút
    → lần thứ hai bị BỎ QUA (không lỗi, không cảnh báo)
        ↓
    Với dữ liệu hợp lệ giống hệt nhau, phải đặt id khác nhau

Ba tham số quan trọng: | Tham số | Mặc định | Lưu ý | |---|---|---| | Visibility timeout | 30 giây | ≥ thời gian xử lý | | Message retention | 4 ngày | tối đa 14 ngày | | WaitTimeSeconds | 0 | đặt 20 — long polling |

⚠ Dead-letter queue cho FIFO cũng phải là FIFO:

aws sqs create-queue --queue-name xu-ly-lo-loi.fifo \
  --attributes '{"FifoQueue":"true"}'

aws sqs set-queue-attributes --queue-url $URL --attributes '{
  "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"3\"}"}'

⚠ Lỗi một thông điệp chặn cả message group:

Thông điệp lỗi trong group A
    → mọi thông điệp sau nó trong group A bị chặn
    → group B, C vẫn chạy bình thường
        ↓
    DLQ tách thông điệp lỗi ra, group chạy tiếp

Ba lưu ý về gộp lô: | Lưu ý | Chi tiết | |---|---| | Tối đa 10 thông điệp mỗi lần gọi | | | Tổng payload tối đa 256 KB | | | Giảm cả chi phí lẫn tăng thông lượng | |

Ba lưu ý về payload lớn: | Lưu ý | Chi tiết | |---|---| | Giới hạn 256 KB mỗi thông điệp | | | Extended Client Library lưu nội dung vào S3 | | | Thông điệp chỉ chứa con trỏ | |

Ba lưu ý về consumer: | Lưu ý | Chi tiết | |---|---| | Số message group quyết định độ song song | | | Lambda xử lý mỗi group tuần tự | | | Chỉ gọi DeleteMessage sau khi xử lý xong | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng | | ApproximateAgeOfOldestMessage | có group nào bị kẹt không | | Số thông điệp trong DLQ | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | FIFO đắt hơn Standard một chút | | | Long polling giảm phí request | | | Gộp lô giảm số lần gọi API | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi 1.000 thông điệp/giây và đo | | | Kiểm tra thứ tự trong mỗi group | | | Kiểm tra không có thông điệp trùng | |

Và một lời khuyên: hãy chọn MessageGroupId sao cho có nhiều group nhất mà vẫn giữ đúng thứ tự nghiệp vụ. Dùng một group duy nhất là cách chắc chắn nhất để có thứ tự tuyệt đối — và cũng là cách chắc chắn nhất để thông lượng đứng yên ở 300 thông điệp mỗi giây, tức chưa tới một phần ba nhu cầu của đề.

Đáp án theo nguồn

D — Tạo một VPC security group cho ELB và dùng AWS Lambda tự động cập nhật dải IP nội bộ của CloudFront khi chúng thay đổi.

Vì sao đáp án nguồn chọn D

Đề nêu một yêu cầu cụ thể, và trong bốn lựa chọn chỉ D làm được: | Yêu cầu | Cách đáp ứng | |---|---| | Ngăn người dùng bỏ qua CloudFront, vào thẳng ELB | security group chỉ cho phép IP của CloudFront |

⚠ Vì sao OAI không dùng được ở đây:

Origin Access Identity CHỈ hoạt động với origin là S3
    → nó là một danh tính CloudFront dùng khi gọi S3
        ↓
    Với origin là ELB, OAI hoàn toàn không áp dụng
    → đây là lý do loại phương án B

Cách làm theo đáp án:

AWS công bố dải IP của mình tại ip-ranges.json
    → lọc các dải có service = "CLOUDFRONT_ORIGIN_FACING"
    → cập nhật security group của ELB
        ↓
    Dải IP đổi → AWS gửi thông báo SNS
    → Lambda tự cập nhật lại

Lambda cập nhật:

import json, urllib.request, boto3

def handler(event, context):
    du_lieu = json.loads(urllib.request.urlopen(
        'https://ip-ranges.amazonaws.com/ip-ranges.json').read())
    dai = [p['ip_prefix'] for p in du_lieu['prefixes']
           if p['service'] == 'CLOUDFRONT_ORIGIN_FACING']
    # cập nhật security group với danh sách dải này

Đăng ký nhận thông báo khi dải IP đổi:

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged \
  --protocol lambda --notification-endpoint <arn-lambda>

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

• **B. Tạo Origin Access Identity và gắn vào distribution — đây là phương án gần nhất vì OAI đúng là cơ chế khoá origin cho riêng CloudFront, nhưng nó chỉ dùng được với origin là S3. Với ELB thì không có tác dụng nào.
• **C. Dùng Network ACL giới hạn truy cập ELB — NACL lọc theo CIDR nhưng giới hạn 20 quy tắc (tối đa 40), trong khi CloudFront có hàng trăm dải IP. Không đủ chỗ.
• **A. Dùng signed URL hoặc signed cookie — chúng giới hạn ai xem được nội dung qua CloudFront, nhưng không ngăn ai đó gọi thẳng ELB.

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

Đáp án D đúng theo tài liệu cũ, nhưng AWS đã có hai cách tốt hơn nhiều và người học nên biết:

⚠ Cách 1 — CloudFront managed prefix list (từ 2022):

aws ec2 authorize-security-group-ingress --group-id sg-elb \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":443,"ToPort":443,
    "PrefixListIds":[{"PrefixListId":"pl-3b927c52"}]}]'

AWS duy trì prefix list "com.amazonaws.global.cloudfront.origin-facing"
    → AWS TỰ cập nhật khi dải IP đổi
        ↓
    KHÔNG cần Lambda, không cần theo dõi ip-ranges.json
    → đây là cách thay thế trực tiếp cho phương án D

Tìm prefix list ID:

aws ec2 describe-managed-prefix-lists \
  --filters "Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing"

⚠ Cách 2 — custom header bí mật (thường tốt hơn nữa):

CloudFront thêm một header bí mật vào mọi request tới origin
    → ALB listener rule chỉ chấp nhận request có header đó
        ↓
    Không phụ thuộc dải IP nào cả
    → và chặn được cả người biết IP của ALB

aws elbv2 create-rule --listener-arn <arn-listener> --priority 1 \
  --conditions '[{"Field":"http-header",
    "HttpHeaderConfig":{"HttpHeaderName":"X-Origin-Secret",
      "Values":["<chuoi-bi-mat-dai>"]}}]' \
  --actions Type=forward,TargetGroupArn=<arn-tg>

aws elbv2 create-rule --listener-arn <arn-listener> --priority 2 \
  --conditions '[{"Field":"path-pattern","Values":["/*"]}]' \
  --actions '[{"Type":"fixed-response","FixedResponseConfig":
    {"StatusCode":"403","ContentType":"text/plain",
     "MessageBody":"Truy cap truc tiep bi tu choi"}}]'

⚠ Cách tốt nhất là kết hợp cả hai:

Prefix list: chỉ CloudFront tới được ALB về mặt mạng
Custom header: chỉ ĐÚNG distribution của bạn được chấp nhận
        ↓
    Vì prefix list cho phép MỌI distribution của MỌI khách hàng AWS

Đây là chi tiết quan trọng: dải IP origin-facing dùng chung cho toàn bộ CloudFront, nên chỉ lọc IP thôi vẫn cho phép ai đó dựng distribution riêng trỏ vào ALB của bạn.

Ghi nhớ

⚠ Ba cách khoá origin cho riêng CloudFront — bảng phải thuộc: | Origin | Cách | |---|---| | Amazon S3 | OAC (hoặc OAI cũ) | | ALB / EC2 | prefix list + custom header | | Custom origin ngoài AWS | custom header |

Từ khoá nhận diện:

"prevent bypassing CloudFront to reach ALB" → prefix list + custom header "restrict S3 bucket to CloudFront" → OAC / OAI "limit who can view content" → signed URL / cookie "block by IP or country" → WAF / geo restriction

⚠ OAC và OAI — nhắc lại: | | OAC | OAI | |---|---|---| | Trạng thái | hiện hành (từ 08/2022) | cũ | | Origin hỗ trợ | S3, và một số dịch vụ khác | CHỈ S3 | | SSE-KMS | ✅ | ❌ |

Ba đặc điểm của managed prefix list: | Đặc điểm | Chi tiết | |---|---| | AWS tự duy trì và cập nhật | | | Dùng trong security group và route table | | | Đếm theo số entry vào giới hạn quy tắc | |

⚠ Prefix list đếm vào giới hạn 60 quy tắc:

Prefix list của CloudFront có nhiều entry
    → mỗi entry tính là một quy tắc
        ↓
    Kiểm tra MaxEntries và xin tăng giới hạn nếu cần

Ba lưu ý về custom header: | Lưu ý | Chi tiết | |---|---| | Dùng chuỗi ngẫu nhiên dài | | | Lưu trong Secrets Manager | | | Xoay định kỳ | |

Cấu hình ở CloudFront:

{"Origins": {"Items": [{
  "Id": "alb-goc",
  "DomainName": "alb-abc.ap-southeast-1.elb.amazonaws.com",
  "CustomOriginConfig": {"HTTPPort":80,"HTTPSPort":443,
    "OriginProtocolPolicy":"https-only"},
  "CustomHeaders": {"Quantity":1,"Items":[
    {"HeaderName":"X-Origin-Secret","HeaderValue":"<chuoi-bi-mat>"}]}}]}}

Ba lợi ích của cách custom header: | Lợi ích | Chi tiết | |---|---| | Không phụ thuộc dải IP | | | Chặn được distribution của người khác | | | Không cần Lambda hay theo dõi gì | |

Ba lưu ý về bảo mật tổng thể: | Lớp | Việc | |---|---| | WAF trên CloudFront | lọc tấn công tầng 7 | | Prefix list + custom header | chặn đường vòng | | Security group của EC2 | chỉ nhận từ ALB |

Ba lưu ý về ip-ranges.json: | Lưu ý | Chi tiết | |---|---| | AWS công bố công khai | | | Có topic SNS thông báo khi đổi | | | Lọc theo service và region | |

Ba service tag liên quan tới CloudFront: | Tag | Nghĩa | |---|---| | CLOUDFRONT | mọi IP của CloudFront | | CLOUDFRONT_ORIGIN_FACING | IP dùng khi gọi origin ← cần dải này | | GLOBALACCELERATOR | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi qua CloudFront | phải thành công | | Gọi thẳng tên miền ALB | phải nhận 403 | | Kiểm tra sau khi AWS cập nhật dải IP | |

Và một lời khuyên: khi dựng hệ thống thật, hãy dùng custom header thay vì lọc theo dải IP của CloudFront. Dải IP origin-facing dùng chung cho mọi khách hàng AWS, nên chỉ lọc IP vẫn cho phép bất kỳ ai dựng một distribution trỏ thẳng vào ALB của bạn — và họ sẽ đi qua đúng lớp lọc mà bạn vừa dựng.

Đáp án

C và E.

• C — Triển khai AWS Directory Service tích hợp với thư mục doanh nghiệp, và dùng IAM Identity Center để xác thực qua các tài khoản
• E — Tạo một AWS Organizations mới với tất cả tính năng bật, và tạo các tài khoản mới trong tổ chức đó

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này thoả hết: | Yêu cầu | Hành động | |---|---| | Chuyển từ nhiều tài khoản rời rạc sang cấu trúc đa tài khoản | E: Organizations với all features | | Tạo nhiều tài khoản cho các phòng ban | E: tạo trong tổ chức | | Xác thực bằng THƯ MỤC DOANH NGHIỆP tập trung | C: Directory Service + Identity Center |

⚠ "All features" là chi tiết bắt buộc:

AWS Organizations có hai chế độ:
    → Consolidated billing only: CHỈ gộp hoá đơn
    → All features: có SCP, có tích hợp dịch vụ khác
        ↓
    Không bật all features thì KHÔNG dùng được SCP
    → và không tích hợp được IAM Identity Center

Tạo tổ chức:

aws organizations create-organization --feature-set ALL

aws organizations create-account \
  --email aws+phong-ke-toan@congty.com \
  --account-name "Phong Ke Toan"

⚠ Và nối thư mục doanh nghiệp:

Directory Service có ba lựa chọn:
    → AD Connector: PROXY về AD tại chỗ
    → AWS Managed Microsoft AD: AD thật trên AWS, lập trust được
    → Simple AD: AD tối giản
        ↓
    Chọn theo việc muốn giữ AD ở đâu

Nối AD Connector:

aws ds connect-directory --name congty.local \
  --password '<mat-khau>' --size Small \
  --connect-settings VpcId=vpc-abc,SubnetIds=subnet-a,subnet-b,\
CustomerDnsIps=10.0.1.10,10.0.2.10,CustomerUserName=svc_aws

Cấu hình IAM Identity Center dùng AD làm nguồn danh tính:

aws sso-admin create-permission-set --instance-arn <arn-instance> \
  --name QuanTriPhongBan --session-duration PT8H

aws sso-admin create-account-assignment --instance-arn <arn-instance> \
  --target-id 111122223333 --target-type AWS_ACCOUNT \
  --permission-set-arn <arn-ps> \
  --principal-type GROUP --principal-id <id-nhom-ad>

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nơi quản lý danh tính cho mọi tài khoản | | | Nhân viên nghỉ việc: khoá ở AD là mất quyền mọi nơi | | | Credential TẠM, không có access key dài hạn | |

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

• **A. Cài AWS Control Tower và kết hợp IAM Identity Center — đây là phương án gần nhất và thực ra là cách làm tốt hơn trong thực tế, nhưng nó không nhắc tới việc nối THƯ MỤC DOANH NGHIỆP mà đề nêu rõ. Control Tower dựng landing zone nhưng nguồn danh tính vẫn phải cấu hình riêng.
• **B. Dùng Amazon Cognito user pool và cho Identity Center chấp nhận Cognito — sai vai trò dịch vụ: Cognito quản lý danh tính người dùng ứng dụng, không phải nhân viên truy cập tài nguyên AWS. Và Identity Center không nhận Cognito làm nguồn danh tính.
• **D. Dựng Transit Gateway quản lý mạng tập trung — Transit Gateway giải quyết vấn đề kết nối mạng, hoàn toàn không liên quan tới xác thực và quản lý tài khoản.

Ghi nhớ

⚠ Ba dịch vụ quản trị đa tài khoản — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS Organizations | cấu trúc tài khoản, OU, SCP | | IAM Identity Center | truy cập tập trung cho nhân viên | | AWS Control Tower | dựng landing zone (dùng cả hai cái trên) |

⚠ Hai chế độ của Organizations: | Chế độ | Có gì | |---|---| | Consolidated billing only | chỉ gộp hoá đơn | | All features | SCP, tích hợp dịch vụ, tag policy |

Luôn chọn ALL features
    → chuyển từ billing-only sang all features cần
      MỌI tài khoản thành viên chấp nhận

Từ khoá nhận diện:

"multi-account + corporate directory" → Organizations + Directory Service + Identity Center "landing zone with guardrails" → Control Tower "app users sign up and sign in" → Cognito "connect VPCs" → Transit Gateway

⚠ Ba dịch vụ thư mục của AWS: | Dịch vụ | Đặc điểm | |---|---| | AWS Managed Microsoft AD | AD THẬT trên AWS, lập trust được | | AD Connector | PROXY, không lưu dữ liệu | | Simple AD | AD tối giản (Samba) |

⚠ AD Connector và Managed AD — chọn cái nào:

AD Connector:  ít việc hơn, nhưng PHỤ THUỘC hoàn toàn
               vào kết nối tới AD tại chỗ
        ↓
Managed AD:    có bản sao trên AWS, chịu được mất kết nối
               nhưng phải quản lý trust

Ba nguồn danh tính cho IAM Identity Center: | Nguồn | Khi nào | |---|---| | Identity Center directory | chưa có IdP | | Active Directory | có AD ← câu này | | IdP ngoài qua SAML 2.0 | Okta, Entra ID |

Ba khái niệm của Identity Center: | Khái niệm | Nghĩa | |---|---| | Permission set | tập quyền tái dùng | | Account assignment | (nhóm) × (permission set) × (tài khoản) | | Session duration | 1-12 giờ |

⚠ Gán quyền cho NHÓM, không gán cho từng người:

Thêm nhân viên mới: chỉ cần thêm vào nhóm AD
    → không phải đụng gì tới AWS
        ↓
    Nghỉ việc: khoá tài khoản AD là mất quyền mọi nơi

Ba lợi ích bảo mật: | Lợi ích | Chi tiết | |---|---| | Không có IAM user, không có access key dài hạn | | | Credential tạm, tự hết hạn | | | Mọi lần đăng nhập ghi vào CloudTrail | |

⚠ Ba bước triển khai theo thứ tự: | Bước | Chi tiết | |---|---| | 1. Tạo Organizations với all features | | | 2. Bật IAM Identity Center ở tài khoản quản lý | | | 3. Nối nguồn danh tính và tạo permission set | |

Ba lưu ý về Control Tower (nếu dùng): | Lưu ý | Chi tiết | |---|---| | Tự dựng Organizations, Identity Center, tài khoản log | | | Có guardrail dựng sẵn | | | Account Factory tạo tài khoản theo mẫu | |

⚠ Control Tower là cách làm tốt hơn cho dự án mới:

Nó dựng sẵn mọi thứ mà phương án C và E phải làm bằng tay
    → cộng thêm guardrail và bảng điều khiển tuân thủ
        ↓
    Nhưng đề chọn C và E vì chúng nêu rõ
    việc nối thư mục doanh nghiệp

Ba lưu ý về tạo tài khoản: | Lưu ý | Chi tiết | |---|---| | Mỗi tài khoản cần EMAIL DUY NHẤT | | | Dùng subaddressing hoặc alias | | | Tạo tài khoản mất vài phút | |

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | Cần all features mới dùng được | | | KHÔNG cấp quyền, chỉ giới hạn | | | Không áp cho tài khoản quản lý | |

Ba lưu ý về ABAC: | Lưu ý | Chi tiết | |---|---| | Truyền thuộc tính AD làm session tag | | | Policy dùng aws:PrincipalTag | | | Giảm số permission set phải tạo | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập bằng tài khoản AD | | | Kiểm tra thấy đúng danh sách tài khoản | | | Khoá một tài khoản AD, xác nhận mất quyền | |

Và một lời khuyên: hãy bật "all features" ngay khi tạo Organizations. Chuyển từ chế độ chỉ gộp hoá đơn sang all features về sau đòi hỏi mọi tài khoản thành viên phải chấp nhận — với vài chục tài khoản của nhiều phòng ban, đó là một chiến dịch email dài chứ không phải một thao tác.

Đáp án

C — Tạo một IAM role với quyền tối thiểu và gắn vào instance profile của EC2.

Vì sao đúng

Đề hỏi cách AN TOÀN NHẤT để EC2 truy cập S3, và IAM role là cơ chế chuẩn: | Yêu cầu | Cách đáp ứng | |---|---| | EC2 cần quyền truy cập S3 | role cấp credential tạm cho instance | | AN TOÀN NHẤT | không có khoá dài hạn nào để rò rỉ |

⚠ Vì sao role an toàn hơn access key:

Access key: tồn tại vĩnh viễn cho tới khi ai đó xoay
    → nằm trong tệp cấu hình, biến môi trường, hoặc mã
    → rò rỉ là mất quyền vĩnh viễn
        ↓
IAM role: credential TẠM, AWS tự luân chuyển
    → không có gì để rò rỉ
    → thu hồi bằng cách sửa policy, có hiệu lực ngay

Tạo role và instance profile:

aws iam create-role --role-name VaiTroDocS3 \
  --assume-role-policy-document '{"Version":"2012-10-17",
    "Statement":[{"Effect":"Allow",
      "Principal":{"Service":"ec2.amazonaws.com"},
      "Action":"sts:AssumeRole"}]}'

aws iam put-role-policy --role-name VaiTroDocS3 \
  --policy-name QuyenS3 --policy-document '{"Version":"2012-10-17",
    "Statement":[
      {"Effect":"Allow","Action":"s3:ListBucket",
       "Resource":"arn:aws:s3:::kho-tep"},
      {"Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],
       "Resource":"arn:aws:s3:::kho-tep/*"}]}'

aws ec2 associate-iam-instance-profile --instance-id i-abc123 \
  --iam-instance-profile Name=VaiTroDocS3

⚠ Quyền cấp bucket và cấp object khác nhau:

s3:ListBucket → Resource là "arn:aws:s3:::kho-tep"   (KHÔNG có /*)
s3:GetObject  → Resource là "arn:aws:s3:::kho-tep/*" (CÓ /*)
        ↓
    Nhầm chỗ này là lỗi AccessDenied khó hiểu nhất với S3

Trong mã không cần làm gì:

import boto3
s3 = boto3.client('s3')      # SDK tự lấy credential từ instance profile
s3.get_object(Bucket='kho-tep', Key='du-lieu.json')

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Credential tạm, tự luân chuyển | | | Không có khoá nào trong mã hay đĩa | | | Sửa policy có hiệu lực gần như ngay | |

⚠ Và nên chặn truy cập IMDSv1:

aws ec2 modify-instance-metadata-options --instance-id i-abc123 \
  --http-tokens required --http-endpoint enabled

IMDSv1 dễ bị khai thác qua lỗ hổng SSRF
    → IMDSv2 yêu cầu token, chặn được kiểu tấn công đó

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

• **D. Tạo một IAM user cho ứng dụng với quyền cụ thể trên bucket — đây là phương án gần nhất vì cũng giới hạn quyền đúng, nhưng IAM user đi kèm access key dài hạn phải lưu ở đâu đó trên máy. Đó chính là thứ role loại bỏ.
• **A. Sinh access key và lưu credential trên EC2 — kém an toàn nhất: khoá tồn tại vĩnh viễn, nằm trên đĩa, và ai đọc được máy là có quyền.
• **B. Tạo bucket ACL với instance ID làm grantee — không có cơ chế này: ACL của S3 cấp quyền cho tài khoản AWS hoặc nhóm định sẵn, không nhận instance ID. Và AWS khuyến nghị tắt hẳn ACL, dùng bucket policy thay thế.

Ghi nhớ

⚠ Ba cách cấp quyền AWS cho tải chạy trên AWS — bảng phải thuộc: | Nơi chạy | Cơ chế | |---|---| | EC2 | instance profile (IAM role) | | ECS task | task role (taskRoleArn) | | EKS pod | IRSA hoặc Pod Identity | | Lambda | execution role |

Nguyên tắc gốc:

KHÔNG BAO GIỜ đặt access key dài hạn vào mã, ảnh máy, hay biến môi trường. Luôn dùng role — credential tạm thời, tự luân chuyển.

Từ khoá nhận diện:

"most securely grant EC2 access" → IAM role + instance profile "ECS task needs permissions" → task role "application outside AWS needs access" → IAM Roles Anywhere hoặc access key có xoay | "cross-account access" → assume role

⚠ Ba khái niệm dễ lẫn: | Khái niệm | Nghĩa | |---|---| | IAM role | tập quyền có thể được "đóng vai" | | Instance profile | vỏ bọc để gắn role vào EC2 | | IAM user | danh tính lâu dài, có access key |

Một instance profile chứa ĐÚNG MỘT role
    → console tự tạo instance profile khi bạn gắn role cho EC2
    → dùng CLI thì phải tạo tường minh

⚠ Ba trục của đặc quyền tối thiểu: | Trục | Siết bằng | |---|---| | Action | liệt kê cụ thể, không dùng * | | Resource | ARN cụ thể, có thể tới tiền tố | | Condition | thêm ràng buộc |

Giới hạn tới một tiền tố:

{"Effect":"Allow","Action":"s3:GetObject",
 "Resource":"arn:aws:s3:::kho-tep/ung-dung-a/*"}

⚠ Và s3:ListBucket cần điều kiện prefix:

{"Effect":"Allow","Action":"s3:ListBucket",
 "Resource":"arn:aws:s3:::kho-tep",
 "Condition":{"StringLike":{"s3:prefix":["ung-dung-a/*"]}}}

Ba lưu ý về IMDS: | Lưu ý | Chi tiết | |---|---| | Credential lấy từ 169.254.169.254 | | | IMDSv2 yêu cầu token — an toàn hơn | | | Đặt hop limit = 1 để container không lấy được | |

⚠ Container trên EC2 lấy được credential của instance:

aws ec2 modify-instance-metadata-options --instance-id i-abc \
  --http-put-response-hop-limit 1 --http-tokens required

Không giới hạn hop
    → container gọi được IMDS
    → lấy credential của INSTANCE PROFILE
        ↓
    Phá vỡ mọi phân quyền ở cấp task

Ba lưu ý về S3 ACL: | Lưu ý | Chi tiết | |---|---| | AWS khuyến nghị TẮT hẳn ACL | | | Dùng bucket policy thay thế | | | Object Ownership = BucketOwnerEnforced | |

aws s3api put-bucket-ownership-controls --bucket kho-tep \
  --ownership-controls '{"Rules":[
    {"ObjectOwnership":"BucketOwnerEnforced"}]}'

Ba lưu ý cho bucket nhiều tệp nhỏ: | Lưu ý | Chi tiết | |---|---| | Phí request có thể vượt phí lưu trữ | | | Gộp tệp nếu quy trình cho phép | | | Nhớ ngưỡng 128 KB của lớp IA | |

Ba công cụ kiểm chứng quyền: | Công cụ | Việc | |---|---| | aws sts get-caller-identity | xem đang là danh tính nào | | IAM Policy Simulator | thử trước | | IAM Access Analyzer | sinh policy từ CloudTrail thật |

⚠ Access Analyzer sinh policy rất hữu ích:

Đọc CloudTrail xem role THỰC SỰ dùng những API nào
    → sinh ra policy đặc quyền tối thiểu
        ↓
    Kết quả gần như luôn ngắn hơn policy viết tay "cho chắc"

Ba lưu ý về VPC endpoint: | Lưu ý | Chi tiết | |---|---| | Gateway endpoint cho S3 MIỄN PHÍ | | | Không đi qua Internet hay NAT | | | Endpoint policy giới hạn bucket được truy cập | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | SSE-S3 là mặc định từ 01/2023 | | | SSE-KMS cần thêm quyền kms:Decrypt | | | Bật S3 Bucket Key giảm phí KMS | |

⚠ Quên kms:Decrypt là lỗi hay gặp:

Cấp s3:GetObject nhưng bucket mã hoá SSE-KMS
    → AccessDenied nhắc tới KMS
    → dễ tưởng là lỗi quyền S3

Ba việc kiểm chứng: | Việc | Cách | |---|---| | aws sts get-caller-identity trên máy | | | Thử aws s3 ls và aws s3 cp | | | Xác nhận không có access key nào trên đĩa | |

Và một lời khuyên: hãy bật IMDSv2 bắt buộc và đặt hop limit = 1 cùng lúc với việc gắn role. IAM role loại bỏ access key trên đĩa, nhưng nếu IMDS còn mở rộng thì một lỗ hổng SSRF trong ứng dụng vẫn lấy được credential — và lúc đó bạn quay lại đúng vấn đề mà role sinh ra để giải quyết.

Đáp án

D — Dựng một S3 bucket, sửa ứng dụng để lưu tài liệu vào S3, và giữ metadata của object trong CSDL hiện có.

Vì sao đúng

Đề nêu bốn dữ kiện, và tách blob ra khỏi CSDL là lời giải: | Dữ kiện | Vấn đề | |---|---| | **Tài liệu 6 MB lưu dạng BLOB trong Oracle | CSDL không thiết kế cho object lớn | | CSDL lớn dần, hiệu năng GIẢM | blob chiếm hết I/O và buffer cache | | Chi phí lưu trữ TĂNG | 12 TB gp3 đắt hơn S3 nhiều lần | | Cần sẵn sàng cao và bền | S3: 11 số 9 độ bền, đa AZ |

⚠ Vì sao lưu blob trong CSDL quan hệ là mô hình sai:

Mỗi truy vấn đọc một hàng có blob 6 MB
    → 6 MB đi qua buffer cache
    → đẩy dữ liệu chỉ mục và bảng nóng ra khỏi bộ nhớ
        ↓
    Toàn bộ CSDL chậm đi, không chỉ truy vấn tài liệu

Tính thử chi phí: | Kho | Giá tương đối mỗi GB-tháng | |---|---| | EBS gp3 | ~1,0× | | S3 Standard | ~0,35× | | S3 Standard-IA | ~0,19× | | S3 Glacier Instant Retrieval | ~0,07× |

12 TB blob trên EBS → chuyển sang S3
    → tiết kiệm ngay khoảng 65% phí lưu trữ
    → cộng thêm việc thu nhỏ được instance RDS

Mô hình sau khi tách:

Ứng dụng ghi tài liệu:
    1. PUT object vào S3, nhận về key
    2. INSERT vào Oracle: id, tên, ngày, ma_nguoi_dung, s3_key

Ứng dụng đọc tài liệu:
    1. SELECT metadata từ Oracle
    2. GET object từ S3 (hoặc trả presigned URL)

Presigned URL để client tải thẳng:

url = s3.generate_presigned_url(
    'get_object',
    Params={'Bucket': 'kho-tai-lieu', 'Key': ban_ghi['s3_key']},
    ExpiresIn=900)

Client tải thẳng từ S3
    → không đi qua máy chủ ứng dụng
    → giảm tải và giảm phí truyền

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | CSDL nhỏ lại, hiệu năng phục hồi | | | Chi phí lưu trữ giảm mạnh | | | S3 bền và sẵn sàng hơn EBS | |

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

{"Rules":[{"ID":"tai-lieu-cu","Status":"Enabled","Filter":{},
  "Transitions":[
    {"Days":90,"StorageClass":"STANDARD_IA"},
    {"Days":365,"StorageClass":"GLACIER_IR"}]}]}

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

• **B. Tăng cỡ instance RDS, tăng dung lượng lên 24 TiB, đổi sang Provisioned IOPS — đây là phương án gần nhất vì thực sự cải thiện hiệu năng, nhưng nó làm chi phí tăng mạnh thay vì giảm, và không giải quyết nguyên nhân gốc là blob nằm sai chỗ.
• **C. Thu nhỏ instance, tăng dung lượng lên 24 TiB, dùng magnetic storage — magnetic là loại lưu trữ đời cũ, hiệu năng thấp nhất. Ngược hẳn yêu cầu cải thiện hiệu năng.
• **A. Chuyển sang DynamoDB bằng DMS — DynamoDB giới hạn 400 KB mỗi item, không chứa nổi tài liệu 6 MB. Và chuyển từ Oracle sang DynamoDB là viết lại toàn bộ tầng dữ liệu.

Ghi nhớ

⚠ Bảng chọn kho lưu trữ theo loại dữ liệu — phải thuộc: | Loại dữ liệu | Kho | |---|---| | Object lớn (tài liệu, ảnh, video) | Amazon S3 | | Bản ghi nhỏ, tra cứu theo khoá | DynamoDB (tối đa 400 KB/item) | | Dữ liệu quan hệ, cần JOIN | RDS / Aurora | | Hệ thống tệp chia sẻ | EFS / FSx |

⚠ Mẫu kiến trúc chuẩn: metadata trong CSDL, nội dung trong S3.

CSDL giữ: id, tên tệp, kích thước, ngày, người tạo, s3_key
S3 giữ:   nội dung tệp
        ↓
    Truy vấn và lọc bằng SQL trên metadata (nhanh)
    → lấy nội dung từ S3 khi cần

Từ khoá nhận diện:

"blobs in database" + "performance degraded" + "storage costs" → tách sang S3 "400 KB limit" → DynamoDB không chứa được file lớn "need JOIN and transactions" → giữ CSDL quan hệ cho metadata "shared file system for EC2" → EFS / FSx

⚠ Ba giới hạn kích thước cần nhớ: | Dịch vụ | Giới hạn | |---|---| | DynamoDB item | 400 KB | | SQS message | 256 KB | | S3 object | 5 TB | | Lambda payload đồng bộ | 6 MB |

Ba lợi ích của S3 cho tài liệu: | Lợi ích | Chi tiết | |---|---| | 11 số 9 độ bền, đa AZ tự động | | | Không giới hạn dung lượng | | | Lifecycle chuyển tầng tự động | |

⚠ Ba bước di chuyển blob ra khỏi CSDL: | Bước | Chi tiết | |---|---| | 1. Thêm cột s3_key vào bảng | | | 2. Script đọc blob, ghi vào S3, cập nhật s3_key | | | 3. Xoá cột blob và thu nhỏ dung lượng | |

⚠ Bước 3 với RDS có ràng buộc:

RDS KHÔNG giảm được allocated storage
    → chỉ tăng được
        ↓
    Muốn thu nhỏ: tạo instance mới và di chuyển dữ liệu
    → dùng DMS để giảm thời gian ngừng

Ba lưu ý về nhất quán: | Lưu ý | Chi tiết | |---|---| | Ghi S3 trước, ghi CSDL sau | | | Nếu ghi CSDL lỗi → object mồ côi trong S3 | | | Dùng lifecycle hoặc job dọn object mồ côi | |

⚠ Object mồ côi là vấn đề thật:

Ghi S3 thành công, ghi CSDL thất bại
    → object nằm trong S3 mà không ai biết
        ↓
    Chạy job định kỳ so sánh S3 Inventory với CSDL
    → hoặc dùng S3 Event Notification xác nhận

S3 Inventory để đối chiếu:

aws s3api put-bucket-inventory-configuration --bucket kho-tai-lieu \
  --id kiem-ke-hang-tuan --inventory-configuration '{
    "Destination":{"S3BucketDestination":{
      "Bucket":"arn:aws:s3:::kho-bao-cao","Format":"Parquet"}},
    "IsEnabled":true,"Id":"kiem-ke-hang-tuan",
    "IncludedObjectVersions":"Current",
    "Schedule":{"Frequency":"Weekly"}}'

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá SSE-KMS | | | Block Public Access | | | Presigned URL có hạn ngắn | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Đặt CloudFront trước S3 nếu tài liệu hay đọc | | | Multipart upload cho tệp lớn | | | Transfer Acceleration nếu người dùng ở xa | |

Ba lưu ý về Oracle trên RDS: | Lưu ý | Chi tiết | |---|---| | Có License Included và BYOL | | | Multi-AZ dùng Oracle Data Guard | | | Không có quyền SYSDBA | |

Ba lưu ý về chi phí sau khi tách: | Khoản | Chi tiết | |---|---| | Thu nhỏ được instance RDS | ít RAM và IOPS hơn | | Giảm dung lượng EBS | | | Lifecycle chuyển tài liệu cũ sang lớp rẻ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo hiệu năng truy vấn trước và sau | | | So số bản ghi và số object | | | Kiểm tra không có object mồ côi | |

Và một lời khuyên: hãy ghi vào S3 trước rồi mới ghi metadata vào CSDL. Thứ tự ngược lại tạo ra bản ghi trỏ tới một object không tồn tại — và lỗi đó chỉ lộ ra khi người dùng bấm tải tài liệu, tức là rất lâu sau khi nguyên nhân đã trôi qua.

Đáp án

D — Amazon ElastiCache for Memcached.

Vì sao đúng

Đề nêu hai đặc điểm của tầng cache cũ, và Memcached khớp cả hai: | Đặc điểm | Cách đáp ứng | |---|---| | Cache TRONG BỘ NHỚ | Memcached là in-memory | | ĐA LUỒNG (multi-threaded) | Memcached đa luồng GỐC |

⚠ "Multi-threaded" là từ khoá quyết định duy nhất:

Memcached: đa luồng từ thiết kế
    → tận dụng được nhiều core của một node
        ↓
Redis: về cơ bản là ĐƠN LUỒNG cho việc xử lý lệnh
    → (Redis 6+ có I/O threads nhưng lệnh vẫn chạy đơn luồng)
        ↓
    Đề nói rõ "multi-threaded" → Memcached

Tạo cụm Memcached:

aws elasticache create-cache-cluster \
  --cache-cluster-id cum-cache \
  --engine memcached --cache-node-type cache.r7g.large \
  --num-cache-nodes 3 \
  --cache-subnet-group-name nhom-subnet-rieng-tu \
  --security-group-ids sg-cache

Client kết nối qua auto discovery:

from pymemcache.client.hash import HashClient
client = HashClient([
    ('cum-cache.abc.cfg.apse1.cache.amazonaws.com', 11211)])
client.set('khoa', 'gia-tri', expire=300)

Ba đặc điểm của Memcached: | Đặc điểm | Chi tiết | |---|---| | Đa luồng | tận dụng nhiều core | | Mô hình dữ liệu đơn giản | chỉ key-value chuỗi | | Mở rộng ngang bằng cách thêm node | |

⚠ Và ba thứ Memcached KHÔNG có: | Thiếu | Hệ quả | |---|---| | Nhân bản | mất node là mất dữ liệu trên node đó | | Bền vững (snapshot) | khởi động lại là mất sạch | | Cấu trúc dữ liệu phong phú | không có list, set, sorted set |

Với vai trò CACHE thuần tuý thì những thứ đó không cần
    → dữ liệu mất thì đọc lại từ CSDL

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

• **C. ElastiCache for Redis — đây là phương án gần nhất và là lựa chọn mặc định cho hầu hết trường hợp, nhưng Redis xử lý lệnh đơn luồng. Đề nêu rõ tầng cache cũ là đa luồng, nên Memcached là bản thay thế sát hơn.
• **B. DynamoDB DAX — cache chỉ dành cho DynamoDB, không dùng làm cache cho CSDL quan hệ.
• **A. Amazon RDS MySQL — là CSDL trên đĩa, không phải cache trong bộ nhớ.

Ghi nhớ

⚠ Redis và Memcached — bảng phải thuộc: | | Redis | Memcached | |---|---|---| | Đa luồng | đơn luồng xử lý lệnh | ✅ đa luồng gốc | | Cấu trúc dữ liệu | list, set, sorted set, hash, stream | chỉ chuỗi | | Nhân bản | ✅ | ❌ | | Multi-AZ, tự động failover | ✅ | ❌ | | Bền vững (snapshot) | ✅ | ❌ | | Pub/Sub | ✅ | ❌ | | Giao dịch | ✅ | ❌ | | Phân mảnh | cluster mode | đơn giản, thêm node |

⚠ Cách chọn nhanh trong đề thi:

Đề nhắc "multi-threaded", "simple", "horizontal scaling"
    → Memcached

Đề nhắc "replication", "persistence", "sorted set",
        "leaderboard", "pub/sub", "high availability"
    → Redis

Từ khoá nhận diện:

"multi-threaded in-memory cache" → Memcached "in-memory + replication/persistence" → Redis "cache for DynamoDB" → DAX "in-memory DATABASE, durable" → MemoryDB for Redis

⚠ MemoryDB là dịch vụ thứ ba cần biết: | | ElastiCache for Redis | MemoryDB for Redis | |---|---|---| | Vai trò | CACHE (dữ liệu có thể mất) | CSDL CHÍNH (bền vững) | | Ghi | vào bộ nhớ | ghi vào transaction log đa AZ | | Độ bền | snapshot định kỳ | không mất dữ liệu |

Ba mẫu cache: | Mẫu | Cách hoạt động | |---|---| | Lazy loading (cache-aside) | đọc cache trước, trượt thì đọc CSDL rồi lưu | | Write-through | ghi vào cả cache và CSDL | | TTL | để dữ liệu tự hết hạn |

Mẫu cache-aside:

def lay_du_lieu(ma):
    kq = client.get(f'du-lieu:{ma}')
    if kq:
        return json.loads(kq)
    kq = truy_van_csdl(ma)
    client.set(f'du-lieu:{ma}', json.dumps(kq), expire=300)
    return kq

⚠ Ba vấn đề kinh điển của cache: | Vấn đề | Chi tiết | |---|---| | Cache stampede | nhiều request cùng trượt cache, dồn vào CSDL | | Hot key | một khoá bị đọc quá nhiều | | Cache invalidation | biết khi nào phải xoá |

Chống stampede:

TTL hết đúng lúc cao điểm
    → hàng nghìn request cùng trượt
    → tất cả dồn vào CSDL cùng lúc
        ↓
    Dùng khoá tạm cho phép MỘT tiến trình nạp lại
    → hoặc thêm jitter vào TTL

Ba đặc điểm của Memcached auto discovery: | Đặc điểm | Chi tiết | |---|---| | Có configuration endpoint | client tự tìm node | | Thêm bớt node không cần sửa client | | | Cần client hỗ trợ auto discovery | |

⚠ Ba chính sách khi hết bộ nhớ: | Chính sách | Hành vi | |---|---| | Memcached: LRU | tự đẩy khoá ít dùng nhất | | Redis allkeys-lru | tương tự | | Redis noeviction | từ chối ghi mới |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả cache | | Evictions | bộ nhớ đầy | | CurrConnections | |

⚠ Evictions tăng là tín hiệu rõ ràng:

Bộ nhớ đầy → đẩy khoá cũ ra
    → tỷ lệ trúng cache giảm
        ↓
    Tăng cỡ node, thêm node, hoặc rút ngắn TTL

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Đặt trong subnet RIÊNG TƯ | | | Security group chỉ cho ứng dụng vào cổng 11211 | | | Memcached hỗ trợ mã hoá in-transit (bản mới) | |

⚠ Memcached có ít tuỳ chọn bảo mật hơn Redis:

Redis: AUTH token, RBAC, IAM authentication
Memcached: SASL (hạn chế), mã hoá in-transit
        ↓
    Với dữ liệu nhạy cảm, Redis có nhiều lựa chọn hơn

Ba lưu ý về mở rộng: | Lưu ý | Chi tiết | |---|---| | Memcached: thêm node là thêm dung lượng | | | Thêm/bớt node làm phân bố khoá thay đổi | | | Dùng consistent hashing ở client | |

Ba lựa chọn thay thế: | Lựa chọn | Khi nào | |---|---| | ElastiCache Serverless | không muốn chọn cỡ node | | Redis | cần nhân bản hoặc cấu trúc dữ liệu | | DAX | cache cho DynamoDB |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo tỷ lệ trúng cache sau vài ngày | | | So độ trễ truy vấn trước và sau | | | Theo dõi tải CSDL giảm bao nhiêu | |

Và một lời khuyên: hãy cân nhắc lại xem có thực sự cần đa luồng không trước khi chọn Memcached. Trong đề thi thì "multi-threaded" là từ khoá rõ ràng, nhưng khi thiết kế thật, khả năng nhân bản và Multi-AZ của Redis thường đáng giá hơn lợi thế đa luồng — nhất là khi cache đã trở thành đường tới hạn của ứng dụng.