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

Tìm thấy 2194 câu.

Câu 991 AWS Application Integration

An application running on Amazon EC2 needs to asynchronously invoke an AWS Lambda function to perform data processing. The services should be decoupled.

Which service can be used to decouple the compute services?

  1. A

    AWS Step Functions
  2. B

    Amazon SNS
  3. C

    Amazon MQ
  4. D

    AWS Config
Xem giải thích

Đáp án

B — Amazon SNS.

Vì sao đúng

Đề nêu ba yêu cầu, và SNS khớp cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng trên EC2 gọi Lambda | SNS gọi Lambda được | | **Gọi BẤT ĐỒNG BỘ | SNS đẩy, không chờ kết quả | | Hai dịch vụ phải TÁCH RỜI | SNS đứng giữa |

Vì sao SNS là câu trả lời cho "asynchronously invoke":

EC2 publish một thông điệp vào SNS topic
    → SNS ĐẨY thông điệp tới Lambda
    → EC2 không chờ Lambda chạy xong
        ↓
    Hai bên không biết gì về nhau
    → chỉ biết chung một topic

Cấu hình:

aws sns create-topic --name su-kien-xu-ly

aws sns subscribe --topic-arn <arn-topic> \
  --protocol lambda --notification-endpoint <arn-lambda>

aws lambda add-permission --function-name xu-ly-du-lieu \
  --statement-id sns-invoke --action lambda:InvokeFunction \
  --principal sns.amazonaws.com --source-arn <arn-topic>

⚠ Bước add-permission là bắt buộc:

Subscribe xong nhưng chưa cấp quyền cho SNS
    → SNS không gọi được Lambda
    → thông điệp bị bỏ

Ứng dụng trên EC2 publish:

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

sns.publish(
    TopicArn='arn:aws:sns:ap-southeast-1:123456789012:su-kien-xu-ly',
    Message=json.dumps({'ma_viec': 'abc123', 'loai': 'phan-tich'}),
    Subject='Viec moi')

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Fan-out — thêm subscriber không sửa mã EC2 | | | Lambda tự co giãn theo số thông điệp | | | Không có máy chủ trung gian nào | |

⚠ Và một điều quan trọng về độ tin cậy:

SNS gọi Lambda BẤT ĐỒNG BỘ
    → Lambda tự thử lại 2 lần khi lỗi
    → sau đó thông điệp MẤT nếu không có DLQ
        ↓
    Cấu hình dead-letter queue cho Lambda

aws lambda update-function-configuration \
  --function-name xu-ly-du-lieu \
  --dead-letter-config TargetArn=<arn-sqs-dlq>

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

  • **A. AWS Step Functions — đây là phương án gần nhất vì cũng điều phối được Lambda, nhưng nó là công cụ điều phối quy trình nhiều bước có trạng thái, không phải cơ chế tách rời đơn giản. Dùng nó ở đây là quá mức cho một lần gọi bất đồng bộ.
  • **C. Amazon MQ — message broker được quản lý cho ActiveMQ và RabbitMQ, dùng khi cần giữ nguyên giao thức nhắn tin cũ (JMS, AMQP, MQTT) khi di chuyển ứng dụng. Với ứng dụng mới trên AWS thì SNS/SQS đơn giản và rẻ hơn nhiều.
  • **D. AWS Config — dịch vụ đánh giá và ghi lại cấu hình tài nguyên để kiểm tra tuân thủ. Hoàn toàn không phải dịch vụ nhắn tin.

Ghi nhớ

⚠ Bốn dịch vụ nhắn tin của AWS — bảng phải thuộc: | Dịch vụ | Mô hình | Dùng khi | |---|---|---| | Amazon SNS | pub/sub, ĐẨY | fan-out, gọi bất đồng bộ | | Amazon SQS | hàng đợi, KÉO | đệm tải, giữ việc | | Amazon EventBridge | định tuyến sự kiện | lọc theo nội dung, nhiều nguồn | | Amazon MQ | broker truyền thống | di chuyển ứng dụng dùng JMS/AMQP |

Từ khoá nhận diện:

"asynchronously invoke Lambda", "decouple", "push" → SNS "buffer work, retain failed items" → SQS "existing app uses JMS/AMQP/MQTT" → Amazon MQ "route events by content from many sources" → EventBridge

⚠ SNS và SQS — bảng phân biệt cốt lõi: | | SNS | SQS | |---|---|---| | Mô hình | ĐẨY tới subscriber | KÉO bởi consumer | | Lưu trữ | không lưu | tới 14 ngày | | Số bên nhận | nhiều (fan-out) | một consumer mỗi thông điệp | | Đệm tải | ❌ | ✅ |

Sáu giao thức SNS hỗ trợ: | Giao thức | Dùng cho | |---|---| | Lambda | ← câu này | | SQS | fan-out có độ bền | | HTTP/HTTPS | webhook | | Email, SMS | thông báo người dùng | | Kinesis Data Firehose | nạp vào kho dữ liệu |

⚠ Mẫu SNS + SQS là mẫu quan trọng nhất:

SNS topic
  ├── SQS hệ thống A
  ├── SQS hệ thống B
  └── Lambda
        ↓
    Vừa fan-out (nhiều bên nhận)
    vừa bền (mỗi bên có hàng đợi riêng)
        ↓
    Bên nhận chết cũng không mất thông điệp

Ba lưu ý về độ tin cậy của SNS: | Lưu ý | Chi tiết | |---|---| | SNS thử lại theo chính sách retry | | | Cấu hình DLQ cho subscription | | | Lambda cũng có DLQ riêng | |

DLQ cho subscription SNS:

aws sns set-subscription-attributes --subscription-arn <arn-sub> \
  --attribute-name RedrivePolicy \
  --attribute-value '{"deadLetterTargetArn":"<arn-sqs-dlq>"}'

Ba tính năng của SNS đáng biết: | Tính năng | Việc | |---|---| | Message filtering | subscriber chỉ nhận thứ mình quan tâm | | FIFO topic | đảm bảo thứ tự (ghép với SQS FIFO) | | Message attributes | metadata để lọc |

Filter policy:

aws sns set-subscription-attributes --subscription-arn <arn-sub> \
  --attribute-name FilterPolicy \
  --attribute-value '{"loai":["phan-tich","bao-cao"]}'

Lọc ở SNS rẻ hơn lọc ở consumer
    → không gọi Lambda cho thông điệp không liên quan

Ba cách gọi Lambda: | Cách | Đặc điểm | |---|---| | Đồng bộ (RequestResponse) | chờ kết quả | | Bất đồng bộ (Event) | không chờ, tự thử lại 2 lần | | Event source mapping | Lambda tự kéo từ SQS, Kinesis |

Gọi Lambda trực tiếp bất đồng bộ:

lambda_client.invoke(
    FunctionName='xu-ly-du-lieu',
    InvocationType='Event',      # bất đồng bộ
    Payload=json.dumps(du_lieu))

Cách này CŨNG bất đồng bộ
    → nhưng KHÔNG tách rời: EC2 phải biết tên hàm Lambda
        ↓
    SNS làm hai bên hoàn toàn độc lập

Ba lưu ý về Amazon MQ (để biết vì sao C sai): | Lưu ý | Chi tiết | |---|---| | Dành cho ứng dụng dùng giao thức chuẩn ngành | | | Phải quản lý broker (cỡ, phiên bản) | | | Đắt hơn SNS/SQS | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | SNS tính theo số lần publish và delivery | | | 1 triệu request đầu miễn phí mỗi tháng | | | Rẻ hơn Amazon MQ nhiều | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Publish thử và xem log Lambda | | | Kiểm tra quyền lambda:InvokeFunction | | | Đặt alarm trên NumberOfNotificationsFailed | |

Và một lời khuyên: hãy cấu hình dead-letter queue cho subscription ngay khi tạo. SNS gọi Lambda bất đồng bộ và sẽ bỏ thông điệp sau khi thử lại thất bại — không có lỗi trả về cho bên gửi, nên nếu không có DLQ thì công việc biến mất mà không ai biết.

Câu 992 AWS Database

A company is deploying an Amazon ElastiCache for Redis cluster. To enhance security a password should be required to access the database. What should the solutions architect use?

  1. A

    VPC Security Group
  2. B

    AWS Directory Service
  3. C

    Redis AUTH command
  4. D

    AWS IAM Policy
Xem giải thích

Đáp án

C — Dùng lệnh Redis AUTH.

Vì sao đúng

Đề nêu một yêu cầu rất hẹp, và Redis AUTH là cơ chế đúng: | Yêu cầu | Cách đáp ứng | |---|---| | Cụm ElastiCache for Redis | | | Cần MẬT KHẨU để truy cập | Redis AUTH — cơ chế mật khẩu của chính Redis |

Redis AUTH hoạt động thế nào:

Đặt một auth token khi tạo cụm
    → client phải gửi lệnh AUTH <token> trước khi làm gì
        ↓
    Không có token → mọi lệnh bị từ chối

Bật khi tạo cụm:

aws elasticache create-replication-group \
  --replication-group-id cum-redis \
  --replication-group-description "Cum Redis co mat khau" \
  --engine redis --cache-node-type cache.r7g.large \
  --num-cache-clusters 2 --automatic-failover-enabled \
  --transit-encryption-enabled \
  --auth-token 'MatKhauRatDaiVaKho123!' \
  --cache-subnet-group-name nhom-subnet-rieng-tu

⚠ Ba ràng buộc bắt buộc của Redis AUTH: | Ràng buộc | Chi tiết | |---|---| | PHẢI bật --transit-encryption-enabled | | | Token dài 16-128 ký tự | | | Không chứa @, ", hoặc khoảng trắng | |

Vế đầu là ràng buộc quan trọng nhất:

Không có mã hoá đường truyền
    → token đi TRẦN trên mạng
    → ai bắt được gói tin là có mật khẩu
        ↓
    AWS bắt buộc bật TLS khi dùng AUTH

Client kết nối:

import redis
r = redis.Redis(
    host='cum-redis.abc.cache.amazonaws.com', port=6379,
    password='MatKhauRatDaiVaKho123!',
    ssl=True, ssl_cert_reqs='required')

Xoay token không gián đoạn:

aws elasticache modify-replication-group \
  --replication-group-id cum-redis \
  --auth-token 'MatKhauMoi456!' \
  --auth-token-update-strategy ROTATE --apply-immediately

⚠ Chiến lược ROTATE cho phép hai token cùng hợp lệ tạm thời:

ROTATE: token cũ VÀ mới đều dùng được
    → cập nhật client dần dần
    → rồi chạy lại với SET để bỏ token cũ
        ↓
    Không có thời gian ngừng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lớp bảo vệ ngoài mạng | không chỉ dựa vào security group | | Xoay được không gián đoạn | | | Lưu token trong Secrets Manager | |

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

  • **A. VPC Security Group — đây là phương án gần nhất và là lớp bảo vệ bắt buộc phải có, nhưng nó kiểm soát AI KẾT NỐI ĐƯỢC theo IP và security group, không phải mật khẩu. Đề hỏi cụ thể về việc yêu cầu mật khẩu.
  • **B. AWS Directory Service — dịch vụ thư mục (Active Directory), dùng cho xác thực người dùng vào Windows, WorkSpaces, FSx. ElastiCache không tích hợp với nó.
  • **D. AWS IAM Policy — IAM kiểm soát thao tác quản trị trên cụm (tạo, xoá, sửa cấu hình), không kiểm soát truy cập dữ liệu bên trong Redis theo cách này.

Ghi nhớ về lựa chọn hiện đại

Redis AUTH đúng cho câu hỏi này, nhưng đáng biết rằng ElastiCache đã có xác thực IAM từ 2023:

aws elasticache create-user --user-id ung-dung-a \
  --user-name ung-dung-a --engine redis \
  --authentication-mode Type=iam \
  --access-string "on ~app:* +@read +@write"

Kết nối bằng token IAM thay vì mật khẩu tĩnh
    → không có mật khẩu nào để rò rỉ
    → không phải xoay token
        ↓
    Với thiết kế mới, đây là lựa chọn tốt hơn

Ba cách xác thực ElastiCache for Redis: | Cách | Đặc điểm | |---|---| | Redis AUTH (token) | đơn giản, mật khẩu tĩnh ← câu này | | RBAC (user và user group) | phân quyền theo lệnh và khoá | | IAM authentication | không mật khẩu, token 15 phút |

RBAC cho phân quyền chi tiết:

aws elasticache create-user --user-id chi-doc \
  --user-name chi-doc --engine redis \
  --passwords 'MatKhauChiDoc123!' \
  --access-string "on ~cache:* +@read"

aws elasticache create-user-group --user-group-id nhom-ung-dung \
  --engine redis --user-ids default chi-doc

Access string kiểu Redis ACL:
    ~cache:*  → chỉ khoá bắt đầu bằng "cache:"
    +@read    → chỉ lệnh đọc
        ↓
    Đặc quyền tối thiểu ở tầng dữ liệu

Ghi nhớ

⚠ Ba lớp bảo vệ ElastiCache — nên có ĐỦ CẢ BA: | Lớp | Việc | |---|---| | Security group + subnet riêng tư | ai kết nối được | | Redis AUTH / RBAC / IAM | xác thực và phân quyền | | Mã hoá at rest và in transit | bảo vệ dữ liệu |

Từ khoá nhận diện:

"require a password for Redis" → Redis AUTH "fine-grained command/key permissions" → RBAC "no static credentials" → IAM authentication "restrict network access" → security group

⚠ Redis và Memcached — bảng phải thuộc: | | Redis | Memcached | |---|---|---| | Xác thực | AUTH, RBAC, IAM | SASL (hạn chế) | | Mã hoá | ✅ at rest và in transit | in transit (bản mới) | | Nhân bản, Multi-AZ | ✅ | ❌ | | Cấu trúc dữ liệu | phong phú | chỉ chuỗi | | Snapshot | ✅ | ❌ |

⚠ Ba ràng buộc phải nhớ về mã hoá ElastiCache: | Ràng buộc | Chi tiết | |---|---| | Mã hoá phải bật KHI TẠO cụm | không bật sau được | | AUTH yêu cầu in-transit encryption | | | Đổi thì phải tạo cụm mới | |

Ba lưu ý về quản lý token: | Lưu ý | Chi tiết | |---|---| | Lưu trong Secrets Manager | không hardcode | | Xoay định kỳ bằng ROTATE | | | Không ghi token ra log | |

Lưu vào Secrets Manager:

aws secretsmanager create-secret --name redis/auth-token \
  --secret-string '{"token":"MatKhauRatDaiVaKho123!"}' \
  --kms-key-id alias/khoa-bi-mat

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Đặt cụm trong subnet RIÊNG TƯ | | | Security group chỉ cho ứng dụng vào cổng 6379 | | | Không bao giờ mở ra Internet | |

aws ec2 authorize-security-group-ingress --group-id sg-redis \
  --protocol tcp --port 6379 --source-group sg-ung-dung

Hai chế độ cluster của Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, tới 5 replica | | Cluster mode enabled | nhiều shard, dữ liệu phân mảnh |

Ba chính sách khi hết bộ nhớ: | Chính sách | Hành vi | |---|---| | allkeys-lru | đẩy khoá ít dùng nhất — cho cache | | volatile-lru | chỉ đẩy khoá có TTL | | noeviction | từ chối ghi mới |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả cache | | Evictions | bộ nhớ đầy | | AuthenticationFailures | có ai thử sai token không |

Metric thứ ba đáng đặt alarm — nó là dấu hiệu bị dò mật khẩu.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối không có token | phải bị từ chối | | Kết nối có token và TLS | phải thành công | | Kiểm tra dữ liệu mã hoá at rest | |

Và một lời khuyên: hãy cân nhắc IAM authentication thay vì AUTH token cho hệ thống mới. Mật khẩu tĩnh nào cũng phải lưu ở đâu đó, phải xoay định kỳ, và có thể lọt vào log hay biến môi trường — còn token IAM sống 15 phút và không có gì để rò rỉ.

Câu 993 AWS Storage

A solutions architect needs to backup some application log files from an online ecommerce store to Amazon S3. It is unknown how often the logs will be accessed or which logs will be accessed the most. The solutions architect must keep costs as low as possible by using the appropriate S3 storage class.

Which S3 storage class should be implemented to meet these requirements?

  1. A

    S3 Intelligent-Tiering
  2. B

    S3 Standard-Infrequent Access (S3 Standard-IA)
  3. C

    S3 Glacier
  4. D

    S3 One Zone-Infrequent Access (S3 One Zone-IA)
Xem giải thích

Đáp án

A — S3 Intelligent-Tiering.

Vì sao đúng

Đề nêu hai dữ kiện, và Intelligent-Tiering sinh ra đúng cho tình huống này: | Dữ kiện | Cách đáp ứng | |---|---| | KHÔNG BIẾT log sẽ được truy cập bao nhiêu lần | không dự đoán được → để AWS tự quyết | | KHÔNG BIẾT log nào được đọc nhiều nhất | tự theo dõi TỪNG object | | Giữ chi phí thấp nhất | tự chuyển tầng theo thực tế |

⚠ "Unknown access pattern" là từ khoá duy nhất cần thấy:

Mọi lớp lưu trữ khác đòi bạn PHẢI BIẾT trước:
    → Standard-IA: biết là ít truy cập
    → Glacier: biết là gần như không truy cập
        ↓
    Intelligent-Tiering: KHÔNG cần biết gì
    → nó theo dõi từng object và tự chuyển

Cách hoạt động:

Object mới → tầng Frequent Access
    → 30 ngày không ai đọc → chuyển sang Infrequent Access
    → 90 ngày không ai đọc → chuyển sang Archive Instant Access
        ↓
    Có người đọc → TỰ QUAY LẠI tầng Frequent
    → và KHÔNG tính phí lấy dữ liệu

Cấu hình bằng lifecycle:

{"Rules": [{
  "ID": "tu-dong-phan-tang", "Status": "Enabled", "Filter": {},
  "Transitions": [{"Days": 0, "StorageClass": "INTELLIGENT_TIERING"}]}]}

Hoặc tải lên thẳng vào lớp đó:

aws s3 cp log.gz s3://kho-log/ --storage-class INTELLIGENT_TIERING

⚠ Ba đặc điểm quyết định: | Đặc điểm | Chi tiết | |---|---| | KHÔNG có phí lấy dữ liệu | khác hẳn Standard-IA | | KHÔNG có thời gian lưu tối thiểu | | | Có phí GIÁM SÁT nhỏ mỗi object | |

Vế đầu là lý do nó an toàn khi không biết mẫu truy cập:

Standard-IA: đoán sai (thực ra đọc nhiều)
    → phí lấy dữ liệu vượt khoản tiết kiệm
        ↓
Intelligent-Tiering: đoán sai không bị phạt
    → object tự quay về tầng nóng, không mất phí đọc

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần phân tích trước | | | Tự điều chỉnh khi mẫu truy cập đổi | | | Không rủi ro chọn sai lớp | |

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

  • **B. S3 Standard-IA — đây là phương án gần nhất và rẻ hơn về lưu trữ, nhưng nó có phí lấy dữ liệu mỗi GB. Với log mà bạn không biết sẽ đọc bao nhiêu, đây là rủi ro thật: nếu đọc nhiều hơn dự kiến thì tổng chi phí cao hơn cả Standard.
  • **D. S3 One Zone-IA — cùng vấn đề phí lấy dữ liệu, cộng thêm việc chỉ lưu trong một AZ. Log ứng dụng thường không tạo lại được, nên mất AZ là mất vĩnh viễn.
  • **C. S3 Glacier — cần khôi phục mất vài phút tới vài giờ, không phù hợp cho log có thể cần đọc bất cứ lúc nào để gỡ lỗi.

Ghi nhớ

⚠ Bảng lớp lưu trữ S3 — phải thuộc: | Lớp | Truy cập | Phí lấy dữ liệu | Lưu tối thiểu | |---|---|---|---| | Standard | tức thì | không | — | | Intelligent-Tiering | tức thì | KHÔNG | — | | Standard-IA | tức thì | có | 30 ngày | | One Zone-IA | tức thì | có | 30 ngày | | Glacier Instant Retrieval | tức thì | có (cao) | 90 ngày | | Glacier Flexible Retrieval | phút - giờ | có | 90 ngày | | Deep Archive | 12-48 giờ | có | 180 ngày |

Từ khoá nhận diện:

"unknown or changing access pattern" → Intelligent-Tiering "known: infrequent but immediate" → Standard-IA "archive, retrieval time acceptable" → Glacier "can be recreated, not critical" → One Zone-IA

⚠ Năm tầng của Intelligent-Tiering: | Tầng | Chuyển sau | Truy cập | |---|---|---| | Frequent Access | mặc định | tức thì | | Infrequent Access | 30 ngày | tức thì | | Archive Instant Access | 90 ngày | tức thì | | Archive Access (tuỳ chọn) | 90+ ngày | phút - giờ | | Deep Archive Access (tuỳ chọn) | 180+ ngày | giờ |

Ba tầng đầu là tự động; hai tầng cuối phải bật thủ công:

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket kho-log --id cau-hinh-luu-tru \
  --intelligent-tiering-configuration '{
    "Id":"cau-hinh-luu-tru","Status":"Enabled",
    "Tierings":[
      {"Days":90,"AccessTier":"ARCHIVE_ACCESS"},
      {"Days":180,"AccessTier":"DEEP_ARCHIVE_ACCESS"}]}'

⚠ Bật hai tầng cuối làm mất tính "truy cập tức thì" — cân nhắc kỹ với log.

Ba lưu ý về phí giám sát: | Lưu ý | Chi tiết | |---|---| | Tính theo SỐ object mỗi tháng | | | Object dưới 128 KB KHÔNG tính phí giám sát | | | Và cũng không được tự chuyển tầng | |

⚠ Vế thứ hai và ba là chi tiết quan trọng:

Object nhỏ hơn 128 KB
    → luôn ở tầng Frequent Access
    → không tính phí giám sát
        ↓
    Với hàng triệu log nhỏ, Intelligent-Tiering
    không giúp gì — phải GỘP LẠI trước

Ba lỗi thiết kế khi ghi log lên S3: | Lỗi | Hậu quả | |---|---| | Mỗi dòng log một object | phí request rất lớn | | Không nén | tốn gấp 5-10 lần | | Không phân vùng theo ngày | truy vấn quét toàn bộ |

Cách ghi log đúng:

aws s3 cp log-gop.json.gz \
  s3://kho-log/nam=2026/thang=08/ngay=30/may=web01/lo-001.json.gz

Gộp theo lô, nén, phân vùng theo ngày
    → ít object, rẻ hơn, truy vấn Athena nhanh hơn

⚠ Ba giới hạn lifecycle phải nhớ: | Giới hạn | Con số | |---|---| | Standard → Standard-IA / One Zone-IA | tối thiểu 30 ngày | | Object < 128 KB | không chuyển sang IA | | Đã ở IA → Glacier | không còn ràng buộc 30 ngày |

Ba công cụ phân tích: | Công cụ | Việc | |---|---| | S3 Storage Lens | phân bố kích thước và tuổi object | | S3 Storage Class Analysis | gợi ý thời điểm chuyển tầng | | Cost Explorer | chi phí theo lớp |

Storage Lens là bước đầu nên làm:

Nó cho biết ngay:
    → bao nhiêu % object nhỏ hơn 128 KB
    → bao nhiêu dữ liệu chưa từng được đọc lại
    → bao nhiêu phần tải lên dở chưa dọn

Ba quy tắc lifecycle nên có ở mọi bucket: | Quy tắc | Việc | |---|---| | Transitions theo tuổi | giảm chi phí | | AbortIncompleteMultipartUpload | dọn phần tải lên dở | | NoncurrentVersionExpiration | nếu bật versioning |

Ba lưu ý về phân tích log: | Lưu ý | Chi tiết | |---|---| | Athena truy vấn trực tiếp trên S3 | | | Định dạng Parquet rẻ hơn nhiều | | | Lọc theo cột phân vùng | |

Và một lời khuyên: hãy kiểm tra phân bố kích thước object bằng S3 Storage Lens trước khi chọn lớp lưu trữ. Với log ứng dụng, phần lớn tệp thường nhỏ hơn ngưỡng 128 KB — và trong trường hợp đó, cả Intelligent-Tiering lẫn Standard-IA đều không mang lại lợi ích nào cho tới khi bạn gộp chúng lại.

Câu 994 AWS Application Integration

A Solutions Architect is designing an application that will run on an Amazon EC2 instance. The application must asynchronously invoke an AWS Lambda function to analyze thousands of .CSV files. The services should be decoupled.

Which service can be used to decouple the compute services?

  1. A

    Amazon SNS
  2. B

    Amazon SWF
  3. C

    Amazon OpsWorks
  4. D

    Amazon Kinesis
Xem giải thích

Đáp án

A — Amazon SNS.

Vì sao đúng

Đề nêu ba yêu cầu, và SNS là dịch vụ duy nhất trong bốn lựa chọn khớp cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | EC2 gọi Lambda phân tích hàng nghìn tệp CSV | SNS gọi Lambda được | | **Gọi BẤT ĐỒNG BỘ | SNS đẩy, bên gửi không chờ | | Hai dịch vụ phải TÁCH RỜI | SNS đứng giữa |

Vì sao SNS tách rời được hai bên:

EC2 chỉ biết ARN của TOPIC
    → không biết Lambda nào đang lắng nghe
    → không biết có bao nhiêu subscriber
        ↓
    Thêm bớt bên xử lý không cần sửa mã EC2

Với hàng nghìn tệp CSV, mô hình fan-out phát huy tác dụng:

SNS topic
  ├── Lambda phân tích nội dung
  ├── SQS cho hệ thống báo cáo
  └── Lambda ghi log kiểm toán
        ↓
    Một lần publish, nhiều bên cùng nhận

Cấu hình:

aws sns create-topic --name tep-csv-moi

aws sns subscribe --topic-arn <arn-topic> \
  --protocol lambda --notification-endpoint <arn-lambda>

aws lambda add-permission --function-name phan-tich-csv \
  --statement-id sns-invoke --action lambda:InvokeFunction \
  --principal sns.amazonaws.com --source-arn <arn-topic>

⚠ Với hàng nghìn tệp, phải chú ý giới hạn đồng thời của Lambda:

Publish 5.000 thông điệp trong một phút
    → SNS gọi Lambda 5.000 lần gần như đồng thời
    → chạm giới hạn concurrency (mặc định 1.000/vùng)
        ↓
    Phần vượt bị throttle → SNS thử lại → có thể mất

Ba cách xử lý: | Cách | Chi tiết | |---|---| | Đặt reserved concurrency cho hàm | bảo vệ hàm khác | | Chèn SQS giữa SNS và Lambda | đệm và điều tiết | | Xin tăng hạn ngạch concurrency | |

Mẫu SNS → SQS → Lambda:

aws sns subscribe --topic-arn <arn-topic> \
  --protocol sqs --notification-endpoint <arn-sqs>

aws lambda create-event-source-mapping \
  --function-name phan-tich-csv --event-source-arn <arn-sqs> \
  --batch-size 10 --maximum-batching-window-in-seconds 5

SQS đệm đợt tăng
    → Lambda kéo theo nhịp của nó
    → thông điệp lỗi vào DLQ thay vì mất
        ↓
    Đây là mô hình bền nhất cho khối lượng lớn

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

  • **D. Amazon Kinesis — đây là phương án gần nhất vì cũng tách rời được và cũng gọi Lambda được, nhưng nó là dịch vụ cho luồng dữ liệu liên tục có thứ tự và đọc lại được. Với việc đơn giản là báo cho Lambda biết có tệp cần xử lý, Kinesis là quá mức và cần quản lý shard.
  • **B. Amazon SWF (Simple Workflow Service) — dịch vụ điều phối quy trình đời cũ, AWS khuyến nghị dùng Step Functions thay thế. Nó cũng đòi tự chạy worker và decider — công vận hành cao.
  • **C. AWS OpsWorks — dịch vụ quản lý cấu hình dựa trên Chef và Puppet. Hoàn toàn không phải dịch vụ nhắn tin, và AWS đã ngừng nhận khách hàng mới.

Ghi nhớ

⚠ Bốn dịch vụ tách rời — bảng phải thuộc: | Dịch vụ | Mô hình | Đặc điểm | |---|---|---| | Amazon SNS | pub/sub, ĐẨY | fan-out, gọi bất đồng bộ | | Amazon SQS | hàng đợi, KÉO | đệm tải, giữ việc | | Amazon Kinesis Data Streams | luồng | thứ tự, đọc lại được | | Amazon EventBridge | định tuyến sự kiện | lọc theo nội dung |

Từ khoá nhận diện:

"asynchronously invoke", "decouple", "push" → SNS "buffer, retain failed items" → SQS "ordered, replay, multiple consumers" → Kinesis "orchestrate multi-step workflow" → Step Functions

⚠ Ba dịch vụ AWS đã lỗi thời — biết để loại: | Dịch vụ | Thay bằng | |---|---| | Amazon SWF | AWS Step Functions | | AWS OpsWorks | Systems Manager, CloudFormation | | AWS CodeCommit (khách mới) | GitHub, GitLab |

⚠ SNS và SQS — bảng phân biệt cốt lõi: | | SNS | SQS | |---|---|---| | Mô hình | ĐẨY | KÉO | | Lưu trữ | không | tới 14 ngày | | Số bên nhận | nhiều | một consumer mỗi thông điệp | | Đệm tải | ❌ | ✅ |

⚠ Với việc xử lý tệp trong S3, có cách trực tiếp hơn:

S3 Event Notification → Lambda (hoặc SQS)
    → không cần EC2 publish thông điệp
        ↓
    Tệp CSV vào S3 là tự động kích hoạt xử lý

aws s3api put-bucket-notification-configuration --bucket kho-csv \
  --notification-configuration '{"QueueConfigurations":[{
    "QueueArn":"arn:aws:sqs:ap-southeast-1:123456789012:hang-doi-csv",
    "Events":["s3:ObjectCreated:*"],
    "Filter":{"Key":{"FilterRules":[{"Name":"suffix","Value":".csv"}]}}}]}'

Ba lưu ý về giới hạn Lambda: | Giới hạn | Con số | |---|---| | Thời gian chạy tối đa | 15 phút | | Concurrency mặc định mỗi vùng | 1.000 | | Bộ nhớ | 128 MB - 10.240 MB |

⚠ Với tệp CSV lớn, giới hạn 15 phút là ràng buộc thật:

Một tệp CSV vài GB xử lý quá 15 phút
    → Lambda không dùng được
        ↓
    Chuyển sang AWS Batch, Fargate, hoặc Glue
    → hoặc chia tệp thành đoạn nhỏ

Ba cách kiểm soát đồng thời: | Cách | Chi tiết | |---|---| | Reserved concurrency | giới hạn tối đa cho một hàm | | Provisioned concurrency | giữ sẵn instance, giảm khởi động lạnh | | SQS ở giữa | điều tiết tự nhiên |

aws lambda put-function-concurrency --function-name phan-tich-csv \
  --reserved-concurrent-executions 100

Ba lưu ý về độ tin cậy: | Lưu ý | Chi tiết | |---|---| | Gọi bất đồng bộ tự thử lại 2 lần | | | Sau đó MẤT nếu không có DLQ | | | Cấu hình DLQ hoặc destination | |

aws lambda update-function-event-invoke-config \
  --function-name phan-tich-csv \
  --destination-config '{"OnFailure":{"Destination":"<arn-sqs-dlq>"}}'

Ba tính năng của SNS: | Tính năng | Việc | |---|---| | Message filtering | subscriber chỉ nhận thứ liên quan | | FIFO topic | đảm bảo thứ tự | | DLQ cho subscription | |

Ba lưu ý về idempotent: | Lưu ý | Chi tiết | |---|---| | SNS có thể giao TRÙNG | | | Lambda phải xử lý lại được | | | Dùng tên tệp làm khoá chống trùng | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | SNS rẻ, 1 triệu request đầu miễn phí | | | Lambda tính theo GB-giây | | | Tăng bộ nhớ có thể GIẢM tổng chi phí | chạy nhanh hơn |

Và một lời khuyên: hãy chèn SQS giữa SNS và Lambda khi khối lượng lớn. Với hàng nghìn tệp đổ vào cùng lúc, SNS sẽ gọi Lambda nhanh hơn mức concurrency cho phép — và những lần gọi bị throttle sẽ biến mất sau vài lần thử lại mà không để lại dấu vết nào.

Câu 995 AWS Migration & Transfer

A large MongoDB database running on-premises must be migrated to Amazon DynamoDB within the next few weeks. The database is too large to migrate over the company’s limited internet bandwidth so an alternative solution must be used. What should a Solutions Architect recommend?

  1. A

    Use the AWS Database Migration Service (DMS) to extract and load the data to an AWS Snowball Edge device. Complete the migration to Amazon DynamoDB using AWS DMS in the AWS Cloud
  2. B

    Setup an AWS Direct Connect and migrate the database to Amazon DynamoDB using the AWS Database Migration Service (DMS)
  3. C

    Enable compression on the MongoDB database and use the AWS Database Migration Service (DMS) to directly migrate the database to Amazon DynamoDB
  4. D

    Use the Schema Conversion Tool (SCT) to extract and load the data to an AWS Snowball Edge device. Use the AWS Database Migration Service (DMS) to migrate the data to Amazon DynamoDB
Xem giải thích

Đáp án

D — Dùng Schema Conversion Tool (SCT) trích xuất và nạp dữ liệu lên Snowball Edge, rồi dùng AWS DMS chuyển dữ liệu vào DynamoDB.

Vì sao đúng

Đề nêu ba ràng buộc, và quy trình này giải quyết từng cái: | Ràng buộc | Cách đáp ứng | |---|---| | CSDL MongoDB rất lớn | Snowball Edge — chuyển vật lý | | Băng thông Internet hạn chế | không truyền qua mạng | | Đích là DynamoDB (đổi loại CSDL) | SCT + DMS |

⚠ Quy trình DMS + Snowball Edge có ba giai đoạn:

1. SCT chạy tại chỗ, TRÍCH XUẤT dữ liệu MongoDB
   → ghi vào thiết bị Snowball Edge (định dạng CSV/Parquet)

2. Gửi thiết bị về AWS
   → AWS nạp dữ liệu vào một S3 bucket trung gian

3. DMS đọc từ S3 và ghi vào DynamoDB
        ↓
    Đây là quy trình chính thức của AWS cho
    "database migration with Snowball Edge"

Vì sao cần SCT chứ không chỉ DMS:

MongoDB (document, không schema cố định)
    → DynamoDB (key-value, mô hình khác hẳn)
        ↓
    Đổi LOẠI CSDL → cần chuyển đổi mô hình dữ liệu
    → đó là việc của Schema Conversion Tool

Và SCT có chức năng data extraction agent:

SCT không chỉ chuyển schema
    → nó còn có AGENT trích xuất dữ liệu
    → agent ghi thẳng vào Snowball Edge
        ↓
    Đây là điểm phân biệt SCT với DMS trong phương án A

Cấu hình job Snowball cho DMS:

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

Rồi DMS task đọc từ S3:

aws dms create-endpoint --endpoint-identifier nguon-s3 \
  --endpoint-type source --engine-name s3 \
  --s3-settings '{"BucketName":"kho-trung-gian",
    "ServiceAccessRoleArn":"<arn-role>",
    "ExternalTableDefinition":"file://dinh-nghia-bang.json"}'

aws dms create-replication-task \
  --replication-task-identifier nap-vao-dynamodb \
  --source-endpoint-arn <arn-s3> --target-endpoint-arn <arn-dynamodb> \
  --migration-type full-load --table-mappings file://anh-xa.json

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không dùng băng thông Internet | | | Xử lý được chuyển đổi mô hình dữ liệu | | | Mã hoá AES-256 trên thiết bị | |

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

  • **A. Dùng DMS trích xuất và nạp lên Snowball Edge, rồi dùng DMS hoàn tất — đây là phương án gần nhất và mô tả gần đúng quy trình, nhưng phần trích xuất ra thiết bị là việc của SCT data extraction agent, không phải DMS. DMS chỉ vào cuộc ở giai đoạn nạp từ S3 vào đích.
  • **B. Dựng Direct Connect rồi dùng DMS chuyển qua mạng — DX mất hàng tuần tới hàng tháng để cung cấp, trong khi đề nói phải xong trong vài tuần. Và chi phí dựng DX cho một lần di chuyển là không hợp lý.
  • **C. Bật nén trên MongoDB rồi dùng DMS chuyển thẳng — nén giúp giảm dung lượng nhưng không thay đổi thực tế băng thông hạn chế; với CSDL "quá lớn" thì vẫn không kịp.

Ghi nhớ

⚠ SCT và DMS — bảng phải thuộc: | | Schema Conversion Tool (SCT) | Database Migration Service (DMS) | |---|---|---| | Việc | chuyển đổi SCHEMA và mã | chuyển DỮ LIỆU | | Cần khi | ĐỔI loại CSDL | mọi lần di chuyển | | Cùng engine | không cần | vẫn cần | | Data extraction agent | ✅ ghi ra Snowball | ❌ |

Oracle → Oracle:       chỉ cần DMS
Oracle → PostgreSQL:   cần SCT + DMS
MongoDB → DynamoDB:    cần SCT + DMS

Từ khoá nhận diện:

"database too large for bandwidth" → SCT + Snowball Edge + DMS "change database engine" → SCT + DMS "same engine, minimal downtime" → DMS với CDC "varying workload, low overhead" → DMS Serverless

Ba loại migration type của DMS: | Loại | Việc | |---|---| | full-load | chép toàn bộ một lần | | cdc | chỉ sao chép thay đổi | | full-load-and-cdc | thời gian ngừng tối thiểu |

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

⚠ Quy tắc ước lượng nhanh:

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

    → mất hơn MỘT TUẦN  → cân nhắc Snowball
    → mất hơn MỘT THÁNG → chắc chắn Snowball

Ba lưu ý về thời gian Snowball: | Mốc | Thời gian điển hình | |---|---| | Vận chuyển tới nơi | 2-5 ngày | | Trích xuất và ghi dữ liệu | tuỳ dung lượng | | Vận chuyển về + nạp vào S3 | 3-7 ngày |

⚠ Ba lưu ý khi chuyển MongoDB sang DynamoDB: | Lưu ý | Chi tiết | |---|---| | Mô hình dữ liệu khác hẳn | phải thiết kế lại khoá | | DynamoDB giới hạn 400 KB mỗi item | document lớn phải tách | | Không có JOIN, không có truy vấn linh hoạt | |

Vế đầu là công việc lớn nhất:

MongoDB: truy vấn linh hoạt trên bất kỳ trường nào
DynamoDB: phải thiết kế partition key và sort key
          theo ĐÚNG mẫu truy cập
        ↓
    Đây là thiết kế lại, không phải chuyển đổi máy móc

Ba lưu ý về thiết kế khoá DynamoDB: | Lưu ý | Chi tiết | |---|---| | Partition key phân bố đều | tránh hot partition | | GSI cho mẫu truy cập khác | | | Single-table design nếu nhiều thực thể | |

Ba lựa chọn thay thế nếu không muốn đổi mô hình: | Lựa chọn | Đặc điểm | |---|---| | Amazon DocumentDB | tương thích MongoDB API | | MongoDB Atlas trên AWS | dịch vụ của bên thứ ba | | MongoDB tự quản trên EC2 | công vận hành cao |

⚠ DocumentDB đáng cân nhắc:

Tương thích với MongoDB API
    → gần như không phải đổi mã ứng dụng
    → không cần SCT
        ↓
    Nhưng đề nói rõ đích là DynamoDB

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 lưu ý về dữ liệu thay đổi trong lúc chờ: | Lưu ý | Chi tiết | |---|---| | Dữ liệu mới chưa nằm trên thiết bị | | | Dùng DMS CDC đồng bộ phần chênh lệch | | | Phần chênh nhỏ nên mạng kém vẫn kham được | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So số bản ghi nguồn và đích | | | Bật validation của DMS | | | Thử truy vấn mẫu trên DynamoDB | |

Và một lời khuyên: hãy thiết kế mô hình dữ liệu DynamoDB trước khi đặt Snowball. Việc chuyển từ document sang key-value không phải một bước kỹ thuật mà là một quyết định kiến trúc — và nếu bạn phát hiện ra mẫu truy cập cần một khoá khác sau khi dữ liệu đã nạp xong, việc sửa sẽ tốn hơn cả lần di chuyển đầu tiên.

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

A company has uploaded some highly critical data to an Amazon S3 bucket. Management are concerned about data availability and require that steps are taken to protect the data from accidental deletion. The data should still be accessible, and a user should be able to delete the data intentionally.

Which combination of steps should a solutions architect take to accomplish this? (Select TWO.)

  1. A

    Create a lifecycle policy for the objects in the S3 bucket.
  2. B

    Enable MFA Delete on the S3 bucket.
  3. C

    Enable default encryption on the S3 bucket.
  4. D

    Create a bucket policy on the S3 bucket.
  5. E

    Enable versioning on the S3 bucket.
Xem giải thích

Đáp án

B và E.

  • B — Bật MFA Delete trên bucket
  • E — Bật versioning trên bucket

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Bảo vệ dữ liệu quan trọng khỏi XOÁ NHẦM | versioning giữ lại, MFA Delete chặn xoá vĩnh viễn | | Dữ liệu vẫn TRUY CẬP ĐƯỢC | cả hai không cản việc đọc | | Người dùng vẫn xoá được KHI CỐ Ý | có MFA thì xoá được |

⚠ Vế thứ ba là điểm phân biệt với Object Lock:

Object Lock compliance: KHÔNG AI xoá được, kể cả cố ý
    → quá chặt cho yêu cầu này

MFA Delete: xoá được, nhưng phải có mã MFA
    → "intentional" nghĩa là chủ động, có chủ đích
        ↓
    Đúng mức bảo vệ mà đề mô tả

Versioning làm gì:

Ghi đè → tạo phiên bản mới, bản cũ VẪN CÒN
Xoá    → tạo DELETE MARKER, dữ liệu vẫn còn phía dưới
        ↓
    Xoá nhầm luôn khôi phục được

Bật versioning:

aws s3api put-bucket-versioning --bucket kho-du-lieu-quan-trong \
  --versioning-configuration Status=Enabled

Bật MFA Delete:

aws s3api put-bucket-versioning --bucket kho-du-lieu-quan-trong \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

⚠ Ba ràng buộc của MFA Delete: | Ràng buộc | Chi tiết | |---|---| | CHỈ tài khoản ROOT bật được | không phải IAM user | | CHỈ qua CLI hoặc API | console không làm được | | Bucket phải bật versioning | |

Khôi phục object bị xoá nhầm:

aws s3api list-object-versions --bucket kho-du-lieu-quan-trong \
  --prefix bao-cao/quan-trong.xlsx \
  --query "DeleteMarkers[].[Key,VersionId]" --output table

aws s3api delete-object --bucket kho-du-lieu-quan-trong \
  --key bao-cao/quan-trong.xlsx --version-id <id-delete-marker>

Xoá delete marker → object hiện lại nguyên vẹn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Xoá nhầm khôi phục được | | | Xoá vĩnh viễn cần MFA | | | Dữ liệu vẫn đọc bình thường | |

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

  • **D. Tạo một bucket policy trên bucket — đây là phương án gần nhất vì bucket policy đúng là công cụ kiểm soát truy cập, nhưng một chính sách từ chối xoá sẽ chặn cả việc xoá cố ý hợp lệ mà đề yêu cầu giữ lại. Và nó không giữ được phiên bản cũ.
  • **A. Tạo một lifecycle policy cho object — lifecycle dùng để chuyển tầng hoặc XOÁ object theo thời gian. Nó không bảo vệ gì; ngược lại, cấu hình sai còn xoá mất dữ liệu.
  • **C. Bật default encryption trên bucket — mã hoá bảo vệ dữ liệu khi lưu trữ, hoàn toàn không liên quan tới việc chống xoá nhầm.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ dữ liệu S3 — bảng phải thuộc: | Cơ chế | Bảo vệ khỏi | Cố ý xoá được | |---|---|---| | Versioning | ghi đè và xoá | ✅ | | MFA Delete | xoá vĩnh viễn vô ý | ✅ (có MFA) ← câu này | | Object Lock — Governance | xoá nhầm | ✅ (có quyền bypass) | | Object Lock — Compliance | xoá cố ý | ❌ KHÔNG AI |

Từ khoá nhận diện:

"prevent accidental deletion" + "user can delete intentionally" → versioning + MFA Delete "cannot be deleted for a fixed period" → Object Lock compliance "admin can override" → Object Lock governance "recover deleted EBS snapshots" → Recycle Bin

Ba trạng thái versioning: | Trạng thái | Nghĩa | |---|---| | Unversioned | mặc định | | Enabled | đang bật | | Suspended | tạm dừng — phiên bản CŨ vẫn còn |

⚠ Không quay về unversioned được — chỉ suspend, và phiên bản cũ vẫn tính phí.

⚠ Ba bẫy chi phí với versioning: | Bẫy | Chi tiết | |---|---| | Mỗi phiên bản tính phí ĐẦY ĐỦ | không phải phần khác biệt | | Xoá chỉ tạo delete marker | dung lượng KHÔNG giảm | | Multipart upload dở tích tụ | |

Lifecycle dọn phiên bản cũ:

{"Rules": [{
  "ID": "don-dep", "Status": "Enabled", "Filter": {},
  "NoncurrentVersionTransitions": [
    {"NoncurrentDays": 30, "StorageClass": "GLACIER_IR"}],
  "NoncurrentVersionExpiration": {"NoncurrentDays": 365},
  "Expiration": {"ExpiredObjectDeleteMarker": true},
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

⚠ MFA Delete xung đột với lifecycle:

Bật MFA Delete
    → lifecycle KHÔNG xoá được phiên bản cũ
        ↓
    Dung lượng chỉ có tăng
    → cân nhắc Object Lock governance thay thế
      nếu cần vừa bảo vệ vừa tự dọn

Ba lệnh làm việc với phiên bản: | Lệnh | Việc | |---|---| | list-object-versions | xem mọi phiên bản | | get-object --version-id | lấy một phiên bản | | delete-object --version-id | xoá VĨNH VIỄN |

Ba lưu ý về delete marker: | Lưu ý | Chi tiết | |---|---| | GET không có version-id → 404 | | | Object vẫn còn phía dưới | | | Xoá delete marker → object hiện lại | |

Ba biện pháp bổ sung cho dữ liệu quan trọng: | Biện pháp | Việc | |---|---| | S3 Replication sang bucket/tài khoản khác | chống mất cả bucket | | CloudTrail data event | ghi mọi thao tác | | Bucket policy chặn s3:DeleteObjectVersion | |

⚠ Replication sang TÀI KHOẢN khác là bảo vệ mạnh nhất:

Kẻ tấn công chiếm được tài khoản
    → xoá được mọi thứ trong tài khoản đó
        ↓
    Bản sao ở tài khoản khác vẫn còn
    → đây là lớp bảo vệ mà versioning không cho được

aws s3api put-bucket-replication --bucket kho-du-lieu-quan-trong \
  --replication-configuration '{"Role":"<arn-role>","Rules":[{
    "ID":"sao-luu-tai-khoan-khac","Status":"Enabled","Priority":1,
    "Filter":{},"DeleteMarkerReplication":{"Status":"Disabled"},
    "Destination":{"Bucket":"arn:aws:s3:::kho-sao-luu",
      "Account":"444455556666",
      "AccessControlTranslation":{"Owner":"Destination"}}}]}'

⚠ DeleteMarkerReplication: Disabled là chi tiết quan trọng:

Bật replication delete marker
    → xoá ở nguồn cũng "xoá" ở đích
        ↓
    Tắt nó đi để bản sao lưu KHÔNG bị ảnh hưởng

Ba lưu ý về CloudTrail data event: | Lưu ý | Chi tiết | |---|---| | Không bật mặc định | phải khai rõ | | Tính phí theo số sự kiện | | | Lọc theo tiền tố để giảm chi phí | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoá một object rồi khôi phục | | | Thử xoá vĩnh viễn không có MFA | phải bị từ chối | | Kiểm tra dung lượng bucket theo thời gian | |

Và một lời khuyên: hãy thêm replication sang một tài khoản AWS khác cho dữ liệu thực sự quan trọng. Versioning và MFA Delete bảo vệ rất tốt khỏi lỗi con người trong tài khoản, nhưng chúng không giúp gì khi chính tài khoản đó bị chiếm quyền — và đó là kịch bản mà "highly critical data" cần được chuẩn bị cho.

Câu 997 AWS Networking & Content Delivery

A Solutions Architect has placed an Amazon CloudFront distribution in front of their web server, which is serving up a highly accessed website, serving content globally. The Solutions Architect needs to dynamically route the user to a new URL depending on where the user is accessing from, through running a particular script. This dynamic routing will happen on every request, and as a result requires the code to run at extremely low latency, and low cost.

What solution will best achieve this goal?

  1. A

    Use Path Based Routing to route each user to the appropriate webpage behind an Application Load Balancer.
  2. B

    At the Edge Location, run your code with CloudFront Functions.
  3. C

    Use Route 53 Geo Proximity Routing to route users’ traffic to your resources based on their geographic location.
  4. D

    Redirect traffic by running your code within a Lambda function using Lambda@Edge.
Xem giải thích

Đáp án

B — Chạy mã ở Edge Location bằng CloudFront Functions.

Vì sao đúng

Đề nêu bốn yêu cầu, và CloudFront Functions khớp chính xác: | Yêu cầu | Cách đáp ứng | |---|---| | Định tuyến động theo vị trí người dùng | đọc header CloudFront-Viewer-Country | | Chạy trên MỖI request | CloudFront Functions thiết kế cho việc này | | Độ trễ CỰC THẤP | dưới 1 mili giây | | Chi phí THẤP | rẻ hơn Lambda@Edge khoảng 6 lần |

⚠ Hai yêu cầu cuối là điểm phân biệt với Lambda@Edge: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Thời gian chạy | dưới 1 ms | tới 5 giây (viewer) / 30 giây (origin) | | Chi phí | rẻ hơn ~6 lần | | | Chạy ở | hơn 600 edge location | ~13 regional edge cache | | Truy cập mạng | ❌ | ✅ | | Ngôn ngữ | JavaScript (ECMAScript 5.1) | Node.js, Python |

Đề nói "extremely low latency" VÀ "low cost"
    → cả hai đều chỉ về CloudFront Functions

Viết function:

function handler(event) {
    var req = event.request;
    var headers = req.headers;

    var quocGia = headers['cloudfront-viewer-country']
        ? headers['cloudfront-viewer-country'].value : 'US';

    var duongDan = {
        'VN': '/vi',
        'JP': '/ja',
        'DE': '/de'
    };

    var tienTo = duongDan[quocGia] || '/en';
    req.uri = tienTo + req.uri;

    return req;
}

Hoặc chuyển hướng hẳn sang URL khác:

function handler(event) {
    var quocGia = event.request.headers['cloudfront-viewer-country'].value;
    if (quocGia === 'VN') {
        return {
            statusCode: 302,
            statusDescription: 'Found',
            headers: { 'location': { value: 'https://vidu.vn/' } }
        };
    }
    return event.request;
}

Triển khai:

aws cloudfront create-function --name dinh-tuyen-theo-quoc-gia \
  --function-config Comment="Dinh tuyen theo quoc gia",Runtime=cloudfront-js-2.0 \
  --function-code fileb://ham.js

aws cloudfront publish-function --name dinh-tuyen-theo-quoc-gia \
  --if-match <etag>

Gắn vào distribution:

{"DefaultCacheBehavior": {
  "FunctionAssociations": {"Quantity": 1, "Items": [
    {"EventType": "viewer-request",
     "FunctionARN": "arn:aws:cloudfront::123456789012:function/dinh-tuyen-theo-quoc-gia"}]}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chạy trước khi tra cache | có thể đổi cache key | | Không có khởi động lạnh | | | Chi phí rất thấp cho lưu lượng lớn | |

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

  • **D. Chuyển hướng bằng mã trong Lambda@Edge — đây là phương án gần nhất và hoàn toàn làm được, nhưng nó đắt hơn và chậm hơn: Lambda@Edge chạy ở regional edge cache chứ không phải mọi edge location, có khởi động lạnh, và tính phí cao hơn nhiều. Đề nhấn mạnh cả "extremely low latency" lẫn "low cost".
  • **C. Dùng Route 53 Geo Proximity Routing — định tuyến ở tầng DNS, chỉ chọn được endpoint nào, không đổi được URL hay đường dẫn. Và nó không "chạy một script trên mỗi request".
  • **A. Dùng Path Based Routing trên ALB — ALB định tuyến theo đường dẫn có sẵn trong request, nó không tạo ra đường dẫn mới theo vị trí người dùng. Và ALB nằm ở origin, không phải ở edge.

Ghi nhớ

⚠ Hai dịch vụ chạy mã ở edge — bảng phải thuộc: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Thời gian tối đa | < 1 ms | 5-30 giây | | Bộ nhớ | 2 MB | 128 MB - 10 GB | | Truy cập mạng / gọi AWS API | ❌ | ✅ | | Đọc thân request | ❌ | ✅ | | Sự kiện hỗ trợ | viewer-request, viewer-response | cả 4 loại | | Chi phí | rẻ hơn ~6 lần | |

⚠ Bốn điểm gắn mã trong vòng đời CloudFront:

Viewer → [1. viewer-request] → CloudFront cache
                                    ↓ (cache miss)
                            [2. origin-request] → Origin
                                    ↓
                            [3. origin-response]
                                    ↓
         [4. viewer-response] ← CloudFront
Điểm CloudFront Functions Lambda@Edge
viewer-request ✅ ✅
origin-request ❌ ✅
origin-response ❌ ✅
viewer-response ✅ ✅

Từ khoá nhận diện:

"every request", "extremely low latency", "low cost" → CloudFront Functions "call an API", "access a database", "read request body" → Lambda@Edge "route to nearest Region" → Route 53 latency hoặc Global Accelerator

Ba trường hợp dùng CloudFront Functions: | Trường hợp | Chi tiết | |---|---| | Viết lại URL, chuyển hướng | ← câu này | | Thêm/sửa header (bảo mật, cache) | | | Kiểm tra token đơn giản | |

Ba trường hợp cần Lambda@Edge: | Trường hợp | Chi tiết | |---|---| | Gọi API hoặc CSDL để quyết định | | | Xử lý thân request (POST body) | | | Chọn origin động | |

⚠ Ba header CloudFront thêm vào: | Header | Nội dung | |---|---| | CloudFront-Viewer-Country | mã quốc gia hai chữ | | CloudFront-Is-Mobile-Viewer | loại thiết bị | | CloudFront-Viewer-Latitude/Longitude | vị trí gần đúng |

⚠ Phải bật header trong origin request policy:

aws cloudfront create-origin-request-policy --origin-request-policy-config '{
  "Name":"chuyen-tiep-quoc-gia",
  "HeadersConfig":{"HeaderBehavior":"whitelist",
    "Headers":{"Quantity":1,"Items":["CloudFront-Viewer-Country"]}},
  "CookiesConfig":{"CookieBehavior":"none"},
  "QueryStringsConfig":{"QueryStringBehavior":"none"}}'

Không bật: header không tới được function
    → mã đọc ra undefined

⚠ Đưa quốc gia vào CACHE KEY nếu nội dung khác nhau:

aws cloudfront create-cache-policy --cache-policy-config '{
  "Name":"cache-theo-quoc-gia","DefaultTTL":86400,"MaxTTL":31536000,"MinTTL":1,
  "ParametersInCacheKeyAndForwardedToOrigin":{
    "HeadersConfig":{"HeaderBehavior":"whitelist",
      "Headers":{"Quantity":1,"Items":["CloudFront-Viewer-Country"]}},
    "CookiesConfig":{"CookieBehavior":"none"},
    "QueryStringsConfig":{"QueryStringBehavior":"none"}}}'

Không đưa vào cache key
    → người dùng Nhật có thể nhận bản cache của người Việt

Ba giới hạn của CloudFront Functions: | Giới hạn | Chi tiết | |---|---| | Kích thước mã tối đa 10 KB | | | Không đọc được thân request | | | JavaScript hạn chế (không có fetch, không có timer) | |

Ba lưu ý về kiểm thử: | Lưu ý | Chi tiết | |---|---| | Dùng test-function trước khi publish | | | Function có hai stage: DEVELOPMENT và LIVE | | | publish-function đưa từ DEV lên LIVE | |

aws cloudfront test-function --name dinh-tuyen-theo-quoc-gia \
  --if-match <etag> --stage DEVELOPMENT \
  --event-object fileb://su-kien-mau.json

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudFront Functions tính theo số lần gọi | | | Lambda@Edge tính cả số lần gọi và thời gian | | | Cache tốt giảm số lần gọi origin-request | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử từ nhiều quốc gia (VPN hoặc curl với header) | | | Kiểm tra CloudWatch metric của function | | | Xem tỷ lệ cache hit không tụt | |

Và một lời khuyên: hãy kiểm tra cache key ngay sau khi thêm logic định tuyến theo vị trí. Function chạy đúng nhưng cache key không phân biệt quốc gia là cách nhanh nhất để một người dùng ở Đức nhận được trang tiếng Việt — và lỗi đó xuất hiện ngẫu nhiên nên rất khó tái hiện.

Câu 998 AWS Compute

An application running on an Amazon ECS container instance using the EC2 launch type needs permissions to write data to Amazon DynamoDB.

How can you assign these permissions only to the specific ECS task that is running the application?

  1. A

    Modify the AmazonECSTaskExecutionRolePolicy policy to add permissions for DynamoDB
  2. B

    Use a security group to allow outbound connections to DynamoDB and assign it to the container instance
  3. C

    Create an IAM policy with permissions to DynamoDB and attach it to the container instance
  4. D

    Create an IAM policy with permissions to DynamoDB and assign It to a task using the taskRoleArn parameter
Xem giải thích

Đáp án

D — Tạo một IAM policy có quyền vào DynamoDB và gán cho task qua tham số taskRoleArn.

Vì sao đúng

Đề hỏi cách cấp quyền chỉ cho một ECS task cụ thể, và task role là cơ chế duy nhất làm được: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng chạy trong ECS task cần ghi DynamoDB | task role cấp credential tạm cho container | | **Quyền chỉ áp cho RIÊNG task đó | mỗi task definition một role riêng |

Task role hoạt động thế nào:

ECS agent lấy credential tạm cho task role
    → phơi bày qua endpoint metadata cục bộ của container
        ↓
    AWS SDK trong container TỰ TÌM THẤY và dùng
    → không cần đặt access key ở đâu cả

Task definition:

{"family": "ung-dung-ghi-dynamodb",
 "taskRoleArn": "arn:aws:iam::123456789012:role/VaiTroTacVuDynamoDB",
 "executionRoleArn": "arn:aws:iam::123456789012:role/VaiTroThucThiECS",
 "containerDefinitions": [{
   "name": "ung-dung",
   "image": "123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/ung-dung:latest",
   "memory": 512, "cpu": 256}]}

Trust policy của role:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"Service": "ecs-tasks.amazonaws.com"},
   "Action": "sts:AssumeRole"}]}

Permission policy:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Action": ["dynamodb:PutItem", "dynamodb:UpdateItem"],
   "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/DuLieu"}]}

⚠ Phân biệt hai role trong task definition — điều phải thuộc: | Role | Ai dùng | Việc | |---|---|---| | taskRoleArn (task role) | MÃ TRONG container | gọi API AWS ← câu này | | executionRoleArn (execution role) | ECS agent | kéo ảnh ECR, ghi log, lấy secret |

Nhầm hai cái này là lỗi rất phổ biến:
    → cấp quyền DynamoDB cho execution role
    → task chạy được nhưng ứng dụng vẫn AccessDenied

Trong mã không cần làm gì:

import boto3
bang = boto3.resource('dynamodb').Table('DuLieu')
bang.put_item(Item={'ma': 'abc123', 'gia_tri': 42})

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi task một quyền riêng | đặc quyền tối thiểu | | Credential tạm, tự luân chuyển | | | Không có khoá nào để rò rỉ | |

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

  • **C. Tạo IAM policy và gắn vào container instance — đây là phương án gần nhất vì cũng cấp được quyền, nhưng nó phá vỡ yêu cầu "chỉ cho task cụ thể": gắn vào instance profile nghĩa là MỌI task chạy trên máy đó đều dùng chung quyền.
  • **A. Sửa chính sách AmazonECSTaskExecutionRolePolicy thêm quyền DynamoDB — sai role: policy đó dành cho execution role, tức ECS agent dùng để kéo ảnh và ghi log, không phải cho mã ứng dụng. Và sửa một managed policy của AWS là việc không nên làm.
  • **B. Dùng security group cho phép kết nối ra DynamoDB — security group kiểm soát đường đi mạng, không cấp quyền API. Kể cả mở hết mạng thì DynamoDB vẫn từ chối vì thiếu quyền IAM.

Ghi nhớ

⚠ Ba cách cấp quyền AWS cho tải chạy trên AWS — bảng phải thuộc: | Nơi chạy | Cơ chế | |---|---| | EC2 | instance profile | | ECS task | task role (taskRoleArn) ← câu này | | EKS pod | IRSA hoặc Pod Identity | | Lambda | execution role |

Nguyên tắc gốc:

KHÔNG BAO GIỜ đặt access key dài hạn vào mã, ảnh container, hay biến môi trường. Luôn dùng role — credential tạm thời, tự luân chuyển.

Từ khoá nhận diện:

"permissions only for a specific ECS task" → task role "ECS needs to pull image from ECR" → execution role "EKS pod needs AWS permissions" → IRSA / Pod Identity

Ba quyền điển hình của execution role: | Quyền | Việc | |---|---| | ecr:GetAuthorizationToken, ecr:BatchGetImage | kéo ảnh | | logs:CreateLogStream, logs:PutLogEvents | ghi log | | secretsmanager:GetSecretValue | tiêm secret vào biến môi trường |

⚠ Vế thứ ba là chỗ hay nhầm nhất:

Container cần mật khẩu từ Secrets Manager
    → khai trong "secrets" của task definition
    → ECS AGENT lấy giá trị và tiêm vào
        ↓
    Quyền đó thuộc EXECUTION role

Còn nếu MÃ tự gọi API Secrets Manager lúc chạy
        ↓
    Quyền thuộc TASK role

{"secrets": [{"name": "DB_PASSWORD",
  "valueFrom": "arn:aws:secretsmanager:...:secret:db-abc:password::"}]}

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Mỗi task definition một role riêng | không dùng chung | | Giới hạn Resource tới đúng ARN bảng | | | Tách quyền đọc và ghi nếu được | |

⚠ Quyền cấp bảng và cấp index khác nhau:

{"Effect":"Allow","Action":"dynamodb:Query",
 "Resource":["arn:aws:dynamodb:...:table/DuLieu",
             "arn:aws:dynamodb:...:table/DuLieu/index/*"]}

Truy vấn qua GSI cần quyền trên CẢ bảng lẫn index
    → chỉ khai bảng thì Query trên GSI bị từ chối

Ba lưu ý cho launch type EC2 (như đề nêu): | Lưu ý | Chi tiết | |---|---| | Instance profile vẫn cần cho ECS agent | AmazonEC2ContainerServiceforEC2Role | | Task role tách biệt với instance profile | | | Chặn task truy cập IMDS của instance | |

⚠ Chặn IMDS là bước bảo mật quan trọng:

# Trong /etc/ecs/ecs.config trên container instance
ECS_AWSVPC_BLOCK_IMDS=true

Không chặn: container gọi được 169.254.169.254
    → lấy credential của INSTANCE PROFILE
    → task role trở nên vô nghĩa

Ba lưu ý cho Fargate: | Lưu ý | Chi tiết | |---|---| | Không có container instance nào | mọi quyền qua task role | | Execution role BẮT BUỘC | | | IMDS không phơi bày credential của node | an toàn hơn |

Ba cách kiểm chứng quyền: | Cách | Chi tiết | |---|---| | aws sts get-caller-identity trong container | | | IAM Policy Simulator | | | CloudTrail xem lệnh bị từ chối | |

# Trong container
curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
aws sts get-caller-identity

Hai lệnh này cho biết ngay container đang mang danh tính nào

Ba lỗi hay gặp: | Lỗi | Nguyên nhân | |---|---| | AccessDenied dù đã gắn role | nhầm task role với execution role | | Task không khởi động | execution role thiếu quyền ECR | | Container dùng quyền của instance | chưa chặn IMDS |

Ba lưu ý về network mode: | Mode | Đặc điểm | |---|---| | awsvpc | mỗi task một ENI — bắt buộc với Fargate | | bridge | chia sẻ mạng của host | | host | dùng thẳng mạng host |

Ba lưu ý về VPC endpoint: | Endpoint | Vì sao | |---|---| | DynamoDB (gateway) | miễn phí, không qua NAT | | ECR api và dkr | kéo ảnh riêng tư | | S3 (gateway) | lớp ảnh nằm ở S3 |

Và một lời khuyên: hãy chạy aws sts get-caller-identity trong container khi gặp lỗi phân quyền, trước khi đọc lại policy. Một dòng lệnh cho biết ngay container đang mang danh tính nào — và rất thường xuyên câu trả lời là nó đang dùng instance profile chứ không phải task role.

Câu 999 AWS Networking & Content Delivery

Three Amazon VPCs are used by a company in the same region. The company has two AWS Direct Connect connections to two separate company offices and wishes to share these with all three VPCs. A Solutions Architect has created an AWS Direct Connect gateway. How can the required connectivity be configured?

  1. A

    Create a VPC peering connection between the VPCs and route entries for the Direct Connect Gateway
  2. B

    Create a transit virtual interface between the Direct Connect gateway and each VPC
  3. C

    Associate the Direct Connect gateway to a virtual private gateway in each VPC
  4. D

    Associate the Direct Connect gateway to a transit gateway
Xem giải thích

Đáp án

D — Gắn Direct Connect gateway vào một Transit Gateway.

Vì sao đúng

Đề nêu ba dữ kiện, và Transit Gateway là cách duy nhất thoả hết: | Dữ kiện | Cách đáp ứng | |---|---| | BA VPC trong cùng một vùng | gắn cả ba vào Transit Gateway | | HAI kết nối Direct Connect tới hai văn phòng | gắn DX gateway vào TGW | | Muốn CHIA SẺ cả hai DX cho cả ba VPC | TGW làm trung tâm định tuyến |

Kiến trúc:

Văn phòng A ─┐
             ├─ Direct Connect ─ DX Gateway
Văn phòng B ─┘                       │ transit VIF
                                     ▼
                            ┌─── Transit Gateway ───┐
                            │        │        │      │
                          VPC-1    VPC-2    VPC-3

⚠ Vì sao không dùng virtual private gateway (phương án C):

DX Gateway gắn với VGW:
    → mỗi VPC một VGW, mỗi VGW một association
    → hoạt động được
        ↓
    NHƯNG: các VPC KHÔNG nói chuyện được với nhau qua DX Gateway
    → và không mở rộng tốt khi thêm VPC
        ↓
    Transit Gateway giải quyết cả hai

Ba bước cấu hình:

# 1. Tạo Transit Gateway
aws ec2 create-transit-gateway \
  --description "TGW chia se DX" \
  --options AmazonSideAsn=64512,DefaultRouteTableAssociation=enable

# 2. Gắn ba VPC
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-abc --vpc-id vpc-1 \
  --subnet-ids subnet-1a subnet-1b

# 3. Gắn DX Gateway vào TGW
aws ec2 create-transit-gateway-direct-connect-gateway-attachment \
  --transit-gateway-id tgw-abc --direct-connect-gateway-id dxgw-123

⚠ Và phải dùng TRANSIT VIF, không phải private VIF: | Loại VIF | Nối tới | |---|---| | Private VIF | VPC qua VGW | | Transit VIF | Transit Gateway ← câu này | | Public VIF | dịch vụ AWS công khai |

Transit VIF yêu cầu kết nối DX từ 1 Gbps trở lên
    → hosted connection nhỏ hơn không dùng được

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cả ba VPC dùng chung cả hai DX | | | VPC nói chuyện được với nhau | | | Thêm VPC chỉ là một attachment | |

Và phân đoạn được nếu cần:

TGW route table "san-xuat": chỉ VPC production
TGW route table "thu-nghiem": chỉ VPC test
        ↓
    Cả hai ra được văn phòng
    → nhưng không thấy nhau

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

  • **C. Gắn Direct Connect gateway vào virtual private gateway ở mỗi VPC — đây là phương án gần nhất và về mặt kỹ thuật hoạt động được, nhưng nó kém hơn ở hai điểm: các VPC không nối được với nhau qua DX Gateway, và mỗi VPC cần một VGW riêng nên không mở rộng tốt. Transit Gateway là kiến trúc AWS khuyến nghị cho nhiều VPC.
  • **B. Tạo transit virtual interface giữa DX gateway và MỖI VPC — hiểu sai: transit VIF nối DX với Transit Gateway, không nối trực tiếp với VPC. Và một kết nối DX chỉ hỗ trợ một transit VIF.
  • **A. Tạo VPC peering giữa các VPC và thêm route tới DX Gateway — peering KHÔNG bắc cầu: VPC-2 không dùng được kết nối DX của VPC-1 dù đã peer. Đây là hạn chế cơ bản của peering.

Ghi nhớ

⚠ Ba loại VIF của Direct Connect — bảng phải thuộc: | Loại | Nối tới | Yêu cầu | |---|---|---| | Private VIF | VPC qua VGW | — | | Transit VIF | Transit Gateway | DX ≥ 1 Gbps | | Public VIF | dịch vụ AWS công khai | — |

Từ khoá nhận diện:

"share DX with many VPCs" → Transit Gateway + transit VIF "one DX to VPCs in multiple Regions" → Direct Connect Gateway "two VPCs only" → VPC Peering "expose one service" → PrivateLink

⚠ Direct Connect Gateway và Transit Gateway — phân biệt: | | Direct Connect Gateway | Transit Gateway | |---|---|---| | Phạm vi | TOÀN CẦU | một vùng | | Việc | gộp DX tới VPC ở nhiều vùng | trung tâm định tuyến giữa VPC | | VPC nói chuyện với nhau | ❌ | ✅ | | Tính phí | miễn phí | theo attachment và GB |

Cần cả hai khi có DX và nhiều VPC:
    DX → DX Gateway → Transit Gateway → các VPC

⚠ Ba hạn chế của VPC Peering: | Hạn chế | Chi tiết | |---|---| | KHÔNG bắc cầu | A↔B, B↔C không cho A↔C | | Không dùng chung DX, VPN, NAT, IGW của VPC kia | | | CIDR không được trùng | |

Ba loại attachment của Transit Gateway: | Loại | Nối tới | |---|---| | VPC attachment | VPC | | VPN attachment | Site-to-Site VPN | | Direct Connect Gateway attachment | DX ← câu này | | Peering attachment | TGW ở vùng khác |

Ba khái niệm route table của TGW: | Khái niệm | Nghĩa | |---|---| | Association | attachment này tra bảng nào | | Propagation | route của attachment này vào bảng nào | | Static route | route khai tay |

⚠ Hai khái niệm đầu hay bị lẫn:

Association: "lưu lượng TỪ attachment này tra bảng nào"
Propagation: "route CỦA attachment này xuất hiện ở bảng nào"
        ↓
    Cấu hình sai một trong hai → gói đi được một chiều

Ba giới hạn của Transit Gateway: | Giới hạn | Con số | |---|---| | VPC attachment mỗi TGW | 5.000 | | Băng thông mỗi attachment | ~50 Gbps | | Bảng định tuyến mỗi TGW | 20 |

Ba lưu ý về Direct Connect Gateway: | Lưu ý | Chi tiết | |---|---| | Toàn cầu, không thuộc vùng nào | | | Nối tới VPC ở nhiều vùng | | | KHÔNG cho VPC nói chuyện với nhau qua nó | |

Ba 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ề BGP: | Lưu ý | Chi tiết | |---|---| | Dùng BGP thay static route | tự chuyển khi đường chết | | AS path prepending để ưu tiên | | | BFD phát hiện đường chết dưới 1 giây | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | TGW tính phí theo GIỜ mỗi attachment | | | Cộng phí xử lý theo GB | | | DX Gateway miễn phí | |

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | search-transit-gateway-routes | route đã lan chưa | | Reachability Analyzer | tìm chỗ chặn | | TGW Flow Logs | xem lưu lượng thật |

aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-abc \
  --filters "Name=state,Values=active" --output table

Và một lời khuyên: hãy thiết kế bảng định tuyến phân đoạn của Transit Gateway ngay từ khi gắn VPC đầu tiên. Mặc định "mọi VPC thấy nhau" là một quyết định bảo mật mà không ai chủ động đưa ra — và tách chúng ra sau khi đã có chục attachment là việc phải làm từng bước để không cắt nhầm đường đang chạy.

Câu 1000 AWS Database

A Solutions Architect is migrating a distributed application from their on-premises environment into AWS. This application consists of an Apache Cassandra NoSQL database, with a containerized SUSE Linux compute layer with an additional storage layer made up of multiple Microsoft SQL Server databases. Once in the cloud the company wants to have as little operational overhead as possible, with no schema conversion during the migration and the company wants to host the architecture in a highly available and durable way.


Which of the following groups of services will provide the solutions architect with the best solution ?

  1. A

    Run the NoSQL database on DynamoDB, and the compute layer on Amazon ECS on Fargate. Use Amazon RDS for Microsoft SQL Server to host the second storage layer.
  2. B

    Run the NoSQL database on DynamoDB, and the compute layer on Amazon ECS on EC2. Use Amazon RDS for Microsoft SQL Server to host the second storage layer.
  3. C

    Run the NoSQL database on Amazon Keyspaces, and the compute layer on Amazon ECS on Fargate. Use Amazon RDS for Microsoft SQL Server to host the second storage layer.
  4. D

    Run the NoSQL database on Amazon Keyspaces, and the compute layer on Amazon ECS on Fargate. Use Amazon Aurora to host the second storage layer.
Xem giải thích

Đáp án

C — Chạy NoSQL trên Amazon Keyspaces, tầng tính toán trên ECS với Fargate, và dùng Amazon RDS for Microsoft SQL Server cho tầng lưu trữ thứ hai.

Vì sao đúng

Đề nêu năm ràng buộc, và phương án này thoả hết: | Ràng buộc | Cách đáp ứng | |---|---| | **CSDL NoSQL là Apache Cassandra | Keyspaces tương thích Cassandra | | Tầng tính toán đã container hoá (SUSE Linux) | ECS trên Fargate | | Tầng lưu trữ thứ hai là Microsoft SQL Server | RDS for SQL Server | | KHÔNG chuyển đổi schema khi di chuyển | cả ba đều giữ nguyên engine | | Ít công vận hành, sẵn sàng cao và bền | cả ba đều được quản lý |

⚠ "No schema conversion" là ràng buộc quyết định:

Cassandra → DynamoDB: PHẢI chuyển đổi mô hình dữ liệu
    → mô hình khoá khác, ngôn ngữ truy vấn khác (CQL vs API)
        ↓
Cassandra → Amazon Keyspaces: TƯƠNG THÍCH CQL
    → giữ nguyên schema, giữ nguyên mã ứng dụng

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

Amazon Keyspaces là gì:

Dịch vụ Cassandra được quản lý hoàn toàn của AWS
    → dùng chính CQL (Cassandra Query Language)
    → driver Cassandra hiện có kết nối được
        ↓
    Không có node nào để vận hành
    → tự co giãn, tự nhân bản qua 3 AZ

Tạo keyspace và bảng:

CREATE KEYSPACE du_lieu_ung_dung
WITH REPLICATION = {'class': 'SingleRegionStrategy'};

CREATE TABLE du_lieu_ung_dung.su_kien (
    ma_thiet_bi text,
    thoi_gian timestamp,
    gia_tri double,
    PRIMARY KEY (ma_thiet_bi, thoi_gian)
) WITH CUSTOM_PROPERTIES = {'capacity_mode': {'throughput_mode': 'PAY_PER_REQUEST'}};

Và vì sao Fargate chứ không phải EC2:

Container hiện có chạy SUSE Linux
    → Fargate chạy container Linux bình thường
        ↓
    ECS trên EC2: vẫn phải vá lỗi và co giãn cụm máy
    ECS trên Fargate: KHÔNG có máy chủ nào
        ↓
    "as little operational overhead as possible"

Triển khai:

aws ecs create-service --cluster cum-ung-dung --service-name dich-vu-tinh-toan \
  --task-definition tinh-toan:1 --desired-count 4 --launch-type FARGATE \
  --network-configuration 'awsvpcConfiguration={
    subnets=[subnet-a,subnet-b],securityGroups=[sg-app],assignPublicIp=DISABLED}'

Và RDS for SQL Server giữ nguyên engine:

aws rds create-db-instance --db-instance-identifier sql-server-ung-dung \
  --engine sqlserver-se --engine-version 15.00 \
  --db-instance-class db.m6i.xlarge --allocated-storage 500 \
  --multi-az --storage-encrypted --license-model license-included

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đổi schema, không đổi mã | | | Cả ba tầng đều đa AZ | | | Không quản lý máy chủ nào | |

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

  • **D. Keyspaces + Fargate + Amazon Aurora cho tầng lưu trữ thứ hai — đây là phương án gần nhất và hai phần đầu hoàn toàn đúng, nhưng Aurora chỉ hỗ trợ MySQL và PostgreSQL. Chuyển SQL Server sang Aurora nghĩa là chuyển đổi schema và mã — đúng thứ đề nói không được làm.
  • **A. DynamoDB + Fargate + RDS SQL Server — DynamoDB không tương thích Cassandra: phải thiết kế lại mô hình dữ liệu và viết lại tầng truy cập.
  • **B. DynamoDB + ECS trên EC2 + RDS SQL Server — sai cả hai vế đầu: DynamoDB cần chuyển đổi schema, và ECS trên EC2 là công vận hành cao hơn Fargate.

Ghi nhớ

⚠ Bảng "dịch vụ AWS tương thích với engine nào" — phải thuộc: | Engine gốc | Dịch vụ AWS tương thích | |---|---| | Apache Cassandra | Amazon Keyspaces | | MongoDB | Amazon DocumentDB | | Redis | ElastiCache for Redis / MemoryDB | | Apache Kafka | Amazon MSK | | Microsoft SQL Server | RDS for SQL Server | | Oracle | RDS for Oracle | | Neo4j / Gremlin / SPARQL | Amazon Neptune |

⚠ Đây là nhóm câu hỏi rất hay gặp:

Đề nói "no schema conversion" hoặc "minimal code changes"
    → tìm dịch vụ AWS TƯƠNG THÍCH với engine gốc
        ↓
    Không phải "dịch vụ AWS tốt nhất trong loại đó"

Từ khoá nhận diện:

"Cassandra" + "no schema conversion" → Amazon Keyspaces "MongoDB" + "minimal changes" → DocumentDB "SQL Server" → RDS for SQL Server (Aurora không hỗ trợ) "containerized, least overhead" → ECS/EKS trên Fargate

Ba engine mà Aurora hỗ trợ: | Engine | Hỗ trợ | |---|---| | MySQL | ✅ | | PostgreSQL | ✅ | | SQL Server, Oracle | ❌ |

Ba đặc điểm của Amazon Keyspaces: | Đặc điểm | Chi tiết | |---|---| | Serverless — không có node | | | Tương thích CQL và driver Cassandra | | | Nhân bản qua 3 AZ tự động | |

Hai chế độ dung lượng của Keyspaces: | Chế độ | Khi nào | |---|---| | On-demand (PAY_PER_REQUEST) | tải không đoán trước | | Provisioned | tải ổn định, rẻ hơn |

⚠ Ba khác biệt của Keyspaces so với Cassandra tự quản: | Khác biệt | Chi tiết | |---|---| | Không cấu hình replication factor | AWS lo | | Một số tính năng Cassandra không hỗ trợ | materialized view, một số hàm | | Giới hạn kích thước row 1 MB | |

Vế thứ hai đáng kiểm tra trước khi di chuyển:

Ứng dụng dùng tính năng Cassandra nâng cao
    → kiểm tra danh sách tương thích của Keyspaces
        ↓
    Phần lớn ứng dụng chạy được, nhưng nên thử trước

Ba mức "được quản lý" cho container: | Mức | Dịch vụ | Bạn quản lý | |---|---|---| | Cao nhất | App Runner | chỉ ảnh container | | Cao | ECS/EKS trên Fargate | task definition | | Trung bình | ECS/EKS trên EC2 | cụm + máy chủ |

Ba lưu ý về RDS for SQL Server: | Lưu ý | Chi tiết | |---|---| | Có tuỳ chọn license-included hoặc BYOL | | | Multi-AZ dùng Always On hoặc Mirroring | | | Không có quyền sysadmin | |

⚠ Vế thứ ba hay gây bất ngờ khi di chuyển:

RDS không cho truy cập hệ điều hành hay quyền sysadmin
    → một số thao tác quản trị phải làm cách khác
        ↓
    Kiểm tra ứng dụng có phụ thuộc gì vào đó không

Ba lưu ý về di chuyển: | Lưu ý | Chi tiết | |---|---| | DMS chuyển dữ liệu với thời gian ngừng tối thiểu | | | Cùng engine thì KHÔNG cần SCT | | | Bật validation của DMS | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Keyspaces mã hoá at rest mặc định | | | RDS phải bật mã hoá LÚC TẠO | | | Đặt cả hai trong subnet riêng tư | |

Ba lưu ý về Fargate: | Lưu ý | Chi tiết | |---|---| | Mỗi task một ENI — tính IP của subnet | | | Task role cho quyền AWS | | | Chỉ chạy container Linux | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử driver Cassandra với Keyspaces | | | So sánh kết quả truy vấn nguồn và đích | | | Đo độ trễ so với hệ thống cũ | |

Và một lời khuyên: hãy kiểm tra danh sách tính năng Cassandra mà Keyspaces hỗ trợ trước khi cam kết. Tương thích CQL nghĩa là phần lớn truy vấn chạy được, nhưng vài tính năng như materialized view hay một số hàm tổng hợp thì không — và phát hiện điều đó sau khi đã chuyển dữ liệu là lúc rất khó xoay xở.