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

Tìm thấy 2194 câu.

Câu 711 Design Secure Architectures

A financial auditing firm uses Amazon S3 to store sensitive client records that are subject to write-once-read-many (WORM) regulations to prevent alteration or deletion of records for a specific retention period. The firm wants to enforce immutable storage, such that even administrators cannot overwrite or delete the records during the lock duration. They also need audit-friendly enforcement to prevent accidental or malicious deletion.

Which configuration of S3 Object Lock will ensure that the retention policy is strictly enforced, and no user (including root or administrators) can override or delete protected objects during the lock period?

  1. A

    Enable S3 Versioning and set a bucket policy that denies s3:DeleteObject to all users during the retention period
  2. B

    Use S3 Object Lock in Compliance Mode, which enforces retention policies strictly and prevents all users from modifying or deleting data during the retention period
  3. C

    Use S3 Lifecycle Policies to transition data to Glacier Deep Archive and treat it as immutable during the archival period
  4. D

    Use S3 Object Lock in Governance Mode, which allows only IAM users with elevated permissions to override or remove retention settings
Xem giải thích

Đáp án

B — Dùng S3 Object Lock ở chế độ Compliance, thực thi nghiêm ngặt chính sách giữ và ngăn MỌI người dùng sửa hoặc xoá dữ liệu trong thời hạn.

Vì sao đúng

Đề nêu yêu cầu chính xác bằng ngôn ngữ của chế độ Compliance: | Yêu cầu | Cơ chế | |---|---| | WORM (ghi một lần, đọc nhiều lần) | Object Lock | | KỂ CẢ root và quản trị viên không ghi đè được | CHỈ chế độ Compliance | | Chống xoá vô ý và cố ý | |

Hai chế độ của Object Lock — khác biệt cốt lõi:

GOVERNANCE mode:
    → người có quyền s3:BypassGovernanceRetention VẪN xoá được
    → root VẪN xoá được
        ↓
    Bảo vệ khỏi xoá NHẦM, không bảo vệ khỏi xoá CỐ Ý

COMPLIANCE mode:
    → KHÔNG AI xoá được, kể cả tài khoản ROOT
    → KHÔNG rút ngắn thời hạn được
    → kể cả AWS Support cũng không can thiệp được
        ↓
    Đề nói "including ROOT or administrators" → phải là Compliance

Cấu hình:

# Object Lock BẮT BUỘC bật lúc TẠO bucket
aws s3api create-bucket --bucket ho-so-kiem-toan   --object-lock-enabled-for-bucket   --create-bucket-configuration LocationConstraint=ap-northeast-1

aws s3api put-object-lock-configuration --bucket ho-so-kiem-toan   --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}'

Hoặc đặt cho từng object:

aws s3api put-object --bucket ho-so-kiem-toan --key ho-so-2026.pdf   --body ho-so.pdf   --object-lock-mode COMPLIANCE   --object-lock-retain-until-date 2033-08-30T00:00:00Z

Và hành vi khi cố xoá:

aws s3api delete-object --bucket ho-so-kiem-toan   --key ho-so-2026.pdf --version-id <id>

An error occurred (AccessDenied): Access Denied
    ↓
    Không có cách nào vượt qua — kể cả bằng root credential

Và Object Lock hoạt động ở cấp VERSION:

Object bị khoá không SỬA được
    → nhưng GHI ĐÈ tạo VERSION MỚI
    → version cũ VẪN CÒN và vẫn bị khoá
        ↓
    Tính bất biến được đảm bảo ở cấp phiên bản

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

  • **D. Dùng Object Lock ở chế độ GOVERNANCE, chỉ IAM user có quyền nâng cao mới ghi đè được — đây là phương án gần nhất và chỉ khác một từ, nhưng đó là từ quyết định: đề nói rõ KHÔNG AI, kể cả root, được ghi đè. Governance cho phép vượt qua.
  • **A. Bật versioning + bucket policy từ chối s3:DeleteObject — không bất biến thật sự: bucket policy sửa được bởi bất kỳ ai có quyền s3:PutBucketPolicy, và root luôn sửa được. Đây là kiểm soát truy cập, không phải bất biến.
  • **C. Dùng lifecycle chuyển sang Deep Archive và coi như bất biến — hiểu sai hoàn toàn: lifecycle chỉ đổi lớp lưu trữ, object vẫn xoá được bình thường. Không có tính bất biến nào.

Ghi nhớ

Hai chế độ Object Lock — bảng phải thuộc: | | Governance | Compliance | |---|---|---| | Người có BypassGovernanceRetention xoá được | ✅ | ❌ | | Root xoá được | ✅ | ❌ | | Rút ngắn thời hạn được | ✅ | ❌ | | Kéo dài thời hạn được | ✅ | ✅ | | Phù hợp | bảo vệ nội bộ | tuân thủ pháp lý |

Dòng "kéo dài được" đúng cho cả hai — chỉ có rút ngắn là bị cấm ở Compliance.

Từ khoá nhận diện:

"including the root user", "no one can delete", "WORM", "SEC 17a-4" → Compliance "protect from accidental deletion", "admins can override" → Governance

Ba điều kiện bắt buộc của Object Lock: | Điều kiện | Chi tiết | |---|---| | Bật LÚC TẠO bucket | KHÔNG bật sau được | | Versioning phải bật | và không tắt được nữa | | Áp cho từng VERSION | |

Dòng đầu là hạn chế nghiêm trọng nhất:

Bucket đã tồn tại mà chưa bật Object Lock
    → PHẢI tạo bucket mới và di chuyển dữ liệu
        ↓
    Quyết định này phải đúng ngay từ đầu

(AWS Support có thể bật cho bucket đã có trong một số trường hợp, nhưng đừng dựa vào điều đó khi thiết kế.)

Ba cách khai thời gian giữ: | Cách | Chi tiết | |---|---| | Default retention của bucket | áp cho object MỚI | | Retention của từng object | ghi đè mặc định | | Legal hold | giữ VÔ THỜI HẠN cho tới khi gỡ |

Legal hold là cơ chế độc lập:

aws s3api put-object-legal-hold --bucket ho-so-kiem-toan   --key ho-so.pdf --legal-hold Status=ON

Legal hold:
    → KHÔNG có thời hạn
    → độc lập với retention period
    → gỡ được bởi người có s3:PutObjectLegalHold
        ↓
    Dùng khi có tranh chấp pháp lý cần giữ chứng cứ

⚠ Ba rủi ro của chế độ Compliance: | Rủi ro | Chi tiết | |---|---| | Đặt nhầm thời hạn = trả tiền suốt thời hạn đó | không sửa được | | Không xoá được dù dữ liệu sai | | | AWS Support KHÔNG can thiệp được | |

Ví dụ hậu quả:

Đặt nhầm 70 năm thay vì 7 năm ở chế độ Compliance
    → 100 TB dữ liệu bị khoá 70 năm
    → không ai xoá được
        ↓
    Chi phí lưu trữ suốt 70 năm, không có cách hoàn tác

Vì vậy: LUÔN thử trên bucket nhỏ với thời hạn vài ngày trước.

Ba biện pháp bảo vệ dữ liệu bổ sung: | Biện pháp | Chống lại | |---|---| | Versioning | ghi đè, xoá nhầm | | MFA Delete | xoá version cần thiết bị MFA | | Replication sang tài khoản khác | mất cả tài khoản |

Object Lock và replication kết hợp được:

Bucket đích cũng bật Object Lock
    → bản sao cũng bất biến
        ↓
    Bảo vệ cả khi mất Region

Ba tiêu chuẩn tuân thủ liên quan: | Tiêu chuẩn | Yêu cầu | |---|---| | SEC Rule 17a-4(f) | WORM cho hồ sơ tài chính | | FINRA Rule 4511 | tương tự | | CFTC 1.31(c)-(d) | tương tự |

AWS đã được bên thứ ba đánh giá rằng Object Lock chế độ Compliance đáp ứng các tiêu chuẩn này.

Ba cơ chế bất biến tương tự: | Dịch vụ | Cơ chế | |---|---| | S3 | Object Lock | | AWS Backup | Vault Lock | | Glacier (nguyên bản) | Vault Lock |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Object Lock KHÔNG tính phí thêm | | | Nhưng không xoá được = trả đủ thời hạn | | | Kết hợp lifecycle sang Glacier để giảm | mã hoá và khoá vẫn giữ |

Lifecycle vẫn hoạt động với Object Lock:

{"Transitions": [{"Days": 90, "StorageClass": "DEEP_ARCHIVE"}]}

Object vẫn bất biến
    → chỉ chuyển sang lớp lưu trữ rẻ hơn
        ↓
    7 năm ở Deep Archive rẻ hơn Standard hơn 20 lần

Ba việc nên làm trước khi triển khai: | Việc | Chi tiết | |---|---| | THỬ trên bucket riêng với retention 1 ngày | | | Xác nhận thời hạn với bộ phận pháp chế | | | Tính trước tổng chi phí cả thời hạn | |

Và một lời khuyên: hãy thử toàn bộ quy trình với retention một ngày trước khi đặt bảy năm. Chế độ Compliance không có nút hoàn tác nào — một tham số gõ nhầm ở đây tạo ra ràng buộc và chi phí kéo dài đúng bằng con số bạn đã gõ, và không ai trên đời sửa được nó.

Câu 712 Design Resilient Architectures

A streaming solutions company is building a video streaming product by using an Application Load Balancer (ALB) that routes the requests to the underlying Amazon EC2 instances. The engineering team has noticed a peculiar pattern. The Application Load Balancer removes an instance from its pool of healthy instances whenever it is detected as unhealthy but the Auto Scaling group fails to kick-in and provision the replacement instance.

What could explain this anomaly?

  1. A

    Both the Auto Scaling group and Application Load Balancer are using Amazon EC2 based health check
  2. B

    Both the Auto Scaling group and Application Load Balancer are using ALB based health check
  3. C

    The Auto Scaling group is using ALB based health check and the Application Load Balancer is using Amazon EC2 based health check
  4. D

    The Auto Scaling group is using Amazon EC2 based health check and the Application Load Balancer is using ALB based health check
Xem giải thích

Đáp án

D — Auto Scaling group dùng health check kiểu EC2, còn Application Load Balancer dùng health check của ALB.

Vì sao đúng

Đề mô tả nghịch lý: ALB rút máy khỏi pool, nhưng ASG không thay máy. Nguyên nhân là hai bên đang đánh giá sức khoẻ theo hai tiêu chí khác nhau.

Cơ chế:

ALB dùng health check của nó (gọi HTTP tới đường dẫn ứng dụng):
    → ứng dụng không phản hồi đúng
    → ALB đánh dấu UNHEALTHY và ngừng gửi lưu lượng ✓

ASG dùng health check kiểu EC2 (status check của instance):
    → máy vẫn CHẠY, hệ điều hành vẫn phản hồi
    → ASG thấy máy KHOẺ
        ↓
    ASG KHÔNG thay máy
    → máy nằm đó, không phục vụ, không bị thay

Đây chính là hiện tượng trong đề.

Hai loại health check của ASG: | Loại | Kiểm tra | |---|---| | EC2 (mặc định) | status check của instance — máy có chạy không | | ELB | thêm đánh giá của load balancer — ỨNG DỤNG có khoẻ không |

Sửa:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-streaming   --health-check-type ELB   --health-check-grace-period 300

Sau khi đổi:

ALB đánh dấu target unhealthy
    → ASG cũng coi instance đó là unhealthy
    → ASG chấm dứt và khởi động máy thay thế
        ↓
    Tự phục hồi hoàn chỉnh

Và HealthCheckGracePeriod phải đủ dài:

Máy mới cần thời gian khởi động ứng dụng
    → trong khoảng grace period, ASG BỎ QUA kết quả health check
        ↓
    Grace period quá ngắn → máy mới bị đánh giá hỏng trước khi sẵn sàng
    → ASG chấm dứt và tạo máy khác
    → VÒNG LẶP VÔ TẬN

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

  • **A. Cả hai đều dùng health check kiểu EC2 — đây là phương án gần nhất vì cũng nói ASG dùng EC2 health check, nhưng nó mâu thuẫn với triệu chứng: nếu ALB dùng EC2 health check thì nó đã không phát hiện được ứng dụng hỏng để rút máy ra. Đề nói rõ ALB có rút máy.
  • **B. Cả hai đều dùng health check của ALB — thì sự cố đã không xảy ra: ASG với HealthCheckType = ELB sẽ thay máy ngay khi ALB đánh dấu unhealthy.
  • **C. ASG dùng ALB health check, ALB dùng EC2 health check — đảo ngược và không đúng thực tế: ALB luôn dùng health check riêng của nó, không có tuỳ chọn "EC2 health check".

Ghi nhớ

Hai loại health check của ASG — bảng phải thuộc: | Loại | Kiểm tra | Phát hiện được | |---|---|---| | EC2 (mặc định) | status check của instance | máy chết, hệ điều hành treo | | ELB | EC2 + đánh giá của load balancer | ứng dụng hỏng dù máy vẫn chạy |

Quy tắc: mọi ASG đứng sau load balancer nên dùng ELB.

Ba loại status check của EC2: | Loại | Kiểm tra | |---|---| | StatusCheckFailed_Instance | hệ điều hành, mạng của instance | | StatusCheckFailed_System | hạ tầng AWS bên dưới | | StatusCheckFailed_AttachedEBS | volume EBS |

Ba tình huống mà EC2 health check KHÔNG phát hiện được: | Tình huống | Vì sao | |---|---| | Tiến trình ứng dụng chết | máy vẫn chạy | | Ứng dụng treo, không phản hồi | hệ điều hành vẫn khoẻ | | Ứng dụng trả lỗi 500 | |

Đây là ba lý do phải dùng ELB.

Ba tham số health check của ASG: | Tham số | Chi tiết | |---|---| | HealthCheckType | EC2 hoặc ELB | | HealthCheckGracePeriod | đủ dài cho thời gian khởi động | | DefaultInstanceWarmup | thay thế mới hơn cho grace period |

Ba tham số health check của target group: | Tham số | Chi tiết | |---|---| | HealthCheckPath | đường dẫn ALB gọi tới | | Matcher | mã HTTP coi là khoẻ | | UnhealthyThresholdCount | số lần thất bại để đánh dấu hỏng |

Ba nguyên tắc thiết kế endpoint health check: | Nguyên tắc | Chi tiết | |---|---| | Kiểm tra ĐƯỜNG ĐI THẬT của ứng dụng | không trả 200 tĩnh | | Nhưng ĐỪNG kiểm tra quá sâu | phụ thuộc bên ngoài hỏng → MỌI máy bị đánh dấu hỏng | | Phản hồi nhanh | dưới thời gian timeout |

Dòng giữa là cạm bẫy nghiêm trọng:

/health kiểm tra cả kết nối database
    → database chậm một lúc
    → MỌI máy trả health check thất bại
    → ASG chấm dứt TOÀN BỘ đội máy
        ↓
    Một sự cố nhỏ biến thành sự cố toàn diện

Thiết kế an toàn:

/health       → kiểm tra ứng dụng đã khởi tạo xong (cho ALB và ASG)
/health/deep  → kiểm tra cả phụ thuộc (cho giám sát, KHÔNG cho health check)

Ba nguyên nhân vòng lặp thay máy: | Nguyên nhân | Dấu hiệu | |---|---| | Grace period quá ngắn | máy bị thay ngay sau khi khởi động | | Đường dẫn health check sai | mọi máy đều unhealthy | | Ứng dụng thật sự hỏng | log ứng dụng có lỗi |

Kiểm tra lịch sử hoạt động của ASG:

aws autoscaling describe-scaling-activities   --auto-scaling-group-name asg-streaming --max-items 20

Nó ghi rõ lý do:
    "an instance was taken out of service in response to
     an ELB system health check failure"

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | describe-target-health | lý do cụ thể từng target | | describe-scaling-activities | vì sao ASG thay máy | | CloudWatch HealthyHostCount | |

Ba lưu ý về deregistration delay: | Lưu ý | Chi tiết | |---|---| | Mặc định 300 giây | | | Đặt bằng thời gian request dài nhất | tránh cắt request đang chạy | | Quá dài làm việc thay máy chậm | |

Ba lưu ý về lifecycle hook: | Lưu ý | Chi tiết | |---|---| | TERMINATING hook cho phép dọn dẹp | đẩy log, hoàn tất việc | | LAUNCHING hook cho phép cấu hình thêm | | | Phải gọi complete-lifecycle-action | không thì chờ hết timeout |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyHostCount của target group | số máy đang phục vụ | | GroupInServiceInstances | số máy ASG coi là khoẻ | | — | hai số này LỆCH nhau là dấu hiệu của sự cố trong đề |

Và một lời khuyên: hãy đặt alarm khi HealthyHostCount và GroupInServiceInstances chênh nhau. Đó là chữ ký chính xác của tình huống trong đề — ASG tin rằng mọi máy đều khoẻ trong khi load balancer đã rút một nửa ra khỏi vòng phục vụ, và không có cảnh báo nào khác cho bạn biết điều đó.

Câu 713 Design High-Performing Architectures

An application with global users across AWS Regions had suffered an issue when the Elastic Load Balancing (ELB) in a Region malfunctioned thereby taking down the traffic with it. The manual intervention cost the company significant time and resulted in major revenue loss.

What should a solutions architect recommend to reduce internet latency and add automatic failover across AWS Regions?

  1. A

    Set up an Amazon Route 53 geoproximity routing policy to route traffic
  2. B

    Set up AWS Direct Connect as the backbone for each of the AWS Regions where the application is deployed
  3. C

    Set up AWS Global Accelerator and add endpoints to cater to users in different geographic locations
  4. D

    Create Amazon S3 buckets in different AWS Regions and configure Amazon CloudFront to pick the nearest edge location to the user
Xem giải thích

Đáp án

C — Dựng AWS Global Accelerator và thêm endpoint để phục vụ người dùng ở các khu vực địa lý khác nhau.

Vì sao đúng

Đề nêu hai yêu cầu, và Global Accelerator đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Giảm độ trễ Internet | lưu lượng vào mạng riêng AWS ở edge gần nhất | | Chuyển vùng TỰ ĐỘNG xuyên Region | health check + định tuyến lại trong ~30 giây |

Và sự cố trong đề chính là thứ Global Accelerator giải quyết:

"ELB in a Region MALFUNCTIONED, taking down the traffic with it"
"MANUAL INTERVENTION cost significant time"
        ↓
    Global Accelerator theo dõi sức khoẻ endpoint
    → endpoint hỏng → tự định tuyến sang Region khác
    → KHÔNG cần can thiệp thủ công

Vì sao chuyển vùng của Global Accelerator nhanh hơn DNS:

Route 53 failover:
    → đổi bản ghi DNS
    → client phải chờ TTL hết hạn
    → và nhiều trình phân giải bỏ qua TTL thấp
        ↓
    Thời gian thực tế: vài phút tới hàng chục phút

Global Accelerator:
    → IP anycast KHÔNG ĐỔI
    → chỉ đổi đích phía sau
        ↓
    Client không phải phân giải lại gì
    → chuyển vùng ~30 giây

Triển khai:

aws globalaccelerator create-accelerator --name ung-dung-toan-cau --enabled

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

# Endpoint group cho mỗi Region
aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region ap-northeast-1   --endpoint-configurations EndpointId=<arn-alb-tokyo>,Weight=128   --health-check-interval-seconds 10 --threshold-count 3

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region eu-west-1   --endpoint-configurations EndpointId=<arn-alb-ireland>,Weight=128

Và ba lợi ích cùng lúc: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp hơn | mạng riêng của AWS | | Chuyển vùng tự động | ← giải quyết sự cố trong đề | | 2 IP tĩnh | cho danh sách trắng tường lửa |

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

  • **A. Route 53 geoproximity routing — đây là phương án gần nhất vì cũng định tuyến người dùng toàn cầu, nhưng nó chuyển vùng chậm hơn nhiều: DNS phụ thuộc TTL và bộ đệm của trình phân giải, nên thời gian phục hồi tính bằng phút chứ không phải giây. Và geoproximity định tuyến theo vị trí chứ không tối ưu độ trễ mạng.
  • **D. Tạo S3 bucket ở nhiều Region với CloudFront chọn edge gần nhất — chỉ phục vụ nội dung TĨNH: S3 không chạy được ứng dụng động. Đề nói tới một ứng dụng, không phải một website tĩnh.
  • **B. Dùng Direct Connect làm backbone cho mỗi Region — sai công cụ: Direct Connect nối on-premises với AWS. Nó không giải quyết độ trễ cho người dùng Internet toàn cầu và không có cơ chế chuyển vùng ứng dụng.

Ghi nhớ

Ba cách định tuyến người dùng toàn cầu — bảng phải thuộc: | Cách | Chuyển vùng | Giao thức | |---|---|---| | Global Accelerator | ~30 giây, KHÔNG đụng DNS | TCP, UDP | | Route 53 failover | phụ thuộc TTL — phút | mọi thứ (chỉ DNS) | | CloudFront | theo origin failover | HTTP/HTTPS |

Từ khoá nhận diện:

"automatic failover across Regions", "fast", "static IP", "UDP" → Global Accelerator "DNS-based routing", "geolocation compliance" → Route 53 "cache static content globally" → CloudFront

Global Accelerator và CloudFront — bảng phân biệt: | | Global Accelerator | CloudFront | |---|---|---| | Caching | ❌ | ✅ | | Giao thức | TCP và UDP, mọi cổng | HTTP/HTTPS | | Địa chỉ | 2 IP anycast tĩnh | tên miền | | Nội dung động | tối ưu cho việc này | có nhưng không đệm |

Ba khái niệm của Global Accelerator: | Khái niệm | Việc | |---|---| | Accelerator | mang 2 IP tĩnh | | Listener | cổng và giao thức | | Endpoint group | một Region, có traffic dial và health check |

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

Ba tham số health check: | Tham số | Mặc định | |---|---| | HealthCheckIntervalSeconds | 30 (đặt được 10) | | ThresholdCount | 3 | | — | thời gian phát hiện ≈ interval × threshold |

Đặt interval 10 giây, threshold 3 → phát hiện trong ~30 giây.

Ba lợi ích của IP anycast tĩnh: | Lợi ích | Chi tiết | |---|---| | Chuyển vùng KHÔNG cần đổi DNS | ← lý do nhanh hơn Route 53 | | Đưa vào danh sách trắng tường lửa | | | Thêm Region không đổi IP | |

Ba loại endpoint được hỗ trợ: | Endpoint | Hỗ trợ | |---|---| | Application Load Balancer | ✅ | | Network Load Balancer | ✅ | | EC2 instance | ✅ | | Elastic IP | ✅ |

Traffic dial cho triển khai dần và rút Region:

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

Đặt 0 để rút một Region ra NGAY LẬP TỨC
    → hữu ích khi bảo trì có kế hoạch

Ba chính sách định tuyến của Route 53 để so sánh: | Chính sách | Việc | |---|---| | Failover | active-passive | | Latency-based | Region có độ trễ thấp nhất | | Geoproximity | theo khoảng cách, có bias | | Geolocation | theo quốc gia của người dùng |

Geolocation dùng cho yêu cầu pháp lý — ví dụ dữ liệu người dùng châu Âu phải xử lý ở châu Âu.

Ba lưu ý về kiến trúc đa Region: | Lưu ý | Chi tiết | |---|---| | Dữ liệu phải sao chép | Aurora Global, DynamoDB Global Tables | | AMI phải có ở mọi Region | | | Diễn tập chuyển vùng định kỳ | |

Dòng đầu là phần khó nhất:

Global Accelerator chuyển lưu lượng sang Region khác trong 30 giây
    → nhưng nếu database ở Region đó chưa sẵn sàng
    → ứng dụng vẫn lỗi
        ↓
    Tầng dữ liệu phải sẵn sàng TRƯỚC

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

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyEndpointCount | Region nào đang phục vụ | | NewFlowCount | kết nối mới | | ProcessedBytesIn/Out | lưu lượng |

Ba biện pháp bảo mật đi kèm: | Biện pháp | Chi tiết | |---|---| | AWS Shield Standard tự động | chống DDoS tầng 3/4 | | WAF trên ALB phía sau | WAF KHÔNG gắn vào GA được | | Security group trên ALB | |

Và một lời khuyên: hãy diễn tập chuyển vùng bằng cách đặt traffic dial của một Region về 0 ít nhất mỗi quý. Cơ chế chuyển vùng của Global Accelerator hoạt động đáng tin cậy, nhưng thứ hay hỏng là tầng phía sau — database chưa promote, cấu hình thiếu, hạn mức chưa nâng — và những thứ đó chỉ lộ ra khi bạn thật sự dồn toàn bộ lưu lượng sang.

Câu 714 Design High-Performing Architectures

A mobile-based e-learning platform is migrating its backend storage layer to Amazon DynamoDB to support a rapidly increasing number of student users and learning transactions. The platform must ensure seamless availability and minimal disruption for a global user base. The DynamoDB design must provide low-latency performance, high availability, and automatic fault tolerance across geographies with the lowest possible operational overhead and cost.

Which solution will fulfill these needs in the most cost-efficient manner?

  1. A

    Enable DynamoDB Accelerator (DAX) to reduce response time for read operations. Deploy DAX in one Region, and use scheduled Lambda functions to replicate data to other Regions
  2. B

    Create separate DynamoDB tables in multiple Regions. Use AWS Data Pipeline to synchronize data periodically between Regions to maintain availability
  3. C

    Deploy separate DynamoDB tables in each required AWS Region using on-demand capacity mode. Implement a custom cross-Region replication mechanism by streaming data changes with DynamoDB Streams and processing them through AWS Lambda functions
  4. D

    Use DynamoDB global tables for automatic multi-Region replication. Enable provisioned capacity mode with auto scaling to optimize cost and ensure consistent availability
Xem giải thích

Đáp án

D — Dùng DynamoDB global tables để tự sao chép đa Region; bật chế độ provisioned kèm auto scaling để tối ưu chi phí và đảm bảo sẵn sàng ổn định.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án D đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Độ trễ thấp cho người dùng toàn cầu | bản sao ở mỗi Region, đọc và ghi cục bộ | | Sẵn sàng cao, chịu lỗi tự động | global table sao chép hai chiều tự động | | Công vận hành thấp nhất | AWS lo toàn bộ việc sao chép | | Chi phí thấp nhất | provisioned + auto scaling rẻ hơn on-demand |

Vế cuối là điểm phân biệt so với phương án C:

On-demand: tiện nhất, nhưng ĐẮT HƠN provisioned ~5–7 lần
           khi tải đã có mẫu ổn định

Provisioned + auto scaling:
    → tự điều chỉnh dung lượng theo tải
    → nhưng vẫn hưởng đơn giá thấp của provisioned
        ↓
    Với nền tảng học tập đang lớn dần (tải tăng đều,
    có chu kỳ theo giờ học), đây là lựa chọn kinh tế hơn

Tạo global table:

aws dynamodb create-table --table-name tien-do-hoc   --attribute-definitions AttributeName=ma_hoc_vien,AttributeType=S                           AttributeName=ma_bai_hoc,AttributeType=S   --key-schema AttributeName=ma_hoc_vien,KeyType=HASH                 AttributeName=ma_bai_hoc,KeyType=RANGE   --billing-mode PROVISIONED   --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=50   --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws dynamodb update-table --table-name tien-do-hoc   --replica-updates '[{"Create":{"RegionName":"eu-west-1"}},
                      {"Create":{"RegionName":"us-east-1"}}]'

Và bật auto scaling:

aws application-autoscaling register-scalable-target   --service-namespace dynamodb   --resource-id "table/tien-do-hoc"   --scalable-dimension "dynamodb:table:WriteCapacityUnits"   --min-capacity 20 --max-capacity 4000

aws application-autoscaling put-scaling-policy   --service-namespace dynamodb   --resource-id "table/tien-do-hoc"   --scalable-dimension "dynamodb:table:WriteCapacityUnits"   --policy-name theo-muc-dung --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "DynamoDBWriteCapacityUtilization"}}'

Lưu ý: với global table, auto scaling phải bật ở MỖI Region.

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

  • **C. Triển khai bảng riêng ở mỗi Region với on-demand, tự viết cơ chế sao chép bằng DynamoDB Streams và Lambda — đây là phương án gần nhất và về mặt kỹ thuật là mô tả chính xác cách global table hoạt động bên trong, nhưng nó bắt bạn tự dựng lại thứ AWS đã làm sẵn: phải xử lý xung đột, thứ tự, vòng lặp sao chép, thử lại. Đi ngược yêu cầu "lowest operational overhead".
  • **A. Bật DAX ở một Region và dùng Lambda theo lịch sao chép sang Region khác — hai lỗi: DAX chỉ là bộ đệm đọc, không giải quyết đa Region; và sao chép theo lịch nghĩa là dữ liệu ở Region khác luôn cũ.
  • **B. Bảng riêng ở nhiều Region, đồng bộ định kỳ bằng AWS Data Pipeline — độ trễ rất cao và dịch vụ đã lỗi thời: Data Pipeline xử lý theo lô, không phù hợp với đồng bộ gần thời gian thực. (AWS đã ngừng nhận khách hàng mới cho Data Pipeline.)

Ghi nhớ

Ba yêu cầu của DynamoDB global table: | Yêu cầu | Chi tiết | |---|---| | DynamoDB Streams bật | NEW_AND_OLD_IMAGES | | Cùng tên bảng ở mọi Region | | | Cùng schema khoá | |

Ba đặc điểm của global table: | Đặc điểm | Chi tiết | |---|---| | Ghi được ở MỌI Region | active-active | | Sao chép thường dưới một giây | bất đồng bộ | | Xung đột: last writer wins | dựa trên timestamp |

Hai chế độ dung lượng — bảng phải thuộc: | | On-demand | Provisioned | |---|---|---| | Tính phí | theo request | theo dung lượng cấp | | Phản ứng đỉnh đột ngột | tức thì | chậm (auto scaling) | | Chi phí khi tải ổn định | cao hơn ~5–7 lần | thấp hơn | | Cần dự đoán tải | ❌ | ✅ |

Quy tắc chọn:

Tải mới, khó đoán, đỉnh đột ngột → on-demand Tải có mẫu, đã đo được → provisioned + auto scaling

Và đổi chế độ được, nhưng chỉ MỘT LẦN mỗi 24 giờ:

aws dynamodb update-table --table-name tien-do-hoc   --billing-mode PAY_PER_REQUEST

Ba tham số auto scaling của DynamoDB: | Tham số | Chi tiết | |---|---| | TargetValue | thường 70% — chừa biên cho đỉnh | | MinCapacity | không xuống dưới | | MaxCapacity | trần — chạm trần là bị throttle |

Auto scaling có độ trễ:

CloudWatch alarm cần vài phút để kích hoạt
    → đỉnh tải đột ngột vẫn có thể bị throttle
        ↓
    Đặt MinCapacity đủ cao cho tải nền
    → và TargetValue không quá sát 100%

Ba lưu ý về chi phí global table: | Khoản | Chi tiết | |---|---| | Mỗi Region tính dung lượng RIÊNG | | | Ghi tính bằng rWCU | đắt hơn WCU thường | | Truyền dữ liệu xuyên Region | |

Phép tính:

3 Region, 1 triệu ghi/tháng ở mỗi Region:
    → mỗi ghi sao chép sang 2 Region khác
    → tổng khoảng 3 triệu thao tác ghi
        ↓
    Chi phí ghi gần gấp 3 so với một Region

Ba chiến lược tránh xung đột: | Chiến lược | Chi tiết | |---|---| | Phân vùng theo Region | học viên chỉ ghi ở Region của mình | | Item bất biến, chỉ thêm mới | event sourcing | | Khoá logic ở tầng ứng dụng | phức tạp |

Chiến lược đầu rất tự nhiên với nền tảng học tập:

Tiến độ học của một học viên chỉ được ghi
  từ Region gần họ nhất
    → xung đột gần như không bao giờ xảy ra
        ↓
    Vẫn đọc được từ mọi Region

Ba tính năng nên bật: | Tính năng | Chi tiết | |---|---| | Point-in-time recovery | bật RIÊNG ở mỗi Region | | Deletion protection | miễn phí | | TTL | dữ liệu phiên học có hạn |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicationLatency | độ trễ sao chép | | ThrottledRequests | bị giới hạn — dung lượng chưa đủ | | ConsumedWriteCapacityUnits | mức dùng thật |

Ba nguyên tắc thiết kế bảng: | Nguyên tắc | Chi tiết | |---|---| | Partition key phân bố đều | mã học viên là lựa chọn tốt | | Sort key cho truy vấn khoảng | mã bài học, dấu thời gian | | Tránh scan | thiết kế để luôn dùng được Query |

Ba giới hạn cần nhớ: | Giới hạn | Giá trị | |---|---| | Kích thước item | 400 KB | | Thông lượng mỗi partition | 3.000 RCU hoặc 1.000 WCU | | Số GSI mỗi bảng | 20 |

Ba cách giảm chi phí thêm: | Cách | Tiết kiệm | |---|---| | DynamoDB reserved capacity | tới 77% cho provisioned | | TTL xoá dữ liệu cũ | miễn phí, không tốn WCU | | Chỉ sao chép sang Region THẬT SỰ cần | |

Reserved capacity đáng cân nhắc:

Cam kết 1 hoặc 3 năm cho mức dung lượng nền
    → giảm tới 77%
        ↓
    Kết hợp: reserved cho nền + auto scaling cho đỉnh

Và một lời khuyên: hãy chạy on-demand vài tháng đầu rồi mới chuyển sang provisioned. Nền tảng đang tăng trưởng nhanh chưa có mẫu tải ổn định, và đoán sai dung lượng provisioned dẫn tới throttle ngay trong giờ học cao điểm — còn on-demand đắt hơn nhưng cho bạn dữ liệu thật để tính toán.

Câu 715 Design Secure Architectures

An application hosted on Amazon EC2 contains sensitive personal information about all its customers and needs to be protected from all types of cyber-attacks. The company is considering using the AWS Web Application Firewall (AWS WAF) to handle this requirement.

Can you identify the correct solution leveraging the capabilities of AWS WAF?

  1. A

    Configure an Application Load Balancer (ALB) to balance the workload for all the Amazon EC2 instances. Configure Amazon CloudFront to distribute from an Application Load Balancer since AWS WAF cannot be directly configured on ALB. This configuration not only provides necessary safety but is scalable too
  2. B

    AWS WAF can be directly configured only on an Application Load Balancer or an Amazon API Gateway. One of these two services can then be configured with Amazon EC2 to build the needed secure architecture
  3. C

    Create Amazon CloudFront distribution for the application on Amazon EC2 instances. Deploy AWS WAF on Amazon CloudFront to provide the necessary safety measures
  4. D

    AWS WAF can be directly configured on Amazon EC2 instances for ensuring the security of the underlying application data
Xem giải thích

Đáp án

C — Tạo CloudFront distribution cho ứng dụng chạy trên EC2, triển khai AWS WAF trên CloudFront để có được biện pháp bảo vệ cần thiết.

Vì sao đúng

Đề nêu một ràng buộc quan trọng: ứng dụng chạy trực tiếp trên EC2.

AWS WAF KHÔNG gắn trực tiếp vào EC2 được
    → phải có một dịch vụ ở phía trước
        ↓
    Các lựa chọn: CloudFront, ALB, API Gateway

Và CloudFront là lựa chọn hợp lý ở đây:

CloudFront với custom origin trỏ tới EC2
    → WAF gắn vào CloudFront
    → tấn công bị chặn TẠI BIÊN, gần người tấn công
        ↓
    Lưu lượng độc hại không bao giờ tới EC2

Cấu hình:

# Web ACL cho CloudFront phải tạo ở us-east-1
aws wafv2 create-web-acl --name acl-bao-ve-du-lieu   --scope CLOUDFRONT --region us-east-1   --default-action Allow={}   --rules '[
    {"Name":"quy-tac-chung","Priority":1,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesCommonRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"chung"}},
    {"Name":"chan-sqli","Priority":2,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesSQLiRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"sqli"}}]'   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=aclBaoVe

Và ba lợi ích phụ của CloudFront: | Lợi ích | Chi tiết | |---|---| | Đệm nội dung tĩnh | giảm tải EC2 | | Kết thúc TLS ở biên | giảm độ trễ | | AWS Shield Standard tự động | chống DDoS |

Và phải chặn truy cập thẳng vào EC2:

Không chặn:
    → kẻ tấn công gọi thẳng IP của EC2
    → BỎ QUA CloudFront và WAF hoàn toàn
        ↓
    Security group của EC2 chỉ cho phép prefix list của CloudFront

aws ec2 authorize-security-group-ingress --group-id sg-ec2   --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,
    PrefixListIds=[{PrefixListId=pl-58a04531}]'

Đây là bước bắt buộc mà nhiều người quên — không có nó thì WAF chỉ là trang trí.

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

  • **A. Dùng ALB cân bằng tải, rồi CloudFront phân phối từ ALB "vì WAF KHÔNG cấu hình trực tiếp trên ALB được" — đây là phương án gần nhất và kiến trúc mô tả hoàn toàn hợp lệ, nhưng mệnh đề giải thích SAI: AWS WAF gắn trực tiếp vào ALB được từ năm 2016. Phương án dựa trên một tiền đề sai.
  • **B. "WAF chỉ cấu hình trực tiếp được trên ALB hoặc API Gateway" — thiếu sót: WAF còn gắn được vào CloudFront, AppSync, Cognito user pool, App Runner và Verified Access. Chữ "chỉ" khiến mệnh đề sai.
  • **D. WAF cấu hình trực tiếp trên EC2 — sai về mặt kỹ thuật: WAF không gắn vào EC2 instance được.

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

Câu này có hai phương án chứa mệnh đề sai về khả năng của WAF, và điều đó khiến đề dễ gây nhầm.

Danh sách đầy đủ tài nguyên gắn được AWS WAF: | Tài nguyên | Scope | |---|---| | Amazon CloudFront | CLOUDFRONT (tạo ở us-east-1) | | Application Load Balancer | REGIONAL | | Amazon API Gateway (REST API) | REGIONAL | | AWS AppSync | REGIONAL | | Amazon Cognito user pool | REGIONAL | | AWS App Runner | REGIONAL | | AWS Verified Access | REGIONAL |

KHÔNG gắn được: EC2 trực tiếp, Network Load Balancer, Gateway Load Balancer.

Phương án A nói "WAF không cấu hình trực tiếp trên ALB" — sai. Phương án B nói "chỉ ALB hoặc API Gateway" — cũng sai vì bỏ sót CloudFront. Đáp án C đúng, nhưng nó đúng vì kiến trúc hợp lý, không phải vì các phương án kia bất khả thi về kỹ thuật.

Trong thực tế, với ứng dụng trên EC2, cả hai kiến trúc sau đều hợp lệ:

① EC2 → ALB (có WAF)
② EC2 → ALB → CloudFront (có WAF ở biên)  ← tốt hơn

Cách thứ hai chặn tấn công gần người tấn công hơn và có thêm lợi ích đệm.

Ghi nhớ

Ba tấn công web phổ biến WAF chặn được: | Tấn công | Managed rule group | |---|---| | SQL injection | AWSManagedRulesSQLiRuleSet | | Cross-site scripting | AWSManagedRulesCommonRuleSet | | Đầu vào độc hại đã biết | AWSManagedRulesKnownBadInputsRuleSet | | Bot | AWSManagedRulesBotControlRuleSet (có phí) |

Ba loại statement hay dùng: | Statement | Việc | |---|---| | Managed rule group | bộ quy tắc do AWS duy trì | | Rate-based | giới hạn request mỗi IP | | Geo match, IP set | theo quốc gia hoặc IP |

Ba hành động của rule: | Hành động | Chi tiết | |---|---| | Allow | cho qua, dừng đánh giá | | Block | chặn, dừng đánh giá | | Count | chỉ đếm — dùng để THỬ an toàn |

Luôn thử bằng Count trước khi Block:

Managed rule có thể chặn nhầm request hợp lệ
    → chạy Count vài ngày
    → xem sampled requests trong console
        ↓
    Xác nhận rồi mới bật Block

Ba lớp bảo vệ nên có cho ứng dụng chứa dữ liệu cá nhân: | Lớp | Cơ chế | |---|---| | Tầng mạng | security group, NACL, private subnet | | Tầng ứng dụng | WAF ← câu này | | Tầng dữ liệu | mã hoá at rest và in transit |

Ba biện pháp bảo vệ dữ liệu cá nhân: | Biện pháp | Chi tiết | |---|---| | Mã hoá EBS và RDS bằng KMS | | | TLS cho mọi kết nối | | | Amazon Macie quét S3 tìm PII | |

Ba dịch vụ bảo mật bổ sung: | Dịch vụ | Việc | |---|---| | GuardDuty | phát hiện hành vi bất thường | | Inspector | lỗ hổng phần mềm trên EC2 | | Security Hub | tổng hợp phát hiện |

Ba cách chặn bỏ qua CloudFront: | Cách | Chi tiết | |---|---| | Security group chỉ cho prefix list CloudFront | đơn giản nhất | | Header bí mật do CloudFront thêm | WAF ở ALB kiểm tra | | VPC origin | tính năng mới, origin không cần IP công cộng |

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

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BlockedRequests | tăng đột biến = đang bị tấn công | | AllowedRequests | | | CountedRequests | rule đang ở chế độ thử |

Ba lưu ý về log của WAF: | Lưu ý | Chi tiết | |---|---| | Gửi vào S3, CloudWatch Logs hoặc Firehose | | | Che trường nhạy cảm | mật khẩu, token | | Sampled requests xem ngay trong console | không cần bật log |

Và một lời khuyên: hãy khoá security group của EC2 chỉ cho phép prefix list của CloudFront ngay sau khi dựng distribution. Một WAF hoàn hảo ở biên không có giá trị gì nếu địa chỉ IP gốc của máy chủ vẫn nhận request trực tiếp — và địa chỉ đó thường lộ ra qua bản ghi DNS cũ, header email, hoặc chứng chỉ TLS.

Câu 716 Design High-Performing Architectures

A leading media company wants to do an accelerated online migration of hundreds of terabytes of files from their on-premises data center to Amazon S3 and then establish a mechanism to access the migrated data for ongoing updates from the on-premises applications.

As a solutions architect, which of the following would you select as the MOST performant solution for the given use-case?

  1. A

    Use File Gateway configuration of AWS Storage Gateway to migrate data to Amazon S3 and then use Amazon S3 Transfer Acceleration (Amazon S3TA) for ongoing updates from the on-premises applications
  2. B

    Use AWS DataSync to migrate existing data to Amazon S3 as well as access the Amazon S3 data for ongoing updates
  3. C

    Use Amazon S3 Transfer Acceleration (Amazon S3TA) to migrate existing data to Amazon S3 and then use AWS DataSync for ongoing updates from the on-premises applications
  4. D

    Use AWS DataSync to migrate existing data to Amazon S3 and then use File Gateway to retain access to the migrated data for ongoing updates from the on-premises applications
Xem giải thích

Đáp án

D — Dùng AWS DataSync để di chuyển dữ liệu hiện có sang S3, rồi dùng File Gateway để giữ quyền truy cập dữ liệu đã di chuyển cho các cập nhật liên tục từ ứng dụng tại chỗ.

Vì sao đúng

Đề nêu hai giai đoạn với hai nhu cầu khác nhau, và mỗi giai đoạn có công cụ đúng: | Giai đoạn | Nhu cầu | Công cụ | |---|---|---| | Di chuyển hàng trăm TB ban đầu | tốc độ tối đa | AWS DataSync | | Truy cập liên tục sau đó | giao diện tệp có cache | S3 File Gateway |

DataSync cho việc di chuyển:

AWS DataSync:
    ✓ giao thức truyền tối ưu riêng của AWS
    ✓ nhanh hơn công cụ chép tệp thông thường tới 10 lần
    ✓ song song hoá, nén, kiểm tra toàn vẹn tự động
    ✓ chạy theo lịch hoặc một lần
        ↓
    Được thiết kế riêng cho di chuyển khối lượng lớn

File Gateway cho truy cập liên tục:

S3 File Gateway:
    ✓ xuất NFS/SMB share tại chỗ
    ✓ CACHE cục bộ cho tệp hay dùng
    ✓ ghi vào share tự đẩy lên S3
        ↓
    Ứng dụng tại chỗ dùng như thư mục mạng bình thường

Và đây là mẫu kết hợp được AWS khuyến nghị:

DataSync: chuyển KHỐI LƯỢNG LỚN một lần (nhanh)
    ↓
File Gateway: TRUY CẬP LIÊN TỤC sau đó (có cache)
        ↓
    Mỗi công cụ làm đúng việc nó được thiết kế cho

Triển khai DataSync:

aws datasync create-location-nfs   --server-hostname 192.168.1.100 --subdirectory /du-lieu   --on-prem-config AgentArns=<arn-agent>

aws datasync create-location-s3   --s3-bucket-arn arn:aws:s3:::kho-media   --s3-config BucketAccessRoleArn=<arn-role>

aws datasync create-task   --source-location-arn <arn-nfs> --destination-location-arn <arn-s3>   --options VerifyMode=POINT_IN_TIME_CONSISTENT,TransferMode=CHANGED,PreserveDeletedFiles=PRESERVE

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

  • **C. Dùng S3 Transfer Acceleration để di chuyển, rồi DataSync cho cập nhật liên tục — đây là phương án gần nhất và đảo đúng hai công cụ: Transfer Acceleration tăng tốc tải lên nhưng chậm hơn DataSync nhiều cho khối lượng lớn (nó không song song hoá và không tối ưu giao thức). Và DataSync là công cụ đồng bộ theo lịch, không phải giao diện truy cập liên tục.
  • **B. Dùng DataSync cho cả hai việc — DataSync không phải giao diện truy cập: nó đồng bộ theo lịch, ứng dụng tại chỗ không mount được nó như một thư mục.
  • **A. Dùng File Gateway để di chuyển, rồi Transfer Acceleration cho cập nhật — File Gateway không tối ưu cho di chuyển khối lượng lớn: nó được thiết kế cho truy cập liên tục, và đẩy hàng trăm TB qua nó chậm hơn DataSync đáng kể.

Ghi nhớ

AWS DataSync và Storage Gateway — bảng phải thuộc: | | DataSync | Storage Gateway | |---|---|---| | Mục đích | DI CHUYỂN dữ liệu | TRUY CẬP liên tục | | Cache cục bộ | ❌ | ✅ | | Chạy | theo lịch hoặc một lần | liên tục | | Giao diện tại chỗ | ❌ | NFS, SMB, iSCSI | | Tốc độ di chuyển | rất cao | vừa |

Từ khoá nhận diện:

"migrate", "one-time transfer", "sync on schedule" → DataSync "ongoing access", "on-premises applications need the files" → Storage Gateway "both" → DataSync trước, Storage Gateway sau ← câu này

Ba đặc điểm của AWS DataSync: | Đặc điểm | Chi tiết | |---|---| | Nhanh hơn công cụ thông thường tới 10 lần | giao thức riêng | | Kiểm tra toàn vẹn tự động | checksum mọi tệp | | Bảo toàn metadata | quyền, timestamp |

Ba nguồn và đích DataSync hỗ trợ: | Loại | Ví dụ | |---|---| | Tại chỗ | NFS, SMB, HDFS, object storage | | AWS | S3, EFS, FSx (mọi loại) | | Đám mây khác | Azure, Google Cloud |

DataSync chuyển được cả giữa các dịch vụ AWS — ví dụ EFS sang S3.

Ba tuỳ chọn quan trọng của DataSync task: | Tuỳ chọn | Chi tiết | |---|---| | TransferMode | CHANGED (chỉ tệp đổi) hoặc ALL | | VerifyMode | kiểm tra toàn vẹn | | PreserveDeletedFiles | giữ hay xoá tệp đã bị xoá ở nguồn |

Ba chế độ triển khai DataSync agent: | Cách | Khi nào | |---|---| | Máy ảo tại chỗ | nguồn ở trung tâm dữ liệu | | EC2 instance | nguồn trong AWS | | Snowcone | môi trường không có mạng tốt |

Không cần agent khi cả nguồn lẫn đích đều là dịch vụ AWS.

Bốn chế độ của Storage Gateway — nhắc lại: | Chế độ | Giao diện | |---|---| | S3 File Gateway | NFS, SMB → S3 | | FSx File Gateway | SMB → FSx for Windows | | Volume Gateway | iSCSI khối | | Tape Gateway | iSCSI VTL |

Ba lưu ý về File Gateway: | Lưu ý | Chi tiết | |---|---| | Mỗi tệp thành MỘT object S3 | đọc trực tiếp từ S3 được | | Cache tối thiểu 150 GB | càng lớn tỷ lệ trúng càng cao | | Object ghi thẳng vào S3 cần RefreshCache | gateway không tự biết |

Lệnh làm mới cache:

aws storagegateway refresh-cache --file-share-arn <arn>

Hoặc đặt CacheStaleTimeoutInSeconds để tự làm mới định kỳ.

Ba lựa chọn di chuyển dữ liệu lớn — bảng tổng hợp: | Lựa chọn | Quy mô | Qua mạng | |---|---|---| | Tải trực tiếp (multipart) | tới vài TB | ✅ | | DataSync | TB tới PB | ✅ | | Snowball Edge | hàng chục TB tới PB | ❌ vận chuyển vật lý |

Quy tắc ước lượng:

Thời gian (ngày) = Dung lượng (TB) × 8.000 ÷ (Băng thông Mbps × 86,4)

100 TB qua đường 1 Gbps ≈ 9 ngày
100 TB qua đường 10 Gbps ≈ 1 ngày
        ↓
    Đề nói "ACCELERATED ONLINE migration"
    → chọn đường mạng, và DataSync là công cụ nhanh nhất

Ba cách tăng tốc DataSync: | Cách | Chi tiết | |---|---| | Nhiều agent chạy song song | chia thư mục | | Nhiều task cho các thư mục khác nhau | | | Băng thông đủ và ổn định | |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | DataSync | ~0,0125 USD/GB chuyển | | File Gateway | theo lượng dữ liệu ghi | | Nhập vào AWS | miễn phí phí mạng |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | DataSync: FilesTransferred, BytesTransferred | tiến độ | | File Gateway: CacheHitPercent | thấp = cache quá nhỏ | | File Gateway: CachePercentUsed | |

Ba việc nên làm khi chuyển đổi: | Việc | Chi tiết | |---|---| | Chạy DataSync lần cuối trước khi cắt | bắt các thay đổi cuối | | Chạy song song File Gateway một thời gian | xác nhận trước khi bỏ kho cũ | | Kiểm tra checksum vài tệp mẫu | |

Và một lời khuyên: hãy chạy DataSync một lần nữa với TransferMode: CHANGED ngay trước khi chuyển sang File Gateway. Việc di chuyển hàng trăm TB mất nhiều ngày, và trong thời gian đó ứng dụng vẫn ghi tệp mới vào kho cũ — lần chạy cuối cùng này chỉ mất vài phút và đảm bảo không bỏ sót gì.

Câu 717 Design High-Performing Architectures

A streaming service provider collects user experience feedback through embedded feedback forms in their mobile and web apps. Feedback submissions frequently spike to thousands per hour during content launches or service outages. Currently, the feedback is sent via email to the operations team for manual review. The company now wants to automate feedback collection and sentiment analysis so that insights can be generated quickly and stored for a full year for trend analysis.

Which solution provides the most scalable and automated approach to meet these requirements?

  1. A

    Build a web service on Amazon EC2 that receives feedback data and stores each record in a DynamoDB table. Use the EC2 application to invoke Amazon Comprehend for sentiment detection and write results to a second table. Apply a TTL of 365 days to each table
  2. B

    Route all feedback submissions through Amazon Kinesis Data Streams. Use an AWS Lambda consumer to batch process incoming records, invoke Amazon Translate to detect language and convert input to English, and save the processed content in an Amazon OpenSearch Service index. Configure OpenSearch Index State Management (ISM) policies to delete documents after 12 months
  3. C

    Use Amazon EventBridge to capture feedback events and forward them to an AWS Step Functions workflow. The workflow invokes Lambda functions for validation, calls Amazon Transcribe to convert the text to audio for archival, and stores the results in an Amazon RDS database. Configure a lifecycle policy to remove records after 12 months
  4. D

    Design a RESTful API with Amazon API Gateway that forwards incoming feedback data to an Amazon SQS queue. Set up an AWS Lambda function to process the queue messages, analyze sentiment using Amazon Comprehend, and store results in a DynamoDB table with a 365-day TTL configured on each item
Xem giải thích

Đáp án

D — Thiết kế API REST bằng API Gateway chuyển phản hồi vào hàng đợi SQS; Lambda xử lý thông điệp, phân tích cảm xúc bằng Amazon Comprehend, lưu kết quả vào DynamoDB có TTL 365 ngày.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án D đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Đỉnh tải hàng nghìn phản hồi mỗi giờ | SQS đệm, Lambda co giãn tự động | | Phân tích cảm xúc tự động | Amazon Comprehend | | Lưu một năm để phân tích xu hướng | DynamoDB với TTL 365 ngày | | Mở rộng được và tự động hoàn toàn | serverless từ đầu tới cuối |

Kiến trúc:

Ứng dụng di động / web
    ↓ POST
API Gateway
    ↓ tích hợp trực tiếp (không cần Lambda trung gian)
SQS  ← đệm, chịu được đỉnh tải
    ↓ event source mapping
Lambda
    ├─→ Comprehend (phân tích cảm xúc)
    └─→ DynamoDB (lưu kết quả, TTL 365 ngày)

Vì sao SQS là mảnh ghép quan trọng:

"Feedback submissions frequently SPIKE to THOUSANDS PER HOUR"
        ↓
    Không có hàng đợi:
        → đỉnh tải dồn thẳng vào Lambda và Comprehend
        → có thể bị throttle, mất phản hồi

    Có SQS:
        → đỉnh được đệm lại
        → Lambda xử lý theo nhịp của nó
        → KHÔNG mất phản hồi nào

API Gateway tích hợp thẳng với SQS — không cần Lambda trung gian:

aws apigateway put-integration --rest-api-id abc123   --resource-id res123 --http-method POST   --type AWS --integration-http-method POST   --uri "arn:aws:apigateway:ap-northeast-1:sqs:path/123456789012/hang-doi-phan-hoi"   --credentials <arn-role>

Ít một tầng, ít một chỗ hỏng, và rẻ hơn.

Và TTL của DynamoDB xử lý việc giữ một năm:

import time
het_han = int(time.time()) + 365 * 24 * 3600
bang.put_item(Item={'ma_phan_hoi': ma, 'noi_dung': van_ban,
                    'cam_xuc': ket_qua['Sentiment'],
                    'diem': ket_qua['SentimentScore'],
                    'het_han': het_han})

aws dynamodb update-time-to-live --table-name phan-hoi   --time-to-live-specification "Enabled=true, AttributeName=het_han"

TTL xoá item tự động, KHÔNG tốn WCU
    → kiểm soát chi phí lưu trữ mà không cần job dọn dẹp

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

  • **A. Dịch vụ web trên EC2 nhận phản hồi, lưu DynamoDB, gọi Comprehend, ghi bảng thứ hai — đây là phương án gần nhất về mặt các dịch vụ dùng, nhưng nó không serverless và không có đệm: EC2 phải tự co giãn để chịu đỉnh tải, và không có hàng đợi nên đỉnh dồn thẳng vào ứng dụng.
  • **B. Kinesis Data Streams + Lambda + Amazon Translate + OpenSearch — sai dịch vụ AI: Translate dịch ngôn ngữ, không phân tích cảm xúc. Và OpenSearch đòi quản lý cụm, nặng hơn DynamoDB cho nhu cầu này.
  • **C. EventBridge + Step Functions + Amazon Transcribe chuyển văn bản thành âm thanh + RDS — sai dịch vụ và vô nghĩa: Transcribe chuyển giọng nói thành văn bản (không phải ngược lại — đó là Polly), và chuyển văn bản thành âm thanh để lưu trữ không phục vụ mục đích nào.

Ghi nhớ

Các dịch vụ AI/ML của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Amazon Comprehend | phân tích VĂN BẢN: cảm xúc, thực thể, PII, chủ đề | | Amazon Transcribe | giọng nói → văn bản | | Amazon Polly | văn bản → giọng nói | | Amazon Translate | dịch ngôn ngữ | | Amazon Rekognition | ảnh và video | | Amazon Textract | trích xuất từ tài liệu quét | | Amazon Lex | chatbot |

Bốn dòng đầu rất hay bị hoán đổi trong đề thi.

Bốn giá trị cảm xúc của Comprehend: | Giá trị | Nghĩa | |---|---| | POSITIVE | tích cực | | NEGATIVE | tiêu cực | | NEUTRAL | trung tính | | MIXED | lẫn lộn — vừa khen vừa chê |

kq = comprehend.detect_sentiment(Text=van_ban, LanguageCode='vi')
# {'Sentiment': 'NEGATIVE',
#  'SentimentScore': {'Positive': 0.02, 'Negative': 0.93, ...}}

Và có API xử lý theo lô:

comprehend.batch_detect_sentiment(TextList=danh_sach, LanguageCode='vi')

Tối đa 25 tài liệu mỗi lời gọi — rẻ hơn và nhanh hơn gọi từng cái.

Ba mẫu kiến trúc serverless nhận dữ liệu: | Mẫu | Khi nào | |---|---| | API Gateway → SQS → Lambda | cần đệm, chịu đỉnh tải ← câu này | | API Gateway → Lambda | đơn giản, tải đều | | API Gateway → Kinesis → Lambda | cần nhiều consumer, phát lại |

Ba lợi ích của việc chèn SQS: | Lợi ích | Chi tiết | |---|---| | Đệm đỉnh tải | ← lý do chính | | Không mất dữ liệu khi Lambda lỗi | thông điệp quay lại hàng đợi | | DLQ cho thông điệp hỏng | |

Ba thông số SQS cần đặt đúng: | Thông số | Chi tiết | |---|---| | Visibility timeout ≥ Lambda timeout | khuyến nghị gấp 6 lần | | maxReceiveCount 3–5 với DLQ | | | Batch size của event source mapping | 1–10 cho xử lý AI |

Dòng đầu là quy tắc cụ thể của AWS:

Lambda timeout 30 giây
    → visibility timeout nên là 180 giây
        ↓
    Tránh thông điệp hiện lại khi Lambda vẫn đang chạy

Ba đặc điểm của TTL trong DynamoDB: | Đặc điểm | Chi tiết | |---|---| | MIỄN PHÍ, không tốn WCU | | | Xoá trong vòng 48 giờ sau thời điểm hết hạn | không chính xác tuyệt đối | | Giá trị là Unix epoch dạng SỐ | không phải chuỗi ngày |

Dòng giữa cần biết:

TTL không xoá đúng giây hết hạn
    → có thể chậm tới 48 giờ
        ↓
    Nếu cần chính xác, lọc thêm ở tầng ứng dụng

Ba lưu ý về API Gateway: | Lưu ý | Chi tiết | |---|---| | Tích hợp trực tiếp với SQS, DynamoDB, Kinesis | không cần Lambda trung gian | | Có throttling và usage plan | bảo vệ backend | | REST API có cache, HTTP API rẻ hơn | |

Ba lưu ý về Lambda đọc từ SQS: | Lưu ý | Chi tiết | |---|---| | Lambda tự co giãn theo độ sâu hàng đợi | | | Đặt reserved concurrency giới hạn | tránh chiếm hết hạn mức tài khoản | | Xử lý lỗi từng phần với ReportBatchItemFailures | |

{"FunctionResponseTypes": ["ReportBatchItemFailures"]}

Không có nó: một thông điệp lỗi làm CẢ LÔ được xử lý lại
    → thông điệp thành công bị xử lý trùng

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Comprehend sentiment | ~0,0001 USD mỗi đơn vị 100 ký tự | | SQS | ~0,40 USD mỗi triệu request | | DynamoDB on-demand | theo request |

Với hàng nghìn phản hồi mỗi giờ, tổng chi phí rất thấp.

Ba cách phân tích xu hướng sau này: | Cách | Chi tiết | |---|---| | Xuất DynamoDB sang S3 rồi dùng Athena | rẻ nhất cho phân tích lịch sử | | QuickSight kết nối trực tiếp | trực quan hoá | | DynamoDB Streams → Firehose → S3 | luồng liên tục |

Ba lưu ý về quyền riêng tư: | Lưu ý | Chi tiết | |---|---| | Comprehend có API phát hiện PII | che thông tin cá nhân | | Mã hoá DynamoDB bằng KMS | | | Ghi rõ chính sách lưu giữ dữ liệu | 365 ngày |

Và một lời khuyên: hãy dùng batch_detect_sentiment thay vì gọi từng phản hồi một. Với đỉnh tải hàng nghìn phản hồi mỗi giờ, gộp 25 tài liệu mỗi lời gọi giảm đáng kể cả chi phí lẫn nguy cơ chạm hạn mức API của Comprehend — và Lambda đọc từ SQS vốn đã nhận theo lô, nên việc gộp là tự nhiên.

Câu 718 Design High-Performing Architectures

The engineering team at a weather tracking company wants to enhance the performance of its relational database and is looking for a caching solution that supports geospatial data.

As a solutions architect, which of the following solutions will you suggest?

  1. A

    Use Amazon ElastiCache for Memcached
  2. B

    Use AWS Global Accelerator
  3. C

    Use Amazon DynamoDB Accelerator (DAX)
  4. D

    Use Amazon ElastiCache for Redis
Xem giải thích

Đáp án

D — Dùng Amazon ElastiCache for Redis.

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ Redis đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Bộ đệm cho database quan hệ | ElastiCache đặt trước RDS | | Hỗ trợ dữ liệu ĐỊA LÝ (geospatial) | Redis có kiểu dữ liệu GEO dựng sẵn |

Vế thứ hai là điểm phân biệt quyết định:

Redis có lệnh GEO nguyên bản:
    GEOADD    — thêm toạ độ
    GEOSEARCH — tìm trong bán kính hoặc hộp chữ nhật
    GEODIST   — khoảng cách giữa hai điểm
    GEOPOS    — lấy toạ độ
        ↓
    Memcached CHỈ có key-value đơn giản
    → không có khái niệm toạ độ

Và với công ty theo dõi thời tiết, đây đúng là nhu cầu:

GEOADD tram-quan-trac 106.700 10.776 "tram-hcm"
GEOADD tram-quan-trac 105.854 21.028 "tram-hanoi"

# Tìm trạm trong bán kính 100 km
GEOSEARCH tram-quan-trac FROMLONLAT 106.5 10.9 BYRADIUS 100 km ASC WITHDIST

Và Redis còn có nhiều kiểu dữ liệu khác: | Kiểu | Dùng cho | |---|---| | GEO | toạ độ địa lý ← câu này | | Sorted set | bảng xếp hạng, dữ liệu theo thời gian | | Hash | bản ghi có nhiều trường | | List | hàng đợi đơn giản | | String với TTL | đệm thông thường |

Tạo cụm:

aws elasticache create-replication-group   --replication-group-id cum-thoi-tiet   --replication-group-description "Dem du lieu thoi tiet"   --engine redis --cache-node-type cache.r6g.large   --num-cache-clusters 3   --automatic-failover-enabled --multi-az-enabled   --at-rest-encryption-enabled --transit-encryption-enabled

Và mẫu cache-aside:

def tra_cuu_tram_gan(kinh_do, vi_do, ban_kinh_km):
    khoa = f'gan:{kinh_do}:{vi_do}:{ban_kinh_km}'
    kq = redis.get(khoa)
    if kq is None:
        kq = redis.geosearch('tram-quan-trac',
                             longitude=kinh_do, latitude=vi_do,
                             radius=ban_kinh_km, unit='km')
        redis.setex(khoa, 300, json.dumps(kq))
    return json.loads(kq)

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

  • **A. Dùng ElastiCache for Memcached — đây là phương án gần nhất và cũng là bộ đệm trong bộ nhớ đặt trước database, nhưng nó không hỗ trợ dữ liệu địa lý: Memcached chỉ có key-value đơn giản, không có kiểu dữ liệu phong phú. Nó cũng không có sao chép hay chuyển đổi tự động.
  • **C. Dùng DynamoDB Accelerator (DAX) — chỉ dùng được với DynamoDB: DAX là bộ đệm chuyên biệt cho DynamoDB, không đặt trước database quan hệ được.
  • **B. Dùng AWS Global Accelerator — hoàn toàn không phải bộ đệm: đây là dịch vụ định tuyến mạng toàn cầu, không lưu trữ dữ liệu.

Ghi nhớ

Redis và Memcached — bảng phải thuộc: | | Redis / Valkey | Memcached | |---|---|---| | Cấu trúc dữ liệu | phong phú: GEO, sorted set, hash, list | CHỈ key-value | | Sao chép và Multi-AZ | ✅ | ❌ | | Bền vững (snapshot, AOF) | ✅ | ❌ | | Pub/Sub, transaction, Lua | ✅ | ❌ | | Đa luồng | có I/O threading từ v6 | ✅ từ đầu | | Đơn giản, chia dữ liệu ngang | | ✅ |

Quy tắc: cần bất cứ thứ gì ngoài key-value đơn giản thì dùng Redis.

Từ khoá nhận diện:

"geospatial", "leaderboard", "pub/sub", "high availability" → Redis "simple caching", "multi-threaded", "horizontal scaling only" → Memcached "cache for DynamoDB" → DAX

Bốn lệnh GEO của Redis: | Lệnh | Việc | |---|---| | GEOADD | thêm hoặc cập nhật toạ độ | | GEOSEARCH | tìm trong bán kính hoặc hộp chữ nhật | | GEODIST | khoảng cách giữa hai điểm | | GEOPOS | lấy toạ độ của một thành viên |

Redis lưu toạ độ bằng geohash trong sorted set — nên các thao tác này rất nhanh.

Ba dịch vụ in-memory của AWS: | Dịch vụ | Vai trò | |---|---| | ElastiCache Redis | bộ ĐỆM — mất dữ liệu chấp nhận được | | MemoryDB for Redis | DATABASE CHÍNH — bền vững đa AZ | | DAX | bộ đệm riêng cho DynamoDB |

MemoryDB đáng cân nhắc nếu dữ liệu không tái tạo được:

ElastiCache: node hỏng có thể mất dữ liệu chưa snapshot
MemoryDB:    transaction log đa AZ, KHÔNG mất
        ↓
    Với bộ đệm trước RDS, ElastiCache là đúng

Ba chế độ triển khai ElastiCache Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, tới 5 replica | | Cluster mode enabled | tới 500 shard — mở rộng ngang | | Serverless | tự co giãn, Multi-AZ mặc định |

Ba mẫu đệm: | Mẫu | Cơ chế | |---|---| | Lazy loading (cache-aside) | đọc trượt thì nạp từ database | | Write-through | ghi cả hai nơi cùng lúc | | TTL | tự hết hạn tránh dữ liệu cũ |

Ba cấu hình cho sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Multi-AZ với automatic failover | replica ở AZ khác | | Ít nhất 2 replica | | | Bật snapshot tự động | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp = đệm không hiệu quả | | Evictions | cao = bộ nhớ không đủ | | EngineCPUUtilization | CPU của tiến trình Redis, chính xác hơn CPUUtilization |

EngineCPUUtilization là metric đúng:

Redis xử lý lệnh chủ yếu ĐƠN LUỒNG
    → CPUUtilization của cả instance có thể thấp
    → nhưng EngineCPUUtilization đã gần 100%
        ↓
    Dùng metric thứ hai để biết khi nào cần thêm shard

Ba cách mở rộng Redis: | Cách | Mở rộng | |---|---| | Thêm replica | ĐỌC | | Thêm shard (cluster mode) | GHI và dung lượng | | Node lớn hơn | bộ nhớ và CPU |

Ba lưu ý về thiết kế khoá cache: | Lưu ý | Chi tiết | |---|---| | Khoá phản ánh đúng truy vấn | | | TTL phù hợp với độ tươi cần thiết | dữ liệu thời tiết: vài phút | | Xoá khoá khi dữ liệu đổi | hoặc dựa vào TTL |

Ba biện pháp bảo mật: | Biện pháp | Chi tiết | |---|---| | Cụm trong PRIVATE subnet | | | Mã hoá at rest và in transit | bật LÚC TẠO | | Redis AUTH hoặc RBAC | xác thực client |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo node-giờ | như EC2 | | Reserved node giảm tới 55% | | | Rẻ hơn nhiều so với nâng cỡ RDS | cho cùng lượng truy vấn |

Và một lời khuyên: hãy theo dõi Evictions ngay từ tuần đầu. Với dữ liệu địa lý, tập dữ liệu thường lớn hơn dự đoán ban đầu — và khi Redis bắt đầu đuổi key để lấy chỗ, tỷ lệ trúng cache giảm âm thầm cho tới lúc bộ đệm gần như không còn tác dụng gì.

Câu 719 Design Resilient Architectures

A company wants to ensure high availability for its Amazon RDS database. The development team wants to opt for Multi-AZ deployment and they would like to understand what happens when the primary instance of the Multi-AZ configuration goes down.

As a Solutions Architect, which of the following will you identify as the outcome of the scenario?

  1. A

    An email will be sent to the System Administrator asking for manual intervention
  2. B

    The application will be down until the primary database has recovered itself
  3. C

    The URL to access the database will change to the standby database
  4. D

    The CNAME record will be updated to point to the standby database
Xem giải thích

Đáp án

**D — Bản ghi CNAME sẽ được cập nhật để trỏ tới database standby.

Vì sao đúng

Đây là cơ chế chuyển đổi của RDS Multi-AZ, và điểm mấu chốt là endpoint KHÔNG ĐỔI.

RDS cho một endpoint dạng:
    db-abc.xyz123.ap-northeast-1.rds.amazonaws.com
        ↓
    Đó là bản ghi CNAME (hoặc tương đương)
    → trỏ tới địa chỉ của instance primary hiện tại

Khi primary hỏng:

① RDS phát hiện primary không phản hồi
② RDS thăng cấp standby thành primary mới
③ RDS CẬP NHẬT bản ghi DNS trỏ sang instance mới
        ↓
    Chuỗi kết nối của ứng dụng KHÔNG ĐỔI
    → chỉ cần KẾT NỐI LẠI

Thời gian chuyển đổi:

Thường 60–120 giây
    → gồm phát hiện, thăng cấp, cập nhật DNS

Và ứng dụng phải xử lý được việc kết nối lại:

Trong lúc chuyển đổi:
    → kết nối đang mở bị NGẮT
    → ứng dụng nhận lỗi kết nối
        ↓
    Ứng dụng phải có logic THỬ LẠI
    → và KHÔNG cache DNS quá lâu

Vấn đề cache DNS là bẫy thực tế quan trọng nhất:

JVM mặc định có thể cache DNS VĨNH VIỄN
    → sau chuyển đổi, ứng dụng vẫn gọi IP CŨ
    → lỗi kéo dài dù RDS đã chuyển xong
        ↓
    Đặt networkaddress.cache.ttl = 60 hoặc thấp hơn

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

Và thử chuyển đổi có chủ đích:

aws rds reboot-db-instance --db-instance-identifier db-san-xuat   --force-failover

Đây là cách duy nhất biết chắc ứng dụng chịu được chuyển đổi.

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

  • **C. URL truy cập database sẽ ĐỔI sang database standby — đây là phương án gần nhất và nghe rất giống đáp án đúng, nhưng nó mô tả ngược: URL (endpoint) KHÔNG đổi. Chính vì nó không đổi mà bản ghi DNS phía sau mới phải được cập nhật. Nếu URL đổi thì ứng dụng phải sửa cấu hình mỗi lần chuyển đổi — đúng thứ Multi-AZ tránh.
  • **A. Gửi email cho quản trị viên yêu cầu can thiệp thủ công — sai bản chất của Multi-AZ: chuyển đổi là TỰ ĐỘNG. (RDS có gửi thông báo qua event subscription nếu bạn cấu hình, nhưng đó là thông báo chứ không phải yêu cầu can thiệp.)
  • **B. Ứng dụng ngừng hoạt động cho tới khi primary tự phục hồi — cũng sai: Multi-AZ tồn tại chính là để tránh điều này.

Ghi nhớ

Cơ chế chuyển đổi của RDS Multi-AZ:

Primary hỏng
    ↓
RDS phát hiện (health check nội bộ)
    ↓
Thăng cấp standby → primary mới
    ↓
CẬP NHẬT BẢN GHI DNS của endpoint
    ↓
Ứng dụng kết nối lại → tới instance mới

Ba tình huống kích hoạt chuyển đổi tự động: | Tình huống | Chi tiết | |---|---| | Primary hỏng | phần cứng hoặc phần mềm | | AZ chứa primary mất kết nối | | | Bảo trì có kế hoạch | vá lỗi, đổi cỡ instance | | Thay đổi loại lưu trữ | |

Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | RPO | 0 | giây tới phút | | Chuyển đổi | TỰ ĐỘNG | thủ công (promote) | | Standby phục vụ đọc | ❌ | ✅ | | Phạm vi | cùng Region | cùng hoặc khác Region |

Ba kiểu triển khai của RDS: | Kiểu | Đặc điểm | |---|---| | Single-AZ | không chịu lỗi — chỉ cho dev | | Multi-AZ instance | 1 standby, KHÔNG phục vụ đọc, chuyển đổi 60–120 giây | | Multi-AZ DB cluster | 2 standby CÓ phục vụ đọc, chuyển đổi dưới 35 giây |

Multi-AZ DB cluster hỗ trợ MySQL và PostgreSQL — nhanh hơn và tận dụng được standby.

Ba loại bảo trì và tác động: | Loại | Multi-AZ giảm ngừng | |---|---| | Vá lỗi hệ điều hành | ✅ vá standby trước rồi chuyển đổi | | Đổi cỡ instance | ✅ | | Nâng cấp phiên bản ENGINE | ❌ cả hai cùng lúc, CÓ ngừng |

Dòng cuối hay bị hiểu nhầm — Multi-AZ không loại bỏ mọi thời gian ngừng.

Ba việc Multi-AZ KHÔNG bảo vệ: | Không bảo vệ | Cách bảo vệ | |---|---| | Lỗi con người (xoá nhầm bảng) | automated backup + PITR | | Thảm hoạ cấp Region | cross-Region replica hoặc backup | | Dữ liệu hỏng do ứng dụng | PITR |

Multi-AZ là cơ chế SẴN SÀNG, không phải SAO LƯU.

Ba yêu cầu với ứng dụng để chịu được chuyển đổi: | Yêu cầu | Chi tiết | |---|---| | Logic thử lại kết nối | với backoff | | KHÔNG cache DNS quá lâu | JVM là ca hay gặp nhất | | Connection pool có kiểm tra sức khoẻ | loại bỏ kết nối chết |

Ba cách giảm tác động của chuyển đổi: | Cách | Chi tiết | |---|---| | RDS Proxy | giữ kết nối qua chuyển đổi, giảm thời gian ngừng tới 66% | | Multi-AZ DB cluster | chuyển đổi dưới 35 giây | | Aurora | chuyển đổi thường dưới 30 giây |

RDS Proxy đáng dùng:

aws rds create-db-proxy --db-proxy-name proxy-san-xuat   --engine-family MYSQL --role-arn <arn-role>   --auth '[{"SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]'   --vpc-subnet-ids subnet-a subnet-c

RDS Proxy:
    ✓ gộp kết nối
    ✓ GIỮ kết nối của client trong lúc chuyển đổi
    ✓ tự kết nối lại tới primary mới
        ↓
    Ứng dụng gần như không cảm nhận được

Ba cách theo dõi chuyển đổi: | Cách | Chi tiết | |---|---| | RDS event subscription qua SNS | nhận thông báo khi có chuyển đổi | | CloudWatch metric FailoverTime | | | CloudTrail | |

aws rds create-event-subscription --subscription-name canh-bao-rds   --sns-topic-arn <arn-sns> --source-type db-instance   --event-categories failover availability

Ba việc nên làm sau khi bật Multi-AZ: | Việc | Chi tiết | |---|---| | THỬ chuyển đổi trong giờ thấp điểm | --force-failover | | Đo thời gian ứng dụng phục hồi | | | Kiểm tra cấu hình cache DNS của client | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Multi-AZ tốn GẤP ĐÔI chi phí instance | standby cũng tính phí | | Không có phí truyền dữ liệu giữa primary và standby | | | Đáng giá cho mọi database sản xuất | |

Và một lời khuyên: hãy thử --force-failover ngay sau khi bật Multi-AZ, đừng đợi sự cố thật. Phía AWS luôn hoạt động đúng, nhưng phía ứng dụng thì không chắc — và việc cache DNS hoặc thiếu logic thử lại chỉ lộ ra khi chuyển đổi xảy ra, tức là đúng lúc bạn ít có thời gian để sửa nhất.

Câu 720 Design High-Performing Architectures

A Customer relationship management (CRM) application is facing user experience issues with users reporting frequent sign-in requests from the application. The application is currently hosted on multiple Amazon EC2 instances behind an Application Load Balancer. The engineering team has identified the root cause as unhealthy servers causing session data to be lost. The team would like to implement a distributed in-memory cache-based session management solution.

As a solutions architect, which of the following solutions would you recommend?

  1. A

    Use Amazon RDS for distributed in-memory cache based session management
  2. B

    Use Amazon Elasticache for distributed in-memory cache based session management
  3. C

    Use Application Load Balancer sticky sessions
  4. D

    Use Amazon DynamoDB for distributed in-memory cache based session management
Xem giải thích

Đáp án

B — Dùng Amazon ElastiCache làm nơi quản lý phiên phân tán trong bộ nhớ.

Vì sao đúng

Đề nêu chính xác thuật ngữ cần tìm: distributed in-memory cache-based session management.

ElastiCache:
    ✓ lưu trữ TRONG BỘ NHỚ
    ✓ PHÂN TÁN — mọi EC2 đều truy cập được
    ✓ độ trễ micro giây
        ↓
    Đúng định nghĩa từng chữ của yêu cầu

Và nó giải quyết đúng nguyên nhân gốc:

Nguyên nhân: phiên lưu TRONG BỘ NHỚ CỦA TỪNG MÁY
    → máy hỏng → phiên mất → người dùng phải đăng nhập lại
        ↓
    Đưa phiên RA NGOÀI máy chủ ứng dụng
    → máy nào hỏng cũng không ảnh hưởng phiên
    → ứng dụng trở thành STATELESS thật sự

Mẫu triển khai:

import redis, json
r = redis.Redis(host='cum-phien.abc.ng.0001.apne1.cache.amazonaws.com', port=6379)

def luu_phien(ma_phien, du_lieu):
    r.setex(f'phien:{ma_phien}', 1800, json.dumps(du_lieu))  # TTL 30 phút

def doc_phien(ma_phien):
    v = r.get(f'phien:{ma_phien}')
    return json.loads(v) if v else None

Và TTL xử lý việc dọn phiên hết hạn tự động — không cần job dọn dẹp nào.

Cấu hình cụm sẵn sàng cao:

aws elasticache create-replication-group   --replication-group-id cum-phien   --replication-group-description "Luu phien CRM"   --engine redis --cache-node-type cache.r6g.large   --num-cache-clusters 3   --automatic-failover-enabled --multi-az-enabled

Và lợi ích phụ: ứng dụng stateless mở ra nhiều thứ khác: | Lợi ích | Chi tiết | |---|---| | Auto Scaling thay máy tự do | không lo mất phiên | | Không cần sticky session | tải phân phối đều hơn | | Triển khai blue/green dễ hơn | |

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

  • **C. Dùng sticky session của ALB — đây là phương án gần nhất và thực sự làm người dùng luôn về đúng máy cũ, nhưng nó không giải quyết vấn đề trong đề: máy đó hỏng thì phiên vẫn mất. Đề nói rõ nguyên nhân là "unhealthy servers causing session data to be lost". Sticky session chỉ che giấu vấn đề, không sửa nó.
  • **D. Dùng DynamoDB — là lựa chọn hợp lệ cho lưu phiên nhưng không phải "in-memory cache": DynamoDB là database bền vững trên đĩa (dù rất nhanh). Đề yêu cầu rõ giải pháp dựa trên bộ đệm trong bộ nhớ.
  • **A. Dùng Amazon RDS — sai loại kho hoàn toàn: database quan hệ không phù hợp cho việc đọc ghi phiên tần suất rất cao, và cũng không phải in-memory.

Ghi nhớ

Ba nơi lưu phiên cho ứng dụng nhiều máy — bảng phải thuộc: | Nơi | Đặc điểm | |---|---| | ElastiCache (Redis/Memcached) | in-memory, nhanh nhất ← câu này | | DynamoDB | bền vững, có TTL, serverless | | Sticky session của ALB | không phải giải pháp thật — chỉ né tránh |

Từ khoá nhận diện:

"in-memory", "distributed cache", "session management" → ElastiCache "serverless, durable session store" → DynamoDB

Ba vấn đề của sticky session: | Vấn đề | Chi tiết | |---|---| | Máy hỏng vẫn mất phiên | ← vấn đề trong đề | | Phân phối tải LỆCH | máy cũ giữ nhiều người dùng | | Cản trở việc thay máy khi triển khai | |

Bật sticky session (khi buộc phải dùng tạm):

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=stickiness.enabled,Value=true                Key=stickiness.type,Value=lb_cookie                Key=stickiness.lb_cookie.duration_seconds,Value=86400

Coi nó là giải pháp tạm, không phải đích đến.

Redis và Memcached — bảng phân biệt: | | Redis / Valkey | Memcached | |---|---|---| | Sao chép và Multi-AZ | ✅ | ❌ | | Bền vững (snapshot) | ✅ | ❌ | | Cấu trúc dữ liệu phong phú | ✅ | chỉ key-value | | Đa luồng | I/O threading từ v6 | ✅ từ đầu |

Với lưu phiên cần sẵn sàng cao, Redis là lựa chọn đúng.

Ba yêu cầu để ứng dụng thật sự stateless: | Yêu cầu | Đưa ra đâu | |---|---| | Phiên đăng nhập | ElastiCache hoặc DynamoDB | | Tệp người dùng tải lên | S3 | | Log | CloudWatch Logs |

Ba lưu ý khi thiết kế lưu phiên: | Lưu ý | Chi tiết | |---|---| | Đặt TTL khớp thời gian hết hạn phiên | tự dọn | | Mã hoá dữ liệu phiên nhạy cảm | | | Xử lý được trường hợp cache không truy cập được | |

Dòng cuối quan trọng:

Cụm ElastiCache không truy cập được
    → ứng dụng KHÔNG được sập hoàn toàn
    → nên đăng xuất người dùng một cách có kiểm soát
        ↓
    Thiết kế xử lý lỗi ngay từ đầu

Ba cấu hình cho ElastiCache sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Multi-AZ với automatic failover | replica ở AZ khác | | Ít nhất 2 replica | | | Bật mã hoá at rest và in transit | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | phiên có được đọc thành công không | | Evictions | bộ nhớ không đủ — phiên bị đuổi ra | | EngineCPUUtilization | CPU của tiến trình Redis |

Evictions đặc biệt nguy hiểm với lưu phiên:

Redis hết bộ nhớ → đuổi key theo chính sách maxmemory
    → PHIÊN ĐANG DÙNG bị xoá
    → người dùng bị đăng xuất ngẫu nhiên
        ↓
    Đúng triệu chứng ban đầu, chỉ đổi nguyên nhân

Ba lưu ý về chính sách bộ nhớ: | Chính sách | Chi tiết | |---|---| | volatile-lru | chỉ đuổi key CÓ TTL — an toàn hơn | | allkeys-lru | đuổi mọi key | | noeviction | trả lỗi thay vì đuổi |

Ba lựa chọn kiến trúc thay thế: | Lựa chọn | Khi nào | |---|---| | Token không trạng thái (JWT) | không cần lưu phiên ở server | | DynamoDB với TTL | serverless, bền vững | | ElastiCache | ← câu này, nhanh nhất |

JWT đáng cân nhắc:

Token chứa sẵn thông tin phiên, có chữ ký
    → server KHÔNG lưu gì
        ↓
    Nhưng khó thu hồi token trước hạn
    → thường kết hợp với danh sách đen ngắn hạn trong cache

Và một lời khuyên: hãy đặt alarm cho Evictions ngay khi triển khai. Với dữ liệu phiên, việc Redis đuổi key vì thiếu bộ nhớ tạo ra đúng triệu chứng ban đầu — người dùng bị đăng xuất bất chợt — và bạn sẽ mất rất nhiều thời gian tìm ở tầng ứng dụng trước khi nghĩ tới bộ nhớ cache.