When I first explored AWS's EC2 Free Tier offering for my personal Drupal site, I discovered several nuances that aren't immediately obvious:
- The free tier includes 750 hours per month of t2.micro or t3.micro instance usage
- 30 GB of EBS storage (SSD or magnetic)
- 15 GB of bandwidth out per month
- 2 million I/O operations on EBS
From personal experience and community reports, these are the most frequent sources of unexpected charges:
// Example of accidental charge scenario
1. Leaving instances running 24/7 (750 free hours = ~31 days for 1 instance)
2. Using non-free-tier instance types during testing
3. Exceeding free EBS storage limits
4. Unintentional data transfer costs (especially between AZs)
5. Elastic IPs that aren't attached to running instances
Here's how I configured my Drupal site to stay within free tier limits:
# CloudWatch Alarm to prevent overages
aws cloudwatch put-metric-alarm \
--alarm-name FreeTierEBSLimit \
--metric-name VolumeWriteBytes \
--namespace AWS/EBS \
--statistic Sum \
--period 3600 \
--evaluation-periods 1 \
--threshold 32212254720 \ # 30GB in bytes
--comparison-operator GreaterThanThreshold \
--alarm-actions arn:aws:sns:us-east-1:123456789012:FreeTierAlerts
Essential AWS CLI commands to track your free tier consumption:
# Check EC2 instance hours
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
--start-time $(date -u +"%Y-%m-%dT%H:%M:%SZ" --date "-1 month") \
--end-time $(date -u +"%Y-%m-%dT%H:%M:%SZ") \
--period 86400 \
--statistics Maximum
# Monitor data transfer
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name NetworkOut \
--dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
--start-time $(date -u +"%Y-%m-%dT%H:%M:%SZ" --date "-1 month") \
--end-time $(date -u +"%Y-%m-%dT%H:%M:%SZ") \
--period 86400 \
--statistics Sum
For my growing Drupal site (5K+ visits/month), I implemented these cost optimization strategies:
- Scheduled instance stop/start using AWS Lambda
- Implemented CloudFront caching to reduce origin requests
- Moved static assets to S3 (free tier includes 5GB)
- Configured RDS free tier instead of EC2-hosted database
Many developers are attracted to AWS's Free Tier offering, particularly the EC2 t2.micro instance that provides 750 hours per month for 12 months. While this sounds generous, there are several caveats that can lead to unexpected charges.
Based on real developer experiences, these are the most frequent sources of unexpected charges:
- EBS Storage Costs: The Free Tier includes 30GB of EBS storage, but any additional storage is charged at $0.10/GB/month
- Data Transfer Fees: While inbound traffic is free, outbound traffic beyond 1GB/month incurs charges
- Instance Overuse: Running more than one t2.micro instance simultaneously consumes your free hours faster
Let's estimate costs for your scenario (5,000 hits/month Drupal site):
# Sample cost estimation for Free Tier usage
free_hours = 750
monthly_hours = 24 * 30 # 720 hours
storage_usage = 20 # GB
data_transfer = 5 # GB
if monthly_hours <= free_hours:
instance_cost = 0
else:
instance_cost = (monthly_hours - free_hours) * 0.0116 # t2.micro hourly rate
storage_cost = max(0, storage_usage - 30) * 0.10
bandwidth_cost = max(0, data_transfer - 1) * 0.09
total_cost = instance_cost + storage_cost + bandwidth_cost
print(f"Estimated monthly cost: ${total_cost:.2f}")
AWS provides tools to track your Free Tier usage:
# AWS CLI command to check Free Tier usage
aws ce get-cost-and-usage \
--time-period Start=2023-01-01,End=2023-01-31 \
--granularity MONTHLY \
--metrics "BlendedCost" \
--filter '{"Dimensions": {"Key": "USAGE_TYPE_GROUP", "Values": ["EC2: Free Tier"]}}'
- Set up billing alerts in AWS Budgets
- Use CloudWatch to monitor instance uptime
- Consider using S3 for static assets to reduce EBS usage
- Implement caching to reduce bandwidth usage
For growing sites (like yours approaching 5,000 hits/month), shared hosting or VPS providers might offer more predictable pricing. The $10/month you're trying to avoid might actually be cheaper than potential AWS charges once you factor in all variables.