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

Tìm thấy 2194 câu.

Câu 281 Design High-Performing Architectures

An e-commerce application is using a fanout messaging pattern for its order management system. For every order, it sends an Amazon SNS message to an SNS topic, and the message is replicated and pushed to multiple Amazon SQS queues for parallel asynchronous processing. A Spot EC2 instance retrieves the message from each SQS queue and processes the message. There was an incident that while an EC2 instance is currently processing a message, the instance was abruptly terminated, and the processing was not completed in time.

In this scenario, what happens to the SQS message?

  1. A When the message visibility timeout expires, the message becomes available for processing by other EC2 instances
  2. B

    The message will automatically be assigned to the same EC2 instance when it comes back online within or after the visibility timeout.
  3. C The message is deleted and becomes duplicated in the SQS when the EC2 instance comes online.
  4. D

    The message will be sent to a Dead Letter Queue in AWS DataSync.
Xem giải thích

Đáp án

A — Khi visibility timeout hết hạn, thông điệp trở lại trạng thái sẵn sàng và EC2 instance khác nhận được để xử lý.

Vì sao đúng

Đề mô tả tình huống kinh điển: consumer chết giữa chừng khi đang xử lý thông điệp.

Và SQS được thiết kế để xử lý đúng tình huống này:

① Consumer gọi ReceiveMessage
    → thông điệp KHÔNG bị xoá, chỉ bị ẨN
    → bắt đầu đếm visibility timeout (mặc định 30 giây)
② Consumer xử lý xong → gọi DeleteMessage → thông điệp biến mất
③ Consumer CHẾT trước khi xoá:
    → hết visibility timeout
    → thông điệp XUẤT HIỆN LẠI trong hàng đợi
    → consumer khác nhận được

Điểm mấu chốt: ReceiveMessage KHÔNG xoá thông điệp.

Chỉ DeleteMessage mới xoá
    → không gọi Delete = coi như chưa xử lý
    → SQS tự động trả lại

Đây chính là cơ chế khiến SQS an toàn với Spot Instance:

Spot bị thu hồi giữa chừng
    → thông điệp quay lại hàng đợi
    → máy khác xử lý lại
    → KHÔNG mất công việc nào

Và đó là lý do kiến trúc trong đề dùng Spot được — hàng đợi đã lo phần thử lại.

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

  • **B. Thông điệp tự động được giao lại cho ĐÚNG instance đó khi nó quay lại — đây là phương án gần nhất và nghe hợp lý, nhưng SQS không có khái niệm "chủ sở hữu thông điệp": nó chỉ ẩn thông điệp trong một khoảng thời gian. Hết thời gian đó thì bất kỳ consumer nào cũng nhận được.
  • **C. Thông điệp bị xoá và trở thành trùng lặp khi instance quay lại — sai về mặt cơ chế: thông điệp không bị xoá (vì DeleteMessage chưa được gọi), và không có việc "nhân bản" nào xảy ra.
  • **D. Thông điệp được chuyển sang Dead Letter Queue trong AWS DataSync — sai dịch vụ: dead-letter queue là một SQS queue khác, không liên quan gì tới DataSync (dịch vụ đồng bộ tệp). Và thông điệp chỉ vào DLQ sau khi thất bại đủ maxReceiveCount lần, không phải ngay lần đầu.

Ghi nhớ

Vòng đời một thông điệp SQS:

Producer gửi → thông điệp ở trạng thái SẴN SÀNG
    ↓ ReceiveMessage
Trạng thái ĐANG BAY (in flight) — bị ẩn khỏi consumer khác
    ↓
    ├─ DeleteMessage      → XOÁ hẳn
    ├─ Hết visibility timeout → quay lại SẴN SÀNG
    └─ Quá maxReceiveCount   → chuyển sang DEAD-LETTER QUEUE

Ba cấu hình quan trọng nhất của SQS: | Cấu hình | Mặc định | Ghi chú | |---|---|---| | VisibilityTimeout | 30 giây | PHẢI ≥ thời gian xử lý dài nhất (tối đa 12 giờ) | | MessageRetentionPeriod | 4 ngày | 1 phút – 14 ngày | | ReceiveMessageWaitTimeSeconds | 0 (short polling) | đặt 20 để bật long polling |

Cạm bẫy lớn nhất: visibility timeout NGẮN HƠN thời gian xử lý.

Xử lý mất 5 phút, visibility timeout 30 giây
    → sau 30 giây thông điệp xuất hiện lại
    → máy KHÁC bắt đầu xử lý cùng thông điệp
    → XỬ LÝ TRÙNG, và máy đầu vẫn đang chạy

Với công việc có thời gian không đoán trước, hãy gia hạn động:

sqs.change_message_visibility(QueueUrl=q, ReceiptHandle=rh,
                              VisibilityTimeout=600)

Và với Spot Instance, hãy xử lý cảnh báo thu hồi:

r = requests.get('http://169.254.169.254/latest/meta-data/spot/instance-action')
if r.status_code == 200:
    # Trả thông điệp về hàng đợi NGAY thay vì chờ hết timeout
    sqs.change_message_visibility(QueueUrl=q, ReceiptHandle=rh,
                                  VisibilityTimeout=0)

Đặt visibility về 0 khiến thông điệp có sẵn lập tức — máy khác nhận ngay, không phải chờ hết 30 giây hay 5 phút.

Dead-letter queue — cấu hình nên có cho mọi hàng đợi sản xuất:

{"RedrivePolicy": "{\"deadLetterTargetArn\":\"<arn-dlq>\",
                    \"maxReceiveCount\":\"3\"}"}

Vì sao cần: một thông điệp gây lỗi hàm sẽ quay lại hàng đợi mãi, chiếm chỗ và làm nhiễu log. DLQ tách nó ra để xử lý riêng.

SQS Standard và FIFO: | | Standard | FIFO | |---|---|---| | Thứ tự | không đảm bảo | ✅ trong message group | | Trùng lặp | có thể (at-least-once) | không (exactly-once) | | Thông lượng | gần như không giới hạn | 300–3.000 TPS (cao hơn với high throughput mode) |

Vì standard queue giao ít nhất một lần, consumer nên IDEMPOTENT:

def xu_ly(don):
    if da_xu_ly(don['ma_don']):    # kiểm tra trong DynamoDB
        return
    thuc_hien(don)
    danh_dau_da_xu_ly(don['ma_don'])

Đây là lớp bảo vệ cuối cùng — cần thiết ngay cả với FIFO, vì consumer có thể chết sau khi xử lý xong mà chưa kịp xoá thông điệp.

Và mẫu fan-out mà đề mô tả (SNS → nhiều SQS) là kiến trúc chuẩn:

SNS topic
    ├─▶ SQS queue A → xử lý thanh toán
    ├─▶ SQS queue B → gửi email xác nhận
    └─▶ SQS queue C → cập nhật kho
    → mỗi hàng đợi xử lý ĐỘC LẬP, lỗi ở một nhánh không ảnh hưởng nhánh khác

Ba metric cần đặt alarm: | Metric | Cảnh báo khi | |---|---| | ApproximateAgeOfOldestMessage | thông điệp tồn quá lâu — consumer không theo kịp | | ApproximateNumberOfMessagesVisible | hàng đợi tích tụ | | NumberOfMessagesSent vào DLQ | có thông điệp hỏng |

Và một lưu ý về mở rộng: dùng chính ApproximateNumberOfMessagesVisible làm metric cho Auto Scaling — đội máy tự lớn lên khi hàng đợi dài và co lại khi xử lý hết. Đó là cách co giãn phản ánh nhu cầu thật chính xác hơn CPU.

Câu 282 Design Resilient Architectures

A top investment bank is in the process of building a new Forex trading platform. To ensure high availability and scalability, you designed the trading platform to use an Elastic Load Balancer in front of an Auto Scaling group of On-Demand EC2 instances across multiple Availability Zones. For its database tier, you chose to use a single Amazon Aurora instance to take advantage of its distributed, fault-tolerant, and self-healing storage system.

In the event of system failure on the primary database instance, what happens to Amazon Aurora during the failover?

  1. A

    Amazon Aurora flips the canonical name record (CNAME) for your DB Instance to point at the healthy replica, which in turn is promoted to become the new primary.
  2. B

    Aurora will attempt to create a new DB Instance in the same Availability Zone as the original instance and is done on a best-effort basis.
  3. C

    Amazon Aurora flips the A record of your DB Instance to point at the healthy replica, which in turn is promoted to become the new primary.
  4. D

    Aurora will first attempt to create a new DB Instance in a different Availability Zone of the original instance. If unable to do so, Aurora will attempt to create a new DB Instance in the original Availability Zone in which the instance was first launched.
Xem giải thích

Đáp án

B — Aurora sẽ cố tạo một DB Instance MỚI trong CÙNG Availability Zone với instance gốc, theo cơ chế nỗ lực tối đa (best-effort).

Vì sao đúng

Đề cho một chi tiết quyết định: cụm chỉ có MỘT Aurora instance duy nhất, không có replica.

Và hành vi failover của Aurora phụ thuộc hoàn toàn vào việc có replica hay không:

CÓ Aurora Replica:
    → Aurora đổi CNAME của endpoint sang replica
    → replica được thăng cấp thành primary
    → thường DƯỚI 30 GIÂY

KHÔNG có replica (trường hợp của đề):
    → không có gì để chuyển sang
    → Aurora phải TẠO MỚI một DB instance
    → cố tạo trong CÙNG AZ, theo nỗ lực tối đa
    → mất VÀI PHÚT

Vì sao "best-effort" và vì sao cùng AZ:

Tầng lưu trữ của Aurora tách rời khỏi tầng compute
    → dữ liệu đã có 6 bản qua 3 AZ, KHÔNG mất
    → chỉ cần dựng lại phần compute
    ↓
Ưu tiên cùng AZ để gần tầng lưu trữ nhất
    → nhưng nếu AZ đó đang có sự cố hoặc hết dung lượng
    → "best-effort" nghĩa là có thể không thành công ngay

Và đây là bài học kiến trúc quan trọng của câu hỏi:

Đề nói thiết kế nhằm "high availability"
    → nhưng dùng MỘT instance Aurora duy nhất
    → tầng web có nhiều AZ, tầng dữ liệu thì KHÔNG
    → điểm hỏng đơn vẫn còn nguyên

Với sàn giao dịch ngoại hối, cấu hình đúng phải có ít nhất một Aurora Replica ở AZ khác.

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

  • **A. Aurora đổi CNAME sang replica khoẻ mạnh và thăng cấp nó thành primary — đây là phương án gần nhất và mô tả ĐÚNG cơ chế failover của Aurora, nhưng nó chỉ đúng khi CÓ REPLICA. Đề nói rõ cụm chỉ có một instance duy nhất, nên không có replica nào để chuyển sang.
  • **C. Aurora đổi bản ghi A sang replica — sai loại bản ghi: endpoint của Aurora là tên DNS, và cơ chế chuyển đổi dùng CNAME, không phải bản ghi A. (Và vẫn sai vì không có replica.)
  • **D. Aurora cố tạo instance ở AZ KHÁC trước, không được thì mới tạo ở AZ gốc — đảo ngược thứ tự ưu tiên: Aurora ưu tiên cùng AZ với instance gốc trước.

Ghi nhớ

Hành vi failover của Aurora — bảng cần thuộc: | Cấu hình | Cơ chế | Thời gian | |---|---|---| | Có Aurora Replica | đổi CNAME sang replica, thăng cấp | dưới 30 giây | | KHÔNG có replica | tạo mới DB instance, ưu tiên cùng AZ, best-effort | vài phút ← câu này |

Kiến trúc lưu trữ của Aurora — nền tảng của mọi hành vi trên:

Tầng COMPUTE (DB instance)  ←→  tách rời  ←→  Tầng LƯU TRỮ
                                                 ↓
                                    6 bản sao qua 3 AZ
                                    tự sửa lỗi, tự mở rộng tới 128 TB

Mất instance KHÔNG mất dữ liệu — đó là lý do Aurora dựng lại được instance mới rất nhanh.

Khả năng chịu lỗi của tầng lưu trữ Aurora: | Mất | Hậu quả | |---|---| | 2 trong 6 bản | vẫn GHI được bình thường | | 3 trong 6 bản | vẫn ĐỌC được | | — | tự sao chép lại phần thiếu trong nền |

Ba loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster endpoint (writer) | instance chính — dùng cho ghi | | Reader endpoint | tự cân bằng tải giữa các replica — dùng cho đọc | | Custom endpoint | nhóm instance do bạn định nghĩa |

Reader endpoint là tiện ích đáng giá: ứng dụng chỉ cần một địa chỉ, Aurora tự phân phối truy vấn đọc giữa các replica.

Và promotion tier quyết định replica nào được chọn khi failover:

Tier 0 (cao nhất) → được ưu tiên thăng cấp trước
Tier 15 (thấp nhất) → chọn sau cùng
    → cùng tier thì chọn replica có kích thước GẦN NHẤT với primary

aws rds modify-db-instance --db-instance-identifier aurora-replica-1   --promotion-tier 0

Aurora và RDS Multi-AZ — bảng phân biệt: | | Aurora | RDS Multi-AZ | |---|---|---| | Kiến trúc | tầng lưu trữ chung, 6 bản qua 3 AZ | 2 instance, 2 bản dữ liệu riêng | | Failover | dưới 30 giây (có replica) | 60–120 giây | | Replica phục vụ đọc | ✅ tới 15 | ❌ standby không đọc được | | Replica làm mục tiêu failover | ✅ | — |

Ba cấu hình ứng dụng cần có để failover mượt: | Cấu hình | Lý do | |---|---| | Dùng ENDPOINT, không hard-code IP | IP đổi sau failover | | Đặt TTL cache DNS ngắn | Java mặc định cache DNS VĨNH VIỄN | | Có cơ chế thử lại kết nối | failover mất vài giây tới vài phút |

Cạm bẫy kinh điển với ứng dụng Java:

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

Không đặt thì ứng dụng vẫn gọi tới IP cũ mãi sau khi failover xong.

Và một công cụ đáng dùng: RDS Proxy.

RDS Proxy đứng giữa ứng dụng và Aurora:
    ✓ gộp và tái dùng kết nối
    ✓ GIỮ kết nối của client trong lúc failover
    ✓ giảm thời gian failover cảm nhận được TỚI 66%

Với ứng dụng giao dịch nhạy cảm như sàn ngoại hối, đây là bổ sung rất đáng cân nhắc.

Ba tính năng khác của Aurora cho tình huống này: | Tính năng | Việc | |---|---| | Aurora Global Database | sao chép sang Region khác, độ trễ dưới 1 giây | | Backtrack | quay ngược cả cluster tới 72 giờ — chữa lỗi do người | | Aurora Serverless v2 | tự co giãn compute theo tải |

Và cách diễn tập failover:

aws rds failover-db-cluster --db-cluster-identifier cum-forex

Hãy chạy thử vào giờ thấp điểm để đo thời gian thật và kiểm chứng ứng dụng kết nối lại đúng — trước khi sự cố thật xảy ra.

Và một lời khuyên cho kiến trúc trong đề: thêm ít nhất một Aurora Replica ở AZ khác là thay đổi nhỏ nhất mang lại cải thiện lớn nhất. Nó vừa rút thời gian failover từ vài phút xuống dưới 30 giây, vừa cho thêm năng lực đọc — và với sàn giao dịch, vài phút ngừng dịch vụ là con số rất đắt.

Câu 283 Design Secure Architectures

A company has a web application hosted on a fleet of EC2 instances located in two Availability Zones that are all placed behind an Application Load Balancer. As a Solutions Architect, you have to add a health check configuration to ensure your application is highly-available.

Which health checks will you implement?

  1. A HTTP or HTTPS health check
  2. B ICMP health check
  3. C FTP health check
  4. D TCP health check
Xem giải thích

Đáp án

A — HTTP hoặc HTTPS health check.

Vì sao đúng

Đề dùng Application Load Balancer, và ALB chỉ hỗ trợ đúng hai giao thức health check.

Vì sao chỉ có HTTP và HTTPS:

ALB hoạt động ở TẦNG 7 (tầng ứng dụng)
    → nó HIỂU nội dung HTTP: đường dẫn, header, mã trạng thái
    → health check của nó cũng phải ở tầng đó
    → gửi request HTTP tới một đường dẫn và xét MÃ TRẢ VỀ

Và đó là điểm mạnh so với health check ở tầng thấp hơn:

Health check TCP (tầng 4):
    → chỉ kiểm tra "cổng có mở không"
    → ứng dụng treo nhưng vẫn giữ cổng mở → vẫn được coi là KHOẺ

Health check HTTP (tầng 7):
    → gọi thật vào ứng dụng và xét mã trả về
    → ứng dụng treo hoặc lỗi → nhận 5xx hoặc timeout → bị loại

Cấu hình:

aws elbv2 modify-target-group --target-group-arn <arn>   --health-check-protocol HTTP   --health-check-path /health   --health-check-port traffic-port   --matcher HttpCode=200   --health-check-interval-seconds 30   --healthy-threshold-count 2 --unhealthy-threshold-count 3

Và với kiến trúc hai AZ như đề mô tả, health check là thứ khiến "sẵn sàng cao" thành hiện thực:

Instance ở AZ-a hỏng
    → health check thất bại 3 lần liên tiếp
    → ALB NGỪNG gửi lưu lượng tới nó
    → mọi request chuyển sang instance ở AZ-b
    → người dùng không nhận ra gì

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

  • **D. TCP health check — đây là phương án gần nhất và là loại health check có thật, nhưng nó thuộc về Network Load Balancer, không phải ALB. Và nó yếu hơn: chỉ biết cổng có mở hay không, không biết ứng dụng có hoạt động đúng không.
  • **B. ICMP health check — không tồn tại trong Elastic Load Balancing: ICMP là giao thức của lệnh ping. Không load balancer nào của AWS dùng nó để kiểm tra sức khoẻ.
  • **C. FTP health check — cũng không tồn tại: không có loại health check nào dùng giao thức FTP.

Ghi nhớ

Giao thức health check theo từng loại load balancer: | Load balancer | Giao thức health check | |---|---| | Application Load Balancer | CHỈ HTTP, HTTPS | | Network Load Balancer | TCP, HTTP, HTTPS | | Gateway Load Balancer | TCP, HTTP, HTTPS | | Route 53 | HTTP, HTTPS, TCP |

NLB hỗ trợ cả HTTP dù nó hoạt động ở tầng 4 — và nên dùng HTTP khi có thể, vì nó kiểm tra được ứng dụng thật sự.

Các tham số health check của ALB: | Tham số | Mặc định | Khoảng cho phép | |---|---|---| | HealthCheckPath | / | tuỳ ý | | HealthCheckIntervalSeconds | 30 | 5–300 | | HealthCheckTimeoutSeconds | 5 | 2–120 | | HealthyThresholdCount | 5 | 2–10 | | UnhealthyThresholdCount | 2 | 2–10 | | Matcher | 200 | ví dụ 200-299, 200,301 |

Lỗi phổ biến nhất: đường dẫn mặc định /.

Ứng dụng chuyển hướng "/" sang "/dang-nhap" → trả 302
    → Matcher mặc định chỉ chấp nhận 200
    → health check THẤT BẠI
    → instance bị loại dù hoàn toàn khoẻ mạnh

Cách sửa: tạo endpoint riêng /health trả về 200 thuần, hoặc mở rộng Matcher thành 200-399.

Thiết kế endpoint health check tốt:

✅ Trả 200 nhanh, không phụ thuộc dịch vụ bên ngoài
✅ Kiểm tra được các phụ thuộc THIẾT YẾU (kết nối database)
✅ Không yêu cầu xác thực
✅ Trả nội dung nhẹ
❌ Đừng gọi API bên thứ ba
❌ Đừng ghi vào database

Cạm bẫy quan trọng: health check phụ thuộc quá nhiều thứ.

Health check kiểm tra cả database, cache, và ba dịch vụ khác
    → một dịch vụ phụ chậm → MỌI instance bị đánh dấu hỏng
    → ALB loại hết → dịch vụ sập hoàn toàn

Nguyên tắc: chỉ kiểm tra thứ mà instance đó thực sự cần để phục vụ request.

Ba trạng thái của target trong ALB: | Trạng thái | Ý nghĩa | |---|---| | initial | đang đăng ký, chưa đủ health check | | healthy | nhận lưu lượng bình thường | | unhealthy | không nhận lưu lượng | | draining | đang xử nốt kết nối cũ trước khi gỡ | | unused | không nằm trong target group đang dùng |

Trạng thái draining liên quan tới deregistration_delay — mặc định 300 giây. Với ứng dụng có request ngắn, giảm xuống 30 giây giúp việc thay instance nhanh hơn nhiều:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=deregistration_delay.timeout_seconds,Value=30

Và cấu hình Auto Scaling cần khớp với health check của ALB:

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

Mặc định ASG chỉ dùng EC2 status check — instance treo ở tầng ứng dụng nhưng máy vẫn sống sẽ không bị thay. Bật ELB mới bắt được.

Nhưng grace period phải đủ dài:

Ứng dụng khởi động 4 phút, grace period 60 giây
    → ASG coi instance mới là hỏng → chấm dứt → khởi chạy lại
    → VÒNG LẶP vô tận

Ba yếu tố khác cần có cho sẵn sàng cao thật sự: | Yếu tố | Chi tiết | |---|---| | Đủ dung lượng khi mất một AZ | 2 AZ nghĩa là mỗi AZ phải gánh được toàn bộ tải | | Database Multi-AZ | tầng web hai AZ mà database một AZ là vô nghĩa | | Cross-zone load balancing | ALB bật MẶC ĐỊNH; NLB thì không |

Và một cách kiểm tra nhanh khi target unhealthy:

aws elbv2 describe-target-health --target-group-arn <arn>

Trường Reason cho biết chính xác nguyên nhân: Target.ResponseCodeMismatch, Target.Timeout, hay Target.FailedHealthChecks.

Câu 284 Design High-Performing Architectures

In a startup company you are working for, you are asked to design a web application that requires a NoSQL database that has no limit on the storage size for a given table. The startup is still new in the market and it has very limited human resources who can take care of the database infrastructure.

Which is the most suitable service that you can implement that provides a fully managed, scalable and highly available NoSQL service?

  1. A DynamoDB
  2. B

    Amazon Neptune
  3. C

    Amazon Aurora
  4. D SimpleDB
Xem giải thích

Đáp án

A — Amazon DynamoDB.

Vì sao đúng

Đề nêu bốn yêu cầu, và DynamoDB đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Cơ sở dữ liệu NoSQL | DynamoDB là kho khoá–giá trị và tài liệu | | KHÔNG giới hạn dung lượng bảng | bảng tự lớn không giới hạn | | Được quản lý hoàn toàn, sẵn sàng cao | AWS lo mọi thứ — không có máy chủ nào | | Đội ngũ rất ít người | không cần quản trị viên cơ sở dữ liệu |

Điểm mạnh quyết định cho một startup thiếu nhân lực:

DynamoDB:
    ✓ Không có máy chủ để cấp phát hay vá lỗi
    ✓ Tự sao chép qua 3 AZ — sẵn sàng cao mặc định
    ✓ Tự sao lưu liên tục (point-in-time recovery)
    ✓ Chế độ on-demand: không cần dự báo dung lượng
        ↓
    Gần như KHÔNG có công vận hành nào

Và dung lượng thực sự không giới hạn:

Kích thước bảng:  KHÔNG giới hạn
Số item:          KHÔNG giới hạn
Giới hạn duy nhất: 400 KB cho MỘT item

Chế độ on-demand phù hợp nhất với startup:

aws dynamodb create-table --table-name nguoi-dung   --attribute-definitions AttributeName=ma_nguoi_dung,AttributeType=S   --key-schema AttributeName=ma_nguoi_dung,KeyType=HASH   --billing-mode PAY_PER_REQUEST

Không phải đoán trước lưu lượng — trả tiền theo request thật, tự mở rộng khi ứng dụng lan truyền.

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

  • **D. SimpleDB — đây là phương án gần nhất vì cũng là NoSQL của AWS, nhưng nó là dịch vụ thế hệ cũ đã bị thay thế bởi DynamoDB. Và nó có giới hạn cứng 10 GB mỗi domain — mâu thuẫn trực tiếp với yêu cầu "no limit on the storage size".
  • **B. Amazon Neptune — sai loại NoSQL: Neptune là cơ sở dữ liệu ĐỒ THỊ, dùng Gremlin hoặc SPARQL, phục vụ bài toán mạng lưới quan hệ (mạng xã hội, phát hiện gian lận). Nó không phải kho khoá–giá trị đa dụng.
  • **C. Amazon Aurora — là cơ sở dữ liệu QUAN HỆ, không phải NoSQL. Và dung lượng giới hạn ở 128 TB.

Ghi nhớ

Các dịch vụ cơ sở dữ liệu của AWS theo mô hình: | Mô hình | Dịch vụ | |---|---| | Khoá–giá trị / tài liệu | DynamoDB | | Quan hệ | RDS, Aurora | | Tài liệu (tương thích MongoDB) | DocumentDB | | Bộ nhớ đệm | ElastiCache, MemoryDB | | Đồ thị | Neptune | | Cột rộng (tương thích Cassandra) | Keyspaces | | Chuỗi thời gian | Timestream | | Sổ cái | QLDB |

Ba giới hạn thực sự của DynamoDB: | Giới hạn | Giá trị | |---|---| | Kích thước một item | 400 KB | | Số GSI mỗi bảng | 20 | | Số LSI mỗi bảng | 5 (và phải tạo cùng lúc với bảng) | | Dung lượng bảng | KHÔNG giới hạn |

Với item vượt 400 KB, mẫu chuẩn là lưu nội dung ở S3 và giữ đường dẫn trong DynamoDB.

Hai chế độ dung lượng: | | On-demand | Provisioned | |---|---|---| | Cấu hình | không cần gì | khai RCU/WCU | | Chi phí | đắt hơn mỗi request | rẻ hơn khi tải ỔN ĐỊNH | | Đột biến | hấp thụ ngay | có thể throttle | | Phù hợp | startup, tải khó đoán | tải đều đặn, đã biết mẫu |

Và với Provisioned, nhớ bật Auto Scaling — nó KHÔNG bật mặc định khi tạo bảng bằng CLI, SDK hay CloudFormation (chỉ Console mới bật sẵn).

Ba tính năng của DynamoDB giảm công vận hành: | Tính năng | Việc | |---|---| | Point-in-time recovery | khôi phục về bất kỳ giây nào trong 35 ngày | | TTL | tự xoá item hết hạn — MIỄN PHÍ | | DynamoDB Streams | bắt thay đổi, kích hoạt Lambda | | Global Tables | sao chép đa Region, đọc ghi ở mọi nơi |

TTL là tính năng tiết kiệm chi phí đáng dùng:

aws dynamodb update-time-to-live --table-name phien-dang-nhap   --time-to-live-specification "Enabled=true,AttributeName=het_han_luc"

Item tự biến mất khi tới hạn, không tốn WCU nào — hoàn hảo cho dữ liệu phiên, cache, log tạm.

Nguyên tắc thiết kế bảng DynamoDB — quan trọng nhất: | Nguyên tắc | Lý do | |---|---| | Thiết kế theo MẪU TRUY CẬP, không theo mô hình dữ liệu | khác hẳn cơ sở dữ liệu quan hệ | | Partition key có độ phân biệt CAO | tránh hot partition | | Dùng GSI cho truy vấn phụ | mỗi GSI có dung lượng riêng |

Dòng đầu là khác biệt tư duy lớn nhất:

Cơ sở dữ liệu quan hệ: chuẩn hoá trước, truy vấn sau (JOIN tuỳ ý)
DynamoDB:              biết trước sẽ truy vấn thế nào → thiết kế khoá cho phù hợp
    → đổi khoá chính sau này đòi TẠO BẢNG MỚI và di chuyển dữ liệu

Ba thao tác đọc và chi phí: | Thao tác | Đặc điểm | |---|---| | GetItem | lấy một item theo khoá — rẻ nhất, nhanh nhất | | Query | lấy nhiều item cùng partition key | | Scan | quét TOÀN BỘ bảng — tránh dùng trong sản xuất |

Scan là thao tác cần tránh: nó đọc mọi item và tính RCU cho tất cả, kể cả những item bị lọc bỏ. Với bảng lớn, một lệnh Scan có thể ngốn hết dung lượng và làm chậm cả ứng dụng.

Ba metric cần đặt alarm: | Metric | Cảnh báo khi | |---|---| | ThrottledRequests | request bị từ chối | | ConsumedReadCapacityUnits | tiến gần mức đã cấp | | SuccessfulRequestLatency | độ trễ tăng |

Nếu throttle xảy ra dù dung lượng còn dư, nguyên nhân thường là hot partition — dùng CloudWatch Contributor Insights để tìm khoá nào đang bị gọi quá nhiều.

Và một lời khuyên cho startup: bắt đầu với chế độ on-demand, chạy vài tháng để hiểu mẫu tải thật, rồi cân nhắc chuyển sang provisioned nếu tải đã ổn định. Chuyển đổi giữa hai chế độ được phép mỗi 24 giờ một lần, nên đó là quyết định có thể điều chỉnh về sau.

Câu 285 Design Secure Architectures

A news company is planning to use a Hardware Security Module (CloudHSM) in AWS for secure key storage of their web applications. You have launched the CloudHSM cluster but after just a few hours, a support staff mistakenly attempted to log in as the administrator three times using an invalid password in the Hardware Security Module. This has caused the HSM to be zeroized, which means that the encryption keys on it have been wiped. Unfortunately, you did not have a copy of the keys stored anywhere else.

How can you obtain a new copy of the keys that you have stored on Hardware Security Module?

  1. A Restore a snapshot of the Hardware Security Module.
  2. B Contact AWS Support and they will provide you a copy of the keys.
  3. C The keys are lost permanently if you did not have a copy.
  4. D Use the Amazon CLI to get a copy of the keys.
Xem giải thích

Đáp án

C — Khoá bị mất VĨNH VIỄN nếu bạn không có bản sao.

Vì sao đúng

Đề mô tả tình huống nghiêm trọng: HSM bị zeroize (xoá sạch) sau ba lần đăng nhập sai với vai trò quản trị.

Và đó là hành vi được thiết kế có chủ ý của phần cứng bảo mật:

HSM phát hiện nhiều lần đăng nhập thất bại
    → coi là dấu hiệu bị tấn công
    → TỰ XOÁ toàn bộ vật liệu khoá
    → đây là TÍNH NĂNG BẢO VỆ, không phải lỗi

Và mô hình bảo mật của CloudHSM khiến việc khôi phục là bất khả thi:

CloudHSM là mô hình "single-tenant"
    → AWS quản lý PHẦN CỨNG
    → BẠN quản lý hoàn toàn KHOÁ và người dùng
    ↓
AWS KHÔNG có quyền truy cập vào khoá của bạn
    → không thể lấy lại giúp bạn
    → không có "cửa sau" nào

Đây chính là điểm bán hàng của CloudHSM — và cũng là rủi ro của nó:

Kiểm soát tuyệt đối = trách nhiệm tuyệt đối

Và trách nhiệm đó nằm ở việc sao lưu:

CloudHSM có cơ chế BACKUP tự động
    → mã hoá và lưu trong S3 do AWS quản lý
    → khôi phục được vào cluster mới
        ↓
NHƯNG đề nói rõ: "you did not have a copy of the keys stored anywhere else"
    → không có bản sao → không có gì để khôi phục

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

  • **A. Khôi phục từ snapshot của HSM — đây là phương án gần nhất và CloudHSM thực sự có cơ chế sao lưu, nhưng nó không áp dụng được ở đây: đề nói rõ không có bản sao nào được lưu. Không có backup thì không có gì để khôi phục.
  • **B. Liên hệ AWS Support để họ cấp lại bản sao khoá — AWS KHÔNG BAO GIỜ có quyền truy cập khoá của bạn trong CloudHSM. Đó là bản chất của mô hình. Không có quy trình hỗ trợ nào lấy lại được.
  • **D. Dùng AWS CLI để lấy bản sao khoá — sai về mặt thiết kế: khoá riêng trong HSM không xuất ra được dưới dạng thuần. Đó là toàn bộ mục đích của thiết bị phần cứng bảo mật.

Ghi nhớ

CloudHSM và AWS KMS — bảng phân biệt cốt lõi: | | CloudHSM | AWS KMS | |---|---|---| | Mô hình thuê | single-tenant — thiết bị RIÊNG | multi-tenant | | Ai kiểm soát khoá | CHỈ BẠN — AWS không truy cập được | AWS quản lý, bạn kiểm soát policy | | Khôi phục khi mất | ❌ chỉ từ backup của bạn | ✅ AWS lo | | Chuẩn tuân thủ | FIPS 140-2 Level 3 | FIPS 140-2 Level 3 (HSM validated) | | Tích hợp dịch vụ AWS | hạn chế | ✅ rất rộng | | Chi phí | ~1,45 USD/giờ mỗi HSM | ~1 USD/khoá/tháng | | Công vận hành | cao — bạn quản lý người dùng, khoá, cụm | rất thấp |

Quy tắc chọn:

Cần FIPS 140-2 Level 3 với thiết bị riêng, hoặc yêu cầu pháp lý buộc chỉ bạn giữ khoá → CloudHSM Mọi trường hợp còn lại → KMS

Ba loại người dùng trong CloudHSM: | Vai | Quyền | |---|---| | PRECO | người dùng ban đầu, chỉ dùng để kích hoạt cụm | | CO (Crypto Officer) | quản lý người dùng và cụm ← vai bị đăng nhập sai trong đề | | CU (Crypto User) | tạo và dùng khoá | | AU (Appliance User) | AWS dùng cho việc đồng bộ và sao lưu |

Ngưỡng zeroize khác nhau theo vai:

Crypto Officer: 3 lần sai      ← đề này
Crypto User:    5 lần sai

Con số 3 trong đề khớp chính xác với ngưỡng của vai CO.

Ba cơ chế bảo vệ khoá trong CloudHSM: | Cơ chế | Chi tiết | |---|---| | Backup tự động | mỗi 24 giờ, mã hoá, lưu ở S3 do AWS quản lý | | Backup thủ công | tạo bất cứ lúc nào | | Nhiều HSM trong một cụm | tự đồng bộ khoá giữa các thiết bị |

Cấu hình sẵn sàng cao được khuyến nghị:

Ít nhất HAI HSM ở HAI Availability Zone khác nhau
    → khoá tự đồng bộ giữa chúng
    → một HSM hỏng thì cụm vẫn hoạt động

Một HSM duy nhất là điểm hỏng đơn — và cũng chính là tình huống của đề.

Sao chép backup sang Region khác cho phục hồi thảm hoạ:

aws cloudhsmv2 copy-backup-to-region   --destination-region us-west-2 --backup-id backup-abc123

Ba trường hợp dùng CloudHSM: | Trường hợp | Lý do | |---|---| | Yêu cầu pháp lý buộc chỉ bạn giữ khoá | AWS không truy cập được | | Cần FIPS 140-2 Level 3 với thiết bị riêng | tuân thủ nghiêm ngặt | | Offload SSL/TLS, ký mã, PKI riêng | HSM có hiệu năng mật mã cao |

Và CloudHSM tích hợp được với KMS qua custom key store:

KMS custom key store backed by CloudHSM:
    → dùng giao diện tiện lợi của KMS
    → nhưng vật liệu khoá nằm trong HSM của bạn
    → kết hợp được ưu điểm hai bên

Bốn thực hành bắt buộc khi vận hành CloudHSM: | Thực hành | Lý do | |---|---| | Sao lưu khoá ra ngoài, cất nơi an toàn | backup của AWS phụ thuộc vào cụm còn tồn tại | | Ghi lại thông tin đăng nhập CO ở nơi an toàn | 3 lần sai là mất tất cả | | Dùng nhiều HSM ở nhiều AZ | tránh điểm hỏng đơn | | Hạn chế số người biết mật khẩu CO | mỗi người là một nguồn rủi ro |

Dòng thứ hai là bài học trực tiếp của câu hỏi này: một nhân viên hỗ trợ gõ sai mật khẩu ba lần đã xoá sạch toàn bộ khoá của công ty. Quy trình quản lý mật khẩu quản trị viên phải chặt chẽ tương xứng với hậu quả.

Và một lời khuyên thực tế: với phần lớn tổ chức, AWS KMS là lựa chọn đúng. CloudHSM chỉ nên dùng khi có yêu cầu tuân thủ cụ thể buộc phải có thiết bị riêng — vì nó đắt hơn nhiều, đòi hỏi chuyên môn vận hành, và như câu hỏi này cho thấy, sai một bước là mất dữ liệu không cứu được.

Câu 286 Design Secure Architectures

A business plans to deploy an application on EC2 instances within an Amazon VPC and is considering adopting a Network Load Balancer to distribute incoming traffic among the instances. A solutions architect needs to suggest a solution that will enable the security team to inspect traffic entering and exiting their VPC.

Which approach satisfies the requirements?

  1. A

    Create a firewall using the AWS Network Firewall service at the VPC level then add custom rule groups for inspecting ingress and egress traffic. Update the necessary VPC route tables.
  2. B

    Use the Network Access Analyzer service on the application’s VPC for inspecting ingress and egress traffic. Create a new Network Access Scope to filter and analyze all incoming and outgoing requests.
  3. C

    Create a firewall at the subnet level using the Amazon Detective service. Inspect the ingress and egress traffic using the VPC Reachability Analyzer.
  4. D

    Enable Traffic Mirroring on the Network Load Balancer and forward traffic to the instances. Create a traffic mirror filter to inspect the ingress and egress of data that traverses your Amazon VPC.
Xem giải thích

Đáp án

A — Tạo tường lửa bằng AWS Network Firewall ở mức VPC, thêm rule group tuỳ chỉnh để kiểm tra lưu lượng vào và ra; cập nhật route table của VPC.

Vì sao đúng

Đề cần kiểm tra (inspect) lưu lượng vào và ra khỏi VPC — và AWS Network Firewall là dịch vụ được thiết kế cho đúng việc đó.

Vì sao Network Firewall khác với security group và NACL:

Security group, NACL:
    → lọc theo IP, cổng, giao thức (tầng 3–4)
    → KHÔNG nhìn vào NỘI DUNG gói tin

AWS Network Firewall:
    → kiểm tra sâu gói tin (deep packet inspection)
    → lọc theo TÊN MIỀN, chữ ký tấn công, nội dung
    → phát hiện và ngăn xâm nhập (IDS/IPS)

Kiến trúc triển khai — điểm quan trọng nhất:

Internet Gateway
    ↓ route table sửa lại
Firewall subnet (chứa endpoint của Network Firewall)
    ↓
Subnet ứng dụng

Lưu lượng phải được ĐỊNH TUYẾN qua endpoint của firewall — đó là lý do đề nhắc "update the necessary VPC route tables".

Hai loại rule group: | Loại | Lọc theo | |---|---| | Stateless | IP, cổng, giao thức — nhanh, đánh giá từng gói tin | | Stateful | theo luồng: tên miền, chữ ký Suricata, giao thức ứng dụng |

Ví dụ rule chặn theo tên miền:

{"RulesSource": {"RulesSourceList": {
   "TargetTypes": ["HTTP_HOST", "TLS_SNI"],
   "Targets": [".ten-mien-doc-hai.com"],
   "GeneratedRulesType": "DENYLIST"}}}

Và có thể dùng danh sách cho phép — chặt hơn nhiều:

{"GeneratedRulesType": "ALLOWLIST",
 "Targets": [".amazonaws.com", ".cong-ty.com"]}

Instance chỉ gọi được tới các tên miền đã duyệt — biện pháp chống rò rỉ dữ liệu rất hiệu quả.

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

  • **B. Dùng Network Access Analyzer để kiểm tra lưu lượng vào ra — đây là phương án gần nhất về mặt tên nghe giống, nhưng nó phân tích CẤU HÌNH, không kiểm tra LƯU LƯỢNG THẬT: Network Access Analyzer xác định những đường đi nào KHẢ THI dựa trên security group, NACL và route table. Nó là công cụ đánh giá tĩnh, không phải tường lửa.
  • **C. Tạo tường lửa ở mức subnet bằng Amazon Detective và kiểm tra bằng VPC Reachability Analyzer — sai vai trò cả hai: Detective là công cụ ĐIỀU TRA bảo mật (phân tích sự kiện sau khi có cảnh báo). Reachability Analyzer kiểm tra một đường mạng có thông không. Không cái nào lọc lưu lượng.
  • **D. Bật Traffic Mirroring trên Network Load Balancer — hai vấn đề: Traffic Mirroring chỉ SAO CHÉP lưu lượng để phân tích, nó không CHẶN được gì. Và nó bật trên ENI của instance, không phải trên load balancer.

Ghi nhớ

Các lớp kiểm soát mạng trong VPC — từ trong ra ngoài: | Lớp | Mức | Khả năng | |---|---|---| | Security group | ENI / instance | stateful, chỉ Allow, theo IP và cổng | | Network ACL | subnet | stateless, có Deny, theo CIDR | | AWS Network Firewall | VPC | kiểm tra sâu gói tin, theo tên miền, IDS/IPS | | AWS WAF | ALB, CloudFront, API Gateway | tầng 7, chỉ HTTP/HTTPS |

Network Firewall và WAF — đừng nhầm:

WAF:              lọc HTTP/HTTPS đi vào ứng dụng web
Network Firewall: lọc MỌI lưu lượng mạng vào/ra VPC, cả hai chiều

Chúng bổ sung nhau, không thay thế nhau.

Ba khả năng chính của AWS Network Firewall: | Khả năng | Chi tiết | |---|---| | Lọc theo tên miền | danh sách cho phép hoặc cấm cho lưu lượng RA | | Ngăn xâm nhập (IPS) | dùng chữ ký kiểu Suricata | | Kiểm tra TLS | giải mã và kiểm tra nội dung mã hoá |

Lọc lưu lượng RA (egress filtering) là giá trị lớn nhất trong thực tế:

Máy chủ bị xâm nhập
    → kẻ tấn công cố gửi dữ liệu ra máy chủ điều khiển
    → Network Firewall chặn vì tên miền không nằm trong danh sách cho phép
    → ngăn được bước rò rỉ dữ liệu

Security group không làm được việc này — nó không biết tên miền.

Ba lựa chọn kiểm tra lưu lượng — theo mức phức tạp: | Lựa chọn | Đặc điểm | |---|---| | AWS Network Firewall | được quản lý, ít công vận hành ← câu này | | Gateway Load Balancer + thiết bị bên thứ ba | dùng Palo Alto, Fortinet... | | Thiết bị ảo tự quản lý trên EC2 | kiểm soát cao nhất, công vận hành lớn nhất |

Gateway Load Balancer đáng biết: nó cho phép chèn thiết bị bảo mật của bên thứ ba vào đường đi của lưu lượng một cách trong suốt, với khả năng mở rộng và chịu lỗi tự động.

Ba công cụ phân tích mạng của AWS — đừng nhầm với tường lửa: | Công cụ | Việc | |---|---| | VPC Flow Logs | ghi metadata mọi luồng: IP, cổng, ACCEPT/REJECT | | Network Access Analyzer | phân tích CẤU HÌNH — đường đi nào khả thi | | Reachability Analyzer | kiểm tra một đường cụ thể có thông không | | Traffic Mirroring | sao chép gói tin để phân tích sâu |

Cả bốn đều là công cụ QUAN SÁT, không cái nào CHẶN được gì.

Kiến trúc route table khi dùng Network Firewall:

Route table của Internet Gateway (ingress routing):
    subnet-ung-dung-cidr → vpce-firewall

Route table của firewall subnet:
    0.0.0.0/0 → igw-xxxxx

Route table của subnet ứng dụng:
    0.0.0.0/0 → vpce-firewall

Đây là phần dễ sai nhất khi triển khai — thiếu một route là lưu lượng đi vòng qua firewall mà không ai biết.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí endpoint theo giờ | mỗi AZ một endpoint | | Phí xử lý dữ liệu mỗi GB | tích tụ với lưu lượng lớn | | Phí rule group được quản lý | một số bộ rule của AWS |

Với sẵn sàng cao, cần endpoint ở mỗi AZ — nên chi phí nhân theo số AZ.

Ba bộ rule được quản lý của AWS đáng dùng: | Bộ rule | Chống | |---|---| | AbusedLegitDomainsActionOrder | tên miền hợp pháp bị lạm dụng | | MalwareDomainsActionOrder | tên miền phát tán mã độc | | BotNetCommandAndControlDomainsActionOrder | máy chủ điều khiển botnet |

Và một lời khuyên khi triển khai: bắt đầu ở chế độ chỉ cảnh báo (alert) thay vì chặn, chạy vài tuần và xem log để biết rule sẽ chặn những gì. Một danh sách cho phép quá chặt sẽ làm hỏng những kết nối hợp lệ mà bạn không lường trước — và triệu chứng là timeout không rõ nguyên nhân, rất khó chẩn đoán.

Câu 287 Design Cost-Optimized Architectures

A company needs to use Amazon S3 to store irreproducible financial documents. For their quarterly reporting, the files are required to be retrieved after a period of 3 months. There will be some occasions when a surprise audit will be held, which requires access to the archived data that they need to present immediately.

What will you do to satisfy this requirement in a cost-effective way?

  1. A Use Amazon S3 Standard
  2. B Use Amazon S3 Standard - Infrequent Access
  3. C

    Use Amazon S3 -Intelligent Tiering
  4. D

    Use Amazon Glacier Deep Archive
Xem giải thích

Đáp án

B — Amazon S3 Standard-Infrequent Access (Standard-IA).

Vì sao đúng

Đề nêu ba điều kiện, và Standard-IA là lựa chọn duy nhất thoả cả ba: | Điều kiện | Yêu cầu | |---|---| | Tài liệu KHÔNG TÁI TẠO ĐƯỢC (irreproducible) | phải lưu ở NHIỀU AZ — độ bền cao | | Truy xuất theo quý (mỗi 3 tháng) | truy cập THƯA — không cần Standard | | Kiểm toán bất ngờ cần dữ liệu NGAY LẬP TỨC | phải truy xuất TỨC THÌ — không dùng Glacier được |

Vế thứ ba là điều kiện loại bỏ Glacier:

"requires access to the archived data that they need to present IMMEDIATELY"
    ↓
Glacier Deep Archive: 12–48 giờ  ✗
Glacier Flexible:     1 phút – 12 giờ  ✗ (không "immediately")
Standard-IA:          TỨC THÌ  ✅

Và vế "irreproducible" loại bỏ One Zone-IA:

One Zone-IA lưu ở MỘT AZ duy nhất
    → AZ đó bị phá huỷ → dữ liệu MẤT VĨNH VIỄN
    → tài liệu tài chính không tái tạo được thì không chấp nhận rủi ro này

Standard-IA cho cả hai:

Độ bền:      99,999999999% (11 số 9), lưu ở ≥ 3 AZ
Truy xuất:   TỨC THÌ, cùng độ trễ với Standard
Chi phí lưu: rẻ hơn Standard khoảng 45%

Đổi lại: có phí truy xuất theo GB — nhưng với dữ liệu chỉ đọc mỗi quý, khoản đó nhỏ hơn nhiều so với phần tiết kiệm được ở chi phí lưu trữ.

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

  • **C. S3 Intelligent-Tiering — đây là phương án gần nhất và cũng cho truy xuất tức thì với độ bền cao, nhưng nó không tối ưu khi mẫu truy cập ĐÃ BIẾT RÕ: Intelligent-Tiering có giá trị khi bạn không đoán được dữ liệu nào sẽ được đọc. Ở đây đề nói rõ là mỗi quý một lần — đặt Standard-IA tường minh rẻ hơn và tránh được phí giám sát theo object của Intelligent-Tiering.
  • **A. S3 Standard — đắt hơn không cần thiết: Standard dành cho dữ liệu truy cập thường xuyên. Với mẫu đọc mỗi ba tháng, bạn đang trả giá cao nhất cho thứ hầu như không dùng tới.
  • **D. Glacier Deep Archive — rẻ nhất nhưng vi phạm yêu cầu: thời gian truy xuất 12 giờ (Standard) tới 48 giờ (Bulk). Không thể trình bày dữ liệu "immediately" cho kiểm toán viên.

Ghi nhớ

Các lớp lưu trữ S3 — bảng cần thuộc: | Lớp | Số AZ | Truy xuất | Chi phí lưu | Phí truy xuất | |---|---|---|---|---| | Standard | ≥ 3 | tức thì | cao nhất | không | | Standard-IA | ≥ 3 | tức thì | ~45% rẻ hơn | có ← câu này | | One Zone-IA | 1 | tức thì | ~20% rẻ hơn IA | có | | Intelligent-Tiering | ≥ 3 | tức thì | tự tối ưu | không (có phí giám sát) | | Glacier Instant Retrieval | ≥ 3 | mili giây | rẻ hơn nữa | cao hơn | | Glacier Flexible | ≥ 3 | 1 phút – 12 giờ | rất rẻ | cao | | Glacier Deep Archive | ≥ 3 | 12–48 giờ | rẻ nhất | cao nhất |

Ba câu hỏi để chọn đúng lớp:

① Dữ liệu có TÁI TẠO ĐƯỢC không?
      Không → tránh One Zone-IA
② Cần truy xuất NHANH đến mức nào?
      Tức thì → Standard, IA, hoặc Glacier Instant Retrieval
      Chờ được vài giờ → Glacier Flexible
      Chờ được cả ngày → Deep Archive
③ Mẫu truy cập có ĐOÁN ĐƯỢC không?
      Có → đặt lớp tường minh
      Không → Intelligent-Tiering

Và Glacier Instant Retrieval đáng cân nhắc cho tình huống này:

Truy xuất MILI GIÂY như Standard-IA
    → và rẻ hơn Standard-IA về chi phí lưu trữ
    → đổi lại: phí truy xuất cao hơn, lưu tối thiểu 90 ngày

(Nó ra mắt sau khi câu hỏi được soạn. Với dữ liệu đọc đúng bốn lần mỗi năm, nó thường rẻ hơn Standard-IA về tổng chi phí.)

Ràng buộc thời gian lưu tối thiểu: | Lớp | Tối thiểu | |---|---| | Standard-IA, One Zone-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Glacier Deep Archive | 180 ngày |

Xoá trước hạn vẫn bị tính đủ phí.

Và một chi tiết về Standard-IA cần biết:

Object NHỎ HƠN 128 KB vẫn bị TÍNH PHÍ NHƯ 128 KB
    → với nhiều tệp tí hon, Standard-IA có thể ĐẮT HƠN Standard

Lọc theo kích thước trong lifecycle rule:

{"Filter": {"ObjectSizeGreaterThan": 131072},
 "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}]}

Bốn tầng của S3 Intelligent-Tiering: | Tầng | Chuyển sang khi | |---|---| | Frequent Access | mặc định | | Infrequent Access | 30 ngày không truy cập | | Archive Instant Access | 90 ngày không truy cập | | Archive Access (tuỳ chọn) | 90–730 ngày | | Deep Archive Access (tuỳ chọn) | 180–730 ngày |

Ưu điểm lớn nhất của Intelligent-Tiering: KHÔNG có phí truy xuất — nên một đợt kiểm toán bất ngờ đọc toàn bộ dữ liệu không tạo ra hoá đơn bất ngờ. Với dữ liệu tài chính hay bị kiểm toán đột xuất, đó là điểm đáng cân nhắc.

Ba biện pháp nên có cho tài liệu tài chính không tái tạo được: | Biện pháp | Lý do | |---|---| | Bật versioning | chống xoá nhầm và ghi đè nhầm | | S3 Object Lock ở chế độ Compliance | không ai xoá được trong thời hạn giữ — đáp ứng WORM | | Sao chép sang Region khác (CRR) | chịu được sự cố cả Region |

Dòng giữa đáng cân nhắc nghiêm túc: với dữ liệu "irreproducible" phục vụ kiểm toán, Object Lock biến việc xoá nhầm từ "rủi ro" thành "bất khả thi".

Và một lời khuyên: dùng S3 Storage Class Analysis để đo mẫu truy cập thật trong vài tháng trước khi chốt lớp lưu trữ. Nó cho biết dữ liệu thực sự được đọc bao nhiêu lần và khi nào — thay vì đoán, và có thể tiết kiệm đáng kể nếu mẫu thật khác dự tính.

Câu 288 Design Secure Architectures

An On-Demand EC2 instance is launched into a VPC subnet with the Network ACL configured to allow all inbound traffic and deny all outbound traffic. The instance’s security group has an inbound rule to allow SSH from any IP address and does not have any outbound rules. 

In this scenario, what are the changes needed to allow SSH connection to the instance?

  1. A The outbound security group needs to be modified to allow outbound traffic.
  2. B

    The network ACL needs to be modified to allow outbound traffic.
  3. C No action needed. It can already be accessed from any IP address using SSH.
  4. D Both the outbound security group and outbound network ACL need to be modified to allow outbound traffic.
Xem giải thích

Đáp án

B — Network ACL cần được sửa để cho phép lưu lượng ĐI RA.

Vì sao đúng

Đề mô tả một cấu hình rất cụ thể, và mấu chốt nằm ở sự khác biệt stateful và stateless.

Phân tích từng lớp:

NACL:
    inbound  = cho phép TẤT CẢ   ✅ request SSH vào được
    outbound = TỪ CHỐI tất cả    ✗ PHẢN HỒI không đi ra được

Security group:
    inbound  = cho phép SSH từ mọi IP  ✅
    outbound = KHÔNG có rule nào
        → nhưng security group STATEFUL
        → phản hồi cho kết nối vào được TỰ ĐỘNG cho phép
        → không cần rule outbound  ✅

Nên chỉ có một chỗ hỏng: chiều RA của NACL.

Vì sao NACL cần rule outbound mà security group thì không:

Security group STATEFUL:
    → ghi nhớ kết nối đã được phép vào
    → phản hồi tự động được phép ra
    → MỘT rule inbound là đủ

Network ACL STATELESS:
    → đánh giá từng gói tin ĐỘC LẬP
    → không biết gói tin đi ra là phản hồi của gói tin nào
    → PHẢI có rule outbound tường minh

Và rule outbound phải mở dải CỔNG TẠM, không phải cổng 22:

Client mở kết nối:
    IP client : cổng tạm 54321  ──▶  máy chủ : 22
Máy chủ trả lời:
    máy chủ : 22  ──▶  IP client : cổng tạm 54321
                                    ↑
              phản hồi đi TỚI cổng tạm, không phải cổng 22

Rule cần thêm:

aws ec2 create-network-acl-entry --network-acl-id acl-0abc123   --rule-number 100 --protocol tcp   --port-range From=32768,To=65535   --cidr-block 0.0.0.0/0 --rule-action allow --egress

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

  • **D. Cần sửa CẢ security group outbound LẪN NACL outbound — đây là phương án gần nhất và phần NACL đúng, nhưng phần security group thừa: security group là stateful nên phản hồi tự động được phép. Và security group mặc định vốn đã cho phép mọi lưu lượng ra.
  • **A. Chỉ cần sửa security group outbound — sai chỗ: security group không phải nguyên nhân. Sửa nó không giải quyết được việc NACL chặn chiều ra.
  • **C. Không cần làm gì, đã SSH được rồi — sai: NACL chặn chiều ra khiến phản hồi không về được client. Triệu chứng là kết nối treo rồi timeout, không phải kết nối thành công.

Ghi nhớ

Stateful và stateless — khác biệt quyết định: | | Security group | Network ACL | |---|---|---| | Trạng thái | STATEFUL | STATELESS | | Phản hồi | tự động được phép | phải có rule riêng cho CỔNG TẠM | | Số rule cho một dịch vụ | 1 (inbound) | 2 (inbound + outbound cổng tạm) | | Áp ở mức | ENI/instance | subnet | | Loại rule | chỉ Allow | Allow và Deny | | Đánh giá | mọi rule | theo thứ tự số, dừng ở rule đầu khớp |

Dải cổng tạm theo hệ điều hành: | Hệ thống | Dải | |---|---| | Linux nhân hiện đại | 32768–60999 | | Windows Server 2008 trở lên | 49152–65535 | | Elastic Load Balancer | 1024–65535 | | NAT Gateway | 1024–65535 |

Mở 32768–65535 phủ được hầu hết trường hợp; nếu có ELB hoặc NAT gateway trong đường đi thì mở 1024–65535.

Bốn mặc định cần nhớ: | Đối tượng | Mặc định | |---|---| | Security group mặc định của VPC | chặn inbound từ ngoài; cho phép mọi outbound | | Security group TỰ TẠO | chặn mọi inbound; cho phép mọi outbound | | NACL mặc định của VPC | CHO PHÉP mọi lưu lượng hai chiều | | NACL TỰ TẠO | CHẶN mọi lưu lượng hai chiều |

Hai dòng cuối gây rất nhiều sự cố khó chẩn đoán — người ta tạo NACL mới rồi ngạc nhiên vì mọi thứ ngừng hoạt động.

Bộ rule NACL tối thiểu cho SSH:

INBOUND
  100 | SSH (22)               | <IP cua ban>/32 | ALLOW
  110 | Custom TCP 32768-65535 | 0.0.0.0/0       | ALLOW  ← phản hồi cho kết nối RA
  *   | ALL                    | 0.0.0.0/0       | DENY

OUTBOUND
  100 | Custom TCP 32768-65535 | 0.0.0.0/0       | ALLOW  ← PHẢN HỒI SSH  ← thiếu cái này
  110 | HTTPS (443)            | 0.0.0.0/0       | ALLOW  ← cập nhật gói phần mềm
  *   | ALL                    | 0.0.0.0/0       | DENY

Kỹ thuật chẩn đoán khi kết nối bị chặn: | Triệu chứng | Nghi ngờ | |---|---| | Timeout, không phản hồi gì | security group hoặc NACL chặn | | Connection refused | tới được máy nhưng không có dịch vụ nghe cổng đó | | Chỉ MỘT instance hỏng | security group của instance đó | | CẢ SUBNET hỏng | NACL hoặc route table | | Bắt tay xong rồi treo | NACL thiếu rule cổng tạm ← đề này |

Dòng cuối là dấu hiệu đặc trưng của lỗi trong câu hỏi.

Công cụ chẩn đoán tốt nhất: VPC Flow Logs.

aws ec2 create-flow-logs --resource-type Subnet --resource-ids subnet-0abc   --traffic-type ALL --log-destination-type cloud-watch-logs   --log-group-name /vpc/flow-logs

Bản ghi có ACCEPT hoặc REJECT cho từng luồng — thấy REJECT ở chiều nào là biết lớp nào chặn.

Và một lời khuyên thiết kế: chỉ dùng NACL tuỳ chỉnh khi thực sự cần rule DENY.

Security group đủ cho phần lớn nhu cầu
    → stateful nên ít sai sót hơn hẳn
    → NACL tuỳ chỉnh nên dành cho:
        - chặn dải IP cụ thể
        - lớp phòng thủ bổ sung ở mức subnet

Và một lựa chọn tốt hơn hẳn việc mở SSH: AWS Systems Manager Session Manager — không cần cổng 22, không cần IP công khai, không cần khoá SSH, và có audit log đầy đủ. Với cấu hình đó, cả bài toán NACL cổng tạm này cũng biến mất.

Câu 289 Design Resilient Architectures

An investment bank has a distributed batch processing application which is hosted in an Auto Scaling group of Spot EC2 instances with an SQS queue. You configured your components to use client-side buffering so that the calls made from the client will be buffered first and then sent as a batch request to SQS. What is a period of time during which the SQS queue prevents other consuming components from receiving and processing a message?

  1. A Component Timeout
  2. B Visibility Timeout
  3. C Processing Timeout
  4. D Receiving Timeout
Xem giải thích

Đáp án

B — Visibility Timeout.

Vì sao đúng

Đề định nghĩa chính xác một khái niệm: khoảng thời gian SQS ngăn các consumer khác nhận và xử lý một thông điệp.

Và đó đúng là định nghĩa của visibility timeout:

Consumer gọi ReceiveMessage
    → thông điệp KHÔNG bị xoá, chỉ bị ẨN
    → bắt đầu đếm visibility timeout (mặc định 30 giây)
        ↓
Trong khoảng đó:
    → consumer khác gọi ReceiveMessage sẽ KHÔNG thấy thông điệp này
    → thông điệp ở trạng thái "đang bay" (in flight)
        ↓
Hết thời gian mà chưa có DeleteMessage:
    → thông điệp XUẤT HIỆN LẠI
    → consumer khác nhận được

Cơ chế này giải quyết hai vấn đề cùng lúc: | Vấn đề | Cách giải | |---|---| | Hai consumer cùng xử lý một thông điệp | thông điệp bị ẩn trong lúc đang xử lý | | Consumer chết giữa chừng | thông điệp tự quay lại, không mất công việc |

Và với kiến trúc Spot Instance như đề mô tả, vế thứ hai là thứ khiến hệ thống an toàn:

Spot bị thu hồi giữa chừng
    → không kịp gọi DeleteMessage
    → hết visibility timeout → thông điệp quay lại
    → máy khác xử lý lại

aws sqs set-queue-attributes --queue-url <url>   --attributes VisibilityTimeout=300

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

(Ba phương án còn lại đều là tên bịa, không tồn tại trong SQS.)

  • **A. Component Timeout — đây là phương án gần nhất về mặt nghe có vẻ hợp lý, nhưng SQS không có khái niệm nào tên như vậy.
  • **C. Processing Timeout — cũng không tồn tại. Nghe hợp lý vì nó mô tả đúng ý nghĩa, nhưng tên chính thức là visibility timeout.
  • **D. Receiving Timeout — không tồn tại. (Có ReceiveMessageWaitTimeSeconds cho long polling, nhưng đó là khái niệm khác hẳn.)

Ghi nhớ

Ba khái niệm thời gian của SQS — đừng nhầm: | Khái niệm | Việc | Mặc định | |---|---|---| | VisibilityTimeout | thời gian thông điệp bị ẩn sau khi được nhận | 30 giây (tối đa 12 giờ) | | MessageRetentionPeriod | thông điệp tồn tại bao lâu trong hàng đợi | 4 ngày (1 phút – 14 ngày) | | ReceiveMessageWaitTimeSeconds | long polling — chờ bao lâu nếu hàng đợi rỗng | 0 (tối đa 20 giây) | | DelaySeconds | hoãn thông điệp mới trước khi hiện ra | 0 (tối đa 15 phút) |

Cạm bẫy lớn nhất: visibility timeout NGẮN HƠN thời gian xử lý.

Xử lý mất 5 phút, visibility timeout 30 giây
    → sau 30 giây thông điệp xuất hiện lại
    → máy KHÁC bắt đầu xử lý cùng thông điệp
    → XỬ LÝ TRÙNG, và máy đầu vẫn đang chạy
    → có thể gây hậu quả nghiêm trọng (trừ tiền hai lần, gửi email hai lần)

Quy tắc: đặt visibility timeout LỚN HƠN thời gian xử lý dài nhất.

Và với thời gian xử lý không đoán trước, gia hạn động:

sqs.change_message_visibility(QueueUrl=q, ReceiptHandle=rh,
                              VisibilityTimeout=600)

Gọi định kỳ trong lúc xử lý — như một nhịp tim báo "tôi vẫn đang làm".

Và với Spot Instance, hãy trả thông điệp về ngay khi nhận cảnh báo thu hồi:

r = requests.get('http://169.254.169.254/latest/meta-data/spot/instance-action')
if r.status_code == 200:
    sqs.change_message_visibility(QueueUrl=q, ReceiptHandle=rh,
                                  VisibilityTimeout=0)

Đặt về 0 khiến thông điệp có sẵn LẬP TỨC — máy khác nhận ngay thay vì chờ hết timeout.

Vòng đời một thông điệp SQS:

Producer gửi → SẴN SÀNG
    ↓ ReceiveMessage
ĐANG BAY (in flight) — bị ẩn
    ├─ DeleteMessage           → XOÁ hẳn
    ├─ Hết visibility timeout  → quay lại SẴN SÀNG
    └─ Quá maxReceiveCount     → DEAD-LETTER QUEUE

Giới hạn số thông điệp đang bay: | Loại hàng đợi | Tối đa in flight | |---|---| | Standard | 120.000 | | FIFO | 20.000 |

Vượt giới hạn thì ReceiveMessage trả về lỗi — dấu hiệu consumer xử lý quá chậm hoặc quên gọi DeleteMessage.

Và client-side buffering mà đề nhắc tới:

Thư viện Buffered Async Client của SDK:
    → gom nhiều lời gọi thành MỘT request SendMessageBatch
    → tối đa 10 thông điệp hoặc 256 KB mỗi lô
    → giảm mạnh SỐ REQUEST → giảm chi phí

SQS tính phí theo số request, nên gộp lô là tối ưu chi phí quan trọng ở khối lượng lớn.

Long polling và short polling: | | Short polling (mặc định) | Long polling | |---|---|---| | ReceiveMessageWaitTimeSeconds | 0 | 1–20 | | Hàng đợi rỗng | trả về NGAY với kết quả rỗng | CHỜ tới khi có thông điệp | | Chi phí | cao — nhiều request rỗng | thấp |

Long polling nên bật cho mọi hàng đợi — nó vừa rẻ hơn vừa giảm độ trễ nhận thông điệp.

Dead-letter queue — cấu hình nên có:

{"RedrivePolicy": "{\"deadLetterTargetArn\":\"<arn-dlq>\",
                    \"maxReceiveCount\":\"3\"}"}

Thông điệp thất bại 3 lần được tách ra — nếu không nó quay lại mãi và chiếm chỗ.

Và một lời khuyên về mở rộng cho kiến trúc trong đề: dùng metric ApproximateNumberOfMessagesVisible làm cơ sở cho Auto Scaling. Đội máy Spot tự lớn lên khi hàng đợi dài và co lại khi xử lý hết — phản ánh nhu cầu thật chính xác hơn nhiều so với co giãn theo CPU.

Câu 290 Design High-Performing Architectures

A healthcare company manages patient data using a distributed system. The organization utilizes a microservice-based serverless application to handle various aspects of patient care. Data has to be retrieved and written from multiple Amazon DynamoDB tables.

The primary goal is to enable efficient retrieval and writing of data without impacting the baseline performance of the application as well as ensuring seamless access to patient information for healthcare professionals.

Which of the following is the MOST operationally efficient solution?

  1. A

    Utilize AWS AppSync pipeline resolvers
  2. B

    Launched AWS Lambda functions with an edge-optimized Amazon API Gateway
  3. C

    Set up DynamoDB connector for Amazon Athena Federated Query
  4. D

    Use CloudFront functions
Xem giải thích

Đáp án

A — Dùng AWS AppSync pipeline resolver.

Vì sao đúng

Đề nêu ba yêu cầu, và pipeline resolver của AppSync đáp ứng đúng cả ba: | Yêu cầu | Cơ chế | |---|---| | Đọc và ghi từ NHIỀU bảng DynamoDB | mỗi function trong pipeline thao tác với một nguồn dữ liệu | | KHÔNG ảnh hưởng hiệu năng nền của ứng dụng | AppSync gọi THẲNG DynamoDB, không qua Lambda | | Vận hành hiệu quả nhất | không có mã nào để bảo trì |

Điểm mạnh quyết định: AppSync gọi trực tiếp DynamoDB.

Kiến trúc thông thường:
    Client → API Gateway → Lambda → DynamoDB
        → có cold start của Lambda
        → phải viết và bảo trì mã Lambda
        → trả tiền cho thời gian chạy Lambda

AppSync với DynamoDB resolver:
    Client → AppSync → DynamoDB
        → KHÔNG có Lambda ở giữa
        → không cold start
        → chỉ khai ánh xạ, không viết mã xử lý

Và pipeline resolver cho phép nối nhiều bước trong MỘT request:

Một truy vấn GraphQL:
    Function 1 → đọc bảng "benh-nhan"
    Function 2 → đọc bảng "lich-kham" (dùng kết quả bước 1)
    Function 3 → đọc bảng "ket-qua-xet-nghiem"
        ↓
    Trả về MỘT phản hồi hợp nhất

Client gọi một lần, nhận đủ dữ liệu từ nhiều bảng — thay vì gọi ba API rồi tự ghép.

Và đó chính là ưu điểm cốt lõi của GraphQL cho ứng dụng y tế:

Bác sĩ mở hồ sơ bệnh nhân
    → cần thông tin cá nhân, lịch sử khám, đơn thuốc, kết quả xét nghiệm
    → REST: 4 request riêng
    → GraphQL: 1 request, lấy ĐÚNG những trường cần

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

  • **B. Dùng Lambda function với API Gateway edge-optimized — đây là phương án gần nhất và hoạt động hoàn toàn được, nhưng nó nhiều công vận hành hơn: phải viết, kiểm thử, triển khai và bảo trì mã Lambda cho từng thao tác; phải xử lý cold start; và với nhiều bảng thì mã phối hợp phức tạp dần. Đề hỏi cách "MOST operationally efficient".
  • **C. Dùng DynamoDB connector cho Athena Federated Query — sai mục đích: Athena Federated Query dành cho PHÂN TÍCH — chạy SQL trên nhiều nguồn dữ liệu. Nó không phải API cho ứng dụng, độ trễ tính bằng giây, và không GHI dữ liệu được.
  • **D. Dùng CloudFront Functions — sai hoàn toàn về khả năng: CloudFront Functions chạy dưới 1 mili giây, không truy cập mạng được, nên không gọi được DynamoDB. Chúng dùng để viết lại URL, sửa header — không phải để truy cập dữ liệu.

Ghi nhớ

Hai loại resolver của AppSync: | Loại | Đặc điểm | |---|---| | Unit resolver | một thao tác trên MỘT nguồn dữ liệu | | Pipeline resolver | chuỗi nhiều function chạy TUẦN TỰ ← câu này |

Các nguồn dữ liệu mà AppSync hỗ trợ: | Nguồn | Ghi chú | |---|---| | DynamoDB | gọi trực tiếp, không cần Lambda | | Aurora Serverless (Data API) | trực tiếp | | OpenSearch | trực tiếp | | Lambda | khi cần logic phức tạp | | HTTP endpoint | gọi API bên ngoài | | EventBridge | phát sự kiện | | None (local) | biến đổi dữ liệu tại chỗ |

Ba loại thao tác GraphQL: | Thao tác | Việc | |---|---| | Query | đọc dữ liệu | | Mutation | ghi dữ liệu | | Subscription | nhận cập nhật THỜI GIAN THỰC qua WebSocket |

Subscription là tính năng rất phù hợp với y tế:

Kết quả xét nghiệm mới về
    → mutation ghi vào DynamoDB
    → subscription tự đẩy tới mọi bác sĩ đang xem hồ sơ đó
    → không cần polling

Năm chế độ xác thực của AppSync: | Chế độ | Phù hợp | |---|---| | Amazon Cognito User Pool | người dùng ứng dụng — có group và claim | | IAM | dịch vụ nội bộ | | OIDC | nhà cung cấp danh tính bên ngoài | | Lambda authorizer | logic xác thực tuỳ chỉnh | | API key | chỉ cho phát triển và thử nghiệm |

Và AppSync hỗ trợ phân quyền tới TỪNG TRƯỜNG:

type BenhNhan @aws_cognito_user_pools {
  ma: ID!
  hoTen: String!
  soBaoHiem: String @aws_auth(cognito_groups: ["bac-si", "quan-tri"])
}

Y tá thấy tên bệnh nhân nhưng không thấy số bảo hiểm — quyền tối thiểu ở mức trường dữ liệu, rất phù hợp với yêu cầu bảo mật của ngành y tế.

Ba tính năng khác của AppSync: | Tính năng | Việc | |---|---| | Caching | giảm tải xuống nguồn dữ liệu | | Offline sync (Amplify DataStore) | ứng dụng di động dùng được khi mất mạng | | Merged API | gộp nhiều schema thành một API |

Ưu điểm của GraphQL so với REST cho ứng dụng phức tạp: | | GraphQL | REST | |---|---|---| | Số request | một request lấy đủ dữ liệu | nhiều endpoint | | Over-fetching | client khai đúng trường cần | trả về cả object | | Thời gian thực | subscription dựng sẵn | phải tự dựng WebSocket | | Cache HTTP | khó hơn | dễ — theo URL |

Nhược điểm cần biết: GraphQL khó cache ở tầng HTTP hơn REST, và một truy vấn lồng sâu có thể gây tải lớn bất ngờ — nên đặt giới hạn độ sâu và độ phức tạp của truy vấn.

Ba lưu ý cho ứng dụng y tế: | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | AppSync và DynamoDB đều đủ điều kiện HIPAA | | Mã hoá at rest | DynamoDB mã hoá mặc định | | Ghi log truy cập | bật CloudWatch Logs cho AppSync, ghi cả request và response |

Và một lưu ý về thiết kế bảng: với DynamoDB, hãy thiết kế theo mẫu truy cập của GraphQL schema. Nếu một truy vấn thường lấy bệnh nhân kèm lịch sử khám, cân nhắc mẫu single-table design — gộp cả hai loại item vào một bảng với partition key chung — thay vì để pipeline resolver phải gọi nhiều bảng.