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

Đáp án

A — Tạo một DynamoDB Global Table với bảng bản sao ở các Region mong muốn; mỗi Region ghi giao dịch vào bảng bản sao tại chỗ; thay đổi ở một bảng tự động nhân bản sang tất cả các bảng còn lại.

Vì sao đúng

Đề nêu bốn yêu cầu, và Global Tables là dịch vụ duy nhất đáp ứng cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Backend ở NHIỀU Region, xử lý tại Region gần người dùng | ghi vào bảng bản sao địa phương | | Giao dịch ở một Region tự nhân bản sang các Region khác | Global Tables active-active | | Hàng triệu người dùng bốn châu lục | DynamoDB mở rộng ngang | | Tiết kiệm, sẵn sàng cao | không máy chủ, nhân bản qua 3 AZ mỗi Region |

⚠ "Ghi ở mọi Region" là yêu cầu chỉ Global Tables đáp ứng được:

Aurora Global Database: MỘT writer duy nhất
    → mọi ghi phải đi về Region chính
    → người dùng châu Á ghi vào Bắc Mỹ = độ trễ cao
        ↓
DynamoDB Global Tables: GHI ở BẤT KỲ Region nào
    → mỗi Region là writer đầy đủ

Dựng:

aws dynamodb create-table --table-name GiaoDich \
  --attribute-definitions AttributeName=maGiaoDich,AttributeType=S \
  --key-schema AttributeName=maGiaoDich,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

aws dynamodb update-table --table-name GiaoDich \
  --replica-updates '[
    {"Create":{"RegionName":"eu-west-1"}},
    {"Create":{"RegionName":"ap-southeast-1"}},
    {"Create":{"RegionName":"sa-east-1"}}]' \
  --region us-east-1

⚠ Điều kiện bắt buộc: bảng phải bật DynamoDB Streams:

Global Tables dùng Streams làm cơ chế nhân bản
    → `StreamViewType` phải là `NEW_AND_OLD_IMAGES`
        ↓
    Tạo bảng qua console thì tự bật
    → tạo bằng CLI phải khai

Ba đặc điểm phải hiểu: | Đặc điểm | Chi tiết | |---|---| | Độ trễ nhân bản | thường dưới 1 giây | | Giải quyết xung đột | "last writer wins" theo timestamp | | Đọc | eventually consistent giữa các Region |

⚠ "Last writer wins" là đánh đổi phải chấp nhận:

Hai Region cùng ghi một item trong cùng giây
    → bản ghi có timestamp muộn hơn thắng
    → bản kia BIẾN MẤT, không có cảnh báo
        ↓
    Thiết kế để tránh: phân vùng dữ liệu theo Region,
      hoặc dùng khoá duy nhất cho mỗi giao dịch

Mẫu tránh xung đột cho ứng dụng giao dịch:

maGiaoDich = <maRegion>#<uuid>
    → mỗi Region sinh khoá riêng biệt
        ↓
    Không bao giờ có hai Region ghi cùng một khoá
    → không có xung đột để giải quyết

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp cho người dùng mọi châu lục | | | Một Region hỏng, các Region khác vẫn chạy | | | AWS lo toàn bộ việc nhân bản | |

⚠ Global Tables cũng là chiến lược DR mạnh nhất:

Region hỏng hoàn toàn
    → chuyển lưu lượng sang Region khác
    → dữ liệu đã có sẵn ở đó
        ↓
    RPO gần bằng 0, RTO chỉ là thời gian đổi DNS

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

• **D. Aurora Multi-Master ở mọi Region với "Aurora replication" — sai hai lần: Aurora Multi-Master chỉ hoạt động trong MỘT Region (và AWS đã ngừng tính năng này), còn Aurora Global Database thì chỉ có một writer duy nhất, không phải active-active.
• **B. Bảng DynamoDB riêng mỗi Region với Lambda tự đọc và phát lại sang các Region khác — đây là phương án gần nhất và về lý thuyết chạy được, nhưng nó là việc tự dựng lại Global Tables: phải tự xử lý thứ tự, trùng lặp, lỗi, và giải quyết xung đột; ngược thẳng với "scalable, cost-effective".
• **C. Dùng Control Tower và Amazon Connect quản lý bảng DynamoDB — Control Tower dựng và quản trị môi trường nhiều tài khoản; Amazon Connect là tổng đài. Cả hai không liên quan gì tới nhân bản dữ liệu.

Ghi nhớ

⚠ Ba cơ chế nhân bản xuyên Region — bảng phải thuộc: | Cơ chế | Ghi ở nhiều Region | Kiểu dữ liệu | |---|---|---| | DynamoDB Global Tables | ✅ active-active | NoSQL | | Aurora Global Database | ❌ một writer | quan hệ | | S3 Cross-Region Replication | ✅ hai chiều được | object |

⚠ Đây là bảng quyết định cho mọi câu hỏi đa Region:

Cần GHI ở nhiều Region + NoSQL → Global Tables
Cần GHI ở nhiều Region + quan hệ → không có lựa chọn tốt
    → phải phân vùng dữ liệu theo Region
Cần ĐỌC ở nhiều Region + quan hệ → Aurora Global Database

Từ khoá nhận diện:

"writes in one Region replicate to others automatically" → Global Tables "relational, multi-Region DR" → Aurora Global Database "replicate objects" → S3 CRR "single writer, read in many Regions" → Aurora Global

Ba lưu ý về chi phí Global Tables: | Khoản | Chi tiết | |---|---| | Mỗi bản sao tính lưu trữ và năng lực riêng | | | Ghi tính bằng rWCU (replicated WCU) | | | Phí truyền dữ liệu xuyên Region | |

⚠ rWCU đắt hơn WCU thường:

Ghi vào Global Table
    → tính rWCU ở Region ghi
    → cộng rWCU ở MỖI Region bản sao
        ↓
    4 Region = chi phí ghi gấp ~4 lần
    → nhưng đó là cái giá của active-active

Ba lưu ý về tính nhất quán: | Lưu ý | Chi tiết | |---|---| | Trong một Region: strongly consistent read được | | | Giữa các Region: LUÔN eventually consistent | | | Không có strongly consistent read xuyên Region | |

⚠ Ứng dụng phải chịu được điều này:

Người dùng ghi ở Region A rồi đọc ngay ở Region B
    → có thể chưa thấy
        ↓
    Với giao dịch tài chính: đọc lại từ Region đã ghi
    → hoặc thiết kế để người dùng luôn ở một Region

Ba lưu ý về thêm và bớt Region: | Lưu ý | Chi tiết | |---|---| | Thêm bản sao không cần dừng gì | | | Bảng phải cùng tên ở mọi Region | | | Xoá bản sao được, không mất dữ liệu ở nơi khác | |

Ba lưu ý về thiết kế khoá: | Lưu ý | Chi tiết | |---|---| | Khoá phải phân tán đều | | | Nhúng mã Region để tránh xung đột | | | Tránh dùng thời gian làm partition key | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | ReplicationLatency | độ trễ nhân bản mỗi Region | | PendingReplicationCount | tồn đọng | | ThrottledRequests | |

⚠ Đặt cảnh báo cho ReplicationLatency:

aws cloudwatch put-metric-alarm --alarm-name global-table-tre \
  --namespace AWS/DynamoDB --metric-name ReplicationLatency \
  --dimensions Name=TableName,Value=GiaoDich \
    Name=ReceivingRegion,Value=eu-west-1 \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 5000 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

Ba lưu ý về định tuyến người dùng: | Cách | Chi tiết | |---|---| | Route 53 latency routing | tới Region nhanh nhất | | Route 53 geolocation | theo vị trí địa lý | | Global Accelerator | chuyển vùng nhanh hơn |

Ba lưu ý về giao dịch: | Lưu ý | Chi tiết | |---|---| | TransactWriteItems chỉ ACID TRONG một Region | | | Không có giao dịch xuyên Region | | | Thiết kế nghiệp vụ phải tính tới điều này | |

⚠ Đây là giới hạn quan trọng cho ứng dụng tài chính:

Giao dịch ACID chỉ đảm bảo trong Region thực hiện
    → nhân bản sang Region khác là bất đồng bộ
        ↓
    Không thể có giao dịch nguyên tử giữa hai châu lục
    → phải thiết kế theo mô hình saga hoặc
      giữ mỗi giao dịch trong một Region

Ba lưu ý về sao lưu: | Cách | Chi tiết | |---|---| | PITR bật riêng cho từng bản sao | | | Nhân bản KHÔNG thay thế sao lưu | | | Xoá nhầm được nhân bản ngay sang mọi Region | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi ở Region A, đọc ở Region B, đo thời gian | | | Theo dõi ReplicationLatency | | | Thử tắt một Region, xem ứng dụng còn chạy | |

Và một lời khuyên: hãy nhúng mã Region vào khoá chính của mỗi giao dịch. Global Tables giải quyết xung đột bằng cách để bản ghi muộn hơn thắng và bản kia biến mất không dấu vết — với dữ liệu giao dịch tài chính thì cách xử lý đúng là thiết kế sao cho xung đột không bao giờ xảy ra.

Đáp án

C và E — Giảm tải tầng CSDL bằng cụm ElastiCache để cache truy vấn hay dùng; và đổi health check của target group sang một trang HTML đơn giản thay vì trang truy vấn CSDL, đồng thời tạo Route 53 health check cho trang kiểm tra CSDL và cảnh báo qua CloudWatch.

Vì sao đúng

Đề mô tả một vòng xoáy sự cố kinh điển, và hai lựa chọn này cắt nó ở hai chỗ khác nhau:

CSDL quá tải (CPU cao)
    ↓
Health check truy vấn CSDL → timeout
    ↓
ASG cho rằng máy web hỏng → thay máy
    ↓
Máy mới khởi động, mở kết nối mới tới CSDL
    ↓
CSDL càng quá tải hơn
    ↓
    (quay lại từ đầu — vòng lặp không thoát ra được)

⚠ Bài học cốt lõi: health check phải kiểm ĐÚNG thứ nó chịu trách nhiệm:

Health check của target group hỏi:
    "MÁY WEB này có khoẻ không?"
        ↓
    Nó KHÔNG nên hỏi "CSDL có khoẻ không?"
    → vì ASG phản ứng bằng cách thay MÁY WEB
    → hành động sai cho vấn đề sai

Health check đúng — trang tĩnh:

aws elbv2 modify-target-group --target-group-arn <arn> \
  --health-check-path /kiem-tra.html \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 2 --unhealthy-threshold-count 5

Giám sát CSDL riêng bằng Route 53 health check:

aws route53 create-health-check --caller-reference $(uuidgen) \
  --health-check-config '{
    "Type":"HTTPS",
    "FullyQualifiedDomainName":"ung-dung.vidu.com",
    "ResourcePath":"/kiem-tra-csdl",
    "RequestInterval":30,
    "FailureThreshold":3}'

⚠ Tách bạch hai loại kiểm tra: | Kiểm tra | Ai phản ứng | Hành động | |---|---|---| | Health check của ALB | ASG | thay máy web | | Route 53 health check + alarm | con người | điều tra CSDL |

Vấn đề ở CSDL cần CON NGƯỜI xử lý
    → không phải một cơ chế tự động thay máy

ElastiCache giảm tải gốc rễ:

aws elasticache create-replication-group \
  --replication-group-id cache-ung-dung \
  --replication-group-description "Cache truy van hay dung" \
  --engine redis --cache-node-type cache.r7g.large \
  --num-node-groups 1 --replicas-per-node-group 2 \
  --automatic-failover-enabled --multi-az-enabled

Mẫu cache-aside:

def lay_san_pham(ma):
    khoa = f"sp:{ma}"
    gia_tri = r.get(khoa)
    if gia_tri:
        return json.loads(gia_tri)
    du_lieu = truy_van_csdl(ma)
    r.setex(khoa, 300, json.dumps(du_lieu))
    return du_lieu

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Vòng lặp thay máy bị chặn | | | Tải CSDL giảm mạnh | | | Vẫn biết khi CSDL có vấn đề | |

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

• **D. Đổi health check sang kiểm tra TCP trên EC2 — đây là phương án gần nhất và cũng cắt được vòng lặp, nhưng kiểm tra TCP chỉ xác nhận cổng đang mở; ứng dụng có thể treo hoàn toàn mà cổng vẫn mở, nên máy hỏng thật sẽ không bị phát hiện. Trang HTML đơn giản kiểm được cả web server lẫn tiến trình ứng dụng.
• **A. Tạo read replica và trỏ mọi thao tác đọc vào một reader endpoint — RDS MySQL Multi-AZ không có "single reader endpoint" như Aurora; và tự nó không cắt được vòng lặp health check.
• **B. Đặt CloudWatch alarm tự khôi phục RDS khi tải cao — hành động recover dành cho hỏng phần cứng, không phải cho tải cao; và khởi động lại CSDL đang quá tải làm sự cố tệ hơn nhiều.

Ghi nhớ

⚠ Nguyên tắc thiết kế health check — bảng phải thuộc: | Nguyên tắc | Lý do | |---|---| | Chỉ kiểm thứ mà hành động phản ứng sửa được | | | Không kiểm phụ thuộc bên ngoài | | | Nhẹ, nhanh, không tốn tài nguyên | |

⚠ Đây là một trong những sai lầm kiến trúc tốn kém nhất:

Health check "sâu" nghe có vẻ kỹ càng hơn
    → nhưng nó biến sự cố của MỘT phụ thuộc
      thành sự cố của TOÀN BỘ đội máy
        ↓
    Và cơ chế tự phục hồi trở thành cơ chế
      khuếch đại sự cố

Từ khoá nhận diện:

"health check queries database, instances replaced" → đổi sang health check nông "reduce database load" → ElastiCache hoặc read replica "monitor dependency separately" → Route 53 health check + alarm "scale reads" → read replica

Ba mức health check: | Mức | Kiểm gì | |---|---| | TCP | cổng mở — nông nhất | | HTTP trang tĩnh | web server và tiến trình còn sống | | HTTP có kiểm phụ thuộc | sâu — NGUY HIỂM cho ASG |

⚠ Health check sâu vẫn có chỗ dùng — nhưng không phải cho ASG:

Dùng cho: Route 53 failover giữa các Region
          + cảnh báo cho người trực
        ↓
    Không dùng cho: quyết định thay máy

Ba lưu ý về ElastiCache: | Lưu ý | Chi tiết | |---|---| | Luôn đặt TTL cho khoá | | | Redis nếu cần bền và failover | | | Theo dõi CacheHitRate | |

⚠ Cache chỉ có tác dụng nếu tỷ lệ trúng cao:

CacheHitRate 20%
    → 80% truy vấn vẫn xuống CSDL
        ↓
    Xem lại: cache đúng truy vấn chưa,
    TTL có quá ngắn không, bộ nhớ có đủ không

Ba cách khác giảm tải CSDL: | Cách | Chi tiết | |---|---| | Read replica | tách tải đọc | | RDS Proxy | gộp kết nối | | Tối ưu truy vấn và index | thường hiệu quả nhất |

⚠ CPU CSDL cao thường là do truy vấn thiếu index:

Thêm cache che được triệu chứng
    → nhưng một truy vấn quét toàn bảng
      vẫn là truy vấn quét toàn bảng
        ↓
    Dùng Performance Insights tìm truy vấn tốn nhất

aws pi get-resource-metrics \
  --service-type RDS --identifier <id-tai-nguyen> \
  --metric-queries '[{"Metric":"db.load.avg",
    "GroupBy":{"Group":"db.sql_tokenized"}}]' \
  --start-time 2026-08-30T00:00:00Z --end-time 2026-08-30T01:00:00Z \
  --period-in-seconds 300

Ba lưu ý về grace period: | Lưu ý | Chi tiết | |---|---| | health-check-grace-period đủ dài | | | Quá ngắn tạo vòng lặp giết máy | | | Tính cả thời gian ứng dụng khởi động | |

Ba lưu ý về ngưỡng health check: | Tham số | Ảnh hưởng | |---|---| | unhealthy-threshold-count | cao hơn = ít nhạy hơn với lỗi tạm | | interval-seconds | | | timeout-seconds | phải nhỏ hơn interval |

⚠ Ngưỡng quá nhạy cũng gây thay máy oan:

unhealthy-threshold = 2, interval = 10 giây
    → một đợt chậm 20 giây là máy bị thay
        ↓
    Đặt 5 lần thất bại liên tiếp cho ổn định hơn

Ba lưu ý về scale-in protection: | Lưu ý | Chi tiết | |---|---| | Bảo vệ máy đang xử lý việc dở | | | Lifecycle hook để hoàn tất trước khi tắt | | | deregistration_delay của target group | |

Ba lưu ý về phản ứng sự cố: | Việc | Chi tiết | |---|---| | Có runbook cho CSDL quá tải | | | Biết cách tạm dừng ASG scaling | | | Diễn tập tình huống này | |

aws autoscaling suspend-processes \
  --auto-scaling-group-name asg-web \
  --scaling-processes ReplaceUnhealthy

⚠ Lệnh này là cách dừng vòng lặp trong lúc sự cố:

Tạm dừng ReplaceUnhealthy
    → ASG ngừng thay máy
        ↓
    Có thời gian xử lý CSDL
    → rồi bật lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giả lập CSDL chậm, xem máy web có bị thay không | | | Theo dõi CacheHitRate | | | Kiểm tra cảnh báo CSDL vẫn hoạt động | |

Và một lời khuyên: hãy rà lại mọi health check trong hệ thống và hỏi "hành động phản ứng có sửa được thứ này không". Health check chạm vào phụ thuộc bên ngoài biến một sự cố cục bộ thành sự cố toàn hệ thống, và cơ chế tự phục hồi vốn để cứu bạn sẽ trở thành thứ khuếch đại thiệt hại.

Đáp án

C — Chuyển script cron Python thành hàm AWS Lambda, và cấu hình S3 event notification để gọi hàm mỗi khi có object được tải lên bucket.

Vì sao đúng

Đề nêu hai yêu cầu, và S3 event notification là cách trực tiếp nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Xử lý dữ liệu NGAY khi tệp tới | S3 gọi Lambda trong dưới một giây | | ÍT CÔNG SỨC NHẤT | một cấu hình, không thêm dịch vụ nào |

⚠ Đây là mẫu kinh điển "S3 → Lambda":

Cron chạy nửa đêm: dữ liệu chờ tới 24 giờ
        ↓
    S3 event: mỗi tệp được xử lý ngay khi tới
    → độ trễ từ 24 giờ xuống dưới một giây

Cấu hình:

aws s3api put-bucket-notification-configuration \
  --bucket du-lieu-thiet-bi \
  --notification-configuration '{
    "LambdaFunctionConfigurations": [{
      "LambdaFunctionArn": "<arn-ham>",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": {"Key": {"FilterRules": [
        {"Name": "prefix", "Value": "du-lieu-tho/"},
        {"Name": "suffix", "Value": ".json"}]}}}]}

Cấp quyền cho S3 gọi hàm:

aws lambda add-permission --function-name xu-ly-du-lieu \
  --principal s3.amazonaws.com --action lambda:InvokeFunction \
  --statement-id s3-goi \
  --source-arn arn:aws:s3:::du-lieu-thiet-bi

⚠ Vì sao C ít công hơn A: | Phương án | Bộ phận cần dựng | |---|---| | C | S3 notification + Lambda | | A | CloudTrail data event + EventBridge rule + Lambda |

Phương án A đi vòng qua CloudTrail
    → phải bật data event (có phí theo sự kiện)
    → thêm một EventBridge rule
    → độ trễ cao hơn (CloudTrail có độ trễ vài phút)
        ↓
    Trong khi S3 gọi thẳng Lambda được

Xử lý và ghi vào RDS:

import boto3, json, pymysql
s3 = boto3.client('s3')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        gau = ban_ghi['s3']['bucket']['name']
        khoa = ban_ghi['s3']['object']['key']
        doi_tuong = s3.get_object(Bucket=gau, Key=khoa)
        du_lieu = json.loads(doi_tuong['Body'].read())
        ghi_vao_rds(du_lieu)
        s3.delete_object(Bucket=gau, Key=khoa)

⚠ Lambda + RDS cần RDS Proxy:

Mỗi thiết bị gửi tệp mỗi 5 phút
    → hàng nghìn thiết bị = hàng nghìn Lambda đồng thời
    → hàng nghìn kết nối tới RDS
        ↓
    RDS chạm max_connections
    → dùng RDS Proxy để gộp kết nối

aws lambda put-function-concurrency \
  --function-name xu-ly-du-lieu \
  --reserved-concurrent-executions 50

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dữ liệu sẵn sàng gần như tức thì | | | Không còn máy EC2 chạy 24/7 | | | Xử lý song song, không tuần tự | |

⚠ Đây là cải thiện lớn thứ hai — song song hoá:

Cron cũ: một tiến trình xử lý tuần tự cả ngày dữ liệu
        ↓
    Lambda: mỗi tệp một thực thi riêng
    → hàng nghìn tệp xử lý cùng lúc

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

• **A. Lambda + CloudTrail data event + EventBridge rule — đây là phương án gần nhất và hoàn toàn chạy được, nhưng nó đi vòng: phải bật data event (tính phí theo sự kiện), thêm một EventBridge rule, và CloudTrail có độ trễ cao hơn. Đề nói "LEAST amount of effort".
• **B. Lambda + EventBridge rule chạy mỗi phút và nhiều rule song song — vẫn là mô hình bỏ phiếu định kỳ; chạy mỗi phút dù không có tệp nào, và "nhiều rule song song gọi cùng một hàm" không giảm được thời gian xử lý.
• **D. Tăng cỡ EC2 và chạy cron mỗi phút — giữ nguyên máy chạy 24/7, và bỏ phiếu mỗi phút vẫn chậm hơn hẳn so với kích hoạt theo sự kiện.

Ghi nhớ

⚠ Ba cách kích hoạt xử lý từ S3 — bảng phải thuộc: | Cách | Độ trễ | Công dựng | |---|---|---| | S3 event notification | dưới một giây | thấp nhất | | EventBridge (S3 events) | dưới một giây | trung bình, lọc mạnh hơn | | CloudTrail data event → EventBridge | vài phút | cao nhất, có phí |

⚠ EventBridge trực tiếp từ S3 cũng là lựa chọn tốt:

aws s3api put-bucket-notification-configuration \
  --bucket du-lieu-thiet-bi \
  --notification-configuration '{"EventBridgeConfiguration":{}}'

Ưu điểm: lọc theo nội dung phức tạp,
         nhiều đích, không giới hạn 2 filter
        ↓
    Nhược: thêm một bộ phận

Từ khoá nhận diện:

"process as soon as file arrives, least effort" → S3 event notification "complex filtering, multiple targets" → EventBridge "audit who accessed objects" → CloudTrail data events "scheduled batch" → EventBridge Scheduler

Ba lưu ý về S3 event notification: | Lưu ý | Chi tiết | |---|---| | Giao ÍT NHẤT một lần — có thể trùng | | | Không đảm bảo thứ tự | | | Tối đa 100 cấu hình mỗi bucket | |

⚠ Vì có thể trùng, xử lý phải idempotent:

Cùng một tệp có thể gọi hàm hai lần
    → ghi vào RDS hai lần
        ↓
    Dùng khoá duy nhất và `INSERT ... ON DUPLICATE KEY UPDATE`

Ba lưu ý về lọc: | Lưu ý | Chi tiết | |---|---| | Lọc theo prefix và suffix | | | Không lọc = hàm gọi cho MỌI object | | | Ghi kết quả vào bucket khác | |

⚠ Vòng lặp tự kích hoạt là lỗi phổ biến nhất:

Hàm ghi kết quả vào cùng bucket
    → kích hoạt chính nó
        ↓
    VÒNG LẶP VÔ HẠN — hoá đơn không giới hạn

Ba lưu ý về độ tin cậy: | Lưu ý | Chi tiết | |---|---| | S3 → Lambda chỉ thử lại 2 lần rồi bỏ | | | Cấu hình destination OnFailure | | | Hoặc đi qua SQS để có DLQ đầy đủ | |

⚠ S3 → SQS → Lambda bền hơn nhiều:

S3 → Lambda: lỗi thì mất tệp trong im lặng
        ↓
S3 → SQS → Lambda: tin nhắn nằm trong hàng đợi
    → thử lại nhiều lần, hỏng thì vào DLQ
    → và điều tiết được nhịp ghi vào RDS

Ba lưu ý về kết nối RDS: | Lưu ý | Chi tiết | |---|---| | RDS Proxy gộp kết nối | | | Khai kết nối NGOÀI handler | | | Đặt reserved concurrency | |

Ba lưu ý về xoá tệp sau xử lý: | Lưu ý | Chi tiết | |---|---| | Chỉ xoá SAU KHI xử lý thành công | | | Hoặc dùng lifecycle policy | | | Giữ vài ngày để điều tra nếu cần | |

⚠ Lifecycle policy an toàn hơn xoá trong mã:

{"Rules": [{"ID":"xoa-sau-7-ngay","Status":"Enabled",
  "Filter":{"Prefix":"du-lieu-tho/"},
  "Expiration":{"Days":7}}]}

Xử lý lỗi mà đã xoá tệp = mất dữ liệu
    → giữ 7 ngày cho phép chạy lại

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | Lambda Errors, Throttles | | | RDS DatabaseConnections | | | Cảnh báo khi KHÔNG có tệp nào | |

⚠ Cảnh báo khi im lặng cũng quan trọng:

Thiết bị ngừng gửi hoàn toàn
    → không có lỗi nào, chỉ là không có gì
        ↓
    Cảnh báo khi số lời gọi bằng 0 trong X giờ

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | S3 event notification MIỄN PHÍ | | | Lambda theo lời gọi và GB-giây | | | Bỏ được tiền máy EC2 chạy 24/7 | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tệp thử, đo thời gian tới RDS | | | Đẩy nhiều tệp cùng lúc, xem throttle | | | Kiểm tra kết nối RDS không vượt giới hạn | |

Và một lời khuyên: hãy đặt reserved concurrency cho hàm ghi vào RDS. Hàng nghìn thiết bị gửi tệp mỗi năm phút sẽ tạo ra hàng nghìn thực thi Lambda đồng thời, và không giới hạn nghĩa là bạn vừa đổi một cron chậm lấy một cơn lũ kết nối đánh sập cơ sở dữ liệu.

Đáp án

A — Tạo job import với Snowball Edge; dùng AWS SCT xử lý kho dữ liệu tại chỗ và nạp lên thiết bị; cài extraction agent trên một máy chủ riêng và đăng ký với SCT; sau khi Snowball nạp dữ liệu vào S3 thì dùng SCT chuyển tiếp sang Redshift; cấu hình local task và DMS task để nhân bản các cập nhật liên tục.

Vì sao đúng

Đề cho bốn ràng buộc, và phương án này là phương án duy nhất thoả cả bốn: | Ràng buộc | Cách đáp ứng | |---|---| | 60 TB, chỉ 50 Mbps | Snowball Edge — không dùng mạng | | Đổi engine Oracle → Redshift | SCT chuyển đổi lược đồ | | Cập nhật hằng ngày phải theo kịp | DMS CDC nhân bản liên tục | | Xong trong ~30 ngày | Snowball mất 1-2 tuần |

⚠ Tính thử thời gian truyền qua mạng:

60 TB qua 50 Mbps
    → 60.000.000 MB × 8 / 50 Mbps
    → ~111 ngày
        ↓
    Vượt xa cửa sổ 30 ngày
    → mạng không phải lựa chọn

⚠ SCT extraction agent là thành phần đặc biệt cho kho dữ liệu:

SCT không chỉ chuyển đổi lược đồ
    → nó còn có "data extraction agent"
    → trích dữ liệu từ kho, nén, mã hoá
    → ghi thẳng lên thiết bị Snowball
        ↓
    Đây là quy trình AWS thiết kế riêng
      cho migrate kho dữ liệu quy mô lớn

Đăng ký agent với SCT:

1. Cài extraction agent trên máy chủ riêng tại chỗ
2. Trong SCT: Register agent, trỏ tới máy đó
3. Tạo migration task, chọn đích là Snowball Edge
4. Agent trích dữ liệu → ghi lên thiết bị

⚠ Vì sao cài agent trên MÁY RIÊNG:

Trích 60 TB là việc rất nặng CPU và I/O
    → chạy trên chính máy chủ Oracle
      sẽ làm chậm hệ thống sản xuất
        ↓
    Máy riêng để không ảnh hưởng nghiệp vụ

Xử lý cập nhật hằng ngày bằng DMS CDC:

aws dms create-replication-task \
  --replication-task-identifier bat-kip-cap-nhat \
  --source-endpoint-arn <arn-oracle> \
  --target-endpoint-arn <arn-redshift> \
  --replication-instance-arn <arn-may> \
  --migration-type cdc \
  --cdc-start-position "<scn-luc-bat-dau-trich>"

⚠ Điểm bắt đầu CDC phải khớp với lúc bắt đầu trích dữ liệu:

Trích dữ liệu lúc SCN = 12345
    → CDC phải bắt đầu từ SCN đó
        ↓
    Sớm hơn: dữ liệu trùng
    Muộn hơn: MẤT dữ liệu trong khoảng trống

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không chiếm băng thông của nghiệp vụ | | | Dữ liệu nền chuyển bằng đường vật lý | | | Cập nhật hằng ngày theo kịp qua mạng | |

⚠ Cập nhật hằng ngày là khối lượng NHỎ — 50 Mbps đủ:

60 TB dữ liệu nền → Snowball
Cập nhật nhỏ hằng ngày → CDC qua mạng
        ↓
    Đúng công cụ cho đúng khối lượng

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

• **D. Snowball Edge, nhập vào S3, tạo RDS for Oracle rồi SCT + DMS sang Redshift, chép cập nhật thiếu qua Internet — đây là phương án gần nhất và cũng dùng Snowball, nhưng nó thêm một bước RDS for Oracle trung gian hoàn toàn thừa (tốn tiền, tốn thời gian), và "chép cập nhật thiếu qua Internet" là thủ công, không phải CDC.
• **B. Dựng RDS Oracle và nhân bản qua VPN rồi mới sang Redshift — nhân bản 60 TB qua VPN trên đường 50 Mbps vẫn mất hơn 100 ngày; VPN không thay đổi băng thông vật lý.
• **C. Dựng Direct Connect 1 Gbps và Oracle RAC trên EC2 — Direct Connect mất nhiều tuần tới nhiều tháng để cung cấp, không kịp cửa sổ 30 ngày; và dựng Oracle RAC trên EC2 là công việc rất lớn không cần thiết.

Ghi nhớ

⚠ SCT vs DMS — bảng phải thuộc: | Công cụ | Chuyển gì | |---|---| | SCT (Schema Conversion Tool) | LƯỢC ĐỒ, mã, thủ tục — khi ĐỔI ENGINE | | DMS | DỮ LIỆU — cả full load lẫn CDC | | SCT extraction agent | dữ liệu kho quy mô lớn, ghi ra Snowball |

⚠ Quy tắc: đổi engine thì cần SCT, cùng engine thì không.

Từ khoá nhận diện:

"Oracle to Redshift/PostgreSQL, huge data, low bandwidth" → SCT + extraction agent + Snowball + DMS CDC "same engine migration" → chỉ DMS "ongoing replication" → DMS CDC "petabytes, no network" → Snowball / Snowmobile

⚠ Công thức quyết định Snowball hay mạng:

Thời gian (ngày) = dung lượng (TB) × 8000
                   / (băng thông Mbps × 86,4)
        ↓
    Quá một tuần → cân nhắc Snowball
    Quá một tháng → chắc chắn Snowball

Ba giai đoạn của một cuộc di chuyển lớn: | Giai đoạn | Công cụ | |---|---| | Chuyển lược đồ | SCT | | Chuyển dữ liệu nền | Snowball hoặc DMS full load | | Bắt kịp thay đổi | DMS CDC |

Ba lưu ý về SCT: | Lưu ý | Chi tiết | |---|---| | Sinh báo cáo đánh giá độ khó trước | | | Phần không tự chuyển được thì báo rõ | | | Chuyển được cả stored procedure và view | |

⚠ Chạy báo cáo đánh giá TRƯỚC khi lập kế hoạch:

SCT Assessment Report cho biết:
    → bao nhiêu % tự động chuyển được
    → những đối tượng nào phải viết lại tay
        ↓
    Đây là dữ liệu để ước lượng thời gian thật

Ba lưu ý về extraction agent: | Lưu ý | Chi tiết | |---|---| | Chạy nhiều agent song song cho nhanh | | | Nén và mã hoá dữ liệu khi trích | | | Ghi thẳng ra Snowball hoặc S3 | |

Ba lưu ý về Snowball Edge: | Lưu ý | Chi tiết | |---|---| | ~80 TB dùng được (Storage Optimized) | | | Mã hoá 256-bit bằng khoá KMS | | | Nhập dữ liệu vào AWS MIỄN PHÍ | |

⚠ 60 TB vừa một thiết bị — nhưng nên đặt hai:

Một thiết bị 80 TB đủ cho 60 TB
    → nhưng nếu có sự cố thì mất cả chu kỳ vận chuyển
        ↓
    Hai thiết bị chạy song song
    → nhanh hơn và có dự phòng

Ba lưu ý về Redshift: | Lưu ý | Chi tiết | |---|---| | Chọn distribution key và sort key đúng | | | COPY từ S3 là cách nạp nhanh nhất | | | Chạy ANALYZE sau khi nạp | |

⚠ Distribution key quyết định hiệu năng truy vấn:

Chọn sai: dữ liệu lệch giữa các node
    → một node làm hết việc
        ↓
    Chọn cột có độ đa dạng cao và hay dùng để JOIN

Ba lưu ý về DMS CDC với Oracle: | Lưu ý | Chi tiết | |---|---| | Bật supplemental logging | | | Dùng LogMiner hoặc Binary Reader | | | Theo dõi archive log không đầy đĩa | |

⚠ Archive log tích tụ là rủi ro cho hệ thống nguồn:

DMS đọc archive log để lấy thay đổi
    → task dừng thì log không được dọn
        ↓
    Đĩa nguồn đầy → CSDL SẢN XUẤT ngừng
    → theo dõi dung lượng đĩa cùng với độ trễ CDC

Ba lưu ý về cắt chuyển: | Bước | Chi tiết | |---|---| | Chờ độ trễ CDC về 0 | | | Dừng ghi ở nguồn | | | Chuyển ứng dụng sang Redshift | |

Ba lưu ý về kiểm chứng dữ liệu: | Việc | Cách | |---|---| | Bật DMS validation | | | So số dòng từng bảng | | | So tổng của vài cột số | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Theo dõi tiến độ trích của agent | | | Kiểm tra dữ liệu trong S3 sau khi nhập | | | Theo dõi CDCLatencyTarget | |

Và một lời khuyên: hãy ghi lại chính xác điểm SCN lúc bắt đầu trích dữ liệu. Toàn bộ tính đúng đắn của cuộc di chuyển nằm ở việc CDC bắt đầu đúng từ mốc đó — sớm hơn thì dữ liệu trùng, muộn hơn thì có một khoảng trống mà không ai phát hiện ra cho tới khi báo cáo lệch số.

Đáp án

A — Đăng ký tên miền trên Route 53 và bật DNSSEC validation cho mọi public hosted zone; dùng ACM sinh chứng chỉ TLS/SSL hợp lệ; cấu hình ALB với listener HTTPS dùng chứng chỉ đó.

Vì sao đúng

Đề nêu ba loại tấn công "kẻ đứng giữa", và mỗi loại có một biện pháp chống: | Tấn công | Biện pháp | |---|---| | DNS spoofing | DNSSEC — ký số bản ghi DNS | | HTTPS spoofing / SSL hijacking | chứng chỉ TLS hợp lệ từ CA tin cậy | | Nghe lén đường truyền | HTTPS end-to-end |

⚠ DNSSEC chống chính xác kiểu tấn công DNS spoofing:

Không có DNSSEC:
    → kẻ tấn công giả mạo phản hồi DNS
    → khách hàng bị dẫn tới máy chủ giả
        ↓
DNSSEC: mỗi bản ghi được KÝ SỐ
    → trình phân giải kiểm chữ ký
    → phản hồi giả bị từ chối

Bật DNSSEC cho hosted zone:

aws route53 create-key-signing-key \
  --hosted-zone-id <id-zone> \
  --key-management-service-arn <arn-khoa-kms> \
  --name khoa-ky-chinh --status ACTIVE

aws route53 enable-hosted-zone-dnssec --hosted-zone-id <id-zone>

⚠ Khoá KSK phải là khoá KMS loại ECC_NIST_P256 ở us-east-1:

DNSSEC của Route 53 yêu cầu:
    → khoá bất đối xứng ECC_NIST_P256
    → BẮT BUỘC ở Region us-east-1
        ↓
    Tạo ở Region khác sẽ không dùng được

Và phải thêm bản ghi DS ở registry cha:

aws route53 get-dnssec --hosted-zone-id <id-zone> \
  --query "KeySigningKeys[0].DSRecord"

Lấy bản ghi DS rồi khai vào nơi đăng ký tên miền
    → thiếu bước này, DNSSEC KHÔNG có hiệu lực
    → chuỗi tin cậy bị đứt

Chứng chỉ ACM miễn phí và tự gia hạn:

aws acm request-certificate \
  --domain-name vidu.com \
  --subject-alternative-names "*.vidu.com" \
  --validation-method DNS

⚠ Xác thực bằng DNS thì ACM tự gia hạn vĩnh viễn:

Xác thực bằng email: phải xác nhận lại mỗi lần gia hạn
        ↓
    Xác thực bằng DNS: bản ghi CNAME nằm mãi
    → ACM tự gia hạn, không ai phải nhớ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chứng chỉ ACM miễn phí cho ALB và CloudFront | | | Tự gia hạn — không bao giờ hết hạn bất ngờ | | | DNSSEC do Route 53 quản lý, không tự vận hành khoá | |

⚠ Chứng chỉ hết hạn là sự cố hay gặp và hoàn toàn tránh được:

Chứng chỉ mua ngoài: phải nhớ gia hạn thủ công
    → quên = trang web báo lỗi bảo mật với mọi khách
        ↓
    ACM + xác thực DNS: không bao giờ xảy ra

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

• **C. Đăng ký ở Route 53 nhưng dùng nhà cung cấp DNS bên thứ ba cho DNSSEC và nhập chứng chỉ bên ngoài vào ACM — đây là phương án gần nhất và về kỹ thuật chạy được, nhưng nó bỏ qua khả năng DNSSEC gốc của Route 53 và mất tính năng tự gia hạn của ACM (chứng chỉ nhập vào phải tự gia hạn).
• **B. Dùng nhà cung cấp DNS bên thứ ba hỗ trợ DNSSEC với khoá tự quản lý — cùng vấn đề: tự vận hành khoá DNSSEC là công việc phức tạp và rủi ro, trong khi Route 53 làm sẵn.
• **D. Tự host DNS root server trên EC2 chạy BIND — mô tả sai về Route 53: Route 53 hỗ trợ DNSSEC cho cả hosted zone công khai từ 2020, không chỉ cho việc đăng ký. Và tự vận hành BIND là bước lùi lớn về vận hành lẫn bảo mật.

Ghi nhớ

⚠ Ba lớp bảo vệ chống "kẻ đứng giữa" — bảng phải thuộc: | Lớp | Chống gì | |---|---| | DNSSEC | giả mạo phản hồi DNS | | TLS với chứng chỉ hợp lệ | giả mạo máy chủ, nghe lén | | HSTS | hạ cấp xuống HTTP |

⚠ HSTS là lớp thứ ba nên thêm:

Strict-Transport-Security: max-age=31536000; includeSubDomains
        ↓
    Trình duyệt TỪ CHỐI kết nối HTTP tới tên miền này
    → chặn tấn công hạ cấp giao thức

aws cloudfront create-response-headers-policy \
  --response-headers-policy-config '{
    "Name":"header-bao-mat",
    "SecurityHeadersConfig":{
      "StrictTransportSecurity":{"Override":true,
        "AccessControlMaxAgeSec":31536000,
        "IncludeSubdomains":true,"Preload":true}}}'

Từ khoá nhận diện:

"DNS spoofing, DNSSEC" → Route 53 DNSSEC signing "free auto-renewing certificate" → ACM với xác thực DNS "protect from downgrade to HTTP" → HSTS "validate DNS responses from resolver side" → DNSSEC validation

⚠ DNSSEC có hai vế — phân biệt rõ: | Vế | Việc | |---|---| | Signing | hosted zone KÝ bản ghi của mình | | Validation | resolver KIỂM chữ ký của tên miền khác |

Bảo vệ khách hàng của BẠN → signing
Bảo vệ ứng dụng của bạn khi gọi ra ngoài → validation
        ↓
    Route 53 Resolver bật validation được

aws route53resolver update-resolver-dnssec-config \
  --resource-id vpc-abc --validation ENABLE

Ba lưu ý về DNSSEC: | Lưu ý | Chi tiết | |---|---| | Phải thêm bản ghi DS ở registry cha | | | Khoá KSK dùng KMS ở us-east-1 | | | Xoay khoá định kỳ | |

⚠ DNSSEC cấu hình sai làm tên miền BIẾN MẤT:

Bản ghi DS không khớp khoá đang ký
    → resolver có validation TỪ CHỐI mọi phản hồi
        ↓
    Tên miền không phân giải được với một phần
      người dùng — rất khó chẩn đoán
        ↓
    Kiểm tra kỹ trước khi bật, và có kế hoạch tắt

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Miễn phí cho ALB, CloudFront, API Gateway | | | CloudFront cần chứng chỉ ở us-east-1 | | | Không xuất được khoá riêng ra ngoài | |

⚠ ACM không cho xuất khoá riêng:

Chỉ dùng được với dịch vụ AWS tích hợp
    → cần chứng chỉ cho EC2 tự quản lý
        ↓
    Dùng ACM Private CA, hoặc mua chứng chỉ ngoài

Ba lưu ý về listener HTTPS: | Lưu ý | Chi tiết | |---|---| | Chọn security policy TLS hiện đại | | | Chuyển hướng HTTP sang HTTPS | | | Gắn nhiều chứng chỉ qua SNI | |

aws elbv2 create-listener --load-balancer-arn <arn-alb> \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=<arn-cert> \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=<arn-tg>

Ba lưu ý về mã hoá tới backend: | Lưu ý | Chi tiết | |---|---| | TLS kết thúc ở ALB theo mặc định | | | Mã hoá tiếp tới target nếu cần | | | Tuân thủ có thể đòi end-to-end | |

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | ViewerProtocolPolicy: redirect-to-https | | | OriginProtocolPolicy: https-only | | | Chứng chỉ phải ở us-east-1 | |

Ba lưu ý về giám sát: | Việc | Cách | |---|---| | Cảnh báo khi chứng chỉ sắp hết hạn | | | Config rule acm-certificate-expiration-check | | | Kiểm tra DNSSEC bằng công cụ ngoài | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig +dnssec vidu.com | xem có bản ghi RRSIG | | Kiểm tra chuỗi tin cậy DNSSEC | | | Chạy quét TLS bằng công cụ ngoài | |

dig +dnssec vidu.com | grep RRSIG
aws route53 get-dnssec --hosted-zone-id <id-zone>

Và một lời khuyên: hãy kiểm tra bản ghi DS đã được khai ở registry cha trước khi coi DNSSEC là xong. Ký bản ghi mà không có DS ở cấp trên nghĩa là chuỗi tin cậy bị đứt — bạn trả tiền cho KMS và chịu mọi rủi ro cấu hình mà không nhận được chút bảo vệ nào.

Đáp án

C — Cấu hình lại redrive policy của SQS và đặt maxReceiveCount thành 10 để consumer được thử lại nhiều lần trước khi tin nhắn bị đẩy sang dead-letter queue.

Vì sao đúng

Đề cho ba con số, và mâu thuẫn giữa chúng chính là nguyên nhân: | Thông số | Giá trị | |---|---| | Thời gian xử lý mỗi video | 20-40 phút | | Visibility timeout | 1 giờ | | maxReceiveCount | 1 |

⚠ maxReceiveCount = 1 nghĩa là KHÔNG có lần thử lại nào:

Tin nhắn được nhận lần thứ nhất
    → nếu không bị xoá trong visibility timeout
    → nó quay lại hàng đợi
        ↓
    Lần nhận thứ HAI vượt maxReceiveCount = 1
    → đẩy thẳng sang DLQ

Vì sao đội phát triển không tìm thấy lỗi trong log:

Không có lỗi ứng dụng nào cả
    → máy EC2 bị Auto Scaling thay
    → hoặc máy Spot bị lấy lại
    → hoặc quá trình bị khởi động lại
        ↓
    Tin nhắn quay lại hàng đợi một cách BÌNH THƯỜNG
    → nhưng maxReceiveCount = 1 biến việc đó
      thành "thất bại vĩnh viễn"

Sửa:

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

⚠ maxReceiveCount nên phản ánh mức độ chấp nhận thử lại: | Giá trị | Ý nghĩa | |---|---| | 1 | không thử lại — gần như luôn sai | | 3-5 | phổ biến cho tác vụ ngắn | | 10 | hợp cho tác vụ dài, hay bị gián đoạn hạ tầng |

Vì sao D (tăng visibility timeout) không phải nguyên nhân chính:

Video mất 20-40 phút
Visibility timeout đã là 60 phút
        ↓
    Còn dư 20 phút biên
    → thời gian không phải vấn đề

⚠ Nhưng nếu có video ngoại lệ vượt 60 phút thì vẫn nên gia hạn động:

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

def gia_han_dinh_ky(url, receipt, dung_lai):
    while not dung_lai.is_set():
        sqs.change_message_visibility(
            QueueUrl=url, ReceiptHandle=receipt,
            VisibilityTimeout=1800)
        dung_lai.wait(600)

Gia hạn mỗi 10 phút trong lúc còn xử lý
    → xử lý bao lâu cũng được
    → mà không phải đặt timeout dài cố định

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Video không bị bỏ vì gián đoạn hạ tầng | | | DLQ chỉ chứa lỗi THẬT | | | Cảnh báo DLQ lấy lại giá trị chẩn đoán | |

⚠ Vế cuối quan trọng hơn người ta nghĩ:

DLQ đầy tin nhắn không phải lỗi thật
    → đội phát triển quen bỏ qua cảnh báo
        ↓
    Ngày có lỗi thật, không ai để ý
    → cảnh báo mất hoàn toàn tác dụng

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

• **D. Tăng visibility timeout lên 2 giờ — đây là phương án gần nhất và là một cấu hình hợp lý về nguyên tắc, nhưng con số trong đề không ủng hộ nó: xử lý mất 20-40 phút trong khi timeout đã là 60 phút, còn dư biên. Nó không giải thích được vì sao tin nhắn vào DLQ.
• **B. Đặt số máy tối thiểu cho Auto Scaling group vì "quá trình mở rộng chậm" — mở rộng chậm khiến tin nhắn chờ lâu hơn, nhưng tin nhắn chưa được nhận thì không tăng receive count và không vào DLQ.
• **A. Tăng delivery delay của hàng đợi — delivery delay làm tin nhắn xuất hiện muộn hơn, hoàn toàn không liên quan tới việc tin nhắn bị đẩy sang DLQ.

Ghi nhớ

⚠ Ba tham số SQS quyết định hành vi thử lại — bảng phải thuộc: | Tham số | Việc | |---|---| | VisibilityTimeout | bao lâu tin nhắn bị ẩn sau khi nhận | | maxReceiveCount | nhận bao nhiêu lần thì sang DLQ | | MessageRetentionPeriod | giữ tối đa bao lâu (tới 14 ngày) |

⚠ Công thức đặt visibility timeout:

VisibilityTimeout ≥ thời gian xử lý TỆ NHẤT × 1,5
        ↓
    Hoặc dùng ChangeMessageVisibility gia hạn động
    → linh hoạt hơn nhiều

Từ khoá nhận diện:

"messages in DLQ but no application errors" → maxReceiveCount quá thấp "message processed twice" → visibility timeout quá ngắn "messages disappear before processing" → retention period "consumers idle then flood" → long polling

Ba nguyên nhân tin nhắn quay lại hàng đợi mà KHÔNG phải lỗi ứng dụng: | Nguyên nhân | Chi tiết | |---|---| | Máy bị Auto Scaling thay | | | Spot instance bị lấy lại | | | Tiến trình bị khởi động lại khi triển khai | |

⚠ Đây chính là tình huống của đề:

ASG co giãn theo số tin nhắn trong hàng đợi
    → tin nhắn giảm → ASG thu nhỏ → giết máy
        ↓
    Máy đang xử lý video bị giết giữa chừng
    → tin nhắn quay lại → maxReceiveCount = 1 → DLQ

Ba biện pháp bảo vệ máy đang xử lý: | Biện pháp | Chi tiết | |---|---| | Lifecycle hook EC2_INSTANCE_TERMINATING | | | Scale-in protection | | | Xử lý SIGTERM để hoàn tất việc | |

aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name asg-xu-ly-video \
  --lifecycle-hook-name cho-hoan-tat \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 3600

⚠ Lifecycle hook cho phép hoàn tất video trước khi máy bị tắt:

ASG muốn tắt máy
    → hook giữ máy ở trạng thái Terminating:Wait
    → ứng dụng xử lý nốt rồi báo hoàn tất
        ↓
    Tin nhắn được xoá đúng cách, không quay lại

Ba lưu ý về DLQ: | Lưu ý | Chi tiết | |---|---| | DLQ phải cùng loại với hàng đợi nguồn | | | Retention của DLQ nên dài hơn | | | Redrive tin nhắn từ DLQ về được | |

aws sqs start-message-move-task \
  --source-arn <arn-dlq> \
  --destination-arn <arn-hang-doi-goc>

Ba lưu ý về cảnh báo DLQ: | Lưu ý | Chi tiết | |---|---| | Cảnh báo khi có bất kỳ tin nào | | | Nhưng chỉ hữu ích nếu DLQ sạch | | | Rà nguyên nhân trước khi tăng ngưỡng | |

Ba lưu ý về mở rộng theo hàng đợi: | Lưu ý | Chi tiết | |---|---| | Dùng "tin nhắn mỗi máy", không dùng tổng | | | Thu nhỏ chậm hơn mở rộng | | | Tính tới thời gian xử lý dài | |

⚠ Với tác vụ 40 phút, thu nhỏ phải rất thận trọng:

Metric giảm ngay khi tin nhắn được NHẬN
    → nhưng máy còn xử lý 40 phút nữa
        ↓
    ASG tưởng rảnh và giết máy
    → dùng "tin nhắn visible + not visible"
      làm metric thay vì chỉ visible

Ba lưu ý về idempotency: | Lưu ý | Chi tiết | |---|---| | Thử lại nghĩa là có thể xử lý trùng | | | Kiểm tra kết quả đã tồn tại chưa trước khi làm | | | Ghi kết quả với tên xác định từ đầu vào | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | tồn đọng lâu chưa | | ApproximateNumberOfMessagesNotVisible | đang xử lý | | NumberOfMessagesSent của DLQ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem log của máy bị thay quanh lúc tin vào DLQ | | | Redrive tin từ DLQ, xem xử lý thành công không | | | Theo dõi DLQ sau khi đổi cấu hình | |

Và một lời khuyên: hãy coi maxReceiveCount = 1 là một lỗi cấu hình, không phải một lựa chọn. Nó biến mọi gián đoạn hạ tầng bình thường — thay máy, triển khai, lấy lại Spot — thành thất bại vĩnh viễn, và đội vận hành sẽ đi tìm lỗi ứng dụng vốn không hề tồn tại.

Đáp án

C — Dùng CloudFront cache và phân phối ảnh độ phân giải cao cùng tài sản tĩnh, và triển khai AWS WAF trên CloudFront distribution để chống các tấn công web thường gặp.

Vì sao đúng

Đề nêu ba ràng buộc, và phương án này là phương án duy nhất thoả cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | HẠN CHÓT GẤP, không kịp migrate | CloudFront đặt trước origin tại chỗ — không đụng ứng dụng | | Lưu lượng sắp tăng mạnh | edge hấp thụ phần lớn request | | Cần chặn SQL injection và XSS | WAF gắn vào CloudFront |

⚠ CloudFront hỗ trợ origin TẠI CHỖ — đây là điều nhiều người không biết:

Custom origin của CloudFront có thể là
BẤT KỲ máy chủ HTTP nào có tên miền công khai
        ↓
    Kể cả máy chủ trong trung tâm dữ liệu của bạn
    → không cần migrate gì cả

Cấu hình origin tại chỗ:

aws cloudfront create-distribution --distribution-config '{
  "CallerReference": "flight-deals",
  "Origins": {"Quantity": 1, "Items": [{
    "Id": "goc-tai-cho",
    "DomainName": "goc.flightdeals.vidu.com",
    "CustomOriginConfig": {
      "HTTPPort": 80, "HTTPSPort": 443,
      "OriginProtocolPolicy": "https-only",
      "OriginSslProtocols": {"Quantity":1,"Items":["TLSv1.2"]}}}]},
  "DefaultCacheBehavior": {
    "TargetOriginId": "goc-tai-cho",
    "ViewerProtocolPolicy": "redirect-to-https",
    "CachePolicyId": "<CachingOptimized>"},
  "Enabled": true}'

⚠ Ảnh độ phân giải cao là loại nội dung cache HIỆU QUẢ NHẤT:

Ảnh điểm du lịch: giống nhau với mọi khách
    → cache một lần ở edge
    → phục vụ hàng triệu lượt mà không chạm origin
        ↓
    Tỷ lệ trúng cache có thể trên 95%
    → origin tại chỗ chỉ nhận vài phần trăm lưu lượng

Gắn WAF:

aws wafv2 create-web-acl --name acl-flight-deals \
  --scope CLOUDFRONT --region us-east-1 \
  --default-action Allow={} \
  --rules '[
    {"Name":"ChanOWASP","Priority":1,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesCommonRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"ChanOWASP"}},
    {"Name":"ChanSQLi","Priority":2,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesSQLiRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"ChanSQLi"}}]' \
  --visibility-config 'SampledRequestsEnabled=true,
    CloudWatchMetricsEnabled=true,MetricName=aclFlightDeals'

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

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Triển khai trong vài giờ, không sửa ứng dụng | | | Chặn tấn công ở edge, trước khi tới origin | | | Giảm mạnh tải lên hạ tầng tại chỗ | |

⚠ Đây cũng là bước đệm tự nhiên cho việc migrate sau này:

Hôm nay: CloudFront → origin tại chỗ
        ↓
    Sau khi migrate: đổi origin sang ALB trên AWS
    → khách hàng không thấy gì thay đổi
    → cùng một tên miền, cùng một distribution

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

• **B. Tạo AMI từ website hiện tại, dựng ASG và đặt ALB cân bằng giữa máy chủ tại chỗ và EC2 — đây là phương án gần nhất và có ý tưởng lai hợp lý, nhưng ALB không nhận target ngoài VPC qua Internet công cộng; và tạo AMI từ một máy chủ vật lý tại chỗ đòi cả một quy trình migrate mà đề nói không có thời gian.
• **A. Dùng AWS Server Migration Service migrate rồi dựng ASG — SMS đã ngừng (thay bằng Application Migration Service), và migrate toàn bộ là đúng thứ đề nói không kịp làm.
• **D. Dựng S3 static website và chuyển tên miền sang Route 53 — website có thanh toán qua bên thứ ba và logic tìm kiếm chuyến bay; đó là ứng dụng động, không phải trang tĩnh.

Ghi nhớ

⚠ CloudFront không đòi origin phải nằm trên AWS: | Loại origin | Ví dụ | |---|---| | S3 bucket | tài sản tĩnh | | ALB / EC2 | ứng dụng trên AWS | | Custom origin bất kỳ | máy chủ tại chỗ, đám mây khác | | MediaPackage, Lambda Function URL | |

⚠ Đây là mẫu "migrate dần" rất hữu ích:

Bước 1: CloudFront trước origin tại chỗ
    → giảm tải ngay, có WAF ngay
        ↓
Bước 2: chuyển tài sản tĩnh sang S3
        ↓
Bước 3: chuyển ứng dụng sang AWS
    → đổi origin, khách hàng không biết

Từ khoá nhận diện:

"no time to migrate, handle traffic spike" → CloudFront trước origin hiện có "block SQL injection and XSS" → WAF "protect from DDoS layer 3/4" → Shield "migrate servers to AWS" → Application Migration Service (MGN)

Ba nhóm quy tắc WAF nên bật: | Nhóm | Chống | |---|---| | AWSManagedRulesCommonRuleSet | XSS, path traversal, OWASP cơ bản | | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesKnownBadInputsRuleSet | payload đã biết | | AWSManagedRulesAmazonIpReputationList | IP xấu |

⚠ Luôn chạy chế độ COUNT trước khi BLOCK:

Bật BLOCK ngay
    → quy tắc quản lý có thể chặn lưu lượng hợp lệ
        ↓
    Chạy COUNT vài ngày, xem log, thêm ngoại lệ
    → rồi mới chuyển sang BLOCK

Ba lưu ý về bảo vệ origin: | Lưu ý | Chi tiết | |---|---| | Chỉ cho CloudFront gọi origin | | | Dùng custom header bí mật | | | Hoặc managed prefix list của CloudFront | |

⚠ Không bảo vệ origin thì WAF vô nghĩa:

Kẻ tấn công tìm ra IP thật của máy chủ tại chỗ
    → gọi thẳng, bỏ qua CloudFront và WAF
        ↓
    Tường lửa tại chỗ chỉ cho dải IP
      của CloudFront, hoặc kiểm header bí mật

Ba lưu ý về cache: | Loại nội dung | TTL | |---|---| | Ảnh, CSS, JS | dài (ngày tới năm) | | HTML | ngắn hoặc theo header | | API động | không cache |

⚠ Tách cache behavior theo đường dẫn:

{"CacheBehaviors": {"Quantity": 2, "Items": [
  {"PathPattern": "/anh/*", "CachePolicyId": "<CachingOptimized>"},
  {"PathPattern": "/api/*", "CachePolicyId": "<CachingDisabled>"}]}}

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudFront ~0,085 USD/GB | rẻ hơn nhiều so với nâng đường truyền tại chỗ | | WAF ~5 USD/web ACL + 1 USD/quy tắc + 0,60 USD/triệu request | | | Price class giới hạn edge để giảm giá | |

Ba lưu ý về Shield: | Lưu ý | Chi tiết | |---|---| | Shield Standard đã BẬT SẴN, miễn phí | | | Shield Advanced ~3.000 USD/tháng | | | Có đội phản ứng DDoS và hoàn phí | |

Ba lưu ý về rate limiting: | Lưu ý | Chi tiết | |---|---| | Rate-based rule chặn IP gửi quá nhiều | | | Bảo vệ origin khỏi bị dồn | | | Đặt ngưỡng theo lưu lượng bình thường | |

{"Name": "GioiHanTanSuat", "Priority": 10,
 "Statement": {"RateBasedStatement":
   {"Limit": 2000, "AggregateKeyType": "IP"}},
 "Action": {"Block": {}}}

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp = origin vẫn chịu tải | | OriginLatency | origin tại chỗ có nghẽn không | | WAF BlockedRequests | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo tỷ lệ trúng cache sau vài ngày | | | Gửi payload SQLi thử | phải bị chặn | | Thử gọi thẳng origin | phải bị tường lửa chặn |

Và một lời khuyên: hãy khoá origin lại ngay khi đặt CloudFront lên trước nó. Một WAF hoàn hảo ở edge không bảo vệ được gì nếu địa chỉ thật của máy chủ vẫn nhận kết nối trực tiếp — và địa chỉ đó thường tìm ra chỉ bằng vài phút tra cứu lịch sử DNS.

Đáp án

C — Dùng Kinesis Data Streams nhận dữ liệu sinh trắc; phân tích bằng Kinesis và hiển thị trên bảng điều khiển thời gian thực; tổng hợp rồi đẩy sang S3; lưu vào Redshift có sao lưu tự động cho phân tích lâu dài.

Vì sao đúng

Đề nêu bốn yêu cầu, và kiến trúc này đáp ứng từng cái bằng đúng công cụ: | Yêu cầu | Thành phần | |---|---| | Nhận dữ liệu mỗi giây từ hàng loạt vòng cổ | Kinesis Data Streams | | Phân tích và giám sát THỜI GIAN THỰC | phân tích luồng + dashboard | | Báo cáo xu hướng và sức khoẻ đầy đủ | Redshift | | Bền, sẵn sàng, co giãn | S3 + Redshift có sao lưu |

⚠ Kinesis Data Streams là lựa chọn đúng cho dữ liệu "mỗi giây":

Dữ liệu tới liên tục, tần suất cao
    → cần đệm có thứ tự và đọc lại được
        ↓
    Và cho phép NHIỀU người tiêu thụ cùng lúc:
    → một cho dashboard thời gian thực
    → một cho việc ghi vào kho

Dựng luồng:

aws kinesis create-stream --stream-name du-lieu-vong-co \
  --stream-mode-details StreamMode=ON_DEMAND

⚠ Chế độ On-Demand bỏ hẳn việc quản lý shard:

Provisioned: phải tính số shard, chia lại khi tải đổi
    → mỗi shard 1 MB/s hoặc 1.000 bản ghi/s
        ↓
    On-Demand: tự mở rộng tới 200 MB/s
    → hợp với startup chưa biết quy mô

Hai nhánh tiêu thụ song song:

Kinesis Data Streams
    ├── Managed Service for Apache Flink → dashboard thời gian thực
    └── Kinesis Data Firehose → S3 → COPY vào Redshift

⚠ Đây là lợi thế quyết định của Data Streams so với Firehose:

Firehose: một luồng, một đích
        ↓
Data Streams: nhiều consumer đọc CÙNG dữ liệu
    → mỗi consumer có tốc độ và mục đích riêng
    → và đọc lại được tới 365 ngày

Nạp vào Redshift từ S3:

COPY sinh_trac
FROM 's3://kho-du-lieu/vong-co/nam=2026/thang=08/'
IAM_ROLE 'arn:aws:iam::123456789012:role/VaiTroRedshift'
FORMAT AS PARQUET;

⚠ COPY từ S3 là cách nạp nhanh nhất vào Redshift — nhanh hơn INSERT hàng loạt lần.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thời gian thực và phân tích lịch sử tách bạch | | | S3 làm kho bền vững, rẻ | | | Redshift tối ưu cho truy vấn tổng hợp | |

⚠ Vì sao Redshift chứ không phải RDS cho báo cáo xu hướng:

Báo cáo sức khoẻ: tổng hợp hàng tỷ điểm dữ liệu
    → "nhịp tim trung bình theo tuần trong một năm"
        ↓
    Redshift lưu theo CỘT, nén tốt, quét song song
    → nhanh hơn CSDL hàng nhiều lần cho loại truy vấn này

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

• **A. SQS nhận dữ liệu rồi Kinesis phân tích, lưu RDS MySQL — SQS là hàng đợi tin nhắn: một tin chỉ một consumer đọc, không đọc lại được, không giữ thứ tự (hàng đợi chuẩn). Và RDS MySQL không hợp cho phân tích tổng hợp quy mô lớn.
• **B. S3 nhận trực tiếp rồi Data Pipeline phân tích mỗi ngày — chạy mỗi ngày là ngược thẳng với yêu cầu "thời gian thực"; và AWS Data Pipeline đã ngừng nhận khách hàng mới.
• **D. EMR nhận dữ liệu, Kinesis phân tích, lưu DynamoDB — EMR là cụm xử lý theo lô, không phải điểm nhận luồng; và thứ tự các bước bị đảo lộn.

Ghi nhớ

⚠ Bốn dịch vụ luồng — bảng phải thuộc: | Dịch vụ | Nhiều consumer | Đọc lại | Độ trễ | |---|---|---|---| | Kinesis Data Streams | ✅ | ✅ tới 365 ngày | ~200 ms | | Kinesis Data Firehose | ❌ | ❌ | tối thiểu 60 giây | | SQS | ❌ một tin một consumer | ❌ | thấp | | MSK (Kafka) | ✅ | ✅ | thấp |

⚠ SQS vs Kinesis — khác biệt cốt lõi:

SQS: tin nhắn được XOÁ sau khi xử lý
    → mỗi tin đúng một người nhận
        ↓
Kinesis: bản ghi NẰM LẠI trong luồng
    → nhiều consumer đọc cùng dữ liệu
    → đọc lại từ đầu được

Từ khoá nhận diện:

"real-time analytics + store for later analysis" → Kinesis Data Streams (nhiều consumer) "just deliver to S3/Redshift" → Firehose "decouple two services, one consumer" → SQS "data warehouse, complex aggregations" → Redshift

Ba lựa chọn phân tích luồng: | Công cụ | Chi tiết | |---|---| | Managed Service for Apache Flink | SQL hoặc Java, có trạng thái, cửa sổ | | Lambda | đơn giản, không trạng thái | | Kinesis Client Library trên EC2/ECS | kiểm soát đầy đủ |

⚠ Flink cần thiết khi phân tích có TRẠNG THÁI:

"Nhịp tim trung bình 10 phút gần nhất mỗi con vật"
    → cần cửa sổ thời gian và trạng thái theo khoá
        ↓
    Lambda không giữ trạng thái giữa các lần gọi
    → phải tự dựng bằng DynamoDB — phức tạp

Ba lưu ý về shard: | Lưu ý | Chi tiết | |---|---| | Mỗi shard: 1 MB/s ghi, 1.000 bản ghi/s | | | Đọc: 2 MB/s mỗi shard chia cho consumer | | | Enhanced fan-out: 2 MB/s RIÊNG mỗi consumer | |

⚠ Enhanced fan-out khi có nhiều consumer:

aws kinesis register-stream-consumer \
  --stream-arn <arn> --consumer-name dashboard

Không có: các consumer CHIA NHAU 2 MB/s
    → thêm consumer làm chậm consumer khác
        ↓
    Có: mỗi consumer 2 MB/s riêng, độ trễ ~70 ms

Ba lưu ý về partition key: | Lưu ý | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | | | Phải phân tán đều | | | Cùng khoá = cùng shard = giữ thứ tự | |

⚠ Dùng mã thiết bị làm partition key:

Hàng triệu vòng cổ → phân tán rất đều
    → và mọi bản ghi của một con vật
      vào cùng shard, giữ đúng thứ tự

Ba lưu ý về Firehose sang S3: | Lưu ý | Chi tiết | |---|---| | Gộp bản ghi nhỏ thành tệp lớn | | | Chuyển sang Parquet ngay trong luồng | | | Phân vùng theo ngày | |

Ba lưu ý về Redshift: | Lưu ý | Chi tiết | |---|---| | Chọn distribution key và sort key kỹ | | | Redshift Serverless nếu tải thất thường | | | Redshift Spectrum truy vấn thẳng S3 | |

⚠ Spectrum cho phép giữ dữ liệu lạnh ở S3:

Dữ liệu 90 ngày gần nhất → trong Redshift
Dữ liệu cũ hơn → ở S3, truy vấn qua Spectrum
        ↓
    Giảm mạnh chi phí mà vẫn truy vấn được

Ba lưu ý về giữ dữ liệu trong Kinesis: | Lưu ý | Chi tiết | |---|---| | Mặc định 24 giờ | | | Tăng tới 365 ngày | | | Giữ lâu tính phí thêm | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | GetRecords.IteratorAgeMilliseconds | consumer tụt hậu bao lâu | | WriteProvisionedThroughputExceeded | thiếu shard | | PutRecord.Success | |

⚠ IteratorAge tăng đều là dấu hiệu nguy hiểm:

Consumer xử lý chậm hơn tốc độ dữ liệu tới
    → khoảng cách nới rộng mãi
        ↓
    Chạm hạn giữ dữ liệu = MẤT dữ liệu
    → cảnh báo sớm và tăng số consumer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ thiết bị tới dashboard | | | Theo dõi IteratorAge | | | Chạy truy vấn xu hướng trên Redshift | |

Và một lời khuyên: hãy đặt cảnh báo cho IteratorAgeMilliseconds ngay khi dựng luồng. Kinesis không báo lỗi khi consumer tụt lại — nó chỉ lặng lẽ để khoảng cách nới rộng cho tới khi dữ liệu chạm hạn lưu trữ và biến mất, và lúc đó không có cách nào lấy lại.

Đáp án

A — Tạo HAI Patch Group với tag riêng gán cho các máy Windows; gắn baseline AWS-DefaultPatchBaseline cho cả hai; dựng hai maintenance window KHÔNG chồng lấn, mỗi cái gắn với một patch group; đăng ký target theo tag của patch group.

Vì sao đúng

Đề nêu hai yêu cầu, và chi tiết quyết định nằm ở yêu cầu thứ hai: | Yêu cầu | Cách đáp ứng | |---|---| | Vá tự động mọi máy Windows | Patch Manager với baseline | | Máy KHÔNG được khởi động lại CÙNG LÚC | hai patch group, hai cửa sổ TÁCH BIỆT |

⚠ Vá Windows gần như luôn đòi khởi động lại:

Bản vá Windows cần reboot để có hiệu lực
    → vá tất cả máy cùng lúc = tất cả reboot cùng lúc
        ↓
    Dịch vụ ngừng hoàn toàn
    → đúng thứ đề nói phải tránh

Gán tag cho hai nhóm:

aws ec2 create-tags --resources i-abc i-def \
  --tags 'Key=Patch Group,Value=dot-1'

aws ec2 create-tags --resources i-ghi i-jkl \
  --tags 'Key=Patch Group,Value=dot-2'

⚠ Tên tag là Patch Group — CÓ DẤU CÁCH và phân biệt hoa thường:

Viết `PatchGroup` (không dấu cách)
    → Patch Manager KHÔNG nhận ra
    → và không báo lỗi gì
        ↓
    Máy đơn giản là không được vá

Gắn baseline cho patch group:

aws ssm register-patch-baseline-for-patch-group \
  --baseline-id <id-baseline> --patch-group dot-1

aws ssm register-patch-baseline-for-patch-group \
  --baseline-id <id-baseline> --patch-group dot-2

Hai maintenance window không chồng lấn:

aws ssm create-maintenance-window --name cua-so-dot-1 \
  --schedule "cron(0 2 ? * SUN *)" \
  --schedule-timezone "Asia/Ho_Chi_Minh" \
  --duration 3 --cutoff 1 --allow-unassociated-targets

aws ssm create-maintenance-window --name cua-so-dot-2 \
  --schedule "cron(0 6 ? * SUN *)" \
  --schedule-timezone "Asia/Ho_Chi_Minh" \
  --duration 3 --cutoff 1 --allow-unassociated-targets

⚠ Cửa sổ thứ hai bắt đầu SAU khi cửa sổ thứ nhất kết thúc:

Cửa sổ 1: 2h-5h sáng (duration 3 giờ)
Cửa sổ 2: 6h-9h sáng
        ↓
    Có khoảng đệm một giờ
    → đợt 1 chắc chắn xong trước khi đợt 2 bắt đầu

Đăng ký target theo tag:

aws ssm register-target-with-maintenance-window \
  --window-id <id-cua-so-1> \
  --resource-type INSTANCE \
  --targets "Key=tag:Patch Group,Values=dot-1"

aws ssm register-task-with-maintenance-window \
  --window-id <id-cua-so-1> \
  --task-type RUN_COMMAND \
  --task-arn "AWS-RunPatchBaseline" \
  --targets "Key=WindowTargetIds,Values=<id-target>" \
  --max-concurrency "25%" --max-errors "10%" \
  --task-invocation-parameters '{"RunCommand":{
    "Parameters":{"Operation":["Install"],
                  "RebootOption":["RebootIfNeeded"]}}}'

⚠ --max-concurrency 25% là lớp bảo vệ THỨ HAI:

Ngay cả TRONG một patch group
    → chỉ 25% số máy vá cùng lúc
        ↓
    Kết hợp hai lớp:
    → hai nhóm tách thời gian
    → trong mỗi nhóm lại theo đợt nhỏ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không bao giờ mất toàn bộ đội máy | | | Có thời gian phát hiện bản vá gây lỗi | | | Tự động hoàn toàn, không cần người trực | |

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

• **C. Hai patch group nhưng dùng hai CloudWatch Events rule với cron — đây là phương án gần nhất và cũng tách được thời gian, nhưng nó bỏ qua Maintenance Window vốn được thiết kế đúng cho việc này: Maintenance Window có duration, cutoff, max-concurrency, max-errors và báo cáo tích hợp mà EventBridge rule không có.
• **B. MỘT patch group với CloudWatch Events cron — một nhóm nghĩa là mọi máy vá cùng lúc; vi phạm thẳng yêu cầu chính.
• **D. MỘT patch group với một maintenance window — cùng vấn đề: tất cả máy reboot trong cùng một cửa sổ.

Ghi nhớ

⚠ Bốn khái niệm của Patch Manager — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | Patch baseline | quy tắc bản vá nào được duyệt | | Patch group | nhóm máy dùng chung baseline (tag Patch Group) | | Maintenance window | khi nào và cách nào chạy việc vá | | Patch policy | áp baseline theo lịch cho nhiều tài khoản |

⚠ cutoff là tham số quan trọng của maintenance window:

duration 3, cutoff 1
    → cửa sổ kéo dài 3 giờ
    → nhưng KHÔNG bắt đầu việc mới
      trong 1 giờ cuối
        ↓
    Bảo đảm việc đang chạy có thời gian hoàn tất

Từ khoá nhận diện:

"patch without all instances rebooting at once" → nhiều patch group + cửa sổ tách biệt "apply OS patches automatically" → Patch Manager "install third-party software" → Run Command / Distributor "keep configuration applied" → State Manager

Ba tham số Operation: | Giá trị | Việc | |---|---| | Scan | chỉ kiểm tra, không cài | | Install | cài bản vá | | RebootOption | RebootIfNeeded hoặc NoReboot |

⚠ NoReboot cho phép tách việc vá và việc reboot:

Vá với NoReboot
    → bản vá cài xong nhưng chưa có hiệu lực
        ↓
    Reboot theo lịch riêng, theo đợt
    → kiểm soát chính xác hơn nữa

Ba lưu ý về baseline cho Windows: | Lưu ý | Chi tiết | |---|---| | Lọc theo MSRC_SEVERITY | | | ApproveAfterDays cho thời gian đệm | | | Danh sách duyệt và từ chối tường minh | |

aws ssm create-patch-baseline \
  --name baseline-windows --operating-system WINDOWS \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=MSRC_SEVERITY,Values=[Critical,Important]},
      {Key=CLASSIFICATION,Values=[SecurityUpdates,CriticalUpdates]}]},
    ApproveAfterDays=7,ComplianceLevel=CRITICAL}]'

⚠ ApproveAfterDays=7 là lớp bảo vệ khỏi bản vá hỏng:

Microsoft phát hành bản vá
    → chờ 7 ngày trước khi tự cài
        ↓
    Nếu bản vá có vấn đề, cộng đồng sẽ biết
      trong khoảng đó
        ↓
    Đổi lại: chậm hơn với lỗ hổng khẩn cấp
    → dùng ApproveAfterDays=0 cho baseline riêng
      cho lỗ hổng nghiêm trọng

Ba lưu ý về máy sau load balancer: | Lưu ý | Chi tiết | |---|---| | Rút máy khỏi target group trước khi reboot | | | Lifecycle hook của ASG xử lý được | | | Hoặc dùng Automation runbook nhiều bước | |

⚠ SSM Automation cho quy trình vá đầy đủ:

1. Rút máy khỏi target group
2. Chờ kết nối hiện có kết thúc
3. Cài bản vá
4. Reboot
5. Chờ health check xanh
6. Đưa lại vào target group
        ↓
    Runbook `AWS-PatchInstanceWithRollback` có sẵn

Ba điều kiện tiên quyết: | Điều kiện | Chi tiết | |---|---| | SSM Agent đang chạy | | | Instance profile có AmazonSSMManagedInstanceCore | | | Tới được endpoint SSM | NAT hoặc VPC endpoint |

Ba lưu ý về báo cáo tuân thủ: | Việc | Cách | |---|---| | list-compliance-summaries | | | Đưa vào Security Hub | | | Config rule kiểm tra | |

aws ssm describe-instance-patch-states-for-patch-group \
  --patch-group dot-1 \
  --query "InstancePatchStates[].[InstanceId,
    InstalledCount,MissingCount,OperationEndTime]" --output table

Ba lưu ý về múi giờ: | Lưu ý | Chi tiết | |---|---| | --schedule-timezone để tránh nhầm UTC | | | Chọn giờ ít lưu lượng nhất | | | Tính tới nhiều múi giờ nếu toàn cầu | |

Ba lưu ý về hạ tầng bất biến (lựa chọn khác): | Cách | Chi tiết | |---|---| | Tạo AMI đã vá bằng Image Builder | | | Thay máy thay vì vá tại chỗ | | | Instance refresh của ASG | |

⚠ Với đội máy lớn, thay AMI thường tốt hơn vá tại chỗ:

Vá tại chỗ: máy dần khác nhau, khó biết trạng thái thật
        ↓
    Thay AMI: mọi máy giống hệt nhau
    → và quay lui bằng cách dùng AMI cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem lịch sử maintenance window | | | Kiểm tra hai nhóm chạy khác giờ | | | Chạy Scan sau khi vá | phải sạch |

Và một lời khuyên: hãy kiểm tra tag Patch Group được viết đúng với dấu cách. Đây là một trong số ít chỗ mà AWS dùng tên tag có khoảng trắng, và viết liền sẽ khiến máy không bao giờ được vá — không có lỗi, không có cảnh báo, chỉ là một nhóm máy lặng lẽ nằm ngoài mọi chu kỳ bảo mật.

Đáp án

C — Tắt chia sẻ Reserved Instance trên tài khoản quản trị (master) cho các tài khoản thành viên của đơn vị Baby products.

Vì sao đúng

Đề nêu một yêu cầu cụ thể: RI mua cho đơn vị Baby products không được chia sẻ với các đơn vị khác.

⚠ Chia sẻ RI được BẬT MẶC ĐỊNH trong AWS Organizations:

Consolidated billing tự động chia sẻ
RI và Savings Plans giữa mọi tài khoản
        ↓
    Nếu Baby products chưa dùng hết 10 RI
    → các đơn vị khác hưởng phần dư
        ↓
    Đó chính là điều họ muốn ngăn

⚠ Và cấu hình đó nằm ở MANAGEMENT ACCOUNT:

Tài khoản thành viên KHÔNG tự tắt được
    → chỉ management account (payer) mới điều chỉnh
        ↓
    Trong Billing preferences → Reserved Instances
    → bật/tắt cho từng tài khoản

Xem trạng thái hiện tại:

aws ce get-preferences

Điều chỉnh:

aws ce update-preferences \
  --reservation-sharing '{"Enabled": false}'

⚠ Tắt chia sẻ có tác động HAI CHIỀU:

Tắt cho tài khoản Baby products:
    → RI của họ KHÔNG chia cho ai
    → và họ cũng KHÔNG hưởng RI của đơn vị khác
        ↓
    Đây là đánh đổi phải nói rõ với các bên

Bối cảnh quan trọng — RI mua trước 3 tháng:

Ứng dụng Supply Chain còn 3 tháng nữa mới chạy
    → trong 3 tháng đó RI không được dùng
        ↓
    Nếu bật chia sẻ: đơn vị khác hưởng miễn phí
    → tắt chia sẻ: RI nằm không, nhưng
      không ai "lấy mất" phần đã trả tiền

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chi phí quy đúng về đơn vị đã trả tiền | | | Điều chỉnh được cho từng tài khoản | | | Bật lại bất cứ lúc nào | |

⚠ Nhưng cân nhắc kỹ trước khi tắt:

Tắt chia sẻ = RI không dùng hết thì LÃNG PHÍ THẬT
    → 3 tháng đầu RI nằm không hoàn toàn
        ↓
    Nếu mục tiêu chỉ là quy đúng chi phí
    → cân nhắc dùng cost allocation tag
      và báo cáo nội bộ thay vì tắt chia sẻ

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

• **B. Đặt chia sẻ RI thành "private" trên tài khoản Baby products — đây là phương án gần nhất về mặt ý tưởng, nhưng "private" không phải một cài đặt tồn tại, và tài khoản thành viên không có quyền thay đổi cấu hình chia sẻ.
• **A. Cho rằng RI luôn được chia sẻ và không tắt được — sai: chia sẻ RI tắt được cho từng tài khoản trong Billing preferences của management account.
• **D. Đưa tài khoản Baby products ra khỏi tổ chức — giải quyết được nhưng mất mọi lợi ích khác của Organizations: hoá đơn hợp nhất, giá bậc thang, SCP, quản trị tập trung.

Ghi nhớ

⚠ Ba đặc điểm của consolidated billing — bảng phải thuộc: | Đặc điểm | Chi tiết | |---|---| | Gộp mức dùng để tính bậc giá | S3, truyền dữ liệu rẻ hơn | | RI và Savings Plans DÙNG CHUNG mặc định | tắt được cho từng tài khoản | | Free tier tính cho CẢ TỔ CHỨC | không nhân theo số tài khoản |

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

10 tài khoản trong tổ chức
    → KHÔNG phải 10 suất free tier
    → chỉ MỘT suất cho tất cả

Từ khoá nhận diện:

"prevent RI discounts from being shared" → tắt RI sharing ở management account "share RI across accounts" → bật RI sharing (mặc định) "share subnets, Transit Gateway" → AWS RAM "attribute costs to teams" → cost allocation tags

⚠ RAM KHÔNG chia sẻ được Reserved Instance:

RAM chia sẻ: subnet, Transit Gateway,
             License Manager config,
             Route 53 Resolver rule
        ↓
    RI được chia sẻ qua CONSOLIDATED BILLING,
      không qua RAM

Ba mô hình giảm giá cam kết: | Mô hình | Linh hoạt | Giảm tối đa | |---|---|---| | Standard RI | thấp nhất | ~72% | | Convertible RI | đổi được loại | ~66% | | Compute Savings Plans | cao nhất | ~66% | | EC2 Instance Savings Plans | một họ, một vùng | ~72% |

⚠ Savings Plans thường tốt hơn RI ngày nay:

Compute Savings Plans áp cho EC2 mọi loại,
mọi vùng, cả Fargate và Lambda
        ↓
    Cam kết theo SỐ TIỀN mỗi giờ
    → không bao giờ "mua sai loại máy"

Ba cách quy chi phí về đúng đơn vị: | Cách | Chi tiết | |---|---| | Cost allocation tags | gắn tag cho tài nguyên | | Cost Categories | nhóm tài khoản và tag thành danh mục | | Tài khoản riêng cho mỗi đơn vị | rõ ràng nhất |

⚠ Tag phải được KÍCH HOẠT trong Billing console:

Gắn tag đầy đủ nhưng quên kích hoạt
    → Cost Explorer không nhóm theo tag đó
    → và KHÔNG hồi tố dữ liệu cũ

Ba lưu ý về theo dõi hiệu quả RI: | Báo cáo | Việc | |---|---| | RI utilization | RI dùng hết bao nhiêu % | | RI coverage | bao nhiêu máy được RI che | | Savings Plans utilization | tương tự |

aws ce get-reservation-utilization \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --granularity MONTHLY

⚠ Utilization dưới 100% nghĩa là đang mất tiền:

RI utilization 40% trong 3 tháng chờ
    → 60% số giờ đã trả tiền mà không dùng
        ↓
    Cân nhắc: mua RI SAU khi ứng dụng chạy
    → hoặc mua Savings Plans linh hoạt hơn

Ba lưu ý về thời điểm mua RI: | Lưu ý | Chi tiết | |---|---| | Mua quá sớm = lãng phí phần chưa dùng | | | Mua sau khi tải ổn định thì chính xác hơn | | | Savings Plans linh hoạt hơn cho tải đang thay đổi | |

Ba lưu ý về RI Marketplace: | Lưu ý | Chi tiết | |---|---| | Chỉ bán được Standard RI trả trước | | | Convertible RI KHÔNG bán được | | | Cần tài khoản ngân hàng ở Mỹ | |

Ba lưu ý về Savings Plans: | Lưu ý | Chi tiết | |---|---| | KHÔNG bán lại được | | | KHÔNG huỷ được | | | Cân nhắc kỹ hơn RI vì không có đường lùi | |

Ba lưu ý về đặt trước năng lực: | Lưu ý | Chi tiết | |---|---| | Zonal RI ĐẶT TRƯỚC năng lực | | | Regional RI và Savings Plans KHÔNG | | | On-Demand Capacity Reservation nếu cần đảm bảo | |

⚠ Đây là điều hay bị hiểu nhầm:

"Mua RI để chắc chắn có máy"
    → Regional RI KHÔNG giữ chỗ
    → AZ hết năng lực vẫn không khởi động được
        ↓
    Cần đảm bảo → Zonal RI hoặc Capacity Reservation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem RI utilization sau khi tắt chia sẻ | | | Kiểm tra hoá đơn các đơn vị khác | | | Xác nhận cài đặt trong Billing preferences | |

Và một lời khuyên: hãy cân nhắc dùng cost allocation tag để quy chi phí thay vì tắt chia sẻ RI. Tắt chia sẻ đảm bảo không ai "hưởng ké", nhưng nó cũng bảo đảm rằng mọi giờ RI không dùng tới đều bị lãng phí thật — và trong ba tháng chờ ứng dụng khởi chạy thì đó là toàn bộ khoản đã trả.