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

Đáp án

D — Tạo một quy tắc Amazon EventBridge cho lời gọi API CreateImage, đặt đích là một SNS topic để gửi cảnh báo.

Vì sao đúng

Đề nêu hai yêu cầu, và EventBridge đáp ứng cả hai với ít bộ phận nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Bắt lời gọi API CreateImage | EventBridge nhận sự kiện CloudTrail thời gian thực | | CÔNG VẬN HÀNH ÍT NHẤT | một quy tắc, một đích, không có mã |

⚠ EventBridge nhận sự kiện API từ CloudTrail gần như tức thì:

Ai đó gọi CreateImage
    → CloudTrail phát sự kiện
    → EventBridge khớp mẫu
        ↓
    SNS gửi thư — thường trong vài giây

Quy tắc:

{"source": ["aws.ec2"],
 "detail-type": ["AWS API Call via CloudTrail"],
 "detail": {
   "eventSource": ["ec2.amazonaws.com"],
   "eventName": ["CreateImage"]}}

aws events put-rule --name canh-bao-tao-ami \
  --event-pattern file://mau-su-kien.json \
  --description "Canh bao khi co ai goi CreateImage"

aws events put-targets --rule canh-bao-tao-ami \
  --targets 'Id=1,Arn=<arn-sns-topic>'

⚠ Cho phép EventBridge publish vào topic — bước hay bị quên:

{"Effect": "Allow",
 "Principal": {"Service": "events.amazonaws.com"},
 "Action": "sns:Publish",
 "Resource": "<arn-topic>"}

Làm thư dễ đọc bằng input transformer:

{"InputPathsMap": {
   "nguoi": "$.detail.userIdentity.arn",
   "thoiDiem": "$.detail.eventTime",
   "may": "$.detail.requestParameters.instanceId"},
 "InputTemplate":
   "\"Canh bao: <nguoi> da tao AMI tu may <may> luc <thoiDiem>\""}

⚠ Không có transformer thì thư là một khối JSON thô — đọc được nhưng khó dùng.

Điều kiện tiên quyết: CloudTrail phải đang ghi:

aws cloudtrail create-trail --name duong-mon-chinh \
  --s3-bucket-name log-cloudtrail --is-multi-region-trail
aws cloudtrail start-logging --name duong-mon-chinh

⚠ EventBridge cần một trail đang hoạt động — không có trail thì sự kiện API không được phát ra.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không viết dòng mã nào | | | Gần thời gian thực | | | Thêm đích khác dễ dàng | Lambda, SQS, Step Functions |

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

• **C. Viết Lambda truy vấn log CloudTrail và gửi cảnh báo — đây là phương án gần nhất và cho ra kết quả tương tự, nhưng phải viết mã, phải lên lịch chạy, và có độ trễ theo chu kỳ chạy. EventBridge làm sẵn phần đó.
• **B. CloudTrail gửi thông báo SNS khi có log mới, rồi dùng Athena truy vấn — thông báo chỉ báo "có tệp log mới", không nói gì về CreateImage; phải thêm cả bước truy vấn thủ công.
• **A. Đặt SQS FIFO làm đích của CloudTrail — CloudTrail không gửi trực tiếp vào SQS; nó ghi ra S3 (và tuỳ chọn CloudWatch Logs). Phương án mô tả một tích hợp không tồn tại.

Ghi nhớ

⚠ Bốn cách phản ứng với sự kiện API — bảng phải thuộc: | Cách | Độ trễ | Công dựng | |---|---|---| | EventBridge rule | giây | thấp nhất | | CloudWatch Logs metric filter + alarm | phút | trung bình | | Lambda quét log định kỳ | theo chu kỳ | cao | | Athena truy vấn thủ công | thủ công | cao |

Từ khoá nhận diện:

"alert when a specific API is called, least overhead" → EventBridge "count occurrences over time, threshold" → metric filter + alarm "investigate past activity" → Athena / CloudTrail Lake "prevent the action entirely" → SCP hoặc IAM policy

⚠ Nếu mục tiêu là NGĂN chứ không phải BIẾT:

{"Effect": "Deny",
 "Action": "ec2:CreateImage",
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/QuanTriAnh"}}}

Cảnh báo cho bạn biết SAU KHI việc đã xảy ra
    → SCP ngăn nó xảy ra
        ↓
    Với AMI vàng dùng chung, ngăn thường đúng hơn

Ba loại sự kiện EventBridge bắt được: | Loại | Ví dụ | |---|---| | Sự kiện dịch vụ AWS | trạng thái EC2 đổi, job Batch xong | | Lời gọi API qua CloudTrail | CreateImage, DeleteBucket | | Sự kiện tuỳ chỉnh | ứng dụng tự phát |

⚠ Không phải mọi API đều là "management event":

Data event (s3:GetObject, lambda:Invoke)
    → phải BẬT riêng trong trail
        ↓
    EventBridge chỉ thấy chúng khi trail đã bật

Ba đích hay dùng của EventBridge: | Đích | Việc | |---|---| | SNS | thông báo cho người | | Lambda | xử lý hoặc khắc phục | | Step Functions | quy trình nhiều bước | | SQS | đệm cho hệ thống hạ nguồn |

Ba lưu ý về mẫu sự kiện: | Lưu ý | Chi tiết | |---|---| | Lọc theo nhiều trường cùng lúc | | | Có toán tử anything-but, prefix, numeric | | | Thử bằng test-event-pattern | |

aws events test-event-pattern \
  --event-pattern file://mau-su-kien.json \
  --event file://su-kien-mau.json

⚠ Lọc theo tài khoản hoặc vai trò cụ thể:

{"detail": {
  "eventName": ["CreateImage"],
  "userIdentity": {"arn": [{"anything-but":
    {"prefix": "arn:aws:sts::123456789012:assumed-role/CIPipeline"}}]}}}

Chỉ cảnh báo khi KHÔNG phải đường ống CI tạo
    → giảm nhiễu rất nhiều

Ba lưu ý về SNS: | Lưu ý | Chi tiết | |---|---| | Người nhận phải xác nhận đăng ký | | | Hỗ trợ email, SMS, HTTP, Lambda, SQS | | | Bật mã hoã bằng KMS cho topic | |

Ba lưu ý về nhiễu cảnh báo: | Lưu ý | Chi tiết | |---|---| | Cảnh báo quá nhiều = không ai đọc | | | Lọc bỏ hoạt động tự động hợp lệ | | | Rà lại mẫu sự kiện định kỳ | |

Ba lưu ý về chia sẻ AMI (bối cảnh của đề): | Lưu ý | Chi tiết | |---|---| | Chia sẻ theo account ID hoặc ID tổ chức | | | Snapshot mã hoá cần chia sẻ cả khoá KMS | | | Có thể đặt AMI public — nên chặn | |

⚠ Chặn chia sẻ AMI ra công khai ở cấp tài khoản:

aws ec2 disable-image-block-public-access
# Thực tế nên BẬT chặn:
aws ec2 enable-image-block-public-access \
  --image-block-public-access-state block-new-sharing

AMI vàng chứa cấu hình nội bộ
    → chia sẻ nhầm ra public là rò rỉ nghiêm trọng

Ba lưu ý về EventBridge nâng cao: | Tính năng | Việc | |---|---| | Archive và replay | phát lại sự kiện cũ | | Schema registry | biết cấu trúc sự kiện | | Event bus riêng | tách theo miền nghiệp vụ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo một AMI thử | | | Xác nhận nhận được thư | | | Kiểm tra metric Invocations của rule | |

aws ec2 create-image --instance-id i-abc --name "thu-canh-bao"

Và một lời khuyên: hãy lọc bỏ vai trò của đường ống CI ra khỏi mẫu sự kiện. Cảnh báo có giá trị đúng bằng tỷ lệ nó báo đúng thứ đáng chú ý, và một quy tắc gửi thư mỗi lần đường ống tự động dựng AMI sẽ được lọc vào thư mục rác trong đúng một tuần.

Đáp án

C — Dùng AWS DMS di chuyển thẳng CSDL sang một Amazon RDS MySQL Multi-AZ.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Giải pháp ĐƯỢC QUẢN LÝ | RDS — AWS lo vá, sao lưu, giám sát | | Sẵn sàng cao, tự chuyển đổi khi AZ hỏng | Multi-AZ | | Di chuyển từ MySQL tại chỗ | DMS, cùng engine nên đơn giản |

⚠ Cùng engine nghĩa là di chuyển "đồng nhất" — không cần SCT:

MySQL → MySQL: cấu trúc dữ liệu giống nhau
    → DMS chép thẳng
        ↓
    Oracle → PostgreSQL: khác cú pháp, khác kiểu dữ liệu
    → mới cần Schema Conversion Tool

Đây chính là lý do phương án A sai.

Dựng RDS Multi-AZ:

aws rds create-db-instance \
  --db-instance-identifier csdl-khach-hang \
  --engine mysql --engine-version 8.0.36 \
  --db-instance-class db.r6g.xlarge \
  --allocated-storage 500 --storage-type gp3 \
  --multi-az --storage-encrypted \
  --backup-retention-period 30 \
  --manage-master-user-password

Di chuyển bằng DMS ít gián đoạn:

aws dms create-replication-task \
  --replication-task-identifier chuyen-mysql \
  --source-endpoint-arn <arn-mysql-tai-cho> \
  --target-endpoint-arn <arn-rds> \
  --replication-instance-arn <arn-may-nhan-ban> \
  --migration-type full-load-and-cdc \
  --table-mappings file://anh-xa.json

⚠ full-load-and-cdc là chìa khoá giảm thời gian ngừng:

1. Full load: chép toàn bộ dữ liệu (chạy nhiều giờ cũng được,
              ứng dụng vẫn chạy bình thường)
2. CDC:       theo dõi và áp thay đổi liên tục
        ↓
    Khi độ trễ về gần 0 → dừng ghi ở nguồn
    → chuyển ứng dụng sang RDS
        ↓
    Thời gian ngừng: vài phút

Chuẩn bị nguồn MySQL cho CDC:

# my.cnf
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
expire_logs_days = 7

⚠ binlog_format = ROW là bắt buộc cho CDC — định dạng STATEMENT không đủ thông tin để DMS tái tạo thay đổi.

Cách RDS Multi-AZ hoạt động:

Ghi vào primary
    → nhân bản ĐỒNG BỘ sang standby ở AZ khác
        ↓
    AZ chính hỏng → RDS tự chuyển
    → endpoint DNS trỏ sang standby
    → ứng dụng không đổi chuỗi kết nối

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không quản lý máy chủ nào | | | Failover tự động, thường 60-120 giây | | | Sao lưu tự động, khôi phục điểm thời gian | |

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

• **A. DMS sang RDS MySQL nhưng dùng Schema Conversion Tool — đây là phương án gần nhất và dùng đúng công cụ chính, nhưng SCT chỉ cần khi đổi engine (Oracle → PostgreSQL chẳng hạn). MySQL sang MySQL không cần chuyển đổi lược đồ, và phương án cũng không nói tới Multi-AZ.
• **B. DMS sang MySQL Multi-AZ trên EC2 — "Multi-AZ" không phải tính năng bạn bật trên EC2; bạn phải tự dựng nhân bản và tự dựng cơ chế failover. Và vi phạm yêu cầu "managed solution".
• **D. Chụp snapshot máy chủ MySQL, dùng DataSync đưa lên S3, rồi khôi phục RDS từ snapshot đó — RDS không khôi phục được từ snapshot của máy ảo; nó chỉ khôi phục từ snapshot RDS hoặc từ tệp backup theo quy trình riêng.

Ghi nhớ

⚠ DMS và SCT — khi nào cần cái nào: | Tình huống | Công cụ | |---|---| | MySQL → RDS MySQL | chỉ DMS | | Oracle → Aurora PostgreSQL | DMS + SCT | | SQL Server → RDS SQL Server | chỉ DMS | | PostgreSQL → Aurora PostgreSQL | chỉ DMS |

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

Từ khoá nhận diện:

"migrate database, same engine" → DMS "migrate database, different engine" → DMS + SCT "managed MySQL with automatic failover" → RDS Multi-AZ "lift and shift whole servers" → Application Migration Service (MGN)

⚠ Ba kiểu Multi-AZ của RDS/Aurora: | Kiểu | Standby đọc được | AZ | |---|---|---| | RDS Multi-AZ DB instance | ❌ | 2 | | RDS Multi-AZ DB cluster | ✅ hai replica | 3 | | Aurora | ✅ mọi replica | 3 |

Multi-AZ DB cluster (ra mắt 2022) failover
nhanh hơn — thường dưới 35 giây
    → và hai standby ĐỌC ĐƯỢC
        ↓
    Đáng cân nhắc thay cho DB instance

Ba lưu ý về failover của RDS: | Lưu ý | Chi tiết | |---|---| | Endpoint không đổi — DNS trỏ sang standby | | | Ứng dụng phải biết thử lại | | | Kết nối đang mở bị ngắt | |

⚠ RDS Proxy rút ngắn gián đoạn:

aws rds create-db-proxy --db-proxy-name proxy-csdl \
  --engine-family MYSQL --role-arn <arn-role> \
  --auth '[{"AuthScheme":"SECRETS","SecretArn":"<arn-secret>"}]' \
  --vpc-subnet-ids subnet-a subnet-b --require-tls

Proxy giữ kết nối, tự trỏ sang writer mới
    → giảm thời gian gián đoạn tới ~66%

Ba thứ DMS KHÔNG chép: | Thứ | Phải tự làm | |---|---| | Index phụ | tạo sau khi full load xong | | Khoá ngoại, trigger | | | Stored procedure, view | |

⚠ Tạo index SAU khi full load là mẹo tăng tốc lớn:

Có index sẵn: mỗi dòng chèn phải cập nhật index
    → full load chậm nhiều lần
        ↓
    Chép dữ liệu trước, tạo index sau

Ba lưu ý về giám sát DMS: | Metric | Ý nghĩa | |---|---| | CDCLatencySource | đọc từ nguồn chậm bao lâu | | CDCLatencyTarget | ghi vào đích chậm bao lâu | | FullLoadThroughputRowsTarget | tốc độ chép |

Ba lưu ý về validation: | Lưu ý | Chi tiết | |---|---| | Bật EnableValidation trong task settings | | | DMS tự so từng dòng | | | Báo cáo dòng nào lệch | |

Ba lưu ý về kích thước replication instance: | Lưu ý | Chi tiết | |---|---| | Quá nhỏ = nút thắt cổ chai | | | CDC cần bộ nhớ để giữ giao dịch đang mở | | | Bật Multi-AZ cho task chạy dài | |

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | DMS phải tới được CSDL nguồn | VPN hoặc Direct Connect | | Bật SSL cho endpoint | | | Security group cho phép cổng 3306 | |

Ba lưu ý về chuyển đổi cuối cùng: | Bước | Chi tiết | |---|---| | Dừng ghi ở nguồn | | | Chờ CDCLatencyTarget về 0 | | | Đổi chuỗi kết nối, kiểm tra, mở lại ghi | |

⚠ Dùng Route 53 CNAME cho endpoint CSDL:

Ứng dụng kết nối tới csdl.noi-bo.vidu.com
    → CNAME trỏ tới endpoint RDS
        ↓
    Chuyển đổi = đổi một bản ghi DNS
    → không phải triển khai lại ứng dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So số dòng vài bảng lớn | | | Chạy --force-failover thử | | | Kiểm tra ứng dụng phục hồi sau failover | |

aws rds reboot-db-instance --db-instance-identifier csdl-khach-hang \
  --force-failover

Và một lời khuyên: hãy trỏ ứng dụng vào một bản ghi CNAME thay vì endpoint RDS trực tiếp. Bạn sẽ cần đổi endpoint nhiều lần hơn tưởng — lúc chuyển đổi, lúc nâng cấp, lúc khôi phục — và mỗi lần đổi bằng DNS là một lần không phải triển khai lại ứng dụng.

Đáp án

A — Tạo gateway VPC endpoint cho Amazon S3 và DynamoDB.

Vì sao đúng

Đề nêu một yêu cầu duy nhất và rất rõ: lưu lượng giữa EC2 và các dịch vụ AWS không được đi qua Internet công cộng.

⚠ Điểm quyết định: S3 và DynamoDB là HAI dịch vụ duy nhất dùng Gateway endpoint:

Gateway endpoint: CHỈ S3 và DynamoDB
Interface endpoint (PrivateLink): mọi dịch vụ còn lại

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

Tạo endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-rieng-tu-a rtb-rieng-tu-b

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.dynamodb \
  --route-table-ids rtb-rieng-tu-a rtb-rieng-tu-b

⚠ Gateway endpoint hoạt động bằng cách thêm TUYẾN, không phải thêm ENI:

AWS thêm một tuyến vào route table:
    đích = prefix list của S3 (pl-xxxxxx)
    next hop = vpce-abc
        ↓
    Gói tin tới S3 đi theo tuyến đó
    → không ra internet gateway

Kiểm tra tuyến đã được thêm:

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu-a \
  --query "RouteTables[0].Routes[?GatewayId!=null]"

⚠ Phải khai ĐÚNG route table — endpoint chỉ có tác dụng cho subnet dùng route table đã gắn:

Tạo endpoint nhưng quên một route table
    → subnet dùng route table đó vẫn đi qua NAT
        ↓
    Không có lỗi nào — chỉ là vẫn tốn tiền
      và vẫn đi qua Internet

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

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": "*",
   "Action": ["s3:GetObject", "s3:PutObject"],
   "Resource": ["arn:aws:s3:::kho-anh-ung-dung/*"]}]}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | MIỄN PHÍ hoàn toàn | không phí giờ, không phí dữ liệu | | Lưu lượng không rời mạng AWS | | | Không cần NAT gateway cho hai dịch vụ này | |

⚠ Khoản tiết kiệm rất lớn nếu trước đó đi qua NAT:

Ứng dụng tải 10 TB từ S3 mỗi tháng qua NAT gateway
    → 10.000 GB × 0,045 USD = 450 USD
        ↓
    Gateway endpoint: 0 USD

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

• **B. Tạo interface VPC endpoint cho S3 và DynamoDB — đây là phương án gần nhất và với S3 thì thật sự tồn tại (interface endpoint cho S3 có từ 2021, dùng khi cần truy cập từ tại chỗ), nhưng DynamoDB KHÔNG có interface endpoint; và interface endpoint tính phí trong khi gateway endpoint miễn phí.
• **C. Tạo NAT gateway trong subnet công khai — NAT gateway cho phép ra Internet, tức là lưu lượng VẪN đi qua Internet công cộng, vi phạm thẳng yêu cầu.
• **D. Tạo virtual private gateway và cấu hình route table — VGW là đầu AWS của kết nối VPN tới trung tâm dữ liệu tại chỗ, hoàn toàn không liên quan tới truy cập dịch vụ AWS.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ | Cơ chế | Phí | |---|---|---|---| | Gateway | CHỈ S3 và DynamoDB | tuyến trong route table | MIỄN PHÍ | | Interface | hầu hết dịch vụ AWS | ENI có IP riêng tư | ~0,01 USD/giờ/AZ + dữ liệu |

Từ khoá nhận diện:

"S3 or DynamoDB privately, no internet" → Gateway endpoint "other AWS services privately" → Interface endpoint "access S3 from on-premises privately" → Interface endpoint cho S3 "expose your own service to other VPCs" → PrivateLink service

⚠ Ba khác biệt vận hành đáng nhớ: | Khía cạnh | Gateway | Interface | |---|---|---| | Security group | không gắn được | gắn được | | Truy cập từ tại chỗ | KHÔNG | CÓ | | DNS | dùng prefix list | private DNS ghi đè tên công khai |

Máy tại chỗ qua Direct Connect muốn vào S3 riêng tư
    → Gateway endpoint KHÔNG dùng được
        ↓
    Phải dùng Interface endpoint cho S3

Ba interface endpoint thường cần nhất: | Dịch vụ | Khi nào | |---|---| | ssm, ssmmessages, ec2messages | Systems Manager, Session Manager | | ecr.api, ecr.dkr | kéo image container | | secretsmanager, kms | lấy bí mật, giải mã |

⚠ Dùng SSM qua endpoint thì không cần NAT gateway chút nào:

Máy trong subnet riêng tư cần:
    → vá bằng Patch Manager
    → shell bằng Session Manager
        ↓
    Ba endpoint SSM là đủ
    → bỏ được NAT gateway

Ba lưu ý về prefix list: | Lưu ý | Chi tiết | |---|---| | Gateway endpoint dùng managed prefix list của AWS | | | Dùng được trong security group | | | Tự cập nhật khi AWS đổi dải IP | |

aws ec2 describe-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.ap-southeast-1.s3

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

⚠ Bucket policy có thể yêu cầu đi qua endpoint:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-anh-ung-dung",
              "arn:aws:s3:::kho-anh-ung-dung/*"],
 "Condition": {"StringNotEquals":
   {"aws:SourceVpce": "vpce-abc123"}}}

Bucket CHỈ truy cập được qua endpoint này
    → kể cả có credential đúng, từ Internet cũng bị từ chối

Ba lưu ý về hạn ngạch: | Hạn ngạch | Mặc định | |---|---| | Gateway endpoint mỗi VPC | 20 | | Interface endpoint mỗi VPC | 50 | | Tuyến mỗi route table | 50 (tăng được) |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | VPC Flow Logs ghi lưu lượng qua endpoint | | | Interface endpoint có metric CloudWatch | | | Gateway endpoint không có metric riêng | |

Ba lưu ý về chi phí interface endpoint: | Khoản | Chi tiết | |---|---| | Tính theo giờ mỗi AZ | | | Nhiều AZ = nhân lên | | | Vẫn thường rẻ hơn NAT ở lưu lượng lớn | |

Ba lưu ý về gỡ lỗi: | Triệu chứng | Nguyên nhân hay gặp | |---|---| | Vẫn đi qua NAT | quên gắn route table | | Access denied | endpoint policy quá chặt | | Interface endpoint không phân giải | quên --private-dns-enabled |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra tuyến trong route table | | | traceroute tới S3 từ máy riêng tư | | | Xem hoá đơn NAT có giảm không | |

dig +short s3.ap-southeast-1.amazonaws.com
# Với gateway endpoint, tên vẫn phân giải ra IP công khai
# nhưng ĐỊNH TUYẾN đi qua endpoint — kiểm tra bằng route table

Và một lời khuyên: hãy tạo Gateway endpoint cho S3 và DynamoDB ở mọi VPC, kể cả khi chưa có yêu cầu bảo mật nào. Chúng miễn phí, mất một lệnh, và ở phần lớn kiến trúc thì lưu lượng S3 chính là phần lớn nhất của hoá đơn xử lý dữ liệu NAT gateway.

Đáp án

A — Lưu tệp trên Amazon S3 với lifecycle policy chuyển object cũ hơn 2 năm sang S3 Standard-Infrequent Access.

Vì sao đúng

Đề nêu bốn yêu cầu, và S3 đáp ứng cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Mở rộng tới BẤT KỲ số lượng tệp nào | S3 không có giới hạn số object | | Sẵn sàng cao | 99,99% SLA, dữ liệu trải nhiều AZ | | Độ bền cao | 99,999999999% (11 số 9) | | Tệp cũ hơn 2 năm ít truy cập hơn | lifecycle sang Standard-IA |

⚠ "Any number of files" là từ khoá loại ngay EBS và EFS khỏi cuộc chơi:

EBS: dung lượng cố định, phải cấp trước, tối đa 64 TiB
EFS: tự mở rộng nhưng vẫn là hệ thống tệp
        ↓
S3:  không có khái niệm dung lượng
     → object đầu tiên và object thứ mười tỷ như nhau

Lifecycle policy:

aws s3api put-bucket-lifecycle-configuration \
  --bucket kho-tep-nguoi-dung \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "chuyen-sang-ia-sau-2-nam",
      "Filter": {"Prefix": ""},
      "Status": "Enabled",
      "Transitions": [{
        "Days": 730,
        "StorageClass": "STANDARD_IA"}],
      "NoncurrentVersionTransitions": [{
        "NoncurrentDays": 30,
        "StorageClass": "STANDARD_IA"}],
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7}}]}'

⚠ AbortIncompleteMultipartUpload là quy tắc ai cũng nên có:

Tải lên nhiều phần bị hỏng giữa chừng
    → các phần đã tải NẰM LẠI và TÍNH TIỀN
    → không hiện trong `ls`
        ↓
    Không có quy tắc dọn = trả tiền cho dữ liệu
      không ai thấy, tích tụ hàng năm

So sánh chi phí: | Lớp | Giá tham khảo/GB-tháng | Phí lấy dữ liệu | |---|---|---| | S3 Standard | ~0,023 USD | không | | S3 Standard-IA | ~0,0125 USD (giảm ~46%) | ~0,01 USD/GB |

⚠ Standard-IA chỉ rẻ hơn nếu THẬT SỰ ít đọc:

Object 1 GB ở IA, đọc 3 lần mỗi tháng
    → 0,0125 (lưu) + 0,03 (lấy) = 0,0425 USD
        ↓
    Ở Standard chỉ 0,023 USD
    → IA ĐẮT GẤP ĐÔI

Ba lưu ý bắt buộc về Standard-IA: | Lưu ý | Chi tiết | |---|---| | Lưu tối thiểu 30 ngày | xoá sớm vẫn tính đủ | | Kích thước tính phí tối thiểu 128 KB | | | Có phí lấy dữ liệu theo GB | |

⚠ Ngưỡng 128 KB rất quan trọng với tệp nhỏ:

Tệp 10 KB ở Standard-IA
    → tính tiền như 128 KB
    → ĐẮT HƠN để ở Standard
        ↓
    Lọc lifecycle theo kích thước:

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

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải nghĩ về dung lượng | | | Tệp cũ vẫn truy cập ngay lập tức | | | Chuyển lớp tự động, không cần mã | |

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

• **D. Lưu trên EFS với lifecycle sang EFS IA — đây là phương án gần nhất và cũng tự mở rộng, cũng có lifecycle, nhưng EFS là hệ thống tệp: đắt hơn nhiều mỗi GB, và không phù hợp cho ứng dụng "người dùng tải lên và tải về" vốn hợp với lưu trữ đối tượng.
• **C. Lưu trên EBS rồi lifecycle chuyển tệp sang Glacier — EBS không có lifecycle policy cho tệp; đó là khái niệm của S3. EBS chỉ có snapshot ở mức volume.
• **B. Lưu trên EBS rồi dùng snapshot để lưu trữ tệp cũ — snapshot là ảnh chụp toàn bộ volume, không phải cơ chế lưu trữ theo tệp; và EBS không mở rộng tới "bất kỳ số lượng tệp nào".

Ghi nhớ

⚠ Các lớp lưu trữ S3 — bảng phải thuộc: | Lớp | Lưu tối thiểu | Lấy dữ liệu | Dùng khi | |---|---|---|---| | Standard | không | không | truy cập thường xuyên | | Intelligent-Tiering | không | không | mẫu truy cập KHÔNG đoán được | | Standard-IA | 30 ngày | có phí | ít truy cập, cần ngay | | One Zone-IA | 30 ngày | có phí | tái tạo được, rẻ hơn 20% | | Glacier Instant Retrieval | 90 ngày | có phí | lưu trữ nhưng cần mili giây | | Glacier Flexible Retrieval | 90 ngày | có phí | lưu trữ, chờ phút-giờ | | Glacier Deep Archive | 180 ngày | có phí | rẻ nhất, chờ 12-48 giờ |

⚠ Intelligent-Tiering là lựa chọn an toàn khi không chắc:

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket kho-tep-nguoi-dung --id tu-dong \
  --intelligent-tiering-configuration '{
    "Id":"tu-dong","Status":"Enabled",
    "Tierings":[{"Days":90,"AccessTier":"ARCHIVE_ACCESS"},
                {"Days":180,"AccessTier":"DEEP_ARCHIVE_ACCESS"}]}'

Tự chuyển lớp theo mẫu truy cập THẬT
    → KHÔNG có phí lấy dữ liệu
        ↓
    Chỉ có phí giám sát ~0,0025 USD mỗi 1000 object
    → đắt với hàng tỷ object nhỏ

Từ khoá nhận diện:

"any number of files, highly durable" → S3 "shared POSIX file system" → EFS "block storage for one instance" → EBS "unknown or changing access pattern" → Intelligent-Tiering "deep archive, cheapest" → Glacier Deep Archive

Ba lưu ý về độ bền và sẵn sàng: | Lớp | Độ bền | Sẵn sàng | |---|---|---| | Standard | 11 số 9 | 99,99% | | Standard-IA | 11 số 9 | 99,9% | | One Zone-IA | 11 số 9 nhưng MỘT AZ | 99,5% |

⚠ One Zone-IA mất dữ liệu nếu AZ đó bị phá huỷ:

Chỉ dùng cho dữ liệu TÁI TẠO ĐƯỢC
    → ảnh thumbnail, bản chuyển mã
        ↓
    Không bao giờ dùng cho tệp gốc của người dùng

Ba lưu ý về versioning: | Lưu ý | Chi tiết | |---|---| | Bảo vệ khỏi xoá và ghi đè nhầm | | | Phiên bản cũ vẫn tính tiền | | | Đặt lifecycle cho phiên bản không hiện hành | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access ở cấp tài khoản | | | Mã hoá mặc định SSE-KMS hoặc SSE-S3 | | | BucketOwnerEnforced tắt hẳn ACL | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | 3.500 PUT và 5.500 GET mỗi giây mỗi tiền tố | | | Chia tiền tố để tăng thông lượng | | | Multipart upload cho tệp trên 100 MB | |

⚠ Tiền tố ngẫu nhiên không còn cần thiết như trước:

S3 tự mở rộng theo tiền tố từ 2018
    → không cần thêm hash ngẫu nhiên vào đầu key
        ↓
    Nhưng vẫn cần nhiều tiền tố nếu vượt
      3.500 PUT/giây

Ba lưu ý về S3 Storage Lens: | Lưu ý | Chi tiết | |---|---| | Bức tranh toàn cảnh về mức dùng | | | Tìm object không dùng, tải lên dở dang | | | Bản miễn phí đã đủ dùng nhiều | |

Ba lưu ý về chuyển lớp hàng loạt: | Cách | Chi tiết | |---|---| | Lifecycle policy | tự động, liên tục | | S3 Batch Operations | chuyển hàng loạt một lần | | Phí chuyển tính theo số object | |

⚠ Phí chuyển lớp theo object là chỗ hay bị bất ngờ:

100 triệu object nhỏ chuyển sang IA
    → ~0,01 USD mỗi 1000 object = 1.000 USD
        ↓
    Tính trước xem có tiết kiệm thật không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra object cũ đã đổi lớp | | | Xem Storage Lens phân bố theo lớp | | | So hoá đơn tháng trước và sau | |

aws s3api list-objects-v2 --bucket kho-tep-nguoi-dung \
  --query "Contents[?StorageClass=='STANDARD_IA'] | length(@)"

Và một lời khuyên: hãy thêm điều kiện kích thước tối thiểu 128 KB vào quy tắc lifecycle. Standard-IA tính phí mọi object như thể nó nặng 128 KB, nên chuyển hàng triệu tệp nhỏ sang đó sẽ làm hoá đơn tăng lên chứ không giảm đi — và đó là kết quả ngược hẳn với ý định của quy tắc.

Đáp án

B — Tạo AWS Service Catalog portfolio cho khách hàng.

Vì sao đúng

Đề nêu ba yêu cầu, và Service Catalog là dịch vụ sinh ra cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Quản lý TẬP TRUNG một bộ giải pháp chuẩn | portfolio chứa các sản phẩm đã duyệt | | PHÂN PHỐI cho khách hàng | chia sẻ portfolio xuyên tài khoản/tổ chức | | Khách hàng TỰ PHỤC VỤ | họ tự khởi chạy từ danh mục |

⚠ Điểm cốt lõi: người dùng khởi chạy được mà KHÔNG cần quyền tạo tài nguyên:

Cách thông thường: cấp quyền tạo EC2, RDS, VPC...
    → người dùng làm gì cũng được
        ↓
Service Catalog: người dùng chỉ có quyền
                 "launch product X"
    → tài nguyên được tạo bởi LAUNCH ROLE
    → đúng cấu hình bạn đã duyệt, không hơn

Dựng portfolio:

aws servicecatalog create-portfolio \
  --display-name "Bo cong cu phan tich du lieu" \
  --provider-name "Cong ty ABC"

aws servicecatalog create-product \
  --name "Moi truong phan tich chuan" \
  --owner "Doi nen tang" --product-type CLOUD_FORMATION_TEMPLATE \
  --provisioning-artifact-parameters \
    'Name=v1.0,Type=CLOUD_FORMATION_TEMPLATE,
     Info={LoadTemplateFromURL=https://s3.../mau.yaml}'

aws servicecatalog associate-product-with-portfolio \
  --product-id prod-abc --portfolio-id port-abc

Chia sẻ cho cả tổ chức:

aws servicecatalog create-portfolio-share \
  --portfolio-id port-abc \
  --organization-node 'Type=ORGANIZATION,Value=o-abc123def4'

⚠ Launch constraint là cơ chế làm nên giá trị của Service Catalog:

aws servicecatalog create-constraint \
  --portfolio-id port-abc --product-id prod-abc \
  --type LAUNCH \
  --parameters '{"RoleArn":"arn:aws:iam::123456789012:role/VaiTroKhoiChay"}'

Người dùng KHÔNG có quyền tạo RDS
    → nhưng khởi chạy được sản phẩm chứa RDS
        ↓
    Vì CloudFormation dùng launch role, không dùng
      quyền của người dùng

Ba loại ràng buộc: | Loại | Việc | |---|---| | Launch | vai trò dùng để tạo tài nguyên | | Template | giới hạn giá trị tham số | | Notification | gửi SNS khi có sự kiện |

⚠ Template constraint giới hạn lựa chọn của người dùng:

{"Rules": {"GioiHanLoaiMay": {
  "Assertions": [{
    "Assert": {"Fn::Contains": [
      ["t3.micro","t3.small","m5.large"],
      {"Ref": "LoaiInstance"}]},
    "AssertDescription": "Chi duoc chon ba loai may nay"}]}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chuẩn hoá — mọi người dùng cùng một cấu hình | | | Quản lý phiên bản sản phẩm | | | Kiểm soát chi phí và tuân thủ từ gốc | |

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

• **D. Tạo CloudFormation stack cho khách hàng — đây là phương án gần nhất và là công nghệ nằm BÊN DƯỚI Service Catalog, nhưng nó không có danh mục, không có tự phục vụ, không có ràng buộc khởi chạy, và không có cơ chế chia sẻ có kiểm soát. Bạn sẽ phải cấp quyền CloudFormation rộng cho từng khách hàng.
• **A. Tạo Systems Manager document — SSM document chạy lệnh trên máy đã có, không phải để cấp phát hạ tầng mới.
• **C. Tạo AWS Config rule — Config phát hiện cấu hình không tuân thủ, nó không phân phối hay cấp phát gì cả.

Ghi nhớ

⚠ Bốn công cụ quản trị hay bị lẫn — bảng phải thuộc: | Công cụ | Việc | |---|---| | Service Catalog | danh mục sản phẩm tự phục vụ có kiểm soát | | CloudFormation | cấp phát hạ tầng bằng mã | | Config | phát hiện cấu hình không tuân thủ | | Control Tower | dựng và quản trị môi trường nhiều tài khoản |

Từ khoá nhận diện:

"self-service catalog of approved solutions" → Service Catalog "infrastructure as code" → CloudFormation / CDK "detect non-compliant resources" → Config "set up multi-account landing zone" → Control Tower "run commands on instances" → Systems Manager

⚠ Control Tower và Service Catalog bổ sung nhau:

Control Tower: dựng KHUNG tài khoản, guardrail, SSO
    → chính nó dùng Service Catalog cho Account Factory
        ↓
Service Catalog: cấp phát TÀI NGUYÊN trong các tài khoản đó

Ba cách chia sẻ portfolio: | Cách | Chi tiết | |---|---| | Theo account ID | từng tài khoản | | Theo OU | tài khoản trong OU đó | | Theo ID tổ chức | cả tổ chức |

Ba lưu ý về quản lý phiên bản: | Lưu ý | Chi tiết | |---|---| | Mỗi sản phẩm có nhiều provisioning artifact | | | Đánh dấu phiên bản cũ là không dùng nữa | | | Người dùng cập nhật sản phẩm đã cấp phát | |

aws servicecatalog update-provisioned-product \
  --provisioned-product-id pp-abc \
  --provisioning-artifact-id pa-moi

⚠ Cập nhật hàng loạt là lợi thế lớn:

Phát hiện lỗ hổng trong AMI đang dùng
    → cập nhật template, tạo phiên bản mới
        ↓
    Mọi sản phẩm đã cấp phát cập nhật được
    → không phải liên hệ từng khách hàng

Ba lưu ý về TagOptions: | Lưu ý | Chi tiết | |---|---| | Ép tag khi cấp phát | | | Bảo đảm phân bổ chi phí đúng | | | Người dùng chọn từ danh sách cho phép | |

Ba lưu ý về loại sản phẩm: | Loại | Chi tiết | |---|---| | CloudFormation template | phổ biến nhất | | Terraform Open Source | hỗ trợ từ 2023 | | Terraform Cloud | |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Người dùng cần servicecatalog:* hạn chế | | | KHÔNG cần quyền tạo tài nguyên | | | Launch role phải có đủ quyền | |

{"Effect": "Allow",
 "Action": ["servicecatalog:SearchProducts",
            "servicecatalog:ProvisionProduct",
            "servicecatalog:DescribeRecord",
            "servicecatalog:ListLaunchPaths"],
 "Resource": "*"}

Ba lưu ý về launch role: | Lưu ý | Chi tiết | |---|---| | Cần quyền cho mọi tài nguyên trong template | | | Trust policy cho servicecatalog.amazonaws.com | | | Áp dụng nguyên tắc quyền tối thiểu | |

Ba lưu ý về Service Actions: | Lưu ý | Chi tiết | |---|---| | Cho phép chạy SSM document lên sản phẩm | | | Ví dụ: khởi động lại, sao lưu | | | Người dùng thao tác mà không cần quyền EC2 | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Service Catalog gần như miễn phí | | | Chỉ trả tiền tài nguyên được tạo | | | Có phí nhỏ cho API call | |

Ba lưu ý về vận hành: | Lưu ý | Chi tiết | |---|---| | Ghi tài liệu cho từng sản phẩm | | | Kiểm thử template trước khi xuất bản | | | Theo dõi sản phẩm nào được dùng nhiều | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập bằng tài khoản người dùng thử | | | Cấp phát một sản phẩm | | | Xác nhận người dùng KHÔNG tạo được EC2 trực tiếp | |

aws servicecatalog search-products \
  --query "ProductViewSummaries[].[Name,Owner]" --output table

Và một lời khuyên: hãy luôn đặt launch constraint cho mọi sản phẩm. Không có nó, người dùng phải tự có quyền tạo mọi tài nguyên trong template — và lúc đó Service Catalog chỉ còn là một danh sách đẹp mắt chứ không còn là cơ chế kiểm soát nào cả.

Đáp án

A — Cấu hình một Amazon RDS Proxy cho CSDL và sửa ứng dụng để kết nối tới endpoint của proxy.

Vì sao đúng

Đề nêu triệu chứng rất cụ thể: ngừng khoảng 3 phút khi failover có kế hoạch, và cần giảm thời gian đó với ít công vận hành nhất.

⚠ Ba phút là điển hình cho failover KHÔNG có proxy:

RDS chuyển sang standby (~60-120 giây)
    + ứng dụng chờ TCP timeout của kết nối cũ
    + chờ DNS cache hết hạn
    + mở lại pool kết nối
        ↓
    Tổng cộng ~3 phút

RDS Proxy rút ngắn ở cả ba khâu:

Proxy giữ pool kết nối tới CSDL
    → khi failover, proxy phát hiện và tự trỏ sang writer mới
        ↓
    Kết nối từ ỨNG DỤNG tới PROXY không bị ngắt
    → ứng dụng chỉ thấy một khoảng chờ ngắn
        ↓
    AWS đo được: giảm thời gian gián đoạn tới ~66%

Dựng proxy:

aws rds create-db-proxy --db-proxy-name proxy-ung-dung \
  --engine-family MYSQL \
  --auth '[{"AuthScheme":"SECRETS",
            "SecretArn":"<arn-secret>",
            "IAMAuth":"DISABLED"}]' \
  --role-arn <arn-role> \
  --vpc-subnet-ids subnet-a subnet-b \
  --vpc-security-group-ids sg-proxy \
  --require-tls --idle-client-timeout 1800

aws rds register-db-proxy-targets \
  --db-proxy-name proxy-ung-dung \
  --db-instance-identifiers csdl-ung-dung

Đổi chuỗi kết nối:

Trước: csdl-ung-dung.abc.ap-southeast-1.rds.amazonaws.com
Sau:   proxy-ung-dung.proxy-abc.ap-southeast-1.rds.amazonaws.com

⚠ Đây là toàn bộ thay đổi ở phía ứng dụng — đúng nghĩa "minimizing operational overhead".

RDS Proxy còn giải quyết ba vấn đề khác: | Vấn đề | Cách giải | |---|---| | Cạn kết nối CSDL | gộp và tái dùng kết nối | | Credential nằm trong ứng dụng | proxy lấy từ Secrets Manager | | Lambda mở quá nhiều kết nối | proxy làm lớp đệm |

⚠ Bật IAM authentication để bỏ hẳn mật khẩu ở phía ứng dụng:

--auth '[{"AuthScheme":"SECRETS","SecretArn":"<arn>",
          "IAMAuth":"REQUIRED"}]'

Client dùng token IAM tới proxy
    → proxy dùng Secrets Manager tới CSDL
        ↓
    Không có mật khẩu nào ở phía ứng dụng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giảm thời gian gián đoạn khi failover | | | Gộp kết nối, giảm tải CSDL | | | Quản lý credential tập trung | |

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

• **C. Thêm read replica để chịu tải trong lúc failover — đây là phương án gần nhất vì có vẻ liên quan tới tính sẵn sàng, nhưng read replica chỉ phục vụ ĐỌC; trong lúc failover, các thao tác GHI vẫn thất bại. Nó không rút ngắn thời gian chuyển đổi.
• **B. Dùng ElastiCache for Redis chịu tải trong lúc failover — cache phục vụ được đọc từ dữ liệu đã lưu, nhưng cũng không giúp gì cho ghi, và không rút ngắn failover.
• **D. Dựng cụm RDS thứ hai và đổi ứng dụng trỏ sang writer của nó khi cần — đây là công vận hành thủ công trong lúc sự cố, ngược hẳn "minimizing operational overhead"; và giữ một cụm thứ hai là chi phí gấp đôi.

Ghi nhớ

⚠ Bốn cách rút ngắn gián đoạn khi failover — bảng phải thuộc: | Cách | Hiệu quả | |---|---| | RDS Proxy | giảm tới ~66% thời gian gián đoạn | | Ứng dụng biết thử lại có backoff | bắt buộc phải có | | Giảm TTL DNS ở client | JVM mặc định cache mãi mãi | | Aurora thay RDS | failover dưới 30 giây |

⚠ Java cache DNS vĩnh viễn theo mặc định — bẫy kinh điển:

java.security.Security.setProperty(
    "networkaddress.cache.ttl", "5");

Không đặt: JVM giữ IP cũ MÃI MÃI
    → sau failover, ứng dụng vẫn gọi vào máy chết
        ↓
    Đây là nguyên nhân số một của "failover xong
      mà ứng dụng vẫn không kết nối được"

Từ khoá nhận diện:

"reduce failover downtime, least overhead" → RDS Proxy "too many database connections" → RDS Proxy "scale read traffic" → read replica "failover under 30 seconds" → Aurora

Ba trường hợp RDS Proxy đặc biệt đáng dùng: | Trường hợp | Vì sao | |---|---| | Lambda gọi CSDL | Lambda mở rộng nhanh hơn CSDL chịu được | | Ứng dụng mở nhiều kết nối ngắn | | | Cần giảm gián đoạn khi failover | |

⚠ Với Lambda, RDS Proxy gần như bắt buộc:

1000 thực thi Lambda đồng thời
    → 1000 kết nối tới RDS
        ↓
    CSDL chạm `max_connections` và từ chối
    → proxy gộp lại còn vài chục kết nối thật

Ba khái niệm của RDS Proxy: | Khái niệm | Nghĩa | |---|---| | Connection pool | kết nối tới CSDL được tái dùng | | Pinning | kết nối bị "ghim", không tái dùng được | | Target group | instance nào proxy trỏ tới |

⚠ Pinning làm mất lợi ích gộp kết nối:

Một số thao tác buộc proxy ghim kết nối:
    → dùng biến phiên, temporary table,
      prepared statement, khoá bảng
        ↓
    Kết nối đó không phục vụ client khác được
    → theo dõi `DatabaseConnectionsCurrentlySessionPinned`

aws rds modify-db-proxy --db-proxy-name proxy-ung-dung \
  --debug-logging   # bật để xem nguyên nhân ghim

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Proxy thêm ~5 ms độ trễ mỗi truy vấn | | | Đáng đổi lấy độ ổn định | | | Không dùng cho truy vấn cực nhạy độ trễ | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo vCPU của instance CSDL | | | ~0,015 USD mỗi vCPU mỗi giờ | | | Instance lớn = proxy đắt hơn | |

Ba lưu ý về thử lại trong ứng dụng: | Lưu ý | Chi tiết | |---|---| | Thử lại có exponential backoff và jitter | | | Phân biệt lỗi tạm và lỗi vĩnh viễn | | | Giới hạn số lần thử | |

⚠ Thử lại không có jitter tạo ra bão kết nối:

1000 client cùng thất bại, cùng chờ 1 giây, cùng thử lại
    → CSDL vừa hồi phục lại bị đánh sập
        ↓
    Thêm jitter ngẫu nhiên vào khoảng chờ

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Multi-AZ DB instance: 60-120 giây | | | Multi-AZ DB cluster: dưới 35 giây | | | Aurora: thường dưới 30 giây | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | DatabaseConnections | tổng kết nối | | ClientConnections | client tới proxy | | DatabaseConnectionsCurrentlySessionPinned | bao nhiêu bị ghim |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | --require-tls bắt buộc mã hoá | | | Proxy trong subnet riêng tư | | | Vai trò proxy chỉ đọc được secret cần thiết | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy failover thử, bấm giờ | | | Theo dõi ClientConnections khi có tải | | | Kiểm tra tỷ lệ kết nối bị ghim | |

aws rds reboot-db-instance --db-instance-identifier csdl-ung-dung \
  --force-failover

Và một lời khuyên: hãy đặt TTL cache DNS trong ứng dụng cùng lúc với việc dựng RDS Proxy. Proxy chuyển sang writer mới rất nhanh, nhưng nếu client vẫn giữ IP cũ của endpoint proxy trong bộ nhớ đệm vĩnh viễn thì bạn đã sửa đúng một nửa vấn đề và sẽ đo được đúng một nửa cải thiện.

Đáp án

C — Dùng Amazon SageMaker để xây dựng, huấn luyện và triển khai mô hình ML, và dùng Amazon QuickSight để trực quan hoá.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Tự tạo mô hình ML trên dữ liệu giao dịch của mình | SageMaker — xây, huấn luyện, triển khai | | Tích hợp vào hệ thống BI để quyết định | QuickSight | | Công vận hành tối thiểu | cả hai đều được quản lý hoàn toàn |

⚠ Đề nói "create ML models based on their vast transaction data" — tức là mô hình TUỲ CHỈNH:

Dịch vụ AI dựng sẵn (Comprehend, Rekognition...)
    → mô hình do AWS huấn luyện trên dữ liệu chung
        ↓
    Phát hiện gian lận cần mô hình học trên
    ĐÚNG dữ liệu giao dịch của tổ chức đó
    → SageMaker

Ba giai đoạn trong SageMaker:

# Huấn luyện
aws sagemaker create-training-job \
  --training-job-name mo-hinh-gian-lan-v1 \
  --algorithm-specification     'TrainingImage=<image-xgboost>,TrainingInputMode=File' \
  --role-arn <arn-role> \
  --input-data-config '[{"ChannelName":"train",
    "DataSource":{"S3DataSource":{"S3Uri":"s3://du-lieu/train/",
      "S3DataType":"S3Prefix"}}}]' \
  --output-data-config S3OutputPath=s3://mo-hinh/ \
  --resource-config 'InstanceType=ml.m5.2xlarge,
                     InstanceCount=1,VolumeSizeInGB=50' \
  --stopping-condition MaxRuntimeInSeconds=7200

# Triển khai endpoint thời gian thực
aws sagemaker create-endpoint \
  --endpoint-name gian-lan-thoi-gian-thuc \
  --endpoint-config-name cau-hinh-gian-lan

⚠ QuickSight nối thẳng vào endpoint SageMaker:

QuickSight ML integration:
    → gửi dữ liệu qua endpoint SageMaker
    → nhận điểm dự đoán về
        ↓
    Dashboard hiện điểm rủi ro gian lận
    → đúng "tích hợp vào hệ thống BI"

Ba tính năng của SageMaker giảm công vận hành: | Tính năng | Việc | |---|---| | Autopilot | tự chọn thuật toán và tinh chỉnh | | Automatic Model Tuning | tìm siêu tham số tốt nhất | | Serverless Inference | không quản lý endpoint |

⚠ Serverless Inference đáng cân nhắc cho tải thất thường:

aws sagemaker create-endpoint-config \
  --endpoint-config-name cau-hinh-serverless \
  --production-variants '[{
    "VariantName":"chinh","ModelName":"mo-hinh-gian-lan",
    "ServerlessConfig":{"MemorySizeInMB":4096,
                        "MaxConcurrency":20}}]'

Endpoint thường trực: trả tiền 24/7
        ↓
    Serverless: trả theo lời gọi
    → hợp khi lưu lượng không đều

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không quản lý hạ tầng huấn luyện | | | Có sẵn thuật toán tối ưu (XGBoost, Random Cut Forest) | | | Từ dữ liệu tới dashboard trong một hệ sinh thái | |

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

• **B. Glue ETL rồi Amazon Forecast — đây là phương án gần nhất vì Forecast cũng là dịch vụ ML được quản lý, nhưng Forecast dành cho dự báo chuỗi thời gian (doanh số tháng tới, nhu cầu hàng hoá), không phải phân loại giao dịch gian lận.
• **A. Comprehend phân tích dữ liệu giao dịch + Elasticsearch trực quan hoá — Comprehend xử lý văn bản tự nhiên (cảm xúc, thực thể), không phải dữ liệu giao dịch dạng bảng.
• **D. Dùng AMI ML từ Marketplace và Athena để trực quan hoá — sai hai chỗ: tự quản lý EC2 là công vận hành cao nhất, và Athena là công cụ truy vấn, không phải công cụ trực quan hoá.

Ghi nhớ

⚠ Ba tầng dịch vụ ML của AWS — bảng phải thuộc: | Tầng | Dịch vụ | Khi nào | |---|---|---| | Dịch vụ AI dựng sẵn | Rekognition, Comprehend, Transcribe, Fraud Detector | bài toán phổ biến | | Nền tảng ML | SageMaker | mô hình tuỳ chỉnh trên dữ liệu riêng | | Hạ tầng ML | EC2 với GPU, Deep Learning AMI | kiểm soát tối đa |

⚠ Có một dịch vụ chuyên cho bài toán này — Amazon Fraud Detector:

aws frauddetector create-model \
  --model-id mo-hinh-gian-lan \
  --model-type ONLINE_FRAUD_INSIGHTS \
  --event-type-name giao-dich

Fraud Detector: chuyên phát hiện gian lận,
                ít công hơn SageMaker
        ↓
    Nhưng không có trong bốn phương án
    → và đề nói rõ muốn "create ML models"
      trên dữ liệu của mình

Từ khoá nhận diện:

"build, train, deploy custom ML models" → SageMaker "time-series forecasting" → Amazon Forecast "fraud detection out of the box" → Fraud Detector "text sentiment, entities" → Comprehend "personalized recommendations" → Personalize "anomaly detection in metrics" → Lookout for Metrics

Ba thuật toán dựng sẵn hợp cho phát hiện gian lận: | Thuật toán | Việc | |---|---| | XGBoost | phân loại có nhãn — chuẩn công nghiệp | | Random Cut Forest | phát hiện bất thường không cần nhãn | | Linear Learner | phân loại đơn giản, nhanh |

⚠ Dữ liệu gian lận luôn MẤT CÂN BẰNG nghiêm trọng:

99,9% giao dịch hợp lệ, 0,1% gian lận
    → mô hình đoán "hợp lệ" cho mọi thứ
    → độ chính xác 99,9% mà VÔ DỤNG
        ↓
    Dùng precision, recall, F1, AUC-PR
    → KHÔNG dùng accuracy

Ba cách xử lý mất cân bằng: | Cách | Chi tiết | |---|---| | scale_pos_weight trong XGBoost | | | Lấy mẫu lại (SMOTE) | | | Điều chỉnh ngưỡng quyết định | |

Ba lưu ý về SageMaker Feature Store: | Lưu ý | Chi tiết | |---|---| | Lưu đặc trưng dùng chung cho huấn luyện và suy luận | | | Tránh lệch giữa training và serving | | | Có kho online và offline | |

⚠ Lệch giữa huấn luyện và suy luận là lỗi ML phổ biến nhất:

Huấn luyện tính đặc trưng bằng Spark
Suy luận tính lại bằng Python
        ↓
    Hai cách tính khác nhau chút ít
    → mô hình chạy thật kém hơn hẳn lúc thử

Ba lưu ý về Model Monitor: | Lưu ý | Chi tiết | |---|---| | Phát hiện lệch dữ liệu (data drift) | | | Cảnh báo khi chất lượng giảm | | | Mẫu gian lận thay đổi liên tục | |

Ba lưu ý về triển khai: | Cách | Khi nào | |---|---| | Real-time endpoint | cần trả lời tức thì | | Serverless inference | tải thất thường | | Batch transform | chấm điểm hàng loạt | | Asynchronous inference | payload lớn, chờ được |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Huấn luyện tính theo giờ instance | | | Endpoint tính 24/7 nếu thường trực | | | Dùng Spot cho huấn luyện, giảm tới 90% | |

--enable-managed-spot-training \
--stopping-condition MaxRuntimeInSeconds=7200,MaxWaitTimeInSeconds=14400

Ba lưu ý về giải thích mô hình: | Lưu ý | Chi tiết | |---|---| | SageMaker Clarify giải thích dự đoán | | | Ngành tài chính thường bắt buộc giải thích được | | | Phát hiện thiên lệch trong dữ liệu | |

⚠ Với dịch vụ tài chính, giải thích được là yêu cầu pháp lý:

Từ chối một giao dịch của khách hàng
    → có thể phải giải thích vì sao
        ↓
    Mô hình hộp đen gây rủi ro tuân thủ
    → dùng Clarify, hoặc mô hình đơn giản hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo precision và recall trên tập kiểm tra | | | Gọi endpoint thử, đo độ trễ | | | Xác nhận dashboard QuickSight hiện điểm | |

Và một lời khuyên: hãy đánh giá mô hình bằng precision và recall chứ đừng bằng độ chính xác. Trong phát hiện gian lận, một mô hình gắn nhãn "hợp lệ" cho mọi giao dịch sẽ đạt độ chính xác trên 99% và bắt được đúng không giao dịch gian lận nào — con số đẹp nhất trong báo cáo lại chính là con số vô nghĩa nhất.

Đáp án

C — Xây dựng WebSocket API bằng Amazon API Gateway, chạy ứng dụng trên EKS trong subnet riêng tư, và thiết lập VPC link riêng tư để API Gateway truy cập cụm EKS an toàn.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này là phương án duy nhất đúng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Kết nối BỀN VỮNG bằng WebSocket | WebSocket API, không phải REST API | | Backend trong subnet riêng tư, truy cập AN TOÀN | VPC link, không phải security group |

⚠ Vế thứ nhất — REST API KHÔNG hỗ trợ WebSocket:

REST API và HTTP API: yêu cầu–phản hồi, kết nối đóng ngay
        ↓
WebSocket API: giữ kết nối hai chiều, máy chủ chủ động
               đẩy tin nhắn xuống client
        ↓
    Chat thời gian thực cần vế thứ hai

⚠ Vế thứ hai — security group KHÔNG cho API Gateway vào VPC:

API Gateway là dịch vụ CÔNG KHAI, nằm ngoài VPC của bạn
    → không có ENI nào trong VPC
    → không có gì để đặt vào security group
        ↓
    Cách duy nhất tới backend riêng tư: VPC link

Đây chính là lý do phương án D sai dù nó cũng dùng WebSocket API.

Tạo VPC link:

aws apigatewayv2 create-vpc-link \
  --name link-eks --subnet-ids subnet-a subnet-b \
  --security-group-ids sg-vpclink

⚠ VPC link của WebSocket/REST API trỏ vào NLB: | Loại API | VPC link trỏ tới | |---|---| | REST API, WebSocket API | Network Load Balancer | | HTTP API | ALB, NLB, hoặc Cloud Map |

EKS Service kiểu LoadBalancer với annotation NLB
    → NLB nội bộ trong subnet riêng tư
        ↓
    VPC link trỏ vào NLB đó

apiVersion: v1
kind: Service
metadata:
  name: dich-vu-chat
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ba tuyến bắt buộc của WebSocket API: | Tuyến | Khi nào | |---|---| | $connect | client mở kết nối — xác thực ở đây | | $disconnect | client đóng kết nối | | $default | tin nhắn không khớp tuyến nào |

aws apigatewayv2 create-api --name api-chat \
  --protocol-type WEBSOCKET \
  --route-selection-expression '$request.body.hanhDong'

⚠ Gửi tin nhắn ngược xuống client dùng API riêng:

import boto3
quan_ly = boto3.client('apigatewaymanagementapi',
    endpoint_url='https://abc.execute-api.ap-southeast-1.amazonaws.com/prod')

quan_ly.post_to_connection(
    ConnectionId='<id-ket-noi>',
    Data=json.dumps({'noiDung': 'Xin chao'}).encode())

⚠ Phải lưu connectionId ở đâu đó:

Backend cần biết gửi cho ai
    → lưu connectionId vào DynamoDB lúc $connect
    → xoá lúc $disconnect
        ↓
    Không lưu = không gửi tin nhắn xuống được

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | API Gateway quản lý kết nối, không phải backend | | | Backend không phơi ra Internet | | | Tự mở rộng theo số kết nối | |

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

• **D. WebSocket API + EKS riêng tư + security group cho phép API Gateway — đây là phương án gần nhất và đúng ở vế WebSocket, nhưng API Gateway không có ENI trong VPC nên không tham chiếu được bằng security group; phải dùng VPC link.
• **A. REST API + VPC link — đúng ở vế kết nối riêng tư nhưng REST API không hỗ trợ WebSocket, vi phạm yêu cầu chính của đề.
• **B. REST API + security group — sai cả hai vế.

Ghi nhớ

⚠ Ba loại API của API Gateway — bảng phải thuộc: | Loại | Giao thức | VPC link trỏ tới | |---|---|---| | REST API | HTTP yêu cầu–phản hồi | NLB | | HTTP API | HTTP, rẻ hơn ~70% | ALB, NLB, Cloud Map | | WebSocket API | kết nối bền vững hai chiều | NLB |

Từ khoá nhận diện:

"persistent connection, real-time chat, push to client" → WebSocket API "private backend in VPC" → VPC link "simple REST, lowest cost" → HTTP API "API key, usage plan, WAF" → REST API

⚠ Ba cách làm thời gian thực trên AWS: | Cách | Khi nào | |---|---| | API Gateway WebSocket | kiểm soát đầy đủ, backend tuỳ ý | | AWS AppSync (GraphQL subscriptions) | ít mã hơn, có sẵn quản lý kết nối | | IoT Core (MQTT over WebSocket) | thiết bị, pub/sub quy mô lớn |

Chat đơn giản → AppSync thường ít việc hơn
Logic phức tạp, backend có sẵn → WebSocket API

Ba lưu ý về xác thực WebSocket: | Lưu ý | Chi tiết | |---|---| | Xác thực ở tuyến $connect | | | Lambda authorizer hoặc IAM | | | Token qua query string vì WebSocket không có header tuỳ chỉnh | |

⚠ Đây là hạn chế thật của WebSocket trong trình duyệt:

API WebSocket của trình duyệt KHÔNG đặt header được
    → không gửi được `Authorization: Bearer ...`
        ↓
    Truyền token qua query string
    → hoặc xác thực bằng tin nhắn đầu tiên

Ba giới hạn của WebSocket API: | Giới hạn | Giá trị | |---|---| | Thời gian kết nối tối đa | 2 giờ | | Thời gian rảnh tối đa | 10 phút | | Kích thước khung tin nhắn | 128 KB |

⚠ Client phải tự kết nối lại sau 2 giờ:

Kết nối bị đóng khi đủ 2 giờ
    → client phải bắt sự kiện close và mở lại
        ↓
    Và gửi ping định kỳ để tránh timeout 10 phút

Ba lưu ý về VPC link: | Lưu ý | Chi tiết | |---|---| | Tạo mất vài phút | | | Dùng lại được cho nhiều API | | | NLB phải là internal | |

Ba lưu ý về EKS: | Lưu ý | Chi tiết | |---|---| | Cần AWS Load Balancer Controller | | | Pod trong subnet riêng tư | | | Ứng dụng WebSocket cần xử lý kết nối bền | |

Ba lưu ý về lưu trạng thái kết nối: | Lưu ý | Chi tiết | |---|---| | DynamoDB lưu connectionId là mẫu chuẩn | | | Đặt TTL để dọn kết nối chết | | | Lưu thêm mã phòng chat để gửi nhóm | |

bang.put_item(Item={
    'connectionId': ma_ket_noi,
    'maPhong': ma_phong,
    'hetHan': int(time.time()) + 7200})

⚠ TTL quan trọng vì $disconnect không đảm bảo chạy:

Client mất mạng đột ngột
    → $disconnect có thể không được gọi
        ↓
    Bản ghi kết nối nằm lại mãi
    → gửi tin nhắn vào đó trả lỗi GoneException

Ba lưu ý về mở rộng: | Lưu ý | Chi tiết | |---|---| | API Gateway quản lý kết nối, backend không cần | | | Backend chỉ xử lý tin nhắn, không giữ trạng thái | | | Gửi nhóm thì lặp qua danh sách connectionId | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | ~1,00 USD mỗi triệu tin nhắn | | | ~0,25 USD mỗi triệu phút kết nối | | | Kết nối rảnh vẫn tính phí phút | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối bằng wscat | | | Gửi tin nhắn hai chiều | | | Xác nhận backend không truy cập được từ Internet | |

wscat -c "wss://abc.execute-api.ap-southeast-1.amazonaws.com/prod?token=<token>"

Và một lời khuyên: hãy đặt TTL cho bản ghi connectionId trong DynamoDB ngay từ đầu. Tuyến $disconnect không được đảm bảo gọi khi client mất mạng đột ngột, nên bảng kết nối sẽ đầy dần những định danh chết mà bạn chỉ phát hiện khi mỗi lần gửi tin nhắn nhóm phải xử lý hàng nghìn lỗi GoneException.

Đáp án

B — Tạo VPC Flow Log cho từng network interface gắn với ELB.

Vì sao đúng

Đề cần ghi lại nguồn, đích và giao thức của lưu lượng tới ELB, một cách an toàn và tin cậy.

⚠ VPC Flow Logs ghi đúng ba trường đó:

Bản ghi flow log gồm:
    srcaddr  dstaddr  srcport  dstport  protocol
    packets  bytes    action   log-status
        ↓
    Đúng "source, destination, and protocol"

ELB có ENI trong mỗi subnet nó hoạt động:

aws ec2 describe-network-interfaces \
  --filters Name=description,Values="ELB app/alb-ung-dung/*" \
  --query "NetworkInterfaces[].[NetworkInterfaceId,AvailabilityZone]" \
  --output table

Tạo flow log cho từng ENI:

aws ec2 create-flow-logs \
  --resource-type NetworkInterface \
  --resource-ids eni-abc eni-def \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::log-flow-elb/ \
  --max-aggregation-interval 60

⚠ Vì sao "an toàn và tin cậy": | Tiêu chí | Vì sao Flow Logs đạt | |---|---| | AWS thu thập ở tầng hạ tầng | không phụ thuộc agent nào | | Không đụng vào đường dữ liệu | không ảnh hưởng hiệu năng | | Đích là S3 hoặc CloudWatch Logs có mã hoá | |

Định dạng tuỳ chỉnh lấy đúng trường cần:

--log-format '${srcaddr} ${dstaddr} ${srcport} ${dstport} \
${protocol} ${action} ${log-status} ${flow-direction}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần cài gì lên máy nào | | | Ghi cả lưu lượng bị từ chối (REJECT) | | | Truy vấn bằng Athena | |

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

⚠ Phương án A cũng ghi được đúng dữ liệu đó, và trong thực tế thường tốt hơn.

Flow log ở cấp subnet bao trùm mọi ENI trong subnet — bao gồm cả ENI của ELB. Khác biệt thật:

ALB TỰ THÊM ENI khi mở rộng
    → ENI mới KHÔNG có flow log
        ↓
    Cấu hình theo ENI đúng vào hôm nay,
    thiếu dần theo thời gian

Đề chọn B, có lẽ vì "chính xác nhất" — nhưng cấu hình theo subnet hoặc theo VPC bền hơn cho mục đích giám sát lâu dài. Nếu dựng thật, hãy chọn cấp VPC hoặc subnet rồi lọc theo ENI của ELB lúc truy vấn.

SELECT srcaddr, dstaddr, protocol, SUM(bytes) AS tong
FROM flow_logs
WHERE interface_id IN (SELECT eni FROM eni_cua_elb)
GROUP BY srcaddr, dstaddr, protocol;

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

• **A. Flow log cho subnet chứa ELB — xem phần trên: cũng ghi được, và thực tế bền hơn; đề coi là kém chính xác vì lẫn lưu lượng khác.
• **C. Dùng CloudWatch Logs xem thông tin chi tiết — CloudWatch Logs là nơi chứa log, không phải nguồn sinh ra chúng; riêng nó không ghi lưu lượng mạng.
• **D. Bật CloudTrail và cấu hình bắt gói tin — CloudTrail ghi lời gọi API, không ghi lưu lượng mạng; và CloudTrail không có tính năng bắt gói tin nào.

Ghi nhớ

⚠ Ba cấp của VPC Flow Logs — bảng phải thuộc: | Cấp | Bao phủ | |---|---| | VPC | mọi ENI trong VPC, gồm cả ENI tạo sau | | Subnet | mọi ENI trong subnet đó | | Network interface | chỉ đúng ENI đó |

⚠ Cấp thấp hơn ghi đè cấp cao hơn cho ENI đó — có thể tạo nhiều flow log cùng lúc.

Từ khoá nhận diện:

"source, destination, protocol of traffic" → VPC Flow Logs "who called which API" → CloudTrail "full packet contents" → VPC Traffic Mirroring "HTTP request details, user agent, URL" → ALB access logs

⚠ ALB access log ghi thứ Flow Logs không có: | Nguồn | Ghi gì | |---|---| | VPC Flow Logs | tầng 3/4 — IP, cổng, giao thức, byte | | ALB access logs | tầng 7 — URL, user agent, mã trạng thái, độ trễ | | Traffic Mirroring | toàn bộ nội dung gói tin |

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn> \
  --attributes Key=access_logs.s3.enabled,Value=true \
    Key=access_logs.s3.bucket,Value=log-alb

⚠ Với ALB, IP nguồn thật nằm trong X-Forwarded-For:

Flow log của ENI target group thấy IP của ALB
    → không thấy IP người dùng cuối
        ↓
    IP thật chỉ có ở access log của ALB
    → hoặc ở flow log của ENI phía ngoài ALB

Ba trường quan trọng của flow log: | Trường | Ý nghĩa | |---|---| | action | ACCEPT hoặc REJECT | | log-status | OK, NODATA, SKIPDATA | | flow-direction | ingress hay egress |

⚠ SKIPDATA nghĩa là bản ghi bị BỎ:

Lưu lượng quá lớn trong một cửa sổ tổng hợp
    → AWS bỏ bớt bản ghi
        ↓
    Flow log KHÔNG đảm bảo đầy đủ 100%
    → không dùng làm bằng chứng tuyệt đối

Ba lưu ý về khoảng tổng hợp: | Giá trị | Đánh đổi | |---|---| | 60 giây | chi tiết hơn, nhiều dữ liệu hơn | | 600 giây (mặc định) | ít dữ liệu, kém chi tiết |

Ba đích của flow log: | Đích | Khi nào | |---|---| | S3 | rẻ nhất, phân tích bằng Athena | | CloudWatch Logs | cần cảnh báo thời gian thực | | Kinesis Data Firehose | đưa sang hệ thống khác |

⚠ S3 rẻ hơn CloudWatch Logs nhiều cho khối lượng lớn:

Flow log của VPC bận sinh hàng chục GB mỗi ngày
    → CloudWatch Logs tính phí nạp cao
        ↓
    S3 + Athena rẻ hơn nhiều lần

Ba thứ flow log KHÔNG ghi: | Không ghi | Chi tiết | |---|---| | Nội dung gói tin | chỉ siêu dữ liệu | | Lưu lượng tới DNS của Amazon | | | Lưu lượng tới metadata service (169.254.169.254) | |

Ba lưu ý về Traffic Mirroring: | Lưu ý | Chi tiết | |---|---| | Sao chép TOÀN BỘ gói tin | | | Cần đích là NLB hoặc ENI phân tích | | | Tốn băng thông đáng kể | |

Ba lưu ý về phân tích: | Công cụ | Việc | |---|---| | Athena | truy vấn SQL trên S3 | | CloudWatch Logs Insights | nếu đích là CW Logs | | VPC Flow Logs dashboard | mẫu dựng sẵn |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí nạp theo GB | | | Phí lưu trữ ở đích | | | Định dạng tuỳ chỉnh ít trường = ít dữ liệu hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chờ vài phút rồi kiểm tra có bản ghi | | | Xác nhận thấy được IP nguồn | | | Kiểm tra log-status không phải SKIPDATA | |

aws ec2 describe-flow-logs \
  --query "FlowLogs[].[FlowLogId,ResourceId,FlowLogStatus]" --output table

Và một lời khuyên: hãy cấu hình flow log ở cấp VPC chứ đừng theo từng ENI khi giám sát lâu dài. Load balancer tự thêm và bỏ network interface khi co giãn, nên một cấu hình liệt kê ENI cụ thể sẽ dần bỏ sót lưu lượng — và bạn không có cách nào biết trừ khi đi đối chiếu lại danh sách.

Đáp án

A — Amazon ElastiCache for Redis.

Vì sao đúng

Đề nêu hai yêu cầu cho tầng cache, và chỉ Redis đáp ứng cả hai: | Yêu cầu | Redis có | |---|---| | Tính sẵn sàng cao | Multi-AZ với chuyển đổi tự động | | Nhân bản (replication) | replication group với primary và replica |

⚠ Memcached KHÔNG có cả hai thứ này:

Memcached: các node độc lập, KHÔNG nhân bản
    → node chết = mất sạch dữ liệu trên node đó
    → không có failover
        ↓
Redis replication group: primary + tới 5 replica
    → primary chết, replica lên thay tự động

Dựng cụm Redis có nhân bản:

aws elasticache create-replication-group \
  --replication-group-id cache-ung-dung \
  --replication-group-description "Tang cache co nhan ban" \
  --engine redis --cache-node-type cache.r7g.large \
  --num-node-groups 1 --replicas-per-node-group 2 \
  --automatic-failover-enabled --multi-az-enabled \
  --at-rest-encryption-enabled --transit-encryption-enabled

⚠ Hai cờ này phải đi cùng nhau: | Cờ | Việc | |---|---| | --automatic-failover-enabled | replica tự lên thay primary | | --multi-az-enabled | replica đặt ở AZ khác |

Chỉ bật automatic-failover mà không Multi-AZ
    → replica cùng AZ với primary
        ↓
    AZ hỏng = mất cả hai

Ba lợi ích của Redis ngoài yêu cầu của đề: | Lợi ích | Chi tiết | |---|---| | Bền vững | snapshot và AOF | | Cấu trúc dữ liệu phong phú | list, set, sorted set, hash | | Pub/Sub và Streams | |

⚠ Đề nói "in-memory cache" tại chỗ — nhiều khả năng là Redis hoặc Memcached:

Ứng dụng cũ dùng Redis  → ElastiCache for Redis, không đổi mã
Ứng dụng cũ dùng Memcached → ElastiCache for Memcached
        ↓
    Nhưng yêu cầu HA và nhân bản
    → buộc phải là Redis

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

• **B. ElastiCache Memcached — đây là phương án gần nhất vì cũng là cache trong bộ nhớ, nhưng Memcached không có nhân bản và không có failover. Nó chỉ phân mảnh dữ liệu qua nhiều node độc lập.
• **C. RDS Multi-AZ — RDS là CSDL quan hệ trên đĩa, không phải cache trong bộ nhớ; nó thay thế tầng CSDL chứ không thay thế tầng cache.
• **D. DynamoDB — CSDL NoSQL bền vững, không phải cache. (DAX mới là cache của DynamoDB, và chỉ dùng cho DynamoDB.)

Ghi nhớ

⚠ Redis vs Memcached — bảng phải thuộc: | Tiêu chí | Redis | Memcached | |---|---|---| | Nhân bản | ✅ | ❌ | | Multi-AZ failover | ✅ | ❌ | | Bền vững (snapshot) | ✅ | ❌ | | Cấu trúc dữ liệu | phong phú | chỉ chuỗi | | Pub/Sub, Streams | ✅ | ❌ | | Đa luồng thuần | có I/O threads | ✅ | | Phân mảnh đơn giản | cluster mode | ✅ |

⚠ Quy tắc chọn nhanh:

Cần HA, bền, hoặc cấu trúc dữ liệu → Redis
Chỉ cache tạm, mất cũng không sao,
cần đa luồng tối đa               → Memcached
        ↓
    Trong đề thi, câu hỏi có "replication" hay
    "high availability" thì LUÔN là Redis

Từ khoá nhận diện:

"caching layer with HA and replication" → ElastiCache Redis "simple cache, multi-threaded, scale out" → Memcached "cache for DynamoDB, minimal code change" → DAX "cache API responses" → API Gateway cache

Ba chế độ của ElastiCache Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, tới 5 replica | | Cluster mode enabled | nhiều shard, phân mảnh dữ liệu | | Serverless | tự mở rộng, không chọn node |

⚠ ElastiCache Serverless đáng biết:

aws elasticache create-serverless-cache \
  --serverless-cache-name cache-tu-dong \
  --engine redis

Không chọn cỡ node, không chọn số replica
    → tự mở rộng theo tải
    → Multi-AZ mặc định
        ↓
    Đắt hơn khi tải ổn định, rẻ hơn khi thất thường

Ba mẫu cache thường dùng: | Mẫu | Chi tiết | |---|---| | Lazy loading (cache-aside) | đọc miss thì nạp từ CSDL | | Write-through | ghi cache cùng lúc với CSDL | | TTL | luôn đặt hạn cho khoá |

⚠ Luôn đặt TTL kể cả với write-through:

Không có TTL
    → khoá lỗi thời nằm mãi, bộ nhớ đầy dần
        ↓
    TTL là lưới an toàn cho mọi lỗi vô hiệu hoá cache

Ba lưu ý về failover: | Lưu ý | Chi tiết | |---|---| | Thường 15-30 giây | | | Dùng primary endpoint, không dùng IP node | | | Ứng dụng phải biết thử lại | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Đặt trong subnet riêng tư | | | Bật mã hoá at rest và in transit | | | Bật Redis AUTH hoặc RBAC | |

aws elasticache create-user --user-id ung-dung \
  --user-name ung-dung --engine redis \
  --access-string "on ~app:* +@read +@write" \
  --authentication-mode Type=password,Passwords=<mat-khau>

Ba lưu ý về kích thước: | Lưu ý | Chi tiết | |---|---| | Chừa ~25% bộ nhớ cho overhead | | | reserved-memory-percent cho snapshot | | | Bộ nhớ đầy = bắt đầu đuổi khoá | |

⚠ Chính sách đuổi khoá quyết định hành vi khi đầy: | Chính sách | Hành vi | |---|---| | volatile-lru | đuổi khoá CÓ TTL, ít dùng nhất | | allkeys-lru | đuổi mọi khoá, ít dùng nhất | | noeviction | từ chối ghi mới — ứng dụng lỗi |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | tỷ lệ trúng cache | | Evictions | tăng = bộ nhớ không đủ | | DatabaseMemoryUsagePercentage | |

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Lưu vào S3 do AWS quản lý | | | Chụp từ replica để không ảnh hưởng primary | | | Khôi phục vào cụm mới | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kích hoạt failover thử | | | Kiểm tra dữ liệu còn nguyên | | | Theo dõi Evictions | |

aws elasticache test-failover \
  --replication-group-id cache-ung-dung \
  --node-group-id 0001

Và một lời khuyên: hãy bật --multi-az-enabled cùng lúc với --automatic-failover-enabled. Bật riêng cờ failover cho bạn một replica sẵn sàng tiếp quản nhưng nằm cùng vùng sẵn sàng với primary — nó bảo vệ khỏi hỏng một node, chứ không bảo vệ khỏi đúng thứ mà kiến trúc sẵn sàng cao được dựng ra để chống.