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

Đáp án

**B và E — Dựng một hàng đợi SQS đệm việc ghi vào bảng DynamoDB để giảm thông lượng ghi phải cấp phát; và tạo một bảng DynamoDB mới mỗi ngày, xoá bảng của ngày hôm trước sau khi dữ liệu đã được ghi sang S3.

Vì sao đúng

Đề mô tả hai khoản chi phí riêng biệt, và mỗi đáp án cắt một khoản: | Khoản chi | Cách cắt | |---|---| | Thông lượng GHI đã cấp phát | SQS đệm, làm phẳng đỉnh | | Lưu trữ dữ liệu cũ trong DynamoDB | xoá cả bảng mỗi ngày |

⚠ Điểm mấu chốt thứ nhất: ghi mỗi 2 phút từ nhiều người dùng tạo đỉnh không đều:

50.000 người dùng ghi mỗi 2 phút
        ↓
    Nhưng không đồng đều theo thời gian
        ↓
    Phải cấp thông lượng cho ĐỈNH
        ↓
    SQS đệm → ghi đều đặn
    → cấp thông lượng cho mức TRUNG BÌNH

Tính thông lượng cần:

50.000 người × 1 lần / 120 giây
        ↓
    ≈ 417 ghi mỗi giây trung bình
        ↓
    Nhưng đỉnh có thể gấp 3-5 lần
        ↓
    Cấp cho đỉnh: lãng phí
    → SQS làm phẳng: cấp 500 WCU là đủ

⚠ Và 2 KB mỗi lần ghi cần 2 WCU:

Một WCU = 1 KB
        ↓
    2 KB → 2 WCU mỗi lần ghi
        ↓
    417 ghi/giây × 2 = 834 WCU
        ↓
    Với đỉnh gấp ba → 2.500 WCU
    → chênh lệch rất lớn về chi phí

Lambda đọc từ SQS và ghi theo lô:

import boto3, json
bang = boto3.resource('dynamodb').Table(f'suc-khoe-{ngay_hom_nay}')

def xu_ly(event, context):
    with bang.batch_writer() as lo:
        for r in event['Records']:
            dl = json.loads(r['body'])
            lo.put_item(Item=dl)

⚠ batch_writer gộp thành BatchWriteItem — giảm số lời gọi:

25 mục mỗi lời gọi BatchWriteItem
        ↓
    Ít lời gọi API hơn
        ↓
    Nhưng WCU tiêu thụ không đổi
    → tiết kiệm ở độ trễ và số yêu cầu

⚠ Điểm mấu chốt thứ hai: xoá cả BẢNG rẻ hơn xoá từng mục:

`DeleteItem` cho hàng triệu bản ghi
        ↓
    Mỗi lần xoá tốn WCU
        ↓
    50.000 người × 720 lần/ngày
    = 36 triệu mục
        ↓
    Xoá bằng DeleteItem: 72 triệu WCU
        ↓
    `DeleteTable`: MIỄN PHÍ

Đây là lý do phương án A thua — nó xoá từng mục.

Xoay bảng theo ngày:

aws dynamodb create-table \
  --table-name suc-khoe-2026-09-02 \
  --attribute-definitions \
    AttributeName=ma_nguoi_dung,AttributeType=S \
    AttributeName=thoi_diem,AttributeType=S \
  --key-schema \
    AttributeName=ma_nguoi_dung,KeyType=HASH \
    AttributeName=thoi_diem,KeyType=RANGE \
  --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=900

aws dynamodb delete-table --table-name suc-khoe-2026-09-01

⚠ Và quy trình quét ban đêm hưởng lợi từ bảng theo ngày:

Bảng chỉ chứa dữ liệu của một ngày
        ↓
    `Scan` chỉ quét đúng phần cần
        ↓
    Bảng gộp nhiều ngày → quét cả
      lịch sử
    → tốn RCU rất nhiều

⚠ Và vì sao phương án D sai — phục vụ từ DynamoDB đắt hơn S3:

D nói phục vụ insight TRỰC TIẾP từ
  DynamoDB thay vì JSON trên S3
        ↓
    1 MB mỗi người dùng
        ↓
    Đọc 1 MB tốn 128 RCU (eventually
      consistent)
        ↓
    50.000 người đọc mỗi sáng
    → 6,4 triệu RCU
        ↓
    S3: vài xu cho cùng lượng dữ liệu

⚠ Và DynamoDB có giới hạn kích thước mục 400 KB:

Tệp insight 1 MB mỗi người
        ↓
    Vượt giới hạn 400 KB
        ↓
    Phải chia nhỏ hoặc lưu ở S3
    → D không khả thi về kỹ thuật

⚠ Và vì sao phương án C không giải quyết đúng vấn đề:

C dùng DAX cache đọc từ DynamoDB
        ↓
    DAX giảm RCU cho việc ĐỌC LẶP LẠI
        ↓
    Nhưng mẫu ở đây là: mỗi người
      đọc insight CỦA MÌNH, một lần
        ↓
    Không có lặp lại để cache
    → DAX là chi phí thêm không có
      lợi ích

⚠ Và DAX là một cụm phải trả tiền theo giờ:

Cụm DAX nhỏ nhất ≈ 0,04 USD/giờ
      mỗi node
        ↓
    Ba node cho sẵn sàng cao
        ↓
    ~87 USD/tháng
    → cho một cache gần như không
      bao giờ hit

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cấp thông lượng theo trung bình, không theo đỉnh | | | Xoá dữ liệu cũ hoàn toàn miễn phí | | | Quét ban đêm chỉ chạm dữ liệu của ngày đó | |

⚠ Và ứng dụng phải biết tên bảng của hôm nay:

Bảng đổi tên mỗi ngày
        ↓
    Ứng dụng phải tính tên hoặc tra
      Parameter Store
        ↓
    Đây là cái giá của mẫu bảng theo
      thời gian

import boto3
ssm = boto3.client('ssm')
ten_bang = ssm.get_parameter(
    Name='/suc-khoe/bang-hom-nay')['Parameter']['Value']

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

⚠ TTL và on-demand là hai cơ chế hiện đại hơn hẳn cho bài toán này.

TTL thay cho việc xoay bảng:

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

On-demand thay cho việc đệm bằng SQS:

aws dynamodb update-table --table-name suc-khoe \
  --billing-mode PAY_PER_REQUEST

Không phải đoán công suất
        ↓
    Tự chịu đỉnh gấp đôi mức cao nhất
        ↓
    Trả theo lượng ghi thật
    → bỏ được cả hàng đợi SQS

Và DynamoDB Export to S3 thay cho việc Scan ban đêm:

aws dynamodb export-table-to-point-in-time \
  --table-arn <arn-bang> \
  --s3-bucket ket-qua-tong-hop \
  --export-format DYNAMODB_JSON

Export KHÔNG tiêu RCU
        ↓
    Scan toàn bảng tốn RCU theo
      dung lượng
        ↓
    Đây là khoản tiết kiệm mà đề
      không nhắc tới

Với kiến thức hiện tại, kiến trúc tối ưu là: DynamoDB on-demand + TTL + Export to S3 + Athena — bỏ được cả SQS, cả việc xoay bảng, và cả việc Scan.

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

• **A. Xoá tất cả mục của ngày hôm trước sau khi dữ liệu đã ghi sang S3 — đây là phương án gần nhất và đạt cùng kết quả về mặt dữ liệu, nhưng xoá từng mục tốn WCU cho mỗi lần xoá, trong khi DeleteTable hoàn toàn miễn phí.
• **C. Dùng DAX cache việc đọc từ DynamoDB — mẫu truy cập ở đây là mỗi người đọc dữ liệu của riêng mình một lần, không có lặp lại để cache.
• **D. Phục vụ insight trực tiếp từ DynamoDB thay vì JSON trên S3 — tệp 1 MB vượt giới hạn kích thước mục 400 KB, và chi phí RCU cao hơn S3 rất nhiều.

Ghi nhớ

⚠ Bốn cách giảm chi phí DynamoDB — bảng phải thuộc: | Cách | Giảm gì | |---|---| | On-demand hoặc SQS đệm | không cấp thừa thông lượng ghi | | TTL hoặc DeleteTable | chi phí lưu trữ | | Export to S3 thay Scan | chi phí RCU | | Standard-IA table class | lưu trữ cho bảng ít đọc |

Từ khoá nhận diện:

"buffer writes, reduce provisioned throughput" → SQS hoặc on-demand "delete all data from a day" → DeleteTable hoặc TTL "export table for analysis" → Export to S3, không tốn RCU "cache repeated reads" → DAX, chỉ khi có lặp lại

⚠ Chi phí xoá — bảng phải thuộc: | Cách | Chi phí | |---|---| | DeleteTable | miễn phí | | TTL | miễn phí | | DeleteItem | tốn WCU | | BatchWriteItem xoá | tốn WCU |

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | Thuộc tính phải là số, epoch giây | | | Xoá trong vòng vài ngày sau hạn | | | Mục hết hạn vẫn hiện trong truy vấn tới khi xoá thật | |

Ba lưu ý về on-demand: | Lưu ý | Chi tiết | |---|---| | Chịu được đỉnh gấp đôi mức cao nhất trước đó | | | Đắt hơn provisioned cho tải ổn định | | | Chuyển qua lại được, mỗi 24 giờ một lần | |

⚠ Điểm hoà vốn giữa hai chế độ:

Mức dùng dưới ~18% công suất cấp
  phát
        ↓
    On-demand rẻ hơn
        ↓
    Trên đó → provisioned rẻ hơn
        ↓
    Với đỉnh không đều thì on-demand
      thường thắng

Ba lưu ý về SQS làm bộ đệm: | Lưu ý | Chi tiết | |---|---| | Làm phẳng đỉnh, không mất dữ liệu | | | Thêm độ trễ vài giây | | | MaximumConcurrency bảo vệ DynamoDB | |

Ba lưu ý về thiết kế khoá: | Lưu ý | Chi tiết | |---|---| | Partition key là mã người dùng | | | Sort key là thời điểm | | | Đừng dùng ngày làm partition key | |

Ba lưu ý về Export to S3: | Lưu ý | Chi tiết | |---|---| | Cần bật point-in-time recovery | | | Không tiêu RCU | | | Xuất được ở dạng DynamoDB JSON hoặc ION | |

Ba lưu ý về phục vụ insight: | Cách | Chi phí | |---|---| | S3 + CloudFront | rẻ nhất | | S3 pre-signed URL | rẻ, có kiểm soát truy cập | | DynamoDB | đắt hơn nhiều cho tệp lớn |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem ConsumedWriteCapacityUnits thật | | | So với công suất đã cấp | | | Kiểm ThrottledRequests về 0 | |

Và một lời khuyên: hãy so mức tiêu thụ thật với công suất đã cấp trước khi tối ưu bất cứ thứ gì. Rất nhiều bảng DynamoDB được cấp phát theo con số ước lượng ban đầu và không ai xem lại — và biểu đồ ConsumedWriteCapacityUnits thường cho thấy khoản tiết kiệm lớn hơn mọi thay đổi kiến trúc.

Đáp án

**C — Dựng VPC Flow Log cho các elastic network interface gắn với instance, cấu hình lọc theo lưu lượng bị TỪ CHỐI, và đẩy flow log vào CloudWatch Logs.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Ghi lại kết nối THẤT BẠI | filter REJECT | | Chỉ các EC2 instance đó | flow log ở cấp ENI | | Hiệu quả chi phí nhất | lọc trước, không ghi mọi thứ |

⚠ Điểm mấu chốt: flow log đặt được ở BA cấp, và cấp ENI là hẹp nhất: | Cấp | Phạm vi | |---|---| | VPC | mọi ENI trong VPC | | Subnet | mọi ENI trong subnet | | ENI | chỉ một network interface |

Đề nói "các EC2 instance" cụ thể
        ↓
    Cấp ENI là hẹp nhất
        ↓
    Không ghi thừa lưu lượng của
      tài nguyên khác
    → rẻ nhất

⚠ Và bộ lọc REJECT là chỗ tiết kiệm lớn nhất:

Ghi ALL: mọi luồng, cả thành công
  lẫn thất bại
        ↓
    Lưu lượng bình thường chiếm
      99%+
        ↓
    Chỉ ghi REJECT
    → giảm lượng log hàng trăm lần

Tạo flow log ở cấp ENI:

aws ec2 create-flow-logs \
  --resource-type NetworkInterface \
  --resource-ids eni-0abc123 eni-0def456 \
  --traffic-type REJECT \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flow-log-tu-choi \
  --deliver-logs-permission-arn <arn-role>

⚠ Và --traffic-type có ba giá trị: | Giá trị | Ghi gì | |---|---| | ACCEPT | chỉ lưu lượng được chấp nhận | | REJECT | chỉ lưu lượng bị từ chối | | ALL | cả hai |

⚠ Và vì sao hai phương án di trú VPC (A, B) là việc thừa:

A và B nói "di trú instance sang
  một VPC riêng"
        ↓
    Để đặt flow log ở cấp VPC
        ↓
    Nhưng flow log đặt được ở cấp
      ENI ngay
    → không cần di trú gì
        ↓
    Di trú instance là việc lớn, có
      rủi ro, và tốn thời gian

⚠ Và vì sao phương án D đắt hơn:

D đẩy flow log vào Kinesis Data
  Streams rồi mới sang S3
        ↓
    Phải trả phí shard-giờ
        ↓
    Và phải viết consumer hoặc dùng
      Firehose
        ↓
    CloudWatch Logs nhận trực tiếp
    → ít một thành phần

⚠ Và flow log gửi thẳng được vào ba đích: | Đích | Đặc điểm | |---|---| | CloudWatch Logs | truy vấn ngay bằng Insights, đắt hơn khi lưu lâu | | S3 | rẻ nhất, truy vấn bằng Athena | | Firehose | linh hoạt, biến đổi được |

Kinesis Data Streams KHÔNG phải
  đích trực tiếp
        ↓
    Phải qua Firehose
        ↓
    Phương án D mô tả một luồng
      phức tạp hơn cần thiết

⚠ Nhưng S3 rẻ hơn CloudWatch Logs nếu lưu lâu: | Đích | Giá xấp xỉ | |---|---| | CloudWatch Logs nạp | 0,50 USD/GB | | CloudWatch Logs lưu | 0,03 USD/GB-tháng | | S3 (qua flow log) | 0,25 USD/GB nạp + 0,023 lưu |

Đề nói "hiệu quả chi phí nhất"
        ↓
    S3 rẻ hơn cho lưu trữ dài hạn
        ↓
    Nhưng CloudWatch Logs cho phép
      truy vấn và cảnh báo ngay
    → đề chọn CloudWatch Logs

Truy vấn log bị từ chối bằng Logs Insights:

fields @timestamp, srcAddr, dstAddr, dstPort, protocol
| filter action = "REJECT"
| stats count() as so_lan by srcAddr, dstPort
| sort so_lan desc
| limit 20

⚠ Và có thể đặt cảnh báo khi có quá nhiều kết nối bị từ chối:

aws logs put-metric-filter \
  --log-group-name /vpc/flow-log-tu-choi \
  --filter-name dem-tu-choi \
  --filter-pattern '[version, account, eni, source, destination,
                     srcport, destport, protocol, packets, bytes,
                     windowstart, windowend, action=REJECT, flowlogstatus]' \
  --metric-transformations \
    metricName=KetNoiBiTuChoi,metricNamespace=BaoMat,metricValue=1

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ ghi đúng thứ cần | | | Không phải di trú instance | | | Truy vấn và cảnh báo được ngay | |

⚠ Và flow log KHÔNG ghi mọi loại lưu lượng:

Không ghi:
    - lưu lượng tới Amazon DNS
      (VPC_CIDR + 2)
    - lưu lượng tới metadata service
      (169.254.169.254)
    - DHCP
    - lưu lượng tới địa chỉ dành riêng
      của VPC router

⚠ Và flow log là bản GHI TỔNG HỢP, không phải từng gói:

Mỗi dòng là một LUỒNG trong một
  cửa sổ thời gian
        ↓
    Cửa sổ mặc định 10 phút
    → hoặc 1 phút nếu khai
        ↓
    Muốn xem từng gói → Traffic
      Mirroring

--max-aggregation-interval 60

⚠ Và định dạng tuỳ chỉnh cho thêm nhiều trường hữu ích:

--log-format '${version} ${srcaddr} ${dstaddr} ${srcport} \
${dstport} ${protocol} ${action} ${flow-direction} \
${pkt-src-aws-service} ${pkt-dst-aws-service} ${traffic-path}'

`pkt-dst-aws-service` cho biết lưu
  lượng đi tới dịch vụ AWS nào
        ↓
    Rất hữu ích để tìm chi phí NAT
      bất ngờ
        ↓
    `flow-direction` phân biệt vào/ra

⚠ Và trường log-status cho biết log có đầy đủ không: | Giá trị | Nghĩa | |---|---| | OK | dữ liệu bình thường | | NODATA | không có lưu lượng trong cửa sổ | | SKIPDATA | một số bản ghi bị BỎ QUA |

`SKIPDATA` xuất hiện khi lưu lượng
  quá lớn
        ↓
    Flow log không phải công cụ
      kiểm toán đầy đủ tuyệt đối

⚠ Và REJECT không phân biệt được security group với NACL:

Flow log ghi `REJECT`
        ↓
    Nhưng không nói ai từ chối
        ↓
    Security group stateful → chỉ
      thấy REJECT chiều vào
        ↓
    NACL stateless → thấy REJECT cả
      hai chiều
    → suy luận từ đó

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

• **A. Di trú instance sang một VPC riêng, cấu hình flow log lọc REJECT, đẩy vào CloudWatch Logs — đây là phương án gần nhất và cấu hình flow log hoàn toàn đúng, nhưng việc di trú instance sang VPC mới là thừa vì flow log đặt được ngay ở cấp ENI.
• **B. Di trú sang VPC riêng, flow log lọc REJECT, đẩy qua Firehose vào S3 — cùng vấn đề di trú thừa, và thêm một thành phần vào đường dữ liệu.
• **D. Flow log ở cấp ENI lọc REJECT, đẩy vào Kinesis Data Streams rồi sang S3 — Kinesis Data Streams không phải đích trực tiếp của flow log, và phải trả phí shard.

Ghi nhớ

⚠ Ba cấp đặt VPC Flow Log — bảng phải thuộc: | Cấp | Dùng khi | |---|---| | VPC | cần bức tranh toàn bộ | | Subnet | một tầng ứng dụng | | ENI | vài instance cụ thể — rẻ nhất |

Từ khoá nhận diện:

"log failed connections" → flow log với traffic-type REJECT "specific instances only" → flow log ở cấp ENI "inspect packet contents" → Traffic Mirroring, không phải flow log "cheapest long-term storage" → S3, không phải CloudWatch Logs

Ba đích của flow log: | Đích | Ưu điểm | |---|---| | CloudWatch Logs | truy vấn và cảnh báo ngay | | S3 | rẻ nhất, Athena truy vấn | | Firehose | biến đổi, gửi sang SIEM |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo GB log sinh ra | | | Lọc REJECT giảm mạnh nhất | | | Đặt retention cho log group | |

⚠ Log group không đặt retention lưu VĨNH VIỄN:

aws logs put-retention-policy \
  --log-group-name /vpc/flow-log-tu-choi \
  --retention-in-days 90

Ba lưu ý về định dạng: | Trường hữu ích | Cho biết | |---|---| | pkt-dst-aws-service | đi tới dịch vụ AWS nào | | flow-direction | vào hay ra | | traffic-path | đi qua NAT, IGW, hay peering |

Ba lưu ý về những gì flow log KHÔNG ghi: | Không ghi | Ghi chú | |---|---| | DNS tới Amazon Resolver | dùng Resolver query log | | Metadata service | 169.254.169.254 | | Nội dung gói tin | dùng Traffic Mirroring |

Ba lưu ý về phân tích: | Công cụ | Việc | |---|---| | Logs Insights | truy vấn gần thời gian thực | | Athena | truy vấn log trên S3 | | Security Lake | chuẩn hoá theo OCSF |

Ba lưu ý về chẩn đoán mạng: | Công cụ | Việc | |---|---| | Reachability Analyzer | phân tích cấu hình, chỉ ra chỗ chặn | | Flow log | xem lưu lượng thật | | Traffic Mirroring | xem nội dung gói |

⚠ Reachability Analyzer chỉ ra chính xác thành phần nào chặn:

aws ec2 create-network-insights-path \
  --source i-nguon --destination i-dich \
  --protocol tcp --destination-port 443

Kết quả nói: security group nào,
  NACL nào, route table nào
        ↓
    Nhanh hơn nhiều so với đọc flow
      log

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cố ý gửi một kết nối bị chặn | | | Tìm dòng REJECT tương ứng trong log | | | So lượng log với ước tính chi phí | |

Và một lời khuyên: hãy đặt flow log ở cấp hẹp nhất đủ dùng và lọc ngay từ đầu. Chi phí flow log tính theo lượng dữ liệu sinh ra, và một cấu hình ALL ở cấp VPC trên một môi trường bận rộn có thể tạo ra hoá đơn lớn hơn cả chi phí của chính những instance mà nó đang giám sát.

Đáp án

**D — Tạo một bucket S3 mới làm đích sao chép; tạo một quy tắc S3 Replication Time Control (S3 RTC) trên bucket nguồn lọc theo tiền tố của loại yêu cầu bồi thường giá trị cao và sao chép sang bucket mới; dùng S3 event notification để phát cảnh báo khi thời gian sao chép vượt ngưỡng.

Vì sao đúng

Đề nêu hai yêu cầu về thời gian, và S3 RTC đáp ứng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Sao chép sang bucket khác, xử lý trong một giờ | RTC bảo đảm 99,99% trong 15 phút | | Báo cho đội kiểm toán nếu quá 15 phút | sự kiện OperationFailedReplication |

⚠ Điểm mấu chốt: S3 RTC là tính năng có SLA về thời gian sao chép:

Cross-Region Replication thường:
  không cam kết thời gian
        ↓
    RTC: 99,99% object sao chép
      trong 15 PHÚT
        ↓
    Có SLA, có chỉ số CloudWatch
    → đúng thứ đề cần

Cấu hình RTC:

aws s3api put-bucket-replication --bucket ho-so-boi-thuong \
  --replication-configuration '{
    "Role": "arn:aws:iam::111122223333:role/S3Replication",
    "Rules": [{
      "ID": "boi-thuong-gia-tri-cao",
      "Priority": 1,
      "Status": "Enabled",
      "Filter": {"Prefix": "gia-tri-cao/"},
      "DeleteMarkerReplication": {"Status": "Disabled"},
      "Destination": {
        "Bucket": "arn:aws:s3:::ho-so-gia-tri-cao",
        "ReplicationTime": {
          "Status": "Enabled",
          "Time": {"Minutes": 15}},
        "Metrics": {
          "Status": "Enabled",
          "EventThreshold": {"Minutes": 15}}}}]}'

⚠ ReplicationTime và Metrics phải bật CÙNG NHAU:

`ReplicationTime`: bật SLA 15 phút
        ↓
    `Metrics` với `EventThreshold`:
      phát sự kiện khi vượt ngưỡng
        ↓
    Bật RTC mà không bật Metrics
    → có SLA nhưng không biết khi
      nào vi phạm

⚠ Điểm mấu chốt thứ hai: sự kiện vượt ngưỡng là S3 EVENT, không phải EventBridge rule:

S3 phát sự kiện
  `s3:Replication:OperationMissedThreshold`
        ↓
    Đây là S3 EVENT NOTIFICATION
        ↓
    Cấu hình trong notification
      configuration của bucket

Đây là lý do phương án C sai — nó dùng EventBridge rule.

Cấu hình thông báo:

aws s3api put-bucket-notification-configuration \
  --bucket ho-so-boi-thuong \
  --notification-configuration '{
    "TopicConfigurations": [{
      "TopicArn": "arn:aws:sns:ap-southeast-1:111122223333:canh-bao-kiem-toan",
      "Events": [
        "s3:Replication:OperationMissedThreshold",
        "s3:Replication:OperationFailedReplication",
        "s3:Replication:OperationNotTracked"]}]}'

⚠ Và bốn sự kiện sao chép của S3 — phải nhớ: | Sự kiện | Khi nào | |---|---| | OperationMissedThreshold | vượt ngưỡng 15 phút | | OperationReplicatedAfterThreshold | sao chép xong nhưng đã trễ | | OperationFailedReplication | sao chép thất bại | | OperationNotTracked | object không được RTC theo dõi |

⚠ Và EventBridge cũng nhận được sự kiện đó — nhưng phải bật riêng:

Bật `EventBridgeConfiguration` trên
  bucket
        ↓
    Mọi sự kiện S3 đi vào EventBridge
        ↓
    Rồi tạo rule khớp
        ↓
    Thêm một bước so với gửi thẳng
      tới SNS

⚠ Đây là điểm phân biệt giữa C và D — chỉ khác cơ chế thông báo:

C: EventBridge rule
        ↓
    D: S3 event notification
        ↓
    Cả hai hoạt động được
        ↓
    Nhưng D trực tiếp hơn
    → và đề hỏi "nhanh chóng triển
      khai được"

⚠ Và vì sao phương án A không đạt yêu cầu:

A dùng S3 event notification gọi
  Lambda dùng S3 Transfer Acceleration
  để chép
        ↓
    Phải viết và bảo trì mã Lambda
        ↓
    Không có SLA nào về thời gian
        ↓
    Và S3TA là để tăng tốc tải lên
      từ XA, không phải chép giữa
      hai bucket

⚠ Và chép giữa hai bucket cùng Region không cần S3TA:

S3TA đưa lưu lượng qua điểm biên
  CloudFront
        ↓
    Hai bucket cùng Region đã ở gần
      nhau
        ↓
    S3TA không giúp gì
    → và có thể chậm hơn

⚠ Và vì sao phương án B sai — DataSync chạy theo lịch:

DataSync chuyển dữ liệu theo LỊCH
        ↓
    Lịch tối thiểu là mỗi giờ
        ↓
    Đề đòi phát hiện trong 15 phút
    → và xử lý trong một giờ
        ↓
    DataSync không đáp ứng được độ
      trễ đó

⚠ Và bộ lọc theo tiền tố là chi tiết quan trọng:

Chỉ yêu cầu bồi thường GIÁ TRỊ CAO
  cần sao chép
        ↓
    Filter theo prefix
        ↓
    Không sao chép mọi thứ
    → và không trả phí RTC cho dữ
      liệu không cần

⚠ Và RTC tính phí thêm ngoài phí sao chép thường:

CRR thường: phí truyền dữ liệu +
  phí PUT ở đích
        ↓
    RTC: cộng thêm phí theo GB
      (~0,015 USD/GB)
        ↓
    Lọc theo tiền tố giữ khoản này
      trong tầm kiểm soát

⚠ Và cả hai bucket đều phải bật versioning:

aws s3api put-bucket-versioning --bucket ho-so-boi-thuong \
  --versioning-configuration Status=Enabled
aws s3api put-bucket-versioning --bucket ho-so-gia-tri-cao \
  --versioning-configuration Status=Enabled

Thiếu versioning → không bật được
  replication
        ↓
    Đây là điều kiện tiên quyết

⚠ Và replication chỉ áp cho object MỚI:

Bật quy tắc hôm nay
        ↓
    Object đã có KHÔNG được sao chép
        ↓
    Dùng S3 Batch Replication cho
      dữ liệu cũ

aws s3control create-job --account-id 111122223333 \
  --operation '{"S3ReplicateObject": {}}' \
  --manifest-generator '{"S3JobManifestGenerator": {
    "SourceBucket": "arn:aws:s3:::ho-so-boi-thuong",
    "Filter": {"ObjectReplicationStatuses": ["NONE"]}}}' \
  --role-arn <arn-role> --priority 10 --no-confirmation-required

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Có SLA về thời gian sao chép | | | Không phải viết mã nào | | | Cảnh báo tự động khi vi phạm ngưỡng | |

⚠ Và có thể theo dõi bằng chỉ số CloudWatch:

aws cloudwatch put-metric-alarm \
  --alarm-name sao-chep-tre \
  --namespace AWS/S3 \
  --metric-name ReplicationLatency \
  --dimensions Name=SourceBucket,Value=ho-so-boi-thuong \
               Name=DestinationBucket,Value=ho-so-gia-tri-cao \
               Name=RuleId,Value=boi-thuong-gia-tri-cao \
  --statistic Maximum --period 300 \
  --evaluation-periods 1 --threshold 900 \
  --comparison-operator GreaterThanThreshold

⚠ Và ba chỉ số của RTC: | Chỉ số | Ý nghĩa | |---|---| | ReplicationLatency | độ trễ sao chép tính bằng giây | | BytesPendingReplication | còn bao nhiêu chưa chép | | OperationsPendingReplication | còn bao nhiêu object |

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

• **C. Dựng bucket mới, tạo quy tắc S3 RTC lọc theo tiền tố, và dùng EventBridge rule để phát cảnh báo khi vượt ngưỡng — đây là phương án gần nhất và chỉ khác đáp án đúng ở cơ chế thông báo, nhưng sự kiện vượt ngưỡng của RTC là S3 event notification; dùng EventBridge phải bật thêm một bước và không trực tiếp bằng.
• **A. Dùng S3 event notification gọi Lambda dùng S3 Transfer Acceleration để chép — phải viết và bảo trì mã, không có SLA nào, và S3TA không giúp gì khi chép giữa hai bucket cùng Region.
• **B. Lập lịch chuyển định kỳ bằng DataSync — DataSync chạy theo lịch với chu kỳ tối thiểu một giờ, không đáp ứng ngưỡng 15 phút.

Ghi nhớ

⚠ Ba cách sao chép giữa hai bucket S3 — bảng phải thuộc: | Cách | Độ trễ | SLA | |---|---|---| | S3 Replication thường | thường vài phút | KHÔNG | | S3 RTC | 99,99% trong 15 phút | CÓ | | DataSync | theo lịch, tối thiểu một giờ | không | | Lambda tự viết | tuỳ mã | không |

Từ khoá nhận diện:

"replicate within a guaranteed time" → S3 RTC "alert if replication is late" → OperationMissedThreshold "replicate only some prefixes" → filter trong replication rule "replicate existing objects" → S3 Batch Replication

Ba lưu ý về S3 Replication: | Lưu ý | Chi tiết | |---|---| | Cần versioning ở CẢ HAI bucket | | | Chỉ sao chép object mới sau khi bật | | | Sao chép được cùng Region (SRR) hoặc liên Region (CRR) | |

⚠ Đề này là sao chép CÙNG Region:

Bucket nguồn và đích cùng Region
        ↓
    Đó là Same-Region Replication
      (SRR)
        ↓
    RTC hỗ trợ cả SRR lẫn CRR
        ↓
    SRR không có phí truyền liên Region
    → rẻ hơn

Ba lưu ý về filter: | Loại filter | Chi tiết | |---|---| | Prefix | theo đường dẫn | | Tag | theo thẻ object | | And | kết hợp prefix và nhiều thẻ |

Ba lưu ý về RTC: | Lưu ý | Chi tiết | |---|---| | Phí thêm theo GB sao chép | | | Metrics phải bật cùng ReplicationTime | | | SLA 99,99% trong 15 phút | |

Ba lưu ý về những gì KHÔNG được sao chép: | Không sao chép | Ghi chú | |---|---| | Object đã có trước khi bật | dùng Batch Replication | | Object mã hoá bằng SSE-C | không hỗ trợ | | Delete marker | trừ khi bật tường minh |

⚠ DeleteMarkerReplication cần cân nhắc kỹ:

Bật: xoá ở nguồn → xoá ở đích
        ↓
    Tắt: đích giữ lại
        ↓
    Với dữ liệu tuân thủ
    → thường tắt để giữ bản sao

Ba lưu ý về sự kiện S3: | Đích | Ghi chú | |---|---| | SNS | cần topic policy cho S3 | | SQS | cần queue policy, và key policy nếu có SSE | | Lambda | cần resource-based policy | | EventBridge | chỉ cần bật cờ |

Ba lưu ý về vai trò sao chép: | Quyền cần | Ở bucket nào | |---|---| | s3:GetObjectVersionForReplication | nguồn | | s3:ReplicateObject, s3:ReplicateDelete | đích | | kms:Decrypt / kms:Encrypt | nếu có mã hoá |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải một object và đo thời gian tới đích | | | Kiểm ReplicationLatency trong CloudWatch | | | Xem x-amz-replication-status của object | |

aws s3api head-object --bucket ho-so-boi-thuong \
  --key gia-tri-cao/ho-so.pdf \
  --query 'ReplicationStatus'

Và một lời khuyên: hãy bật Metrics cùng lúc với ReplicationTime. RTC cho bạn cam kết 15 phút nhưng không tự nói khi nào nó không giữ được cam kết đó — và chính sự kiện vượt ngưỡng mới là thứ đề bài yêu cầu để mở ticket cho đội kiểm toán.

Đáp án

**A — Cấu hình connection draining trên Elastic Load Balancer.

Vì sao đúng

Đề mô tả một triệu chứng rất cụ thể, gắn với việc co giãn vào:

Tải bình thường: 4 instance
        ↓
    Đỉnh: thêm 10 instance
        ↓
    Khách hàng báo request timeout
      và trang tải dở dang
        ↓
    → yêu cầu bị NGẮT giữa chừng

⚠ Điểm mấu chốt: khi ASG thu về, instance bị chấm dứt NGAY:

Hết đỉnh, ASG scale-in
        ↓
    Chọn instance để chấm dứt
        ↓
    Không có connection draining
    → mọi kết nối đang mở bị CẮT
        ↓
    Trình duyệt đang tải trang
    → trang tải dở dang

⚠ Và "trang tải dở dang" là dấu hiệu kinh điển:

HTML đã tải xong
        ↓
    Đang tải ảnh, CSS, JS
        ↓
    Instance bị chấm dứt giữa chừng
    → một phần tài nguyên không tải
      được
        ↓
    Đúng như đề mô tả

Bật connection draining:

aws elbv2 modify-target-group-attributes \
  --target-group-arn <arn-tg> \
  --attributes \
    Key=deregistration_delay.timeout_seconds,Value=300

⚠ Và tên gọi đã đổi — cần biết cả hai: | Loại | Tên gọi | |---|---| | Classic Load Balancer | Connection Draining | | ALB, NLB | Deregistration Delay |

Cùng một cơ chế
        ↓
    Đề dùng tên cũ "connection
      draining"
    → nhưng ý nghĩa như nhau

⚠ Và cơ chế hoạt động thế nào:

Instance được đánh dấu gỡ đăng ký
        ↓
    Load balancer NGỪNG gửi yêu cầu
      MỚI tới nó
        ↓
    Nhưng vẫn cho yêu cầu ĐANG XỬ LÝ
      hoàn tất
        ↓
    Hết `deregistration_delay` hoặc
      hết kết nối → thật sự gỡ

⚠ Và vì sao phương án C không giải quyết được:

C cấu hình chính sách chấm dứt
        ↓
    Nó quyết định instance NÀO bị
      chấm dứt
        ↓
    Không quyết định CÁCH chấm dứt
        ↓
    Instance nào cũng bị cắt kết nối
      như nhau

⚠ Và bốn chính sách chấm dứt — hữu ích nhưng không phải câu trả lời: | Chính sách | Chọn instance nào | |---|---| | Default | AZ nhiều nhất → launch config cũ nhất | | OldestInstance | chạy lâu nhất | | NewestInstance | mới nhất | | ClosestToNextInstanceHour | sắp sang giờ tính phí mới |

⚠ Và vì sao phương án B không phù hợp:

B bật sticky session
        ↓
    Giữ một người dùng ở một instance
        ↓
    Nhưng instance đó bị chấm dứt
    → NGƯỜI DÙNG ĐÓ vẫn mất kết nối
        ↓
    Thậm chí tệ hơn: mất cả phiên

⚠ Và sticky session làm co giãn vào nguy hiểm hơn:

Không sticky: mất một instance
  → người dùng chuyển sang máy khác
        ↓
    Có sticky: mất instance
    → người dùng mất phiên đăng nhập
        ↓
    Trừ khi phiên lưu ở ElastiCache

⚠ Và vì sao phương án D giải quyết đúng vấn đề NGƯỢC LẠI:

D thêm lifecycle hook cho sự kiện
  SCALE-OUT
        ↓
    Để instance sẵn sàng trước khi
      nhận lưu lượng
        ↓
    Đó là vấn đề khi MỞ RỘNG
        ↓
    Nhưng triệu chứng ở đây xảy ra
      khi THU VỀ

⚠ Nhưng lifecycle hook cho scale-IN thì lại rất hữu ích:

aws autoscaling put-lifecycle-hook \
  --lifecycle-hook-name rut-em \
  --auto-scaling-group-name doi-ung-dung \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 300 \
  --default-result CONTINUE

Giữ instance ở trạng thái
  `Terminating:Wait`
        ↓
    Đủ thời gian để: đẩy log ra,
      hoàn tất việc nền, rút êm
        ↓
    Bổ trợ cho connection draining

⚠ Và health check grace period là vấn đề khác nữa:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name doi-ung-dung \
  --health-check-type ELB \
  --health-check-grace-period 300

Instance mới cần thời gian khởi
  động ứng dụng
        ↓
    Grace period quá ngắn
    → ASG coi nó hỏng và chấm dứt
        ↓
    Vòng lặp chấm dứt vô tận

Ba lợi ích của connection draining: | Lợi ích | Chi tiết | |---|---| | Yêu cầu đang xử lý được hoàn tất | | | Không có timeout khi co giãn vào | | | Cũng áp dụng khi triển khai và khi instance hỏng | |

⚠ Và giá trị deregistration_delay cần chọn đúng:

Mặc định 300 giây
        ↓
    Quá ngắn: yêu cầu dài bị cắt
        ↓
    Quá dài: co giãn vào chậm, vẫn
      trả tiền instance
        ↓
    Đặt bằng thời gian yêu cầu lâu
      nhất + biên

⚠ Và với kết nối WebSocket hoặc tải tệp lớn thì cần dài hơn:

Tải tệp 500 MB mất 10 phút
        ↓
    Delay 300 giây → cắt giữa chừng
        ↓
    Đặt 900 giây (tối đa 3.600)

⚠ Và ASG cooldown là khái niệm khác — dễ nhầm: | Cơ chế | Việc | |---|---| | deregistration_delay | cho yêu cầu đang xử lý hoàn tất | | ASG cooldown | chờ giữa hai hoạt động co giãn | | health-check-grace-period | chờ instance mới sẵn sàng |

⚠ Và có thể theo dõi quá trình rút êm:

aws elbv2 describe-target-health \
  --target-group-arn <arn-tg> \
  --query 'TargetHealthDescriptions[?TargetHealth.State==`draining`]'

Trạng thái `draining`
        ↓
    Đang chờ kết nối hoàn tất
        ↓
    Xong → biến mất khỏi target group

⚠ Và ứng dụng nên bắt tín hiệu để rút êm chủ động:

import signal, sys

dang_tat = False

def xu_ly_tin_hieu(signum, frame):
    global dang_tat
    dang_tat = True

signal.signal(signal.SIGTERM, xu_ly_tin_hieu)

@app.route('/health')
def suc_khoe():
    if dang_tat:
        return 'DANG_TAT', 503
    return 'OK', 200

Nhận SIGTERM → trả 503 ở health
  check
        ↓
    Load balancer ngừng gửi yêu cầu
      mới ngay
        ↓
    Rồi hoàn tất việc đang làm

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

• **D. Thêm lifecycle hook cho sự kiện scale-out để bảo đảm instance sẵn sàng trước khi nhận lưu lượng — đây là phương án gần nhất và lifecycle hook thật sự là công cụ đúng cho loại vấn đề này, nhưng nó giải quyết chiều ngược lại: vấn đề trong đề xảy ra khi thu về, không phải khi mở rộng.
• **C. Cấu hình chính sách chấm dứt để chọn instance nào bị bỏ trước — quyết định instance nào, không quyết định cách ngắt kết nối.
• **B. Bật sticky session — giữ người dùng ở một instance, và khi instance đó bị chấm dứt thì họ mất cả kết nối lẫn phiên.

Ghi nhớ

⚠ Bốn cơ chế thời gian của ELB và ASG — bảng phải thuộc: | Cơ chế | Việc | Mặc định | |---|---|---| | deregistration_delay | cho yêu cầu hoàn tất khi gỡ | 300 giây | | health-check-grace-period | chờ instance mới sẵn sàng | 300 giây | | ASG cooldown | chờ giữa hai lần co giãn | 300 giây | | Lifecycle hook heartbeat | giữ instance ở trạng thái chờ | 3.600 giây |

Từ khoá nhận diện:

"timeouts and partially loaded pages during scale-in" → connection draining "instance not ready when receiving traffic" → lifecycle hook scale-out hoặc grace period "which instance to terminate" → termination policy "keep user on same instance" → sticky session

Ba lưu ý về deregistration delay: | Lưu ý | Chi tiết | |---|---| | Mặc định 300 giây, tối đa 3.600 | | | Đặt bằng thời gian yêu cầu lâu nhất | | | Áp cả khi triển khai và khi instance hỏng | |

Ba lưu ý về lifecycle hook: | Lưu ý | Chi tiết | |---|---| | Có hook cho cả launch và terminate | | | Phải gọi complete-lifecycle-action | | | Không gọi → chờ tới hết heartbeat | |

aws autoscaling complete-lifecycle-action \
  --lifecycle-hook-name rut-em \
  --auto-scaling-group-name doi-ung-dung \
  --lifecycle-action-result CONTINUE \
  --instance-id i-0abc123

Ba lưu ý về rút êm ở ứng dụng: | Lưu ý | Chi tiết | |---|---| | Bắt SIGTERM | | | Trả 503 ở health check ngay | | | Hoàn tất việc đang xử lý rồi thoát | |

Ba lưu ý về trạng thái phiên: | Nơi lưu | Đặc điểm | |---|---| | Bộ nhớ instance | mất khi instance chết | | ElastiCache | sống sót mọi thay đổi instance | | DynamoDB | bền, có TTL |

Ba lưu ý về co giãn: | Lưu ý | Chi tiết | |---|---| | Scale-out nhanh, scale-in chậm | | | Cooldown tránh dao động | | | Predictive scaling cho tải theo chu kỳ | |

⚠ Scale-in nên chậm hơn scale-out:

Mở rộng chậm → người dùng chờ
        ↓
    Thu về nhanh → cắt kết nối và
      có thể phải mở lại ngay
        ↓
    Đặt cooldown scale-in dài hơn

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | TargetResponseTime | độ trễ phản hồi | | HTTPCode_ELB_5XX_Count | lỗi ở tầng load balancer | | UnHealthyHostCount | bao nhiêu target không khoẻ |

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Health check phải chạm logic ứng dụng | | | Cross-zone bật sẵn | | | Idle timeout mặc định 60 giây | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gỡ một target và theo dõi trạng thái draining | | | Chạy tải trong lúc co giãn vào và đếm lỗi | | | Kiểm log ứng dụng có nhận SIGTERM không | |

Và một lời khuyên: hãy đặt deregistration_delay bằng thời gian của yêu cầu lâu nhất cộng thêm biên. Giá trị mặc định 300 giây đủ cho phần lớn ứng dụng web, nhưng nếu bạn có endpoint xuất báo cáo hay tải tệp lớn thì chính những yêu cầu đó sẽ bị cắt — và người dùng gặp chúng luôn là người khó chịu nhất.

Đáp án

**D — Tạo một RDS Read Replica mới từ cơ sở dữ liệu chính Multi-AZ và sinh báo cáo bằng cách truy vấn Read Replica đó.

Vì sao đúng

Đề nêu hai yêu cầu, và read replica đáp ứng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Lấy dữ liệu từ CSDL cho bảng điều khiển | replica có bản sao đầy đủ | | Ảnh hưởng ÍT NHẤT tới hiệu năng CSDL chính | truy vấn chạy trên máy khác |

⚠ Điểm mấu chốt: standby của Multi-AZ KHÔNG phục vụ truy vấn:

Multi-AZ kiểu instance
        ↓
    Standby hoàn toàn THỤ ĐỘNG
        ↓
    Không có endpoint riêng
    → không kết nối tới được
        ↓
    Nó chỉ để chuyển đổi khi hỏng

Đây là lý do phương án C sai — đây cũng là nhầm lẫn phổ biến nhất về Multi-AZ.

⚠ Và đây là bảng phân biệt phải thuộc: | Cấu hình | Phục vụ đọc | |---|---| | Multi-AZ instance (1 standby) | KHÔNG | | Multi-AZ DB cluster (2 reader) | CÓ | | Read replica | CÓ | | Aurora replica | CÓ |

Tạo read replica:

aws rds create-db-instance-read-replica \
  --db-instance-identifier replica-bao-cao \
  --source-db-instance-identifier csdl-chinh \
  --db-instance-class db.r6g.xlarge \
  --availability-zone ap-southeast-1c

⚠ Và replica có thể cấu hình KHÁC instance chính:

Instance chính: tối ưu cho giao dịch
  nhỏ, nhiều
        ↓
    Replica báo cáo: nhiều RAM hơn
      để chứa kết quả tổng hợp
        ↓
    Và thêm chỉ mục riêng cho truy
      vấn báo cáo
    → chỉ mục đó không làm chậm việc
      ghi ở chính

⚠ Và độ trễ sao chép ở đây hoàn toàn chấp nhận được:

Bảng điều khiển cập nhật mỗi 30
  PHÚT
        ↓
    Replica trễ vài giây
        ↓
    Không ai nhận ra
    → đây là mẫu tải hoàn hảo cho
      replica

⚠ Và vì sao phương án B sai — ElastiCache chỉ có dữ liệu đã cache:

B nói truy vấn từ tầng cache
  ElastiCache
        ↓
    Cache chỉ chứa những gì ứng dụng
      đã đặt vào
        ↓
    Báo cáo bán hàng cần tổng hợp
      trên toàn bộ dữ liệu
        ↓
    Cache không có gì để tổng hợp

⚠ Và cache không hỗ trợ truy vấn tổng hợp:

Redis là kho khoá-giá trị
        ↓
    Không có `GROUP BY`, không có
      `JOIN`
        ↓
    Muốn tổng hợp → phải đọc hết
      rồi tính ở ứng dụng
    → không khả thi

⚠ Và vì sao phương án A phức tạp quá mức:

A dùng Lambda đẩy transaction log
  sang S3 rồi dùng Athena
        ↓
    Transaction log của RDS không
      phải thứ đọc và phân tích được
      trực tiếp
        ↓
    Nó là định dạng nhị phân nội bộ
      của engine
        ↓
    Phải qua DMS hoặc công cụ CDC
      mới dùng được

⚠ Nhưng mẫu "đưa dữ liệu sang S3 rồi phân tích" là hợp lệ — chỉ khác cách:

aws dms create-replication-task \
  --migration-type full-load-and-cdc \
  --source-endpoint-arn <arn-rds> \
  --target-endpoint-arn <arn-s3> \
  --table-mappings file://anh-xa.json

DMS đọc binlog và ghi ra S3
        ↓
    Rồi Athena hoặc Redshift phân tích
        ↓
    Hợp khi báo cáo rất nặng
    → nhưng phức tạp hơn nhiều so
      với một replica

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Báo cáo không đụng tới CSDL chính | | | Tạo và xoá được bất cứ lúc nào | | | Không phải sửa ứng dụng hiện có | |

⚠ Và ứng dụng báo cáo phải trỏ vào endpoint của replica:

ket_noi_bao_cao = ket_noi(
    'replica-bao-cao.abc.ap-southeast-1.rds.amazonaws.com')

Tạo replica xong không tự có tác
  dụng
        ↓
    Mỗi replica có endpoint RIÊNG
        ↓
    Phải chủ động dùng nó

⚠ Và Aurora làm việc này tốt hơn RDS: | Tiêu chí | RDS replica | Aurora replica | |---|---|---| | Độ trễ | giây | thường dưới 100 ms | | Endpoint | riêng từng replica | reader endpoint tự cân bằng | | Số lượng | 5 | 15 | | Auto scaling | không | CÓ |

⚠ Và có thể tạo replica chỉ khi cần:

Báo cáo chạy mỗi 30 phút
        ↓
    Replica phải chạy 24/7
        ↓
    Hoặc: tạo replica trước giờ báo
      cáo, xoá sau
    → nhưng tạo replica mất thời gian
      sao chép ban đầu
        ↓
    Với báo cáo mỗi 30 phút thì giữ
      luôn là hợp lý

⚠ Và cần theo dõi độ trễ sao chép:

aws cloudwatch put-metric-alarm \
  --alarm-name replica-tre \
  --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=replica-bao-cao \
  --statistic Maximum --period 300 \
  --evaluation-periods 2 --threshold 300 \
  --comparison-operator GreaterThanThreshold

⚠ Và truy vấn báo cáo nặng vẫn có thể làm replica tụt lại:

Truy vấn dài giữ khoá đọc
        ↓
    MySQL replica áp dụng thay đổi
      theo một luồng (mặc định)
        ↓
    Truy vấn chặn luồng đó
    → độ trễ tăng
        ↓
    Bật parallel replication để giảm

⚠ Và khi báo cáo trở nên quá nặng thì chuyển sang kho phân tích:

Truy vấn quét hàng trăm triệu dòng
        ↓
    CSDL quan hệ theo dòng không hợp
        ↓
    Redshift lưu theo cột, nén, xử
      lý song song
        ↓
    Đưa dữ liệu sang bằng zero-ETL

aws rds create-integration \
  --integration-name aurora-sang-redshift \
  --source-arn <arn-cum-aurora> \
  --target-arn <arn-redshift>

⚠ Và replica cũng có thể promote thành CSDL độc lập:

aws rds promote-read-replica \
  --db-instance-identifier replica-bao-cao

Thao tác MỘT CHIỀU
        ↓
    Sau khi promote không quay lại
      làm replica được
        ↓
    Hữu ích cho khôi phục thảm hoạ
    → nhưng không phải mục đích ở đây

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

• **C. Dùng standby của Multi-AZ để truy vấn và sinh báo cáo — đây là phương án gần nhất và standby thật sự có bản sao đồng bộ đầy đủ của dữ liệu, nhưng nó hoàn toàn thụ động, không có endpoint riêng và không kết nối tới được.
• **B. Truy vấn từ tầng cache ElastiCache — cache chỉ chứa dữ liệu ứng dụng đã đặt vào và không hỗ trợ truy vấn tổng hợp.
• **A. Dùng Lambda đẩy transaction log sang S3 rồi dùng Athena — transaction log là định dạng nhị phân nội bộ của engine, không đọc và phân tích trực tiếp được.

Ghi nhớ

⚠ Multi-AZ và Read Replica — bảng phải thuộc: | Tiêu chí | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | mở rộng đọc | | Sao chép | đồng bộ | không đồng bộ | | Phục vụ đọc | KHÔNG (kiểu instance) | CÓ | | Chuyển đổi | tự động | thủ công (promote) | | Liên Region | không | CÓ |

Từ khoá nhận diện:

"reporting without impacting production" → read replica "standby serves reads" → SAI với Multi-AZ instance "heavy analytical queries" → Redshift "cache repeated queries" → ElastiCache

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 (RDS), 15 (Aurora) | | | Mỗi replica endpoint riêng (RDS) | | | Cấu hình khác instance chính được | |

⚠ Aurora reader endpoint là ưu thế lớn:

RDS: ứng dụng phải tự chia tải giữa
  các replica
        ↓
    Aurora: một reader endpoint tự
      cân bằng
        ↓
    Thêm replica không cần sửa mã

Ba lưu ý về độ trễ sao chép: | Nguyên nhân | Cách chữa | |---|---| | Giao dịch ghi lớn ở chính | chia nhỏ | | Replica yếu hơn chính | nâng cỡ replica | | Truy vấn dài trên replica | bật parallel replication |

Ba lưu ý về Multi-AZ DB cluster: | Lưu ý | Chi tiết | |---|---| | 1 writer + 2 reader ở ba AZ | | | Reader phục vụ đọc được | | | Chuyển đổi dưới 35 giây | |

Ba lưu ý về RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Gộp kết nối, giảm tải CSDL | | | Có read-only endpoint | | | Giữ kết nối khi chuyển đổi | |

Ba lưu ý về kho phân tích: | Khi nào chuyển | Dấu hiệu | |---|---| | Truy vấn quét hàng trăm triệu dòng | replica cũng chậm | | Cần dữ liệu từ nhiều nguồn | CSDL đơn không đủ | | Truy vấn ad-hoc phức tạp | Redshift hoặc Athena |

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Replica tính như instance đầy đủ | | | Phí truyền liên AZ nếu khác AZ | | | Reserved Instance áp được cho replica | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | ReplicaLag | replica tụt lại bao xa | | CPUUtilization | so giữa chính và replica | | DatabaseConnections | có chạm trần không |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So CPU của instance chính trước và sau | | | Kiểm ứng dụng báo cáo dùng endpoint replica | | | Đo ReplicaLag khi báo cáo chạy | |

Và một lời khuyên: hãy nhớ rằng standby của Multi-AZ không phục vụ truy vấn nào. Đây là nhầm lẫn phổ biến nhất về RDS, và nó dẫn tới việc trả tiền cho một instance thứ hai suốt nhiều tháng với kỳ vọng nó đang chia tải — trong khi thực tế nó chỉ ngồi chờ một sự cố có thể không bao giờ xảy ra.

Đáp án

**B và E — Bỏ subnet hiện tại trong VPC B, tạo hai subnet mới 192.168.2.0/28 và 192.168.2.16/28, chuyển b-1 sang subnet đầu và b-2 sang subnet sau; và tạo hai bảng định tuyến trong VPC B — một cái có tuyến tới VPC A, một cái có tuyến tới VPC C.

Vì sao đúng

Đề mô tả một tình huống rất đặc thù: hai VPC peer có CIDR TRÙNG NHAU.

VPC A: 10.1.0.0/16
VPC C: 10.1.0.0/16
        ↓
    Cả hai peer với VPC B
        ↓
    b-1 phải nói chuyện với a-1
    b-2 phải nói chuyện với c-1
        ↓
    Nhưng cả hai đều tới a-1

⚠ Điểm mấu chốt: một bảng định tuyến chỉ có MỘT tuyến cho một đích:

Bảng định tuyến hiện tại có:
    10.1.0.0/16 → pcx-toi-A
        ↓
    Không thêm được:
    10.1.0.0/16 → pcx-toi-C
        ↓
    Cùng CIDR đích → xung đột
    → chỉ một tuyến tồn tại

Đây là lý do phương án A sai — không thể có hai tuyến cùng đích trong một bảng.

⚠ Và giải pháp là TÁCH BẢNG ĐỊNH TUYẾN:

Bảng 1 (gắn subnet của b-1):
    10.1.0.0/16 → pcx-toi-A
        ↓
    Bảng 2 (gắn subnet của b-2):
    10.1.0.0/16 → pcx-toi-C
        ↓
    Mỗi subnet đi theo tuyến của mình

⚠ Và bảng định tuyến gắn với SUBNET, không gắn với instance:

Muốn hai instance đi hai đường
  khác nhau
        ↓
    Phải ở HAI SUBNET khác nhau
        ↓
    Đây là lý do phải chia lại subnet

⚠ Và tính toán CIDR là chỗ ba phương án B, C, D khác nhau:

b-1: 192.168.2.10
b-2: 192.168.2.20
        ↓
    Phải nằm ở hai subnet KHÁC NHAU

Kiểm tra /28:

192.168.2.0/28  → .0 tới .15
192.168.2.16/28 → .16 tới .31
        ↓
    b-1 (.10) ∈ subnet đầu ✅
    b-2 (.20) ∈ subnet sau ✅
        ↓
    ĐÚNG

Kiểm tra /29:

192.168.2.0/29  → .0 tới .7
192.168.2.16/29 → .16 tới .23
        ↓
    b-1 (.10) KHÔNG nằm trong .0/29
    → nằm trong khoảng .8-.15 bị bỏ
      trống
        ↓
    SAI

Đây là lý do phương án C sai.

Kiểm tra /27:

192.168.2.0/27 → .0 tới .31
        ↓
    Cả b-1 và b-2 đều nằm trong đó
        ↓
    Và 192.168.2.16/27 KHÔNG hợp lệ
    → /27 phải bắt đầu ở bội số của
      32: .0, .32, .64...
        ↓
    SAI về cả hai mặt

Đây là lý do phương án D sai.

⚠ Và quy tắc căn chỉnh CIDR phải nhớ: | Prefix | Kích thước | Bắt đầu ở bội số của | |---|---|---| | /28 | 16 địa chỉ | 16 | | /27 | 32 địa chỉ | 32 | | /26 | 64 địa chỉ | 64 | | /29 | 8 địa chỉ | 8 |

`192.168.2.16/27` sai vì 16 không
  phải bội số của 32
        ↓
    Phải là `192.168.2.0/27` hoặc
      `192.168.2.32/27`

Tạo subnet và bảng định tuyến:

aws ec2 create-subnet --vpc-id vpc-B \
  --cidr-block 192.168.2.0/28 \
  --availability-zone ap-southeast-1a

aws ec2 create-subnet --vpc-id vpc-B \
  --cidr-block 192.168.2.16/28 \
  --availability-zone ap-southeast-1a

aws ec2 create-route-table --vpc-id vpc-B
aws ec2 create-route --route-table-id rtb-toi-A \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-B-A

aws ec2 create-route-table --vpc-id vpc-B
aws ec2 create-route --route-table-id rtb-toi-C \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-B-C

aws ec2 associate-route-table \
  --route-table-id rtb-toi-A --subnet-id subnet-b1
aws ec2 associate-route-table \
  --route-table-id rtb-toi-C --subnet-id subnet-b2

⚠ Và không đổi được subnet của instance đang chạy:

Instance gắn với subnet lúc khởi
  động
        ↓
    Không có API nào đổi subnet
        ↓
    Phải tạo AMI rồi khởi động
      instance mới trong subnet mới
        ↓
    Đây là lý do phương án nói
      "launching a new instance via
      an AMI"

⚠ Và subnet /28 chỉ có 11 IP dùng được:

16 địa chỉ tổng
        ↓
    AWS giữ 5 địa chỉ mỗi subnet:
      .0 (mạng)
      .1 (router)
      .2 (DNS)
      .3 (dự phòng)
      .15 (broadcast)
        ↓
    Còn 11 địa chỉ
    → /28 là subnet NHỎ NHẤT AWS cho
      phép

⚠ Và đây là ràng buộc phải nhớ: | Prefix | Tổng IP | Dùng được | |---|---|---| | /28 | 16 | 11 — nhỏ nhất | | /24 | 256 | 251 | | /16 | 65.536 | 65.531 |

⚠ Và VPC peering KHÔNG hỗ trợ CIDR trùng nhau — đây là ngoại lệ:

Bình thường: hai VPC có CIDR trùng
  → KHÔNG peering được
        ↓
    Ở đây: A và C không peer với nhau
        ↓
    Mỗi cái peer riêng với B
    → về mặt kỹ thuật hợp lệ
        ↓
    Nhưng B phải phân biệt bằng
      bảng định tuyến

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi instance đi đúng đường | | | Không phải đánh số lại VPC A hay C | | | Dùng cơ chế có sẵn của VPC | |

⚠ Nhưng đây là kiến trúc rất khó bảo trì:

Mỗi đích trùng CIDR cần một subnet
  riêng
        ↓
    Thêm VPC D cũng dùng 10.1.0.0/16
    → thêm một subnet nữa
        ↓
    Không mở rộng được

⚠ Và PrivateLink là giải pháp đúng cho CIDR trùng nhau:

aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns <arn-nlb-o-A> \
  --acceptance-required

VPC A phơi dịch vụ qua NLB
        ↓
    VPC B tạo interface endpoint
        ↓
    Không định tuyến cả dải CIDR
    → trùng CIDR không thành vấn đề

⚠ Và cách bền vững nhất là quy hoạch lại IP:

Dùng AWS IPAM
        ↓
    Cấp phát dải không trùng cho
      từng VPC
        ↓
    Trùng CIDR là nợ kỹ thuật
    → sớm muộn cũng phải trả

aws ec2 create-ipam-pool --ipam-scope-id <id> \
  --address-family ipv4 --locale ap-southeast-1 \
  --provisioned-cidrs Cidr=10.0.0.0/8

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

• **C. Tạo hai subnet /29 và chuyển b-1, b-2 sang — đây là phương án gần nhất và ý tưởng chia subnet hoàn toàn đúng, nhưng 192.168.2.0/29 chỉ phủ .0 tới .7 nên không chứa được b-1 ở địa chỉ .10.
• **D. Tạo hai subnet /27 — 192.168.2.0/27 phủ cả .0 tới .31 nên chứa cả hai instance, và 192.168.2.16/27 không phải CIDR hợp lệ vì không căn chỉnh đúng biên.
• **A. Tạo một bảng định tuyến với các tuyến riêng cho VPC A và VPC C — không thể có hai tuyến cùng đích 10.1.0.0/16 trong một bảng định tuyến.

Ghi nhớ

⚠ Quy tắc căn chỉnh CIDR phải thuộc:

Subnet /n bắt đầu ở địa chỉ chia
  hết cho (2^(32-n))
        ↓
    /28 → bội số của 16
    /27 → bội số của 32
    /26 → bội số của 64

Từ khoá nhận diện:

"overlapping CIDR between peered VPCs" → tách subnet + tách bảng định tuyến "one route table cannot have two routes to same CIDR" → luôn đúng "cannot change instance subnet" → tạo AMI, khởi động máy mới "overlapping CIDR, scalable solution" → PrivateLink

Ba lưu ý về bảng định tuyến: | Lưu ý | Chi tiết | |---|---| | Gắn với subnet, không gắn với instance | | | Một subnet chỉ gắn được một bảng | | | Tuyến cụ thể hơn được ưu tiên | |

⚠ Tuyến cụ thể hơn thắng:

10.1.0.0/16 → pcx-A
10.1.5.0/24 → pcx-C
        ↓
    Gói tới 10.1.5.10 dùng tuyến
      thứ hai
        ↓
    Nhưng ở đây cả A và C dùng CHUNG
      dải
    → không tách được bằng cách này

Ba lưu ý về VPC peering: | Lưu ý | Chi tiết | |---|---| | KHÔNG bắc cầu | | | CIDR không được trùng giữa hai bên peer | | | Phải sửa route ở CẢ HAI bên | |

Ba lưu ý về subnet: | Lưu ý | Chi tiết | |---|---| | /28 là nhỏ nhất, 11 IP dùng được | | | AWS giữ 5 địa chỉ mỗi subnet | | | Không đổi CIDR của subnet đã tạo | |

Ba lưu ý về chuyển instance sang subnet khác: | Bước | Việc | |---|---| | Tạo AMI từ instance | | | Khởi động instance mới trong subnet mới | | | Chuyển lưu lượng rồi chấm dứt máy cũ | |

Ba lưu ý về PrivateLink: | Lưu ý | Chi tiết | |---|---| | Không định tuyến cả dải CIDR | | | Trùng CIDR không thành vấn đề | | | Một chiều: consumer gọi provider | |

Ba lưu ý về Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Bắc cầu được | | | Nhiều bảng định tuyến để phân đoạn | | | CIDR vẫn KHÔNG được trùng | |

Ba lưu ý về quy hoạch IP: | Lưu ý | Chi tiết | |---|---| | Lên kế hoạch trước khi tạo VPC | | | Dùng IPAM theo dõi và cấp phát | | | Chừa chỗ cho tăng trưởng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | ping từ b-1 tới a-1 và từ b-2 tới c-1 | | | Kiểm subnet nào gắn bảng định tuyến nào | | | Chạy Reachability Analyzer cho từng cặp | |

Và một lời khuyên: hãy coi việc trùng CIDR là nợ kỹ thuật cần trả chứ đừng coi là vấn đề đã giải quyết xong. Cách chia subnet và tách bảng định tuyến hoạt động cho đúng hai đích — nhưng nó không mở rộng được, và mỗi VPC mới dùng cùng dải địa chỉ sẽ đòi thêm một subnet nữa cho tới lúc không còn chỗ.

Đáp án

**A và D — Đặt luật vòng đời chuyển TOÀN BỘ object sang Glacier sau 180 ngày; và đặt luật chuyển object sang S3 Standard-IA theo TIỀN TỐ sau 45 ngày.

Vì sao đúng

Đề mô tả hai nhóm dữ liệu với hai mẫu truy cập khác nhau:

`images/`: sau 45 ngày HIẾM khi
  được yêu cầu
        ↓
    `thumbnails/`: vẫn được yêu cầu
      thường xuyên
        ↓
    Sau 180 ngày: CẢ HAI đều lưu trữ

⚠ Điểm mấu chốt: chỉ một nhóm chuyển tầng ở mốc 45 ngày:

Chuyển TOÀN BỘ sang IA sau 45 ngày
        ↓
    Thumbnail vẫn đọc thường xuyên
        ↓
    IA có phí LẤY RA 0,01 USD/GB
    → đọc nhiều thì đắt hơn Standard
        ↓
    Phải lọc theo tiền tố `images/`

Đây là lý do phương án C sai — nó chuyển tất cả.

Luật vòng đời đầy đủ:

{"Rules": [
  {"ID": "anh-goc-sang-ia-sau-45-ngay",
   "Filter": {"Prefix": "images/"},
   "Status": "Enabled",
   "Transitions": [{"Days": 45,
                    "StorageClass": "STANDARD_IA"}]},
  {"ID": "tat-ca-sang-glacier-sau-180-ngay",
   "Filter": {},
   "Status": "Enabled",
   "Transitions": [{"Days": 180,
                    "StorageClass": "GLACIER"}]}]}

⚠ Và Filter: {} rỗng nghĩa là áp cho MỌI object — đúng yêu cầu ở mốc 180 ngày:

Đề nói "sau 180 ngày, công ty muốn
  lưu trữ CẢ ảnh gốc LẪN thumbnail"
        ↓
    Không cần lọc tiền tố
        ↓
    Một luật cho toàn bộ bucket

Đây là lý do phương án E kém hơn — nó lọc theo tiền tố ở mốc 180 ngày, làm thừa việc.

⚠ Và điểm mấu chốt thứ hai: yêu cầu chịu được mất một AZ loại One Zone-IA:

Đề nói "giải pháp phải sẵn sàng cao
  để chống thảm hoạ mất cả một AZ"
        ↓
    One Zone-IA lưu ở MỘT AZ duy nhất
        ↓
    Mất AZ đó → MẤT dữ liệu
    → vi phạm yêu cầu

Đây là lý do phương án B sai.

⚠ Và bảng độ bền theo AZ phải thuộc: | Lớp | Số AZ | Chịu mất một AZ | |---|---|---| | Standard | ≥3 | CÓ | | Standard-IA | ≥3 | CÓ | | One Zone-IA | 1 | KHÔNG | | Glacier (mọi loại) | ≥3 | CÓ |

One Zone-IA rẻ hơn Standard-IA 20%
        ↓
    Đổi lại: mất độ bền đa AZ
        ↓
    Chỉ dùng cho dữ liệu TÁI TẠO ĐƯỢC
    → thumbnail thì tái tạo được từ
      ảnh gốc
    → nhưng đề nói rõ phải chống mất AZ

⚠ Và ràng buộc 30 ngày tối thiểu cho phép chuyển ở mốc 45 ngày:

Standard-IA yêu cầu object phải ở
  Standard ít nhất 30 ngày
        ↓
    Chuyển ở ngày 45
    → hợp lệ
        ↓
    Chuyển ở ngày 20 → luật bị từ chối

⚠ Và chuyển IA → Glacier ở ngày 180 cũng hợp lệ:

Standard-IA có phí tối thiểu 30 ngày
        ↓
    Object vào IA ngày 45
        ↓
    Chuyển sang Glacier ngày 180
    → đã ở IA 135 ngày
    → không chạm ràng buộc

⚠ Và luật vòng đời không cho phép chuyển NGƯỢC:

Standard → IA → Glacier → Deep Archive
        ↓
    Chỉ đi một chiều
        ↓
    Muốn đưa về Standard
    → phải khôi phục và chép lại

⚠ Và với thumbnail thì cân nhắc Intelligent-Tiering:

Thumbnail vẫn đọc thường xuyên
        ↓
    Nhưng có thể giảm dần theo thời
      gian
        ↓
    Intelligent-Tiering tự chuyển tầng
    → và KHÔNG có phí lấy ra

{"ID": "thumbnail-tu-phan-tang",
 "Filter": {"Prefix": "thumbnails/"},
 "Status": "Enabled",
 "Transitions": [{"Days": 0,
                  "StorageClass": "INTELLIGENT_TIERING"}]}

⚠ Và Intelligent-Tiering có phí giám sát mỗi object:

~0,0025 USD cho 1.000 object mỗi
  tháng
        ↓
    Hàng triệu thumbnail nhỏ
    → khoản này đáng kể
        ↓
    Và object dưới 128 KB không được
      tự chuyển tầng

⚠ Và thumbnail thường nhỏ hơn 128 KB — chi tiết quan trọng:

Standard-IA và Intelligent-Tiering
  tính tối thiểu 128 KB mỗi object
        ↓
    Thumbnail 20 KB vẫn tính như
      128 KB
        ↓
    Chuyển sang IA có thể ĐẮT HƠN
      Standard
    → đây là lý do nữa để không
      chuyển thumbnail

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ảnh gốc rẻ hơn 46% từ ngày 45 | | | Thumbnail vẫn ở Standard, không phí lấy ra | | | Cả hai lưu trữ rẻ nhất từ ngày 180 | |

⚠ Và cần chú ý phí chuyển tầng theo SỐ OBJECT:

Chuyển sang IA: ~0,01 USD cho
  1.000 object
        ↓
    Chuyển sang Glacier: ~0,05 USD
      cho 1.000 object
        ↓
    Hàng triệu thumbnail nhỏ
    → phí chuyển có thể lớn hơn phí
      tiết kiệm

⚠ Và đây là phép tính nên làm trước:

Object 20 KB chuyển sang Glacier
        ↓
    Phí chuyển: 0,00005 USD
        ↓
    Tiết kiệm mỗi tháng:
      20 KB × (0,023 - 0,0036) / 1024 / 1024
    ≈ 0,00000037 USD
        ↓
    Cần 135 THÁNG mới hoà vốn
    → không đáng

⚠ Và cách chữa là gom object nhỏ trước:

Gom thumbnail thành tệp tar theo
  ngày hoặc theo album
        ↓
    Ít object hơn, mỗi cái lớn hơn
        ↓
    Phí chuyển tầng giảm mạnh
    → và không chạm ràng buộc 128 KB

⚠ Và S3 Storage Lens cho biết phân bố kích thước object:

aws s3control get-storage-lens-configuration \
  --account-id 111122223333 --config-id mac-dinh

Xem có bao nhiêu object dưới 128 KB
        ↓
    Quyết định có nên chuyển tầng
      hay không

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

⚠ Đề nói "Glacier" nhưng hiện nay có ba lớp Glacier khác nhau.

`StorageClass: GLACIER` trong API
  = Glacier Flexible Retrieval
        ↓
    Đề chỉ nói "archive" mà không
      nêu yêu cầu thời gian lấy ra
        ↓
    Deep Archive rẻ hơn 3,6 lần
    → nếu chấp nhận chờ 12-48 giờ

Và thumbnail có thể tái tạo được từ ảnh gốc, nên One Zone-IA vốn là lựa chọn hợp lý cho chúng — nếu đề không đặt yêu cầu chống mất AZ. Đây là chỗ ràng buộc trong đề làm thay đổi câu trả lời so với trực giác về chi phí.

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

• **E. Đặt luật chuyển object sang Glacier theo tiền tố sau 180 ngày — đây là phương án gần nhất và cho kết quả gần như giống đáp án, nhưng ở mốc 180 ngày cả hai nhóm đều chuyển nên lọc theo tiền tố là thừa; cần hai luật thay vì một.
• **C. Chuyển TOÀN BỘ object sang Standard-IA sau 45 ngày — thumbnail vẫn đọc thường xuyên, mà IA có phí lấy ra nên sẽ đắt hơn Standard.
• **B. Chuyển object sang One Zone-IA theo tiền tố sau 45 ngày — One Zone-IA lưu ở một AZ duy nhất, vi phạm yêu cầu chống mất cả một AZ.

Ghi nhớ

⚠ Sáu lớp lưu trữ S3 — bảng phải thuộc: | Lớp | Số AZ | Phí lấy ra | Tối thiểu | |---|---|---|---| | Standard | ≥3 | không | không | | Standard-IA | ≥3 | 0,01 USD/GB | 30 ngày | | One Zone-IA | 1 | 0,01 USD/GB | 30 ngày | | Glacier Instant Retrieval | ≥3 | 0,03 USD/GB | 90 ngày | | Glacier Flexible Retrieval | ≥3 | 0,0025-0,03 USD/GB | 90 ngày | | Glacier Deep Archive | ≥3 | 0,02 USD/GB | 180 ngày |

Từ khoá nhận diện:

"different access patterns per prefix" → lọc theo tiền tố trong luật vòng đời "must survive AZ loss" → KHÔNG dùng One Zone-IA "recreatable data" → One Zone-IA hợp lý | "unknown access pattern" → Intelligent-Tiering

Ba lưu ý về luật vòng đời: | Lưu ý | Chi tiết | |---|---| | Lọc theo prefix, tag, hoặc kích thước | | | Chỉ chuyển một chiều | | | Phí chuyển tính theo SỐ OBJECT | |

⚠ Lọc theo kích thước là tính năng mới đáng biết:

{"Filter": {"And": {
  "Prefix": "images/",
  "ObjectSizeGreaterThan": 131072}}}

Chỉ chuyển object trên 128 KB
        ↓
    Tránh chuyển tệp nhỏ không hiệu quả
    → giải quyết đúng vấn đề ở trên

Ba lưu ý về kích thước tối thiểu: | Lớp | Tính tiền tối thiểu | |---|---| | Standard-IA, One Zone-IA | 128 KB | | Glacier Instant Retrieval | 128 KB | | Glacier Flexible, Deep Archive | 40 KB |

Ba lưu ý về Intelligent-Tiering: | Lưu ý | Chi tiết | |---|---| | KHÔNG có phí lấy ra | | | Có phí giám sát mỗi object | | | Object dưới 128 KB không tự chuyển tầng | |

Ba lưu ý về phí chuyển tầng: | Đích | Giá xấp xỉ mỗi 1.000 object | |---|---| | Standard-IA | 0,01 USD | | Glacier Flexible | 0,05 USD | | Deep Archive | 0,05 USD |

Ba lưu ý về dọn dẹp: | Luật | Việc | |---|---| | AbortIncompleteMultipartUpload | dọn phần tải dở dang | | NoncurrentVersionExpiration | xoá phiên bản cũ | | ExpiredObjectDeleteMarker | dọn delete marker mồ côi |

⚠ Luôn thêm luật dọn multipart:

{"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}

Ba lưu ý về Storage Lens: | Lưu ý | Chi tiết | |---|---| | Xem phân bố lớp lưu trữ | | | Xem phân bố kích thước object | | | Đề xuất tối ưu chi phí | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm object đã chuyển đúng lớp | | | So chi phí trong Cost Explorer | | | Đếm phí chuyển tầng có vượt tiết kiệm không | |

Và một lời khuyên: hãy kiểm phân bố kích thước object trước khi đặt luật chuyển tầng. Với hàng triệu thumbnail vài chục KB, phí chuyển tầng tính theo số object có thể vượt xa khoản tiết kiệm về lưu trữ — và bộ lọc ObjectSizeGreaterThan sinh ra chính để tránh chuyện đó.

Đáp án

**D — Đăng ký Application Load Balancer làm target của một Network Load Balancer, và NLB cung cấp địa chỉ IP tĩnh cần thiết.

Vì sao đúng

Đề nêu hai ràng buộc:

ALB cần một địa chỉ IP TĨNH
        ↓
    Và chi phí phải TỐI THIỂU

⚠ Điểm mấu chốt: ALB KHÔNG BAO GIỜ có IP tĩnh:

ALB dùng tên DNS
        ↓
    Địa chỉ IP phía sau thay đổi khi
      ALB co giãn
        ↓
    Không gắn Elastic IP vào ALB được
        ↓
    Đây là ràng buộc thiết kế, không
      phải cấu hình

Đây là lý do phương án B sai — không có cách nào đăng ký Elastic IP cho ALB, kể cả lúc tạo.

⚠ Và NLB thì ngược lại — nó gắn được Elastic IP: | Load balancer | IP tĩnh | |---|---| | ALB | KHÔNG | | NLB | CÓ, gán Elastic IP mỗi AZ | | GWLB | không áp dụng |

Tạo NLB với Elastic IP:

aws elbv2 create-load-balancer \
  --name nlb-truoc-alb --type network \
  --scheme internet-facing \
  --subnet-mappings \
    SubnetId=subnet-1a,AllocationId=eipalloc-abc \
    SubnetId=subnet-1b,AllocationId=eipalloc-def

⚠ Và từ 2021, NLB đăng ký được ALB làm target — đây là tính năng then chốt:

aws elbv2 create-target-group \
  --name tg-alb --target-type alb \
  --protocol TCP --port 443 --vpc-id vpc-abc

aws elbv2 register-targets \
  --target-group-arn <arn-tg> \
  --targets Id=<arn-alb>

⚠ --target-type alb là chi tiết quyết định:

Trước 2021: không đăng ký ALB làm
  target của NLB được
        ↓
    Phải dùng Global Accelerator
      hoặc tự dựng proxy
        ↓
    Nay: NLB → ALB là cấu hình chính
      thức

⚠ Và kiến trúc này giữ được mọi tính năng của ALB:

Client → NLB (IP tĩnh)
        ↓
    NLB → ALB
        ↓
    ALB → target group theo path,
      host, header
        ↓
    Vẫn có WAF, sticky session,
      định tuyến tầng 7

⚠ Và vì sao phương án A đắt hơn:

Global Accelerator cũng cho IP tĩnh
        ↓
    Nhưng phí cố định ~0,025 USD/giờ
    ≈ 18 USD/tháng
        ↓
    Cộng phí truyền dữ liệu premium
      theo Region
        ↓
    NLB: ~0,0225 USD/giờ + phí LCU
    → rẻ hơn cho một Region

⚠ Nhưng Global Accelerator có ưu điểm riêng: | Tiêu chí | NLB trước ALB | Global Accelerator | |---|---|---| | Phạm vi | một Region | toàn cầu | | Chuyển Region khi hỏng | không | CÓ, vài giây | | Giảm độ trễ toàn cầu | không | CÓ | | Chi phí | thấp hơn | cao hơn |

Đề nói "giữ chi phí tối thiểu"
        ↓
    Và không nhắc tới nhiều Region
        ↓
    → NLB là lựa chọn đúng

⚠ Và vì sao phương án C sai — GWLB dùng cho việc khác hẳn:

Gateway Load Balancer
        ↓
    Chuyển lưu lượng tới THIẾT BỊ
      AN NINH bên thứ ba
        ↓
    Tường lửa ảo, IDS/IPS
        ↓
    Không phải cơ chế cung cấp IP
      tĩnh cho ALB

⚠ Và GWLB hoạt động ở tầng 3 với giao thức GENEVE:

GWLB endpoint chặn gói tin
        ↓
    Đóng gói bằng GENEVE, gửi tới
      thiết bị
        ↓
    Thiết bị kiểm tra rồi trả lại
        ↓
    Hoàn toàn khác mục đích ở đây

⚠ Và cần chú ý: NLB trước ALB làm mất IP thật của client:

NLB với target-type `alb`
        ↓
    ALB thấy IP nguồn là của NLB
        ↓
    Trừ khi bật client IP preservation
        ↓
    Nhưng với target-type `alb` thì
      KHÔNG bật được

⚠ Giải pháp: đọc X-Forwarded-For:

NLB hoạt động ở tầng 4
        ↓
    Nó KHÔNG thêm header nào
        ↓
    Nhưng ALB thêm `X-Forwarded-For`
        ↓
    Ứng dụng đọc header đó
    → vẫn biết IP client

X-Forwarded-For: 203.0.113.10, 10.0.1.50
                 ↑ client thật    ↑ IP của NLB

⚠ Và NLB có thể bật Proxy Protocol v2 để truyền IP nguồn:

aws elbv2 modify-target-group-attributes \
  --target-group-arn <arn-tg> \
  --attributes Key=proxy_protocol_v2.enabled,Value=true

Nhưng ALB KHÔNG hiểu Proxy Protocol
        ↓
    Chỉ dùng khi target là EC2 tự
      xử lý

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | IP tĩnh cho toàn bộ ứng dụng | | | Giữ nguyên mọi tính năng tầng 7 của ALB | | | Rẻ hơn Global Accelerator | |

⚠ Và một Elastic IP mỗi AZ — không phải một cho toàn bộ:

NLB có một node ở mỗi AZ đã bật
        ↓
    Mỗi node một Elastic IP
        ↓
    Hai AZ → hai IP tĩnh
        ↓
    Bên ngoài phải khai cả hai vào
      allowlist

⚠ Và đây là điều cần thông báo cho bên đối tác:

"Một địa chỉ IP tĩnh" trong đề
        ↓
    Thực tế là một IP MỖI AZ
        ↓
    Muốn đúng một IP → chỉ bật một AZ
    → mất tính sẵn sàng cao

⚠ Và cần thêm một lớp health check:

NLB kiểm tra sức khoẻ của ALB
        ↓
    Mặc định kiểm TCP tới cổng đã khai
        ↓
    Nên đổi sang HTTP/HTTPS để kiểm
      sâu hơn

aws elbv2 modify-target-group \
  --target-group-arn <arn-tg> \
  --health-check-protocol HTTPS \
  --health-check-path /health \
  --health-check-port 443

⚠ Và security group của ALB phải cho phép NLB:

NLB không có security group (trừ
  loại mới có tuỳ chọn)
        ↓
    ALB thấy lưu lượng đến từ IP
      RIÊNG của NLB node
        ↓
    Mở security group của ALB cho
      dải CIDR của subnet chứa NLB

⚠ Và chi phí LCU của NLB cần tính:

NLB tính theo NLCU (Network LCU)
        ↓
    Dựa trên: kết nối mới, kết nối
      đang mở, băng thông
        ↓
    Lưu lượng đi qua HAI load balancer
    → trả phí cho cả hai

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

• **A. Cấu hình Global Accelerator trước ALB để cung cấp IP tĩnh — đây là phương án gần nhất và thật sự giải quyết đúng bài toán, thậm chí tốt hơn về mặt độ trễ toàn cầu, nhưng có phí cố định theo giờ cộng phí truyền dữ liệu premium, đắt hơn NLB cho một Region.
• **C. Cấu hình Gateway Load Balancer trước ALB — GWLB dùng để chuyển lưu lượng tới thiết bị an ninh bên thứ ba, không phải cơ chế cung cấp IP tĩnh.
• **B. Đăng ký Elastic IP cho ALB lúc tạo rồi dựng lại ALB — ALB không hỗ trợ Elastic IP ở bất kỳ thời điểm nào.

Ghi nhớ

⚠ Bốn cách có IP tĩnh cho ứng dụng web — bảng phải thuộc: | Cách | Phạm vi | Chi phí | |---|---|---| | NLB với Elastic IP | một Region | thấp nhất | | NLB trước ALB | một Region, giữ tính năng tầng 7 | thấp | | Global Accelerator | toàn cầu, có failover Region | cao hơn | | Elastic IP trên EC2 | một instance | không có LB |

Từ khoá nhận diện:

"static IP for ALB, minimum cost" → NLB trước ALB "static IP + global low latency" → Global Accelerator "third-party firewall inspection" → Gateway Load Balancer "Elastic IP on ALB" → KHÔNG bao giờ được

Ba lưu ý về NLB: | Lưu ý | Chi tiết | |---|---| | Một Elastic IP mỗi AZ | | | Cross-zone MẶC ĐỊNH TẮT | | | Hỗ trợ TCP, UDP, TLS | |

⚠ Cross-zone tắt gây phân bố lệch:

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <arn> \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

Bật thì phân bố đều
        ↓
    Nhưng tính phí truyền liên AZ

Ba lưu ý về target-type của NLB: | Loại | Target | |---|---| | instance | EC2, giữ IP client | | ip | địa chỉ IP, kể cả tại chỗ | | alb | Application Load Balancer | | lambda | KHÔNG hỗ trợ (chỉ ALB có) |

Ba lưu ý về IP client: | Tình huống | Cách lấy IP thật | |---|---| | NLB target-type instance | giữ nguyên IP client | | NLB target-type alb | đọc X-Forwarded-For từ ALB | | ALB | luôn thêm X-Forwarded-For |

Ba lưu ý về Global Accelerator: | Lưu ý | Chi tiết | |---|---| | Hai IP tĩnh anycast | | | Chuyển Region trong vài giây | | | Phí cố định + phí truyền premium | |

Ba lưu ý về chi phí: | Thành phần | Giá xấp xỉ | |---|---| | ALB | 0,0225 USD/giờ + LCU | | NLB | 0,0225 USD/giờ + NLCU | | Global Accelerator | 0,025 USD/giờ + truyền premium | | Elastic IP không gắn | 0,005 USD/giờ |

⚠ Elastic IP đã gắn vào NLB thì miễn phí:

EIP gắn vào tài nguyên đang chạy
        ↓
    Không tính phí
        ↓
    EIP mồ côi mới tính tiền

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | NLB mặc định kiểm TCP | | | Đổi sang HTTP/HTTPS để kiểm sâu hơn | | | ALB cũng kiểm sức khoẻ target của nó | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig tên NLB — phải ra Elastic IP | | | Gọi qua NLB và kiểm ALB định tuyến đúng | | | Kiểm ứng dụng đọc được IP client từ header | |

Và một lời khuyên: hãy báo trước cho bên đối tác rằng sẽ có một IP tĩnh cho mỗi Availability Zone chứ không phải một IP duy nhất. Nhiều yêu cầu "một địa chỉ IP tĩnh" đến từ một bảng allowlist ở phía đối tác, và việc phát hiện ra có hai địa chỉ vào phút chót thường tốn nhiều thời gian phối hợp hơn cả việc dựng NLB.

Đáp án

**C — Cấu hình Kinesis Data Firehose đẩy dữ liệu vào Amazon Redshift, và dựng bảng điều khiển bằng QuickSight với nguồn dữ liệu là Redshift.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Nạp luồng thẳng vào kho dữ liệu | Firehose có đích Redshift sẵn | | Cho phép SỬA ĐỔI bằng SQL | Redshift hỗ trợ UPDATE, DELETE | | Truy vấn phân tích phức tạp, NHANH NHẤT | Redshift lưu theo cột, xử lý song song | | Bảng điều khiển BI | QuickSight nối thẳng Redshift |

⚠ Điểm mấu chốt: "cho phép sửa đổi bằng SQL" loại S3 và Athena:

Athena chỉ ĐỌC
        ↓
    Không có `UPDATE`, không có
      `DELETE` theo dòng
        ↓
    Muốn sửa → phải ghi lại cả tệp
        ↓
    Redshift là CSDL thật
    → sửa được bằng SQL

Đây là lý do phương án A và B đều sai.

⚠ Và "truy vấn phân tích chạy nhanh nhất có thể" cũng nghiêng về Redshift:

Athena đọc trực tiếp từ S3
        ↓
    Không có chỉ mục, không có sort
      key, không có thống kê
        ↓
    Redshift: dữ liệu đã nạp, đã sắp
      xếp, đã nén, có thống kê
    → truy vấn lặp lại nhanh hơn
      nhiều

⚠ Và Firehose có Redshift làm đích sẵn — không phải tự viết gì:

aws firehose create-delivery-stream \
  --delivery-stream-name nap-giao-dich \
  --redshift-destination-configuration '{
    "RoleARN": "arn:aws:iam::111122223333:role/Firehose",
    "ClusterJDBCURL": "jdbc:redshift://cum.abc.ap-southeast-1.redshift.amazonaws.com:5439/kho",
    "CopyCommand": {
      "DataTableName": "giao_dich",
      "CopyOptions": "FORMAT AS JSON \'auto\'"},
    "Username": "firehose_user",
    "Password": "...",
    "S3Configuration": {
      "RoleARN": "arn:aws:iam::111122223333:role/Firehose",
      "BucketARN": "arn:aws:s3:::trung-gian-firehose",
      "BufferingHints": {"SizeInMBs": 128,
                         "IntervalInSeconds": 300}}}'

⚠ Và Firehose nạp vào Redshift QUA S3 — đây là cách nạp đúng:

Firehose ghi tệp vào S3 trung gian
        ↓
    Rồi phát lệnh `COPY` vào Redshift
        ↓
    `COPY` chạy song song trên mọi
      slice
    → nhanh hơn `INSERT` rất nhiều

⚠ Và đây là lý do phương án D không phải lựa chọn tốt nhất:

D dùng Kinesis Data Streams đẩy
  vào Redshift
        ↓
    Data Streams KHÔNG có đích Redshift
      tích hợp sẵn
        ↓
    Phải tự viết consumer:
      đọc → gom lô → ghi S3 → COPY
        ↓
    Firehose làm sẵn toàn bộ

⚠ Và Data Streams chỉ đáng dùng khi cần nhiều consumer hoặc phát lại: | Tiêu chí | Firehose | Data Streams | |---|---|---| | Đích Redshift | tích hợp sẵn | tự viết | | Nhiều consumer | không | CÓ | | Phát lại | không | CÓ | | Độ trễ | tối thiểu 60 giây | dưới 1 giây | | Vận hành | thấp nhất | quản shard |

Đề chỉ có một luồng xuống kho dữ
  liệu
        ↓
    Không cần nhiều consumer
    → Firehose đơn giản hơn

⚠ Và QuickSight nối thẳng Redshift được:

aws quicksight create-data-source \
  --aws-account-id 111122223333 \
  --data-source-id nguon-redshift \
  --name "Kho giao dich" --type REDSHIFT \
  --data-source-parameters '{"RedshiftParameters": {
    "Host": "cum.abc.ap-southeast-1.redshift.amazonaws.com",
    "Port": 5439, "Database": "kho"}}' \
  --credentials '{"CredentialPair": {
    "Username": "quicksight_ro", "Password": "..."}}'

⚠ Và phát hiện bất thường giá cổ phiếu có sẵn trong QuickSight:

QuickSight ML Insights
        ↓
    Anomaly detection trên chuỗi
      thời gian
        ↓
    Tự học mẫu bình thường và đánh
      dấu điểm lệch
        ↓
    Không phải viết mô hình nào

⚠ Và Firehose có phép đệm tối thiểu — cần biết:

Đích Redshift: tối thiểu 60 giây
        ↓
    "Streams data directly" trong đề
      hiểu là gần thời gian thực
        ↓
    Cần dưới một giây
    → phải đọc thẳng từ Data Streams

⚠ Và Redshift Streaming Ingestion là cách hiện đại hơn:

CREATE EXTERNAL SCHEMA kinesis_schema
FROM KINESIS IAM_ROLE '<arn-role>';

CREATE MATERIALIZED VIEW giao_dich_moi AUTO REFRESH YES AS
SELECT approximate_arrival_timestamp,
       json_extract_path_text(
         from_varbyte(kinesis_data,'utf-8'), 'ma_ck') AS ma_ck,
       json_extract_path_text(
         from_varbyte(kinesis_data,'utf-8'), 'gia')::DECIMAL AS gia
FROM kinesis_schema."luong-giao-dich";

Redshift đọc THẲNG từ Kinesis
        ↓
    Không qua S3, không qua Firehose
        ↓
    Độ trễ vài giây thay vì 60+
    → đây là cách AWS khuyến nghị
      hiện nay

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nạp tự động, không viết mã | | | Sửa dữ liệu bằng SQL khi cần | | | Truy vấn phân tích nhanh nhất | |

⚠ Và thiết kế bảng quyết định tốc độ truy vấn:

CREATE TABLE giao_dich (
    ma_ck       VARCHAR(16) DISTKEY,
    thoi_diem   TIMESTAMP   SORTKEY,
    gia         DECIMAL(12,4),
    khoi_luong  BIGINT)
DISTSTYLE KEY;

`SORTKEY` theo thời gian
        ↓
    Truy vấn lọc theo khoảng thời gian
    → Redshift bỏ qua toàn bộ khối
      ngoài khoảng
        ↓
    `DISTKEY` theo mã chứng khoán
    → JOIN theo mã không phải xáo
      dữ liệu giữa các node

⚠ Và cần chạy VACUUM và ANALYZE định kỳ:

VACUUM giao_dich;
ANALYZE giao_dich;

Nạp liên tục làm bảng phân mảnh
        ↓
    `VACUUM` sắp xếp lại theo SORTKEY
        ↓
    `ANALYZE` cập nhật thống kê cho
      trình tối ưu
        ↓
    Redshift có auto vacuum và auto
      analyze — nhưng vẫn nên kiểm

⚠ Và QuickSight nên dùng SPICE cho bảng điều khiển:

Direct query: mỗi lần mở bảng là
  một truy vấn tới Redshift
        ↓
    Nhiều người xem → tải lên cụm
        ↓
    SPICE: nạp vào bộ nhớ QuickSight
    → bảng phản hồi tức thì
    → và không đụng cụm

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

• **A. Firehose đẩy dữ liệu vào Amazon S3, dựng bảng điều khiển QuickSight với nguồn là Athena — đây là phương án gần nhất và thật sự là kiến trúc data lake hợp lệ, rẻ hơn nhiều, nhưng Athena chỉ đọc nên không đáp ứng yêu cầu sửa đổi dữ liệu bằng SQL, và truy vấn phức tạp lặp lại chậm hơn Redshift.
• **B. Kinesis Data Streams đẩy vào S3, QuickSight với Athena — cùng vấn đề không sửa được dữ liệu, thêm vào đó Data Streams không có đích S3 tích hợp sẵn.
• **D. Kinesis Data Streams đẩy vào Redshift, QuickSight với Redshift — kiến trúc đích đúng nhưng Data Streams không có đích Redshift tích hợp, phải tự viết consumer.

Ghi nhớ

⚠ Đích tích hợp sẵn của Kinesis Data Firehose — bảng phải thuộc: | Đích | Hỗ trợ | |---|---| | S3 | CÓ | | Redshift | CÓ (qua S3) | | OpenSearch | CÓ | | Splunk, HTTP endpoint | CÓ | | Snowflake, Iceberg | CÓ | | DynamoDB, RDS | KHÔNG |

Từ khoá nhận diện:

"stream into data warehouse" → Firehose → Redshift "SQL modifications needed" → Redshift, không phải Athena "fastest complex analytical queries" → Redshift "cheapest, read-only analytics" → S3 + Athena

Ba lưu ý về Firehose: | Lưu ý | Chi tiết | |---|---| | Đệm tối thiểu 60 giây cho Redshift | | | Biến đổi bằng Lambda | | | KHÔNG lưu giữ dữ liệu — mất là mất | |

⚠ Luôn bật sao lưu S3 cho Firehose:

"S3BackupMode": "Enabled"

Redshift gặp sự cố kéo dài
        ↓
    Firehose thử lại rồi bỏ
        ↓
    Có backup → nạp lại được

Ba lưu ý về Redshift: | Lưu ý | Chi tiết | |---|---| | COPY từ S3 là cách nạp đúng | | | DISTKEY quyết định phân bố dữ liệu | | | SORTKEY quyết định tốc độ lọc | |

Ba lưu ý về Redshift Streaming Ingestion: | Lưu ý | Chi tiết | |---|---| | Đọc thẳng từ Kinesis hoặc MSK | | | Materialized view tự làm mới | | | Độ trễ vài giây thay vì 60+ | |

Ba lưu ý về Athena và Redshift: | Tiêu chí | Athena | Redshift | |---|---|---| | Ghi được | KHÔNG | CÓ | | Cần cụm | không | CÓ (trừ Serverless) | | Chi phí | theo TB quét | theo giờ cụm | | Truy vấn lặp lại | chậm hơn | nhanh hơn |

Ba lưu ý về QuickSight: | Lưu ý | Chi tiết | |---|---| | SPICE cache trong bộ nhớ | | | ML Insights phát hiện bất thường | | | Enterprise Edition cho VPC connection | |

Ba lưu ý về chi phí Redshift: | Cách giảm | Chi tiết | |---|---| | RA3 tách tính toán khỏi lưu trữ | | | Reserved node giảm tới 75% | | | Serverless trả theo lượng dùng | | | Spectrum cho dữ liệu nguội trên S3 | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm DeliveryToRedshift.Success của Firehose | | | Đo thời gian từ lúc gửi tới lúc thấy trên bảng | | | Xem STL_LOAD_ERRORS nếu COPY thất bại | |

Và một lời khuyên: hãy theo dõi bảng STL_LOAD_ERRORS của Redshift ngay từ đầu. Firehose báo giao thành công khi nó đã ghi vào S3 và phát lệnh COPY, nhưng nếu COPY thất bại vì một dòng dữ liệu sai định dạng thì bạn sẽ thấy chỉ số giao hàng xanh trong khi bảng vẫn trống.

Đáp án

**D — Dựng Interface endpoint cho Amazon S3.

Vì sao đúng

Đề nêu ba yêu cầu, và interface endpoint là thứ duy nhất đáp ứng cả ba: | Yêu cầu | Gateway endpoint | Interface endpoint | |---|---|---| | Truy cập S3 bằng IP riêng từ VPC | CÓ | CÓ | | Truy cập từ hệ thống TẠI CHỖ | KHÔNG | CÓ | | Truy cập từ VPC ở Region KHÁC | KHÔNG | CÓ |

⚠ Điểm mấu chốt: gateway endpoint hoạt động qua BẢNG ĐỊNH TUYẾN của chính VPC đó:

Gateway endpoint thêm một tuyến
  vào route table
        ↓
    Đích là prefix list của S3
        ↓
    Chỉ tài nguyên TRONG VPC đó dùng
      được
        ↓
    Máy tại chỗ không có route table
      đó
    → không tới được

⚠ Và interface endpoint tạo ENI có IP RIÊNG:

Endpoint là một ENI trong subnet
        ↓
    Có địa chỉ IP riêng, ví dụ
      10.0.1.50
        ↓
    Bất kỳ ai định tuyến tới IP đó
      đều dùng được
        ↓
    Qua Direct Connect, VPN, peering,
      Transit Gateway

Tạo interface endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-1a subnet-1b \
  --security-group-ids sg-endpoint \
  --private-dns-enabled

⚠ Và đây là bảng so sánh đầy đủ phải thuộc: | Tiêu chí | Gateway | Interface | |---|---|---| | Dịch vụ | chỉ S3, DynamoDB | hầu hết dịch vụ | | Cơ chế | route table | ENI có IP riêng | | Chi phí | MIỄN PHÍ | theo giờ + GB | | Từ tại chỗ | KHÔNG | CÓ | | Liên Region | KHÔNG | CÓ (qua peering/TGW) | | Security group | không có | CÓ |

⚠ Và vì sao phương án A không đủ:

A dùng gateway endpoint
        ↓
    Đáp ứng yêu cầu đầu (IP riêng
      từ VPC)
        ↓
    Nhưng KHÔNG đáp ứng hai yêu cầu
      còn lại
        ↓
    Đề nói rõ cần cả từ tại chỗ và
      từ Region khác

⚠ Và vì sao phương án B không chính xác:

B dùng private virtual interface để
  kết nối tới S3
        ↓
    Private VIF chỉ vào được VPC
        ↓
    S3 có endpoint CÔNG KHAI
        ↓
    Muốn tới S3 qua DX:
      - public VIF (IP công khai)
      - hoặc private VIF + interface
        endpoint (IP riêng)
        ↓
    B thiếu vế thứ hai

⚠ Và vì sao phương án C sai — VGW không nối tới dịch vụ:

Virtual private gateway là điểm cuối
  VPN/DX phía AWS
        ↓
    Nó nối mạng tại chỗ với VPC
        ↓
    Không phải cơ chế truy cập S3

⚠ Và private DNS làm interface endpoint trong suốt với ứng dụng:

--private-dns-enabled

`bucket.s3.ap-southeast-1.amazonaws.com`
  phân giải thành IP RIÊNG
        ↓
    Ứng dụng không phải đổi endpoint
        ↓
    Nhưng chỉ hoạt động TRONG VPC đó

⚠ Và từ TẠI CHỖ phải giải quyết DNS riêng:

Máy tại chỗ dùng DNS của công ty
        ↓
    Không phân giải được tên riêng
      của VPC
        ↓
    Ba cách:
      - Route 53 Resolver inbound
        endpoint
      - forwarder trỏ tới VPC_CIDR+2
      - gọi thẳng tên DNS riêng của
        endpoint

aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-abc \
  --query 'VpcEndpoints[0].DnsEntries[].DnsName'

⚠ Và từ Region KHÁC thì phải tắt private DNS:

Private DNS chỉ áp trong VPC chứa
  endpoint
        ↓
    VPC ở Region khác peer tới
        ↓
    Nó phân giải tên S3 thành IP
      CÔNG KHAI của Region nó
        ↓
    Phải dùng tên DNS riêng của
      endpoint, hoặc private hosted
      zone chia sẻ

⚠ Và đây là mẫu endpoint tập trung:

Một shared services VPC chứa
  interface endpoint
        ↓
    Tắt private DNS trên endpoint
        ↓
    Tạo private hosted zone cho
      `s3.ap-southeast-1.amazonaws.com`
        ↓
    Gắn hosted zone đó với mọi VPC
    → tất cả dùng chung một endpoint

aws route53 create-hosted-zone \
  --name s3.ap-southeast-1.amazonaws.com \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-shared \
  --caller-reference $(uuidgen) \
  --hosted-zone-config PrivateZone=true

⚠ Và endpoint policy giới hạn được truy cập:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::du-lieu-mat/*",
  "Condition": {"StringEquals": {
    "aws:PrincipalOrgID": "o-abc123"}}}]}

Qua endpoint này chỉ tới được
  bucket đã khai
        ↓
    Chống rò rỉ sang bucket cá nhân

⚠ Và bucket policy khoá theo endpoint là chiều ngược lại:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::du-lieu-mat",
              "arn:aws:s3:::du-lieu-mat/*"],
 "Condition": {"StringNotEquals": {
   "aws:SourceVpce": "vpce-0abc123"}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một endpoint phục vụ cả ba tình huống | | | Lưu lượng không bao giờ ra Internet | | | Security group và endpoint policy kiểm soát được | |

⚠ Nhưng interface endpoint tính phí — cần cân nhắc:

~0,01 USD/giờ mỗi AZ
        ↓
    Cộng ~0,01 USD/GB xử lý
        ↓
    Hai AZ chạy 24/7 ≈ 15 USD/tháng
      + phí GB
        ↓
    Gateway endpoint miễn phí
    → dùng cả hai nếu hợp lý

⚠ Và mẫu kết hợp là cách tối ưu chi phí:

Gateway endpoint cho lưu lượng
  TRONG VPC (miễn phí)
        ↓
    Interface endpoint cho lưu lượng
      từ tại chỗ và Region khác
        ↓
    Route table ưu tiên gateway
      endpoint cho tài nguyên nội bộ

⚠ Và có hai loại interface endpoint cho S3: | Service name | Dùng cho | |---|---| | com.amazonaws.<region>.s3 | truy cập object thông thường | | com.amazonaws.<region>.s3-outposts | S3 on Outposts | | com.amazonaws.s3-global.accesspoint | Multi-Region Access Point |

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

• **A. Dựng Gateway endpoint cho S3 — đây là phương án gần nhất và miễn phí, đáp ứng hoàn hảo yêu cầu truy cập từ trong VPC, nhưng nó hoạt động qua bảng định tuyến của VPC nên hệ thống tại chỗ và VPC ở Region khác không dùng được.
• **B. Dựng private virtual interface để kết nối tới S3 — private VIF chỉ vào được VPC; muốn tới S3 bằng IP riêng vẫn cần thêm interface endpoint.
• **C. Dựng virtual private gateway để kết nối tới S3 — VGW là điểm cuối VPN/DX phía AWS, không phải cơ chế truy cập dịch vụ.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | Tiêu chí | Gateway | Interface | |---|---|---| | Dịch vụ | S3, DynamoDB | hầu hết | | Chi phí | miễn phí | theo giờ + GB | | Từ tại chỗ | KHÔNG | CÓ | | Liên VPC/Region | KHÔNG | CÓ |

Từ khoá nhận diện:

"access S3 privately from on-premises" → interface endpoint "access S3 privately from VPC only" → gateway endpoint (miễn phí) "access from another Region" → interface endpoint + peering/TGW "DynamoDB from on-premises" → interface endpoint (mới có)

Ba lưu ý về interface endpoint: | Lưu ý | Chi tiết | |---|---| | Tạo ENI, tốn IP trong subnet | | | Security group kiểm soát ai gọi tới | | | Private DNS chỉ áp trong VPC chứa nó | |

⚠ Security group của endpoint phải mở cổng 443:

aws ec2 authorize-security-group-ingress \
  --group-id sg-endpoint \
  --protocol tcp --port 443 \
  --cidr 192.168.0.0/16

Thiếu bước này → kết nối treo
        ↓
    Và không có thông báo lỗi rõ ràng

Ba lưu ý về DNS: | Tình huống | Cách | |---|---| | Trong VPC | private DNS tự phân giải | | Từ tại chỗ | Resolver inbound endpoint | | Endpoint tập trung | tắt private DNS + private hosted zone |

Ba lưu ý về endpoint policy: | Lưu ý | Chi tiết | |---|---| | Mặc định cho phép tất cả | | | Giới hạn tới bucket cụ thể | | | aws:PrincipalOrgID chặn ngoài tổ chức | |

Ba lưu ý về chống rò rỉ dữ liệu: | Lớp | Việc | |---|---| | Endpoint policy | qua endpoint tới được gì | | Bucket policy aws:SourceVpce | bucket nhận từ đâu | | SCP aws:ResourceOrgID | không gọi ra bucket ngoài tổ chức |

Ba lưu ý về chi phí: | Cách | Chi phí | |---|---| | Gateway endpoint | 0 | | Interface endpoint | ~0,01 USD/giờ mỗi AZ + 0,01 USD/GB | | NAT gateway | ~0,045 USD/giờ + 0,045 USD/GB |

⚠ Interface endpoint vẫn rẻ hơn NAT gateway:

Với lưu lượng S3 lớn
        ↓
    Endpoint rẻ hơn NAT khoảng 4 lần
      về phí xử lý
        ↓
    Và không đi qua Internet

Ba lưu ý về chẩn đoán: | Triệu chứng | Nguyên nhân hay gặp | |---|---| | Timeout từ VPC | security group chưa mở 443 | | Vẫn ra Internet | route table chưa gắn gateway endpoint | | Từ tại chỗ không phân giải được | thiếu Resolver inbound endpoint |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig tên bucket từ máy tại chỗ | | | Kiểm IP trả về là địa chỉ riêng | | | Xem VPC Flow Log xác nhận lưu lượng tới ENI endpoint | |

Và một lời khuyên: hãy dùng cả hai loại endpoint song song nếu chi phí là mối quan tâm. Gateway endpoint miễn phí và phục vụ tốt lưu lượng trong VPC, còn interface endpoint chỉ cần cho phần lưu lượng từ tại chỗ và từ Region khác — chia như vậy giữ được cả tính riêng tư lẫn hoá đơn.