AWS Cloud Practitioner CLF-C02

Cloud computing is the on-demand delivery of IT resources over the internet with pay-as-you-go pricing. CLF-C02 leans heavily on the three service models and how AWS maps onto each.

• On-demand delivery: compute, storage, databases, and networking become services you rent by the second or hour instead of capital purchases. No procurement cycle, no rack-and-stack, no overprovisioning for peak.
• Pay-as-you-go pricing: you pay only for what you consume — EC2 by the second (Linux) or hour (Windows), S3 per GB-month, Lambda per millisecond and per request. Stop a resource and the meter stops.
• IaaS (Infrastructure as a Service): highest control — you manage the OS, runtime, app, and data. Amazon EC2 is the canonical IaaS example.
• PaaS (Platform as a Service): AWS manages the underlying infrastructure; you only deploy code and config. AWS Elastic Beanstalk is the canonical PaaS example.
• SaaS (Software as a Service): a complete product, fully run and managed by the provider. Amazon WorkSpaces (DaaS flavour) and Amazon Chime are the canonical AWS SaaS examples.
• Economies of scale: aggregate usage across millions of AWS customers lets AWS achieve lower variable costs than any single customer ever could on their own.

Scenario: a 5-person startup needs a public-facing API. On-prem path: buy a server, lease rack space, hire ops, wait 6 weeks. Cloud path: launch a t3.micro Amazon EC2 instance (IaaS) — running in 90 seconds — or skip the server entirely and deploy the code as an AWS Lambda function behind API Gateway. Storage goes in Amazon S3. Pay only for the seconds the API actually runs. Zero capex, no procurement.

AWS publishes six named benefits of cloud computing. The CLF-C02 exam loves to ask "which benefit is described by …" — memorise the exact AWS phrasing.

• Trade upfront expense for variable expense: no more buying servers before you know how much capacity you need. Pay for what you use, when you use it.
• Benefit from massive economies of scale: aggregate AWS customer demand drives pay-as-you-go prices lower than any one customer could achieve on their own.
• Stop guessing capacity: EC2 Auto Scaling and serverless platforms like AWS Lambda match capacity to actual demand automatically — no more over- or under-provisioning.
• Increase speed and agility: new resources are a few clicks or one API call away. What used to take weeks now takes minutes — accelerates experimentation and time-to-market.
• Stop spending money running and maintaining data centers: AWS owns the heating, cooling, racks, networking gear, and 24/7 staffing. You focus on the differentiator: your application.
• Go global in minutes: deploy across multiple AWS Regions worldwide for low-latency, in-jurisdiction service. Amazon CloudFront adds 600+ edge locations on top. Also: TCO (Total Cost of Ownership) tools help you model cloud vs on-prem.

Scenario: a French e-commerce site launches a global product line. On-prem would mean building data centers in Frankfurt, Sao Paulo, Singapore, Sydney — 2 years and millions in capex. Cloud path: launch in 4 AWS Regions (eu-central-1, sa-east-1, ap-southeast-1, ap-southeast-2), front everything with Amazon CloudFront for sub-50ms edge delivery, autoscale on Black Friday with EC2 Auto Scaling. Use the AWS Pricing Calculator to model TCO. Global in days, not years.

Three deployment models, and the AWS-specific terminology of Regions, Availability Zones, and Edge Locations. The exam frequently contrasts hybrid scenarios.

• Public cloud (cloud-native): all resources run in the cloud — no on-prem infrastructure. AWS is a public cloud provider; running 100% on AWS is the canonical example.
• Private cloud (on-prem): virtualization + resource management on dedicated hardware in your own data center. Maximum control and isolation, but no economies of scale or elasticity.
• Hybrid cloud: cloud-based resources connected to on-prem infrastructure. Use for keeping sensitive data or legacy mainframes on-prem while bursting capacity to AWS. AWS Outposts brings AWS hardware into your data center for a fully consistent hybrid experience.
• AWS Region: a geographic area containing multiple, isolated data centers — e.g. eu-west-3 (Paris), us-east-1 (N. Virginia). Choose by latency, data residency law, service availability, and price.
• Availability Zone (AZ): one or more discrete data centers within a Region, each with redundant power, networking, and connectivity. Multi-AZ deployment = high availability inside a Region.
• Edge Locations: 600+ global PoPs used by Amazon CloudFront and AWS Global Accelerator for low-latency content delivery to end users.

Scenario: a French bank must keep customer PII in France but wants AWS elasticity for the front-end. Solution: hybrid architecture — keep the regulated database on-prem (or on AWS Outposts), run the public web tier on Amazon EC2 in eu-west-3 (Paris) across two Availability Zones for HA, and serve static assets globally via Amazon CloudFront edge locations. Connect on-prem to AWS via AWS Direct Connect for a private, consistent link.

A consistent approach for evaluating architectures. CLF-C02 candidates need to recognise each pillar by its definition and name one or two anchor services.

• Operational Excellence: run and monitor systems to deliver business value; continually improve processes. Anchor services: AWS CloudFormation, AWS Config, Amazon CloudWatch.
• Security: protect information, systems, and assets through risk assessment and mitigation. Anchor services: IAM, AWS CloudTrail, AWS KMS, encryption.
• Reliability: ensure workloads perform correctly and recover from failures. Anchor services: EC2 Auto Scaling, multi-AZ deployments, AWS Backup.
• Performance Efficiency: use computing resources efficiently and maintain that efficiency as demand changes. Anchor services: AWS Lambda (serverless), right-sizing, Amazon ElastiCache.
• Cost Optimization: avoid unnecessary costs and understand spending. Anchor services: AWS Cost Explorer, Reserved Instances, Savings Plans, AWS Trusted Advisor.
• Sustainability: the newest pillar — minimise environmental impact of running cloud workloads. Right-size, use managed services, choose Regions with low carbon intensity. Use the Well-Architected Tool in the console to review workloads against all six pillars.

Scenario: a CTO wants to review a production workload before scaling 10x. Solution: open the AWS Well-Architected Tool, define the workload, answer the questions per pillar. The tool surfaces high-risk issues — e.g. no multi-AZ deployment (Reliability), no encryption at rest (Security), still on On-Demand instances (Cost Optimization). Each issue links to AWS best-practice docs. Schedule remediations and re-review quarterly.

The CAF guides organisations through cloud transformation. Six perspectives covering business + tech sides — easy to confuse with Well-Architected's six pillars on the exam.

• Business perspective: ensures IT is aligned with business needs and that IT investments trace to demonstrable business results. Owned by execs, CFO, finance.
• People perspective: change management — HR and staffing prepare for cloud with updated training, org structure, and new roles. Owned by HR, training leads.
• Governance perspective: aligns IT strategy with business strategy; covers budget management, portfolio management, risk management. Owned by CIO, PMO.
• Platform perspective: design, implement, and optimise cloud architecture; principles and patterns for new solutions. Owned by architects, engineering leads.
• Security perspective: meet security objectives for visibility, auditability, control, and agility. Owned by CISO, security team.
• Operations perspective: ensure cloud services are delivered at agreed-upon levels, matching current business needs. Owned by ops, SRE.

Scenario: a bank starts a 3-year cloud migration. Solution: use the AWS CAF as the transformation roadmap. Business perspective produces the cloud business case; People perspective drives a training plan with AWS Skill Builder and gets every engineer CLF-C02 certified; Governance perspective sets up AWS Organizations with SCPs and budgets; Platform perspective designs the landing zone; Security perspective wires AWS Config and GuardDuty from day one; Operations perspective stands up the cloud Center of Excellence (CCoE).

The single most-tested concept on CLF-C02. Where AWS responsibility ends and customer responsibility begins shifts with each service tier.

• AWS is responsible for security OF the cloud: physical infrastructure, hardware, networking, virtualization layer, and the global infrastructure that runs every AWS service. Data-center physical security included.
• Customer is responsible for security IN the cloud: customer data, IAM (identity and access management), OS configuration, network/firewall settings, client-side encryption, server-side encryption choices.
• IaaS line — Amazon EC2: customer manages guest OS, patching, firewall rules (Security Groups), and application security. AWS handles the hypervisor and below.
• Managed-service line — Amazon RDS: AWS handles OS and database engine patching, backups, and underlying compute. Customer manages users, schema, encryption choice, network exposure.
• Serverless line — AWS Lambda: AWS manages virtually all infrastructure including the runtime. Customer is only responsible for the code, the IAM execution role, and the data it touches.
• Shared controls: patch management (AWS patches infra; you patch your guest OS + apps), config management, awareness + training. These are owned by both parties at different layers.

Scenario: a customer runs WordPress on an Amazon EC2 instance behind an Application Load Balancer with an Amazon RDS MySQL backend, secrets in AWS Secrets Manager. AWS responsibility: data-center physical security, hypervisor patches, the RDS engine and OS, the ALB hardware. Customer responsibility: WordPress version patches, EC2 guest OS patches, IAM users and policies, Security Group rules, the choice to enable RDS encryption at rest, MFA on the root account, the database password stored in Secrets Manager.

IAM is the front door to every AWS resource. CLF-C02 tests the difference between root, users, groups, roles, the JSON policy shape, and the least-privilege principle.

• Root user: created when the account is created; has unrestricted access. Best practice: enable MFA, lock the credentials away, use only for the handful of tasks that require it (change account settings, close account, change support plan).
• IAM users: represent an individual person or service. Each user has unique credentials (password and/or access keys). Never share a user; never use root for daily work.
• IAM groups: collections of users that share permissions — e.g. Developers, Admins, Billing. Attach the policy to the group, not the user, for clean management.
• IAM roles: identities assumed by trusted entities (EC2 instances, Lambda functions, federated users, cross-account principals) for temporary credentials. The right way to give an EC2 instance access to S3 — never embed access keys in code.
• IAM policies: JSON documents with Effect (Allow/Deny), Action (e.g. s3:GetObject), Resource (ARN), optional Condition. Identity-based (attached to users/groups/roles) or resource-based (attached to the resource).
• MFA + least privilege: enable MFA on every human user, especially root. Grant the minimum permissions required — start with nothing, add as needed; never go the other way.

Scenario: a 5-person dev team needs read/write access to one specific S3 bucket and EC2 in dev only. Solution: create an IAM group Developers with a policy granting s3:* on arn:aws:s3:::myapp-dev/* and ec2:* with a Condition aws:RequestedRegion = eu-west-3. Create 5 IAM users, add them to the group, enable MFA on all 5. For the application running on an EC2 instance that needs S3 access, attach an IAM Role to the instance — never store access keys on disk.

AWS exposes a stack of named security services. CLF-C02 doesn't expect deep config — just "which service answers which problem".

• AWS Security Hub: central dashboard aggregating findings from GuardDuty, Inspector, Macie, and partner tools. Automated compliance checks against frameworks like CIS AWS Foundations and PCI DSS.
• Amazon GuardDuty: intelligent threat detection — continuously analyses CloudTrail events, VPC Flow Logs, and DNS logs using machine learning + threat intelligence feeds. No agents to install; click-to-enable.
• Amazon Inspector: automated vulnerability assessment for Amazon EC2 instances, container images in Amazon ECR, and AWS Lambda functions. Surfaces CVEs and deviations from best practices.
• AWS WAF: Web Application Firewall — protects web apps from SQL injection, XSS, and other Layer-7 exploits. Customisable rules; attaches to CloudFront, ALB, or API Gateway.
• AWS Shield Standard: automatic, free DDoS protection for every AWS customer against the most common L3/L4 attacks. Always-on; no opt-in needed.
• AWS Shield Advanced: premium DDoS service ($3,000/month) with 24/7 AWS DDoS Response Team (DRT) access, advanced L7 mitigation, and financial protection against DDoS-related scaling costs. AWS Firewall Manager centralises WAF/Shield rule deployment across an Organisation.

Scenario: an e-commerce shop suspects credential stuffing + SQL injection attempts. Solution: enable Amazon GuardDuty to detect anomalous API calls and reconnaissance from suspect IPs; deploy AWS WAF in front of the CloudFront distribution with AWS Managed Rules (Core rule set + Known Bad Inputs + SQL injection); aggregate findings in AWS Security Hub. For sustained DDoS waves, subscribe to AWS Shield Advanced for the 24/7 DRT line. Run Amazon Inspector weekly to catch new CVEs on the EC2 fleet.

AWS inherits dozens of compliance attestations; customers consume them through Artifact. Config, CloudTrail, and Audit Manager handle the customer-side controls.

• AWS Artifact: self-service portal for AWS compliance reports — SOC 1/2/3, PCI DSS attestations, ISO 27001 certificates. Also handles agreements like the HIPAA Business Associate Addendum (BAA).
• AWS Config: continuously records resource configurations and evaluates them against rules. Managed rules from AWS or custom rules in AWS Lambda. Provides a configuration timeline showing how resources changed.
• AWS CloudTrail: logs every API call (who, when, from where, what changed). On by default with 90-day management-event history; create a Trail to ship to Amazon S3 indefinitely. Forensic source-of-truth.
• AWS Audit Manager: continuously collects evidence for audits against frameworks (PCI, HIPAA, SOC 2, GDPR). Reduces the manual evidence-gathering burden.
• Inherited controls: AWS handles infrastructure compliance — customer inherits SOC, PCI, HIPAA at the infrastructure layer and adds their own application-layer controls on top.
• Compliance programs: HIPAA (health data), PCI DSS (payment cards), SOC 1/2/3 (controls reporting), ISO 27001 (infosec management), FedRAMP (US Gov), GDPR (EU data privacy).

Scenario: a healthtech startup must prove HIPAA compliance for an annual audit. Solution: download SOC 2 + HIPAA reports from AWS Artifact; accept the HIPAA BAA. Enable AWS Config with the AWS-managed conformance pack for HIPAA — auto-flag any S3 bucket without encryption. Enable AWS CloudTrail with multi-region, shipped to a locked S3 bucket with Object Lock for tamper-proof audit logs. Use AWS Audit Manager to collect HIPAA evidence automatically throughout the year.

Encryption at rest + encryption in transit + secrets management + sensitive-data discovery. The four pillars of AWS data protection.

• AWS Key Management Service (KMS): create, manage, and audit cryptographic keys. Integrated with virtually every AWS service for transparent server-side encryption.
• Encryption at rest: Amazon S3 supports SSE-S3, SSE-KMS, and SSE-C; Amazon EBS volumes can be encrypted at creation; Amazon RDS encrypts the underlying storage. AWS-managed keys are free; customer-managed CMKs cost $1/month per key.
• Encryption in transit: TLS/SSL protects data moving between systems. AWS APIs are HTTPS-only by default.
• AWS Certificate Manager (ACM): free, auto-renewing public TLS certificates for CloudFront, ALB, API Gateway. Private CA option for internal certs. No more manual cert rotation drama.
• Amazon Macie: ML-based discovery and classification of sensitive data (PII, financial, healthcare data) in Amazon S3. Flags buckets containing credit cards, SSNs, etc.
• AWS Secrets Manager: securely store, automatically rotate, and retrieve secrets — DB credentials, API keys, OAuth tokens. Native rotation for RDS, Redshift, DocumentDB. Stop hard-coding passwords.

Scenario: a fintech needs to protect customer financial data end-to-end. Solution: encrypt every layer. Create a customer-managed CMK in AWS KMS with annual key rotation; encrypt the Amazon RDS database, all Amazon EBS volumes, and Amazon S3 buckets with that key. Front the public web tier with AWS Certificate Manager TLS certificates on the ALB. Store the database master password in AWS Secrets Manager with 30-day auto-rotation. Run Amazon Macie weekly to flag any S3 bucket that accidentally received unencrypted PII.

Compute is the heart of AWS. CLF-C02 wants you to pick the right compute primitive for each workload — VM vs container vs serverless vs PaaS.

• Amazon EC2 (Elastic Compute Cloud): resizable virtual servers. Choose instance type (CPU/memory/storage/network), AMI (the OS image), and Security Groups (the virtual firewall). Families: General (M/T), Compute (C), Memory (R/X), Storage (I/D), Accelerated (P/G with GPUs).
• AWS Lambda: serverless compute — run code in response to events, billed per millisecond and per request. Auto-scales from 0 to thousands of concurrent executions. No servers to provision or patch.
• Amazon ECS (Elastic Container Service): fully managed Docker container orchestration. Tasks run on either EC2 (you manage instances) or Fargate (serverless).
• AWS Fargate: serverless compute engine for ECS and EKS — no EC2 instances to manage. Pay for the vCPU and memory the container uses. Trade-off: less control, more convenience.
• AWS Elastic Beanstalk: PaaS — upload code (Java, .NET, Node.js, Python, Ruby, Go, Docker) and Beanstalk handles deployment, capacity, load balancing, and health monitoring. Underneath it's just EC2 + ASG + ELB.
• EC2 Auto Scaling: automatically adjusts EC2 capacity based on CloudWatch metrics. Combined with an ALB, this is the canonical AWS HA pattern. Amazon Lightsail = simplified bundled VPS for beginners.

Scenario: 4 compute choices for 4 workloads. (1) A WordPress site → Amazon Lightsail bundle (cheapest for beginners). (2) A custom REST API → AWS Lambda behind API Gateway (pay per request only). (3) A Docker microservices stack → Amazon ECS on AWS Fargate (no infra to manage). (4) A Java enterprise app needing a real server → Amazon EC2 with EC2 Auto Scaling + ALB, or wrap it in AWS Elastic Beanstalk if the team wants PaaS conveniences.

Object vs block vs file storage. CLF-C02 loves to ask "which S3 storage class for which access pattern" and "which storage type for which workload".

• Amazon S3 (Simple Storage Service): virtually unlimited object storage with 99.999999999% (11 nines) durability. Files (called objects) live in buckets with globally unique names. Accessed via HTTPS API.
• S3 storage classes: Standard (frequent access), Standard-IA (infrequent, rapid retrieval), One Zone-IA (single-AZ, cheaper), Intelligent-Tiering (auto-moves objects between tiers), Glacier Instant / Flexible / Deep Archive (archival, ms-to-12h retrieval).
• S3 lifecycle policies: automate object transitions between classes — e.g. Standard → IA after 30 days → Glacier after 90 days → expire after 7 years.
• Amazon EBS (Elastic Block Store): persistent block storage volumes attached to one EC2 instance (multi-attach for io2 limited). SSD-backed (gp3, io2) for IOPS; HDD-backed (st1, sc1) for throughput. AZ-scoped.
• Amazon EFS (Elastic File System): fully managed NFS file system. Mountable by many EC2 instances across AZs simultaneously. Scales storage automatically. Linux-only NFS; FSx for Windows / Lustre / NetApp / OpenZFS.
• AWS Storage Gateway: hybrid storage — connect on-prem to AWS storage transparently. File Gateway (NFS/SMB → S3), Volume Gateway (iSCSI → EBS-style), Tape Gateway (VTL → S3 Glacier). For data-center migration and backup.

Scenario: a media company stores 100TB of video. Solution: tier by access pattern. Hot uploads → Amazon S3 Standard. After 30 days → transition to S3 Standard-IA via lifecycle policy. After 1 year → S3 Glacier Flexible Retrieval. Active editing workstation files → Amazon EFS mounted on multiple EC2 video-editing instances. Each EC2 instance's OS disk → Amazon EBS gp3. On-prem video-archive tapes migrated via AWS Storage Gateway Tape Gateway → S3 Glacier Deep Archive. Cost drops from ~$2,300/month to ~$500/month with no usability loss.

Relational vs NoSQL vs data warehouse vs in-memory cache. Match each AWS database service to its job description.

• Amazon RDS (Relational Database Service): managed relational DB with 6 engines — Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server. AWS handles provisioning, patching, backup, recovery. Multi-AZ = HA; Read Replicas = scale-out reads.
• Amazon Aurora: MySQL- and PostgreSQL-compatible cloud-native DB, up to 5x MySQL throughput and 3x PostgreSQL. Storage auto-grows; replicated across 3 AZs by default. Aurora Serverless for unpredictable workloads.
• Amazon DynamoDB: fully managed NoSQL key-value + document store. Single-digit millisecond latency at any scale. On-demand or provisioned capacity. Built-in security, backup, global tables, in-memory caching via DAX.
• Amazon Redshift: petabyte-scale data warehouse. Columnar storage, MPP query engine. Use SQL to analyse data across warehouses and S3 data lakes (Redshift Spectrum).
• Amazon ElastiCache: managed in-memory cache — Redis or Memcached. Microsecond latency. Use for session stores, leaderboards, real-time analytics, DB query caching.
• Amazon DocumentDB / Neptune / Keyspaces / Timestream / QLDB: purpose-built engines for documents (Mongo-compatible), graphs, Cassandra workloads, time-series, and append-only ledgers respectively.

Scenario: a gaming startup needs 4 data layers. Solution: player profiles (key-value, low-latency, global) → Amazon DynamoDB with Global Tables. Game-session leaderboard (sorted set, microsecond reads) → Amazon ElastiCache for Redis. Transactions and billing (ACID relational) → Amazon RDS for PostgreSQL Multi-AZ. Analytics dashboard (SQL over years of click data) → Amazon Redshift with data ingested from S3.

The AWS networking primitives. VPC is the foundational private network; CloudFront accelerates delivery; Route 53 is global DNS; ELB distributes load.

• Amazon VPC (Virtual Private Cloud): a logically isolated network you define. Spans all AZs in a Region. Contains subnets, route tables, internet gateway, NAT gateway.
• Subnets: public (route to Internet Gateway) for resources that need internet; private (no IGW route, may have NAT for outbound) for backend tiers. Multi-AZ subnets = HA.
• Security groups vs NACLs: Security Groups = stateful instance-level firewall (return traffic auto-allowed). NACLs = stateless subnet-level firewall (explicitly allow both directions). SGs are the day-one tool.
• Amazon CloudFront: global CDN with 600+ edge locations. Caches content close to users; integrates with WAF, ACM TLS certs, and S3/ALB origins. Lowers latency and origin load.
• Amazon Route 53: highly available global DNS + domain registration. Routing policies: simple, weighted, latency-based, failover (HA), geolocation, geoproximity, multi-value answer. Health checks for failover.
• AWS Direct Connect + Elastic Load Balancing: Direct Connect = dedicated private link from on-prem to AWS (more consistent than VPN). ELB = ALB (L7 HTTP), NLB (L4 TCP/UDP), GWLB (firewall insertion). Multi-AZ targets = HA.

Scenario: a global web app needs HA + low latency. Solution: build a VPC in eu-west-3 (Paris) with 2 public subnets (for the Application Load Balancer) and 2 private subnets (for the EC2 Auto Scaling group of web servers) across two AZs. Amazon RDS Multi-AZ in the DB private subnets. Front everything with Amazon CloudFront for static + dynamic acceleration. Register the domain in Amazon Route 53 with a failover routing policy to a DR region. For the on-prem CRM that the app calls, use AWS Direct Connect for a private, consistent link.

The day-2 toolchain. CloudWatch monitors; CloudFormation provisions; Trusted Advisor recommends; SSM operates. Plus the 3 ways you talk to AWS — Console, CLI, SDK.

• Amazon CloudWatch: metrics (CPU, network, custom), logs, events, alarms. Set CloudWatch Alarms on thresholds to send SNS notifications or trigger Auto Scaling actions.
• AWS CloudFormation: infrastructure-as-code. Write a JSON or YAML template; CloudFormation creates, updates, and tears down resources in dependency order. Repeatable, version-controlled stacks.
• AWS Trusted Advisor: live, real-time recommendations across 5 categories: cost optimization, performance, security, fault tolerance, and service limits. Basic checks free; full checks need Business or Enterprise support.
• AWS Systems Manager (SSM): unified ops interface — Patch Manager (OS patching), Run Command (remote shell without SSH), Session Manager (SSH-less shell), Parameter Store (config), Automation (runbooks).
• Management Console / CLI / SDKs: Console = web UI. CLI = command line (aws s3 cp …). SDKs = programmatic in Python, JS, Java, Go, etc. CloudShell = browser-based shell preconfigured with AWS CLI.
• AWS Health + Personal Health Dashboard: visibility into AWS service events and account-specific incidents affecting your resources.

Scenario: an ops team needs to provision a new 3-tier app + monitor it + cost-optimize. Solution: write a CloudFormation template with the VPC, ALB, Auto Scaling group, and RDS — deploy in dev / staging / prod with the same template. Wire Amazon CloudWatch Alarms on CPU + 5xx errors, alerting via SNS to the on-call team. Use AWS Trusted Advisor weekly to surface idle EC2 instances and underutilized RDS. Patch EC2 monthly via AWS Systems Manager Patch Manager. The team interacts via AWS CloudShell in the Console — no local credentials needed.

Pick the right pricing model and you save up to 90%. CLF-C02 frequently asks "which pricing model is MOST cost-effective for workload X" — memorise the trade-offs.

• On-Demand: pay by the second (Linux) or hour (Windows). No long-term commitment. Use for unpredictable workloads, short-term testing, or first-time apps. Most expensive per hour; most flexible.
• Reserved Instances (RI): commit to a 1- or 3-year term for a specific instance type in exchange for up to 72% discount. Standard RI = highest discount; Convertible RI = lower discount but can change family.
• Savings Plans: flexible commitment by $/hour for 1 or 3 years; up to 72% off. Compute Savings Plans apply across EC2, Fargate, and Lambda regardless of family or Region. EC2 Instance Savings Plans are restricted to a family + Region but bigger discount.
• Spot Instances: spare EC2 capacity at up to 90% discount, but AWS can reclaim them with a 2-minute warning. Perfect for fault-tolerant, flexible, stateless workloads — batch processing, big-data analytics, CI runners.
• Dedicated Hosts: physical servers fully dedicated to you. Used for BYOL licensing (Oracle, Microsoft) or strict compliance/isolation requirements. Most expensive.
• AWS Free Tier: three flavours — always free (e.g. Lambda 1M requests/month, DynamoDB 25GB), 12 months free (e.g. 750 hours/month of t2.micro EC2, 5GB S3 Standard), short trials (e.g. Inspector 90-day trial).

Scenario: a company runs 100 EC2 instances. Solution: mix pricing models for max savings. 60 instances run 24/7 (the steady production fleet) → buy 3-year Compute Savings Plans for ~66% discount. 20 instances are dev/test, running business-hours only → On-Demand with scheduled stop/start. 20 instances are a nightly batch analytics job that tolerates interruption → Amazon EC2 Spot for 80–90% discount. New ML training jobs use the AWS Free Tier SageMaker trial for the first 250 hours.

Five tools own the AWS cost workflow. CLF-C02 wants you to know which one answers "how much did I spend", "alert me before I overspend", "estimate before I build", and "tag for allocation".

• AWS Cost Explorer: free visualization of historical AWS costs and usage. Default reports + custom filters/groupings (by service, account, tag). ML-based 12-month forecast.
• AWS Budgets: set custom cost + usage budgets and get alerted when you exceed (or are forecasted to exceed) thresholds (50%, 80%, 100%). Optional automated actions — e.g. detach a permissive IAM policy when budget is blown.
• AWS Cost & Usage Report (CUR): the most granular cost data — line-item per resource-hour. Exported to Amazon S3 for analysis in Athena, Redshift, or QuickSight. The source-of-truth for FinOps.
• AWS Pricing Calculator: estimate AWS costs before deploying. Build an architecture, pick instance types and storage, compare options. Public — no AWS account needed.
• Cost allocation tags: key-value tags (e.g. Project: ProjectX, Environment: prod, Owner: alice) that surface as breakdown dimensions in Cost Explorer and CUR. Activate them in the Billing Console.
• Billing Console + AWS Cost Anomaly Detection: single billing dashboard for all accounts; Cost Anomaly Detection uses ML to flag unusual spend spikes automatically.

Scenario: a CFO asks "where did $50k of AWS spend go last month and how do we control it?". Solution: open AWS Cost Explorer and break down by service + tag. Notice $20k from a single team's untagged dev resources — fix it by enforcing the Project + Owner cost allocation tags via AWS Organizations tag policies. Create an AWS Budget per team with alerts at 80% and 100%. For the deep-dive analyst, export the Cost & Usage Report to S3 and query it from Amazon Athena. Before launching the next big project, model it in the AWS Pricing Calculator.

Five support plans. CLF-C02 loves "which plan is needed for X" — memorise response times and what each plan includes.

• Basic Support (free, every account): 24/7 access to customer service, documentation, whitepapers, support forums, the Personal Health Dashboard, and a limited set of Trusted Advisor checks. No tech support.
• Developer Support (from $29/month): business-hours email access to Cloud Support Associates. 12–24 hour response for general guidance and 12-hour for system-impaired cases. One contact (the account owner). No phone, no chat.
• Business Support (from $100/month): 24/7 phone, email, and chat access to Cloud Support Engineers. 1-hour response for production system down. All Trusted Advisor checks. AWS Support API for programmatic case management. Unlimited contacts.
• Enterprise On-Ramp (from $5,500/month): pool of Technical Account Managers (shared, not designated). 30-minute response for business-critical system down. Consultative architecture guidance. Aimed at growing businesses.
• Enterprise Support (from $15,000/month): designated Technical Account Manager (TAM) with proactive guidance, architecture and operational reviews, 15-minute response for business-critical system down, Infrastructure Event Management, concierge billing support team.
• The TAM: the key Enterprise differentiator — a dedicated AWS expert who knows your workload, recommends optimizations, and advocates for you internally at AWS. Worth the premium for mission-critical multi-million-dollar AWS spend.

Scenario: 3 customers, 3 different needs. (1) A solo founder learning AWS → Basic Support (free), use re:Post forums. (2) A mid-market SaaS with 24/7 prod traffic → Business Support for the 1-hour response SLA + Trusted Advisor full checks + Support API. (3) A Fortune 500 bank with multi-million-$ spend → Enterprise Support with a designated TAM for quarterly architecture reviews, 15-minute SLA on business-critical issues, and Infrastructure Event Management around their Black Friday launch.

Multi-account governance. CLF-C02 asks about the management/member account model, OUs, SCPs as guardrails, and the volume-pricing benefit of consolidated billing.

• AWS Organizations: central management for multiple AWS accounts. One management account (formerly "master") owns the org and invites or creates member accounts.
• Organizational Units (OUs): group member accounts into hierarchies — typical layout: Root → Security OU, Production OU, Sandbox OU. Policies attach at OU level for broad effect.
• Service Control Policies (SCPs): guardrails — set the maximum permissions for IAM users/roles in member accounts. SCPs do not grant permissions; they restrict what IAM in the account can do. Example SCP: "deny any action outside eu-west-3".
• Consolidated billing: single invoice for all accounts in the org. Aggregates usage across accounts to reach higher volume-pricing tiers + share Reserved Instance / Savings Plans benefits org-wide.
• Volume + RI/SP sharing: if 5 accounts each use a little S3, their combined volume might reach the next discount tier — everyone in the org pays less. Same applies to RIs / Savings Plans purchased in one account and consumed by another.
• AWS Control Tower: opinionated landing zone built on top of Organizations — sets up multi-account governance, guardrails, and an Account Factory using AWS best practices in a few clicks.

Scenario: a scale-up has 1 AWS account that's become a mess — dev, prod, and security all mixed together. Solution: stand up AWS Organizations, create a Production OU and a Sandbox OU. Attach an SCP to the Sandbox OU that denies launching any instance bigger than m5.large and any action outside eu-west-3. Consolidated billing rolls all accounts onto one invoice; existing Reserved Instances purchased in the management account are shared across member accounts. Use AWS Control Tower for an opinionated multi-account starting point with built-in guardrails.

Where to find third-party software, how AWS Partners help, and the lifecycle / migration tooling beginners should know.

• AWS Marketplace: curated catalogue of third-party software sold through AWS — SaaS, AMIs, container images, ML models, professional services. Pay through your existing AWS bill; per-hour, monthly, or annual SKUs.
• AWS Partner Network (APN): ecosystem of consulting + technology partners. Partner tiers (Select, Advanced, Premier) reflect AWS expertise. Consulting partners help you migrate and build; technology partners sell software that runs on AWS.
• AWS Migration Hub + MAP: Migration Hub tracks application migrations across services. The Migration Acceleration Program (MAP) offers training, tooling, and partial funding for large migrations.
• AWS re:Post + Skill Builder: re:Post is the official Q&A community (replaced AWS Forums). Skill Builder is the free + paid AWS training platform — CLF-C02 exam prep included.
• AWS Knowledge Center + IQ: Knowledge Center publishes how-tos for common issues. AWS IQ matches you with freelance AWS-certified experts for small jobs (hourly or fixed-price).
• Account lifecycle: create account → enable MFA on root → set up billing alerts → create IAM users → enable CloudTrail → tag everything → close account via Account Settings (data retained 90 days then deleted).

Scenario: an SMB plans a 6-month AWS migration. Solution: engage an AWS Partner Network Advanced Consulting Partner via AWS Migration Acceleration Program (MAP) for partial funding + expert guidance. Their engineers train on AWS Skill Builder and earn CLF-C02 in week 2. Buy the new monitoring tool from AWS Marketplace as a SaaS subscription (billed via the AWS invoice). Track each app's migration progress in AWS Migration Hub. When stuck, ask the community on AWS re:Post.