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

Tìm thấy 2194 câu.

Câu 831 AWS Security, Identity, & Compliance

A healthcare organization is designing a secure web application in the AWS Cloud for managing patient records. The application must securely retrieve and store multiple patient credentials, including access keys and passwords. The organization wants to use an AWS-managed service to handle these credentials. The solution must minimize operational overhead while ensuring security.

Which solution will meet these requirements with the LEAST operational overhead?

  1. A

    Store the patient credentials in AWS Secrets Manager. Use the GetSecretValue API to securely retrieve the credentials in the application at runtime.
  2. B

    Store the patient credentials in AWS Systems Manager Parameter Store. Use the GetParametersByPath API to securely retrieve the credentials in the application at runtime.
  3. C

    Store the patient credentials in an Amazon RDS database table. Encrypt the credentials by using AWS Key Management Service (AWS KMS). Configure the application to query the RDS database to retrieve the credentials.
  4. D

    Store the patient credentials in an Amazon S3 bucket. Enable server-side encryption with AWS KMS keys (SSE-KMS). Use pre-signed URLs to retrieve the credentials securely.
Xem giải thích

Đáp án

A — Lưu thông tin xác thực trong AWS Secrets Manager, dùng GetSecretValue API lấy ra lúc chạy.

Vì sao đúng

Đề nêu ba yêu cầu, và Secrets Manager được thiết kế đúng cho việc này: | Yêu cầu | Cơ chế | |---|---| | Lưu và lấy nhiều loại credential | access key, mật khẩu, chuỗi kết nối | | Dịch vụ AWS quản lý | Secrets Manager là dịch vụ được quản lý | | Ít công vận hành nhất | XOAY VÒNG TỰ ĐỘNG dựng sẵn |

Và xoay vòng tự động là điểm phân biệt quyết định:

Secrets Manager:
    ✓ xoay vòng TỰ ĐỘNG theo lịch
    ✓ Lambda xoay vòng dựng sẵn cho RDS, Redshift, DocumentDB
    ✓ tự cập nhật cả bí mật lẫn database
        ↓
    Parameter Store KHÔNG có cơ chế xoay vòng dựng sẵn
    → phải tự viết

Lưu bí mật:

aws secretsmanager create-secret --name thong-tin-benh-nhan   --secret-string '{"username":"ung_dung","password":"<mat-khau>"}'   --kms-key-id <arn-khoa>

Và lấy ra trong ứng dụng:

import boto3, json
sm = boto3.client('secretsmanager')
bi_mat = json.loads(sm.get_secret_value(
    SecretId='thong-tin-benh-nhan')['SecretString'])

Và bật xoay vòng:

aws secretsmanager rotate-secret --secret-id thong-tin-benh-nhan   --rotation-lambda-arn <arn-lambda>   --rotation-rules AutomaticallyAfterDays=30

Ba lợi ích quan trọng với dữ liệu y tế: | Lợi ích | Chi tiết | |---|---| | Mã hoá bằng KMS mặc định | | | CloudTrail ghi mọi lần truy cập bí mật | audit đầy đủ | | Resource policy giới hạn ai đọc được | |

Và nên đệm bí mật ở phía ứng dụng:

from aws_secretsmanager_caching import SecretCache
cache = SecretCache()
bi_mat = cache.get_secret_string('thong-tin-benh-nhan')

Không đệm: mỗi request gọi API Secrets Manager
    → tốn tiền và thêm độ trễ
        ↓
    Thư viện caching tự làm mới khi bí mật đổi

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

  • **B. Lưu trong Systems Manager Parameter Store, dùng GetParametersByPath — đây là phương án gần nhất và cũng lưu bí mật an toàn (SecureString mã hoá bằng KMS, và tầng standard MIỄN PHÍ), nhưng nó không có xoay vòng tự động dựng sẵn: phải tự viết và bảo trì Lambda xoay vòng. Với yêu cầu "LEAST operational overhead" cho credential, Secrets Manager phù hợp hơn.
  • **C. Lưu trong bảng RDS mã hoá bằng KMS — tự dựng lại một dịch vụ đã có: phải tự lo mã hoá, phân quyền, audit và xoay vòng. Và bản thân việc kết nối tới RDS lại cần một credential khác.
  • **D. Lưu trong S3 với SSE-KMS, dùng presigned URL — presigned URL không phải cơ chế cho bí mật: URL có thể bị chia sẻ, và S3 không có khái niệm phiên bản bí mật hay xoay vòng.

Ghi nhớ

Secrets Manager và Parameter Store — bảng phải thuộc: | | Secrets Manager | Parameter Store | |---|---|---| | Xoay vòng TỰ ĐỘNG | ✅ dựng sẵn | ❌ tự viết | | Sinh mật khẩu ngẫu nhiên | ✅ | ❌ | | Sao chép xuyên Region | ✅ | ❌ | | Resource policy | ✅ | ❌ | | Chi phí | ~0,40 USD/bí mật/tháng | standard MIỄN PHÍ | | Kích thước tối đa | 64 KB | 4 KB (standard), 8 KB (advanced) |

Quy tắc chọn:

Cần XOAY VÒNG tự động, credential database → Secrets Manager Cấu hình thường, không cần xoay vòng, muốn miễn phí → Parameter Store

Ba loại tham số của Parameter Store: | Loại | Đặc điểm | |---|---| | String | văn bản thường | | StringList | danh sách phân tách bằng dấu phẩy | | SecureString | mã hoá bằng KMS |

Ba tính năng của Secrets Manager: | Tính năng | Chi tiết | |---|---| | Xoay vòng tự động | Lambda dựng sẵn cho RDS, Redshift, DocumentDB | | Version staging | AWSCURRENT, AWSPENDING, AWSPREVIOUS | | Cross-Region replica | cho ứng dụng đa Region |

Version staging là cơ chế quan trọng:

Trong lúc xoay vòng:
    AWSCURRENT  → mật khẩu đang dùng
    AWSPENDING  → mật khẩu mới đang được tạo
        ↓
    Sau khi xác nhận: đảo hai nhãn
    → ứng dụng không bao giờ gặp mật khẩu chưa sẵn sàng

Bốn bước của Lambda xoay vòng: | Bước | Việc | |---|---| | createSecret | sinh mật khẩu mới, gắn AWSPENDING | | setSecret | đổi mật khẩu ở database | | testSecret | thử kết nối bằng mật khẩu mới | | finishSecret | chuyển AWSPENDING thành AWSCURRENT |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | IAM policy cho secretsmanager:GetSecretValue | | | Resource policy giới hạn principal | | | Quyền kms:Decrypt trên khoá | bắt buộc |

Dòng cuối là nguyên nhân "Access Denied" hay gặp:

IAM policy cho GetSecretValue ✓
    → nhưng thiếu kms:Decrypt trên khoá mã hoá
        ↓
    Vẫn bị từ chối, và thông báo không nhắc tới KMS

Ba cách tích hợp: | Cách | Chi tiết | |---|---| | SDK gọi GetSecretValue | ← câu này | | Lambda extension | đệm sẵn, giảm lời gọi | | ECS/EKS secret injection | biến môi trường |

ECS lấy bí mật vào biến môi trường:

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

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Mỗi bí mật | ~0,40 USD/tháng | | Mỗi 10.000 lời gọi API | ~0,05 USD | | — | đệm ở ứng dụng giảm mạnh khoản thứ hai |

Ba lưu ý về tuân thủ y tế: | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS cho HIPAA | | | Dùng customer managed key | audit việc dùng khoá | | CloudTrail ghi mọi lần lấy bí mật | |

Ba lỗi bảo mật hay gặp với credential: | Lỗi | Hậu quả | |---|---| | Mật khẩu trong mã nguồn | lộ khi commit lên Git | | Mật khẩu trong user data | đọc được từ metadata service | | Mật khẩu trong biến môi trường không mã hoá | lộ trong log |

Ba lựa chọn tốt hơn nữa nếu áp dụng được: | Lựa chọn | Chi tiết | |---|---| | IAM database authentication | KHÔNG có mật khẩu nào | | IAM role thay access key | cho dịch vụ AWS | | IAM Roles Anywhere | cho ứng dụng ngoài AWS |

Dòng đầu đáng cân nhắc:

Nếu credential là để kết nối RDS
    → IAM database authentication bỏ hẳn mật khẩu
        ↓
    Không có bí mật nào để lưu, để xoay vòng, hay để lộ

Và một lời khuyên: hãy dùng thư viện caching của AWS thay vì gọi GetSecretValue mỗi request. Một ứng dụng có lưu lượng vừa phải gọi API hàng triệu lần mỗi tháng sẽ tốn nhiều hơn cả phí lưu bí mật — và thư viện tự làm mới khi bí mật được xoay vòng nên không có đánh đổi nào.

Câu 832 AWS Analytics

A retail company with many stores and warehouses is implementing IoT sensors to gather monitoring data from devices in each location. The data will be sent to AWS in real time. A solutions architect must provide a solution for ensuring events are received in order for each device and ensure that data is saved for future processing.

Which solution would be MOST efficient?

  1. A

    Use Amazon Kinesis Data Streams for real-time events with a shard for each device. Use Amazon Kinesis Data Firehose to save data to Amazon EBS
  2. B

    Use an Amazon SQS standard queue for real-time events with one queue for each device. Trigger an AWS Lambda function from the SQS queue to save data to Amazon S3
  3. C

    Use an Amazon SQS FIFO queue for real-time events with one queue for each device. Trigger an AWS Lambda function for the SQS queue to save data to Amazon EFS
  4. D

    Use Amazon Kinesis Data Streams for real-time events with a partition key for each device. Use Amazon Kinesis Data Firehose to save data to Amazon S3
Xem giải thích

Đáp án

D — Dùng Kinesis Data Streams với partition key là mã thiết bị, dùng Kinesis Data Firehose lưu dữ liệu vào Amazon S3.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án D đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Giữ THỨ TỰ sự kiện cho MỖI thiết bị | partition key = mã thiết bị | | Thời gian thực | Kinesis độ trễ dưới một giây | | Lưu dữ liệu cho xử lý sau | Firehose đẩy vào S3 |

Vì sao partition key giữ được thứ tự:

Kinesis đảm bảo thứ tự TRONG MỘT SHARD
    → cùng partition key = cùng shard
        ↓
    Mọi sự kiện của thiết bị X đi vào cùng một shard
    → và được đọc đúng thứ tự

Và vì sao KHÔNG dùng một shard cho mỗi thiết bị:

Cửa hàng và kho có RẤT NHIỀU thiết bị
    → một shard mỗi thiết bị = hàng nghìn shard
    → chi phí khổng lồ, và chạm giới hạn tài khoản
        ↓
    Partition key cho phép hàng nghìn thiết bị
      chia sẻ vài shard mà VẪN giữ thứ tự riêng

Đây là khác biệt cốt lõi với phương án A.

Triển khai:

aws kinesis create-stream --stream-name du-lieu-iot   --stream-mode-details StreamMode=ON_DEMAND

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

Và producer gửi với partition key:

kinesis.put_record(
    StreamName='du-lieu-iot',
    Data=json.dumps(su_kien),
    PartitionKey=ma_thiet_bi)     # ← quyết định thứ tự

Và S3 là đích đúng cho lưu trữ:

S3:
    ✓ dung lượng không giới hạn
    ✓ độ bền 11 số 9
    ✓ rẻ nhất
    ✓ truy vấn được bằng Athena
        ↓
    Khác EBS (gắn một máy) và EFS (đắt hơn nhiều)

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

  • **A. Kinesis Data Streams với MỘT SHARD cho mỗi thiết bị, Firehose lưu vào Amazon EBS — đây là phương án gần nhất và đúng ở việc chọn Kinesis, nhưng nó sai ở hai điểm: một shard mỗi thiết bị không mở rộng được với hàng nghìn thiết bị, và Firehose KHÔNG hỗ trợ EBS làm đích.
  • **C. SQS FIFO cho mỗi thiết bị, Lambda lưu vào EFS — không mở rộng được: một hàng đợi cho mỗi thiết bị nghĩa là hàng nghìn hàng đợi phải quản lý. Và EFS đắt hơn S3 nhiều lần cho việc lưu trữ.
  • **B. SQS Standard cho mỗi thiết bị — SQS Standard KHÔNG đảm bảo thứ tự, vi phạm yêu cầu chính. Và cũng gặp vấn đề hàng nghìn hàng đợi.

Ghi nhớ

Ba cơ chế giữ thứ tự — bảng phải thuộc: | Dịch vụ | Cách giữ thứ tự | |---|---| | Kinesis Data Streams | cùng PARTITION KEY = cùng shard | | SQS FIFO | cùng MessageGroupId | | SQS Standard | KHÔNG đảm bảo |

Cả Kinesis lẫn SQS FIFO đều dùng ý tưởng "nhóm" chứ không cần tài nguyên riêng cho mỗi nguồn.

Ba đích của Kinesis Data Firehose: | Đích | Hỗ trợ | |---|---| | Amazon S3 | ✅ | | Amazon Redshift | ✅ | | OpenSearch Service | ✅ | | Splunk, HTTP endpoint, Snowflake | ✅ | | EBS, EFS, DynamoDB | ❌ |

Dòng cuối là lý do phương án A sai ở vế thứ hai.

Kinesis Data Streams và Firehose — bảng phân biệt: | | Data Streams | Firehose | |---|---|---| | Giữ dữ liệu | 1–365 ngày | ❌ | | Nhiều consumer | ✅ | ❌ | | Độ trễ | dưới 1 giây | ~60 giây trở lên | | Quản lý shard | có (hoặc on-demand) | tự động |

Mẫu kết hợp trong câu này rất phổ biến:

Kinesis Data Streams (thời gian thực, giữ thứ tự)
    ├─→ Lambda hoặc ứng dụng: xử lý ngay
    └─→ Firehose: đẩy vào S3 cho lưu trữ và phân tích sau
        ↓
    Một luồng, hai mục đích

Giới hạn của một shard: | Chiều | Giới hạn | |---|---| | Ghi | 1.000 bản ghi/giây HOẶC 1 MB/giây | | Đọc chia sẻ | 2 MB/giây | | Enhanced fan-out | 2 MB/giây riêng mỗi consumer |

Hai chế độ dung lượng: | Chế độ | Đặc điểm | |---|---| | Provisioned | khai shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn tới 200 MB/giây |

Ba nguyên tắc chọn partition key: | Nguyên tắc | Chi tiết | |---|---| | Phân bố ĐỀU tránh hot shard | | | Cùng key = cùng shard = giữ thứ tự | ← câu này | | Số giá trị đủ nhiều | mã thiết bị là lựa chọn tốt |

Hot shard là rủi ro cần theo dõi:

Một thiết bị gửi nhiều hơn hẳn thiết bị khác
    → shard chứa nó bị throttle
        ↓
    Bật shard-level metrics mới thấy

aws kinesis enable-enhanced-monitoring --stream-name du-lieu-iot   --shard-level-metrics IncomingRecords WriteProvisionedThroughputExceeded

Ba tính năng của Firehose: | Tính năng | Chi tiết | |---|---| | Biến đổi bằng Lambda | làm sạch dữ liệu trước khi lưu | | Chuyển đổi định dạng sang Parquet hoặc ORC | rẻ hơn nhiều khi truy vấn | | Phân vùng động | theo trường trong dữ liệu |

Chuyển sang Parquet đáng làm:

{"DataFormatConversionConfiguration": {
  "Enabled": true,
  "OutputFormatConfiguration": {"Serializer": {"ParquetSerDe": {}}}}}

Athena truy vấn JSON: quét toàn bộ
Athena truy vấn Parquet: chỉ đọc cột cần
        ↓
    Giảm chi phí truy vấn tới 90%

Ba lưu ý về phân vùng động: | Lưu ý | Chi tiết | |---|---| | Phân vùng theo mã cửa hàng hoặc ngày | | | Athena chỉ quét phân vùng cần | | | Có phí thêm nhỏ | thường đáng |

Ba dịch vụ cho IoT trên AWS: | Dịch vụ | Việc | |---|---| | AWS IoT Core | kết nối MQTT cho hàng triệu thiết bị | | Kinesis Data Streams | luồng dữ liệu | | IoT Analytics, Timestream | phân tích chuỗi thời gian |

IoT Core đáng cân nhắc:

Nếu thiết bị dùng MQTT và cần quản lý chứng chỉ
    → IoT Core xử lý xác thực từng thiết bị
    → IoT Rule đẩy dữ liệu vào Kinesis
        ↓
    Bảo mật tốt hơn nhiều so với để thiết bị gọi thẳng Kinesis

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAgeMilliseconds | consumer tụt lại | | WriteProvisionedThroughputExceeded | bị throttle | | DeliveryToS3.Success của Firehose | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Kinesis shard-giờ hoặc on-demand | | | Firehose theo GB nạp | | | Gộp lô ở producer giảm PUT payload unit | |

Và một lời khuyên: hãy bật chuyển đổi sang Parquet ngay trong Firehose. Dữ liệu IoT tích tụ rất nhanh, và chênh lệch giữa truy vấn JSON thô với Parquet có phân vùng là hàng chục lần về chi phí Athena — một cấu hình mất năm phút quyết định hoá đơn phân tích của cả năm sau.

Câu 833 AWS Compute

A Solutions Architect has deployed an application on several Amazon EC2 instances across three private subnets. The application must be made accessible to internet-based clients with the least amount of administrative effort.

How can the Solutions Architect make the application available on the internet?

  1. A

    Create an Application Load Balancer and associate three public subnets from the same Availability Zones as the private instances. Add the private instances to the ALB.
  2. B

    Create an Amazon Machine Image (AMI) of the instances in the private subnet and launch new instances from the AMI in public subnets. Create an Application Load Balancer and add the public instances to the ALB.
  3. C

    Create an Application Load Balancer and associate three private subnets from the same Availability Zones as the private instances. Add the private instances to the ALB.
  4. D

    Create a NAT gateway in a public subnet. Add a route to the NAT gateway to the route tables of the three private subnets.
Xem giải thích

Đáp án

A — Tạo Application Load Balancer và gắn BA public subnet ở cùng các AZ với instance riêng tư; thêm instance riêng tư vào ALB.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án A đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng truy cập được từ Internet | ALB ở PUBLIC subnet | | Ít công quản trị nhất | không phải di chuyển instance |

Điểm mấu chốt: ALB và target KHÔNG cần cùng subnet.

ALB đặt ở PUBLIC subnet
    → có đường ra Internet, nhận được request

Target (EC2) ở PRIVATE subnet
    → ALB gọi tới chúng qua IP RIÊNG trong VPC
        ↓
    Hoàn toàn hợp lệ — và là mẫu kiến trúc CHUẨN

Và đây chính là kiến trúc được khuyến nghị:

Internet
    ↓
Public subnet:  ALB (điểm vào duy nhất)
    ↓ IP riêng
Private subnet: EC2 (KHÔNG có IP công cộng)
        ↓
    EC2 không bị quét và tấn công trực tiếp

Triển khai:

aws elbv2 create-load-balancer --name alb-ung-dung   --subnets subnet-public-a subnet-public-b subnet-public-c   --security-groups sg-alb --scheme internet-facing

aws elbv2 create-target-group --name tg-ung-dung   --protocol HTTP --port 8080 --vpc-id vpc-abc --target-type instance

aws elbv2 register-targets --target-group-arn <arn-tg>   --targets Id=i-0aaa Id=i-0bbb Id=i-0ccc

⚠ Và public subnet phải ở CÙNG AZ với instance:

ALB chỉ định tuyến tới target trong AZ mà nó có subnet
    → instance ở AZ-A nhưng ALB không có subnet ở AZ-A
    → target đó KHÔNG nhận được lưu lượng
        ↓
    Đây là lý do đề nhấn mạnh "same Availability Zones"

(Nếu bật cross-zone load balancing — mặc định BẬT với ALB — thì ALB vẫn gửi được, nhưng phải có ít nhất một subnet đăng ký. Đặt subnet ở cùng AZ vẫn là cách rõ ràng và tối ưu độ trễ.)

Và security group thắt chặt:

aws ec2 authorize-security-group-ingress --group-id sg-alb   --protocol tcp --port 443 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress --group-id sg-ec2   --protocol tcp --port 8080 --source-group sg-alb

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

  • **C. Tạo ALB và gắn BA PRIVATE subnet — đây là phương án gần nhất vì chỉ khác một chữ, nhưng ALB ở private subnet không nhận được lưu lượng từ Internet: nó không có đường vào từ ngoài. Đây sẽ là ALB nội bộ (internal).
  • **B. Tạo AMI và khởi động instance MỚI ở public subnet — nhiều công quản trị và kém an toàn hơn: phải dựng lại toàn bộ instance, và đặt chúng ở public subnet làm tăng bề mặt tấn công.
  • **D. Tạo NAT Gateway và thêm route từ private subnet — NAT chỉ cho phép đi RA, không cho vào: nó giúp instance gọi ra Internet, không giúp Internet gọi vào instance.

Ghi nhớ

Mẫu kiến trúc ba tầng chuẩn — bảng phải thuộc: | Thành phần | Subnet | |---|---| | Load balancer, NAT Gateway, bastion | PUBLIC | | EC2 ứng dụng | PRIVATE | | Database | PRIVATE |

Định nghĩa public và private subnet:

Public subnet:  route table CÓ route 0.0.0.0/0 → Internet Gateway
Private subnet: KHÔNG có route đó
        ↓
    Đây là khác biệt DUY NHẤT

NAT Gateway và Internet Gateway — bảng phân biệt: | | Internet Gateway | NAT Gateway | |---|---|---| | Cho phép VÀO từ Internet | ✅ | ❌ | | Cho phép RA Internet | ✅ | ✅ | | Đặt ở | cấp VPC | public subnet | | Dùng cho | public subnet | private subnet ra Internet |

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

Ba loại scheme của load balancer: | Scheme | Đặc điểm | |---|---| | internet-facing | có IP công cộng, cần public subnet | | internal | chỉ IP riêng, dùng trong VPC |

Ba yêu cầu khi tạo ALB: | Yêu cầu | Chi tiết | |---|---| | Ít nhất 2 subnet ở 2 AZ khác nhau | bắt buộc | | Security group | | | Target group với health check | |

Ba loại target type: | Loại | Đăng ký gì | |---|---| | instance | EC2 trong cùng VPC | | ip | IP trong VPC, VPC peering, hoặc on-premises | | lambda | hàm Lambda |

Ba lợi ích của việc để EC2 ở private subnet: | Lợi ích | Chi tiết | |---|---| | Không bị quét từ Internet | | | Không cần IP công cộng | tiết kiệm phí IPv4 | | Điểm vào duy nhất là ALB | dễ kiểm soát |

Ba cách EC2 ở private subnet ra Internet: | Cách | Chi tiết | |---|---| | NAT Gateway | cho lưu lượng Internet thật | | VPC endpoint | cho dịch vụ AWS — rẻ hơn | | Không cần gì | nếu chỉ phục vụ request từ ALB |

Ba cách truy cập quản trị EC2 ở private subnet: | Cách | Chi tiết | |---|---| | Session Manager | không mở cổng nào | | EC2 Instance Connect Endpoint | | | Bastion host ở public subnet | truyền thống |

Ba lưu ý về cross-zone load balancing: | Loại | Mặc định | |---|---| | ALB | BẬT, không tắt được ở mức LB, MIỄN PHÍ | | NLB | TẮT, bật thì tính phí chéo AZ | | GWLB | tắt |

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | ALB gọi target qua IP RIÊNG | không cần IP công cộng | | Security group của target phải cho phép SG của ALB | | | Đường dẫn health check phải tồn tại | |

Ba lỗi hay gặp khiến target unhealthy: | Lỗi | Dấu hiệu | |---|---| | Security group chưa mở | Target.Timeout | | Đường dẫn health check sai | Target.ResponseCodeMismatch | | Ứng dụng chưa khởi động xong | thất bại rồi khoẻ lại |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | ALB theo giờ và LCU | ~18 USD/tháng cơ bản | | Không cần IP công cộng cho EC2 | tiết kiệm ~3,6 USD mỗi IP | | NAT Gateway nếu EC2 cần ra Internet | ~32 USD/tháng |

Và một lời khuyên: hãy nhớ rằng ALB và target không cần nằm cùng subnet. Đây là hiểu lầm rất phổ biến khiến người ta di chuyển instance ra public subnet một cách không cần thiết — và mỗi lần làm vậy là thêm một đội máy bị phơi trực tiếp ra Internet mà không thu được lợi ích gì.

Câu 834 AWS Storage

A Microsoft Windows file server farm uses Distributed File System Replication (DFSR) to synchronize data in an on-premises environment. The infrastructure is being migrated to the AWS Cloud.

Which service should the solutions architect use to replace the file server farm?

  1. A

    Amazon EFS
  2. B

    Amazon FSx
  3. C

    Amazon EBS
  4. D

    AWS Storage Gateway
Xem giải thích

Đáp án

B — Amazon FSx (cụ thể là FSx for Windows File Server).

Vì sao đúng

Đề nêu từ khoá quyết định: DFSR (Distributed File System Replication) của Microsoft Windows.

DFSR là công nghệ RIÊNG của Windows
    → đồng bộ dữ liệu giữa các file server Windows
        ↓
    Thay thế nó cần một dịch vụ hiểu:
        ✓ giao thức SMB
        ✓ quyền NTFS
        ✓ Active Directory
        ↓
    Chỉ FSx for Windows File Server có cả ba

Và FSx for Windows còn có sẵn cơ chế dư thừa:

FSx for Windows Multi-AZ:
    → hai file server ở hai AZ
    → sao chép ĐỒNG BỘ
    → tự chuyển đổi
        ↓
    Thay thế trọn vẹn vai trò của DFSR
    → mà KHÔNG phải tự quản lý gì

Tạo file system:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 1024 --storage-type SSD   --subnet-ids subnet-a subnet-c   --security-group-ids sg-fsx   --windows-configuration       ActiveDirectoryId=d-abc123,DeploymentType=MULTI_AZ_1,ThroughputCapacity=32,PreferredSubnetId=subnet-a

Và máy Windows mount như file share bình thường:

net use Z: \\amznfsxabc123.corp.vidu.com\share

Ba tính năng của Windows mà FSx giữ nguyên: | Tính năng | Chi tiết | |---|---| | Quyền NTFS và ACL | theo tài khoản AD | | Shadow copy (bản sao trước đó) | người dùng tự khôi phục tệp | | DFS Namespace | gộp nhiều file system thành một namespace |

Và tích hợp Active Directory là điều kiện:

FSx for Windows cần AD:
    → AWS Managed Microsoft AD, hoặc
    → AD tự quản (tại chỗ hoặc trên EC2)
        ↓
    Quyền tệp theo đúng tài khoản người dùng hiện có

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

  • **A. Amazon EFS — đây là phương án gần nhất vì cũng là hệ thống tệp chia sẻ được quản lý, nhưng nó chỉ hỗ trợ NFS (Linux): không có SMB, không có quyền NTFS, không tích hợp Active Directory. Ứng dụng Windows không dùng được.
  • **D. AWS Storage Gateway — là cầu nối lai, không phải hệ thống tệp thay thế: File Gateway cho truy cập S3 qua SMB, nhưng nó vẫn là lớp đệm trước S3 chứ không phải file server đầy đủ với quyền NTFS và AD.
  • **C. Amazon EBS — là lưu trữ KHỐI gắn một instance, không phải hệ thống tệp chia sẻ.

Ghi nhớ

Các hệ thống tệp được quản lý của AWS — bảng phải thuộc: | Dịch vụ | Giao thức | Dùng cho | |---|---|---| | Amazon EFS | NFS | Linux | | FSx for Windows File Server | SMB | Windows, AD, NTFS | | FSx for Lustre | Lustre | HPC, thông lượng cao | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức | | FSx for OpenZFS | NFS | ZFS |

Từ khoá nhận diện:

"Windows", "SMB", "DFSR", "Active Directory", "NTFS" → FSx for Windows File Server "Linux", "NFS", "POSIX" → EFS "HPC", "Lustre", "high throughput" → FSx for Lustre "both NFS and SMB", "NetApp" → FSx for ONTAP

Ba kiểu triển khai của FSx for Windows: | Kiểu | Đặc điểm | |---|---| | Single-AZ 1 | thế hệ trước | | Single-AZ 2 | hiệu năng cao hơn | | Multi-AZ | sao chép đồng bộ, tự chuyển đổi |

Multi-AZ chính là thứ thay thế DFSR.

Ba yêu cầu để dùng FSx for Windows: | Yêu cầu | Chi tiết | |---|---| | Active Directory | Managed AD hoặc AD tự quản | | Subnet trong VPC | hai subnet cho Multi-AZ | | Security group mở cổng SMB | 445, và các cổng AD |

Ba tính năng đáng biết: | Tính năng | Chi tiết | |---|---| | Data deduplication | tiết kiệm tới 50–60% dung lượng | | Shadow copy | người dùng tự khôi phục tệp | | User quota | giới hạn dung lượng mỗi người |

Bật deduplication:

Enable-FSxDedup -FileSystemPath \\amznfsxabc.corp.vidu.com\share

Tệp Windows thường trùng lặp nhiều
    → deduplication tiết kiệm đáng kể

Hai loại lưu trữ của FSx for Windows: | Loại | Đặc điểm | |---|---| | SSD | độ trễ thấp, IOPS cao | | HDD | rẻ hơn ~6 lần, cho tải ít truy cập |

Ba cách di chuyển dữ liệu sang FSx: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh nhất, giữ metadata và ACL | | Robocopy | quen thuộc với quản trị Windows | | Storage Gateway | cho di chuyển dần |

DataSync giữ được ACL:

aws datasync create-location-smb   --server-hostname 192.168.1.50 --subdirectory /share   --user quantri --domain CORP --password '<mat-khau>'   --agent-arns <arn-agent>

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Backup tự động hằng ngày | giữ tới 90 ngày | | AWS Backup quản lý tập trung được | | | Shadow copy cho khôi phục nhanh từng tệp | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Throughput capacity chọn khi tạo | đổi sau được | | Multi-AZ có độ trễ ghi cao hơn Single-AZ | do sao chép đồng bộ | | SSD cho tải nhạy độ trễ | |

Ba lưu ý về truy cập từ on-premises: | Lưu ý | Chi tiết | |---|---| | Cần VPN hoặc Direct Connect | | | DNS phải phân giải được tên FSx | | | Mở đủ cổng SMB và AD | |

Ba lựa chọn nếu không dùng Windows: | Lựa chọn | Khi nào | |---|---| | EFS | ứng dụng Linux | | FSx for ONTAP | cần cả NFS lẫn SMB | | S3 | nếu sửa được ứng dụng |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Dung lượng lưu trữ | SSD đắt hơn HDD nhiều | | Throughput capacity | tính riêng | | Multi-AZ gấp đôi phí lưu trữ | |

Và một lời khuyên: hãy bật data deduplication ngay sau khi tạo file system. Dữ liệu file server Windows thường trùng lặp rất nhiều — bản sao tài liệu, tệp cài đặt, hồ sơ người dùng — và mức tiết kiệm 50% dung lượng là con số thường thấy chứ không phải trường hợp đặc biệt.

Câu 835 AWS Storage

A company runs a dynamic website that is hosted on an on-premises server in the United States. The company is expanding to Europe and is investigating how they can optimize the performance of the website for European users. The website’s backed must remain in the United States. The company requires a solution that can be implemented within a few days.

What should a Solutions Architect recommend?

  1. A

    Launch an Amazon EC2 instance in an AWS Region in the United States and migrate the website to it.
  2. B

    Migrate the website to Amazon S3. Use cross-Region replication between Regions and a latency-based Route 53 policy.
  3. C

    Use Amazon CloudFront with Lambda@Edge to direct traffic to an on-premises origin.
  4. D

    Use Amazon CloudFront with a custom origin pointing to the on-premises servers.
Xem giải thích

Đáp án

D — Dùng Amazon CloudFront với custom origin trỏ tới máy chủ tại chỗ.

Vì sao đúng

Đề nêu ba ràng buộc, và CloudFront với custom origin đáp ứng cả ba: | Ràng buộc | Cơ chế | |---|---| | Backend PHẢI ở lại Mỹ | custom origin trỏ tới máy chủ tại chỗ | | Cải thiện hiệu năng cho người dùng châu Âu | đệm ở edge location châu Âu | | Triển khai trong vài NGÀY | chỉ tạo một distribution |

Điểm mấu chốt: origin của CloudFront KHÔNG cần ở AWS.

CloudFront custom origin:
    → bất kỳ máy chủ HTTP nào có tên miền công khai
    → kể cả máy chủ trong trung tâm dữ liệu của bạn
        ↓
    Không phải di chuyển gì cả

Triển khai:

aws cloudfront create-distribution --distribution-config '{
  "CallerReference":"web-eu",
  "Origins":{"Quantity":1,"Items":[{
    "Id":"origin-tai-cho",
    "DomainName":"goc.vidu.com",
    "CustomOriginConfig":{
      "HTTPPort":80,"HTTPSPort":443,
      "OriginProtocolPolicy":"https-only",
      "OriginSslProtocols":{"Quantity":1,"Items":["TLSv1.2"]}}}]},
  "DefaultCacheBehavior":{
    "TargetOriginId":"origin-tai-cho",
    "ViewerProtocolPolicy":"redirect-to-https",
    "CachePolicyId":"<id-cache-policy>"},
  "Enabled":true}'

Và với website ĐỘNG, CloudFront vẫn giúp đáng kể:

Nội dung động không đệm được lâu
    → nhưng vẫn hưởng:
        ✓ kết thúc TLS ở edge gần người dùng
        ✓ kết nối giữ sẵn tới origin
        ✓ mạng riêng của AWS cho chặng dài
        ↓
    Giảm số vòng lượt qua Đại Tây Dương

Con số cụ thể:

Không có CloudFront:
    Người dùng Paris → máy chủ Mỹ
    → bắt tay TCP + TLS = 3 vòng lượt × ~120ms = ~360ms
    → rồi mới bắt đầu tải nội dung

Có CloudFront:
    Người dùng Paris → edge Paris (~5ms)
    → bắt tay ở đó
    → CloudFront giữ kết nối sẵn tới origin
        ↓
    Tiết kiệm phần lớn thời gian chờ ban đầu

Và phần tĩnh được đệm hoàn toàn:

Website động vẫn có ảnh, CSS, JavaScript
    → những thứ đó đệm được lâu
        ↓
    Phần lớn byte của một trang web là nội dung tĩnh

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

  • **C. Dùng CloudFront với Lambda@Edge định tuyến tới origin tại chỗ — đây là phương án gần nhất vì cũng dùng CloudFront với origin tại chỗ, nhưng Lambda@Edge là phần thừa: nó dùng để biến đổi request và response ở biên, không cần thiết cho việc chỉ đơn giản trỏ tới origin. Thêm nó là thêm độ phức tạp và chi phí.
  • **A. Khởi động EC2 ở Region Mỹ và di chuyển website — vi phạm ràng buộc "backend phải ở lại Mỹ" theo nghĩa là phải di chuyển, và không cải thiện gì cho người dùng châu Âu: vẫn ở Mỹ.
  • **B. Di chuyển sang S3 với cross-Region replication — S3 chỉ phục vụ nội dung TĨNH: đề nói rõ đây là "dynamic website".

Ghi nhớ

Ba loại origin của CloudFront — bảng phải thuộc: | Loại | Chi tiết | |---|---| | S3 origin | bucket, dùng với OAC | | Custom origin | ALB, EC2, hoặc máy chủ NGOÀI AWS | | VPC origin | tài nguyên trong VPC không cần IP công cộng |

Dòng giữa là chìa khoá của câu này — origin không cần ở AWS.

Ba lợi ích của CloudFront với nội dung động: | Lợi ích | Chi tiết | |---|---| | Kết thúc TLS ở edge | giảm vòng lượt bắt tay | | Kết nối giữ sẵn tới origin | bỏ chi phí thiết lập | | Mạng riêng của AWS cho chặng dài | ít mất gói hơn |

Ba chính sách cache dựng sẵn: | Chính sách | Việc | |---|---| | CachingOptimized | đệm tối đa, cho nội dung tĩnh | | CachingDisabled | cho nội dung động và API | | CachingOptimizedForUncompressedObjects | |

Với website động, nên tách cache behavior:

/static/*  → CachingOptimized (đệm lâu)
/*         → CachingDisabled hoặc TTL ngắn
        ↓
    Phần tĩnh hưởng lợi tối đa, phần động vẫn tươi

Ba tham số của custom origin: | Tham số | Chi tiết | |---|---| | OriginProtocolPolicy | https-only cho an toàn | | OriginSslProtocols | TLS 1.2 trở lên | | OriginReadTimeout | mặc định 30 giây |

Ba biện pháp bảo vệ origin tại chỗ: | Biện pháp | Chi tiết | |---|---| | Tường lửa chỉ cho phép prefix list CloudFront | | | Header bí mật do CloudFront thêm | origin kiểm tra | | AWS WAF trên distribution | lọc tấn công |

Thêm header bí mật:

{"OriginCustomHeaders": {"Quantity": 1, "Items": [
  {"HeaderName": "X-Origin-Verify", "HeaderValue": "<chuoi-bi-mat>"}]}}

Origin từ chối request thiếu header đó
    → kẻ tấn công không gọi thẳng origin được
        ↓
    Quan trọng vì origin tại chỗ phải có IP công cộng

Ba lưu ý về prefix list của CloudFront: | Lưu ý | Chi tiết | |---|---| | AWS công bố dải IP của CloudFront | qua ip-ranges.json | | Cập nhật định kỳ | phải theo dõi | | Header bí mật ổn định hơn | |

Ba tính năng tăng tốc nội dung động: | Tính năng | Chi tiết | |---|---| | Origin Shield | thêm lớp đệm, gộp request | | HTTP/2 và HTTP/3 | ghép nhiều request | | Nén tự động | gzip, brotli |

Ba lựa chọn khác cho người dùng toàn cầu: | Lựa chọn | Đặc điểm | |---|---| | CloudFront | ← câu này, cho HTTP | | Global Accelerator | TCP/UDP, IP tĩnh, không đệm | | Triển khai đa Region | tốn kém, chậm triển khai |

Global Accelerator cũng dùng được với origin tại chỗ:

Endpoint có thể là Elastic IP hoặc ALB
    → nhưng KHÔNG trỏ thẳng tới máy chủ tại chỗ được
        ↓
    Với website HTTP, CloudFront là lựa chọn đúng

Ba lưu ý về chứng chỉ: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ cho CloudFront phải ở us-east-1 | | | ACM cấp miễn phí | | | Origin cũng nên có chứng chỉ hợp lệ | cho https-only |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả đệm | | OriginLatency | origin tại chỗ phản hồi chậm | | 4xxErrorRate, 5xxErrorRate | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudFront tính theo GB truyền và request | | | Price class giới hạn edge để tiết kiệm | | | Băng thông của origin tại chỗ vẫn tính riêng | |

Ba bước triển khai nhanh: | Bước | Thời gian | |---|---| | Tạo distribution | vài phút | | Chờ triển khai | ~15 phút | | Đổi DNS trỏ tới CloudFront | theo TTL |

Tổng cộng chưa tới một giờ — đúng yêu cầu "within a few days".

Và một lời khuyên: hãy thêm header bí mật giữa CloudFront và origin ngay từ đầu. Origin tại chỗ phải có tên miền công khai để CloudFront gọi tới được, nghĩa là ai cũng gọi thẳng vào đó được — và header bí mật là cách đơn giản nhất để đảm bảo mọi lưu lượng thật đều đi qua CloudFront.

Câu 836 AWS Storage

A company is deploying a fleet of Amazon EC2 instances running Linux across multiple Availability Zones within an AWS Region. The application requires a data storage solution that can be accessed by all of the EC2 instances simultaneously. The solution must be highly scalable and easy to implement. The storage must be mounted using the NFS protocol.

Which solution meets these requirements?

  1. A

    Create an Amazon EFS file system with mount targets in each Availability Zone. Configure the application instances to mount the file system.
  2. B

    Create an Amazon RDS database and store the data in a BLOB format. Point the application instances to the RDS endpoint.
  3. C

    Create an Amazon EBS volume and use EBS Multi-Attach to mount the volume to all EC2 instances across each Availability Zone.
  4. D

    Create an Amazon S3 bucket and create an S3 gateway endpoint to allow access to the file system using the NFS protocol.
Xem giải thích

Đáp án

A — Tạo Amazon EFS file system với mount target ở mỗi Availability Zone, cấu hình instance mount file system đó.

Vì sao đúng

Đề nêu bốn yêu cầu, và EFS đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Nhiều EC2 truy cập ĐỒNG THỜI | EFS chia sẻ thật sự | | Trải nhiều AZ trong một Region | EFS là dịch vụ cấp Region | | Co giãn cao, dễ triển khai | tự co giãn, không cấp phát trước | | Mount bằng giao thức NFS | EFS xuất NFS v4.1 |

Vế cuối là điểm quyết định tuyệt đối:

"The storage must be mounted using the NFS protocol"
        ↓
    EFS là dịch vụ AWS DUY NHẤT xuất NFS
      cho nhiều EC2 Linux
        ↓
    Mọi phương án khác đều không phải NFS

Tạo file system và mount target:

aws efs create-file-system --performance-mode generalPurpose   --throughput-mode elastic --encrypted

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

Và mount trên instance:

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

⚠ Và mount target ở MỖI AZ là quan trọng:

Mount target là ENI trong MỘT subnet của MỘT AZ
    ↓
Instance mount vào mount target CÙNG AZ:
    → độ trễ thấp nhất
    → tên DNS TỰ CHỌN mount target cùng AZ
        ↓
    Thiếu mount target ở một AZ
    → instance ở đó phải đi chéo AZ
    → chậm hơn, và không có cảnh báo nào

Và EFS tự co giãn:

Không cấp phát dung lượng trước
    → file system lớn lên và nhỏ đi theo dữ liệu thật
        ↓
    Đúng "highly scalable and easy to implement"

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

  • **C. Tạo EBS volume và dùng Multi-Attach mount vào mọi EC2 ở các AZ — đây là phương án gần nhất vì Multi-Attach thật sự cho nhiều instance dùng chung một volume, nhưng nó sai ở hai điểm: Multi-Attach chỉ hoạt động trong CÙNG một AZ, và nó là lưu trữ khối chứ không phải NFS — cần hệ thống tệp cluster-aware, dùng ext4 hay XFS sẽ hỏng dữ liệu.
  • **D. Tạo S3 bucket và gateway endpoint để truy cập bằng NFS — S3 KHÔNG hỗ trợ NFS: nó là object storage với API HTTP. Gateway endpoint chỉ là đường đi mạng riêng tư.
  • **B. Tạo RDS và lưu dữ liệu dạng BLOB — hoàn toàn không phải hệ thống tệp, và lưu tệp trong database là mẫu thiết kế nên tránh.

Ghi nhớ

Phạm vi và khả năng chia sẻ của các loại lưu trữ — bảng phải thuộc: | Lưu trữ | Phạm vi | Chia sẻ nhiều máy | Giao thức | |---|---|---|---| | Instance store | một INSTANCE | ❌ | — | | EBS | một AZ | ❌ (trừ Multi-Attach cùng AZ) | khối | | EFS | REGION, nhiều AZ | ✅ | NFS | | FSx for Windows | Region | ✅ | SMB | | FSx for Lustre | một AZ | ✅ | Lustre | | S3 | Region | ✅ | HTTP API |

Từ khoá nhận diện:

"NFS", "Linux", "multiple AZs", "shared" → EFS "SMB", "Windows" → FSx for Windows "HPC, highest throughput" → FSx for Lustre "object storage, API" → S3

Ba đặc điểm của EFS mount target: | Đặc điểm | Chi tiết | |---|---| | MỘT mount target mỗi AZ | không tạo hai trong cùng AZ | | Là một ENI có IP riêng | gắn security group vào đây | | Tên DNS tự chọn mount target CÙNG AZ | |

Ba chế độ thông lượng của EFS: | Chế độ | Đặc điểm | |---|---| | Elastic (khuyến nghị) | tự co giãn, trả theo lượng dùng thật | | Bursting | theo dung lượng, có credit | | Provisioned | khai trước, tính phí liên tục |

Hai chế độ hiệu năng: | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | độ trễ thấp nhất | | Max I/O | thông lượng cao hơn, độ trễ cao hơn |

Ba lớp lưu trữ của EFS: | Lớp | Giá tham khảo | Số AZ | |---|---|---| | Standard | ~0,30 USD/GB | ≥3 | | Standard-IA | ~0,025 USD/GB | ≥3 | | Archive | ~0,008 USD/GB | ≥3 | | One Zone | rẻ hơn ~47% | 1 ⚠ |

Lifecycle tự phân tầng:

aws efs put-lifecycle-configuration --file-system-id fs-0abc   --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Ba cách tăng hiệu năng EFS: | Cách | Chi tiết | |---|---| | Mount target cùng AZ với instance | ← câu này | | Dùng Elastic throughput | bỏ trần theo dung lượng | | Tham số nconnect khi mount | nhiều kết nối TCP song song |

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,nconnect=16   fs-0abc.efs.ap-northeast-1.amazonaws.com:/ /du-lieu

Ba lưu ý về bảo mật EFS: | Lớp | Cơ chế | |---|---| | Mạng | security group của mount target, cổng 2049 | | Danh tính | IAM policy + file system policy | | Hệ thống tệp | quyền POSIX + Access Point |

Ba lợi ích của EFS Access Point: | Lợi ích | Chi tiết | |---|---| | Ép POSIX user | không phụ thuộc uid của client | | Ép thư mục gốc | client chỉ thấy phần của mình | | Đơn giản hoá phân quyền | |

Ba lưu ý khi mount: | Lưu ý | Chi tiết | |---|---| | Cài amazon-efs-utils | để dùng -t efs với TLS và IAM | | Thêm vào /etc/fstab với _netdev | mount lại sau khởi động | | Mở cổng 2049 trong security group | |

fs-0abc:/ /du-lieu efs _netdev,tls,iam 0 0

Ba lưu ý về EBS Multi-Attach (để phân biệt): | Lưu ý | Chi tiết | |---|---| | Chỉ io1 và io2 | | | Tối đa 16 instance CÙNG AZ | | | Cần hệ thống tệp CLUSTER-AWARE | ext4 và XFS sẽ HỎNG dữ liệu |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PercentIOLimit | gần 100% = chạm trần chế độ hiệu năng | | MeteredIOBytes | thông lượng thực tế | | ClientConnections | số máy đang mount |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Truyền dữ liệu chéo AZ với EFS MIỄN PHÍ | khác EC2 chéo AZ | | Nhưng độ trễ vẫn cao hơn | ← lý do vẫn nên cùng AZ | | Lifecycle sang IA giảm ~90% | |

Và một lời khuyên: hãy tạo mount target ở mọi AZ mà bạn có instance, kể cả khi chỉ có một máy ở đó. Thiếu mount target không gây lỗi — EFS vẫn hoạt động qua AZ khác, chỉ chậm hơn — và đó là loại suy giảm hiệu năng không có cảnh báo nào chỉ ra.

Câu 837 AWS Database

An application is being created that will use Amazon EC2 instances to generate and store data. Another set of EC2 instances will then analyze and modify the data. Storage requirements will be significant and will continue to grow over time. The application architects require a storage solution.

Which actions would meet these needs?

  1. A

    Store the data in an Amazon EFS filesystem. Mount the file system on the application instances
  2. B

    Store the data in an Amazon EBS volume. Mount the EBS volume on the application instances
  3. C

    Store the data in Amazon S3 Glacier. Update the vault policy to allow access to the application instances
  4. D

    Store the data in AWS Storage Gateway. Setup AWS Direct Connect between the Gateway appliance and the EC2 instances
Xem giải thích

Đáp án

A — Lưu dữ liệu trong Amazon EFS file system, mount file system đó lên các instance ứng dụng.

Vì sao đúng

Đề nêu ba yêu cầu, và EFS đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | HAI nhóm instance cùng truy cập dữ liệu | EFS chia sẻ được | | Nhóm thứ hai SỬA dữ liệu | EFS cho ghi tại chỗ (POSIX) | | Dung lượng lớn và TIẾP TỤC TĂNG | EFS tự co giãn, không giới hạn |

Vế thứ hai đáng chú ý:

"analyze and MODIFY the data"
        ↓
    Sửa dữ liệu tại chỗ cần ngữ nghĩa POSIX
    → mở tệp, ghi vào giữa, khoá vùng
        ↓
    S3 KHÔNG sửa tại chỗ được (phải ghi lại cả object)
    → EFS làm được

Và vế thứ ba loại EBS:

"Storage requirements will be SIGNIFICANT and CONTINUE TO GROW"
        ↓
    EBS: phải cấp phát trước và mở rộng thủ công
    EFS: tự co giãn tới petabyte, không cần làm gì

Triển khai:

aws efs create-file-system --throughput-mode elastic --encrypted

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

Và cả hai nhóm instance mount cùng file system:

# Trên nhóm sinh dữ liệu
sudo mount -t efs -o tls fs-0abc:/ /du-lieu

# Trên nhóm phân tích — cùng lệnh
sudo mount -t efs -o tls fs-0abc:/ /du-lieu

Và nên dùng Access Point tách hai vai trò:

aws efs create-access-point --file-system-id fs-0abc   --posix-user Uid=1001,Gid=1001   --root-directory 'Path=/du-lieu-tho,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=0755}'

Nhóm sinh dữ liệu: access point ghi vào /du-lieu-tho
Nhóm phân tích:    access point đọc và ghi vào /ket-qua
        ↓
    Phân quyền rõ ràng mà vẫn dùng chung file system

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

  • **B. Lưu trong EBS volume và mount lên các instance — đây là phương án gần nhất vì EBS cũng là lưu trữ bền vững gắn vào EC2, nhưng nó không chia sẻ được giữa nhiều instance: một EBS volume gắn vào một instance (trừ Multi-Attach io1/io2 cùng AZ, cần hệ thống tệp cluster-aware). Và phải cấp phát dung lượng trước.
  • **C. Lưu trong S3 Glacier và cập nhật vault policy — Glacier dành cho LƯU TRỮ DÀI HẠN: mất phút tới giờ để lấy dữ liệu, hoàn toàn không phù hợp cho việc xử lý đang diễn ra.
  • **D. Lưu trong Storage Gateway và dựng Direct Connect giữa gateway và EC2 — hiểu sai kiến trúc: Storage Gateway là cầu nối cho ứng dụng tại chỗ, và Direct Connect nối on-premises với AWS. Cả hai đều đã ở trong AWS.

Ghi nhớ

Câu hỏi quyết định giữa EFS, EBS và S3: | Câu hỏi | Nếu "có" | |---|---| | Nhiều instance cùng truy cập? | EFS (hoặc S3) | | Cần SỬA tại chỗ, khoá tệp, POSIX? | EFS | | Chỉ đọc ghi cả tệp, sửa được mã? | S3 (rẻ hơn nhiều) | | Một instance, hiệu năng khối cao? | EBS |

Bảng so sánh ba lựa chọn: | | EBS | EFS | S3 | |---|---|---|---| | Chia sẻ nhiều máy | ❌ | ✅ | ✅ | | Phạm vi | một AZ | Region | Region | | Tự co giãn | ❌ | ✅ | ✅ | | Sửa tại chỗ | ✅ | ✅ | ❌ | | Giá tham khảo | ~0,08 USD/GB | ~0,30 USD/GB | ~0,023 USD/GB |

S3 rẻ hơn EFS khoảng 13 lần — nếu sửa được ứng dụng, đó là lựa chọn kinh tế hơn.

Ba chế độ thông lượng của EFS: | Chế độ | Đặc điểm | |---|---| | Elastic (khuyến nghị) | tự co giãn, trả theo lượng dùng | | Bursting | theo dung lượng, có credit | | Provisioned | khai trước |

Elastic phù hợp với tải xử lý theo đợt:

Nhàn rỗi phần lớn thời gian, bùng phát khi phân tích
    → Elastic trả theo lượng đọc ghi thật
        ↓
    Provisioned sẽ tính phí đủ 24/7

Ba lớp lưu trữ của EFS: | Lớp | Giá tham khảo | Phí truy xuất | |---|---|---| | Standard | ~0,30 USD/GB | ❌ | | Standard-IA | ~0,025 USD/GB | ✅ | | Archive | ~0,008 USD/GB | ✅ cao hơn |

Lifecycle giảm chi phí đáng kể:

[{"TransitionToIA":"AFTER_30_DAYS"},
 {"TransitionToArchive":"AFTER_90_DAYS"},
 {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]

Ba lợi ích của EFS Access Point: | Lợi ích | Chi tiết | |---|---| | Ép POSIX user và group | | | Ép thư mục gốc | cách ly từng ứng dụng | | Đơn giản hoá quyền | |

Ba cách tăng hiệu năng EFS: | Cách | Chi tiết | |---|---| | Mount target cùng AZ | giảm độ trễ | | Elastic throughput | bỏ trần | | nconnect=16 khi mount | nhiều kết nối song song |

Ba lưu ý khi nhiều máy cùng ghi: | Lưu ý | Chi tiết | |---|---| | EFS hỗ trợ khoá tệp NFS | tránh ghi đè lẫn nhau | | Thiết kế để mỗi máy ghi vùng riêng | an toàn hơn | | Cân nhắc hàng đợi điều phối công việc | |

Dòng giữa là mẫu tốt:

Nhóm sinh dữ liệu: ghi vào /du-lieu-tho/<id>/
Nhóm phân tích:    đọc từ đó, ghi vào /ket-qua/<id>/
        ↓
    Không hai máy nào ghi cùng tệp
    → không cần khoá, không có xung đột

Ba lựa chọn nếu bỏ được ràng buộc POSIX: | Lựa chọn | Chi tiết | |---|---| | S3 | rẻ nhất, cần sửa mã | | FSx for Lustre liên kết S3 | kết hợp cả hai | | Mountpoint for S3 | POSIX một phần |

FSx for Lustre đáng cân nhắc cho tải phân tích:

Dữ liệu gốc ở S3 (rẻ)
    → dựng Lustre khi cần chạy phân tích
    → thông lượng cực cao
    → xoá cụm sau khi xong
        ↓
    Nhưng chỉ một AZ, và phức tạp hơn EFS

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PercentIOLimit | chạm trần chế độ hiệu năng | | MeteredIOBytes | thông lượng | | StorageBytes theo lớp | phân bố lưu trữ |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest bật LÚC TẠO | | | Mã hoá in transit qua tuỳ chọn tls | | | File system policy giới hạn truy cập | |

Và một lời khuyên: hãy bật lifecycle chuyển sang IA ngay khi tạo file system. Với dữ liệu "tiếp tục tăng" theo thời gian, phần lớn dung lượng sau vài tháng sẽ là dữ liệu cũ không ai đọc — và chênh lệch giữa Standard với IA là hơn mười lần, đủ để quyết định EFS có phải lựa chọn kinh tế hay không.

Câu 838 AWS Management & Governance

A company is launching a new internal platform for managing multiple independent projects. Each project will require its own dedicated AWS account for isolation. The company needs a solution that automates account creation, applies mandatory security guardrails, and centrally manages shared networking resources such as VPNs and subnets for the accounts. The solution must minimize manual effort and ensure compliance with security standards.

Which solution will meet these requirements with the LEAST operational overhead?

  1. A

    Use AWS Control Tower to automate account provisioning. Create a dedicated networking account with a centralized VPC. Use AWS Resource Access Manager (AWS RAM) to share subnets with project accounts. Enforce security guardrails by using AWS Control Tower guardrails.
  2. B

    Use AWS Organizations to create accounts for each project. Deploy a shared VPC in a centralized account. Configure AWS Firewall Manager to enforce security controls. Manually configure routing for project account traffic through the shared VPC.
  3. C

    Use AWS Control Tower to set up accounts with pre-configured VPCs in each project account. Connect these VPCs to a central networking account through a transit gateway. Enforce security controls with AWS Config.
  4. D

    Use AWS Organizations to create project accounts manually. Deploy a VPC in a centralized networking account. Use AWS RAM to share subnets. Manually configure security policies in each account.
Xem giải thích

Đáp án

A — Dùng AWS Control Tower tự động tạo tài khoản; tạo tài khoản mạng riêng với VPC tập trung; dùng AWS RAM chia sẻ subnet cho các tài khoản dự án; áp Control Tower guardrail cho bảo mật.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án A đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Tự động tạo tài khoản | Control Tower Account Factory | | Áp guardrail bảo mật bắt buộc | Control Tower control | | Quản lý mạng dùng chung tập trung | VPC chung + RAM | | Ít công vận hành nhất | tất cả đều tự động |

VPC dùng chung là điểm mấu chốt của vế "centrally manages shared networking":

Mỗi tài khoản một VPC riêng:
    → lặp lại subnet, NAT Gateway, VPN, route table
    → mỗi VPC cần NAT riêng (~32 USD/tháng)
    → phải nối chúng với nhau

VPC dùng chung qua RAM:
    → MỘT VPC ở tài khoản mạng
    → chia subnet cho các tài khoản dự án
        ↓
    Một bộ NAT, một bộ VPN, một bộ route table

Chia sẻ subnet:

aws ram create-resource-share --name chia-se-subnet   --resource-arns arn:aws:ec2:ap-northeast-1:111111111111:subnet/subnet-a                   arn:aws:ec2:ap-northeast-1:111111111111:subnet/subnet-c   --principals arn:aws:organizations::111111111111:ou/o-abc/ou-du-an

Và mô hình quyền rõ ràng: | Vai trò | Quyền | |---|---| | Tài khoản chủ VPC | quản lý VPC, subnet, route table, VPN | | Tài khoản dự án | tạo EC2, RDS, ALB TRONG subnet được chia | | — | tài khoản dự án KHÔNG sửa được cấu hình mạng |

Và Control Tower lo phần guardrail tự động:

Khi tạo tài khoản mới, Control Tower TỰ:
    ✓ bật CloudTrail tổ chức
    ✓ bật AWS Config
    ✓ gửi log về tài khoản Log Archive
    ✓ áp control đã chọn cho OU
        ↓
    Không phải nhớ làm gì thủ công

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

  • **B. Dùng AWS Organizations tạo tài khoản, VPC chung, Firewall Manager, và cấu hình định tuyến THỦ CÔNG — đây là phương án gần nhất và kiến trúc mạng đúng, nhưng nó thiếu tự động hoá quản trị: Organizations không tự thiết lập CloudTrail, Config và log tập trung cho tài khoản mới. Và "manually configure routing" đi ngược yêu cầu.
  • **C. Control Tower với VPC RIÊNG ở mỗi tài khoản nối qua Transit Gateway — lặp lại hạ tầng mạng, đúng điều đề muốn tránh. Và thêm phí attachment TGW cho mỗi VPC.
  • **D. Tạo tài khoản THỦ CÔNG và cấu hình chính sách bảo mật thủ công ở mỗi tài khoản — công vận hành cao nhất.

Ghi nhớ

Ba dịch vụ quản trị đa tài khoản — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS Organizations | nền tảng: tài khoản, OU, SCP, hoá đơn gộp | | AWS Control Tower | landing zone TỰ ĐỘNG trên Organizations | | AWS RAM | chia sẻ TÀI NGUYÊN giữa các tài khoản |

Organizations và Control Tower — bảng phân biệt: | | Organizations | Control Tower | |---|---|---| | Tạo tài khoản | ✅ | ✅ Account Factory | | SCP | ✅ | ✅ (gọi là control) | | Tự bật CloudTrail, Config | ❌ | ✅ | | Log tập trung | ❌ | ✅ Log Archive account | | Bảng điều khiển tuân thủ | ❌ | ✅ |

Control Tower là Organizations cộng tự động hoá.

Ba tài khoản Control Tower tạo sẵn: | Tài khoản | Việc | |---|---| | Management | quản lý tổ chức | | Log Archive | lưu log của MỌI tài khoản | | Audit | truy cập chỉ đọc cho kiểm toán |

Ba loại control (guardrail): | Loại | Cơ chế | |---|---| | Preventive | SCP — CHẶN hành động | | Detective | Config rule — PHÁT HIỆN vi phạm | | Proactive | CloudFormation hook |

Ba mức bắt buộc: | Mức | Chi tiết | |---|---| | Mandatory | luôn bật | | Strongly recommended | nên bật | | Elective | tuỳ chọn |

Ba tài nguyên chia sẻ được qua RAM: | Tài nguyên | Chi tiết | |---|---| | VPC subnet | ← câu này | | Transit Gateway | | | Route 53 Resolver rule | | | License Manager, Aurora cluster, ACM Private CA | |

Ba lưu ý về VPC sharing: | Lưu ý | Chi tiết | |---|---| | Tài khoản tham gia KHÔNG sửa được VPC | chỉ dùng subnet | | Security group tạo trong tài khoản tham gia | thuộc VPC chung | | Flow log, NAT, VPN do chủ VPC quản lý | |

Ba mô hình mạng đa tài khoản: | Mô hình | Đặc điểm | |---|---| | VPC dùng chung (RAM) | ít hạ tầng lặp nhất, rẻ nhất ← câu này | | VPC riêng + Transit Gateway | cách ly mạnh hơn, phức tạp hơn | | VPC riêng + peering | không mở rộng được |

Chọn giữa hai mô hình đầu:

VPC dùng chung:
    ✓ một bộ NAT, VPN, endpoint
    ✓ rẻ nhất
    ✗ cách ly mạng yếu hơn (cùng một VPC)

VPC riêng + TGW:
    ✓ cách ly rõ ràng
    ✗ mỗi VPC cần NAT và endpoint riêng
    ✗ ~36 USD/tháng mỗi attachment

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Control Tower | miễn phí, chỉ trả dịch vụ bên dưới | | RAM | miễn phí | | Config và CloudTrail | có phí, tăng theo số tài khoản |

Ba việc Control Tower làm khi tạo tài khoản: | Việc | Chi tiết | |---|---| | Đưa vào OU đã chọn | kế thừa control | | Bật CloudTrail và Config | gửi log tập trung | | Tạo permission set trong IAM Identity Center | |

Ba lưu ý về cấu trúc OU: | Lưu ý | Chi tiết | |---|---| | Nhóm theo môi trường hoặc chức năng | | | SCP áp ở cấp OU | | | Tài khoản Management KHÔNG bị SCP ràng buộc | |

Dòng cuối là lý do không chạy tải trong tài khoản quản lý.

Ba việc nên làm khi thiết lập: | Việc | Chi tiết | |---|---| | Quy hoạch dải CIDR trước | tránh chồng lấn | | Thiết kế OU trước khi tạo tài khoản | | | Bắt đầu với ít control, mở rộng dần | |

Ba lưu ý về Account Factory: | Lưu ý | Chi tiết | |---|---| | Tạo tài khoản qua Service Catalog | | | Account Factory for Terraform (AFT) | cho đội dùng IaC | | Tuỳ chỉnh bằng Customizations for Control Tower | |

Và một lời khuyên: hãy quy hoạch dải CIDR cho toàn tổ chức trước khi tạo VPC đầu tiên. Dù chọn VPC dùng chung hay Transit Gateway, chồng lấn địa chỉ là thứ không sửa được mà không dựng lại — và nó chỉ lộ ra khi bạn cần nối hai mạng, tức là rất lâu sau khi quyết định ban đầu đã bị quên.

Câu 839 AWS Application Integration

A logistics company processes real-time sensor data from delivery vehicles to optimize routes and track vehicle health. The current architecture includes an Auto Scaling group of Amazon EC2 instances for ingesting and storing sensor data, and a separate Auto Scaling group for analyzing and generating route optimizations based on this data.

The company has observed performance issues during peak delivery hours when the rate of data ingestion is significantly higher than the analysis and processing rate. The company wants to ensure that both systems can scale independently, and no data is lost during scaling events.

Which solution will meet these requirements?

  1. A

    Use two Amazon SQS queues: one for data ingestion and one for route analysis. Configure Amazon EventBridge rules to monitor queue length and scale each Auto Scaling group based on the backlog of messages in their respective queues.
  2. B

    Replace the EC2-based Auto Scaling groups with AWS Lambda functions to process the incoming data and analysis tasks. Use Amazon DynamoDB to store the intermediate data and scale DynamoDB based on the traffic patterns.
  3. C

    Use two Amazon Simple Queue Service (Amazon SQS) queues: one for data ingestion and one for route analysis. Configure the EC2 instances to poll their respective queues and scale the Auto Scaling groups based on the ApproximateNumberOfMessages metric in each queue.
  4. D

    Use Amazon Kinesis Data Streams to buffer the sensor data. Configure Amazon Kinesis Data Analytics to process the data and adjust the number of EC2 instances in the analysis Auto Scaling group based on the volume of data being processed.
Xem giải thích

Đáp án

C — Dùng hai hàng đợi SQS (một cho nạp dữ liệu, một cho phân tích); EC2 lấy việc từ hàng đợi tương ứng và co giãn ASG theo metric ApproximateNumberOfMessages của mỗi hàng đợi.

Vì sao đúng

Đề nêu ba vấn đề, và phương án C giải quyết cả ba: | Vấn đề | Cơ chế | |---|---| | Tốc độ nạp cao hơn tốc độ phân tích | hàng đợi ĐỆM phần chênh lệch | | Hai hệ thống phải co giãn ĐỘC LẬP | hai hàng đợi, hai chính sách co giãn | | KHÔNG mất dữ liệu khi co giãn | SQS giữ thông điệp tới khi xử lý xong |

Vì sao phải hai hàng đợi:

Nạp dữ liệu: nhanh
Phân tích:   chậm
        ↓
    Hai tốc độ khác nhau → hai độ sâu hàng đợi khác nhau
    → hai chính sách co giãn khác nhau
        ↓
    Một hàng đợi chung không phân biệt được
      việc nào thuộc giai đoạn nào

Và SQS bảo vệ dữ liệu khi co giãn:

Instance bị chấm dứt giữa lúc xử lý:
    → thông điệp KHÔNG bị xoá (chỉ xoá sau khi xong)
    → hết visibility timeout → thông điệp HIỆN LẠI
    → instance khác nhận và làm lại
        ↓
    Đúng "no data is lost during scaling events"

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

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-phan-tich   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 20,
    "CustomizedMetricSpecification": {
      "MetricName":"ApproximateNumberOfMessagesVisible",
      "Namespace":"AWS/SQS","Statistic":"Average",
      "Dimensions":[{"Name":"QueueName","Value":"hang-doi-phan-tich"}]}}'

Và metric tốt hơn nữa là "tồn đọng trên mỗi instance":

Backlog per instance = số thông điệp ÷ số instance
Mục tiêu = (thời gian chờ chấp nhận được) ÷ (thời gian xử lý mỗi việc)

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

  • **A. Hai hàng đợi SQS nhưng dùng EventBridge rule theo dõi độ dài hàng đợi để co giãn — đây là phương án gần nhất và kiến trúc hàng đợi hoàn toàn đúng, nhưng nó sai ở cơ chế co giãn: EventBridge phản ứng với sự kiện, còn độ dài hàng đợi là metric CloudWatch. Auto Scaling đọc metric trực tiếp, không cần EventBridge làm trung gian.
  • **D. Dùng Kinesis Data Streams đệm và Kinesis Data Analytics xử lý — đổi kiến trúc lớn và không tách được hai giai đoạn: Kinesis phù hợp cho luồng nhiều consumer, nhưng ở đây bài toán là hàng đợi công việc với hai tốc độ khác nhau.
  • **B. Thay ASG bằng Lambda và lưu trung gian vào DynamoDB — có thể vướng giới hạn 15 phút với việc phân tích, và tái cấu trúc lớn hơn cần thiết.

Ghi nhớ

Ba lợi ích của việc tách rời bằng SQS: | Lợi ích | Chi tiết | |---|---| | Đệm khi tải tăng đột ngột | producer không bị chặn | | KHÔNG mất việc khi consumer hỏng | ← yêu cầu của đề | | Hai bên co giãn ĐỘC LẬP | |

Ba metric của SQS để co giãn: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | ApproximateAgeOfOldestMessage | chỉ báo trải nghiệm tốt nhất | | ApproximateNumberOfMessagesNotVisible | đang xử lý |

Công thức backlog per instance của AWS:

Mục tiêu = (thời gian chấp nhận được) ÷ (thời gian xử lý mỗi việc)

Chấp nhận chờ 10 phút, mỗi việc 30 giây
    → 600 ÷ 30 = 20 việc mỗi instance

Ba cách kích hoạt co giãn — bảng phân biệt: | Cách | Cơ chế | |---|---| | Target tracking trên metric CloudWatch | Auto Scaling đọc metric trực tiếp | | Step scaling với CloudWatch alarm | alarm kích hoạt policy | | EventBridge + Lambda | cho SỰ KIỆN, không cho metric |

Dòng cuối là điểm phương án A hiểu sai.

Ba thông số SQS quan trọng: | Thông số | Chi tiết | |---|---| | Visibility timeout ≥ thời gian xử lý | tránh xử lý trùng | | Message retention 60 giây – 14 ngày | | | Long polling 20 giây | giảm chi phí API |

Visibility timeout sai gây xử lý trùng:

Xử lý mất 10 phút, visibility timeout 30 giây
    → thông điệp hiện lại sau 30 giây
    → instance khác nhận và làm lại
        ↓
    Cùng một việc xử lý nhiều lần

Gia hạn cho việc chạy lâu:

while dang_xu_ly:
    sqs.change_message_visibility(
        QueueUrl=url, ReceiptHandle=rh, VisibilityTimeout=600)
    time.sleep(500)

Ba cấu hình ASG cho consumer: | Cấu hình | Chi tiết | |---|---| | Lifecycle hook TERMINATING | hoàn tất việc trước khi tắt | | Instance scale-in protection | không tắt máy đang bận | | EstimatedInstanceWarmup | tránh mở rộng quá mức |

Lifecycle hook giải quyết đúng nỗi lo của đề:

aws autoscaling put-lifecycle-hook   --auto-scaling-group-name asg-phan-tich   --lifecycle-hook-name cho-xong-viec   --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING   --heartbeat-timeout 600

Instance nhận tín hiệu sắp bị chấm dứt
    → ngừng lấy việc mới, hoàn tất việc đang làm
    → gọi complete-lifecycle-action
        ↓
    KHÔNG có việc nào bị bỏ dở

Ba yêu cầu với consumer: | Yêu cầu | Chi tiết | |---|---| | IDEMPOTENT | SQS Standard giao ít nhất một lần | | Chỉ xoá SAU KHI xong | | | DLQ cho thông điệp hỏng | |

Hai loại hàng đợi SQS: | | Standard | FIFO | |---|---|---| | Thông lượng | gần như vô hạn | 300/3.000 msg/giây | | Thứ tự | không đảm bảo | trong message group | | Trùng lặp | có thể | đúng một lần |

Ba lựa chọn thay thế cho ASG: | Lựa chọn | Đặc điểm | |---|---| | Lambda đọc từ SQS | tự co giãn, giới hạn 15 phút | | AWS Batch | tự quản hàng đợi và năng lực | | ECS/Fargate co giãn theo SQS | container |

Ba cách giảm chi phí: | Cách | Tiết kiệm | |---|---| | Spot cho tầng phân tích | việc trong SQS không mất | | Graviton | ~20% | | Long polling | giảm số request |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | việc chờ lâu nhất | | GroupInServiceInstances | số máy phục vụ | | Số thông điệp trong DLQ | có lỗi |

Ba lưu ý về DLQ: | Lưu ý | Chi tiết | |---|---| | maxReceiveCount 3–5 | | | DLQ giữ lâu hơn hàng đợi chính | | | ĐẶT ALARM cho DLQ | không có alarm thì DLQ vô dụng |

Và một lời khuyên: hãy thêm lifecycle hook TERMINATING cho cả hai Auto Scaling group. Đề nêu rõ nỗi lo mất dữ liệu khi co giãn — và tuy SQS đã bảo vệ bằng visibility timeout, lifecycle hook loại bỏ hẳn việc phải xử lý lại một công việc dài chỉ vì ASG quyết định thu hẹp đúng lúc đó.

Câu 840 AWS Application Integration

A company is launching a new photo processing service that uses machine learning (ML) models to analyze and tag images. The service consists of independent microservices for different types of image processing tasks. Each ML model loads approximately 500 MB of data from Amazon S3 into memory at startup.
Users will submit images through a RESTful API, which can handle individual or batch requests. Traffic patterns are unpredictable, with peaks during marketing campaigns and minimal usage during off-hours. The company needs a scalable and cost-effective solution to manage this workload.

Which solution will meet these requirements?

  1. A

    Send the API requests to an Amazon EventBridge bus. Deploy the ML models as AWS Lambda functions that EventBridge invokes. Use auto scaling to increase memory and concurrency based on the size of the event payloads.
  2. B

    Route the API requests to an Application Load Balancer (ALB). Deploy the ML models as AWS Lambda functions. Use provisioned concurrency to ensure Lambda functions remain warm for high-performance batch processing.
  3. C

    Send the API requests to an Amazon Simple Queue Service (Amazon SQS) queue. Deploy the ML models as Amazon Elastic Container Service (Amazon ECS) services that read messages from the queue. Use auto scaling for ECS to adjust capacity based on queue length.
  4. D

    Route the API requests to a Network Load Balancer (NLB). Deploy the ML models as Amazon Elastic Kubernetes Service (Amazon EKS) pods. Configure auto scaling based on CPU usage for EKS nodes.
Xem giải thích

Đáp án

C — Gửi request tới hàng đợi SQS; triển khai mô hình học máy dưới dạng dịch vụ ECS đọc từ hàng đợi; auto scaling ECS theo độ dài hàng đợi.

Vì sao đúng

Đề cho một con số quyết định: mỗi mô hình nạp khoảng 500 MB dữ liệu vào bộ nhớ lúc khởi động.

500 MB nạp lúc khởi động
    → với Lambda, đó là CHI PHÍ CỦA MỖI COLD START
    → mỗi lần Lambda mở rộng lại phải nạp lại
        ↓
    Container ECS nạp MỘT LẦN rồi phục vụ nhiều request
    → chi phí nạp được khấu hao

Và tải không đoán trước là lý do cần hàng đợi:

"Traffic patterns are unpredictable, with PEAKS during
 marketing campaigns and MINIMAL usage during off-hours"
        ↓
    SQS đệm đỉnh tải
    → ECS xử lý theo nhịp của nó
    → không mất request nào

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

aws application-autoscaling put-scaling-policy   --service-namespace ecs   --resource-id service/cum-ml/dich-vu-gan-nhan   --scalable-dimension ecs:service:DesiredCount   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 10,
    "CustomizedMetricSpecification": {
      "MetricName":"ApproximateNumberOfMessagesVisible",
      "Namespace":"AWS/SQS","Statistic":"Average",
      "Dimensions":[{"Name":"QueueName","Value":"hang-doi-anh"}]}}'

Và mỗi microservice một hàng đợi và một dịch vụ ECS:

"independent microservices for different types of
 image processing tasks"
        ↓
    Mỗi loại xử lý: một hàng đợi + một ECS service
    → co giãn độc lập theo nhu cầu riêng

Và SQS hỗ trợ cả request đơn lẫn theo lô:

API nhận batch → gửi nhiều thông điệp vào hàng đợi
    → ECS xử lý song song
        ↓
    Không có giới hạn thời gian nào

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

  • **B. Định tuyến qua ALB tới Lambda với provisioned concurrency giữ hàm ấm — đây là phương án gần nhất và provisioned concurrency thật sự giải quyết cold start, nhưng nó tốn kém và không phù hợp với tải rất không đều: bạn phải trả tiền giữ ấm suốt cả giờ thấp điểm, mà đề nói rõ có "minimal usage during off-hours". Và 500 MB mô hình vượt xa mức hợp lý cho Lambda.
  • **A. Gửi request tới EventBridge bus rồi Lambda, "auto scaling tăng bộ nhớ theo kích thước payload" — không làm được như mô tả: Lambda không tự tăng bộ nhớ theo payload; cấu hình bộ nhớ là cố định cho mỗi phiên bản hàm.
  • **D. Định tuyến qua NLB tới EKS pod, co giãn theo CPU của node — hai vấn đề: không có hàng đợi nên đỉnh tải dồn thẳng vào pod, và co giãn theo CPU của node phản ứng chậm hơn theo độ dài hàng đợi.

Ghi nhớ

Ba lựa chọn tính toán cho mô hình học máy — bảng phải thuộc: | Lựa chọn | Phù hợp | |---|---| | Lambda | mô hình NHỎ, tải đều, dưới 15 phút | | ECS/Fargate | mô hình LỚN, nạp một lần rồi phục vụ nhiều | | SageMaker endpoint | suy luận được quản lý, có auto scaling |

SageMaker đáng cân nhắc mạnh:

SageMaker real-time endpoint:
    ✓ được quản lý hoàn toàn
    ✓ auto scaling dựng sẵn
    ✓ multi-model endpoint: nhiều mô hình một endpoint
        ↓
    SageMaker Serverless Inference cũng có
    → nhưng vẫn vướng cold start với mô hình lớn

Ba vấn đề của Lambda với mô hình lớn: | Vấn đề | Chi tiết | |---|---| | Cold start nạp 500 MB mỗi lần | vài giây tới chục giây | | Giới hạn gói triển khai | 250 MB ZIP, 10 GB container | | Bộ nhớ tối đa 10 GB | |

Ba cách giảm cold start của Lambda: | Cách | Chi tiết | |---|---| | Provisioned concurrency | giữ ấm — CÓ PHÍ liên tục | | SnapStart | chỉ Java, .NET, Python | | Giảm kích thước gói | |

Provisioned concurrency đắt với tải không đều:

Giữ ấm 20 instance suốt 24 giờ
    → trả tiền cả những giờ không ai dùng
        ↓
    Với "minimal usage during off-hours", đó là lãng phí lớn

Ba mẫu kiến trúc xử lý bất đồng bộ: | Mẫu | Chi tiết | |---|---| | API Gateway → SQS → worker | đệm, chịu đỉnh tải ← câu này | | API Gateway → Lambda | đồng bộ, đơn giản | | API Gateway → Step Functions | luồng nhiều bước |

API Gateway tích hợp thẳng với SQS:

aws apigateway put-integration --rest-api-id abc --resource-id res   --http-method POST --type AWS --integration-http-method POST   --uri "arn:aws:apigateway:ap-northeast-1:sqs:path/123456789012/hang-doi-anh"   --credentials <arn-role>

Không cần Lambda trung gian — ít một tầng, rẻ hơn.

Ba metric để co giãn ECS: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | ApproximateAgeOfOldestMessage | trải nghiệm | | CPU và bộ nhớ của service | phản ứng chậm hơn |

Ba lựa chọn năng lực cho ECS: | Lựa chọn | Đặc điểm | |---|---| | Fargate | không quản node | | Fargate Spot | rẻ hơn ~70% | | EC2 launch type | kiểm soát instance, dùng GPU được |

Fargate Spot rất phù hợp:

{"capacityProviderStrategy": [
  {"capacityProvider": "FARGATE", "base": 1, "weight": 1},
  {"capacityProvider": "FARGATE_SPOT", "weight": 4}]}

Task bị thu hồi giữa lúc xử lý
    → thông điệp quay lại hàng đợi
    → task khác nhận và làm lại
        ↓
    Không mất ảnh nào

Ba lưu ý về task definition cho mô hình học máy: | Lưu ý | Chi tiết | |---|---| | Bộ nhớ đủ cho mô hình 500 MB cộng biên | ít nhất 2–4 GB | | Ephemeral storage cho ảnh tạm | tới 200 GB | | Image trong ECR, tối ưu kích thước | |

Ba lưu ý về SQS trong kiến trúc này: | Lưu ý | Chi tiết | |---|---| | Ảnh ở S3, chỉ gửi khoá qua SQS | thông điệp tối đa 256 KB | | Visibility timeout ≥ thời gian xử lý | | | DLQ cho ảnh xử lý lỗi | |

Ba cách trả kết quả về cho người dùng: | Cách | Chi tiết | |---|---| | Ghi kết quả vào DynamoDB, client polling | đơn giản | | WebSocket qua API Gateway | thời gian thực | | SNS gửi thông báo khi xong | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Fargate theo vCPU-giây và GB-giây | | | SQS ~0,40 USD mỗi triệu request | | | Đặt MinCapacity thấp cho giờ thấp điểm | |

Ba lựa chọn nếu mô hình cần GPU: | Lựa chọn | Chi tiết | |---|---| | ECS trên EC2 với instance GPU | Fargate KHÔNG có GPU | | SageMaker endpoint với instance GPU | | | AWS Batch với GPU | cho xử lý theo lô |

Và một lời khuyên: hãy đánh giá SageMaker multi-model endpoint nếu có nhiều mô hình khác nhau. Nó nạp và giải phóng mô hình theo nhu cầu trên cùng một endpoint — giải quyết đúng bài toán "nhiều microservice, mỗi cái một mô hình 500 MB" mà không cần chạy một dịch vụ riêng cho từng loại.