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

Đáp án

A và C.

• A — Amazon S3
• C — Amazon Redshift

Vì sao đúng

Đề hỏi consumer của Kinesis Data Streams lưu kết quả xử lý ở đâu — và câu trả lời phải là các dịch vụ LƯU TRỮ dữ liệu.

Hai đích này là nơi lưu trữ thật sự: | Đích | Vai trò | |---|---| | Amazon S3 | kho object — lưu trữ bền vững, rẻ, quy mô không giới hạn | | Amazon Redshift | kho dữ liệu — phân tích SQL trên khối lượng lớn |

Và chúng là hai đích chuẩn của đường ống dữ liệu tài chính:

Kinesis Data Streams
    ├─▶ S3        → lưu dữ liệu thô, phân tích sau bằng Athena
    └─▶ Redshift  → dữ liệu đã tổng hợp cho báo cáo và dashboard

Đây cũng chính là hai đích mà Kinesis Data Firehose hỗ trợ gốc:

aws firehose create-delivery-stream   --delivery-stream-name luu-du-lieu-chung-khoan   --delivery-stream-type KinesisStreamAsSource   --kinesis-stream-source-configuration     KinesisStreamARN=<arn-stream>,RoleARN=<arn-role>   --s3-destination-configuration     RoleARN=<arn-role>,BucketARN=arn:aws:s3:::kho-du-lieu-chung-khoan

Và mẫu kiến trúc điển hình dùng cả hai:

S3       → dữ liệu thô, giữ lâu dài, chi phí thấp (data lake)
Redshift → dữ liệu đã làm sạch và tổng hợp, phục vụ truy vấn nhanh

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

• **E. Amazon Athena — đây là phương án gần nhất và thường xuất hiện cùng S3 trong kiến trúc phân tích, nhưng nó không phải nơi LƯU dữ liệu: Athena là công cụ TRUY VẤN chạy SQL trên dữ liệu đã nằm trong S3. Nó không có tầng lưu trữ riêng.
• **D. AWS Glue — cũng không phải kho lưu trữ: Glue là dịch vụ ETL và kho METADATA (Data Catalog). Nó biến đổi và mô tả dữ liệu, nhưng dữ liệu vẫn nằm ở S3 hoặc nơi khác.
• **B. Glacier Select — là tính năng TRUY VẤN, không phải đích lưu: nó cho phép chạy SQL trên dữ liệu đã lưu trữ trong Glacier. Và Glacier không phải nơi ghi trực tiếp từ consumer của một luồng thời gian thực — nó dành cho lưu trữ dài hạn.

Ghi nhớ

Phân biệt ba loại dịch vụ trong kiến trúc dữ liệu: | Loại | Ví dụ | Việc | |---|---|---| | LƯU TRỮ | S3, Redshift, DynamoDB, RDS, OpenSearch | giữ dữ liệu | | TRUY VẤN | Athena, Redshift Spectrum, Glacier Select | đọc và phân tích | | XỬ LÝ / ETL | Glue, EMR, Lambda, Flink | biến đổi dữ liệu |

Câu hỏi dạng "nơi lưu kết quả" luôn tìm nhóm đầu.

Các đích mà Kinesis Data Firehose hỗ trợ GỐC: | Đích | Ghi chú | |---|---| | Amazon S3 | phổ biến nhất | | Amazon Redshift | qua S3 rồi COPY vào | | Amazon OpenSearch Service | tìm kiếm và dashboard | | Splunk | công cụ của bên thứ ba | | HTTP endpoint tuỳ chỉnh | Datadog, New Relic, MongoDB | | Apache Iceberg tables | định dạng bảng mở |

Và với Kinesis Data Streams, consumer tự viết thì ghi được đi bất cứ đâu — DynamoDB, RDS, ElastiCache, hoặc gọi API bên ngoài.

Data Streams và Firehose — chọn đúng: | | Data Streams | Firehose | |---|---|---| | Bạn viết consumer | ✅ CÓ | ❌ không cần | | Phát lại (replay) | ✅ 1–365 ngày | ❌ | | Nhiều consumer độc lập | ✅ | ❌ | | Độ trễ | mili giây | tối thiểu ~60 giây | | Đích | tuỳ bạn | danh sách cố định |

Kiến trúc đầy đủ cho phân tích chứng khoán thời gian thực:

Producer (dữ liệu thị trường)
    ↓
Kinesis Data Streams
    ├─▶ Managed Service for Apache Flink → phân tích cửa sổ thời gian thực
    │        ↓
    │   Dashboard, cảnh báo giá
    ├─▶ Firehose → S3 (dữ liệu thô, giữ lâu dài)
    └─▶ Firehose → Redshift (dữ liệu tổng hợp cho báo cáo)

Ba cách viết consumer cho Kinesis Data Streams: | Cách | Đặc điểm | |---|---| | Lambda (event source mapping) | đơn giản nhất, tự mở rộng, đọc theo lô | | Kinesis Client Library (KCL) | quản lý checkpoint và cân bằng shard tự động | | API GetRecords trực tiếp | kiểm soát cao nhất, phải tự lo mọi thứ |

KCL đáng biết cho ứng dụng phức tạp: nó tự phân chia shard giữa các worker, tự lưu checkpoint vào DynamoDB, và tự cân bằng lại khi worker thêm hoặc chết.

Ba tối ưu khi ghi vào S3 từ luồng dữ liệu: | Tối ưu | Lợi ích | |---|---| | Gom bản ghi thành tệp LỚN | hàng triệu tệp nhỏ làm Athena và EMR rất chậm | | Chuyển sang Parquet ngay trong Firehose | giảm 80–90% dữ liệu quét về sau | | Phân vùng theo thời gian | nam=2026/thang=08/ngay=30/ |

Firehose làm được cả ba việc trên tự động:

{"DataFormatConversionConfiguration": {
   "Enabled": true,
   "OutputFormatConfiguration": {"Serializer": {"ParquetSerDe": {}}}},
 "BufferingHints": {"SizeInMBs": 128, "IntervalInSeconds": 300},
 "DynamicPartitioningConfiguration": {"Enabled": true}}

Ba lưu ý khi ghi vào Redshift: | Lưu ý | Chi tiết | |---|---| | Firehose ghi qua S3 rồi COPY | cần bucket trung gian | | COPY hiệu quả hơn INSERT rất nhiều | đừng ghi từng dòng | | Chọn distribution key và sort key phù hợp | quyết định hiệu năng truy vấn |

Với dữ liệu chứng khoán, sort key theo thời gian là lựa chọn tự nhiên — hầu hết truy vấn đều lọc theo khoảng thời gian.

Và một lưu ý về việc giữ dữ liệu: Kinesis Data Streams giữ bản ghi tối đa 365 ngày, nhưng chi phí giữ dài tăng đáng kể. Mẫu chuẩn là giữ ngắn trong Kinesis (24 giờ đến 7 ngày) đủ để phát lại khi consumer lỗi, còn lưu trữ dài hạn thì đẩy sang S3 — nơi rẻ hơn hàng chục lần và vẫn truy vấn được bằng Athena.

Đáp án

A — Amazon Aurora.

Vì sao đúng

Đề nêu bốn yêu cầu, và Aurora đáp ứng tốt nhất cả bốn: | Yêu cầu | Cơ chế | |---|---| | Hơn 50 TB và CÒN TĂNG | lưu trữ tự mở rộng tới 128 TB, không cần cấp phát trước | | Tải giao dịch cao (OLTP) | tối ưu cho OLTP, nhanh hơn MySQL tiêu chuẩn tới 5 lần | | Tuân thủ ACID | cơ sở dữ liệu quan hệ đầy đủ | | Truy vấn phức tạp | SQL đầy đủ, tương thích MySQL hoặc PostgreSQL |

Điểm mạnh quyết định ở đây là khả năng mở rộng lưu trữ:

RDS thông thường:
    → phải CẤP PHÁT dung lượng trước
    → tối đa 64 TB
    → hết chỗ thì phải can thiệp (dù có storage autoscaling)

Aurora:
    → lưu trữ TỰ mở rộng theo mức tăng 10 GB
    → tới 128 TB
    → KHÔNG cần cấp phát, không cần theo dõi

Và kiến trúc lưu trữ của Aurora khác hẳn RDS:

Tầng compute và tầng storage TÁCH RỜI
    → 6 bản sao dữ liệu trải qua 3 AZ
    → chịu được mất 2 bản mà không mất khả năng ghi
    → chịu được mất 3 bản mà vẫn đọc được
    → tự sửa lỗi đĩa trong nền

Với "dữ liệu người tiêu dùng" 50 TB và đang tăng, đây là khác biệt thực tế lớn nhất — bạn không phải lo về dung lượng nữa.

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

• **D. Amazon RDS — đây là phương án gần nhất và cũng là cơ sở dữ liệu quan hệ ACID hỗ trợ truy vấn phức tạp, nhưng nó thua Aurora ở hai điểm quan trọng cho quy mô này: giới hạn 64 TB (đề nói 50 TB và còn tăng), và phải cấp phát dung lượng trước. Aurora là lựa chọn tốt hơn ở mọi tiêu chí mà đề nêu.
• **C. Amazon DynamoDB — sai loại cơ sở dữ liệu cho yêu cầu này: DynamoDB là NoSQL khoá–giá trị, không hỗ trợ truy vấn phức tạp (không JOIN, không tổng hợp phức tạp). Nó có giao dịch ACID nhưng phạm vi hạn chế. Và di chuyển từ cơ sở dữ liệu quan hệ tại chỗ sang DynamoDB đòi viết lại toàn bộ mô hình dữ liệu và ứng dụng.
• **B. Amazon Redshift — sai loại workload: Redshift là kho dữ liệu tối ưu cho OLAP (phân tích, quét lượng lớn dữ liệu). Đề nói rõ tải là OLTP (nhiều giao dịch nhỏ, đọc ghi thường xuyên) — Redshift xử lý mẫu đó rất kém.

Ghi nhớ

OLTP và OLAP — bảng phân biệt cốt lõi: | | OLTP | OLAP | |---|---|---| | Mẫu truy cập | nhiều giao dịch NHỎ | ít truy vấn LỚN | | Thao tác | INSERT, UPDATE, DELETE nhiều | chủ yếu SELECT tổng hợp | | Ví dụ | đặt hàng, thanh toán, đăng ký | báo cáo doanh thu, phân tích xu hướng | | Dịch vụ AWS | RDS, Aurora, DynamoDB | Redshift, Athena, EMR | | Lưu trữ | theo dòng | theo cột |

Từ khoá nhận diện trong đề thi:

"transactional", "OLTP", "ACID", "complex queries" → Aurora hoặc RDS "data warehouse", "OLAP", "analytics", "petabyte" → Redshift "key-value", "millisecond latency", "massive scale" → DynamoDB

Aurora và RDS — bảng so sánh: | | Aurora | RDS | |---|---|---| | Lưu trữ tối đa | 128 TB | 64 TB | | Cấp phát dung lượng | TỰ ĐỘNG mở rộng | phải khai trước (có autoscaling) | | Read replica | tới 15, độ trễ mili giây | tối đa 5, độ trễ giây | | Failover | dưới 30 giây, tự động | 60–120 giây | | Sao chép dữ liệu | 6 bản qua 3 AZ | 1 standby (Multi-AZ) | | Hiệu năng | tới 5× MySQL, 3× PostgreSQL | tiêu chuẩn | | Engine hỗ trợ | MySQL, PostgreSQL | thêm MariaDB, Oracle, SQL Server | | Chi phí | cao hơn một chút | thấp hơn |

Khi nào vẫn chọn RDS thay vì Aurora: | Trường hợp | Lý do | |---|---| | Cần Oracle hoặc SQL Server | Aurora không hỗ trợ | | Cần MariaDB | Aurora không hỗ trợ | | Cơ sở dữ liệu nhỏ, chi phí là ưu tiên | RDS rẻ hơn |

Ba tính năng của Aurora đáng biết cho khối lượng lớn: | Tính năng | Việc | |---|---| | Aurora Serverless v2 | tự co giãn compute theo tải, không gián đoạn | | Aurora Global Database | sao chép sang Region khác, độ trễ dưới 1 giây | | Backtrack | quay ngược cả cluster tới 72 giờ — chữa lỗi do người | | Parallel Query | đẩy xử lý xuống tầng lưu trữ cho truy vấn phân tích |

Backtrack rất hữu ích cho dữ liệu người tiêu dùng: lỡ chạy DELETE thiếu WHERE thì quay ngược trong vài phút, thay vì khôi phục snapshot mất hàng giờ với 50 TB.

Ba lưu ý khi di chuyển 50 TB lên Aurora: | Lưu ý | Chi tiết | |---|---| | Dùng AWS DMS với chế độ CDC | thời gian ngừng chỉ vài phút | | Dùng SCT nếu đổi engine | chuyển lược đồ, stored procedure | | Kiểm thử hiệu năng trước khi cắt chuyển | kế hoạch thực thi có thể khác engine cũ |

Với 50 TB, hãy cân nhắc cách nạp dữ liệu ban đầu:

Nếu nguồn là MySQL/PostgreSQL:
    → khôi phục từ backup vào Aurora (nhanh hơn DMS full load rất nhiều)
    → rồi dùng DMS CDC để bắt kịp phần thay đổi

Ba yếu tố quyết định chi phí Aurora: | Yếu tố | Chi tiết | |---|---| | Instance (compute) | theo giờ, giảm được bằng Reserved Instance | | Lưu trữ | ~0,10 USD/GB-tháng — 50 TB là ~5.000 USD/tháng | | I/O | tính theo số request — có thể lớn hơn cả compute |

Aurora I/O-Optimized đáng cân nhắc cho tải giao dịch cao:

Cấu hình I/O-Optimized:
    → KHÔNG tính phí I/O
    → giá lưu trữ và compute cao hơn khoảng 25%
    → có lợi khi chi phí I/O vượt 25% tổng hoá đơn

Với ứng dụng OLTP nhiều giao dịch như đề mô tả, đây thường là lựa chọn rẻ hơn — và nó cũng khiến hoá đơn dự đoán được, không biến động theo lưu lượng.

Và một lời khuyên về kiến trúc lai mà đề nhắc tới: nếu ứng dụng còn chạy tại chỗ trong giai đoạn chuyển tiếp, hãy đảm bảo có Direct Connect hoặc VPN với băng thông đủ, và kiểm tra độ trễ mạng tới Aurora. Cơ sở dữ liệu OLTP rất nhạy với độ trễ — mỗi truy vấn thêm 20 mili giây sẽ cảm nhận rõ nếu ứng dụng gọi hàng chục truy vấn cho một thao tác người dùng.

Đáp án

A — Triển khai ứng dụng lên Amazon EKS; tạo node group trong Wavelength Zone qua dịch vụ AWS Wavelength; áp dụng aws-auth ConfigMap cho cụm.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp chính xác cả ba: | Yêu cầu | Cơ chế | |---|---| | Chạy ở BIÊN của mạng 5G, độ trễ MILI GIÂY một chữ số | AWS Wavelength Zone đặt trong hạ tầng nhà mạng | | Triển khai lên cụm Kubernetes | Amazon EKS | | RBAC gắn với IAM user và role | aws-auth ConfigMap — cơ chế CHUẨN của EKS |

AWS Wavelength là gì và vì sao nó cho độ trễ thấp như vậy:

Wavelength Zone = hạ tầng AWS đặt NGAY TRONG trung tâm dữ liệu của nhà mạng 5G
    ↓
Dữ liệu từ thiết bị 5G:
    thiết bị → trạm phát 5G → Wavelength Zone
        → KHÔNG đi ra Internet
        → KHÔNG về Region
    → độ trễ MILI GIÂY MỘT CHỮ SỐ

So với kiến trúc thông thường:

Thông thường: thiết bị → 5G → Internet → Region AWS → ~50–100 mili giây
Wavelength:   thiết bị → 5G → Wavelength Zone       → dưới 10 mili giây

Với ứng dụng chẩn đoán y tế dùng học máy, khác biệt đó có ý nghĩa thực sự.

Và aws-auth ConfigMap là cơ chế chuẩn ánh xạ danh tính IAM sang RBAC của Kubernetes:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::123456789012:role/vai-tro-node
      username: system:node:{{EC2PrivateDNSName}}
      groups: [system:bootstrappers, system:nodes]
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/bac-si-truong
      username: bac-si-truong
      groups: [system:masters]

Cách nó hoạt động:

Người dùng chạy kubectl
    → xác thực bằng token IAM
    → EKS tra aws-auth ConfigMap để biết ánh xạ sang username và group nào
    → RBAC của Kubernetes quyết định họ làm được gì

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

• **C. Tạo VPC endpoint cho Wavelength Zone và cài aws-iam-authenticator vào cụm — đây là phương án gần nhất về mặt cũng nhắc tới Wavelength và xác thực IAM, nhưng nó sai ở hai chỗ: Wavelength không hoạt động qua VPC endpoint — bạn mở rộng VPC vào Wavelength Zone bằng cách tạo subnet ở đó. Và aws-iam-authenticator đã được TÍCH HỢP SẴN trong EKS — không phải cài thêm.
• **B. Gắn AmazonECSConnectorAgentRole và dùng AWS Control Tower cho RBAC — sai cả hai: AmazonECSConnectorAgentRole là vai trò của ECS Anywhere, không liên quan tới EKS. Và Control Tower quản trị đa tài khoản, nó không cấu hình RBAC của Kubernetes.
• **D. Chạy pod trên AWS Fargate trong Wavelength Zone — không dựng được: Fargate KHÔNG hỗ trợ Wavelength Zone. Wavelength chỉ chạy được với node EC2. Và vế "Fargate profile phải có cùng IAM role với node group EC2" là mô tả sai — hai thứ đó dùng role khác nhau.

Ghi nhớ

Ba dịch vụ biên của AWS — bảng phân biệt: | Dịch vụ | Vị trí | Dùng cho | |---|---|---| | AWS Wavelength | trong mạng 5G của nhà mạng | ứng dụng di động cần độ trễ cực thấp ← câu này | | AWS Local Zones | trong thành phố lớn, gần người dùng | game, streaming, dựng phim | | AWS Outposts | trong trung tâm dữ liệu CỦA BẠN | dữ liệu phải ở tại chỗ, hệ thống lai |

Từ khoá nhận diện:

"5G", "carrier network", "mobile edge" → Wavelength "single-digit millisecond in a metro area" → Local Zones "on-premises", "data residency" → Outposts

Ba khái niệm của Wavelength: | Khái niệm | Ý nghĩa | |---|---| | Wavelength Zone | vùng hạ tầng AWS trong mạng nhà mạng | | Carrier gateway | cổng kết nối giữa Wavelength Zone và mạng 5G | | Carrier IP | địa chỉ IP mà thiết bị 5G dùng để gọi tới ứng dụng |

Cách mở rộng VPC vào Wavelength Zone:

# Chọn nhóm vùng biên
aws ec2 modify-availability-zone-group   --group-name us-east-1-wl1 --opt-in-status opted-in

# Tạo subnet trong Wavelength Zone
aws ec2 create-subnet --vpc-id vpc-0abc123   --cidr-block 10.0.10.0/24   --availability-zone us-east-1-wl1-bos-wlz-1

# Tạo carrier gateway
aws ec2 create-carrier-gateway --vpc-id vpc-0abc123

Ba giới hạn của Wavelength Zone cần biết: | Giới hạn | Chi tiết | |---|---| | Chỉ một số dịch vụ AWS có mặt | EC2, EBS, VPC, EKS, ECS — KHÔNG có Fargate | | Chỉ một số loại instance | thường là các loại phổ biến, có cả loại có GPU | | Thiết bị phải trên mạng của nhà mạng đối tác | Verizon, Vodafone, KDDI, SK Telecom... |

Dòng đầu là lý do phương án D sai.

Hai cơ chế quản lý quyền truy cập EKS: | Cơ chế | Đặc điểm | |---|---| | aws-auth ConfigMap | cách truyền thống, phổ biến nhất ← câu này | | EKS access entries | cách mới hơn, quản lý qua API thay vì sửa ConfigMap |

Access entries là cải tiến đáng chú ý:

aws eks create-access-entry --cluster-name cum-y-te   --principal-arn arn:aws:iam::123456789012:role/vai-tro-bac-si   --type STANDARD

Ưu điểm: không phải sửa ConfigMap bằng tay (thao tác dễ gây lỗi và có thể khoá chính mình ra khỏi cụm), quản lý được bằng IaC, và có API để kiểm toán.

Ba cấu hình bảo mật quan trọng cho EKS: | Cấu hình | Việc | |---|---| | IRSA (IAM Roles for Service Accounts) | mỗi pod có quyền IAM riêng, tối thiểu | | aws-auth hoặc access entries | ánh xạ IAM sang RBAC cho con người | | Network policy | kiểm soát pod nào gọi được pod nào | | Quét image trong ECR | phát hiện lỗ hổng trước khi triển khai |

IRSA và aws-auth giải quyết hai vấn đề khác nhau:

aws-auth  → CON NGƯỜI dùng kubectl truy cập cụm
IRSA      → POD gọi dịch vụ AWS (S3, DynamoDB...)

Ba lưu ý khi triển khai ứng dụng y tế ở biên: | Lưu ý | Chi tiết | |---|---| | Wavelength Zone không có sẵn dự phòng đa AZ | cần thiết kế dự phòng ở Region | | Dữ liệu bệnh nhân phải mã hoá | và tuân thủ HIPAA — kiểm tra dịch vụ đủ điều kiện | | Cân nhắc xử lý gì ở biên, gì ở Region | suy luận mô hình ở biên, huấn luyện ở Region |

Dòng cuối là mẫu kiến trúc chuẩn cho học máy ở biên:

Region:          huấn luyện mô hình (cần GPU lớn, dữ liệu tập trung)
    ↓ triển khai mô hình đã huấn luyện
Wavelength Zone: suy luận thời gian thực (cần độ trễ thấp)

Và một lưu ý về tính sẵn sàng: Wavelength Zone không có nhiều AZ, nên một sự cố ở đó làm mất dịch vụ tại khu vực đó. Kiến trúc an toàn cho ứng dụng y tế nên có đường lui về Region — nếu Wavelength Zone không phản hồi, client tự chuyển sang endpoint ở Region với độ trễ cao hơn nhưng vẫn hoạt động.

Đáp án

D — AWS Glue.

Vì sao đúng

Đề hỏi thẳng: dịch vụ nào làm ETL (extract, transform, load) — và Glue là dịch vụ ETL được quản lý của AWS.

Bốn thành phần của Glue: | Thành phần | Việc | |---|---| | ETL job | biến đổi dữ liệu bằng Spark hoặc Python shell | | Crawler | tự phát hiện lược đồ, cập nhật Data Catalog | | Data Catalog | kho metadata dùng chung với Athena, Redshift Spectrum, EMR | | Job bookmark | theo dõi dữ liệu đã xử lý, không làm lại |

Và kiến trúc mà đề mô tả là mẫu rất phổ biến:

Dữ liệu clickstream mới ghi vào S3
    ↓ S3 event notification
Lambda được kích hoạt
    ↓ gọi API
Glue job chạy → biến đổi dữ liệu → ghi kết quả

def lambda_handler(event, context):
    boto3.client('glue').start_job_run(
        JobName='xu-ly-clickstream',
        Arguments={'--duong_dan_vao': f"s3://{bucket}/{key}"})

Và với dữ liệu tích luỹ liên tục, hãy bật job bookmark — nó khiến Glue chỉ xử lý dữ liệu mới thay vì làm lại từ đầu mỗi lần.

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

• **C. AWS Step Functions — đây là phương án gần nhất và thường xuất hiện trong đường ống dữ liệu, nhưng nó là công cụ ĐIỀU PHỐI luồng công việc, không phải công cụ ETL. Step Functions gọi các bước xử lý (Lambda, Glue, Batch) theo trình tự — bản thân nó không biến đổi dữ liệu.
• **B. Redshift Spectrum — là công cụ TRUY VẤN: nó cho phép Redshift chạy SQL trên dữ liệu nằm trong S3. Nó đọc dữ liệu, không phải đường ống ETL.
• **A. S3 Select — cũng chỉ là truy vấn: nó chạy SQL đơn giản trên một object để lấy phần dữ liệu cần. Không có khả năng biến đổi và nạp dữ liệu ở quy mô đường ống.

Ghi nhớ

Phân biệt ba loại dịch vụ trong kiến trúc dữ liệu: | Loại | Dịch vụ | Việc | |---|---|---| | ETL / xử lý | Glue, EMR, Lambda, Kinesis Analytics | biến đổi dữ liệu | | Truy vấn | Athena, Redshift Spectrum, S3 Select | đọc và phân tích | | Điều phối | Step Functions, MWAA (Airflow), EventBridge | sắp xếp trình tự các bước |

Câu hỏi dạng "dịch vụ ETL nào" luôn tìm nhóm đầu.

Glue và EMR — chọn cái nào: | | AWS Glue | Amazon EMR | |---|---|---| | Hạ tầng | KHÔNG máy chủ | cụm bạn quản lý | | Khởi động | vài phút | vài phút tới chục phút | | Kiểm soát | hạn chế | đầy đủ — cấu hình Spark, cài thư viện riêng | | Chi phí | theo DPU-giây | theo giờ instance | | Phù hợp | ETL thông thường, ít công vận hành | xử lý phức tạp, cần tinh chỉnh sâu |

Với đội ngũ nhỏ và ETL tiêu chuẩn, Glue gần như luôn là lựa chọn đúng.

Ba cách kích hoạt Glue job: | Cách | Chi tiết | |---|---| | S3 event → Lambda → start_job_run | ← kiến trúc của đề | | Glue trigger theo lịch | cron hoặc theo khoảng thời gian | | Glue workflow | chuỗi nhiều job và crawler | | EventBridge rule | linh hoạt nhất |

Và một lựa chọn hiện đại hơn cho việc kích hoạt: EventBridge trực tiếp gọi Glue, không cần Lambda trung gian — bớt được một thành phần phải bảo trì.

Ba loại Glue job: | Loại | Đặc điểm | |---|---| | Spark | xử lý phân tán, khối lượng lớn | | Python shell | script đơn giản, rẻ hơn nhiều cho việc nhẹ | | Streaming ETL | đọc từ Kinesis hoặc Kafka |

Python shell job chỉ tốn 0,0625 hoặc 1 DPU — với dữ liệu nhỏ, nó rẻ hơn Spark job rất nhiều.

Ba tối ưu quan trọng cho ETL trên S3: | Tối ưu | Lợi ích | |---|---| | Bật job bookmark | chỉ xử lý dữ liệu MỚI, thời gian chạy ổn định | | Ghi ra định dạng Parquet | giảm 80–90% dữ liệu quét ở bước phân tích | | Phân vùng theo thời gian | truy vấn chỉ đọc phân vùng cần |

Bật job bookmark:

aws glue update-job --job-name xu-ly-clickstream   --job-update '{"DefaultArguments": {"--job-bookmark-option": "job-bookmark-enable"}}'

Nhớ gọi job.commit() ở cuối script — không gọi thì bookmark không tiến lên.

Và một cạm bẫy với dữ liệu clickstream: rất nhiều tệp NHỎ.

Mỗi sự kiện một tệp
    → hàng triệu object tí hon trong S3
    → Glue và Athena phải mở từng tệp → rất chậm

Giải pháp: dùng Kinesis Data Firehose gom bản ghi thành tệp lớn (128 MB – 1 GB) trước khi ghi vào S3, đồng thời chuyển sang Parquet ngay trên đường đi.

Và một lưu ý về chi phí Glue: nó tính phí theo DPU-giờ với tối thiểu 1 phút mỗi lần chạy. Nếu job được kích hoạt cho từng tệp nhỏ như kiến trúc trong đề, chi phí sẽ rất cao — hãy cân nhắc gom lại và chạy theo lô mỗi 5–15 phút thay vì mỗi lần có object mới.

Đáp án

B — Tải dữ liệu lên S3 và đặt lifecycle policy chuyển sang Glacier sau 0 ngày.

Vì sao đúng

Đề cho ba điều kiện, và cả ba đều chỉ tới Glacier: | Điều kiện | Kết luận | |---|---| | Truy cập RẤT THƯA — chỉ vài tuần cụ thể để kiểm toán | lớp lưu trữ rẻ nhất | | Thời gian truy xuất chấp nhận tới 24 GIỜ | Glacier hoàn toàn đáp ứng | | An toàn, bền vững, tiết kiệm chi phí | Glacier có độ bền 11 số 9 |

Vế "retrieval time is not strict as long as it does not exceed 24 hours" là điều kiện quyết định:

Glacier Flexible Retrieval:
    Expedited: 1–5 phút
    Standard:  3–5 giờ    ← thoải mái dưới 24 giờ
    Bulk:      5–12 giờ   ← vẫn dưới 24 giờ

Và "chuyển sau 0 ngày" nghĩa là chuyển ngay lập tức:

{"Rules": [{
  "ID": "chuyen-ngay-sang-glacier",
  "Status": "Enabled",
  "Filter": {},
  "Transitions": [{"Days": 0, "StorageClass": "GLACIER"}]}]}

Dữ liệu vốn đã "hiếm khi truy cập" ngay từ đầu, nên không có lý do gì để nó nằm ở Standard dù chỉ một ngày.

Chênh lệch chi phí cho 10 TB:

S3 Standard:       10.000 GB × 0,023 = ~230 USD/tháng
S3 Standard-IA:    10.000 GB × 0,0125 = ~125 USD/tháng
Glacier Flexible:  10.000 GB × 0,0036 = ~36 USD/tháng

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

• **A. Chuyển sang S3-IA — đây là phương án gần nhất và cũng hợp lệ về mặt kỹ thuật, nhưng nó đắt hơn khoảng 3,5 lần mà không mang lại lợi ích nào: Standard-IA cho truy xuất tức thì, còn đề nói rõ chờ tới 24 giờ vẫn được.
• **D. Chuyển sang S3 One Zone-IA — hai vấn đề: vẫn đắt hơn Glacier, và quan trọng hơn là chỉ lưu ở MỘT AZ. Dữ liệu tài chính phục vụ kiểm toán không nên chấp nhận rủi ro mất khi một AZ bị phá huỷ.
• **C. Dùng Amazon FSx for Windows File Server với SMB — sai loại dịch vụ và rất đắt: FSx là hệ thống tệp cho truy cập thường xuyên, giá cao hơn S3 rất nhiều lần. Nó không phải giải pháp lưu trữ dài hạn.

Ghi nhớ

Ba chế độ truy xuất của Glacier Flexible Retrieval: | Chế độ | Thời gian | Chi phí truy xuất | |---|---|---| | Expedited | 1–5 phút | cao nhất | | Standard | 3–5 giờ | vừa | | Bulk | 5–12 giờ | rẻ nhất |

Ba lớp Glacier — chọn theo yêu cầu thời gian: | Lớp | Nhanh nhất | Chi phí lưu trữ | |---|---|---| | Glacier Instant Retrieval | mili giây | ~0,004 USD/GB | | Glacier Flexible Retrieval | 1–5 phút | ~0,0036 USD/GB | | Glacier Deep Archive | 12 giờ | ~0,00099 USD/GB |

Deep Archive rẻ nhất nhưng chờ 12 giờ (Standard) hoặc 48 giờ (Bulk) — với yêu cầu "không quá 24 giờ" của đề, Deep Archive rủi ro vì chế độ Bulk vượt ngưỡng.

Ràng buộc thời gian lưu tối thiểu — ảnh hưởng trực tiếp tới chi phí: | Lớp | Tối thiểu | |---|---| | Standard-IA, One Zone-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Glacier Deep Archive | 180 ngày |

Xoá trước hạn vẫn bị tính đủ phí — với dữ liệu kiểm toán giữ nhiều năm thì không thành vấn đề.

Và một ràng buộc quan trọng về chuyển đổi:

Chuyển sang Standard-IA hoặc One Zone-IA:
    → object phải ở Standard ít nhất 30 NGÀY

Chuyển thẳng sang GLACIER:
    → KHÔNG có ràng buộc → "Days: 0" hợp lệ

Đó là lý do phương án B dùng được con số 0.

Ba loại chi phí khi dùng Glacier: | Loại | Chi tiết | |---|---| | Lưu trữ | rất rẻ | | Truy xuất | khác nhau tới 10 lần giữa Expedited và Bulk | | Request | theo số lượng |

Với đợt kiểm toán lấy toàn bộ 10 TB, hãy dùng chế độ Bulk — chênh lệch chi phí truy xuất rất đáng kể ở khối lượng này.

Và một lưu ý về object nhỏ: Glacier tính thêm khoảng 32 KB metadata cho mỗi object, cộng 8 KB cho tên object ở S3. Với hàng triệu tệp tí hon, phần overhead này có thể vượt cả chi phí dữ liệu thật:

{"Filter": {"ObjectSizeGreaterThan": 131072}}

Lọc theo kích thước để chỉ chuyển các tệp trên 128 KB.

Ba biện pháp bảo mật nên có cho dữ liệu tài chính: | Biện pháp | Cấu hình | |---|---| | Mã hoá at rest | SSE-KMS để có audit trail | | Bắt buộc HTTPS | điều kiện aws:SecureTransport | | S3 Object Lock hoặc Glacier Vault Lock | chống xoá, đáp ứng yêu cầu WORM của kiểm toán |

Dòng cuối đáng cân nhắc nghiêm túc với dữ liệu kiểm toán — nhiều quy định tài chính yêu cầu dữ liệu phải bất biến trong thời hạn giữ.

Và một lời khuyên vận hành: hãy thử khôi phục một mẫu nhỏ ngay sau khi chuyển dữ liệu sang Glacier, để đo thời gian thật và kiểm chứng quy trình. Phát hiện vấn đề khi kiểm toán viên đang chờ là tình huống nên tránh.

Đáp án

B — Tạo AWS Lambda function từ địa chỉ 100.220.0.11/32.

Vì sao đúng

Policy có hai statement, và phải đọc cả hai cùng lúc:

Statement 1: ALLOW  CreateFunction, DeleteFunction   trên MỌI tài nguyên
Statement 2: DENY   CreateFunction, DeleteFunction,
                    InvokeFunction, TagResource
                    CHỈ KHI aws:SourceIp = 187.5.104.11/32

Nguyên tắc đánh giá IAM: explicit DENY luôn thắng.

Quyền hiệu lực = (có Allow) VÀ (KHÔNG có Deny nào áp dụng)

Xét từng lựa chọn theo hai chiều — HÀNH ĐỘNG và ĐỊA CHỈ NGUỒN:

Từ 187.5.104.11:
    → Statement 2 ÁP DỤNG → DENY mọi hành động Lambda liệt kê
    → không làm được gì

Từ địa chỉ KHÁC (ví dụ 100.220.0.11):
    → Statement 2 KHÔNG áp dụng (điều kiện IP không khớp)
    → chỉ còn Statement 1 → ALLOW CreateFunction và DeleteFunction
    → tạo được, xoá được

Nên "tạo function từ 100.220.0.11" được phép — đó là đáp án B.

Bảng tóm tắt: | Hành động | Từ 187.5.104.11 | Từ IP khác | |---|---|---| | CreateFunction | DENY | ALLOW ← B | | DeleteFunction | DENY | ALLOW | | InvokeFunction | DENY | không có Allow → ngầm từ chối | | TagResource | DENY | không có Allow → ngầm từ chối |

Chú ý hai dòng cuối: InvokeFunction và TagResource KHÔNG được phép từ bất kỳ đâu — vì Statement 1 không cấp chúng, và mặc định của IAM là từ chối.

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

• **D. Tạo function từ 187.5.104.11/32 — đây là phương án gần nhất và là bẫy chính: hành động đúng nhưng địa chỉ nguồn khớp với điều kiện DENY. Statement 2 chặn nó.
• **A. Xoá function từ 187.5.104.11/32 — cùng lý do: bị Statement 2 chặn.
• **C. Xoá function từ BẤT KỲ địa chỉ nào — sai vì chữ "bất kỳ": xoá được từ hầu hết địa chỉ, nhưng KHÔNG từ 187.5.104.11. Mệnh đề phổ quát này bị một phản ví dụ bác bỏ.

Ghi nhớ

Thứ tự đánh giá của IAM — thuộc lòng:

① Có explicit DENY nào áp dụng không?  → CÓ  → TỪ CHỐI (dừng)
② Có explicit ALLOW nào không?          → CÓ  → CHO PHÉP
③ Không có gì                           → TỪ CHỐI ngầm định

Explicit DENY luôn thắng mọi Allow — không có ngoại lệ nào.

Các thành phần của một policy statement: | Trường | Vai trò | |---|---| | Effect | Allow hoặc Deny | | Action | hành động | | Resource | tài nguyên áp dụng | | Condition | điều kiện — statement CHỈ áp dụng khi điều kiện đúng | | Sid | nhãn cho người đọc, không ảnh hưởng quyền |

Hiểu đúng Condition là chìa khoá của câu hỏi này:

Deny + Condition IpAddress = 187.5.104.11
    → CHỈ từ chối khi request đến TỪ địa chỉ đó
    → từ địa chỉ khác, statement này KHÔNG tồn tại

Và có một mẫu ngược lại rất hay dùng trong thực tế:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"NotIpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}}}

NotIpAddress chặn MỌI địa chỉ TRỪ dải cho phép — đó là cách khoá truy cập vào mạng công ty. Policy trong đề làm ngược lại: nó chặn đúng một địa chỉ.

Các khoá điều kiện toàn cục hay dùng: | Khoá | Ý nghĩa | |---|---| | aws:SourceIp | IP nguồn của request | | aws:MultiFactorAuthPresent | phiên có MFA không | | aws:RequestedRegion | Region đang thao tác | | aws:SecureTransport | có dùng HTTPS không | | aws:PrincipalTag/... | thẻ của người gọi | | aws:ResourceTag/... | thẻ của tài nguyên |

Một cạm bẫy quan trọng với aws:SourceIp:

Khi request đi QUA một dịch vụ AWS (ví dụ CloudFormation gọi hộ)
    → aws:SourceIp là IP của DỊCH VỤ, không phải của bạn
    → điều kiện IP có thể chặn nhầm
→ dùng thêm aws:ViaAWSService để xử lý trường hợp này

Bốn loại policy và vai trò: | Loại | Vai trò | |---|---| | Identity-based | CẤP quyền cho user, group, role ← policy trong đề | | Resource-based | gắn vào tài nguyên (S3 bucket, Lambda function) | | SCP | GIỚI HẠN quyền tối đa của tài khoản | | Permissions boundary | giới hạn quyền tối đa của một thực thể |

Và có một điểm cần lưu ý về chính policy này: "Resource": "*" cho phép tạo và xoá bất kỳ Lambda function nào trong tài khoản. Nếu muốn áp dụng quyền tối thiểu, nên giới hạn theo tên hoặc theo thẻ:

{"Resource": "arn:aws:lambda:*:*:function:ung-dung-abc-*"}

Công cụ kiểm chứng: IAM Policy Simulator cho phép thử một hành động cụ thể với điều kiện cụ thể và xem kết quả kèm lý do — nhanh hơn nhiều so với gán policy rồi thử trong thực tế.

Đáp án

B — Gửi toàn bộ log event vào Amazon Kinesis, sau đó viết tiến trình client áp dụng heuristic lên log.

Vì sao đúng

Đề nêu ba yêu cầu, và Kinesis Data Streams đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Gộp nhiều luồng log vào MỘT hệ thống | nhiều producer cùng ghi vào một stream | | Phân tích THỜI GIAN THỰC | độ trễ mili giây | | Quay lại lấy mẫu dữ liệu của 12 GIỜ trước | giữ dữ liệu 24 giờ mặc định, PHÁT LẠI được |

Yêu cầu thứ ba là điều kiện quyết định — và chỉ Kinesis có:

Kinesis Data Streams giữ bản ghi 24 GIỜ (mặc định)
    → tăng được tới 365 ngày
    → consumer đọc lại từ BẤT KỲ điểm nào trong khoảng đó
    → "going back to data samples from the last 12 hours" ✅

Trong khi SQS thì không:

SQS: thông điệp bị XOÁ sau khi consumer xử lý xong
    → không có cách nào đọc lại

Và Kinesis cho phép nhiều consumer độc lập:

Một stream
    ├─▶ Consumer A: áp dụng heuristic thời gian thực
    ├─▶ Consumer B: ghi vào S3 để lưu trữ
    └─▶ Consumer C: kiểm chứng heuristic trên dữ liệu 12 giờ trước
    → mỗi consumer đọc theo tốc độ và vị trí RIÊNG

Đọc lại từ một thời điểm cụ thể:

r = kinesis.get_shard_iterator(
    StreamName='log-tap-trung', ShardId='shardId-000000000000',
    ShardIteratorType='AT_TIMESTAMP',
    Timestamp=datetime(2026, 8, 30, 6, 0, 0))

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

• **D. Gửi log vào Amazon SQS rồi dùng Auto Scaling group EC2 tiêu thụ — đây là phương án gần nhất và cũng gộp được log từ nhiều nguồn, nhưng nó không đáp ứng yêu cầu quay lại 12 giờ trước: SQS xoá thông điệp sau khi xử lý, không có cơ chế phát lại. Và SQS không đảm bảo thứ tự với standard queue.
• **A. Auto Scaling group EC2 → lưu log vào S3 → dùng EMR phân tích — không phải thời gian thực: dữ liệu phải được ghi thành tệp trên S3 rồi mới phân tích theo lô. Đề yêu cầu "analyze these logs in REAL-TIME".
• **C. Cấu hình CloudTrail nhận log tuỳ chỉnh rồi dùng EMR — sai chức năng dịch vụ: CloudTrail chỉ ghi lời gọi API tới AWS, nó không nhận log tuỳ chỉnh của ứng dụng. Đây là hiểu sai căn bản về CloudTrail.

Ghi nhớ

Kinesis Data Streams và SQS — bảng phân biệt cốt lõi: | | Kinesis Data Streams | SQS | |---|---|---| | Phát lại (replay) | ✅ 1–365 ngày | ❌ xoá sau khi xử lý | | Nhiều consumer độc lập | ✅ mỗi cái đọc riêng | ❌ một thông điệp một người đọc | | Thứ tự | ✅ trong shard | ❌ (standard) / ✅ (FIFO) | | Mô hình | luồng — nhiều người đọc cùng dữ liệu | hàng đợi — chia việc | | Mở rộng | theo shard | tự động, không giới hạn |

Quy tắc chọn:

"replay", "multiple consumers", "real-time analytics", "go back in time" → Kinesis "decouple", "work queue", "process once" → SQS

Bốn dịch vụ trong họ Kinesis: | Dịch vụ | Việc | |---|---| | Data Streams | luồng có phát lại, nhiều consumer ← câu này | | Data Firehose | giao dữ liệu tự động vào S3, Redshift, OpenSearch | | Managed Service for Apache Flink | phân tích luồng bằng SQL hoặc Flink | | Video Streams | video và âm thanh |

Và với "áp dụng heuristic thời gian thực", Managed Service for Apache Flink đáng cân nhắc:

Thay vì tự viết consumer:
    → viết truy vấn SQL trên cửa sổ thời gian
    → ví dụ: đếm số lỗi 500 trong 5 phút gần nhất theo từng dịch vụ
    → không phải quản lý ứng dụng consumer nào

Thông lượng của một shard: | Chiều | Giới hạn | |---|---| | Ghi vào | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc ra (standard) | 2 MB/giây CHIA cho mọi consumer | | Đọc ra (enhanced fan-out) | 2 MB/giây RIÊNG mỗi consumer |

Với ba consumer trở lên, hãy bật enhanced fan-out — nếu không chúng chia nhau 2 MB/giây và đều chậm.

Bốn loại shard iterator — cơ chế cho phép "quay lại 12 giờ trước": | Loại | Bắt đầu đọc từ | |---|---| | LATEST | bản ghi mới nhất | | TRIM_HORIZON | bản ghi cũ nhất còn giữ | | AT_TIMESTAMP | thời điểm cụ thể ← đúng nhu cầu của đề | | AT_SEQUENCE_NUMBER | vị trí cụ thể |

Ba cách đưa log vào Kinesis: | Cách | Đặc điểm | |---|---| | Kinesis Agent | đọc tệp log và đẩy lên — không cần viết mã | | CloudWatch Logs subscription filter | log đã ở CloudWatch thì chuyển tiếp sang | | SDK trong ứng dụng | kiểm soát cao nhất |

Kinesis Agent là cách đơn giản nhất cho log access và log ứng dụng trên máy chủ.

Kiến trúc đầy đủ cho tình huống của đề:

Log access, ứng dụng, bảo mật
    ↓ Kinesis Agent
Kinesis Data Streams (giữ 24 giờ — hoặc tăng lên 7 ngày)
    ├─▶ Flink: heuristic thời gian thực → cảnh báo
    ├─▶ Firehose → S3: lưu trữ dài hạn, phân tích bằng Athena
    └─▶ Firehose → OpenSearch: tìm kiếm và dashboard

Tăng thời gian giữ nếu cần quay lại xa hơn:

aws kinesis increase-stream-retention-period   --stream-name log-tap-trung --retention-period-hours 168

Và một metric cần đặt alarm: GetRecords.IteratorAgeMilliseconds. Nếu nó tiến gần thời gian giữ dữ liệu, consumer đang tụt hậu và bản ghi sắp bị xoá trước khi được xử lý — mất khả năng phát lại đúng lúc cần nhất.

Đáp án

B — Amazon EFS.

Vì sao đúng

Đề nêu năm yêu cầu, và EFS là dịch vụ duy nhất đáp ứng cả năm: | Yêu cầu | Cơ chế | |---|---| | 1.000 máy chủ Linux truy cập ĐỒNG THỜI | EFS hỗ trợ hàng nghìn kết nối cùng lúc | | Nhiều Availability Zone | mount target ở mỗi AZ | | Cấu trúc thư mục PHÂN CẤP qua NFSv4 | EFS chính là NFS | | Dữ liệu thay đổi nhanh, quy mô lớn | tự mở rộng, không cần cấp phát | | Bền vững, sẵn sàng cao, ít công quản lý | dịch vụ được quản lý hoàn toàn |

Ba từ khoá trong đề chỉ thẳng tới EFS:

"NFSv4"                    → EFS là dịch vụ NFS của AWS
"hierarchical directory"   → hệ thống TỆP, không phải kho object
"1000 Linux servers"       → cần lưu trữ chia sẻ được
"multiple availability zones" → EFS trải qua nhiều AZ

Và EFS tự mở rộng hoàn toàn:

Không phải cấp phát dung lượng trước
    → tự lớn lên khi ghi thêm tệp
    → tự nhỏ lại khi xoá
    → trả tiền theo dung lượng THỰC DÙNG

sudo mount -t efs -o tls fs-0abc123:/ /du-lieu-chung

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

• **C. Amazon EBS — đây là phương án gần nhất về mặt cũng là lưu trữ khối cho EC2, nhưng nó không chia sẻ được ở quy mô này: EBS volume gắn với MỘT AZ, và dù có multi-attach thì cũng tối đa 16 instance TRONG CÙNG AZ (và chỉ với io1/io2). Không thể phục vụ 1.000 máy trải nhiều AZ.
• **A. Amazon S3 — sai mô hình lưu trữ: S3 là kho object, truy cập qua API HTTP. Nó không hỗ trợ NFSv4 và không có cấu trúc thư mục thật (chỉ là quy ước tiền tố trong tên khoá). Ứng dụng đang dùng đường dẫn tệp sẽ phải viết lại.
• **D. Amazon FSx for Windows File Server — sai giao thức và hệ điều hành: FSx for Windows dùng SMB, phục vụ máy chủ Windows. Đề nói rõ 1.000 máy chủ Linux dùng NFSv4.

Ghi nhớ

Ba loại lưu trữ trên AWS — bảng cần thuộc: | Loại | Dịch vụ | Truy cập | Chia sẻ | |---|---|---|---| | Khối (block) | EBS, instance store | gắn vào máy như ổ đĩa | rất hạn chế | | Tệp (file) | EFS, FSx | NFS hoặc SMB | ✅ nhiều máy cùng lúc | | Object | S3 | API HTTP | ✅ nhưng không phải hệ thống tệp |

Quy tắc nhận diện trong đề thi:

"NFS", "shared file system", "POSIX", "hierarchical directory", "Linux" → EFS "SMB", "Windows", "Active Directory", "NTFS" → FSx for Windows "HPC", "machine learning", "Lustre", "hundreds of GB/s" → FSx for Lustre "object", "REST API", "unlimited storage" → S3

Bốn dịch vụ FSx: | Dịch vụ | Giao thức | Dùng cho | |---|---|---| | FSx for Windows File Server | SMB | ứng dụng Windows, AD | | FSx for Lustre | Lustre (POSIX) | HPC, học máy — thông lượng cực cao | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | môi trường lai với NetApp | | FSx for OpenZFS | NFS | thay thế máy chủ ZFS |

Hai chế độ hiệu năng của EFS: | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | độ trễ THẤP NHẤT — phù hợp hầu hết | | Max I/O | thông lượng cao hơn, độ trễ cao hơn một chút |

Ba chế độ throughput: | Chế độ | Đặc điểm | |---|---| | Elastic (khuyến nghị) | tự điều chỉnh, trả theo lượng dùng thật | | Bursting | tích luỹ tín dụng theo DUNG LƯỢNG lưu trữ | | Provisioned | khai trước mức thông lượng cố định |

Cạm bẫy của chế độ Bursting — quan trọng cho tình huống 1.000 máy:

Tín dụng burst tích luỹ theo dung lượng:
    file system nhỏ (vài GB) + 1.000 máy đọc liên tục
        → CẠN tín dụng
        → tụt xuống mức cơ sở rất thấp (50 KB/giây mỗi GB)
        → hiệu năng sụp đổ

Với "rapidly changing data at scale" như đề mô tả, hãy dùng Elastic throughput — nó không có khái niệm tín dụng.

Hai lớp lưu trữ của EFS: | Lớp | Chi phí | |---|---| | Standard | cao hơn | | Infrequent Access (IA) | rẻ hơn ~92%, có phí truy xuất |

Lifecycle policy tự chuyển tệp ít dùng sang IA:

aws efs put-lifecycle-configuration --file-system-id fs-0abc123   --lifecycle-policies TransitionToIA=AFTER_30_DAYS                        TransitionToPrimaryStorageClass=AFTER_1_ACCESS

Đây là tối ưu chi phí quan trọng nhất với EFS — nó thường giảm hoá đơn rất đáng kể mà không ảnh hưởng ứng dụng.

Ba lưu ý khi triển khai EFS cho 1.000 máy: | Lưu ý | Chi tiết | |---|---| | Tạo mount target ở MỖI AZ | máy ở AZ không có mount target sẽ trả phí truyền dữ liệu giữa AZ | | Security group của mount target phải mở cổng 2049 | NFS | | Dùng EFS Access Point | ép POSIX user và thư mục gốc cho từng nhóm ứng dụng |

Và bật mã hoá cả hai chiều:

At rest:    bật lúc tạo file system (KMS)
In transit: tuỳ chọn -o tls khi mount

Và một lưu ý về chi phí ở quy mô này: EFS đắt hơn S3 khoảng 10 lần tính theo GB. Nếu một phần dữ liệu thực chất chỉ được đọc và không cần ngữ nghĩa hệ thống tệp, hãy cân nhắc để phần đó ở S3 — kiến trúc lai như vậy thường giảm hoá đơn rất nhiều mà không mất tính năng nào.

Đáp án

B — Bỏ NAT instance và tạo S3 gateway endpoint để truy cập object trong S3.

Vì sao đúng

Đề cần giảm chi phí cho kiến trúc mà EC2 ở private subnet lấy dữ liệu từ S3 qua NAT instance.

Và gateway endpoint là lựa chọn rẻ nhất tuyệt đối:

S3 Gateway Endpoint:
    ✓ Không phí giờ
    ✓ Không phí xử lý dữ liệu
    ✓ HOÀN TOÀN MIỄN PHÍ

So với NAT instance:

NAT instance:
    ~ chi phí EC2 chạy 24/7 (dù nhỏ cũng vài chục USD/tháng)
  + băng thông giới hạn theo loại instance
  + bạn phải tự vá lỗi, tự giám sát, tự lo sẵn sàng cao

Gateway endpoint:
    0 USD
  + băng thông không giới hạn
  + AWS quản lý hoàn toàn

Cách nó hoạt động — chỉ là một route:

Tạo gateway endpoint
    → AWS thêm route vào route table của private subnet
    → prefix list của S3 (pl-xxxx) → vpce-xxxx
    → lưu lượng tới S3 đi qua MẠNG NỘI BỘ của AWS
    → không ra Internet, không qua NAT

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc123   --service-name com.amazonaws.ap-southeast-1.s3   --route-table-ids rtb-private-1a rtb-private-1b

Và nó còn AN TOÀN HƠN: lưu lượng không bao giờ rời khỏi mạng AWS.

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

• **D. Bỏ NAT instance và tạo S3 INTERFACE endpoint — đây là phương án gần nhất và cũng cho truy cập S3 riêng tư, nhưng nó TỐN TIỀN: interface endpoint tính phí theo giờ cho mỗi AZ CỘNG phí mỗi GB xử lý. Với yêu cầu "most cost-efficient", gateway endpoint miễn phí thắng rõ ràng.
• **A. Thay NAT instance bằng NAT Gateway — thường ĐẮT HƠN: NAT gateway tốn ~32 USD/tháng phí giờ cộng ~0,045 USD mỗi GB xử lý. Nó tiện hơn về vận hành nhưng không phải cách giảm chi phí.
• **C. Dùng loại instance NHỎ HƠN cho NAT instance — chỉ giảm được một chút và tạo rủi ro mới: instance nhỏ hơn có băng thông thấp hơn, dễ thành nút thắt cổ chai. Và vẫn phải trả tiền cho một máy chạy 24/7.

Ghi nhớ

Hai loại VPC endpoint — bảng phân biệt cốt lõi: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ hỗ trợ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Chi phí | MIỄN PHÍ | phí giờ mỗi AZ + phí mỗi GB | | Cơ chế | route trong route table | ENI có IP riêng trong subnet | | Truy cập từ tại chỗ (qua DX/VPN) | ❌ KHÔNG | ✅ CÓ | | Dùng qua VPC peering | ❌ | ✅ | | Security group | không gắn được | gắn được |

"Chỉ S3 và DynamoDB" là điều cần thuộc lòng.

Khi nào PHẢI dùng interface endpoint cho S3 dù tốn tiền: | Tình huống | Lý do | |---|---| | Truy cập S3 từ trung tâm dữ liệu qua Direct Connect | gateway endpoint không hoạt động ngoài VPC | | Truy cập từ VPC khác qua peering | gateway endpoint không đi qua peering | | Tường lửa tại chỗ lọc theo IP | cần địa chỉ IP riêng tư cố định |

Ba cách để instance ở private subnet ra Internet hoặc tới dịch vụ AWS: | Cách | Chi phí | Phù hợp | |---|---|---| | VPC gateway endpoint | MIỄN PHÍ | chỉ S3 và DynamoDB ← câu này | | VPC interface endpoint | phí giờ + phí GB | dịch vụ AWS khác | | NAT Gateway | ~32 USD/tháng + 0,045 USD/GB | Internet công cộng nói chung | | NAT instance | chi phí EC2, tự quản lý | môi trường thử nghiệm nhỏ |

NAT gateway là khoản chi phí âm thầm phổ biến nhất trên AWS.

Sau khi đặt gateway endpoint, hãy kiểm tra còn lưu lượng nào qua NAT không:

Các dịch vụ hay tốn tiền qua NAT:
    ECR (kéo image container — rất nặng)
    CloudWatch Logs
    Systems Manager
    Secrets Manager, KMS
→ tất cả đều có interface endpoint

Với khối lượng lớn, phí interface endpoint vẫn rẻ hơn phí NAT nhiều.

Ba lưu ý khi triển khai gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Phải gắn vào ĐÚNG mọi route table | quên một cái là subnet đó vẫn đi qua NAT và tính phí | | Chỉ hoạt động trong cùng Region | bucket ở Region khác vẫn đi Internet | | Không thay thế IAM | endpoint là đường đi, quyền vẫn do IAM và bucket policy quyết định |

Dòng đầu là lỗi triển khai phổ biến nhất — và triệu chứng của nó là hoá đơn NAT không giảm như mong đợi.

Và endpoint policy là công cụ bảo mật đáng dùng:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": ["arn:aws:s3:::kho-cua-cong-ty/*"]}]}

Nó ngăn instance dùng endpoint để tải dữ liệu lên bucket của người khác — một biện pháp chống rò rỉ dữ liệu hiệu quả mà không tốn gì.

Ở chiều ngược lại, bucket policy giới hạn theo endpoint:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": "arn:aws:s3:::kho-cua-cong-ty/*",
 "Condition": {"StringNotEquals": {"aws:sourceVpce": "vpce-0abc123"}}}

Bucket chỉ truy cập được qua đúng endpoint đó — kể cả người có thông tin đăng nhập hợp lệ cũng không tải dữ liệu về từ bên ngoài.

Và một lưu ý cuối: đừng xoá NAT ngay nếu instance còn cần gọi các dịch vụ khác trên Internet (cập nhật gói phần mềm, gọi API bên thứ ba). Hãy kiểm tra VPC Flow Logs xem lưu lượng còn lại đi đâu trước khi gỡ bỏ.

Đáp án

A — AWS Direct Connect.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều là mô tả chính xác của Direct Connect: | Yêu cầu | Cơ chế | |---|---| | Kết nối CHUYÊN DỤNG (dedicated) | đường cáp vật lý riêng, không chia sẻ | | Băng thông CAO | 50 Mbps tới 100 Gbps | | Trải nghiệm mạng NHẤT QUÁN hơn giải pháp qua Internet | không đi qua Internet công cộng |

Vì sao Direct Connect nhất quán hơn VPN:

Site-to-Site VPN:
    đi qua INTERNET CÔNG CỘNG
        → độ trễ biến động theo tình trạng mạng
        → băng thông phụ thuộc đường truyền Internet
        → có thể nghẽn vào giờ cao điểm

Direct Connect:
    cáp VẬT LÝ RIÊNG từ trung tâm dữ liệu tới điểm hiện diện của AWS
        → độ trễ ổn định, đo được
        → băng thông cam kết
        → không chịu ảnh hưởng của Internet

Và cụm từ "more consistent network experience than Internet-based solutions" trong đề chính là câu quảng bá chính thức của Direct Connect.

Ba loại virtual interface: | Loại VIF | Dùng để | |---|---| | Private VIF | vào VPC riêng tư qua virtual private gateway | | Public VIF | truy cập dịch vụ công khai của AWS (S3, DynamoDB) qua DX | | Transit VIF | vào Transit Gateway — cho kiến trúc nhiều VPC |

Với "kết nối riêng tư giữa VPC và mạng tại chỗ" như đề mô tả, private VIF là loại cần dùng.

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

• **D. AWS Site-to-Site VPN — đây là phương án gần nhất và cũng tạo kết nối riêng tư (mã hoá), nhưng nó đi qua Internet công cộng: băng thông và độ trễ phụ thuộc chất lượng đường truyền Internet, không "nhất quán" như đề yêu cầu. Và mỗi tunnel VPN giới hạn khoảng 1,25 Gbps.
• **C. Transit Gateway với ECMP — không phải cơ chế kết nối tới mạng tại chỗ: Transit Gateway là trung tâm ĐỊNH TUYẾN giữa các VPC và các kết nối. ECMP cho phép gộp nhiều tunnel VPN để tăng băng thông, nhưng bản thân TGW không tạo ra đường kết nối vật lý nào.
• **B. Transit VPC — là một MẪU KIẾN TRÚC cũ, không phải dịch vụ: nó dùng một VPC trung tâm với thiết bị mạng ảo để nối các VPC lại. AWS đã thay thế bằng Transit Gateway. Và nó cũng không tạo kết nối chuyên dụng.

Ghi nhớ

Direct Connect và Site-to-Site VPN — bảng phân biệt cốt lõi: | | Direct Connect | Site-to-Site VPN | |---|---|---| | Đường đi | cáp VẬT LÝ riêng | Internet công cộng | | Băng thông | 50 Mbps – 100 Gbps | ~1,25 Gbps mỗi tunnel | | Độ trễ | ổn định, thấp | biến động | | Mã hoá | KHÔNG mặc định | ✅ IPsec | | Thời gian thiết lập | hàng TUẦN tới hàng tháng | vài PHÚT | | Chi phí | cao (phí cổng + phí truyền) | thấp | | Phí truyền dữ liệu ra | rẻ hơn đáng kể | giá Internet thông thường |

Chú ý dòng "mã hoá": Direct Connect KHÔNG mã hoá mặc định.

Muốn vừa riêng tư vừa mã hoá:
    → chạy VPN QUA Direct Connect
    → hoặc dùng MACsec (với kết nối chuyên dụng tốc độ cao)

Với dữ liệu nhạy cảm, đây là chi tiết quan trọng — nhiều người tưởng DX đã mã hoá sẵn.

Ba lưu ý về sẵn sàng cao của Direct Connect: | Lưu ý | Chi tiết | |---|---| | MỘT kết nối DX = KHÔNG có dự phòng | cáp đứt là mất kết nối | | Sẵn sàng cao thật sự cần HAI kết nối ở HAI vị trí khác nhau | tốn gấp đôi | | Nên có VPN làm đường dự phòng | rẻ, thiết lập nhanh, tự chuyển bằng BGP |

Dòng cuối là thực hành được AWS khuyến nghị: kết hợp DX (đường chính) với VPN (đường dự phòng) cho tỷ lệ chi phí trên độ tin cậy tốt nhất.

Hai loại kết nối Direct Connect: | Loại | Băng thông | Đặt qua | |---|---|---| | Dedicated connection | 1, 10, 100 Gbps | AWS trực tiếp | | Hosted connection | 50 Mbps – 25 Gbps | đối tác Direct Connect |

Hosted connection linh hoạt hơn cho nhu cầu nhỏ — bạn không phải mua nguyên một cổng 1 Gbps nếu chỉ cần 200 Mbps.

Ba thành phần bổ trợ: | Thành phần | Việc | |---|---| | Direct Connect Gateway | một DX phục vụ NHIỀU VPC ở nhiều Region | | Link Aggregation Group (LAG) | gộp nhiều kết nối thành một, tăng băng thông | | Transit VIF + Transit Gateway | kiến trúc hàng trăm VPC |

Direct Connect Gateway là thành phần gần như luôn cần khi có nhiều hơn một VPC — và nó miễn phí.

Ba yếu tố chi phí của Direct Connect: | Khoản | Chi tiết | |---|---| | Phí cổng theo giờ | tuỳ băng thông | | Phí truyền dữ liệu RA | rẻ hơn Internet đáng kể | | Phí của đối tác / trung tâm dữ liệu | nếu dùng hosted connection |

Dòng giữa là lý do kinh tế thật của Direct Connect: với tổ chức truyền hàng trăm terabyte ra khỏi AWS mỗi tháng, phần tiết kiệm ở phí truyền dữ liệu có thể bù được toàn bộ chi phí cổng.

Và một lời khuyên khi lập kế hoạch: thời gian lắp đặt DX tính bằng tuần đến tháng vì cần làm việc với nhà cung cấp và trung tâm dữ liệu. Hãy dựng Site-to-Site VPN trước để đội ngũ bắt đầu làm việc ngay, rồi chuyển sang DX khi nó sẵn sàng — và giữ VPN lại làm đường dự phòng.