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

Đáp án

D — Dùng AWS Config để theo dõi thay đổi cấu hình và AWS CloudTrail để ghi lịch sử các lời gọi API.

Vì sao đúng

Đề nêu hai nhu cầu tách bạch, mỗi cái có một dịch vụ chuyên trách: | Nhu cầu | Dịch vụ | |---|---| | Theo dõi thay đổi CẤU HÌNH | AWS Config | | Ghi lịch sử LỜI GỌI API | AWS CloudTrail |

⚠ Câu ghi nhớ ngắn nhất:

CloudTrail: AI đã LÀM GÌ  (hành động)
Config:     tài nguyên ĐANG THẾ NÀO (trạng thái)

Cùng một sự việc, hai góc nhìn:

Ai đó mở bucket S3 ra công khai
        ↓
CloudTrail:  "vai trò trien-khai gọi PutBucketPolicy
              lúc 03:14 từ IP 198.51.100.7"
        ↓
Config:      "kho-du-lieu lúc 03:13: riêng tư
              kho-du-lieu lúc 03:15: CÔNG KHAI
              → vi phạm s3-bucket-public-read-prohibited"

Bật CloudTrail đúng cách:

aws cloudtrail create-trail --name duong-mon-chinh \
  --s3-bucket-name log-cloudtrail \
  --is-multi-region-trail --is-organization-trail \
  --enable-log-file-validation --kms-key-id <arn-khoa>
aws cloudtrail start-logging --name duong-mon-chinh

⚠ Ba tuỳ chọn không được bỏ: | Tuỳ chọn | Vì sao | |---|---| | --is-multi-region-trail | hoạt động đáng ngờ hay ở Region ít dùng | | --enable-log-file-validation | phát hiện log bị sửa | | --kms-key-id | log chứa thông tin nhạy cảm |

Bật Config:

aws configservice put-configuration-recorder \
  --configuration-recorder 'name=ghi-chinh,roleARN=<arn-role>,
    recordingGroup={allSupported=true,
                    includeGlobalResourceTypes=true}'

aws configservice put-delivery-channel \
  --delivery-channel 'name=kenh-chinh,
    s3BucketName=log-config,
    configSnapshotDeliveryProperties={deliveryFrequency=TwentyFour_Hours}'

aws configservice start-configuration-recorder \
  --configuration-recorder-name ghi-chinh

⚠ Config có tính năng ít người biết — timeline cấu hình:

aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup \
  --resource-id sg-abc --limit 10

Xem tài nguyên này đã trông như thế nào
tại BẤT KỲ thời điểm nào trong quá khứ
    → đúng thứ kiểm toán viên hỏi

Ba lợi ích khi có cả hai: | Lợi ích | Chi tiết | |---|---| | Trả lời được cả "ai" lẫn "cái gì đã đổi" | | | Đáp ứng yêu cầu tuân thủ | | | Dựng lại dòng thời gian sự cố | |

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

• **C. CloudTrail theo dõi cấu hình và Config ghi lời gọi API — đây là phương án gần nhất và dùng đúng hai dịch vụ, nhưng đảo ngược vai trò của chúng. Đây là bẫy hay gặp nhất về cặp này.
• **A. CloudTrail theo dõi cấu hình và CloudWatch ghi lời gọi API — sai cả hai vế; CloudWatch là giám sát chỉ số và log ứng dụng.
• **B. Config theo dõi cấu hình (đúng) và CloudWatch ghi lời gọi API (sai) — vế đầu đúng nhưng CloudWatch không phải kho kiểm toán API.

Ghi nhớ

⚠ Năm dịch vụ quan sát — bảng phải thuộc: | Dịch vụ | Trả lời | |---|---| | CloudTrail | "ai gọi API gì?" | | Config | "tài nguyên cấu hình ra sao, đổi gì?" | | CloudWatch | "hệ thống chạy thế nào?" | | EventBridge | "khi X xảy ra thì làm Y" | | X-Ray | "yêu cầu đi qua đâu, chậm ở đâu?" |

Từ khoá nhận diện:

"who made the API call, audit user activity" → CloudTrail "configuration history, compliance, drift" → Config "metrics, alarms, application logs" → CloudWatch "aggregate findings" → Security Hub

⚠ Ba loại sự kiện CloudTrail: | Loại | Mặc định | Ghi gì | |---|---|---| | Management | BẬT, miễn phí (một trail) | control plane | | Data | TẮT, có phí | s3:GetObject, lambda:Invoke | | Insights | TẮT, có phí | bất thường về tần suất |

"Ai đã ĐỌC object nào trong S3?"
    → management event KHÔNG ghi
    → phải bật data event
        ↓
    Bật cho bucket lớn sinh khối lượng log rất lớn
    → giới hạn theo tiền tố

Ba quy tắc Config nên bật ngay: | Quy tắc | Kiểm tra | |---|---| | s3-bucket-public-read-prohibited | | | restricted-ssh | cổng 22 mở ra Internet | | encrypted-volumes | | | root-account-mfa-enabled | |

⚠ Config rule tự khắc phục được:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "s3-bucket-public-read-prohibited",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-DisableS3BucketPublicReadWrite",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3}]'

Ba lưu ý về conformance pack: | Lưu ý | Chi tiết | |---|---| | Gói nhiều quy tắc theo một khung tuân thủ | | | Có sẵn cho PCI-DSS, HIPAA, CIS | | | Triển khai cho cả tổ chức | |

Ba lưu ý về aggregator: | Lưu ý | Chi tiết | |---|---| | Gom dữ liệu Config từ mọi tài khoản và Region | | | Truy vấn nâng cao bằng SQL | | | Cần thiết cho tổ chức nhiều tài khoản | |

SELECT accountId, resourceId, resourceType
WHERE resourceType = 'AWS::S3::Bucket'
  AND configuration.publicAccessBlockConfiguration.blockPublicAcls = false

Ba lưu ý về bảo vệ log: | Lưu ý | Chi tiết | |---|---| | Bucket log ở TÀI KHOẢN RIÊNG | | | Object Lock chế độ Compliance | | | MFA Delete | |

⚠ Việc đầu tiên kẻ tấn công làm là tắt log:

{"source": ["aws.cloudtrail"],
 "detail": {"eventName": ["StopLogging","DeleteTrail","UpdateTrail"]}}

Đặt EventBridge rule cho ba sự kiện này
    → cảnh báo ngay lập tức

Ba cách truy vấn CloudTrail: | Cách | Đặc điểm | |---|---| | Console Event history | chỉ 90 ngày, chỉ management | | CloudTrail Lake | SQL, giữ tới 10 năm | | Athena trên bucket log | rẻ nhất |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Trail đầu tiên (management) miễn phí | | | Data event tính theo sự kiện | có thể rất lớn | | Config tính theo mục cấu hình ghi nhận | |

⚠ Config ghi mọi loại tài nguyên có thể tốn bất ngờ:

allSupported=true trong môi trường thay đổi liên tục
    → mỗi lần ASG thay máy là nhiều bản ghi
        ↓
    Cân nhắc giới hạn loại tài nguyên cần theo dõi

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Gom phát hiện từ Config, GuardDuty, Inspector, Macie | | | Có tiêu chuẩn dựng sẵn | | | Một màn hình cho toàn tổ chức | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đổi một tài nguyên, xem Config ghi nhận | | | Tìm lời gọi tương ứng trong CloudTrail | | | Chạy validate-logs | |

aws cloudtrail validate-logs --trail-arn <arn> \
  --start-time 2026-08-01T00:00:00Z

Và một lời khuyên: hãy đặt cảnh báo EventBridge cho StopLogging và DeleteTrail trước khi làm bất cứ việc kiểm toán nào khác. Toàn bộ giá trị của CloudTrail nằm ở chỗ nó ghi lại những việc người ta không muốn bị ghi lại — và bước đầu tiên của bất kỳ ai muốn thế là tắt nó đi.

Đáp án

A — Tạo một AWS Transit Gateway và chia sẻ nó cho từng tài khoản bằng AWS Resource Access Manager (RAM).

Vì sao đúng

Đề nêu ba yêu cầu, và Transit Gateway là dịch vụ duy nhất đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Nhiều tài khoản, nhiều VPC | RAM chia sẻ TGW xuyên tài khoản | | Kiến trúc ĐƠN GIẢN | hình sao thay vì lưới đầy đủ | | Định tuyến BẮC CẦU | TGW hỗ trợ, VPC peering thì KHÔNG |

⚠ "Transitive routing" là từ khoá loại ngay VPC peering:

VPC peering KHÔNG bắc cầu
    A ↔ B, B ↔ C
    → A KHÔNG nói chuyện được với C
        ↓
Transit Gateway bắc cầu
    A, B, C đều gắn vào TGW
    → mọi cặp nói chuyện được

⚠ Và độ phức tạp là lý do thứ hai:

Full mesh peering với n VPC: n × (n-1) / 2 kết nối
        ↓
    10 VPC  → 45 kết nối peering
    20 VPC  → 190 kết nối
        ↓
Transit Gateway: n attachment, một bảng định tuyến
    → 10 VPC = 10 attachment

Dựng và chia sẻ:

aws ec2 create-transit-gateway \
  --description "TGW trung tam" \
  --options 'DefaultRouteTableAssociation=enable,
             DefaultRouteTablePropagation=enable,
             DnsSupport=enable,
             AutoAcceptSharedAttachments=enable'

aws ram create-resource-share \
  --name chia-se-tgw \
  --resource-arns <arn-tgw> \
  --principals o-abc123def4 \
  --allow-external-principals false

⚠ Chia sẻ cho ID TỔ CHỨC thay vì từng tài khoản:

--principals o-abc123def4
    → mọi tài khoản trong tổ chức dùng được
    → tài khoản mới tự động có
        ↓
    Liệt kê từng tài khoản = phải sửa mỗi lần thêm

Tài khoản thành viên tự gắn VPC của mình:

aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-abc \
  --vpc-id vpc-cua-toi \
  --subnet-ids subnet-a subnet-b

Thêm tuyến trong VPC:

aws ec2 create-route --route-table-id rtb-abc \
  --destination-cidr-block 10.0.0.0/8 \
  --transit-gateway-id tgw-abc

⚠ Bảng định tuyến của TGW cho phép phân tách môi trường:

Bảng "san-xuat": chỉ VPC sản xuất
Bảng "phat-trien": chỉ VPC phát triển
Bảng "dung-chung": mọi VPC tới được
        ↓
    Sản xuất và phát triển KHÔNG thấy nhau
    → phân tách ngay ở tầng định tuyến

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một điểm quản lý định tuyến | | | Thêm VPC mới chỉ cần một attachment | | | Nối được cả Direct Connect và VPN | |

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

• **B. VPC peering bắc cầu giữa từng cặp VPC — peering không bắc cầu, đây là giới hạn cơ bản của nó; và số kết nối tăng theo bình phương số VPC.
• **C. AWS Managed VPN giữa từng cặp VPC — đây là phương án gần nhất về mặt cũng tạo được kết nối, nhưng VPN dành cho nối tại chỗ với AWS, không phải nối VPC với VPC; nó chậm hơn, giới hạn băng thông, và cũng không bắc cầu.
• **D. Hình sao bằng AWS App Mesh — App Mesh là service mesh ở tầng ứng dụng (định tuyến lưu lượng giữa microservice), không phải giải pháp mạng ở tầng VPC.

Ghi nhớ

⚠ Ba cách nối VPC — bảng phải thuộc: | Cách | Bắc cầu | Quy mô | |---|---|---| | VPC peering | ❌ | 2-3 VPC | | Transit Gateway | ✅ | hàng nghìn | | PrivateLink | không áp dụng | một DỊCH VỤ, một chiều |

⚠ PrivateLink giải bài toán khác hẳn:

Peering / TGW: nối MẠNG với nhau
    → hai bên thấy dải IP của nhau
        ↓
PrivateLink: phơi bày MỘT DỊCH VỤ
    → bên tiêu thụ chỉ thấy một endpoint
    → CIDR chồng lấn cũng không sao

Từ khoá nhận diện:

"many VPCs, many accounts, transitive" → Transit Gateway + RAM "two VPCs, simple" → VPC peering "expose one service to other VPCs" → PrivateLink "overlapping CIDRs" → PrivateLink "share subnets across accounts" → RAM + VPC sharing

Ba thứ RAM chia sẻ được: | Tài nguyên | Việc | |---|---| | Transit Gateway | | | Subnet của VPC | nhiều tài khoản dùng chung một VPC | | Route 53 Resolver rule | | | License Manager configuration | |

⚠ VPC sharing là lựa chọn đáng cân nhắc bên cạnh TGW:

Chia sẻ SUBNET thay vì nối nhiều VPC
    → mọi tài khoản chạy máy trong CÙNG một VPC
        ↓
    Không cần TGW, không phí attachment
    → nhưng ít cô lập hơn

Ba loại attachment của TGW: | Loại | Nối với | |---|---| | VPC | | | VPN | tại chỗ qua Internet | | Direct Connect Gateway | tại chỗ qua đường riêng | | Peering (TGW-TGW) | Region khác |

⚠ TGW peering hỗ trợ bắc cầu, khác VPC peering:

TGW vùng A ↔ TGW vùng B
    → VPC ở vùng A tới được VPC ở vùng B
        ↓
    Nhưng tham chiếu security group KHÔNG hoạt động
    → phải dùng CIDR

Ba khoản chi phí của TGW: | Khoản | Giá tham khảo | |---|---| | Mỗi attachment mỗi giờ | ~0,05 USD | | Dữ liệu xử lý | ~0,02 USD/GB | | Không có phí cho chính TGW | |

⚠ Phí xử lý dữ liệu là khoản chính:

10 VPC × 0,05 USD/giờ ≈ 365 USD/tháng phí attachment
    → cộng phí dữ liệu
        ↓
    Lưu lượng lớn giữa hai VPC cụ thể
    → peering trực tiếp giữa chúng rẻ hơn

Ba lưu ý về bảng định tuyến TGW: | Lưu ý | Chi tiết | |---|---| | Association: attachment dùng bảng nào | | | Propagation: tuyến của attachment vào bảng nào | | | Tách hai khái niệm này là chìa khoá phân tách | |

aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id tgw-abc

aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id tgw-rtb-sanxuat \
  --transit-gateway-attachment-id tgw-attach-abc

⚠ Mẫu kiến trúc phổ biến — VPC kiểm tra tập trung:

Mọi VPC → TGW → VPC kiểm tra (tường lửa)
    → rồi mới ra Internet hoặc sang VPC khác
        ↓
    Một chỗ áp chính sách bảo mật cho tất cả

Ba lưu ý về CIDR: | Lưu ý | Chi tiết | |---|---| | CIDR KHÔNG được chồng lấn | | | Lập kế hoạch dải IP toàn tổ chức | | | AWS IPAM quản lý tập trung | |

Ba lưu ý về hạn ngạch: | Hạn ngạch | Mặc định | |---|---| | Attachment mỗi TGW | 5.000 | | Băng thông mỗi attachment | ~50 Gbps | | Tuyến mỗi bảng | 10.000 |

Ba lưu ý về gỡ lỗi: | Công cụ | Việc | |---|---| | Reachability Analyzer | chỉ ra chặn ở đâu | | TGW Flow Logs | thấy lưu lượng qua TGW | | search-transit-gateway-routes | kiểm tra tuyến |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ping giữa hai VPC khác tài khoản | | | Kiểm tra tuyến trong bảng TGW | | | Xác nhận resource share đã được chấp nhận | |

aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-abc \
  --filters Name=state,Values=active

Và một lời khuyên: hãy chia sẻ Transit Gateway cho ID tổ chức chứ đừng liệt kê từng tài khoản. Danh sách tài khoản là thứ luôn lỗi thời trong một tổ chức đang phát triển, và tài khoản mới không kết nối được sẽ được phát hiện bởi đội đang cố triển khai chứ không phải bởi đội mạng.

Đáp án

C — Tạo một endpoint API Gateway cho hàm Lambda và cung cấp endpoint đó cho bên thứ ba làm webhook.

Vì sao đúng

Đề nêu hai yêu cầu, và API Gateway là cách trực tiếp nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Phơi bày Lambda cho bên thứ ba gọi qua HTTP | API Gateway cho endpoint HTTPS công khai | | ÍT PHỨC TẠP NHẤT | một tài nguyên, không có gì phải quản lý |

⚠ Webhook nghĩa là bên kia gửi HTTP POST — họ cần một URL:

Webhook = "khi có sự kiện, tôi POST tới URL của bạn"
        ↓
    Bên thứ ba chỉ biết nói HTTP
    → phải cho họ một URL HTTPS
        ↓
    ARN của SNS hay SQS KHÔNG phải URL họ gọi được

Dựng bằng SAM:

Resources:
  HamWebhook:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      Handler: app.handler
      Events:
        Webhook:
          Type: HttpApi
          Properties:
            Path: /webhook/bai-hat
            Method: POST

⚠ Xác thực webhook là việc bắt buộc:

Endpoint công khai = ai cũng POST được
    → phải kiểm chứng yêu cầu đến từ bên thứ ba thật
        ↓
    Ba cách: chữ ký HMAC, API key, mTLS

import hmac, hashlib, os

def kiem_chu_ky(than, chu_ky_nhan):
    bi_mat = os.environ['BI_MAT_WEBHOOK'].encode()
    tinh = hmac.new(bi_mat, than.encode(), hashlib.sha256).hexdigest()
    return hmac.compare_digest(tinh, chu_ky_nhan)

def handler(su_kien, ngu_canh):
    if not kiem_chu_ky(su_kien['body'],
                       su_kien['headers'].get('x-signature','')):
        return {'statusCode': 401}
    xu_ly(su_kien['body'])
    return {'statusCode': 200}

⚠ Dùng hmac.compare_digest, không dùng == — so sánh thường bị tấn công theo thời gian.

Mẫu bền hơn cho webhook — trả lời ngay, xử lý sau:

API Gateway → Lambda mỏng → SQS
        ↓
    Trả 200 trong vài chục mili giây
        ↓
    Lambda thứ hai đọc SQS và xử lý thật

Phần lớn nhà cung cấp webhook timeout sau 3-10 giây
    → xử lý nặng ngay trong request là rủi ro
        ↓
    Nhận và xác nhận nhanh, xử lý bất đồng bộ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | HTTPS và chứng chỉ do AWS lo | | | Có throttling và WAF gắn được | | | Không có máy chủ nào phải quản lý | |

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

• **A. Dùng Network Load Balancer phân phối tới Lambda — đây là phương án gần nhất về mặt cũng cho một endpoint mạng, nhưng NLB không có Lambda làm target; chỉ ALB mới gọi được Lambda. Và dù dùng ALB thì cũng phức tạp hơn API Gateway cho một webhook.
• **B. Tạo SNS topic và cho bên thứ ba ARN của topic — bên thứ ba gửi HTTP POST, họ không gọi được sns:Publish bằng ARN mà không có credential AWS.
• **D. Tạo SQS queue và cho ARN của hàng đợi — cùng lý do: ARN không phải endpoint HTTP.

Ghi nhớ

⚠ Ba cách phơi bày Lambda ra HTTP — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | API Gateway | đầy đủ: authorizer, throttling, WAF, stage | | Lambda Function URL | đơn giản nhất, miễn phí, ít tính năng | | Application Load Balancer | khi đã có ALB sẵn |

⚠ Lambda Function URL là lựa chọn còn đơn giản hơn — nhưng không có trong đề:

aws lambda create-function-url-config \
  --function-name ham-webhook --auth-type NONE

Cho ngay một URL HTTPS
    → không có API Gateway ở giữa
        ↓
    Nhưng: không throttling, không WAF trực tiếp,
    không stage, không authorizer

Từ khoá nhận diện:

"expose Lambda via HTTP, least complexity" → API Gateway (hoặc Function URL) "webhook from third party" → endpoint HTTPS "fan-out to multiple subscribers" → SNS "buffer and decouple" → SQS

⚠ NLB vs ALB với Lambda — nhớ kỹ: | Load balancer | Target Lambda | |---|---| | ALB | ✅ có | | NLB | ❌ KHÔNG |

Ba cách xác thực webhook: | Cách | Chi tiết | |---|---| | Chữ ký HMAC trong header | phổ biến nhất | | API key qua usage plan | REST API | | mTLS | chặt nhất, bên kia phải hỗ trợ |

⚠ mTLS cấu hình được trên custom domain của API Gateway:

aws apigatewayv2 create-domain-name \
  --domain-name webhook.vidu.com \
  --domain-name-configurations CertificateArn=<arn> \
  --mutual-tls-authentication \
    TruststoreUri=s3://kho-chung-chi/ca.pem

Ba lưu ý về idempotency: | Lưu ý | Chi tiết | |---|---| | Nhà cung cấp thường gửi lại khi không nhận 200 | | | Cùng sự kiện có thể tới nhiều lần | | | Lưu ID sự kiện để khử trùng | |

bang.put_item(
    Item={'maSuKien': ma, 'thoiDiem': int(time.time())},
    ConditionExpression='attribute_not_exists(maSuKien)')

Ba lưu ý về throttling: | Lưu ý | Chi tiết | |---|---| | Đặt rate và burst limit ở stage | | | Bảo vệ backend khỏi đợt sự kiện lớn | | | Reserved concurrency cho Lambda | |

Ba lưu ý về timeout: | Giới hạn | Giá trị | |---|---| | API Gateway | 29 giây | | Lambda | 15 phút | | Webhook của bên thứ ba | thường 3-10 giây |

⚠ Giới hạn chặt nhất là của bên kia, không phải của bạn:

Lambda chạy 20 giây (trong giới hạn API Gateway)
    → nhưng nhà cung cấp timeout ở 5 giây
        ↓
    Họ coi là thất bại và gửi lại
    → bạn xử lý cùng sự kiện nhiều lần

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | 4XXError | chữ ký sai, đường dẫn sai | | 5XXError | Lambda lỗi | | Count | có nhận được webhook không |

⚠ Đặt cảnh báo cho Count bằng 0 cũng quan trọng:

Webhook ngừng tới hoàn toàn
    → không có lỗi nào, chỉ là im lặng
        ↓
    Cảnh báo khi không có yêu cầu nào trong X giờ

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bí mật webhook lưu ở Secrets Manager | | | Gắn WAF nếu bị dò quét | | | Giới hạn IP nguồn nếu nhà cung cấp công bố dải | |

Ba lưu ý về REST API vs HTTP API: | Tiêu chí | HTTP API | REST API | |---|---|---| | Giá | rẻ hơn ~70% | | | API key / usage plan | ❌ | ✅ | | WAF gắn trực tiếp | ❌ | ✅ | | Độ trễ | thấp hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl thử endpoint | | | Gửi chữ ký sai | phải 401 | | Xem log Lambda có nhận đúng payload | |

curl -X POST https://abc.execute-api.ap-southeast-1.amazonaws.com/webhook/bai-hat \
  -H "Content-Type: application/json" \
  -H "x-signature: <chu-ky>" \
  -d '{"maBaiHat":"12345"}'

Và một lời khuyên: hãy trả 200 ngay rồi xử lý bất đồng bộ qua SQS. Nhà cung cấp webhook thường timeout sau vài giây và gửi lại khi không nhận được xác nhận, nên xử lý nặng ngay trong request sẽ tạo ra đúng thứ bạn không muốn: cùng một sự kiện được xử lý nhiều lần vì lần đầu quá chậm.

Đáp án

B — Chụp snapshot của RDS instance, tạo một bản sao snapshot ĐÃ MÃ HOÁ, rồi khôi phục instance từ snapshot mã hoá đó.

Vì sao đúng

Đề nêu một ràng buộc quyết định: không bật được mã hoá cho RDS instance đang chạy.

⚠ Đây là giới hạn cứng của RDS:

Mã hoá at rest phải quyết định LÚC TẠO instance
    → không có API nào bật cho instance đã có
        ↓
    Con đường duy nhất:
    snapshot → chép có mã hoá → khôi phục

Ba bước:

# 1. Snapshot instance chưa mã hoá
aws rds create-db-snapshot \
  --db-instance-identifier csdl-ung-dung \
  --db-snapshot-identifier anh-chup-truoc-ma-hoa

# 2. Chép snapshot, BẬT mã hoá ở bước này
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier anh-chup-truoc-ma-hoa \
  --target-db-snapshot-identifier anh-chup-da-ma-hoa \
  --kms-key-id <arn-khoa> --copy-tags

# 3. Khôi phục instance mới từ snapshot mã hoá
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier csdl-ung-dung-moi \
  --db-snapshot-identifier anh-chup-da-ma-hoa \
  --db-instance-class db.r6g.large --multi-az

⚠ Bước 2 là chỗ mã hoá được "thêm vào" — không thể ở bước 1 hay bước 3.

Điều này thoả mãn cả "dữ liệu cũ" lẫn "dữ liệu mới":

Snapshot chứa TOÀN BỘ dữ liệu hiện có
    → khôi phục ra instance mã hoá
        ↓
    Dữ liệu cũ: đã nằm trong volume mã hoá
    Dữ liệu mới: ghi vào chính volume đó

⚠ Có thời gian ngừng dịch vụ — phải lập kế hoạch:

Instance mới có ENDPOINT KHÁC
    → ứng dụng phải đổi chuỗi kết nối
        ↓
    Giảm thiểu: dùng Route 53 CNAME trỏ tới endpoint
    → đổi CNAME thay vì đổi cấu hình ứng dụng

Ba việc phải làm lại trên instance mới: | Việc | Chi tiết | |---|---| | Kiểm tra parameter group | | | Kiểm tra security group | | | Tạo lại read replica nếu có | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Toàn bộ dữ liệu cũ và mới đều mã hoá | | | Snapshot sau này cũng tự mã hoá | | | Read replica của nó cũng mã hoá | |

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

• **A. Tạo read replica có mã hoá rồi promote lên master — đây là phương án gần nhất và nghe rất hợp lý, nhưng không tạo được read replica mã hoá từ instance CHƯA mã hoá. RDS yêu cầu replica cùng trạng thái mã hoá với nguồn.
• **D. Bật mã hoá bằng API rồi chụp snapshot — không có API nào bật mã hoá cho instance đã có; đây là thao tác không tồn tại.
• **C. Tạo cụm ElastiCache và mã hoá qua cache node — ElastiCache là bộ nhớ đệm, hoàn toàn không liên quan tới mã hoá dữ liệu của RDS.

Ghi nhớ

⚠ Bốn quy tắc mã hoá RDS phải thuộc: | Quy tắc | Chi tiết | |---|---| | Chỉ bật được LÚC TẠO | | | Không tắt được sau khi bật | | | Read replica phải cùng trạng thái mã hoá với nguồn | | | Snapshot của instance mã hoá cũng mã hoá | |

⚠ Cách duy nhất để đổi trạng thái mã hoá:

Chưa mã hoá → mã hoá:
    snapshot → copy có KMS key → restore
        ↓
Mã hoá → chưa mã hoá:
    KHÔNG có cách nào trực tiếp
    → phải dump và nạp lại bằng công cụ CSDL

Từ khoá nhận diện:

"encrypt existing unencrypted RDS" → snapshot, copy encrypted, restore "encrypt existing EBS volume" → snapshot, copy encrypted, create volume "encrypt existing S3 objects" → copy object hoặc S3 Batch Operations "encrypt in transit" → SSL/TLS, rds.force_ssl

⚠ EBS theo đúng mẫu này — nhớ chung một lần:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region ap-southeast-1 --encrypted --kms-key-id <arn>

Ba lưu ý về giảm thời gian ngừng: | Cách | Chi tiết | |---|---| | Dùng Route 53 CNAME cho endpoint | | | Chọn cửa sổ ít lưu lượng nhất | | | Chuẩn bị trước instance mới rồi mới cắt | |

⚠ Mẫu giảm thời gian ngừng bằng DMS:

1. Khôi phục instance mã hoá từ snapshot (mất thời gian)
2. Dùng DMS CDC đồng bộ thay đổi từ instance cũ sang mới
3. Cắt chuyển khi độ trễ về 0
        ↓
    Thời gian ngừng chỉ vài phút thay vì cả giờ

Ba lưu ý về khoá KMS: | Lưu ý | Chi tiết | |---|---| | AWS managed key miễn phí nhưng ít kiểm soát | | | Customer managed key ~1 USD/tháng, kiểm soát đầy đủ | | | Xoá khoá = mất dữ liệu vĩnh viễn | |

⚠ Bảo vệ khoá bằng key policy:

{"Effect": "Deny", "Principal": "*",
 "Action": ["kms:ScheduleKeyDeletion", "kms:DisableKey"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/QuanTriKhoa"}}}

Ba lưu ý về sao chép xuyên Region: | Lưu ý | Chi tiết | |---|---| | Cần khoá KMS ở Region đích | | | Khoá không dùng chung giữa Region | | | Chỉ định --kms-key-id của Region đích | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Mã hoá ảnh hưởng hiệu năng không đáng kể | | | Xử lý ở tầng lưu trữ, không tốn CPU của CSDL | | | Không có lý do hiệu năng để không mã hoá | |

Ba lưu ý về mã hoá khi truyền: | Lưu ý | Chi tiết | |---|---| | Khác hoàn toàn mã hoá at rest | | | Bật rds.force_ssl=1 trong parameter group | | | Client phải có RDS CA bundle | |

aws rds modify-db-parameter-group \
  --db-parameter-group-name nhom-tham-so \
  --parameters "ParameterName=rds.force_ssl,ParameterValue=1,
                ApplyMethod=pending-reboot"

⚠ Hai loại mã hoá thường bị gộp làm một:

At rest:    dữ liệu trên đĩa   → KMS
In transit: dữ liệu trên dây   → SSL/TLS
        ↓
    Cần CẢ HAI cho tuân thủ

Ba lưu ý về Transparent Data Encryption: | Lưu ý | Chi tiết | |---|---| | Oracle và SQL Server có TDE riêng | | | Là lớp mã hoá TRONG CSDL | | | Kết hợp được với mã hoá RDS | |

Ba lưu ý về kiểm tra tuân thủ: | Công cụ | Việc | |---|---| | Config rule rds-storage-encrypted | | | Security Hub tổng hợp | | | SCP chặn tạo RDS chưa mã hoá | |

{"Effect": "Deny", "Action": "rds:CreateDBInstance",
 "Resource": "*",
 "Condition": {"Bool": {"rds:StorageEncrypted": "false"}}}

⚠ SCP này ngăn chuyện phải làm lại bài tập này lần nữa.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra StorageEncrypted: true | | | So số dòng vài bảng trước và sau | | | Kiểm tra ứng dụng kết nối được | |

aws rds describe-db-instances --db-instance-identifier csdl-ung-dung-moi \
  --query "DBInstances[0].[StorageEncrypted,KmsKeyId]"

Và một lời khuyên: hãy đặt SCP chặn tạo RDS chưa mã hoá ngay sau khi hoàn tất việc chuyển đổi này. Quy trình snapshot–copy–restore tốn một cửa sổ ngừng dịch vụ và một buổi làm việc, và cách duy nhất để không phải làm lại là biến việc quên bật mã hoá thành điều bất khả thi.

Đáp án

C — Thiết lập VPC endpoint cho Amazon EKS và ECR để node giao tiếp được với control plane.

Vì sao đúng

Đề mô tả cụm EKS chỉ có private endpoint, node nằm trong subnet riêng tư, và node không tham gia được vào cụm.

⚠ Node cần gọi ra ngoài nhiều thứ, không chỉ API server:

Node khởi động và cần:
    1. Gọi API server EKS để đăng ký
    2. Kéo image từ ECR (kube-proxy, CNI, CoreDNS)
    3. Lấy image layer từ S3 (ECR lưu layer ở S3)
    4. Gọi STS để lấy token xác thực
    5. Gọi EC2 API để mô tả tài nguyên
        ↓
    Subnet riêng tư, không NAT, không endpoint
    → mọi lời gọi trên đều thất bại

Các endpoint cần tạo:

for dv in ecr.api ecr.dkr sts ec2 elasticloadbalancing; do
  aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
    --vpc-endpoint-type Interface \
    --service-name com.amazonaws.ap-southeast-1.$dv \
    --subnet-ids subnet-a subnet-b \
    --security-group-ids sg-endpoint \
    --private-dns-enabled
done

# S3 dùng Gateway endpoint — MIỄN PHÍ
aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-rieng-tu

⚠ Thiếu S3 endpoint là lỗi phổ biến nhất:

ECR chỉ giữ SIÊU DỮ LIỆU của image
    → các LAYER thật nằm trong S3
        ↓
    Có endpoint ECR mà thiếu S3
    → `docker pull` treo ở phần tải layer
    → node không bao giờ sẵn sàng

Security group của endpoint phải cho phép node vào:

aws ec2 authorize-security-group-ingress \
  --group-id sg-endpoint --protocol tcp --port 443 \
  --source-group sg-node

⚠ --private-dns-enabled là bắt buộc:

Không bật: node vẫn phân giải tên dịch vụ
           thành IP CÔNG KHAI
    → gói tin đi ra Internet → không có đường
        ↓
    Bật: tên dịch vụ phân giải thành IP của endpoint

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần NAT gateway | tiết kiệm phí xử lý dữ liệu | | Lưu lượng không rời khỏi mạng AWS | | | Endpoint policy giới hạn được thêm | |

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

⚠ Có một chi tiết trong đáp án cần nói rõ: node KHÔNG tới API server qua VPC endpoint.

Khi bật private endpoint access, EKS tạo
ENI XUYÊN TÀI KHOẢN trong chính subnet của bạn
    + một private hosted zone của Route 53
        ↓
    Node phân giải tên cụm thành IP riêng tư của ENI đó
    → đây KHÔNG phải VPC endpoint kiểu PrivateLink

Có tồn tại endpoint com.amazonaws.<vùng>.eks, nhưng nó dành cho EKS management API (CreateCluster, DescribeCluster), không phải cho Kubernetes API server của cụm.

Vậy thứ node thật sự THIẾU là:
    → ECR (api + dkr), S3, STS, EC2
    → hoặc đơn giản là một NAT gateway
        ↓
    Phương án C vẫn là đáp án đúng duy nhất
    vì nó là phương án duy nhất tạo endpoint

Nói rõ điều này vì khi gỡ lỗi thật, tìm nhầm chỗ sẽ mất rất nhiều thời gian: đừng đi tìm endpoint cho API server, hãy kiểm tra ECR và S3.

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

• **B. Chuyển node sang subnet công khai và sửa security group — đây là phương án gần nhất vì nó cũng khôi phục được kết nối ra ngoài, nhưng nó phá vỡ yêu cầu bảo mật mà đề nêu rõ: data plane phải nằm trong subnet riêng tư.
• **A. Tạo VPC peering để node tới control plane — control plane của EKS không nằm trong VPC của bạn; nó nằm trong tài khoản do AWS quản lý và đã được phơi bày qua ENI xuyên tài khoản. Không có VPC nào để peer.
• **D. Sửa IAM role thêm AmazonEKSClusterPolicy — policy này dành cho vai trò của CỤM, không phải vai trò của node. Node cần AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly và AmazonEKS_CNI_Policy.

Ghi nhớ

⚠ Ba chế độ endpoint của EKS — bảng phải thuộc: | Chế độ | Node trong VPC | Truy cập từ ngoài | |---|---|---| | Public only | qua Internet | ✅ | | Public + Private | qua ENI riêng tư | ✅ | | Private only | qua ENI riêng tư | ❌ phải qua VPN/DX |

⚠ Private only nghĩa là kubectl từ máy cá nhân cũng không vào được:

Bật private-only
    → phải dùng VPN, Direct Connect,
      hoặc một bastion trong VPC
        ↓
    Đây là hệ quả hay bị quên khi siết bảo mật

Ba IAM policy của node group: | Policy | Việc | |---|---| | AmazonEKSWorkerNodePolicy | đăng ký vào cụm | | AmazonEC2ContainerRegistryReadOnly | kéo image | | AmazonEKS_CNI_Policy | cấp IP cho pod |

Từ khoá nhận diện:

"private cluster, nodes cannot join" → thiếu VPC endpoint hoặc NAT "pod needs AWS permissions" → IRSA hoặc Pod Identity "cluster API from on-premises" → VPN/DX + private endpoint "image pull fails" → ECR + S3 endpoint

⚠ Hai loại VPC endpoint: | Loại | Dịch vụ | Phí | |---|---|---| | Gateway | S3, DynamoDB | MIỄN PHÍ | | Interface (PrivateLink) | hầu hết dịch vụ còn lại | ~0,01 USD/giờ + dữ liệu |

⚠ Luôn tạo S3 Gateway endpoint — nó miễn phí và giải quyết rất nhiều vấn đề.

Ba cách chẩn đoán node không join: | Bước | Lệnh | |---|---| | Xem log của kubelet | journalctl -u kubelet | | Thử phân giải tên cụm | nslookup <endpoint> | | Thử kéo image thủ công | docker pull |

aws eks describe-cluster --name cum-ung-dung \
  --query "cluster.resourcesVpcConfig"

Ba lưu ý về aws-auth: | Lưu ý | Chi tiết | |---|---| | Vai trò node phải có trong aws-auth ConfigMap | | | Managed node group tự thêm | | | Node tự quản lý phải thêm tay | |

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::123456789012:role/vai-tro-node
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

⚠ EKS Access Entries là cách mới thay aws-auth:

aws eks create-access-entry --cluster-name cum-ung-dung \
  --principal-arn <arn-vai-tro> --type EC2_LINUX

Quản lý bằng API thay vì sửa ConfigMap
    → sửa sai aws-auth có thể khoá luôn cả cụm

Ba lưu ý về chi phí endpoint: | Khoản | Chi tiết | |---|---| | Interface endpoint ~0,01 USD/giờ mỗi AZ | | | Cộng phí dữ liệu xử lý | | | Vẫn rẻ hơn NAT gateway ở lưu lượng lớn | |

⚠ So sánh với NAT gateway:

NAT gateway: 0,045 USD/giờ + 0,045 USD/GB
5 interface endpoint × 2 AZ: ~0,10 USD/giờ + 0,01 USD/GB
        ↓
    Lưu lượng lớn → endpoint rẻ hơn nhiều
    Lưu lượng nhỏ → NAT đơn giản hơn

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

Ba lưu ý về subnet: | Lưu ý | Chi tiết | |---|---| | Tag subnet cho load balancer | | | kubernetes.io/role/internal-elb=1 cho subnet riêng tư | | | Đủ IP trống cho pod | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | kubectl get nodes | node phải Ready | | Thử kéo image từ ECR trên node | | | Kiểm tra endpoint ở trạng thái available | |

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-abc \
  --query "VpcEndpoints[].[ServiceName,State,PrivateDnsEnabled]" \
  --output table

Và một lời khuyên: hãy tạo S3 Gateway endpoint ngay cả khi bạn nghĩ chỉ cần ECR. ECR lưu layer image trong S3, nên một cụm có đủ endpoint ECR mà thiếu S3 sẽ cho ra triệu chứng khó hiểu nhất: node đăng ký thành công rồi treo mãi ở bước kéo image, không có thông báo lỗi nào nói tới S3.

Đáp án

C và E — Chuyển CSDL PostgreSQL sang Amazon Aurora, và chuyển ứng dụng container sang AWS Fargate với Amazon ECS.

Vì sao đúng

Đề nêu hai mục tiêu — hiệu quả vận hành và hiệu năng — và hai lựa chọn này tấn công đúng hai tầng đang tự quản lý:

⚠ E — Fargate loại bỏ hẳn tầng máy chủ:

ECS trên EC2:  bạn quản lý instance
    → vá, đổi cỡ, theo dõi dung lượng cụm
        ↓
ECS trên Fargate: chỉ khai CPU và bộ nhớ mỗi task
    → không có instance nào tồn tại với bạn

Task definition Fargate:

{"family": "ung-dung-web",
 "requiresCompatibilities": ["FARGATE"],
 "networkMode": "awsvpc",
 "cpu": "1024", "memory": "2048",
 "executionRoleArn": "<arn-execution-role>",
 "taskRoleArn": "<arn-task-role>",
 "containerDefinitions": [{
   "name": "web",
   "image": "<id>.dkr.ecr.ap-southeast-1.amazonaws.com/web:1.4",
   "portMappings": [{"containerPort": 8080}],
   "logConfiguration": {
     "logDriver": "awslogs",
     "options": {"awslogs-group": "/ecs/ung-dung-web",
                 "awslogs-region": "ap-southeast-1",
                 "awslogs-stream-prefix": "web"}}}]}

⚠ C — Aurora cải thiện CẢ vận hành LẪN hiệu năng: | Khía cạnh | Aurora cho gì | |---|---| | Vận hành | vá tự động, sao lưu liên tục, failover tự động | | Hiệu năng | nhanh gấp ~3 lần PostgreSQL tiêu chuẩn | | Độ bền | 6 bản sao trên 3 AZ | | Mở rộng đọc | tới 15 Aurora Replica, độ trễ mili giây |

Chuyển sang Aurora:

aws rds create-db-cluster \
  --db-cluster-identifier cum-ung-dung \
  --engine aurora-postgresql \
  --engine-version 16.1 \
  --master-username quantri --manage-master-user-password \
  --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=32

aws rds create-db-instance \
  --db-instance-identifier ghi-1 \
  --db-cluster-identifier cum-ung-dung \
  --db-instance-class db.serverless --engine aurora-postgresql

⚠ Aurora tương thích PostgreSQL — không đổi mã ứng dụng:

Cùng driver, cùng SQL, cùng công cụ
    → chỉ đổi chuỗi kết nối

Ba lợi ích khi làm cả hai: | Lợi ích | Chi tiết | |---|---| | Không còn máy chủ nào phải vá | | | Cả hai tầng tự mở rộng | | | Aurora tự failover, ECS tự thay task hỏng | |

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

• **A. Đặt ElastiCache giữa ứng dụng và CSDL — đây là phương án gần nhất vì có cải thiện hiệu năng thật, nhưng nó thêm một dịch vụ phải quản lý và đòi sửa mã ứng dụng để viết logic cache; nó không cải thiện "operational efficiency".
• **D. Thêm CloudFront cho nội dung ứng dụng — hữu ích cho nội dung tĩnh phục vụ người dùng phân tán, nhưng đề không nói tới người dùng toàn cầu hay nội dung tĩnh; nó không đụng tới hai tầng đang tự quản lý.
• **B. Gộp ứng dụng vào cùng EC2 với CSDL — đi ngược mọi thực hành tốt: hai tầng tranh tài nguyên, mở rộng không độc lập được, và một sự cố ảnh hưởng cả hai.

Ghi nhớ

⚠ Ba mức trách nhiệm khi chạy container — bảng phải thuộc: | Cách | Bạn quản lý | |---|---| | EC2 tự cài Docker | máy + Docker + điều phối | | ECS/EKS trên EC2 | máy | | ECS/EKS trên Fargate | chỉ container | | App Runner | chỉ mã nguồn |

Từ khoá nhận diện:

"reduce operational overhead, containers" → Fargate "managed PostgreSQL/MySQL, better performance" → Aurora "cache to reduce database load" → ElastiCache "global static content" → CloudFront

⚠ ECS vs EKS — chọn theo bối cảnh: | Tiêu chí | ECS | EKS | |---|---|---| | Độ phức tạp | thấp hơn | cao hơn | | Chuẩn Kubernetes | ❌ | ✅ | | Phí control plane | không | ~0,10 USD/giờ | | Khi nào | chỉ chạy trên AWS | đã có kỹ năng k8s, đa đám mây |

Ba lưu ý về Fargate: | Lưu ý | Chi tiết | |---|---| | CPU và bộ nhớ theo tổ hợp cố định | | | Không SSH vào được | dùng ECS Exec | | Đắt hơn EC2 mỗi vCPU nhưng không lãng phí | |

⚠ ECS Exec thay cho SSH:

aws ecs execute-command --cluster cum-ung-dung \
  --task <id-task> --container web \
  --interactive --command "/bin/sh"

Ba lưu ý về Fargate Spot: | Lưu ý | Chi tiết | |---|---| | Giảm tới 70% | | | Có thể bị lấy lại, báo trước 2 phút | | | Trộn với On-Demand bằng capacity provider | |

{"capacityProviderStrategy": [
  {"capacityProvider": "FARGATE", "base": 2, "weight": 1},
  {"capacityProvider": "FARGATE_SPOT", "weight": 4}]}

Ba lợi thế kiến trúc của Aurora: | Lợi thế | Chi tiết | |---|---| | Tách tính toán và lưu trữ | | | Lưu trữ tự mở rộng tới 128 TB | | | Failover thường dưới 30 giây | |

⚠ Aurora Multi-AZ khác RDS Multi-AZ:

RDS Multi-AZ: standby KHÔNG phục vụ đọc
        ↓
Aurora: mọi replica đều ĐỌC ĐƯỢC
    → vừa HA vừa mở rộng đọc

Ba lưu ý về Aurora Serverless v2: | Lưu ý | Chi tiết | |---|---| | Mở rộng theo bước 0,5 ACU, trong vài giây | | | Trộn được với instance provisioned | | | Hợp tải thất thường | |

Ba lưu ý về chuyển đổi CSDL: | Cách | Gián đoạn | |---|---| | pg_dump / pg_restore | có | | DMS full-load + CDC | rất ít | | Snapshot restore (nếu đã ở RDS) | có |

Ba lưu ý về ALB cho ECS: | Lưu ý | Chi tiết | |---|---| | Dùng target type ip với awsvpc | | | Health check quyết định task nào nhận lưu lượng | | | Deregistration delay đủ dài cho request đang chạy | |

Ba lưu ý về mở rộng ECS: | Cách | Chi tiết | |---|---| | Target tracking theo CPU hoặc bộ nhớ | | | Hoặc ALBRequestCountPerTarget | | | Đặt min task tối thiểu 2, trải nhiều AZ | |

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/cum-ung-dung/dich-vu-web \
  --policy-name theo-cpu --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{"TargetValue":60,
    "PredefinedMetricSpecification":
      {"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

Ba lưu ý về bảo mật container: | Lưu ý | Chi tiết | |---|---| | Task role riêng cho từng dịch vụ | | | Quét image bằng ECR scanning | | | Không chạy container bằng root | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Task chạy được, health check xanh | | | Ứng dụng kết nối Aurora | | | Đo độ trễ truy vấn trước và sau | |

Và một lời khuyên: hãy chuyển CSDL trước, container sau. Chuyển cả hai cùng lúc nghĩa là khi có vấn đề về hiệu năng bạn sẽ không biết nó đến từ đâu — còn chuyển tuần tự thì mỗi bước đều có một đường cơ sở để so sánh.

Đáp án

A — Tạo một Application Load Balancer, đặt tầng web sau nó, và bật AWS WAF.

Vì sao đúng

Đề nêu một lỗ hổng cụ thể — cross-site scripting (XSS) — và WAF là công cụ chuyên trị.

⚠ Nhưng chi tiết quyết định là LOẠI load balancer:

AWS WAF gắn được vào:
    → CloudFront
    → Application Load Balancer
    → API Gateway
    → AppSync
    → Cognito user pool
    → App Runner, Verified Access
        ↓
    KHÔNG gắn được vào:
    → Network Load Balancer
    → Classic Load Balancer

Đây chính là lý do B và C sai.

Vì sao chỉ ALB được:

WAF kiểm tra NỘI DUNG HTTP
    → header, query string, thân request, cookie
        ↓
    NLB hoạt động ở tầng 4 — chỉ thấy TCP
    → không có gì để kiểm tra

Tạo web ACL với quy tắc chống XSS:

aws wafv2 create-web-acl --name acl-ung-dung-web \
  --scope REGIONAL --region ap-southeast-1 \
  --default-action Allow={} \
  --rules '[{
    "Name": "ChanXSS",
    "Priority": 1,
    "Statement": {"ManagedRuleGroupStatement": {
      "VendorName": "AWS",
      "Name": "AWSManagedRulesCommonRuleSet"}},
    "OverrideAction": {"None": {}},
    "VisibilityConfig": {"SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true, "MetricName": "ChanXSS"}}]' \
  --visibility-config 'SampledRequestsEnabled=true,
    CloudWatchMetricsEnabled=true,MetricName=aclUngDungWeb'

Gắn vào ALB:

aws wafv2 associate-web-acl \
  --web-acl-arn <arn-web-acl> \
  --resource-arn <arn-alb>

⚠ AWSManagedRulesCommonRuleSet đã có sẵn quy tắc XSS — không cần tự viết.

Quy tắc XSS tự viết nếu cần chi tiết hơn:

{"Name": "XssTuyChinh", "Priority": 2,
 "Statement": {"XssMatchStatement": {
   "FieldToMatch": {"Body": {}},
   "TextTransformations": [
     {"Priority": 0, "Type": "URL_DECODE"},
     {"Priority": 1, "Type": "HTML_ENTITY_DECODE"},
     {"Priority": 2, "Type": "LOWERCASE"}]}},
 "Action": {"Block": {}},
 "VisibilityConfig": {"SampledRequestsEnabled": true,
   "CloudWatchMetricsEnabled": true, "MetricName": "XssTuyChinh"}}

⚠ TextTransformations là phần quan trọng nhất:

Kẻ tấn công mã hoá payload để né bộ lọc
    → %3Cscript%3E thay vì <script>
    → &lt;script&gt;
        ↓
    Không giải mã trước khi so
    → bộ lọc bị vượt qua dễ dàng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn ở tầng trước, không chạm ứng dụng | | | Quy tắc quản lý được AWS cập nhật liên tục | | | Bảo vệ ngay, không cần sửa mã | |

⚠ Nhưng WAF là biện pháp giảm thiểu, không phải cách sửa:

WAF chặn payload đã biết
    → mua thời gian để sửa mã
        ↓
    Cách sửa thật: mã hoá đầu ra theo ngữ cảnh,
    Content-Security-Policy, dùng template engine
      tự escape

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

• **D. ALB + AWS Shield Standard — đây là phương án gần nhất vì dùng đúng loại load balancer, nhưng Shield chống DDoS ở tầng 3 và 4, hoàn toàn không kiểm tra nội dung HTTP nên không phát hiện XSS.
• **C. Network Load Balancer + WAF — WAF không gắn được vào NLB.
• **B. Classic Load Balancer + WAF — WAF không gắn được vào CLB; và CLB là dịch vụ cũ, không dùng cho thiết kế mới.

Ghi nhớ

⚠ Bốn dịch vụ bảo vệ AWS — bảng phải thuộc: | Dịch vụ | Chống gì | Tầng | |---|---|---| | WAF | SQL injection, XSS, bot, rate | 7 (HTTP) | | Shield Standard | DDoS | 3/4, miễn phí, tự bật | | Shield Advanced | DDoS lớn + đội hỗ trợ | 3/4/7 | | Network Firewall | lọc lưu lượng VPC | 3/4/7 |

⚠ Shield Standard đã BẬT SẴN cho mọi khách hàng, miễn phí — không phải bật gì.

Từ khoá nhận diện:

"XSS, SQL injection, OWASP" → WAF "DDoS protection" → Shield "WAF with load balancer" → phải là ALB "filter traffic between VPCs" → Network Firewall

⚠ Nơi gắn WAF quyết định hiệu quả:

Gắn vào CloudFront: chặn ở EDGE, gần kẻ tấn công nhất
    → yêu cầu độc hại không vào tới Region
        ↓
Gắn vào ALB: chặn ở Region
    → vẫn tốt, nhưng lưu lượng đã đi xa hơn

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

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

aws wafv2 update-web-acl --name acl-ung-dung-web \
  --scope REGIONAL --id <id> --lock-token <token> \
  --rules '[{...,"OverrideAction":{"Count":{}}}]' ...

Bật BLOCK ngay
    → quy tắc quản lý có thể chặn lưu lượng hợp lệ
    → ví dụ form cho phép nhập HTML
        ↓
    Chạy COUNT vài ngày, xem log, thêm ngoại lệ

Ba loại quy tắc tự viết: | Loại | Việc | |---|---| | Rate-based | chặn IP gửi quá nhiều | | Geo match | chặn theo quốc gia | | IP set | danh sách cho phép hoặc chặn |

Ba lưu ý về logging: | Lưu ý | Chi tiết | |---|---| | Log ra Firehose, S3 hoặc CloudWatch Logs | | | Che trường nhạy cảm | | | Athena truy vấn để phân tích | |

aws wafv2 put-logging-configuration --logging-configuration \
  'ResourceArn=<arn-web-acl>,
   LogDestinationConfigs=<arn-log-group>,
   RedactedFields=[{SingleHeader={Name=authorization}}]'

Ba lưu ý về chi phí WAF: | Khoản | Giá tham khảo | |---|---| | Web ACL | ~5 USD/tháng | | Mỗi quy tắc | ~1 USD/tháng | | Mỗi triệu request | ~0,60 USD |

Ba cách sửa XSS ở tầng mã nguồn: | Cách | Chi tiết | |---|---| | Mã hoá đầu ra theo ngữ cảnh | HTML, JS, URL khác nhau | | Content-Security-Policy | chặn script nội tuyến | | Template engine tự escape | |

⚠ CSP là lớp phòng thủ mạnh thứ hai sau mã hoá đầu ra:

Content-Security-Policy: default-src 'self';
    script-src 'self'; object-src 'none'
        ↓
    Script nội tuyến bị trình duyệt từ chối chạy
    → payload XSS có lọt qua cũng vô hại

Ba lưu ý về Firewall Manager: | Lưu ý | Chi tiết | |---|---| | Áp cùng web ACL cho nhiều tài khoản | | | Tự gắn cho ALB mới tạo | | | Cần Organizations và Config | |

Ba lưu ý về kiểm thử: | Việc | Cách | |---|---| | Gửi payload XSS thử | phải bị chặn | | Kiểm tra lưu lượng hợp lệ không bị chặn nhầm | | | Xem SampledRequests để hiểu quy tắc nào khớp | |

curl "https://ung-dung.vidu.com/tim?q=<script>alert(1)</script>"
# phải nhận 403

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xác nhận web ACL đã gắn vào ALB | | | Theo dõi metric BlockedRequests | | | Rà log tìm chặn nhầm | |

Và một lời khuyên: hãy coi WAF là thời gian mua được chứ không phải bản vá. Nó chặn những payload đã biết ngay hôm nay, nhưng lỗ hổng XSS vẫn nằm nguyên trong mã — và biến thể mã hoá tiếp theo có thể lọt qua trước khi ai đó kịp cập nhật quy tắc.

Đáp án

B — Chụp EBS snapshot của volume sản xuất, bật Fast Snapshot Restore (FSR) trên snapshot đó, khôi phục ra volume mới và gắn vào EC2 ở môi trường thử nghiệm.

Vì sao đúng

Đề nêu ba yêu cầu, và FSR giải quyết đúng chỗ nghẽn: | Yêu cầu | Cách đáp ứng | |---|---| | Sửa dữ liệu thử KHÔNG ảnh hưởng sản xuất | volume mới độc lập hoàn toàn | | Hiệu năng I/O CAO NGAY TỪ ĐẦU | FSR loại bỏ việc nạp lười | | Thời gian nhân bản NGẮN NHẤT | volume dùng được ngay, đủ tốc độ ngay |

⚠ Vấn đề mà FSR giải quyết — nạp lười:

Volume khôi phục từ snapshot dùng được NGAY
    → nhưng block chưa được nạp từ S3
        ↓
    Lần đọc đầu tiên vào mỗi block:
    → phải kéo từ S3 → chậm hơn nhiều lần
        ↓
    Với volume 1 TB, "làm nóng" hết có thể mất hàng giờ

Bật FSR:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones ap-southeast-1a ap-southeast-1b \
  --source-snapshot-ids snap-abc

Chờ trạng thái enabled rồi mới khôi phục:

aws ec2 describe-fast-snapshot-restores \
  --filters Name=snapshot-id,Values=snap-abc \
  --query "FastSnapshotRestores[].[AvailabilityZone,State]" --output table

⚠ FSR cần thời gian "tối ưu hoá" trước khi có tác dụng:

Trạng thái: enabling → optimizing → enabled
    → thời gian tối ưu ~60 phút mỗi TiB
        ↓
    Khôi phục lúc còn "optimizing"
    → vẫn bị nạp lười, không được lợi gì

Cách làm nóng thủ công (khi không dùng FSR):

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=1M \
  --iodepth=32 --ioengine=libaio --direct=1 \
  --name=lam-nong --numjobs=4

Đọc toàn bộ volume một lượt để kéo mọi block về
    → hiệu quả tương tự nhưng tốn thời gian và I/O

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Volume đạt hiệu năng đầy đủ ngay lập tức | | | Nhân bản được nhiều volume từ một snapshot | | | Không đụng gì tới volume sản xuất | |

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

• **A. Snapshot, tạo volume mới và khởi tạo (initialize) rồi khôi phục — đây là phương án gần nhất và mô tả đúng vấn đề nạp lười, nhưng thứ tự bị đảo lộn (khởi tạo trước khi khôi phục là vô nghĩa), và "khởi tạo thủ công" chính là cách chậm mà FSR sinh ra để thay thế.
• **D. Dùng EBS Multi-Attach rồi gắn chính volume sản xuất vào máy thử — vi phạm thẳng yêu cầu "sửa dữ liệu không được ảnh hưởng sản xuất"; và Multi-Attach chỉ trong một AZ, chỉ io1/io2, và cần hệ thống tệp cụm.
• **C. Khôi phục snapshot vào instance store — không khôi phục snapshot trực tiếp vào instance store được, và instance store mất dữ liệu khi máy dừng.

Ghi nhớ

⚠ Ba cách nhân bản dữ liệu EBS — bảng phải thuộc: | Cách | Tốc độ đạt hiệu năng đầy đủ | |---|---| | Snapshot → volume (mặc định) | chậm — nạp lười | | Snapshot + FSR → volume | ngay lập tức | | Snapshot + làm nóng thủ công | sau khi đọc hết |

Từ khoá nhận diện:

"clone data fast, consistent high I/O immediately" → Fast Snapshot Restore "share one volume across instances" → Multi-Attach (io1/io2, cùng AZ) "temporary scratch, highest IOPS" → instance store "cross-region copy" → copy-snapshot

⚠ FSR có phí và có hạn ngạch: | Điểm | Chi tiết | |---|---| | Phí | ~0,75 USD mỗi giờ mỗi snapshot mỗi AZ | | Hạn ngạch | 5 snapshot bật FSR mỗi Region | | Tính phí kể cả khi không khôi phục | |

Bật FSR rồi quên tắt
    → 0,75 × 24 × 30 ≈ 540 USD mỗi tháng mỗi AZ
        ↓
    Tắt ngay sau khi nhân bản xong

aws ec2 disable-fast-snapshot-restores \
  --availability-zones ap-southeast-1a \
  --source-snapshot-ids snap-abc

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Tăng dần — chỉ lưu block thay đổi | | | Lưu trong S3 do AWS quản lý | | | Khôi phục được vào AZ khác trong cùng Region | |

⚠ Nhất quán dữ liệu khi chụp snapshot:

Snapshot là ảnh chụp mức KHỐI
    → dữ liệu trong bộ đệm ứng dụng chưa ghi xuống
        ↓
    Với CSDL: đóng băng I/O hoặc dừng dịch vụ trước
    → hoặc dùng snapshot của chính RDS

Lệnh đóng băng hệ thống tệp trước khi chụp:

sudo fsfreeze -f /du-lieu
aws ec2 create-snapshot --volume-id vol-abc \
  --description "Anh chup nhat quan"
sudo fsfreeze -u /du-lieu

Ba lựa chọn thay thế cho việc nhân bản môi trường thử: | Cách | Chi tiết | |---|---| | Aurora cloning | copy-on-write, gần như tức thì | | RDS restore to point in time | | | AMI + launch | cả máy lẫn dữ liệu |

⚠ Aurora clone là ví dụ đáng biết vì nhanh hơn hẳn:

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cum-san-xuat \
  --db-cluster-identifier cum-thu-nghiem \
  --restore-type copy-on-write --use-latest-restorable-time

Không sao chép dữ liệu
    → chỉ chép block khi có bên ghi vào
        ↓
    Cụm vài TB nhân bản trong vài phút

Ba lưu ý về Multi-Attach: | Lưu ý | Chi tiết | |---|---| | Chỉ io1/io2 | | | Tối đa 16 instance, CÙNG một AZ | | | Cần hệ thống tệp cụm như GFS2 | |

⚠ Gắn volume vào hai máy với hệ thống tệp thường là hỏng dữ liệu:

ext4 hay XFS giả định chỉ MỘT máy ghi
    → hai máy ghi cùng lúc = hỏng hệ thống tệp
        ↓
    Multi-Attach chỉ dùng với ứng dụng biết phối hợp

Ba loại volume: | Loại | Dùng cho | |---|---| | gp3 | mặc định — IOPS đặt độc lập với dung lượng | | io2 Block Express | IOPS cao nhất, độ bền cao nhất | | st1 / sc1 | HDD, tuần tự, rẻ |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Instance cũng có trần băng thông EBS riêng | | | Bật EBS-optimized | mặc định trên máy đời mới | | Nút thắt có thể ở instance, không ở volume | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Volume tính theo GB CẤP PHÁT | | | Snapshot tính theo dữ liệu thật thay đổi | | | FSR tính theo giờ — nhớ tắt | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra trạng thái FSR là enabled | | | Đo IOPS ngay sau khi gắn volume | | | Xác nhận volume sản xuất không đổi | |

Và một lời khuyên: hãy tắt Fast Snapshot Restore ngay sau khi nhân bản xong. Nó tính phí theo giờ cho mỗi snapshot ở mỗi vùng sẵn sàng bất kể bạn có khôi phục hay không, và một cờ bật lúc gấp rồi quên mất sẽ lặng lẽ tốn hơn cả chính môi trường thử nghiệm.

Đáp án

D — Chuyển CSDL sang RDS for PostgreSQL Multi-AZ DB instance, dùng ElastiCache for Redis có replication group để quản lý session và cache đọc, và chuyển máy chủ ứng dụng vào Auto Scaling group trải ba AZ.

Vì sao đúng

Đề nêu ba vấn đề, và phương án này là phương án duy nhất giải cả ba đúng cách: | Vấn đề | Giải pháp | |---|---| | PostgreSQL chạy trên EC2 — điểm hỏng duy nhất | RDS Multi-AZ, failover tự động | | Máy chủ ứng dụng giữ session | Redis lưu session ngoài máy | | Cần co giãn và sẵn sàng cao trên 3 AZ | ASG trải 3 AZ |

⚠ Vì sao Redis chứ không phải Memcached — đây là chỗ phân biệt với phương án A: | Tiêu chí | Redis | Memcached | |---|---|---| | Bền vững dữ liệu | ✅ có snapshot, AOF | ❌ mất khi node restart | | Nhân bản và failover | ✅ replication group | ❌ không có | | Cấu trúc dữ liệu | list, set, sorted set, hash | chỉ chuỗi | | Đa luồng | từ Redis 6 có I/O threads | ✅ hoàn toàn |

Lưu session trong Memcached
    → node restart = MỌI NGƯỜI DÙNG BỊ ĐĂNG XUẤT
        ↓
    Redis replication group:
    → có bản sao, có failover, session sống sót

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

aws elasticache create-replication-group \
  --replication-group-id phien-ung-dung \
  --replication-group-description "Luu session va cache doc" \
  --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 \
  --snapshot-retention-limit 5

⚠ --multi-az-enabled và --automatic-failover-enabled phải đi cùng nhau — thiếu một là không có chuyển đổi tự động.

Chuyển CSDL sang RDS Multi-AZ:

aws rds create-db-instance \
  --db-instance-identifier csdl-ho-so \
  --engine postgres --engine-version 16.3 \
  --db-instance-class db.r6g.xlarge \
  --allocated-storage 500 --storage-type gp3 \
  --multi-az --storage-encrypted \
  --backup-retention-period 30 \
  --manage-master-user-password

⚠ RDS Multi-AZ: standby KHÔNG phục vụ đọc:

Multi-AZ = TÍNH SẴN SÀNG, không phải mở rộng đọc
    → standby chỉ ngồi chờ tiếp quản
        ↓
    Cần mở rộng đọc → thêm read replica
    → hoặc chính là lý do cần cache đọc bằng Redis

ASG trải ba AZ:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name asg-ho-so \
  --launch-template LaunchTemplateName=mau-ung-dung,Version='$Latest' \
  --min-size 3 --max-size 30 --desired-capacity 6 \
  --vpc-zone-identifier "subnet-a,subnet-b,subnet-c" \
  --target-group-arns <arn-tg> --health-check-type ELB \
  --health-check-grace-period 300

⚠ Đưa session ra ngoài là điều kiện để co giãn thật sự:

Session trong bộ nhớ máy
    → ASG thay máy = người dùng bị đăng xuất
    → phải bật sticky session
    → tải phân bổ không đều
        ↓
    Session ở Redis: máy nào phục vụ cũng được
    → co giãn tự do

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không còn điểm hỏng duy nhất nào | | | Cả ba tầng chịu được mất một AZ | | | Ứng dụng không trạng thái, mở rộng thoải mái | |

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

• **A. Aurora Single-AZ + Memcached — đây là phương án gần nhất và có Aurora vốn tốt hơn RDS về hiệu năng, nhưng sai hai chỗ nghiêm trọng: Single-AZ không sẵn sàng cao, và Memcached không bền nên session mất khi node restart.
• **B. Giữ PostgreSQL trên EC2 + Redis + ASG — hai vế sau đúng nhưng vế đầu để nguyên điểm hỏng duy nhất lớn nhất; đề nói rõ cần sẵn sàng cao trên cả ba AZ.
• **C. Chuyển sang DynamoDB — đổi từ CSDL quan hệ sang NoSQL là viết lại toàn bộ mô hình dữ liệu và truy vấn cho một ứng dụng hồ sơ y tế; đề không nói được phép làm vậy.

Ghi nhớ

⚠ Redis vs Memcached — bảng phải thuộc: | Tiêu chí | Redis | Memcached | |---|---|---| | Bền vững | ✅ | ❌ | | Nhân bản, failover | ✅ | ❌ | | Cấu trúc dữ liệu phong phú | ✅ | ❌ | | Pub/Sub, Streams | ✅ | ❌ | | Đa luồng thuần | có I/O threads | ✅ | | Đơn giản, chỉ cache tạm | | ✅ |

⚠ Khi nào Memcached vẫn hợp:

Cache thuần tuý, mất cũng không sao
    → dữ liệu tính lại được từ nguồn
    → cần đa luồng tối đa
        ↓
    Session, leaderboard, hàng đợi → luôn là Redis

Từ khoá nhận diện:

"session store, must survive restart" → Redis "simple cache, multi-threaded" → Memcached "high availability database" → Multi-AZ "scale reads" → read replica hoặc cache

⚠ RDS Multi-AZ có hai kiểu: | Kiểu | Đặc điểm | |---|---| | Multi-AZ DB instance | một standby, KHÔNG đọc được, 2 AZ | | Multi-AZ DB cluster | hai replica ĐỌC ĐƯỢC, 3 AZ, failover nhanh hơn |

Đề nói "Multi-AZ DB instance" — chọn theo đề
    → nhưng biết rằng DB cluster cho thêm
      khả năng đọc và failover dưới 35 giây

Ba lưu ý về failover của RDS: | Lưu ý | Chi tiết | |---|---| | Thường 60-120 giây với DB instance | | | Endpoint không đổi — DNS trỏ sang standby | | | Ứng dụng phải thử lại kết nối | |

⚠ RDS Proxy rút ngắn thời gian gián đoạn đáng kể:

Không có proxy: ứng dụng chờ DNS TTL, chờ timeout
        ↓
Có RDS Proxy: proxy giữ kết nối, tự trỏ sang writer mới
    → gián đoạn giảm tới ~66%

Ba lưu ý về ElastiCache: | 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 | |

Ba mẫu cache thường dùng: | Mẫu | Chi tiết | |---|---| | Lazy loading (cache-aside) | đọc miss thì nạp | | Write-through | ghi vào 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
        ↓
    Đặt TTL là lưới an toàn cho mọi lỗi vô hiệu hoá cache

Ba lưu ý về session trong Redis: | Lưu ý | Chi tiết | |---|---| | Đặt TTL bằng thời gian hết hạn phiên | | | Bật snapshot để sống sót qua bảo trì | | | Cân nhắc DynamoDB nếu cần bền hơn nữa | |

Ba lưu ý về HIPAA (đề là ứng dụng y tế): | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | | | Mã hoá at rest và in transit ở MỌI tầng | | | Bật audit log của CSDL | |

⚠ Với dữ liệu y tế, mã hoá là bắt buộc chứ không phải tuỳ chọn:

RDS: --storage-encrypted
ElastiCache: --at-rest-encryption-enabled
             --transit-encryption-enabled
EBS của EC2: mã hoá mặc định

Ba lưu ý về mở rộng ASG: | Lưu ý | Chi tiết | |---|---| | Target tracking là mặc định tốt | | | min-size ít nhất bằng số AZ | | | Health check type ELB | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử failover RDS có kế hoạch | đo thời gian | | Tắt một node Redis, xem session còn không | | | Tắt máy ứng dụng, xem người dùng có bị đăng xuất | |

aws rds reboot-db-instance --db-instance-identifier csdl-ho-so \
  --force-failover

Và một lời khuyên: hãy diễn tập failover của cả RDS lẫn Redis trước khi lưu lượng thật tăng. Chuyển đổi tự động chỉ đáng tin khi đã được chứng kiến ít nhất một lần — và thời điểm để phát hiện ứng dụng không biết thử lại kết nối là buổi diễn tập, chứ không phải ngày ra mắt quan hệ đối tác.

Đáp án

B — Dùng Amazon Aurora tương thích MySQL và trỏ tác vụ báo cáo vào một Aurora Replica.

Vì sao đúng

Đề nêu ba yêu cầu, và Aurora đáp ứng cả ba một cách trực tiếp: | Yêu cầu | Cách đáp ứng | |---|---| | Tính sẵn sàng cao hơn | 6 bản sao dữ liệu trên 3 AZ, failover tự động | | Hiệu năng ứng dụng tốt hơn | nhanh gấp ~5 lần MySQL tiêu chuẩn | | Tách tải báo cáo khỏi CSDL chính | Aurora Replica đọc được, độ trễ mili giây |

⚠ Aurora Replica khác read replica của RDS ở điểm quan trọng: | | Aurora Replica | RDS read replica | |---|---|---| | Cơ chế | dùng CHUNG tầng lưu trữ | nhân bản logic qua binlog | | Độ trễ | thường dưới 100 ms | giây tới phút | | Số lượng | tới 15 | tới 15 (MySQL) | | Là mục tiêu failover | ✅ tự động | phải promote thủ công |

Aurora Replica đọc CÙNG một volume lưu trữ
    → không phải phát lại giao dịch
        ↓
    Báo cáo thấy dữ liệu gần như tức thì

Dựng cụm và replica:

aws rds create-db-cluster \
  --db-cluster-identifier cum-khach-hang \
  --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.05.2 \
  --master-username quantri --manage-master-user-password \
  --storage-encrypted --backup-retention-period 30

aws rds create-db-instance --db-instance-identifier ghi-1 \
  --db-cluster-identifier cum-khach-hang \
  --db-instance-class db.r6g.xlarge --engine aurora-mysql

aws rds create-db-instance --db-instance-identifier doc-bao-cao \
  --db-cluster-identifier cum-khach-hang \
  --db-instance-class db.r6g.2xlarge --engine aurora-mysql \
  --promotion-tier 15

⚠ --promotion-tier 15 là chi tiết quan trọng:

Tier thấp = ưu tiên cao khi failover
    → instance báo cáo đặt tier 15 (thấp nhất)
        ↓
    Nó sẽ KHÔNG được chọn làm writer
    → tải báo cáo không bao giờ ảnh hưởng tầng ghi

Custom endpoint chỉ trỏ vào instance báo cáo:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier cum-khach-hang \
  --db-cluster-endpoint-identifier bao-cao \
  --endpoint-type READER \
  --static-members doc-bao-cao

⚠ Vì sao cần custom endpoint chứ không dùng reader endpoint:

Reader endpoint: cân bằng tải giữa MỌI replica
    → truy vấn báo cáo nặng có thể rơi vào
      replica đang phục vụ ứng dụng
        ↓
    Custom endpoint: chỉ trỏ vào instance báo cáo
    → tách bạch thật sự

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tương thích MySQL — không sửa mã | | | Lưu trữ tự mở rộng tới 128 TB | | | Failover thường dưới 30 giây | |

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

• **A. RDS MySQL Single-AZ với read replica CÙNG một AZ — đây là phương án gần nhất và cũng tách được tải báo cáo, nhưng cả hai đều nằm trong một AZ: AZ đó hỏng là mất tất cả. Đề nói rõ cần "higher availability".
• **C. Tự quản lý MySQL trên EC2 với nhân bản thủ công — công vận hành cao nhất: tự vá, tự sao lưu, tự dựng HA. Ngược hẳn "MOST operationally efficient".
• **D. Dùng DMS tạo cụm Aurora ở nhiều Region — DMS là công cụ di chuyển, không phải kiến trúc vận hành; nhân bản xuyên Region là giải pháp cho DR, không phải cho việc tách tải báo cáo trong một Region.

Ghi nhớ

⚠ Ba cơ chế của RDS/Aurora hay bị lẫn — bảng phải thuộc: | Cơ chế | Mục đích | |---|---| | Multi-AZ | TÍNH SẴN SÀNG — standby không đọc được (RDS) | | Read replica | MỞ RỘNG ĐỌC | | Aurora Replica | CẢ HAI — vừa đọc được vừa là mục tiêu failover |

⚠ Đây là ưu thế kiến trúc lớn nhất của Aurora:

RDS: muốn cả HA lẫn mở rộng đọc
    → phải có standby (không dùng được)
      + read replica riêng
        ↓
Aurora: mỗi replica vừa phục vụ đọc
        vừa sẵn sàng tiếp quản

Từ khoá nhận diện:

"offload reporting, higher availability, MySQL" → Aurora + Aurora Replica "failover only, no read scaling" → RDS Multi-AZ "scale reads on RDS" → read replica "unpredictable workload" → Aurora Serverless v2

Ba loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance ghi hiện tại | | Reader | cân bằng giữa các replica | | Custom | nhóm instance bạn chọn |

⚠ Ứng dụng phải dùng ĐÚNG endpoint:

Ghi vào reader endpoint → lỗi read-only
Đọc qua cluster endpoint → dồn tải vào writer
        ↓
    Tách chuỗi kết nối đọc và ghi trong ứng dụng

Ba lưu ý về failover: | Lưu ý | Chi tiết | |---|---| | Thường dưới 30 giây | | | Chọn replica có promotion tier thấp nhất | | | Cùng tier thì chọn instance lớn nhất | |

Ba lưu ý về Aurora Auto Scaling cho replica: | Lưu ý | Chi tiết | |---|---| | Thêm replica theo CPU hoặc số kết nối | | | Tối đa 15 replica | | | Replica tự động không nhận promotion tier thấp | |

aws application-autoscaling register-scalable-target \
  --service-namespace rds --scalable-dimension rds:cluster:ReadReplicaCount \
  --resource-id cluster:cum-khach-hang --min-capacity 1 --max-capacity 5

Ba tính năng riêng của Aurora: | Tính năng | Việc | |---|---| | Backtrack | tua ngược cụm về thời điểm trước | | Cloning | copy-on-write, nhân bản gần như tức thì | | Global Database | RPO ~1 giây xuyên Region |

⚠ Backtrack rất hữu ích cho lỗi vận hành:

aws rds backtrack-db-cluster --db-cluster-identifier cum-khach-hang \
  --backtrack-to 2026-08-30T09:00:00Z

Chạy nhầm một câu DELETE
    → tua ngược cả cụm về trước đó vài phút
        ↓
    Nhanh hơn nhiều so với restore từ snapshot
    (chỉ Aurora MySQL, phải bật trước)

Ba cách chuyển từ MySQL tại chỗ: | Cách | Gián đoạn | |---|---| | DMS full-load + CDC | rất ít | | mysqldump rồi nạp | có | | Nhân bản binlog từ nguồn | ít |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Mỗi instance tính riêng | | | Lưu trữ theo GB thật dùng | | | I/O tính riêng, trừ khi dùng I/O-Optimized | |

⚠ Aurora I/O-Optimized đáng cân nhắc khi báo cáo đọc nhiều:

Truy vấn báo cáo quét nhiều dữ liệu = nhiều I/O
    → chi phí I/O có thể vượt 25% hoá đơn
        ↓
    I/O-Optimized: giá instance cao hơn, I/O miễn phí

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | AuroraReplicaLag | replica tụt hậu bao lâu | | DatabaseConnections | | | Performance Insights | truy vấn nào tốn nhất |

Ba lưu ý về tối ưu truy vấn báo cáo: | Lưu ý | Chi tiết | |---|---| | Index riêng cho truy vấn báo cáo | | | Chạy ngoài giờ cao điểm nếu được | | | Cân nhắc Redshift nếu báo cáo quá nặng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy báo cáo, xem CPU của writer không tăng | | | Đo AuroraReplicaLag | | | Thử failover có kế hoạch | |

Và một lời khuyên: hãy đặt promotion tier cao nhất cho instance chạy báo cáo. Nếu không, một lần failover có thể biến chính cái máy đang chạy truy vấn tổng hợp nặng thành writer của hệ thống — và bạn sẽ có một sự cố hiệu năng chồng lên một sự cố hạ tầng.