Understanding AWS T3 Burstable Instances: CPU Credits, Throttling, and When to Upgrade

Your EC2 application runs perfectly for hours, then suddenly grinds to a halt under moderate load — no memory pressure, no disk I/O bottleneck, just a CPU that refuses to go above 20%. If you're on a T3 instance, you've just hit a CPU credit exhaustion event, and understanding why requires a clear mental model of how burstable performance actually works.

TL;DR

ConceptWhat It Means
CPU CreditOne credit = 1 vCPU running at 100% for 1 minute
Baseline PerformanceThe guaranteed CPU % a T3 instance can sustain indefinitely
Credit AccrualCredits accumulate when CPU usage is below baseline
Credit SpendCredits are consumed when CPU usage exceeds baseline
Unlimited ModeAllows bursting beyond credit balance; surplus usage is billed
ThrottlingIn Standard mode, CPU is hard-capped at baseline when credits are exhausted

The Core Mental Model: A CPU Credit Bank Account

Analogy: Think of CPU credits like a prepaid data plan. Your phone (the instance) has a baseline data speed available 24/7. When you stream video (burst workload), you draw from your prepaid data balance. When you're idle, the balance slowly refills. Once the balance hits zero and you have no top-up plan (Standard mode), your speed is throttled back to the baseline rate — not cut off entirely, just capped.

Every T3 instance has two key parameters that govern this system:

  • Baseline CPU Utilization: The percentage of vCPU the instance can use continuously without spending credits. This varies by instance size.
  • Credit Accrual Rate: The number of CPU credits earned per hour when the instance is running at or below baseline.

Credit Accrual & Spend: The Exact Mechanics

The math is straightforward once you internalize the unit definition:

1 CPU Credit = 1 vCPU × 100% utilization × 1 minute

This means 1 credit also equals: 1 vCPU at 50% for 2 minutes, or 2 vCPUs at 100% for 30 seconds.

Credit Accrual Formula

Credits earned per hour = vCPUs × Baseline% × 60 minutes

For a t3.small (2 vCPUs, 20% baseline): 2 × 0.20 × 60 = 24 credits/hour

Credit Spend Formula

Credits consumed per minute = vCPUs × (Actual CPU% − Baseline CPU%)

This formula yields credits per minute because 1 credit = 1 vCPU at 100% for 1 minute. The delta above baseline is the fraction of a full vCPU-minute being consumed beyond what is "free".

Worked Example — t3.small at 80% CPU for 10 minutes:

  • vCPUs: 2
  • Actual CPU: 80%, Baseline: 20%, Delta: 60%
  • Credits per minute: 2 × 0.60 = 1.2 credits/min
  • Total over 10 minutes: 1.2 × 10 = 12 credits consumed

T3 Instance Baseline & Credit Reference

InstancevCPUsBaseline CPU %Credits Earned/HourMax Credit Balance
t3.nano25%6144
t3.micro210%12288
t3.small220%24576
t3.medium220%24576
t3.large230%36864
t3.xlarge440%962304
t3.2xlarge840%1924608

Note: Always verify current values in the official AWS documentation, as these may be updated.

The Full Credit Lifecycle

graph TD A["Instance Running"] --> B{"CPU vs Baseline?"} B -- "Below Baseline" --> C["Credits Accumulate (up to max balance)"] B -- "Above Baseline" --> D{"Credit Balance > 0?"} D -- "Yes" --> E["Burst: Draw from Credit Balance"] D -- "No" --> F{"Mode?"} F -- "Standard" --> G["CPU Throttled to Baseline % (Performance Degraded)"] F -- "Unlimited" --> H["Burst Continues Surplus Credits Borrowed (Billed if not repaid)"] C --> A E --> A G --> I["Load Drops Below Baseline"] H --> I I --> C
  1. Idle / Low Load: CPU stays below baseline. Credits accumulate at the instance's accrual rate up to the maximum balance cap.
  2. Burst Phase: CPU exceeds baseline. The delta above baseline is funded by drawing from the credit balance.
  3. Credit Exhaustion (Standard Mode): Balance hits zero. The hypervisor hard-throttles the vCPU to the baseline percentage. This is the "sudden slowdown" symptom.
  4. Recovery: Once load drops below baseline, credits begin refilling. Performance recovers proportionally as the balance grows.

Standard Mode vs. Unlimited Mode

T3 instances launch in Unlimited mode by default. This is a critical distinction from T2 instances, which default to Standard mode.

graph LR subgraph Standard_Mode ["Standard Mode"] S1["Credit Balance > 0"] -- "Burst allowed" --> S2["High CPU Performance"] S2 -- "Credits depleted" --> S3["CPU Hard-Throttled to Baseline"] S3 -- "Credits refill" --> S1 end subgraph Unlimited_Mode ["Unlimited Mode (T3 Default)"] U1["Credit Balance > 0"] -- "Burst allowed" --> U2["High CPU Performance"] U2 -- "Credits depleted" --> U3["Surplus Credits Borrowed Burst Continues"] U3 -- "Surplus billed if not repaid" --> U4["Unexpected AWS Charges"] U3 -- "Load drops, credits refill" --> U1 end
  1. Standard Mode: Hard ceiling at baseline CPU when credits are exhausted. Zero additional cost, but your application suffers performance degradation.
  2. Unlimited Mode (T3 Default): The instance can continue bursting beyond its credit balance. AWS bills the surplus CPU usage at a per-vCPU-hour rate. This prevents throttling but can generate unexpected charges on sustained high-CPU workloads.

Key Risk: An application with a runaway process in Unlimited mode will silently accumulate surplus CPU charges. Always set a CloudWatch billing alarm.

Monitoring CPU Credits in CloudWatch

AWS publishes dedicated CloudWatch metrics for T3 credit tracking. The three most operationally important metrics are:

CloudWatch MetricWhat to Watch For
CPUCreditBalanceTrending toward zero = throttling risk (Standard) or surprise bill (Unlimited)
CPUCreditUsageSpikes indicate burst events; sustained high values signal a sizing problem
CPUSurplusCreditBalanceUnlimited mode only: credits borrowed beyond the balance cap
CPUSurplusCreditsChargedUnlimited mode only: surplus credits that were not repaid and will be billed

Recommended CloudWatch Alarm (AWS CLI)

🔽 Click to expand: Create a CPUCreditBalance low-balance alarm 
aws cloudwatch put-metric-alarm \
  --alarm-name "T3-CreditBalance-Low" \
  --alarm-description "T3 CPU credit balance is critically low" \
  --metric-name CPUCreditBalance \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --treat-missing-data notBreaching

Decision Framework: T3 vs. Fixed-Performance Instances

graph TD Start(["What is your workload profile?"]) --> Q1{"Average CPU over 24 hours?"} Q1 -- "< Baseline %" --> T3S["✅ T3 Standard Mode Ideal fit, cost-efficient"] Q1 -- "Near Baseline %" --> Q2{"Occasional spikes?"} Q2 -- "Yes, short spikes" --> T3U["✅ T3 Unlimited Mode Monitor surplus charges"] Q2 -- "No, sustained" --> Fixed["⚠️ Consider Fixed-Performance (M6i, C6i, etc.)"] Q1 -- "> Baseline % sustained" --> Fixed Fixed --> CO["Use AWS Compute Optimizer for right-sizing recommendation"]
  1. Spiky, low-average workloads (dev/test, low-traffic web servers, CI agents) are the ideal T3 use case. The burst model is a cost advantage here.
  2. Sustained high-CPU workloads (video encoding, ML inference, high-traffic APIs) should use fixed-performance instances (M6i, C6i, etc.). Running T3 Unlimited under sustained load is almost always more expensive than the equivalent fixed-performance instance.
  3. Unpredictable workloads: Enable Unlimited mode, monitor CPUSurplusCreditsCharged for 2 weeks, then make a data-driven sizing decision.

Switching Between Standard and Unlimited Mode

🔽 Click to expand: AWS CLI commands to toggle credit mode 
# Check current credit specification
aws ec2 describe-instance-credit-specifications \
  --instance-ids i-0123456789abcdef0

# Switch to Standard mode (enables hard throttle, no surplus charges)
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications \
  '[{"InstanceId": "i-0123456789abcdef0", "CpuCredits": "standard"}]'

# Switch back to Unlimited mode
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications \
  '[{"InstanceId": "i-0123456789abcdef0", "CpuCredits": "unlimited"}]'

Glossary

TermDefinition
CPU CreditA unit representing 1 vCPU running at 100% utilization for 1 minute.
Baseline PerformanceThe sustained CPU percentage a T3 instance can use without consuming credits.
Credit ExhaustionThe state where the CPUCreditBalance reaches zero, triggering throttling (Standard) or surplus billing (Unlimited).
Surplus CreditsIn Unlimited mode, credits borrowed beyond the maximum balance cap; billed if not repaid by subsequent idle periods.
ThrottlingThe hypervisor-enforced hard cap on vCPU usage at the baseline percentage when credits are exhausted in Standard mode.

Next Steps

  • 📖 AWS Docs: Burstable Performance Instances
  • 📊 Enable detailed monitoring (1-minute granularity) on all T3 instances to catch credit drain events before they impact users.
  • 💡 Use AWS Compute Optimizer to get data-driven recommendations on whether to right-size to a fixed-performance instance type.
  • 🔔 Set billing alerts on CPUSurplusCreditsCharged if running any T3 instances in Unlimited mode in production.

Comments

Post a Comment

Popular posts from this blog

IAM User vs. IAM Role: Why Your EC2 Instance Should Never Use a User

Choosing between an IAM User and an IAM Role is one of the most consequential security decisions in AWS — get it wrong and you either expose long-lived credentials or block your application entirely. This post cuts through the confusion and gives you a definitive answer for the EC2-to-S3 access pattern. TL;DR — Quick Comparison Dimension IAM User IAM Role Identity type A person or a static service account An assumable identity for AWS services, users, or external principals Credential type Long-lived Access Key ID + Secret Access Key Short-lived, auto-rotating STS tokens (max 12 h by default) Credential rotation Manual — you must rotate keys yourself Automatic — AWS rotates them transparently Stored on EC2? Yes — in ~/.aws/credentials or env vars (risky) No — delivered via the In...
Read more

EC2 No Internet Access in Custom VPC: Attaching an Internet Gateway and Fixing Route Tables

Launching an EC2 instance in a custom VPC only to find it cannot reach the internet is one of the most common networking pitfalls in AWS — and it almost always comes down to two missing pieces: an Internet Gateway (IGW) and a correctly configured Route Table. This post walks you through the exact architecture, the root cause, and the precise steps to fix it. TL;DR Step Action Why It Matters 1 Create and attach an Internet Gateway to your VPC Without an IGW, there is no path between your VPC and the public internet 2 Add a 0.0.0.0/0 route pointing to the IGW in your subnet's Route Table The route table is the traffic director — without this entry, outbound packets have nowhere to go 3 Assign a Public IP or Elastic IP to the EC2 instance The IGW performs NAT only for instances with a public IP address 4 Verify Security Group allows outbound traffic Security Groups are stateful firewalls; outbound rules...
Read more

Lambda Infinite Loop with S3: How to Prevent Recursive Triggers

Writing a processed file back to the same S3 bucket that triggered your Lambda function creates a recursive loop — each output file fires a new invocation, which writes another file, ad infinitum. Left unchecked, this silently drains your AWS budget and exhausts Lambda concurrency limits within minutes. TL;DR Strategy Mechanism Best For Complexity Separate Output Prefix/Bucket S3 event filter on prefix Simple pipelines Low Object Metadata Check Lambda reads S3 object metadata before processing Single-bucket requirement Medium Separate Output Bucket Trigger only on source bucket Clean architectural separation Low DynamoDB Idempotency Guard Track processed ETag/key in DynamoDB Exactly-once guarantees Medium-High Understanding the Recursive Loop Before fixing the problem, you need to understand exactly why it happens. The S3 → Lambda trigger is an event-driven subscription: S3 publishes an ObjectCreat...
Read more