AWS Cloud Practitioner · Tiếng Việt
Chương 16 / 20

Quản lý tài khoản, Billing & Support

Cách quản lý nhiều tài khoản AWS trong một tổ chức, các mô hình giá và bộ công cụ theo dõi/tối ưu chi phí, cùng các gói AWS Support phù hợp với từng quy mô doanh nghiệp.

Nội dung chương

  1. AWS Organizations – quản lý nhiều tài khoản
  2. Chiến lược multi-account & Organizational Units (OU)
  3. Service Control Policies (SCP)
  4. Consolidated Billing (hóa đơn hợp nhất)
  5. AWS Control Tower
  6. AWS Resource Access Manager (RAM)
  7. AWS Service Catalog
  8. Các mô hình giá của AWS & Free Tier
  9. Chi phí Compute: EC2, Lambda, ECS/Fargate
  10. Chi phí Storage: S3 và EBS
  11. Chi phí Database (RDS), CloudFront và Network
  12. Savings Plans & AWS Compute Optimizer
  13. Bộ công cụ theo dõi & quản lý chi phí
  14. AWS Trusted Advisor
  15. Các gói AWS Support Plans
  16. Tổng hợp Best Practices quản lý tài khoản

1. AWS Organizations – quản lý nhiều tài khoản

Khi một công ty chỉ mới bắt đầu dùng AWS, một tài khoản duy nhất là đủ. Nhưng khi công ty lớn lên, có nhiều team, nhiều dự án, nhiều môi trường (dev/test/prod), việc dồn tất cả vào một tài khoản sẽ gây rủi ro: một lỗi cấu hình ở môi trường test có thể ảnh hưởng tới production, hay một nhân viên bị lộ quyền truy cập có thể động tới toàn bộ hệ thống công ty. Giải pháp là tách ra nhiều tài khoản AWS riêng biệt — và AWS Organizations là dịch vụ toàn cầu (global service) giúp quản lý tập trung nhiều tài khoản đó như một tổ chức thống nhất.

Trong AWS Organizations, tài khoản đầu tiên tạo ra tổ chức được gọi là management account (trước đây gọi là master account) — tài khoản "gốc" có quyền quản lý toàn bộ các tài khoản thành viên khác. Lợi ích chính khi dùng Organizations xoay quanh chi phí:

Ngoài lợi ích về chi phí, Organizations còn cung cấp API để tự động hóa việc tạo tài khoản AWS mới (thay vì phải tạo tay từng cái), và cho phép giới hạn quyền của các tài khoản thành viên bằng Service Control Policies (SCP) — sẽ nói chi tiết ở mục 3.

Lưu ý khi thi: AWS Organizations là dịch vụ MIỄN PHÍ — bạn không tốn thêm phí khi dùng Organizations, lợi ích đến từ việc tối ưu chi phí các dịch vụ khác nhờ gộp usage.

2. Chiến lược multi-account & Organizational Units (OU)

Câu hỏi thường gặp: "Nên tách tài khoản theo tiêu chí gì?" Một số chiến lược phổ biến khi thiết kế multi-account:

Một câu hỏi kiến trúc quan trọng là: nên dùng nhiều tài khoản (Multi Account) hay một tài khoản với nhiều VPC (One Account Multi VPC)? Xu hướng hiện tại của AWS là khuyến khích multi-account vì cách ly triệt để hơn về mặt bảo mật, billing, và giới hạn dịch vụ — dù vận hành phức tạp hơn một chút.

Để việc quản lý nhiều tài khoản không trở nên hỗn loạn, cần áp dụng một số nguyên tắc vận hành:

Organizational Units (OU)

Khi số lượng tài khoản tăng lên, AWS Organizations cho phép nhóm các tài khoản lại thành các Organizational Units (OU) — giống như các thư mục con để tổ chức tài khoản theo cây phân cấp. Có thể tổ chức OU theo Business Unit (đơn vị kinh doanh), theo Environmental Lifecycle (dev/test/prod), hoặc theo dự án (project-based).

Một cấu trúc điển hình: Management Account nằm ở gốc (Root OU), và các OU con như Prod OU, Finance OU, Dev OU, HR OU — mỗi OU chứa các tài khoản thuộc đơn vị/mục đích tương ứng, và có thể áp SCP riêng cho từng OU.

Ví dụ thực tế: Một tập đoàn có Root OU chứa 3 OU con: "Prod" (chỉ chứa tài khoản sản xuất, SCP chặt), "Dev" (SCP nới hơn để dev thoải mái thử nghiệm), và "Sandbox" (SCP giới hạn instance type để tránh phát sinh chi phí lớn khi thử nghiệm).

3. Service Control Policies (SCP)

Service Control Policies (SCP) là công cụ để giới hạn quyền của các tài khoản trong tổ chức — bạn có thể dùng SCP để whitelist (chỉ cho phép) hoặc blacklist (cấm) các hành động IAM cụ thể. SCP được áp dụng ở cấp độ OU hoặc cấp độ Account.

Một vài quy tắc quan trọng cần nhớ về SCP:

Một số trường hợp sử dụng SCP tiêu biểu: hạn chế truy cập tới một số dịch vụ nhất định (ví dụ cấm hoàn toàn việc dùng EMR trong một OU), hoặc thực thi tuân thủ PCI bằng cách chủ động vô hiệu hóa (explicitly disable) các dịch vụ không được phép dùng khi xử lý dữ liệu thẻ thanh toán.

Lưu ý khi thi: Câu hỏi kinh điển: "SCP có áp dụng cho Root user của tài khoản thành viên không?" — CÓ. Nhưng "SCP có áp dụng cho Management Account không?" — KHÔNG. Đây là hai câu dễ bị đánh lừa vì nghe tương tự nhau.

4. Consolidated Billing (hóa đơn hợp nhất)

Consolidated Billing là một tính năng đi kèm khi bật AWS Organizations, mang lại hai lợi ích chính:

Một điểm cần chú ý: management account có thể tắt việc chia sẻ chiết khấu RI (RI discount sharing) cho bất kỳ tài khoản nào, kể cả cho chính management account — nghĩa là bạn có thể kiểm soát account nào được hưởng lợi từ RI đã mua ở nơi khác, tránh trường hợp một team "dùng ké" chiết khấu của team khác nếu không mong muốn.

Ví dụ thực tế: Team A mua Reserved Instance cho instance loại m5.large ở account của họ, nhưng account đó lại ít dùng hết công suất reserved. Nhờ Consolidated Billing, phần công suất RI dư thừa có thể được Team B (dùng cùng loại instance ở account khác trong tổ chức) tận dụng, giúp cả tổ chức tiết kiệm tối đa mà không cần Team B tự mua RI riêng.

5. AWS Control Tower

Thiết lập một môi trường multi-account đúng chuẩn (chuẩn về bảo mật, về tuân thủ) từ đầu là việc không dễ — cần cấu hình Organizations, tạo OU hợp lý, viết SCP đúng, thiết lập logging trung tâm... AWS Control Tower ra đời để giải quyết bài toán này: đây là cách dễ dàng để thiết lập và quản trị (govern) một môi trường AWS multi-account an toàn và tuân thủ, dựa trên các best practice đã được AWS đóng gói sẵn.

Các lợi ích chính của Control Tower:

Về mặt kỹ thuật, AWS Control Tower chạy TRÊN NỀN AWS Organizations — khi bạn dùng Control Tower, nó tự động thiết lập Organizations để tổ chức các tài khoản và triển khai SCP cho bạn. Có thể hiểu Control Tower như "lớp tự động hóa" phía trên Organizations, giúp bạn không phải tự tay cấu hình từng SCP, từng OU.

Lưu ý khi thi: Control Tower KHÔNG thay thế Organizations — nó được xây dựng trên nền Organizations, tự động hóa việc thiết lập theo best practice.

6. AWS Resource Access Manager (RAM)

Trong một tổ chức multi-account, đôi lúc bạn có một resource ở account A (ví dụ một VPC Subnet, hoặc một Transit Gateway) mà account B cũng cần dùng — thay vì tạo lại (duplicate) resource đó ở account B (tốn thêm chi phí, khó đồng bộ), bạn có thể CHIA SẺ resource trực tiếp bằng AWS Resource Access Manager (RAM).

AWS RAM cho phép chia sẻ các resource AWS mà bạn sở hữu với các tài khoản khác — có thể chia sẻ với bất kỳ tài khoản nào, hoặc chỉ trong nội bộ Organization của bạn. Mục tiêu chính: tránh trùng lặp resource (avoid resource duplication).

Các loại resource được hỗ trợ chia sẻ qua RAM bao gồm: Amazon Aurora, VPC Subnets, Transit Gateway, Route 53 (resolver rules), EC2 Dedicated Hosts, và License Manager Configurations.

Ví dụ thực tế: Team hạ tầng trung tâm tạo một VPC dùng chung với các Subnet đã cấu hình sẵn (đúng CIDR, đúng route table), rồi dùng RAM để chia sẻ các Subnet đó cho nhiều account ứng dụng khác nhau trong tổ chức — mỗi team chỉ cần triển khai EC2/Lambda vào Subnet được chia sẻ, không cần tự dựng VPC riêng.

7. AWS Service Catalog

Người dùng mới làm quen với AWS thường gặp một vấn đề: có QUÁ NHIỀU lựa chọn dịch vụ và cấu hình, dễ tự tạo ra các stack không tuân thủ chuẩn của tổ chức (sai security group, sai region, thiếu tag...). Nhiều người dùng thực ra chỉ muốn một cổng tự phục vụ (self-service portal) đơn giản, để chọn nhanh trong danh sách các sản phẩm đã được admin định nghĩa và cho phép trước — đó chính là mục đích của AWS Service Catalog.

Service Catalog cho phép danh mục hóa các loại tài nguyên phổ biến để người dùng tự triển khai, bao gồm: máy chủ ảo (virtual machines), cơ sở dữ liệu (databases), các tùy chọn lưu trữ (storage options)...

Cấu trúc hoạt động của Service Catalog:

  1. Admin định nghĩa một Portfolio (bộ sưu tập) gồm nhiều Product — mỗi Product thực chất là một CloudFormation Template đã được viết và kiểm duyệt sẵn.
  2. Admin cấp quyền truy cập Portfolio cho người dùng thông qua IAM Permissions.
  3. Người dùng (đã được IAM cho phép) chọn từ Product List và launch (khởi chạy) sản phẩm mong muốn.
  4. Kết quả là các Provisioned Products — tài nguyên đã sẵn sàng sử dụng, được cấu hình đúng chuẩn, và được gắn tag đúng quy định — mà người dùng không cần biết chi tiết kỹ thuật bên dưới.
Lưu ý khi thi: Service Catalog giải quyết vấn đề "governance" (kiểm soát) khi cho người dùng tự phục vụ — khác với Control Tower là thiết lập toàn bộ multi-account environment, và khác với RAM là chia sẻ resource đã tồn tại giữa các account.

8. Các mô hình giá của AWS & Free Tier

Một trong những lý do khiến cloud hấp dẫn là mô hình định giá linh hoạt. AWS có 4 mô hình giá chính:

Free Services & Free Plan

Khi tạo một tài khoản AWS mới, bạn nhận được tới $200 tín dụng (credits) miễn phí. Bạn có thể chọn giữa hai lựa chọn: Free Plan hoặc Paid Plan.

Cả hai Plan đều có quyền truy cập các dịch vụ Always Free — những dịch vụ hoặc mức sử dụng luôn miễn phí, không phụ thuộc vào việc credits còn hay hết. AWS cung cấp các hạn mức sử dụng miễn phí hàng tháng (monthly free usage limits), ví dụ:

Lưu ý khi thi: Hãy nhớ 4 mô hình giá theo tên tiếng Anh gốc vì đề thi thường trích dẫn nguyên câu: "Pay as you go", "Save when you reserve", "Pay less by using more", "Pay less as AWS grows".

9. Chi phí Compute: EC2, Lambda, ECS/Fargate

EC2

Với EC2, bạn chỉ bị tính phí cho những gì thực sự dùng. Các yếu tố ảnh hưởng tới chi phí EC2 gồm: số lượng instance đang chạy, cấu hình instance (dung lượng vật lý, region, hệ điều hành/phần mềm, loại instance, kích thước instance), thời gian chạy của Elastic Load Balancer (ELB) và lượng dữ liệu ELB xử lý, và việc có bật detailed monitoring hay không.

Các phương án mua EC2 ảnh hưởng lớn tới giá:

Lambda & ECS/Fargate

Với AWS Lambda, bạn trả tiền theo hai yếu tố: pay per call (trả theo số lượt gọi hàm) và pay per duration (trả theo thời gian hàm thực thi) — không có máy chủ nào chạy liên tục để bạn phải trả tiền lúc rảnh.

Với Amazon ECS, có hai mô hình launch khác nhau về chi phí:

Ví dụ thực tế: Một ứng dụng có traffic biến động mạnh theo giờ trong ngày. Nếu chạy trên EC2 On-Demand cố định để đáp ứng peak, bạn trả tiền cả những giờ ít traffic. Chuyển một phần workload sang Lambda hoặc Fargate giúp chi phí "co giãn" đúng theo mức sử dụng thực tế, tránh lãng phí.

10. Chi phí Storage: S3 và EBS

Amazon S3

Chi phí S3 phụ thuộc vào nhiều yếu tố: storage class đang dùng (S3 Standard, Infrequent Access, One-Zone IA, Intelligent-Tiering, Glacier, Glacier Deep Archive — mỗi class có mức giá lưu trữ và giá truy xuất khác nhau), số lượng và kích thước object (định giá theo bậc - tiered pricing dựa trên khối lượng), số lượng và loại request (GET, PUT...), lượng dữ liệu truyền RA khỏi region S3 (data transfer OUT), việc có dùng S3 Transfer Acceleration hay không, và các lần chuyển đổi lifecycle (lifecycle transitions, ví dụ tự động chuyển object từ Standard sang Glacier sau 90 ngày).

Một dịch vụ tương tự về mô hình tính phí là Amazon EFS: cũng trả tiền theo mức sử dụng (pay per use), và cũng có các mức truy cập không thường xuyên (infrequent access) cùng lifecycle rules riêng.

Amazon EBS

Với EBS, các yếu tố tính phí gồm: loại volume (dựa trên mức hiệu năng — General Purpose SSD, Provisioned IOPS SSD, Magnetic...), dung lượng volume tính theo GB mỗi tháng đã cấp phát (provisioned), IOPS (với General Purpose SSD, IOPS đã bao gồm trong giá; với Provisioned IOPS SSD, bạn trả riêng theo lượng IOPS đã đặt; với Magnetic, trả theo số lượng request), snapshot (chi phí lưu trữ dữ liệu snapshot tính theo GB mỗi tháng), và data transfer (dữ liệu đi ra ngoài — outbound — được định giá theo bậc để có chiết khấu khối lượng, còn dữ liệu đi vào — inbound — luôn miễn phí).

Lưu ý khi thi: Quy tắc chung xuyên suốt AWS: dữ liệu truyền VÀO (inbound) luôn miễn phí; dữ liệu truyền RA (outbound) mới bị tính phí và được chiết khấu theo khối lượng.

11. Chi phí Database (RDS), CloudFront và Network

Amazon RDS

RDS được tính phí theo giờ (per hour billing), phụ thuộc vào: đặc điểm cơ sở dữ liệu (engine, kích thước, hạng bộ nhớ), loại hình mua (on-demand, hoặc reserved instances 1/3 năm có thể trả trước một phần), dung lượng backup storage (không tính phí thêm cho tới 100% tổng dung lượng database trong một region), dung lượng lưu trữ bổ sung (tính theo GB mỗi tháng), số lượng I/O request mỗi tháng, loại triển khai (Single-AZ hay Multi-AZ — ảnh hưởng tới chi phí storage và I/O vì dữ liệu được nhân bản), và data transfer (outbound theo bậc, inbound miễn phí).

Amazon CloudFront

Giá của CloudFront khác nhau tùy khu vực địa lý, được tính gộp theo từng edge location rồi cộng vào hóa đơn tổng. Hai yếu tố chính: Data Transfer Out (có chiết khấu theo khối lượng) và số lượng request HTTP/HTTPS.

Chi phí Network trong AWS

Chi phí truyền dữ liệu (networking) trong AWS thường bị đánh giá thấp nhưng có thể tích lũy thành khoản lớn. Một bảng giá đơn giản hóa (mang tính minh họa) theo GB:

Loại lưu chuyển dữ liệuChi phí ước tính
Giữa các Region (inter-region transfer)~$0.02/GB
Trong cùng Region, khác AZ, dùng Public/Elastic IP~$0.02/GB
Trong cùng Region, khác AZ, dùng Private IP~$0.01/GB
Trong cùng AZ, dùng Private IPMiễn phí
Dữ liệu truyền VÀO (inbound), mọi trường hợpMiễn phí

Hai mẹo tối ưu chi phí network cần nhớ: ưu tiên dùng Private IP thay vì Public IP (tiết kiệm chi phí và hiệu năng tốt hơn vì không đi qua internet gateway), và đặt các resource giao tiếp nhiều với nhau trong cùng một AZ để tối đa hóa tiết kiệm — đánh đổi là giảm khả năng chịu lỗi cao (high availability) nếu AZ đó gặp sự cố.

Ví dụ thực tế: Một ứng dụng có EC2 và RDS giao tiếp liên tục với lượng dữ liệu lớn. Nếu đặt cả hai trong cùng AZ và giao tiếp qua Private IP, chi phí network gần như bằng 0; nếu đặt ở hai AZ khác nhau dùng Public IP, chi phí có thể phát sinh đáng kể theo từng GB truyền qua lại mỗi ngày.

12. Savings Plans & AWS Compute Optimizer

Savings Plans

Savings Plans cho phép bạn cam kết một số tiền ($) nhất định mỗi giờ, trong 1 hoặc 3 năm — đây được xem là cách dễ nhất để thiết lập cam kết dài hạn (long-term commitment) trên AWS, vì bạn không cần chọn chính xác instance family/size như Reserved Instances.

Savings Plans được thiết lập trực tiếp từ console AWS Cost Explorer.

AWS Compute Optimizer

AWS Compute Optimizer giúp giảm chi phí và cải thiện hiệu năng bằng cách khuyến nghị các cấu hình resource tối ưu cho workload của bạn. Nó giúp bạn chọn được cấu hình phù hợp và "right-size" (đúng kích cỡ) cho các workload đang bị cấp phát dư (over-provisioned) hoặc thiếu (under-provisioned).

Compute Optimizer dùng Machine Learning để phân tích cấu hình resource và các chỉ số sử dụng (utilization metrics) từ CloudWatch. Các loại resource được hỗ trợ: EC2 instances, EC2 Auto Scaling Groups, EBS volumes, và Lambda functions. Việc áp dụng khuyến nghị của Compute Optimizer có thể giúp giảm chi phí tới 25%. Các khuyến nghị này cũng có thể được export ra S3 để phân tích hoặc lưu trữ.

Lưu ý khi thi: Savings Plans là công cụ CAM KẾT chi tiêu để được giảm giá; Compute Optimizer là công cụ PHÂN TÍCH và khuyến nghị cấu hình phù hợp — hai công cụ bổ trợ nhau nhưng giải quyết hai vấn đề khác nhau.

13. Bộ công cụ theo dõi & quản lý chi phí

AWS cung cấp một bộ công cụ billing và costing có thể chia theo 3 mục đích: ước tính chi phí trước khi triển khai, theo dõi chi phí thực tế, và giám sát/cảnh báo khi chi phí vượt kế hoạch.

Ước tính chi phí — AWS Pricing Calculator

AWS Pricing Calculator (truy cập tại calculator.aws) cho phép bạn ước tính chi phí cho một kiến trúc giải pháp cụ thể trước khi triển khai thật, giúp lập ngân sách và so sánh phương án.

Theo dõi chi phí

Giám sát và cảnh báo

Ví dụ thực tế: Một startup đặt AWS Budgets với ngưỡng $500/tháng cho toàn tổ chức, kèm Cost Anomaly Detection để phát hiện nếu một kỹ sư vô tình bật nhầm một cụm EC2 lớn quên tắt qua đêm — Anomaly Detection sẽ nhận ra mức chi tiêu bất thường này nhanh hơn là chờ tới cuối tháng nhìn hóa đơn.
Lưu ý khi thi: Nhớ phân biệt: Billing Alarm (CloudWatch, us-east-1, đơn giản, actual cost) vs Budgets (nâng cao hơn, có forecast, nhiều loại budget, cảnh báo qua SNS) vs Cost Anomaly Detection (dùng ML, không cần đặt threshold, phát hiện bất thường tự động).

14. AWS Trusted Advisor

AWS Trusted Advisor là một công cụ đánh giá tài khoản AWS ở mức cao (high level account assessment) mà bạn không cần cài đặt gì cả — nó tự động phân tích cấu hình tài khoản của bạn và đưa ra khuyến nghị theo 6 nhóm (categories):

Mức độ chi tiết của Trusted Advisor phụ thuộc vào gói Support đang dùng: với gói Business và Enterprise Support, bạn được truy cập Full Set of Checks (bộ kiểm tra đầy đủ) và Programmatic Access thông qua AWS Support API (tự động hóa việc lấy kết quả kiểm tra). Với gói Basic hoặc Developer Support, bạn chỉ được truy cập 7 core checks (7 kiểm tra cơ bản, chủ yếu liên quan tới security và service limits).

Lưu ý khi thi: Nhớ số "7 core checks" cho Basic/Developer, và "full checks + API" chỉ có ở Business/Enterprise — đây là câu hỏi rất hay gặp trong đề thi.

15. Các gói AWS Support Plans

AWS cung cấp 5 gói hỗ trợ (Support Plans) với mức giá và mức độ hỗ trợ tăng dần, phù hợp với quy mô và mức độ nghiêm trọng của workload. Basic Support là miễn phí; các gói còn lại tính phí theo tháng dựa trên mức chi tiêu AWS của bạn.

AWS Basic Support Plan (miễn phí)

AWS Developer Support Plan

Bao gồm toàn bộ Basic, cộng thêm: truy cập email tới Cloud Support Associates trong giờ hành chính (business hours), số lượng case/liên hệ không giới hạn (unlimited). Thời gian phản hồi theo mức độ nghiêm trọng: hướng dẫn chung (general guidance) dưới 24 giờ làm việc; hệ thống bị suy giảm (system impaired) dưới 12 giờ làm việc.

AWS Business Support Plan (24/7)

Dành cho các workload đang chạy production. Bao gồm: Trusted Advisor đầy đủ (full set of checks) kèm truy cập API; hỗ trợ 24x7 qua điện thoại/email/chat với Cloud Support Engineers; số case/liên hệ không giới hạn; có thể trả thêm phí để dùng Infrastructure Event Management. Thời gian phản hồi: hướng dẫn chung dưới 24 giờ; hệ thống suy giảm dưới 12 giờ; hệ thống production bị suy giảm (production system impaired) dưới 4 giờ; hệ thống production ngừng hoạt động (production system down) dưới 1 giờ.

AWS Enterprise On-Ramp Support Plan (24/7)

Dành cho workload production hoặc mang tính then chốt cho doanh nghiệp (business critical). Bao gồm toàn bộ Business, cộng thêm: truy cập vào một NHÓM (pool) các Technical Account Manager (TAM), Concierge Support Team (hỗ trợ về billing và best practice tài khoản), Infrastructure Event Management, và các buổi rà soát Well-Architected & Operations Reviews. Thời gian phản hồi: production bị suy giảm dưới 4 giờ; production ngừng hoạt động dưới 1 giờ; hệ thống business-critical ngừng hoạt động dưới 30 phút.

AWS Enterprise Support Plan (24/7)

Dành cho workload mang tính sống còn (mission critical). Bao gồm toàn bộ Business, cộng thêm: truy cập vào một Technical Account Manager (TAM) ĐƯỢC CHỈ ĐỊNH RIÊNG (designated) — khác với "một pool TAM chung" ở gói On-Ramp; Concierge Support Team; Infrastructure Event Management/Well-Architected/Operations Reviews; và có thể trả thêm phí để dùng AWS Incident Detection and Response. Thời gian phản hồi: production bị suy giảm dưới 4 giờ; production ngừng hoạt động dưới 1 giờ; hệ thống business-critical ngừng hoạt động dưới 15 phút (nhanh hơn On-Ramp).

GóiChi phíĐối tượng phù hợpPhản hồi nhanh nhất
BasicMiễn phíMọi tài khoản AWSKhông có SLA phản hồi
DeveloperTrả phí, thấp nhấtĐang thử nghiệm/phát triển<12h (system impaired)
BusinessTrả phí, theo % chi tiêuWorkload production<1h (production down)
Enterprise On-RampTrả phí, cao hơn BusinessProduction/business-critical<30 phút (business-critical down)
EnterpriseTrả phí, cao nhấtMission-critical<15 phút (business-critical down)
Lưu ý khi thi: Điểm khác biệt quan trọng nhất giữa Enterprise On-Ramp và Enterprise là: On-Ramp có một POOL TAM chung, còn Enterprise có một TAM ĐƯỢC CHỈ ĐỊNH RIÊNG cho tài khoản của bạn. Đây là câu hỏi rất hay bị hỏi để phân biệt hai gói cao cấp nhất.
Ví dụ thực tế: Một ngân hàng vận hành hệ thống thanh toán 24/7 không thể chấp nhận downtime chọn gói Enterprise Support để có TAM riêng luôn hiểu rõ hệ thống của họ và SLA phản hồi 15 phút khi hệ thống business-critical gặp sự cố. Một startup nhỏ mới launch MVP chỉ cần gói Basic hoặc Developer để tiết kiệm chi phí trong giai đoạn đầu.

16. Tổng hợp Best Practices quản lý tài khoản

Để kết thúc chương, dưới đây là danh sách tổng hợp các best practice khi vận hành tài khoản AWS ở quy mô tổ chức, kết hợp lại các dịch vụ đã học ở chương này và các chương trước:

Lưu ý khi thi: Nếu đề thi hỏi "bước đầu tiên cần làm khi phát hiện root account bị compromised" — đáp án luôn ưu tiên: đổi mật khẩu root NGAY, sau đó xoay vòng toàn bộ credentials, rồi mới liên hệ AWS Support.

Tổng kết chương

← Chương trước Chương sau →