The 'Free Tier' Trap: How Students Get $100K Bills on Zero-Revenue Projects

Every few months, a new story surfaces on Hacker News or Reddit: a student, a junior developer, a bootcamp graduate opens their AWS console to find a bill measured in tens of thousands of dollars. The project generated zero revenue. The usage was often not even intentional. And the word "free" was prominently featured in the documentation they followed.

This is not a bug in AWS's billing system. It is a structural feature of how pay-as-you-go cloud pricing works -- and it catches newcomers consistently, predictably, and expensively.

This post examines what actually happens when "free tier" meets real-world usage, why the architecture of cloud billing creates these situations, and what safer alternatives look like for teams who want predictable costs without the risk.

What "Free Tier" Actually Means

AWS Free Tier is not a free product. It is a marketing program attached to a live billing account.

When you sign up for AWS Free Tier, you are creating a full commercial AWS account. That account requires a valid payment method -- credit card, debit card, or bank account -- with no spending cap enforced by AWS. The "free" portion is a set of usage allowances: 750 hours of EC2 t2.micro or t3.micro per month for 12 months, 5 GB of S3 storage, 1 million Lambda invocations per month indefinitely, and so on.

Every dollar of usage beyond those allowances is billed at full standard rates, automatically, with no confirmation prompt.

AWS restructured its Free Tier in mid-2025. New accounts now receive a credit-based Free Plan worth up to $200 over six months, replacing the traditional 12-month trial period. The underlying mechanic is the same: a real billing account, a real payment method, and real charges the moment you exceed the defined limits.

There is no built-in spending limit. AWS does offer a Budgets feature that sends email alerts when you cross thresholds you configure, but by the time the alert arrives, the charges are already accruing. An alert at $100 does not stop billing at $100.

How Services Graduate from Free to Paid -- Often Without Warning

The free tier limits sound generous until you understand how quickly real-world usage exceeds them.

Data Transfer

S3 gives you 5 GB of free storage but only 1 GB of free outbound data transfer per month. A tutorial that deploys a simple web application and serves a few hundred users can exhaust that in hours. Outbound data from AWS to the internet is billed at $0.09 per GB in US regions. Stream a 4K video file a few times and you have moved past the free allowance.

Inter-region data transfer is never free, regardless of tier. A tutorial that deploys an application in us-east-1 and calls an API in eu-west-1 starts generating transfer charges immediately.

EC2 Instance Hours

The 750 free EC2 hours per month sounds like a full month of one instance -- and it is, for exactly one instance in one region. Deploy two t2.micro instances for a high-availability tutorial and you are paying for the second one from the start. Leave them running across a month boundary and the 750-hour clock resets while both instances continue running.

Lambda and API Gateway

Lambda's free tier (1 million requests, 400,000 GB-seconds of compute) is genuinely generous for light workloads. The problem is that API Gateway -- the service most tutorials pair with Lambda -- has its own pricing: $3.50 per million API calls for REST APIs. Lambda invocations and API Gateway requests are counted and billed separately. A tutorial that drives load testing or gets indexed by a search crawler can push API Gateway costs past free-tier thresholds within a week.

RDS and the Forgotten Instance

AWS RDS offers 750 hours of db.t2.micro or db.t3.micro per month for 12 months. Crucially, if you create a Multi-AZ deployment (which many tutorials recommend for production readiness), that counts as two instances, consuming 1,500 hours against a 750-hour allowance. The first month generates a full billing event.

The pattern across all of these services is the same: free tier limits are per-account, not per-project. Running multiple tutorial projects simultaneously multiplies your exposure across every dimension.

Real Incidents: When "Free" Becomes Financially Ruinous

The developer community has documented these incidents extensively. They follow a consistent pattern.

The Committed Credentials Attack

In October 2023, security researchers at Palo Alto Networks Unit 42 documented the EleKtra-Leak campaign -- an automated operation that continuously scanned public GitHub repositories for exposed AWS IAM credentials. Attackers began exploiting newly committed credentials within four minutes of exposure. Within ten minutes, EC2 instances were spinning up in multiple regions to mine Monero cryptocurrency.

The victims in these cases were often students following tutorials that instructed them to hardcode credentials in configuration files, then commit those files to GitHub without realizing the exposure risk. The tutorial project earned no revenue. The EC2 instances running mining operations generated charges that could reach tens of thousands of dollars before the account owner noticed.

A 2025 campaign documented by Amazon's own GuardDuty service showed attackers using a new persistence technique: modifying instance attributes to disable API termination. This means even when a victim notices the unauthorized instances and tries to delete them, the API call fails. The instances keep running and keep billing.

The $14,000 Tutorial Project

A developer's account, documented on DEV Community, accumulated $14,267.86 in charges after AWS credentials were accidentally committed to a GitHub repository for a matter of minutes. The project was a learning exercise. It had no users, no traffic, and no revenue. AWS ultimately issued a refund after the unauthorized usage was confirmed, but the process required active support engagement and was not guaranteed.

The $8,000 Idle Account

A Quora post that gained significant attention described a developer who stopped actively using their AWS account for months, received an $8,000 bill, and had to scramble to engage AWS support. The charges came from resources left running -- instances, NAT gateways, Elastic IPs -- that the account owner had forgotten about and had no automated shutdown mechanism.

These are not edge cases. A GitHub repository maintained by security researcher Rami McCarthy -- aws-customer-security-incidents -- catalogs hundreds of similar incidents. The incidents range from students to senior engineers at funded companies.

What AWS Does (and Doesn't Do) When You Dispute

This is where expectations and reality diverge most sharply.

AWS has no published, binding policy that guarantees bill waivers for Free Tier overages or unauthorized usage. Each case is handled by the billing support team on a discretionary basis. The outcome depends on how quickly you identified and contained the issue, whether you can demonstrate the usage was unauthorized, and the dollar amount involved.

In practice, AWS has waived charges in documented cases -- particularly for credential theft where forensic evidence is clear and the account owner acted quickly to revoke credentials and terminate unauthorized resources. First-time overages for genuine mistakes (a student who forgot to terminate an EC2 instance) are often partially or fully credited. AWS support teams are empowered to apply courtesy credits.

But "often" is not "always," and there is no ceiling on what you might owe if the situation is unclear or if AWS determines the usage was your responsibility. Attempting to file a chargeback with your credit card company is explicitly discouraged by AWS, because it triggers collections escalation rather than resolving the billing dispute. The correct path is always a billing support case through the AWS console.

For malicious traffic cases specifically -- where bots or attackers generate billable usage against your account without compromising your credentials -- the outcome is even less predictable. If your public S3 bucket receives 10 TB of unexpected download traffic because someone posted the URL, that data transfer cost falls on you. AWS does not have a mechanism to identify and reverse charges from third-party abuse of publicly accessible resources.

The Architecture of the Problem

The fundamental issue is not that AWS is predatory. It is that the pay-as-you-go model, which makes cloud infrastructure enormously powerful for businesses with revenue, is structurally misaligned with the needs of learners and project-stage developers.

A business with $100K in monthly recurring revenue can absorb a $5,000 unexpected AWS bill while it investigates. A university student with $200 in their checking account cannot absorb a $50,000 bill for a tutorial project with zero users.

The metered model has no natural floor. Every legitimate service AWS provides -- storage, compute, data transfer, API calls, DNS queries -- is a potential billing event. The free tier limits are a ceiling on free usage, not a floor on what you can be charged. Once those limits are exceeded, billing continues until you notice and act.

AWS Budgets can send notifications, but notifications are not circuit breakers. AWS does not automatically terminate your infrastructure when you hit a budget threshold. Adding that capability requires custom Lambda functions, CloudWatch alarms, and IAM policies -- a non-trivial configuration that is itself a source of errors for beginners.

Practical Protection: What Actually Works

If you are using AWS Free Tier for learning, these steps reduce but do not eliminate your risk.

Enable billing alerts immediately. Go to CloudWatch, create an alarm on estimated charges, and set it to trigger at an amount you can afford to lose -- $10, $25, whatever your threshold is. This does not stop charges but gives you early warning.

Set an AWS Budget. Create a monthly budget in the Billing console. Set alert thresholds at 50%, 80%, and 100% of your limit. Again, this is notification only, not enforcement.

Never commit credentials to any repository. Use IAM roles where possible. When you must use access keys, store them in environment variables or AWS credential files, and add .env to your .gitignore before your first commit. Once credentials are committed, rotate them immediately regardless of whether the commit was public.

Create a dedicated IAM user with minimal permissions for each project. Do not use root account credentials for anything. If a limited-permission IAM key is compromised, the attacker's blast radius is constrained.

Terminate everything when you are done. Build the habit of ending your session by checking EC2, RDS, and ECS for running resources. Set up a calendar reminder if you need one. Elastic IPs cost money even when unattached. NAT gateways accumulate charges around the clock.

Enable MFA on your root account. This reduces the risk of account takeover that leads to unauthorized resource creation.

None of these measures are foolproof. A compromised key with broad permissions can generate six-figure bills in hours regardless of budget alerts. Bot traffic to a public endpoint will be billed regardless of your spending intentions.

Fixed-Price Alternatives for Learners and Small Teams

For students, independent developers, and small teams working on pre-revenue projects, fixed-price cloud environments provide a fundamentally safer model. You pay a known monthly fee, and when resources are exhausted, you either upgrade your plan or your resources stop -- they do not keep generating unbounded charges.

InMotion Cloud provides managed cloud infrastructure with transparent, fixed monthly pricing. There is no metered billing model where an unexpected traffic spike or a forgotten resource generates an open-ended invoice. The cost is predictable before the first line of code is deployed.

This model makes a meaningful operational difference for teams learning cloud infrastructure. The cognitive overhead of monitoring billing alongside learning new services is real, and it frequently leads to the exact oversights that cause bill shock. A fixed-price environment removes that variable.

For workloads that genuinely need the elastic scaling of AWS -- traffic that legitimately varies by orders of magnitude -- the pay-as-you-go model is often the right tool. But the majority of learning projects, personal sites, internal tools, and small SaaS applications do not have that requirement. They have predictable, modest traffic and need reliable hosting, not elastic autoscaling.

The Bottom Line

The "free tier" label creates a specific and dangerous misunderstanding: that there is a safe sandbox where charges cannot accrue unexpectedly. There is no such sandbox in AWS Free Tier. The account is live, the payment method is active, and the billing system operates continuously.

Students have received bills in the tens of thousands of dollars for projects with zero users and zero revenue. Some of those bills were waived after lengthy support engagement. Some were not. The variance is the problem.

If you are learning cloud infrastructure, approach AWS Free Tier the way you would approach a credit card attached to a metered utility: with awareness that every service you touch has a price, and that price starts the moment you exceed a usage threshold you may not have noticed.

For teams and organizations evaluating cloud infrastructure for production use, the calculus shifts toward the right tool for the actual workload. But for learning and pre-revenue projects, fixed-price alternatives eliminate a category of financial risk that the pay-as-you-go model cannot, by design, eliminate for you.