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

Tìm thấy 2194 câu.

Câu 681 Chọn nhiều đáp án Design Secure Architectures

While troubleshooting, a cloud architect realized that the Amazon EC2 instance is unable to connect to the internet using the Internet Gateway.

Which conditions should be met for internet connectivity to be established? (Select two)

A
The network access control list (network ACL) associated with the subnet must have rules to allow inbound and outbound traffic
B
The route table in the instance’s subnet should have a route to an Internet Gateway
C
The instance's subnet is associated with multiple route tables with conflicting configurations
D
The subnet has been configured to be public and has no access to the internet
E
The instance's subnet is not associated with any route table

Xem giải thích

Đáp án

A và B.

A — Network ACL gắn với subnet phải có quy tắc cho phép lưu lượng cả VÀO lẫn RA
B — Route table của subnet chứa instance phải có route tới Internet Gateway

Vì sao đúng

Instance ra được Internet cần một chuỗi điều kiện, và hai đáp án là hai mắt xích trong đó.

B — route table là điều kiện định nghĩa public subnet:

Gắn Internet Gateway vào VPC là CHƯA ĐỦ
    → subnet phải có ROUTE trỏ tới nó
        ↓
    0.0.0.0/0 → igw-xxxxx

aws ec2 create-route --route-table-id rtb-public   --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0abc

Đây chính là ĐỊNH NGHĨA của public subnet:
    Public:  route table CÓ route tới IGW
    Private: KHÔNG có route đó

A — NACL là STATELESS nên phải mở cả hai chiều:

Security group STATEFUL:
    → cho phép ra thì phản hồi tự động được vào

NACL STATELESS:
    → mỗi chiều phải có quy tắc RIÊNG
        ↓
    Cho phép ra cổng 443
    NHƯNG không cho phép vào cổng ephemeral (1024–65535)
        ↓
    Phản hồi bị chặn → kết nối TREO

Cấu hình NACL đúng:

# Ra: cho phép mọi lưu lượng
aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 100 --protocol -1 --cidr-block 0.0.0.0/0   --rule-action allow --egress

# Vào: cổng ephemeral cho phản hồi
aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 100 --protocol tcp --port-range From=1024,To=65535   --cidr-block 0.0.0.0/0 --rule-action allow --ingress

Đây là lỗi kinh điển khi tự tạo NACL — NACL mặc định cho phép hết, nhưng NACL tự tạo từ chối hết.

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

**E. Subnet của instance KHÔNG liên kết với route table nào — đây là phương án gần nhất vì cũng nói về route table, nhưng nó không phải trạng thái có thật: mọi subnet luôn liên kết với một route table — nếu không liên kết tường minh thì dùng main route table của VPC.
**C. Subnet liên kết với NHIỀU route table có cấu hình mâu thuẫn — không làm được: một subnet chỉ liên kết với ĐÚNG MỘT route table tại một thời điểm.
**D. Subnet đã được cấu hình là public nhưng không có truy cập Internet — mâu thuẫn tự thân: "public" theo định nghĩa nghĩa là có route tới IGW. Câu này mô tả kết quả chứ không phải điều kiện.

Ghi nhớ

Năm điều kiện để instance ra Internet — bảng kiểm tra: | Điều kiện | Kiểm tra bằng | |---|---| | Internet Gateway gắn vào VPC | describe-internet-gateways | | Route 0.0.0.0/0 → IGW | describe-route-tables ← đáp án B | | Instance có IP công cộng hoặc EIP | describe-instances | | Security group cho phép | describe-security-groups | | NACL cho phép CẢ HAI chiều | describe-network-acls ← đáp án A |

Thiếu bất kỳ điều kiện nào là không hoạt động.

Security group và NACL — bảng phải thuộc: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI | SUBNET | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | chỉ Allow | Allow và Deny | | Thứ tự đánh giá | tất cả cùng lúc | theo SỐ THỨ TỰ, dừng ở quy tắc đầu khớp | | Tham chiếu SG khác | ✅ | ❌ chỉ CIDR | | Mặc định (tạo mới) | chặn inbound | TỪ CHỐI HẾT | | Mặc định (của VPC) | — | cho phép hết |

Hai dòng cuối là bẫy lớn:

NACL MẶC ĐỊNH của VPC: cho phép mọi thứ
NACL bạn TỰ TẠO:       từ chối mọi thứ
        ↓
    Gắn NACL tự tạo vào subnet mà quên thêm quy tắc
    = cắt đứt toàn bộ lưu lượng

Cổng ephemeral theo hệ điều hành: | Hệ thống | Dải cổng | |---|---| | Linux hiện đại | 32768–60999 | | Windows | 49152–65535 | | NLB, Lambda | 1024–65535 | | Khuyến nghị mở | 1024–65535 cho an toàn |

Ba đặc điểm của route table: | Đặc điểm | Chi tiết | |---|---| | Mỗi subnet liên kết ĐÚNG MỘT route table | | | Không liên kết tường minh → dùng main route table | | | Route cụ thể hơn thắng | /24 thắng /16 thắng /0 |

Ba đích của route: | Đích | Dùng cho | |---|---| | Internet Gateway | ra Internet (public subnet) | | NAT Gateway | private subnet ra Internet | | Virtual Private Gateway | on-premises qua VPN | | Transit Gateway | nối nhiều VPC | | VPC Endpoint | dịch vụ AWS riêng tư |

Ba đặc điểm của Internet Gateway: | Đặc điểm | Chi tiết | |---|---| | MỘT IGW mỗi VPC | gắn ở cấp VPC | | Dư thừa và sẵn sàng cao | AWS quản lý | | Thực hiện NAT 1:1 | IP công cộng KHÔNG hiện trong hệ điều hành |

Dòng cuối gây bối rối cho nhiều người:

ip addr show   # chỉ thấy IP RIÊNG

Internet Gateway dịch giữa IP công cộng và IP riêng
    → hệ điều hành chỉ biết IP riêng
        ↓
    Đây là hành vi bình thường, không phải lỗi

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | chỉ ra CHÍNH XÁC thành phần nào chặn | | VPC Flow Logs | thấy gói bị REJECT | | traceroute, curl | thử thủ công |

Reachability Analyzer là công cụ nhanh nhất:

aws ec2 create-network-insights-path   --source i-0abc --destination-ip 8.8.8.8   --protocol tcp --destination-port 443
aws ec2 start-network-insights-analysis --network-insights-path-id nip-0abc

Nó trả về đúng thành phần chặn: route table, NACL, hay security group.

Đọc VPC Flow Log:

2 123456789012 eni-abc 10.0.1.5 8.8.8.8 45678 443 6 1 40 ... REJECT OK
                                                            ↑
                                      bị từ chối — NACL hoặc SG chặn

Ba khuyến nghị về NACL: | Khuyến nghị | Lý do | |---|---| | Dùng security group làm lớp chính | stateful, dễ hơn nhiều | | NACL chỉ cho quy tắc thô ở cấp subnet | chặn dải IP xấu | | Nếu dùng NACL, nhớ mở cổng ephemeral | ← bài học của câu này |

Ba lưu ý về private subnet: | Lưu ý | Chi tiết | |---|---| | Ra Internet qua NAT Gateway | đặt ở public subnet | | NAT Gateway tính phí theo giờ và theo GB | | | Dùng VPC endpoint cho dịch vụ AWS | rẻ hơn NAT |

Và một lời khuyên: hãy dùng VPC Reachability Analyzer trước khi đọc từng cấu hình bằng tay. Nó chạy trong khoảng một phút và chỉ thẳng ra thành phần đang chặn — còn việc tự đối chiếu route table, NACL và security group thường mất nửa giờ và vẫn có thể bỏ sót đúng chiều bị thiếu trong một NACL stateless.

Câu 682 Design High-Performing Architectures

A big data analytics company is using Amazon Kinesis Data Streams (KDS) to process IoT data from the field devices of an agricultural sciences company. Multiple consumer applications are using the incoming data streams and the engineers have noticed a performance lag for the data delivery speed between producers and consumers of the data streams.

As a solutions architect, which of the following would you recommend for improving the performance for the given use-case?

A
Use Enhanced Fanout feature of Amazon Kinesis Data Streams
B
Swap out Amazon Kinesis Data Streams with Amazon Kinesis Data Firehose
C
Swap out Amazon Kinesis Data Streams with Amazon SQS FIFO queues
D
Swap out Amazon Kinesis Data Streams with Amazon SQS Standard queues

Xem giải thích

Đáp án

A — Dùng tính năng Enhanced Fan-Out của Kinesis Data Streams.

Vì sao đúng

Đề nêu đúng triệu chứng: NHIỀU ứng dụng consumer và độ trễ giao dữ liệu giữa producer và consumer.

Không có enhanced fan-out:
    → mỗi shard cho 2 MB/giây ĐỌC, CHIA CHUNG cho mọi consumer
    → và tối đa 5 lời gọi GetRecords mỗi giây mỗi shard
        ↓
    Nhiều consumer → mỗi cái được ít băng thông
    → và phải chờ lượt gọi API
        ↓
    Độ trễ tăng dần theo số consumer

Enhanced fan-out giải quyết cả hai:

Enhanced fan-out:
    ✓ MỖI consumer có 2 MB/giây RIÊNG mỗi shard
    ✓ dùng HTTP/2 push thay vì polling
        ↓
    Độ trễ giảm từ ~200 mili giây xuống ~70 mili giây
    Và không còn cạnh tranh băng thông

Phép tính cụ thể:

5 consumer, chia sẻ:
    2 MB/giây ÷ 5 = 400 KB/giây mỗi consumer

5 consumer, enhanced fan-out:
    2 MB/giây × 5 = 10 MB/giây tổng, mỗi cái đủ 2 MB/giây

Đăng ký consumer:

aws kinesis register-stream-consumer   --stream-arn <arn-stream> --consumer-name ung-dung-phan-tich

aws kinesis subscribe-to-shard   --consumer-arn <arn-consumer> --shard-id shardId-000000000000   --starting-position '{"Type":"LATEST"}'

Và cơ chế push của HTTP/2 là điểm khác biệt:

Polling truyền thống:
    consumer gọi GetRecords → chờ → gọi lại
    → độ trễ = khoảng cách giữa hai lần gọi

Enhanced fan-out:
    Kinesis ĐẨY bản ghi tới consumer ngay khi có
    → không có khoảng chờ

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

**B. Thay Kinesis Data Streams bằng Kinesis Data Firehose — đây là phương án gần nhất vì cũng là dịch vụ Kinesis, nhưng nó làm mất hẳn khả năng nhiều consumer: Firehose đẩy tới đích đã cấu hình và không cho ứng dụng đọc lại. Và độ trễ của nó cao hơn (~60 giây trở lên).
**C. Thay bằng SQS FIFO — sai mô hình: SQS là hàng đợi, thông điệp bị một consumer lấy đi chứ không phát cho nhiều consumer. Và FIFO có giới hạn thông lượng thấp hơn nhiều.
**D. Thay bằng SQS Standard — cùng vấn đề mô hình, và mất luôn thứ tự lẫn khả năng phát lại dữ liệu.

Ghi nhớ

Giới hạn của một shard Kinesis — bảng phải thuộc: | Chiều | Giới hạn | |---|---| | Ghi | 1.000 bản ghi/giây HOẶC 1 MB/giây | | Đọc chia sẻ | 2 MB/giây, tối đa 5 GetRecords/giây — CHIA CHUNG | | Đọc enhanced fan-out | 2 MB/giây RIÊNG mỗi consumer |

Enhanced fan-out và đọc chia sẻ — bảng phân biệt: | | Chia sẻ | Enhanced fan-out | |---|---|---| | Băng thông | 2 MB/giây CHIA CHUNG | 2 MB/giây MỖI consumer | | Cơ chế | polling (GetRecords) | push (HTTP/2) | | Độ trễ điển hình | ~200 ms | ~70 ms | | Số consumer khuyến nghị | 1–2 | tới 20 mỗi stream | | Chi phí | miễn phí | có phí consumer-shard-giờ |

Quy tắc: từ 3 consumer trở lên nên cân nhắc enhanced fan-out.

Ba dịch vụ luồng và hàng đợi — bảng phân biệt: | | Kinesis Data Streams | SQS | SNS | |---|---|---|---| | Mô hình | luồng, nhiều consumer đọc lại | hàng đợi, một consumer lấy | phát tán | | Giữ dữ liệu | 1–365 ngày | tới 14 ngày | ❌ | | Đọc lại được | ✅ | ❌ (đã xoá là mất) | ❌ | | Thứ tự | trong shard | FIFO queue | ❌ |

Từ khoá nhận diện:

"multiple consumers", "replay", "ordered stream" → Kinesis Data Streams "decouple", "one worker per message" → SQS "fan out to many subscribers" → SNS

Hai chế độ dung lượng của Kinesis: | Chế độ | Đặc điểm | |---|---| | Provisioned | khai số shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn tới 200 MB/giây |

Ba cách cải thiện hiệu năng Kinesis: | Cách | Giải quyết | |---|---| | Enhanced fan-out | nhiều consumer cạnh tranh băng thông ĐỌC ← câu này | | Thêm shard | thiếu dung lượng GHI | | Gộp lô ở producer | vượt giới hạn số bản ghi |

Ba nguyên nhân độ trễ trong Kinesis: | Nguyên nhân | Dấu hiệu | |---|---| | Nhiều consumer chia sẻ băng thông | ← câu này | | Consumer xử lý chậm | IteratorAgeMilliseconds tăng | | Thiếu shard phía ghi | WriteProvisionedThroughputExceeded |

IteratorAgeMilliseconds là metric quan trọng nhất:

Tăng đều:
    → consumer không theo kịp tốc độ ghi
    → dữ liệu sẽ hết hạn trước khi được xử lý
        ↓
    Đây là metric cần đặt alarm đầu tiên

Ba lưu ý về enhanced fan-out: | Lưu ý | Chi tiết | |---|---| | Tối đa 20 consumer đăng ký mỗi stream | | | Tính phí theo consumer-shard-giờ | ~0,015 USD | | Cộng thêm phí theo GB dữ liệu đọc | |

Ba lưu ý về partition key: | Lưu ý | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | băm MD5 | | Phân bố ĐỀU tránh hot shard | | | Cùng key = cùng shard = giữ thứ tự | |

Hot shard là nguyên nhân ẩn:

Stream 10 shard, tổng dung lượng dư
    → nhưng 80% bản ghi dùng cùng partition key
    → dồn vào MỘT shard
        ↓
    Metric cấp STREAM trông bình thường
    → phải bật shard-level metrics mới thấy

aws kinesis enable-enhanced-monitoring --stream-name du-lieu-iot   --shard-level-metrics ALL

Ba thư viện làm việc với Kinesis: | Thư viện | Việc | |---|---| | KPL (Producer Library) | gộp lô và aggregation | | KCL (Client Library) | quản lý con trỏ, cân bằng shard giữa worker | | SDK trực tiếp | linh hoạt nhất |

KCL đáng dùng cho consumer:

KCL tự lo:
    ✓ theo dõi vị trí đọc (checkpoint trong DynamoDB)
    ✓ cân bằng shard giữa các worker
    ✓ xử lý khi shard tách hoặc gộp
        ↓
    Và KCL 2.x hỗ trợ enhanced fan-out sẵn

Ba lựa chọn thay thế cho tải IoT: | Lựa chọn | Khi nào | |---|---| | AWS IoT Core | hàng triệu thiết bị, giao thức MQTT | | Amazon MSK | đã dùng Kafka | | Kinesis Data Streams | ← câu này |

Và một lời khuyên: hãy kiểm tra IteratorAgeMilliseconds của từng consumer trước khi bật enhanced fan-out. Nếu chỉ một consumer tụt lại còn các consumer khác vẫn theo kịp, vấn đề nằm ở tốc độ xử lý của chính ứng dụng đó chứ không phải băng thông chia sẻ — và enhanced fan-out sẽ tốn tiền mà không giải quyết được gì.

Câu 683 Design Secure Architectures

The infrastructure team at a company maintains 5 different VPCs (let's call these VPCs A, B, C, D, E) for resource isolation. Due to the changed organizational structure, the team wants to interconnect all VPCs together. To facilitate this, the team has set up VPC peering connection between VPC A and all other VPCs in a hub and spoke model with VPC A at the center. However, the team has still failed to establish connectivity between all VPCs.

As a solutions architect, which of the following would you recommend as the MOST resource-efficient and scalable solution?

A
Use an internet gateway to interconnect the VPCs
B
Use a VPC endpoint to interconnect the VPCs
C
Establish VPC peering connections between all VPCs
D
Use AWS transit gateway to interconnect the VPCs

Xem giải thích

Đáp án

D — Dùng AWS Transit Gateway để kết nối các VPC.

Vì sao đúng

Đề mô tả chính xác giới hạn cốt lõi của VPC peering: KHÔNG có định tuyến bắc cầu.

Mô hình hub-and-spoke bằng peering:
    A ↔ B, A ↔ C, A ↔ D, A ↔ E
        ↓
    B muốn nói với C:
        → phải đi qua A
        → nhưng VPC peering KHÔNG BẮC CẦU
        → B và C KHÔNG nói chuyện được

Đây là hạn chế thiết kế có chủ đích của VPC peering, không phải lỗi cấu hình.

Transit Gateway hoạt động như một bộ định tuyến trung tâm:

Transit Gateway:
    → mỗi VPC gắn vào bằng MỘT attachment
    → TGW định tuyến giữa mọi attachment
        ↓
    5 VPC = 5 attachment
    → mọi VPC nói chuyện được với nhau

Và phép so sánh về số lượng kết nối:

VPC peering full mesh với n VPC:
    số kết nối = n × (n − 1) ÷ 2
        ↓
    5 VPC  → 10 kết nối peering
    10 VPC → 45 kết nối
    20 VPC → 190 kết nối
        ↓
    Và mỗi VPC phải có route tới MỌI VPC khác trong route table

Transit Gateway:
    n VPC → n attachment
        ↓
    Tăng TUYẾN TÍNH — đây là ý nghĩa của "scalable"

Triển khai:

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

for vpc in vpc-a vpc-b vpc-c vpc-d vpc-e; do
  aws ec2 create-transit-gateway-vpc-attachment     --transit-gateway-id tgw-abc --vpc-id $vpc --subnet-ids <subnet>
done

Và route table của mỗi VPC chỉ cần một route:

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

Một dòng thay cho bốn dòng trỏ tới bốn peering connection.

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

**C. Thiết lập VPC peering giữa TẤT CẢ các VPC (full mesh) — đây là phương án gần nhất và thực sự giải quyết được kết nối, nhưng nó không mở rộng được: 5 VPC cần 10 kết nối, và mỗi VPC mới thêm vào cần peering với mọi VPC hiện có. Đề hỏi giải pháp "MOST resource-efficient and scalable".
**A. Dùng Internet Gateway để kết nối các VPC — sai công cụ: IGW cho phép ra Internet, không phải để nối các VPC riêng tư với nhau. Và đi qua Internet là bước lùi về bảo mật.
**B. Dùng VPC endpoint để kết nối các VPC — sai mục đích: VPC endpoint cho phép truy cập dịch vụ AWS hoặc dịch vụ qua PrivateLink một cách riêng tư, không phải để nối các VPC thành mạng chung.

Ghi nhớ

Ba hạn chế của VPC peering — bảng phải thuộc: | Hạn chế | Chi tiết | |---|---| | KHÔNG bắc cầu (transitive) | A↔B và A↔C KHÔNG cho B↔C ← câu này | | CIDR không được chồng lấn | | | Full mesh tăng theo n(n−1)/2 | |

VPC Peering và Transit Gateway — bảng phân biệt: | | VPC Peering | Transit Gateway | |---|---|---| | Bắc cầu | ❌ | ✅ | | Số kết nối với n VPC | n(n−1)/2 | n | | Băng thông | không giới hạn | 50 Gbps mỗi attachment | | Chi phí | chỉ phí truyền dữ liệu | phí attachment/giờ + truyền | | Nối VPN và Direct Connect | ❌ | ✅ | | Xuyên Region | ✅ | ✅ (TGW peering) |

Khi nào vẫn dùng peering:

Chỉ 2–3 VPC, kết nối đơn giản
    → peering rẻ hơn (không có phí attachment)
    → và băng thông không giới hạn
        ↓
    Từ 4–5 VPC trở lên, Transit Gateway thắng rõ

Ba loại attachment của Transit Gateway: | Loại | Nối tới | |---|---| | VPC attachment | một VPC | | VPN attachment | Site-to-Site VPN | | Direct Connect gateway | on-premises qua DX | | Peering attachment | TGW ở Region khác |

Đây là lợi thế lớn: một TGW nối được cả VPC, VPN và Direct Connect.

Ba khái niệm định tuyến của Transit Gateway: | Khái niệm | Việc | |---|---| | Association | attachment dùng route table nào để TRA CỨU | | Propagation | attachment quảng bá CIDR của nó vào route table nào | | Static route | khai tay |

Nhiều route table cho phép cách ly:

Route table "sản xuất": chỉ VPC sản xuất
Route table "phát triển": chỉ VPC phát triển
    → cả hai propagate vào route table "dùng chung"
        ↓
    Sản xuất và phát triển KHÔNG nói chuyện được với nhau
    nhưng cả hai đều tới được dịch vụ dùng chung

Đây là mẫu kiến trúc phổ biến nhất với Transit Gateway.

Ba lưu ý khi triển khai Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Attachment cần subnet ở mỗi AZ muốn dùng | | | Nên có subnet riêng cho TGW attachment | /28 là đủ | | CIDR các VPC không được chồng lấn | như peering |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Attachment | ~0,05 USD/giờ mỗi attachment (~36 USD/tháng) | | Truyền dữ liệu qua TGW | ~0,02 USD/GB | | — | với 5 VPC: ~180 USD/tháng phí attachment |

Peering rẻ hơn về phí cố định nhưng đắt hơn nhiều về công quản lý khi số VPC tăng.

Ba cách chia sẻ Transit Gateway: | Cách | Chi tiết | |---|---| | AWS Resource Access Manager (RAM) | chia sẻ TGW cho tài khoản khác trong tổ chức | | Một TGW cho cả tổ chức | mô hình tập trung | | TGW mỗi môi trường | cách ly mạnh hơn |

aws ram create-resource-share --name chia-se-tgw   --resource-arns <arn-tgw>   --principals <id-to-chuc> --allow-external-principals false

Ba giới hạn của Transit Gateway: | Giới hạn | Giá trị | |---|---| | Attachment mỗi TGW | 5.000 | | Băng thông mỗi attachment | 50 Gbps | | Route mỗi route table | 10.000 |

Dòng giữa là điểm cần lưu ý — VPC peering không có giới hạn này.

Ba lựa chọn kết nối VPC — bảng tổng hợp: | Lựa chọn | Phù hợp | |---|---| | VPC Peering | 2–3 VPC, băng thông rất cao | | Transit Gateway | nhiều VPC, cần bắc cầu ← câu này | | PrivateLink | expose MỘT dịch vụ, không nối cả mạng | | VPC Lattice | kết nối cấp ứng dụng, mới hơn |

PrivateLink khác về bản chất:

Transit Gateway: nối MẠNG với nhau
PrivateLink:     expose một DỊCH VỤ cụ thể
        ↓
    PrivateLink an toàn hơn khi chỉ cần một dịch vụ
    → không mở toàn bộ mạng

Ba công cụ giám sát Transit Gateway: | Công cụ | Việc | |---|---| | Transit Gateway Flow Logs | lưu lượng qua TGW | | Network Manager | hình dung toàn bộ mạng toàn cầu | | CloudWatch metric | băng thông, gói bị rớt |

Và một lời khuyên: hãy quy hoạch dải CIDR cho toàn bộ tổ chức trước khi tạo VPC mới. Cả peering lẫn Transit Gateway đều không xử lý được CIDR chồng lấn, và việc đổi dải địa chỉ của một VPC đang chạy nghĩa là dựng lại gần như toàn bộ hạ tầng mạng trong đó.

Câu 684 Design Cost-Optimized Architectures

A digital content production company has transitioned all of its media assets to Amazon S3 in an effort to reduce storage costs. However, the rendering engine used in production continues to run in an on-premises data center and requires frequent and low-latency access to large media files. The company wants to implement a storage solution that maintains application performance while keeping costs low.

Which approach should the company choose to meet these requirements in the most cost-effective way?

A
Set up an Amazon S3 File Gateway to provide storage for the on-premises application
B
Set up a dedicated on-premises storage array that periodically fetches data from Amazon S3 using a custom-built application. Mount this storage volume on the rendering servers as their primary working directory
C
Deploy an Amazon FSx for Lustre file system and sync media data from Amazon S3 into it using DataSync. Mount the FSx file system on the on-premises render servers using a VPN tunnel
D
Use Mountpoint for Amazon S3 on the on-premises rendering servers to facilitate low-latency access to the S3 bucket

Xem giải thích

Đáp án

A — Dựng Amazon S3 File Gateway làm lớp lưu trữ cho ứng dụng tại chỗ.

Vì sao đúng

Đề nêu ba ràng buộc, và S3 File Gateway đáp ứng cả ba: | Ràng buộc | Cơ chế | |---|---| | Dữ liệu ĐÃ ở S3 | File Gateway dùng S3 làm kho phía sau | | Ứng dụng TẠI CHỖ cần truy cập độ trễ thấp | CACHE cục bộ giữ tệp nóng | | Giữ chi phí thấp | chỉ trả cho S3 + gateway, không mua mảng lưu trữ |

Cơ chế cache là điểm mấu chốt:

S3 File Gateway:
    → xuất ra NFS hoặc SMB share tại chỗ
    → giữ bản sao tệp HAY DÙNG trên đĩa cục bộ
        ↓
    Đọc tệp đã trong cache → tốc độ ĐĨA CỤC BỘ
    Đọc tệp chưa có        → tải từ S3, rồi lưu vào cache

Và ứng dụng render không phải sửa gì:

Máy chủ render mount NFS share như bình thường
    → không biết dữ liệu thật nằm ở S3
        ↓
    Không phải viết lại ứng dụng dùng API của S3

Triển khai:

aws storagegateway create-nfs-file-share   --client-token $(uuidgen) --gateway-arn <arn-gateway>   --location-arn arn:aws:s3:::kho-media   --role <arn-role>   --client-list 192.168.1.0/24   --cache-attributes CacheStaleTimeoutInSeconds=300

Và mount từ máy chủ render:

sudo mount -t nfs -o nolock,hard <ip-gateway>:/kho-media /media

Ba đặc điểm quan trọng của S3 File Gateway: | Đặc điểm | Chi tiết | |---|---| | Mỗi tệp thành MỘT object S3 | đọc trực tiếp từ S3 được | | Ghi vào share → tự đẩy lên S3 | bất đồng bộ | | Kích thước cache tuỳ chọn | tối thiểu 150 GB |

Dòng đầu là lợi thế lớn:

Tệp ghi qua File Gateway = object S3 bình thường
    → ứng dụng đám mây đọc trực tiếp được
    → dùng được lifecycle, replication, Athena
        ↓
    Khác Volume Gateway (lưu dạng khối, chỉ đọc qua gateway)

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

**C. Dựng FSx for Lustre, đồng bộ từ S3 bằng DataSync, mount qua VPN — đây là phương án gần nhất vì Lustre thật sự tích hợp với S3 và cho hiệu năng rất cao, nhưng nó có độ trễ mạng của đường VPN cho MỌI thao tác: hệ thống tệp nằm trong AWS, còn máy chủ render ở tại chỗ. File Gateway giữ cache ngay tại trung tâm dữ liệu. Và Lustre đắt hơn nhiều.
**B. Mảng lưu trữ tại chỗ riêng với ứng dụng tự viết đồng bộ từ S3 — công vận hành và chi phí cao nhất: mua phần cứng, tự viết và bảo trì logic đồng bộ, tự xử lý lỗi.
**D. Dùng Mountpoint for Amazon S3 trên máy chủ render tại chỗ — không có cache cục bộ: Mountpoint là client đọc thẳng từ S3, mọi lần đọc đều qua Internet. Nó cũng chỉ hỗ trợ một tập con thao tác POSIX.

Ghi nhớ

Bốn chế độ của AWS Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Dùng cho | |---|---|---| | S3 File Gateway | NFS, SMB | tệp lưu vào S3, có cache ← câu này | | FSx File Gateway | SMB | truy cập FSx for Windows tại chỗ | | Volume Gateway | iSCSI (khối) | ổ đĩa, snapshot EBS | | Tape Gateway | iSCSI VTL | thay băng từ vật lý |

Từ khoá nhận diện:

"NFS/SMB access to S3 data", "low-latency on-premises", "cache" → S3 File Gateway "replace tape backup" → Tape Gateway "iSCSI block volumes" → Volume Gateway "one-time bulk migration" → DataSync

Storage Gateway và DataSync — bảng phân biệt: | | Storage Gateway | DataSync | |---|---|---| | Mục đích | truy cập LIÊN TỤC | DI CHUYỂN dữ liệu | | Sau khi chạy | vẫn dùng như file share | dữ liệu đã ở AWS | | Cache | ✅ | ❌ | | Phù hợp | ứng dụng tại chỗ đang chạy | migration, đồng bộ định kỳ |

Và hai cái thường dùng CÙNG nhau:

DataSync: chuyển khối lượng lớn ban đầu (nhanh)
File Gateway: truy cập liên tục sau đó
        ↓
    Đây là mẫu di chuyển được khuyến nghị

Ba cách triển khai gateway: | Cách | Chi tiết | |---|---| | Máy ảo (VMware, Hyper-V, KVM) | phổ biến nhất | | Amazon EC2 | cho tải chạy trên AWS | | Phần cứng chuyên dụng | Hardware Appliance |

Ba yêu cầu hạ tầng: | Yêu cầu | Chi tiết | |---|---| | Đĩa cache tối thiểu 150 GB | cache lớn = tỷ lệ trúng cao | | Băng thông đủ cho việc tải lên | | | Cổng 443 ra AWS | hoặc VPC endpoint |

Kích thước cache là quyết định thiết kế quan trọng:

Cache nhỏ:
    → tỷ lệ trúng thấp
    → nhiều lần đọc phải kéo từ S3
    → độ trễ như không có gateway

Quy tắc: cache đủ chứa "tập dữ liệu đang làm việc"
    → với render, thường là các dự án đang chạy

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CachePercentUsed | đầy thì phải đuổi dữ liệu | | CacheHitPercent | thấp = cache quá nhỏ | | CloudBytesDownloaded | lượng kéo từ S3 |

Ba lưu ý về nhất quán dữ liệu: | Lưu ý | Chi tiết | |---|---| | Ghi qua share → đẩy lên S3 BẤT ĐỒNG BỘ | có độ trễ | | Object ghi thẳng vào S3 không tự hiện trong share | phải RefreshCache | | CacheStaleTimeoutInSeconds tự làm mới định kỳ | |

Dòng giữa là bẫy hay gặp:

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

Ứng dụng đám mây ghi object mới vào bucket
    → File Gateway KHÔNG biết
    → máy chủ tại chỗ không thấy tệp đó
        ↓
    Phải gọi RefreshCache, hoặc đặt CacheStaleTimeout

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Dùng SSD cho đĩa cache | | | Băng thông upload quyết định tốc độ ghi | | | Giới hạn băng thông theo giờ nếu cần | tránh nghẽn giờ làm việc |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest trong S3 | SSE-S3 hoặc SSE-KMS | | Truyền qua TLS | | | client-list giới hạn IP mount được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ S3 | theo lớp | | Phí gateway | theo lượng dữ liệu ghi | | Truyền dữ liệu ra khỏi AWS | khi đọc tệp chưa có trong cache |

Dòng cuối đáng lưu ý:

Tỷ lệ trúng cache thấp
    → nhiều lần kéo từ S3
    → phí truyền dữ liệu ra tăng
        ↓
    Cache lớn hơn có thể RẺ HƠN tổng thể

Ba lưu ý về lớp lưu trữ S3 phía sau: | Lưu ý | Chi tiết | |---|---| | File Gateway ghi vào S3 Standard mặc định | | | Lifecycle chuyển tệp cũ sang IA hoặc Glacier | | | Tệp đã sang Glacier KHÔNG đọc qua share được ngay | phải khôi phục trước |

Và một lời khuyên: hãy cấp đĩa cache lớn hơn ước tính ban đầu. Đĩa cục bộ rẻ hơn nhiều so với phí truyền dữ liệu và thời gian chờ của đội render — và tăng dung lượng cache sau khi gateway đã chạy đòi hỏi thêm đĩa mới rồi cấu hình lại, chứ không đơn giản như mở rộng một volume.

Câu 685 Design Cost-Optimized Architectures

A multinational logistics company operates its shipment tracking platform from Amazon EC2 instances deployed in the AWS us-west-2 Region. The platform exposes a set of APIs over HTTPS, which are used by logistics partners and customers around the world to retrieve real-time tracking data. The company has observed that users from Europe and Asia experience latency issues and inconsistent API response times when accessing the service. As a cloud architect, you have been tasked to propose the most cost-effective solution to improve performance for these international users without migrating the application.

Which solution should you recommend?

A
Deploy Amazon API Gateway in multiple AWS Regions and synchronize the API definitions. Use AWS Lambda as a proxy to forward requests to the EC2-hosted API in us-west-2
B
Deploy an Amazon CloudFront distribution in front of the API endpoint and apply the CachingOptimized managed policy to enhance caching behavior and improve content delivery efficiency
C
Set up AWS Global Accelerator with listeners configured for HTTPS. Create endpoint groups for Europe and Asia and add the existing us-west-2 EC2 endpoint to these groups
D
Use Amazon Route 53 latency-based routing to direct user requests to a copy of the EC2 API deployed in each major geographic Region

Xem giải thích

Đáp án

C — Dựng AWS Global Accelerator với listener HTTPS; tạo endpoint group cho châu Âu và châu Á, thêm endpoint EC2 ở us-west-2 vào các group đó.

Vì sao đúng

Đề nêu ba ràng buộc, và Global Accelerator đáp ứng cả ba: | Ràng buộc | Cơ chế | |---|---| | Cải thiện độ trễ cho người dùng châu Âu và châu Á | lưu lượng vào mạng riêng của AWS ở edge gần nhất | | KHÔNG di chuyển ứng dụng | ứng dụng vẫn ở us-west-2 | | Tiết kiệm chi phí nhất | không phải nhân bản hạ tầng |

Cơ chế giảm độ trễ của Global Accelerator:

Không có Global Accelerator:
    Người dùng ở Tokyo → Internet công cộng → us-west-2
        ↓
    Nhiều chặng, qua nhiều nhà mạng
    → độ trễ cao và BIẾN ĐỘNG

Có Global Accelerator:
    Người dùng ở Tokyo → edge location Tokyo (rất gần)
        → MẠNG RIÊNG của AWS → us-west-2
        ↓
    Ít chặng qua Internet công cộng
    → độ trễ thấp hơn và ỔN ĐỊNH hơn

Và đây chính là vế "inconsistent API response times" trong đề:

Vấn đề không chỉ là độ trễ CAO
    → mà còn là BIẾN ĐỘNG (jitter)
        ↓
    Mạng riêng của AWS cho độ trễ ổn định hơn nhiều
      so với đường Internet công cộng

Triển khai:

aws globalaccelerator create-accelerator --name tang-toc-api --enabled

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

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region us-west-2   --endpoint-configurations EndpointId=<arn-alb>,Weight=128

Và vì sao đây là lựa chọn rẻ nhất:

Global Accelerator: ~18 USD/tháng + phí truyền dữ liệu
    → KHÔNG nhân bản EC2, database, hay hạ tầng nào
        ↓
Triển khai ứng dụng ở 3 Region:
    → gấp 3 chi phí tính toán và vận hành
    → cộng phức tạp của đồng bộ dữ liệu

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

**B. Đặt CloudFront trước API endpoint với chính sách CachingOptimized — đây là phương án gần nhất và CloudFront thật sự có mạng biên toàn cầu, nhưng CachingOptimized sai với API dữ liệu THỜI GIAN THỰC: dữ liệu theo dõi vận đơn thay đổi liên tục, đệm sẽ trả về thông tin cũ. (CloudFront với CachingDisabled và origin shield vẫn giúp về mặt mạng, nhưng Global Accelerator được thiết kế riêng cho việc tăng tốc TCP như thế này.)
**D. Route 53 latency-based routing tới bản sao API ở mỗi Region — đòi triển khai lại ứng dụng ở nhiều Region, trái yêu cầu "without migrating the application" và tốn kém hơn nhiều.
**A. API Gateway ở nhiều Region + Lambda proxy chuyển tiếp về us-west-2 — thêm chặng làm CHẬM HƠN: request đi qua API Gateway rồi Lambda rồi mới tới EC2, mỗi tầng thêm độ trễ.

Ghi nhớ

Global Accelerator và CloudFront — bảng phải thuộc: | | Global Accelerator | CloudFront | |---|---|---| | Cơ chế | định tuyến qua mạng riêng AWS | ĐỆM nội dung ở biên | | Giao thức | TCP và UDP, mọi cổng | chỉ HTTP/HTTPS | | Nội dung động | ✅ tối ưu cho việc này | có (nhưng không đệm được) | | Địa chỉ | 2 IP anycast tĩnh | tên miền | | Chuyển vùng Region | ~30 giây | theo origin |

Quy tắc chọn:

Nội dung TĨNH đệm được → CloudFront API động, TCP/UDP, cần IP tĩnh → Global Accelerator

Và hai cái dùng CÙNG nhau được:

CloudFront cho tài nguyên tĩnh (ảnh, JS, CSS)
Global Accelerator cho API động
        ↓
    Mỗi cái làm đúng việc của nó

Ba lợi ích của Global Accelerator: | Lợi ích | Chi tiết | |---|---| | Giảm độ trễ và jitter | ← câu này | | 2 IP anycast tĩnh | cho danh sách trắng tường lửa | | Chuyển vùng ~30 giây | không phụ thuộc TTL của DNS |

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

Lưu ý về cấu hình trong đề:

Đề nói "tạo endpoint group cho châu Âu và châu Á,
 thêm endpoint us-west-2 vào các group đó"
        ↓
    Endpoint group gắn với REGION CỦA ENDPOINT,
    không phải khu vực của NGƯỜI DÙNG
        ↓
    Với một Region duy nhất, chỉ cần MỘT endpoint group us-west-2
    → Global Accelerator tự định tuyến người dùng toàn cầu tới đó

Cách diễn đạt của đề hơi lỏng, nhưng ý định (dùng Global Accelerator) là đúng.

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

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

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, khác nhau theo khu vực | | — | không có phí request |

So sánh chi phí với việc mở rộng đa Region:

Global Accelerator: ~18 USD/tháng + truyền dữ liệu
Triển khai thêm 2 Region: hàng nghìn USD/tháng
        ↓
    Với yêu cầu "most cost-effective", chênh lệch rất rõ

Ba cách khác cải thiện độ trễ cho người dùng xa: | Cách | Chi phí | |---|---| | Global Accelerator | thấp ← câu này | | CloudFront cho phần đệm được | thấp | | Triển khai đa Region | cao |

Ba lưu ý về đo lường trước và sau: | Đo | Cách | |---|---| | Độ trễ từ nhiều vị trí | CloudWatch Synthetics canary | | Phân bố P50, P95, P99 | quan trọng hơn trung bình | | Tỷ lệ lỗi và timeout | |

CloudWatch Synthetics là công cụ tốt cho việc này:

aws synthetics create-canary --name kiem-tra-api-tokyo   --artifact-s3-location s3://ket-qua/   --execution-role-arn <arn> --runtime-version syn-nodejs-puppeteer-6.2   --schedule Expression="rate(5 minutes)"

Chạy canary từ nhiều Region để đo trải nghiệm thật của người dùng.

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 | | Traffic dial | tỷ lệ lưu lượng mỗi Region | | Vị trí client | Region gần nhất khoẻ mạnh |

Ba biện pháp bổ sung: | Biện pháp | Chi tiết | |---|---| | AWS Shield Standard tự động | chống DDoS | | WAF trên ALB phía sau | lọc tầng 7 | | Bật HTTP keep-alive | giảm số lần bắt tay TLS |

Dòng cuối đáng lưu ý cho API:

Mỗi kết nối mới cần bắt tay TCP + TLS
    → với người dùng ở xa, đó là 2–3 vòng lượt
    → có thể chiếm phần lớn thời gian phản hồi
        ↓
    Keep-alive và HTTP/2 giảm đáng kể chi phí này

Và một lời khuyên: hãy đo độ trễ P95 từ Tokyo và Frankfurt trước khi bật Global Accelerator, rồi đo lại sau. Mức cải thiện phụ thuộc vào chất lượng đường Internet giữa người dùng và Region đích — thường là 20–60%, nhưng con số cụ thể của bạn là thứ duy nhất chứng minh được khoản chi này xứng đáng.

Câu 686 Design Cost-Optimized Architectures

A media company wants to get out of the business of owning and maintaining its own IT infrastructure. As part of this digital transformation, the media company wants to archive about 5 petabytes of data in its on-premises data center to durable long term storage.

As a solutions architect, what is your recommendation to migrate this data in the MOST cost-optimal way?

A
Transfer the on-premises data into multiple AWS Snowball Edge Storage Optimized devices. Copy the AWS Snowball Edge data into Amazon S3 and create a lifecycle policy to transition the data into Amazon S3 Glacier
B
Setup AWS Site-to-Site VPN connection between the on-premises data center and AWS Cloud. Use this connection to transfer the data into Amazon S3 Glacier
C
Setup AWS direct connect between the on-premises data center and AWS Cloud. Use this connection to transfer the data into Amazon S3 Glacier
D
Transfer the on-premises data into multiple AWS Snowball Edge Storage Optimized devices. Copy the AWS Snowball Edge data into Amazon S3 Glacier

Xem giải thích

Đáp án

A — Chuyển dữ liệu vào nhiều thiết bị Snowball Edge Storage Optimized, chép dữ liệu vào Amazon S3, rồi dùng lifecycle policy chuyển sang S3 Glacier.

Vì sao đúng

Đề cho hai dữ kiện quyết định: 5 petabyte và tối ưu chi phí nhất.

Vì sao phải dùng Snowball:

5 PB qua đường mạng 1 Gbps (dùng hết băng thông):
    5.000.000 GB × 8 bit ÷ 1 Gbps ≈ 40.000.000 giây
        ↓
    Khoảng 463 NGÀY — hơn một năm
        ↓
    Không khả thi, và chi phí băng thông khổng lồ

Và Snowball Edge Storage Optimized:

Mỗi thiết bị: ~80 TB dung lượng dùng được
    → 5 PB cần khoảng 63 thiết bị
    → AWS gửi song song nhiều thiết bị
        ↓
    Hoàn tất trong vài tuần

⚠ Và điểm mấu chốt: Snowball KHÔNG chuyển thẳng vào Glacier.

Snowball chỉ có MỘT đích: Amazon S3
    → không có tuỳ chọn "chuyển vào Glacier" trực tiếp
        ↓
    Quy trình đúng:
        ① Snowball → S3 (lớp Standard)
        ② Lifecycle policy → chuyển sang Glacier

Đây chính là khác biệt giữa đáp án A và D.

Quy trình đầy đủ:

aws snowball create-job --job-type IMPORT   --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::kho-luu-tru"}]}'   --address-id <id-dia-chi> --role-arn <arn-role>   --snowball-type EDGE_S   --shipping-option SECOND_DAY_SHIPPING

Và lifecycle chuyển sang Glacier:

{"Rules": [{
  "ID": "chuyen-sang-glacier",
  "Status": "Enabled",
  "Filter": {},
  "Transitions": [{"Days": 1, "StorageClass": "DEEP_ARCHIVE"}]}]}

Với dữ liệu lưu trữ dài hạn, Deep Archive rẻ hơn nhiều:

5 PB mỗi tháng:
    S3 Standard:     ~115.000 USD
    Glacier Flexible: ~18.000 USD
    Deep Archive:     ~5.000 USD
        ↓
    Chênh lệch rất lớn ở quy mô này

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

**D. Chuyển vào Snowball Edge rồi chép thẳng vào S3 Glacier — đây là phương án gần nhất và chỉ khác đáp án đúng ở một bước, nhưng đó là bước không tồn tại: Snowball chỉ nhập vào S3, không nhập trực tiếp vào Glacier. Phải qua S3 rồi mới chuyển lớp.
**B. Dùng Site-to-Site VPN chuyển dữ liệu — hoàn toàn không khả thi: VPN tối đa ~1,25 Gbps mỗi tunnel, chuyển 5 PB mất hơn một năm.
**C. Dùng Direct Connect — nhanh hơn VPN nhưng vẫn quá lâu và quá tốn: kể cả đường 10 Gbps dùng hết công suất cũng mất khoảng 46 ngày, cộng chi phí kéo đường và phí cổng.

Ghi nhớ

Họ AWS Snow — bảng phải thuộc: | Thiết bị | Dung lượng | Phù hợp | |---|---|---| | Snowcone | 8 TB (HDD) / 14 TB (SSD) | nhỏ, môi trường khắc nghiệt | | Snowball Edge Storage Optimized | ~80 TB dùng được | di chuyển dữ liệu lớn ← câu này | | Snowball Edge Compute Optimized | ~28 TB + GPU | xử lý tại biên | | Snowmobile | tới 100 PB | exabyte (dịch vụ đã ngừng nhận mới) |

Quy tắc ước lượng — khi nào dùng Snowball:

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

Nếu kết quả > 1 tuần → cân nhắc Snowball
Nếu > 1 tháng        → chắc chắn dùng Snowball

Bảng tham khảo nhanh: | Dung lượng | 1 Gbps | 10 Gbps | Snowball | |---|---|---|---| | 10 TB | ~1 ngày | ~2,5 giờ | ~1 tuần (vận chuyển) | | 100 TB | ~9 ngày | ~1 ngày | ~1–2 tuần | | 1 PB | ~93 ngày | ~9 ngày | ~2 tuần | | 5 PB | ~463 ngày | ~46 ngày | ~3–4 tuần |

Ba đích của Snowball import: | Đích | Hỗ trợ | |---|---| | Amazon S3 | ✅ DUY NHẤT | | S3 Glacier trực tiếp | ❌ | | EFS, EBS trực tiếp | ❌ |

Muốn vào Glacier hay EFS thì phải qua S3 rồi chuyển tiếp.

Các lớp lưu trữ lạnh — bảng nhắc lại: | Lớp | Giá tham khảo | Thời gian lấy | |---|---|---| | Glacier Instant Retrieval | ~0,004 USD/GB | mili giây | | Glacier Flexible Retrieval | ~0,0036 USD/GB | 1 phút – 12 giờ | | Glacier Deep Archive | ~0,00099 USD/GB | 12–48 giờ |

Với lưu trữ dài hạn không cần truy cập, Deep Archive là lựa chọn đúng.

Ba ràng buộc của lifecycle sang Glacier: | Ràng buộc | Chi tiết | |---|---| | Thời gian lưu tối thiểu tính phí | Glacier 90 ngày, Deep Archive 180 ngày | | Object nhỏ hơn 128 KB không tự chuyển | | | Có phí request cho việc chuyển lớp | ~0,05 USD mỗi 1.000 object |

Dòng cuối đáng tính với dữ liệu lớn:

5 PB gồm 50 triệu tệp:
    Phí chuyển lớp: 50.000 × 0,05 = 2.500 USD một lần
        ↓
    Vẫn rất đáng so với khoản tiết kiệm hằng tháng,
    nhưng nên biết trước

Ba đặc điểm của Snowball Edge: | Đặc điểm | Chi tiết | |---|---| | Mã hoá 256-bit, khoá do KMS quản lý | | | Vỏ chống va đập, có e-ink hiển thị địa chỉ gửi | | | Chạy được EC2 và Lambda tại chỗ | Compute Optimized |

Ba bước của quy trình Snowball: | Bước | Chi tiết | |---|---| | ① Tạo job trong console | AWS gửi thiết bị | | ② Chép dữ liệu bằng Snowball Client hoặc S3 adapter | | | ③ Gửi trả, AWS nhập vào S3 | theo dõi tiến độ trong console |

Ba lưu ý khi chép dữ liệu: | Lưu ý | Chi tiết | |---|---| | Dùng nhiều luồng song song | tối đa hoá tốc độ | | Tệp nhỏ chép chậm hơn nhiều | gộp thành archive nếu được | | Kiểm tra checksum | Snowball tự làm |

Ba lựa chọn chuyển dữ liệu lên AWS: | Lựa chọn | Quy mô | |---|---| | Tải trực tiếp (multipart) | tới vài TB | | DataSync | TB tới PB, qua mạng | | Snowball | hàng chục TB tới PB ← câu này |

Ba lưu ý về chi phí Snowball: | Khoản | Chi tiết | |---|---| | Phí thuê mỗi thiết bị | theo job | | Phí ngày thêm nếu giữ lâu | | | Nhập dữ liệu VÀO AWS miễn phí | chỉ trả phí thiết bị và vận chuyển |

Ba việc nên làm trước khi đặt Snowball: | Việc | Chi tiết | |---|---| | Đo chính xác dung lượng và số tệp | quyết định số thiết bị | | Chuẩn bị máy chủ có băng thông cao tới thiết bị | 10 GbE | | Lập kế hoạch song song nhiều thiết bị | |

Và một lời khuyên: hãy đặt lifecycle chuyển sang Deep Archive với Days: 1 ngay khi tạo bucket, trước cả khi Snowball về. Dữ liệu vừa nhập sẽ tự xuống tầng rẻ nhất sau một ngày — còn nếu để 5 PB nằm ở S3 Standard vài tháng vì quên đặt quy tắc, khoản chênh lệch đủ trả cho toàn bộ dự án di chuyển.

Câu 687 Chọn nhiều đáp án Design High-Performing Architectures

Reporters at a news agency upload/download video files (about 500 megabytes each) to/from an Amazon S3 bucket as part of their daily work. As the agency has started offices in remote locations, it has resulted in poor latency for uploading and accessing data to/from the given Amazon S3 bucket. The agency wants to continue using a serverless storage solution such as Amazon S3 but wants to improve the performance.

As a solutions architect, which of the following solutions do you propose to address this issue? (Select two)

A
Enable Amazon S3 Transfer Acceleration (Amazon S3TA) for the Amazon S3 bucket. This would speed up uploads as well as downloads for the video files
B
Spin up Amazon EC2 instances in each region where the agency has a remote office. Create a daily job to transfer Amazon S3 data into Amazon EBS volumes attached to the Amazon EC2 instances
C
Use Amazon CloudFront distribution with origin as the Amazon S3 bucket. This would speed up uploads as well as downloads for the video files
D
Create new Amazon S3 buckets in every region where the agency has a remote office, so that each office can maintain its storage for the media assets
E
Move Amazon S3 data into Amazon Elastic File System (Amazon EFS) created in a US region, connect to Amazon EFS file system from Amazon EC2 instances in other AWS regions using an inter-region VPC peering connection

Xem giải thích

Đáp án

A và C.

A — Bật S3 Transfer Acceleration cho bucket — tăng tốc CẢ tải lên lẫn tải xuống
C — Dùng CloudFront với origin là bucket S3 — tăng tốc CẢ tải lên lẫn tải xuống

Vì sao đúng

Đề nêu vấn đề rõ: văn phòng ở xa, độ trễ cao khi tải lên và tải xuống tệp 500 MB, và muốn giữ S3.

A — S3 Transfer Acceleration:

Client → edge location GẦN NHẤT
    → mạng riêng, tối ưu của AWS
    → bucket S3
        ↓
    Thay vì đi Internet công cộng suốt chặng đường

aws s3api put-bucket-accelerate-configuration   --bucket kho-video --accelerate-configuration Status=Enabled

aws s3 cp video.mp4 s3://kho-video/   --endpoint-url https://s3-accelerate.amazonaws.com

C — CloudFront cũng tăng tốc CẢ HAI CHIỀU:

Tải xuống: đệm ở edge, lần sau phục vụ ngay tại chỗ
Tải LÊN:   qua edge → mạng riêng AWS → origin
        ↓
    CloudFront hỗ trợ PUT/POST khi bật phương thức tương ứng

Vế "tải lên" của CloudFront là điều nhiều người không biết:

CloudFront không chỉ để phân phối nội dung
    → nó cũng tăng tốc UPLOAD nhờ mạng riêng của AWS
        ↓
    Bật allowed methods gồm PUT, POST
    → dùng OAC để CloudFront ghi được vào S3

Và cả hai đều dựa trên cùng một nguyên lý:

Rút ngắn quãng đường đi trên Internet CÔNG CỘNG
    → chuyển sang MẠNG RIÊNG của AWS sớm nhất có thể
        ↓
    Mạng riêng có độ trễ thấp hơn, ít mất gói hơn,
      và băng thông ổn định hơn

Với tệp 500 MB, nên kết hợp thêm multipart upload:

aws configure set default.s3.multipart_chunksize 25MB
aws configure set default.s3.max_concurrent_requests 20

Tải song song nhiều phần trên đường đã được tăng tốc.

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

**D. Tạo bucket S3 riêng ở mỗi Region có văn phòng — đây là phương án gần nhất vì đặt dữ liệu gần người dùng thật sự giảm độ trễ, nhưng nó phá vỡ kho lưu trữ thống nhất: mỗi văn phòng có kho riêng, phóng viên ở Hà Nội không thấy tệp của đồng nghiệp ở Tokyo. (Nếu bổ sung Cross-Region Replication thì giải quyết được, nhưng phương án không nêu điều đó.)
**B. Dựng EC2 ở mỗi Region, chép dữ liệu S3 vào EBS hằng ngày — không còn là serverless và có độ trễ một ngày: đề nói rõ muốn tiếp tục dùng giải pháp lưu trữ serverless.
**E. Chuyển sang EFS ở một Region, truy cập từ EC2 các Region khác qua VPC peering — NFS xuyên Region là thiết kế rất tệ: mỗi thao tác tệp là một vòng lượt mạng, và với khoảng cách liên lục địa thì hiệu năng còn tệ hơn hiện tại.

Ghi nhớ

Ba cách tăng tốc truyền dữ liệu với S3 — bảng phải thuộc: | Cách | Chiều | Cơ chế | |---|---|---| | S3 Transfer Acceleration | lên và xuống | qua edge, mạng riêng AWS | | CloudFront | lên và xuống | đệm khi xuống, mạng riêng khi lên | | Multipart upload | lên | chia phần, tải song song |

Transfer Acceleration và CloudFront — khi nào cái nào: | Tình huống | Chọn | |---|---| | Chủ yếu TẢI LÊN tệp lớn | Transfer Acceleration | | Nhiều người TẢI XUỐNG cùng tệp | CloudFront (đệm) | | Cần cả hai | dùng cả hai |

Với hãng tin, nhiều phóng viên tải cùng một video → CloudFront đệm rất hiệu quả.

Ba đặc điểm của S3 Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Dùng endpoint riêng | <bucket>.s3-accelerate.amazonaws.com | | Có phí thêm ~0,04 USD/GB | | | Tên bucket KHÔNG được chứa dấu chấm | yêu cầu kỹ thuật |

Và AWS có công cụ đo trước khi quyết định:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
  en/accelerate-speed-comparsion.html

So tốc độ có và không có Transfer Acceleration
  từ chính vị trí của bạn
    → không nhanh hơn thì KHÔNG nên trả phí

Ba lưu ý khi dùng CloudFront cho tải lên: | Lưu ý | Chi tiết | |---|---| | Bật PUT, POST trong allowed methods | mặc định chỉ GET, HEAD | | Dùng OAC với SigningBehavior: always | | | Đặt cache policy CachingDisabled cho đường dẫn tải lên | |

Ba lưu ý về multipart upload với tệp 500 MB: | Lưu ý | Chi tiết | |---|---| | AWS CLI tự dùng multipart trên 8 MB | | | Tăng max_concurrent_requests | mặc định 10 | | Thêm lifecycle dọn phần dở dang | |

{"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}

Ba cách khác giảm độ trễ cho văn phòng xa: | Cách | Đặc điểm | |---|---| | S3 Cross-Region Replication | bản sao ở Region gần | | S3 Multi-Region Access Point | một endpoint, tự định tuyến tới bucket gần nhất | | Storage Gateway tại văn phòng | cache cục bộ |

Multi-Region Access Point đáng biết:

Một tên miền toàn cầu
    → tự định tuyến tới bucket có độ trễ thấp nhất
    → hỗ trợ cả đọc và ghi (với failover)
        ↓
    Kết hợp lợi ích của D mà không mất tính thống nhất

Ba yếu tố ảnh hưởng tốc độ tải lên S3: | Yếu tố | Ảnh hưởng | |---|---| | Khoảng cách địa lý | ← vấn đề trong đề | | Số kết nối song song | multipart | | Chất lượng đường Internet | mất gói làm TCP giảm tốc |

Dòng cuối là lý do mạng riêng của AWS hiệu quả:

TCP giảm cửa sổ khi mất gói
    → đường Internet công cộng mất gói nhiều hơn
    → thông lượng thực tế thấp hơn nhiều so với băng thông danh nghĩa
        ↓
    Mạng riêng của AWS ít mất gói → TCP giữ được tốc độ cao

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tải LÊN S3 miễn phí | chỉ phí request | | Transfer Acceleration | ~0,04 USD/GB thêm | | CloudFront egress | RẺ HƠN egress trực tiếp từ S3 |

Dòng cuối là lợi ích phụ đáng kể:

CloudFront không chỉ nhanh hơn
    → mà còn RẺ HƠN cho việc tải xuống nhiều
        ↓
    Với tệp video 500 MB tải nhiều lần, tiết kiệm đáng kể

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Thời gian tải lên trung bình | đo trước và sau | | CacheHitRate của CloudFront | hiệu quả đệm | | Tỷ lệ tải lên thất bại | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Presigned URL cho tải lên trực tiếp | không lộ credential | | CloudFront signed URL cho tải xuống | kiểm soát ai xem được | | Bucket giữ Block Public Access | |

Và một lời khuyên: hãy chạy công cụ so tốc độ của AWS từ chính các văn phòng xa trước khi bật Transfer Acceleration. Mức cải thiện phụ thuộc hoàn toàn vào chất lượng đường mạng ở đó — có nơi nhanh gấp đôi, có nơi gần như không đổi, và phí 0,04 USD mỗi GB chỉ đáng chi ở nhóm đầu.

Câu 688 Design High-Performing Architectures

A company needs a massive PostgreSQL database and the engineering team would like to retain control over managing the patches, version upgrades for the database, and consistent performance with high IOPS. The team wants to install the database on an Amazon EC2 instance with the optimal storage type on the attached Amazon EBS volume.

As a solutions architect, which of the following configurations would you suggest to the engineering team?

A
Amazon EC2 with Amazon EBS volume of General Purpose SSD (gp2) type
B
Amazon EC2 with Amazon EBS volume of cold HDD (sc1) type
C
Amazon EC2 with Amazon EBS volume of Throughput Optimized HDD (st1) type
D
Amazon EC2 with Amazon EBS volume of Provisioned IOPS SSD (io1) type

Xem giải thích

Đáp án

D — EC2 với EBS volume loại Provisioned IOPS SSD (io1).

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba dẫn tới io1: | Yêu cầu | Kết luận | |---|---| | Database PostgreSQL RẤT LỚN | tải I/O nặng | | IOPS CAO và NHẤT QUÁN | Provisioned IOPS đảm bảo mức cam kết | | Tự quản lý bản vá và phiên bản | → chạy trên EC2, không dùng RDS |

Từ khoá quyết định là "consistent performance with high IOPS":

Provisioned IOPS SSD:
    → bạn KHAI số IOPS cần
    → AWS ĐẢM BẢO mức đó, 99,9% thời gian
        ↓
    Không có cơ chế credit, không có tụt tốc bất ngờ

Và gp2 không đảm bảo được:

gp2:
    → baseline 3 IOPS mỗi GB
    → bùng phát tới 3.000 IOPS bằng CREDIT
        ↓
    HẾT CREDIT → tụt về baseline
    → hiệu năng KHÔNG NHẤT QUÁN

Với database, tụt tốc bất ngờ là vấn đề nghiêm trọng:

Database đang phục vụ bình thường
    → burst credit cạn giữa giờ cao điểm
    → IOPS tụt đột ngột
    → truy vấn xếp hàng, ứng dụng timeout
        ↓
    Và không có cảnh báo nào ngoài metric BurstBalance

Tạo volume io1:

aws ec2 create-volume --availability-zone ap-northeast-1a   --size 1000 --volume-type io1 --iops 20000 --encrypted

Và io1 có tỷ lệ IOPS trên dung lượng cao:

io1: tối đa 50 IOPS mỗi GB
    → volume 1.000 GB → tới 50.000 IOPS
    → trần tuyệt đối 64.000 IOPS (với instance Nitro)

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

**A. General Purpose SSD (gp2) — đây là phương án gần nhất và là lựa chọn tốt cho hầu hết tải, nhưng nó không cho hiệu năng NHẤT QUÁN: cơ chế burst credit nghĩa là IOPS có thể tụt khi credit cạn. Đề nêu rõ "consistent performance with high IOPS".
**C. Throughput Optimized HDD (st1) — sai loại tải: st1 là HDD tối ưu cho thông lượng tuần tự (log, big data), IOPS rất thấp. Database làm việc với I/O ngẫu nhiên.
**B. Cold HDD (sc1) — loại chậm nhất: dành cho dữ liệu hiếm truy cập, hoàn toàn không phù hợp với database.

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

Đáp án là io1, nhưng ngày nay io2 và io2 Block Express là lựa chọn đúng hơn.

	io1	io2	io2 Block Express
Độ bền	99,8–99,9%	99,999%	99,999%
IOPS tối đa	64.000	64.000	256.000
Thông lượng tối đa	1.000 MB/giây	1.000 MB/giây	4.000 MB/giây
IOPS mỗi GB	50	500	1.000
Giá	—	BẰNG io1	cao hơn

io2 có độ bền cao hơn io1 GẤP 100 LẦN
    → mà giá NGANG NHAU
        ↓
    Không có lý do nào chọn io1 cho thiết kế mới
    → AWS khuyến nghị io2 thay thế hoàn toàn

Và gp3 cũng đáng cân nhắc:

gp3:
    ✓ 3.000 IOPS baseline MIỄN PHÍ, KHÔNG có credit
    ✓ tăng tới 16.000 IOPS độc lập với dung lượng
    ✓ rẻ hơn gp2 ~20%
        ↓
    Nếu database cần dưới 16.000 IOPS,
    gp3 rẻ hơn nhiều so với io1/io2
        ↓
    Và gp3 CŨNG nhất quán — nó bỏ hẳn cơ chế credit

Nghĩa là lập luận "gp2 không nhất quán" của câu hỏi đúng với gp2, nhưng KHÔNG còn đúng với gp3.

Ghi nhớ

Các loại EBS volume — bảng phải thuộc: | Loại | IOPS tối đa | Thông lượng | Phù hợp | |---|---|---|---| | gp3 | 16.000 | 1.000 MB/giây | mặc định khuyến nghị | | gp2 | 16.000 | 250 MB/giây | thế hệ trước | | io1 | 64.000 | 1.000 MB/giây | thế hệ trước | | io2 | 64.000 | 1.000 MB/giây | IOPS cao, độ bền 99,999% | | io2 Block Express | 256.000 | 4.000 MB/giây | database lớn nhất | | st1 | 500 | 500 MB/giây | log, big data tuần tự | | sc1 | 250 | 250 MB/giây | lưu trữ lạnh |

Từ khoá nhận diện:

"consistent high IOPS", "critical database", "sub-millisecond" → io2 "general purpose", "cost-effective" → gp3 "sequential throughput", "big data", "log processing" → st1 "lowest cost, rarely accessed" → sc1

IOPS và thông lượng — phân biệt quan trọng: | | IOPS | Thông lượng | |---|---|---| | Đo gì | số thao tác mỗi giây | MB mỗi giây | | Quan trọng cho | database (I/O ngẫu nhiên nhỏ) | big data (đọc tuần tự lớn) | | Loại volume | SSD | HDD hoặc SSD |

Ba lựa chọn chạy PostgreSQL trên AWS: | Lựa chọn | Kiểm soát | Công vận hành | |---|---|---| | PostgreSQL trên EC2 | toàn quyền | cao nhất ← câu này | | RDS for PostgreSQL | hạn chế | thấp | | Aurora PostgreSQL | hạn chế | thấp, hiệu năng cao nhất |

Đề nói rõ đội kỹ thuật muốn tự quản lý bản vá và nâng cấp — đó là lý do chọn EC2.

Ba yếu tố tối ưu hiệu năng database trên EC2: | Yếu tố | Chi tiết | |---|---| | EBS-optimized instance | băng thông riêng cho EBS | | Loại instance có băng thông EBS cao | r5b, r6i, m6i | | Nhiều volume trong RAID 0 | cộng dồn IOPS |

Băng thông EBS của instance là trần thật sự:

Volume io2 cấp 60.000 IOPS
    → nhưng instance chỉ có băng thông EBS cho 20.000 IOPS
        ↓
    Trả tiền cho 60.000 mà chỉ dùng được 20.000
        ↓
    Phải chọn loại instance TƯƠNG XỨNG với volume

Ba metric để đánh giá volume: | Metric | Ý nghĩa | |---|---| | VolumeReadOps + VolumeWriteOps | IOPS thực tế | | VolumeQueueLength | cao liên tục = thiếu IOPS | | BurstBalance | chỉ gp2 — về 0 là tụt tốc |

VolumeQueueLength là chỉ báo tốt nhất:

Queue length > 1 cho mỗi 1.000 IOPS đã cấp
    → volume không theo kịp
    → cần tăng IOPS hoặc đổi loại

Ba tính năng riêng của io1/io2: | Tính năng | Chi tiết | |---|---| | Multi-Attach | gắn một volume vào tới 16 instance | | Đảm bảo IOPS 99,9% thời gian | | | io2 có độ bền 99,999% | |

Multi-Attach cần hệ thống tệp cluster-aware — không dùng được với ext4 hay xfs thông thường.

Ba lưu ý về sao lưu database trên EC2: | Lưu ý | Chi tiết | |---|---| | Snapshot EBS KHÔNG đảm bảo nhất quán | trừ khi dừng ghi hoặc dùng lệnh của database | | Dùng pg_basebackup hoặc WAL archiving | | | AWS Backup có hỗ trợ ứng dụng nhất quán | với VSS trên Windows |

Dòng đầu là bẫy nghiêm trọng:

Chụp snapshot EBS khi PostgreSQL đang ghi
    → snapshot có thể ở trạng thái không nhất quán
    → khôi phục ra database hỏng
        ↓
    Phải dùng cơ chế sao lưu của chính database

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | io1/io2 tính phí IOPS RIÊNG | ~0,065 USD mỗi IOPS-tháng | | 60.000 IOPS ≈ 3.900 USD/tháng | chỉ riêng phần IOPS | | gp3 gồm 3.000 IOPS miễn phí | rẻ hơn nhiều nếu đủ dùng |

Và một lời khuyên: hãy đo IOPS thực tế của database trong một tuần trước khi chọn loại volume. Rất nhiều hệ thống được cấp io1 với hàng chục nghìn IOPS trong khi mức dùng đỉnh chỉ vài nghìn — và ở mức đó, gp3 cho hiệu năng nhất quán tương đương với chi phí thấp hơn nhiều lần.

Câu 689 Design Cost-Optimized Architectures

The data engineering team at an e-commerce company has set up a workflow to ingest the clickstream data into the raw zone of the Amazon S3 data lake. The team wants to run some SQL based data sanity checks on the raw zone of the data lake.

What AWS services would you recommend for this use-case such that the solution is cost-effective and easy to maintain?

A
Use Amazon Athena to run SQL based analytics against Amazon S3 data
B
Load the incremental raw zone data into Amazon Redshift on an hourly basis and run the SQL based sanity checks
C
Load the incremental raw zone data into Amazon RDS on an hourly basis and run the SQL based sanity checks
D
Load the incremental raw zone data into an Amazon EMR based Spark Cluster on an hourly basis and use SparkSQL to run the SQL based sanity checks

Xem giải thích

Đáp án

A — Dùng Amazon Athena chạy phân tích SQL trực tiếp trên dữ liệu S3.

Vì sao đúng

Đề nêu ba yêu cầu, và Athena đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Kiểm tra dữ liệu bằng SQL trên vùng thô của data lake | Athena truy vấn thẳng tệp trên S3 | | Tiết kiệm chi phí | trả theo lượng dữ liệu QUÉT, không có hạ tầng chạy không | | Dễ bảo trì | serverless — không cụm nào để quản lý |

Điểm mấu chốt: không phải nạp dữ liệu đi đâu cả.

Ba phương án kia đều NẠP dữ liệu vào một hệ thống khác:
    → thêm bước ETL phải viết và bảo trì
    → thêm chi phí lưu trữ trùng lặp
    → thêm độ trễ (theo giờ)
        ↓
Athena:
    → đọc THẲNG tệp gốc trên S3
    → không sao chép gì

Và mô hình chi phí phù hợp với việc kiểm tra dữ liệu:

Kiểm tra chất lượng dữ liệu = truy vấn KHÔNG THƯỜNG XUYÊN
        ↓
    Athena: chỉ trả tiền khi chạy truy vấn
    Redshift/EMR: trả tiền cho cụm 24/7 dù không dùng

Tạo bảng trỏ vào vùng thô:

CREATE EXTERNAL TABLE clickstream_tho (
  ma_phien string, ma_nguoi_dung string, url string,
  thoi_diem timestamp, thiet_bi string)
PARTITIONED BY (nam int, thang int, ngay int)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://data-lake/vung-tho/clickstream/';

Và chạy kiểm tra:

-- Đếm bản ghi thiếu trường bắt buộc
SELECT COUNT(*) FROM clickstream_tho
WHERE nam=2026 AND thang=8 AND (ma_phien IS NULL OR url IS NULL);

-- Kiểm tra giá trị ngoài khoảng hợp lệ
SELECT thiet_bi, COUNT(*) FROM clickstream_tho
WHERE nam=2026 AND thang=8
GROUP BY thiet_bi ORDER BY 2 DESC;

Nạp phân vùng mới:

MSCK REPAIR TABLE clickstream_tho;

Hoặc dùng partition projection để khỏi phải chạy lệnh này.

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

**B. Nạp dữ liệu vùng thô vào Redshift theo giờ rồi chạy kiểm tra — đây là phương án gần nhất và Redshift thực sự chạy SQL rất tốt, nhưng nó thêm cụm phải trả tiền 24/7 và một bước ETL phải bảo trì. Với việc kiểm tra dữ liệu không thường xuyên, đó là chi phí không tương xứng.
**C. Nạp vào Amazon RDS theo giờ — sai loại database: RDS là database giao dịch, không tối ưu cho quét phân tích trên khối lượng lớn dữ liệu clickstream. Và cũng có cùng vấn đề ETL và cụm chạy liên tục.
**D. Nạp vào cụm EMR Spark theo giờ dùng SparkSQL — công vận hành cao nhất: phải quản lý cụm, cấu hình Spark, xử lý lỗi job. Quá nặng cho việc kiểm tra dữ liệu đơn giản.

Ghi nhớ

Ba công cụ truy vấn dữ liệu trên S3 — bảng phải thuộc: | Công cụ | Đặc điểm | |---|---| | Athena | serverless, SQL đặc biệt, trả theo dữ liệu quét | | Redshift Spectrum | cần cụm Redshift, mạnh hơn cho join phức tạp | | EMR (Spark, Presto) | biến đổi phức tạp, quy mô lớn, cần quản cụm |

Từ khoá nhận diện:

"ad-hoc SQL on S3", "serverless", "cost-effective", "easy to maintain" → Athena "data warehouse", "complex joins", "BI dashboards" → Redshift "custom Spark jobs", "machine learning pipeline" → EMR

Ba cách giảm chi phí Athena — rất đáng nhớ: | Cách | Tiết kiệm | |---|---| | Định dạng cột (Parquet, ORC) | tới 90% | | Phân vùng theo cột hay lọc | rất nhiều | | Nén (Snappy, GZIP) | |

Phép so sánh cụ thể:

Quét 1 TB CSV:                   ~5,00 USD
Quét cùng dữ liệu ở Parquet nén: ~0,50 USD hoặc thấp hơn
    → chỉ đọc cột cần dùng
    → và dữ liệu nhỏ hơn nhiều

Phân vùng còn quan trọng hơn:

-- Không phân vùng: quét TOÀN BỘ dữ liệu
SELECT COUNT(*) FROM clickstream_tho WHERE ngay = 15;

-- Có phân vùng: chỉ quét thư mục của ngày đó
SELECT COUNT(*) FROM clickstream_tho
WHERE nam=2026 AND thang=8 AND ngay=15;

Chênh lệch có thể là hàng trăm lần.

Ba khái niệm đi kèm Athena: | Khái niệm | Việc | |---|---| | AWS Glue Data Catalog | lưu định nghĩa bảng và schema | | Glue Crawler | tự phát hiện schema từ dữ liệu | | Workgroup | giới hạn chi phí và tách biệt nhóm người dùng |

Workgroup rất hữu ích để kiểm soát chi phí:

aws athena create-work-group --name kiem-tra-du-lieu   --configuration '{"BytesScannedCutoffPerQuery": 10737418240,
                    "EnforceWorkGroupConfiguration": true,
                    "ResultConfiguration": {"OutputLocation":"s3://ket-qua/"}}'

Giới hạn 10 GB mỗi truy vấn
    → truy vấn quét quá nhiều bị HUỶ
        ↓
    Ngăn một câu SELECT * vô ý tốn hàng trăm USD

Ba lưu ý về partition projection: | Lưu ý | Chi tiết | |---|---| | Không cần chạy MSCK REPAIR | Athena tự suy ra phân vùng | | Nhanh hơn với hàng nghìn phân vùng | | | Khai trong thuộc tính bảng | |

TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.nam.type' = 'integer',
  'projection.nam.range' = '2024,2030',
  'projection.thang.type' = 'integer',
  'projection.thang.range' = '1,12')

Ba tầng của data lake: | Tầng | Nội dung | |---|---| | Raw (thô) | dữ liệu nguyên bản, chưa biến đổi ← câu này | | Cleansed / Curated | đã làm sạch, chuẩn hoá | | Consumption | tổng hợp sẵn cho báo cáo |

Kiểm tra chất lượng ở tầng thô là đúng vị trí — phát hiện vấn đề trước khi nó lan xuống các tầng sau.

Ba loại kiểm tra chất lượng dữ liệu phổ biến: | Kiểm tra | Ví dụ SQL | |---|---| | Tính đầy đủ | COUNT(*) WHERE cot IS NULL | | Tính duy nhất | COUNT(*) - COUNT(DISTINCT ma) | | Khoảng hợp lệ | WHERE gia < 0 OR gia > 1000000 |

Và AWS có dịch vụ chuyên cho việc này:

AWS Glue Data Quality:
    → định nghĩa quy tắc bằng DQDL
    → chạy tự động và báo cáo
    → tích hợp với Glue job và Data Catalog
        ↓
    Đáng cân nhắc khi số quy tắc kiểm tra tăng lên

Ba lưu ý về hiệu năng Athena: | Lưu ý | Chi tiết | |---|---| | Tệp quá nhỏ làm chậm | gộp thành tệp 128 MB – 1 GB | | Tránh SELECT * | chỉ chọn cột cần | | Dùng LIMIT khi thăm dò | |

Vấn đề tệp nhỏ đáng lưu ý với clickstream:

Dữ liệu luồng ghi thành hàng nghìn tệp nhỏ mỗi giờ
    → Athena phải mở từng tệp
    → chi phí xử lý vượt xa việc đọc dữ liệu
        ↓
    Chạy job gộp tệp định kỳ (compaction)

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Athena | ~5 USD mỗi TB quét | | Lưu trữ S3 | theo lớp | | Glue Data Catalog | miễn phí tới 1 triệu object |

Và một lời khuyên: hãy đặt BytesScannedCutoffPerQuery cho workgroup ngay từ đầu. Một truy vấn SELECT * không có điều kiện phân vùng trên data lake clickstream có thể quét hàng chục terabyte trong một lần chạy — và với Athena bạn chỉ phát hiện điều đó khi hoá đơn về, chứ không phải khi truy vấn đang chạy.

Câu 690 Design High-Performing Architectures

A media company is evaluating the possibility of moving its IT infrastructure to the AWS Cloud. The company needs at least 10 terabytes of storage with the maximum possible I/O performance for processing certain files which are mostly large videos. The company also needs close to 450 terabytes of very durable storage for storing media content and almost double of it, i.e. 900 terabytes for archival of legacy data.

As a Solutions Architect, which set of services will you recommend to meet these requirements?

A
Amazon EC2 instance store for maximum performance, AWS Storage Gateway for on-premises durable data access and Amazon S3 Glacier Deep Archive for archival storage
B
Amazon EBS for maximum performance, Amazon S3 for durable data storage, and Amazon S3 Glacier for archival storage
C
Amazon EC2 instance store for maximum performance, Amazon S3 for durable data storage, and Amazon S3 Glacier for archival storage
D
Amazon S3 standard storage for maximum performance, Amazon S3 Intelligent-Tiering for intelligent, durable storage, and Amazon S3 Glacier Deep Archive for archival storage

Xem giải thích

Đáp án

C — EC2 instance store cho hiệu năng tối đa, Amazon S3 cho lưu trữ bền vững, S3 Glacier cho lưu trữ dài hạn.

Vì sao đúng

Đề nêu ba nhu cầu riêng biệt với ba đặc tính khác nhau: | Nhu cầu | Dung lượng | Yêu cầu | Dịch vụ | |---|---|---|---| | Xử lý tệp video lớn | 10 TB | hiệu năng I/O TỐI ĐA | Instance store | | Lưu nội dung media | 450 TB | rất bền vững | S3 | | Lưu trữ dữ liệu cũ | 900 TB | lưu trữ dài hạn | S3 Glacier |

① Instance store cho hiệu năng tối đa:

Instance store = NVMe SSD gắn TRỰC TIẾP vào máy chủ vật lý
    → không đi qua mạng như EBS
        ↓
    Hàng triệu IOPS, độ trễ micro giây
    → NHANH NHẤT trong mọi lựa chọn lưu trữ của AWS

Và dữ liệu tạm khi xử lý video hoàn toàn phù hợp:

Instance store MẤT dữ liệu khi stop hoặc hỏng phần cứng
    → nhưng đây chỉ là không gian làm việc tạm
    → nguồn gốc vẫn nằm ở S3
        ↓
    Rủi ro chấp nhận được, đổi lại hiệu năng cao nhất

② S3 cho 450 TB nội dung media:

S3:
    ✓ độ bền 99,999999999% (11 số 9)
    ✓ dung lượng không giới hạn
    ✓ rẻ hơn nhiều so với EBS hay EFS

③ Glacier cho 900 TB lưu trữ:

Dữ liệu cũ (legacy) — hiếm khi truy cập
    → Glacier hoặc Deep Archive
        ↓
    900 TB ở Deep Archive: ~890 USD/tháng
    900 TB ở S3 Standard:  ~20.700 USD/tháng

Kiến trúc hoàn chỉnh:

Video gốc ở S3
    ↓ tải xuống instance store
EC2 (i4i, i3en) xử lý ở tốc độ tối đa
    ↓ kết quả đẩy lên
S3 (media hiện hành)
    ↓ lifecycle sau N ngày
S3 Glacier / Deep Archive (lưu trữ)

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

**B. EBS cho hiệu năng tối đa, S3 cho bền vững, Glacier cho lưu trữ — đây là phương án gần nhất và đúng hoàn toàn ở hai vế sau, nhưng nó sai ở vế "maximum possible I/O performance": EBS đi qua mạng nên luôn chậm hơn instance store. Đề nói "maximum POSSIBLE", và câu trả lời đó là instance store.
**A. Instance store, Storage Gateway cho truy cập bền vững tại chỗ, Deep Archive cho lưu trữ — Storage Gateway không phải kho lưu trữ: nó là cầu nối cho ứng dụng tại chỗ, mà đề nói công ty muốn thoát khỏi hạ tầng tại chỗ.
**D. S3 Standard cho hiệu năng tối đa — S3 không phải lưu trữ hiệu năng cao cho xử lý tệp: nó là object storage với độ trễ hàng chục mili giây, không so được với NVMe cục bộ.

Ghi nhớ

Hiệu năng lưu trữ trên AWS — thứ tự từ nhanh nhất: | Lưu trữ | Độ trễ | Bền vững | |---|---|---| | Instance store (NVMe) | micro giây | ❌ MẤT khi stop | | EBS io2 Block Express | dưới mili giây | ✅ 99,999% | | EBS gp3 | mili giây một chữ số | ✅ | | EFS | mili giây | ✅ | | S3 | hàng chục mili giây | ✅ 11 số 9 | | Glacier | phút tới giờ | ✅ |

Từ khoá nhận diện:

"maximum I/O performance", "temporary", "scratch space" → instance store "persistent block storage", "database" → EBS "shared file system" → EFS "durable object storage" → S3

Ba đặc điểm của instance store: | Đặc điểm | Chi tiết | |---|---| | Hiệu năng cao nhất | gắn trực tiếp vào máy chủ | | MẤT dữ liệu khi stop, hibernate, hỏng phần cứng | giữ được khi REBOOT | | Dung lượng và số lượng cố định theo loại instance | |

Dòng giữa có chi tiết cần chính xác:

Reboot:              dữ liệu instance store CÒN
Stop / Terminate:    MẤT
Hỏng phần cứng:      MẤT
        ↓
    Nhiều người tưởng reboot cũng mất — không phải

Ba họ instance có instance store lớn: | Họ | Đặc điểm | |---|---| | i4i, i3en | tối ưu lưu trữ, NVMe dung lượng lớn | | d3, d3en | HDD dung lượng rất lớn | | m5d, c5d, r5d | biến thể có NVMe của họ thông thường |

Ba trường hợp dùng instance store: | Trường hợp | Lý do | |---|---| | Không gian làm việc tạm | ← câu này | | Bộ đệm | dữ liệu tái tạo được | | Bản sao của cụm phân tán | Cassandra, Elasticsearch |

Nguyên tắc: chỉ để dữ liệu TÁI TẠO ĐƯỢC trên instance store.

Các lớp lưu trữ S3 — bảng nhắc lại: | Lớp | Giá tham khảo | Thời gian lấy | |---|---|---| | Standard | ~0,023 USD/GB | tức thì | | Intelligent-Tiering | ~0,023 + giám sát | tức thì | | Standard-IA | ~0,0125 USD/GB | tức thì | | Glacier Instant | ~0,004 USD/GB | mili giây | | Glacier Flexible | ~0,0036 USD/GB | 1 phút – 12 giờ | | Deep Archive | ~0,00099 USD/GB | 12–48 giờ |

Phép tính cho 900 TB lưu trữ:

S3 Standard:      900.000 GB × 0,023  ≈ 20.700 USD/tháng
Glacier Flexible: 900.000 GB × 0,0036 ≈  3.240 USD/tháng
Deep Archive:     900.000 GB × 0,00099 ≈   891 USD/tháng
        ↓
    Chênh lệch hơn 23 lần giữa Standard và Deep Archive

Ba lưu ý khi xử lý video quy mô lớn: | Lưu ý | Chi tiết | |---|---| | Kiểm tra băng thông mạng của instance | tải video từ S3 nhanh chậm phụ thuộc đây | | Dùng multipart download song song | | | Cân nhắc AWS Elemental MediaConvert | dịch vụ chuyển mã được quản lý |

MediaConvert đáng cân nhắc:

Thay vì tự chạy EC2 chuyển mã:
    → MediaConvert trả theo phút video
    → tự co giãn, không quản hạ tầng
        ↓
    Với tải chuyển mã không đều, thường rẻ hơn

Ba lựa chọn thay thế cho không gian làm việc tốc độ cao: | Lựa chọn | Đặc điểm | |---|---| | Instance store | nhanh nhất, không bền ← câu này | | FSx for Lustre | chia sẻ nhiều máy, tích hợp S3 | | EBS io2 Block Express | bền vững, tới 256.000 IOPS |

FSx for Lustre rất hợp với xử lý media:

FSx for Lustre liên kết với bucket S3:
    → tự tải dữ liệu từ S3 khi cần (lazy loading)
    → ghi kết quả ngược lại S3
        ↓
    Nhiều máy cùng xử lý một kho video

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Thời gian lưu tối thiểu tính phí | Glacier 90 ngày, Deep Archive 180 ngày | | Object nhỏ hơn 128 KB không tự chuyển | | | Có phí request cho việc chuyển lớp | |

Ba lưu ý về sao lưu dữ liệu trên instance store: | Lưu ý | Chi tiết | |---|---| | KHÔNG có snapshot cho instance store | | | Phải tự đẩy kết quả lên S3 | | | Xử lý được trường hợp máy biến mất giữa chừng | |

Và một lời khuyên: hãy thiết kế quy trình xử lý sao cho làm lại được từ đầu. Với instance store, một lần hỏng phần cứng là mất toàn bộ công việc đang dở — và nếu job chuyển mã video ghi tiến độ vào S3 theo từng phần, việc mất một máy chỉ là làm lại vài phút thay vì vài giờ.

Trang 69 / 220 — tổng 2194 câu hỏi