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

Tìm thấy 2194 câu.

Câu 1001 AWS Application Integration

A solutions architect is designing an application on AWS. The compute layer will run in parallel across EC2 instances. The compute layer should scale based on the number of jobs to be processed. The compute layer is stateless. The solutions architect must ensure that the application is loosely coupled and the job items are durably stored.

Which design should the solutions architect use?

  1. A

    Create an Amazon SQS queue to hold the jobs that need to be processed. Create an Amazon EC2 Auto Scaling group for the compute application. Set the scaling policy for the Auto Scaling group to add and remove nodes based on network usage
  2. B

    Create an Amazon SNS topic to send the jobs that need to be processed. Create an Amazon EC2 Auto Scaling group for the compute application. Set the scaling policy for the Auto Scaling group to add and remove nodes based on CPU usage
  3. C

    Create an Amazon SNS topic to send the jobs that need to be processed. Create an Amazon EC2 Auto Scaling group for the compute application. Set the scaling policy for the Auto Scaling group to add and remove nodes based on the number of messages published to the SNS topic
  4. D

    Create an Amazon SQS queue to hold the jobs that needs to be processed. Create an Amazon EC2 Auto Scaling group for the compute application. Set the scaling policy for the Auto Scaling group to add and remove nodes based on the number of items in the SQS queue
Xem giải thích

Đáp án

D — Tạo một Amazon SQS queue giữ các job cần xử lý, tạo ASG cho tầng tính toán, và đặt chính sách co giãn theo số item trong hàng đợi SQS.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này thoả hết: | Yêu cầu | Cách đáp ứng | |---|---| | Tầng tính toán chạy song song, KHÔNG GIỮ TRẠNG THÁI | nhiều máy cùng lấy việc từ hàng đợi | | **Co giãn theo SỐ JOB cần xử lý | metric độ dài hàng đợi | | Ứng dụng phải TÁCH RỜI LỎNG | hàng đợi ở giữa | | Job phải được lưu BỀN VỮNG | SQS giữ tới 14 ngày |

⚠ "Job items durably stored" là điểm loại SNS:

SQS: thông điệp LƯU TRỮ tới 14 ngày
    → consumer chết thì việc vẫn còn
        ↓
SNS: ĐẨY một lần, KHÔNG lưu
    → không ai nhận thì mất

Đây là lý do loại cả B và C.

Và metric co giãn phải phản ánh lượng việc:

Đề nói "scale based on the NUMBER OF JOBS to be processed"
    → đó chính là số thông điệp trong hàng đợi
        ↓
    CPU hay network usage chỉ là triệu chứng

Đây là lý do loại phương án A.

Cách làm chuẩn — metric "backlog per instance":

Backlog mỗi instance = số thông điệp / số máy InService
        ↓
    Con số này độc lập với quy mô hiện tại

Đẩy custom metric:

import boto3
sqs = boto3.client('sqs'); asg = boto3.client('autoscaling')
cw = boto3.client('cloudwatch')

so_tin = int(sqs.get_queue_attributes(QueueUrl=URL,
    AttributeNames=['ApproximateNumberOfMessages'])
    ['Attributes']['ApproximateNumberOfMessages'])
so_may = len([i for i in asg.describe_auto_scaling_groups(
    AutoScalingGroupNames=['asg-xu-ly'])['AutoScalingGroups'][0]['Instances']
    if i['LifecycleState'] == 'InService'])

cw.put_metric_data(Namespace='UngDung/Job', MetricData=[{
    'MetricName': 'BacklogPerInstance', 'Value': so_tin / max(so_may, 1)}])

Chính sách co giãn:

aws autoscaling put-scaling-policy --auto-scaling-group-name asg-xu-ly \
  --policy-name theo-hang-doi --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{"TargetValue":20.0,
    "CustomizedMetricSpecification":{
      "MetricName":"BacklogPerInstance","Namespace":"UngDung/Job",
      "Statistic":"Average"}}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Job không mất khi máy chết | thông điệp quay lại hàng đợi | | Co giãn theo lượng việc thật | | | Máy xử lý hoàn toàn stateless | |

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

  • **A. SQS queue + ASG co giãn theo network usage — đây là phương án gần nhất vì dùng đúng SQS để lưu job bền vững, nhưng metric sai: lưu lượng mạng không phản ánh số job đang chờ. Job nhỏ nhiều và job lớn ít cho ra cùng một mức mạng.
  • **C. SNS topic + ASG co giãn theo số thông điệp publish vào SNS — SNS không lưu trữ, vi phạm "durably stored". Và metric số thông điệp đã publish nói về lượng đến, không nói về lượng tồn đọng.
  • **B. SNS topic + ASG co giãn theo CPU — sai cả hai vế: SNS không lưu bền, và CPU không phản ánh số job.

Ghi nhớ

⚠ SQS và SNS — bảng phải thuộc: | | Amazon SQS | Amazon SNS | |---|---|---| | Mô hình | hàng đợi, KÉO | pub/sub, ĐẨY | | Lưu trữ | tới 14 ngày | KHÔNG | | Đo được tồn đọng | ✅ | ❌ | | Đệm tải | ✅ | ❌ |

Từ khoá nhận diện:

"durably stored", "loosely coupled", "scale by number of jobs" → SQS + metric hàng đợi "fan-out to many subscribers" → SNS "process in order" → SQS FIFO "replay events, multiple consumers" → Kinesis

Ba metric SQS quan trọng: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | đang chờ xử lý | | ApproximateNumberOfMessagesNotVisible | đang được xử lý | | ApproximateAgeOfOldestMessage | có bị kẹt không |

⚠ Vì sao dùng "backlog per instance":

Đặt mục tiêu "500 thông điệp trong hàng đợi"
    → 2 máy: mỗi máy gánh 250 → quá tải
    → 50 máy: mỗi máy gánh 10 → thừa máy
        ↓
    Chia cho số máy làm con số độc lập với quy mô

Công thức tính mục tiêu:

Mục tiêu = (job một máy xử lý mỗi phút) × (thời gian chờ chấp nhận được)

Ví dụ: 10 job/phút mỗi máy, chấp nhận chờ 2 phút
    → mục tiêu backlog mỗi instance = 20

Ba tham số quan trọng của SQS: | Tham số | Mặc định | Lưu ý | |---|---|---| | Visibility timeout | 30 giây | ≥ thời gian xử lý | | Message retention | 4 ngày | tối đa 14 ngày | | WaitTimeSeconds | 0 | đặt 20 — long polling |

⚠ Dead-letter queue là bắt buộc:

aws sqs set-queue-attributes --queue-url $URL --attributes '{
  "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"3\"}"}'

Không có DLQ: job lỗi quay vòng mãi
    → làm metric co giãn SAI
    → ASG thêm máy để xử lý một job không xử lý được

Ba yêu cầu để tầng tính toán thật sự stateless: | Yêu cầu | Chi tiết | |---|---| | Không lưu gì trên đĩa cục bộ | dùng S3 hoặc EFS | | Không giữ session trong bộ nhớ | | | Xử lý lại cùng job phải vô hại | idempotent |

⚠ Vế thứ ba quan trọng vì SQS Standard giao ÍT NHẤT MỘT LẦN:

Cùng một job có thể được giao hai lần
    → nếu job ghi vào CSDL thì phải chống trùng
        ↓
    Dùng khoá nghiệp vụ suy ra từ nội dung job

Ba lưu ý về scale in: | Lưu ý | Chi tiết | |---|---| | ScaleInCooldown dài hơn scale out | | | Lifecycle hook để xử lý nốt job | | | Ứng dụng xử lý SIGTERM | |

Lifecycle hook:

aws autoscaling put-lifecycle-hook --auto-scaling-group-name asg-xu-ly \
  --lifecycle-hook-name cho-xu-ly-xong \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 300

Ba cách xử lý job chạy lâu: | Cách | Chi tiết | |---|---| | Gia hạn visibility timeout động | | | Chia job thành bước nhỏ | | | Step Functions với callback pattern | quá 12 giờ |

Ba lựa chọn thay thế: | Lựa chọn | Khi nào | |---|---| | AWS Batch | job theo lô, tự cấp máy | | Lambda đọc SQS | job dưới 15 phút | | ECS Service Auto Scaling | nếu chạy container |

Ba cách giảm chi phí: | Cách | Chi tiết | |---|---| | Spot cho tầng xử lý | job idempotent | | Long polling giảm phí request | | | Gộp lô 10 thông điệp mỗi lần | |

Ba metric theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | thời gian chờ thật | | GroupInServiceInstances | ASG có phản ứng không | | Số thông điệp trong DLQ | |

Và một lời khuyên: hãy đặt alarm trên ApproximateAgeOfOldestMessage, không chỉ trên độ dài hàng đợi. Hàng đợi ngắn mà thông điệp cũ nghĩa là có job nào đó đang quay vòng mà không ai xử lý được — và đó là loại sự cố mà đồ thị số lượng thông điệp không hề cho thấy.

Câu 1002 Chọn nhiều đáp án AWS Database

A company runs a web application that serves weather updates. The application runs on a fleet of Amazon EC2 instances in a Multi-AZ Auto scaling group behind an Application Load Balancer (ALB). The instances store data in an Amazon Aurora database. A solutions architect needs to make the application more resilient to sporadic increases in request rates.

Which architecture should the solutions architect implement? (Select TWO.)

  1. A

    Add an Amazon CloudFront distribution in front of the ALB
  2. B

    Add an AWS Global Accelerator endpoint
  3. C

    Add Amazon Aurora Replicas
  4. D

    Add an AWS Transit Gateway to the Availability Zones
  5. E

    Add and AWS WAF in front of the ALB
Xem giải thích

Đáp án

A và C.

  • A — Thêm một CloudFront distribution phía trước ALB
  • C — Thêm Aurora Replica

Vì sao đúng

Đề nêu hai tầng có thể nghẽn, và mỗi hành động lo một tầng: | Tầng | Vấn đề khi tải tăng đột ngột | Giải bằng | |---|---|---| | Tầng web (EC2 sau ALB) | quá nhiều request | A: CloudFront cache và giảm tải | | Tầng CSDL (Aurora) | quá nhiều truy vấn đọc | C: thêm replica |

Vì sao CloudFront giúp với "sporadic increases":

Ứng dụng dự báo thời tiết
    → cùng một bản tin được HÀNG NGHÌN người xem
        ↓
    CloudFront cache một lần, phục vụ tất cả
    → EC2 chỉ chịu MỘT request thay vì hàng nghìn

Cấu hình cache cho nội dung nửa động:

{"DefaultCacheBehavior": {
  "TargetOriginId": "alb-goc",
  "ViewerProtocolPolicy": "redirect-to-https",
  "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6",
  "MinTTL": 0, "DefaultTTL": 60, "MaxTTL": 300}}

Bản tin thời tiết cập nhật vài phút một lần
    → TTL 60 giây đã giảm tải rất nhiều
    → mà dữ liệu vẫn đủ mới

Và Aurora Replica cho tầng dữ liệu:

aws rds create-db-instance --db-instance-identifier replica-1 \
  --db-cluster-identifier cum-thoi-tiet \
  --db-instance-class db.r6g.xlarge --engine aurora-postgresql

⚠ Aurora Replica chia sẻ CÙNG tầng lưu trữ:

Không nhân đôi dung lượng
    → chỉ trả tiền instance
    → độ trễ sao chép thường dưới 100 ms
        ↓
    Thêm replica là cách rẻ và nhanh nhất để tăng sức đọc

Ứng dụng dùng reader endpoint:

Ghi:  cum.cluster-abc.ap-southeast-1.rds.amazonaws.com
Đọc:  cum.cluster-ro-abc.ap-southeast-1.rds.amazonaws.com

Và Aurora Auto Scaling tự thêm replica:

aws application-autoscaling register-scalable-target \
  --service-namespace rds --resource-id cluster:cum-thoi-tiet \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --min-capacity 1 --max-capacity 8

aws application-autoscaling put-scaling-policy \
  --service-namespace rds --resource-id cluster:cum-thoi-tiet \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --policy-name theo-cpu --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{"TargetValue":60.0,
    "PredefinedMetricSpecification":{
      "PredefinedMetricType":"RDSReaderAverageCPUUtilization"}}'

Ba lợi ích của cặp A + C: | Lợi ích | Chi tiết | |---|---| | Giảm tải ở CẢ hai tầng | | | CloudFront còn giảm độ trễ toàn cầu | | | Không đổi kiến trúc | |

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

  • **B. Thêm một AWS Global Accelerator endpoint — đây là phương án gần nhất vì cũng cải thiện đường mạng, nhưng Global Accelerator KHÔNG cache: mọi request vẫn tới ALB và EC2. Nó giúp độ trễ, không giúp chịu tải.
  • **E. Thêm AWS WAF trước ALB — WAF lọc lưu lượng độc hại (SQLi, XSS, bot). Nó có rate-based rule để chặn lạm dụng, nhưng đề nói tải tăng là từ người dùng thật, không phải tấn công.
  • **D. Thêm Transit Gateway cho các Availability Zone — hiểu sai vai trò: Transit Gateway nối các VPC với nhau, không liên quan tới việc chịu tải trong một VPC. Và các AZ trong một VPC vốn đã thông nhau.

Ghi nhớ

⚠ Nguyên tắc gốc:

Muốn chịu tải tăng, phải xử lý MỌI tầng có thể nghẽn. Cache ở trước để giảm số request; thêm sức đọc ở CSDL cho phần còn lại.

Từ khoá nhận diện:

"resilient to increases in request rates" → CloudFront + read replica "reduce latency globally, non-HTTP" → Global Accelerator "block malicious traffic" → WAF "connect multiple VPCs" → Transit Gateway

⚠ CloudFront và Global Accelerator — bảng phải thuộc: | | CloudFront | Global Accelerator | |---|---|---| | Có cache | ✅ | ❌ | | Giảm tải origin | ✅ | ❌ | | Giao thức | HTTP/HTTPS | TCP, UDP | | IP | thay đổi | 2 IP tĩnh |

Muốn GIẢM TẢI → CloudFront
Muốn GIẢM ĐỘ TRỄ cho giao thức không phải HTTP → Global Accelerator

Ba cách giảm tải cho tầng web: | Cách | Chi tiết | |---|---| | CloudFront cache | ← câu này | | ASG co giãn theo request count | | | Tách nội dung tĩnh sang S3 | |

⚠ Ba cách giảm tải đọc cho CSDL: | Cách | Giảm gì | |---|---| | Read replica / Aurora Replica | phân tán truy vấn | | ElastiCache | SỐ truy vấn | | RDS Proxy | số kết nối |

Với dự báo thời tiết, ElastiCache cũng rất hợp:

Cùng một bản tin được truy vấn hàng nghìn lần
    → cache kết quả 60 giây
    → CSDL chỉ chịu một truy vấn mỗi phút

⚠ Aurora Replica và RDS Read Replica: | | Aurora Replica | RDS Read Replica | |---|---|---| | Cơ chế | chia sẻ tầng lưu trữ | binlog | | Độ trễ | < 100 ms | giây | | Dung lượng thêm | không | nhân đôi | | Số tối đa | 15 | 5 |

Bốn endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance ghi | | Reader | cân bằng qua mọi replica | | Custom | nhóm tự chọn | | Instance | một instance |

⚠ Cân bằng qua DNS có hạn chế:

Cân bằng xảy ra lúc PHÂN GIẢI DNS
    → connection pool giữ kết nối lâu
    → truy vấn dồn vào một replica
        ↓
    Đặt TTL ngắn, hoặc dùng RDS Proxy

Ba lỗi làm hỏng tỷ lệ cache hit của CloudFront: | Lỗi | Hậu quả | |---|---| | Forward mọi cookie | mỗi khách một bản cache | | Forward mọi query string | ?utm_source= tách cache | | TTL quá ngắn | |

Ba managed cache policy: | Policy | Dùng cho | |---|---| | CachingOptimized | nội dung tĩnh | | CachingDisabled | nội dung động hoàn toàn | | Tự tạo với TTL ngắn | nội dung nửa động ← câu này |

Ba lưu ý về replica lag: | Lưu ý | Chi tiết | |---|---| | Aurora lag thường < 100 ms | | | Nhưng không bằng 0 | | | Đọc-sau-ghi có thể thấy dữ liệu cũ | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate của CloudFront | cache có hiệu quả không | | AuroraReplicaLag | độ trễ dữ liệu | | DatabaseConnections theo instance | có cân bằng không |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudFront giảm phí truyền của ALB | | | Replica tính phí instance đầy đủ | | | Aurora Auto Scaling tự bớt replica khi vắng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo tỷ lệ cache hit sau vài ngày | | | Kiểm tra tải đọc đã chuyển sang replica | | | Thử tải để xem hai tầng chịu được không | |

Và một lời khuyên: hãy đo tỷ lệ cache hit của CloudFront trước khi kết luận nó đã giúp. Với ứng dụng có phần cá nhân hoá, cấu hình mặc định thường forward quá nhiều cookie và header — và một distribution có tỷ lệ trúng 5% chỉ thêm một chặng mạng chứ không giảm được tải nào.

Câu 1003 AWS Database

Over 500 TB of data must be analyzed using standard SQL business intelligence tools. The dataset consists of a combination of structured data and unstructured data. The unstructured data is small and stored on Amazon S3. Which AWS services are most suitable for performing analytics on the data?

  1. A

    Amazon ElastiCache for Redis with cluster mode enabled
  2. B

    Amazon Redshift with Amazon Redshift Spectrum
  3. C

    Amazon DynamoDB with Amazon DynamoDB Accelerator (DAX)
  4. D

    Amazon RDS MariaDB with Amazon Athena
Xem giải thích

Đáp án

B — Amazon Redshift với Amazon Redshift Spectrum.

Vì sao đúng

Đề nêu bốn dữ kiện, và cặp này khớp từng cái: | Dữ kiện | Cách đáp ứng | |---|---| | Hơn 500 TB dữ liệu cần phân tích | Redshift là kho dữ liệu quy mô petabyte | | **Dùng công cụ BI với SQL chuẩn | Redshift dùng SQL chuẩn (PostgreSQL) | | Dữ liệu CÓ CẤU TRÚC | bảng trong Redshift | | Dữ liệu PHI CẤU TRÚC nằm trên S3 | Redshift Spectrum truy vấn thẳng trên S3 |

⚠ Redshift Spectrum là mảnh ghép quyết định:

Spectrum cho phép Redshift truy vấn dữ liệu NẰM TRONG S3
    → không phải nạp vào cụm
        ↓
    Một câu SQL JOIN được cả:
    → bảng trong Redshift (dữ liệu có cấu trúc)
    → bảng ngoài trên S3 (dữ liệu phi cấu trúc)

Tạo external schema trỏ vào Glue Data Catalog:

CREATE EXTERNAL SCHEMA du_lieu_s3
FROM DATA CATALOG
DATABASE 'kho_du_lieu'
IAM_ROLE 'arn:aws:iam::123456789012:role/VaiTroRedshiftSpectrum'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

Rồi JOIN hai nguồn trong một truy vấn:

SELECT k.ten_khach_hang,
       count(s.ma_su_kien) AS so_su_kien
FROM ban_hang k                          -- bảng trong Redshift
JOIN du_lieu_s3.su_kien_log s            -- bảng ngoài trên S3
  ON k.ma_khach = s.ma_khach
WHERE s.ngay >= '2026-08-01'
GROUP BY 1 ORDER BY 2 DESC;

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải nạp dữ liệu S3 vào cụm | tiết kiệm dung lượng | | SQL chuẩn — công cụ BI kết nối thẳng | | | Spectrum tự co giãn tính toán | |

Vế đầu quan trọng với 500 TB:

Nạp hết 500 TB vào cụm Redshift
    → cần cụm rất lớn, rất đắt
        ↓
    Giữ dữ liệu nguội trên S3, chỉ nạp dữ liệu nóng
    → cụm nhỏ hơn nhiều, Spectrum lo phần còn lại

Và Redshift kết nối với công cụ BI qua JDBC/ODBC:

QuickSight, Tableau, Power BI, Looker
    → đều kết nối Redshift bằng driver chuẩn
        ↓
    "standard SQL business intelligence tools"

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

  • **D. RDS MariaDB với Amazon Athena — đây là phương án gần nhất vì cũng ghép một CSDL SQL với công cụ truy vấn S3, nhưng RDS MariaDB không phải kho dữ liệu: nó là CSDL giao dịch, không xử lý nổi phân tích trên 500 TB. Và Athena với RDS là hai hệ thống rời rạc — không JOIN được trong một truy vấn.
  • **A. ElastiCache for Redis — bộ nhớ đệm trong RAM, không phải công cụ phân tích, và không thể chứa 500 TB.
  • **C. DynamoDB với DAX — CSDL NoSQL key-value, không hỗ trợ SQL và không phù hợp cho truy vấn phân tích phức tạp.

Ghi nhớ

⚠ Ba công cụ truy vấn SQL trên AWS — bảng phải thuộc: | Công cụ | Dùng cho | |---|---| | Amazon Redshift | kho dữ liệu, phân tích quy mô lớn, BI | | Amazon Athena | truy vấn ad-hoc trên S3, serverless | | Amazon RDS / Aurora | CSDL GIAO DỊCH (OLTP) |

Từ khoá nhận diện:

"data warehouse", "BI tools", "hundreds of TB", "complex joins" → Redshift "query S3 directly, serverless, ad-hoc" → Athena "structured in warehouse + unstructured in S3" → Redshift + Spectrum "transactional application" → RDS/Aurora

⚠ Redshift Spectrum và Athena — bảng phân biệt: | | Redshift Spectrum | Amazon Athena | |---|---|---| | Cần cụm Redshift | ✅ | ❌ serverless | | JOIN với bảng trong kho | ✅ | ❌ | | Tính phí | cụm + dữ liệu quét | chỉ dữ liệu quét | | Dùng chung Glue Data Catalog | ✅ | ✅ |

Đã có cụm Redshift và cần JOIN → Spectrum
Chỉ truy vấn S3 thỉnh thoảng    → Athena

⚠ Redshift Serverless đáng biết:

aws redshift-serverless create-workgroup \
  --workgroup-name nhom-phan-tich \
  --namespace-name khong-gian-phan-tich \
  --base-capacity 32

Không phải chọn số node và loại node
    → tự co giãn theo RPU
        ↓
    Với tải phân tích không đều, đây là lựa chọn ít việc hơn

Ba khái niệm của Redshift: | Khái niệm | Nghĩa | |---|---| | Leader node | nhận truy vấn, lập kế hoạch | | Compute node | thực thi, lưu dữ liệu | | Slice | đơn vị song song trong node |

⚠ Ba yếu tố quyết định hiệu năng Redshift: | Yếu tố | Chi tiết | |---|---| | Distribution key | cách phân tán dòng giữa các node | | Sort key | thứ tự lưu trong node | | Compression (encoding) | giảm I/O |

Ba kiểu distribution: | Kiểu | Khi nào | |---|---| | KEY | JOIN thường xuyên theo cột đó | | ALL | bảng nhỏ, nhân bản mọi node | | EVEN | không có mẫu JOIN rõ ràng | | AUTO | để Redshift tự chọn — mặc định |

CREATE TABLE ban_hang (
    ma_khach bigint,
    ngay date,
    doanh_thu decimal(12,2)
)
DISTSTYLE KEY DISTKEY (ma_khach)
SORTKEY (ngay);

⚠ Ba lưu ý về hiệu năng Spectrum: | Lưu ý | Chi tiết | |---|---| | Dùng định dạng cột (Parquet, ORC) | giảm dữ liệu quét rất nhiều | | Phân vùng dữ liệu trên S3 | | | Nén tệp | |

Phân vùng giảm chi phí mạnh:

ALTER TABLE du_lieu_s3.su_kien_log
ADD PARTITION (nam='2026', thang='08')
LOCATION 's3://kho-du-lieu/su-kien/nam=2026/thang=08/';

Truy vấn lọc theo nam và thang
    → chỉ quét đúng phân vùng đó
    → thay vì quét cả 500 TB

Ba lưu ý về chi phí Redshift: | Khoản | Chi tiết | |---|---| | Cụm tính theo giờ node | | | Spectrum tính theo dữ liệu QUÉT | | | Reserved node giảm tới 75% | |

Ba tính năng đáng biết: | Tính năng | Việc | |---|---| | Concurrency Scaling | tự thêm cụm tạm khi nhiều truy vấn | | RA3 node với managed storage | tách tính toán và lưu trữ | | Data sharing | chia sẻ dữ liệu giữa cụm |

⚠ RA3 node là lựa chọn hiện đại:

Node DC2 cũ: lưu trữ gắn với node
    → muốn thêm dung lượng phải thêm node
        ↓
RA3: lưu trữ quản lý riêng trên S3
    → chọn node theo nhu cầu TÍNH TOÁN
    → dung lượng tự mở rộng

Ba lưu ý về nạp dữ liệu: | Lưu ý | Chi tiết | |---|---| | Dùng lệnh COPY từ S3 | nhanh nhất | | Chia thành nhiều tệp bằng số slice | song song hoá | | Chạy ANALYZE và VACUUM định kỳ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem kế hoạch truy vấn (EXPLAIN) | | | Kiểm tra dữ liệu quét của Spectrum | SVL_S3QUERY_SUMMARY | | Theo dõi hàng đợi truy vấn | |

Và một lời khuyên: hãy chuyển dữ liệu trên S3 sang Parquet có phân vùng trước khi dùng Spectrum. Spectrum tính tiền theo lượng dữ liệu quét, và cùng một câu truy vấn trên CSV không nén so với Parquet phân vùng có thể chênh nhau hàng trăm lần chi phí.

Câu 1004 AWS Migration & Transfer

A company has acquired another business and needs to migrate their 50TB of data into AWS within 1 month. They also require a secure, reliable and private connection to the AWS cloud.

How are these requirements best accomplished?

  1. A

    Provision an AWS VPN CloudHub connection and migrate the data over redundant links
  2. B

    Launch a Virtual Private Gateway (VPG) and migrate the data over the AWS VPN
  3. C

    Provision an AWS Direct Connect connection and migrate the data over the link
  4. D

    Migrate data using AWS Snowball. Provision an AWS VPN initially and order a Direct Connect link
Xem giải thích

Đáp án

D — Di chuyển dữ liệu bằng AWS Snowball; dựng VPN trước mắt và đặt một đường Direct Connect cho lâu dài.

Vì sao đúng

Đề nêu hai yêu cầu tách bạch, và phương án này giải quyết cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Di chuyển 50 TB trong 1 THÁNG | Snowball — không phụ thuộc băng thông | | Cần kết nối AN TOÀN, TIN CẬY và RIÊNG TƯ | VPN ngay + DX về sau |

⚠ Đây là hai bài toán khác nhau, đừng gộp làm một:

Bài toán 1: chuyển 50 TB MỘT LẦN
    → Snowball là nhanh nhất và rẻ nhất

Bài toán 2: kết nối LÂU DÀI, riêng tư
    → Direct Connect là tốt nhất
    → nhưng mất hàng tuần tới hàng tháng để cung cấp
        ↓
    VPN dựng trong vài giờ, dùng tạm cho tới khi DX sẵn sàng

Vì sao không chờ DX rồi chuyển dữ liệu qua đó:

DX mất hàng tuần tới hàng tháng để cung cấp
    → mà hạn di chuyển là 1 tháng
        ↓
    Chờ DX xong mới bắt đầu chuyển là hết hạn

Đặt Snowball:

aws snowball create-job --job-type IMPORT \
  --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::kho-du-lieu"}]}' \
  --address-id ADID123 --snowball-type EDGE_S \
  --shipping-option EXPRESS \
  --role-arn <arn-role> --kms-key-arn <arn-khoa>

Dựng VPN ngay:

aws ec2 create-customer-gateway --type ipsec.1 \
  --public-ip 203.0.113.10 --bgp-asn 65000

aws ec2 create-vpn-gateway --type ipsec.1
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-abc --vpc-id vpc-abc

aws ec2 create-vpn-connection --type ipsec.1 \
  --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc \
  --options '{"StaticRoutesOnly":false}'

Và đặt DX song song:

aws directconnect create-connection \
  --location EqSG2 --bandwidth 1Gbps --connection-name ket-noi-chinh

Ba lợi ích của chiến lược hai giai đoạn: | Lợi ích | Chi tiết | |---|---| | Có kết nối ngay từ ngày đầu | VPN | | Dữ liệu lớn không chiếm băng thông | Snowball | | Kết nối tốt nhất cho lâu dài | DX |

Và khi DX xong, VPN thành đường dự phòng:

DX sẵn sàng → chuyển lưu lượng chính sang DX
    → giữ VPN làm backup
        ↓
    BGP tự chuyển khi DX hỏng
    → đây là kiến trúc lai được khuyến nghị

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

  • **C. Dựng Direct Connect và chuyển dữ liệu qua đường đó — đây là phương án gần nhất vì DX đúng là kết nối riêng tư tốt nhất, nhưng nó không kịp hạn: DX mất hàng tuần tới hàng tháng để cung cấp, và đề chỉ có 1 tháng cho cả việc di chuyển.
  • **B. Dựng Virtual Private Gateway và chuyển dữ liệu qua VPN — VPN chạy trên chính đường Internet hiện có, giới hạn khoảng 1,25 Gbps mỗi tunnel. Với 50 TB thì rất chậm và chiếm hết băng thông của công ty.
  • **A. Dựng AWS VPN CloudHub và chuyển qua nhiều đường — CloudHub là mô hình nối nhiều chi nhánh với nhau qua AWS, không phải công cụ tăng băng thông cho việc di chuyển dữ liệu.

Ghi nhớ

⚠ Ba cách kết nối tại chỗ với AWS — bảng phải thuộc: | Cách | Thời gian dựng | Băng thông | Mã hoá | |---|---|---|---| | Site-to-Site VPN | vài giờ | ~1,25 Gbps mỗi tunnel | ✅ IPsec | | Direct Connect | hàng tuần - tháng | 50 Mbps - 400 Gbps | ❌ mặc định không | | DX + VPN | | cao | ✅ |

⚠ Direct Connect KHÔNG mã hoá — điều phải nhớ:

DX là đường riêng, không qua Internet
    → nhưng dữ liệu KHÔNG được mã hoá
        ↓
    Dữ liệu nhạy cảm: chạy VPN IPsec trên DX,
    hoặc dùng MACsec

Từ khoá nhận diện:

"large data + deadline + limited bandwidth" → Snowball "need connection NOW" → VPN "consistent bandwidth long-term" → Direct Connect "secure + reliable + private" → DX (có thể kèm VPN)

⚠ Quy tắc ước lượng thời gian truyền:

Thời gian (ngày) ≈ Dung lượng (TB) × 8.000.000
                   ÷ (Băng thông Mbps × 86.400)

Ví dụ 50 TB qua 100 Mbps:
    50 × 8.000.000 / (100 × 86.400) ≈ 46 NGÀY
        ↓
    Quá hạn 1 tháng → phải dùng Snowball

Ba thiết bị họ Snow: | Thiết bị | Dung lượng | |---|---| | Snowcone | 8-14 TB | | Snowball Edge Storage Optimized | ~80 TB ← đủ cho 50 TB | | Snowmobile | tới 100 PB |

Ba mốc thời gian của Snowball: | Mốc | Thời gian | |---|---| | Vận chuyển tới nơi | 2-5 ngày | | Chép dữ liệu | tuỳ dung lượng và mạng nội bộ | | Vận chuyển về + nạp vào S3 | 3-7 ngày |

Ba đặc điểm bảo mật của Snowball: | Đặc điểm | Chi tiết | |---|---| | Mã hoá AES-256, khoá trong KMS | | | Khoá KHÔNG lưu trên thiết bị | | | Vỏ chống phá, có TPM | |

Ba thành phần của Site-to-Site VPN: | Thành phần | Ở đâu | |---|---| | Customer Gateway (CGW) | phía bạn | | Virtual Private Gateway hoặc Transit Gateway | phía AWS | | VPN Connection | hai tunnel IPsec |

⚠ Dự phòng VPN — phía nào cần lo:

AWS đã cho SẴN hai tunnel ở hai AZ
    → dự phòng phía AWS có sẵn
        ↓
    Điểm hỏng còn lại là THIẾT BỊ CGW phía bạn
    → dùng hai thiết bị CGW để bỏ nốt

Ba loại VIF của Direct Connect: | Loại | Nối tới | |---|---| | Private VIF | VPC qua VGW | | Transit VIF | Transit Gateway (cần DX ≥ 1 Gbps) | | Public VIF | dịch vụ AWS công khai, và endpoint VPN |

⚠ Bốn mức phục hồi của DX: | Mức | Cấu hình | SLA | |---|---|---| | Development/Test | 1 kết nối, 1 location | không | | High Resiliency | 2 kết nối, 2 location | 99,9% | | Maximum Resiliency | 2 kết nối ở mỗi trong 2 location | 99,99% |

Ba lưu ý về AWS VPN CloudHub: | Lưu ý | Chi tiết | |---|---| | Nối nhiều chi nhánh với nhau QUA AWS | | | Dùng một VGW làm trung tâm | | | Không tăng băng thông cho việc di chuyển | |

Ba lưu ý khi kết hợp Snowball và DataSync: | Lưu ý | Chi tiết | |---|---| | Snowball chở khối lượng lớn ban đầu | | | DataSync đồng bộ phần thay đổi sau | | | Phần chênh nhỏ nên mạng kém vẫn kham được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Snowball: phí thuê theo ngày + vận chuyển | | | VPN: ~0,05 USD/giờ mỗi connection | | | DX: phí cổng theo giờ + phí chéo nhà mạng | |

⚠ Data transfer IN vào AWS luôn MIỄN PHÍ — dù qua Snowball, VPN hay DX.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra hai tunnel VPN đều UP | | | So số object trong S3 sau khi nạp Snowball | | | Đo băng thông thật của DX khi sẵn sàng | |

Và một lời khuyên: hãy đặt Direct Connect ngay ngày đầu tiên, song song với việc đặt Snowball. Thời gian cung cấp DX là phần duy nhất bạn không kiểm soát được — và một đơn hàng đặt muộn hai tuần sẽ đẩy cả kế hoạch chậm đúng hai tuần đó.

Câu 1005 AWS Machine Learning

A computer scientist working for a university is looking to build a machine learning application which will use telemetry data to predict weather for a given area at a given time. This application would benefit from using managed services and will need to find a solution which uses third party data within the application.


Which of the following combinations of services will deliver the best solution?

  1. A

    Use a TensorFlow AMI from the AWS Marketplace to build the machine learning part of the application and use AWS Data Exchange to gain access to the third-party telemetry data.
  2. B

    Use Amazon SageMaker to build the machine learning part of the application and use AWS DataSync to gain access to the third-party telemetry data.
  3. C

    Use a TensorFlow AMI from the AWS Marketplace to build the machine learning part of the application and use AWS DataSync to gain access to the third-party telemetry data.
  4. D

    Use Amazon SageMaker to build the machine learning part of the application and use AWS Data Exchange to gain access to the third-party telemetry data.
Xem giải thích

Đáp án

D — Dùng Amazon SageMaker xây phần học máy, và AWS Data Exchange để lấy dữ liệu telemetry của bên thứ ba.

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi phần được một dịch vụ đảm nhiệm: | Yêu cầu | Cách đáp ứng | |---|---| | Xây ứng dụng học máy | SageMaker — nền tảng ML được quản lý | | Dùng DỊCH VỤ ĐƯỢC QUẢN LÝ | SageMaker thay vì tự dựng trên EC2 | | Dùng dữ liệu của BÊN THỨ BA | AWS Data Exchange — chợ dữ liệu |

⚠ "Third party data" là từ khoá chỉ thẳng vào Data Exchange:

AWS Data Exchange = chợ để TÌM, ĐĂNG KÝ và DÙNG
    bộ dữ liệu của nhà cung cấp bên thứ ba
        ↓
    Dữ liệu tự động được giao vào S3 của bạn
    → hoặc truy cập qua API, Redshift, Lake Formation

Đây là lý do loại cả B và C (chúng dùng DataSync).

⚠ DataSync KHÔNG phải để lấy dữ liệu bên thứ ba:

DataSync = di chuyển dữ liệu giữa NƠI LƯU TRỮ CỦA BẠN
    → tại chỗ ↔ AWS, hoặc giữa các dịch vụ AWS
        ↓
    Nó không có chợ dữ liệu, không có nhà cung cấp nào

Đăng ký bộ dữ liệu:

aws dataexchange list-data-sets --origin ENTITLED

aws dataexchange create-job --type EXPORT_ASSETS_TO_S3 \
  --details '{"ExportAssetsToS3":{
    "DataSetId":"<id>","RevisionId":"<id>",
    "AssetDestinations":[{"AssetId":"<id>",
      "Bucket":"kho-du-lieu-thoi-tiet","Key":"telemetry/"}]}}'

Và SageMaker cho phần học máy:

import sagemaker
from sagemaker.sklearn.estimator import SKLearn

phien = sagemaker.Session()
uoc_luong = SKLearn(
    entry_point='huan_luyen.py',
    role='arn:aws:iam::123456789012:role/VaiTroSageMaker',
    instance_type='ml.m5.xlarge',
    framework_version='1.2-1')

uoc_luong.fit({'train': 's3://kho-du-lieu-thoi-tiet/telemetry/'})
du_doan = uoc_luong.deploy(initial_instance_count=1,
                           instance_type='ml.m5.large')

Ba lợi ích của SageMaker so với tự dựng TensorFlow trên EC2: | Lợi ích | Chi tiết | |---|---| | Không quản lý máy chủ huấn luyện | tự cấp và thu hồi | | Có sẵn notebook, pipeline, model registry | | | Triển khai endpoint suy luận bằng một dòng | |

Vế đầu là khác biệt lớn về chi phí:

EC2 với TensorFlow AMI: máy chạy suốt, bạn phải nhớ tắt
SageMaker training job:  tự cấp máy, chạy xong TỰ TẮT
        ↓
    Chỉ trả tiền đúng thời gian huấn luyện

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

  • **A. Dùng TensorFlow AMI từ Marketplace + Data Exchange — đây là phương án gần nhất vì vế dữ liệu hoàn toàn đúng, nhưng tự dựng TensorFlow trên EC2 là công vận hành cao: phải vá lỗi, tự quản lý máy huấn luyện, tự dựng endpoint suy luận. Đề nói rõ muốn dùng dịch vụ được quản lý.
  • **B. SageMaker + DataSync — vế học máy đúng, nhưng DataSync không lấy được dữ liệu bên thứ ba: nó chỉ di chuyển dữ liệu giữa các kho lưu trữ mà bạn đã có quyền.
  • **C. TensorFlow AMI + DataSync — sai cả hai vế.

Ghi nhớ

⚠ Ba dịch vụ dữ liệu dễ lẫn — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS Data Exchange | TÌM và ĐĂNG KÝ dữ liệu của BÊN THỨ BA | | AWS DataSync | DI CHUYỂN dữ liệu của CHÍNH BẠN | | AWS Transfer Family | máy chủ SFTP/FTPS được quản lý |

Từ khoá nhận diện:

"third-party data", "data provider", "subscribe to a dataset" → AWS Data Exchange "migrate data from on-premises" → DataSync "build ML models with managed services" → SageMaker "pre-trained AI, no ML expertise" → dịch vụ AI cấp cao |

⚠ Ba tầng dịch vụ AI/ML của AWS: | Tầng | Dịch vụ | Dùng khi | |---|---|---| | Dịch vụ AI cấp cao | Rekognition, Comprehend, Transcribe, Forecast | không cần chuyên môn ML | | SageMaker | xây, huấn luyện, triển khai | cần mô hình riêng | | Framework trên EC2 | TensorFlow, PyTorch tự cài | kiểm soát tối đa |

⚠ Amazon Forecast đáng biết cho bài toán dự báo:

Đề nói "dự đoán thời tiết theo khu vực và thời gian"
    → đó là bài toán CHUỖI THỜI GIAN
        ↓
    Amazon Forecast là dịch vụ chuyên cho việc này
    → không cần viết mô hình
        ↓
    Nhưng đề đưa SageMaker nên đó là đáp án

Ba khả năng chính của SageMaker: | Khả năng | Việc | |---|---| | SageMaker Studio | IDE cho ML | | Training job | huấn luyện có quản lý | | Endpoint | triển khai suy luận |

Ba chế độ suy luận của SageMaker: | Chế độ | Khi nào | |---|---| | Real-time endpoint | độ trễ thấp, luôn sẵn sàng | | Serverless inference | tải không đều, không trả khi rảnh | | Batch transform | suy luận theo lô | | Asynchronous inference | payload lớn, xử lý lâu |

⚠ Serverless inference tiết kiệm cho tải thưa:

aws sagemaker create-endpoint-config \
  --endpoint-config-name cau-hinh-serverless \
  --production-variants '[{"VariantName":"chinh",
    "ModelName":"mo-hinh-thoi-tiet",
    "ServerlessConfig":{"MemorySizeInMB":2048,"MaxConcurrency":10}}]'

Ba tính năng của Data Exchange: | Tính năng | Chi tiết | |---|---| | Đăng ký bộ dữ liệu miễn phí hoặc trả phí | | | Tự động nhận bản cập nhật (revision) | | | Giao vào S3, hoặc truy cập qua API/Redshift | |

Tự động xuất khi có bản mới:

aws dataexchange create-event-action \
  --event '{"RevisionPublished":{"DataSetId":"<id>"}}' \
  --action '{"ExportRevisionToS3":{
    "RevisionDestination":{"Bucket":"kho-du-lieu-thoi-tiet",
      "KeyPattern":"telemetry/${Revision.CreatedAt}/"}}}'

Nhà cung cấp đăng dữ liệu mới
    → tự động xuất vào S3 của bạn
        ↓
    Không phải theo dõi và tải bằng tay

Ba lưu ý về chi phí SageMaker: | Khoản | Chi tiết | |---|---| | Training job tính theo giây | tự tắt khi xong | | Endpoint tính theo GIỜ — nhớ xoá khi không dùng | | | Notebook instance cũng tính theo giờ | |

⚠ Vế thứ hai là chi phí ẩn phổ biến nhất:

Tạo endpoint để thử → quên xoá
    → chạy 24/7 hàng tháng
        ↓
    Đặt alarm hoặc dùng serverless inference

Ba lưu ý về dữ liệu huấn luyện: | Lưu ý | Chi tiết | |---|---| | Lưu trên S3, dùng định dạng hiệu quả | | | SageMaker Feature Store cho đặc trưng dùng lại | | | Data Wrangler cho tiền xử lý | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | SageMaker chạy trong VPC được | | | Mã hoá dữ liệu và mô hình bằng KMS | | | IAM role riêng cho từng job | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra dữ liệu đã tới S3 | | | Xem log huấn luyện trong CloudWatch | | | Thử gọi endpoint suy luận | |

Và một lời khuyên: hãy đặt lịch tự động xoá endpoint SageMaker ở môi trường thử nghiệm. Endpoint tính phí theo giờ dù có ai gọi hay không, và một mô hình thử nghiệm bị quên là khoản chi âm thầm lớn nhất trong hầu hết dự án học máy.

Câu 1006 AWS Application Integration

A new application will run across multiple Amazon ECS tasks. Front-end application logic will process data and then pass that data to a back-end ECS task to perform further processing and write the data to a datastore. The Architect would like to reduce-interdependencies so failures do no impact other components.

Which solution should the Architect use?

  1. A

    Create an Amazon SQS queue that pushes messages to the back-end. Configure the front-end to add messages to the queue
  2. B

    Create an Amazon Kinesis Firehose delivery stream that delivers data to an Amazon S3 bucket, configure the front-end to write data to the stream and the back-end to read data from Amazon S3
  3. C

    Create an Amazon SQS queue and configure the front-end to add messages to the queue and the back-end to poll the queue for messages
  4. D

    Create an Amazon Kinesis Firehose delivery stream and configure the front-end to add data to the stream and the back-end to read data from the stream
Xem giải thích

Đáp án

C — Tạo một Amazon SQS queue, cấu hình tầng đầu đẩy thông điệp vào hàng đợi và tầng sau POLL hàng đợi để lấy thông điệp.

Vì sao đúng

Đề nêu ba dữ kiện, và SQS với mô hình poll là lời giải: | Dữ kiện | Cách đáp ứng | |---|---| | Tầng đầu xử lý rồi chuyển cho tầng sau | hàng đợi ở giữa | | Giảm PHỤ THUỘC LẪN NHAU | hai bên chỉ biết hàng đợi | | Lỗi ở một bên KHÔNG ảnh hưởng bên kia | hàng đợi giữ việc lại |

⚠ "Push" và "poll" — điểm phân biệt C với A:

SQS là mô hình KÉO (poll)
    → consumer chủ động gọi ReceiveMessage
        ↓
    SQS KHÔNG "đẩy" thông điệp tới ai cả
    → phương án A mô tả sai cách SQS hoạt động

Vì sao mô hình poll giúp giảm phụ thuộc:

Tầng sau chết hoặc quá tải
    → nó đơn giản là NGỪNG POLL
    → thông điệp nằm yên trong hàng đợi
        ↓
    Tầng đầu vẫn chạy bình thường, không biết gì
    → hồi phục xong thì poll tiếp

Tầng đầu gửi:

import boto3, json
sqs = boto3.client('sqs')

sqs.send_message(
    QueueUrl=URL,
    MessageBody=json.dumps({'ma_viec': 'abc123', 'du_lieu': ket_qua}))

Tầng sau poll:

while True:
    r = sqs.receive_message(QueueUrl=URL, MaxNumberOfMessages=10,
                            WaitTimeSeconds=20)      # long polling
    for m in r.get('Messages', []):
        xu_ly_va_ghi_datastore(json.loads(m['Body']))
        sqs.delete_message(QueueUrl=URL, ReceiptHandle=m['ReceiptHandle'])

⚠ DeleteMessage chỉ gọi SAU khi xử lý xong:

Xử lý lỗi giữa chừng → không gọi delete
    → hết visibility timeout → thông điệp quay lại hàng đợi
        ↓
    Task khác nhận và xử lý lại
    → không mất việc

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hai tầng co giãn độc lập | | | Lỗi một bên không lan sang bên kia | | | Hàng đợi đệm khi tải lệch | |

Và ECS co giãn theo độ dài hàng đợi:

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs --resource-id service/cum/tang-sau \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name theo-hang-doi --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{"TargetValue":10.0,
    "CustomizedMetricSpecification":{
      "MetricName":"ApproximateNumberOfMessagesVisible",
      "Namespace":"AWS/SQS",
      "Dimensions":[{"Name":"QueueName","Value":"hang-doi-xu-ly"}],
      "Statistic":"Average"}}'

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

  • **A. Tạo SQS queue "ĐẨY thông điệp tới tầng sau", tầng đầu thêm thông điệp — đây là phương án gần nhất và đúng ý tưởng dùng SQS, nhưng nó mô tả sai cách SQS hoạt động: SQS không đẩy tới bất kỳ ai; consumer phải chủ động poll. (SNS mới là dịch vụ đẩy.)
  • **D. Tạo Kinesis Firehose delivery stream, tầng đầu ghi vào stream và tầng sau đọc từ stream — Firehose là một chiều: nó nạp dữ liệu vào đích lưu trữ (S3, Redshift, OpenSearch). Không đọc lại được từ Firehose.
  • **B. Firehose giao vào S3, tầng sau đọc từ S3 — làm được nhưng nhiều tầng và có độ trễ: Firehose đệm 60-900 giây trước khi ghi, rồi tầng sau phải quét bucket. Phức tạp hơn hẳn một hàng đợi.

Ghi nhớ

⚠ Bốn dịch vụ nhắn tin — bảng phải thuộc: | Dịch vụ | Mô hình | Consumer | |---|---|---| | Amazon SQS | hàng đợi, KÉO (poll) | chủ động gọi | | Amazon SNS | pub/sub, ĐẨY | bị gọi | | Kinesis Data Streams | luồng, KÉO | nhiều consumer đọc lại được | | Kinesis Data Firehose | nạp MỘT CHIỀU vào đích | không đọc lại được |

⚠ Firehose và Data Streams — bảng phân biệt: | | Data Streams | Firehose | |---|---|---| | Đọc lại được | ✅ trong retention | ❌ | | Quản lý shard | có (hoặc on-demand) | không có gì | | Đích | consumer tự đọc | S3, Redshift, OpenSearch, HTTP | | Độ trễ | dưới giây | 60-900 giây (đệm) |

Từ khoá nhận diện:

"decouple, reduce interdependencies", "poll" → SQS "notify multiple subscribers" → SNS "multiple consumers read same stream, replay" → Kinesis Data Streams "load streaming data into S3/Redshift" → Firehose

Hai loại hàng đợi SQS: | Loại | Thứ tự | Thông lượng | |---|---|---| | Standard | cố gắng, không đảm bảo | không giới hạn | | FIFO | đảm bảo trong message group | 300 TPS (3.000 gộp lô) |

Ba tham số quan trọng: | Tham số | Mặc định | Lưu ý | |---|---|---| | Visibility timeout | 30 giây | ≥ thời gian xử lý | | Message retention | 4 ngày | tối đa 14 ngày | | WaitTimeSeconds | 0 | đặt 20 — long polling |

⚠ Long polling nên bật mặc định:

Short polling: gọi liên tục, phần lớn trả rỗng
    → trả tiền cho hàng triệu request vô ích
Long polling: giữ kết nối tới 20 giây chờ thông điệp
    → ít request hơn nhiều, độ trễ cũng thấp hơn

aws sqs set-queue-attributes --queue-url $URL \
  --attributes ReceiveMessageWaitTimeSeconds=20

⚠ Dead-letter queue là bắt buộc:

aws sqs set-queue-attributes --queue-url $URL --attributes '{
  "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"3\"}"}'

Không có DLQ: thông điệp lỗi quay vòng mãi
    → chiếm chỗ, làm metric co giãn sai

Ba lưu ý về idempotent: | Lưu ý | Chi tiết | |---|---| | Standard queue giao ÍT NHẤT MỘT LẦN | có thể trùng | | Consumer phải xử lý lại được | | | Dùng khoá nghiệp vụ chống ghi trùng | |

Ba lưu ý cho ECS làm consumer: | Lưu ý | Chi tiết | |---|---| | Task role cần sqs:ReceiveMessage, DeleteMessage | | | Xử lý SIGTERM để hoàn tất việc đang làm | | | stopTimeout đủ dài | |

⚠ SIGTERM quan trọng khi scale in:

ECS dừng task → gửi SIGTERM → chờ stopTimeout → SIGKILL
    → không xử lý SIGTERM thì việc đang làm bị cắt
        ↓
    Thông điệp quay lại hàng đợi (tốt)
    nhưng công đã làm bị phí

Ba mẫu kết hợp: | Mẫu | Việc | |---|---| | SNS → nhiều SQS | fan-out có độ bền | | SQS → Lambda | serverless consumer | | EventBridge → SQS | định tuyến rồi đệm |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng | | ApproximateAgeOfOldestMessage | có bị kẹt không | | Số thông điệp trong DLQ | |

Ba lưu ý về payload lớn: | Lưu ý | Chi tiết | |---|---| | Giới hạn 256 KB mỗi thông điệp | | | Extended Client Library lưu nội dung vào S3 | | | Thông điệp chỉ chứa con trỏ | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo số request | | | Long polling giảm mạnh | | | Gộp lô 10 thông điệp mỗi lần | |

Và một lời khuyên: hãy chỉ gọi DeleteMessage sau khi công việc đã hoàn tất và ghi xong. Xoá sớm là cách nhanh nhất để mất dữ liệu một cách âm thầm — thông điệp biến mất khỏi hàng đợi, tầng sau lỗi giữa chừng, và không có gì để thử lại.

Câu 1007 AWS Security, Identity, & Compliance

An application has been deployed on Amazon EC2 instances behind an Application Load Balancer (ALB). A Solutions Architect must improve the security posture of the application and minimize the impact of a DDoS attack on resources.

Which of the following solutions is MOST effective?

  1. A

    Enable access logs on the Application Load Balancer and configure Amazon CloudWatch to monitor the access logs and trigger a Lambda function when potential attacks are identified. Configure the Lambda function to modify the ALBs security group and block the attack.
  2. B

    Configure an AWS WAF ACL with rate-based rules. Enable the WAF ACL on the Application Load Balancer.
  3. C

    Create a custom AWS Lambda function that monitors for suspicious traffic and modifies a network ACL when a potential DDoS attack is identified.
  4. D

    Enable VPC Flow Logs and store them in Amazon S3. Use Amazon Athena to parse the logs and identify and block potential DDoS attacks.
Xem giải thích

Đáp án

B — Cấu hình một AWS WAF ACL với rate-based rule và gắn vào Application Load Balancer.

Vì sao đúng

Đề nêu hai yêu cầu, và WAF rate-based rule là công cụ chuyên dụng: | Yêu cầu | Cách đáp ứng | |---|---| | Cải thiện thế trận bảo mật | WAF lọc tấn công tầng 7 | | Giảm ảnh hưởng của tấn công DDoS | rate-based rule tự chặn IP gửi quá nhiều |

Rate-based rule hoạt động thế nào:

WAF đếm số request từ mỗi IP trong cửa sổ 5 phút
    → vượt ngưỡng → TỰ ĐỘNG chặn IP đó
    → giảm xuống dưới ngưỡng → tự bỏ chặn
        ↓
    Hoàn toàn tự động, không cần ai can thiệp

Cấu hình:

aws wafv2 create-web-acl --name bao-ve-ung-dung --scope REGIONAL \
  --default-action Allow={} \
  --rules '[{
    "Name":"GioiHanTanSuat","Priority":0,
    "Statement":{"RateBasedStatement":{
      "Limit":2000,"AggregateKeyType":"IP"}},
    "Action":{"Block":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"GioiHanTanSuat"}}]' \
  --visibility-config SampledRequestsEnabled=true,\
CloudWatchMetricsEnabled=true,MetricName=baoVeUngDung

aws wafv2 associate-web-acl --web-acl-arn <arn> \
  --resource-arn <arn-alb>

⚠ Ba lý do WAF hơn hẳn các phương án tự viết: | Lý do | Chi tiết | |---|---| | Chặn NGAY, không có độ trễ phát hiện | | | Chặn ở tầng 7, TRƯỚC khi tới EC2 | | | Không phải viết và bảo trì mã | |

Vế đầu là điểm quyết định:

Giải pháp tự viết (Lambda đọc log):
    → log ghi → CloudWatch → Lambda phát hiện → sửa security group
        ↓
    Tổng độ trễ vài phút
    → trong khoảng đó tấn công đã gây thiệt hại

WAF rate-based rule:
    → đánh giá NGAY trên từng request

Và nên thêm managed rule group:

{"Name":"NhomLuatChung","Priority":1,
 "Statement":{"ManagedRuleGroupStatement":{
   "VendorName":"AWS","Name":"AWSManagedRulesCommonRuleSet"}},
 "OverrideAction":{"None":{}},
 "VisibilityConfig":{"SampledRequestsEnabled":true,
   "CloudWatchMetricsEnabled":true,"MetricName":"NhomLuatChung"}}

⚠ Và AWS Shield Standard đã bảo vệ sẵn tầng 3/4:

Shield Standard: MIỄN PHÍ, TỰ ĐỘNG cho mọi khách hàng AWS
    → chống SYN flood, UDP reflection, và các tấn công tầng mạng
        ↓
    WAF lo tầng 7 (HTTP flood)
    → hai lớp bổ sung cho nhau

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

  • **A. Bật access log của ALB, CloudWatch giám sát và Lambda sửa security group — đây là phương án gần nhất vì cũng nhắm tới việc chặn IP tấn công, nhưng nó phản ứng quá chậm: log có độ trễ, Lambda phải phân tích, rồi mới sửa security group. Và security group không có quy tắc Deny — chỉ có Allow.
  • **C. Viết Lambda giám sát và sửa network ACL — cùng vấn đề độ trễ, và NACL giới hạn 20 quy tắc (tăng được tới 40), không đủ cho một cuộc tấn công phân tán từ hàng nghìn IP.
  • **D. Bật VPC Flow Logs và dùng Athena phân tích — đây là công cụ điều tra sau sự cố, độ trễ tính bằng phút tới giờ. Hoàn toàn không phải cơ chế phòng thủ thời gian thực.

Ghi nhớ

⚠ Ba lớp chống DDoS của AWS — bảng phải thuộc: | Lớp | Bảo vệ | Chi phí | |---|---|---| | AWS Shield Standard | tầng 3/4 — SYN flood, reflection | MIỄN PHÍ, tự động | | AWS WAF | tầng 7 — HTTP flood, SQLi, XSS | theo dùng | | AWS Shield Advanced | DDoS lớn, có đội SRT hỗ trợ | ~3.000 USD/tháng |

⚠ Shield Advanced đáng biết: | Lợi ích | Chi tiết | |---|---| | Đội Shield Response Team hỗ trợ 24/7 | | | Bảo vệ chi phí | hoàn phí co giãn do DDoS | | WAF miễn phí đi kèm | | | Báo cáo tấn công chi tiết | |

Từ khoá nhận diện:

"minimize impact of DDoS on an ALB" → WAF rate-based rule "DDoS cost protection, 24/7 support" → Shield Advanced "block a specific known IP" → WAF IP set "deny an IP at subnet level (no CDN)" → NACL

⚠ Bốn công cụ lọc — bảng chọn nhanh: | Công cụ | Tầng | Có Deny | Số quy tắc | |---|---|---|---| | AWS WAF | 7 | ✅ | IP set tới 10.000 | | Security Group | 3/4 | ❌ chỉ Allow | 60 | | Network ACL | 3/4 | ✅ | 20 (tối đa 40) | | Network Firewall | 3-7 | ✅ | nhiều |

Ba tham số của rate-based rule: | Tham số | Chi tiết | |---|---| | Limit | số request trong 5 phút (tối thiểu 100) | | AggregateKeyType | IP, FORWARDED_IP, hoặc CUSTOM_KEYS | | ScopeDownStatement | chỉ áp cho một phần lưu lượng |

⚠ FORWARDED_IP cần khi có CDN phía trước:

Có CloudFront trước ALB
    → WAF trên ALB thấy IP của CloudFront
        ↓
    Dùng FORWARDED_IP với header X-Forwarded-For
    → hoặc tốt hơn: gắn WAF vào CHÍNH CloudFront

Scope-down statement rất hữu ích:

{"RateBasedStatement":{
  "Limit":100,"AggregateKeyType":"IP",
  "ScopeDownStatement":{"ByteMatchStatement":{
    "SearchString":"/api/dang-nhap",
    "FieldToMatch":{"UriPath":{}},
    "TextTransformations":[{"Priority":0,"Type":"NONE"}],
    "PositionalConstraint":"STARTS_WITH"}}}}

Giới hạn chặt riêng cho endpoint đăng nhập
    → chống dò mật khẩu
    → mà không ảnh hưởng phần còn lại của site

Ba managed rule group nên bật: | Nhóm | Bảo vệ | |---|---| | AWSManagedRulesCommonRuleSet | OWASP cơ bản | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesKnownBadInputsRuleSet | payload tấn công đã biết |

Ba lưu ý khi bật WAF lần đầu: | Lưu ý | Chi tiết | |---|---| | Bật ở chế độ COUNT trước | xem có chặn nhầm không | | Đọc sampled request | | | Rồi mới chuyển sang BLOCK | |

⚠ Ba biện pháp bổ sung chống DDoS: | Biện pháp | Chi tiết | |---|---| | Đặt CloudFront trước ALB | hấp thụ tấn công ở edge | | Auto Scaling để chịu tải | | | Giới hạn tần suất ở API Gateway | nếu có |

CloudFront là lớp phòng thủ đầu tiên rất hiệu quả:

Tấn công tới edge của CloudFront
    → bị chặn ở đó, không tới ALB
        ↓
    Và CloudFront có dung lượng hấp thụ rất lớn

Ba cách theo dõi: | Cách | Chi tiết | |---|---| | WAF logging ra S3 hoặc CloudWatch | | | CloudWatch metric theo từng luật | | | Sampled requests trong console | |

Ba lưu ý về chi phí WAF: | Khoản | Chi tiết | |---|---| | Phí theo web ACL mỗi tháng | | | Phí theo luật | | | Phí theo triệu request | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử tải vượt ngưỡng từ một IP | phải bị chặn | | Kiểm tra người dùng thật không bị ảnh hưởng | | | Đặt alarm trên metric BlockedRequests | |

Và một lời khuyên: hãy bật rate-based rule ở chế độ COUNT một tuần trước khi chuyển sang BLOCK. Ngưỡng đặt quá thấp sẽ chặn nhầm người dùng thật đứng sau một NAT của văn phòng hay trường học — và chế độ COUNT cho bạn thấy điều đó mà không gây sự cố.

Câu 1008 AWS Application Integration

A Solutions Architect has been tasked with re-deploying an application running on AWS to enable high availability. The application processes messages that are received in an ActiveMQ queue running on a single Amazon EC2 instance. Messages are then processed by a consumer application running on Amazon EC2. After processing the messages the consumer application writes results to a MySQL database running on Amazon EC2.

Which architecture offers the highest availability and low operational complexity?

  1. A

    Deploy Amazon MQ with active/standby brokers configured across two Availability Zones. Launch an additional consumer EC2 instance in another Availability Zone. Use Amazon RDS for MySQL with Multi-AZ enabled.
  2. B

    Deploy Amazon MQ with active/standby brokers configured across two Availability Zones. Create an Auto Scaling group for the consumer EC2 instances across two Availability Zones. Use an Amazon RDS MySQL database with Multi-AZ enabled.
  3. C

    Deploy a second Active MQ server to another Availability Zone. Launch an additional consumer EC2 instance in another Availability Zone. Use MySQL database replication to another Availability Zone.
  4. D

    Deploy Amazon MQ with active/standby brokers configured across two Availability Zones. Launch an additional consumer EC2 instance in another Availability Zone. Use MySQL database replication to another Availability Zone.
Xem giải thích

Đáp án

B — Triển khai Amazon MQ với broker active/standby qua hai AZ, tạo Auto Scaling group cho các EC2 tiêu thụ trải qua hai AZ, và dùng RDS MySQL với Multi-AZ.

Vì sao đúng

Đề mô tả ba tầng, và phương án này làm cả ba đều sẵn sàng cao: | Tầng | Hiện trạng | Sửa bằng | |---|---|---| | Hàng đợi ActiveMQ trên MỘT EC2 | điểm hỏng đơn lẻ | Amazon MQ active/standby | | Ứng dụng tiêu thụ trên EC2 | một máy | ASG trải hai AZ | | MySQL trên EC2 | tự quản, một máy | RDS MySQL Multi-AZ |

⚠ Điểm phân biệt B với A và D là tầng tiêu thụ:

"Launch an ADDITIONAL consumer EC2 instance in another AZ"
    → hai máy cố định
    → máy chết thì phải có người dựng lại
        ↓
"Create an AUTO SCALING GROUP for the consumer instances"
    → máy chết được thay TỰ ĐỘNG
    → và co giãn theo tải
        ↓
    Đây là "highest availability and LOW operational complexity"

Vì sao Amazon MQ chứ không phải tự dựng ActiveMQ:

Amazon MQ = ActiveMQ (hoặc RabbitMQ) ĐƯỢC QUẢN LÝ
    → giữ nguyên giao thức JMS, AMQP, MQTT, STOMP
    → ứng dụng KHÔNG phải sửa mã
        ↓
    AWS lo vá lỗi, sao lưu, chuyển đổi dự phòng

Tạo broker active/standby:

aws mq create-broker --broker-name broker-ung-dung \
  --engine-type ACTIVEMQ --engine-version 5.18 \
  --host-instance-type mq.m5.large \
  --deployment-mode ACTIVE_STANDBY_MULTI_AZ \
  --subnet-ids subnet-az-a subnet-az-b \
  --security-groups sg-mq \
  --users Username=ungdung,Password=<mat-khau>,ConsoleAccess=false \
  --publicly-accessible false

⚠ Ba chế độ triển khai của Amazon MQ: | Chế độ | Đặc điểm | |---|---| | SINGLE_INSTANCE | một broker, không dự phòng | | ACTIVE_STANDBY_MULTI_AZ | hai broker, tự chuyển đổi (ActiveMQ) | | CLUSTER_MULTI_AZ | cụm ba node (RabbitMQ) |

ASG cho tầng tiêu thụ:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name asg-tieu-thu \
  --launch-template LaunchTemplateName=mau-tieu-thu,Version='$Latest' \
  --min-size 2 --max-size 10 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-az-a,subnet-az-b"

Và RDS Multi-AZ:

aws rds create-db-instance --db-instance-identifier csdl-ket-qua \
  --engine mysql --db-instance-class db.m6g.large \
  --allocated-storage 100 --multi-az --storage-encrypted \
  --db-subnet-group-name nhom-subnet-rieng-tu --no-publicly-accessible

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cả ba tầng chịu được mất một AZ | | | Không đổi mã ứng dụng | giữ giao thức JMS | | AWS lo vá lỗi và sao lưu | |

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

  • **A. Amazon MQ active/standby + thêm MỘT máy tiêu thụ ở AZ khác + RDS Multi-AZ — đây là phương án gần nhất và đã sẵn sàng cao ở cả ba tầng, nhưng tầng tiêu thụ dùng máy cố định: khi một máy chết vì lỗi phần cứng, phải có người dựng lại. ASG tự làm việc đó.
  • **D. Amazon MQ active/standby + thêm một máy tiêu thụ + MySQL replication tự quản — cùng vấn đề tầng tiêu thụ, cộng thêm việc tự quản lý sao chép MySQL: phải tự lo chuyển đổi dự phòng, tự vá lỗi, tự sao lưu.
  • **C. Dựng ActiveMQ thứ hai ở AZ khác + máy tiêu thụ thêm + MySQL replication — công vận hành cao nhất: tự quản cả broker lẫn CSDL, và hai ActiveMQ rời rạc không tự chuyển đổi cho nhau.

Ghi nhớ

⚠ Amazon MQ và SQS/SNS — khi nào dùng cái nào: | | Amazon MQ | SQS / SNS | |---|---|---| | Giao thức | JMS, AMQP, MQTT, STOMP, OpenWire | API riêng của AWS | | Dùng khi | DI CHUYỂN ứng dụng có sẵn | xây MỚI trên AWS | | Co giãn | theo cỡ broker | gần như vô hạn | | Vận hành | chọn cỡ, phiên bản | không có gì | | Chi phí | theo giờ broker | theo request |

Đề nói ứng dụng ĐANG dùng ActiveMQ
    → Amazon MQ giữ nguyên mã
        ↓
    Nếu xây mới thì SQS gần như luôn tốt hơn

Từ khoá nhận diện:

"existing ActiveMQ/RabbitMQ", "JMS", "AMQP" → Amazon MQ "build new decoupled app on AWS" → SQS / SNS "highest availability + low operational complexity" → dịch vụ được quản lý + ASG

⚠ Ba tầng cần kiểm tra khi làm HA: | Tầng | Cách làm | |---|---| | Nhắn tin | Amazon MQ active/standby hoặc SQS | | Tính toán | ASG trải nhiều AZ | | CSDL | RDS Multi-AZ hoặc Aurora |

Bỏ sót một tầng = cả hệ thống vẫn có điểm hỏng đơn lẻ

Ba đặc điểm của Amazon MQ active/standby: | Đặc điểm | Chi tiết | |---|---| | Hai broker ở hai AZ | | | Dùng chung EFS làm kho thông điệp | | | Chuyển đổi tự động khi broker chính hỏng | |

⚠ Thời gian chuyển đổi của Amazon MQ:

Chuyển đổi active/standby mất khoảng 1-2 phút
    → client phải TỰ KẾT NỐI LẠI
        ↓
    Dùng failover transport URI trong chuỗi kết nối

failover:(ssl://b-1-abc.mq.ap-southeast-1.amazonaws.com:61617,
          ssl://b-2-abc.mq.ap-southeast-1.amazonaws.com:61617)

Ba lưu ý về RDS Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Standby KHÔNG phục vụ đọc | | | Chuyển đổi tự động 1-2 phút | | | Endpoint DNS giữ nguyên | |

⚠ Ba lưu ý về ứng dụng khi có failover: | Lưu ý | Chi tiết | |---|---| | Kết nối đang mở BỊ NGẮT | | | Ứng dụng phải thử lại | | | Connection pool phải xử lý được | |

Ba lợi ích của ASG so với máy cố định: | Lợi ích | Chi tiết | |---|---| | Tự thay máy hỏng | | | Co giãn theo tải | | | Trải đều giữa các AZ | |

Co giãn theo độ sâu hàng đợi Amazon MQ:

aws cloudwatch put-metric-alarm --alarm-name hang-doi-dai \
  --namespace AWS/AmazonMQ --metric-name QueueSize \
  --dimensions Name=Broker,Value=broker-ung-dung Name=Queue,Value=hang-doi-viec \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 1000 --comparison-operator GreaterThanThreshold

Ba metric của Amazon MQ: | Metric | Ý nghĩa | |---|---| | QueueSize | số thông điệp chờ | | ConsumerCount | có consumer nào không | | CpuUtilization của broker | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Broker tính theo GIỜ | active/standby tính hai | | Cộng phí lưu trữ | | | Đắt hơn SQS đáng kể | |

Ba bước di chuyển từ ActiveMQ tự quản: | Bước | Chi tiết | |---|---| | Tạo broker Amazon MQ cùng phiên bản | | | Đổi chuỗi kết nối của ứng dụng | | | Chuyển dần producer rồi consumer | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ép chuyển đổi broker | reboot-broker | | Tắt một máy tiêu thụ, xem ASG thay không | | | Ép failover RDS | reboot-db-instance --force-failover |

Và một lời khuyên: hãy dùng failover transport URI trong chuỗi kết nối ngay từ đầu. Amazon MQ active/standby chuyển đổi rất tốt ở phía hạ tầng, nhưng client chỉ biết một endpoint sẽ ngồi im báo lỗi cho tới khi ai đó khởi động lại ứng dụng.

Câu 1009 Chọn nhiều đáp án AWS Storage

Storage capacity has become an issue for a company that runs application servers on-premises. The servers are connected to a combination of block storage and NFS storage solutions. The company requires a solution that supports local caching without re-architecting its existing applications.

Which combination of changes can the company make to meet these requirements? (Select TWO.)

  1. A

    1. Use an AWS Storage Gateway file gateway to replace the NFS storage.
  2. B

    Use an AWS Storage Gateway volume gateway to replace the block storage.
  3. C

    1. Use the mount command on servers to mount Amazon S3 buckets using NFS.
  4. D

    1. Use AWS Direct Connect and mount an Amazon FSx for Windows File Server using iSCSI.
  5. E

    1. Use Amazon Elastic File System (EFS) volumes to replace the block storage.
Xem giải thích

Đáp án

A và B.

  • A — Dùng AWS Storage Gateway file gateway thay cho lưu trữ NFS
  • B — Dùng AWS Storage Gateway volume gateway thay cho lưu trữ khối

Vì sao đúng

Đề nêu ba dữ kiện, và mỗi loại lưu trữ cần một chế độ gateway riêng: | Dữ kiện | Cách đáp ứng | |---|---| | Máy chủ tại chỗ dùng lưu trữ KHỐI | B: volume gateway (iSCSI) | | **Và lưu trữ NFS | A: file gateway (NFS) | | Cần CACHE cục bộ, KHÔNG viết lại ứng dụng | cả hai đều có cache và giữ nguyên giao diện |

⚠ Ánh xạ giao thức là cách chọn nhanh nhất:

Lưu trữ KHỐI  → iSCSI → Volume Gateway
Lưu trữ NFS   → NFS   → File Gateway
        ↓
    Mỗi loại một gateway, không thay thế lẫn nhau được

File Gateway cho phần NFS:

aws storagegateway create-nfs-file-share \
  --client-token $(uuidgen) --gateway-arn <arn-gateway-file> \
  --location-arn arn:aws:s3:::kho-tep \
  --role <arn-role> --client-list 192.168.1.0/24

Volume Gateway cho phần khối:

aws storagegateway create-cached-iscsi-volume \
  --gateway-arn <arn-gateway-volume> \
  --volume-size-in-bytes 5000000000000 \
  --target-name du-lieu-ung-dung \
  --network-interface-id 192.168.1.50 \
  --client-token $(uuidgen)

⚠ Chế độ cached là chìa khoá cho "storage capacity has become an issue": | Chế độ | Dữ liệu chính ở đâu | |---|---| | Cached volume | AWS (S3) — cache nóng tại chỗ | | Stored volume | TẠI CHỖ toàn bộ — snapshot lên AWS |

Đề nói hết dung lượng tại chỗ
    → cached mode đưa dữ liệu chính lên AWS
    → chỉ giữ phần nóng ở local
        ↓
    Stored mode không giải quyết được vấn đề

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ứng dụng KHÔNG phải sửa | vẫn là NFS share và ổ iSCSI | | Dung lượng "nhìn thấy" gần như vô hạn | | | Cache cục bộ giữ độ trễ thấp | |

Vế đầu là yêu cầu cốt lõi của đề:

"without re-architecting its existing applications"
    → giữ nguyên giao diện lưu trữ
        ↓
    Đây là lý do Storage Gateway tồn tại

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

  • **E. Dùng Amazon EFS thay cho lưu trữ khối — đây là phương án gần nhất vì EFS cũng là lưu trữ chia sẻ được quản lý, nhưng nó dùng NFS (tệp), không thay được lưu trữ khối. Và EFS không có cache cục bộ cho máy chủ tại chỗ.
  • **C. Mount S3 bucket bằng NFS trên máy chủ — S3 không hỗ trợ NFS. (Mountpoint for Amazon S3 có tồn tại nhưng là FUSE, không phải NFS, và không có cache như đề yêu cầu.)
  • **D. Dùng Direct Connect và mount FSx for Windows bằng iSCSI — FSx for Windows dùng SMB, không phải iSCSI. Và nó không cung cấp cache cục bộ.

Ghi nhớ

⚠ Bốn chế độ Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Thay thế | |---|---|---| | S3 File Gateway | NFS, SMB | NAS, file server | | FSx File Gateway | SMB | truy cập FSx for Windows | | Volume Gateway | iSCSI (khối) | SAN, ổ đĩa | | Tape Gateway | iSCSI VTL | thư viện băng từ |

Từ khoá nhận diện:

"block storage" + "local caching" → Volume Gateway (cached) "NFS/SMB file share" + "local caching" → File Gateway "replace tape library" → Tape Gateway "migrate data once" → DataSync

⚠ Hai chế độ Volume Gateway: | Chế độ | Dữ liệu chính | Dung lượng tối đa | |---|---|---| | Cached | S3 | 32 TB mỗi volume, 1 PB tổng | | Stored | tại chỗ | 16 TB mỗi volume, 512 TB |

⚠ Ba loại đĩa cục bộ Volume Gateway cần: | Đĩa | Việc | |---|---| | Cache storage | giữ dữ liệu đọc nóng | | Upload buffer | đệm dữ liệu ghi chờ lên S3 | | (Stored mode) đĩa dữ liệu chính | |

⚠ Upload buffer đầy là sự cố hay gặp nhất:

Upload buffer đầy
    → gateway KHÔNG nhận thêm ghi
    → ứng dụng bị chặn
        ↓
    Xảy ra khi băng thông lên AWS chậm hơn tốc độ ghi
    → theo dõi UploadBufferPercentUsed

Ba metric bắt buộc theo dõi: | Metric | Ngưỡng cảnh báo | |---|---| | UploadBufferPercentUsed | > 80% là nguy hiểm | | CachePercentUsed | cache đầy làm chậm | | CacheHitPercent | thấp = độ trễ cao |

Ba cách triển khai gateway: | Cách | Khi nào | |---|---| | Máy ảo (VMware, Hyper-V, KVM) | có hạ tầng ảo hoá | | Hardware Appliance | không có tài nguyên ảo hoá | | EC2 | tải chạy trên AWS |

Ba yêu cầu tài nguyên: | Yêu cầu | Con số tối thiểu | |---|---| | vCPU | 4 | | RAM | 16 GB | | Đĩa cache | 150 GB |

⚠ Ba khác biệt về dữ liệu trên AWS: | Gateway | Dữ liệu lưu dạng | |---|---| | File Gateway | object S3 — đọc trực tiếp được | | Volume Gateway | snapshot EBS — phải khôi phục mới đọc | | Tape Gateway | băng ảo trong S3/Glacier |

Muốn EC2 trên AWS phân tích dữ liệu đó
    → File Gateway (object S3)
Chỉ để mở rộng dung lượng và sao lưu
    → Volume Gateway cũng được

Ba lưu ý về snapshot của Volume Gateway: | Lưu ý | Chi tiết | |---|---| | Lưu thành EBS snapshot | | | Tạo EBS volume từ snapshot để dùng trên EC2 | | | Đặt lịch tự động | |

aws storagegateway update-snapshot-schedule \
  --volume-arn <arn-volume> --start-at 2 --recurrence-in-hours 24 \
  --description "Sao luu hang ngay"

Ba lưu ý về nhất quán của File Gateway: | Lưu ý | Chi tiết | |---|---| | Object ghi thẳng vào S3 không tự hiện trong share | | | Phải gọi RefreshCache | | | Hoặc đặt CacheStaleTimeoutInSeconds | |

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Đặt giới hạn tải lên theo giờ | | | Đồng bộ ban đầu tốn nhiều | | | Cân nhắc Snowball cho lượng lớn ban đầu | |

aws storagegateway update-bandwidth-rate-limit --gateway-arn <arn> \
  --average-upload-rate-limit-in-bits-per-sec 104857600

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ trên AWS theo lớp | | | Phí gateway theo lượng dữ liệu ghi | | | Phí lấy dữ liệu khi cache miss với lớp IA | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi tệp qua share, xem trên S3 | | | Đọc dữ liệu cũ, đo thời gian | | | Theo dõi CacheHitPercent một tuần | |

Và một lời khuyên: hãy đặt alarm trên UploadBufferPercentUsed ngay khi dựng Volume Gateway. Đây là chỗ duy nhất mà một vấn đề về băng thông biến thành một sự cố cho ứng dụng — buffer đầy nghĩa là ứng dụng không ghi được nữa, và triệu chứng đó trông giống hệt một lỗi lưu trữ cục bộ.

Câu 1010 AWS Networking & Content Delivery

An organization want to share regular updates about their charitable work using static webpages. The pages are expected to generate a large amount of views from around the world. The files are stored in an Amazon S3 bucket. A solutions architect has been asked to design an efficient and effective solution.

Which action should the solutions architect take to accomplish this?

  1. A

    Use the geoproximity feature of Amazon Route 53
  2. B

    Generate presigned URLs for the files
  3. C

    Use Amazon CloudFront with the S3 bucket as its origin
  4. D

    Use cross-Region replication to all Regions
Xem giải thích

Đáp án

C — Dùng Amazon CloudFront với S3 bucket làm origin.

Vì sao đúng

Đề nêu ba dữ kiện, và CloudFront khớp cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | Trang web TĨNH trong S3 | CloudFront cache rất hiệu quả | | Nhiều lượt xem TỪ KHẮP THẾ GIỚI | hơn 600 edge location | | Cần giải pháp hiệu quả | giảm cả độ trễ lẫn chi phí |

Vì sao CloudFront vừa nhanh vừa rẻ:

Nội dung tĩnh được cache ở edge gần người dùng
    → phục vụ ngay, không đi tới vùng chứa bucket
        ↓
    VÀ: data transfer từ S3 sang CloudFront MIỄN PHÍ
    → thường RẺ HƠN phục vụ thẳng từ S3

Tạo distribution:

aws cloudfront create-distribution --distribution-config '{
  "CallerReference":"trang-tu-thien-2026",
  "Origins":{"Quantity":1,"Items":[{
    "Id":"s3-goc",
    "DomainName":"trang-tu-thien.s3.ap-southeast-1.amazonaws.com",
    "S3OriginConfig":{"OriginAccessIdentity":""},
    "OriginAccessControlId":"<id-oac>"}]},
  "DefaultCacheBehavior":{"TargetOriginId":"s3-goc",
    "ViewerProtocolPolicy":"redirect-to-https",
    "CachePolicyId":"658327ea-f89d-4fab-a63d-7e88639e58f6",
    "Compress":true},
  "DefaultRootObject":"index.html",
  "Enabled":true,"Comment":"Trang tin tu thien"}'

Bảo vệ bucket bằng OAC:

aws cloudfront create-origin-access-control \
  --origin-access-control-config \
  'Name=oac-trang-tu-thien,OriginAccessControlOriginType=s3,
   SigningBehavior=always,SigningProtocol=sigv4'

Bucket policy chỉ cho CloudFront:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::trang-tu-thien/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123ABC"}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ thấp toàn cầu | | | Bucket riêng tư hoàn toàn | | | HTTPS miễn phí qua ACM | |

Và giảm tải cho S3:

Tỷ lệ cache hit 95%
    → chỉ 5% request chạm tới S3
        ↓
    Ít phí request, ít phí truyền

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

  • **D. Dùng cross-Region replication sang MỌI vùng — đây là phương án gần nhất vì cũng đưa nội dung tới gần người dùng, nhưng nó cực kỳ tốn kém và phức tạp: nhân bản dữ liệu ra hàng chục vùng, trả phí lưu trữ và truyền cho từng vùng, và phải tự viết logic đưa người dùng tới bucket gần nhất.
  • **A. Dùng geoproximity của Route 53 — định tuyến DNS chỉ chọn được endpoint nào, mà ở đây chỉ có một bucket. Và DNS không cache nội dung nên không giảm độ trễ tải xuống.
  • **B. Sinh presigned URL cho các tệp — presigned URL dùng để chia sẻ có kiểm soát và có hạn cho object riêng tư. Với trang web công khai thì nó chỉ thêm phức tạp mà không giúp gì về hiệu năng.

Ghi nhớ

⚠ Ba dịch vụ tăng tốc — bảng phải thuộc: | Dịch vụ | Tối ưu cho | Có cache | |---|---|---| | CloudFront | nội dung tĩnh, web | ✅ | | S3 Transfer Acceleration | TẢI LÊN từ xa | ❌ | | Global Accelerator | TCP/UDP, IP tĩnh | ❌ |

Từ khoá nhận diện:

"static website in S3" + "global viewers" → CloudFront "slow uploads from around the world" → Transfer Acceleration "non-HTTP protocol, static IP" → Global Accelerator "share a private file temporarily" → presigned URL

⚠ Hai kiểu endpoint của S3 — hay bị lẫn: | Kiểu | Đặc điểm | |---|---| | REST API endpoint | hỗ trợ HTTPS, dùng được OAC | | Website endpoint (s3-website-...) | CHỈ HTTP, có index và error document |

Dùng CloudFront với S3 → chọn REST endpoint + OAC
    → bucket riêng tư hoàn toàn
        ↓
    Website endpoint bắt buộc bucket phải CÔNG KHAI

⚠ OAC thay thế OAI: | | OAC | OAI | |---|---|---| | Trạng thái | hiện hành (từ 08/2022) | cũ | | SSE-KMS | ✅ | ❌ | | Vùng mới | ✅ | ❌ |

Ba việc cần cấu hình cho website tĩnh: | Việc | Chi tiết | |---|---| | DefaultRootObject: index.html | | | Custom error response cho SPA | 403/404 → /index.html | | Alternate domain name + chứng chỉ ACM | |

⚠ Chứng chỉ ACM cho CloudFront phải ở us-east-1 — bất kể bucket ở vùng nào.

Ba cách tối ưu chi phí CloudFront: | Cách | Chi tiết | |---|---| | Chọn price class hợp phân bố khách | | | Bật nén (gzip, Brotli) | | | TTL dài cho nội dung tĩnh | |

Ba price class: | Price class | Khu vực | |---|---| | PriceClass_All | toàn cầu ← đề nói khách khắp thế giới | | PriceClass_200 | trừ Nam Mỹ, Úc/NZ | | PriceClass_100 | Bắc Mỹ, châu Âu |

⚠ Ba lỗi làm hỏng tỷ lệ cache hit: | Lỗi | Hậu quả | |---|---| | Forward mọi cookie | mỗi khách một bản cache | | Forward mọi query string | ?utm_source= tách cache | | TTL quá ngắn | |

Chiến lược cache tối ưu cho website tĩnh:

# Tài nguyên có mã băm: cache vĩnh viễn
aws s3 sync ./build/static s3://trang-tu-thien/static/ \
  --cache-control "public, max-age=31536000, immutable"

# index.html: luôn kiểm tra lại
aws s3 cp ./build/index.html s3://trang-tu-thien/ \
  --cache-control "public, max-age=0, must-revalidate"

Không cần invalidation nào cả
    → tệp mới có tên mới
    → index.html luôn mới

Ba lưu ý về invalidation: | Lưu ý | Chi tiết | |---|---| | 1.000 đường dẫn đầu mỗi tháng miễn phí | | | Sau đó tính phí theo đường dẫn | | | Có độ trễ vài phút | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access trên bucket | | | ViewerProtocolPolicy: redirect-to-https | | | Thêm response header policy (CSP, HSTS) | |

Response header policy:

aws cloudfront create-response-headers-policy \
  --response-headers-policy-config '{
    "Name":"bao-mat-co-ban",
    "SecurityHeadersConfig":{
      "StrictTransportSecurity":{"AccessControlMaxAgeSec":31536000,
        "IncludeSubdomains":true,"Override":true},
      "ContentTypeOptions":{"Override":true},
      "FrameOptions":{"FrameOption":"DENY","Override":true}}}'

Ba lựa chọn khác cho website tĩnh: | Lựa chọn | Đặc điểm | |---|---| | S3 + CloudFront | chuẩn mực ← câu này | | AWS Amplify Hosting | có CI/CD sẵn, dùng CloudFront bên dưới | | S3 website endpoint trực tiếp | không HTTPS, không CDN |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp là cấu hình sai | | OriginLatency | | | TotalErrorRate | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra header X-Cache | Hit hay Miss | | Thử truy cập thẳng bucket | phải bị từ chối | | Đo độ trễ từ nhiều khu vực | |

curl -sI https://tu-thien.vidu.com/ | grep -i x-cache

Và một lời khuyên: hãy đặt tên tệp tài nguyên theo mã băm nội dung ngay từ khi dựng trang. Đó là cách duy nhất để vừa cache vĩnh viễn vừa cập nhật tức thì — và nó loại bỏ hẳn nhu cầu dùng invalidation, thứ vừa tốn phí vừa có độ trễ.