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

Tìm thấy 1221 câu.

Câu 181 Domain - Continuous Improvement for Existing Solutions

The www.tutorialsdojonews.com website is using the WordPress platform that runs on a fleet of Amazon EC2 instances behind an application load balancer to deliver news around the globe. There are a lot of customers complaining about the slow loading time of the website. The solutions architect has created a CloudFront distribution and set the ALB as the origin to improve the read performance. After several days, the IT Security team reported that the setup is not secure and it should enable end-to-end HTTPS connections from the user's browser to the origin via CloudFront.

Which of the following options should the solutions architect implement to satisfy the above requirements?

A Use third-party CA certificate on both the origin and CloudFront.
B
Configure the CloudFront distribution to redirect HTTP to HTTPS protocol. Generate a new SSL certificate on AWS Certificate Manager and use it as the CloudFront distribution and origin certificate.
C Use a self-signed certificate in both the origin and CloudFront.
D
Configure CloudFront to use its default certificate. Configure the CloudFront distribution to redirect HTTP to HTTPS protocol. For the origin, generate a new SSL certificate on AWS Certificate Manager.

Xem giải thích

Đáp án

**B — Cấu hình phân phối CloudFront chuyển hướng HTTP sang HTTPS; tạo chứng chỉ SSL mới trên AWS Certificate Manager và dùng nó cho cả phân phối CloudFront lẫn origin.

Vì sao đúng

Đề yêu cầu HTTPS đầu-cuối, tức là hai đoạn đường đều phải mã hoá:

Trình duyệt → CloudFront: cần chứng chỉ
  cho tên miền www.tutorialsdojonews.com
        ↓
    CloudFront → ALB: cần chứng chỉ
      hợp lệ trên ALB
        ↓
    Cả hai đều lấy từ ACM

⚠ Nhưng phải chú ý ràng buộc Region — hai chứng chỉ ở hai nơi: | Dùng cho | Region | |---|---| | CloudFront | BẮT BUỘC us-east-1 | | ALB | cùng Region với ALB |

Đây là lỗi cấu hình phổ biến nhất
    → yêu cầu chứng chỉ ở đúng Region
      của ALB rồi tưởng CloudFront
      cũng dùng được

Hai lệnh cho hai chứng chỉ:

aws acm request-certificate --region us-east-1 \
  --domain-name www.tutorialsdojonews.com \
  --validation-method DNS

aws acm request-certificate --region ap-southeast-1 \
  --domain-name goc.tutorialsdojonews.com \
  --validation-method DNS

⚠ Vì sao chứng chỉ ACM dùng được ở ALB nhưng KHÔNG cài lên EC2:

Chứng chỉ công khai ACM không xuất được
    → không có API lấy khoá riêng
        ↓
    Nhưng ALB là dịch vụ AWS
    → nó dùng chứng chỉ trực tiếp
      từ ACM
        ↓
    Origin ở đây LÀ ALB
    → nên phương án này chạy được

Cấu hình đầu-cuối:

{"DefaultCacheBehavior": {
  "ViewerProtocolPolicy": "redirect-to-https"},
 "Origins": {"Items": [{
   "Id": "alb-wordpress",
   "DomainName": "goc.tutorialsdojonews.com",
   "CustomOriginConfig": {
     "OriginProtocolPolicy": "https-only",
     "OriginSslProtocols": {"Quantity": 1, "Items": ["TLSv1.2"]}}}]},
 "ViewerCertificate": {
   "ACMCertificateArn": "<arn-us-east-1>",
   "SSLSupportMethod": "sni-only",
   "MinimumProtocolVersion": "TLSv1.2_2021"}}

⚠ Hai thiết lập giao thức, hai đoạn đường: | Thiết lập | Đoạn | |---|---| | ViewerProtocolPolicy | người dùng ↔ CloudFront | | OriginProtocolPolicy | CloudFront ↔ origin |

Chỉ đặt cái đầu
    → đoạn CloudFront–ALB vẫn HTTP
    → KHÔNG phải đầu-cuối

⚠ Và CloudFront KIỂM chứng chỉ của origin — khác với ALB:

ALB tới target: KHÔNG kiểm chứng chỉ
    → tự ký cũng được
        ↓
    CloudFront tới origin: CÓ kiểm
    → chứng chỉ tự ký bị từ chối
        ↓
    Đây là lý do phương án C sai

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Miễn phí và tự gia hạn | | | Không đoạn nào ở dạng rõ | | | Không phải mua chứng chỉ hằng năm | |

⚠ Vì sao chứng chỉ mặc định của CloudFront không dùng được ở đây:

Chứng chỉ mặc định chỉ hợp lệ cho
  `*.cloudfront.net`
        ↓
    Trang dùng tên miền riêng
      `www.tutorialsdojonews.com`
    → trình duyệt báo lỗi tên miền
      không khớp

Đây là lý do phương án D sai.

Xác thực bằng DNS để tự gia hạn:

aws acm describe-certificate --certificate-arn <arn> \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord'

⚠ Và giữ bản ghi CNAME xác thực vĩnh viễn:

Xoá nó sau khi cấp chứng chỉ
    → ACM không xác thực lại được
      khi gia hạn
        ↓
    Chứng chỉ hết hạn
    → đây là nguyên nhân phổ biến
      nhất của sự cố chứng chỉ

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

**A. Dùng chứng chỉ từ CA bên thứ ba cho cả origin lẫn CloudFront — đây là phương án gần nhất và về mặt kỹ thuật hoàn toàn chạy được, nhưng tốn tiền mua và không tự gia hạn; ACM cho cùng kết quả mà miễn phí.
**C. Dùng chứng chỉ tự ký ở cả hai nơi — trình duyệt báo lỗi bảo mật, và CloudFront từ chối origin có chứng chỉ tự ký.
**D. Dùng chứng chỉ mặc định của CloudFront, chuyển hướng HTTP sang HTTPS, và sinh chứng chỉ ACM cho origin — chứng chỉ mặc định không hợp lệ cho tên miền riêng.

Ghi nhớ

⚠ Ba đoạn đường và chứng chỉ tương ứng — bảng phải thuộc: | Đoạn | Chứng chỉ | |---|---| | Người dùng ↔ CloudFront | ACM ở us-east-1 | | CloudFront ↔ ALB | ACM cùng Region ALB | | ALB ↔ EC2 | tự ký cũng được (ALB không kiểm) |

Từ khoá nhận diện:

"end-to-end HTTPS" → cả hai protocol policy + chứng chỉ ở origin "custom domain on CloudFront" → ACM ở us-east-1 "certificate on EC2 directly" → KHÔNG xuất được từ ACM "internal certificates" → ACM Private CA

⚠ ACM không xuất được khoá riêng — hệ quả:

Cần chứng chỉ trên chính EC2
    → phải mua từ nhà cung cấp ngoài
    → hoặc dùng Let's Encrypt
    → hoặc ACM Private CA (nội bộ)

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ công khai miễn phí với dịch vụ tích hợp | | | Xác thực DNS để tự gia hạn | | | Wildcard chỉ phủ một cấp tên miền con | |

⚠ Xác thực email KHÔNG tự gia hạn: | Cách | Gia hạn tự động | |---|---| | DNS | CÓ, miễn bản ghi CNAME còn đó | | Email | không — phải bấm link mỗi lần |

Ba lưu ý về SSL policy: | Lưu ý | Chi tiết | |---|---| | Đặt MinimumProtocolVersion từ TLS 1.2 | | | Bỏ TLS 1.0/1.1 để đạt tuân thủ | | | TLS 1.3 nếu client hỗ trợ | |

Ba lưu ý về WordPress sau CloudFront: | Lưu ý | Chi tiết | |---|---| | Cấu hình WP_HOME và WP_SITEURL dùng https | | | Xử lý header X-Forwarded-Proto | | | Không cache trang quản trị /wp-admin | |

⚠ Vòng lặp chuyển hướng là lỗi kinh điển của WordPress sau CDN:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Không có đoạn này
    → WordPress thấy request là HTTP
    → chuyển hướng sang HTTPS
    → CloudFront gọi lại origin bằng HTTPS
    → WordPress vẫn thấy HTTP
        ↓
    Vòng lặp chuyển hướng vô hạn

Ba lưu ý về cache behavior cho WordPress: | Đường dẫn | Cách xử lý | |---|---| | /wp-admin/* | KHÔNG cache, chuyển tiếp mọi cookie | | /wp-content/uploads/* | cache TTL dài | | Trang công khai | cache TTL ngắn |

Ba lưu ý về theo dõi hết hạn: | Lưu ý | Chi tiết | |---|---| | ACM gửi sự kiện EventBridge trước 45 ngày | | | Config rule acm-certificate-expiration-check | | | Chứng chỉ nhập từ ngoài không tự gia hạn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl -I http://... xem có 301 | | | openssl s_client với cả CloudFront và ALB | | | Kiểm không còn nội dung hỗn hợp HTTP | |

Và một lời khuyên: hãy kiểm tra header X-Forwarded-Proto trong ứng dụng trước khi bật HTTPS đầu-cuối. Với WordPress và nhiều framework khác, việc thiếu một dòng xử lý header đó biến toàn bộ cấu hình đúng đắn thành một vòng lặp chuyển hướng vô hạn.

Câu 182 Domain - Design for New Solutions

A company recently adopted a modern design for its legacy application. The new application is now suitable for native cloud deployments so the CI/CD pipelines need to be updated as well. The following deployment requirements are needed to support the new application:

- The pipeline should support deployments of new versions several times every hour.

- The pipeline should be able to quickly rollback to the previous application version if any problems are encountered on the new version.

Which of the following options is the recommended solution to meet the company requirements?

A
Reconfigure the pipeline to create a Staging environment on AWS Elastic Beanstalk. Deploy the newer version on the Staging environment. Swap the Staging and Production environment URLs to shift traffic to the newer version.
B
Package the newer application version on AMIs including the needed configurations. Update the Launch Template of the Auto Scaling group and trigger a scale-out to use this new AMI. Ensure that the configured termination policy is to delete the old instances using the previous AMI.
C
Use Amazon Lightsail to handle the deployment of new Amazon EC2 instances and the needed load balancers. Add an Amazon EC2 user data script to download the latest application artifact from an Amazon S3 bucket. Use a weighted routing policy on Amazon Route 53 to slowly shift traffic to the newer version.
D
Package the newer application version on AMIs including the needed configurations. Reconfigure the CI/CD pipeline to deploy this AMI by replacing the current Amazon EC2 instances.

Xem giải thích

Đáp án

**A — Cấu hình lại pipeline để tạo một môi trường Staging trên Elastic Beanstalk, triển khai phiên bản mới lên đó, rồi hoán đổi URL giữa Staging và Production để chuyển lưu lượng sang phiên bản mới.

Vì sao đúng

Đề nêu hai yêu cầu, và đây là mô tả chính xác của triển khai blue/green: | Yêu cầu | Cách đáp ứng | |---|---| | Triển khai vài lần mỗi giờ | hoán đổi URL mất vài giây | | Quay lui nhanh khi có vấn đề | hoán đổi ngược lại |

⚠ Đặc tính quyết định: quay lui nhanh như triển khai:

Môi trường cũ VẪN CÒN NGUYÊN sau
  khi hoán đổi
        ↓
    Có vấn đề: hoán đổi ngược
    → mất vài giây
        ↓
    Không phải triển khai lại
      phiên bản cũ

Hoán đổi:

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name moi-truong-staging \
  --destination-environment-name moi-truong-san-xuat

⚠ Cơ chế bên dưới là đổi bản ghi CNAME:

Beanstalk đổi CNAME của hai môi trường
  cho nhau
        ↓
    Nghĩa là có độ trễ DNS
    → người dùng đang có bản ghi cũ
      trong cache vẫn tới môi trường cũ
        ↓
    Cả hai môi trường phải chạy được
      trong vài phút sau khi hoán đổi

⚠ Và điều đó có hệ quả với CSDL:

Hai môi trường cùng trỏ vào một CSDL
    → thay đổi schema phải TƯƠNG THÍCH
      NGƯỢC
        ↓
    Thêm cột: an toàn
    → xoá cột hoặc đổi kiểu: hỏng
      môi trường cũ
        ↓
    Nguyên tắc: expand rồi mới contract

Mẫu expand–contract:

Lần 1: THÊM cột mới, mã ghi cả hai cột
    ↓
Lần 2: mã chỉ đọc cột mới
    ↓
Lần 3: XOÁ cột cũ
        ↓
    Mỗi bước đều quay lui được

⚠ Đừng để Beanstalk quản lý CSDL:

Beanstalk tạo được RDS trong môi trường
    → nhưng xoá môi trường là XOÁ CSDL
        ↓
    Và hoán đổi hai môi trường nghĩa là
      hai CSDL khác nhau
    → luôn tạo RDS RIÊNG bên ngoài

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Quay lui nhanh bằng cách hoán đổi ngược | | | Kiểm thử được trên môi trường thật trước | | | Không có thời gian chết khi chuyển | |

⚠ Vì sao phương án B và D chậm hơn hẳn:

Dựng AMI mới cho mỗi lần triển khai
    → mất hàng chục phút mỗi lần
        ↓
    Đề nói "vài lần MỖI GIỜ"
    → không kịp

⚠ Và quay lui bằng AMI cũng chậm:

Phải đổi launch template về AMI cũ
    → rồi thay lại toàn bộ instance
        ↓
    Hàng chục phút
    → so với vài giây của hoán đổi

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

**B. Đóng gói phiên bản mới thành AMI, cập nhật launch template và mở rộng ASG để dùng AMI mới, đặt chính sách thu hồi xoá instance dùng AMI cũ — đây là phương án gần nhất và là mẫu rolling update hợp lệ, nhưng dựng AMI mất hàng chục phút mỗi lần, không đáp ứng được tần suất vài lần mỗi giờ; và quay lui cũng chậm tương tự.
**D. Đóng gói thành AMI và cấu hình pipeline thay thế toàn bộ instance hiện tại — cùng vấn đề tốc độ, và thay toàn bộ cùng lúc còn gây gián đoạn.
**C. Dùng Lightsail triển khai EC2 và load balancer, tải artifact bằng user data, dùng weighted routing của Route 53 — Lightsail dành cho ứng dụng đơn giản, không tích hợp với pipeline CI/CD theo cách này; và weighted routing chuyển lưu lượng dần chứ không cho quay lui tức thì.

Ghi nhớ

⚠ Năm kiểu triển khai của Elastic Beanstalk — bảng phải thuộc: | Kiểu | Thời gian chết | Quay lui | |---|---|---| | All at once | CÓ | triển khai lại | | Rolling | không, nhưng giảm công suất | triển khai lại | | Rolling with additional batch | không, giữ nguyên công suất | triển khai lại | | Immutable | không, dựng instance mới | xoá instance mới | | Blue/Green (swap URL) | không | HOÁN ĐỔI NGƯỢC, vài giây |

Từ khoá nhận diện:

"deploy several times an hour, quick rollback" → blue/green swap "no downtime, keep capacity" → rolling with additional batch "safest rolling deployment" → immutable "gradual traffic shift" → weighted routing hoặc canary

⚠ Immutable so với blue/green:

Immutable: dựng instance mới trong
  CÙNG môi trường
    → quay lui bằng cách xoá chúng
        ↓
    Blue/Green: hai môi trường riêng
    → quay lui bằng hoán đổi
    → nhanh hơn nhưng tốn gấp đôi
      tài nguyên trong lúc chuyển

Ba lưu ý về hoán đổi CNAME: | Lưu ý | Chi tiết | |---|---| | Có độ trễ DNS, giữ cả hai môi trường một lúc | | | Đặt TTL ngắn cho bản ghi | | | Kiểm thử môi trường staging trước khi hoán đổi | |

Ba lưu ý về CSDL: | Lưu ý | Chi tiết | |---|---| | Tạo RDS bên ngoài Beanstalk | | | Thay đổi schema phải tương thích ngược | | | Expand rồi mới contract | |

⚠ Đây là ràng buộc quan trọng nhất của blue/green:

Hai phiên bản mã cùng chạy trong
  vài phút
        ↓
    CSDL phải phục vụ được CẢ HAI
    → mọi thay đổi schema phá vỡ
      tương thích đều gây sự cố

Ba lưu ý về phiên người dùng: | Lưu ý | Chi tiết | |---|---| | Phiên trong bộ nhớ instance sẽ mất khi chuyển | | | Lưu phiên trong ElastiCache hoặc DynamoDB | | | Ứng dụng phải stateless | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Hai môi trường chạy song song trong lúc chuyển | | | Thu nhỏ môi trường cũ sau khi ổn định | | | Hoặc xoá sau vài giờ nếu chắc chắn | |

⚠ Nhưng đừng xoá quá sớm:

Vấn đề của phiên bản mới có thể
  chỉ lộ ra sau vài giờ
        ↓
    Giữ môi trường cũ ít nhất
      một chu kỳ tải đầy đủ
    → rồi mới xoá

Ba lưu ý về pipeline: | Lưu ý | Chi tiết | |---|---| | Chạy kiểm thử tự động trên staging trước khi hoán đổi | | | Có bước duyệt tay cho sản xuất nếu cần | | | Ghi lại lịch sử mọi lần triển khai | |

Ba lưu ý về giám sát sau triển khai: | Lưu ý | Chi tiết | |---|---| | Theo dõi tỷ lệ lỗi trong 15 phút đầu | | | So độ trễ trước và sau | | | Có kịch bản hoán đổi ngược sẵn sàng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hoán đổi thử rồi hoán đổi ngược, bấm giờ | | | Kiểm ứng dụng chạy được trên staging trước | | | Xác nhận hai phiên bản dùng chung CSDL không xung đột | |

Và một lời khuyên: hãy luyện tập thao tác hoán đổi ngược ít nhất một lần trước khi cần tới nó. Giá trị của blue/green nằm hoàn toàn ở việc quay lui trong vài giây — và điều đó chỉ đúng nếu người trực biết chính xác cần gõ lệnh gì mà không phải tra tài liệu giữa cơn sự cố.

Câu 183 Domain - Continuous Improvement for Existing Solutions

A company has multiple database servers hosted on extra-large Reserved Amazon EC2 instances which are all deployed to a private subnet. A single NAT instance is in place to allow the servers to fetch data from the Internet. The solutions architect noticed that whenever there is a new database patch update, the processing takes a lot of time which results in request time-outs. As a workaround, the developers just manually re-run the database patch update on the servers that failed to complete the process the first time.

What could be the possible root cause of the issue and what steps should the solutions architect implement to solve it?

A The database servers are not in a Placement Group, which means that the inter-instance communications are not optimal. This is causing the timeout issue. Place all the database servers on either a Spread or a Cluster type Placement group to fix the problem.
B The timeout behavior of a NAT instance is that, when there is a connection time out, it sends a FIN packet to resources behind the NAT instance to close the connection. It does not attempt to continue the connection which is why some database updates are failing. For better performance, use a NAT Gateway instead.
C There is no Internet Gateway (IGW) attached to the VPC. Simply add an IGW and the issue will be resolved.
D There is no Virtual Private Gateway attached to the VPC that links up to the Customer Gateway of the database provider. Simply add the missing gateway and the issue will be resolved

Xem giải thích

Đáp án

**B — Hành vi hết thời gian chờ của NAT instance là gửi gói FIN để đóng kết nối chứ không cố duy trì nó, nên một số lần cập nhật bản vá thất bại; nên dùng NAT gateway để có hiệu năng tốt hơn.

Vì sao đúng

Đề mô tả đúng một khác biệt hành vi giữa hai loại NAT: | Loại | Khi kết nối hết thời gian chờ | |---|---| | NAT instance | gửi gói FIN đóng kết nối | | NAT gateway | gửi gói RST |

⚠ Khác biệt này có hệ quả thực tế:

Bản vá CSDL tải rất lâu
    → có khoảng im lặng dài trên
      kết nối
        ↓
    NAT đóng kết nối vì hết hạn nhàn rỗi
    → tiến trình tải nhận tín hiệu đóng
    → thất bại giữa chừng

⚠ Cả hai loại NAT đều có thời gian nhàn rỗi 350 giây:

Kết nối không có lưu lượng 350 giây
    → NAT bỏ khỏi bảng theo dõi
        ↓
    Đây là hành vi CHUNG
    → khác biệt là cách báo cho
      hai đầu biết

⚠ Nhưng vấn đề thật sự lớn hơn: NAT instance là một điểm hỏng: | Tiêu chí | NAT instance | NAT gateway | |---|---|---| | Sẵn sàng | một máy, tự lo | dư thừa trong AZ | | Băng thông | theo loại instance | tới 100 Gbps, tự co giãn | | Vá lỗi và giám sát | bạn lo | AWS lo | | Kết nối đồng thời | theo cấu hình HĐH | 55.000 mỗi đích |

Đề nói "một NAT instance duy nhất"
    → nhiều CSDL cùng tải bản vá
    → NAT instance quá tải
        ↓
    Đây có thể là nguyên nhân
      lớn hơn cả timeout

Chuyển sang NAT gateway:

aws ec2 allocate-address --domain vpc
aws ec2 create-nat-gateway \
  --subnet-id subnet-cong-khai-1a \
  --allocation-id eipalloc-abc

aws ec2 replace-route --route-table-id rtb-rieng-1a \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-abc

⚠ Một NAT gateway mỗi AZ — đừng dùng chung:

NAT gateway ở AZ-a
    → AZ-a hỏng là subnet riêng ở
      AZ-b và AZ-c mất đường ra
        ↓
    Và lưu lượng liên AZ có phí
        ↓
    Mỗi AZ một NAT, bảng định tuyến
      trỏ tới NAT cùng AZ

Giữ kết nối sống bằng TCP keepalive:

sysctl -w net.ipv4.tcp_keepalive_time=200
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=5

Gửi gói thăm dò mỗi 200 giây
    → dưới ngưỡng 350 giây của NAT
        ↓
    Kết nối không bị coi là nhàn rỗi
    → giải pháp bổ sung, dùng được
      với cả hai loại NAT

Ba lợi ích khi chuyển: | Lợi ích | Chi tiết | |---|---| | AWS lo vá lỗi và sẵn sàng | | | Băng thông tự co giãn tới 100 Gbps | | | Không có gì để giám sát ngoài chi phí | |

⚠ Và VPC endpoint giảm cả tải lẫn chi phí NAT:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-rieng-1a rtb-rieng-1b

Gateway endpoint cho S3 và DynamoDB:
  MIỄN PHÍ
        ↓
    Lưu lượng tới hai dịch vụ này
      không qua NAT nữa
    → thường là phần lớn nhất
      của lưu lượng đi ra

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

**A. Các máy chủ CSDL không nằm trong placement group nên giao tiếp giữa chúng không tối ưu — placement group ảnh hưởng độ trễ giữa các instance trong VPC, còn vấn đề ở đây là kết nối ra Internet để tải bản vá.
**C. Không có Internet Gateway gắn vào VPC — nếu thiếu IGW thì NAT instance cũng không ra được Internet, và không có bản vá nào tải được; đề nói việc tải có chạy, chỉ là hay thất bại.
**D. Thiếu Virtual Private Gateway nối tới Customer Gateway của nhà cung cấp CSDL — VGW dùng cho VPN tới mạng riêng, không liên quan tới việc tải bản vá công khai từ Internet.

Ghi nhớ

⚠ NAT instance và NAT gateway — bảng phải thuộc: | Tiêu chí | NAT instance | NAT gateway | |---|---|---| | Vận hành | bạn vá, bạn giám sát | AWS lo | | Sẵn sàng | tự dựng script chuyển đổi | dư thừa trong AZ | | Băng thông | theo loại instance | tới 100 Gbps | | Security group | gắn được | KHÔNG gắn được | | Dùng làm bastion | được | không | | Chuyển tiếp cổng | được | không |

Từ khoá nhận diện:

"NAT instance timeouts, availability" → chuyển sang NAT gateway "filter outbound by URL" → proxy hoặc Network Firewall (NAT không lọc) "IPv6 outbound only" → egress-only Internet gateway "reduce NAT cost" → VPC endpoint cho S3 và DynamoDB

Ba lưu ý về NAT gateway: | Lưu ý | Chi tiết | |---|---| | Phải nằm trong subnet CÔNG KHAI | | | Cần Elastic IP | | | Không gắn security group được | |

⚠ NAT trong subnet riêng tư là lỗi cấu hình phổ biến:

NAT gateway trong subnet riêng
    → chính nó không ra Internet được
        ↓
    Subnet của NAT phải có tuyến
      0.0.0.0/0 → Internet gateway

Ba lưu ý về hạn ngạch: | Lưu ý | Chi tiết | |---|---| | 55.000 kết nối đồng thời tới mỗi đích | | | Vượt: lỗi ErrorPortAllocation | | | Chia tải sang nhiều NAT nếu chạm trần | |

aws cloudwatch put-metric-alarm \
  --alarm-name nat-het-cong --namespace AWS/NATGateway \
  --metric-name ErrorPortAllocation \
  --statistic Sum --period 300 --threshold 0 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=NatGatewayId,Value=nat-abc

Ba lưu ý về thời gian nhàn rỗi: | Lưu ý | Chi tiết | |---|---| | 350 giây cho cả hai loại NAT | | | TCP keepalive dưới ngưỡng đó giữ kết nối | | | Ứng dụng nên có logic thử lại | |

Ba lưu ý về chi phí NAT: | Lưu ý | Chi tiết | |---|---| | Phí giờ chạy + phí GB xử lý | | | Gateway endpoint cho S3/DynamoDB miễn phí | | | Interface endpoint thường rẻ hơn NAT | |

⚠ Phân tích chi phí NAT bằng flow log:

SELECT dstaddr, SUM(bytes) AS tong
FROM vpc_flow_logs
WHERE interface_id = '<eni-cua-nat>'
GROUP BY dstaddr ORDER BY tong DESC LIMIT 20

Thấy đích nào chiếm nhiều nhất
    → thường là S3, ECR, kho gói
        ↓
    Tạo endpoint cho chúng

Ba lưu ý về khi nào NAT instance vẫn hợp lý: | Trường hợp | Lý do | |---|---| | Môi trường thử nghiệm rất nhỏ | rẻ hơn | | Cần chuyển tiếp cổng hoặc làm bastion | NAT gateway không làm được | | Cần lọc lưu lượng ra | cài proxy lên đó |

Ba lưu ý về gỡ lỗi kết nối ra: | Công cụ | Việc | |---|---| | Reachability Analyzer | kiểm đường đi có thông không | | VPC Flow Logs | thấy REJECT ở đâu | | curl -v | xem lỗi cụ thể từ instance |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải một tệp lớn từ instance riêng tư | | | Theo dõi ErrorPortAllocation | | | Kiểm mỗi AZ có NAT riêng | |

Và một lời khuyên: hãy tạo gateway endpoint cho S3 và DynamoDB ngay cả khi bạn đã chuyển sang NAT gateway. Chúng miễn phí, mất hai phút, và thường cắt phần lớn lưu lượng đi qua NAT — nghĩa là ít điểm gãy hơn và hoá đơn nhỏ hơn cùng lúc.

Câu 184 Domain - Accelerate Workload Migration and Modernization

A company offers a service that allows users to upload media files through a web portal. The web servers accept the media files and are directly uploaded on the on-premises Network Attached Storage (NAS). For each uploaded media file, a corresponding message is sent to the message queue. A processing server picks up each message and processes each media file which can take up to 30 minutes to process. The company noticed that the number of media files waiting in the processing queue is significantly higher during business hours, but the processing server quickly catches up after business hours. To save costs, the company hired a Solutions Architect to improve the media processing by migrating the workload to AWS Cloud.

Which of the following options is the most cost-effective solution?

A
Reconfigure the existing web servers to publish messages to a queue in Amazon MQ. Create an Auto Scaling group of Amazon EC2 instances that will pull requests from the queue and process the media files. Configure the Auto Scaling group to scale based on the length of the SQS queue. Send the processed media files into an Amazon EFS mount point and shut down the EC2 instances after processing is complete.
B
Reconfigure the existing web servers to publish messages to a standard queue on Amazon SQS. Create an Auto Scaling group of Amazon EC2 instances that will pull requests from the queue and process the media files. Configure the Auto Scaling group to scale based on the length of the SQS queue. Send the processed media files into an Amazon S3 bucket.
C
Reconfigure the existing web servers to publish messages to a standard queue on Amazon SQS. Create an AWS Lambda function that will pull requests from the SQS queue and process the media files. Invoke the Lambda function every time a new message is sent to the queue. Send the processed media files into an Amazon S3 bucket.
D
Reconfigure the existing web servers to publish messages to a queue in Amazon MQ. Create an AWS Lambda function that will pull requests from the SQS queue and process the media files. Invoke the Lambda function every time a new message is sent to the queue. Send the processed media files into an Amazon EFS volume.

Xem giải thích

Đáp án

**B — Cấu hình lại máy chủ web để đẩy thông điệp vào hàng đợi standard của Amazon SQS; tạo Auto Scaling group EC2 kéo yêu cầu từ hàng đợi và xử lý tệp; cho ASG co giãn theo độ dài hàng đợi; và đưa tệp đã xử lý vào bucket S3.

Vì sao đúng

Đề cho một dữ kiện quyết định về thời gian xử lý:

Mỗi tệp mất tới 30 PHÚT để xử lý
        ↓
    Lambda tối đa 15 PHÚT
    → KHÔNG dùng được
        ↓
    Đây là lý do phương án C và D sai

⚠ Và ba yêu cầu còn lại đều khớp: | Yêu cầu | Cách đáp ứng | |---|---| | Hàng đợi dài trong giờ làm việc, ngắn ngoài giờ | ASG co giãn theo độ dài hàng đợi | | Thay hệ thống nhắn tin hiện có | SQS | | Thay NAS lưu tệp | S3, rẻ hơn nhiều |

⚠ Co giãn theo độ dài hàng đợi phải tính đúng chỉ số:

`ApproximateNumberOfMessagesVisible`
  một mình
    → 1.000 thông điệp là nhiều hay ít?
    → phụ thuộc số instance đang có
        ↓
    Chỉ số đúng: hàng chờ / số instance
    → gọi là backlog per instance

Đẩy chỉ số tuỳ chỉnh:

import boto3
cw = boto3.client('cloudwatch')
so_thong_diep = lay_do_sau_hang_doi()
so_may = lay_so_instance_dang_chay()
cw.put_metric_data(Namespace='XuLyMedia', MetricData=[{
    'MetricName': 'BacklogPerInstance',
    'Value': so_thong_diep / max(so_may, 1)}])

Chính sách co giãn:

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

⚠ Visibility timeout phải dài hơn 30 phút:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes VisibilityTimeout=2400

Timeout ngắn hơn thời gian xử lý
    → thông điệp hiện lại giữa chừng
    → instance khác xử lý CÙNG tệp
        ↓
    Tốn gấp đôi tài nguyên
    → và có thể ghi đè kết quả

⚠ Hoặc gia hạn động trong lúc xử lý:

import threading
def gia_han_dinh_ky(url, the, dung_lai):
    while not dung_lai.is_set():
        sqs.change_message_visibility(
            QueueUrl=url, ReceiptHandle=the,
            VisibilityTimeout=600)
        dung_lai.wait(300)

⚠ Và tại sao SQS standard chứ không phải Amazon MQ:

Amazon MQ: broker tương thích
  ActiveMQ/RabbitMQ
    → chọn khi PHẢI giữ giao thức cũ
      (JMS, AMQP) mà không sửa mã
        ↓
    Đề nói được cấu hình lại máy chủ web
    → SQS đơn giản và rẻ hơn nhiều

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ngoài giờ làm việc thu về gần 0 máy | | | S3 rẻ hơn NAS rất nhiều | | | Xử lý được việc dài hơn 15 phút | |

⚠ Và Spot instance giảm chi phí thêm rất nhiều:

Xử lý media là việc chịu được
  gián đoạn
    → thông điệp quay lại hàng đợi
      nếu instance bị thu hồi
        ↓
    Spot rẻ hơn tới 90%
    → hợp hoàn hảo với mẫu này

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

**A. Dùng Amazon MQ thay SQS, ASG co giãn theo độ dài hàng đợi, và đưa kết quả vào EFS rồi tắt instance — đây là phương án gần nhất và phần ASG hoàn toàn đúng, nhưng Amazon MQ là broker phải vận hành và đắt hơn SQS mà không mang lại gì thêm ở đây; và EFS đắt hơn S3 nhiều cho việc lưu tệp đã xử lý.
**C. Dùng SQS nhưng để Lambda xử lý tệp — Lambda tối đa 15 phút, không đủ cho việc mất tới 30 phút.
**D. Dùng Amazon MQ và Lambda "kéo từ hàng đợi SQS" — mâu thuẫn nội tại (nói MQ rồi lại nói SQS), và Lambda vẫn không đủ thời gian.

Ghi nhớ

⚠ Giới hạn thời gian của các dịch vụ tính toán — bảng phải thuộc: | Dịch vụ | Thời gian tối đa | |---|---| | Lambda | 15 phút | | Fargate | không giới hạn | | EC2 | không giới hạn | | Batch | không giới hạn |

Việc dài hơn 15 phút
    → loại Lambda ngay lập tức
    → đây là bộ lọc đầu tiên

Từ khoá nhận diện:

"takes up to 30 minutes" → KHÔNG dùng Lambda "scale by queue length" → backlog per instance "must keep JMS/AMQP protocol" → Amazon MQ "replace NAS" → S3 hoặc EFS tuỳ mẫu truy cập

⚠ SQS và Amazon MQ — bảng phải thuộc: | Tiêu chí | SQS | Amazon MQ | |---|---|---| | Giao thức | API riêng của AWS | JMS, AMQP, MQTT, STOMP | | Vận hành | hoàn toàn quản lý | quản lý broker, có bản vá | | Co giãn | vô hạn | theo cỡ broker | | Chọn khi | thiết kế mới | di chuyển ứng dụng cũ không sửa mã |

Ba lưu ý về AWS Batch: | Lưu ý | Chi tiết | |---|---| | Quản lý hàng đợi job và co giãn tính toán | | | Hợp với việc chạy theo lô kiểu này | | | Dùng Spot dễ dàng | |

⚠ AWS Batch là lựa chọn đáng cân nhắc ở đây:

Batch tự lo hàng đợi job, phân bổ
  tài nguyên, thử lại
        ↓
    Không phải tự viết vòng lặp
      kéo SQS
    → và tự co giãn theo số job chờ

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Visibility timeout dài hơn thời gian xử lý | | | Long polling giảm chi phí lời gọi | | | Dead-letter queue cho thông điệp hỏng | |

Ba lưu ý về S3 so với EFS: | Tiêu chí | S3 | EFS | |---|---|---| | Chi phí mỗi GB | thấp hơn nhiều | cao | | Giao diện | API object | hệ thống tệp POSIX | | Chọn khi | ứng dụng dùng được API | ứng dụng cần đường dẫn tệp |

⚠ Nếu ứng dụng bắt buộc dùng đường dẫn tệp:

Mountpoint for Amazon S3
    → mount bucket như hệ thống tệp
        ↓
    Có chi phí của S3, giao diện
      gần như tệp
    → cân nhắc trước khi chọn EFS

Ba lưu ý về xử lý idempotent: | Lưu ý | Chi tiết | |---|---| | SQS Standard có thể giao hơn một lần | | | Ghi kết quả với khoá xác định | | | Kiểm tệp đã xử lý chưa trước khi làm lại | |

Ba lưu ý về Spot cho tải này: | Lưu ý | Chi tiết | |---|---| | Xử lý tín hiệu thu hồi 2 phút | | | Trả thông điệp về hàng đợi ngay | | | Đa dạng loại instance | |

def sap_bi_thu_hoi():
    r = requests.get(
        'http://169.254.169.254/latest/meta-data/spot/instance-action',
        timeout=1)
    return r.status_code == 200

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | ApproximateAgeOfOldestMessage | tăng đều | | Độ sâu DLQ | lớn hơn 0 | | Số instance trong ASG | chạm trần |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy nhiều tệp, xem ASG mở rộng | | | Kiểm ngoài giờ ASG có thu nhỏ | | | Xem có tệp nào bị xử lý hai lần | |

Và một lời khuyên: hãy đặt visibility timeout theo thời gian xử lý CHẬM NHẤT chứ đừng theo trung bình. Một tệp lớn bất thường vượt quá timeout sẽ được xử lý song song bởi hai instance — và chi phí của việc đó không chỉ là tiền máy, mà còn là hai kết quả ghi đè lên nhau.

Câu 185 Domain - Design for New Solutions

A company has a multi-tier web application hosted in AWS. It leverages Amazon CloudFront to reliably scale and quickly serve requests from users around the world. After several months in operation, the company received user complaints of slow response time from the web application. The monitoring team reported that the CloudFront cache hit ratio metric is steadily dropping for the past months. This metric indicates that there are inconsistent query strings on user requests and queries that contain upper-case or mixed-case letters. These requests cause CloudFront to send unnecessary origin queries.

Which of the following actions will increase the cache hit ratio of the CloudFront distribution?

A
Reconfigure the CloudFront distribution to remove the caching behavior based on query string parameters. This will cache the requests regardless of the order or case of the query parameters.
B
Reconfigure the CloudFront distribution to ensure that the “case insensitive” option is enabled for processing query string parameters.
C
Write a Lamda@Edge function that will normalize the query parameters by sorting them in alphabetical order and converting them into lower case. Deploy this function with the CloudFront distribution and set “viewer request” as the trigger to invoke the function.
D
Launch a reverse proxy inside the application VPC to intercept the requests going to the origin instances. Process the query parameters to sort them by name and convert them to lowercase letters before forwarding them to the instances.

Xem giải thích

Đáp án

**C — Viết một hàm Lambda@Edge chuẩn hoá tham số truy vấn: sắp xếp theo thứ tự bảng chữ cái và chuyển về chữ thường; triển khai cùng phân phối CloudFront với trigger là viewer request.

Vì sao đúng

Đề nêu đúng nguyên nhân, và giải pháp phải xử lý đúng nguyên nhân đó:

Tham số truy vấn không nhất quán
  về THỨ TỰ và CHỮ HOA/THƯỜNG
        ↓
    Cache key khác nhau cho cùng
      một nội dung
        ↓
    Mỗi biến thể là một mục cache riêng
    → tỷ lệ trúng cache tụt dần

⚠ CloudFront coi cache key là chuỗi khớp CHÍNH XÁC:

`?color=Red&size=L`
`?size=L&color=Red`
`?color=red&size=l`
        ↓
    Ba cache key KHÁC NHAU
    → ba lần gọi origin cho cùng
      một nội dung

Hàm chuẩn hoá:

exports.handler = async (su_kien) => {
  const yeu_cau = su_kien.Records[0].cf.request;
  const tham_so = new URLSearchParams(yeu_cau.querystring);
  const da_sap = new URLSearchParams();
  [...tham_so.keys()].sort().forEach(khoa => {
    da_sap.append(khoa.toLowerCase(),
                  tham_so.get(khoa).toLowerCase());
  });
  yeu_cau.querystring = da_sap.toString();
  return yeu_cau;
};

⚠ Phải đặt ở VIEWER REQUEST — đây là điểm quyết định:

Viewer request: chạy TRƯỚC khi
  CloudFront tra cache
        ↓
    Chuẩn hoá xong mới tính cache key
    → mọi biến thể quy về một key
        ↓
    Origin request: chạy SAU khi
      cache trượt
    → cache key đã tính rồi
    → chuẩn hoá lúc này VÔ NGHĨA

⚠ Và CloudFront Functions còn rẻ hơn cho việc này: | Tiêu chí | CloudFront Functions | Lambda@Edge | |---|---|---| | Thời gian chạy | dưới 1ms | tới 5 giây | | Truy cập mạng | không | có | | Chi phí | rẻ hơn ~6 lần | | | Trigger | viewer request/response | cả bốn |

Sắp xếp và đổi chữ thường là thao tác
  chuỗi thuần
    → CloudFront Functions dư sức
        ↓
    Và nó chạy trên MỌI yêu cầu
    → chênh lệch chi phí rất đáng kể

Hàm tương đương bằng CloudFront Functions:

function handler(su_kien) {
  var yeu_cau = su_kien.request;
  var cu = yeu_cau.querystring;
  var moi = {};
  Object.keys(cu).sort().forEach(function (khoa) {
    moi[khoa.toLowerCase()] = cu[khoa];
  });
  yeu_cau.querystring = moi;
  return yeu_cau;
}

⚠ Nhưng trước khi viết hàm — hãy xem có cần tham số đó không:

{"QueryStringsConfig": {
  "QueryStringBehavior": "whitelist",
  "QueryStrings": {"Quantity": 2,
    "Items": ["color", "size"]}}}

Chỉ đưa tham số THẬT SỰ đổi nội dung
  vào cache key
        ↓
    `utm_source`, `fbclid`, `ref`
      không đổi nội dung
    → loại chúng ra là đã cải thiện
      rất nhiều

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mọi biến thể quy về một cache key | | | Giảm mạnh số lời gọi tới origin | | | Không phải sửa ứng dụng hay client | |

⚠ Vì sao phương án A (bỏ hẳn query string khỏi cache) không đúng:

Bỏ query string khỏi cache key
    → mọi biến thể trả về CÙNG
      một nội dung
        ↓
    `?color=red` và `?color=blue`
      trả cùng kết quả
    → SAI về mặt chức năng

⚠ Và phương án B nói tới một tuỳ chọn không tồn tại:

CloudFront KHÔNG có thiết lập
  "case insensitive" cho query string
        ↓
    Đây là lý do phải tự chuẩn hoá
      bằng hàm ở biên

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

**D. Dựng reverse proxy trong VPC chặn yêu cầu tới origin và chuẩn hoá tham số trước khi chuyển tiếp — đây là phương án gần nhất và logic chuẩn hoá đúng, nhưng proxy nằm SAU CloudFront: cache key đã được tính trước khi yêu cầu tới đó, nên tỷ lệ trúng cache không đổi chút nào.
**A. Bỏ hẳn hành vi cache theo tham số truy vấn — sẽ trả về cùng nội dung cho các tham số khác nhau; sai về chức năng.
**B. Bật tuỳ chọn "case insensitive" cho tham số truy vấn — CloudFront không có tuỳ chọn này.

Ghi nhớ

⚠ Bốn trigger của Lambda@Edge — bảng phải thuộc: | Trigger | Chạy khi | Dùng cho | |---|---|---| | Viewer request | mỗi yêu cầu, TRƯỚC cache | chuẩn hoá, xác thực | | Origin request | chỉ khi cache trượt | sửa yêu cầu tới gốc | | Origin response | khi gốc trả về | sửa phản hồi | | Viewer response | trước khi trả người dùng | thêm header |

Việc ảnh hưởng CACHE KEY
    → phải ở VIEWER REQUEST
        ↓
    Đây là quy tắc quan trọng nhất
      của Lambda@Edge

Từ khoá nhận diện:

"normalise query strings" → viewer request "authenticate at the edge" → viewer request "rewrite path before fetching origin" → origin request "add security headers" → viewer response hoặc response headers policy

⚠ Năm yếu tố quyết định tỷ lệ trúng cache — theo mức ảnh hưởng:

1. TTL / max-age
2. Cache key: bớt header, cookie, query string
3. Chuẩn hoá đầu vào
4. Nén (bản nén cũng được cache)
5. Origin Shield

Ba lưu ý về cache key: | Lưu ý | Chi tiết | |---|---| | Chỉ đưa vào thứ THẬT SỰ đổi nội dung | | | Cookie phiên trong cache key phá hỏng cache | | | Tách cache policy khỏi origin request policy | |

⚠ Origin cần thứ mà cache key không cần:

Origin muốn ghi log tham số `utm_source`
    → đưa vào ORIGIN REQUEST policy
    → KHÔNG đưa vào cache key
        ↓
    Origin vẫn nhận được
    → mà cache không bị phân mảnh

Ba lưu ý về Lambda@Edge: | Lưu ý | Chi tiết | |---|---| | Phải triển khai ở us-east-1 | | | Chỉ dùng phiên bản đánh số, không dùng $LATEST | | | Log nằm ở Region gần người dùng | |

⚠ Log phân tán gây bối rối khi gỡ lỗi:

Hàm chạy ở POP Singapore
    → log vào CloudWatch ap-southeast-1
        ↓
    Tìm ở us-east-1 không thấy gì

Ba lưu ý về CloudFront Functions: | Lưu ý | Chi tiết | |---|---| | JavaScript giới hạn, không gọi mạng | | | Dưới 1ms, rẻ hơn nhiều | | | Chỉ viewer request và viewer response | |

Ba lưu ý về đo lường: | Lưu ý | Chi tiết | |---|---| | Phải bật chỉ số bổ sung mới thấy CacheHitRate | | | Phân tích log để tìm biến thể query string | | | So tỷ lệ trúng trước và sau khi sửa | |

SELECT uri, query_string, COUNT(*) AS so_lan
FROM cloudfront_logs
WHERE uri = '/san-pham'
GROUP BY uri, query_string
ORDER BY so_lan DESC LIMIT 50;

⚠ Truy vấn này cho thấy ngay mức độ phân mảnh:

Cùng một `uri` mà có hàng nghìn
  `query_string` khác nhau
        ↓
    Đó chính là số mục cache
      đang tồn tại cho một trang

Ba lưu ý về Origin Shield: | Lưu ý | Chi tiết | |---|---| | Thêm một tầng cache khu vực | | | Nhiều POP trượt cache chỉ gọi origin một lần | | | Có phí, chọn Region gần origin | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi cùng yêu cầu với thứ tự tham số khác nhau | | | Xem header X-Cache lần thứ hai phải là Hit | | | Theo dõi CacheHitRate sau vài ngày | |

Và một lời khuyên: hãy lọc bớt tham số ra khỏi cache key trước khi nghĩ tới việc viết hàm chuẩn hoá. Phần lớn tham số trong URL thực tế là mã theo dõi quảng cáo — chúng không đổi nội dung một chút nào, và loại chúng ra là thao tác cấu hình thuần không cần dòng mã nào.

Câu 186 Domain - Design for New Solutions

A company uses an AWS CloudFormation template to deploy its three-tier web application on the AWS Cloud. The CloudFormation template contains a custom AMI value used by the Auto Scaling group of Amazon EC2 instances. Every new version of the application corresponds to a new AMI that needs to be deployed. The company doesn’t want any downtime during the deployment process. The Solutions Architect has been tasked to implement a solution that will streamline its AMI deployment process by doing the following steps:

- Update the CloudFormation template to refer to the new AMI.

- Launch new EC2 instances from the new AMI by using the calling the UpdateStack API to replace the old EC2 instances.

Which of the following actions should the Solutions Architect take to achieve the above requirements?

A
Copy the updated template and deploy it to a new CloudFormation stack. After its successful deployment, update the Amazon Route 53 records to point to the new stack and delete the old stack.
B
Update the CloudFormation template AWS::AutoScaling::LaunchConfiguration resource section and specify a DeletionPolicy attribute with MinSuccessfulInstancesPercent of 50.
C
Create a new CloudFormation change set to view the changes in the new version of the template. Verify that the correct AMI is listed on the change before executing the change set.
D
Update the CloudFormation template AWS::AutoScaling::AutoScalingGroup resource section and specify an UpdatePolicy attribute with an AutoScalingRollingUpdate.

Xem giải thích

Đáp án

**D — Cập nhật phần tài nguyên AWS::AutoScaling::AutoScalingGroup trong template và khai thuộc tính UpdatePolicy với AutoScalingRollingUpdate.

Vì sao đúng

Đề nêu hai yêu cầu, và UpdatePolicy là cơ chế duy nhất đáp ứng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | UpdateStack thay instance cũ bằng AMI mới | AutoScalingRollingUpdate | | Không có thời gian chết | thay theo đợt, giữ công suất tối thiểu |

⚠ Không có UpdatePolicy thì CloudFormation KHÔNG thay instance:

Đổi AMI trong launch template
    → CloudFormation cập nhật
      launch template
        ↓
    ASG vẫn giữ nguyên instance CŨ
    → chỉ instance MỚI (khi co giãn)
      dùng AMI mới
        ↓
    Đội máy trở nên hỗn tạp

Khai UpdatePolicy:

NhomCoGian:
  Type: AWS::AutoScaling::AutoScalingGroup
  UpdatePolicy:
    AutoScalingRollingUpdate:
      MinInstancesInService: 4
      MaxBatchSize: 2
      PauseTime: PT10M
      WaitOnResourceSignals: true
      SuspendProcesses:
        - HealthCheck
        - ReplaceUnhealthy
        - AZRebalance
  Properties:
    MinSize: 4
    MaxSize: 10
    LaunchTemplate:
      LaunchTemplateId: !Ref MauKhoiChay
      Version: !GetAtt MauKhoiChay.LatestVersionNumber

⚠ MinInstancesInService là thứ bảo đảm không có thời gian chết:

Đặt bằng công suất tối thiểu cần thiết
    → CloudFormation không bao giờ
      để số instance khoẻ xuống dưới đó
        ↓
    Thay 2 máy một đợt, luôn giữ
      4 máy phục vụ

⚠ WaitOnResourceSignals là phần quan trọng nhất:

Không bật: CloudFormation coi instance
  "sẵn sàng" ngay khi EC2 khởi động
        ↓
    Nhưng ứng dụng còn đang cài đặt
    → chuyển sang đợt tiếp theo
    → thay hết máy trước khi máy nào
      thật sự phục vụ được
        ↓
    Bật: chờ tín hiệu từ chính instance

Gửi tín hiệu từ user data:

#!/bin/bash
/opt/aws/bin/cfn-init -s ${AWS::StackName} \
  -r NhomCoGian --region ${AWS::Region}
/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} \
  --resource NhomCoGian --region ${AWS::Region}

⚠ Và SuspendProcesses tránh xung đột:

Trong lúc rolling update
    → ASG health check có thể thay
      instance đang được cập nhật
        ↓
    Hai cơ chế cùng thay máy
    → hỗn loạn
        ↓
    Tạm dừng chúng trong lúc cập nhật

⚠ Ba UpdatePolicy cho ASG — bảng phải thuộc: | Chính sách | Việc | |---|---| | AutoScalingRollingUpdate | thay instance theo đợt | | AutoScalingReplacingUpdate | tạo ASG MỚI hoàn toàn rồi chuyển | | AutoScalingScheduledAction | giữ nguyên công suất khi cập nhật |

`ReplacingUpdate`: an toàn hơn vì
  ASG cũ còn nguyên để quay lui
    → nhưng tốn gấp đôi tài nguyên
      trong lúc chuyển

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đúng quy trình đề yêu cầu: sửa template rồi UpdateStack | | | Không có thời gian chết | | | Tự quay lui nếu đợt nào thất bại | |

⚠ CloudFormation tự quay lui khi rolling update thất bại:

Một đợt không gửi tín hiệu trong
  `PauseTime`
        ↓
    CloudFormation coi là thất bại
    → quay lui về AMI cũ
    → cũng theo kiểu rolling

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

**C. Tạo change set để xem trước thay đổi và kiểm tra AMI đúng chưa trước khi thực thi — đây là phương án gần nhất và change set là thực hành rất tốt, nhưng nó chỉ xem trước; không có UpdatePolicy thì thực thi xong instance cũ vẫn nguyên đó.
**B. Khai DeletionPolicy với MinSuccessfulInstancesPercent trên AWS::AutoScaling::LaunchConfiguration — DeletionPolicy kiểm soát điều xảy ra khi XOÁ tài nguyên; MinSuccessfulInstancesPercent là thuộc tính của AutoScalingRollingUpdate chứ không phải DeletionPolicy; và launch configuration đã lỗi thời, nên dùng launch template.
**A. Triển khai template mới thành stack mới rồi đổi Route 53 và xoá stack cũ — đây là blue/green ở mức stack, chạy được nhưng không phải điều đề mô tả (đề nói rõ dùng UpdateStack thay instance).

Ghi nhớ

⚠ Bốn thuộc tính đặc biệt của tài nguyên CloudFormation — bảng phải thuộc: | Thuộc tính | Kiểm soát | |---|---| | UpdatePolicy | cách CẬP NHẬT tài nguyên | | DeletionPolicy | điều xảy ra khi XOÁ stack | | UpdateReplacePolicy | điều xảy ra khi tài nguyên bị THAY THẾ | | CreationPolicy | chờ tín hiệu khi TẠO |

Từ khoá nhận diện:

"replace instances on stack update, no downtime" → UpdatePolicy rolling "keep data when stack is deleted" → DeletionPolicy: Retain "wait for instances to be ready" → CreationPolicy + cfn-signal "preview changes" → change set

Ba lưu ý về AutoScalingRollingUpdate: | Thuộc tính | Ý nghĩa | |---|---| | MinInstancesInService | số máy luôn phục vụ | | MaxBatchSize | thay bao nhiêu máy mỗi đợt | | PauseTime | chờ tối đa bao lâu mỗi đợt |

⚠ PauseTime phải dài hơn thời gian khởi động thật:

Ứng dụng mất 8 phút để sẵn sàng
    → `PauseTime: PT5M`
        ↓
    Hết giờ chờ, coi là thất bại
    → quay lui dù không có lỗi gì

Ba lưu ý về launch template: | Lưu ý | Chi tiết | |---|---| | Thay thế launch configuration đã lỗi thời | | | Có phiên bản, quay lui được | | | Dùng LatestVersionNumber để tự lấy bản mới | |

Ba lưu ý về Instance Refresh: | Lưu ý | Chi tiết | |---|---| | Tính năng của chính ASG, không qua CloudFormation | | | Thay instance theo tỷ lệ khoẻ tối thiểu | | | Có checkpoint để dừng giữa chừng | |

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name asg-ung-dung \
  --preferences '{"MinHealthyPercentage":90,
                  "InstanceWarmup":300,
                  "CheckpointPercentages":[20,50,100],
                  "CheckpointDelay":600}'

⚠ Instance Refresh là cách hiện đại hơn:

Không cần `UpdatePolicy`
    → gọi API là ASG tự thay
        ↓
    Có checkpoint: dừng ở 20%,
      chờ 10 phút, kiểm rồi mới đi tiếp
    → kiểm soát tốt hơn rolling update
      của CloudFormation

Ba lưu ý về change set: | Lưu ý | Chi tiết | |---|---| | Luôn dùng với stack sản xuất | | | Cho biết tài nguyên nào bị THAY THẾ | | | Thay thế CSDL nghĩa là mất dữ liệu | |

aws cloudformation describe-change-set \
  --stack-name stack-san-xuat --change-set-name kiem-tra \
  --query 'Changes[?ResourceChange.Replacement==`True`]'

Ba lưu ý về AMI: | Lưu ý | Chi tiết | |---|---| | EC2 Image Builder dựng AMI theo lịch | | | Lưu AMI ID trong SSM Parameter | | | Template đọc parameter thay vì hardcode | |

Parameters:
  MaAnh:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /ung-dung/ami-moi-nhat

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy UpdateStack ở môi trường thử | | | Theo dõi HealthyHostCount trong lúc cập nhật | | | Cố ý dùng AMI hỏng, xem có quay lui không | |

Và một lời khuyên: hãy bật WaitOnResourceSignals và gọi cfn-signal từ user data. Không có nó, CloudFormation thay xong toàn bộ đội máy trong vài phút mà không máy nào thật sự phục vụ được — và ALB sẽ báo không còn target khoẻ nào đúng lúc bạn tưởng mọi thứ đang tốt đẹp.

Câu 187 Domain - Continuous Improvement for Existing Solutions

A media company runs its new content management system (CMS) on a Windows-based Amazon EC2 instance. This is a test setup with a single instance. After a few weeks of testing, the application will be deployed on a production environment. For high availability, the application will be hosted on at least three Amazon EC2 instances across multiple Availability Zones. The current test EC2 instance has a 1 TB Amazon Elastic Block Store (EBS) volume as its root device. This is where all the static content is stored.

The solutions architect must ensure that all instances will have the same data at all times, for the application to work properly. The filesystem must also support Windows ACLs to control access to file contents. Additionally, all instances must be joined to the company’s Active Directory domain. The solution should have the least amount of management overhead.

Which of the following options should the Solutions Architect implement to meet the company's requirements?

A
Deploy a new Windows AMI for an Auto Scaling group with a minimum size of three instances and spans across three Availability Zones (AZs). Use an Amazon EBS volume with Multi-Attach enabled to allow multiple Amazon EC2 instances to share the volume. Write a user data script to install the CMS application and join the instances to the AD domain.
B
Deploy a new Windows AMI for an Auto Scaling group with a minimum size of three instances and spans across three Availability Zones (AZs). Create an Amazon FSx for Windows File Server file system that will be used for shared storage. Write a user data script to install the CMS application, mount the FSx for Windows File Server file system and join the instances to the AD domain.
C
Create an Amazon Machine Image (AMI) of the test Amazon EC2 instance. Use the AMI for an Auto Scaling group with a minimum size of three instances that spans three Availability Zones (AZs). Create an Amazon FSx for Lustre filesystem that will be used for shared storage. Write a user data script to join the instances on the AD domain and mount the EFS share upon boot-up.
D
Create an Amazon Machine Image (AMI) of the test Amazon EC2 instance. Use the AMI for an Auto Scaling group with a minimum size of three instances that spans three Availability Zones (AZs). Create an Amazon Elastic Filesystem (Amazon EFS) volume. Write a user data script to join the instances on the AD domain and mount the EFS share upon boot-up.

Xem giải thích

Đáp án

**B — Triển khai AMI Windows mới cho Auto Scaling group tối thiểu ba instance trải ba vùng sẵn sàng; tạo hệ thống tệp Amazon FSx for Windows File Server làm lưu trữ dùng chung; viết user data script cài ứng dụng CMS, mount FSx và tham gia miền Active Directory.

Vì sao đúng

Đề nêu ba yêu cầu kỹ thuật, và FSx for Windows là dịch vụ duy nhất thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Mọi instance thấy cùng dữ liệu | chia sẻ SMB dùng chung | | Hỗ trợ Windows ACL | FSx for Windows hỗ trợ đầy đủ | | Tham gia miền Active Directory | FSx tích hợp trực tiếp với AD |

⚠ "Windows ACL" là từ khoá loại bỏ mọi phương án khác:

EFS: hệ thống tệp POSIX (NFS)
    → quyền kiểu Linux (owner, group, other)
    → KHÔNG có Windows ACL
        ↓
    FSx for Lustre: cũng POSIX
    → dành cho HPC
        ↓
    Chỉ FSx for Windows nói SMB
      và hiểu ACL của Windows

Tạo hệ thống tệp:

aws fsx create-file-system --file-system-type WINDOWS \
  --storage-capacity 1024 --storage-type SSD \
  --subnet-ids subnet-a subnet-b \
  --windows-configuration '{
    "ActiveDirectoryId":"d-1234567890",
    "ThroughputCapacity":32,
    "DeploymentType":"MULTI_AZ_1",
    "AutomaticBackupRetentionDays":30}'

⚠ MULTI_AZ_1 là lựa chọn đúng cho sẵn sàng cao: | Kiểu triển khai | Đặc điểm | |---|---| | SINGLE_AZ_1 / SINGLE_AZ_2 | một AZ, rẻ hơn | | MULTI_AZ_1 | hai AZ, tự chuyển đổi |

Đề đòi sẵn sàng cao ở tầng ứng dụng
    → tầng lưu trữ cũng phải vậy
        ↓
    Single AZ: mất AZ đó là mọi
      instance mất dữ liệu chung

⚠ ActiveDirectoryId gắn thẳng vào Managed Microsoft AD:

FSx tự tham gia miền
    → quyền tệp dùng chính tài khoản AD
        ↓
    Người dùng đăng nhập bằng tài khoản
      công ty và thấy đúng quyền
      của họ

Tham gia miền bằng user data:

<powershell>
$bi_mat = Get-SECSecretValue -SecretId 'ad/tham-gia-mien'
$thong_tin = ConvertFrom-Json $bi_mat.SecretString
$mat_khau = ConvertTo-SecureString $thong_tin.password -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential(
    $thong_tin.username, $mat_khau)
Add-Computer -DomainName "congty.local" -Credential $cred -Restart
</powershell>

⚠ Nhưng có cách tốt hơn user data script:

aws ssm create-document --name ThamGiaMien \
  --document-type Command --content file://tham-gia.json

Systems Manager có tài liệu
  `AWS-JoinDirectoryServiceDomain`
        ↓
    Gắn vào ASG qua State Manager
    → instance mới tự tham gia miền
    → không cần script tự viết

⚠ Và mật khẩu tham gia miền KHÔNG được để trong user data:

User data đọc được từ instance metadata
    → ai vào được máy là lấy được
      mật khẩu tài khoản miền
        ↓
    Lưu trong Secrets Manager
    → và cấp quyền đọc qua IAM role

Mount FSx:

New-PSDrive -Name Z -PSProvider FileSystem `
  -Root "\\fs-abc.congty.local\share" -Persist

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mọi instance thấy cùng dữ liệu ngay lập tức | | | Windows ACL hoạt động đúng như tại chỗ | | | AWS lo sao lưu và chuyển đổi | |

⚠ Vì sao EBS Multi-Attach (phương án A) không dùng được:

Multi-Attach: nhiều instance gắn
  cùng một volume
        ↓
    Nhưng NTFS KHÔNG chịu được
      truy cập đồng thời
    → dữ liệu hỏng ngay
        ↓
    Cần hệ thống tệp cụm
    → và Multi-Attach chỉ trong
      MỘT AZ, chỉ io1/io2

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

**D. Tạo AMI từ instance thử, dùng cho ASG ba AZ, tạo Amazon EFS làm lưu trữ dùng chung — đây là phương án gần nhất và EFS thật sự là hệ thống tệp dùng chung nhiều AZ, nhưng EFS dùng NFS với quyền POSIX; nó không hỗ trợ Windows ACL như đề yêu cầu.
**C. Dùng FSx for Lustre làm lưu trữ dùng chung — Lustre là hệ thống tệp POSIX cho tính toán hiệu năng cao, không nói SMB và không hiểu Windows ACL; phương án còn tự mâu thuẫn khi bảo mount "EFS share".
**A. Dùng EBS Multi-Attach để nhiều instance dùng chung volume — NTFS không chịu được nhiều máy ghi đồng thời; và Multi-Attach chỉ trong một AZ.

Ghi nhớ

⚠ Bốn hệ thống tệp dùng chung — bảng phải thuộc: | Dịch vụ | Giao thức | Quyền | |---|---|---| | EFS | NFS | POSIX | | FSx for Windows | SMB | Windows ACL | | FSx for Lustre | POSIX | POSIX | | FSx for NetApp ONTAP | NFS và SMB | cả hai |

Từ khoá nhận diện:

"Windows ACLs, Active Directory" → FSx for Windows "POSIX shared file system" → EFS "HPC, high throughput" → FSx for Lustre "both NFS and SMB" → FSx for NetApp ONTAP

Ba lưu ý về FSx for Windows: | Lưu ý | Chi tiết | |---|---| | Tích hợp trực tiếp với Managed Microsoft AD | | | Hỗ trợ DFS Namespace và shadow copy | | | Multi-AZ có endpoint DNS tự chuyển | |

⚠ Shadow copy cho phép người dùng tự khôi phục tệp:

Set-FSxShadowStorage -Default
Set-FSxShadowCopySchedule -Default

Người dùng chuột phải → Previous Versions
    → tự khôi phục tệp xoá nhầm
        ↓
    Giảm rất nhiều yêu cầu tới
      đội vận hành

Ba lưu ý về thông lượng: | Lưu ý | Chi tiết | |---|---| | ThroughputCapacity chọn riêng, không theo dung lượng | | | Tăng được sau khi tạo | | | SSD cho độ trễ thấp, HDD cho dung lượng lớn | |

Ba lưu ý về Active Directory: | Lựa chọn | Ghi chú | |---|---| | AWS Managed Microsoft AD | FSx tích hợp trực tiếp | | AD tự quản lý | cần cấu hình thủ công | | AD Connector | KHÔNG dùng được với FSx |

⚠ Điểm cuối là hạn chế đáng nhớ:

AD Connector chỉ là proxy xác thực
    → FSx cần thư mục THẬT để
      tham gia miền
        ↓
    Managed Microsoft AD hoặc
      AD tự quản lý

Ba lưu ý về ASG với Windows: | Lưu ý | Chi tiết | |---|---| | Windows khởi động chậm hơn Linux nhiều | | | Đặt HealthCheckGracePeriod đủ dài | | | Warm pool rút ngắn thời gian sẵn sàng | |

⚠ Grace period ngắn gây vòng lặp thay máy:

Windows mất 6 phút để sẵn sàng
    → grace period 300 giây (5 phút)
        ↓
    ASG coi máy là hỏng và thay
    → máy mới cũng mất 6 phút
    → vòng lặp vô tận

Ba lưu ý về dọn máy khỏi miền: | Lưu ý | Chi tiết | |---|---| | Instance bị thu hồi để lại đối tượng máy trong AD | | | Tích tụ hàng nghìn đối tượng chết | | | Dùng lifecycle hook để gỡ khỏi miền | |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | FSx tự sao lưu hằng ngày | | | AWS Backup quản lý tập trung được | | | Sao lưu giữ cả ACL | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi tệp từ một instance, đọc từ instance khác | | | Kiểm ACL giữ đúng khi truy cập từ nhiều máy | | | Tắt một AZ, xem chia sẻ còn truy cập được | |

Và một lời khuyên: hãy dùng Systems Manager để tham gia miền thay vì viết user data script. Script tự viết luôn cần mật khẩu tài khoản miền ở đâu đó, và user data là nơi tệ nhất để đặt nó — ai đọc được instance metadata là có ngay chìa khoá vào Active Directory của công ty.

Câu 188 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

A financial company is building a new online document portal system that allows its employees and developers to upload yearly and bi-annual corporate earnings report files to a private S3 bucket in which other confidential corporate files will also be stored. You are working as a Solutions Architect and you were instructed to create the private S3 bucket as well as the IAM users for the application developers to start their work. You assigned the required policies in IAM to the developers that allows them read and write access to the S3 bucket. After a few weeks, they have completed the new online portal and hosted it on a fleet of Spot EC2 instances. One of the application developers created a pre-signed URL that points to the correct S3 bucket and after a few testing, he has successfully uploaded the files from his laptop using the generated URL. He then made the necessary code change to the online portal to generate the pre-signed URL to upload the files in S3. However, after a few days, the development team complained that they cannot upload the files anymore using the online portal. Which of the following options are valid reasons for this behavior? (Select TWO.)

A The ACL of the S3 bucket blocks the online portal and prevents the developers from uploading any files.
B
The required AWS credentials in the ~/.aws/credentials configuration file located on the EC2 instances of the online portal were misconfigured
C The application developers do not have access to either read or upload objects to the S3 bucket.
D There was a recent change in the S3 bucket that allows object versioning which invalidates all presigned URLs.
E
The expiration date of the pre-signed URL is incorrectly set to expire too quickly and thus, may have already expired when they used it.

Xem giải thích

Đáp án

**B và E — Thông tin đăng nhập AWS trong tệp ~/.aws/credentials trên các EC2 của cổng thông tin bị cấu hình sai; và thời hạn của pre-signed URL đặt quá ngắn nên đã hết hạn khi họ dùng.

Vì sao đúng

Đề cho một manh mối quyết định:

Lập trình viên tạo URL từ LAPTOP
    → thành công
        ↓
    Cổng thông tin trên EC2 tạo URL
    → thất bại
        ↓
    Khác biệt nằm ở CREDENTIAL DÙNG ĐỂ KÝ
    → không phải ở quyền của
      lập trình viên

⚠ Pre-signed URL kế thừa quyền của người KÝ, không phải người dùng:

URL ký bằng credential nào
    → nó mang đúng quyền của
      credential đó
        ↓
    Credential trên EC2 sai hoặc
      không đủ quyền
    → URL sinh ra vô hiệu

⚠ Và đây là điểm phân biệt với phương án C:

Lập trình viên VẪN tải lên được
  từ laptop
        ↓
    Quyền của họ hoàn toàn ổn
    → vấn đề nằm ở credential
      của MÁY CHỦ

⚠ URL hết hạn là nguyên nhân thứ hai rất phổ biến:

url = s3.generate_presigned_url('put_object',
    Params={'Bucket': 'tai-lieu-mat', 'Key': khoa},
    ExpiresIn=60)

Đặt 60 giây
    → thử từ laptop: dán ngay, kịp
        ↓
    Qua cổng thông tin: người dùng
      chọn tệp, tệp lớn tải chậm
    → hết hạn giữa chừng

⚠ Và có một giới hạn cứng phải biết:

Credential TẠM (vai trò IAM trên EC2)
  có hạn tối đa vài giờ
        ↓
    Pre-signed URL ký bằng nó
      KHÔNG SỐNG LÂU HƠN credential
        ↓
    Đặt `ExpiresIn=7 ngày` nhưng ký
      bằng vai trò
    → URL chết khi credential hết hạn

Cách đúng — dùng vai trò IAM, không dùng tệp credentials:

import boto3
s3 = boto3.client('s3')   # SDK tu lay tu instance metadata
url = s3.generate_presigned_url('put_object',
    Params={'Bucket': 'tai-lieu-mat', 'Key': khoa},
    ExpiresIn=900)

⚠ Tệp ~/.aws/credentials trên EC2 vốn đã là thực hành sai:

Khoá tĩnh nằm trên đĩa
    → phải xoay tay
    → ai đọc được đĩa là lấy được
        ↓
    Instance profile: credential tạm,
      tự xoay
    → không có tệp nào để cấu hình sai

Ba lợi ích khi chuyển sang vai trò: | Lợi ích | Chi tiết | |---|---| | Không có tệp credential để sai | | | Tự xoay, không hết hạn bất ngờ | | | CloudTrail ghi rõ vai trò nào ký | |

Kiểm tra credential trên instance:

aws sts get-caller-identity
aws s3api head-bucket --bucket tai-lieu-mat

⚠ get-caller-identity là lệnh chẩn đoán đầu tiên:

Trả về ARN của vai trò đúng
    → credential ổn
        ↓
    Trả về IAM user lạ hoặc lỗi
    → tìm ra ngay nguyên nhân

⚠ Vì sao versioning (phương án D) không làm URL vô hiệu:

Bật versioning
    → object nhận version ID
        ↓
    Pre-signed URL cho `PutObject`
      vẫn hoạt động bình thường
    → nó tạo phiên bản mới
        ↓
    Versioning KHÔNG ảnh hưởng
      chữ ký của URL

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

**C. Lập trình viên không có quyền đọc hoặc tải lên bucket — đây là phương án gần nhất và quyền là nguyên nhân hợp lý trong nhiều tình huống, nhưng đề nói rõ họ đã tải lên thành công từ laptop; quyền của họ vẫn nguyên vẹn.
**D. Có thay đổi gần đây bật versioning, làm mọi pre-signed URL vô hiệu — versioning không ảnh hưởng gì tới chữ ký của URL.
**A. ACL của bucket chặn cổng thông tin — ACL của S3 không phân biệt được "cổng thông tin" với "laptop"; và AWS khuyến nghị tắt ACL, dùng bucket policy.

Ghi nhớ

⚠ Bốn điều quyết định pre-signed URL có hoạt động không:

1. Credential dùng để KÝ có quyền không
2. URL đã hết hạn chưa
3. Credential ký có còn hiệu lực không
4. Bucket policy có chặn không

Từ khoá nhận diện:

"works from laptop, fails from server" → credential khác nhau "pre-signed URL stopped working" → hết hạn hoặc credential hết hạn "URL kế thừa quyền" → của người ký, không phải người dùng "secure credentials on EC2" → IAM role, không phải tệp credentials

⚠ Thời hạn tối đa của pre-signed URL: | Credential ký | Hạn tối đa | |---|---| | IAM user access key | 7 ngày (SigV4) | | Vai trò IAM (credential tạm) | tới khi credential hết hạn | | Phiên GetSessionToken | tới 36 giờ |

Ba lưu ý về pre-signed URL: | Lưu ý | Chi tiết | |---|---| | Không thu hồi được URL đã phát | | | Đặt hạn ngắn nhất dùng được | | | Giới hạn kích thước và loại tệp trong điều kiện | |

⚠ Dùng generate_presigned_post để giới hạn tải lên:

url = s3.generate_presigned_post(
    Bucket='tai-lieu-mat', Key='bao-cao/${filename}',
    Fields={'Content-Type': 'application/pdf'},
    Conditions=[['content-length-range', 0, 52428800],
                {'Content-Type': 'application/pdf'}],
    ExpiresIn=900)

Không giới hạn kích thước
    → ai có URL đều tải lên tệp 5 GB
        ↓
    Chi phí ngoài dự kiến

Ba lưu ý về credential trên EC2: | Lưu ý | Chi tiết | |---|---| | Luôn dùng instance profile | | | Bắt buộc IMDSv2 | | | Không bao giờ đặt khoá tĩnh trên đĩa | |

aws ec2 modify-instance-metadata-options \
  --instance-id i-abc --http-tokens required \
  --http-put-response-hop-limit 1

⚠ Chuỗi tìm credential của SDK — thứ tự quan trọng:

1. Biến môi trường
2. Tệp ~/.aws/credentials
3. Container credential (ECS)
4. Instance metadata
        ↓
    Tệp credentials ĐỨNG TRƯỚC
      instance metadata
    → một tệp cũ sót lại sẽ đè
      lên vai trò IAM

Ba lưu ý về Spot instance trong đề: | Lưu ý | Chi tiết | |---|---| | Spot bị thu hồi bất kỳ lúc nào | | | Instance mới có thể thiếu cấu hình | | | Đây có thể là lý do tệp credentials không nhất quán | |

⚠ Đây là chi tiết đáng chú ý trong đề:

Cổng thông tin chạy trên Spot
    → instance bị thay liên tục
        ↓
    Nếu tệp credentials được đặt
      thủ công trên máy cũ
    → máy mới không có
    → giải thích chính xác triệu chứng

Ba lưu ý về gỡ lỗi: | Việc | Cách | |---|---| | aws sts get-caller-identity trên máy chủ | | | Kiểm CloudTrail xem ai ký URL | | | Xem thông báo lỗi thật từ S3 | |

Ba lưu ý về bảo mật bucket: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access | | | Bắt buộc HTTPS bằng bucket policy | | | Bật versioning chống ghi đè nhầm | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sinh URL trên máy chủ rồi thử ngay | | | So ARN người ký giữa laptop và máy chủ | | | Kiểm thời hạn URL có đủ cho việc tải tệp lớn | |

Và một lời khuyên: hãy bỏ hẳn tệp ~/.aws/credentials trên EC2 và dùng instance profile. Nó loại bỏ cả hai vấn đề cùng lúc — không còn tệp để cấu hình sai, và không còn khoá tĩnh nằm trên đĩa của một instance có thể bị thu hồi bất cứ lúc nào.

Câu 189 Domain - Continuous Improvement for Existing Solutions

A company is running its main web service in a fleet of Amazon EC2 instances in the us-east-1 AWS Region. The EC2 instances are launched by an Auto Scaling group behind an Application Load Balancer (ALB). The EC2 instances are spread across multiple Availability Zones. The MySQL database is hosted on an Amazon EC2 instance in a private subnet. To improve the resiliency of the web service in case of a disaster, the Solutions Architect must design a data recovery strategy in another region using the available AWS services to lessen the operational overhead. The target RPO is less than a minute and the target RTO is less than 5 minutes. The Solutions Architect has started to provision the ALB and the Auto Scaling group on the us-west-2 region.

Which of the following steps should be implemented next to achieve the above requirements?

A
Migrate the database from the Amazon EC2 instance to an Amazon Aurora global database. Set the us-east-1 region as the primary database and the us-west-2 region as the secondary database. Configure Amazon Route 53 DNS entry with health checks and failover routing policy to the us-west-2 region.
B
Migrate the database from the Amazon EC2 instance to an Amazon RDS for MySQL instance. Enable Multi-AZ deployment for this database. Configure Amazon Route 53 DNS entry with failover routing policy to the us-west-2 region.
C
Migrate the database from the Amazon EC2 instance to an Amazon RDS for MySQL instance. Set the us-east-1 region database as the master and configure a cross-Region read replica to the us-west-2 region. Configure Amazon Route 53 DNS entry with health checks and failover routing policy to the us-west-2 region.
D
Create a snapshot of the current Amazon EC2 database instance and restore the snapshot to the us-west-2 region. Configure the new EC2 instance as MySQL standby database of the us-east-1 instance. Configure Amazon Route 53 DNS entry with failover routing policy to the us-west-2 region.

Xem giải thích

Đáp án

**A — Chuyển CSDL từ EC2 sang Amazon Aurora global database, đặt us-east-1 làm CSDL chính và us-west-2 làm CSDL phụ; cấu hình bản ghi Route 53 với health check và failover routing sang us-west-2.

Vì sao đúng

Đề cho hai con số rất chặt, và chỉ một lựa chọn đạt được: | Chỉ tiêu | Yêu cầu | Aurora Global Database | |---|---|---| | RPO | dưới 1 phút | thường dưới 1 giây | | RTO | dưới 5 phút | chuyển đổi dưới 1 phút |

⚠ Aurora Global Database nhân bản ở tầng LƯU TRỮ:

Nhân bản thường: gửi log giao dịch
  qua tầng CSDL
    → tốn CPU của instance chính
    → độ trễ vài giây tới vài phút
        ↓
    Aurora Global: nhân bản ở tầng
      lưu trữ, bằng hạ tầng chuyên dụng
    → độ trễ thường dưới 1 giây
    → không tốn CPU của instance chính

⚠ Và đây là điểm phân biệt với cross-region read replica: | Tiêu chí | Aurora Global | Cross-region read replica | |---|---|---| | Độ trễ nhân bản | dưới 1 giây | giây tới phút | | Thời gian thăng cấp | dưới 1 phút | vài phút | | Tốn CPU instance chính | không | có |

RPO dưới 1 phút
    → read replica thường có thể
      không đạt khi tải cao
        ↓
    Đây là lý do phương án C yếu hơn

Tạo global database:

aws rds create-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --source-db-cluster-identifier <arn-cum-us-east-1>

aws rds create-db-cluster \
  --db-cluster-identifier cum-us-west-2 \
  --engine aurora-mysql \
  --global-cluster-identifier cum-toan-cau \
  --region us-west-2

⚠ Chuyển đổi có kế hoạch — dùng cho diễn tập:

aws rds failover-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --target-db-cluster-identifier <arn-cum-us-west-2>

Chuyển đổi có kiểm soát: KHÔNG mất
  dữ liệu
    → dùng để diễn tập định kỳ
        ↓
    Chuyển đổi khẩn cấp (detach and
      promote): có thể mất vài giây
      dữ liệu cuối

Route 53 failover:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{"Action":"CREATE",
    "ResourceRecordSet":{
      "Name":"app.congty.com","Type":"A",
      "SetIdentifier":"chinh-east","Failover":"PRIMARY",
      "HealthCheckId":"<hc-east>",
      "AliasTarget":{"HostedZoneId":"<zone-alb-east>",
        "DNSName":"<dns-alb-east>",
        "EvaluateTargetHealth":true}}}]}'

⚠ Tính thời gian chuyển đổi tổng để kiểm RTO 5 phút:

Health check: 10 giây × 3 lần thất bại
    = 30 giây
        ↓
    + TTL của bản ghi DNS: 60 giây
        ↓
    + Thăng cấp cụm Aurora: dưới 60 giây
        ↓
    Tổng khoảng 2,5 phút
    → nằm trong RTO 5 phút

⚠ Nhưng phải chuyển từ MySQL trên EC2 sang Aurora trước:

Đề nói CSDL đang chạy MySQL trên EC2
    → dùng DMS với chế độ
      `full-load-and-cdc`
        ↓
    Chép toàn bộ rồi theo dõi thay đổi
    → cắt chuyển khi độ trễ gần 0
    → gián đoạn chỉ vài phút

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RPO dưới 1 giây, RTO dưới 1 phút ở tầng CSDL | | | Region phụ phục vụ đọc được ngay | | | AWS lo vá lỗi, sao lưu, chuyển đổi | |

⚠ Và Region phụ dùng được cho tải đọc — không lãng phí:

Cụm phụ có tới 16 reader
    → phục vụ báo cáo, phân tích
      cho người dùng bờ Tây
        ↓
    Không phải hạ tầng nằm im
      chờ sự cố

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

**C. Chuyển sang RDS for MySQL với cross-region read replica sang us-west-2 và Route 53 failover — đây là phương án gần nhất và thật sự là kiến trúc DR xuyên vùng hợp lệ, nhưng nhân bản của RDS chậm hơn Aurora Global đáng kể; với RPO dưới một phút thì đây là biên rất mỏng, đặc biệt khi tải ghi cao.
**B. Chuyển sang RDS for MySQL và bật Multi-AZ — Multi-AZ chỉ chống hỏng AZ trong cùng một Region; nó không giúp gì khi mất cả Region.
**D. Chụp ảnh instance EC2 hiện tại, khôi phục ở us-west-2 và cấu hình làm standby MySQL tự quản lý — tự dựng nhân bản MySQL xuyên Region là nhiều việc vận hành nhất, và trái với yêu cầu "giảm gánh nặng vận hành".

Ghi nhớ

⚠ Bốn cơ chế bảo vệ CSDL và phạm vi — bảng phải thuộc: | Cơ chế | Chống được | |---|---| | Multi-AZ | hỏng instance hoặc AZ | | Cross-region read replica | mất Region (RPO phút) | | Aurora Global Database | mất Region (RPO giây) | | Sao lưu và PITR | xoá nhầm dữ liệu |

Từ khoá nhận diện:

"RPO under a minute across Regions" → Aurora Global Database "survive AZ failure" → Multi-AZ "recover from accidental deletion" → PITR "least operational overhead" → dịch vụ quản lý, không tự dựng

Ba lưu ý về Aurora Global Database: | Lưu ý | Chi tiết | |---|---| | Tới 5 Region phụ | | | Mỗi Region phụ tới 16 reader | | | Ghi chỉ ở Region chính | |

⚠ Ghi chỉ ở Region chính — hệ quả với ứng dụng:

Ứng dụng ở us-west-2 muốn ghi
    → phải gọi ngược về us-east-1
        ↓
    Độ trễ xuyên lục địa cho mỗi
      lệnh ghi
    → hoặc dùng write forwarding

aws rds modify-db-cluster \
  --db-cluster-identifier cum-us-west-2 \
  --enable-global-write-forwarding

Ba lưu ý về write forwarding: | Lưu ý | Chi tiết | |---|---| | Reader ở Region phụ nhận lệnh ghi và chuyển về chính | | | Vẫn có độ trễ xuyên Region cho lệnh ghi | | | Đơn giản hoá mã ứng dụng | |

Ba lưu ý về chuyển đổi: | Loại | Đặc điểm | |---|---| | Managed planned failover | không mất dữ liệu, dùng để diễn tập | | Detach and promote | khi Region chính đã mất, có thể mất vài giây cuối |

⚠ Sau khi thăng cấp, phải dựng lại chiều nhân bản:

Region cũ hồi phục
    → không tự trở lại làm chính
        ↓
    Phải thêm nó làm Region phụ
      của cụm mới
    → lên kế hoạch cho cả chiều về

Ba lưu ý về Route 53 failover: | Lưu ý | Chi tiết | |---|---| | TTL ngắn cho bản ghi chuyển đổi | | | EvaluateTargetHealth kiểm target thật | | | Global Accelerator nhanh hơn nếu cần | |

Ba lưu ý về hạn ngạch Region phụ: | Lưu ý | Chi tiết | |---|---| | Xin tăng hạn ngạch vCPU TRƯỚC | | | Sao chép AMI và container image sang đó | | | Nhân bản bí mật trong Secrets Manager | |

⚠ Bí mật là thứ hay bị quên trong kế hoạch DR:

aws secretsmanager replicate-secret-to-regions \
  --secret-id csdl/san-xuat \
  --add-replica-regions Region=us-west-2

Ứng dụng ở Region phụ khởi động
    → không đọc được mật khẩu CSDL
        ↓
    Chuyển đổi thành công mà ứng dụng
      vẫn không chạy

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Region phụ tính phí instance và lưu trữ | | | Có phí truyền dữ liệu nhân bản | | | Reader ở Region phụ dùng được nên không lãng phí | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy managed planned failover, bấm giờ | | | Đo AuroraGlobalDBReplicationLag | | | Thử mở rộng ASG ở Region phụ lên công suất đầy | |

Và một lời khuyên: hãy chạy managed planned failover ít nhất mỗi quý. Đó là thao tác không mất dữ liệu và có thể lên lịch — nghĩa là bạn kiểm chứng được toàn bộ kế hoạch DR mà không phải chờ một sự cố thật để biết nó có hoạt động hay không.

Câu 190 Domain - Continuous Improvement for Existing Solutions

A company runs an application in a fleet of Amazon EC2 instances in the us-east-2 region. A database server is hosted on the on-premises data center which complies with the BASE (Basically Available, Soft state, Eventual consistency) model rather than the ACID (Atomicity, Consistency, Isolation, Durability) consistency model. The on-premises network has a 10 GB AWS Direct Connect connection to the Amazon VPC in us-east-2. The application relies on this database for normal operations. Whenever there are lots of database write requests, the application behavior becomes erratic.

Which of the following options should the solutions architect implement to improve the performance of the application in a cost-effective way?

A
Create an Amazon RDS multi-AZ instance that will synchronize with the on-premises database server using Amazon EventBridge. Redirect the write operations of the application to the Amazon RDS endpoint via the Amazon Elastic Transcoder service.
B
Create an Amazon SQS queue and develop a consumer process to flush the queue to the on-premises database server. Update the application to enable writing to the SQS queue.
C
Create a Hadoop cluster using Amazon Elastic Map Reduce (EMR) and use the S3DistCp tool to synchronize data between the on-premises database and the Hadoop cluster.
D
Update the application to write to an Amazon DynamoDB table. Feed the table to an Amazon EMR cluster and create a map function that will update the on-premises database for every table update.

Xem giải thích

Đáp án

**B — Tạo một hàng đợi Amazon SQS và viết tiến trình consumer đẩy dữ liệu từ hàng đợi vào CSDL tại chỗ; sửa ứng dụng để ghi vào hàng đợi SQS.

Vì sao đúng

Đề cho một dữ kiện rất cụ thể và nó quyết định mọi thứ:

CSDL tuân theo mô hình BASE
    → Basically Available,
      Soft state,
      EVENTUAL CONSISTENCY
        ↓
    Nghĩa là ứng dụng KHÔNG đòi hỏi
      dữ liệu nhất quán ngay lập tức
        ↓
    Ghi bất đồng bộ qua hàng đợi
      hoàn toàn chấp nhận được

⚠ Nếu là ACID thì hàng đợi sẽ không dùng được:

ACID đòi giao dịch commit ngay
  và đọc thấy ngay
        ↓
    Ghi qua hàng đợi: ứng dụng nhận
      "đã nhận" nhưng chưa vào CSDL
    → vi phạm tính nhất quán tức thì
        ↓
    BASE cho phép điều đó

⚠ Và hàng đợi giải quyết đúng triệu chứng trong đề:

"Nhiều yêu cầu ghi thì ứng dụng
  hành xử thất thường"
        ↓
    CSDL tại chỗ nghẽn
    + mỗi lệnh ghi đi qua Direct Connect
      và chờ phản hồi
        ↓
    Hàng đợi: ứng dụng ghi xong ngay
    → consumer đẩy về theo tốc độ
      CSDL chịu được

Ứng dụng ghi vào hàng đợi:

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

def ghi_du_lieu(ban_ghi):
    sqs.send_message(
        QueueUrl=URL_HANG_DOI,
        MessageBody=json.dumps(ban_ghi))

Consumer chạy tại chỗ:

while True:
    phan_hoi = sqs.receive_message(
        QueueUrl=URL_HANG_DOI,
        MaxNumberOfMessages=10,
        WaitTimeSeconds=20)
    for tin in phan_hoi.get('Messages', []):
        ghi_vao_csdl(json.loads(tin['Body']))
        sqs.delete_message(
            QueueUrl=URL_HANG_DOI,
            ReceiptHandle=tin['ReceiptHandle'])

⚠ Consumer nên chạy TẠI CHỖ, gần CSDL:

Consumer trên EC2 ở us-east-2
    → mỗi lệnh ghi đi qua Direct Connect
    → độ trễ cộng dồn
        ↓
    Consumer tại chỗ: kéo lô 10 thông điệp
      qua DX một lần
    → rồi ghi cục bộ, rất nhanh

⚠ Ghi theo lô còn hiệu quả hơn nữa:

ban_ghi = [json.loads(t['Body']) for t in tin_nhan]
ghi_hang_loat(ban_ghi)      # mot lenh INSERT nhieu dong
sqs.delete_message_batch(
    QueueUrl=URL_HANG_DOI,
    Entries=[{'Id': str(i), 'ReceiptHandle': t['ReceiptHandle']}
             for i, t in enumerate(tin_nhan)])

⚠ Và delete_message_batch giảm số lời gọi API:

Xoá từng thông điệp: 10 lời gọi
    → mỗi lời gọi đi qua Internet
        ↓
    Xoá theo lô: 1 lời gọi
    → nhanh hơn và rẻ hơn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ứng dụng không chờ CSDL nữa | | | Đỉnh ghi được san phẳng theo thời gian | | | Không đổi CSDL, không đổi mô hình dữ liệu | |

⚠ Và hàng đợi còn chịu được việc mất kết nối:

Direct Connect đứt
    → consumer không kéo được
        ↓
    Thông điệp nằm trong hàng đợi
      tới 14 ngày
    → kết nối lại là xử lý bù
        ↓
    Ứng dụng trên AWS vẫn chạy
      bình thường

⚠ Nhưng phải nhớ hai điều với SQS Standard:

1. Có thể giao thông điệp hơn một lần
   → xử lý phải idempotent
        ↓
2. KHÔNG đảm bảo thứ tự
   → nếu thứ tự quan trọng, dùng FIFO
     (nhưng có trần thông lượng)

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

**D. Sửa ứng dụng ghi vào DynamoDB, rồi đưa bảng vào cụm EMR với hàm map cập nhật CSDL tại chỗ cho mỗi thay đổi — đây là phương án gần nhất và cũng là ghi bất đồng bộ, nhưng EMR là công cụ xử lý theo lô, dùng nó để đồng bộ từng bản ghi là sai vai trò và tốn kém; DynamoDB Streams + Lambda mới là cách đúng nếu muốn đi hướng này.
**A. Tạo RDS Multi-AZ đồng bộ với CSDL tại chỗ qua EventBridge, rồi chuyển ghi sang RDS qua Elastic Transcoder — EventBridge không đồng bộ CSDL, và Elastic Transcoder là dịch vụ chuyển mã video; hoàn toàn không liên quan.
**C. Dựng cụm Hadoop trên EMR và dùng S3DistCp đồng bộ dữ liệu — S3DistCp chép dữ liệu giữa S3 và HDFS, nó không đồng bộ với CSDL.

Ghi nhớ

⚠ ACID và BASE — bảng phải thuộc: | Mô hình | Đặc điểm | Ví dụ | |---|---|---| | ACID | nhất quán ngay, giao dịch | RDS, Aurora | | BASE | nhất quán cuối cùng, ưu tiên sẵn sàng | DynamoDB, Cassandra |

Đề nói BASE
    → mở đường cho mọi giải pháp
      bất đồng bộ
        ↓
    Đây là dữ kiện quan trọng nhất
      của câu hỏi

Từ khoá nhận diện:

"BASE model, write spikes" → hàng đợi "ACID, must be immediately consistent" → KHÔNG dùng hàng đợi "decouple application from database" → SQS "react to data changes" → DynamoDB Streams

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Standard: thông lượng vô hạn, có thể trùng | | | FIFO: đúng thứ tự, có trần thông lượng | | | Giữ thông điệp tới 14 ngày | |

⚠ Chọn Standard hay FIFO:

Ghi bản ghi độc lập
    → Standard, thông lượng vô hạn
        ↓
    Ghi phải theo đúng trình tự
      (ví dụ cập nhật số dư)
    → FIFO, trần 300 tin/giây mỗi nhóm

Ba lưu ý về xử lý idempotent: | Lưu ý | Chi tiết | |---|---| | SQS Standard có thể giao hơn một lần | | | Dùng khoá tự nhiên và ON CONFLICT | | | Hoặc ghi id đã xử lý vào bảng phụ | |

INSERT INTO du_lieu (id_ban_ghi, noi_dung)
VALUES ($1, $2)
ON CONFLICT (id_ban_ghi) DO NOTHING;

Ba lưu ý về consumer tại chỗ: | Lưu ý | Chi tiết | |---|---| | Chạy nhiều tiến trình để tăng thông lượng | | | Long polling giảm chi phí lời gọi | | | Cần credential AWS — dùng IAM Roles Anywhere | |

⚠ IAM Roles Anywhere thay khoá tĩnh cho máy tại chỗ:

Máy tại chỗ cần gọi SQS
    → truyền thống: access key tĩnh
        ↓
    IAM Roles Anywhere: dùng chứng chỉ
      X.509 đổi lấy credential tạm
    → không có khoá tĩnh nào

Ba lưu ý về visibility timeout: | Lưu ý | Chi tiết | |---|---| | Dài hơn thời gian xử lý một lô | | | Quá ngắn: xử lý trùng | | | Quá dài: thông điệp lỗi chậm được thử lại | |

Ba lưu ý về dead-letter queue: | Lưu ý | Chi tiết | |---|---| | Bản ghi hỏng không chặn hàng đợi mãi | | | Đặt maxReceiveCount khoảng 3-5 | | | Cảnh báo khi DLQ có thông điệp | |

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | ApproximateAgeOfOldestMessage | tăng đều — consumer chết hoặc chậm | | ApproximateNumberOfMessagesVisible | dồn quá mức | | Độ sâu DLQ | lớn hơn 0 |

⚠ Chỉ số đầu là cảnh báo quan trọng nhất:

Consumer tại chỗ chết
    → không có gì báo cho bạn
        ↓
    Tuổi thông điệp cũ nhất tăng dần
    → chạm 14 ngày là MẤT DỮ LIỆU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy đỉnh ghi, xem ứng dụng còn ổn định | | | Ngắt consumer, xem hàng đợi dồn rồi xử lý bù | | | Kiểm không có bản ghi nào bị ghi hai lần | |

Và một lời khuyên: hãy đặt cảnh báo trên tuổi thông điệp cũ nhất ngay khi dựng hàng đợi. Consumer chạy tại chỗ không có health check nào của AWS trông chừng — và chỉ số đó là dấu hiệu duy nhất cho biết nó đã chết, trước khi hàng đợi chạm giới hạn giữ và dữ liệu bắt đầu biến mất.

Trang 19 / 123 — tổng 1221 câu hỏi