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

Tìm thấy 2194 câu.

Câu 631 Design Cost-Optimized Architectures

A streaming media company operates a high-traffic content delivery platform on AWS. The application backend is deployed on Amazon EC2 instances within an Auto Scaling group across multiple Availability Zones in a VPC. The team has observed that workloads follow predictable usage patterns, such as higher viewership on weekends and in the evenings, along with occasional real-time spikes due to viral content. To reduce cost and improve responsiveness, the team wants an automated scaling approach that can forecast future demand using historical usage patterns, scale in advance based on those predictions, and react quickly to unplanned usage surges in real time.

Which scaling strategy should a solutions architect recommend to meet these requirements?

  1. A

    Implement scheduled scaling actions based on pre-defined time windows from historical traffic data. Adjust instance count manually for known high-traffic hours
  2. B

    Set up simple scaling policies with longer cooldown periods to avoid rapid scaling. Trigger scale-out events based on average network throughput
  3. C

    Use predictive scaling for the Auto Scaling group to analyze daily and weekly patterns, and configure dynamic scaling with target tracking policies to respond to real-time traffic changes
  4. D

    Configure step scaling policies based on EC2 CPU utilization. Use CloudWatch alarms to trigger scaling actions when utilization crosses defined thresholds with incremental adjustments
Xem giải thích

Đáp án

C — Dùng predictive scaling cho Auto Scaling group để phân tích mẫu theo ngày và tuần, kết hợp với dynamic scaling bằng target tracking để phản ứng với thay đổi lưu lượng thời gian thực.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ kết hợp hai loại policy mới đáp ứng đủ: | Yêu cầu | Cơ chế | |---|---| | DỰ BÁO nhu cầu tương lai từ dữ liệu lịch sử | predictive scaling — học máy | | Mở rộng TRƯỚC dựa trên dự báo | predictive scaling | | Phản ứng NHANH với đỉnh tải không đoán trước | target tracking |

Predictive scaling giải quyết vế "dự báo":

Predictive scaling:
    → phân tích tối thiểu 24 giờ (tốt nhất 14 ngày) dữ liệu lịch sử
    → dùng học máy phát hiện mẫu theo NGÀY và TUẦN
    → dự báo tải cho 48 giờ tới
    → MỞ RỘNG TRƯỚC khi tải đến
        ↓
    Đúng "higher viewership on weekends and evenings"

Và target tracking giải quyết vế "nội dung lan truyền":

Nội dung bất ngờ lan truyền:
    → không có trong dữ liệu lịch sử
    → predictive scaling không dự báo được
        ↓
    Target tracking phản ứng theo metric thật

Hai loại này được thiết kế để dùng CÙNG NHAU:

Predictive scaling đặt SÀN dung lượng theo dự báo
    → target tracking điều chỉnh THÊM khi tải vượt dự báo
        ↓
    AWS khuyến nghị chính xác cách kết hợp này

Bật predictive scaling:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-streaming   --policy-name du-bao-tai --policy-type PredictiveScaling   --predictive-scaling-configuration '{
    "MetricSpecifications": [{
      "TargetValue": 60,
      "PredefinedMetricPairSpecification": {"PredefinedMetricType": "ASGCPUUtilization"}}],
    "Mode": "ForecastAndScale",
    "SchedulingBufferTime": 300}'

SchedulingBufferTime là tham số quan trọng:

Mở rộng TRƯỚC thời điểm dự báo bao nhiêu giây
    → cho instance đủ thời gian khởi động
    → sẵn sàng đúng lúc tải đến

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

  • **A. Dùng scheduled scaling theo khung giờ định sẵn từ dữ liệu lịch sử, điều chỉnh thủ công — đây là phương án gần nhất và cũng mở rộng trước, nhưng nó đòi con người phân tích và cập nhật lịch: mẫu xem thay đổi theo mùa, theo sự kiện, và scheduled scaling không tự học. Và nó không phản ứng được với nội dung lan truyền.
  • **D. Dùng step scaling theo CPU với CloudWatch alarm — chỉ phản ứng, không dự báo: nó mở rộng SAU KHI tải đã tăng, không đáp ứng vế "scale in advance based on predictions".
  • **B. Dùng simple scaling với cooldown dài — chậm nhất trong mọi lựa chọn: simple scaling là loại policy cũ, chỉ có một hành động và phải chờ hết cooldown trước khi phản ứng tiếp — hoàn toàn không phù hợp với đỉnh tải đột ngột.

Ghi nhớ

Năm loại scaling policy — bảng phải thuộc: | Loại | Bạn khai gì | Đặc điểm | |---|---|---| | Target tracking | một giá trị mục tiêu | đơn giản nhất, phản ứng theo metric | | Step scaling | ngưỡng + các bậc | kiểm soát chi tiết | | Simple scaling | ngưỡng + một hành động | cũ, chậm vì cooldown | | Scheduled scaling | thời điểm và dung lượng | tải biết trước theo giờ | | Predictive scaling | metric để dự báo | HỌC MÁY, mở rộng TRƯỚC |

Từ khoá nhận diện:

"forecast future demand", "recurring daily/weekly patterns", "scale in advance" → predictive scaling "react to real-time changes", "maintain metric at target" → target tracking "at a specific time" → scheduled scaling

Và câu hỏi nào có CẢ HAI vế "dự báo" LẪN "phản ứng thời gian thực" thì đáp án là kết hợp.

Ba yêu cầu của predictive scaling: | Yêu cầu | Chi tiết | |---|---| | Ít nhất 24 giờ dữ liệu lịch sử | 14 ngày cho dự báo tốt | | Mẫu tải có tính CHU KỲ | theo ngày hoặc tuần | | Chạy cùng dynamic scaling | khuyến nghị của AWS |

Hai chế độ của predictive scaling: | Chế độ | Việc | |---|---| | ForecastOnly | chỉ dự báo, KHÔNG hành động — dùng để đánh giá | | ForecastAndScale | dự báo và mở rộng thật |

Nên bắt đầu với ForecastOnly:

Chạy ForecastOnly vài tuần
    → so dự báo với tải thật
    → xác nhận mô hình chính xác
        ↓
    Rồi mới chuyển sang ForecastAndScale

Ba metric dựng sẵn cho predictive scaling: | Metric | Đo gì | |---|---| | ASGCPUUtilization | CPU trung bình | | ASGNetworkIn/Out | lưu lượng mạng | | ALBRequestCount | số request — thường phản ánh tải tốt hơn |

Ba đặc điểm quan trọng của predictive scaling: | Đặc điểm | Chi tiết | |---|---| | CHỈ mở rộng, KHÔNG thu hẹp | thu hẹp do dynamic scaling lo | | Đặt SÀN dung lượng | dynamic scaling có thể tăng thêm | | MIỄN PHÍ | không tính phí riêng |

Dòng đầu là điểm thiết kế quan trọng:

Predictive scaling chỉ nâng MinSize hiệu lực
    → không bao giờ giảm dung lượng
        ↓
    Nếu dự báo sai (cao hơn thực tế), bạn trả tiền thừa
    → nhưng không bao giờ thiếu năng lực

Ba tham số của target tracking: | Tham số | Việc | |---|---| | TargetValue | giá trị cần giữ | | EstimatedInstanceWarmup | bỏ qua instance mới khi tính metric | | DisableScaleIn | chỉ mở rộng |

EstimatedInstanceWarmup là tham số quan trọng nhất:

Không đặt hoặc quá ngắn:
    → instance mới chưa sẵn sàng đã bị tính vào metric
    → metric vẫn cao → ASG thêm tiếp
    → MỞ RỘNG QUÁ MỨC rồi thu hẹp ồ ạt

Ba cấu hình ASG khác cần đúng: | Cấu hình | Chi tiết | |---|---| | HealthCheckType = ELB | thay máy mà ứng dụng hỏng | | MaxSize đủ lớn | chạm trần thì không mở rộng thêm | | Trải nhiều AZ | chịu lỗi |

Ba cách rút ngắn thời gian mở rộng: | Cách | Chi tiết | |---|---| | AMI dựng sẵn | không cài đặt lúc khởi động | | Warm pool | máy đã cấu hình ở trạng thái Stopped | | Giảm thời gian khởi động ứng dụng | |

Warm pool kết hợp tốt với predictive scaling:

Predictive scaling biết trước khi nào cần thêm máy
    → warm pool cho máy sẵn sàng trong vài chục giây
        ↓
    Kết hợp cho phản ứng gần như tức thì

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PredictiveScalingLoadForecast | dự báo so với tải thật | | GroupInServiceInstances | số máy đang phục vụ | | TargetResponseTime của ALB | độ trễ người dùng cảm nhận |

Ba lưu ý khi đánh giá predictive scaling: | Lưu ý | Chi tiết | |---|---| | So dự báo với thực tế trong console | AWS hiển thị biểu đồ | | Mẫu tải thay đổi thì mô hình cần thời gian học lại | | | Sự kiện đặc biệt không dự báo được | ← đó là việc của target tracking |

Và một lời khuyên: hãy chạy predictive scaling ở chế độ ForecastOnly ít nhất hai tuần trước khi bật ForecastAndScale. Console hiển thị biểu đồ so dự báo với tải thật, và nếu mô hình chưa bắt đúng mẫu của bạn, việc mở rộng theo dự báo sai chỉ làm tăng chi phí mà không cải thiện gì.

Câu 632 Chọn nhiều đáp án Design Secure Architectures

A company has recently created a new department to handle their services workload. An IT team has been asked to create a custom VPC to isolate the resources created in this new department. They have set up the public subnet and internet gateway (IGW). However, they are not able to ping the Amazon EC2 instances with elastic IP address (EIP) launched in the newly created VPC.

As a Solutions Architect, the team has requested your help. How will you troubleshoot this scenario? (Select two)

  1. A

    Create a secondary internet gateway to attach with public subnet and move the current internet gateway to private and write route tables
  2. B

    Check if the route table is configured with internet gateway
  3. C

    Disable Source / Destination check on the Amazon EC2 instance
  4. D

    Check if the security groups allow ping from the source
  5. E

    Contact AWS support to map your VPC with subnet
Xem giải thích

Đáp án

B và D.

  • B — Kiểm tra xem route table đã được cấu hình với Internet Gateway chưa
  • D — Kiểm tra xem security group có cho phép ping từ nguồn không

Vì sao đúng

Đề mô tả: đã có public subnet và Internet Gateway, nhưng không ping được EC2 có Elastic IP. Hai đáp án là hai nguyên nhân phổ biến nhất.

B — route table là điều kiện bắt buộc:

Gắn Internet Gateway vào VPC là CHƯA ĐỦ
    → phải có ROUTE trong bảng định tuyến của subnet
        ↓
    0.0.0.0/0 → igw-xxxxx

aws ec2 create-route --route-table-id rtb-public   --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0abc

Và đây chính là định nghĩa của public subnet:

Public subnet:  route table CÓ route tới Internet Gateway
Private subnet: route table KHÔNG có route đó
        ↓
    Không có route = subnet vẫn là private, dù đã gắn IGW vào VPC

D — ping dùng ICMP, không phải TCP:

Security group mặc định chỉ chặn mọi inbound
    → và nhiều người chỉ mở cổng 22 hoặc 80
        ↓
    PING dùng giao thức ICMP, KHÔNG phải TCP
    → phải mở ICMP riêng

aws ec2 authorize-security-group-ingress --group-id sg-web   --protocol icmp --port -1 --cidr 0.0.0.0/0

--port -1 nghĩa là mọi loại ICMP — đây là chi tiết hay bị quên.

Ba điều kiện để instance truy cập được từ Internet:

① VPC có Internet Gateway gắn vào          ← đề đã có
② Route table có route 0.0.0.0/0 tới IGW   ← đáp án B
③ Instance có IP công cộng hoặc EIP        ← đề đã có
④ Security group cho phép giao thức đó     ← đáp án D
⑤ NACL cho phép cả hai chiều

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

  • **C. Tắt Source/Destination check trên EC2 instance — đây là phương án gần nhất và là một thao tác có thật, nhưng nó chỉ cần cho NAT instance: tắt kiểm tra này cho phép instance chuyển tiếp lưu lượng không dành cho nó. Với instance web thông thường, nó không liên quan.
  • **A. Tạo Internet Gateway thứ hai gắn vào public subnet — không làm được: một VPC chỉ gắn được MỘT Internet Gateway, và IGW gắn ở cấp VPC, không gắn vào subnet.
  • **E. Liên hệ AWS Support để ánh xạ VPC với subnet — không phải quy trình có thật: subnet được tạo trong VPC bởi chính bạn, không cần AWS can thiệp.

Ghi nhớ

Năm điều kiện để instance ra Internet — bảng kiểm tra: | Điều kiện | Kiểm tra bằng | |---|---| | Internet Gateway gắn vào VPC | describe-internet-gateways | | Route 0.0.0.0/0 → IGW | describe-route-tables | | Instance có IP công cộng hoặc EIP | describe-instances | | Security group cho phép giao thức | describe-security-groups | | NACL cho phép CẢ hai chiều | describe-network-acls |

Thiếu bất kỳ điều kiện nào là không hoạt động.

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

Public subnet:  route table CÓ route tới Internet Gateway
Private subnet: route table KHÔNG có route đó
        ↓
    Đây là khác biệt DUY NHẤT — không có công tắc "public/private"

Ba giao thức và cách mở trong security group: | Giao thức | Cấu hình | |---|---| | TCP (SSH, HTTP) | --protocol tcp --port 22 | | ICMP (ping) | --protocol icmp --port -1 | | Tất cả | --protocol -1 |

ICMP là chi tiết hay bị quên — mở cổng 80 không cho phép ping.

Ba loại ICMP hay dùng: | Loại | Việc | |---|---| | Echo Request (type 8) | ping đi | | Echo Reply (type 0) | ping trả về | | Destination Unreachable (type 3) | cần cho Path MTU Discovery |

Chặn hết ICMP có thể gây vấn đề MTU — nên cho phép ít nhất type 3.

Security group và NACL — bảng phân biệt: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI | SUBNET | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | chỉ Allow | Allow và Deny | | Mặc định | chặn inbound | cho cả hai chiều |

Với NACL stateless, ping cần mở cả hai chiều:

# Vào: Echo Request
aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 100 --protocol 1 --icmp-type-code Type=8,Code=-1   --cidr-block 0.0.0.0/0 --rule-action allow --ingress

# Ra: Echo Reply
aws ec2 create-network-acl-entry --network-acl-id acl-0abc   --rule-number 100 --protocol 1 --icmp-type-code Type=0,Code=-1   --cidr-block 0.0.0.0/0 --rule-action allow --egress

Ba loại IP của EC2: | Loại | Đặc điểm | |---|---| | IP riêng | luôn có, không đổi trong vòng đời instance | | IPv4 công cộng tự động | thu hồi khi stop/start | | Elastic IP | tĩnh, giữ được |

Và IP công cộng KHÔNG hiện trong hệ điều hành:

ip addr show     # chỉ thấy IP riêng

Internet Gateway làm NAT 1:1 giữa IP công cộng và IP riêng
    → hệ điều hành chỉ biết IP riêng

Ba đặc điểm của Internet Gateway: | Đặc điểm | Chi tiết | |---|---| | MỘT IGW mỗi VPC | gắn ở cấp VPC | | Dư thừa, sẵn sàng cao | AWS quản lý | | MIỄN PHÍ | chỉ trả phí truyền dữ liệu |

Ba lưu ý về tắt Source/Destination check: | Lưu ý | Chi tiết | |---|---| | CHỈ cần cho NAT instance | hoặc thiết bị định tuyến | | Bật mặc định cho mọi instance | | | Tắt cho instance thường là không cần thiết | |

aws ec2 modify-instance-attribute --instance-id i-0nat --no-source-dest-check

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | chỉ ra chính xác thành phần nào chặn | | VPC Flow Logs | thấy gói bị từ chối (REJECT) | | Console: Route table, SG, NACL | kiểm tra cấu hình |

Reachability Analyzer là công cụ nhanh nhất:

aws ec2 create-network-insights-path   --source igw-0abc --destination i-0abc   --protocol tcp --destination-port 80
aws ec2 start-network-insights-analysis --network-insights-path-id nip-0abc

Ba bước chẩn đoán thủ công:

# ① Route table của subnet
aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-a

# ② Security group
aws ec2 describe-security-groups --group-ids sg-web

# ③ NACL
aws ec2 describe-network-acls --filters Name=association.subnet-id,Values=subnet-a

Và một lời khuyên: hãy thử curl hoặc telnet tới cổng 80 song song với ping. Nếu cổng 80 thông mà ping không được, vấn đề chỉ là ICMP chưa mở — và bạn biết ngay mạng vốn đã thông, tiết kiệm thời gian điều tra route table và NACL.

Câu 633 Design Cost-Optimized Architectures

An e-commerce analytics company is preparing to archive several years of transaction records and customer analytics reports in Amazon S3 for long-term storage. To meet compliance requirements, the archived data must be encrypted at rest using AWS-managed encryption keys. Additionally, the solution must be cost-effective and ensure that key rotation occurs automatically every 12 months to comply with the company’s internal data governance policy.

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

  1. A

    Use Amazon S3 server-side encryption with S3-managed keys (SSE-S3). Upload data with default encryption enabled. Rely on the built-in key management and rotation behavior of SSE-S3
  2. B

    Encrypt the data locally using client-side encryption libraries and upload the encrypted files to S3. Create a KMS key with imported key material and configure key rotation settings
  3. C

    Use AWS Key Management Service (KMS) to create a customer managed key with automatic rotation enabled. Configure the S3 bucket’s default encryption to use the customer managed key. Migrate the data to the S3 bucket
  4. D

    Use AWS CloudHSM to generate encryption keys. Configure S3 to use these custom encryption keys via client-side encryption and rotate the keys annually using an on-premises key management workflow
Xem giải thích

Đáp án

C — Dùng AWS KMS tạo customer managed key với xoay vòng TỰ ĐỘNG, cấu hình mã hoá mặc định của bucket dùng khoá đó, rồi chuyển dữ liệu vào bucket.

Vì sao đúng

Đề nêu hai yêu cầu tuân thủ, và điểm phân biệt nằm ở vế thứ hai: | Yêu cầu | Cơ chế | |---|---| | Mã hoá at rest | mọi phương án SSE đều làm được | | Xoay vòng khoá TỰ ĐỘNG mỗi 12 tháng, KIỂM CHỨNG được | CHỈ KMS cho bạn cấu hình và chứng minh |

Vế thứ hai là mấu chốt:

Chính sách quản trị dữ liệu nội bộ đòi
    "key rotation occurs automatically every 12 months"
        ↓
    Bạn phải CHỨNG MINH được điều đó với kiểm toán viên
        ↓
    KMS: bật rotation, xem được ngày xoay vòng, có bản ghi CloudTrail
    SSE-S3: AWS lo ở tầng nền, bạn không thấy, không cấu hình được

Bật xoay vòng tự động:

aws kms create-key --description "Khoa luu tru phan tich"   --key-usage ENCRYPT_DECRYPT

aws kms enable-key-rotation --key-id abc-123 --rotation-period-in-days 365

Và cấu hình bucket:

aws s3api put-bucket-encryption --bucket kho-luu-tru   --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "<arn-khoa>"},
      "BucketKeyEnabled": true}]}'

BucketKeyEnabled: true là chi tiết quan trọng về chi phí:

S3 Bucket Keys giảm tới 99% số lời gọi KMS
    → giữ được vế "cost-effective" của đề

Và ba đặc điểm của xoay vòng tự động: | Đặc điểm | Chi tiết | |---|---| | Key ID và ARN KHÔNG đổi | ứng dụng không phải sửa gì | | Key material CŨ được GIỮ LẠI | dữ liệu cũ vẫn giải mã được | | Hoàn toàn trong suốt | không phải mã hoá lại gì |

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

  • **A. Dùng SSE-S3 và dựa vào cơ chế quản lý và xoay vòng dựng sẵn — đây là phương án gần nhất và rẻ nhất (SSE-S3 miễn phí), nhưng nó không cho kiểm chứng chu kỳ xoay vòng: AWS quản lý khoá SSE-S3 hoàn toàn ở tầng nền, bạn không cấu hình được, không thấy được, không chứng minh được chu kỳ 12 tháng với kiểm toán viên.
  • **B. Mã hoá phía client rồi tải lên, tạo KMS key với key material NHẬP VÀO — hai vấn đề: mã hoá phía client thêm nhiều công vận hành, và khoá có key material nhập vào KHÔNG xoay vòng tự động được — bạn phải tự nhập khoá mới.
  • **D. Dùng CloudHSM sinh khoá và mã hoá phía client, xoay vòng thủ công qua quy trình tại chỗ — công vận hành cao nhất: phải vận hành cụm HSM và xây quy trình xoay vòng thủ công. Đề hỏi "least operational overhead".

Ghi nhớ về chất lượng câu hỏi

Đề nói "encrypted at rest using AWS-managed encryption keys", nhưng đáp án là customer managed key.

Trong thuật ngữ của AWS, "AWS-managed key" có nghĩa cụ thể: | Loại khoá | Ai quản lý | Xoay vòng | |---|---|---| | AWS managed key (aws/s3) | AWS hoàn toàn | TỰ ĐỘNG mỗi năm, KHÔNG tắt được, không cấu hình được | | Customer managed key | bạn kiểm soát policy và rotation | tuỳ chọn, bật bằng enable-key-rotation | | AWS owned key | AWS dùng nội bộ | không thấy |

Theo nghĩa chặt, "AWS-managed key" là khoá aws/s3 — và nó cũng xoay vòng tự động mỗi năm. Nhưng bạn không cấu hình được nó và không đặt được key policy riêng, nên với yêu cầu chứng minh tuân thủ, customer managed key là lựa chọn đúng.

Cách hiểu hợp lý của đề: "AWS-managed" ở đây có nghĩa là AWS quản lý hạ tầng khoá (khác với tự quản lý bằng CloudHSM hay client-side), chứ không phải chỉ đích danh khoá aws/s3.

Ghi nhớ

Năm cách mã hoá S3 — bảng phải thuộc: | Cách | Ai giữ khoá | Audit dùng khoá | Xoay vòng cấu hình được | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | ❌ | ❌ | | SSE-KMS | KMS, bạn kiểm soát policy | ✅ CloudTrail | ✅ | | DSSE-KMS | KMS, mã hoá hai lớp | ✅ | ✅ | | SSE-C | bạn gửi mỗi request | ❌ | tự lo | | Client-side | bạn hoàn toàn | ❌ | tự lo |

Từ khoá nhận diện:

"audit key usage", "control key rotation", "key policy" → SSE-KMS "simplest, AWS manages everything" → SSE-S3 "key never leaves our premises" → SSE-C hoặc client-side

Ba loại khoá KMS và xoay vòng: | Loại | Xoay vòng | |---|---| | AWS managed key | tự động mỗi năm, không tắt được | | Customer managed key | tuỳ chọn, chu kỳ 90–2560 ngày | | Khoá có key material nhập vào | KHÔNG tự xoay vòng được |

Tuỳ chỉnh chu kỳ xoay vòng:

aws kms enable-key-rotation --key-id abc-123 --rotation-period-in-days 365
aws kms get-key-rotation-status --key-id abc-123
aws kms list-key-rotations --key-id abc-123

Lệnh cuối liệt kê lịch sử xoay vòng — đúng thứ kiểm toán viên cần.

Ba chi phí của KMS: | Khoản | Chi tiết | |---|---| | Lưu khoá | ~1 USD/khoá/tháng (customer managed) | | Lời gọi API | ~0,03 USD mỗi 10.000 | | Mỗi phiên bản khoá do xoay vòng | tính thêm ~1 USD/tháng |

Dòng cuối đáng lưu ý: sau 5 năm xoay vòng, một khoá có 5 phiên bản và tính phí tương ứng.

S3 Bucket Keys giảm mạnh chi phí:

{"BucketKeyEnabled": true}

Giảm tới 99% số lời gọi KMS
    → đổi lại: log CloudTrail ít chi tiết hơn
      (một bản ghi mỗi bucket key thay vì mỗi object)

Với yêu cầu audit rất chặt, đó là đánh đổi cần cân nhắc.

Ba lưu ý về mã hoá dữ liệu ĐÃ CÓ: | Lưu ý | Chi tiết | |---|---| | Mã hoá mặc định chỉ áp cho object MỚI | | | Object cũ phải sao chép lại | | | Dùng S3 Batch Operations cho khối lượng lớn | |

aws s3 cp s3://kho-luu-tru/ s3://kho-luu-tru/ --recursive   --sse aws:kms --sse-kms-key-id <arn> --metadata-directive REPLACE

Ba biện pháp tuân thủ bổ sung: | Biện pháp | Chi tiết | |---|---| | Bắt buộc SSE-KMS bằng bucket policy | chặn ghi không mã hoá | | Bật CloudTrail data event | ghi mọi thao tác object | | S3 Object Lock cho dữ liệu lưu trữ | chống xoá và sửa |

Chính sách bắt buộc SSE-KMS:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-luu-tru/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Nhớ thêm statement thứ hai chặn request thiếu hẳn header (Null condition).

Ba lưu ý về lifecycle cho dữ liệu lưu trữ: | Lưu ý | Chi tiết | |---|---| | Chuyển sang Glacier Deep Archive | rẻ nhất cho lưu trữ nhiều năm | | Mã hoá vẫn giữ nguyên khi chuyển lớp | | | AbortIncompleteMultipartUpload | dọn phần dở dang |

Ba lưu ý về key policy: | Lưu ý | Chi tiết | |---|---| | Quyền dùng khoá = CẢ key policy LẪN IAM policy | | | Cấp kms:Decrypt trong IAM là CHƯA ĐỦ | key policy cũng phải cho phép | | Đừng khoá chính mình ra khỏi khoá | luôn để lại quyền quản trị |

Và một lời khuyên: hãy chạy list-key-rotations và lưu kết quả định kỳ. Đó là bằng chứng trực tiếp rằng chính sách xoay vòng 12 tháng đang được thực thi — và với yêu cầu quản trị dữ liệu nội bộ, khả năng chứng minh quan trọng ngang với việc thực sự làm điều đó.

Câu 634 Design Resilient Architectures

A ride-sharing company wants to improve the ride-tracking system that stores GPS coordinates for all rides. The engineering team at the company is looking for a NoSQL database that has single-digit millisecond latency, can scale horizontally, and is serverless, so that they can perform high-frequency lookups reliably.

As a Solutions Architect, which database do you recommend for their requirements?

  1. A

    Amazon Relational Database Service (Amazon RDS)
  2. B

    Amazon DynamoDB
  3. C

    Amazon Neptune
  4. D

    Amazon ElastiCache
Xem giải thích

Đáp án

B — Amazon DynamoDB.

Vì sao đúng

Đề nêu bốn yêu cầu, và DynamoDB thoả cả bốn: | Yêu cầu | Cơ chế | |---|---| | NoSQL | DynamoDB là key-value và document | | Độ trễ MILI GIÂY MỘT CHỮ SỐ | đảm bảo ở mọi quy mô | | Mở rộng NGANG | tự chia partition, không giới hạn dung lượng | | SERVERLESS | không có instance nào để quản lý |

Vế "serverless" là điểm phân biệt quan trọng:

DynamoDB:
    → không chọn cỡ instance
    → không vá lỗi
    → không quản lý cụm
    → chế độ on-demand tự co giãn hoàn toàn
        ↓
    Là dịch vụ NoSQL serverless duy nhất trong các phương án

Và độ trễ mili giây một chữ số là cam kết của DynamoDB:

DynamoDB được thiết kế cho:
    → tra cứu theo khoá chính ở độ trễ ổn định
    → bất kể bảng có 1 GB hay 100 TB
        ↓
    Phù hợp với "high-frequency lookups reliably"

Tạo bảng cho dữ liệu GPS:

aws dynamodb create-table --table-name toa-do-chuyen-di   --attribute-definitions AttributeName=ma_chuyen,AttributeType=S                           AttributeName=thoi_diem,AttributeType=N   --key-schema AttributeName=ma_chuyen,KeyType=HASH                 AttributeName=thoi_diem,KeyType=RANGE   --billing-mode PAY_PER_REQUEST

Và composite key phù hợp với dữ liệu theo dõi:

Partition key = mã chuyến đi (phân bố đều)
Sort key      = dấu thời gian
        ↓
    Truy vấn "toàn bộ toạ độ của chuyến X" là một Query hiệu quả

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

  • **D. Amazon ElastiCache — đây là phương án gần nhất và cho độ trễ còn thấp hơn DynamoDB (micro giây), nhưng nó không phải database bền vững và không serverless theo nghĩa truyền thống: ElastiCache là bộ đệm, dữ liệu mất khi node hỏng, và bạn phải chọn cỡ node. (ElastiCache Serverless có tồn tại, nhưng nó vẫn là bộ đệm.)
  • **A. Amazon RDS — không phải NoSQL: RDS là database quan hệ, và nó đòi chọn cỡ instance nên không serverless.
  • **C. Amazon Neptune — sai loại NoSQL: Neptune là database đồ thị, tối ưu cho truy vấn quan hệ nhiều cấp, không phải cho tra cứu theo khoá tần suất cao. Và nó cũng đòi chọn cỡ instance.

Ghi nhớ

Các loại database của AWS — bảng phải thuộc: | Loại | Dịch vụ | Serverless | |---|---|---| | Key-value / document | DynamoDB | ✅ | | Quan hệ | RDS, Aurora | Aurora Serverless v2 | | Đồ thị | Neptune | Neptune Serverless | | Trong bộ nhớ | ElastiCache, MemoryDB | ElastiCache Serverless | | Chuỗi thời gian | Timestream | ✅ | | Tài liệu (tương thích MongoDB) | DocumentDB | ❌ | | Sổ cái | QLDB | ✅ |

Từ khoá nhận diện:

"NoSQL", "single-digit millisecond", "serverless", "horizontal scaling" → DynamoDB "relationships, friends of friends" → Neptune "caching layer, microsecond" → ElastiCache "time-series, IoT metrics" → Timestream

Ba đặc điểm cốt lõi của DynamoDB: | Đặc điểm | Chi tiết | |---|---| | Độ trễ mili giây một chữ số | ở mọi quy mô | | Tự chia partition | không giới hạn dung lượng | | Sao chép qua 3 AZ | dựng sẵn |

Hai chế độ dung lượng: | Chế độ | Đặc điểm | |---|---| | On-demand | tự co giãn, trả theo request | | Provisioned | rẻ hơn khi tải ổn định, có auto scaling |

Ba giới hạn cần nhớ: | Giới hạn | Giá trị | |---|---| | Kích thước item | 400 KB | | Thông lượng mỗi partition | 3.000 RCU hoặc 1.000 WCU | | Số GSI mỗi bảng | 20 |

Hai loại khoá: | Loại | Chi tiết | |---|---| | Partition key (HASH) | quyết định item nằm ở partition nào | | Sort key (RANGE) | sắp xếp trong partition, cho truy vấn khoảng |

Ba nguyên tắc thiết kế partition key: | Nguyên tắc | Chi tiết | |---|---| | Giá trị phân bố ĐỀU | tránh hot partition | | Số giá trị đủ nhiều | | | Truy vấn thường xuyên nhất dùng khoá này | |

Ba cách truy vấn DynamoDB: | Cách | Đặc điểm | |---|---| | GetItem | lấy một item theo khoá — nhanh nhất | | Query | theo partition key, lọc theo sort key — hiệu quả | | Scan | đọc TOÀN BỘ bảng — tránh dùng |

Scan là thao tác cần tránh:

Scan đọc mọi item rồi mới lọc
    → tốn RCU rất nhiều
    → chậm với bảng lớn
        ↓
    Thiết kế khoá và GSI sao cho luôn dùng được Query

Ba loại index: | Loại | Đặc điểm | |---|---| | Global Secondary Index (GSI) | partition key KHÁC, tạo được sau | | Local Secondary Index (LSI) | cùng partition key, sort key khác, chỉ tạo lúc tạo bảng | | — | GSI linh hoạt hơn nhiều |

Ba tính năng nên bật cho bảng sản xuất: | Tính năng | Chi tiết | |---|---| | Point-in-time recovery | khôi phục về bất kỳ giây nào trong 35 ngày | | Deletion protection | chặn xoá bảng nhầm, MIỄN PHÍ | | TTL | tự xoá dữ liệu cũ, MIỄN PHÍ |

TTL rất phù hợp với dữ liệu GPS:

aws dynamodb update-time-to-live --table-name toa-do-chuyen-di   --time-to-live-specification "Enabled=true, AttributeName=het_han"

Toạ độ chi tiết chỉ cần giữ 30 ngày
    → TTL tự xoá, KHÔNG tốn WCU
    → kiểm soát chi phí lưu trữ

Ba tính năng nâng cao: | Tính năng | Việc | |---|---| | DynamoDB Streams | luồng thay đổi cho Lambda | | Global Tables | đa ghi xuyên Region | | DAX | bộ đệm micro giây |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | On-demand đắt hơn provisioned ~5–7 lần | khi tải ổn định | | Lưu trữ ~0,25 USD/GB-tháng | | | GSI tốn dung lượng và thông lượng riêng | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ThrottledRequests | bị giới hạn — xem lại khoá hoặc dung lượng | | ConsumedReadCapacityUnits | mức dùng thật | | SuccessfulRequestLatency | độ trễ |

Ba lưu ý cho dữ liệu theo dõi hành trình: | Lưu ý | Chi tiết | |---|---| | Ghi theo lô bằng BatchWriteItem | tối đa 25 item | | Xử lý UnprocessedItems | có thể thành công MỘT PHẦN | | Cân nhắc lưu lịch sử dài hạn ở S3 | rẻ hơn nhiều |

Và một lời khuyên: hãy bật TTL ngay khi tạo bảng cho dữ liệu GPS. Toạ độ được ghi liên tục và tích tụ rất nhanh — với TTL, dữ liệu cũ tự biến mất mà không tốn một đơn vị ghi nào, còn không có nó thì chi phí lưu trữ sẽ tăng đều mỗi tháng mà không ai để ý.

Câu 635 Design Resilient Architectures

An e-commerce company wants to migrate its on-premises application to AWS. The application consists of application servers and a Microsoft SQL Server database. The solution should result in the maximum possible availability for the database layer while minimizing operational and management overhead.

As a solutions architect, which of the following would you recommend to meet the given requirements?

  1. A

    Migrate the data to Amazon RDS for SQL Server database in a cross-region read-replica configuration
  2. B

    Migrate the data to Amazon RDS for SQL Server database in a cross-region Multi-AZ deployment
  3. C

    Migrate the data to Amazon EC2 instance hosted SQL Server database. Deploy the Amazon EC2 instances in a Multi-AZ configuration
  4. D

    Migrate the data to Amazon RDS for SQL Server database in a Multi-AZ deployment
Xem giải thích

Đáp án

D — Chuyển dữ liệu sang Amazon RDS for SQL Server ở cấu hình Multi-AZ.

Vì sao đúng

Đề nêu hai yêu cầu, và RDS Multi-AZ đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | SẴN SÀNG tối đa cho tầng database | Multi-AZ với chuyển đổi tự động | | Ít công vận hành và quản lý nhất | RDS lo sao lưu, vá lỗi, chuyển đổi |

Multi-AZ cho sẵn sàng cao thật sự:

Multi-AZ:
    → standby ở AZ khác, sao chép ĐỒNG BỘ
    → tự chuyển đổi khi primary hỏng (60–120 giây)
    → RPO = 0, không mất giao dịch nào

Và RDS lo mọi việc vận hành:

AWS quản lý:
    ✓ cấp phát và vá lỗi hệ điều hành
    ✓ vá lỗi engine SQL Server
    ✓ sao lưu tự động và point-in-time recovery
    ✓ chuyển đổi Multi-AZ
    ✓ giám sát và metric

Bật Multi-AZ:

aws rds create-db-instance --db-instance-identifier db-thuong-mai   --engine sqlserver-se --engine-version 15.00.4335.1.v1   --db-instance-class db.m5.2xlarge --allocated-storage 500   --multi-az --storage-encrypted   --backup-retention-period 35 --license-model license-included

Và vì sao "cross-region" trong hai phương án kia là sai:

Multi-AZ hoạt động TRONG một Region
    → không có khái niệm "cross-region Multi-AZ"
        ↓
    Cross-region là chuyện của read replica hoặc snapshot copy

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

  • **B. RDS for SQL Server ở cross-region Multi-AZ deployment — đây là phương án gần nhất và nhắc đúng Multi-AZ, nhưng nó không phải cấu hình có thật: Multi-AZ trải qua các Availability Zone trong CÙNG một Region, không trải qua Region.
  • **A. RDS for SQL Server với cross-region read replica — không phải cơ chế sẵn sàng cao: read replica sao chép bất đồng bộ (có thể mất dữ liệu) và promote thủ công (không tự chuyển đổi). Nó dùng cho mở rộng đọc và khôi phục thảm hoạ.
  • **C. SQL Server tự cài trên EC2 ở cấu hình Multi-AZ — công vận hành cao nhất: phải tự cài, vá lỗi, dựng Always On Availability Group, tự lo sao lưu và cơ chế chuyển đổi. Đi ngược yêu cầu "minimizing operational and management overhead".

Ghi nhớ

Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | RPO | 0 | giây tới phút | | Chuyển đổi | TỰ ĐỘNG | thủ công (promote) | | Standby phục vụ đọc | ❌ (Multi-AZ instance) | ✅ | | Phạm vi | cùng Region, ≥ 2 AZ | cùng hoặc KHÁC Region |

Từ khoá nhận diện:

"maximum availability", "automatic failover", "no data loss" → Multi-AZ "scale reads", "reporting" → read replica "disaster recovery across Regions" → cross-Region read replica

Ba lựa chọn chạy SQL Server trên AWS: | Lựa chọn | Truy cập OS | Công vận hành | |---|---|---| | RDS for SQL Server | ❌ | thấp nhất ← câu này | | RDS Custom for SQL Server | ✅ | vừa | | SQL Server trên EC2 | ✅ toàn quyền | cao nhất |

Ba kiểu triển khai của RDS: | Kiểu | Đặc điểm | |---|---| | Single-AZ | một instance, chỉ cho dev | | Multi-AZ instance | 1 standby, KHÔNG phục vụ đọc | | Multi-AZ DB cluster | 2 standby CÓ phục vụ đọc, chuyển đổi dưới 35 giây |

(Multi-AZ DB cluster hiện hỗ trợ MySQL và PostgreSQL, không hỗ trợ SQL Server.)

Ba tình huống kích hoạt chuyển đổi: | Tình huống | Chi tiết | |---|---| | Primary hỏng | phần cứng hoặc phần mềm | | AZ mất kết nối | | | Bảo trì có kế hoạch | vá lỗi, đổi cỡ instance |

Và chuyển đổi diễn ra qua DNS:

Endpoint KHÔNG ĐỔI
    → RDS trỏ bản ghi DNS sang standby
    → ứng dụng chỉ cần KẾT NỐI LẠI
        ↓
    ⚠ .NET và Java cache DNS — cần cấu hình TTL phù hợp

Ba loại bảo trì và tác động — bảng cần thuộc: | Loại | Multi-AZ giảm ngừng | |---|---| | Vá lỗi hệ điều hành | ✅ vá standby trước rồi chuyển đổi | | Đổi cỡ instance | ✅ | | Nâng cấp phiên bản ENGINE | ❌ cả hai cùng lúc, CÓ ngừng |

Ba việc Multi-AZ KHÔNG bảo vệ: | Không bảo vệ | Cách bảo vệ | |---|---| | Lỗi con người (xoá nhầm bảng) | automated backup + PITR | | Thảm hoạ cấp Region | cross-Region replica hoặc snapshot copy | | Dữ liệu hỏng do ứng dụng | PITR |

Multi-AZ là cơ chế SẴN SÀNG, không phải SAO LƯU.

Ba mô hình giấy phép SQL Server: | Mô hình | Chi tiết | |---|---| | License Included | giá instance đã gồm giấy phép | | BYOL | dùng giấy phép sẵn có (cần Dedicated Host cho một số phiên bản) | | — | RDS chủ yếu hỗ trợ License Included |

Ba phiên bản SQL Server trên RDS: | Phiên bản | Hỗ trợ Multi-AZ | |---|---| | Express | ❌ | | Web | ❌ | | Standard | ✅ | | Enterprise | ✅ |

Dòng đầu đáng lưu ý: Express và Web edition không hỗ trợ Multi-AZ.

Ba công cụ di chuyển: | Công cụ | Việc | |---|---| | Native backup/restore qua S3 | đơn giản nhất cho SQL Server | | AWS DMS | có CDC, gián đoạn tối thiểu | | AWS SCT | chỉ cần khi đổi engine |

Native backup/restore:

EXEC msdb.dbo.rds_restore_database
  @restore_db_name='thuong_mai',
  @s3_arn_to_restore='arn:aws:s3:::kho-backup/thuong_mai.bak';

Ba biện pháp bảo mật nên có: | Biện pháp | Chi tiết | |---|---| | Database trong PRIVATE subnet | không public IP | | Mã hoá at rest bằng KMS | bật LÚC TẠO | | Bắt buộc TLS | rds.force_ssl |

Ba việc cần làm sau khi triển khai: | Việc | Chi tiết | |---|---| | THỬ chuyển đổi thật | reboot --force-failover | | Bật Performance Insights | | | Đặt alarm cho metric chính | CPU, kết nối, dung lượng |

Và một lời khuyên: hãy thử chuyển đổi trong giờ thấp điểm ngay sau khi triển khai. Nó cho biết ứng dụng mất bao lâu để kết nối lại và có xử lý được ngoại lệ kết nối tạm thời hay không — với ứng dụng .NET, việc cache DNS là vấn đề rất hay gặp và chỉ lộ ra khi thử thật.

Câu 636 Design High-Performing Architectures

A company's business logic is built on several microservices that are running in the on-premises data center. They currently communicate using a message broker that supports the MQTT protocol. The company is looking at migrating these applications and the message broker to AWS Cloud without changing the application logic.

Which technology allows you to get a managed message broker that supports the MQTT protocol?

  1. A

    Amazon MQ
  2. B

    Amazon Kinesis Data Streams
  3. C

    Amazon Simple Notification Service (Amazon SNS)
  4. D

    Amazon Simple Queue Service (Amazon SQS)
Xem giải thích

Đáp án

A — Amazon MQ.

Vì sao đúng

Đề nêu từ khoá quyết định: giao thức MQTT và không đổi logic ứng dụng.

"communicate using a message broker that supports the MQTT protocol"
"migrating ... WITHOUT CHANGING the application logic"
        ↓
    Cần broker được quản lý hiểu MQTT nguyên bản

Amazon MQ hỗ trợ MQTT qua ActiveMQ:

Amazon MQ với engine ActiveMQ hỗ trợ:
    ✓ MQTT
    ✓ AMQP
    ✓ OpenWire
    ✓ STOMP
    ✓ JMS
    ✓ WebSocket
        ↓
    Ứng dụng chỉ đổi CHUỖI KẾT NỐI

Và các dịch vụ nhắn tin khác của AWS dùng API RIÊNG:

SQS, SNS, Kinesis:
    → API riêng của AWS qua HTTPS
    → KHÔNG nói MQTT
        ↓
    Chuyển sang chúng đòi VIẾT LẠI toàn bộ tầng nhắn tin

Tạo broker:

aws mq create-broker --broker-name broker-vi-dich-vu   --engine-type ACTIVEMQ --engine-version 5.18   --host-instance-type mq.m5.large   --deployment-mode ACTIVE_STANDBY_MULTI_AZ   --users Username=quantri,Password='<mat-khau>'   --publicly-accessible false   --subnet-ids subnet-a subnet-b

Và ứng dụng kết nối như với broker cũ:

mqtt+ssl://b-abc123-1.mq.ap-northeast-1.amazonaws.com:8883

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

  • **C. Amazon SNS — đây là phương án gần nhất vì SNS cũng là dịch vụ nhắn tin theo mô hình phát tán, nhưng nó không hỗ trợ MQTT: SNS dùng API riêng của AWS. Và nó không lưu bền — subscriber không nhận được thì thông điệp mất.
  • **D. Amazon SQS — cũng dùng API riêng, và là mô hình hàng đợi một consumer nhận, khác hẳn mô hình publish–subscribe của MQTT.
  • **B. Amazon Kinesis Data Streams — sai loại dịch vụ: Kinesis là nền tảng luồng dữ liệu cho phân tích thời gian thực, không phải message broker và không nói MQTT.

Ghi nhớ

Bốn dịch vụ nhắn tin của AWS — bảng phải thuộc: | Dịch vụ | Giao thức | Phù hợp | |---|---|---| | Amazon MQ | MQTT, AMQP, STOMP, OpenWire, JMS | DI CHUYỂN ứng dụng dùng broker chuẩn ← câu này | | Amazon SQS | API riêng (HTTPS) | ứng dụng mới trên đám mây | | Amazon SNS | API riêng | phát tán thông báo | | Amazon MSK | Kafka | luồng sự kiện quy mô lớn | | AWS IoT Core | MQTT cho THIẾT BỊ IoT | hàng triệu thiết bị |

Quy tắc nhận diện — rất hay được hỏi:

"existing app uses MQTT/AMQP/JMS/STOMP", "lift and shift", "no code change" → Amazon MQ "cloud-native", "new application", "unlimited scale" → SQS hoặc SNS "Apache Kafka" → Amazon MSK "millions of IoT devices" → AWS IoT Core

Và AWS IoT Core cũng hỗ trợ MQTT — khi nào chọn cái nào: | | Amazon MQ | AWS IoT Core | |---|---|---| | Đối tượng | ứng dụng doanh nghiệp di chuyển lên đám mây | thiết bị IoT | | Quy mô | giới hạn bởi cỡ broker | hàng triệu thiết bị | | Xác thực | user và password | chứng chỉ X.509 mỗi thiết bị | | Tính năng riêng | tương thích broker chuẩn | Device Shadow, IoT Rules |

Với microservice doanh nghiệp như trong đề, Amazon MQ là lựa chọn đúng.

Hai engine của Amazon MQ: | Engine | Giao thức hỗ trợ | |---|---| | ActiveMQ | MQTT, AMQP, STOMP, OpenWire, JMS, WebSocket | | RabbitMQ | AMQP 0-9-1 (MQTT qua plugin) |

Với yêu cầu MQTT, ActiveMQ là engine phù hợp.

Ba kiểu triển khai của Amazon MQ: | Kiểu | Sẵn sàng | |---|---| | Single-instance | không chịu lỗi — chỉ cho dev | | Active/standby (ActiveMQ) | hai AZ, tự chuyển đổi | | Cluster deployment (RabbitMQ) | ba node qua ba AZ |

Amazon MQ và SQS — bảng phân biệt: | | Amazon MQ | SQS | |---|---|---| | Giao thức chuẩn ngành | ✅ | ❌ | | Mở rộng | giới hạn bởi cỡ broker | gần như vô hạn | | Cần chọn cỡ instance | ✅ | ❌ | | Nằm trong VPC | ✅ | ❌ (endpoint công khai) | | Chi phí | theo giờ broker | theo request |

Đánh đổi quan trọng:

Amazon MQ dễ di chuyển
    → nhưng KHÔNG mở rộng vô hạn như SQS
    → vẫn là broker chạy trên instance có kích thước cụ thể
        ↓
    Cần theo dõi và nâng cỡ broker khi tải tăng

Ba metric cần theo dõi cho Amazon MQ: | Metric | Ý nghĩa | |---|---| | QueueSize | thông điệp tồn đọng — consumer không kịp | | CpuUtilization của broker | cần nâng cỡ khi cao | | ConnectionCount, ChannelCount | gần trần thì phải xử lý |

Ba đặc điểm của giao thức MQTT: | Đặc điểm | Chi tiết | |---|---| | Nhẹ, thiết kế cho băng thông thấp | phù hợp IoT | | Mô hình publish–subscribe theo TOPIC | | | Ba mức QoS | 0 (at most once), 1 (at least once), 2 (exactly once) |

Ba mức QoS của MQTT: | QoS | Đảm bảo | |---|---| | 0 | gửi một lần, không xác nhận — có thể mất | | 1 | ít nhất một lần — có thể trùng | | 2 | đúng một lần — chậm nhất |

Lưu ý: AWS IoT Core chỉ hỗ trợ QoS 0 và 1, còn Amazon MQ với ActiveMQ hỗ trợ đầy đủ.

Ba biện pháp bảo mật cho Amazon MQ: | Biện pháp | Chi tiết | |---|---| | Đặt broker trong PRIVATE subnet | publicly-accessible false | | Mã hoá at rest bằng KMS và in transit bằng TLS | | | Thông tin đăng nhập trong Secrets Manager | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Broker instance-giờ | như EC2 | | Lưu trữ | theo GB | | Active/standby | gấp đôi chi phí instance |

Ba bước di chuyển: | Bước | Chi tiết | |---|---| | Tạo broker Amazon MQ | | | Đổi chuỗi kết nối trong ứng dụng | | | Chuyển dần từng microservice | chạy song song một thời gian |

Và một lời khuyên về lộ trình: hãy coi Amazon MQ là bước trung gian, không phải đích cuối. Nó cho phép di chuyển lên đám mây mà không viết lại mã, nhưng nếu hệ thống tiếp tục lớn lên thì SQS, SNS hoặc IoT Core sẽ mở rộng tốt hơn — và chuyển đổi dần từng dịch vụ sau khi đã lên đám mây dễ hơn nhiều so với làm hai việc cùng lúc.

Câu 637 Chọn nhiều đáp án Design Resilient Architectures

Your company is deploying a website running on AWS Elastic Beanstalk. The website takes over 45 minutes for the installation and contains both static as well as dynamic files that must be generated during the installation process.

As a Solutions Architect, you would like to bring the time to create a new instance in your AWS Elastic Beanstalk deployment to be less than 2 minutes. Which of the following options should be combined to build a solution for this requirement? (Select two)

  1. A

    Use AWS Elastic Beanstalk deployment caching feature
  2. B

    Create a Golden Amazon Machine Image (AMI) with the static installation components already setup
  3. C

    Store the installation files in Amazon S3 so they can be quickly retrieved
  4. D

    Use Amazon EC2 user data to customize the dynamic installation parts at boot time
  5. E

    Use Amazon EC2 user data to install the application at boot time
Xem giải thích

Đáp án

B và D.

  • B — Dựng golden AMI chứa phần lớn phần mềm và cấu hình, dùng nó cho ASG
  • D — Dùng user data để cấu hình phần thay đổi thường xuyên khi khởi động

Vì sao đúng

Đề nêu vấn đề rõ: cấu hình instance mất quá lâu, làm chậm mở rộng khi lưu lượng tăng.

B — golden AMI loại bỏ phần lớn thời gian:

Trước: khởi động máy trắng
    → tải gói, cài phần mềm, cấu hình
    → mất nhiều phút
        ↓
Sau: khởi động từ AMI ĐÃ CÓ SẴN mọi thứ
    → chỉ còn thời gian khởi động hệ điều hành và ứng dụng
    → tính bằng chục giây

Dựng golden AMI:

# ① Khởi động instance, cài đặt và cấu hình đầy đủ
# ② Tạo AMI
aws ec2 create-image --instance-id i-0abc   --name "web-golden-2026-08" --no-reboot

Hoặc tự động hoá bằng EC2 Image Builder — dựng và kiểm thử AMI theo lịch.

D — user data cho phần thay đổi thường xuyên:

Không phải mọi thứ nên nướng vào AMI:
    → tham số môi trường
    → phiên bản mã ứng dụng
    → cấu hình theo AZ
        ↓
    Những thứ này đặt trong user data
    → đổi mà KHÔNG phải dựng lại AMI

#!/bin/bash
MOI_TRUONG=$(aws ssm get-parameter --name /web/moi-truong --query Parameter.Value --output text)
aws s3 cp s3://kho-trien-khai/ung-dung-latest.tar.gz /tmp/
tar -xzf /tmp/ung-dung-latest.tar.gz -C /opt/ung-dung
systemctl start ung-dung

Và hai đáp án bổ sung nhau — đó là mẫu chuẩn:

Golden AMI:  phần ỔN ĐỊNH (hệ điều hành, runtime, thư viện, agent)
User data:   phần THAY ĐỔI (cấu hình, phiên bản mã)
        ↓
    Cân bằng giữa tốc độ khởi động và tính linh hoạt

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

  • **C. Dùng user data cho TẤT CẢ phần mềm và cấu hình — đây là phương án gần nhất vì user data đúng là một phần của giải pháp, nhưng làm hết mọi thứ trong user data chính là cách làm hiện tại đang gây chậm: cài phần mềm lúc khởi động là phần tốn thời gian nhất.
  • **A. Nướng TẤT CẢ vào AMI, kể cả phần thay đổi thường xuyên — cứng nhắc quá mức: mỗi lần đổi một tham số cấu hình lại phải dựng AMI mới và cập nhật launch template. Nhanh nhưng không vận hành nổi.
  • **E. Bỏ ASG, chạy sẵn số máy tối đa — lãng phí lớn: trả tiền cho năng lực không dùng suốt ngày, và vẫn không co giãn được khi tải vượt dự kiến.

Ghi nhớ

Ba cách cấu hình EC2 khi khởi động — bảng phải thuộc: | Cách | Thời gian | Linh hoạt | |---|---|---| | Golden AMI | nhanh nhất | thấp — phải dựng lại AMI | | User data script | chậm — chạy lúc khởi động | cao | | Kết hợp cả hai | cân bằng | cân bằng ← khuyến nghị |

Nguyên tắc chia:

Vào AMI:      hệ điều hành, runtime, thư viện, agent giám sát,
              phụ thuộc ít đổi
Vào user data: biến môi trường, phiên bản mã, cấu hình theo AZ

Ba công cụ dựng AMI tự động: | Công cụ | Đặc điểm | |---|---| | EC2 Image Builder | dịch vụ được quản lý, có pipeline và kiểm thử | | HashiCorp Packer | công cụ phổ biến, đa nền tảng | | Script thủ công + create-image | đơn giản nhất |

EC2 Image Builder đáng dùng:

✓ pipeline dựng AMI theo lịch
✓ tự kiểm thử AMI trước khi phát hành
✓ tự phân phối sang nhiều Region và tài khoản
✓ tích hợp quét bảo mật

Ba cách rút ngắn thời gian mở rộng — theo mức hiệu quả: | Cách | Rút ngắn | |---|---| | Golden AMI | từ nhiều phút xuống chục giây | | Warm pool | xuống vài chục giây | | Giảm thời gian khởi động ứng dụng | tuỳ ứng dụng |

Warm pool là bước tiếp theo:

aws autoscaling put-warm-pool --auto-scaling-group-name asg-web   --min-size 10 --pool-state Stopped

Máy đã cấu hình sẵn ở trạng thái Stopped:
    ✓ KHÔNG tính phí instance
    ✓ chỉ tính phí EBS
    ✓ vào phục vụ trong vài chục giây

Ba trạng thái của warm pool: | Trạng thái | Chi phí | Tốc độ vào phục vụ | |---|---|---| | Stopped | chỉ EBS | vài chục giây | | Running | đầy đủ | nhanh nhất | | Hibernated | chỉ EBS | giữ nguyên bộ nhớ |

Ba đặc điểm của user data: | Đặc điểm | Chi tiết | |---|---| | Chạy với quyền root | | | Mặc định CHỈ chạy lần khởi động ĐẦU | | | Giới hạn 16 KB | dài hơn thì tải script từ S3 |

Ba lưu ý khi viết user data: | Lưu ý | Chi tiết | |---|---| | KHÔNG đặt bí mật trong đó | user data đọc được từ metadata service | | Ghi log để chẩn đoán | /var/log/cloud-init-output.log | | Báo lỗi rõ ràng | script hỏng làm instance khởi động không hoàn chỉnh |

Dòng đầu là lỗi bảo mật hay gặp:

# Bất kỳ ai vào được instance đều đọc được:
curl http://169.254.169.254/latest/user-data
        ↓
    Bí mật phải lấy từ Secrets Manager hoặc Parameter Store

Ba cấu hình ASG liên quan tới thời gian khởi động: | Cấu hình | Chi tiết | |---|---| | HealthCheckGracePeriod | đủ dài cho thời gian khởi động | | EstimatedInstanceWarmup | bỏ qua máy mới khi tính metric | | DefaultInstanceWarmup | đặt ở cấp ASG |

Grace period quá ngắn gây vòng lặp:

Ứng dụng cần 3 phút, grace period 60 giây
    → máy bị đánh giá hỏng trước khi sẵn sàng
    → ASG chấm dứt và khởi động máy khác
    → LẶP VÔ TẬN, không bao giờ có máy phục vụ

Ba lưu ý về quản lý AMI: | Lưu ý | Chi tiết | |---|---| | Đặt tên có phiên bản và ngày | dễ quay lại | | Dọn AMI cũ định kỳ | snapshot EBS tính phí | | Dùng SSM Parameter trỏ tới AMI mới nhất | launch template không phải sửa |

SSM Parameter cho AMI:

aws ssm put-parameter --name /web/ami-moi-nhat --type String   --value ami-0abc123 --overwrite

ImageId: resolve:ssm:/web/ami-moi-nhat

Launch template tự lấy AMI mới nhất mà không phải sửa phiên bản.

Ba cách triển khai mã ứng dụng: | Cách | Đặc điểm | |---|---| | Nướng vào AMI | nhanh nhất, nhưng mỗi lần triển khai là AMI mới | | Tải từ S3 trong user data | linh hoạt, thêm vài giây | | CodeDeploy | có triển khai dần và quay lại |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Thời gian từ khởi động tới InService | đo hiệu quả tối ưu | | GroupInServiceInstances | số máy đang phục vụ | | TargetResponseTime của ALB | tác động lên người dùng |

Ba việc nên làm khi tối ưu thời gian khởi động: | Việc | Chi tiết | |---|---| | ĐO thời gian hiện tại trước | biết cải thiện được bao nhiêu | | Xác định bước tốn thời gian nhất | log cloud-init có dấu thời gian | | Tối ưu bước đó trước | thường là cài gói |

Và một lời khuyên: hãy đo /var/log/cloud-init-output.log với dấu thời gian trước khi tối ưu. Nó cho biết chính xác bước nào chiếm phần lớn thời gian — và rất thường xuyên đó chỉ là một lệnh cài gói duy nhất, mà đưa vào golden AMI là giải quyết xong toàn bộ vấn đề.

Câu 638 Design High-Performing Architectures

A Big Data analytics company writes data and log files in Amazon S3 buckets. The company now wants to stream the existing data files as well as any ongoing file updates from Amazon S3 to Amazon Kinesis Data Streams.

As a Solutions Architect, which of the following would you suggest as the fastest possible way of building a solution for this requirement?

  1. A

    Leverage Amazon S3 event notification to trigger an AWS Lambda function for the file create event. The AWS Lambda function will then send the necessary data to Amazon Kinesis Data Streams
  2. B

    Leverage AWS Database Migration Service (AWS DMS) as a bridge between Amazon S3 and Amazon Kinesis Data Streams
  3. C

    Amazon S3 bucket actions can be directly configured to write data into Amazon Simple Notification Service (Amazon SNS). Amazon SNS can then be used to send the updates to Amazon Kinesis Data Streams
  4. D

    Configure Amazon EventBridge events for the bucket actions on Amazon S3. An AWS Lambda function can then be triggered from the Amazon EventBridge event that will send the necessary data to Amazon Kinesis Data Streams
Xem giải thích

Đáp án

B — Dùng AWS Database Migration Service (AWS DMS) làm cầu nối: lấy dữ liệu từ Amazon S3 và ghi vào Kinesis Data Streams.

Vì sao đúng

Đề nêu yêu cầu: cách NHANH NHẤT để xây dựng đường ống S3 → Kinesis Data Streams.

AWS DMS hỗ trợ:
    → S3 làm SOURCE endpoint
    → Kinesis Data Streams làm TARGET endpoint
        ↓
    Đây là kết nối SẴN CÓ, chỉ cần cấu hình
    → KHÔNG viết một dòng mã nào

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

# ① Endpoint nguồn: S3
aws dms create-endpoint --endpoint-identifier nguon-s3   --endpoint-type source --engine-name s3   --s3-settings '{"BucketName":"kho-du-lieu","ServiceAccessRoleArn":"<arn>",
                  "ExternalTableDefinition":"<dinh-nghia-bang>"}'

# ② Endpoint đích: Kinesis
aws dms create-endpoint --endpoint-identifier dich-kinesis   --endpoint-type target --engine-name kinesis   --kinesis-settings '{"StreamArn":"<arn-stream>","MessageFormat":"json",
                       "ServiceAccessRoleArn":"<arn>"}'

# ③ Tác vụ di chuyển
aws dms create-replication-task --replication-task-identifier s3-sang-kinesis   --source-endpoint-arn <arn-nguon> --target-endpoint-arn <arn-dich>   --replication-instance-arn <arn-instance>   --migration-type full-load-and-cdc   --table-mappings file://anh-xa.json

Và DMS hỗ trợ cả tải ban đầu lẫn thay đổi liên tục: | Kiểu | Việc | |---|---| | full-load | chuyển dữ liệu hiện có | | cdc | chỉ thay đổi mới | | full-load-and-cdc | cả hai — thường là lựa chọn đúng |

Với S3 làm nguồn, CDC hoạt động qua tệp thay đổi:

DMS đọc tệp trong thư mục cdcPath
    → mỗi tệp chứa các thay đổi mới
    → đẩy sang Kinesis theo thứ tự

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

  • **A. Viết Lambda đọc từ S3 và ghi vào Kinesis Data Streams — đây là phương án gần nhất và hoàn toàn khả thi, nhưng nó đòi viết, kiểm thử và bảo trì mã: xử lý lỗi, thử lại, phân trang, giới hạn thời gian chạy 15 phút với tệp lớn. Đề hỏi "fastest possible way of building".
  • **C. Cấu hình S3 event notification gửi thẳng tới Kinesis Data Streams — không phải đích được hỗ trợ: S3 event notification gửi tới SNS, SQS, Lambda và EventBridge, không gửi trực tiếp tới Kinesis Data Streams. (Qua EventBridge thì được, nhưng đó là kiến trúc khác và chỉ gửi metadata sự kiện, không gửi nội dung tệp.)
  • **D. Dùng AWS Glue — thêm công vận hành: Glue là dịch vụ ETL mạnh nhưng phải viết job, và nó không phải công cụ chuyên cho việc sao chép liên tục sang stream.

Ghi nhớ

Các endpoint được hỗ trợ của AWS DMS — bảng cần biết: | Vai trò | Ví dụ | |---|---| | Nguồn | Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, S3, DocumentDB | | Đích | RDS, Aurora, Redshift, S3, Kinesis Data Streams, MSK, OpenSearch, DynamoDB |

Điểm đáng nhớ: DMS không chỉ chuyển database sang database. Nó chuyển được sang stream và data lake, và đó là điều nhiều người không biết.

Ba loại tác vụ di chuyển: | Loại | Việc | |---|---| | Full load | chuyển dữ liệu hiện có một lần | | CDC | chỉ thay đổi — Change Data Capture | | Full load + CDC | cả hai, gián đoạn tối thiểu |

Ba thành phần của DMS: | Thành phần | Việc | |---|---| | Replication instance | máy chạy việc sao chép | | Endpoint | định nghĩa nguồn và đích | | Task | ánh xạ bảng và quy tắc chuyển đổi |

Và DMS Serverless bỏ được thành phần đầu:

aws dms create-replication-config   --replication-config-identifier s3-sang-kinesis   --replication-type full-load-and-cdc   --compute-config '{"MaxCapacityUnits":16,"MinCapacityUnits":2}'

DMS Serverless:
    ✓ không chọn cỡ replication instance
    ✓ tự co giãn theo tải
    ✓ trả theo lượng dùng

Ba đích của S3 event notification — bảng cần thuộc: | Đích | Hỗ trợ | |---|---| | SNS | ✅ | | SQS | ✅ | | Lambda | ✅ | | EventBridge | ✅ | | Kinesis Data Streams | ❌ trực tiếp |

Ba dịch vụ luồng dữ liệu của AWS: | Dịch vụ | Đặc điểm | |---|---| | Kinesis Data Streams | luồng thời gian thực, giữ 1–365 ngày, nhiều consumer | | Kinesis Data Firehose | nạp vào S3, Redshift, OpenSearch — không giữ lại | | Amazon MSK | Kafka được quản lý |

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 đọc lại | ✅ | ❌ | | Độ trễ | dưới 1 giây | ~60 giây trở lên | | Quản lý shard | có (hoặc on-demand) | hoàn toàn tự động |

Hai chế độ dung lượng của Kinesis Data Streams: | Chế độ | Đặc điểm | |---|---| | Provisioned | khai số shard, mỗi shard 1 MB/giây ghi | | On-demand | tự co giãn tới 200 MB/giây |

Ba lưu ý về shard: | Lưu ý | Chi tiết | |---|---| | 1 MB/giây hoặc 1.000 bản ghi/giây mỗi shard (ghi) | | | 2 MB/giây mỗi shard (đọc) | chia cho các consumer | | Enhanced fan-out | 2 MB/giây RIÊNG cho mỗi consumer |

Ba lưu ý về partition key của Kinesis: | Lưu ý | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | | | Phân bố ĐỀU để tránh hot shard | | | Cùng key = cùng shard = giữ THỨ TỰ | |

Ba metric cần theo dõi cho DMS: | Metric | Ý nghĩa | |---|---| | CDCLatencySource | độ trễ đọc từ nguồn | | CDCLatencyTarget | độ trễ ghi vào đích | | FullLoadThroughputRowsTarget | tốc độ tải ban đầu |

Ba metric của Kinesis: | Metric | Ý nghĩa | |---|---| | WriteProvisionedThroughputExceeded | bị throttle — cần thêm shard | | IteratorAgeMilliseconds | consumer tụt lại bao xa | | IncomingRecords | lượng bản ghi vào |

IteratorAgeMilliseconds là metric quan trọng nhất:

Tăng đều:
    → consumer xử lý chậm hơn tốc độ ghi
    → dữ liệu sẽ hết hạn trước khi xử lý xong
        ↓
    Phải tăng năng lực consumer ngay

Ba lưu ý khi dùng S3 làm nguồn DMS: | Lưu ý | Chi tiết | |---|---| | Cần ExternalTableDefinition mô tả cấu trúc | DMS không tự suy ra | | CDC dùng thư mục cdcPath riêng | | | IAM role phải đọc được bucket | |

Ba lưu ý về IAM cho DMS: | Role | Việc | |---|---| | dms-vpc-role | quản lý ENI trong VPC | | Role cho endpoint S3 | đọc bucket | | Role cho endpoint Kinesis | PutRecord vào stream |

Và một lời khuyên: hãy kiểm tra CDCLatencyTarget sau khi triển khai. Nếu nó tăng đều, đích không theo kịp nguồn — với Kinesis, nguyên nhân thường là thiếu shard, và phát hiện sớm dễ xử lý hơn nhiều so với khi dữ liệu đã bắt đầu bị bỏ lỡ.

Câu 639 Design Resilient Architectures

The engineering team at a global e-commerce company is currently reviewing their disaster recovery strategy. The team has outlined that they need to be able to quickly recover their application stack with a Recovery Time Objective (RTO) of 5 minutes, in all of the AWS Regions that the application runs. The application stack currently takes over 45 minutes to install on a Linux system.

As a Solutions architect, which of the following options would you recommend as the disaster recovery strategy?

  1. A

    Create an Amazon Machine Image (AMI) after installing the software and use this AMI to run the recovery process in other Regions
  2. B

    Store the installation files in Amazon S3 for quicker retrieval
  3. C

    Use Amazon EC2 user data to speed up the installation process
  4. D

    Create an Amazon Machine Image (AMI) after installing the software and copy the AMI across all Regions. Use this Region-specific AMI to run the recovery process in the respective Regions
Xem giải thích

Đáp án

D — Sao chép AMI của ứng dụng sang TẤT CẢ các Region đang triển khai; nếu một Region hỏng, dùng AMI của Region đó khởi động lại phiên bản mới.

Vì sao đúng

Đề nêu vấn đề rõ: AMI KHÔNG dùng được xuyên Region.

AMI là tài nguyên THEO REGION
    → AMI tạo ở us-east-1 KHÔNG khởi động instance ở eu-west-1
        ↓
    Muốn triển khai ở Region nào thì phải có AMI Ở REGION ĐÓ

Và đề nói rõ đây là ứng dụng đa Region:

"deployed in MULTIPLE AWS REGIONS to ensure high availability"
        ↓
    Mỗi Region cần AMI riêng
    → sao chép trước, không phải lúc sự cố

Sao chép AMI:

aws ec2 copy-image --source-region ap-northeast-1   --source-image-id ami-0abc123   --region eu-west-1 --name "web-golden-2026-08"   --encrypted --kms-key-id <arn-khoa-eu>

Và việc sao chép trước là điểm mấu chốt:

Sao chép LÚC XẢY RA SỰ CỐ:
    → mất nhiều phút tới hàng giờ tuỳ kích thước
    → mà Region nguồn có thể đang hỏng
        ↓
    Sao chép TRƯỚC = sẵn sàng ngay khi cần

Tự động hoá bằng EC2 Image Builder:

Image Builder distribution configuration:
    → tự phân phối AMI sang mọi Region đã khai
    → mỗi lần dựng AMI mới
        ↓
    Không phải nhớ sao chép thủ công

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

  • **C. Sao chép EBS snapshot sang Region khác rồi tạo AMI ở đó — đây là phương án gần nhất và thực sự hoạt động được, nhưng nó là cách làm vòng vèo hơn: copy-image làm đúng việc đó trong một lệnh và giữ nguyên cấu hình khởi động (kernel, block device mapping). Và nó vẫn là thao tác phải làm lúc sự cố nếu chỉ chuẩn bị snapshot.
  • **B. Chia sẻ AMI sang các tài khoản ở Region khác — hiểu sai cơ chế: chia sẻ AMI cho phép tài khoản khác trong CÙNG Region dùng nó. Chia sẻ không làm AMI vượt qua ranh giới Region.
  • **A. AMI dùng được ở mọi Region mà không cần làm gì — sai về mặt kỹ thuật: đây chính là hiểu lầm mà câu hỏi kiểm tra.

Ghi nhớ

Phạm vi của các tài nguyên AWS — bảng phải thuộc: | Tài nguyên | Phạm vi | |---|---| | AMI | REGION ← câu này | | EBS snapshot | REGION | | EBS volume | AZ | | Security group | VPC (nên là Region) | | Key pair | REGION | | Elastic IP | REGION | | S3 bucket | REGION (tên toàn cầu) | | IAM role, user | TOÀN CẦU | | Route 53 hosted zone | TOÀN CẦU | | CloudFront distribution | TOÀN CẦU |

Bảng này bị hỏi rất nhiều — nên thuộc lòng.

Ba thao tác với AMI xuyên ranh giới: | Thao tác | Việc | |---|---| | copy-image | sang REGION khác ← câu này | | modify-image-attribute --launch-permission | sang TÀI KHOẢN khác, CÙNG Region | | Kết hợp cả hai | sang tài khoản khác ở Region khác |

Ba lưu ý khi sao chép AMI: | Lưu ý | Chi tiết | |---|---| | AMI mới có ID KHÁC | phải cập nhật launch template | | Snapshot cũng được sao chép theo | tính phí ở Region đích | | Khoá KMS phải là khoá CỦA REGION ĐÍCH | |

Dòng cuối là bẫy hay gặp:

AMI mã hoá bằng khoá KMS của Region nguồn
    → sao chép sang Region khác PHẢI khai khoá của Region đích
    → khoá KMS là tài nguyên THEO REGION
        ↓
    Thiếu tham số này thì lệnh thất bại

Ba cách quản lý AMI ID giữa các Region: | Cách | Chi tiết | |---|---| | SSM Parameter Store mỗi Region | launch template tham chiếu tham số | | CloudFormation Mappings | ánh xạ Region → AMI ID | | Ghi tay trong tài liệu | dễ lỗi |

Cách đầu là tốt nhất:

aws ssm put-parameter --region eu-west-1 --name /web/ami-moi-nhat   --type String --value ami-0xyz789 --overwrite

ImageId: resolve:ssm:/web/ami-moi-nhat

Launch template giống hệt nhau ở mọi Region.

Ba thành phần của AMI: | Thành phần | Chi tiết | |---|---| | Một hoặc nhiều EBS snapshot | hoặc template cho instance store | | Quyền khởi động | ai dùng được | | Block device mapping | volume nào gắn vào đâu |

Ba cách tạo AMI: | Cách | Đặc điểm | |---|---| | create-image từ instance | đơn giản nhất | | EC2 Image Builder | có pipeline, kiểm thử, phân phối tự động | | Packer | công cụ bên thứ ba |

EC2 Image Builder giải quyết trọn vẹn câu hỏi này:

{"distributions": [
  {"region": "ap-northeast-1", "amiDistributionConfiguration": {...}},
  {"region": "eu-west-1",      "amiDistributionConfiguration": {...}},
  {"region": "us-east-1",      "amiDistributionConfiguration": {...}}]}

Mỗi lần dựng AMI mới, nó tự sao chép sang mọi Region.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Snapshot ở mỗi Region tính phí riêng | | | Truyền dữ liệu khi sao chép | tính một lần | | Dọn AMI cũ định kỳ | snapshot tích tụ rất nhanh |

Dọn AMI cũ:

aws ec2 deregister-image --image-id ami-cu
aws ec2 delete-snapshot --snapshot-id snap-cu   # phải xoá RIÊNG

Huỷ đăng ký AMI KHÔNG xoá snapshot — đây là nguồn chi phí âm thầm phổ biến.

Ba lưu ý cho kiến trúc đa Region: | Lưu ý | Chi tiết | |---|---| | AMI phải có ở mọi Region | ← câu này | | Dữ liệu phải sao chép | S3 CRR, Aurora Global, DynamoDB Global Tables | | DNS phải chuyển vùng được | Route 53 health check |

Ba chiến lược khôi phục thảm hoạ: | Chiến lược | RTO | Chi phí | |---|---|---| | Backup & Restore | giờ | thấp nhất | | Pilot Light | chục phút | thấp | | Warm Standby | phút | vừa | | Multi-Site Active/Active | gần bằng 0 | cao nhất |

Đề mô tả kiến trúc active/active (đã triển khai ở nhiều Region), nên AMI sẵn sàng ở mọi Region là điều kiện tối thiểu.

Ba việc nên kiểm tra định kỳ: | Việc | Chi tiết | |---|---| | AMI mới nhất đã có ở MỌI Region chưa | | | Thử khởi động instance từ AMI ở Region phụ | | | Diễn tập chuyển vùng | |

Và một lời khuyên: hãy thử khởi động một instance từ AMI ở Region dự phòng mỗi quý. AMI có thể đã sao chép nhưng thiếu security group, subnet hoặc key pair tương ứng ở Region đó — và phát hiện điều đó trong lúc sự cố là muộn nhất có thể.

Câu 640 Design Secure Architectures

A company wants to grant access to an Amazon S3 bucket to users in its own AWS account as well as to users in another AWS account. Which of the following options can be used to meet this requirement?

  1. A

    Use permissions boundary to grant permission to users in its account as well as to users in another account
  2. B

    Use either a bucket policy or a user policy to grant permission to users in its account as well as to users in another account
  3. C

    Use a bucket policy to grant permission to users in its account as well as to users in another account
  4. D

    Use a user policy to grant permission to users in its account as well as to users in another account
Xem giải thích

Đáp án

C — Viết bucket policy trên bucket S3 cấp quyền cho vai trò IAM của Account B; ứng dụng dùng vai trò đó để truy cập.

Vì sao đúng

Đề nêu tình huống truy cập xuyên tài khoản, và ở đây bucket policy là cơ chế bắt buộc.

Truy cập xuyên tài khoản cần CẢ HAI PHÍA cho phép:
    ① Chính sách phía TÀI NGUYÊN (bucket policy) — Account A
    ② Chính sách phía DANH TÍNH (IAM policy) — Account B
        ↓
    Thiếu một trong hai là bị từ chối

Và điểm quyết định: chỉ chủ bucket mới cấp được quyền cho principal ngoài tài khoản.

Account B tự cấp quyền cho mình trong IAM policy:
    → KHÔNG đủ
    → Account A vẫn từ chối vì bucket policy không cho phép
        ↓
    Bucket policy là mắt xích BẮT BUỘC

Bucket policy ở Account A:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"AWS": "arn:aws:iam::<account-b>:role/vai-tro-ung-dung"},
   "Action": ["s3:GetObject", "s3:PutObject"],
   "Resource": "arn:aws:s3:::kho-du-lieu/*"}]}

Và IAM policy ở Account B:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::kho-du-lieu/*"}

Vấn đề quyền sở hữu object khi ghi xuyên tài khoản:

Account B ghi object vào bucket của Account A
    → object thuộc về ACCOUNT B (theo mặc định cũ)
    → Account A không đọc được object trong chính bucket của mình
        ↓
    Sửa bằng Bucket owner enforced (mặc định từ 2023)

aws s3api put-bucket-ownership-controls --bucket kho-du-lieu   --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

Từ tháng 4/2023, mọi bucket mới mặc định dùng chế độ này — ACL bị vô hiệu và chủ bucket luôn sở hữu mọi object.

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

  • **B. Tạo IAM policy ở Account B cấp quyền truy cập bucket của Account A — đây là phương án gần nhất và là MỘT NỬA của giải pháp đúng, nhưng một mình nó không đủ: không có bucket policy phía Account A, mọi request vẫn bị từ chối. Bạn không thể tự cấp cho mình quyền vào tài nguyên của người khác.
  • **A. Dùng ACL của object để cấp quyền cho Account B — cách làm cũ AWS khuyến nghị KHÔNG dùng: ACL bị vô hiệu hoá mặc định trên bucket mới từ 2023, chỉ cấp được ở mức từng object, và không diễn đạt được điều kiện phức tạp.
  • **D. Tạo IAM user ở Account A rồi chia sẻ access key cho Account B — rủi ro bảo mật nghiêm trọng: chia sẻ khoá dài hạn là cách làm AWS chống lại rõ ràng. Khoá bị lộ, không xoay vòng, không truy vết được ai dùng.

Ghi nhớ

Hai loại chính sách trong IAM — bảng phải thuộc: | Loại | Gắn vào | Có Principal | |---|---|---| | Identity-based | user, group, role | ❌ | | Resource-based | bucket S3, hàng đợi SQS, KMS key, Lambda | ✅ |

Quy tắc vàng cho truy cập xuyên tài khoản:

CẢ HAI phía phải cho phép — resource policy VÀ identity policy. Trong CÙNG tài khoản: chỉ cần MỘT trong hai.

Dòng thứ hai là chi tiết ít người biết:

Cùng tài khoản: bucket policy HOẶC IAM policy cho phép là đủ
Khác tài khoản: PHẢI có cả hai

Ba dịch vụ có resource-based policy: | Dịch vụ | Chính sách | |---|---| | S3 | bucket policy | | SQS, SNS | queue/topic policy | | KMS | key policy — BẮT BUỘC phải có | | Lambda | resource policy | | Secrets Manager | resource policy |

KMS đặc biệt:

Key policy là BẮT BUỘC
    → IAM policy một mình KHÔNG bao giờ đủ
    → key policy phải cho phép, dù cùng tài khoản

Hai mô hình truy cập xuyên tài khoản: | Mô hình | Cơ chế | |---|---| | Resource-based policy | principal ở tài khoản khác truy cập TRỰC TIẾP | | Assume role (sts:AssumeRole) | lấy credential tạm của tài khoản kia |

Khác biệt quan trọng:

Resource-based policy:
    → principal GIỮ NGUYÊN danh tính của mình
    → truy cập được cả tài nguyên ở tài khoản mình

Assume role:
    → ĐỔI sang danh tính của tài khoản kia
    → mất quyền ở tài khoản gốc trong phiên đó

Với S3, resource-based policy là cách đơn giản hơn.

Ba cơ chế kiểm soát quyền S3: | Cơ chế | Trạng thái | |---|---| | Bucket policy | khuyến nghị | | IAM policy | khuyến nghị | | ACL | cũ — AWS khuyến nghị KHÔNG dùng | | S3 Access Points | cho nhiều ứng dụng dùng chung bucket |

Ba chế độ Object Ownership: | Chế độ | Đặc điểm | |---|---| | Bucket owner enforced (mặc định mới) | ACL VÔ HIỆU, chủ bucket sở hữu mọi object | | Bucket owner preferred | chủ bucket sở hữu nếu ACL đúng | | Object writer | người ghi sở hữu (cũ) |

Ba điều kiện hữu ích trong bucket policy: | Điều kiện | Việc | |---|---| | aws:PrincipalOrgID | giới hạn trong tổ chức AWS Organizations | | aws:SourceVpce | chỉ từ VPC endpoint | | s3:x-amz-server-side-encryption | bắt buộc mã hoá |

aws:PrincipalOrgID rất tiện:

{"Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-abc123"}}}

Cho phép mọi tài khoản trong tổ chức mà không phải liệt kê từng ARN.

Ba công cụ kiểm tra quyền: | Công cụ | Việc | |---|---| | IAM Access Analyzer | phát hiện tài nguyên chia sẻ ra ngoài | | IAM Policy Simulator | thử một hành động cụ thể | | CloudTrail | ai đã truy cập gì |

IAM Access Analyzer nên bật ở mọi tài khoản — nó phát hiện bucket chia sẻ ngoài ý muốn.

Ba nguyên nhân "Access Denied" xuyên tài khoản: | Nguyên nhân | Kiểm tra | |---|---| | Thiếu bucket policy | ← câu này | | Thiếu IAM policy phía kia | | | SCP của Organizations chặn | SCP thắng mọi Allow | | KMS key policy không cho phép | với bucket mã hoá SSE-KMS |

Dòng cuối là bẫy hay gặp:

Bucket mã hoá bằng SSE-KMS
    → bucket policy cho phép ✓
    → nhưng KEY POLICY không cho phép Account B
        ↓
    Vẫn Access Denied — và thông báo không nói rõ là do KMS

Ba nguyên tắc bảo mật: | Nguyên tắc | Chi tiết | |---|---| | Không bao giờ chia sẻ access key | dùng role | | Quyền tối thiểu | chỉ hành động và tiền tố cần thiết | | Bật Block Public Access | ở cấp tài khoản |

Và một lời khuyên: hãy kiểm tra cả key policy của KMS khi gặp Access Denied trên bucket mã hoá. Bucket policy và IAM policy đúng hết mà vẫn bị từ chối là dấu hiệu điển hình của việc thiếu quyền kms:Decrypt cho principal ngoài tài khoản — và thông báo lỗi của S3 không hề nhắc tới KMS.