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

Đáp án

A — Mặc định, object trong S3 thuộc sở hữu của tài khoản đã TẢI LÊN. Nên chủ sở hữu bucket không tự động có quyền với object do cụm Redshift ở tài khoản khác ghi vào.

Vì sao đúng

Đây là hành vi kinh điển của mô hình sở hữu object cũ trong S3:

Tài khoản A (Redshift) ghi object vào bucket của tài khoản B
    ↓
    Object thuộc sở hữu của TÀI KHOẢN A
    → ACL mặc định chỉ cấp toàn quyền cho chủ sở hữu (A)
    → chủ BUCKET (B) không đọc được object trong chính bucket của mình

Nghe phi lý nhưng đúng theo thiết kế cũ:

Quyền với BUCKET  ≠ quyền với OBJECT bên trong
    → chủ bucket kiểm soát ai được GHI vào
    → nhưng object đã ghi thuộc về người ghi

Ba cách khắc phục — từ cũ tới mới:

① Cách hiện đại (khuyến nghị): bật S3 Object Ownership

aws s3api put-bucket-ownership-controls --bucket kho-du-lieu   --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

BucketOwnerEnforced:
    → ACL bị VÔ HIỆU HOÁ hoàn toàn
    → chủ bucket LUÔN sở hữu mọi object
    → mặc định cho bucket MỚI từ tháng 4 năm 2023

② Cách cũ: khai ACL khi UNLOAD

UNLOAD ('SELECT * FROM ban_hang')
TO 's3://kho-du-lieu/xuat/'
IAM_ROLE 'arn:aws:iam::111122223333:role/vai-tro-redshift'
FORMAT AS PARQUET;

Với các thao tác sao chép cũ:
    --acl bucket-owner-full-control

③ Ép bằng bucket policy:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-du-lieu/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-acl": "bucket-owner-full-control"}}}

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

• **C. Chủ bucket có quyền ngầm định với mọi object; quyền được đặt sau khi sao chép xong, nên vấn đề là thao tác ghi còn đang chạy — đây là phương án gần nhất và nghe hợp lý về mặt thời gian, nhưng nó sai ở tiền đề: chủ bucket KHÔNG có quyền ngầm định với object do tài khoản khác ghi. Và S3 có tính nhất quán mạnh từ tháng 12 năm 2020 — object hiện ra là đã hoàn tất.
• **B. Chủ bucket được cấp quyền ngầm định, đây là lỗi tải lên có thể sửa bằng cách cấp quyền thủ công qua console — sai tiền đề như trên. Và "cấp quyền thủ công" chỉ chữa triệu chứng cho vài object, không giải quyết nguyên nhân.
• **D. Hai tài khoản phải chia sẻ bucket policy, và policy sai gây ra lỗi này — nhầm lẫn khái niệm: bucket policy kiểm soát ai được ghi vào, và ở đây việc ghi đã thành công. Vấn đề nằm ở quyền sở hữu object, không phải ở quyền ghi.

Ghi nhớ

Ba cấu hình S3 Object Ownership — bảng cần thuộc: | Cấu hình | Hành vi | |---|---| | BucketOwnerEnforced | ACL VÔ HIỆU, chủ bucket luôn sở hữu — MẶC ĐỊNH cho bucket mới | | BucketOwnerPreferred | chủ bucket sở hữu nếu người ghi khai bucket-owner-full-control | | ObjectWriter | người ghi sở hữu — hành vi CŨ ← nguyên nhân của câu này |

Từ tháng 4 năm 2023, mọi bucket mới mặc định BucketOwnerEnforced và tắt ACL — nên vấn đề này chỉ còn xảy ra với bucket cũ.

Ba lợi ích của việc tắt ACL: | Lợi ích | Chi tiết | |---|---| | Một mô hình quyền duy nhất | chỉ IAM policy và bucket policy | | Không còn object mồ côi về quyền | ← câu này | | Dễ kiểm toán hơn | không phải kiểm tra ACL của từng object |

Ba mô hình quyền của S3 — lịch sử: | Mô hình | Trạng thái | |---|---| | ACL | CŨ — AWS khuyến nghị TẮT | | Bucket policy | resource policy, dùng cho quyền cấp bucket | | IAM policy | identity policy |

Ba lệnh chẩn đoán vấn đề sở hữu:

# Xem cấu hình sở hữu của bucket
aws s3api get-bucket-ownership-controls --bucket kho-du-lieu

# Xem ai sở hữu một object cụ thể
aws s3api get-object-acl --bucket kho-du-lieu --key xuat/tep.parquet

# Liệt kê object kèm chủ sở hữu
aws s3api list-objects-v2 --bucket kho-du-lieu --fetch-owner

Ba lưu ý khi bật BucketOwnerEnforced: | Lưu ý | Chi tiết | |---|---| | Object CŨ vẫn thuộc chủ cũ | phải sao chép lại để đổi sở hữu | | Ứng dụng dùng ACL sẽ hỏng | kiểm tra trước bằng CloudTrail | | Chuyển dần qua BucketOwnerPreferred | bước trung gian an toàn |

Sao chép lại để đổi quyền sở hữu object cũ:

aws s3 cp s3://kho-du-lieu/xuat/ s3://kho-du-lieu/xuat/   --recursive --metadata-directive COPY --storage-class STANDARD

Sao chép object lên chính nó khiến chủ bucket trở thành chủ sở hữu mới.

Ba lưu ý về Redshift UNLOAD xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | IAM role của Redshift cần quyền s3:PutObject | trên bucket đích | | Bucket policy phải cho phép role đó | truy cập xuyên tài khoản cần cả hai | | Nếu bucket mã hoá KMS, cần thêm kms:GenerateDataKey | và key policy phải cho phép |

Dòng cuối là nguyên nhân phổ biến của lỗi AccessDenied khó hiểu.

Ba tuỳ chọn hữu ích của UNLOAD: | Tuỳ chọn | Việc | |---|---| | FORMAT AS PARQUET | định dạng cột, nén tốt, Athena đọc nhanh | | PARTITION BY | phân vùng theo cột | | PARALLEL OFF | ghi thành một tệp thay vì nhiều tệp |

UNLOAD ('SELECT * FROM ban_hang')
TO 's3://kho-du-lieu/ban-hang/'
IAM_ROLE 'arn:aws:iam::111122223333:role/vai-tro-redshift'
FORMAT AS PARQUET
PARTITION BY (nam, thang);

Ba nguyên tắc cho bucket dùng chung nhiều tài khoản: | Nguyên tắc | Chi tiết | |---|---| | Bật BucketOwnerEnforced ngay từ đầu | tránh mọi vấn đề sở hữu | | Dùng aws:PrincipalOrgID trong bucket policy | không phải liệt kê từng tài khoản | | Bật CloudTrail data event | biết ai ghi gì |

Và điều kiện PrincipalOrgID rất tiện:

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

Ba công cụ phát hiện vấn đề quyền: | Công cụ | Việc | |---|---| | IAM Access Analyzer | tìm tài nguyên chia sẻ ra ngoài | | S3 Storage Lens | thống kê object theo chủ sở hữu | | CloudTrail | lời gọi bị từ chối |

Và một lời khuyên: hãy bật BucketOwnerEnforced cho mọi bucket cũ trong đợt rà soát tới. Đây là loại vấn đề chỉ lộ ra khi ai đó cố đọc dữ liệu — thường là nhiều tháng sau khi đường ống được dựng, và lúc đó việc truy nguyên nguyên nhân tốn nhiều thời gian hơn hẳn so với việc phòng ngừa từ đầu.

Đáp án

D — Tạo job AWS Snowball nhắm tới một bucket S3, rồi tạo lifecycle policy chuyển dữ liệu sang S3 Glacier Deep Archive NGAY TRONG NGÀY.

Vì sao đúng

Điểm mấu chốt: Snowball chỉ ghi được vào bucket S3 thông thường, không ghi thẳng vào Glacier.

AWS Snowball đích hỗ trợ:
    ✓ Amazon S3 (các lớp truy cập tức thì)
    ✗ KHÔNG ghi thẳng vào Glacier Flexible hay Deep Archive
        ↓
    → Phải qua S3 trước, rồi dùng lifecycle chuyển tiếp

Và Deep Archive rẻ hơn Glacier thường rất nhiều: | Lớp | Giá tham khảo | |---|---| | S3 Standard | ~0,023 USD/GB-tháng | | Glacier Instant Retrieval | ~0,004 USD/GB | | Glacier Flexible Retrieval | ~0,0036 USD/GB | | Glacier Deep Archive | ~0,00099 USD/GB — rẻ nhất |

Deep Archive rẻ hơn Glacier Flexible khoảng 3,6 lần — với dữ liệu sao lưu dài hạn, chênh lệch này rất lớn.

Và chuyển NGAY TRONG NGÀY là hợp lệ:

Ràng buộc chuyển đổi của lifecycle:
    → sang Standard-IA hoặc One Zone-IA: phải ở Standard ÍT NHẤT 30 NGÀY
    → sang GLACIER (mọi loại): KHÔNG có ràng buộc, Days: 0 hợp lệ

{"Rules": [{
  "ID": "chuyen-ngay-sang-deep-archive",
  "Status": "Enabled",
  "Filter": {"Prefix": "sao-luu/"},
  "Transitions": [{"Days": 0, "StorageClass": "DEEP_ARCHIVE"}]}]}

Và cụm "Glacier Vault" trong hai phương án kia là dấu hiệu của mô hình CŨ:

S3 Glacier Vault (dịch vụ Glacier độc lập):
    → API riêng, không phải S3
    → AWS khuyến nghị dùng LỚP LƯU TRỮ Glacier TRONG S3 thay thế
    → Snowball không nhắm tới vault được

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

• **A. Snowball nhắm tới bucket S3, lifecycle chuyển sang S3 Glacier ngay trong ngày — đây là phương án gần nhất và quy trình hoàn toàn đúng, nhưng nó chọn lớp lưu trữ đắt hơn: "S3 Glacier" ở đây là Glacier Flexible Retrieval, đắt hơn Deep Archive khoảng 3,6 lần. Đề hỏi "MOST cost savings" và nói rõ "long term archival tier".
• **C. Snowball nhắm thẳng tới Glacier Deep Archive Vault — không làm được về mặt kỹ thuật: Snowball không ghi trực tiếp vào Glacier, và "Deep Archive Vault" không phải khái niệm tồn tại trong dịch vụ Glacier vault.
• **B. Snowball nhắm thẳng tới Glacier Vault — cùng lỗi kỹ thuật, và Glacier vault là mô hình cũ.

Ghi nhớ

Bảng lớp lưu trữ S3 — nội dung cốt lõi: | Lớp | Truy xuất | Giá lưu trữ | Lưu tối thiểu | |---|---|---|---| | Standard | tức thì | ~0,023 USD/GB | không | | Standard-IA | tức thì | ~0,0125 USD/GB | 30 ngày | | One Zone-IA | tức thì | ~0,01 USD/GB | 30 ngày | | Glacier Instant Retrieval | mili giây | ~0,004 USD/GB | 90 ngày | | Glacier Flexible Retrieval | 1 phút – 12 giờ | ~0,0036 USD/GB | 90 ngày | | Glacier Deep Archive | 12–48 giờ | ~0,00099 USD/GB | 180 ngày |

Ba tuỳ chọn truy xuất của Glacier Flexible: | Tuỳ chọn | Thời gian | |---|---| | Expedited | 1–5 phút | | Standard | 3–5 giờ | | Bulk | 5–12 giờ (rẻ nhất) |

Và Deep Archive chỉ có hai: | Tuỳ chọn | Thời gian | |---|---| | Standard | 12 giờ | | Bulk | 48 giờ |

Quy tắc chọn lớp lưu trữ dài hạn:

Cần trong vài giờ → Glacier Flexible Retrieval Chấp nhận chờ 12–48 giờ → Deep Archive (rẻ nhất) Cần ngay lập tức nhưng ít khi dùng → Glacier Instant Retrieval

Ràng buộc chuyển đổi lifecycle — hai loại khác nhau:

Ràng buộc CHUYỂN ĐỔI:
    Standard → Standard-IA / One Zone-IA: cần ÍT NHẤT 30 NGÀY ở Standard
    Standard → Glacier (mọi loại):        KHÔNG có ràng buộc

Ràng buộc LƯU TỐI THIỂU:
    xoá trước hạn vẫn bị tính đủ phí (30/90/180 ngày)

Ba dòng sản phẩm Snow Family: | Sản phẩm | Dung lượng | |---|---| | Snowcone | ~8–14 TB, nhỏ gọn | | Snowball Edge Storage Optimized | ~80 TB | | Snowball Edge Compute Optimized | ~28 TB + năng lực tính toán | | Snowmobile | hàng chục PB (xe container) |

Khi nào dùng Snow Family:

Ước lượng thời gian truyền qua mạng:
    Dung lượng (TB) × 8.000 ÷ băng thông (Mbps) ÷ 3.600 = số giờ

Ví dụ 100 TB qua 500 Mbps:
    100 × 8.000 ÷ 500 ÷ 3.600 ≈ 444 giờ ≈ 18,5 ngày liên tục
        ↓
    → Snowball nhanh hơn và không chiếm băng thông

Quy tắc chung: trên 10 TB hoặc mất hơn một tuần qua mạng → cân nhắc Snow Family.

Ba lưu ý về Snowball: | Lưu ý | Chi tiết | |---|---| | Dữ liệu được mã hoá bằng KMS | khoá không nằm trên thiết bị | | Có phí thuê thiết bị và vận chuyển | tính theo ngày sau thời gian miễn phí | | Đích là MỘT bucket S3 | dùng lifecycle để chuyển tiếp |

Ba lưu ý khi lưu trữ dài hạn trong Glacier: | Lưu ý | Chi tiết | |---|---| | PHÍ TRUY XUẤT cao | tính theo GB, tính cả phí request | | Ràng buộc lưu tối thiểu 180 ngày | xoá sớm vẫn tính đủ | | Không đọc trực tiếp được | phải RESTORE trước, tệp mới đọc được |

Và restore:

aws s3api restore-object --bucket kho-sao-luu --key sao-luu/2020.tar   --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Bulk"}}'

Bản khôi phục tồn tại tạm thời trong số ngày đã khai, rồi biến mất.

Ba biện pháp bảo vệ cho dữ liệu lưu trữ: | Biện pháp | Chi tiết | |---|---| | Versioning | chống ghi đè và xoá nhầm | | Object Lock (COMPLIANCE) | không ai xoá được, kể cả root | | Cross-Region Replication | chống thảm hoạ cấp Region |

Object Lock đặc biệt phù hợp cho bản sao lưu:

Ransomware chiếm được quyền admin:
    → vẫn KHÔNG xoá hay mã hoá được dữ liệu đã khoá
    → bản sao lưu còn nguyên để khôi phục

Ba lưu ý về chi phí lưu trữ dài hạn: | Lưu ý | Chi tiết | |---|---| | Tệp nhỏ tính phí tối thiểu 40 KB (Glacier) | gộp thành tệp lớn trước khi lưu trữ | | Có phí chuyển đổi mỗi object | với hàng triệu tệp thì đáng kể | | Tính trước chi phí khôi phục | khôi phục 100 TB không rẻ |

Và một lời khuyên: hãy thử khôi phục một tệp từ Deep Archive ít nhất một lần trước khi tin tưởng hoàn toàn. Nó cho biết quy trình mất bao lâu thật sự và chi phí ra sao — và với bản sao lưu, khoảnh khắc bạn phát hiện quy trình khôi phục không chạy được là khoảnh khắc tệ nhất có thể.

Đáp án

B — Triển khai ứng dụng trên nhiều EC2 instance trong Auto Scaling group trải HAI Availability Zone; đặt Application Load Balancer phía trước; gắn AWS WAF vào ALB.

Vì sao đúng

Đề nêu bốn yêu cầu, và đáp án thoả cả bốn: | Yêu cầu | Cơ chế | |---|---| | Sẵn sàng cao ở tải bình thường VÀ tải đỉnh | ASG tự co giãn + trải hai AZ | | Bảo vệ khỏi khai thác web phổ biến | AWS WAF | | Kiến trúc co giãn được | ASG | | Ít phức tạp cấu hình nhất | ba thành phần chuẩn, tích hợp sẵn |

Ba thành phần và vai trò của chúng:

AWS WAF        → lọc tấn công tầng 7 trước khi tới ứng dụng
    ↓
Application LB → phân phối, health check, TLS
    ↓
Auto Scaling   → thêm bớt máy theo tải, thay máy hỏng
   (2 AZ)      → chịu được mất một AZ

Vế "tải đỉnh" là điểm phân biệt quan trọng:

Số máy CỐ ĐỊNH:
    → tải đỉnh vượt năng lực → chậm hoặc sập
    → tải thấp → trả tiền cho máy nhàn rỗi

Auto Scaling group:
    → tự thêm máy khi tải tăng
    → tự bớt khi tải giảm

Và WAF chỉ gắn được vào ALB, không gắn vào NLB hay ASG: | Tài nguyên | WAF hỗ trợ | |---|---| | CloudFront | ✅ | | Application Load Balancer | ✅ ← câu này | | API Gateway REST API | ✅ | | AppSync, Cognito user pool | ✅ | | Network Load Balancer | ❌ | | Auto Scaling group | ❌ không phải khái niệm hợp lệ | | Global Accelerator | ❌ |

aws wafv2 associate-web-acl --web-acl-arn <arn-web-acl>   --resource-arn <arn-application-load-balancer>

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

• **A. Chạy HAI EC2 instance ở hai AZ, đăng ký làm target của ALB, gắn WAF vào ALB — đây là phương án gần nhất và có đủ ALB, WAF và hai AZ, nhưng nó thiếu Auto Scaling group: số máy cố định ở hai, nên không xử lý được tải đỉnh như đề yêu cầu, và máy hỏng cũng không được thay tự động.
• **C. ASG qua nhiều AZ với Network Load Balancer, tích hợp WAF trực tiếp với Auto Scaling group — sai về mặt kỹ thuật ở cả hai vế: WAF không gắn được vào NLB (NLB ở tầng 4), và không có cơ chế nào gắn WAF vào Auto Scaling group.
• **D. EC2 trong MỘT AZ duy nhất với Global Accelerator, gắn WAF vào Global Accelerator — hai lỗi: một AZ thì không sẵn sàng cao, và WAF không gắn được vào Global Accelerator.

Ghi nhớ

Kiến trúc web ba lớp bảo vệ và co giãn — mẫu chuẩn:

Người dùng
    ↓
CloudFront (tuỳ chọn: đệm, chống DDoS ở biên)
    ↓
AWS WAF trên ALB (lọc tầng 7)
    ↓
Application Load Balancer (public subnet, ≥ 2 AZ)
    ↓
Auto Scaling group (private subnet, ≥ 2 AZ)
    ↓
RDS Multi-AZ (private subnet)

Ba thành phần bắt buộc cho sẵn sàng cao: | Thành phần | Vai trò | |---|---| | Load balancer | phân phối, kiểm tra sức khoẻ | | Auto Scaling group | thay máy hỏng, co giãn theo tải | | Nhiều AZ | chịu lỗi hạ tầng |

Thiếu ASG là lỗi thiết kế phổ biến nhất — nó biến kiến trúc từ "tự phục hồi" thành "cần người can thiệp".

ALB, NLB và GWLB — bảng phân biệt: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP) | 4 (TCP/UDP) | 3 (IP) | | AWS WAF | ✅ | ❌ | ❌ | | Định tuyến theo nội dung | ✅ | ❌ | ❌ | | IP tĩnh | ❌ | ✅ | — | | Phù hợp | web, microservice | game, IoT, độ trễ thấp | thiết bị bảo mật |

Ba Managed Rule Group của WAF nên bật: | Nhóm | Bảo vệ khỏi | |---|---| | AWSManagedRulesCommonRuleSet | OWASP Top 10 cơ bản | | AWSManagedRulesKnownBadInputsRuleSet | payload tấn công đã biết | | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu |

Và rate-based rule chống lạm dụng:

{"Name": "gioi-han-tan-suat", "Priority": 10,
 "Action": {"Block": {}},
 "Statement": {"RateBasedStatement": {
   "Limit": 2000, "AggregateKeyType": "IP"}}}

Ba loại tấn công web phổ biến mà WAF chặn: | Tấn công | Cơ chế | |---|---| | SQL injection | SqliMatchStatement | | Cross-site scripting (XSS) | XssMatchStatement | | Bot và quét tự động | Bot Control (tính phí thêm) | | Tấn công tầng 7 dạng flood | rate-based rule |

Ba cấu hình ASG quan trọng: | Cấu hình | Giá trị nên dùng | |---|---| | HealthCheckType = ELB | thay máy mà ứng dụng hỏng, không chỉ OS hỏng | | HealthCheckGracePeriod | đủ dài cho thời gian khởi động | | Trải ít nhất hai AZ, tốt nhất ba | |

Và target tracking là chính sách co giãn nên dùng:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-ung-dung   --policy-name giu-cpu-50 --policy-type TargetTrackingScaling   --estimated-instance-warmup 300   --target-tracking-configuration '{
    "TargetValue": 50.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"}}'

Ba lớp chống DDoS trên AWS: | Lớp | Chi tiết | |---|---| | AWS Shield Standard | MIỄN PHÍ, tự động, tầng 3/4 | | AWS WAF | tầng 7 — rate limiting, lọc mẫu | | Shield Advanced | 3.000 USD/tháng, có đội ứng phó và bảo vệ chi phí |

Ba việc nên làm khi triển khai WAF: | Việc | Chi tiết | |---|---| | Bật ở chế độ Count trước | xem sẽ chặn gì trước khi chặn thật | | Bật logging ra S3 hoặc CloudWatch | phục vụ chẩn đoán | | Theo dõi metric theo từng quy tắc | phát hiện chặn nhầm |

Chế độ Count là bước bắt buộc:

Bật Count vài ngày
    → xem sampled request và metric
    → kiểm tra không có người dùng thật bị khớp
    → rồi mới chuyển sang Block

Ba cải tiến nên cân nhắc thêm: | Cải tiến | Lợi ích | |---|---| | Thêm CloudFront trước ALB | đệm, giảm tải, chống DDoS ở biên, WAF ở biên | | Trải qua BA AZ | tiết kiệm hơn hai AZ cho cùng mức chịu lỗi | | RDS Multi-AZ cho tầng dữ liệu | hoàn thiện kiến trúc |

Và một lời khuyên: hãy triển khai WAF ở chế độ Count ít nhất một tuần trước khi chuyển sang Block. Managed rule group đôi khi khớp với lưu lượng hợp lệ của ứng dụng — ví dụ một biểu mẫu cho phép nhập mã SQL — và phát hiện điều đó bằng metric an toàn hơn nhiều so với phát hiện qua khiếu nại của khách hàng.

Đáp án

B — Dựng Amazon Aurora Global Database cluster.

Vì sao đúng

Đề cho hai con số cụ thể, và chúng chỉ thẳng tới Global Database:

RPO (mất bao nhiêu dữ liệu):  GIÂY
RTO (bao lâu để phục hồi):    MỘT PHÚT
    ↓
    Đây chính là chỉ số công bố của Aurora Global Database

Aurora Global Database là gì:

Một cụm PRIMARY ở Region chính
    + tới 5 cụm PHỤ ở các Region khác
        ↓
    Sao chép ở TẦNG LƯU TRỮ, không qua tầng database
    → độ trễ thường DƯỚI 1 GIÂY
    → KHÔNG ảnh hưởng hiệu năng của primary

Và hai chỉ số của nó: | Chỉ số | Giá trị | |---|---| | RPO | thường dưới 1 giây | | RTO (managed planned failover) | dưới 1 phút | | Độ trễ sao chép | thường dưới 1 giây | | Số Region phụ | tới 5 |

Vì sao sao chép ở tầng lưu trữ nhanh hơn:

Sao chép truyền thống (RDS read replica):
    → primary đọc binlog, gửi qua mạng, replica áp dụng
    → tiêu tốn CPU của primary
    → độ trễ tính bằng giây tới phút

Aurora Global Database:
    → tầng lưu trữ tự sao chép các thay đổi
    → KHÔNG dùng tài nguyên của instance database
    → độ trễ dưới một giây

aws rds create-global-cluster --global-cluster-identifier cum-toan-cau   --source-db-cluster-identifier arn:aws:rds:ap-northeast-1:123456789012:cluster:cum-chinh

aws rds create-db-cluster --db-cluster-identifier cum-eu   --engine aurora-postgresql --global-cluster-identifier cum-toan-cau   --region eu-west-1

Và về vế "độ trễ thấp cho người dùng nhiều nơi":

Mỗi Region phụ có tới 16 reader instance
    → người dùng ở châu Âu đọc từ cụm châu Âu
    → độ trễ thấp cho phần lớn lưu lượng (vốn là ĐỌC)

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

• **A. Dựng Aurora multi-master cluster — đây là phương án gần nhất vì nó hứa hẹn ghi được ở nhiều nơi, nhưng nó không giải quyết bài toán đa Region: Aurora multi-master hoạt động trong MỘT Region (nhiều writer trong cùng cụm), không trải nhiều Region. (Tính năng này cũng đã bị AWS ngừng cho Aurora MySQL từ phiên bản 3.)
• **C. Dựng Aurora provisioned cluster — chỉ ở một Region: không có cơ chế nào cho độ trễ thấp ở nhiều châu lục hay RTO một phút khi mất Region.
• **D. Dựng Aurora Serverless cluster — giải quyết vấn đề khác: Serverless tự co giãn năng lực tính toán, không liên quan tới phân bố địa lý hay khôi phục thảm hoạ đa Region.

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

Đề nói "least possible latency for database READ/WRITE operations from users in several geographies" — và Aurora Global Database KHÔNG cho ghi độ trễ thấp ở mọi nơi.

Aurora Global Database:
    → CHỈ CÓ MỘT writer, ở Region primary
    → Region phụ là CHỈ ĐỌC
        ↓
    Người dùng ở châu Âu:
        ĐỌC  → cụm châu Âu, độ trễ thấp ✓
        GHI  → vẫn phải về Region primary ✗

Có tính năng write forwarding cho phép ứng dụng gửi lệnh ghi tới Region phụ, nhưng bên dưới nó vẫn chuyển tiếp về primary — nên độ trễ ghi không giảm, chỉ tiện hơn về mặt lập trình.

-- Bật write forwarding ở Region phụ
SET aurora_replica_read_consistency = 'session';

Muốn ghi độ trễ thấp ở nhiều Region thật sự thì cần database ĐA GHI: | Lựa chọn | Đặc điểm | |---|---| | DynamoDB Global Tables | đa ghi thật, mọi Region đều ghi được | | Aurora DSQL | database quan hệ đa Region, đa ghi (dịch vụ mới) |

Nhưng đề yêu cầu Aurora và các phương án đều là Aurora, nên Global Database vẫn là đáp án đúng — và nó là lựa chọn duy nhất đạt được RPO giây và RTO một phút.

Ghi nhớ

Bốn lựa chọn Aurora cho nhiều Region: | Lựa chọn | RPO | RTO | |---|---|---| | Global Database | dưới 1 giây | dưới 1 phút ← câu này | | Cross-Region read replica | giây tới phút | phút (promote thủ công) | | Snapshot copy | giờ | giờ | | Backup & restore | giờ | giờ |

Ba tính năng của Aurora Global Database: | Tính năng | Chi tiết | |---|---| | Managed planned failover | chuyển Region primary có kiểm soát, không mất dữ liệu | | Unplanned failover (detach and promote) | khi Region primary hỏng | | Write forwarding | ghi từ Region phụ được chuyển tiếp về primary |

Managed planned failover rất hữu ích:

aws rds failover-global-cluster --global-cluster-identifier cum-toan-cau   --target-db-cluster-identifier arn:aws:rds:eu-west-1:...:cluster:cum-eu

Dùng cho diễn tập khôi phục thảm hoạ và cho bảo trì có kế hoạch.

Ba khái niệm RPO và RTO: | Khái niệm | Nghĩa | |---|---| | RPO (Recovery Point Objective) | mất bao nhiêu DỮ LIỆU | | RTO (Recovery Time Objective) | bao lâu để HOẠT ĐỘNG TRỞ LẠI |

Bốn chiến lược khôi phục thảm hoạ: | Chiến lược | RTO | RPO | |---|---|---| | Backup & Restore | giờ | giờ | | Pilot Light | chục phút | phút | | Warm Standby | phút | giây–phút | | Multi-site active/active | gần 0 | gần 0 |

Aurora Global Database phù hợp với Warm Standby hoặc Pilot Light tuỳ vào việc bạn có chạy sẵn tầng ứng dụng ở Region phụ hay không.

Ba kiến trúc database toàn cầu — chọn đúng: | Nhu cầu | Lựa chọn | |---|---| | Quan hệ, đọc toàn cầu, ghi một nơi | Aurora Global Database | | NoSQL, ghi ở mọi Region | DynamoDB Global Tables | | Quan hệ, ghi ở mọi Region | Aurora DSQL |

DynamoDB Global Tables đáng biết:

Global Tables:
    ✓ đa ghi (multi-active) thật sự
    ✓ mọi Region đều ghi được
    ✓ giải quyết xung đột theo "last writer wins"
        ↓
    Nếu ứng dụng dùng được NoSQL, đây là lựa chọn cho ghi độ trễ thấp toàn cầu

Ba lưu ý về chi phí Aurora Global Database: | Khoản | Chi tiết | |---|---| | Instance ở MỖI Region | nhân theo số Region | | Phí sao chép | tính theo triệu write I/O được sao chép | | Lưu trữ ở mỗi Region | nhân theo số Region |

Ba lưu ý khi thiết kế ứng dụng: | Lưu ý | Chi tiết | |---|---| | Tách rõ đường ĐỌC và đường GHI | ứng dụng phải biết dùng endpoint nào | | Xử lý độ trễ sao chép | đọc-sau-ghi phải đọc từ primary | | Route 53 latency routing cho tầng ứng dụng | đưa người dùng tới Region gần |

Ba việc cần làm cho khôi phục thảm hoạ: | Việc | Chi tiết | |---|---| | DIỄN TẬP failover định kỳ | quan trọng nhất | | Chạy sẵn tầng ứng dụng ở Region phụ | không thì RTO vẫn cao dù database nhanh | | Đo RTO và RPO thật | so với mục tiêu |

Dòng giữa rất quan trọng: database chuyển vùng trong một phút không có ý nghĩa nếu tầng ứng dụng mất 30 phút để dựng ở Region phụ.

Và một lời khuyên cho ứng dụng y tế toàn cầu: hãy xác minh yêu cầu về vị trí dữ liệu trước khi thiết kế. Nhiều quốc gia yêu cầu dữ liệu sức khoẻ của công dân phải ở lại trong nước — và điều đó có thể khiến kiến trúc đúng không phải là một Global Database, mà là nhiều cụm độc lập theo vùng pháp lý.

Đáp án

C — Dùng Amazon EC2 Instance Hibernate.

Vì sao đúng

Đề mô tả chính xác bài toán mà hibernate giải quyết: ứng dụng mất 3 phút để khởi động vì phải chạy các chương trình phụ trợ.

Stop rồi Start thông thường:
    → RAM bị xoá sạch
    → hệ điều hành khởi động lại từ đầu
    → ứng dụng và chương trình phụ trợ chạy lại từ đầu
    → mất 3 phút mỗi lần

Hibernate hoạt động khác hẳn:

Khi hibernate:
    → nội dung RAM được GHI XUỐNG root EBS volume
    → instance dừng lại

Khi khởi động lại:
    → RAM được NẠP LẠI y nguyên từ EBS
    → tiến trình đang chạy tiếp tục ở đúng chỗ
        ↓
    Không phải khởi động lại ứng dụng
    Không phải chạy lại chương trình phụ trợ

Bật hibernate lúc chạy instance:

aws ec2 run-instances --image-id ami-0abc --instance-type m5.xlarge   --hibernation-options Configured=true   --block-device-mappings '[{"DeviceName":"/dev/xvda",
    "Ebs":{"VolumeSize":100,"Encrypted":true,"VolumeType":"gp3"}}]'

aws ec2 stop-instances --instance-ids i-0abc --hibernate

Ba điều kiện bắt buộc: | Điều kiện | Chi tiết | |---|---| | Bật lúc TẠO instance | không bật được sau | | Root volume là EBS và ĐƯỢC MÃ HOÁ | yêu cầu bắt buộc | | Dung lượng root volume ≥ RAM | để chứa được ảnh RAM |

Và những gì được giữ nguyên:

✓ nội dung RAM
✓ tiến trình đang chạy
✓ kết nối tới instance store volume (dữ liệu vẫn còn)
✗ IP công cộng (đổi, trừ khi dùng Elastic IP)

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

• **D. Tạo AMI và khởi động instance từ đó — đây là phương án gần nhất và thực sự rút ngắn thời gian khởi động (phần mềm đã cài sẵn), nhưng nó không giữ được TRẠNG THÁI ĐANG CHẠY: instance mới vẫn phải khởi động hệ điều hành và chạy lại các chương trình phụ trợ. Nó giải quyết việc cài đặt, không giải quyết việc khởi tạo lúc chạy.
• **B. Dùng EC2 User Data — làm cho vấn đề tệ hơn: user data chạy script lúc khởi động, đúng thứ đang tốn 3 phút. Và mặc định nó chỉ chạy ở lần khởi động đầu tiên.
• **A. Dùng EC2 Metadata — sai chức năng: metadata cung cấp thông tin về instance (id, IP, IAM role), nó không thực thi gì và không liên quan tới thời gian khởi động.

Ghi nhớ

Ba trạng thái dừng của EC2 — bảng cần thuộc: | Trạng thái | RAM | Tính phí instance | Thời gian khởi động lại | |---|---|---|---| | Stop | XOÁ | ❌ (vẫn trả EBS) | khởi động OS từ đầu | | Hibernate | LƯU vào EBS | ❌ (vẫn trả EBS) | nạp lại RAM, rất nhanh | | Terminate | xoá | ❌ | không có | | Reboot | giữ nguyên | ✅ vẫn tính | nhanh nhất |

Ba trường hợp dùng hibernate: | Trường hợp | Chi tiết | |---|---| | Ứng dụng khởi động lâu | ← câu này | | Cần giữ cache trong RAM | nạp lại cache tốn thời gian | | Máy trạm lập trình dùng ngắt quãng | giữ nguyên môi trường làm việc |

Ba điều kiện của hibernate — nhắc lại:

① Bật lúc TẠO instance (--hibernation-options Configured=true)
② Root EBS volume phải ĐƯỢC MÃ HOÁ
③ Dung lượng root volume ĐỦ chứa RAM + hệ điều hành

Và các hạn chế cần biết: | Hạn chế | Chi tiết | |---|---| | Chỉ một số loại instance hỗ trợ | phần lớn họ thế hệ mới, RAM tối đa có giới hạn | | Không hibernate quá 60 ngày liên tục | | | Không dùng với instance store làm root | | | Không hỗ trợ trên Spot ở mọi trường hợp | kiểm tra tài liệu |

Ba cách rút ngắn thời gian khởi động — bảng so sánh: | Cách | Giải quyết | |---|---| | Hibernate | giữ nguyên trạng thái đang chạy ← câu này | | AMI dựng sẵn | bỏ bước cài đặt phần mềm | | ASG warm pool | giữ sẵn máy đã cấu hình ở trạng thái Stopped |

Ba cách này giải quyết ba vấn đề khác nhau:

Cài đặt phần mềm chậm    → AMI dựng sẵn
Khởi tạo lúc chạy chậm   → hibernate
Cần máy sẵn sàng ngay    → warm pool

Warm pool của ASG đáng biết:

Warm pool giữ instance ở trạng thái Stopped hoặc Hibernated
    → khi ASG cần mở rộng, chuyển sang InService trong vài giây
    → thay vì khởi động từ đầu mất vài phút

aws autoscaling put-warm-pool --auto-scaling-group-name asg-ung-dung   --min-size 2 --pool-state Hibernated

Hibernated kết hợp cả hai lợi ích — máy sẵn sàng ngay và trạng thái được giữ.

Ba lưu ý về chi phí khi hibernate: | Lưu ý | Chi tiết | |---|---| | KHÔNG tính phí instance khi hibernate | như stop thông thường | | VẪN tính phí EBS | và cần volume lớn hơn để chứa RAM | | Vẫn tính phí Elastic IP nếu không gắn | |

Ba thứ thay đổi sau khi khởi động lại từ hibernate: | Thứ | Chi tiết | |---|---| | IP công cộng | đổi, trừ khi dùng Elastic IP | | IP riêng | giữ nguyên | | Instance ID | giữ nguyên |

Ba lưu ý về EC2 Image Builder cho AMI dựng sẵn: | Lưu ý | Chi tiết | |---|---| | Tự dựng AMI theo lịch | luôn có bản vá mới nhất | | Kiểm thử tự động trước khi phân phối | | | Phân phối tới nhiều Region và tài khoản | |

Và lưu id AMI mới nhất vào Parameter Store:

aws ssm get-parameter --name /cong-ty/ami/ung-dung/moi-nhat   --query Parameter.Value --output text

Launch template trỏ vào parameter thay vì id cứng.

Ba metric cần đo: | Metric | Ý nghĩa | |---|---| | Thời gian từ Start tới ứng dụng sẵn sàng | đo bằng health check | | Kích thước ảnh RAM | ảnh hưởng thời gian hibernate | | Dung lượng root volume còn trống | phải đủ chứa RAM |

Và một lời khuyên: hãy kiểm chứng hibernate hoạt động đúng với ứng dụng thị giác máy tính này. Một số ứng dụng dùng GPU hoặc giữ kết nối mạng lâu dài không phục hồi sạch sau hibernate — và thử một lần trong môi trường thử nghiệm rẻ hơn nhiều so với phát hiện điều đó khi đang chạy thật.

Đáp án

B — Triển khai standard accelerator của AWS Global Accelerator, đăng ký các NLB hiện có làm endpoint; định tuyến request qua mạng biên toàn cầu của AWS tới NLB khoẻ mạnh gần nhất.

Vì sao đúng

Đề nêu bốn ràng buộc, và Global Accelerator thoả cả bốn: | Ràng buộc | Cơ chế | |---|---| | GIỮ NGUYÊN NLB và hạ tầng EC2 | NLB đăng ký làm endpoint, không đổi gì | | Giảm độ trễ toàn cầu | lưu lượng đi qua mạng riêng của AWS | | Cải thiện thời gian THIẾT LẬP PHIÊN | bắt tay TCP diễn ra ở điểm biên gần người dùng | | Ứng dụng hội nghị truyền hình | hỗ trợ TCP và UDP |

Vì sao Global Accelerator giảm được thời gian thiết lập phiên:

Không có Global Accelerator:
    Client ở Singapore → NLB ở us-east-1
    → bắt tay TCP: 1 vòng lượt × ~200ms
    → bắt tay TLS: 2 vòng lượt × ~200ms
    → tổng chỉ riêng thiết lập: ~600ms

Có Global Accelerator:
    Client → điểm biên tại Singapore (~5ms)
    → bắt tay diễn ra Ở ĐÂY
    → từ điểm biên tới Region qua MẠNG RIÊNG của AWS
        ↓
    Thời gian thiết lập giảm rất nhiều

Và mạng riêng của AWS ổn định hơn Internet công cộng: | Yếu tố | Internet công cộng | Mạng AWS | |---|---|---| | Số chặng | nhiều, khó đoán | ít, tối ưu | | Mất gói | cao hơn | thấp | | Jitter | cao | thấp — quan trọng với hội nghị truyền hình |

Cấu hình:

aws globalaccelerator create-accelerator --name tang-toc-hoi-nghi   --ip-address-type IPV4 --enabled

aws globalaccelerator create-listener --accelerator-arn <arn>   --protocol TCP --port-ranges FromPort=443,ToPort=443   --client-affinity SOURCE_IP

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region ap-northeast-1   --endpoint-configurations EndpointId=<arn-nlb>,Weight=100

Và client-affinity SOURCE_IP quan trọng với hội nghị truyền hình — nó giữ cùng một client luôn tới cùng một endpoint.

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

• **A. Dùng Route 53 latency-based routing với health check để chuyển vùng — đây là phương án gần nhất và cũng đưa người dùng tới Region gần nhất, nhưng nó kém hơn ở hai điểm: nó phụ thuộc bộ đệm DNS (client giữ IP cũ), và nó không rút ngắn thời gian bắt tay — client vẫn kết nối trực tiếp tới NLB ở xa qua Internet công cộng.
• **D. Đặt CloudFront với HTTP caching trước NLB — sai giao thức: CloudFront chỉ hỗ trợ HTTP/HTTPS, còn hội nghị truyền hình dùng giao thức thời gian thực (thường là UDP). Và caching vô nghĩa với luồng video trực tiếp — mỗi phiên là nội dung khác nhau.
• **C. Thay mọi NLB bằng ALB, dùng cross-zone load balancing — vi phạm ràng buộc "giữ nguyên NLB", và cross-zone load balancing chỉ phân phối TRONG một Region — nó không giải quyết gì cho độ trễ giữa các châu lục.

Ghi nhớ

Global Accelerator và CloudFront — bảng phân biệt cốt lõi: | | Global Accelerator | CloudFront | |---|---|---| | Giao thức | TCP và UDP, mọi cổng | chỉ HTTP/HTTPS | | Caching | ❌ không đệm | ✅ | | Địa chỉ | 2 IP anycast TĨNH | tên miền | | Chuyển vùng | ~30 giây, không đụng DNS | theo origin | | Phù hợp | game, VoIP, hội nghị, IoT, API | web, video theo yêu cầu, tệp tĩnh |

Từ khoá nhận diện:

"UDP", "non-HTTP", "static IP", "session initiation", "gaming/VoIP" → Global Accelerator "cache static content", "HTTP", "video on demand" → CloudFront "route to nearest Region via DNS" → Route 53 latency routing

Ba lợi ích của Global Accelerator: | Lợi ích | Chi tiết | |---|---| | Giảm độ trễ và jitter | mạng riêng của AWS | | IP anycast TĨNH | không phụ thuộc bộ đệm DNS | | Chuyển vùng nhanh (~30 giây) | ở tầng mạng |

Và IP tĩnh có lợi ích phụ đáng kể:

Khách hàng doanh nghiệp cần đưa IP vào danh sách trắng tường lửa
    → hai IP cố định, không bao giờ đổi
    → không phải cập nhật mỗi khi kiến trúc thay đổi

Hai loại accelerator: | Loại | Đặc điểm | |---|---| | Standard | định tuyến theo độ trễ và sức khoẻ ← câu này | | Custom routing | ánh xạ CỐ ĐỊNH IP+cổng → instance cụ thể |

Custom routing rất phù hợp với hội nghị truyền hình:

Nhiều phòng họp trên cùng fleet EC2
    → mỗi cổng ánh xạ tới đúng một instance và cổng
    → mọi người trong cùng phòng luôn tới cùng máy chủ
        ↓
    Đây là tính năng đáng cân nhắc cho nền tảng trong đề

Ba khái niệm của Global Accelerator: | Khái niệm | Việc | |---|---| | Accelerator | tài nguyên gốc, mang hai IP tĩnh | | Listener | cổng và giao thức (TCP hoặc UDP) | | Endpoint group | một Region, có traffic dial | | Endpoint | ALB, NLB, EC2, hoặc Elastic IP |

Và traffic-dial-percentage cho triển khai dần:

aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn> --traffic-dial-percentage 10

Chuyển 10% lưu lượng sang Region mới, tăng dần nếu ổn.

Ba yếu tố quyết định định tuyến: | Yếu tố | Chi tiết | |---|---| | Sức khoẻ endpoint | không định tuyến tới endpoint hỏng | | Traffic dial của endpoint group | tỷ lệ lưu lượng | | Vị trí địa lý của client | tới Region gần nhất khoẻ mạnh |

Ba tuỳ chọn ClientAffinity: | Tuỳ chọn | Việc | |---|---| | NONE (mặc định) | phân phối theo luồng (5-tuple) | | SOURCE_IP | cùng IP nguồn luôn tới cùng endpoint |

Với hội nghị truyền hình, SOURCE_IP giúp giữ phiên ổn định.

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Phí cố định | ~0,025 USD/giờ mỗi accelerator (~18 USD/tháng) | | Phí truyền dữ liệu cao cấp | theo GB, khác nhau theo Region | | Không có phí request | khác CloudFront |

Ba cách khác giảm độ trễ cho ứng dụng thời gian thực: | Cách | Chi tiết | |---|---| | Triển khai ở nhiều Region | ← đã có trong đề | | AWS Local Zones | gần người dùng hơn cả Region | | AWS Wavelength | trong mạng 5G của nhà mạng |

Local Zones đáng cân nhắc cho hội nghị truyền hình:

Local Zone đặt tại các thành phố lớn
    → độ trễ một chữ số mili giây tới người dùng trong khu vực đó
    → chạy EC2, EBS, ALB ngay tại đó

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NewFlowCount | số phiên mới | | ProcessedBytesIn/Out | lưu lượng | | Health check của endpoint | Region nào đang phục vụ |

Và một lời khuyên: hãy đo độ trễ thật từ nhiều vị trí trước và sau khi bật Global Accelerator. Mức cải thiện phụ thuộc nhiều vào chất lượng đường Internet giữa người dùng và Region — với một số tuyến, cải thiện rất lớn; với tuyến vốn đã tốt, có thể không đáng kể so với chi phí thêm vào.

Đáp án

B — Dùng AWS Config managed rule kiểm tra chứng chỉ SSL/TLS của bên thứ ba ĐƯỢC NHẬP (imported) vào ACM có sắp hết hạn trong 30 ngày không; cấu hình rule kích hoạt thông báo SNS cho đội bảo mật.

Vì sao đúng

Điểm mấu chốt nằm ở một chữ trong đề: chứng chỉ của BÊN THỨ BA.

Chứng chỉ do ACM CẤP (ACM-issued):
    → ACM TỰ ĐỘNG GIA HẠN
    → không cần theo dõi

Chứng chỉ của bên thứ ba NHẬP vào ACM (imported):
    → ACM KHÔNG gia hạn được
    → HẾT HẠN và gây gián đoạn nếu không ai để ý
        ↓
    Đây chính là loại cần cảnh báo

Và AWS Config có managed rule sẵn cho đúng việc này:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "acm-chung-chi-sap-het-han",
  "Source": {"Owner": "AWS",
             "SourceIdentifier": "ACM_CERTIFICATE_EXPIRATION_CHECK"},
  "InputParameters": "{\"daysToExpiration\":\"30\"}",
  "Scope": {"ComplianceResourceTypes": ["AWS::ACM::Certificate"]}}'

Và gắn thông báo SNS qua EventBridge:

{"source": ["aws.config"],
 "detail-type": ["Config Rules Compliance Change"],
 "detail": {
   "configRuleName": ["acm-chung-chi-sap-het-han"],
   "newEvaluationResult": {"complianceType": ["NON_COMPLIANT"]}}}

Vì sao đây là cách "ít script và ít bảo trì nhất":

✓ managed rule — AWS viết sẵn logic
✓ không có Lambda tự viết nào
✓ tự đánh giá định kỳ
✓ tự áp cho chứng chỉ MỚI được nhập vào

Điểm cuối quan trọng: khi đội ngũ nhập thêm chứng chỉ mới, rule tự động bao phủ nó — không phải nhớ tạo thêm alarm.

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

• **D. AWS Config managed rule kiểm tra chứng chỉ ĐƯỢC TẠO QUA ACM — đây là phương án gần nhất và dùng đúng công cụ, nhưng nó nhắm sai loại chứng chỉ: chứng chỉ do ACM cấp tự động gia hạn, nên cảnh báo về chúng gần như vô nghĩa. Đề nói rõ đây là chứng chỉ của bên thứ ba.
• **C. Theo dõi metric DaysToExpiry cho chứng chỉ nhập vào ACM, tạo CloudWatch alarm — gần đúng về kỹ thuật nhưng nhiều công hơn: ACM có phát metric DaysToExpiry, nhưng nó là metric theo từng chứng chỉ, nên phải tạo alarm riêng cho mỗi chứng chỉ và nhớ tạo thêm khi nhập chứng chỉ mới. Config rule bao phủ tự động.
• **A. Cùng cách với C nhưng cho chứng chỉ tạo qua ACM — kết hợp cả hai điểm yếu: nhắm sai loại chứng chỉ và nhiều công bảo trì hơn.

Ghi nhớ

Hai loại chứng chỉ trong ACM — bảng phải thuộc: | Loại | Gia hạn | Chi phí | |---|---|---| | ACM-issued (do ACM cấp) | TỰ ĐỘNG | MIỄN PHÍ | | Imported (nhập từ bên thứ ba) | KHÔNG tự động — bạn phải nhập lại | theo nhà cung cấp |

Và đây là lý do nên dùng chứng chỉ do ACM cấp bất cứ khi nào có thể:

Chứng chỉ ACM:
    ✓ miễn phí
    ✓ tự gia hạn (bắt đầu 60 ngày trước hạn)
    ✓ không bao giờ hết hạn bất ngờ

Ba điều kiện để ACM tự gia hạn: | Điều kiện | Chi tiết | |---|---| | Chứng chỉ đang ĐƯỢC DÙNG | gắn với ALB, CloudFront, API Gateway | | Xác minh DNS còn hợp lệ | bản ghi CNAME xác minh vẫn còn | | Hoặc xác minh email được xác nhận lại | kém tin cậy hơn |

Xác minh DNS là cách đúng:

DNS validation:
    → thêm một bản ghi CNAME vào hosted zone
    → GIỮ NGUYÊN bản ghi đó
    → ACM tự xác minh lại khi gia hạn, hoàn toàn tự động

Email validation:
    → phải bấm link trong email mỗi lần gia hạn
    → dễ bỏ lỡ

Xoá bản ghi CNAME xác minh là nguyên nhân khiến tự gia hạn thất bại — một lỗi hay gặp khi dọn dẹp DNS.

Ba nơi dùng được chứng chỉ ACM: | Nơi | Lưu ý | |---|---| | ALB, NLB | cùng Region | | CloudFront | chứng chỉ PHẢI ở us-east-1 | | API Gateway | cùng Region (edge-optimized thì us-east-1) | | Cognito, App Runner | cùng Region |

Và ACM KHÔNG xuất được private key — nên không dùng được cho EC2 tự quản lý. Muốn vậy phải dùng ACM Private CA hoặc tự quản lý chứng chỉ.

Ba managed rule của AWS Config liên quan tới chứng chỉ và bảo mật: | Rule | Kiểm tra | |---|---| | ACM_CERTIFICATE_EXPIRATION_CHECK | chứng chỉ sắp hết hạn ← câu này | | ALB_HTTP_TO_HTTPS_REDIRECTION_CHECK | ALB có chuyển hướng HTTPS | | ELB_TLS_HTTPS_LISTENERS_ONLY | chỉ có listener HTTPS |

Ba lợi ích của AWS Config managed rule: | Lợi ích | Chi tiết | |---|---| | AWS viết và bảo trì logic | không có mã tự viết | | Tự áp cho tài nguyên MỚI | ← điểm quan trọng nhất | | Ghi lại lịch sử tuân thủ | phục vụ kiểm toán |

Và Config có hơn 300 managed rule — nên kiểm tra danh sách trước khi tự viết custom rule bằng Lambda.

Ba cách kích hoạt thông báo: | Cách | Chi tiết | |---|---| | EventBridge rule bắt Config compliance change | linh hoạt nhất | | Config delivery channel với SNS | thông báo mọi thay đổi (ồn hơn) | | Security Hub | tổng hợp cùng finding khác |

Ba cách khắc phục tự động: | Cách | Chi tiết | |---|---| | Config remediation với SSM Automation | tự chạy hành động sửa | | EventBridge → Lambda | logic tuỳ chỉnh | | Chỉ thông báo | ← phù hợp với chứng chỉ (cần con người nhập bản mới) |

Với chứng chỉ nhập vào, tự động hoá khó — bạn cần lấy chứng chỉ mới từ nhà cung cấp bên ngoài, nên thông báo sớm là cách đúng.

Ba lưu ý về chi phí AWS Config: | Khoản | Chi tiết | |---|---| | Config item được ghi | ~0,003 USD mỗi item | | Đánh giá rule | ~0,001 USD mỗi lần | | Conformance pack | tính theo đánh giá |

Ba việc nên làm cho quản lý chứng chỉ: | Việc | Chi tiết | |---|---| | Chuyển sang chứng chỉ do ACM cấp bất cứ khi nào được | loại bỏ hẳn vấn đề | | Dùng DNS validation, không dùng email | tự gia hạn được | | Cảnh báo trước 30 và 7 ngày | hai mốc để không bỏ lỡ |

Và ACM cũng phát sự kiện EventBridge khi sắp hết hạn:

{"source": ["aws.acm"],
 "detail-type": ["ACM Certificate Approaching Expiration"]}

Sự kiện này phát ra hằng ngày bắt đầu từ 45 ngày trước hạn — một lựa chọn khác cũng ít công.

Và một lời khuyên: hãy kiểm kê xem còn bao nhiêu chứng chỉ nhập vào và có thể thay bằng chứng chỉ ACM không. Mỗi chứng chỉ chuyển được là một nguồn sự cố tiềm tàng biến mất vĩnh viễn — và cảnh báo dù tốt đến đâu cũng chỉ hữu ích nếu có người đọc và hành động kịp.

Đáp án

D — Cài DataSync agent trên máy chủ tại chỗ có quyền truy cập NFS; truyền dữ liệu qua Direct Connect tới interface VPC endpoint (PrivateLink) cho EFS bằng private VIF; đặt DataSync scheduled task gửi video sang EFS mỗi 24 giờ.

Vì sao đúng

Đề nêu yêu cầu hiệu quả vận hành nhất, và điểm phân biệt là số bước trong đường ống.

So sánh hai kiến trúc:

Đáp án D (một bước):
    NFS tại chỗ → DataSync → EFS
        ↓
    Một dịch vụ, một lịch, một chỗ để theo dõi

Các phương án khác (hai bước):
    NFS tại chỗ → DataSync → S3 → Lambda → EFS
        ↓
    Thêm S3 làm trung gian
    Thêm Lambda phải viết và bảo trì
    Thêm event notification phải cấu hình
    Dữ liệu lưu HAI nơi, trả tiền hai lần

DataSync ghi thẳng vào EFS được — đó là một trong các đích được hỗ trợ nguyên bản.

Và về mạng, private VIF + interface endpoint là cấu hình đúng: | Thành phần | Vai trò | |---|---| | Private VIF | truy cập tài nguyên TRONG VPC qua Direct Connect | | Interface VPC endpoint (PrivateLink) cho EFS | DataSync agent kết nối riêng tư tới dịch vụ |

Cấu hình:

# ① Vị trí nguồn: NFS tại chỗ
aws datasync create-location-nfs   --server-hostname 10.100.0.50 --subdirectory /video   --on-prem-config AgentArns=<arn-agent>

# ② Vị trí đích: EFS
aws datasync create-location-efs   --efs-filesystem-arn <arn-efs>   --ec2-config SubnetArn=<arn-subnet>,SecurityGroupArns=<arn-sg>

# ③ Task chạy theo lịch
aws datasync create-task   --source-location-arn <arn-nfs> --destination-location-arn <arn-efs>   --schedule ScheduleExpression="cron(0 2 * * ? *)"   --options VerifyMode=ONLY_FILES_TRANSFERRED,PreserveDeletedFiles=PRESERVE

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

• **C. DataSync qua Direct Connect tới "VPC peering endpoint cho EFS" bằng private VIF, task theo lịch mỗi 24 giờ — đây là phương án gần nhất và kiến trúc một bước hoàn toàn đúng, nhưng nó dùng sai thuật ngữ mạng: không có khái niệm "VPC peering endpoint cho EFS". VPC peering nối hai VPC với nhau, nó không phải endpoint của dịch vụ. Cơ chế đúng là interface VPC endpoint qua PrivateLink.
• **A. DataSync → S3 qua PUBLIC VIF → Lambda → EFS — hai lỗi: thêm bước trung gian không cần thiết, và public VIF đưa lưu lượng qua endpoint công khai của AWS thay vì vào thẳng VPC riêng tư.
• **B. DataSync → S3 qua gateway VPC endpoint → Lambda → EFS — vế mạng đúng hơn A, nhưng vẫn thừa một bước: S3 và Lambda là trung gian không cần thiết khi DataSync ghi thẳng vào EFS được.

Ghi nhớ

Các đích mà AWS DataSync hỗ trợ — bảng cần thuộc: | Đích | Hỗ trợ | |---|---| | Amazon S3 | ✅ | | Amazon EFS | ✅ ← câu này | | FSx for Windows, Lustre, ONTAP, OpenZFS | ✅ | | Hệ thống tệp khác (NFS, SMB, HDFS, object storage) | ✅ (làm nguồn hoặc đích) |

Ba lợi ích của DataSync: | Lợi ích | Chi tiết | |---|---| | Nhanh hơn công cụ mã nguồn mở tới 10 lần | giao thức tối ưu, nén, truyền song song | | Tự KIỂM TRA TÍNH TOÀN VẸN | so checksum nguồn và đích | | Lên lịch, báo cáo, tự thử lại | không phải viết script |

Ba loại virtual interface của Direct Connect — bảng phải thuộc: | Loại | Truy cập gì | |---|---| | Private VIF | tài nguyên TRONG VPC (IP riêng) ← câu này | | Public VIF | dịch vụ AWS công khai (S3, DynamoDB) qua IP công cộng | | Transit VIF | kết nối tới Transit Gateway |

Quy tắc: vào VPC thì private VIF; tới endpoint công khai của dịch vụ thì public VIF.

Ba loại VPC endpoint: | Loại | Dịch vụ | Cơ chế | |---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | route table, MIỄN PHÍ | | Interface endpoint (PrivateLink) | hầu hết dịch vụ AWS | ENI có IP riêng, có phí | | Gateway Load Balancer endpoint | thiết bị bảo mật | chuyển hướng lưu lượng |

Lưu ý quan trọng: gateway endpoint KHÔNG truy cập được từ tại chỗ.

Gateway endpoint hoạt động qua ROUTE TABLE của VPC
    → chỉ tài nguyên TRONG VPC dùng được
    → máy tại chỗ qua Direct Connect KHÔNG dùng được
        ↓
    Muốn truy cập S3 riêng tư từ tại chỗ:
        → interface endpoint cho S3, hoặc
        → public VIF

Ba tuỳ chọn quan trọng của DataSync task: | Tuỳ chọn | Việc | |---|---| | VerifyMode | ONLY_FILES_TRANSFERRED (nhanh) hoặc POINT_IN_TIME_CONSISTENT (kỹ) | | PreserveDeletedFiles | giữ hay xoá tệp đã bị xoá ở nguồn | | TransferMode | CHANGED (chỉ tệp đổi) hoặc ALL | | BytesPerSecond | giới hạn băng thông |

Giới hạn băng thông rất quan trọng với Direct Connect dùng chung:

--options BytesPerSecond=104857600   # giới hạn 100 MB/giây

Không giới hạn thì DataSync chiếm hết đường truyền và ảnh hưởng ứng dụng khác.

Ba lưu ý về DataSync agent: | Lưu ý | Chi tiết | |---|---| | Chạy dưới dạng máy ảo tại chỗ | VMware, Hyper-V, KVM, hoặc EC2 | | Cần kết nối tới endpoint dịch vụ DataSync | qua PrivateLink hoặc Internet | | Cần đủ RAM và CPU | tối thiểu 4 vCPU, 32 GB RAM |

Ba lựa chọn di chuyển dữ liệu — chọn đúng: | Nhu cầu | Công cụ | |---|---| | Di chuyển hoặc đồng bộ định kỳ | DataSync ← câu này | | Truy cập LIÊN TỤC từ tại chỗ | Storage Gateway | | Khối lượng rất lớn, băng thông kém | Snow Family | | Tệp lẻ, thủ công | AWS CLI với multipart |

Và DataSync + Storage Gateway thường dùng cùng nhau:

DataSync: chuyển khối lượng ban đầu (nhanh hơn nhiều)
Storage Gateway: truy cập hằng ngày sau đó

Ba lưu ý khi ghi vào EFS: | Lưu ý | Chi tiết | |---|---| | DataSync tạo ENI trong VPC | cần subnet và security group | | Cần mount target ở AZ tương ứng | | | Quyền POSIX được giữ nguyên | uid, gid, permission bits |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BytesTransferred | tiến độ | | FilesTransferred | số tệp | | Task execution status | thành công hay có tệp lỗi |

Và DataSync ghi báo cáo chi tiết:

aws datasync describe-task-execution --task-execution-arn <arn>

Nó liệt kê tệp nào bị bỏ qua và vì sao — thông tin cần thiết trước khi cắt chuyển.

Ba việc cần làm trước khi cắt chuyển: | Việc | Chi tiết | |---|---| | Chạy task với VerifyMode kỹ một lần | xác nhận dữ liệu khớp hoàn toàn | | So số tệp và tổng dung lượng | nguồn và đích | | Rút ngắn chu kỳ đồng bộ trước ngày cắt | giảm khoảng lệch |

Và một lời khuyên: hãy giảm chu kỳ từ 24 giờ xuống mỗi giờ trong tuần cuối trước khi cắt chuyển. Với hàng trăm video mỗi ngày, chu kỳ 24 giờ nghĩa là lúc cắt chuyển có thể còn tới một ngày dữ liệu chưa đồng bộ — và đó là khoảng trống bạn không muốn phát hiện sau khi đã chuyển ứng dụng sang.

Đáp án

D — Instance B (instance có launch configuration cũ nhất).

Vì sao đúng

Chính sách chấm dứt mặc định của Auto Scaling xét theo thứ tự, và launch configuration được xét TRƯỚC launch template.

Thứ tự đầy đủ của chính sách mặc định:

① Chọn AZ có NHIỀU instance nhất
     → đề đã cho: us-east-1a

② Trong AZ đó, ưu tiên instance dùng LAUNCH CONFIGURATION
     (nếu ASG có cả launch template lẫn launch configuration)
     → Instance B và C dùng launch configuration
     → Instance A dùng launch template → LOẠI

③ Trong nhóm dùng launch configuration, chọn cái CŨ NHẤT
     → Instance B (cũ nhất) vs Instance C (mới nhất)
     → chọn INSTANCE B

④ (Nếu vẫn hoà) chọn instance gần mốc tính tiền theo giờ nhất
     → không cần tới bước này

Vì sao AWS ưu tiên loại launch configuration trước:

Launch configuration là công nghệ CŨ
    → AWS khuyến nghị chuyển sang launch template
    → chính sách mặc định giúp "thay dần" một cách tự nhiên
        ↓
    Mỗi lần thu hẹp, máy dùng cấu hình cũ bị loại trước

Instance D (gần mốc tính tiền) không được chọn vì tiêu chí đó nằm ở bước sau và chỉ dùng khi các bước trước không phân định được.

Xem chính sách hiện tại:

aws autoscaling describe-auto-scaling-groups   --auto-scaling-group-names asg-ung-dung   --query 'AutoScalingGroups[0].TerminationPolicies'

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

• **B. Instance A (launch template cũ nhất) — đây là phương án gần nhất vì "cũ nhất" đúng là tiêu chí được dùng, nhưng nó bỏ qua thứ tự ưu tiên: instance dùng launch configuration bị xét trước instance dùng launch template, bất kể cái nào cũ hơn.
• **A. Instance D (gần mốc tính tiền theo giờ) — tiêu chí này ở bước 3 trong chính sách mặc định, chỉ dùng khi bước trước không phân định được. Ở đây bước launch configuration đã cho ra kết quả.
• **C. Instance C (launch configuration MỚI nhất) — ngược tiêu chí: trong nhóm dùng launch configuration, ASG chọn cái cũ nhất, không phải mới nhất.

Ghi nhớ

Chính sách chấm dứt mặc định của ASG — thứ tự phải thuộc:

① AZ có NHIỀU instance nhất
② Instance dùng LAUNCH CONFIGURATION (trước launch template)
③ Trong đó, cái CŨ NHẤT
④ Instance gần mốc TÍNH TIỀN THEO GIỜ tiếp theo
⑤ Chọn ngẫu nhiên

Các chính sách chấm dứt tuỳ chọn: | Chính sách | Chấm dứt | |---|---| | Default | theo thứ tự trên | | OldestInstance | instance cũ nhất — hữu ích khi nâng cấp loại máy | | NewestInstance | instance mới nhất — hữu ích khi rollback | | OldestLaunchConfiguration | cấu hình cũ nhất | | OldestLaunchTemplate | template cũ nhất | | ClosestToNextInstanceHour | tối ưu chi phí | | AllocationStrategy | cân bằng lại theo chiến lược Spot |

Và kết hợp được nhiều chính sách theo thứ tự:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --termination-policies "OldestLaunchTemplate" "OldestInstance" "Default"

ASG áp lần lượt cho tới khi chọn được một instance.

Launch template và Launch configuration — bảng phân biệt: | | Launch template | Launch configuration | |---|---|---| | Trạng thái | được KHUYẾN NGHỊ | CŨ, AWS không phát triển thêm | | Phiên bản hoá | ✅ | ❌ bất biến | | Trộn loại instance và mua | ✅ | ❌ | | Hỗ trợ tính năng EC2 mới | ✅ | ❌ (T2 unlimited, placement group, capacity reservation...) | | Sửa được | ✅ tạo phiên bản mới | ❌ phải tạo cái mới |

AWS đã ngừng cho tạo launch configuration mới với tài khoản mới — nên chuyển sang launch template là việc nên làm.

Chuyển đổi:

aws ec2 create-launch-template --launch-template-name lt-ung-dung   --source-version ...
# hoặc dùng công cụ chuyển đổi trong console ASG

Hai thứ tự khác nhau của ASG — nhắc lại: | Tình huống | Thứ tự | |---|---| | Thay instance KHÔNG khoẻ mạnh | chấm dứt → khởi động | | Cân bằng lại giữa AZ | khởi động → chấm dứt |

Ba cơ chế bảo vệ instance khỏi bị chấm dứt: | Cơ chế | Chi tiết | |---|---| | Scale-in protection | ASG không chấm dứt instance này khi thu hẹp | | Standby state | tạm gỡ khỏi ASG để bảo trì | | Instance termination protection (EC2) | KHÔNG ngăn được ASG |

Dòng cuối là điểm hay nhầm: disableApiTermination của EC2 ngăn TerminateInstances thủ công, nhưng không ngăn ASG chấm dứt instance.

Bật scale-in protection:

aws autoscaling set-instance-protection --instance-ids i-0abc   --auto-scaling-group-name asg-ung-dung --protected-from-scale-in

Hữu ích cho instance đang xử lý công việc dài không được gián đoạn.

Ba lifecycle hook đáng dùng: | Hook | Việc | |---|---| | EC2_INSTANCE_LAUNCHING | cài đặt hoặc nạp dữ liệu trước khi phục vụ | | EC2_INSTANCE_TERMINATING | đẩy log ra ngoài, hoàn tất công việc dở | | Cả hai | thông báo qua SNS hoặc EventBridge |

Hook chấm dứt rất quan trọng:

Không có hook:
    Instance bị chấm dứt ngay
    → log cục bộ và công việc đang xử lý MẤT

Có hook:
    → instance vào trạng thái Terminating:Wait
    → script có tối đa 1 giờ để hoàn tất
    → gọi CompleteLifecycleAction rồi mới bị chấm dứt

Ba cách thay toàn bộ fleet an toàn: | Cách | Chi tiết | |---|---| | Instance refresh | ASG tự thay dần theo MinHealthyPercentage | | Đặt OldestLaunchTemplate + tăng giảm desired | thủ công hơn | | Blue/green với ASG mới | kiểm soát nhiều nhất |

Instance refresh là cách hiện đại:

aws autoscaling start-instance-refresh   --auto-scaling-group-name asg-ung-dung   --preferences '{"MinHealthyPercentage":90,"InstanceWarmup":300}'

Ba nơi chẩn đoán: | Nơi | Thông tin | |---|---| | Activity history của ASG | lý do cụ thể của mỗi lần chấm dứt | | CloudTrail | lời gọi API | | EventBridge | sự kiện lifecycle |

Và một lời khuyên: hãy chuyển hết sang launch template nếu ASG còn dùng launch configuration. Ngoài việc tránh những chi tiết khó nhớ như thứ tự trong câu hỏi này, launch template còn mở khoá các tính năng mà launch configuration không hỗ trợ — trong đó có việc trộn Spot và On-Demand, thứ tiết kiệm chi phí đáng kể.

Đáp án

D — Dùng Amazon Aurora Global Database để có khả năng đọc cục bộ với độ trễ thấp ở mỗi Region.

Vì sao đúng

Đề nêu bốn ràng buộc, và Aurora Global Database thoả cả bốn: | Ràng buộc | Cơ chế | |---|---| | KHÔNG rời khỏi lược đồ QUAN HỆ | Aurora là database quan hệ, tương thích MySQL | | Read replica hiện tại không đủ | Aurora replica nhanh hơn RDS rất nhiều | | Chi nhánh trên toàn thế giới | tới 5 Region phụ | | Tiết kiệm và hiệu năng cao | không phải tự vận hành gì |

Vì sao read replica của RDS MySQL không đủ:

RDS MySQL read replica:
    → sao chép ở TẦNG DATABASE (qua binlog)
    → tiêu tốn CPU của primary
    → độ trễ tính bằng GIÂY tới PHÚT
    → tối đa 5 replica
    → replica xuyên Region rất chậm

Aurora Global Database khác hẳn:

Sao chép ở TẦNG LƯU TRỮ
    → KHÔNG dùng tài nguyên của instance database
    → độ trễ thường DƯỚI 1 GIÂY, kể cả xuyên lục địa
    → mỗi Region phụ có tới 16 reader instance
        ↓
    Người dùng ở mỗi chi nhánh đọc từ Region gần nhất

Cấu hình:

aws rds create-global-cluster --global-cluster-identifier acm-toan-cau   --source-db-cluster-identifier <arn-cum-chinh>

aws rds create-db-cluster --db-cluster-identifier acm-eu   --engine aurora-mysql --global-cluster-identifier acm-toan-cau   --region eu-west-1

Và di chuyển từ RDS MySQL sang Aurora MySQL rất dễ:

aws rds create-db-cluster --db-cluster-identifier acm-aurora   --engine aurora-mysql   --restore-type copy-on-write   --source-db-cluster-identifier <arn-snapshot-rds>

Aurora tương thích MySQL ở mức giao thức — ứng dụng thường không phải sửa gì.

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

• **A. Dùng DynamoDB Global Tables để có đọc ghi cục bộ nhanh ở mỗi Region — đây là phương án gần nhất và thực sự cho độ trễ thấp toàn cầu và cả GHI cục bộ, nhưng nó vi phạm ràng buộc rõ ràng nhất: đề nói "without moving away from the underlying relational database schema". DynamoDB là NoSQL — chuyển sang nó đòi thiết kế lại toàn bộ mô hình dữ liệu và viết lại ứng dụng.
• **B. Dựng EC2 ở mỗi Region, cài MySQL và di chuyển dữ liệu — công vận hành rất lớn: tự cài, tự vá lỗi, tự cấu hình sao chép giữa các Region, tự lo sẵn sàng cao. Và đồng bộ dữ liệu giữa nhiều MySQL tự quản lý là bài toán khó.
• **C. Dựng Redshift cluster ở mỗi Region — sai loại database: Redshift là kho dữ liệu phân tích (OLAP), tối ưu cho truy vấn tổng hợp trên khối lượng lớn. Nó không phù hợp với ứng dụng giao dịch (OLTP) như hệ thống quản lý kiểm soát truy cập.

Ghi nhớ

Aurora Global Database — các chỉ số chính: | Chỉ số | Giá trị | |---|---| | Độ trễ sao chép | thường dưới 1 giây | | RPO | dưới 1 giây | | RTO (managed failover) | dưới 1 phút | | Số Region phụ | tới 5 | | Reader mỗi Region | tới 16 |

Aurora và RDS — bảng phân biệt cốt lõi: | | RDS MySQL | Aurora MySQL | |---|---|---| | Sao chép | tầng database (binlog) | tầng LƯU TRỮ | | Số bản sao dữ liệu | 2 (Multi-AZ) | 6 bản qua 3 AZ | | Số read replica | 5 | 15 | | Độ trễ replica | giây | thường dưới 100ms | | Hiệu năng | chuẩn | cao hơn tới 5 lần | | Chuyển đổi | 60–120 giây | thường dưới 30 giây | | Mở rộng lưu trữ | cấp phát trước | tự động tới 128 TB |

Từ khoá nhận diện:

"relational schema", "global low-latency reads", "cross-Region" → Aurora Global Database "NoSQL", "key-value", "multi-active writes globally" → DynamoDB Global Tables "analytics", "data warehouse", "aggregate queries" → Redshift

Aurora Global Database và DynamoDB Global Tables — phân biệt: | | Aurora Global DB | DynamoDB Global Tables | |---|---|---| | Mô hình dữ liệu | quan hệ (SQL) | NoSQL key-value | | Ghi ở nhiều Region | ❌ một writer | ✅ đa ghi | | Độ trễ sao chép | dưới 1 giây | dưới 1 giây | | Phù hợp | lược đồ quan hệ có sẵn | ứng dụng mới, cần ghi toàn cầu |

Ba tính năng của Aurora Global Database: | Tính năng | Chi tiết | |---|---| | Managed planned failover | chuyển Region primary có kiểm soát | | Unplanned failover | khi Region primary hỏng | | Write forwarding | ghi từ Region phụ được chuyển tiếp về primary |

Write forwarding giúp đơn giản hoá mã ứng dụng:

SET aurora_replica_read_consistency = 'eventual';
-- Giờ ứng dụng ghi được vào endpoint của Region phụ
-- Aurora tự chuyển tiếp về primary

Lưu ý: độ trễ ghi KHÔNG giảm — lệnh vẫn phải đi về primary. Nó chỉ tiện về mặt lập trình.

Ba mức nhất quán của write forwarding: | Mức | Đặc điểm | |---|---| | eventual | nhanh nhất, có thể đọc dữ liệu cũ | | session | thấy được thay đổi của chính phiên mình | | global | thấy mọi thay đổi đã commit — chậm nhất |

Ba endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance ghi hiện tại | | Reader | cân bằng tải qua mọi reader trong Region đó | | Custom | nhóm instance do bạn định nghĩa |

Và ứng dụng phải tách rõ đường đọc và đường ghi:

# Đọc → reader endpoint của Region GẦN NHẤT
ket_noi_doc = connect(host=os.environ['DB_READER_LOCAL'])
# Ghi → writer endpoint của Region PRIMARY
ket_noi_ghi = connect(host=os.environ['DB_WRITER_PRIMARY'])

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Instance ở mỗi Region | nhân theo số Region | | Phí sao chép | theo triệu write I/O được sao chép | | Lưu trữ nhân theo Region | |

Ba cách di chuyển từ RDS MySQL sang Aurora: | Cách | Gián đoạn | |---|---| | Tạo Aurora read replica từ RDS rồi promote | rất ngắn | | Khôi phục từ snapshot | dài hơn | | AWS DMS với CDC | ngắn, phức tạp hơn |

Cách đầu tiên là đơn giản và ít gián đoạn nhất:

① Tạo Aurora read replica của RDS MySQL instance
② Chờ độ trễ sao chép về 0
③ Promote Aurora cluster thành độc lập
④ Chuyển ứng dụng sang endpoint mới

Ba việc cần làm sau khi chuyển: | Việc | Chi tiết | |---|---| | Bật Performance Insights | tìm truy vấn chậm | | Đặt Aurora Auto Scaling cho reader | co giãn theo tải | | Đo lại hiệu năng | so với trước |

Và một lời khuyên: hãy đo AuroraGlobalDBReplicationLag liên tục. Với ứng dụng kiểm soát truy cập, việc thay đổi quyền của một người phải có hiệu lực nhanh ở mọi chi nhánh — và nếu độ trễ sao chép tăng bất thường, đó là rủi ro bảo mật chứ không chỉ là vấn đề hiệu năng.