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

Tìm thấy 1221 câu.

Câu 1 Domain - Continuous Improvement for Existing Solutions

A company has several AWS accounts that are managed using AWS Organizations. The company created only one organizational unit (OU) so all child accounts are members of the Production OU. The Solutions Architects control access to certain AWS services using SCPs that define the restricted services. The SCPs are attached at the root of the organization so that they will be applied to all AWS accounts under the organization. The company recently acquired a small business firm and its existing AWS account was invited to join the organization. Upon onboarding, the administrators of the small business firm cannot apply the required AWS Config rules to meet the parent company’s security policies.

Which of the following options will allow the administrators to update the AWS Config rules on their AWS account without introducing long-term management overhead?

A
Instead of using a “deny list” to AWS services on the organization’s root SCPs, use an “allow list” to allow only the required AWS services. Temporarily add the AWS Config service on the “allow list” for the principals of the new account and make the required changes.
B
Add the new account to a temporary Onboarding organization unit (OU) that has an attached SCP allowing changes to AWS Config. Perform the needed changes while on this temporary OU before moving the new account to Production OU.
C
Update the SCPs applied in the root of the AWS organization and remove the rule that restricts changes to the AWS Config service. Deploy a new AWS Service Catalog to the whole organization containing the company’s AWS Config policies.
D
Remove the SCPs on the organization’s root and apply them to the Production OU instead. Create a temporary Onboarding OU that has an attached SCP allowing changes to AWS Config. Add the new account to this temporary OU and make the required changes before moving it to Production OU.

Xem giải thích

Đáp án

D — Gỡ SCP khỏi root của tổ chức và gắn chúng vào Production OU; tạo một Onboarding OU tạm có SCP cho phép thay đổi AWS Config; đưa tài khoản mới vào OU tạm này, làm xong việc rồi chuyển sang Production OU.

Vì sao đúng

Đề mô tả một vấn đề kiến trúc rất cụ thể: SCP gắn ở ROOT thì không có OU nào thoát được nó.

⚠ SCP kế thừa từ trên xuống, và Deny thì không gỡ được:

SCP ở root: áp cho MỌI OU và MỌI tài khoản
    → tạo OU con với SCP "cho phép Config"
    → vẫn bị SCP ở root chặn
        ↓
    Quyền hiệu lực = GIAO của mọi cấp
    → một Deny ở bất kỳ cấp nào là chặn

Đây là lý do phương án B không hoạt động.

Cấu trúc đúng:

Root                      ← KHÔNG gắn SCP hạn chế
 ├── Production OU        ← gắn SCP hạn chế ở đây
 └── Onboarding OU (tạm)  ← SCP lỏng hơn

Thực hiện:

# 1. Gỡ SCP khỏi root
aws organizations detach-policy --policy-id p-han-che \
  --target-id r-root-id

# 2. Gắn vào Production OU
aws organizations attach-policy --policy-id p-han-che \
  --target-id ou-san-xuat

# 3. Tạo OU onboarding
aws organizations create-organizational-unit \
  --parent-id r-root-id --name Onboarding

# 4. Chuyển tài khoản mới vào đó
aws organizations move-account \
  --account-id 222222222222 \
  --source-parent-id ou-san-xuat \
  --destination-parent-id ou-onboarding

⚠ Sau khi làm xong thì chuyển tài khoản sang Production:

aws organizations move-account \
  --account-id 222222222222 \
  --source-parent-id ou-onboarding \
  --destination-parent-id ou-san-xuat

Vì sao đây là cách "không tạo gánh nặng quản lý lâu dài": | Điểm | Chi tiết | |---|---| | Không nới lỏng chính sách của Production | | | OU onboarding dùng lại cho mọi tài khoản mới | | | Không phải sửa SCP mỗi lần có tài khoản mới | |

⚠ Đây cũng là thiết kế OU đúng ngay từ đầu:

Đừng gắn SCP hạn chế ở ROOT
    → mất hết khả năng phân biệt giữa các OU
        ↓
    Gắn ở từng OU theo mức kiểm soát cần thiết

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

**B. Đưa tài khoản mới vào Onboarding OU có SCP cho phép Config, làm xong rồi chuyển sang Production — đây là phương án gần nhất và là đúng một nửa ý tưởng, nhưng nó bỏ qua việc SCP vẫn còn ở ROOT: OU con không thể cấp lại quyền mà cấp cha đã Deny.
**C. Gỡ luật hạn chế Config khỏi SCP ở root và triển khai Service Catalog — nới lỏng chính sách cho toàn bộ tổ chức chỉ vì một tài khoản; và Service Catalog để cấp phát tài nguyên, không phải để áp chính sách Config.
**A. Đổi sang allow list rồi tạm thêm Config vào danh sách — viết lại toàn bộ chiến lược SCP là thay đổi rủi ro và tốn công; và "tạm thêm" cho toàn tổ chức nghĩa là mọi tài khoản đều được quyền đó.

Ghi nhớ

⚠ Ba quy tắc SCP phải thuộc: | Quy tắc | Chi tiết | |---|---| | SCP KHÔNG cấp quyền | chỉ giới hạn quyền tối đa | | Kế thừa từ root xuống | quyền hiệu lực là GIAO | | Một Deny ở bất kỳ cấp nào là chặn | OU con không gỡ được |

⚠ Đây là điều nhiều người hiểu sai nhất về SCP:

"Tôi gắn SCP Allow ở OU con để mở lại quyền"
    → KHÔNG hoạt động
        ↓
    SCP ở cấp cha đã Deny thì cấp con không cứu được
    → phải gỡ Deny ở cấp cha

Ba ngoại lệ SCP không áp: | Ngoại lệ | Chi tiết | |---|---| | Management account | SCP KHÔNG áp cho nó | | Service-linked role | | | Hành động ngoài phạm vi Organizations | |

Từ khoá nhận diện:

"SCP at root blocks an OU-level exception" → chuyển SCP xuống OU "restrict actions across all accounts" → SCP "grant permissions" → IAM policy (SCP không cấp) "self-service provisioning of approved resources" → Service Catalog

⚠ Thiết kế OU theo MỨC KIỂM SOÁT, không theo phòng ban:

Root
 ├── Security OU     → SCP chặt nhất, không ai đụng được
 ├── Infrastructure  → mạng dùng chung
 ├── Workloads
 │    ├── Prod OU    → SCP chặt
 │    └── Dev OU     → SCP lỏng hơn
 ├── Sandbox OU      → rất lỏng + budget action
 └── Suspended OU    → Deny gần như mọi thứ

Ba chiến lược viết SCP: | Chiến lược | Cách làm | |---|---| | Deny list | giữ FullAWSAccess, thêm Deny — an toàn hơn | | Allow list | gỡ FullAWSAccess, chỉ Allow thứ cần | | Kết hợp | deny list ở root, chặt hơn ở OU |

⚠ Allow list rất dễ gây sự cố:

Gỡ FullAWSAccess
    → mọi hành động không nằm trong Allow đều bị chặn
        ↓
    Thiếu một action nhỏ = dịch vụ ngừng hoạt động
    → và lỗi chỉ hiện là AccessDenied

Ba lưu ý về gỡ lỗi SCP: | Lưu ý | Chi tiết | |---|---| | Lỗi chỉ hiện AccessDenied, không nói do SCP | | | CloudTrail ghi hành động bị từ chối | | | Luôn kiểm SCP khi IAM có vẻ đúng | |

⚠ Có công cụ mô phỏng SCP:

aws organizations describe-effective-policy \
  --policy-type SERVICE_CONTROL_POLICY \
  --target-id 222222222222

Xem chính sách HIỆU LỰC sau khi kế thừa
    → thay vì đoán qua từng cấp

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | Kích thước SCP | 5.120 byte | | SCP gắn mỗi thực thể | 5 | | Độ sâu OU | 5 cấp |

Ba SCP nên có sớm: | SCP | Chặn gì | |---|---| | Chặn tắt CloudTrail, Config, GuardDuty | | | Giới hạn Region | | | Chặn xoá tài nguyên bảo mật | |

⚠ SCP giới hạn Region phải loại trừ dịch vụ toàn cầu:

{"Effect": "Deny",
 "NotAction": ["iam:*","organizations:*","route53:*",
               "cloudfront:*","support:*","budgets:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:RequestedRegion": ["ap-southeast-1"]}}}

Ba lưu ý về Control Tower: | Lưu ý | Chi tiết | |---|---| | Dựng sẵn cấu trúc OU và guardrail | | | Guardrail bắt buộc không gỡ được | | | Account Factory tạo tài khoản chuẩn hoá | |

⚠ Control Tower gắn SCP ở OU, không ở root — đúng như bài học của câu này.

Ba lưu ý về quy trình onboarding: | Bước | Chi tiết | |---|---| | Mời tài khoản vào tổ chức | | | Đưa vào OU onboarding | | | Chạy baseline rồi chuyển sang OU đích | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem chính sách hiệu lực của tài khoản mới | | | Thử thao tác Config từ tài khoản đó | | | Xác nhận Production OU vẫn bị hạn chế | |

Và một lời khuyên: hãy không bao giờ gắn SCP hạn chế ở root của tổ chức. Nó tước đi khả năng phân biệt giữa các đơn vị tổ chức, và mọi ngoại lệ hợp lệ sau này — dù chỉ trong một giờ cho một tài khoản — đều buộc bạn phải nới lỏng chính sách cho tất cả mọi người.

Câu 2 Chọn nhiều đáp án Domain - Design Solutions for Organizational Complexity

An IT consulting company has multiple AWS accounts for its teams and departments that have been grouped into several organizational units (OUs) using AWS Organizations. The lead solutions architect received a report from the security team that there was a suspected breach in one of the environments wherein a third-party AWS account was suddenly added to the AWS Organization without any prior approval. The external account has high-level access privileges to the accounts that the company owns. Fortunately, no detrimental action was performed yet.

Which of the following actions should the solutions architect take to properly set up a monitoring system that notifies for any changes to the company AWS accounts? (Select TWO.)

A
Set up a CloudWatch Dashboard to monitor any changes to your organizations and create an SNS topic that would send you a notification.
B
Create a trail in Amazon CloudTrail to capture all API calls to your AWS Organizations, including calls from the AWS Organizations console and from code calls to the AWS Organizations APIs. Use Amazon EventBridge and SNS to raise events when administrator-specified actions occur in an organization and send a notification to you.
C
Configure AWS Control Tower to manage and monitor all child accounts under the organization. Use Amazon Inspector to analyze any possible breach and notify the administrators using AWS SNS.
D
Use AWS Config to monitor the compliance of your AWS Organizations. Set up an SNS Topic or Amazon EventBridge that will send alerts to you for any changes.
E
Monitor all changes to your organization using Systems Manager and use Amazon EventBridge to notify you of any new activity to your account.

Xem giải thích

Đáp án

B và D — Tạo một trail CloudTrail ghi mọi lời gọi API tới AWS Organizations, dùng EventBridge và SNS để cảnh báo khi có hành động quản trị; và dùng AWS Config giám sát tuân thủ với SNS hoặc EventBridge gửi cảnh báo khi có thay đổi.

Vì sao đúng

Đề mô tả một sự cố nghiêm trọng — một tài khoản bên thứ ba được thêm vào tổ chức mà không ai duyệt — và cần hệ thống giám sát phát hiện mọi thay đổi.

Lựa chọn	Vai trò
B — CloudTrail + EventBridge + SNS	cảnh báo THỜI GIAN THỰC khi có API gọi tới Organizations
D — AWS Config	theo dõi trạng thái và tuân thủ liên tục

⚠ CloudTrail là nguồn sự thật duy nhất về "ai đã làm gì":

Ai gọi InviteAccountToOrganization?
    → chỉ CloudTrail trả lời được
        ↓
    Và EventBridge biến bản ghi đó thành cảnh báo
      ngay khi nó xảy ra

Quy tắc EventBridge cho các API nguy hiểm của Organizations:

{"source": ["aws.organizations"],
 "detail-type": ["AWS API Call via CloudTrail"],
 "detail": {
   "eventSource": ["organizations.amazonaws.com"],
   "eventName": [
     "InviteAccountToOrganization",
     "AcceptHandshake",
     "CreateAccount",
     "RemoveAccountFromOrganization",
     "DetachPolicy",
     "DeletePolicy",
     "UpdatePolicy",
     "LeaveOrganization"]}}

aws events put-rule --name canh-bao-to-chuc \
  --event-pattern file://mau.json

aws events put-targets --rule canh-bao-to-chuc \
  --targets 'Id=1,Arn=<arn-sns>'

⚠ Organizations là dịch vụ TOÀN CẦU — sự kiện chỉ xuất hiện ở us-east-1:

Tạo EventBridge rule ở ap-southeast-1
    → KHÔNG bao giờ nhận được sự kiện Organizations
        ↓
    Phải tạo rule ở us-east-1
    → hoặc chuyển tiếp sự kiện sang Region khác

Trail phải bật đúng cách:

aws cloudtrail create-trail --name duong-mon-to-chuc \
  --s3-bucket-name log-cloudtrail \
  --is-multi-region-trail --is-organization-trail \
  --include-global-service-events \
  --enable-log-file-validation --kms-key-id <arn-khoa>

⚠ --include-global-service-events là bắt buộc cho Organizations:

Không bật: sự kiện của IAM, Organizations, CloudFront
           KHÔNG được ghi
        ↓
    Đúng những dịch vụ nhạy cảm nhất bị bỏ sót

AWS Config bổ sung góc nhìn TRẠNG THÁI:

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

⚠ CloudTrail và Config trả lời hai câu hỏi khác nhau:

CloudTrail: "AI đã gọi API gì, lúc nào, từ đâu"
Config:     "tài nguyên ĐANG ở trạng thái nào,
             đã thay đổi ra sao"
        ↓
    Điều tra sự cố cần CẢ HAI

Ba lợi ích khi có cả hai: | Lợi ích | Chi tiết | |---|---| | Cảnh báo tức thì khi có thay đổi | | | Có lịch sử đầy đủ để điều tra | | | Đáp ứng yêu cầu kiểm toán | |

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

**C. Dùng Control Tower quản lý và Inspector phân tích vi phạm — đây là phương án gần nhất và Control Tower thật sự hữu ích cho quản trị nhiều tài khoản, nhưng Inspector quét LỖ HỔNG phần mềm (CVE) chứ không phân tích vi phạm quản trị; dịch vụ đúng cho việc đó là GuardDuty hoặc CloudTrail.
**A. Dùng CloudWatch Dashboard theo dõi thay đổi tổ chức — dashboard hiển thị metric, nó không phát hiện sự kiện quản trị và không tự gửi cảnh báo.
**E. Dùng Systems Manager theo dõi mọi thay đổi tổ chức — Systems Manager quản lý instance (vá, chạy lệnh, kiểm kê); nó không biết gì về cấu trúc AWS Organizations.

Ghi nhớ

⚠ Năm dịch vụ quan sát — bảng phải thuộc: | Dịch vụ | Trả lời | |---|---| | CloudTrail | "ai gọi API gì?" | | Config | "tài nguyên cấu hình ra sao, đổi gì?" | | CloudWatch | "hệ thống chạy thế nào?" | | EventBridge | "khi X xảy ra thì làm Y" | | GuardDuty | "có dấu hiệu bị tấn công không?" |

Từ khoá nhận diện:

"notify when organization changes" → CloudTrail + EventBridge + SNS "track configuration compliance" → Config "detect threats and compromise" → GuardDuty "scan for CVEs" → Inspector "manage instances" → Systems Manager

⚠ Các API của Organizations cần cảnh báo: | API | Vì sao nguy hiểm | |---|---| | InviteAccountToOrganization | thêm tài khoản lạ | | AcceptHandshake | chấp nhận lời mời | | RemoveAccountFromOrganization | tách tài khoản khỏi tầm kiểm soát | | DetachPolicy, DeletePolicy | gỡ SCP | | LeaveOrganization | tài khoản tự tách ra |

Ba lưu ý về bảo vệ chính CloudTrail: | Lưu ý | Chi tiết | |---|---| | Bucket log ở TÀI KHOẢN RIÊNG | | | Object Lock chế độ Compliance | | | Cảnh báo cho StopLogging và DeleteTrail | |

⚠ Việc đầu tiên kẻ tấn công làm là tắt log:

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

Ba lưu ý về organization trail: | Lưu ý | Chi tiết | |---|---| | Tạo từ management account | | | Ghi log của MỌI tài khoản thành viên | | | Tài khoản thành viên không tắt được | |

Ba lưu ý về GuardDuty (nên bật cùng): | Lưu ý | Chi tiết | |---|---| | Phát hiện hành vi bất thường tự động | | | auto-enable-organization-members ALL | | | Bổ sung cho cảnh báo dựa trên quy tắc | |

⚠ Cảnh báo theo quy tắc chỉ bắt được thứ bạn đã nghĩ tới:

EventBridge rule: bắt các API bạn liệt kê
    → API mới hoặc kỹ thuật mới thì lọt
        ↓
    GuardDuty: phát hiện theo mẫu bất thường
    → bắt được thứ chưa ai nghĩ tới

Ba lưu ý về Config rules cho Organizations: | Quy tắc | Kiểm tra | |---|---| | account-part-of-organizations | tài khoản có trong tổ chức | | cloudtrail-enabled | | | guardduty-enabled-centralized | |

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Gom phát hiện từ Config, GuardDuty, Inspector, Macie | | | Tiêu chuẩn AWS Foundational Security Best Practices | | | Một màn hình cho toàn tổ chức | |

Ba lưu ý về phản ứng: | Bước | Chi tiết | |---|---| | Có runbook cho từng loại cảnh báo | | | Người trực nhận được cảnh báo ngoài giờ | | | Diễn tập quy trình phản ứng | |

⚠ Cảnh báo không ai đọc là cảnh báo không tồn tại:

SNS gửi email vào hộp thư chung
    → không ai kiểm tra ngoài giờ
        ↓
    Đưa cảnh báo nghiêm trọng vào hệ thống trực
      (PagerDuty, Opsgenie) qua SNS

Ba lưu ý về giảm nhiễu: | Lưu ý | Chi tiết | |---|---| | Lọc bỏ hoạt động tự động hợp lệ | | | Tách cảnh báo nghiêm trọng và thông tin | | | Rà lại quy tắc định kỳ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thực hiện một thay đổi thử | | | Xác nhận cảnh báo tới nơi trong vài phút | | | Chạy validate-logs của CloudTrail | |

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

Và một lời khuyên: hãy tạo quy tắc EventBridge cho Organizations ở us-east-1. Organizations là dịch vụ toàn cầu và sự kiện của nó chỉ xuất hiện ở Region đó — một quy tắc hoàn hảo đặt sai Region sẽ im lặng suốt đời mà không có gì báo cho bạn biết nó chưa từng khớp lần nào.

Câu 3 Domain - Continuous Improvement for Existing Solutions

A company wants to host its internal web application in AWS. The front-end uses Docker containers and it connects to a MySQL instance as the backend database. The company plans to use AWS-managed container services to reduce the overhead in managing the servers. The application should allow employees to access company documents, which are accessed frequently for the first 3 months and then rarely after that. As part of the company policy, these documents must be retained for at least five years. Because this is an internal web application, the company wants to have the lowest possible cost.

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

A
Deploy the Docker containers using Amazon Elastic Container Service (ECS) with Amazon EC2 On-Demand instances. Use On-Demand instances as well for the Amazon RDS database and its read replicas. Create an Amazon EFS volume that is mounted on the EC2 instances to store the company documents. Create a cron job that will copy the documents to Amazon S3 Glacier after three months and then create a bucket lifecycle policy that will delete objects older than five years.
B
Deploy the Docker containers using Amazon Elastic Container Service (ECS) with Amazon EC2 Spot Instances. Ensure that Spot Instance draining is enabled on the ECS agent config. Use Reserved instance for the Amazon RDS database and its read replicas. Create an encrypted Amazon S3 bucket to store the company documents. Create a bucket lifecycle policy that will move the documents to Amazon S3 Glacier after three months and will delete objects older than five years.
C
Deploy the Docker containers using Amazon Elastic Container Service (ECS) with Amazon EC2 Spot Instances. Use Spot instances for the Amazon RDS database and its read replicas. Create an encrypted ECS volume on the EC2 hosts that is shared with the containers to store the company documents. Set up a cron job that will delete the files after five years.
D
Deploy the Docker containers using Amazon Elastic Kubernetes Service (EKS)with auto-scaling enabled. Use Amazon EC2 Spot instances for the EKS cluster to further reduce costs. Use On-Demand instances for the Amazon RDS database and its read replicas. Create an encrypted Amazon S3 bucket to store the company documents. Create a bucket lifecycle policy that will move the documents to Amazon S3 Glacier after three months and will delete objects older than five years.

Xem giải thích

Đáp án

B — Triển khai container bằng ECS trên EC2 Spot Instance (bật Spot Instance draining trong cấu hình ECS agent), dùng Reserved Instance cho RDS và read replica, tạo bucket S3 mã hoá cho tài liệu với lifecycle policy chuyển sang Glacier sau 3 tháng và xoá sau 5 năm.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này tối ưu chi phí ở từng tầng: | Tầng | Đặc điểm tải | Lựa chọn tiết kiệm | |---|---|---| | Container (ứng dụng nội bộ) | chịu được gián đoạn | Spot Instance | | CSDL | chạy liên tục 24/7 | Reserved Instance | | Tài liệu (3 tháng nóng, sau đó nguội) | ít truy cập về sau | S3 + lifecycle sang Glacier |

⚠ Mỗi tầng có mô hình mua RẺ NHẤT riêng — đây là ý chính:

Tải chịu được gián đoạn → Spot (giảm tới 90%)
Tải chạy liên tục       → Reserved (giảm tới 72%)
Dữ liệu nguội dần       → lifecycle sang lớp rẻ hơn
        ↓
    Dùng SAI mô hình cho tầng nào là mất tiền ở tầng đó

⚠ Spot Instance draining là chi tiết bắt buộc:

# /etc/ecs/ecs.config trên EC2
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true

Không bật: AWS lấy lại máy sau 2 phút cảnh báo
    → task bị giết đột ngột, request đang xử lý mất
        ↓
    Bật: ECS đặt instance vào trạng thái DRAINING
    → chuyển task sang máy khác trước khi máy biến mất

⚠ Vì sao Spot hợp cho tầng ứng dụng nhưng SAI cho CSDL:

Container không trạng thái: mất một máy → task chạy chỗ khác
        ↓
CSDL trên Spot: mất máy = mất CSDL
    → đây là lý do phương án C sai nghiêm trọng

Lifecycle policy cho tài liệu:

aws s3api put-bucket-lifecycle-configuration \
  --bucket tai-lieu-cong-ty \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "nguoi-dan-va-xoa",
      "Filter": {"Prefix": ""},
      "Status": "Enabled",
      "Transitions": [{"Days": 90, "StorageClass": "GLACIER"}],
      "Expiration": {"Days": 1825}}]}'

⚠ Vì sao S3 hơn EFS cho tài liệu: | Tiêu chí | S3 | EFS | |---|---|---| | Giá mỗi GB | ~0,023 USD | ~0,30 USD | | Lifecycle sang Glacier | ✅ tự động | chỉ IA/Archive | | Giữ 5 năm | rẻ hơn ~10 lần | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Spot giảm tới 90% chi phí tính toán | | | RI giảm tới 72% chi phí CSDL | | | Glacier giảm ~85% chi phí lưu trữ dài hạn | |

⚠ Ứng dụng NỘI BỘ là chi tiết cho phép dùng Spot:

Đề nói "internal web application"
    → gián đoạn ngắn chấp nhận được
        ↓
    Với ứng dụng khách hàng, cân nhắc trộn
      On-Demand làm nền + Spot cho phần đỉnh

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

**D. ECS trên EKS với Spot cho cụm, On-Demand cho RDS, S3 + lifecycle — đây là phương án gần nhất và phần lưu trữ hoàn toàn đúng, nhưng dùng On-Demand cho CSDL chạy 24/7 là bỏ lỡ khoản giảm giá lớn nhất; và EKS thêm phí control plane (~73 USD/tháng) mà đề không cần.
**C. Spot cho cả RDS và dùng ECS volume trên EC2 host lưu tài liệu — hai lỗi nghiêm trọng: RDS không có tuỳ chọn Spot, và lưu tài liệu phải giữ 5 năm trên đĩa của máy Spot là chắc chắn mất dữ liệu.
**A. On-Demand cho cả container lẫn CSDL, EFS + cron chép sang Glacier — đắt nhất ở mọi tầng, và tự viết cron thay cho lifecycle policy là công vận hành không cần thiết.

Ghi nhớ

⚠ Bốn mô hình mua EC2 — bảng phải thuộc: | Mô hình | Giảm giá | Cam kết | Dùng cho | |---|---|---|---| | On-Demand | 0% | không | tải ngắn, không đoán trước | | Spot | tới 90% | không | chịu được gián đoạn | | Savings Plans / RI | tới 72% | 1-3 năm | tải ổn định 24/7 | | Dedicated Host | — | tuỳ | tuân thủ, license theo socket |

⚠ Quy tắc chọn theo tầng:

Tầng ứng dụng không trạng thái → Spot
Tầng CSDL, hạ tầng nền        → Reserved / Savings Plans
Tải đỉnh không đoán trước      → On-Demand

Từ khoá nhận diện:

"internal app, fault-tolerant, lowest cost" → Spot "database running 24/7" → Reserved Instance "documents accessed for 3 months then rarely" → S3 lifecycle "must retain 5 years" → Glacier + Expiration

Ba lưu ý về Spot với ECS: | Lưu ý | Chi tiết | |---|---| | Bật ECS_ENABLE_SPOT_INSTANCE_DRAINING | | | Khai nhiều loại instance trong ASG | | | Trộn On-Demand làm nền bằng capacity provider | |

⚠ Capacity provider strategy cho phép trộn:

{"capacityProviderStrategy": [
  {"capacityProvider": "on-demand", "base": 2, "weight": 1},
  {"capacityProvider": "spot", "weight": 4}]}

2 task đầu luôn chạy On-Demand
    → phần còn lại 80% Spot
        ↓
    Vừa rẻ vừa có nền ổn định

Ba lưu ý về đa dạng loại instance: | Lưu ý | Chi tiết | |---|---| | Khai 6+ loại tương đương | | | Trải nhiều AZ | | | Giảm xác suất mất toàn bộ cùng lúc | |

Ba lưu ý về Reserved Instance cho RDS: | Lưu ý | Chi tiết | |---|---| | Khớp theo engine, class, Region | | | Size flexibility trong cùng họ | | | Read replica cũng dùng RI được | |

⚠ RDS RI có tính linh hoạt về cỡ:

Mua RI cho db.r6g.large
    → áp được cho 2 × db.r6g.medium
        ↓
    Chỉ trong cùng họ và cùng Region

Ba lưu ý về lifecycle S3: | Lưu ý | Chi tiết | |---|---| | Glacier lưu tối thiểu 90 ngày | | | Object nhỏ hơn 128 KB không nên chuyển | | | Phí chuyển tính theo SỐ OBJECT | |

⚠ Lọc theo kích thước để tránh lỗ:

{"Filter": {"And": {"Prefix": "", "ObjectSizeGreaterThan": 131072}}}

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | SSE-KMS cho tài liệu công ty | | | Bật S3 Bucket Key giảm phí KMS | | | Mã hoá lan sang Glacier tự động | |

Ba lưu ý về Fargate Spot (lựa chọn thay thế): | Lưu ý | Chi tiết | |---|---| | Giảm tới 70% | | | Không phải quản lý EC2 nào | | | Cũng có cảnh báo 2 phút | |

⚠ Fargate Spot ít việc hơn EC2 Spot:

EC2 Spot: phải quản lý ASG, ECS agent, draining
        ↓
Fargate Spot: AWS lo hết
    → giảm ít hơn (70% vs 90%) nhưng đơn giản hơn nhiều

Ba lưu ý về theo dõi chi phí: | Việc | Cách | |---|---| | Cost Explorer lọc theo purchase option | | | Gắn tag cho từng tầng | | | Xem RI utilization report | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô phỏng bị lấy lại Spot bằng FIS | | | Kiểm tra draining hoạt động | | | Xác nhận object cũ đã sang Glacier | |

Và một lời khuyên: hãy bật Spot Instance draining trước khi đưa Spot vào sản xuất. Không có nó, cảnh báo hai phút của AWS trôi qua trong im lặng và các container bị giết giữa chừng — biến khoản tiết kiệm 90% thành một chuỗi lỗi ngẫu nhiên mà không ai giải thích được.

Câu 4 Domain - Continuous Improvement for Existing Solutions

A multinational financial firm plans to do a multi-regional deployment of its cryptocurrency trading application that’s being heavily used in the US and in Europe. The containerized application uses Kubernetes and has Amazon DynamoDB Global Tables as a centralized database to store and sync the data from two regions.

The architecture has distributed computing resources with several public-facing Application Load Balancers (ALBs). The Network team of the firm manages the public DNS internally and wishes to make the application available through an apex domain for easier access. S3 Multi-Region Access Points are also used for object storage workloads and hosting static assets.

Which is the MOST operationally efficient solution that the Solutions Architect should implement to meet the above requirements?

A
Set up an AWS Transit Gateway with a multicast domain that targets specific ALBs on the required AWS Regions. Create a public record in Amazon Route 53 using the static IP address of the AWS Transit Gateway.
B
Set up an AWS Global Accelerator, which has several endpoint groups that target specific endpoints and ALBs on the required AWS Regions. Create a public alias record in Amazon Route 53 that points your custom domain name to the DNS name assigned to your accelerator.
C
Launch an AWS Transit Gateway that targets specific ALBs on the required AWS Regions. Create a CNAME record in Amazon Route 53 that directly points your custom domain name to the DNS name assigned to the AWS Transit Gateway.
D
Launch an AWS Global Accelerator with several endpoint groups that target the ALBs in all the relevant AWS Regions. Create an Amazon Route 53 Resolver Inbound Endpoint that points your custom domain name to the CNAME assigned to your accelerator.

Xem giải thích

Đáp án

B — Dựng AWS Global Accelerator với nhiều endpoint group trỏ tới các ALB ở từng Region, và tạo bản ghi alias công khai trong Route 53 trỏ tên miền tuỳ chỉnh tới tên DNS của accelerator.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Nhiều ALB công khai ở nhiều Region | endpoint group cho từng Region | | Truy cập qua APEX DOMAIN | alias record — CNAME không dùng được ở apex | | Hiệu quả vận hành nhất | một điểm vào, IP tĩnh, không quản lý gì |

⚠ "Apex domain" là chi tiết loại bỏ mạnh nhất:

Apex domain = tên miền gốc, ví dụ vidu.com
              (không phải www.vidu.com)
        ↓
    Chuẩn DNS KHÔNG cho phép CNAME ở apex
    → vì apex đã có bản ghi SOA và NS
        ↓
    Route 53 giải quyết bằng ALIAS record

Đây chính là lý do phương án C sai — nó dùng CNAME.

Tạo alias record ở apex:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{
    "Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"vidu.com","Type":"A",
      "AliasTarget":{
        "HostedZoneId":"Z2BJ6XQ5FK7U4H",
        "DNSName":"abc123.awsglobalaccelerator.com",
        "EvaluateTargetHealth":true}}}]}'

⚠ Z2BJ6XQ5FK7U4H là hosted zone ID cố định của Global Accelerator — giống nhau ở mọi Region.

Ba lợi ích của alias record: | Lợi ích | Chi tiết | |---|---| | Dùng được ở apex domain | | | MIỄN PHÍ truy vấn | CNAME thì tính phí | | Tự cập nhật khi IP đích đổi | |

Dựng Global Accelerator:

aws globalaccelerator create-accelerator --name gia-toc-toan-cau

aws globalaccelerator create-listener --accelerator-arn <arn> \
  --protocol TCP --port-ranges FromPort=443,ToPort=443

for vung in us-east-1 eu-west-1; do
  aws globalaccelerator create-endpoint-group \
    --listener-arn <arn-listener> \
    --endpoint-group-region $vung \
    --endpoint-configurations EndpointId=<arn-alb>,Weight=100 \
    --traffic-dial-percentage 100
done

⚠ Global Accelerator định tuyến người dùng tới Region gần nhất:

Người dùng ở Mỹ → edge Mỹ → mạng riêng AWS → ALB us-east-1
Người dùng ở Đức → edge Đức → mạng riêng AWS → ALB eu-west-1
        ↓
    Và nếu một Region hỏng health check
    → tự chuyển sang Region còn lại

⚠ Vì sao "hiệu quả vận hành nhất":

Route 53 latency routing: phải tạo bản ghi cho từng Region
                          + health check cho từng cái
                          + phụ thuộc TTL khi chuyển vùng
        ↓
Global Accelerator: MỘT tên DNS, MỘT alias record
    → thêm Region = thêm endpoint group
    → chuyển vùng ở tầng mạng, không phụ thuộc DNS

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

**D. Global Accelerator với endpoint group nhưng dùng Route 53 Resolver Inbound Endpoint — Global Accelerator đúng, nhưng Resolver Inbound Endpoint để mạng tại chỗ truy vấn DNS riêng tư của VPC; nó hoàn toàn không liên quan tới việc trỏ tên miền công khai.
**C. Transit Gateway + CNAME record — sai hai lần: Transit Gateway nối các VPC với nhau chứ không phân phối lưu lượng Internet; và CNAME không dùng được ở apex domain.
**A. Transit Gateway với multicast domain + bản ghi trỏ IP tĩnh của Transit Gateway — Transit Gateway không có IP tĩnh công khai, và multicast dành cho ứng dụng phát đa hướng trong VPC, không phải phân phối lưu lượng web.

Ghi nhớ

⚠ Alias record vs CNAME — bảng phải thuộc: | Tiêu chí | Alias | CNAME | |---|---|---| | Dùng ở apex domain | ✅ | ❌ | | Phí truy vấn | miễn phí | có phí | | Trỏ tới | dịch vụ AWS | tên miền bất kỳ | | Health check của đích | đánh giá được | không |

⚠ Các đích alias record hỗ trợ: | Đích | |---| | CloudFront distribution | | Global Accelerator | | ALB, NLB, CLB | | API Gateway, VPC endpoint | | S3 static website | | Bản ghi khác trong cùng hosted zone |

Từ khoá nhận diện:

"apex/root domain pointing to AWS service" → alias record "multi-Region, TCP/UDP, static IPs, fast failover" → Global Accelerator "cache static content globally" → CloudFront "connect VPCs to each other" → Transit Gateway

⚠ Global Accelerator vs CloudFront trong bối cảnh này:

Ứng dụng giao dịch tiền mã hoá:
    → lưu lượng ĐỘNG, không cache được
    → cần độ trễ thấp và chuyển vùng nhanh
        ↓
    Global Accelerator hợp hơn
        ↓
    Nhưng tài sản tĩnh (đề có nhắc S3 Multi-Region
      Access Points) thì nên đặt sau CloudFront

Ba lưu ý về S3 Multi-Region Access Point: | Lưu ý | Chi tiết | |---|---| | Một endpoint toàn cầu cho nhiều bucket | | | Tự định tuyến tới bucket gần nhất | | | Hỗ trợ failover giữa các Region | |

Ba lưu ý về DynamoDB Global Tables (đề có dùng): | Lưu ý | Chi tiết | |---|---| | Active-active, ghi ở mọi Region | | | Xung đột giải quyết kiểu "last writer wins" | | | Độ trễ nhân bản thường dưới 1 giây | |

⚠ Kiến trúc của đề khá nhất quán:

Global Accelerator → ALB đa Region
DynamoDB Global Tables → dữ liệu đa Region
S3 MRAP → object đa Region
        ↓
    Mọi tầng đều active-active

Ba tính năng của Global Accelerator: | Tính năng | Việc | |---|---| | Traffic dial | giảm % lưu lượng vào một Region | | Endpoint weight | chia tỷ lệ | | Client affinity | giữ client ở một endpoint |

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Global Accelerator tự kiểm ALB | | | ALB có health check riêng cho target | | | Endpoint hỏng bị rút tự động | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | ~0,025 USD/giờ mỗi accelerator | | | Phí truyền dữ liệu theo GB | | | Alias record miễn phí truy vấn | |

Ba lưu ý về IP tĩnh: | Lưu ý | Chi tiết | |---|---| | Hai IP anycast, không đổi | | | Dễ đưa vào allowlist của đối tác | | | BYOIP nếu cần dải IP riêng | |

Ba lưu ý về Route 53 hosted zone: | Lưu ý | Chi tiết | |---|---| | Đề nói đội mạng tự quản lý DNS công khai | | | Hosted zone công khai cho tên miền đó | | | Bản ghi alias trỏ tới accelerator | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig vidu.com trả về IP của accelerator | | | Đo độ trễ từ nhiều châu lục | | | Thử rút một Region bằng traffic dial | |

dig +short vidu.com
aws globalaccelerator describe-accelerator --accelerator-arn <arn> \
  --query "Accelerator.IpSets[0].IpAddresses"

Và một lời khuyên: hãy nhớ rằng CNAME không bao giờ dùng được ở apex domain. Đây là ràng buộc của chính chuẩn DNS chứ không phải của AWS, và alias record của Route 53 tồn tại chính vì lý do đó — nên bất kỳ phương án nào đề xuất CNAME cho tên miền gốc đều sai ngay từ đầu.

Câu 5 Domain - Continuous Improvement for Existing Solutions

A company is hosting its production environment in AWS Fargate. To save costs, the Chief Information Officer (CIO) wants to deploy its new development environment workloads on its on-premises servers as this leverages existing capital investments. As the Solutions Architect, you have been tasked by the CIO to provide a solution that will:

have both on-premises and Fargate managed in the same cluster
easily migrate development environment workloads running on-premises to production environment running in AWS Fargate
ensure consistent tooling and API experience across container-based workloads

Which of the following is the MOST operationally efficient solution that meets these requirements?

A
Use EKS Amazon Anywhere to simplify on-premises Kubernetes management with default component configurations and automated cluster management tools. This makes it easy to migrate the development workloads running on-premises to EKS in an AWS region on Fargate.
B
Install and configure AWS Outposts in your on-premises data center. Run Amazon ECS on AWS Outposts to launch the development environment workloads. Migrate development workloads to production that is running on AWS Fargate.
C
Install and configure AWS Outposts in your on-premises data center. Run Amazon EKS Anywhere on AWS Outposts to launch container-based workloads. Migrate development workloads to production that is running on AWS Fargate.
D
Utilize Amazon ECS Anywhere to streamline software management on-premises and on AWS with a standardized container orchestrator. This makes it easy to migrate the development workloads running on-premises to ECS in an AWS region on Fargate.

Xem giải thích

Đáp án

D — Dùng Amazon ECS Anywhere để chuẩn hoá việc điều phối container tại chỗ lẫn trên AWS, giúp dễ dàng chuyển tải phát triển từ tại chỗ sang ECS trên Fargate.

Vì sao đúng

Đề nêu ba yêu cầu, và ECS Anywhere đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Quản lý cả tại chỗ lẫn Fargate trong CÙNG một cụm | ECS Anywhere đăng ký máy tại chỗ vào cụm ECS | | Dễ chuyển tải từ tại chỗ sang Fargate | cùng task definition, chỉ đổi launch type | | Công cụ và API nhất quán | cùng ECS API, cùng CLI, cùng console |

⚠ "Cùng một cụm" là chi tiết quyết định:

ECS Anywhere đăng ký máy tại chỗ như một
"external instance" TRONG cụm ECS hiện có
        ↓
    Cùng cụm chứa cả external instance và Fargate
    → quản lý một chỗ, một API

Đăng ký máy tại chỗ:

aws ssm create-activation \
  --iam-role ecsAnywhereRole \
  --registration-limit 20 \
  --default-instance-name may-tai-cho

# Trên máy tại chỗ
curl -o ecs-anywhere-install.sh \
  https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh
sudo bash ecs-anywhere-install.sh \
  --region ap-southeast-1 --cluster cum-chung \
  --activation-id <id> --activation-code <ma>

⚠ ECS Anywhere dùng Systems Manager làm kênh điều khiển:

Máy tại chỗ cài SSM Agent và ECS Agent
    → đăng ký qua SSM activation
        ↓
    Không cần mở cổng vào từ Internet
    → máy chủ động gọi ra AWS

Chuyển tải sang Fargate — chỉ đổi launch type:

# Chạy tại chỗ
aws ecs run-task --cluster cum-chung \
  --launch-type EXTERNAL \
  --task-definition ung-dung:5

# Chạy trên Fargate — CÙNG task definition
aws ecs run-task --cluster cum-chung \
  --launch-type FARGATE \
  --task-definition ung-dung:5 \
  --network-configuration 'awsvpcConfiguration={
    subnets=[subnet-a,subnet-b],securityGroups=[sg-abc]}'

⚠ Đây chính là "dễ migrate" mà đề nói tới:

Cùng một task definition chạy được ở cả hai nơi
    → chuyển môi trường = đổi một tham số
        ↓
    Không phải đóng gói lại, không phải viết lại
      manifest

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần phần cứng đặc biệt | chạy trên máy sẵn có | | Tận dụng đầu tư phần cứng hiện tại | đúng ý CIO | | Một mặt phẳng điều khiển cho cả hai | |

⚠ Giới hạn của launch type EXTERNAL phải biết: | Giới hạn | Chi tiết | |---|---| | Không hỗ trợ network mode awsvpc | dùng bridge hoặc host | | Không dùng được ELB của AWS | tự lo cân bằng tải | | Không dùng service discovery của Cloud Map | |

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

**A. EKS Anywhere để quản lý Kubernetes tại chỗ — đây là phương án gần nhất và là dịch vụ thật, tương đương cho Kubernetes, nhưng EKS Anywhere tạo ra cụm ĐỘC LẬP tại chỗ, không phải cùng cụm với AWS; đề nói rõ "have both on-premises and Fargate managed in the same cluster".
**B. Outposts chạy ECS — Outposts đòi AWS gửi phần cứng riêng tới trung tâm dữ liệu; điều đó ngược thẳng với mục tiêu của CIO là tận dụng phần cứng đã đầu tư.
**C. Outposts chạy EKS Anywhere — sai cả hai vế: phải mua phần cứng Outposts, và EKS Anywhere không thiết kế để chạy trên Outposts.

Ghi nhớ

⚠ Bốn lựa chọn container lai — bảng phải thuộc: | Dịch vụ | Bản chất | Phần cứng | |---|---|---| | ECS Anywhere | máy tại chỗ vào CÙNG cụm ECS | của bạn | | EKS Anywhere | cụm Kubernetes ĐỘC LẬP tại chỗ | của bạn | | EKS Hybrid Nodes | node tại chỗ vào cụm EKS trên AWS | của bạn | | Outposts | rack của AWS đặt tại chỗ | AWS gửi tới |

⚠ Cách phân biệt nhanh nhất:

"Cùng một cụm với AWS"     → ECS Anywhere / EKS Hybrid Nodes
"Cụm riêng tại chỗ"        → EKS Anywhere
"Hạ tầng AWS đặt tại chỗ"  → Outposts

Từ khoá nhận diện:

"same cluster for on-premises and cloud, ECS" → ECS Anywhere "Kubernetes on-premises, own hardware" → EKS Anywhere "AWS hardware in my data center" → Outposts "use existing hardware investment" → loại Outposts

Ba lưu ý về Outposts: | Lưu ý | Chi tiết | |---|---| | AWS gửi rack tới, AWS bảo trì | | | Cam kết 3 năm | | | Dùng khi cần độ trễ rất thấp tới hệ thống tại chỗ | |

⚠ Outposts giải bài toán khác hẳn:

Outposts: cần API của AWS ngay tại chỗ
          vì lý do độ trễ hoặc chủ quyền dữ liệu
        ↓
ECS/EKS Anywhere: đã có phần cứng, muốn dùng
                  công cụ của AWS để quản lý nó

Ba lưu ý về ECS Anywhere: | Lưu ý | Chi tiết | |---|---| | Tính phí ~0,01 USD/giờ mỗi instance | | | Cần SSM Agent và ECS Agent | | | Máy phải gọi ra được AWS | |

Ba lưu ý về network mode: | Mode | ECS Anywhere hỗ trợ | |---|---| | bridge | ✅ | | host | ✅ | | awsvpc | ❌ |

⚠ Thiếu awsvpc nghĩa là không gắn security group cho task:

Trên AWS: mỗi task có ENI và security group riêng
        ↓
Tại chỗ: dùng mạng của máy chủ
    → phải tự lo tường lửa ở tầng hệ điều hành

Ba lưu ý về cân bằng tải: | Môi trường | Cách | |---|---| | Fargate | ALB hoặc NLB của AWS | | External instance | tự dựng (NGINX, HAProxy) | | Kết hợp | cần thiết kế riêng |

Ba lưu ý về đăng ký image: | Lưu ý | Chi tiết | |---|---| | ECR kéo được từ tại chỗ | | | Cần credential helper cho Docker | | | Hoặc ECR pull-through cache | |

aws ecr get-login-password --region ap-southeast-1 \
  | docker login --username AWS --password-stdin \
    <id>.dkr.ecr.ap-southeast-1.amazonaws.com

Ba lưu ý về log và metric: | Lưu ý | Chi tiết | |---|---| | Log driver awslogs hoạt động từ tại chỗ | | | Container Insights thu thập metric | | | Cùng một nơi xem cho cả hai môi trường | |

Ba lưu ý về EKS Hybrid Nodes (mới hơn): | Lưu ý | Chi tiết | |---|---| | Node tại chỗ vào cụm EKS trên AWS | | | Gần với ý "cùng một cụm" hơn EKS Anywhere | | | Ra mắt cuối 2024 | |

⚠ Nếu đề hỏi tương tự nhưng dùng Kubernetes:

"Cùng một cụm EKS" → EKS Hybrid Nodes
"Cụm riêng tại chỗ" → EKS Anywhere

Ba lưu ý về chuyển đổi môi trường: | Lưu ý | Chi tiết | |---|---| | Task definition dùng chung được | | | Nhưng network mode phải tương thích | | | Kiểm thử cả hai launch type trong CI | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | aws ecs list-container-instances thấy máy tại chỗ | | | Chạy cùng task ở cả hai launch type | | | Kiểm tra log đổ về cùng log group | |

aws ecs list-container-instances --cluster cum-chung \
  --filter "attribute:ecs.capability.external exists"

Và một lời khuyên: hãy kiểm tra task definition không dùng network mode awsvpc trước khi lên kế hoạch chạy nó tại chỗ. Launch type EXTERNAL không hỗ trợ chế độ đó, và một định nghĩa task chạy hoàn hảo trên Fargate có thể đơn giản là không khởi động được trên máy tại chỗ vì lý do duy nhất đó.

Câu 6 Domain - Design for New Solutions

A tech company will soon launch a new smartwatch that will collect statistics and usage information from its users. The solutions architect was tasked to design a data storage and retrieval solution for the receiving application. The application is expected to ingest millions of records per minute from its worldwide user base. For the storage requirements:

Each record is less than 4KB in size.

Data must be stored durably.

Data must be stored for 120 days only, then it can be deleted.

Data must have low latency retrieval time.

For running the application for a year, the estimated storage requirement is around 10-15 TB.

Which of the following options is the recommended storage solution while being the most cost-effective?

A
Configure the application to receive the records and store the records to Amazon Aurora Serverless. Write an AWS Lambda function that runs a query to delete records older than 120 days. Schedule the function to run every night.
B
Configure the application to receive the records and set the storage to a DynamoDB table. Configure proper scaling on the DynamoDB table and enable the DynamoDB table Time to Live (TTL) setting to delete records after 120 days.
C
Use Amazon Kinesis Data Stream to ingest and store the records. Set a custom data retention period of 120 days for the data stream. Send the streamed data to an Amazon S3 bucket for added durability.
D
Configure the application to ingest the records and store each record on a dedicated Amazon S3 bucket. Ensure that a unique filename is set for each object. Create an S3 bucket lifecycle policy to expire objects that are older than 120 days.

Xem giải thích

Đáp án

B — Cấu hình ứng dụng ghi bản ghi vào một bảng DynamoDB, cấu hình mở rộng phù hợp và bật Time to Live (TTL) để tự xoá bản ghi sau 120 ngày.

Vì sao đúng

Đề cho năm ràng buộc, và DynamoDB khớp cả năm: | Ràng buộc | Cách đáp ứng | |---|---| | Hàng TRIỆU bản ghi mỗi phút | DynamoDB mở rộng ngang không giới hạn thực tế | | Mỗi bản ghi dưới 4 KB | vừa một WCU, tối ưu chi phí | | Bền vững | nhân bản qua 3 AZ tự động | | Giữ 120 ngày rồi xoá | TTL — tự xoá, MIỄN PHÍ | | Truy xuất độ trễ thấp | mili giây một chữ số |

⚠ TTL là chi tiết làm cho phương án này thắng rõ ràng:

aws dynamodb update-time-to-live --table-name ThongKeThietBi \
  --time-to-live-specification 'Enabled=true,AttributeName=hetHan'

Xoá bằng DeleteItem: tốn WCU cho mỗi bản ghi
    → hàng tỷ bản ghi = khoản tiền lớn
        ↓
    TTL: AWS xoá trong nền, KHÔNG tốn WCU
    → đúng nghĩa miễn phí

Ghi bản ghi kèm mốc hết hạn:

import time, boto3
bang = boto3.resource('dynamodb').Table('ThongKeThietBi')

bang.put_item(Item={
    'maThietBi': ma,
    'thoiDiem': moc_thoi_gian,
    'nhipTim': 72,
    'buocChan': 1520,
    'hetHan': int(time.time()) + 120*24*3600})

⚠ Kích thước 4 KB khớp chính xác với đơn vị WCU:

1 WCU = ghi 1 KB mỗi giây
    → bản ghi 4 KB = 4 WCU
        ↓
    Bản ghi 4,1 KB = 5 WCU
    → giữ dưới 4 KB là tối ưu chi phí

Thiết kế khoá cho hàng triệu bản ghi mỗi phút:

aws dynamodb create-table --table-name ThongKeThietBi \
  --attribute-definitions \
    AttributeName=maThietBi,AttributeType=S \
    AttributeName=thoiDiem,AttributeType=S \
  --key-schema \
    AttributeName=maThietBi,KeyType=HASH \
    AttributeName=thoiDiem,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --sse-specification Enabled=true,SSEType=KMS

⚠ Partition key là maThietBi — phân tán rất đều:

Hàng triệu thiết bị khác nhau
    → khoá phân vùng có độ đa dạng cực cao
        ↓
    Không có hot partition
    → khác hẳn nếu dùng ngày làm khoá phân vùng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ nào để quản lý | | | Mở rộng tức thì theo lưu lượng | | | Truy xuất theo thiết bị rất nhanh | |

⚠ TTL không xoá tức thì — thường trong 48 giờ:

Bản ghi hết hạn vẫn nằm trong bảng một thời gian
    → truy vấn có thể trả về chúng
        ↓
    Lọc thêm ở tầng ứng dụng nếu cần chính xác:
    FilterExpression = 'hetHan > :bay_gio'

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

**C. Dùng Kinesis Data Stream giữ 120 ngày rồi đẩy sang S3 — đây là phương án gần nhất và Kinesis đúng cho việc NHẬN luồng dữ liệu, nhưng nó là kho tạm để xử lý theo luồng, không phải kho truy xuất; đọc một bản ghi cụ thể từ stream đòi duyệt tuần tự shard, hoàn toàn không phải "low latency retrieval".
**D. Ghi mỗi bản ghi thành một object S3 riêng — hàng triệu object nhỏ mỗi phút: chạm giới hạn 3.500 PUT mỗi giây mỗi tiền tố, chi phí request khổng lồ, và độ trễ đọc cao hơn nhiều so với DynamoDB.
**A. Dùng Aurora Serverless + Lambda xoá mỗi đêm — CSDL quan hệ không chịu nổi hàng triệu ghi mỗi phút mà không phân mảnh; và câu DELETE hàng loạt mỗi đêm là thao tác nặng, khoá bảng và sinh nhiều I/O.

Ghi nhớ

⚠ Bốn kho dữ liệu cho luồng IoT — bảng phải thuộc: | Kho | Vai trò | |---|---| | Kinesis Data Streams | NHẬN và ĐỆM luồng, đọc lại được | | DynamoDB | LƯU và TRUY XUẤT theo khoá, độ trễ thấp | | Timestream | chuỗi thời gian, truy vấn theo khoảng | | S3 | lưu trữ dài hạn, phân tích |

⚠ Amazon Timestream đáng cân nhắc cho đúng bài này:

Dữ liệu cảm biến theo thời gian
    → Timestream có tầng nhớ và tầng từ tính
    → tự chuyển và tự xoá theo chính sách
        ↓
    Nhưng nó không có trong bốn phương án
    → và DynamoDB + TTL đáp ứng đủ yêu cầu

Từ khoá nhận diện:

"millions of records/min, key-value, low latency, auto-expire" → DynamoDB + TTL "real-time stream processing" → Kinesis "time-series queries over ranges" → Timestream "analytics on historical data" → S3 + Athena

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | Thuộc tính phải là số epoch (giây) | | | Xoá trong nền, có thể trễ tới 48 giờ | | | Không tốn WCU | |

⚠ TTL ghi vào Streams — dùng để lưu trữ trước khi xoá:

Bật DynamoDB Streams
    → sự kiện REMOVE khi TTL xoá bản ghi
        ↓
    Lambda đọc và đẩy sang S3
    → giữ lịch sử dài hạn với chi phí thấp

Ba lưu ý về chế độ tính phí: | Chế độ | Khi nào | |---|---| | On-demand | tải thất thường, mới bắt đầu | | Provisioned + auto scaling | tải ổn định — rẻ hơn nhiều | | Chuyển đổi được | mỗi 24 giờ một lần |

⚠ Với hàng triệu ghi mỗi phút ĐỀU ĐẶN, Provisioned rẻ hơn:

On-demand đắt hơn ~6-7 lần mỗi request
    → tải đều 24/7 thì nên Provisioned
        ↓
    Cộng thêm Reserved Capacity giảm tới 77%

aws dynamodb purchase-reserved-capacity-offerings \
  --reserved-capacity-offerings-id <id> --reservation-id <ten>

Ba lưu ý về ước tính dung lượng: | Tính toán | Kết quả | |---|---| | 10-15 TB cho một năm | | | Giữ 120 ngày ≈ 1/3 năm | ~3-5 TB thường trực | | ~0,25 USD/GB-tháng | ~1.000 USD/tháng lưu trữ |

Ba lưu ý về ghi hàng loạt: | Lưu ý | Chi tiết | |---|---| | BatchWriteItem tới 25 item mỗi lần | | | Giảm số lời gọi API | | | Vẫn tính WCU như ghi riêng lẻ | |

Ba lưu ý về hot partition: | Lưu ý | Chi tiết | |---|---| | Khoá phân vùng phải đa dạng | | | Adaptive capacity giúp một phần | | | Theo dõi ThrottledRequests | |

⚠ Dùng ngày làm partition key là sai lầm kinh điển:

Partition key = "2026-08-30"
    → MỌI ghi trong ngày dồn vào một phân vùng
        ↓
    Throttle dù bảng còn thừa năng lực rất nhiều

Ba lưu ý về truy vấn: | Thao tác | Chi phí | |---|---| | GetItem | rẻ nhất | | Query theo maThietBi + khoảng thời gian | rẻ, đúng mẫu của đề | | Scan | đắt nhất — tránh |

Ba lưu ý về sao lưu: | Cách | Chi tiết | |---|---| | Point-in-time recovery | 35 ngày | | On-demand backup | giữ vô hạn | | Export sang S3 | không tốn RCU |

Ba lưu ý về nhận dữ liệu: | Lưu ý | Chi tiết | |---|---| | IoT Core hoặc API Gateway ở đầu vào | | | Cân nhắc Kinesis làm bộ đệm | | | Lambda ghi vào DynamoDB | |

⚠ Kinesis ĐỆM trước DynamoDB là mẫu tốt:

IoT → Kinesis Data Streams → Lambda → DynamoDB
        ↓
    Kinesis hấp thụ đỉnh
    → Lambda ghi theo nhịp DynamoDB chịu được
    → và dữ liệu đọc lại được nếu xử lý lỗi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Theo dõi ThrottledRequests | | | Kiểm tra bản ghi cũ bị TTL xoá | | | Đo độ trễ GetItem p99 | |

Và một lời khuyên: hãy chuyển sang chế độ Provisioned với Reserved Capacity sau khi tải đã ổn định. On-demand rất hợp lúc mới ra mắt khi chưa biết lưu lượng, nhưng với hàng triệu ghi mỗi phút đều đặn thì nó đắt hơn nhiều lần so với mức năng lực bạn hoàn toàn đoán được.

Câu 7 Domain - Design for New Solutions

An innovative Business Process Outsourcing (BPO) startup is planning to launch a scalable and cost-effective call center system using AWS. The system should be able to receive inbound calls from thousands of customers and generate user contact flows. Callers must have the capability to perform basic tasks such as changing their password or checking their balance without them having to speak to a call center agent. It should also have advanced deep learning functionalities such as automatic speech recognition (ASR) to achieve highly engaging user experiences and lifelike conversational interactions. A feature that allows the solution to query other business applications and send relevant data back to callers must also be implemented.

Which of the following is the MOST suitable solution that the Solutions Architect should implement?

A
Set up a cloud-based contact center using the Amazon Connect service. Create a conversational chatbot using Amazon Lex with automatic speech recognition and natural language understanding to recognize the intent of the caller then integrate it with Amazon Connect. Connect the solution to various business applications and other internal systems using AWS Lambda functions.
B
Set up a cloud-based contact center using the AWS Ground Station service. Create a conversational chatbot using Amazon Alexa for Business with automatic speech recognition and natural language understanding to recognize the intent of the caller then integrate it with AWS Ground Station. Connect the solution to various business applications and other internal systems using AWS Lambda functions.
C
Set up a cloud-based contact center using the Amazon Connect service. Create a conversational chatbot using Amazon Comprehend with automatic speech recognition and natural language understanding to recognize the intent of the caller then integrate it with Amazon Connect. Connect the solution to various business applications and other internal systems using AWS Lambda functions.
D
Set up a cloud-based contact center using the AWS Elemental MediaConnect service. Create a conversational chatbot using Amazon Polly with automatic speech recognition and natural language understanding to recognize the intent of the caller then integrate it with AWS Elemental MediaConnect. Connect the solution to various business applications and other internal systems using AWS Lambda functions.

Xem giải thích

Đáp án

A — Dựng tổng đài đám mây bằng Amazon Connect; tạo chatbot hội thoại bằng Amazon Lex có nhận dạng giọng nói tự động và hiểu ngôn ngữ tự nhiên, tích hợp với Connect; kết nối tới các ứng dụng nghiệp vụ bằng AWS Lambda.

Vì sao đúng

Đề nêu bốn yêu cầu, và bộ ba Connect + Lex + Lambda khớp từng cái: | Yêu cầu | Dịch vụ | |---|---| | Nhận cuộc gọi vào, dựng luồng liên hệ | Amazon Connect | | Người gọi tự đổi mật khẩu, xem số dư | Amazon Lex — chatbot hội thoại | | Nhận dạng giọng nói tự động (ASR) | Lex có ASR và NLU tích hợp | | Truy vấn ứng dụng nghiệp vụ và trả dữ liệu về | Lambda |

⚠ Lex là dịch vụ DUY NHẤT trong bốn phương án có cả ASR lẫn NLU:

Amazon Lex = ASR (giọng nói → văn bản)
           + NLU (hiểu ý định)
           + quản lý hội thoại
        ↓
    Đây chính là công nghệ đứng sau Alexa

Định nghĩa intent trong Lex:

{"intentName": "KiemTraSoDu",
 "sampleUtterances": [
   "Toi muon kiem tra so du",
   "So du tai khoan cua toi la bao nhieu",
   "Cho toi xem so du"],
 "slots": [{
   "name": "maTaiKhoan",
   "slotType": "AMAZON.Number",
   "valueElicitationPrompt": {
     "messages": [{"contentType": "PlainText",
       "content": "Vui long doc ma tai khoan cua ban"}]}}],
 "fulfillmentActivity": {
   "type": "CodeHook",
   "codeHook": {"uri": "<arn-lambda>", "messageVersion": "1.0"}}}

⚠ fulfillmentActivity với Lambda chính là vế "truy vấn ứng dụng nghiệp vụ":

Người gọi nói "kiểm tra số dư"
    → Lex nhận diện intent, thu thập slot
    → gọi Lambda
        ↓
    Lambda truy vấn hệ thống ngân hàng
    → trả kết quả cho Lex đọc lại cho người gọi

Tích hợp Lex vào luồng liên hệ của Connect:

Contact flow:
  Play prompt → "Xin chào, tôi có thể giúp gì?"
  Get customer input (Amazon Lex) → chọn bot
  Check intent → rẽ nhánh theo kết quả
  Invoke AWS Lambda → lấy dữ liệu
  Play prompt → đọc kết quả
  Transfer to queue → nếu cần người thật

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có tổng đài vật lý nào | | | Trả tiền theo phút gọi và theo request Lex | | | Mở rộng theo lưu lượng cuộc gọi | |

⚠ Connect tính phí theo phút — không có phí giấy phép agent cố định:

Tổng đài truyền thống: mua giấy phép cho từng agent
    → trả tiền dù agent có làm việc hay không
        ↓
Amazon Connect: theo phút sử dụng
    → phù hợp startup có lưu lượng biến động

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

**C. Amazon Connect + Amazon Comprehend làm chatbot — đây là phương án gần nhất và dùng đúng Amazon Connect, nhưng Comprehend là dịch vụ phân tích VĂN BẢN (cảm xúc, thực thể, chủ đề); nó không có ASR và không quản lý hội thoại.
**B. AWS Ground Station + Alexa for Business — Ground Station là dịch vụ điều khiển ăng-ten vệ tinh, hoàn toàn không liên quan tới tổng đài.
**D. Elemental MediaConnect + Amazon Polly — MediaConnect truyền video trực tiếp; và Polly làm ngược lại với yêu cầu: nó chuyển văn bản thành giọng nói, không phải giọng nói thành văn bản.

Ghi nhớ

⚠ Các dịch vụ AI về giọng nói và ngôn ngữ — bảng phải thuộc: | Dịch vụ | Đầu vào → Đầu ra | |---|---| | Lex | giọng/văn bản → HIỂU Ý ĐỊNH, hội thoại | | Transcribe | giọng nói → văn bản | | Polly | văn bản → giọng nói | | Comprehend | văn bản → cảm xúc, thực thể | | Translate | văn bản → ngôn ngữ khác |

⚠ Cách nhớ ngắn nhất:

Cần HỘI THOẠI hai chiều       → Lex
Chỉ cần CHUYỂN giọng thành chữ → Transcribe
Chỉ cần ĐỌC chữ thành giọng    → Polly
Phân tích Ý NGHĨA của văn bản  → Comprehend

Từ khoá nhận diện:

"call center, contact flows, inbound calls" → Amazon Connect "chatbot, ASR, NLU, self-service" → Amazon Lex "transcribe recorded calls" → Transcribe "analyze sentiment of transcripts" → Comprehend "text to speech" → Polly

Ba thành phần của một bot Lex: | Thành phần | Việc | |---|---| | Intent | ý định người dùng muốn làm | | Utterance | các cách nói khác nhau cho cùng ý định | | Slot | thông tin cần thu thập |

⚠ Số lượng utterance quyết định chất lượng bot:

Chỉ khai 2-3 cách nói
    → bot không nhận ra khi người dùng nói khác đi
        ↓
    Khai 15-20 cách nói tự nhiên cho mỗi intent
    → và bổ sung dần từ log thực tế

Ba loại Lambda hook trong Lex: | Hook | Khi nào chạy | |---|---| | Dialog code hook | sau mỗi lượt — kiểm tra và điều hướng | | Fulfillment code hook | khi đã đủ slot — thực hiện việc | | Initialization | đầu phiên |

Ba lưu ý về Amazon Connect: | Lưu ý | Chi tiết | |---|---| | Contact flow là công cụ kéo thả | | | Ghi âm cuộc gọi lưu vào S3 | | | Contact Lens phân tích cuộc gọi tự động | |

⚠ Contact Lens đáng biết — nó gói sẵn nhiều thứ:

Contact Lens for Amazon Connect:
    → chuyển đổi giọng nói thành văn bản
    → phân tích cảm xúc theo từng đoạn
    → phát hiện từ khoá và ngắt lời
    → che PII tự động
        ↓
    Thay cho việc tự ghép Transcribe + Comprehend

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Che PII trong bản ghi và văn bản | | | Mã hoá ghi âm bằng KMS | | | Connect đạt chuẩn PCI-DSS | |

⚠ Với ngân hàng, che PII gần như bắt buộc:

Khách đọc số thẻ hoặc mật khẩu qua điện thoại
    → nằm nguyên trong file ghi âm và bản ghi
        ↓
    Bật che PII của Contact Lens
    → hoặc dùng DTMF cho dữ liệu nhạy cảm

Ba lưu ý về DTMF (bấm phím): | Lưu ý | Chi tiết | |---|---| | An toàn hơn đọc số nhạy cảm bằng giọng | | | Connect hỗ trợ thu thập DTMF mã hoá | | | Kết hợp với Lex cho phần còn lại | |

Ba lưu ý về chuyển tiếp cho agent: | Lưu ý | Chi tiết | |---|---| | Bot xử lý được thì không cần agent | | | Không xử lý được thì chuyển hàng chờ | | | Truyền ngữ cảnh hội thoại cho agent | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Connect theo phút gọi + phí số điện thoại | | | Lex theo request giọng nói và văn bản | | | Lambda theo lời gọi | |

Ba lưu ý về đa ngôn ngữ: | Lưu ý | Chi tiết | |---|---| | Lex hỗ trợ nhiều ngôn ngữ, chưa có tiếng Việt đầy đủ | | | Mỗi ngôn ngữ là một locale riêng của bot | | | Kiểm tra danh sách hỗ trợ trước khi thiết kế | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi thử và đi hết luồng tự phục vụ | | | Xem tỷ lệ nhận diện intent đúng | | | Kiểm tra Lambda trả dữ liệu chính xác | |

Và một lời khuyên: hãy thu thập utterance thật từ log rồi bổ sung vào bot mỗi tháng. Bot Lex chỉ nhận ra những cách nói mà bạn đã dạy nó, và khoảng cách giữa cách bạn nghĩ khách hàng sẽ nói với cách họ thật sự nói là nguyên nhân số một khiến hệ thống tự phục vụ bị bỏ qua.

Câu 8 Domain - Design for New Solutions

A leading media company has a hybrid architecture where its on-premises data center is connected to AWS via a Direct Connect connection. They also have a repository of over 50-TB digital videos and media files. These files are stored on their on-premises tape library and are used by their Media Asset Management (MAM) system. Due to the sheer size of their data, they want to implement an automated catalog system that will enable them to search their files using facial recognition. A catalog will store the faces of the people who are present in these videos including a still image of each person. Eventually, the media company would like to migrate these media files to AWS including the MAM video contents.

Which of the following options provides a solution which uses the LEAST amount of ongoing management overhead and will cause MINIMAL disruption to the existing system?

A
Integrate the file system of your local data center to AWS Storage Gateway by setting up a file gateway appliance on-premises. Utilize the MAM solution to extract the media files from the current data store and send them into the file gateway. Build a collection using Amazon Rekognition by populating a catalog of faces from the processed media files. Use an AWS Lambda function to invoke Amazon Rekognition Javascript SDK to have it fetch the media file from the S3 bucket which is backing the file gateway, retrieve the needed metadata, and finally, persist the information into the MAM solution.
B
Use Amazon Kinesis Video Streams to set up a video ingestion stream and with Amazon Rekognition, build a collection of faces. Stream the media files from the MAM solution into Kinesis Video Streams and configure the Amazon Rekognition to process the streamed files. Launch a stream consumer to retrieve the required metadata, and push the metadata into the MAM solution. Finally, configure the stream to store the files in an S3 bucket.
C
Request for an AWS Snowball Storage Optimized device to migrate all of the media files from the on-premises library into Amazon S3. Provision a large EC2 instance and allow it to access the S3 bucket. Install an open-source facial recognition tool on the instance like OpenFace or OpenCV. Process the media files to retrieve the metadata and push this information into the MAM solution. Lastly, copy the media files to another S3 bucket.
D
Set up a tape gateway appliance on-premises and connect it to your AWS Storage Gateway. Configure the MAM solution to fetch the media files from the current archive and push them into the tape gateway to be stored in Amazon Glacier. Using Amazon Rekognition, build a collection from the catalog of faces. Utilize a Lambda function which invokes the Rekognition Javascript SDK to have Amazon Rekognition process the video directly from the tape gateway in real-time, retrieve the required metadata, and push the metadata into the MAM solution.

Xem giải thích

Đáp án

A — Tích hợp hệ thống tệp tại chỗ với AWS Storage Gateway bằng file gateway; dùng MAM đẩy tệp media vào file gateway; dựng collection của Amazon Rekognition từ các tệp đã xử lý; dùng Lambda gọi Rekognition lấy tệp từ bucket S3 phía sau gateway, trích siêu dữ liệu rồi ghi ngược vào MAM.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | GIÁN ĐOẠN TỐI THIỂU cho hệ thống hiện có | MAM vẫn ghi vào một share tệp như trước | | CÔNG VẬN HÀNH ÍT NHẤT | Rekognition là dịch vụ được quản lý | | Cuối cùng sẽ chuyển hẳn media lên AWS | tệp đã nằm sẵn trong S3 |

⚠ File Gateway giữ nguyên giao diện mà MAM đang dùng:

MAM biết đọc ghi qua NFS/SMB
    → file gateway phơi ra đúng giao thức đó
        ↓
    MAM không cần sửa dòng mã nào
    → nhưng tệp thật đã nằm trong S3

⚠ Và đây là bước đệm tự nhiên cho việc di chuyển sau này:

Tệp ghi qua file gateway trở thành OBJECT S3 THẬT
    → không phải định dạng độc quyền nào
        ↓
    Ngày chuyển hẳn lên AWS: dữ liệu đã ở đó rồi
    → chỉ cần chuyển MAM

Dựng file gateway:

aws storagegateway create-nfs-file-share \
  --client-token $(uuidgen) \
  --gateway-arn <arn-gateway> \
  --location-arn arn:aws:s3:::kho-media \
  --role <arn-role> \
  --default-storage-class S3_STANDARD \
  --client-list 10.0.0.0/16

Tạo collection khuôn mặt:

aws rekognition create-collection --collection-id bo-suu-tap-khuon-mat

aws rekognition index-faces \
  --collection-id bo-suu-tap-khuon-mat \
  --image '{"S3Object":{"Bucket":"kho-media","Name":"anh/dien-vien-a.jpg"}}' \
  --external-image-id dien-vien-a \
  --detection-attributes ALL

Tìm khuôn mặt trong video:

aws rekognition start-face-search \
  --video '{"S3Object":{"Bucket":"kho-media","Name":"video/tap-01.mp4"}}' \
  --collection-id bo-suu-tap-khuon-mat \
  --face-match-threshold 90 \
  --notification-channel 'SNSTopicArn=<arn-sns>,RoleArn=<arn-role>'

⚠ Phân tích video của Rekognition là BẤT ĐỒNG BỘ:

`start-face-search` trả về JobId ngay
    → xử lý xong thì bắn thông báo lên SNS
        ↓
    Lambda nghe SNS, gọi `get-face-search`
    → lấy kết quả rồi ghi vào MAM

import boto3
rek = boto3.client('rekognition')

def handler(su_kien, ngu_canh):
    thong_bao = json.loads(su_kien['Records'][0]['Sns']['Message'])
    ket_qua = rek.get_face_search(JobId=thong_bao['JobId'])
    for khop in ket_qua['Persons']:
        ghi_vao_mam(khop)

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cài phần mềm nhận dạng nào | | | Không quản lý máy chủ GPU | | | Dữ liệu đã sẵn sàng cho lần chuyển sau | |

⚠ 50 TB là khối lượng lớn — cân nhắc chuyển nền bằng Snowball trước:

File gateway đẩy dần qua mạng
    → 50 TB có thể mất rất lâu tuỳ băng thông
        ↓
    Dùng Snowball chuyển khối lượng lịch sử
    → file gateway lo tệp mới từ đó trở đi

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

**D. Dùng tape gateway đẩy media vào Glacier, rồi Rekognition xử lý video trực tiếp từ tape gateway theo thời gian thực — đây là phương án gần nhất và cũng dùng Storage Gateway, nhưng sai hai chỗ: tape gateway tạo ra băng ảo trong Glacier, Rekognition không đọc được định dạng đó; và Glacier cần hàng giờ để lấy dữ liệu nên "thời gian thực" là bất khả thi.
**B. Dùng Kinesis Video Streams — dịch vụ này dành cho luồng video TRỰC TIẾP từ camera; media ở đây là tệp lưu trữ trong thư viện băng từ, không phải luồng.
**C. Dùng Snowball chuyển hết lên S3 rồi tự cài OpenFace/OpenCV trên EC2 — công vận hành cao nhất: tự cài, tự vá, tự huấn luyện, tự mở rộng công cụ nhận dạng; ngược thẳng với "LEAST amount of ongoing management overhead".

Ghi nhớ

⚠ Bốn loại Storage Gateway — bảng phải thuộc: | Loại | Giao thức | Đích | Dùng cho | |---|---|---|---| | File Gateway (S3) | NFS, SMB | object S3 THẬT | tệp cần xử lý tiếp bằng dịch vụ AWS | | File Gateway (FSx) | SMB | FSx for Windows | share Windows | | Volume Gateway | iSCSI | snapshot EBS | volume khối | | Tape Gateway | iSCSI VTL | băng ảo trong Glacier | thay thư viện băng từ |

⚠ Khác biệt cốt lõi giữa File Gateway và Tape Gateway:

File Gateway: tệp → OBJECT S3 đọc được bằng API
    → dịch vụ khác dùng được ngay
        ↓
Tape Gateway: tệp → BĂNG ẢO trong Glacier
    → chỉ phần mềm sao lưu đọc được
    → Rekognition, Athena, Lambda đều KHÔNG đọc được

Từ khoá nhận diện:

"files must be processed by AWS services" → File Gateway "replace physical tape library" → Tape Gateway "live video stream from cameras" → Kinesis Video Streams "face recognition, object detection" → Rekognition

Ba năng lực của Rekognition: | Năng lực | Chi tiết | |---|---| | Nhận diện khuôn mặt (collection) | so với bộ sưu tập đã lập chỉ mục | | Phát hiện nhãn | vật thể, cảnh, hoạt động | | Kiểm duyệt nội dung | phát hiện nội dung không phù hợp | | Nhận dạng người nổi tiếng | có sẵn, không cần lập chỉ mục |

⚠ Collection lưu VECTOR đặc trưng, không lưu ảnh:

`index-faces` trích đặc trưng khuôn mặt
    → lưu vector vào collection
    → KHÔNG lưu ảnh gốc
        ↓
    Ảnh gốc bạn tự lưu ở S3
    → đề nói "một ảnh tĩnh của mỗi người" chính là việc đó

Ba lưu ý về ngưỡng khớp: | Lưu ý | Chi tiết | |---|---| | FaceMatchThreshold mặc định 80% | | | Cao hơn = ít dương tính giả, nhiều bỏ sót | | | Với thư viện lớn nên đặt 90% trở lên | |

Ba lưu ý về xử lý video: | Lưu ý | Chi tiết | |---|---| | API bất đồng bộ, thông báo qua SNS | | | Video tối đa 10 GB, 6 giờ | | | Trả về mốc thời gian của mỗi lần khớp | |

⚠ Mốc thời gian là thứ MAM cần nhất:

Kết quả trả về: người X xuất hiện ở giây 145, 302, 890
    → ghi vào MAM
        ↓
    Người dùng tìm "cảnh có diễn viên A"
    → nhảy thẳng tới đúng đoạn

Ba lưu ý về chi phí Rekognition: | Khoản | Giá tham khảo | |---|---| | Phân tích video | ~0,10 USD mỗi phút | | Lưu vector khuôn mặt | ~0,01 USD mỗi 1000 mỗi tháng | | Phân tích ảnh | ~0,001 USD mỗi ảnh |

⚠ 50 TB video là khoản chi phí đáng tính trước:

Giả sử 50 TB ≈ 10.000 giờ video
    → 600.000 phút × 0,10 USD = 60.000 USD
        ↓
    Cân nhắc xử lý dần, hoặc chỉ xử lý
      phần thư viện thật sự cần tìm kiếm

Ba lưu ý về quyền riêng tư: | Lưu ý | Chi tiết | |---|---| | Dữ liệu sinh trắc học chịu quy định nghiêm ngặt | | | Một số nơi cấm nhận dạng khuôn mặt | | | Ghi tài liệu mục đích và thời hạn lưu | |

Ba lưu ý về file gateway: | Lưu ý | Chi tiết | |---|---| | Cache cục bộ cho tệp nóng | | | Theo dõi CachePercentDirty | | | RefreshCache khi có ghi trực tiếp vào S3 | |

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Media cũ chuyển sang Glacier Deep Archive | | | Giữ bản proxy độ phân giải thấp ở Standard | | | Bản gốc chỉ lấy khi thật sự cần | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi tệp qua gateway, xem object trong S3 | | | Chạy face search trên một video mẫu | | | Kiểm tra siêu dữ liệu về tới MAM | |

aws rekognition describe-collection \
  --collection-id bo-suu-tap-khuon-mat

Và một lời khuyên: hãy ước tính chi phí Rekognition cho toàn bộ thư viện trước khi bắt đầu. Phân tích video tính theo phút, và một kho 50 TB có thể tương đương hàng chục nghìn giờ — con số đó thường lớn hơn nhiều so với dự đoán ban đầu và có thể đổi hẳn phạm vi của dự án.

Câu 9 Domain - Design for New Solutions

A company develops new android and iOS mobile apps. The company is considering storing user customization data in AWS. This would provide a more uniform cross-platform experience to their users using multiple mobile devices to access their apps. The preference data for each user is estimated to be 4 KB in size. Additionally, 3 million customers are expected to use the application on a regular basis, using their social login accounts for easier user authentication.

How should the Solutions Architect design a highly available, cost-effective, scalable, and secure solution to meet the above requirements?

A
Launch an RDS MySQL instance in 2 availability zones to contain the user preference data. Deploy a public-facing application on a server in front of the database which will manage authentication and access controls.
B
Provision a table in DynamoDB containing an item for each user having the necessary attributes to hold the user preferences. The mobile app will query the user preferences directly from the table. Use STS, Web Identity Federation, and DynamoDB's Fine-Grained Access Control for authentication and authorization.
C
Have the user preference data stored in S3, and set up a DynamoDB table with an item for each user and an item attribute referencing the user's S3 object. The mobile app will retrieve the S3 URL from DynamoDB and then access the S3 object directly utilizing STS, Web identity Federation, and S3 Access Points.
D
Create an RDS MySQL instance with multiple read replicas in 2 availability zones to store the user preference data. The mobile application will then query the user preferences from the read replicas. Finally, utilize MySQL's user management and access privilege system to handle the security and access credentials of the users.

Xem giải thích

Đáp án

B — Tạo bảng DynamoDB chứa một item cho mỗi người dùng với các thuộc tính giữ tuỳ chỉnh; ứng dụng di động truy vấn thẳng vào bảng; dùng STS, Web Identity Federation và Fine-Grained Access Control của DynamoDB cho xác thực và phân quyền.

Vì sao đúng

Đề nêu năm yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | 3 triệu người dùng, dữ liệu 4 KB mỗi người | DynamoDB — mở rộng ngang | | Đăng nhập bằng tài khoản mạng xã hội | Web Identity Federation | | Sẵn sàng cao | DynamoDB nhân bản qua 3 AZ | | Tiết kiệm chi phí | không có máy chủ trung gian nào | | An toàn | Fine-Grained Access Control |

⚠ Fine-Grained Access Control là chi tiết cốt lõi:

Client truy vấn TRỰC TIẾP DynamoDB
    → nhưng chỉ đọc được item CỦA CHÍNH MÌNH
        ↓
    Không cần tầng máy chủ trung gian
    để kiểm tra quyền

Policy giới hạn theo danh tính người dùng:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Action": ["dynamodb:GetItem", "dynamodb:PutItem",
              "dynamodb:UpdateItem", "dynamodb:Query"],
   "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/TuyChinhNguoiDung",
   "Condition": {
     "ForAllValues:StringEquals": {
       "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]}}}]}

⚠ dynamodb:LeadingKeys là điều kiện làm nên toàn bộ giải pháp:

Nó ép partition key phải BẰNG danh tính của người gọi
    → người dùng A không đọc được item của B
        ↓
    Kiểm soát ở tầng IAM, không phải tầng ứng dụng
    → không có mã nào để viết sai

Luồng xác thực đầy đủ:

1. Người dùng đăng nhập bằng Google/Facebook
    → nhận OIDC token
        ↓
2. Đổi token đó lấy credential AWS tạm
    (Cognito Identity Pool gọi STS AssumeRoleWithWebIdentity)
        ↓
3. Client dùng credential đó gọi thẳng DynamoDB
    → policy giới hạn chỉ item của mình

Dựng Identity Pool:

aws cognito-identity create-identity-pool \
  --identity-pool-name kho-danh-tinh-ung-dung \
  --no-allow-unauthenticated-identities \
  --supported-login-providers accounts.google.com=<client-id>

⚠ Vì sao bỏ được tầng máy chủ là điểm tiết kiệm lớn nhất:

Kiến trúc truyền thống: client → API server → CSDL
    → phải chạy và mở rộng tầng API
        ↓
    Ở đây: client → DynamoDB
    → không có gì để mở rộng, không có gì để trả tiền lúc rảnh

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có tầng máy chủ nào | | | Credential tạm, tự hết hạn | | | Đồng bộ giữa mọi thiết bị của người dùng | |

⚠ Item 4 KB khớp đúng đơn vị của DynamoDB:

1 RCU = đọc 4 KB (eventually consistent: 8 KB)
1 WCU = ghi 1 KB
        ↓
    Đọc một item 4 KB = 0,5 RCU (eventual)
    Ghi một item 4 KB = 4 WCU

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

**C. Lưu dữ liệu ở S3, dùng DynamoDB làm bảng tham chiếu tới object S3 — đây là phương án gần nhất và cũng dùng Web Identity Federation, nhưng nó thêm một tầng gián tiếp vô ích: dữ liệu chỉ 4 KB, hoàn toàn vừa trong một item DynamoDB. Hai lần gọi mạng thay vì một, và phức tạp hơn mà không được gì.
**A. RDS MySQL ở hai AZ với một máy chủ ứng dụng công khai phía trước — phải vận hành cả CSDL lẫn tầng ứng dụng, mở rộng dọc có trần, và tự viết logic xác thực.
**D. RDS MySQL với read replica và dùng hệ thống người dùng của MySQL để phân quyền — tạo tài khoản MySQL cho 3 triệu người dùng là bất khả thi; và client di động kết nối thẳng vào CSDL quan hệ là mô hình bảo mật rất tệ.

Ghi nhớ

⚠ Cognito User Pools vs Identity Pools — bảng phải thuộc: | | User Pools | Identity Pools | |---|---|---| | Việc | XÁC THỰC (ai đây?) | PHÂN QUYỀN (được làm gì?) | | Trả về | JWT token | credential AWS tạm | | Có thư mục người dùng | ✅ | ❌ | | Dùng cho | đăng ký, đăng nhập | truy cập tài nguyên AWS trực tiếp |

⚠ Đề này chỉ cần Identity Pool:

Người dùng đăng nhập bằng MẠNG XÃ HỘI
    → không cần thư mục người dùng riêng
        ↓
    Identity Pool đổi token mạng xã hội
      lấy credential AWS

Từ khoá nhận diện:

"mobile app accesses AWS resources directly with social login" → Identity Pool + Web Identity Federation "sign-up, sign-in, MFA, user directory" → User Pools "row-level access control in DynamoDB" → dynamodb:LeadingKeys "temporary credentials" → STS

Ba khoá điều kiện phân quyền chi tiết của DynamoDB: | Khoá | Giới hạn | |---|---| | dynamodb:LeadingKeys | partition key phải khớp | | dynamodb:Attributes | chỉ đọc/ghi một số thuộc tính | | dynamodb:Select | ép SPECIFIC_ATTRIBUTES |

⚠ Kết hợp cả ba cho kiểm soát chặt nhất:

{"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"],
    "dynamodb:Attributes": ["maNguoiDung","giaoDien","ngonNgu"]},
  "StringEqualsIfExists": {
    "dynamodb:Select": "SPECIFIC_ATTRIBUTES"}}}

Ba lưu ý về STS: | Lưu ý | Chi tiết | |---|---| | AssumeRoleWithWebIdentity cho token mạng xã hội | | | Credential mặc định 1 giờ | | | Client tự làm mới trước khi hết hạn | |

Ba nhà cung cấp danh tính hỗ trợ: | Nhà cung cấp | Chi tiết | |---|---| | Google, Facebook, Apple, Amazon | có sẵn | | OIDC bất kỳ | tự khai | | SAML | doanh nghiệp |

Ba lưu ý về vai trò IAM: | Lưu ý | Chi tiết | |---|---| | Vai trò cho người đã xác thực và chưa xác thực | | | Trust policy giới hạn theo identity pool | | | Áp dụng quyền tối thiểu | |

⚠ Trust policy phải giới hạn đúng pool:

{"Effect": "Allow",
 "Principal": {"Federated": "cognito-identity.amazonaws.com"},
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
   "StringEquals": {
     "cognito-identity.amazonaws.com:aud": "<id-identity-pool>"},
   "ForAnyValue:StringLike": {
     "cognito-identity.amazonaws.com:amr": "authenticated"}}}

Thiếu điều kiện `aud`
    → identity pool KHÁC cũng đảm nhận được vai trò này

Ba lưu ý về chế độ tính phí: | Chế độ | Khi nào | |---|---| | On-demand | tải thất thường của ứng dụng di động | | Provisioned | tải ổn định đoán trước được | | Reserved Capacity | giảm tới 77% với Provisioned |

Ba lưu ý về thiết kế bảng: | Lưu ý | Chi tiết | |---|---| | Partition key = danh tính người dùng | | | Một item mỗi người là đủ nếu dữ liệu nhỏ | | | Sort key nếu cần nhiều bản ghi mỗi người | |

Ba lưu ý về đồng bộ nhiều thiết bị: | Lưu ý | Chi tiết | |---|---| | Cùng danh tính → cùng item | | | Đọc mới nhất bằng strongly consistent read | | | Cân nhắc AWS AppSync nếu cần real-time | |

⚠ AppSync là lựa chọn đáng cân nhắc:

AppSync có subscription qua WebSocket
    → thay đổi ở một thiết bị đẩy ngay sang thiết bị khác
        ↓
    Nhưng thêm một dịch vụ; DynamoDB trực tiếp
      đơn giản hơn nếu không cần thời gian thực

Ba lưu ý về bảo mật ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | Không nhúng credential AWS vào ứng dụng | | | Credential tạm là cách duy nhất đúng | | | Bật certificate pinning nếu cần chặt hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử đọc item của người dùng khác | phải bị từ chối | | Kiểm tra credential hết hạn đúng | | | Theo dõi ThrottledRequests | |

Và một lời khuyên: hãy kiểm chứng dynamodb:LeadingKeys bằng cách cố tình đọc item của người khác. Toàn bộ mô hình bảo mật của kiến trúc này nằm trong một dòng điều kiện IAM, và cách duy nhất để biết nó viết đúng là thử phá nó.

Câu 10 Domain - Design for New Solutions

A company needs a deployment solution for its application that is hosted on the AWS cloud. The company has the following requirements for the application:

- The instances must have 500GB worth of static dataset that is accessible for the application upon boot up.

- The instances must be able to scale-out or scale-in depending on the traffic load of the application.

- The Development team must have a quick and automated way to deploy their code updates several times during the day.

- Security patches for the vulnerabilities on the operating system (OS) must be installed within 48 hours of release.

Which of the following solutions should the Solutions Architect implement to meet the company requirements while being cost-effective?

A
Create an Auto Scaling group of EC2 instances using the Amazon Linux AMI. Install the application on the EC2 instances. Replace the existing instances as soon as AWS releases a new Amazon Linux AMI version. Write a user data script that will download the 500 GB static dataset from an Amazon S3 bucket. Deploy the new version of the application to the instances using AWS CodeDeploy.
B
Install OS patches and create a new AMI using AWS Systems Manager. Use this new AMI for the Auto Scaling group of EC2 instances and replace the existing instances. Create a scheduled batch job that will run every night to deploy the new application version and install the OS patches. Mount an Amazon EFS volume containing the static dataset on the instances upon boot up.
C
Install OS patches and create a new AMI using AWS Systems Manager. Use this new AMI for the Auto Scaling group of EC2 instances and replace the existing instances. Deploy the new version of the application to the instances using AWS CodeDeploy. Mount an Amazon EFS volume containing the static dataset on the instances upon boot up.
D
Create an Auto Scaling group of EC2 instances using the Amazon Linux AMI. Install the application on the EC2 instances. Write a user data script that will download the 500 GB static dataset from an Amazon S3 bucket. Use AWS Systems Manager to install the OS patches as soon as they are released. Deploy the new version of the application to the instances using AWS CodeDeploy.

Xem giải thích

Đáp án

C — Cài bản vá và tạo AMI mới bằng AWS Systems Manager, dùng AMI đó cho Auto Scaling group và thay các máy hiện có; triển khai phiên bản ứng dụng mới bằng AWS CodeDeploy; mount EFS chứa tập dữ liệu tĩnh khi máy khởi động.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này giải quyết từng cái bằng công cụ đúng: | Yêu cầu | Giải pháp | |---|---| | 500 GB dữ liệu tĩnh sẵn sàng khi máy khởi động | EFS mount lúc boot | | Co giãn theo tải | Auto Scaling group | | Triển khai mã nhiều lần mỗi ngày, tự động | CodeDeploy | | Vá lỗ hổng OS trong 48 giờ | SSM tạo AMI đã vá, thay máy |

⚠ EFS thắng vì 500 GB tải từ S3 mỗi lần khởi động là bất khả thi:

Tải 500 GB từ S3 trong user data
    → ngay cả ở 1 Gbps cũng mất ~70 phút
        ↓
    Auto Scaling thêm máy khi tải tăng
    → máy đó mất hơn một giờ mới phục vụ được
    → vô dụng
        ↓
    EFS: mount trong vài giây, đọc theo nhu cầu

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

Mount EFS trong user data:

#!/bin/bash
yum install -y amazon-efs-utils
mkdir -p /du-lieu-tinh
echo "fs-abc:/ /du-lieu-tinh efs _netdev,tls,iam 0 0" >> /etc/fstab
mount -a

⚠ Và 500 GB chỉ tồn tại MỘT bản, dùng chung cho mọi máy:

Tải từ S3: mỗi máy một bản 500 GB trên EBS
    → 20 máy = 10 TB dung lượng EBS
        ↓
    EFS: một bản duy nhất, mọi máy đọc chung
    → rẻ hơn nhiều lần

Tạo AMI đã vá bằng Systems Manager Automation:

aws ssm start-automation-execution \
  --document-name "AWS-UpdateLinuxAmi" \
  --parameters '{
    "SourceAmiId":["ami-goc"],
    "IamInstanceProfileName":["VaiTroSSM"],
    "AutomationAssumeRole":["<arn-role>"],
    "TargetAmiName":["ung-dung-da-va-{{global:DATE_TIME}}"]}'

⚠ Đây là mô hình HẠ TẦNG BẤT BIẾN:

Vá tại chỗ trên máy đang chạy:
    → mỗi máy dần khác nhau — "sai lệch cấu hình"
    → không biết máy nào đã vá, máy nào chưa
        ↓
Tạo AMI mới rồi thay máy:
    → mọi máy giống hệt nhau
    → quay lui = dùng lại AMI cũ

Triển khai mã bằng CodeDeploy:

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/ung-dung
hooks:
  BeforeInstall:
    - location: scripts/dung-dich-vu.sh
  AfterInstall:
    - location: scripts/cai-dat.sh
  ApplicationStart:
    - location: scripts/khoi-dong.sh
  ValidateService:
    - location: scripts/kiem-tra.sh

⚠ Vì sao CodeDeploy hợp với "nhiều lần mỗi ngày":

Tạo AMI mới cho mỗi lần đổi mã
    → mất 10-20 phút mỗi lần
    → không làm được nhiều lần mỗi ngày
        ↓
    CodeDeploy đẩy mã lên máy đang chạy
    → vài phút, có rolling và rollback

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tách hai chu kỳ: vá OS (chậm) và triển khai mã (nhanh) | | | Dữ liệu tĩnh dùng chung, không nhân bản | | | Máy mới sẵn sàng trong vài chục giây | |

⚠ Đây là ý thiết kế quan trọng nhất của câu này:

Vá OS: chu kỳ tuần, qua AMI mới
Triển khai mã: chu kỳ giờ, qua CodeDeploy
Dữ liệu tĩnh: không đổi, qua EFS
        ↓
    Ba thứ đổi với ba nhịp khác nhau
    → dùng ba cơ chế khác nhau

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

**B. SSM tạo AMI đã vá, EFS cho dữ liệu, nhưng dùng cron job mỗi đêm để triển khai mã — đây là phương án gần nhất và đúng ở hai vế đầu, nhưng đề nói đội phát triển cần triển khai "nhiều lần trong ngày"; một job chạy mỗi đêm không đáp ứng được.
**A. Thay AMI khi AWS phát hành bản mới và tải 500 GB từ S3 trong user data — hai lỗi: chờ AWS phát hành AMI mới không đảm bảo vá trong 48 giờ, và tải 500 GB mỗi lần khởi động phá hỏng khả năng co giãn.
**D. Dùng SSM cài bản vá lên máy đang chạy và tải 500 GB từ S3 — vá tại chỗ tạo sai lệch cấu hình, và vẫn mắc lỗi tải 500 GB.

Ghi nhớ

⚠ Ba cách vá hệ điều hành — bảng phải thuộc: | Cách | Chi tiết | |---|---| | Patch Manager vá tại chỗ | nhanh nhưng tạo sai lệch cấu hình | | Tạo AMI mới rồi thay máy | bất biến, quay lui được | | EC2 Image Builder | tự động hoá việc tạo AMI theo lịch |

⚠ EC2 Image Builder là công cụ chuyên cho việc này:

aws imagebuilder create-image-pipeline \
  --name duong-ong-anh \
  --image-recipe-arn <arn-recipe> \
  --infrastructure-configuration-arn <arn-ha-tang> \
  --schedule 'scheduleExpression=cron(0 2 ? * SUN *),
              pipelineExecutionStartCondition=EXPRESSION_MATCH_AND_DEPENDENCY_UPDATES_AVAILABLE'

`EXPRESSION_MATCH_AND_DEPENDENCY_UPDATES_AVAILABLE`
    → chỉ dựng AMI mới khi CÓ bản vá mới
    → không dựng thừa

Từ khoá nhận diện:

"large static dataset available at boot" → EFS "deploy code multiple times a day" → CodeDeploy "patch OS within N hours" → AMI mới + thay máy "automate AMI creation" → EC2 Image Builder

Ba chiến lược triển khai của CodeDeploy: | Chiến lược | Chi tiết | |---|---| | AllAtOnce | nhanh nhất, rủi ro nhất | | HalfAtATime | | | OneAtATime | an toàn nhất, chậm nhất | | Blue/Green | đội máy mới hoàn toàn |

⚠ Blue/Green với ASG cho quay lui tức thì:

CodeDeploy dựng ASG mới với mã mới
    → chuyển target group của ALB sang
        ↓
    Có vấn đề → chuyển ngược lại
    → quay lui trong vài giây

Ba lưu ý về EFS: | Lưu ý | Chi tiết | |---|---| | Mount target ở MỖI AZ | | | Elastic throughput là mặc định tốt | | | Lifecycle sang IA cho dữ liệu ít đọc | |

⚠ Với dữ liệu tĩnh chỉ đọc, cân nhắc bật read caching:

Dữ liệu tĩnh 500 GB, đọc nhiều, không ghi
    → EFS đọc qua mạng mỗi lần
        ↓
    Cân nhắc FSx for Lustre nếu cần thông lượng rất cao
    → hoặc cache cục bộ phần nóng nhất

Ba lưu ý về Patch Manager: | Lưu ý | Chi tiết | |---|---| | Patch baseline định nghĩa bản vá được duyệt | | | ApproveAfterDays=0 cho vá nghiêm trọng | | | Patch group tag có DẤU CÁCH: Patch Group | |

Ba lưu ý về tuân thủ 48 giờ: | Việc | Cách | |---|---| | Quét hằng ngày để biết trạng thái | | | Báo cáo tuân thủ của SSM | | | Config rule kiểm tra | |

aws ssm list-compliance-summaries \
  --filters 'Key=ComplianceType,Values=Patch'

Ba lưu ý về Auto Scaling và thay máy: | Lưu ý | Chi tiết | |---|---| | Instance refresh thay máy dần dần | | | MinHealthyPercentage giữ tính sẵn sàng | | | Kết hợp launch template versioning | |

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name asg-ung-dung \
  --preferences 'MinHealthyPercentage=90,InstanceWarmup=300'

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | EFS đắt hơn EBS mỗi GB | | | Nhưng MỘT bản thay vì N bản | | | Lifecycle sang IA giảm ~92% | |

Ba lưu ý về CodeDeploy agent: | Lưu ý | Chi tiết | |---|---| | Phải cài trong AMI | | | Hoặc cài trong user data | | | Kiểm tra agent chạy trước khi triển khai | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian từ lúc ASG thêm máy tới lúc phục vụ | | | Kiểm tra EFS mount thành công | | | Xem báo cáo tuân thủ vá | |

Và một lời khuyên: hãy tách chu kỳ vá hệ điều hành khỏi chu kỳ triển khai mã. Gộp chúng lại buộc bạn phải dựng một AMI mới cho mỗi lần sửa một dòng mã — và đội phát triển muốn triển khai nhiều lần mỗi ngày sẽ nhanh chóng tìm cách đi vòng qua quy trình đó.