Ngân hàng đề — AWS Certified Solutions Architect Professional
Tìm thấy 1221 câu.
A leading internet television network company uses AWS Cloud for analytics, recommendation engines and video transcoding. To monitor and optimize this network, the engineering team at the company has developed a solution for ingesting, augmenting, and analyzing the multiple terabytes of data its network generates daily in the form of virtual private cloud (VPC) flow logs. This would enable the company to identify performance-improvement opportunities such as identifying apps that are communicating across regions and collocating them. The VPC flow logs data is funneled into Kinesis Data Streams which further acts as the source of a delivery stream for Kinesis Firehose. The engineering team has now configured a Kinesis Agent to send the VPC flow logs data from another set of network devices to the same Firehose delivery stream. They noticed that data is not reaching Firehose as expected.
As a Solutions Architect Professional, which of the following options would you identify as the MOST plausible root cause behind this issue?
-
A
Kinesis Agent cannot write to a Kinesis Firehose for which the delivery stream source is already set as Kinesis Data Streams
-
B
Kinesis Firehose delivery stream has reached its limit and needs to be scaled manually
-
C
Kinesis Agent can only write to Kinesis Data Streams, not to Kinesis Firehose
-
D
The data sent by Kinesis Agent is lost because of a configuration error
Xem giải thích
Đáp án
**A — Kinesis Agent không ghi được vào một Firehose delivery stream mà nguồn của nó đã được đặt là Kinesis Data Streams.
Vì sao đúng
Firehose có hai kiểu nguồn, và chúng loại trừ lẫn nhau: | Kiểu nguồn | Ai gửi dữ liệu vào | |---|---| | Direct PUT | ứng dụng gọi PutRecord, Kinesis Agent, CloudWatch Logs... | | Kinesis Data Stream | CHỈ luồng KDS đã khai |
⚠ Điểm mấu chốt: chọn kiểu nguồn là quyết định MỘT LẦN, không đổi được:
Tạo delivery stream với
`DeliveryStreamType = KinesisStreamAsSource`
↓
Firehose ĐỌC từ luồng KDS đó
↓
Nó KHÔNG chấp nhận `PutRecord`
trực tiếp nữa
→ Kinesis Agent bị từ chối
Xem kiểu nguồn hiện tại:
aws firehose describe-delivery-stream \
--delivery-stream-name luong-flow-log \
--query 'DeliveryStreamDescription.DeliveryStreamType'
⚠ Và cách sửa là cho Agent ghi vào chính luồng KDS:
{
"cloudwatch.emitMetrics": true,
"kinesis.endpoint": "https://kinesis.ap-southeast-1.amazonaws.com",
"flows": [{
"filePattern": "/var/log/flow-logs/*.log",
"kinesisStream": "luong-vpc-flow-log"
}]
}
Agent ghi vào KDS
↓
Firehose vẫn đọc từ KDS
↓
Cả hai nguồn dữ liệu gộp lại
trong cùng một luồng
⚠ Và cấu hình Agent có hai khoá khác nhau: | Khoá | Đích | |---|---| | kinesisStream | Kinesis Data Streams | | deliveryStream | Firehose (chỉ khi Direct PUT) |
Dùng `deliveryStream` trỏ vào một
Firehose có nguồn là KDS
↓
Agent gọi `PutRecordBatch`
→ Firehose từ chối
↓
Đây chính là tình huống trong đề
⚠ Và vì sao phương án C sai:
C nói Kinesis Agent CHỈ ghi được
vào Kinesis Data Streams
↓
Sai — Agent ghi được vào cả
Firehose
↓
Miễn là Firehose đó dùng kiểu
nguồn Direct PUT
⚠ Và vì sao phương án B sai:
B nói Firehose chạm giới hạn và
cần mở rộng THỦ CÔNG
↓
Firehose tự co giãn hoàn toàn
↓
Không có khái niệm "scale
manually" với Firehose
↓
Nó có hạn ngạch, nhưng xin nâng
chứ không tự mở rộng
⚠ Và vì sao phương án D quá mơ hồ:
D nói "dữ liệu bị mất vì lỗi cấu
hình"
↓
Đúng theo nghĩa rộng — nhưng
không nói lỗi gì
↓
Đề hỏi "nguyên nhân gốc rễ
HỢP LÝ NHẤT"
→ A nêu đúng cơ chế
⚠ Và cần biết cách chẩn đoán khi Agent không gửi được:
tail -f /var/log/aws-kinesis-agent/aws-kinesis-agent.log
Agent ghi log rất rõ
↓
Lỗi quyền, lỗi endpoint, lỗi
tên luồng đều hiện ở đó
↓
Và chỉ số CloudWatch của Agent
cho biết đã gửi bao nhiêu
⚠ Và Agent cần quyền IAM tương ứng:
{"Effect": "Allow",
"Action": ["kinesis:PutRecords", "kinesis:PutRecord"],
"Resource": "arn:aws:kinesis:*:*:stream/luong-vpc-flow-log"}
Ba lợi ích khi hiểu đúng kiến trúc này: | Lợi ích | Chi tiết | |---|---| | Biết rõ ràng buộc kiểu nguồn | | | Chẩn đoán nhanh khi dữ liệu không tới | | | Thiết kế đúng ngay từ đầu | |
⚠ Và có một cách khác: dựng thêm một Firehose Direct PUT:
Firehose #1: nguồn là KDS
↓
Firehose #2: nguồn Direct PUT
cho Agent
↓
Cả hai ghi vào cùng bucket S3
↓
Nhược điểm: hai luồng phải quản,
hai cấu hình biến đổi
⚠ Và đưa mọi thứ về KDS trước là kiến trúc tốt hơn:
Mọi nguồn → Kinesis Data Streams
↓
KDS → Firehose → S3
KDS → Lambda → cảnh báo
KDS → Managed Flink → phân tích
↓
Một điểm vào, nhiều consumer
→ và phát lại được
⚠ Và VPC Flow Log có thể gửi thẳng vào Firehose hoặc KDS:
aws ec2 create-flow-logs \
--resource-type VPC --resource-ids vpc-abc \
--traffic-type ALL \
--log-destination-type kinesis-data-firehose \
--log-destination <arn-firehose>
Với flow log của VPC trên AWS,
không cần Agent
↓
Agent chỉ cần cho thiết bị mạng
TẠI CHỖ
→ đúng như đề mô tả
Vì sao các phương án khác sai
- **B. Firehose delivery stream đã chạm giới hạn và cần mở rộng thủ công — đây là phương án gần nhất và Firehose thật sự có hạn ngạch, nhưng nó tự co giãn hoàn toàn; không có thao tác mở rộng thủ công nào.
- **C. Kinesis Agent chỉ ghi được vào Kinesis Data Streams, không ghi được vào Firehose — Agent ghi được vào Firehose, miễn là luồng đó dùng kiểu nguồn Direct PUT.
- **D. Dữ liệu bị mất vì lỗi cấu hình — đúng theo nghĩa rất rộng nhưng không nêu được cơ chế; đề hỏi nguyên nhân gốc rễ.
Ghi nhớ
⚠ Hai kiểu nguồn của Firehose — bảng phải thuộc: | Kiểu | Ai gửi vào | Đổi được sau | |---|---|---| | Direct PUT | PutRecord, Agent, CloudWatch Logs, IoT | KHÔNG | | KinesisStreamAsSource | chỉ luồng KDS đã khai | KHÔNG |
Từ khoá nhận diện:
"agent cannot write to Firehose with KDS source" → hai kiểu nguồn loại trừ nhau "Firehose needs manual scaling" → luôn SAI "multiple consumers of same stream" → KDS, không phải Firehose "replay data" → KDS
Ba lưu ý về Kinesis Agent: | Lưu ý | Chi tiết | |---|---| | Chạy trên máy chủ Linux, theo dõi tệp log | | | Ghi được vào cả KDS và Firehose | | | Có tiền xử lý: chuyển sang JSON, tách trường | |
⚠ Agent có sẵn bộ chuyển đổi log phổ biến:
"dataProcessingOptions": [{
"optionName": "LOGTOJSON",
"logFormat": "COMBINEDAPACHELOG"}]
Log Apache, syslog, CSV
↓
Chuyển sang JSON ngay tại nguồn
→ không cần Lambda biến đổi
Ba lưu ý về Firehose: | Lưu ý | Chi tiết | |---|---| | Tự co giãn, không có shard | | | Đệm tối thiểu 60 giây (một số đích) | | | KHÔNG lưu giữ dữ liệu | |
Ba lưu ý về Kinesis Data Streams: | Lưu ý | Chi tiết | |---|---| | Giữ 1-365 ngày, phát lại được | | | Nhiều consumer độc lập | | | On-demand hoặc provisioned shard | |
Ba lưu ý về VPC Flow Log: | Đích | Ghi chú | |---|---| | CloudWatch Logs | truy vấn ngay bằng Insights | | S3 | rẻ nhất, truy vấn bằng Athena | | Firehose | linh hoạt nhất, biến đổi được |
⚠ Flow log có định dạng tuỳ chỉnh:
--log-format '${srcaddr} ${dstaddr} ${srcport} ${dstport} \
${protocol} ${packets} ${bytes} ${action} ${flow-direction} \
${pkt-src-aws-service} ${pkt-dst-aws-service}'
Hai trường cuối cho biết lưu lượng
đi tới dịch vụ AWS nào
↓
Rất hữu ích để tìm chi phí truyền
dữ liệu bất ngờ
Ba lưu ý về phân tích flow log: | Công cụ | Việc | |---|---| | Athena | truy vấn SQL trên S3 | | CloudWatch Logs Insights | truy vấn gần thời gian thực | | Managed Flink | phân tích luồng |
Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Flow log tính theo GB thu thập | | | Firehose theo GB nạp | | | Hàng terabyte mỗi ngày là khoản lớn | |
⚠ Lọc flow log giảm chi phí đáng kể:
Chỉ ghi lưu lượng REJECT
↓
Hoặc chỉ ghi một số ENI
↓
Giảm mạnh lượng dữ liệu
→ nhưng mất bức tranh đầy đủ
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đọc log của Agent tìm lỗi | | | Kiểm DeliveryStreamType của Firehose | | | Xem chỉ số IncomingRecords của KDS | |
Và một lời khuyên: hãy đưa mọi nguồn dữ liệu về Kinesis Data Streams rồi mới nối Firehose vào sau. Kiểu nguồn của Firehose không đổi được sau khi tạo, nên một luồng dựng theo kiểu Direct PUT sẽ chặn bạn khỏi việc thêm consumer thứ hai về sau — và lúc đó phải dựng lại từ đầu.
A company wants to use SharePoint to deploy a content and collaboration platform with document and records management functionality. The company wants to establish an AWS Direct Connect link to connect the AWS Cloud with the internal corporate network using AWS Storage Gateway. Using AWS Direct Connect would enable the company to deliver on its performance benchmark requirements including a three second or less response time for sending small documents across the internal network. To facilitate this goal, the company wants to be able to resolve DNS queries for any resources in the on-premises network from the AWS VPC and also resolve any DNS queries for resources in the AWS VPC from the on-premises network.
As a Solutions Architect Professional, which of the following solutions would you recommend for this use-case? (Select two)
-
A
Create an outbound endpoint on Route 53 Resolver and then DNS resolvers on the on-premises network can forward DNS queries to Route 53 Resolver via this endpoint
-
B
Create an outbound endpoint on Route 53 Resolver and then Route 53 Resolver can conditionally forward queries to resolvers on the on-premises network via this endpoint
-
C
Create an inbound endpoint on Route 53 Resolver and then DNS resolvers on the on-premises network can forward DNS queries to Route 53 Resolver via this endpoint
-
D
Create a universal endpoint on Route 53 Resolver and then Route 53 Resolver can receive and forward queries to resolvers on the on-premises network via this endpoint
-
E
Create an inbound endpoint on Route 53 Resolver and then Route 53 Resolver can conditionally forward queries to resolvers on the on-premises network via this endpoint
Xem giải thích
Đáp án
**B và C — Tạo outbound endpoint trên Route 53 Resolver để Resolver chuyển tiếp có điều kiện truy vấn tới các máy phân giải tại chỗ; và tạo inbound endpoint để máy phân giải tại chỗ chuyển tiếp truy vấn tới Route 53 Resolver.
Vì sao đúng
Đề yêu cầu phân giải DNS theo cả hai chiều, và mỗi chiều cần một loại endpoint: | Chiều | Endpoint | Ai khởi tạo truy vấn | |---|---|---| | VPC → tại chỗ | OUTBOUND | tài nguyên trong VPC | | Tại chỗ → VPC | INBOUND | máy tại chỗ |
⚠ Cách nhớ: tên endpoint đặt theo hướng nhìn từ VPC:
OUTBOUND: truy vấn ĐI RA khỏi VPC
↓
Route 53 Resolver gửi truy vấn
tới máy phân giải tại chỗ
↓
INBOUND: truy vấn ĐI VÀO VPC
↓
Máy tại chỗ gửi truy vấn tới
Route 53 Resolver
⚠ Và đây là lý do phương án A và E sai — chúng đảo ngược vai trò:
A: "outbound endpoint để máy tại chỗ
chuyển tiếp truy vấn TỚI Route 53"
↓
Đó là việc của INBOUND
↓
E: "inbound endpoint để Route 53
chuyển tiếp truy vấn TỚI tại chỗ"
↓
Đó là việc của OUTBOUND
Tạo inbound endpoint:
aws route53resolver create-resolver-endpoint \
--name endpoint-vao \
--direction INBOUND \
--security-group-ids sg-resolver \
--ip-addresses SubnetId=subnet-1a SubnetId=subnet-1b \
--creator-request-id $(uuidgen)
Tạo outbound endpoint và rule chuyển tiếp:
aws route53resolver create-resolver-endpoint \
--name endpoint-ra \
--direction OUTBOUND \
--security-group-ids sg-resolver \
--ip-addresses SubnetId=subnet-1a SubnetId=subnet-1b \
--creator-request-id $(uuidgen)
aws route53resolver create-resolver-rule \
--name chuyen-tiep-noi-bo \
--rule-type FORWARD \
--domain-name noi-bo.cong-ty.vn \
--resolver-endpoint-id rslvr-out-abc \
--target-ips Ip=192.168.1.10,Port=53 Ip=192.168.1.11,Port=53
⚠ Outbound endpoint một mình không đủ — phải có resolver rule:
Endpoint là hạ tầng
↓
Rule quyết định TÊN MIỀN NÀO
được chuyển tiếp
↓
Thiếu rule: endpoint tồn tại
nhưng không chuyển tiếp gì
⚠ Và rule phải gắn với VPC:
aws route53resolver associate-resolver-rule \
--resolver-rule-id rslvr-rr-abc \
--vpc-id vpc-ung-dung
⚠ Và endpoint cần tối thiểu hai IP ở hai AZ:
Mỗi endpoint tạo ENI trong subnet
↓
Tối thiểu 2 địa chỉ IP
↓
Nên đặt ở hai AZ khác nhau
→ DNS hỏng là ứng dụng chết
⚠ Và mỗi ENI xử lý được khoảng 10.000 truy vấn mỗi giây:
Tải DNS cao
↓
Thêm IP vào endpoint
↓
Tối đa 6 IP mỗi endpoint
⚠ Và security group của endpoint phải mở cổng 53:
aws ec2 authorize-security-group-ingress \
--group-id sg-resolver \
--ip-permissions \
'IpProtocol=udp,FromPort=53,ToPort=53,IpRanges=[{CidrIp=192.168.0.0/16}]' \
'IpProtocol=tcp,FromPort=53,ToPort=53,IpRanges=[{CidrIp=192.168.0.0/16}]'
DNS dùng CẢ UDP lẫn TCP
↓
Chỉ mở UDP: truy vấn nhỏ chạy
được
→ phản hồi lớn (DNSSEC, nhiều
bản ghi) dùng TCP và thất bại
↓
Triệu chứng rất khó chẩn đoán
⚠ Và vì sao phương án D vô nghĩa:
D nói "universal endpoint"
↓
Route 53 Resolver chỉ có INBOUND
và OUTBOUND
↓
Không có loại nào tên "universal"
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phân giải tên hai chiều liền mạch | | | Dịch vụ quản lý, không tự dựng máy DNS | | | Rule chia sẻ được qua RAM cho nhiều tài khoản | |
⚠ Và chia sẻ rule qua RAM là mẫu quan trọng cho nhiều tài khoản:
aws ram create-resource-share \
--name chia-se-resolver-rule \
--resource-arns <arn-rule> \
--principals <arn-ou>
Một tài khoản mạng quản endpoint
và rule
↓
Chia sẻ cho mọi tài khoản khác
→ không phải dựng lại ở từng nơi
⚠ Và Resolver DNS Firewall là tính năng bổ trợ đáng biết:
aws route53resolver create-firewall-rule-group \
--name chan-ten-mien-doc-hai
aws route53resolver create-firewall-domain-list \
--name danh-sach-chan
Chặn truy vấn tới tên miền độc hại
ngay ở tầng DNS
↓
Chống rò rỉ dữ liệu qua DNS
tunneling
⚠ Và Route 53 Resolver là địa chỉ VPC_CIDR + 2:
VPC 10.0.0.0/16
↓
Resolver ở 10.0.0.2
↓
Và địa chỉ `169.254.169.253`
cũng dùng được
Vì sao các phương án khác sai
- **A. Tạo outbound endpoint để máy phân giải tại chỗ chuyển tiếp truy vấn TỚI Route 53 Resolver — đây là phương án gần nhất và outbound endpoint là một loại endpoint có thật, nhưng chiều bị đảo: outbound dành cho truy vấn đi ra khỏi VPC, không phải đi vào.
- **E. Tạo inbound endpoint để Route 53 Resolver chuyển tiếp có điều kiện tới máy tại chỗ — cũng đảo chiều; đó là việc của outbound endpoint.
- **D. Tạo universal endpoint — Route 53 Resolver chỉ có hai loại: inbound và outbound.
Ghi nhớ
⚠ Hai loại Resolver endpoint — bảng phải thuộc: | Loại | Chiều truy vấn | Cần thêm gì | |---|---|---| | Inbound | tại chỗ → VPC | chỉ endpoint | | Outbound | VPC → tại chỗ | endpoint + resolver rule |
Từ khoá nhận diện:
"resolve on-premises names from VPC" → outbound endpoint + rule "resolve VPC names from on-premises" → inbound endpoint "both directions" → cả hai endpoint "block malicious domains" → DNS Firewall
Ba lưu ý về resolver rule: | Loại rule | Tác dụng | |---|---| | FORWARD | chuyển tiếp tên miền tới IP đã khai | | SYSTEM | loại trừ tên miền con khỏi rule FORWARD | | RECURSIVE | dùng Resolver mặc định |
⚠ Rule SYSTEM để tạo ngoại lệ:
FORWARD cho `cong-ty.vn`
↓
SYSTEM cho `aws.cong-ty.vn`
↓
Tên miền con đó phân giải bằng
Route 53 thay vì chuyển tiếp
Ba lưu ý về private hosted zone: | Lưu ý | Chi tiết | |---|---| | Phải bật enableDnsHostnames và enableDnsSupport | | | Gắn được với nhiều VPC | | | Chia sẻ liên tài khoản qua API | |
Ba lưu ý về thứ tự phân giải trong VPC:
1. Private hosted zone gắn với VPC
↓
2. Resolver rule (FORWARD)
↓
3. Bản ghi DNS công khai
⚠ Tên miền cụ thể hơn được ưu tiên:
Rule cho `cong-ty.vn` → chuyển tiếp
↓
Rule cho `noi-bo.cong-ty.vn`
→ chuyển tiếp nơi khác
↓
Truy vấn `db.noi-bo.cong-ty.vn`
dùng rule thứ hai
Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Mỗi ENI khoảng 10.000 truy vấn/giây | | | Tối đa 6 IP mỗi endpoint | | | Đặt ở nhiều AZ để chịu lỗi | |
Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Endpoint tính theo ENI-giờ | | | Truy vấn tính theo triệu | | | Hai endpoint = hai khoản phí | |
Ba lưu ý về chẩn đoán: | Việc | Cách | |---|---| | dig @10.0.0.2 ten.noi-bo.vn | thử từ trong VPC | | Resolver query logging | xem truy vấn nào tới và kết quả | | Kiểm security group cổng 53 UDP và TCP | |
⚠ Bật query logging để chẩn đoán:
aws route53resolver create-resolver-query-log-config \
--name log-truy-van \
--destination-arn <arn-log-group>
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ EC2: dig ten-may.noi-bo.vn | | | Từ máy tại chỗ: dig db.abc.rds.amazonaws.com @<ip-inbound> | | | Kiểm rule đã gắn với VPC chưa | |
Và một lời khuyên: hãy mở cổng 53 cho cả UDP lẫn TCP trong security group của endpoint. Truy vấn DNS thông thường đi bằng UDP nên mọi thứ trông như hoạt động — cho tới khi một phản hồi vượt 512 byte và client phải thử lại bằng TCP, lúc đó bạn sẽ có một lỗi phân giải tên chỉ xảy ra với vài tên miền nhất định.
An e-commerce company runs a data archival workflow once a month for its on-premises data center which is connected to the AWS Cloud over a minimally used 10-Gbps Direct Connect connection using a private virtual interface to its virtual private cloud (VPC). The company internet connection is 200 Mbps, and the usual archive size is around 140 TB that is created on the first Friday of a month. The archive must be transferred and available in Amazon S3 by the next Monday morning.
As a Solutions Architect Professional, which of the following options would you recommend as the LEAST expensive way to address the given use-case?
-
A
Order multiple AWS Snowball Edge appliances, transfer the data in parallel to these appliances and ship them to AWS which will then copy the data from the Snowball Edge appliances to S3
-
B
Configure a public virtual interface on the 10-Gbps Direct Connect connection and then copy the data to S3 over the connection
-
C
Configure a VPC endpoint for S3 and then leverage the Direct Connect connection for data transfer with VPC endpoint as the target
-
D
Configure a private virtual interface on the 10-Gbps Direct Connect connection and then copy the data securely to S3 over the connection
Xem giải thích
Đáp án
**B — Cấu hình một public virtual interface trên kết nối Direct Connect 10 Gbps và chép dữ liệu lên S3 qua kết nối đó.
Vì sao đúng
Đề cho những con số phải ghép lại:
140 TB dữ liệu
↓
Direct Connect 10 Gbps, ÍT DÙNG
→ hoặc Internet 200 Mbps
↓
Tạo tối thứ Sáu, phải xong
sáng thứ Hai
→ khoảng 60 giờ
⚠ Tính thời gian truyền qua từng đường: | Đường | Thời gian lý thuyết | Thực tế (~65%) | |---|---|---| | Direct Connect 10 Gbps | ~31 giờ | ~48 giờ | | Internet 200 Mbps | ~65 ngày | ~100 ngày | | Snowball Edge | 1-2 tuần | không kịp |
140 TB = 1.120.000.000 Mb
↓
Ở 10.000 Mbps: 112.000 giây
= 31 giờ
↓
Cửa sổ 60 giờ → vừa đủ
⚠ Và đây là lý do phương án A (Snowball) sai:
Chu trình Snowball 1-2 tuần
↓
Nhưng đây là công việc HẰNG THÁNG
↓
Đặt thiết bị mỗi tháng, chờ giao,
chép, gửi trả
→ không thể hoàn tất trong một
cuối tuần
⚠ Điểm mấu chốt thứ hai: PUBLIC virtual interface chứ không phải private:
S3 là dịch vụ có endpoint CÔNG KHAI
↓
Private VIF chỉ vào được VPC
↓
Public VIF cho phép tới endpoint
công khai của AWS qua đường
Direct Connect
⚠ Ba loại virtual interface — bảng phải thuộc: | Loại | Tới được | |---|---| | Private VIF | VPC qua virtual private gateway | | Public VIF | dịch vụ công khai: S3, DynamoDB, SQS... | | Transit VIF | Transit Gateway qua DX Gateway |
Đề nói kết nối hiện tại dùng
PRIVATE VIF tới VPC
↓
Muốn tới S3 → thêm một public VIF
↓
Một kết nối vật lý mang được
nhiều VIF
Tạo public VIF:
aws directconnect create-public-virtual-interface \
--connection-id dxcon-abc123 \
--new-public-virtual-interface '{
"virtualInterfaceName": "vif-cong-khai-s3",
"vlan": 200,
"asn": 65001,
"amazonAddress": "175.45.176.1/30",
"customerAddress": "175.45.176.2/30",
"routeFilterPrefixes": [
{"cidr": "203.0.113.0/24"}]}'
⚠ Public VIF cần địa chỉ IP CÔNG KHAI thật:
Không dùng được IP riêng
↓
Phải có dải IP công khai sở hữu
hợp lệ
↓
Hoặc xin AWS cấp
→ đây là rào cản thực tế của
public VIF
⚠ Và vì sao phương án D (private VIF) sai:
Private VIF chỉ vào VPC
↓
Từ VPC muốn tới S3 phải qua:
NAT gateway (ra Internet)
hoặc gateway endpoint
↓
Gateway endpoint chỉ dùng được
từ TRONG VPC
→ máy tại chỗ không dùng được
⚠ Và vì sao phương án C sai — gateway endpoint không dùng được qua DX:
C nói dùng VPC endpoint cho S3 làm
đích qua Direct Connect
↓
Gateway endpoint hoạt động bằng
BẢNG ĐỊNH TUYẾN của VPC
↓
Máy tại chỗ không có bảng định
tuyến đó
→ không tới được
⚠ Nhưng INTERFACE endpoint thì dùng được qua private VIF:
aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
--service-name com.amazonaws.us-east-1.s3 \
--vpc-endpoint-type Interface \
--subnet-ids subnet-1a subnet-1b
Interface endpoint có IP RIÊNG
trong VPC
↓
Máy tại chỗ tới được qua
private VIF
↓
Đây là cách để lưu lượng S3
không bao giờ ra Internet
⚠ Và đó là khác biệt quan trọng giữa hai lựa chọn: | Cách | Lưu lượng đi đâu | Chi phí | |---|---|---| | Public VIF | qua Direct Connect tới endpoint công khai S3 | rẻ hơn | | Private VIF + interface endpoint | hoàn toàn trong mạng riêng | thêm phí endpoint |
Đề hỏi "ÍT TỐN KÉM NHẤT"
↓
Public VIF không có phí endpoint
→ và phí truyền qua DX rẻ hơn
qua Internet
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dùng băng thông đã trả tiền mà đang rảnh | | | Kịp cửa sổ cuối tuần | | | Không thêm chi phí hạ tầng nào | |
⚠ Và phí truyền qua Direct Connect rẻ hơn qua Internet:
Truyền ra qua Internet: ~0,09 USD/GB
↓
Truyền ra qua Direct Connect:
~0,02 USD/GB
↓
Nhưng đây là truyền VÀO S3
→ miễn phí cả hai đường
⚠ Và nên bật multipart upload song song để đạt tốc độ đó:
aws configure set default.s3.max_concurrent_requests 50
aws configure set default.s3.multipart_chunksize 64MB
aws s3 cp /du-lieu-luu-tru/ s3://kho-luu-tru/ --recursive
Một luồng TCP không bao giờ đạt
10 Gbps
↓
Phải nhiều luồng song song
→ và nhiều máy chép cùng lúc
⚠ Và cần giới hạn để không nuốt hết băng thông:
Đề nói kết nối "ít được dùng"
↓
Nhưng vẫn có lưu lượng nghiệp vụ
↓
Chạy vào cuối tuần và đặt trần
băng thông là hợp lý
Vì sao các phương án khác sai
- **D. Cấu hình private virtual interface trên kết nối 10 Gbps và chép dữ liệu lên S3 — đây là phương án gần nhất và dùng đúng đường truyền có băng thông đủ, nhưng private VIF chỉ vào được VPC; muốn tới S3 phải thêm interface endpoint, và đề không nói tới bước đó.
- **C. Cấu hình VPC endpoint cho S3 và dùng Direct Connect với endpoint làm đích — gateway endpoint hoạt động qua bảng định tuyến của VPC nên máy tại chỗ không dùng được.
- **A. Đặt nhiều Snowball Edge và chuyển song song — chu trình 1-2 tuần, không thể hoàn tất trong một cuối tuần, và đây là công việc hằng tháng.
Ghi nhớ
⚠ Ba loại VIF và mục đích — bảng phải thuộc: | VIF | Tới được | Cần IP công khai | |---|---|---| | Private | VPC | không | | Public | dịch vụ công khai AWS | CÓ | | Transit | Transit Gateway | không |
Từ khoá nhận diện:
"copy to S3 over Direct Connect" → public VIF "reach VPC resources over DX" → private VIF "connect to Transit Gateway" → transit VIF "S3 traffic must stay private" → private VIF + interface endpoint
⚠ Công thức tính thời gian truyền:
Số giờ ≈ (TB × 8.000.000) /
(Mbps × 3.600 × 0,65)
↓
140 TB ở 10 Gbps ≈ 48 giờ
140 TB ở 200 Mbps ≈ 2.400 giờ
Ba lưu ý về public VIF: | Lưu ý | Chi tiết | |---|---| | Cần dải IP công khai hợp lệ | | | Quảng bá được tới mọi Region công khai | | | BGP với route filter prefix | |
⚠ Public VIF cho phép tới mọi Region:
Private VIF: chỉ VPC trong một Region
↓
Public VIF: mọi endpoint công
khai AWS toàn cầu
↓
Trừ Trung Quốc
Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | KHÔNG mã hoá — cần MACsec hoặc VPN | | | Một kết nối là điểm hỏng đơn lẻ | | | Nhiều VIF trên một kết nối vật lý | |
Ba lưu ý về tối ưu tốc độ chép lên S3: | Cách | Chi tiết | |---|---| | Multipart song song | nhiều luồng mỗi tệp | | Nhiều tiến trình chép | chia tệp cho nhiều máy | | Gom tệp nhỏ | giảm chi phí siêu dữ liệu |
⚠ Với 140 TB, một máy chép không đủ:
Một máy khó đẩy hết 10 Gbps
↓
Chia thư mục cho nhiều máy
chép song song
↓
Hoặc dùng DataSync với nhiều
agent
Ba lưu ý về DataSync qua Direct Connect: | Lưu ý | Chi tiết | |---|---| | Có kiểm tra toàn vẹn sẵn | | | Giới hạn băng thông được | | | Chạy được theo lịch hằng tháng | |
⚠ DataSync là lựa chọn tốt hơn aws s3 cp cho việc lặp lại:
aws datasync create-task \
--source-location-arn <arn-nfs> \
--destination-location-arn <arn-s3> \
--schedule ScheduleExpression="cron(0 20 ? * FRI *)" \
--options BytesPerSecond=1000000000,\
VerifyMode=ONLY_FILES_TRANSFERRED
Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Truyền VÀO AWS | miễn phí | | Phí cổng Direct Connect | theo giờ, đã trả rồi | | VIF không tính phí thêm | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo tốc độ thật đạt được | | | Kiểm BGP đã học tuyến công khai chưa | | | So số object và dung lượng hai bên | |
Và một lời khuyên: hãy chạy thử một phần dữ liệu để đo tốc độ thật trước khi tin vào phép tính lý thuyết. Con số 31 giờ giả định đạt được toàn bộ 10 Gbps — trong thực tế, tốc độ đọc của hệ thống lưu trữ nguồn thường là nút thắt thật sự, và bạn cần biết điều đó trước tối thứ Sáu chứ không phải sáng thứ Hai.
A company runs its two-tier web application from an on-premises data center. The web servers connect to a PostgreSQL database running on a different server. With the consistent increase in users, both the web servers and the database are underperforming leading to a bad user experience. The company has decided to migrate to AWS Cloud and has chosen Amazon Aurora PostgreSQL as its database solution. The company needs a solution that can scale the web servers and the database layer based on user traffic.
Which of the following options will you combine to improve the application scalability and improve the user experience? (Select two)
-
A
Enable Aurora Auto Scaling for Aurora Writes. Deploy the application on Amazon EC2 instances configured behind an Auto Scaling Group
-
B
Configure EC2 instances behind a Network Load Balancer with Least Outstanding Requests routing algorithm and sticky sessions enabled
-
C
Configure EC2 instances behind an Application Load Balancer with flow hash routing algorithm and sticky sessions enabled
-
D
Configure EC2 instances behind an Application Load Balancer with Round Robin routing algorithm and sticky sessions enabled
-
E
Enable Aurora Auto Scaling for Aurora Replicas. Deploy the application on Amazon EC2 instances configured behind an Auto Scaling Group
Xem giải thích
Đáp án
**D và E — Đặt EC2 sau một Application Load Balancer với thuật toán Round Robin và bật sticky session; và bật Aurora Auto Scaling cho Aurora Replica, triển khai ứng dụng trên EC2 trong một Auto Scaling group.
Vì sao đúng
Đề cần co giãn cả hai tầng, và mỗi đáp án lo một tầng: | Tầng | Cách co giãn | |---|---| | Web | ALB + Auto Scaling group | | Cơ sở dữ liệu | Aurora Auto Scaling cho replica |
⚠ Điểm mấu chốt: Aurora Auto Scaling chỉ áp cho REPLICA, không áp cho writer:
Aurora có MỘT writer duy nhất
↓
Không thể thêm writer để co giãn
việc ghi
↓
Chỉ thêm được replica cho việc
ĐỌC
Đây là lý do phương án A sai — nó nói "Aurora Auto Scaling for Aurora Writes".
⚠ Và đây là giới hạn kiến trúc phải nhớ:
Cần mở rộng GHI trên Aurora
↓
Chỉ có ba cách:
- nâng cỡ instance writer
- chia shard ở tầng ứng dụng
- Aurora Limitless Database
↓
Không có auto scaling cho writer
Bật Aurora Auto Scaling:
aws application-autoscaling register-scalable-target \
--service-namespace rds \
--resource-id cluster:cum-ung-dung \
--scalable-dimension rds:cluster:ReadReplicaCount \
--min-capacity 1 --max-capacity 8
aws application-autoscaling put-scaling-policy \
--service-namespace rds \
--resource-id cluster:cum-ung-dung \
--scalable-dimension rds:cluster:ReadReplicaCount \
--policy-name theo-cpu \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{
"TargetValue": 60.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"},
"ScaleInCooldown": 300, "ScaleOutCooldown": 300}'
⚠ Và ứng dụng phải dùng reader endpoint để hưởng lợi:
Aurora thêm replica tự động
↓
Reader endpoint tự phân phối
tới mọi replica
↓
Ứng dụng vẫn dùng một chuỗi
kết nối
→ không phải sửa gì khi số
replica đổi
⚠ Điểm mấu chốt thứ hai: ALB chỉ có hai thuật toán định tuyến: | Thuật toán | Có ở | |---|---| | Round Robin | ALB (mặc định) | | Least Outstanding Requests | ALB | | Flow hash | NLB | | Weighted random | ALB (với target group weighting) |
"Flow hash" là thuật toán của NLB
↓
NLB băm 5-tuple (IP nguồn, cổng
nguồn, IP đích, cổng đích,
giao thức)
↓
Phương án C gán nó cho ALB
→ sai
⚠ Và vì sao phương án B sai — NLB không có sticky session kiểu ALB:
NLB là tầng 4
↓
Không đọc được HTTP cookie
↓
"Stickiness" của NLB dựa trên
IP nguồn, không phải cookie
↓
Và ứng dụng web hai tầng nên
dùng ALB
Bật sticky session trên ALB:
aws elbv2 modify-target-group-attributes \
--target-group-arn <arn-tg> \
--attributes \
Key=stickiness.enabled,Value=true \
Key=stickiness.type,Value=lb_cookie \
Key=stickiness.lb_cookie.duration_seconds,Value=86400
⚠ Nhưng sticky session là giải pháp tạm — không phải thiết kế tốt:
Sticky session buộc người dùng ở
một máy
↓
Máy đó chết → mất phiên
↓
Và co giãn không đều: máy cũ
giữ nhiều phiên
↓
Cách đúng: đưa phiên ra ngoài
(ElastiCache, DynamoDB)
import redis
phien = redis.Redis(host='cache.abc.cache.amazonaws.com')
phien.setex(f'phien:{ma_phien}', 3600, json.dumps(du_lieu))
⚠ Và hai kiểu stickiness của ALB: | Kiểu | Cookie | |---|---| | lb_cookie | ALB tự sinh AWSALB | | app_cookie | dùng cookie của ứng dụng |
`app_cookie`: ALB theo cookie mà
ứng dụng đặt
↓
Ứng dụng kiểm soát vòng đời phiên
⚠ Và Least Outstanding Requests thường tốt hơn Round Robin:
Round Robin: chia đều theo lượt
↓
Yêu cầu có thời gian xử lý rất
khác nhau
→ máy nhận yêu cầu nặng bị dồn
↓
LOR: gửi tới máy đang có ít
yêu cầu chưa xong nhất
→ cân bằng hơn
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tầng web co giãn theo lưu lượng | | | Tầng đọc CSDL co giãn theo tải | | | Không phải can thiệp thủ công | |
⚠ Và Aurora Serverless v2 là lựa chọn đáng cân nhắc:
Serverless v2 co giãn CPU và RAM
của TỪNG instance
↓
Từ 0,5 tới 128 ACU trong vài
giây
↓
Áp được cho cả writer
→ giải quyết được phần nào việc
mở rộng ghi
Vì sao các phương án khác sai
- **A. Bật Aurora Auto Scaling cho Aurora Writes và triển khai ứng dụng trên EC2 trong ASG — đây là phương án gần nhất và vế về tầng ứng dụng hoàn toàn đúng, nhưng Aurora chỉ có một writer và không có cơ chế auto scaling cho việc ghi.
- **C. Đặt EC2 sau ALB với thuật toán flow hash — flow hash là thuật toán của Network Load Balancer, ALB không có.
- **B. Đặt EC2 sau NLB với Least Outstanding Requests — LOR là thuật toán của ALB, không phải NLB; và NLB ở tầng 4 nên không có sticky session dựa trên cookie.
Ghi nhớ
⚠ Thuật toán định tuyến theo loại load balancer — bảng phải thuộc: | Load balancer | Thuật toán | |---|---| | ALB | Round Robin, Least Outstanding Requests, Weighted Random | | NLB | Flow hash (5-tuple) | | CLB | Round Robin (TCP), Least Outstanding (HTTP) |
Từ khoá nhận diện:
"scale reads on Aurora" → Aurora Auto Scaling cho replica "scale writes on Aurora" → nâng cỡ, sharding, hoặc Limitless "flow hash" → NLB "least outstanding requests" → ALB "sticky sessions with cookie" → ALB
Ba lưu ý về Aurora Auto Scaling: | Lưu ý | Chi tiết | |---|---| | Chỉ áp cho số lượng Aurora Replica | | | Chỉ số: CPU trung bình reader hoặc số kết nối | | | Replica mới mất vài phút để sẵn sàng | |
⚠ Replica mới không sẵn sàng ngay:
Auto scaling kích hoạt
↓
Tạo instance mất vài phút
↓
Đỉnh tải ngắn hơn thời gian đó
→ co giãn không kịp
↓
Đặt `min-capacity` đủ cao cho
tải nền
Ba lưu ý về sticky session: | Lưu ý | Chi tiết | |---|---| | Làm co giãn không đều | | | Mất phiên khi máy chết | | | Chỉ nên dùng khi không sửa được ứng dụng | |
Ba lưu ý về trạng thái phiên: | Nơi lưu | Đặc điểm | |---|---| | ElastiCache Redis | nhanh nhất, hay dùng nhất | | DynamoDB | bền, có TTL sẵn | | Cookie đã ký ở client | không cần kho, giới hạn kích thước |
Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Health check phải chạm logic ứng dụng | | | Cross-zone bật sẵn | | | Định tuyến theo host, đường dẫn, header | |
Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | Health check kiểu ELB, không phải EC2 | | | Warm pool giảm thời gian khởi động | | | Predictive scaling cho tải theo chu kỳ | |
⚠ Predictive scaling học mẫu tải theo tuần:
aws autoscaling put-scaling-policy \
--auto-scaling-group-name doi-web \
--policy-name du-doan \
--policy-type PredictiveScaling \
--predictive-scaling-configuration '{
"MetricSpecifications": [{
"TargetValue": 50,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"}}],
"Mode": "ForecastAndScale"}'
Ba lưu ý về di trú PostgreSQL sang Aurora: | Cách | Ngừng dịch vụ | |---|---| | DMS full load + CDC | rất ngắn | | pg_dump/pg_restore | dài | | Khôi phục từ snapshot RDS | trung bình |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử tải và xem replica có tự thêm không | | | Kiểm ứng dụng dùng reader endpoint | | | Đo phân bố yêu cầu giữa các máy web | |
Và một lời khuyên: hãy đưa trạng thái phiên ra ElastiCache thay vì dựa vào sticky session. Sticky session làm ứng dụng chạy được ngay hôm nay, nhưng nó khiến việc co giãn mất tác dụng một nửa — máy mới thêm vào chỉ nhận người dùng mới, còn tải hiện tại vẫn dồn lên những máy cũ.
A health and beauty products company processes thousands of orders each day from 100 countries and its website is localized in 15 languages. The company’s website faces continual security threats and challenges in the form of HTTP flood attacks, distributed denial of service (DDoS) attacks, rogue robots that flood its website with traffic, SQL-injection attacks designed to extract data and cross-site scripting attacks (XSS). Most of these attacks originate from certain countries. Therefore, the company wants to block access to its application from specific countries; however, the company wants to allow its remote development team (from one of the blocked countries) to have access to the application. The application is deployed on EC2 instances running under an Application Load Balancer (ALB) with AWS WAF.
As a Solutions Architect Professional, which of the following solutions would you suggest as the BEST fit for the given use-case? (Select two)
-
A
Use ALB geo match statement listing the countries that you want to block
-
B
Create a deny rule for the blocked countries in the NACL associated with each of the EC2 instances
-
C
Use WAF geo match statement listing the countries that you want to block
-
D
Use ALB IP set statement that specifies the IP addresses that you want to allow through
-
E
Use WAF IP set statement that specifies the IP addresses that you want to allow through
Xem giải thích
Đáp án
**C và E — Dùng WAF geo match statement liệt kê các quốc gia cần chặn, và dùng WAF IP set statement khai các địa chỉ IP được phép đi qua.
Vì sao đúng
Đề nêu hai yêu cầu tưởng như mâu thuẫn, và WAF giải quyết bằng thứ tự quy tắc:
Chặn truy cập từ một số quốc gia
↓
NHƯNG cho phép đội phát triển
(nằm ở một trong các quốc gia
bị chặn)
↓
Cần một ngoại lệ được xét TRƯỚC
quy tắc chặn
⚠ Điểm mấu chốt: WAF xét quy tắc theo THỨ TỰ ƯU TIÊN:
Priority 0: IP set của đội phát
triển → ALLOW
↓
Priority 1: geo match các quốc
gia cấm → BLOCK
↓
Quy tắc khớp ĐẦU TIÊN quyết định
→ đội phát triển được ALLOW
trước khi tới quy tắc chặn
Tạo IP set cho đội phát triển:
aws wafv2 create-ip-set \
--name ip-doi-phat-trien \
--scope REGIONAL \
--ip-address-version IPV4 \
--addresses 203.0.113.0/24 198.51.100.5/32
Web ACL với hai quy tắc theo đúng thứ tự:
{"Name": "bao-ve-ung-dung",
"DefaultAction": {"Allow": {}},
"Rules": [
{"Name": "cho-phep-doi-phat-trien",
"Priority": 0,
"Statement": {"IPSetReferenceStatement": {
"ARN": "<arn-ip-set>"}},
"Action": {"Allow": {}},
"VisibilityConfig": {"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "choPhepDoiPhatTrien"}},
{"Name": "chan-theo-quoc-gia",
"Priority": 1,
"Statement": {"GeoMatchStatement": {
"CountryCodes": ["CN", "RU", "KP", "IR"]}},
"Action": {"Block": {}},
"VisibilityConfig": {"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "chanTheoQuocGia"}}]}
⚠ Priority thấp hơn được xét TRƯỚC — đây là chi tiết quyết định:
Đảo thứ tự: geo match priority 0
↓
Đội phát triển bị chặn ngay
→ không bao giờ tới quy tắc
cho phép
↓
Thứ tự sai làm cả cấu hình
vô nghĩa
⚠ Và hành động Allow là hành động KẾT THÚC: | Hành động | Sau đó | |---|---| | Allow | dừng xét, cho qua | | Block | dừng xét, từ chối | | Count | TIẾP TỤC xét quy tắc sau |
`Count` rất hữu ích để thử nghiệm
↓
Đặt quy tắc mới ở chế độ Count
↓
Xem nó khớp bao nhiêu yêu cầu
→ rồi mới đổi sang Block
⚠ Và vì sao ba phương án còn lại sai:
A và D nói dùng "ALB geo match"
và "ALB IP set"
↓
ALB KHÔNG có hai khái niệm đó
↓
ALB định tuyến theo host, đường
dẫn, header, phương thức,
query, IP nguồn — nhưng không
có geo match
⚠ Và ALB có điều kiện source-ip nhưng không đủ:
aws elbv2 create-rule --listener-arn <arn> \
--conditions '[{"Field":"source-ip",
"SourceIpConfig":{"Values":["203.0.113.0/24"]}}]' \
--actions '[{"Type":"fixed-response",
"FixedResponseConfig":{"StatusCode":"403"}}]' \
--priority 1
Chặn được theo IP
↓
Nhưng không có dữ liệu địa lý
→ phải tự duy trì danh sách IP
của cả một quốc gia
↓
Không khả thi
⚠ Và vì sao phương án B sai — NACL không gắn vào instance:
B nói tạo quy tắc deny trong NACL
"gắn với từng EC2 instance"
↓
NACL gắn vào SUBNET, không phải
instance
↓
Và NACL không biết quốc gia
→ chỉ biết dải IP
↓
Hạn ngạch 20 quy tắc mỗi NACL
→ không đủ cho một quốc gia
⚠ Và WAF giải quyết luôn các mối đe doạ khác trong đề: | Mối đe doạ | Quy tắc WAF | |---|---| | HTTP flood | rate-based rule | | SQL injection | SQLiMatchStatement hoặc managed rule | | XSS | XssMatchStatement hoặc managed rule | | Bot | AWS Managed Rules Bot Control |
Rate-based rule chống HTTP flood:
{"Name": "chan-tan-suat-cao",
"Priority": 2,
"Statement": {"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"}},
"Action": {"Block": {}}}
Managed rule group cho SQLi và XSS:
{"Name": "AWSManagedRulesCommonRuleSet",
"Priority": 3,
"OverrideAction": {"None": {}},
"Statement": {"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet"}}}
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn theo quốc gia mà không cần danh sách IP | | | Ngoại lệ chính xác cho đội phát triển | | | Cùng một web ACL lo mọi mối đe doạ khác | |
⚠ Và WAF ghi log cho việc phân tích:
aws wafv2 put-logging-configuration --logging-configuration '{
"ResourceArn": "<arn-webacl>",
"LogDestinationConfigs": ["arn:aws:s3:::aws-waf-logs-ung-dung"],
"RedactedFields": [{"SingleHeader": {"Name": "authorization"}}]}'
⚠ Nhưng geo match dựa trên cơ sở dữ liệu GeoIP — không tuyệt đối:
VPN và proxy làm sai kết quả
↓
Cơ sở dữ liệu GeoIP có sai số
↓
Chặn theo quốc gia là biện pháp
giảm nhiễu, không phải kiểm
soát an ninh chặt chẽ
Vì sao các phương án khác sai
- **A. Dùng ALB geo match statement liệt kê các quốc gia cần chặn — đây là phương án gần nhất và ý tưởng chặn theo quốc gia hoàn toàn đúng, nhưng ALB không có khả năng geo match; đó là tính năng của WAF.
- **D. Dùng ALB IP set statement khai IP được phép — ALB có điều kiện
source-ipnhưng không có khái niệm "IP set", và cách này không kết hợp được với chặn theo quốc gia. - **B. Tạo quy tắc deny trong NACL gắn với từng EC2 instance — NACL gắn vào subnet chứ không phải instance, không biết quốc gia, và có hạn ngạch quy tắc rất thấp.
Ghi nhớ
⚠ Bốn loại statement hay dùng của WAF — bảng phải thuộc: | Statement | Khớp theo | |---|---| | GeoMatchStatement | quốc gia | | IPSetReferenceStatement | danh sách IP/CIDR | | RateBasedStatement | số yêu cầu mỗi 5 phút từ một IP | | ByteMatchStatement | chuỗi trong header, URI, thân |
Từ khoá nhận diện:
"block by country with exceptions" → WAF: IP set allow trước, geo match block sau "HTTP flood" → rate-based rule "SQL injection, XSS" → AWS Managed Rules "bad bots" → Bot Control managed rule
Ba lưu ý về thứ tự quy tắc: | Lưu ý | Chi tiết | |---|---| | Priority thấp xét trước | | | Allow và Block là hành động kết thúc | | | Count tiếp tục xét quy tắc sau | |
⚠ Dùng Count để thử nghiệm quy tắc mới:
Đặt quy tắc mới ở Count
↓
Theo dõi chỉ số CloudWatch vài
ngày
↓
Xác nhận không chặn nhầm lưu
lượng hợp lệ
→ rồi mới đổi sang Block
Ba lưu ý về rate-based rule: | Lưu ý | Chi tiết | |---|---| | Cửa sổ 5 phút (hoặc 1, 2, 10 phút) | | | Gộp theo IP, header, hoặc IP chuyển tiếp | | | Kết hợp được với scope-down statement | |
⚠ Scope-down giới hạn phạm vi của rate limit:
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": {"ByteMatchStatement": {
"SearchString": "/dang-nhap",
"FieldToMatch": {"UriPath": {}},
"PositionalConstraint": "STARTS_WITH",
"TextTransformations": [{"Priority": 0, "Type": "NONE"}]}}}
Chỉ áp giới hạn tần suất cho
endpoint đăng nhập
↓
Chống dò mật khẩu mà không ảnh
hưởng lưu lượng bình thường
Ba lưu ý về managed rule group: | Nhóm | Chống | |---|---| | CommonRuleSet | OWASP Top 10 phổ biến | | KnownBadInputs | payload khai thác đã biết | | SQLiRuleSet | SQL injection | | IPReputationList | IP có tiếng xấu |
Ba lưu ý về gắn WAF: | Gắn được vào | Scope | |---|---| | CloudFront | CLOUDFRONT (us-east-1) | | ALB | REGIONAL | | API Gateway | REGIONAL | | AppSync, Cognito, App Runner | REGIONAL |
⚠ WAF KHÔNG gắn được vào NLB:
NLB ở tầng 4
↓
WAF cần đọc HTTP
↓
Muốn bảo vệ dịch vụ sau NLB
→ đặt ALB hoặc CloudFront trước
Ba lưu ý về IP thật của client: | Lưu ý | Chi tiết | |---|---| | Sau CloudFront, dùng X-Forwarded-For | | | ForwardedIPConfig trong statement | | | Không cấu hình → thấy IP của CloudFront | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi từ IP của đội phát triển — phải qua | | | Gọi từ quốc gia bị chặn — phải 403 | | | Xem log WAF tìm terminatingRuleId | |
Và một lời khuyên: hãy đặt quy tắc cho phép đội phát triển ở priority 0 và kiểm chứng ngay sau khi triển khai. WAF xét theo thứ tự và dừng ở quy tắc khớp đầu tiên — một quy tắc ngoại lệ đặt sau quy tắc chặn sẽ không bao giờ được xét tới, và bạn sẽ khoá chính đội của mình ra khỏi ứng dụng.
A medical technology company has recently set up a hybrid cloud between its on-premises data centers and AWS Cloud. The engineering team at the company has developed a Media Archiving and Communication System application that runs on AWS to support real-time collaboration among radiologists and other specialists. The company uses Amazon S3 to aggregate the raw medical images and video footage from its research teams across the world to discover tremendous medical insights. The technical teams at the overseas research facilities have reported huge delays in uploading large video files to the destination S3 bucket.
As a Solutions Architect Professional, which of the following would you recommend as the MOST cost-effective solutions to improve the file upload speed into S3? (Select two)
-
A
Create multiple site-to-site VPN connections between the AWS Cloud and research facilities running in the on-premises data centers. Use these VPN connections for faster file uploads into S3
-
B
Use Amazon S3 Transfer Acceleration to enable faster file uploads into the destination S3 bucket
-
C
Use multipart uploads for faster file uploads into the destination S3 bucket
-
D
Create multiple AWS direct connect connections between the AWS Cloud and research facilities running in the on-premises data centers. Use the direct connect connections for faster file uploads into S3
-
E
Use AWS Global Accelerator for faster file uploads into the destination S3 bucket
Xem giải thích
Đáp án
**B và C — Dùng Amazon S3 Transfer Acceleration để tăng tốc tải lên bucket đích, và dùng multipart upload để tải tệp nhanh hơn.
Vì sao đúng
Đề nêu một bài toán rất cụ thể:
Nhóm nghiên cứu ở khắp thế giới
↓
Tải tệp video LỚN lên một bucket
S3 duy nhất
↓
Chậm nghiêm trọng
↓
Cần giải pháp HIỆU QUẢ CHI PHÍ
NHẤT
⚠ Điểm mấu chốt: hai đáp án tấn công hai nguyên nhân khác nhau: | Nguyên nhân | Cách chữa | |---|---| | Đường đi qua Internet công cộng dài và không ổn định | Transfer Acceleration | | Một luồng TCP không đạt hết băng thông | multipart upload song song |
⚠ Và multipart thường cho cải thiện lớn hơn cả S3TA:
Một luồng TCP đường dài
↓
Cửa sổ TCP × RTT giới hạn thông
lượng
↓
RTT 200 ms, cửa sổ 64 KB
→ tối đa khoảng 2,6 Mbps
↓
Mười luồng song song
→ gấp mười
Multipart với nhiều luồng:
from boto3.s3.transfer import TransferConfig
cau_hinh = TransferConfig(
multipart_threshold=64*1024*1024,
max_concurrency=20,
multipart_chunksize=64*1024*1024,
use_threads=True)
s3.upload_file('phim-chup.mp4', 'anh-y-te',
'ca-benh/A-42.mp4', Config=cau_hinh)
⚠ Và multipart có thêm lợi ích về độ tin cậy:
Tệp 10 GB tải một lần
↓
Đứt kết nối ở 95% → làm lại
từ đầu
↓
Multipart: chỉ tải lại phần
bị hỏng
→ và tiếp tục được sau khi
gián đoạn
Bật Transfer Acceleration:
aws s3api put-bucket-accelerate-configuration \
--bucket anh-y-te \
--accelerate-configuration Status=Enabled
⚠ Và S3TA chỉ tính phí khi thật sự nhanh hơn — nên gần như không rủi ro:
AWS so tốc độ qua điểm biên với
đi thẳng
↓
Không nhanh hơn → không tính
phí tăng tốc
↓
Đây là lý do nó "hiệu quả chi
phí"
⚠ Và vì sao phương án E sai — Global Accelerator không hỗ trợ S3:
Global Accelerator định tuyến tới:
ALB, NLB, EC2, Elastic IP
↓
KHÔNG có S3 làm endpoint
↓
Chức năng tăng tốc tới S3 chính
là S3 Transfer Acceleration
⚠ Và vì sao hai phương án về kết nối riêng (A, D) không "hiệu quả chi phí":
Direct Connect: hợp đồng, thiết bị,
phí cổng theo giờ
↓
VPN: phải dựng và quản lý ở
từng cơ sở nghiên cứu
↓
Với NHIỀU cơ sở trên khắp thế
giới
→ chi phí và công sức rất lớn
↓
Và cả hai đều mất hàng tuần
tới hàng tháng để triển khai
⚠ Và VPN qua Internet không nhanh hơn — nó chỉ mã hoá:
Site-to-Site VPN đi trên chính
Internet công cộng
↓
Thêm chi phí mã hoá
↓
Thường CHẬM HƠN kết nối trực
tiếp có TLS
↓
Nó giải quyết bảo mật, không
giải quyết tốc độ
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bật được ngay, không chờ hạ tầng | | | S3TA chỉ tính phí khi hiệu quả | | | Multipart cải thiện cả tốc độ lẫn độ tin cậy | |
⚠ Và nên đo trước bằng công cụ so tốc độ:
https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
en/accelerate-speed-comparsion.html
Chạy từ mỗi cơ sở nghiên cứu
↓
Biết nơi nào hưởng lợi nhiều
↓
Nơi gần Region thì không cần bật
⚠ Và luôn đặt luật dọn phần multipart dở dang:
{"Rules": [{
"ID": "don-multipart-do-dang",
"Filter": {},
"Status": "Enabled",
"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}
Tải lên hỏng giữa chừng
↓
Các phần đã tải nằm lại
↓
KHÔNG hiện khi liệt kê object
→ nhưng vẫn tính tiền lưu trữ
⚠ Và có thể dùng S3 Batch Operations cho phần dở dang cũ:
aws s3api list-multipart-uploads --bucket anh-y-te \
--query 'Uploads[?Initiated<`2026-08-01`].[Key,UploadId]' \
--output text
⚠ Và CloudFront cũng dùng được để tải lên:
CloudFront cho phép PUT/POST
↓
Kết nối TLS kết thúc ở biên
↓
Nhưng với việc CHỈ tải lên,
S3TA đơn giản hơn
→ và không phải quản một
distribution
Vì sao các phương án khác sai
- **D. Tạo nhiều Direct Connect giữa AWS và các cơ sở nghiên cứu — đây là phương án gần nhất và thật sự cho băng thông ổn định nhất, nhưng chi phí và thời gian triển khai cho nhiều cơ sở trên khắp thế giới là rất lớn, trái với yêu cầu hiệu quả chi phí.
- **A. Tạo nhiều site-to-site VPN — VPN đi trên chính Internet công cộng nên không nhanh hơn, chỉ thêm chi phí mã hoá.
- **E. Dùng Global Accelerator để tải tệp lên S3 — Global Accelerator không hỗ trợ S3 làm endpoint.
Ghi nhớ
⚠ Bốn cách tăng tốc tải lên S3 — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Multipart song song | luôn nên bật với tệp lớn | | Transfer Acceleration | client ở xa Region | | CloudFront cho phép PUT | khi đã có distribution | | Snow Family | lượng rất lớn, ngoại tuyến |
Từ khoá nhận diện:
"slow uploads from remote locations" → S3TA + multipart "Global Accelerator for S3" → luôn SAI "cost-effective, quick to implement" → loại Direct Connect "consistent bandwidth guaranteed" → Direct Connect
Ba lưu ý về multipart: | Lưu ý | Chi tiết | |---|---| | Bắt buộc trên 5 GB | | | Tối đa 10.000 phần | | | Mỗi phần 5 MB - 5 GB (trừ phần cuối) | |
⚠ Tính kích thước phần cho tệp rất lớn:
Tệp 100 GB, phần 5 MB
↓
20.000 phần → vượt giới hạn
10.000
↓
Phải dùng phần lớn hơn: 16 MB
→ 6.400 phần
Ba lưu ý về Transfer Acceleration: | Lưu ý | Chi tiết | |---|---| | Tên bucket không được có dấu chấm | | | Endpoint riêng s3-accelerate | | | Không hỗ trợ PUT Object - Copy | |
Ba lưu ý về đo hiệu quả: | Việc | Cách | |---|---| | Chạy công cụ so tốc độ của AWS | | | Đo thời gian tải thật từ mỗi cơ sở | | | Kiểm hoá đơn có dòng phí S3TA không | |
Ba lưu ý về dữ liệu y tế: | Lưu ý | Chi tiết | |---|---| | Mã hoá SSE-KMS với khoá riêng | | | Bật CloudTrail data event | | | Ký BAA với AWS cho HIPAA | |
Ba lưu ý về tổ chức dữ liệu: | Lưu ý | Chi tiết | |---|---| | Tiền tố theo ngày hoặc theo cơ sở | | | Gắn thẻ để phân bổ chi phí | | | Vòng đời chuyển tầng cho dữ liệu cũ | |
⚠ Prefix không còn ảnh hưởng hiệu năng như trước:
Trước tháng 7/2018: phải rải tiền
tố ngẫu nhiên để tránh nóng phân
vùng
↓
Nay S3 tự chia phân vùng
↓
3.500 PUT và 5.500 GET mỗi giây
cho MỖI tiền tố
→ tổ chức tiền tố theo nghiệp vụ
Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | 4xxErrors, 5xxErrors | tải lên thất bại | | FirstByteLatency | độ trễ tới S3 | | CloudTrail data event | ai tải gì lên |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian tải tệp lớn trước và sau | | | Kiểm không còn phần multipart dở dang | | | So chi phí trước và sau khi bật S3TA | |
Và một lời khuyên: hãy đặt luật dọn phần multipart dở dang ngay khi bật multipart upload. Những phần đó không hiện ra khi liệt kê object nên không ai để ý, nhưng chúng vẫn tính tiền lưu trữ — và với các cơ sở nghiên cứu tải tệp video lớn qua đường truyền không ổn định, chúng tích luỹ rất nhanh.
A company has built its serverless solution using Amazon API Gateway REST API and AWS Lambda across multiple AWS Regions configured into a single AWS account. During peak hours, customers began to receive 429 Too Many Requests errors from multiple API methods. While troubleshooting the issue, the team realized that AWS Lambda function(s) have not been invoked for these API methods. Also, the company wants to provide a separate quota for its premium customers to access the APIs.
Which solution will you offer to meet this requirement?
-
A
The error is the outcome of the company reaching its API Gateway account limit for calls per second, configure API keys as client identifiers using usage plans to define the per-client throttling limits for premium customers
-
B
The error is the outcome of the company reaching its API Gateway limits for the steady-state requests per second (RPS) across all APIs within an AWS account per Region. These limits can be overwritten by configuring the AWS Regional throttling parameters to a greater value. However, based on the AWS account type, a limit is set to the overwritten throttling values
-
C
The error is the outcome of the company reaching its API Gateway account per-method limit for calls per second, configure API keys as client identifiers using usage plans to define the per-client throttling limits for premium customers
-
D
The error is the outcome of the company reaching its API Gateway account limit for calls per second, set Lambda-level throttling targets in the API Gateway usage plan, and configure customers to use a particular API method when the client identifier is set
Xem giải thích
Đáp án
**A — Lỗi phát sinh vì công ty đã chạm hạn mức lời gọi mỗi giây ở cấp TÀI KHOẢN của API Gateway; cấu hình API key làm định danh khách hàng kèm usage plan để đặt giới hạn tần suất riêng cho khách hàng cao cấp.
Vì sao đúng
Đề cho một dấu hiệu chẩn đoán rất rõ:
Khách hàng nhận lỗi 429 Too Many
Requests
↓
Từ NHIỀU phương thức API khác nhau
↓
Và hàm Lambda KHÔNG hề được gọi
↓
Nghĩa là API Gateway chặn TRƯỚC
khi tới tích hợp
⚠ Điểm mấu chốt: "nhiều phương thức" và "Lambda không được gọi" chỉ ra hạn mức cấp TÀI KHOẢN:
Hạn mức cấp PHƯƠNG THỨC
↓
Chỉ phương thức đó bị chặn
↓
Hạn mức cấp TÀI KHOẢN
→ mọi phương thức trong Region
đều bị ảnh hưởng
↓
Đề nói "multiple API methods"
→ cấp tài khoản
Đây là lý do phương án C sai — nó nói hạn mức cấp phương thức.
⚠ Và hạn mức mặc định của API Gateway: | Hạn mức | Giá trị mặc định | |---|---| | Steady-state rate | 10.000 yêu cầu/giây mỗi Region mỗi tài khoản | | Burst | 5.000 yêu cầu | | Nâng lên được | CÓ, qua Service Quotas |
Xin nâng hạn mức:
aws service-quotas request-service-quota-increase \
--service-code apigateway \
--quota-code L-8A5B8E43 \
--desired-value 20000
⚠ Và usage plan giải quyết yêu cầu thứ hai của đề:
"Cấp hạn mức riêng cho khách hàng
cao cấp"
↓
API key định danh từng khách
↓
Usage plan gắn với API key
→ mỗi nhóm khách một mức
Tạo usage plan cho khách cao cấp:
aws apigateway create-usage-plan \
--name goi-cao-cap \
--throttle burstLimit=5000,rateLimit=2000 \
--quota limit=50000000,period=MONTH \
--api-stages apiId=abc123,stage=prod
aws apigateway create-usage-plan \
--name goi-tieu-chuan \
--throttle burstLimit=500,rateLimit=200 \
--quota limit=1000000,period=MONTH \
--api-stages apiId=abc123,stage=prod
Gắn API key vào usage plan:
aws apigateway create-api-key --name khach-cao-cap-A --enabled
aws apigateway create-usage-plan-key \
--usage-plan-id up-abc \
--key-id key-xyz --key-type API_KEY
⚠ Và ba tầng throttling của API Gateway — phải phân biệt: | Tầng | Phạm vi | |---|---| | Account-level | mọi API trong Region | | Stage-level và method-level | một stage hoặc một phương thức | | Usage plan | một khách hàng (theo API key) |
Thứ tự áp: usage plan → method →
stage → account
↓
Mức chặt nhất có hiệu lực
⚠ Và vì sao phương án B sai — không "ghi đè" được hạn mức Regional:
B nói có thể ghi đè hạn mức Regional
bằng cách đặt tham số throttling
lớn hơn
↓
Tham số stage/method chỉ đặt
mức THẤP HƠN
↓
Không vượt được trần tài khoản
→ phải xin nâng qua Service Quotas
⚠ Và vì sao phương án D sai — không có "Lambda-level throttling" trong usage plan:
D nói đặt "mục tiêu throttling cấp
Lambda trong usage plan"
↓
Usage plan không có khái niệm đó
↓
Giới hạn đồng thời của Lambda
đặt bằng reserved concurrency,
ở phía Lambda
⚠ Và cần phân biệt 429 của API Gateway với 429 của Lambda: | Nguồn | Dấu hiệu | |---|---| | API Gateway throttle | Lambda KHÔNG được gọi, không có log | | Lambda throttle | chỉ số Throttles của Lambda tăng |
Đề nói Lambda không được gọi
↓
→ API Gateway chặn
↓
Nếu Lambda bị chặn thì API
Gateway trả 500 hoặc 502,
không phải 429
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giải quyết đúng nút thắt | | | Khách cao cấp có hạn mức riêng | | | Khách thường không nuốt hết công suất | |
⚠ Và usage plan còn có hạn mức theo tháng:
`quota limit=50000000,period=MONTH`
↓
Khách dùng hết hạn mức tháng
→ bị chặn tới đầu tháng sau
↓
Hữu ích cho mô hình bán API
theo gói
⚠ Và API key KHÔNG phải cơ chế xác thực:
API key chỉ để ĐỊNH DANH khách và
áp hạn mức
↓
Nó đi trong header `x-api-key`
→ dễ trích từ client
↓
Xác thực người dùng phải dùng
Cognito, Lambda authorizer,
hoặc IAM
⚠ Và HTTP API không có usage plan: | Tính năng | REST API | HTTP API | |---|---|---| | API key + usage plan | CÓ | KHÔNG | | Throttling theo stage/route | CÓ | CÓ | | Giá | cao hơn ~3,5 lần | rẻ hơn |
Đề nói dùng REST API
↓
→ có usage plan
Vì sao các phương án khác sai
- **C. Lỗi do chạm hạn mức cấp PHƯƠNG THỨC, cấu hình API key và usage plan — đây là phương án gần nhất và giải pháp usage plan hoàn toàn đúng, nhưng chẩn đoán sai: hạn mức cấp phương thức chỉ ảnh hưởng một phương thức, còn đề nói nhiều phương thức cùng lỗi.
- **B. Lỗi do chạm hạn mức RPS ở cấp Region, có thể ghi đè bằng cách đặt tham số Regional lớn hơn — tham số throttling của stage/method chỉ đặt được mức thấp hơn trần tài khoản; muốn tăng phải xin qua Service Quotas.
- **D. Đặt mục tiêu throttling cấp Lambda trong usage plan — usage plan không có khái niệm đó; giới hạn Lambda đặt bằng reserved concurrency.
Ghi nhớ
⚠ Bốn tầng throttling của API Gateway — bảng phải thuộc: | Tầng | Ai đặt | Ghi đè trần tài khoản | |---|---|---| | Account | AWS (nâng qua Service Quotas) | — | | Stage | bạn | KHÔNG, chỉ thấp hơn | | Method | bạn | KHÔNG | | Usage plan | bạn, theo API key | KHÔNG |
Từ khoá nhận diện:
"429 across multiple methods, Lambda not invoked" → hạn mức cấp tài khoản "separate quota per customer" → API key + usage plan "limit a single endpoint" → method-level throttling "limit Lambda concurrency" → reserved concurrency
Ba lưu ý về usage plan: | Lưu ý | Chi tiết | |---|---| | Gắn với stage của API | | | Có throttle (giây) và quota (ngày/tuần/tháng) | | | Xem được mức dùng của từng key | |
aws apigateway get-usage --usage-plan-id up-abc \
--start-date 2026-09-01 --end-date 2026-09-30 \
--key-id key-xyz
Ba lưu ý về API key: | Lưu ý | Chi tiết | |---|---| | Không phải cơ chế xác thực | | | Bật apiKeyRequired trên method | | | Truyền trong header x-api-key | |
Ba lưu ý về giảm tải cho backend: | Cách | Tác dụng | |---|---| | Cache phản hồi ở API Gateway | không gọi backend | | Throttling | chặn trước khi tới backend | | Reserved concurrency của Lambda | bảo vệ hệ thống phía sau |
⚠ Cache của API Gateway giảm cả chi phí lẫn tải:
aws apigateway update-stage --rest-api-id abc123 \
--stage-name prod --patch-operations \
op=replace,path=/cacheClusterEnabled,value=true \
op=replace,path=/cacheClusterSize,value=0.5 \
op=replace,path=/*/*/caching/ttlInSeconds,value=300
Ba lưu ý về chẩn đoán 429: | Việc | Cách | |---|---| | Xem chỉ số 4XXError của API Gateway | | | Bật access log ghi $context.status | | | So với chỉ số Throttles của Lambda | |
Ba lưu ý về Service Quotas: | Lưu ý | Chi tiết | |---|---| | Xem hạn mức hiện tại và mức tối đa | | | Xin nâng có thể mất vài ngày | | | Đặt cảnh báo khi sắp chạm | |
Ba lưu ý về thiết kế API nhiều tầng khách hàng: | Tầng | Cấu hình | |---|---| | Miễn phí | quota tháng thấp, throttle thấp | | Tiêu chuẩn | quota trung bình | | Cao cấp | quota cao, throttle cao |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi vượt hạn mức và kiểm nhận 429 | | | Xem get-usage biết khách nào dùng nhiều | | | Kiểm Lambda có log không khi bị 429 | |
Và một lời khuyên: hãy kiểm tra xem Lambda có được gọi hay không trước khi đi tìm nguyên nhân của lỗi 429. Nếu không có log Lambda nào thì nút thắt nằm ở API Gateway, còn nếu có log kèm chỉ số Throttles tăng thì vấn đề nằm ở hạn mức đồng thời của Lambda — hai nguyên nhân hoàn toàn khác nhau với cùng một mã lỗi.
A healthcare technology solutions company recently faced a security event resulting in an S3 bucket with sensitive data containing Personally Identifiable Information (PII) for patients being made public. The company policy mandates never to have public S3 objects so the Governance and Compliance team must be notified immediately as soon as any public objects are identified. The company has hired you as an AWS Certified Solutions Architect Professional to help build a solution that detects the presence of a public S3 object, which in turn sets off an alarm to trigger notifications and then automatically remediates the said object.
Which of the following solutions would you implement in tandem to meet the requirements of the given use-case? (Select two)
-
A
Configure a Lambda function as one of the SNS topic subscribers, which is invoked to secure the objects in the S3 bucket
-
B
Leverage AWS Trusted Advisor to check for S3 bucket public-read permissions and invoke a Lambda function to send a notification via SNS as soon as a public object is uploaded
-
C
Enable object-level logging for S3. Set up a EventBridge event pattern when a PutObject API call with public-read permission is detected in the AWS CloudTrail logs and set the target as an SNS topic for downstream notifications
-
D
Leverage AWS Access Analyzer to check for S3 bucket public-read permissions and invoke a Lambda function to send a notification via SNS as soon as a public object is uploaded
-
E
Enable object-level logging for S3. When a PutObject API call is made with a public-read permission, use S3 event notifications to trigger a Lambda that sends a notification via SNS
Xem giải thích
Đáp án
**A và C — Bật object-level logging cho S3, đặt một mẫu sự kiện EventBridge khi phát hiện lời gọi PutObject có quyền public-read trong log CloudTrail, và đặt đích là một SNS topic; đồng thời cấu hình một hàm Lambda làm người đăng ký của SNS topic để tự động sửa quyền của object.
Vì sao đúng
Đề nêu ba việc phải xảy ra, và hai đáp án ghép lại phủ cả ba: | Việc | Thành phần | |---|---| | Phát hiện object công khai | CloudTrail data event + EventBridge (C) | | Báo cho đội tuân thủ | SNS topic (C) | | Tự sửa quyền | Lambda đăng ký SNS (A) |
⚠ Điểm mấu chốt: SNS fan-out cho phép một sự kiện làm hai việc:
EventBridge → SNS topic
↓
Đăng ký 1: email đội tuân thủ
Đăng ký 2: Lambda sửa quyền
↓
Một sự kiện, hai hành động
song song
⚠ Và object-level logging phải bật riêng — chi tiết dễ bỏ sót:
CloudTrail mặc định chỉ ghi
MANAGEMENT event
↓
`PutObject` là DATA event
↓
Không bật → EventBridge không
bao giờ thấy gì
aws cloudtrail put-event-selectors --trail-name trail-chinh \
--advanced-event-selectors '[{
"Name": "Data event cua bucket nhay cam",
"FieldSelectors": [
{"Field": "eventCategory", "Equals": ["Data"]},
{"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
{"Field": "resources.ARN", "StartsWith":
["arn:aws:s3:::du-lieu-benh-nhan/"]}]}]'
Mẫu sự kiện EventBridge:
{"source": ["aws.s3"],
"detail-type": ["AWS API Call via CloudTrail"],
"detail": {
"eventSource": ["s3.amazonaws.com"],
"eventName": ["PutObject", "PutObjectAcl"],
"requestParameters": {
"x-amz-acl": ["public-read", "public-read-write"]}}}
Lambda sửa quyền:
import boto3, json
s3 = boto3.client('s3')
def xu_ly(event, context):
for ban_ghi in event['Records']:
tin = json.loads(ban_ghi['Sns']['Message'])
tham_so = tin['detail']['requestParameters']
s3.put_object_acl(
Bucket=tham_so['bucketName'],
Key=tham_so['key'],
ACL='private')
⚠ Và Lambda phải bóc hai lớp: SNS rồi mới tới sự kiện EventBridge:
EventBridge gửi sự kiện vào SNS
↓
SNS gói nó trong `Records[].Sns.Message`
↓
Message là chuỗi JSON
→ phải `json.loads` mới đọc được
⚠ Và vì sao phương án E sai — S3 event notification không có thông tin ACL:
E nói dùng S3 event notification
khi có PutObject với public-read
↓
S3 event notification KHÔNG lọc
được theo ACL
↓
Nó chỉ lọc theo tiền tố và
hậu tố khoá
→ không biết object công khai
hay không
⚠ Và vì sao phương án B sai — Trusted Advisor chạy theo lịch:
Trusted Advisor có kiểm tra
"S3 Bucket Permissions"
↓
Nhưng nó làm mới vài giờ một lần
↓
Và kiểm quyền BUCKET, không
kiểm từng OBJECT
↓
Đề đòi báo "ngay lập tức"
⚠ Và vì sao phương án D sai — Access Analyzer cũng không thời gian thực:
IAM Access Analyzer tìm tài nguyên
chia sẻ ra ngoài
↓
Phân tích chính sách, chạy định kỳ
↓
Không phát hiện từng lời gọi
PutObject
↓
Và nó không "gọi Lambda ngay khi
object công khai được tải lên"
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phản ứng trong vài giây | | | Báo người và sửa máy cùng lúc | | | Có dấu vết kiểm toán đầy đủ | |
⚠ Nhưng cần chống vòng lặp — Lambda gọi PutObjectAcl cũng sinh sự kiện:
"detail": {
"eventName": ["PutObject", "PutObjectAcl"],
"userIdentity": {
"arn": [{"anything-but": {"prefix":
"arn:aws:sts::111122223333:assumed-role/LambdaSuaQuyen"}}]}}
Không lọc: Lambda tự kích hoạt
chính nó
↓
Vòng lặp vô hạn
→ và hoá đơn Lambda tăng vọt
⚠ Và cách phòng ngừa vẫn tốt hơn nhiều:
aws s3control put-public-access-block \
--account-id 111122223333 \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true
Block Public Access ở cấp TÀI KHOẢN
↓
Object KHÔNG BAO GIỜ công khai
được
↓
Không cần phát hiện, không có
khoảng thời gian phơi ra
⚠ Và SCP cấm tắt lớp bảo vệ đó:
{"Effect": "Deny",
"Action": ["s3:PutAccountPublicAccessBlock",
"s3:PutBucketPublicAccessBlock"],
"Resource": "*"}
⚠ Và với dữ liệu PII thì Macie là lớp bổ trợ đáng có:
aws macie2 create-classification-job \
--job-type SCHEDULED \
--schedule-frequency '{"dailySchedule": {}}' \
--s3-job-definition '{"bucketDefinitions": [
{"accountId": "111122223333",
"buckets": ["du-lieu-benh-nhan"]}]}'
Macie nhận diện PII: tên, số bảo
hiểm y tế, số thẻ
↓
Và cảnh báo bucket công khai
chứa dữ liệu đó
Vì sao các phương án khác sai
- **E. Bật object-level logging và dùng S3 event notification kích hoạt Lambda gửi thông báo qua SNS — đây là phương án gần nhất và S3 event notification thật sự kích hoạt Lambda khi có object mới, nhưng nó không lọc được theo quyền ACL nên không biết object đó có công khai hay không.
- **B. Dùng Trusted Advisor kiểm quyền public-read và gọi Lambda gửi thông báo — Trusted Advisor chạy theo lịch và kiểm ở cấp bucket, không đáp ứng yêu cầu báo ngay lập tức.
- **D. Dùng Access Analyzer kiểm quyền public-read — Access Analyzer phân tích chính sách định kỳ, không phát hiện từng lời gọi API.
Ghi nhớ
⚠ Bốn cách phát hiện object S3 công khai — bảng phải thuộc: | Cách | Độ trễ | |---|---| | CloudTrail data event + EventBridge | vài giây | | Config rule + remediation | vài phút | | Access Analyzer | định kỳ | | Trusted Advisor | vài giờ |
Từ khoá nhận diện:
"notify immediately when public object created" → CloudTrail data event + EventBridge "prevent public objects entirely" → Block Public Access "find PII in buckets" → Macie "which resources are shared externally" → Access Analyzer
Ba lưu ý về CloudTrail data event: | Lưu ý | Chi tiết | |---|---| | KHÔNG ghi mặc định | | | Tính phí theo số bản ghi | | | Giới hạn phạm vi bằng advanced event selector | |
Ba lưu ý về SNS fan-out: | Lưu ý | Chi tiết | |---|---| | Một topic, nhiều đăng ký khác loại | | | Filter policy lọc tin cho từng đăng ký | | | DLQ cho đăng ký Lambda | |
⚠ Filter policy chia luồng ngay trong SNS:
{"detail": {"eventName": ["PutObject"]}}
Đăng ký email nhận mọi tin
↓
Đăng ký Lambda chỉ nhận PutObject
→ không cần lọc trong mã
Ba lưu ý về Block Public Access: | Cờ | Tác dụng | |---|---| | BlockPublicAcls | từ chối PUT có ACL công khai | | IgnorePublicAcls | bỏ qua ACL công khai đã có | | BlockPublicPolicy | từ chối bucket policy công khai | | RestrictPublicBuckets | chặn truy cập ẩn danh |
Ba lưu ý về Object Ownership: | Chế độ | Đặc điểm | |---|---| | Bucket owner enforced | ACL bị VÔ HIỆU HOÁ hoàn toàn | | Bucket owner preferred | object mới thuộc chủ bucket | | Object writer | người ghi sở hữu object |
⚠ Từ tháng 4/2023, bucket mới mặc định tắt ACL:
Bucket owner enforced là mặc định
↓
`x-amz-acl: public-read` bị
TỪ CHỐI
↓
Tình huống trong đề chỉ xảy ra
với bucket cũ, hoặc bucket đã
bật lại ACL
Ba lưu ý về chống vòng lặp: | Lưu ý | Chi tiết | |---|---| | Lọc theo userIdentity của Lambda | | | Hoặc kiểm trong mã và thoát sớm | | | Đặt reserved concurrency giới hạn thiệt hại | |
Ba lưu ý về tuân thủ y tế: | Lưu ý | Chi tiết | |---|---| | Mã hoá SSE-KMS với khoá riêng | | | Bật versioning và Object Lock | | | Ghi lại mọi truy cập bằng data event | |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải lên object với --acl public-read | | | Bấm giờ tới lúc nhận email và tới lúc ACL bị sửa | | | Kiểm Lambda không tự kích hoạt lại | |
Và một lời khuyên: hãy lọc bỏ chính vai trò của Lambda khắc phục ra khỏi mẫu sự kiện. Hàm sửa quyền cũng gọi một API S3, và nếu mẫu sự kiện không loại trừ nó thì bạn có một vòng lặp tự nuôi — chạy suốt đêm và chỉ phát hiện qua hoá đơn.
A leading Internet-of-Things (IoT) solutions company needs to develop a platform that would analyze real-time clickstream events from embedded sensors in consumer electronic devices. The company has hired you as an AWS Certified Solutions Architect Professional to consult the engineering team and develop a solution using the AWS Cloud. The company wants to use clickstream data to perform data science, develop algorithms, and create visualizations and dashboards to support the business stakeholders. Each of these groups would work independently and would need real-time access to this clickstream data for their applications.
Which of the following options would provide a highly available and fault-tolerant solution to capture the clickstream events from the source and also provide a simultaneous feed of the data stream to the downstream applications?
-
A
Use Amazon SQS to facilitate multiple applications process same streaming data concurrently and independently
-
B
Use AWS Kinesis Data Streams to facilitate multiple applications consume same streaming data concurrently and independently
-
C
Use AWS Kinesis Data Firehose to allow applications to consume the same streaming data concurrently and independently
-
D
Use AWS Kinesis Data Analytics to facilitate multiple applications consume and analyze same streaming data concurrently and independently
Xem giải thích
Đáp án
**B — Dùng Kinesis Data Streams để nhiều ứng dụng cùng tiêu thụ cùng một luồng dữ liệu đồng thời và độc lập.
Vì sao đúng
Đề nêu một yêu cầu rất đặc thù:
Ba nhóm làm việc ĐỘC LẬP:
- khoa học dữ liệu
- phát triển thuật toán
- trực quan hoá và bảng điều khiển
↓
Mỗi nhóm cần truy cập THỜI GIAN
THỰC vào CÙNG dữ liệu
↓
Cho ứng dụng riêng của họ
⚠ Điểm mấu chốt: chỉ Kinesis Data Streams cho nhiều consumer đọc CÙNG dữ liệu:
Dữ liệu nằm trong luồng cho tới
khi hết hạn giữ
↓
Mỗi consumer có con trỏ riêng
↓
Consumer A đọc bản ghi #100
→ không ảnh hưởng consumer B
⚠ Và đây là lý do SQS (phương án A) sai:
SQS: một tin nhắn được MỘT consumer
nhận rồi XOÁ
↓
Consumer thứ hai không thấy
tin đó nữa
↓
Muốn nhiều bên nhận: phải dựng
SNS → nhiều SQS
→ và vẫn không phát lại được
⚠ Và đây là bảng phân biệt căn bản: | Tiêu chí | SQS | Kinesis Data Streams | |---|---|---| | Sau khi xử lý | tin bị xoá | dữ liệu vẫn còn | | Nhiều consumer độc lập | KHÔNG | CÓ | | Phát lại | không | CÓ, tới 365 ngày | | Thứ tự | FIFO queue | theo shard |
Tạo luồng và đăng ký consumer:
aws kinesis create-stream --stream-name su-kien-clickstream \
--stream-mode-details StreamMode=ON_DEMAND
aws kinesis register-stream-consumer \
--stream-arn <arn-luong> --consumer-name khoa-hoc-du-lieu
aws kinesis register-stream-consumer \
--stream-arn <arn-luong> --consumer-name thuat-toan
aws kinesis register-stream-consumer \
--stream-arn <arn-luong> --consumer-name bang-dieu-khien
⚠ Enhanced Fan-Out cho mỗi consumer băng thông riêng:
Chế độ chia sẻ: 2 MB/s mỗi shard
chia cho MỌI consumer
↓
Ba nhóm → mỗi nhóm ~667 KB/s
↓
Enhanced Fan-Out: 2 MB/s riêng
cho mỗi consumer
→ không ai tranh với ai
⚠ Và độ trễ cũng giảm đáng kể: | Chế độ | Độ trễ điển hình | |---|---| | Chia sẻ (GetRecords) | ~200 ms | | Enhanced Fan-Out (SubscribeToShard) | ~70 ms |
⚠ Và vì sao phương án C (Firehose) sai:
Firehose là dịch vụ PHÂN PHỐI
↓
Nó ghi vào MỘT đích
↓
Không có khái niệm nhiều
consumer đọc độc lập
↓
Và độ trễ tối thiểu 60 giây
→ không phải thời gian thực
⚠ Và vì sao phương án D (Kinesis Data Analytics) sai:
KDA là công cụ XỬ LÝ luồng
↓
Nó ĐỌC từ KDS hoặc Firehose
↓
Nó không phải nơi nhận dữ liệu
từ nguồn
→ nó là một consumer, không
phải cái luồng
⚠ Và "sẵn sàng cao, chịu lỗi" là đặc tính có sẵn của KDS:
Dữ liệu tự sao chép đồng bộ sang
BA Availability Zone
↓
Mất một AZ không mất dữ liệu
↓
Không phải cấu hình gì
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ba nhóm đọc độc lập, không cản nhau | | | Phát lại được khi ứng dụng có lỗi | | | Sao chép ba AZ, chịu lỗi sẵn | |
⚠ Và khả năng phát lại rất quan trọng cho nhóm khoa học dữ liệu:
Thuật toán mới cần chạy lại trên
dữ liệu cũ
↓
Đặt lưu giữ 7 ngày
↓
Đọc lại từ đầu bằng
`TRIM_HORIZON`
→ không cần lưu trữ riêng
kinesis.get_shard_iterator(
StreamName='su-kien-clickstream',
ShardId='shardId-000000000000',
ShardIteratorType='AT_TIMESTAMP',
Timestamp=datetime(2026, 9, 1, 0, 0))
⚠ Và bốn kiểu shard iterator — phải nhớ: | Kiểu | Bắt đầu từ | |---|---| | LATEST | bản ghi mới nhất từ giờ trở đi | | TRIM_HORIZON | bản ghi cũ nhất còn giữ | | AT_TIMESTAMP | thời điểm cụ thể | | AFTER_SEQUENCE_NUMBER | sau một bản ghi cụ thể |
⚠ Và chế độ on-demand bỏ được việc quản shard:
aws kinesis update-stream-mode \
--stream-arn <arn> \
--stream-mode-details StreamMode=ON_DEMAND
Tự co giãn tới 200 MB/s vào và
400 MB/s ra
↓
Không phải resharding
→ nhưng đắt hơn provisioned khi
tải ổn định
⚠ Và khoá phân vùng quyết định phân bố:
Dùng mã thiết bị làm khoá
↓
Phân tán đều trên các shard
↓
Dùng loại thiết bị (chỉ vài
giá trị)
→ shard nóng, bị chặn
Vì sao các phương án khác sai
- **A. Dùng Amazon SQS để nhiều ứng dụng xử lý cùng dữ liệu luồng đồng thời và độc lập — đây là phương án gần nhất và SQS thật sự là dịch vụ nhắn tin có sẵn sàng cao, nhưng mỗi tin chỉ được một consumer nhận rồi bị xoá, nên nhiều ứng dụng không đọc được cùng dữ liệu.
- **C. Dùng Kinesis Data Firehose — dịch vụ phân phối tới một đích, không có nhiều consumer độc lập, và có độ trễ tối thiểu 60 giây.
- **D. Dùng Kinesis Data Analytics — công cụ xử lý luồng đọc TỪ Kinesis, không phải nơi nhận dữ liệu từ nguồn.
Ghi nhớ
⚠ Bốn dịch vụ luồng và mô hình tiêu thụ — bảng phải thuộc: | Dịch vụ | Nhiều consumer độc lập | |---|---| | Kinesis Data Streams | CÓ | | MSK (Kafka) | CÓ (consumer group) | | SNS → nhiều SQS | có, nhưng không phát lại | | SQS một mình | KHÔNG | | Firehose | KHÔNG |
Từ khoá nhận diện:
"multiple applications consume same data independently" → Kinesis Data Streams "replay data" → Kinesis hoặc MSK "one message one worker" → SQS "deliver to S3/Redshift with least ops" → Firehose
Ba giới hạn của shard: | Chiều | Giới hạn | |---|---| | Ghi | 1 MB/s hoặc 1.000 bản ghi/giây | | Đọc chia sẻ | 2 MB/s, 5 GetRecords/giây | | Đọc EFO | 2 MB/s mỗi consumer |
Ba lưu ý về Enhanced Fan-Out: | Lưu ý | Chi tiết | |---|---| | Tối đa 20 consumer đăng ký mỗi luồng | | | Dùng SubscribeToShard, HTTP/2 push | | | Tính phí theo consumer-shard-giờ + GB | |
Ba lưu ý về lưu giữ: | Lưu ý | Chi tiết | |---|---| | Mặc định 24 giờ | | | Nâng tới 365 ngày | | | Trên 7 ngày tính phí lưu trữ mở rộng | |
Ba lưu ý về consumer: | Lựa chọn | Đặc điểm | |---|---| | Lambda | đơn giản nhất, hỗ trợ EFO | | KCL | tự quản checkpoint và cân bằng shard | | Managed Flink | xử lý luồng bằng SQL hoặc Java |
⚠ KCL lưu checkpoint vào DynamoDB:
Mỗi ứng dụng KCL có một bảng
DynamoDB riêng
↓
Lưu vị trí đọc của từng shard
↓
Nhớ cấp thông lượng cho bảng đó
→ nó cũng bị chặn được
Ba chỉ số cần theo dõi: | Chỉ số | Ý nghĩa | |---|---| | IteratorAgeMilliseconds | consumer tụt lại bao xa | | WriteProvisionedThroughputExceeded | ghi bị chặn | | ReadProvisionedThroughputExceeded | đọc bị chặn |
Ba lưu ý về khoá phân vùng: | Lưu ý | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | | | Độ phân tán cao để tránh shard nóng | | | Cùng khoá thì cùng shard, giữ thứ tự | |
Ba lưu ý về chi phí: | Chế độ | Cách tính | |---|---| | Provisioned | shard-giờ + PUT payload unit | | On-demand | theo GB vào và ra | | EFO | consumer-shard-giờ + GB |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy hai consumer và xác nhận cả hai thấy cùng bản ghi | | | Đo IteratorAge của từng consumer | | | Thử phát lại từ TRIM_HORIZON | |
Và một lời khuyên: hãy đặt thời gian lưu giữ dài hơn mức bạn nghĩ là cần. Khả năng phát lại chính là thứ phân biệt Kinesis với một hàng đợi — và giá trị của nó chỉ lộ ra vào ngày một trong ba nhóm phát hiện thuật toán của họ đã tính sai suốt bốn ngày qua.
A healthcare company has migrated some of its IT infrastructure to AWS Cloud and is looking for a solution to enable real-time data transfer between AWS and its data centers to reduce the turnaround time to generate the patients' diagnostic reports. The company wants to build a patient results archival solution such that only the most frequently accessed results are available as cached data locally while backing up all results on Amazon S3.
As a Solutions Architect Professional, which of the following solutions would you recommend for this use-case?
-
A
Use AWS Volume Gateway - Stored Volume - to store the most frequently accessed results locally for low-latency access while storing the full volume with all results in its Amazon S3 service bucket
-
B
Use AWS Snowball Edge Storage Optimized device to store the most frequently accessed results locally for low-latency access while storing the full backup of results in an Amazon S3 bucket
-
C
Use AWS Volume Gateway - Cached Volume - to store the most frequently accessed results locally for low-latency access while storing the full volume with all results in its Amazon S3 service bucket
-
D
Use AWS direct connect to store the most frequently accessed results locally for low-latency access while storing the full backup of results in an Amazon S3 bucket
Xem giải thích
Đáp án
**C — Dùng AWS Volume Gateway ở chế độ Cached Volume để giữ kết quả được truy cập nhiều nhất tại chỗ cho độ trễ thấp, trong khi toàn bộ volume với mọi kết quả nằm trong bucket S3 do dịch vụ quản lý.
Vì sao đúng
Đề mô tả chính xác định nghĩa của cached volume:
"CHỈ kết quả được truy cập thường
xuyên nhất có sẵn dưới dạng dữ
liệu cache tại chỗ"
↓
"TOÀN BỘ kết quả được sao lưu
trên Amazon S3"
↓
Đó là mô tả từng chữ của chế độ
Cached Volume
⚠ Điểm mấu chốt: hai chế độ của Volume Gateway ngược nhau về nơi lưu dữ liệu CHÍNH: | Chế độ | Dữ liệu chính ở | Cache ở | |---|---|---| | Cached Volume | S3 | đĩa cục bộ (phần nóng) | | Stored Volume | đĩa cục bộ (TOÀN BỘ) | không có — S3 chỉ là snapshot |
Cached: dung lượng gần như vô hạn
↓
Chỉ giữ phần nóng tại chỗ
↓
Stored: phải có đủ đĩa cục bộ
cho TOÀN BỘ dữ liệu
→ S3 chỉ là bản sao lưu
⚠ Đây là lý do phương án A sai:
Stored Volume giữ TOÀN BỘ dữ liệu
tại chỗ
↓
Không phải "chỉ phần được truy
cập nhiều nhất"
↓
Và không giải quyết được bài
toán dung lượng
Tạo cached volume:
aws storagegateway create-cachedi-scsi-volume \
--gateway-arn <arn-gateway> \
--volume-size-in-bytes 10995116277760 \
--target-name ket-qua-chan-doan \
--network-interface-id 192.168.1.50 \
--client-token $(uuidgen)
⚠ Và gateway cần hai loại đĩa cục bộ riêng biệt: | Đĩa | Vai trò | |---|---| | Cache | giữ dữ liệu nóng, phục vụ đọc nhanh | | Upload buffer | đệm dữ liệu vừa ghi trước khi lên S3 |
Thiếu upload buffer
↓
Gateway không nhận thêm lệnh ghi
↓
Ứng dụng bị treo
⚠ Và Volume Gateway phơi giao thức iSCSI — không phải NFS:
Cached volume xuất hiện với máy
chủ như một ĐĨA
↓
Định dạng, phân vùng, mount
như đĩa thường
↓
Khác với File Gateway (NFS/SMB)
⚠ Và bốn kiểu Storage Gateway — phải phân biệt: | Kiểu | Giao thức | Đích trên AWS | |---|---|---| | S3 File Gateway | NFS, SMB | object S3 đọc được | | FSx File Gateway | SMB | FSx for Windows | | Volume Gateway | iSCSI | snapshot EBS trong S3 do AWS quản | | Tape Gateway | iSCSI VTL | S3 Glacier |
⚠ Và vì sao phương án B sai — Snowball không phải thiết bị thường trực:
Snowball Edge là thiết bị MƯỢN
tạm thời
↓
Dùng để chuyển dữ liệu một lần
↓
Không phải giải pháp lưu trữ
lai chạy liên tục
↓
Và không có cơ chế đồng bộ với
S3 theo thời gian thực
⚠ Và vì sao phương án D sai — Direct Connect chỉ là đường truyền:
Direct Connect là kết nối mạng
↓
Nó không LƯU dữ liệu ở đâu cả
↓
Không có cache, không có tầng
lưu trữ
→ chỉ là ống dẫn
Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dung lượng gần như vô hạn trên S3 | | | Truy cập phần nóng nhanh như đĩa cục bộ | | | Snapshot lên S3 tự động | |
⚠ Và snapshot của cached volume dựng lại thành EBS được:
aws storagegateway create-snapshot \
--volume-arn <arn-volume> \
--snapshot-description "sao luu hang ngay"
aws ec2 create-volume --snapshot-id snap-abc \
--availability-zone ap-southeast-1a --volume-type gp3
Snapshot nằm trong EBS snapshot
↓
Dựng thành volume EBS gắn vào
EC2
↓
Đây là con đường khôi phục thảm
hoạ lên đám mây
⚠ Và kích thước cache quyết định hiệu năng:
Cache nhỏ hơn tập dữ liệu nóng
↓
Liên tục kéo dữ liệu từ S3
↓
Độ trễ tăng vọt
↓
AWS khuyến nghị cache tối thiểu
150 GB, và bằng ít nhất 20%
dữ liệu nóng
⚠ Và hai chỉ số phải theo dõi: | Chỉ số | Ý nghĩa | |---|---| | CachePercentUsed | cache sắp đầy chưa | | CachePercentDirty | bao nhiêu dữ liệu chưa lên S3 |
`CachePercentDirty` cao
↓
Dữ liệu đã ghi nhưng chưa lên
đám mây
↓
Gateway hỏng lúc này là MẤT
phần đó
→ thường do băng thông lên
không đủ
⚠ Và giới hạn dung lượng của Volume Gateway: | Giới hạn | Giá trị | |---|---| | Kích thước một volume (cached) | tối đa 32 TB | | Số volume mỗi gateway (cached) | 32 | | Tổng dung lượng (cached) | 1 PB |
Vì sao các phương án khác sai
- **A. Dùng Volume Gateway ở chế độ Stored Volume — đây là phương án gần nhất và chỉ khác đáp án đúng ở một từ, nhưng chế độ stored giữ toàn bộ dữ liệu trên đĩa cục bộ và chỉ sao lưu lên S3, ngược với yêu cầu "chỉ giữ phần nóng tại chỗ".
- **B. Dùng Snowball Edge Storage Optimized làm nơi lưu phần nóng — Snowball là thiết bị mượn tạm để chuyển dữ liệu, không phải giải pháp lưu trữ lai thường trực.
- **D. Dùng Direct Connect để lưu phần nóng tại chỗ — Direct Connect là kết nối mạng, không lưu trữ dữ liệu.
Ghi nhớ
⚠ Hai chế độ Volume Gateway — bảng phải thuộc: | Tiêu chí | Cached | Stored | |---|---|---| | Dữ liệu chính | S3 | đĩa cục bộ | | Dung lượng tối đa mỗi volume | 32 TB | 16 TB | | Cần đĩa cục bộ bằng toàn bộ dữ liệu | KHÔNG | CÓ | | Độ trễ đọc phần nguội | cao hơn | thấp (luôn cục bộ) |
Từ khoá nhận diện:
"only frequently accessed data locally" → Cached Volume "entire dataset locally, backup to cloud" → Stored Volume "NFS/SMB file share backed by S3" → File Gateway "backup software writing to tape" → Tape Gateway
Ba lưu ý về Volume Gateway: | Lưu ý | Chi tiết | |---|---| | Phơi iSCSI, không phải NFS/SMB | | | Cần đĩa cache và upload buffer riêng | | | Dữ liệu trên S3 ở dạng snapshot EBS, không đọc trực tiếp | |
⚠ Điểm cuối là khác biệt lớn so với File Gateway:
File Gateway: mỗi tệp là một object
S3 đọc được bằng API
↓
Volume Gateway: snapshot EBS
→ chỉ khôi phục thành volume
mới đọc được
↓
Cần phân tích dữ liệu trên đám
mây → File Gateway
Ba lưu ý về triển khai gateway: | Lưu ý | Chi tiết | |---|---| | Chạy trên VMware, Hyper-V, KVM, EC2, hoặc thiết bị phần cứng | | | Cần cổng 443 ra AWS | | | Có bản Hardware Appliance của AWS | |
Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Băng thông lên AWS là nút thắt chính | | | Cache đủ lớn giữ tỷ lệ hit cao | | | Đĩa SSD cho cache tốt hơn HDD | |
Ba lưu ý về khôi phục thảm hoạ: | Bước | Chi tiết | |---|---| | Snapshot tự động theo lịch | | | Dựng volume EBS từ snapshot | | | Gắn vào EC2 để chạy trên đám mây | |
⚠ Đây là mẫu pilot light rất gọn:
Trung tâm dữ liệu mất hoàn toàn
↓
Snapshot mới nhất đã ở S3
↓
Dựng EBS + EC2 trên AWS
→ hệ thống chạy lại trên đám mây
Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá khi truyền bằng TLS | | | Snapshot mã hoá bằng KMS | | | CHAP authentication cho iSCSI | |
Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | CachePercentUsed | cache đầy chưa | | CachePercentDirty | dữ liệu chưa lên S3 | | CloudBytesUploaded | tốc độ đẩy lên đám mây |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một tệp và kiểm CachePercentDirty giảm về 0 | | | Đọc dữ liệu nguội và đo độ trễ | | | Dựng thử volume EBS từ snapshot | |
Và một lời khuyên: hãy theo dõi CachePercentDirty chứ đừng chỉ nhìn CachePercentUsed. Cache còn chỗ trống mà tỷ lệ dirty cao nghĩa là dữ liệu đang ứ lại chưa kịp lên S3 — và đó chính xác là phần kết quả chẩn đoán sẽ mất nếu thiết bị hỏng.