Tài khoản, Billing & Support

1. AWS Organizations

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í:

Consolidated Billing (hóa đơn hợp nhất): tất cả tài khoản trong tổ chức được thanh toán qua một phương thức thanh toán (payment method) duy nhất, thay vì mỗi tài khoản tự thanh toán riêng.
Lợi ích về giá từ việc gộp usage (Pricing benefits): mức sử dụng của tất cả tài khoản được cộng gộp lại, giúp đạt tới các mốc chiết khấu theo khối lượng (volume discount) cho EC2, S3… nhanh hơn so với từng tài khoản riêng lẻ tự tính.
Gộp chung Reserved Instances (Pooling of RIs): các EC2 Reserved Instances được mua ở bất kỳ tài khoản nào trong tổ chức có thể dùng chung cho toàn tổ chức, giúp tối ưu mức tiết kiệm.

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.

2. Multi-account & 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:

Tạo tài khoản riêng theo từng phòng ban (department) hoặc trung tâm chi phí (cost center) — để dễ theo dõi ai chi tiêu bao nhiêu.
Tạo tài khoản riêng theo môi trường dev/test/prod — để lỗi ở dev không ảnh hưởng prod, và để áp policy an ninh khác nhau cho từng môi trường.
Tạo tài khoản riêng dựa trên yêu cầu quy định (regulatory restrictions), dùng SCP để bắt buộc tuân thủ ở tài khoản đó (ví dụ tài khoản xử lý dữ liệu y tế phải tuân thủ HIPAA).
Tạo tài khoản riêng để cách ly resource tốt hơn (ví dụ mỗi tài khoản có VPC riêng, tránh xung đột IP hay chia sẻ nhầm resource).
Tạo tài khoản riêng để có giới hạn dịch vụ (service limits) riêng cho từng account — vì AWS Service Quotas áp dụng theo từng account/region.
Tạo một tài khoản riêng chỉ để chứa log (isolated logging account) — tách biệt log khỏi các tài khoản vận hành, tránh bị xóa/sửa log nếu một tài khoản khác bị tấn công.

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:

Dùng chuẩn đặt tag (tagging standards) nhất quán trên mọi tài khoản, phục vụ mục đích billing (ví dụ luôn có tag Environment, Team, CostCenter).
Bật CloudTrail trên tất cả tài khoản, và gửi log tập trung về một tài khoản S3 logging trung tâm.
Gửi CloudWatch Logs của các tài khoản về một tài khoản logging trung tâm để dễ giám sát tổng thể.

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.

3. Service Control Policies

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:

SCP KHÔNG áp dụng cho Management Account (trước là Master Account) — tài khoản gốc luôn có toàn quyền, không bị SCP giới hạn.
SCP áp dụng cho TẤT CẢ Users và Roles của tài khoản thành viên, bao gồm cả Root user của tài khoản đó.
SCP KHÔNG ảnh hưởng tới các service-linked roles — đây là các role đặc biệt cho phép các dịch vụ AWS khác tích hợp với Organizations, và không thể bị SCP hạn chế.
SCP phải có một Allow tường minh (explicit Allow) — mặc định SCP KHÔNG cho phép bất cứ điều gì; nếu một hành động không được Allow rõ ràng ở đâu đó trong cây SCP, nó sẽ bị chặn.

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.

4. Consolidated Billing

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:

Combined Usage (gộp usage): mức sử dụng của tất cả tài khoản trong tổ chức được cộng gộp để cùng chia sẻ giá theo khối lượng (volume pricing), cùng chia sẻ chiết khấu từ Reserved Instances và Savings Plans.
One Bill (một hóa đơn duy nhất): bạn nhận một hóa đơn tổng hợp cho tất cả các tài khoản AWS trong tổ chức, thay vì phải xử lý nhiều hóa đơn riêng lẻ.

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.

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:

Tự động hóa việc thiết lập môi trường chỉ bằng vài cú click.
Tự động hóa việc quản lý policy liên tục bằng các “guardrail” (lan can bảo vệ) — các quy tắc ngăn hành vi không tuân thủ.
Phát hiện các vi phạm policy và có thể khắc phục (remediate) chúng.
Theo dõi mức độ tuân thủ qua một dashboard tương tác trực quan.

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.

6. AWS 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.

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:

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.
Admin cấp quyền truy cập Portfolio cho người dùng thông qua IAM Permissions.
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.
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.

8. Mô hình giá & 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:

Pay as you go (trả tiền theo mức sử dụng): bạn chỉ trả cho những gì đã dùng, giúp doanh nghiệp linh hoạt (agile), phản ứng nhanh (responsive), và đáp ứng được nhu cầu tăng giảm theo quy mô (scale demands) mà không phải đầu tư trước.
Save when you reserve (tiết kiệm khi đặt trước, cam kết dài hạn): giúp giảm rủi ro, quản lý ngân sách dễ dự đoán hơn, và tuân thủ các yêu cầu cam kết dài hạn. Hình thức “reservation” (đặt trước) có ở nhiều dịch vụ: EC2 Reserved Instances, DynamoDB Reserved Capacity, ElastiCache Reserved Nodes, RDS Reserved Instances, Redshift Reserved Nodes.
Pay less by using more (dùng nhiều hơn, trả ít hơn tính theo đơn vị): chiết khấu theo khối lượng sử dụng (volume-based discounts) — dùng nhiều S3, nhiều băng thông, đơn giá trên mỗi GB sẽ giảm dần.
Pay less as AWS grows (trả ít hơn khi AWS phát triển): AWS liên tục tối ưu quy mô hạ tầng của mình và chuyển một phần lợi ích chi phí đó cho khách hàng qua các lần giảm giá dịch vụ theo thời gian.

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.

Free Plan sẽ hết hạn sau 6 tháng hoặc khi credits được dùng hết, tùy điều kiện nào đến trước — trong thời gian này bạn không bị tính phí (no charges) cho các mức sử dụng nằm trong hạn mức.
Paid Plan sẽ bắt đầu tính phí sau khi credits đã dùng hết.

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ụ:

AWS Lambda: 1.000.000 lượt gọi (requests) mỗi tháng và 400.000 GB-giây (GB-seconds) tính toán mỗi tháng.
Amazon DynamoDB: 25GB dung lượng lưu trữ và 200 triệu requests mỗi tháng.

9. Chi phí Compute

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á:

On-Demand: tối thiểu 60 giây, tính phí theo giây (đối với Linux/Windows) hoặc theo giờ (đối với các hệ điều hành khác) — linh hoạt nhất, giá cao nhất.
Reserved Instances: chiết khấu tới 75% so với giá on-demand theo giờ, cam kết 1 hoặc 3 năm, có thể trả trước toàn bộ, một phần, hoặc không trả trước (all/partial/no upfront).
Spot Instances: chiết khấu tới 90%, đấu giá (bid) cho dung lượng compute nhàn rỗi (unused capacity) của AWS — có thể bị thu hồi bất cứ lúc nào.
Dedicated Host: có thể mua theo on-demand hoặc theo cam kết reservation 1 hoặc 3 năm.
Savings Plans: một phương án thay thế để tiết kiệm cho mức sử dụng bền vững (sustained usage) mà không bị ràng buộc cứng vào một loại/kích cỡ instance cụ thể như RI.

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í:

EC2 Launch Type: không tính thêm phí riêng cho ECS — bạn chỉ trả cho các resource AWS (như EC2 instance) mà ứng dụng của bạn tạo ra và lưu trữ.
Fargate Launch Type: bạn trả tiền theo lượng vCPU và bộ nhớ (memory) được cấp phát cho container, không cần quan tâm tới việc quản lý EC2 instance bên dưới.

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í).

11. Chi phí DB, CloudFront, 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ệu	Chi 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 IP	Miễn phí
Dữ liệu truyền VÀO (inbound), mọi trường hợp	Miễ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ố.

12. Savings Plans & 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.

EC2 Savings Plan: chiết khấu tới 72% so với On-Demand; bạn cam kết sử dụng một họ instance cụ thể (instance family, ví dụ C5 hoặc M5) trong một region, và chiết khấu áp dụng bất kể AZ, kích thước, hệ điều hành, hay tenancy.
Compute Savings Plan: chiết khấu tới 66%, linh hoạt hơn EC2 Savings Plan vì không ràng buộc theo family/region/size/OS/tenancy/loại compute — áp dụng cho cả EC2, Fargate, và Lambda.
Machine Learning Savings Plan: áp dụng riêng cho việc sử dụng SageMaker.

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ữ.

13. Công cụ 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.

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í

AWS Billing Dashboard: cho một góc nhìn tổng quan cấp cao (high-level overview) về mức chi tiêu AWS của bạn.
Cost Allocation Tags: dùng tag để theo dõi chi phí AWS ở mức chi tiết. Có hai loại tag: AWS-generated tags — tự động gắn vào resource bạn tạo, bắt đầu bằng tiền tố aws: (ví dụ aws:createdBy); và User-defined tags — do người dùng tự định nghĩa, bắt đầu bằng tiền tố user:. Tag đặt tên tự do, phổ biến nhất là Name, Environment, Team; gắn được cho hầu hết mọi loại resource (EC2 instance, image, load balancer, security group, RDS, resource trong VPC, Route 53, IAM user…), và resource do CloudFormation tạo ra đều được gắn tag theo cùng một cách.
Resource Groups & Tag Editor: tag còn dùng để tạo Resource Group — một tập hợp các resource chia sẻ cùng bộ tag, để bạn tạo, duy trì và xem chúng như một nhóm thay vì tìm lẻ từng dịch vụ. Bản thân các tag được quản lý tập trung bằng Tag Editor.
Cost and Usage Reports (CUR): báo cáo đi sâu nhất vào chi phí và mức sử dụng AWS — chứa bộ dữ liệu chi phí/sử dụng toàn diện nhất, kèm metadata bổ sung về dịch vụ, giá cả, và reservation (ví dụ EC2 RI). CUR liệt kê mức sử dụng AWS cho từng danh mục dịch vụ theo account/IAM user, ở dạng dòng dữ liệu theo giờ hoặc theo ngày, cùng các cost allocation tag đã kích hoạt. CUR có thể tích hợp với Amazon Athena, Redshift, hoặc QuickSight để phân tích sâu hơn.
Cost Explorer: giúp trực quan hóa (visualize), hiểu, và quản lý chi phí/mức sử dụng AWS theo thời gian. Bạn có thể tạo báo cáo tùy chỉnh để phân tích dữ liệu chi phí/sử dụng, xem ở mức tổng quát (tổng chi phí/mức sử dụng của toàn bộ account) hoặc chi tiết tới từng tháng/giờ/resource. Cost Explorer cũng giúp chọn Savings Plan tối ưu để giảm hóa đơn, và dự báo (forecast) mức sử dụng tới 12 tháng dựa trên lịch sử sử dụng trước đó.

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

Billing Alarms trong CloudWatch: dữ liệu billing được lưu dưới dạng metric trong CloudWatch, và LUÔN nằm ở region us-east-1 (dù bạn dùng dịch vụ ở region nào). Dữ liệu billing này phản ánh tổng chi phí AWS trên toàn thế giới (worldwide), và là chi phí THỰC TẾ ĐÃ PHÁT SINH (actual cost), không phải chi phí dự báo (projected cost). Billing Alarm chỉ là một cảnh báo đơn giản, không mạnh bằng AWS Budgets.
AWS Budgets: cho phép tạo ngân sách (budget) và gửi cảnh báo khi chi phí vượt ngưỡng ngân sách đã đặt. Có 4 loại budget: Usage (theo mức sử dụng), Cost (theo chi phí), Reservation (theo Reserved Instances), và Savings Plans. Riêng với Reserved Instances, Budgets có thể theo dõi mức độ sử dụng (utilization), hỗ trợ EC2, ElastiCache, RDS, Redshift. Mỗi budget có thể gửi tối đa 5 thông báo qua SNS. Bạn có thể lọc budget theo: Service, Linked Account, Tag, Purchase Option, Instance Type, Region, Availability Zone, API Operation — các tùy chọn lọc này tương tự với Cost Explorer.
AWS Cost Anomaly Detection: liên tục giám sát chi phí và mức sử dụng bằng Machine Learning để phát hiện các khoản chi tiêu bất thường. Nó tự học các mẫu chi tiêu lịch sử đặc trưng của bạn (unique historic spend patterns) để phát hiện các đợt tăng chi phí đột ngột (one-time spikes) hoặc tăng liên tục theo thời gian (continuous cost increases) — mà bạn KHÔNG cần tự định nghĩa ngưỡng (threshold) như với Budgets. Có thể giám sát theo dịch vụ AWS, theo tài khoản thành viên, theo cost allocation tag, hoặc theo cost category. Khi phát hiện bất thường, nó gửi báo cáo phân tích nguyên nhân gốc (root-cause analysis), và bạn có thể nhận thông báo qua từng cảnh báo riêng lẻ hoặc bản tóm tắt hàng ngày/hàng tuần (dùng SNS).
AWS Service Quotas: thông báo khi bạn tiến gần tới một ngưỡng giá trị service quota (giới hạn dịch vụ). Bạn có thể tạo CloudWatch Alarms ngay trên console Service Quotas. Ví dụ: cảnh báo khi số lượng Lambda concurrent executions gần đạt giới hạn. Khi gần đạt ngưỡng, bạn có thể yêu cầu tăng quota (request a quota increase) từ AWS Service Quotas, hoặc tắt một số resource trước khi chạm giới hạn để tránh lỗi.

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):

Cost Optimization (tối ưu chi phí)
Performance (hiệu năng)
Security (an ninh)
Fault Tolerance (khả năng chịu lỗi)
Service Limits (giới hạn dịch vụ)
Operational Excellence (vận hành xuất sắc)

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).

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.

Basic Support (miễn phí)

Customer Service & Communities: truy cập 24x7 vào dịch vụ khách hàng, tài liệu, whitepaper, và diễn đàn hỗ trợ (support forums).
AWS Trusted Advisor: truy cập 7 core checks và hướng dẫn cơ bản.
AWS Personal Health Dashboard: góc nhìn cá nhân hóa về tình trạng “sức khỏe” của các dịch vụ AWS, cảnh báo khi resource của bạn bị ảnh hưởng.

Developer Support

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.

Business Support (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ờ.

Enterprise On-Ramp (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.

Enterprise Support (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ói	Chi phí	Đối tượng phù hợp	Phản hồi nhanh nhất
Basic	Miễn phí	Mọi tài khoản AWS	Không có SLA phản hồi
Developer	Trả phí, thấp nhất	Đang thử nghiệm/phát triển	<12h (system impaired)
Business	Trả phí, theo % chi tiêu	Workload production	<1h (production down)
Enterprise On-Ramp	Trả phí, cao hơn Business	Production/business-critical	<30 phút (business-critical down)
Enterprise	Trả phí, cao nhất	Mission-critical	<15 phút (business-critical down)

16. Best Practices 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:

Vận hành nhiều tài khoản bằng AWS Organizations để cách ly và quản lý tập trung.
Dùng SCP để giới hạn quyền lực của các tài khoản thành viên theo đúng nhu cầu.
Dùng AWS Control Tower để thiết lập nhanh môi trường multi-account theo best practice.
Dùng Tags & Cost Allocation Tags để dễ quản lý và tính chi phí theo team/dự án.
Áp dụng các nguyên tắc IAM cơ bản: bật MFA, tuân theo nguyên tắc least-privilege, thiết lập password policy và xoay vòng (rotation) mật khẩu định kỳ.
Dùng AWS Config để ghi lại cấu hình của mọi resource và mức độ tuân thủ (compliance) theo thời gian.
Dùng AWS CloudFormation để triển khai stack nhất quán trên nhiều tài khoản và region.
Dùng Trusted Advisor để có insight về tài khoản, và chọn Support Plan phù hợp với nhu cầu thực tế.
Gửi Service Logs và Access Logs về S3 hoặc CloudWatch Logs tập trung.
Dùng AWS CloudTrail để ghi lại mọi lệnh gọi API được thực hiện trong tài khoản.
Nếu tài khoản bị xâm nhập (account compromised): đổi ngay mật khẩu root, xóa và xoay vòng tất cả password/access key, và liên hệ AWS Support ngay lập tức.
Cho phép người dùng tự triển khai các stack đã được admin định nghĩa sẵn thông qua AWS Service Catalog, tránh việc tự tạo tài nguyên không tuân thủ.

Tổng kết chương

AWS Organizations: quản lý nhiều tài khoản, Consolidated Billing, gộp usage để hưởng chiết khấu khối lượng, SCP để giới hạn quyền.
SCP: whitelist/blacklist hành động IAM ở cấp OU/Account; không áp dụng cho Management Account; luôn cần Allow tường minh.
AWS Control Tower: tự động thiết lập môi trường multi-account chuẩn, chạy trên nền Organizations.
AWS RAM: chia sẻ resource có sẵn giữa các account, tránh trùng lặp.
AWS Service Catalog: cổng self-service cho người dùng triển khai sản phẩm đã được admin duyệt trước.
4 mô hình giá AWS: Pay as you go, Save when you reserve, Pay less by using more, Pay less as AWS grows.
Savings Plans: cam kết $/giờ trong 1-3 năm, linh hoạt hơn Reserved Instances (đặc biệt là Compute Savings Plan).
Compute Optimizer: dùng ML khuyến nghị cấu hình resource tối ưu, có thể giảm chi phí tới 25%.
Bộ công cụ chi phí: Pricing Calculator (ước tính), Billing Dashboard/CUR/Cost Explorer (theo dõi), Billing Alarms/Budgets/Cost Anomaly Detection/Service Quotas (giám sát & cảnh báo).
Trusted Advisor: đánh giá tài khoản theo 6 nhóm; 7 core checks (Basic/Developer) vs full checks + API (Business/Enterprise).
Support Plans: Basic (miễn phí) → Developer → Business (24/7, production) → Enterprise On-Ramp (pool TAM) → Enterprise (TAM chỉ định riêng, SLA nhanh nhất).