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

Tìm thấy 2194 câu.

Câu 1071 AWS Security, Identity, & Compliance

An application analyzes images of people that are uploaded to an Amazon S3 bucket. The application determines demographic data which is then saved to a .CSV file in another S3 bucket. The data must be encrypted at rest and then queried using SQL. The solution should be fully serverless.

Which actions should a Solutions Architect take to encrypt and query the data?

  1. A

    Use AWS KMS encryption keys for the S3 bucket and use Amazon Athena to query the data
  2. B

    Use Amazon S3 server-side encryption and use Amazon RedShift Spectrum to query the data
  3. C

    Use Amazon S3 server-side encryption and Amazon QuickSight to query the data
  4. D

    Use AWS KMS encryption keys for the S3 bucket and use Amazon Managed Service for Apache Flink to query the data.
Xem giải thích

Đáp án

A — Dùng khoá mã hoá AWS KMS cho bucket S3 và dùng Amazon Athena để truy vấn dữ liệu.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp KMS + Athena đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Mã hoá at rest | SSE-KMS trên bucket | | Truy vấn bằng SQL | Athena chạy SQL thẳng trên tệp .CSV | | Hoàn toàn serverless | Athena không có máy chủ nào để quản lý |

⚠ Athena là công cụ SQL serverless đúng nghĩa:

Không có cụm để dựng
Không có node để chọn cỡ
Không có gì chạy khi không truy vấn
        ↓
    Trả tiền theo LƯỢNG DỮ LIỆU QUÉT
    → 5 USD mỗi TB

Bật mã hoá mặc định cho bucket:

aws s3api put-bucket-encryption --bucket du-lieu-nhan-khau \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "<arn-khoa>"},
      "BucketKeyEnabled": true}]}'

⚠ Luôn bật BucketKeyEnabled:

Không bật: mỗi object gọi KMS một lần
    → hàng triệu object = hàng triệu lời gọi
        ↓
Bật S3 Bucket Key: giảm tới 99% số lần gọi KMS
    → giảm chi phí và tránh chạm giới hạn tần suất

Tạo bảng Athena trên tệp CSV:

CREATE EXTERNAL TABLE nhan_khau (
  anh_id      string,
  do_tuoi     int,
  gioi_tinh   string,
  thoi_diem   timestamp)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
WITH SERDEPROPERTIES ('separatorChar' = ',', 'quoteChar' = '"')
LOCATION 's3://du-lieu-nhan-khau/ket-qua/'
TBLPROPERTIES ('skip.header.line.count' = '1');

Truy vấn:

SELECT gioi_tinh, COUNT(*) AS so_luong
FROM nhan_khau
WHERE do_tuoi BETWEEN 18 AND 35
GROUP BY gioi_tinh;

⚠ Athena đọc được dữ liệu mã hoá SSE-KMS trong suốt — miễn là vai trò gọi có quyền kms:Decrypt:

{"Effect": "Allow",
 "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
 "Resource": "<arn-khoa>"}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không hạ tầng nào phải quản lý | | | Trả tiền theo truy vấn | | | Kiểm soát khoá qua key policy, ghi log qua CloudTrail | |

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

  • **B. Mã hoá phía máy chủ của S3 và dùng Redshift Spectrum — đây là phương án gần nhất vì Spectrum cũng chạy SQL trên S3, nhưng Spectrum đòi một cụm Redshift đang chạy, nên không còn serverless. (Redshift Serverless có tồn tại, nhưng phương án không nói vậy.)
  • **C. Dùng QuickSight để truy vấn — QuickSight là công cụ trực quan hoá, nó không phải công cụ chạy SQL trên S3; nó cần một nguồn như Athena bên dưới.
  • **D. Dùng Managed Service for Apache Flink — Flink dành cho xử lý luồng dữ liệu thời gian thực, không phải truy vấn tệp tĩnh trên S3.

Ghi nhớ

⚠ Bốn công cụ truy vấn dữ liệu trên AWS — bảng phải thuộc: | Công cụ | Serverless | Dùng cho | |---|---|---| | Athena | ✅ | SQL đặc biệt trên S3 | | Redshift Spectrum | ❌ cần cụm | kho dữ liệu + S3 | | Redshift Serverless | ✅ | kho dữ liệu, tải nặng | | Managed Service for Apache Flink | ✅ | luồng thời gian thực |

Từ khoá nhận diện:

"query S3 with SQL, serverless" → Athena "data warehouse, complex joins, BI" → Redshift "real-time stream analytics" → Flink / Kinesis "dashboards and visualization" → QuickSight

⚠ Managed Service for Apache Flink chính là Kinesis Data Analytics đổi tên (2023) — hai cái tên, một dịch vụ.

Ba cách mã hoá S3: | Cách | Ai giữ khoá | |---|---| | SSE-S3 | AWS hoàn toàn | | SSE-KMS | bạn, qua KMS | | SSE-C | bạn gửi khoá theo mỗi request | | DSSE-KMS | mã hoá hai lớp |

⚠ SSE-KMS cho ba thứ SSE-S3 không có: | Thứ | Chi tiết | |---|---| | Kiểm soát ai giải mã được | key policy | | Ghi log mọi lần dùng khoá | CloudTrail | | Xoay khoá theo ý bạn | |

Ba cách giảm chi phí Athena: | Cách | Mức giảm | |---|---| | Chuyển sang Parquet/ORC | tới 90% | | Phân vùng theo ngày | | | Nén dữ liệu | |

⚠ Định dạng cột là thay đổi có tác động lớn nhất:

CSV: đọc SELECT một cột vẫn quét TOÀN BỘ tệp
        ↓
Parquet: chỉ đọc cột được chọn
    → dữ liệu quét giảm mạnh
    → hoá đơn giảm theo

Chuyển sang Parquet bằng chính Athena:

CREATE TABLE nhan_khau_parquet
WITH (format = 'PARQUET',
      external_location = 's3://du-lieu-nhan-khau/parquet/',
      partitioned_by = ARRAY['ngay'])
AS SELECT anh_id, do_tuoi, gioi_tinh,
          date_format(thoi_diem, '%Y-%m-%d') AS ngay
FROM nhan_khau;

Ba lưu ý về phân vùng: | Lưu ý | Chi tiết | |---|---| | Phân vùng theo cột hay lọc nhất | | | Partition projection tránh phải MSCK REPAIR | | | Quá nhiều phân vùng nhỏ cũng chậm | |

Ba lưu ý về Glue Data Catalog: | Lưu ý | Chi tiết | |---|---| | Athena dùng Glue Catalog làm siêu dữ liệu | | | Crawler tự suy ra schema | | | Nhiều dịch vụ dùng chung catalog | |

Ba lưu ý về kết quả truy vấn: | Lưu ý | Chi tiết | |---|---| | Athena ghi kết quả vào bucket riêng | | | Bucket đó cũng nên mã hoá | | | Đặt lifecycle xoá kết quả cũ | |

aws athena update-work-group --work-group primary \
  --configuration-updates '{
    "ResultConfigurationUpdates": {
      "OutputLocation": "s3://ket-qua-athena/",
      "EncryptionConfiguration": {
        "EncryptionOption": "SSE_KMS",
        "KmsKey": "<arn-khoa>"}}}'

Ba lưu ý về workgroup: | Lưu ý | Chi tiết | |---|---| | Tách chi phí theo nhóm | | | Đặt hạn mức dữ liệu quét mỗi truy vấn | | | Ép nơi lưu kết quả và mã hoá | |

⚠ Hạn mức quét là lưới an toàn quan trọng:

aws athena create-work-group --name phan-tich \
  --configuration 'BytesScannedCutoffPerQuery=10737418240'

Một truy vấn thiếu điều kiện lọc
    → quét cả petabyte
        ↓
    Hạn mức cắt nó trước khi thành hoá đơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy truy vấn thử, xem dữ liệu quét | | | Xác nhận object mới được mã hoá KMS | | | Kiểm tra CloudTrail ghi lần dùng khoá | |

Và một lời khuyên: hãy đặt hạn mức byte quét cho mỗi truy vấn ngay khi tạo workgroup. Athena tính tiền theo dữ liệu đã đọc, và một câu SELECT * không có điều kiện lọc trên kho CSV lớn có thể tốn hơn cả tháng lưu trữ chỉ trong một lần nhấn nút.

Câu 1072 AWS Storage

A software firm is developing a microservices-based application to be deployed on Amazon ECS. This application needs to interact with a resilient, shared filesystem capable of restoring data to a different AWS Region with a Recovery Point Objective (RPO) of 2 hours.

The filesystem is also expected to provide a mount target in each Availability Zone (AZ) within a Region. The solutions architect intends to employ AWS Backup to oversee the cross-Region data replication.

Which option will meet these requirements?

  1. A

    Amazon FSx for OpenZFS.
  2. B

    Amazon FSx for NetApp ONTAP with a Multi-AZ deployment.
  3. C

    Amazon Elastic File System (Amazon EFS) with the Standard storage class.
  4. D

    Amazon FSx for Windows File Server with a Multi-AZ deployment.
Xem giải thích

Đáp án

C — Amazon EFS với lớp lưu trữ Standard.

Vì sao đúng

Đề nêu ba yêu cầu, và một trong số đó là từ khoá quyết định: | Yêu cầu | Cách đáp ứng | |---|---| | Hệ thống tệp dùng chung cho ECS | EFS mount vào task | | AWS Backup sao chép xuyên Region, RPO 2 giờ | EFS được AWS Backup hỗ trợ đầy đủ | | Có mount target trong MỖI Availability Zone | "mount target" là thuật ngữ RIÊNG của EFS |

⚠ "Mount target trong mỗi AZ" là dấu hiệu chỉ thẳng vào EFS:

FSx dùng khái niệm "file server" và "preferred subnet"
    → không có thứ gọi là mount target
        ↓
EFS: mỗi AZ một mount target, mỗi mount target một IP
    → task trong AZ nào mount qua mount target AZ đó

Tạo và mount cho mỗi AZ:

aws efs create-file-system --performance-mode generalPurpose \
  --throughput-mode elastic --encrypted \
  --backup   # bật sao lưu tự động ngay

for s in subnet-a subnet-b subnet-c; do
  aws efs create-mount-target --file-system-id fs-abc \
    --subnet-id $s --security-groups sg-efs
done

Gắn vào task definition của ECS:

{"volumes": [{
   "name": "du-lieu-chung",
   "efsVolumeConfiguration": {
     "fileSystemId": "fs-abc",
     "transitEncryption": "ENABLED",
     "authorizationConfig": {
       "accessPointId": "fsap-abc",
       "iam": "ENABLED"}}}],
 "containerDefinitions": [{
   "name": "dich-vu",
   "mountPoints": [{
     "sourceVolume": "du-lieu-chung",
     "containerPath": "/du-lieu"}]}]}

⚠ Với Fargate, transitEncryption là bắt buộc — Fargate không cho mount NFS trần.

Kế hoạch AWS Backup xuyên Region với RPO 2 giờ:

aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "efs-xuyen-vung",
  "Rules": [{
    "RuleName": "moi-2-gio",
    "TargetBackupVaultName": "kho-chinh",
    "ScheduleExpression": "cron(0 0/2 * * ? *)",
    "StartWindowMinutes": 60,
    "CopyActions": [{
      "DestinationBackupVaultArn":
        "arn:aws:backup:ap-northeast-1:123456789012:backup-vault:kho-dr",
      "Lifecycle": {"DeleteAfterDays": 30}}]}]}'

⚠ Lịch phải khớp RPO:

RPO 2 giờ = được phép mất tối đa 2 giờ dữ liệu
    → sao lưu ít nhất mỗi 2 giờ
        ↓
    Sao lưu hằng ngày với RPO 2 giờ là mâu thuẫn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nhiều task mount đồng thời | | | AWS Backup lo sao chép xuyên vùng | | | Tự mở rộng, không cấp dung lượng | |

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

  • **B. FSx for NetApp ONTAP Multi-AZ — đây là phương án gần nhất vì cũng dùng chung được và cũng có sao chép xuyên vùng, nhưng nó dùng cơ chế SnapMirror riêng và không dùng khái niệm mount target mỗi AZ; đề nói rõ muốn dùng AWS Backup để quản lý sao chép.
  • **A. FSx for OpenZFS — chỉ Single-AZ ở phần lớn cấu hình, và không khớp mô tả mount target mỗi AZ.
  • **D. FSx for Windows File Server Multi-AZ — dùng SMB, dành cho Windows; container Linux trên ECS không phải đối tượng của nó.

Ghi nhớ

⚠ Thuật ngữ riêng của từng dịch vụ — dấu hiệu nhận diện trong đề: | Thuật ngữ | Dịch vụ | |---|---| | "mount target" | EFS | | "preferred subnet", "file server" | FSx for Windows | | "SVM", "SnapMirror", "volume" | FSx for NetApp ONTAP | | "data repository association" | FSx for Lustre |

Từ khoá nhận diện:

"shared file system for ECS/EKS containers, Linux" → EFS "NFS and SMB at the same time" → FSx for NetApp ONTAP "Windows, Active Directory" → FSx for Windows "HPC, high throughput, links to S3" → FSx for Lustre

Ba lớp lưu trữ EFS: | Lớp | Giá tương đối | |---|---| | Standard | 100% — đề chọn cái này | | Infrequent Access | ~8% + phí đọc | | Archive | ~4% + phí đọc cao hơn |

⚠ Vì sao đề chọn Standard chứ không phải IA:

Ứng dụng microservices truy cập thường xuyên
    → IA tính phí mỗi lần đọc
        ↓
    Dữ liệu nóng đặt ở IA có thể ĐẮT HƠN Standard

Ba lưu ý về EFS Access Point: | Lưu ý | Chi tiết | |---|---| | Ép thư mục gốc riêng cho từng dịch vụ | | | Ép POSIX uid/gid | | | Kết hợp IAM để phân quyền | |

aws efs create-access-point --file-system-id fs-abc \
  --posix-user 'Uid=1000,Gid=1000' \
  --root-directory 'Path=/dich-vu-a,
    CreationInfo={OwnerUid=1000,OwnerGid=1000,Permissions=0755}'

Ba lưu ý về RPO và RTO: | Chỉ số | Nghĩa | |---|---| | RPO | được phép mất bao nhiêu dữ liệu | | RTO | bao lâu để khôi phục | | Tần suất sao lưu quyết định RPO | |

⚠ AWS Backup cho EFS có hai chế độ: | Chế độ | Chi tiết | |---|---| | Sao lưu tăng dần | chỉ phần thay đổi | | Khôi phục vào thư mục mới | không ghi đè dữ liệu hiện có |

Khôi phục EFS KHÔNG đè lên file system
    → nó tạo thư mục `aws-backup-restore_<thời điểm>`
        ↓
    Phải tự chuyển tệp về đúng chỗ
    → tính vào RTO

Ba lưu ý về sao chép xuyên vùng: | Lưu ý | Chi tiết | |---|---| | Vault đích phải tồn tại trước | | | Cần KMS key ở vùng đích | | | Tính phí truyền dữ liệu | |

⚠ EFS còn có Replication riêng, khác AWS Backup:

aws efs create-replication-configuration \
  --source-file-system-id fs-abc \
  --destinations Region=ap-northeast-1

EFS Replication: RPO khoảng 15 phút, liên tục
AWS Backup:      theo lịch, có bản giữ lâu dài
        ↓
    Đề yêu cầu dùng AWS Backup → chọn theo đề

Ba lưu ý về ECS và EFS: | Lưu ý | Chi tiết | |---|---| | Fargate platform version 1.4 trở lên | | | Security group của task phải tới được cổng 2049 | | | Task role cần quyền elasticfilesystem:ClientMount | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Elastic throughput là mặc định tốt | | | Theo dõi BurstCreditBalance nếu dùng bursting | | | Không đặt CSDL trên EFS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra mount target đủ mọi AZ | | | Xác nhận job sao lưu chạy đúng chu kỳ 2 giờ | | | Khôi phục thử ở vùng thứ hai | |

aws backup list-recovery-points-by-backup-vault \
  --backup-vault-name kho-dr --max-results 5 \
  --query "RecoveryPoints[].[CreationDate,Status]" --output table

Và một lời khuyên: hãy diễn tập khôi phục ở vùng thứ hai và bấm giờ. EFS khôi phục vào một thư mục mới thay vì ghi đè, nên bước chuyển tệp về đúng vị trí là một phần thật của RTO — và nó thường dài hơn nhiều so với thời gian AWS Backup báo là "hoàn tất".

Câu 1073 AWS Networking & Content Delivery

A company runs an API on a Linux server in their on-premises data center. The company are planning to migrate the API to the AWS cloud. The company require a highly available, scalable and cost-effective solution. What should a Solutions Architect recommend?

  1. A

    Migrate the API to Amazon CloudFront and use AWS Lambda as the origin
  2. B

    Migrate the API to Amazon API Gateway and use AWS Lambda as the backend
  3. C

    Migrate the API server to Amazon EC2 instances in an Auto Scaling group and attach an Application Load Balancer
  4. D

    Migrate the API to Amazon API Gateway and migrate the backend to Amazon EC2
Xem giải thích

Đáp án

B — Chuyển API sang Amazon API Gateway và dùng AWS Lambda làm backend.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp API Gateway + Lambda đáp ứng cả ba mà không có máy chủ nào: | Yêu cầu | Cách đáp ứng | |---|---| | Sẵn sàng cao | cả hai dịch vụ đều đa AZ sẵn | | Co giãn | tự mở rộng theo lưu lượng, không cấu hình | | Tiết kiệm chi phí | không có lưu lượng = không tốn tiền |

⚠ "Không có lưu lượng = không tốn tiền" là điểm khác biệt lớn nhất:

EC2 + ALB:  ALB ~16 USD/tháng dù không ai gọi
            + tiền máy chạy 24/7
        ↓
API Gateway + Lambda:  0 request = 0 USD
            → chỉ trả theo lời gọi thật

Định giá tham khảo: | Thành phần | Giá | |---|---| | API Gateway REST | ~3,50 USD mỗi triệu request | | API Gateway HTTP API | ~1,00 USD mỗi triệu | | Lambda | ~0,20 USD mỗi triệu + thời gian chạy |

⚠ HTTP API rẻ hơn REST API khoảng 70%:

Không cần: request/response transformation,
           API key usage plan, WAF gắn trực tiếp
        ↓
    Dùng HTTP API

Dựng bằng SAM:

Resources:
  HamApi:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      Handler: app.handler
      MemorySize: 512
      Timeout: 29
      Events:
        Api:
          Type: HttpApi
          Properties:
            Path: /{proxy+}
            Method: ANY

Ba lợi ích vận hành: | Lợi ích | Chi tiết | |---|---| | Không vá hệ điều hành | | | Không cấu hình Auto Scaling | | | Không quản lý health check | |

⚠ Giới hạn phải biết trước khi chọn: | Giới hạn | Giá trị | |---|---| | Thời gian chạy Lambda tối đa | 15 phút | | Timeout API Gateway | 29 giây | | Kích thước payload | 6 MB (đồng bộ) |

API trả về trong 29 giây trở lại → hợp
API xử lý dài hơn → dùng mô hình bất đồng bộ

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

  • **C. Chuyển sang EC2 trong Auto Scaling group sau ALB — đây là phương án gần nhất và đáp ứng đủ tính sẵn sàng lẫn co giãn, nhưng kém tiết kiệm hơn: phải trả tiền máy và ALB kể cả lúc không có lưu lượng, cộng công vá và quản lý.
  • **D. API Gateway nhưng backend là EC2 — vẫn giữ máy chủ, mất phần lớn lợi ích, mà lại thêm một tầng.
  • **A. Chuyển API sang CloudFront với Lambda làm origin — CloudFront là CDN, không phải cổng API; nó không cung cấp mô hình định tuyến, xác thực và giới hạn tần suất của API Gateway.

Ghi nhớ

⚠ Ba lựa chọn chạy API trên AWS — bảng phải thuộc: | Lựa chọn | Quản lý máy chủ | Chi phí khi rảnh | |---|---|---| | API Gateway + Lambda | không | 0 | | ALB + Fargate | không có máy chủ, có container | có | | ALB + EC2 ASG | có | cao nhất |

Từ khoá nhận diện:

"highly available, scalable, cost-effective, API" → API Gateway + Lambda "long-running, > 15 minutes" → Fargate hoặc EC2 "WebSocket" → API Gateway WebSocket API "gRPC" → ALB (API Gateway không hỗ trợ)

⚠ Ba lý do KHÔNG chọn Lambda: | Lý do | Chi tiết | |---|---| | Chạy quá 15 phút | | | Cần kết nối lâu dài | | | Lưu lượng đều và rất cao | container có thể rẻ hơn |

Lưu lượng ổn định 24/7 ở mức cao
    → Lambda tính theo lời gọi có thể đắt hơn
        ↓
    Tính thử cả hai trước khi quyết

Ba lưu ý về khởi động nguội: | Lưu ý | Chi tiết | |---|---| | Lần gọi đầu sau khi rảnh chậm hơn | | | Provisioned concurrency loại bỏ nó | có phí | | Runtime biên dịch sẵn khởi động nhanh hơn | |

⚠ Provisioned concurrency đánh đổi đúng thứ Lambda có lợi:

Bật provisioned concurrency
    → trả tiền cho môi trường giữ sẵn
        ↓
    Mất lợi thế "rảnh thì không tốn"
    → chỉ bật cho endpoint nhạy cảm với độ trễ

Ba lưu ý về xác thực: | Cách | Dùng cho | |---|---| | Cognito authorizer | người dùng cuối | | Lambda authorizer | logic tuỳ chỉnh | | IAM authorization | dịch vụ nội bộ |

Ba lưu ý về giới hạn tần suất: | Lưu ý | Chi tiết | |---|---| | Đặt throttling ở stage | | | Usage plan + API key cho từng khách | REST API | | Bảo vệ backend khỏi lưu lượng đột biến | |

aws apigateway update-stage --rest-api-id abc --stage-name prod \
  --patch-operations \
    op=replace,path=/*/*/throttling/rateLimit,value=1000 \
    op=replace,path=/*/*/throttling/burstLimit,value=2000

⚠ Không đặt giới hạn là để backend hứng trọn:

Lambda mở rộng rất nhanh
    → gọi CSDL đồng thời hàng nghìn kết nối
        ↓
    CSDL sập trước khi Lambda chạm giới hạn
    → đặt reserved concurrency cho Lambda

aws lambda put-function-concurrency \
  --function-name ham-api --reserved-concurrent-executions 100

Ba lưu ý về kết nối CSDL: | Lưu ý | Chi tiết | |---|---| | RDS Proxy gộp kết nối | | | Hoặc dùng DynamoDB | không có khái niệm kết nối | | Tái dùng kết nối ngoài handler | |

Ba lưu ý về theo dõi: | Lưu ý | Chi tiết | |---|---| | Bật X-Ray xem toàn tuyến | | | Metric 4XXError, 5XXError, Latency | | | Lambda Throttles và Errors | |

Ba lưu ý về triển khai: | Lưu ý | Chi tiết | |---|---| | Dùng SAM hoặc CDK | | | Alias + weighted routing để canary | | | Stage riêng cho dev và prod | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | HTTP API rẻ hơn REST API nhiều | | | Bộ nhớ Lambda ảnh hưởng cả tốc độ lẫn giá | | | Lambda Power Tuning tìm cấu hình tối ưu | |

⚠ Bộ nhớ lớn hơn đôi khi RẺ hơn:

128 MB chạy 1000 ms
1024 MB chạy 100 ms
        ↓
    Gấp 8 lần bộ nhớ nhưng 1/10 thời gian
    → tổng chi phí thấp hơn, mà còn nhanh hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy tải giả xem có throttle không | | | Đo độ trễ p99 | | | So chi phí ước tính với EC2 | |

Và một lời khuyên: hãy đặt reserved concurrency cho Lambda khi backend là CSDL quan hệ. Lambda mở rộng nhanh hơn nhiều so với khả năng nhận kết nối của RDS, và không giới hạn nghĩa là đợt lưu lượng đầu tiên sẽ đánh sập CSDL chứ không phải làm chậm API.

Câu 1074 AWS Management & Governance

A financial services company has a large, multi-Region footprint on AWS. A recent security audit highlighted some issues that must be addressed. The company must track all configuration changes affecting AWS resources and have detailed records of who has accessed the AWS environment. The data should include information such as which user has logged in and which API calls they made

What actions should a Solutions Architect take to meet these requirements?

  1. A

    Use Amazon CloudWatch to track configuration changes and AWS Config to record API calls and track access patterns in the AWS Cloud.
  2. B

    Use AWS Config to track configuration changes and AWS CloudTrail to record API calls and track access patterns in the AWS Cloud.
  3. C

    Use Amazon Macie to track configuration changes and Amazon CloudTrail to record API calls and track access patterns in the AWS Cloud.
  4. D

    Use AWS Config to track configuration changes and Amazon EventBridge to record API calls and track access patterns in the AWS Cloud.
Xem giải thích

Đáp án

B — Dùng AWS Config để theo dõi thay đổi cấu hình và AWS CloudTrail để ghi lại các lời gọi API và mẫu truy cập.

Vì sao đúng

Đề nêu hai yêu cầu tách bạch, và mỗi dịch vụ giải quyết đúng một: | Yêu cầu | Dịch vụ | |---|---| | Theo dõi mọi thay đổi CẤU HÌNH của tài nguyên | AWS Config | | Ghi AI đã đăng nhập và gọi API nào | AWS CloudTrail |

⚠ Cách nhớ khác biệt bằng một câu:

CloudTrail: AI làm GÌ  (hành động)
Config:     tài nguyên đang ở TRẠNG THÁI nào (kết quả)

Ví dụ cụ thể trên cùng một sự việc:

Ai đó mở cổng 22 ra Internet
        ↓
CloudTrail ghi:
    "user Nam gọi AuthorizeSecurityGroupIngress
     lúc 14:32 từ IP 203.0.113.5"
        ↓
Config ghi:
    "sg-abc lúc 14:31: chỉ 10.0.0.0/8
     sg-abc lúc 14:33: thêm 0.0.0.0/0:22
     → KHÔNG TUÂN THỦ quy tắc restricted-ssh"

Bật CloudTrail cho cả tổ chức, mọi Region:

aws cloudtrail create-trail --name duong-mon-to-chuc \
  --s3-bucket-name log-cloudtrail-trung-tam \
  --is-multi-region-trail --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id <arn-khoa>
aws cloudtrail start-logging --name duong-mon-to-chuc

⚠ Ba tuỳ chọn bắt buộc bật: | Tuỳ chọn | Vì sao | |---|---| | --is-multi-region-trail | kẻ tấn công hay hoạt động ở Region ít dùng | | --enable-log-file-validation | phát hiện log bị sửa hoặc xoá | | --kms-key-id | log chứa thông tin nhạy cảm |

Bật Config với aggregator toàn tổ chức:

aws configservice put-configuration-aggregator \
  --configuration-aggregator-name tong-hop-to-chuc \
  --organization-aggregation-source \
    'RoleArn=<arn-role>,AllAwsRegions=true'

⚠ Đề nói "multi-Region footprint" — aggregator là chi tiết quan trọng:

Bật Config từng Region, từng tài khoản
    → dữ liệu nằm rải rác, không truy vấn chung được
        ↓
    Aggregator gom tất cả về một chỗ
    → truy vấn được toàn bộ dấu chân AWS

Truy vấn nâng cao của Config:

SELECT resourceId, resourceType, configuration.state.name
WHERE resourceType = 'AWS::EC2::Instance'
  AND configuration.state.name = 'running'

Ba lợi ích khi dùng cả hai: | Lợi ích | Chi tiết | |---|---| | Bức tranh đầy đủ: ai làm và kết quả ra sao | | | Đáp ứng yêu cầu kiểm toán | | | Truy ngược được dòng thời gian sự cố | |

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

  • **D. Config theo dõi cấu hình và EventBridge ghi lời gọi API — đây là phương án gần nhất vì vế đầu đúng, nhưng EventBridge là bộ định tuyến sự kiện, nó không lưu trữ lịch sử API. Nó chuyển tiếp sự kiện chứ không phải kho kiểm toán.
  • **A. CloudWatch theo dõi thay đổi cấu hình và Config ghi lời gọi API — đảo ngược vai trò của cả hai; CloudWatch là giám sát chỉ số và log ứng dụng.
  • **C. Macie theo dõi thay đổi cấu hình — Macie quét nội dung dữ liệu nhạy cảm trong S3, không liên quan gì tới cấu hình tài nguyên.

Ghi nhớ

⚠ Năm dịch vụ quan sát của AWS — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | CloudTrail | "AI đã gọi API gì?" | | Config | "tài nguyên đang cấu hình ra sao, đã đổi gì?" | | CloudWatch | "hệ thống chạy thế nào?" — chỉ số, log | | EventBridge | "khi X xảy ra thì làm Y" — định tuyến | | X-Ray | "yêu cầu này đi qua đâu, chậm ở đâu?" |

Từ khoá nhận diện:

"who made this API call", "audit user activity" → CloudTrail "configuration history", "compliance rules" → Config "metrics, alarms, application logs" → CloudWatch "trigger an action when something happens" → EventBridge

⚠ Ba loại sự kiện của CloudTrail: | Loại | Mặc định | Nội dung | |---|---|---| | Management events | BẬT, miễn phí | thao tác control plane | | Data events | TẮT, có phí | s3:GetObject, lambda:Invoke | | Insights events | TẮT, có phí | phát hiện bất thường |

Ai đọc object nào trong S3?
    → Management event KHÔNG ghi
    → phải bật Data event
        ↓
    Bật cho cả bucket lớn sinh khối lượng log khổng lồ
    → giới hạn theo tiền tố

Ba lưu ý về bảo vệ log: | Lưu ý | Chi tiết | |---|---| | Bucket log ở tài khoản RIÊNG | | | Bật Object Lock chế độ Compliance | | | MFA Delete cho bucket | |

⚠ Việc đầu tiên kẻ tấn công làm là xoá dấu vết:

Log nằm cùng tài khoản bị chiếm
    → xoá được
        ↓
    Đưa sang tài khoản log riêng, quyền ghi-chỉ-thêm
    → kể cả chiếm được tài khoản chính vẫn không xoá được

Ba quy tắc Config nên bật đầu tiên: | Quy tắc | Kiểm tra | |---|---| | s3-bucket-public-read-prohibited | bucket công khai | | restricted-ssh | cổng 22 mở ra Internet | | encrypted-volumes | EBS chưa mã hoá | | iam-user-mfa-enabled | |

⚠ Config rule có thể tự khắc phục:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "restricted-ssh",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-DisablePublicAccessForSecurityGroup",
    "Automatic": true}]'

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudTrail management event miễn phí (một trail) | | | Data event tính theo sự kiện | có thể rất lớn | | Config tính theo số mục cấu hình ghi nhận | |

Ba cách truy vấn log CloudTrail: | Cách | Chi tiết | |---|---| | CloudTrail Lake | SQL, không cần dựng gì | | Athena trên bucket log | rẻ, cần tạo bảng | | Console Event history | chỉ 90 ngày, chỉ management event |

⚠ Event history của console chỉ giữ 90 ngày — kiểm toán dài hạn phải có trail ghi ra S3.

Ba lưu ý về CloudTrail Lake: | Lưu ý | Chi tiết | |---|---| | Kho dữ liệu sự kiện có thể giữ tới 10 năm | | | Truy vấn SQL trực tiếp | | | Đắt hơn S3 + Athena | |

Ba lưu ý về cảnh báo: | Lưu ý | Chi tiết | |---|---| | EventBridge bắt sự kiện CloudTrail thời gian thực | | | Cảnh báo cho ConsoleLogin không MFA | | | Cảnh báo cho StopLogging của CloudTrail | |

⚠ Cảnh báo StopLogging là quan trọng nhất trong ba cái:

{"source": ["aws.cloudtrail"],
 "detail": {"eventName": ["StopLogging", "DeleteTrail",
                          "UpdateTrail"]}}

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đổi một security group, xem Config ghi nhận | | | Tìm lại lời gọi đó trong CloudTrail | | | Chạy validate log file | |

aws cloudtrail validate-logs --trail-arn <arn> \
  --start-time 2026-08-01T00:00:00Z

Và một lời khuyên: hãy đưa bucket log CloudTrail sang một tài khoản riêng với Object Lock. Kiểm toán chỉ có giá trị khi nó không thể bị sửa bởi chính người đang bị kiểm toán — và đó cũng là kịch bản duy nhất mà bạn thật sự cần đến nó.

Câu 1075 AWS Application Integration

An e-commerce company has developed a new application which has been successfully deployed on AWS. For an upcoming sale, the company is expecting a huge rise in traffic and while testing for the event they have encountered performance issues in the application when many requests are sent to the application.

The current application stack is Amazon Aurora PostgreSQL database with an AWS Lambda compute layer fronted by API Gateway. A solutions architect must recommend improvements scalability whilst minimizing the configuration effort.

Which solution will meet these requirements?

  1. A

    Set up two Lambda functions. Configure one function to receive the information. Configure the other function to load the information into the database. Integrate the Lambda functions by using an Amazon Simple Queue Service (Amazon SQS) queue.
  2. B

    Change the platform from Aurora to Amazon DynamoDB. Provision a DynamoDB Accelerator (DAX) cluster. Use the DAX client SDK to point the existing DynamoDB API calls at the DAX cluster.
  3. C

    Refactor the Lambda function code to Apache Tomcat code that runs on Amazon EC2 instances. Connect the database by using native Java Database Connectivity (JDBC) drivers.
  4. D

    Set up two Lambda functions. Configure one function to receive the information. Configure the other function to load the information into the database. Integrate the Lambda functions by using Amazon Simple Notification Service (Amazon SNS).
Xem giải thích

Đáp án

A — Dựng hai hàm Lambda: một hàm nhận thông tin, một hàm nạp vào CSDL. Nối chúng bằng một hàng đợi Amazon SQS.

Vì sao đúng

Đề mô tả đúng triệu chứng kinh điển: Lambda mở rộng nhanh hơn CSDL chịu được.

Nhiều yêu cầu tới cùng lúc
    → API Gateway gọi Lambda
    → Lambda mở rộng lên hàng nghìn thực thi đồng thời
        ↓
    Mỗi thực thi mở một kết nối tới Aurora
    → Aurora hết kết nối, hoặc bị quá tải
        ↓
    Lỗi ở tầng CSDL, không phải tầng Lambda

⚠ SQS làm bộ đệm hấp thụ đỉnh:

Hàm 1: nhận request, đẩy vào SQS, trả 200 NGAY
    → thời gian phản hồi rất ngắn
    → không chạm CSDL
        ↓
SQS: giữ tin nhắn, chịu được đỉnh bất kỳ
        ↓
Hàm 2: đọc từ SQS theo tốc độ CSDL chịu được
    → giới hạn bằng reserved concurrency

Giới hạn nhịp ghi bằng reserved concurrency:

aws lambda put-function-concurrency \
  --function-name ham-nap-csdl \
  --reserved-concurrent-executions 20

Tối đa 20 thực thi đồng thời
    → tối đa ~20 kết nối tới Aurora
        ↓
    CSDL không bao giờ bị quá tải

Cấu hình nguồn sự kiện SQS:

aws lambda create-event-source-mapping \
  --function-name ham-nap-csdl \
  --event-source-arn <arn-hang-doi> \
  --batch-size 10 \
  --maximum-batching-window-in-seconds 5 \
  --function-response-types ReportBatchItemFailures

⚠ ReportBatchItemFailures là tuỳ chọn nên luôn bật:

Không bật: một tin nhắn lỗi trong lô 10
    → CẢ LÔ bị đưa lại hàng đợi
    → 9 tin đã xử lý thành công bị xử lý LẠI
        ↓
Bật:  chỉ tin lỗi quay lại

def handler(su_kien, ngu_canh):
    that_bai = []
    for ban_ghi in su_kien['Records']:
        try:
            nap_vao_csdl(ban_ghi['body'])
        except Exception:
            that_bai.append({'itemIdentifier': ban_ghi['messageId']})
    return {'batchItemFailures': that_bai}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Người dùng nhận phản hồi ngay | | | Đỉnh lưu lượng không đánh sập CSDL | | | Lỗi tạm thời tự thử lại | |

⚠ "Minimizing configuration effort" — vì sao vẫn là ít công nhất:

Không đổi CSDL, không đổi ngôn ngữ,
không dựng máy chủ nào
    → chỉ thêm một hàng đợi và tách hàm làm hai

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

  • **D. Hai hàm Lambda nối bằng SNS — đây là phương án gần nhất và cũng tách hai hàm, nhưng SNS là phát tán tức thì, không có bộ đệm: tin nhắn được đẩy sang Lambda ngay, nên áp lực lên CSDL không hề giảm. SNS cũng không giữ tin nhắn để xử lý lại theo nhịp.
  • **B. Chuyển sang DynamoDB + DAX — đổi cả nền tảng CSDL là công việc lớn, ngược với "minimizing configuration effort", và DAX chỉ tăng tốc đọc trong khi vấn đề ở đây là ghi.
  • **C. Viết lại Lambda thành Tomcat trên EC2 — bỏ hẳn kiến trúc serverless, thêm máy chủ phải quản lý, và không giải quyết được đỉnh tải.

Ghi nhớ

⚠ SQS vs SNS vs EventBridge — bảng phải thuộc: | Dịch vụ | Mô hình | Có bộ đệm | |---|---|---| | SQS | kéo (poll), một người tiêu thụ mỗi tin | ✅ có | | SNS | đẩy, phát tán nhiều người nhận | ❌ | | EventBridge | đẩy, định tuyến theo mẫu | ❌ |

Từ khoá nhận diện:

"buffer, decouple, absorb spikes, throttle downstream" → SQS "fan-out to multiple subscribers" → SNS "route events by content, many AWS sources" → EventBridge "ordered, exactly-once" → SQS FIFO

⚠ Mẫu kết hợp SNS + SQS rất phổ biến:

SNS phát tán tới NHIỀU hàng đợi SQS
    → mỗi hệ thống hạ nguồn có bộ đệm riêng
        ↓
    Vừa fan-out vừa có đệm

Ba lưu ý về hàng đợi thư chết (DLQ): | Lưu ý | Chi tiết | |---|---| | Luôn cấu hình DLQ | | | maxReceiveCount thường 3-5 | | | Đặt cảnh báo khi DLQ có tin | |

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

⚠ Không có DLQ thì tin nhắn hỏng quay vòng mãi:

Tin nhắn không xử lý được
    → thử lại, thất bại, quay lại hàng đợi
        ↓
    Lặp vô hạn, tốn tiền, che khuất tin nhắn tốt

Ba lưu ý về visibility timeout: | Lưu ý | Chi tiết | |---|---| | Phải LỚN HƠN thời gian xử lý của Lambda | | | Khuyến nghị gấp 6 lần timeout hàm | | | Quá ngắn = tin nhắn bị xử lý hai lần | |

Ba lưu ý về RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Gộp kết nối cho Lambda | | | Giữ kết nối qua lúc failover | | | Kết hợp tốt với mẫu này | |

⚠ SQS và RDS Proxy giải hai phần khác nhau của cùng vấn đề:

SQS:       điều tiết SỐ LƯỢNG công việc
RDS Proxy: gộp SỐ KẾT NỐI
        ↓
    Dùng cả hai cho tải ghi nặng

Ba lưu ý về batch: | Lưu ý | Chi tiết | |---|---| | batch-size tới 10.000 với SQS chuẩn | | | Ghi theo lô hiệu quả hơn nhiều lần ghi lẻ | | | maximum-batching-window gom thêm | |

Ba lưu ý về tính bất biến khi lặp: | Lưu ý | Chi tiết | |---|---| | SQS chuẩn có thể giao tin NHIỀU HƠN một lần | | | Xử lý phải idempotent | | | Dùng khoá tự nhiên hoặc bảng khử trùng | |

⚠ Đây là điều bắt buộc phải thiết kế, không phải tuỳ chọn:

INSERT INTO don_hang (ma_don, ...) VALUES (...)
ON CONFLICT (ma_don) DO NOTHING;

Ba lưu ý về theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | tụt hậu bao lâu | | ApproximateNumberOfMessagesVisible | tồn đọng | | NumberOfMessagesSent vs Deleted | |

⚠ ApproximateAgeOfOldestMessage là chỉ số sức khoẻ tốt nhất:

Tuổi tin nhắn cũ nhất tăng đều
    → tiêu thụ chậm hơn sản xuất
        ↓
    Cảnh báo trước khi tồn đọng thành khủng hoảng

Ba lưu ý về FIFO: | Lưu ý | Chi tiết | |---|---| | Giữ thứ tự, giao đúng một lần | | | Thông lượng thấp hơn hàng đợi chuẩn | | | Chỉ dùng khi thứ tự thật sự quan trọng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy tải giả bằng lượng đỉnh dự kiến | | | Xem tồn đọng có tiêu hết không | | | Kiểm tra kết nối CSDL không vượt giới hạn | |

Và một lời khuyên: hãy đặt reserved concurrency cho hàm ghi CSDL ngay khi dựng mẫu này. SQS hấp thụ đỉnh tốt đến mức vô nghĩa nếu Lambda phía sau vẫn mở rộng tự do — hàng đợi chỉ trở thành van điều tiết khi bạn nói cho nó biết van mở bao nhiêu.

Câu 1076 AWS Compute

A company observed an increase in Amazon EC2 costs in its most recent bill. The billing team noticed unwanted vertical scaling of instance types for a couple of EC2 instances. A solutions architect needs to create a graph comparing the last 2 months of EC2 costs and perform an in-depth analysis to identify the root cause of the vertical scaling.

How should the solutions architect generate the information with the LEAST operational overhead?

  1. A

    Use AWS Budgets to create a budget report and compare EC2 costs based on instance types.
  2. B

    Use Cost Explorer's granular filtering feature to perform an in-depth analysis of EC2 costs based on instance types.
  3. C

    Use graphs from the AWS Billing and Cost Management dashboard to compare EC2 costs based on instance types for the last 2 months.
  4. D

    Use AWS Cost and Usage Reports to create a report and send it to an Amazon S3 bucket. Use Amazon QuickSight with Amazon S3 as a source to generate an interactive graph based on instance types.
Xem giải thích

Đáp án

B — Dùng khả năng lọc chi tiết của Cost Explorer để phân tích sâu chi phí EC2 theo loại instance.

Vì sao đúng

Đề nêu ba yêu cầu, và Cost Explorer đáp ứng cả ba mà không phải dựng gì: | Yêu cầu | Cách đáp ứng | |---|---| | Đồ thị so sánh 2 tháng gần nhất | Cost Explorer có sẵn 13 tháng dữ liệu | | Phân tích sâu tìm nguyên nhân | lọc và nhóm theo INSTANCE_TYPE | | CÔNG VẬN HÀNH ÍT NHẤT | bật một lần, dùng ngay, không dựng gì |

⚠ "Least operational overhead" là tiêu chí quyết định:

Cost Explorer: bật lên, chọn bộ lọc, xem đồ thị
        ↓
CUR + QuickSight: tạo báo cáo, đợi ~24 giờ có dữ liệu,
                  dựng bảng Athena, tạo dataset,
                  dựng phân tích, xuất bản dashboard

Truy vấn bằng CLI:

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-08-01 \
  --granularity DAILY --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE",
              "Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --group-by Type=DIMENSION,Key=INSTANCE_TYPE

⚠ Nhóm theo INSTANCE_TYPE là chính xác thứ đề cần:

Đề nói: "unwanted vertical scaling of instance types"
    → tức là máy bị đổi sang loại LỚN HƠN
        ↓
    Nhóm theo loại instance
    → thấy ngay m5.large giảm, m5.4xlarge tăng

Kết hợp thêm chiều để tìm thủ phạm: | Nhóm theo | Trả lời | |---|---| | INSTANCE_TYPE | loại nào tăng | | LINKED_ACCOUNT | tài khoản nào | | Tag Nhom hoặc DuAn | đội nào | | USAGE_TYPE | chi tiết theo Region |

⚠ Rồi ghép với CloudTrail để biết AI đổi:

Cost Explorer:  "m5.4xlarge xuất hiện từ ngày 12/07"
        ↓
CloudTrail:     "ModifyInstanceAttribute lúc 12/07 09:14
                 bởi vai trò trien-khai-tu-dong"
        ↓
    Đủ để chốt nguyên nhân

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải dựng hạ tầng phân tích | | | Dữ liệu lịch sử có sẵn tới 13 tháng | | | Có sẵn khuyến nghị tiết kiệm | |

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

  • **D. Dùng Cost and Usage Report đổ vào S3 rồi phân tích bằng QuickSight — đây là phương án gần nhất và cho phân tích chi tiết nhất, nhưng công vận hành cao hơn hẳn: tạo báo cáo, chờ dữ liệu đầu tiên, dựng bảng, dựng dataset, dựng dashboard. Đề nói rõ "LEAST operational overhead".
  • **A. Dùng AWS Budgets — Budgets để đặt ngưỡng và cảnh báo, nó không phải công cụ phân tích sâu và không vẽ được đồ thị so sánh theo loại instance.
  • **C. Dùng đồ thị trên bảng điều khiển Billing — bảng đó chỉ tổng hợp theo dịch vụ, không lọc được xuống mức loại instance.

Ghi nhớ

⚠ Bốn công cụ quản lý chi phí — bảng phải thuộc: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích và trực quan hoá, có sẵn | | AWS Budgets | đặt ngưỡng và CẢNH BÁO | | Cost and Usage Report (CUR) | dữ liệu THÔ chi tiết nhất | | Compute Optimizer | khuyến nghị đổi cỡ máy |

Từ khoá nhận diện:

"analyze and visualize costs, least overhead" → Cost Explorer "alert when spending exceeds" → Budgets "most granular data, custom BI" → CUR + Athena/QuickSight "right-size my instances" → Compute Optimizer

⚠ CUR là nguồn chi tiết nhất, nhưng phải dựng:

CUR: một dòng cho mỗi giờ mỗi tài nguyên
    → chi tiết tuyệt đối
        ↓
    Nhưng là tệp Parquet trên S3
    → cần Athena hoặc QuickSight mới đọc được

Ba chỉ số chi phí hay nhầm: | Chỉ số | Nghĩa | |---|---| | UnblendedCost | giá thực tế từng tài khoản | | BlendedCost | giá trung bình trong tổ chức | | AmortizedCost | rải đều chi phí trả trước của RI/SP |

⚠ Dùng AmortizedCost khi có Reserved Instance:

UnblendedCost: khoản trả trước RI dồn hết vào một tháng
    → đồ thị có một đỉnh vô nghĩa
        ↓
AmortizedCost: rải đều theo tháng
    → phản ánh đúng chi phí thật

Ba cách ngăn "vertical scaling" ngoài ý muốn: | Cách | Chi tiết | |---|---| | SCP giới hạn loại instance được phép | | | Config rule desired-instance-type | | | Budget action tự dừng khi vượt ngưỡng | |

SCP giới hạn loại máy:

{"Effect": "Deny",
 "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringNotEquals":
   {"ec2:InstanceType": ["t3.micro","t3.small","m5.large"]}}}

⚠ Đây là biện pháp mạnh nhất — chặn từ gốc:

Phát hiện sau khi có hoá đơn = đã mất tiền rồi
    → SCP chặn ngay lúc tạo
        ↓
    Không bao giờ có chi phí bất ngờ để đi tìm

Ba lưu ý về gắn tag chi phí: | Lưu ý | Chi tiết | |---|---| | Phải KÍCH HOẠT tag trong Billing console | | | Tag chỉ có tác dụng từ lúc kích hoạt | | | Không hồi tố cho dữ liệu cũ | |

⚠ Đây là lỗi hay gặp nhất về tag chi phí:

Gắn tag đầy đủ cho mọi tài nguyên
    → nhưng quên kích hoạt tag làm cost allocation tag
        ↓
    Cost Explorer không nhóm theo tag đó được
    → và không lấy lại được dữ liệu quá khứ

Ba lưu ý về dự báo: | Lưu ý | Chi tiết | |---|---| | Cost Explorer dự báo tới 12 tháng | | | Dựa trên xu hướng lịch sử | | | Không biết trước sự kiện đặc biệt | |

Ba lưu ý về Budgets: | Loại | Chi tiết | |---|---| | Budget chi phí | cảnh báo theo tiền | | Budget sử dụng | theo giờ máy | | Budget action | tự áp policy chặn khi vượt |

aws budgets create-budget --account-id 123456789012 \
  --budget '{"BudgetName":"ngan-sach-ec2",
    "BudgetLimit":{"Amount":"5000","Unit":"USD"},
    "TimeUnit":"MONTHLY","BudgetType":"COST",
    "CostFilters":{"Service":["Amazon Elastic Compute Cloud - Compute"]}}'

Ba lưu ý về Compute Optimizer: | Lưu ý | Chi tiết | |---|---| | Cần ít nhất 14 ngày dữ liệu | | | Bật memory metric cho khuyến nghị chính xác hơn | | | Miễn phí | |

Ba lưu ý về phí Cost Explorer: | Lưu ý | Chi tiết | |---|---| | Xem trên console miễn phí | | | Gọi API tính ~0,01 USD mỗi request | | | Script gọi liên tục cũng thành khoản đáng kể | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lọc theo INSTANCE_TYPE cho 2 tháng | | | Đối chiếu ngày tăng với CloudTrail | | | Đặt Budget để lần sau biết sớm | |

Và một lời khuyên: hãy đặt AWS Budget ngay sau khi tìm ra nguyên nhân. Cost Explorer giỏi giải thích chuyện đã xảy ra, nhưng nó không bao giờ đánh thức ai lúc chi phí đang tăng — và bài học của lần này chỉ có giá trị nếu lần sau bạn biết trong vòng một ngày thay vì khi nhận hoá đơn.

Câu 1077 AWS Compute

A Solutions Architect is designing an application for processing and extracting data from log files. The log files are generated by an application and the number and frequency of updates varies. The files are up to 1 GB in size and processing will take around 40 seconds for each file.

Which solution is the most cost-effective?

  1. A

    Write the log files to an Amazon EC2 instance with an attached EBS volume. After processing, save the files to an Amazon S3 bucket
  2. B

    Write the log files to an Amazon SQS queue. Use AWS Lambda to process the files from the queue and save to an Amazon S3 bucket
  3. C

    Write the log files to an Amazon S3 bucket. Create an event notification to invoke an Amazon ECS task to process the files and save to an Amazon S3 bucket
  4. D

    Write the log files to an Amazon S3 bucket. Create an event notification to invoke an AWS Lambda function that will process the files
Xem giải thích

Đáp án

D — Ghi tệp log vào bucket S3, tạo event notification kích hoạt một hàm AWS Lambda xử lý tệp.

Vì sao đúng

Đề cho ba dữ kiện, và cả ba đều nằm gọn trong giới hạn của Lambda: | Dữ kiện | Lambda có đáp ứng | |---|---| | Tệp tới 1 GB | ✅ đọc theo luồng từ S3, không cần nạp hết | | Xử lý ~40 giây mỗi tệp | ✅ giới hạn là 15 phút | | Số lượng và tần suất THẤT THƯỜNG | ✅ rảnh thì không tốn tiền |

⚠ "Thất thường" là từ khoá quyết định tính tiết kiệm:

Máy chạy 24/7: trả tiền cả lúc không có tệp nào
        ↓
Lambda: 0 tệp = 0 USD
    → và đỉnh 1000 tệp cùng lúc cũng xử lý được

Cấu hình thông báo S3:

aws s3api put-bucket-notification-configuration \
  --bucket log-ung-dung \
  --notification-configuration '{
    "LambdaFunctionConfigurations": [{
      "LambdaFunctionArn": "<arn-ham>",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": {"Key": {"FilterRules": [
        {"Name": "prefix", "Value": "log-tho/"},
        {"Name": "suffix", "Value": ".log"}]}}}]}'

⚠ Luôn lọc theo tiền tố và hậu tố:

Không lọc: hàm được gọi cho MỌI object
    → kể cả tệp kết quả do chính nó ghi ra
        ↓
    Ghi kết quả vào cùng bucket = VÒNG LẶP VÔ HẠN
    → hoá đơn tăng không giới hạn

Đọc theo luồng, không nạp cả 1 GB vào bộ nhớ:

import boto3
s3 = boto3.client('s3')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        gau = ban_ghi['s3']['bucket']['name']
        khoa = ban_ghi['s3']['object']['key']
        doi_tuong = s3.get_object(Bucket=gau, Key=khoa)
        for dong in doi_tuong['Body'].iter_lines():
            xu_ly(dong)

⚠ Đây là điểm kỹ thuật quan trọng nhất của câu này:

Lambda có tối đa 10 GB bộ nhớ, nhưng
đọc theo luồng thì chỉ cần vài chục MB
        ↓
    Tệp 1 GB xử lý được với hàm 512 MB
    → miễn là không gọi read() nguyên khối

Cấu hình hàm:

aws lambda update-function-configuration \
  --function-name xu-ly-log \
  --timeout 300 --memory-size 1024

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ nào chạy khi rảnh | | | Tự mở rộng khi nhiều tệp tới cùng lúc | | | Kích hoạt tức thì khi tệp xuất hiện | |

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

  • **C. Ghi vào S3 rồi kích hoạt một tác vụ ECS — đây là phương án gần nhất và cũng đúng về mặt kiến trúc sự kiện, nhưng với việc chỉ mất 40 giây thì khởi động một tác vụ container tốn thời gian và chi phí hơn Lambda. ECS đáng dùng khi vượt 15 phút hoặc cần thư viện lớn.
  • **B. Ghi log vào SQS rồi Lambda xử lý — SQS giới hạn 256 KB mỗi tin nhắn, không chứa nổi tệp 1 GB.
  • **A. Ghi vào EC2 có EBS rồi lưu sang S3 — phải trả tiền máy chạy liên tục trong khi tải thất thường, đắt nhất và nhiều việc nhất.

Ghi nhớ

⚠ Ba giới hạn Lambda quyết định chọn hay không — bảng phải thuộc: | Giới hạn | Giá trị | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 128 MB – 10 GB | | Dung lượng /tmp | 512 MB – 10 GB | | Payload đồng bộ | 6 MB | | Payload bất đồng bộ | 256 KB |

Từ khoá nhận diện:

"< 15 minutes, event-driven, unpredictable" → Lambda "> 15 minutes, or needs large libraries" → Fargate / ECS "batch jobs with dependencies, thousands of jobs" → AWS Batch "steady constant load" → EC2 hoặc Fargate

⚠ Ba giới hạn của SQS đáng nhớ: | Giới hạn | Giá trị | |---|---| | Kích thước tin nhắn | 256 KB | | Giữ tin tối đa | 14 ngày | | Extended Client Library | lưu payload lớn ở S3 |

Muốn gửi payload lớn qua SQS
    → lưu ở S3, gửi ĐƯỜNG DẪN qua SQS
    → chính là mẫu Extended Client Library

Ba lưu ý về S3 event notification: | Lưu ý | Chi tiết | |---|---| | Giao ít nhất một lần — có thể trùng | | | Không đảm bảo thứ tự | | | Có độ trễ thường dưới một giây | |

⚠ Vì có thể trùng, xử lý phải idempotent:

Cùng một tệp có thể kích hoạt hàm hai lần
    → ghi kết quả hai lần
        ↓
    Đặt tên tệp kết quả theo tên tệp nguồn
    → lần thứ hai chỉ ghi đè, không nhân đôi

Ba cách kích hoạt từ S3: | Cách | Khi nào | |---|---| | Event notification trực tiếp | đơn giản nhất | | EventBridge | cần lọc phức tạp, nhiều đích | | S3 Event Notifications tới SQS | cần đệm và thử lại |

⚠ Qua SQS cho độ tin cậy cao hơn:

S3 → Lambda trực tiếp: Lambda lỗi thì thử lại 2 lần rồi bỏ
        ↓
S3 → SQS → Lambda: tin nhắn nằm trong hàng đợi
    → thử lại nhiều lần, hỏng thì vào DLQ
    → không mất tệp nào

Ba lưu ý về đồng thời: | Lưu ý | Chi tiết | |---|---| | Mặc định 1000 thực thi đồng thời mỗi tài khoản | | | Nghìn tệp cùng lúc có thể chạm trần | | | Đặt reserved concurrency để bảo vệ hàm khác | |

Ba lưu ý về chi phí Lambda: | Lưu ý | Chi tiết | |---|---| | Tính theo GB-giây | | | Bộ nhớ lớn hơn có thể RẺ hơn nếu nhanh hơn | | | 1 triệu request đầu mỗi tháng miễn phí | |

⚠ Tính thử với đề này:

1024 MB × 40 giây = 40 GB-giây mỗi tệp
    → ~0,00067 USD mỗi tệp
        ↓
    10.000 tệp mỗi tháng ≈ 6,7 USD
    → so với một máy t3.medium chạy 24/7 ≈ 30 USD

Ba lưu ý về xử lý lỗi: | Lưu ý | Chi tiết | |---|---| | Cấu hình DLQ hoặc destination cho lỗi | | | Đặt cảnh báo cho metric Errors | | | Ghi log đủ để tìm lại tệp hỏng | |

aws lambda put-function-event-invoke-config \
  --function-name xu-ly-log --maximum-retry-attempts 2 \
  --destination-config '{"OnFailure":{"Destination":"<arn-sqs-dlq>"}}'

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Đọc theo luồng thay vì nạp cả tệp | | | Dùng S3 Select nếu chỉ cần một phần | | | Nén tệp giảm thời gian tải | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tệp 1 GB, xem hàm chạy xong | | | Kiểm tra bộ nhớ dùng thật trong log | | | Đẩy 100 tệp cùng lúc, xem có throttle | |

Và một lời khuyên: hãy ghi tệp kết quả sang một bucket khác, hoặc lọc chặt theo tiền tố. Vòng lặp tự kích hoạt là lỗi phổ biến nhất của mẫu S3-triggered Lambda, và nó không dừng lại cho tới khi ai đó nhìn thấy hoá đơn.

Câu 1078 AWS Migration & Transfer

A Solutions Architect is designing a migration strategy for a company moving to the AWS Cloud. The company use a shared Microsoft filesystem that uses Distributed File System Namespaces (DFSN). What will be the MOST suitable migration strategy for the filesystem?

  1. A

    Use the AWS Server Migration Service to migrate to Amazon FSx for Lustre
  2. B

    Use the AWS Server Migration Service to migrate to an Amazon S3 bucket
  3. C

    Use AWS DataSync to migrate to Amazon FSx for Windows File Server
  4. D

    Use AWS DataSync to migrate to an Amazon EFS filesystem
Xem giải thích

Đáp án

C — Dùng AWS DataSync để di chuyển sang Amazon FSx for Windows File Server.

Vì sao đúng

Đề nêu hai dữ kiện, mỗi cái quyết định một nửa câu trả lời: | Dữ kiện | Kết luận | |---|---| | Hệ thống tệp Microsoft dùng DFS Namespaces | đích phải là FSx for Windows | | Cần công cụ di chuyển | DataSync |

⚠ DFS Namespaces là tính năng CHỈ có ở Windows:

DFSN gộp nhiều share nằm rải rác
thành MỘT cây thư mục logic
    → \\congty.vn\dulieu\ketoan
    → \\congty.vn\dulieu\nhansu
        ↓
    Người dùng thấy một cây, thực tế nhiều máy chủ

FSx for Windows hỗ trợ DFS Namespaces gốc — đây là dịch vụ AWS duy nhất làm được.

Dựng DataSync:

# Vị trí nguồn: SMB share tại chỗ
aws datasync create-location-smb \
  --server-hostname may-chu-tep.congty.vn \
  --subdirectory /dulieu \
  --user quantri --domain CONGTY \
  --password '<mat-khau>' \
  --agent-arns <arn-agent>

# Vị trí đích: FSx for Windows
aws datasync create-location-fsx-windows \
  --fsx-filesystem-arn <arn-fsx> \
  --security-group-arns <arn-sg> \
  --user quantri --domain CONGTY --password '<mat-khau>'

aws datasync create-task \
  --source-location-arn <arn-nguon> \
  --destination-location-arn <arn-dich> \
  --options 'VerifyMode=POINT_IN_TIME_CONSISTENT,
             PreserveDeletedFiles=PRESERVE,
             SecurityDescriptorCopyFlags=OWNER_DACL_SACL'

⚠ SecurityDescriptorCopyFlags là tuỳ chọn quan trọng nhất:

Không đặt: tệp chuyển sang nhưng MẤT ACL
    → mọi quyền NTFS phải cấu hình lại bằng tay
        ↓
OWNER_DACL_SACL: giữ chủ sở hữu, quyền, và audit
    → người dùng truy cập y như cũ

DataSync còn cho ba thứ mà robocopy không có: | Thứ | Chi tiết | |---|---| | Truyền song song, nhanh gấp nhiều lần | | | Xác minh toàn vẹn dữ liệu tự động | | | Theo dõi và báo cáo qua CloudWatch | |

⚠ Quy trình chuyển đổi thực tế:

1. Chạy DataSync lần đầu (khối lượng lớn nhất)
2. Chạy lại nhiều lần — mỗi lần chỉ chép phần đổi
3. Chọn cửa sổ ngừng dịch vụ ngắn
4. Chạy lần cuối, chuyển DFS namespace sang FSx
        ↓
    Thời gian ngừng chỉ vài chục phút

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giữ nguyên DFS Namespaces và ACL | | | Ứng dụng và người dùng không đổi cách làm việc | | | AWS quản lý vá, sao lưu, sẵn sàng cao | |

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

  • **D. Dùng DataSync di chuyển sang Amazon EFS — đây là phương án gần nhất vì dùng đúng công cụ di chuyển, nhưng EFS dùng NFS và không hỗ trợ Windows, càng không hỗ trợ DFS Namespaces.
  • **A. Dùng Server Migration Service sang FSx for Lustre — SMS di chuyển máy ảo, không phải dữ liệu tệp; và Lustre dành cho HPC, không hỗ trợ SMB.
  • **B. Dùng SMS sang S3 — S3 là lưu trữ đối tượng, không phải hệ thống tệp SMB.

Ghi nhớ

⚠ Bốn công cụ di chuyển dữ liệu — bảng phải thuộc: | Công cụ | Di chuyển gì | |---|---| | DataSync | dữ liệu TỆP qua mạng | | Snowball / Snow Family | dữ liệu lớn khi mạng yếu | | DMS | CƠ SỞ DỮ LIỆU | | Application Migration Service (MGN) | MÁY CHỦ nguyên vẹn |

⚠ AWS Server Migration Service (SMS) đã ngừng — thay bằng Application Migration Service (MGN). Nhiều đề cũ còn nhắc SMS; biết để nhận ra nó là phương án lỗi thời.

Từ khoá nhận diện:

"Windows file share, DFS, SMB, Active Directory" → FSx for Windows "migrate file data over network" → DataSync "low bandwidth, petabytes" → Snowball "migrate database" → DMS "lift and shift servers" → MGN

Ba loại vị trí DataSync hỗ trợ: | Nguồn | Đích | |---|---| | NFS, SMB, HDFS, object storage | S3, EFS, FSx (mọi loại) | | S3 ở vùng khác | | | Giữa hai vị trí AWS | |

⚠ DataSync còn dùng để đồng bộ liên tục, không chỉ di chuyển một lần:

aws datasync update-task --task-arn <arn> \
  --schedule 'ScheduleExpression=cron(0 2 * * ? *)'

Ba lưu ý về DataSync agent: | Lưu ý | Chi tiết | |---|---| | Cần agent cho nguồn tại chỗ | | | Agent là máy ảo VMware/Hyper-V/KVM hoặc EC2 | | | Không cần agent khi cả hai đầu ở AWS | |

Ba tuỳ chọn quan trọng của task: | Tuỳ chọn | Ý nghĩa | |---|---| | PreserveDeletedFiles=PRESERVE | không xoá tệp ở đích | | PreserveDeletedFiles=REMOVE | nhân bản y hệt, có xoá | | OverwriteMode | ghi đè hay bỏ qua |

⚠ Chọn nhầm REMOVE là mất dữ liệu:

REMOVE: tệp không có ở nguồn thì XOÁ ở đích
    → đúng khi muốn nhân bản chính xác
        ↓
    Sai khi đích đã có dữ liệu khác

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Đặt BytesPerSecond để giới hạn | | | Chạy ngoài giờ làm việc | | | Qua Direct Connect nhanh và ổn định hơn | |

Ba lưu ý về FSx for Windows: | Lưu ý | Chi tiết | |---|---| | BẮT BUỘC nối Active Directory | | | Multi-AZ cho sản xuất | | | Bật deduplication tiết kiệm nhiều | |

⚠ Nối AD là điều kiện tiên quyết hay bị quên trong kế hoạch:

Chưa có AD trên AWS
    → phải dựng AWS Managed Microsoft AD
    → hoặc thiết lập trust với AD tại chỗ
        ↓
    Đây là việc vài ngày, không phải vài giờ

Ba lưu ý về DFS Namespaces trên AWS: | Lưu ý | Chi tiết | |---|---| | FSx là file server, không phải DFS server | | | Cần EC2 chạy DFS Namespace role | | | Hai máy DFS-N cho tính sẵn sàng | |

Ba lưu ý về kiểm tra sau di chuyển: | Việc | Cách | |---|---| | So số tệp và dung lượng | | | Kiểm tra ACL trên tệp mẫu | | | Thử truy cập bằng tài khoản người dùng thật | |

Get-Acl \\amznfsxabc.congty.vn\dulieu\ketoan | Format-List

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | DataSync ~0,0125 USD mỗi GB truyền | | | FSx theo GB cấp phát | | | Deduplication giảm dung lượng cần cấp | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem báo cáo task của DataSync | | | Đối chiếu số tệp hai bên | | | Kiểm tra DFS namespace trỏ đúng | |

Và một lời khuyên: hãy đặt SecurityDescriptorCopyFlags ngay từ lần chạy thử đầu tiên. Dữ liệu chuyển sang mà mất hết ACL trông giống như thành công cho tới khi người dùng đầu tiên báo họ không mở được thư mục — và lúc đó việc dựng lại quyền cho hàng nghìn thư mục là công việc thủ công không có đường tắt.

Câu 1079 AWS Analytics

A traffic law enforcement company is building a solution that has thousands of edge devices that collectively generate 1 TB of status alerts each day. These devices provide vehicle information and number plate data whenever alerts detecting red light jumps are detected. Each entry is around 2Kb in size. A solutions architect needs to implement a solution to ingest and store the alerts for future analysis.

The company wants a highly available solution. However, the company needs to minimize costs and does not want to manage additional infrastructure. Additionally, the company wants to keep 14 days of data available for immediate analysis and archive any data older than 14 days.

What is the MOST operationally efficient solution that meets these requirements?

  1. A

    Create an Amazon Kinesis Data Firehose delivery stream to ingest the alerts. Configure the kinesis Data Firehose stream to deliver the alerts to an Amazon OpenSearch Service (Amazon Elasticsearch Service) cluster. Set up the Amazon Open Search Service (Amazon Elasticsearch Service) cluster to take manual snapshots every day and delete data from the cluster that is older than 14 days.
  2. B

    Launch Amazon EC2 instances across two Availability Zones and place them behind an Elastic Load Balancer to ingest the alerts. Create a script on the EC2 instances that will store the alerts in an Amazon S3 bucket. Set up an S3 Lifecycle configuration to transition data to Amazon S3 Glacier after 14 days.
  3. C

    Create an Amazon Kinesis Data Firehose delivery stream to ingest the alerts. Configure the Kinesis Data Firehose stream to deliver the alerts to an Amazon S3 bucket. Set up an S3 Lifecycle configuration to transition data to Amazon S3 Glacier after 14 days.
  4. D

    Create an Amazon Simple Queue Service (Amazon SQS) standard queue to ingest the alerts and set the message retention period to 14 days. Configure consumers to poll the SQS queue, check the age of the message, and analyze the message data as needed. If the message is 14 days old, the consumer should copy the message to an Amazon S3 bucket and delete the message from the SQS queue.
Xem giải thích

Đáp án

C — Tạo luồng Kinesis Data Firehose để nhận cảnh báo, đưa vào bucket S3, và đặt S3 Lifecycle chuyển sang S3 Glacier sau 14 ngày.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Nhận 1 TB mỗi ngày từ hàng nghìn thiết bị | Firehose tự mở rộng | | Không quản lý thêm hạ tầng | Firehose hoàn toàn được quản lý | | 14 ngày sẵn sàng phân tích ngay | S3 Standard, truy vấn bằng Athena | | Lưu trữ dữ liệu cũ hơn 14 ngày | Lifecycle sang Glacier |

⚠ Firehose khác Kinesis Data Streams ở chỗ không cần quản lý gì:

Kinesis Data Streams: phải chọn số shard,
                      phải theo dõi, phải chia lại
        ↓
Firehose: không có shard, không có gì để chỉnh
    → đúng nghĩa "không quản lý hạ tầng"

Tạo luồng:

aws firehose create-delivery-stream \
  --delivery-stream-name canh-bao-den-do \
  --delivery-stream-type DirectPut \
  --extended-s3-destination-configuration '{
    "RoleARN": "<arn-role>",
    "BucketARN": "arn:aws:s3:::canh-bao-giao-thong",
    "Prefix": "du-lieu/nam=!{timestamp:yyyy}/thang=!{timestamp:MM}/ngay=!{timestamp:dd}/",
    "ErrorOutputPrefix": "loi/",
    "BufferingHints": {"SizeInMBs": 128, "IntervalInSeconds": 300},
    "CompressionFormat": "GZIP",
    "DataFormatConversionConfiguration": {"Enabled": true}}'

⚠ Gộp bản ghi nhỏ là lý do quan trọng nhất để dùng Firehose ở đây:

Mỗi cảnh báo chỉ 2 KB
    → ghi thẳng vào S3 = 500 triệu object mỗi ngày
        ↓
    Firehose gom thành tệp 128 MB
    → vài nghìn object mỗi ngày
    → Athena truy vấn nhanh hơn hàng trăm lần

Lifecycle chuyển sang Glacier:

aws s3api put-bucket-lifecycle-configuration \
  --bucket canh-bao-giao-thong \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "luu-tru-sau-14-ngay",
      "Filter": {"Prefix": "du-lieu/"},
      "Status": "Enabled",
      "Transitions": [{
        "Days": 14,
        "StorageClass": "GLACIER"}]}]}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ hay cụm nào | | | Chi phí lưu trữ giảm ~83% sau 14 ngày | | | Athena truy vấn dữ liệu 14 ngày ngay | |

⚠ Chi phí lưu trữ so sánh: | Lớp | Giá tham khảo mỗi GB-tháng | |---|---| | S3 Standard | ~0,023 USD | | S3 Glacier Flexible Retrieval | ~0,0036 USD |

1 TB/ngày × 14 ngày = 14 TB ở Standard
Phần còn lại ở Glacier
    → khoản tiết kiệm tăng theo thời gian

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

  • **A. Firehose đưa vào OpenSearch rồi chụp snapshot thủ công hằng ngày — đây là phương án gần nhất và cho khả năng phân tích mạnh nhất, nhưng cụm OpenSearch là hạ tầng phải quản lý (đúng thứ đề nói muốn tránh), đắt hơn nhiều, và "snapshot thủ công mỗi ngày" là công vận hành lặp đi lặp lại.
  • **B. Dùng EC2 sau load balancer và script tự ghi vào S3 — tự dựng lại thứ Firehose làm sẵn, phải quản lý máy, và script tự viết không có cơ chế thử lại và đệm của Firehose.
  • **D. Dùng SQS giữ 14 ngày rồi consumer tự kiểm tra tuổi tin nhắn — SQS là hàng đợi, không phải kho lưu trữ để phân tích; không truy vấn được, và logic "kiểm tra tuổi rồi chép sang S3" là công vận hành tự chuốc lấy.

Ghi nhớ

⚠ Kinesis Data Streams vs Firehose — bảng phải thuộc: | Tiêu chí | Data Streams | Firehose | |---|---|---| | Quản lý | chọn shard, tự chỉnh | không có gì để chỉnh | | Độ trễ | ~200 ms | tối thiểu 60 giây | | Đích | tuỳ ứng dụng đọc | S3, Redshift, OpenSearch, Splunk | | Giữ dữ liệu | 1-365 ngày, đọc lại được | không giữ | | Nhiều người tiêu thụ | ✅ | ❌ |

Từ khoá nhận diện:

"deliver to S3/Redshift, no infrastructure" → Firehose "sub-second, multiple consumers, replay" → Data Streams "real-time SQL/analytics on stream" → Managed Service for Apache Flink "IoT devices, MQTT" → IoT Core

⚠ Firehose có độ trễ tối thiểu 60 giây — cần thời gian thực đúng nghĩa thì phải dùng Data Streams.

Ba lớp Glacier — chọn theo thời gian lấy lại: | Lớp | Thời gian lấy | |---|---| | Glacier Instant Retrieval | mili giây | | Glacier Flexible Retrieval | 1-5 phút (Expedited) tới 5-12 giờ | | Glacier Deep Archive | 12-48 giờ, rẻ nhất |

⚠ "S3 Glacier" trong lifecycle nghĩa là Flexible Retrieval — đây là lớp lưu trữ, không phải dịch vụ vault cũ.

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Glacier có thời gian lưu tối thiểu 90 ngày | | | Xoá sớm vẫn tính đủ 90 ngày | | | Object nhỏ hơn 128 KB không nên chuyển | |

Object 2 KB chuyển sang Glacier
    → phí siêu dữ liệu (40 KB mỗi object)
    → ĐẮT HƠN giữ ở Standard
        ↓
    Đây chính là lý do Firehose gộp thành tệp lớn

Ba lưu ý về phân vùng dữ liệu: | Lưu ý | Chi tiết | |---|---| | Dùng tiền tố kiểu Hive nam=/thang=/ngay= | | | Athena cắt bỏ phân vùng không cần | | | Firehose hỗ trợ dynamic partitioning | |

⚠ Phân vùng quyết định chi phí truy vấn:

Không phân vùng: mỗi truy vấn quét CẢ 14 TB
        ↓
Phân vùng theo ngày: truy vấn một ngày quét 1 TB
    → hoá đơn Athena giảm 14 lần

Ba lưu ý về định dạng: | Định dạng | Ưu điểm | |---|---| | Parquet | quét ít nhất, nén tốt nhất | | GZIP JSON | đơn giản, vẫn nén | | JSON thô | dễ đọc, tốn nhất |

Firehose chuyển sang Parquet được ngay trong luồng — bật DataFormatConversionConfiguration.

Ba lưu ý về đệm của Firehose: | Tham số | Đánh đổi | |---|---| | SizeInMBs 1-128 | lớn hơn = tệp lớn hơn, trễ hơn | | IntervalInSeconds 60-900 | | | Firehose ghi khi đạt điều kiện nào TRƯỚC | |

Ba lưu ý về chuyển đổi dữ liệu: | Lưu ý | Chi tiết | |---|---| | Lambda transform ngay trong luồng | | | Bản ghi hỏng đi vào tiền tố lỗi | | | Không làm mất dữ liệu gốc | |

Ba lưu ý về theo dõi: | Metric | Ý nghĩa | |---|---| | DeliveryToS3.Success | tỷ lệ giao thành công | | IncomingBytes | lượng vào | | ThrottledRecords | chạm hạn ngạch |

Ba lưu ý về hạn ngạch: | Hạn ngạch | Giá trị mặc định | |---|---| | Thông lượng mỗi luồng | 5 MB/s hoặc 2000 bản ghi/s | | Tăng được qua Support | | | 1 TB/ngày ≈ 12 MB/s — cần tăng | |

⚠ Đây là chi tiết thực tế quan trọng của đề này:

1 TB mỗi ngày = ~12 MB/s trung bình
    → vượt hạn ngạch mặc định 5 MB/s
        ↓
    Phải yêu cầu tăng hạn ngạch TRƯỚC khi lên sản xuất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi bản ghi thử, xem xuất hiện ở S3 | | | Chạy truy vấn Athena trên dữ liệu 14 ngày | | | Kiểm tra object cũ đã chuyển sang Glacier | |

Và một lời khuyên: hãy yêu cầu tăng hạn ngạch thông lượng Firehose trước khi bật lưu lượng thật. Ở mức 1 TB mỗi ngày bạn đang ở gấp hơn hai lần hạn ngạch mặc định, và bản ghi bị từ chối vì throttling không quay lại — chúng biến mất cùng với đúng những cảnh báo mà hệ thống được dựng ra để ghi lại.

Câu 1080 AWS Storage

A large quantity of data is stored on a NAS device on-premises and accessed using the SMB protocol. The company require a managed service for hosting the filesystem and a tool to automate the migration.

Which actions should a Solutions Architect take?

  1. A

    Migrate the data to Amazon FSx for Lustre using AWS DataSync
  2. B

    Migrate the data to Amazon EFS using the AWS Server Migration Service (SMS)
  3. C

    Migrate the data to Amazon S3 using and AWS Snowball Edge device
  4. D

    Migrate the data to Amazon FSx for Windows File Server using AWS DataSync
Xem giải thích

Đáp án

D — Di chuyển dữ liệu sang Amazon FSx for Windows File Server bằng AWS DataSync.

Vì sao đúng

Đề cho hai dữ kiện, mỗi cái quyết định một nửa câu trả lời: | Dữ kiện | Kết luận | |---|---| | Dữ liệu truy cập bằng giao thức SMB | đích phải hỗ trợ SMB → FSx for Windows | | Cần dịch vụ được quản lý + công cụ tự động hoá | FSx (quản lý) + DataSync (tự động) |

⚠ SMB là từ khoá loại trừ ngay ba phương án còn lại:

SMB (Server Message Block) = giao thức chia sẻ tệp của Windows
        ↓
    EFS nói NFS       → loại
    Lustre nói Lustre → loại
    S3 nói HTTP API   → loại
        ↓
    Chỉ FSx for Windows và FSx for NetApp ONTAP nói SMB

Dựng vị trí nguồn là NAS dùng SMB:

aws datasync create-location-smb \
  --server-hostname nas.congty.local \
  --subdirectory /du-lieu \
  --user quantri --domain CONGTY \
  --password '<mat-khau>' \
  --agent-arns <arn-agent>

Tạo task với các tuỳ chọn giữ nguyên quyền:

aws datasync create-task \
  --source-location-arn <arn-nguon> \
  --destination-location-arn <arn-fsx> \
  --name chuyen-nas-sang-fsx \
  --options 'VerifyMode=ONLY_FILES_TRANSFERRED,
             PreserveDeletedFiles=PRESERVE,
             SecurityDescriptorCopyFlags=OWNER_DACL_SACL,
             PosixPermissions=NONE,
             LogLevel=TRANSFER' \
  --cloud-watch-log-group-arn <arn-log-group>

⚠ Ba lý do DataSync hơn hẳn script robocopy tự viết: | Lý do | Chi tiết | |---|---| | Truyền song song nhiều luồng | nhanh hơn nhiều lần | | Xác minh toàn vẹn tự động | so checksum | | Chỉ chép phần THAY ĐỔI ở lần chạy sau | |

Quy trình chuyển đổi ít gián đoạn:

Lần 1: chép toàn bộ (chạy nhiều ngày cũng được)
Lần 2-n: chỉ chép phần đổi (nhanh dần)
        ↓
    Cửa sổ ngừng dịch vụ: chạy lần cuối
    → chuyển người dùng sang FSx
    → chỉ vài chục phút

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ứng dụng và người dùng giữ nguyên đường dẫn UNC | | | AWS lo vá, sao lưu, sẵn sàng cao | | | Giữ nguyên ACL NTFS | |

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

  • **A. Dùng DataSync sang FSx for Lustre — đây là phương án gần nhất về mặt dùng đúng công cụ di chuyển và đúng họ dịch vụ FSx, nhưng Lustre là hệ thống tệp hiệu năng cao cho HPC, dùng giao thức Lustre, không nói SMB.
  • **B. Dùng Server Migration Service sang EFS — SMS di chuyển máy ảo chứ không phải dữ liệu tệp (và đã ngừng, thay bằng MGN); EFS lại là NFS.
  • **C. Dùng Snowball Edge sang S3 — Snowball hợp khi mạng quá yếu, nhưng đề không nói vậy; và S3 không phải hệ thống tệp SMB.

Ghi nhớ

⚠ Giao thức quyết định dịch vụ — bảng phải thuộc: | Giao thức | Dịch vụ AWS | |---|---| | SMB | FSx for Windows, FSx for NetApp ONTAP | | NFS | EFS, FSx for OpenZFS, FSx for NetApp ONTAP | | Lustre | FSx for Lustre | | iSCSI | FSx for NetApp ONTAP, Storage Gateway | | HTTP API | S3 |

Từ khoá nhận diện:

"SMB, Windows, NAS, Active Directory" → FSx for Windows "NFS, Linux" → EFS "both SMB and NFS on same data" → FSx for NetApp ONTAP "automate migration over network" → DataSync "bandwidth too low, petabyte scale" → Snowball

⚠ Khi nào chọn Snowball thay vì DataSync:

Công thức thô: thời gian truyền (ngày)
             = dung lượng (TB) × 8 / (băng thông Mbps × 0,0864)
        ↓
    100 TB qua đường 100 Mbps ≈ 92 ngày
    → Snowball nhanh hơn hẳn
        ↓
    10 TB qua đường 1 Gbps ≈ 1 ngày
    → DataSync đơn giản hơn

Ba lưu ý về DataSync agent: | Lưu ý | Chi tiết | |---|---| | Cần agent khi nguồn ở tại chỗ | | | Máy ảo VMware/Hyper-V/KVM, hoặc EC2 | | | Khuyến nghị tối thiểu 4 vCPU, 32 GB RAM | |

⚠ Agent thiếu tài nguyên là nguyên nhân chậm phổ biến nhất:

Agent 2 vCPU, 8 GB RAM
    → thành nút thắt cổ chai
        ↓
    Đường mạng rảnh mà truyền vẫn chậm
    → tăng cỡ agent trước khi đổ lỗi cho mạng

Ba tuỳ chọn ảnh hưởng lớn: | Tuỳ chọn | Ý nghĩa | |---|---| | SecurityDescriptorCopyFlags | giữ ACL NTFS | | PreserveDeletedFiles | PRESERVE hay REMOVE | | VerifyMode | mức xác minh toàn vẹn |

Ba mức VerifyMode: | Mức | Chi tiết | |---|---| | ONLY_FILES_TRANSFERRED | nhanh, đủ dùng | | POINT_IN_TIME_CONSISTENT | kiểm cả tệp cũ, chậm hơn | | NONE | không kiểm — không khuyến nghị |

Ba lưu ý về giới hạn băng thông: | Lưu ý | Chi tiết | |---|---| | BytesPerSecond giới hạn tốc độ | | | Tránh làm nghẹt đường mạng văn phòng | | | Chạy đêm với hạn mức cao hơn | |

aws datasync update-task --task-arn <arn> \
  --options 'BytesPerSecond=52428800'

Ba lưu ý về FSx for Windows: | Lưu ý | Chi tiết | |---|---| | BẮT BUỘC nối Active Directory | | | Multi-AZ cho sản xuất | | | Throughput capacity chọn khi tạo, đổi được sau | |

Ba lưu ý về dung lượng cần cấp: | Lưu ý | Chi tiết | |---|---| | Tính theo GB cấp phát, không phải GB dùng | | | Bật deduplication giảm 50-60% với tệp người dùng | | | Tăng dung lượng được, không giảm được | |

⚠ Không giảm được dung lượng là chi tiết phải nhớ khi lập kế hoạch:

Cấp thừa 10 TB "cho chắc"
    → trả tiền 10 TB đó mãi mãi
        ↓
    Cấp vừa đủ, tăng dần khi cần

Ba lưu ý về kiểm tra sau khi chuyển: | Việc | Cách | |---|---| | So số tệp và tổng dung lượng | | | Kiểm ACL trên thư mục mẫu | | | Cho người dùng thật thử truy cập | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | DataSync ~0,0125 USD mỗi GB | | | FSx theo GB cấp phát mỗi tháng | | | Truyền qua Direct Connect rẻ hơn Internet | |

Ba lưu ý về đồng bộ liên tục: | Lưu ý | Chi tiết | |---|---| | DataSync đặt lịch được | | | Dùng cho giai đoạn chạy song song | | | Tắt sau khi chuyển đổi xong | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem báo cáo task | | | Mount FSx và mở tệp thử | | | Kiểm tra log CloudWatch có tệp nào bị bỏ qua | |

aws datasync describe-task-execution --task-execution-arn <arn> \
  --query "[Status,FilesTransferred,BytesTransferred]"

Và một lời khuyên: hãy cấp dung lượng FSx vừa đủ chứ đừng cấp thừa cho chắc. Dung lượng chỉ tăng được chứ không giảm, nên một quyết định "làm tròn lên" trong buổi lập kế hoạch sẽ theo bạn suốt vòng đời của hệ thống tệp đó.