How We Cut AWS Costs by 85%: From $487 to $73/Month

This isn't another "we saved money on AWS" fluff piece. This is the exact playbook we used to cut a healthcare platform's AWS bill from $487 to $73/month - including the mistakes we made and the code we wrote.

📊 The Starting Point: A Typical Over-Provisioned Setup

🎯 Step 1: The Discovery Phase (Week 1)

We started by installing CloudWatch detailed monitoring and actually looking at the data. The results were shocking:

📐 Step 2: Architecture Redesign (Week 2)

💻 Step 3: The Actual Migration (Weeks 3-4)

Phase 1: API Migration to Lambda

// app.js - Running 24/7 on EC2
const express = require('express');
const mysql = require('mysql2');
const app = express();

const db = mysql.createConnection({
  host: 'rds-instance.aws.com',
  user: 'admin',
  password: process.env.DB_PASS,
  database: 'healthapp'
});

app.get('/api/patients/:id', (req, res) => {
  db.query(
    'SELECT * FROM patients WHERE id = ?',
    [req.params.id],
    (err, results) => {
      if (err) return res.status(500).json({err});
      res.json(results[0]);
    }
  );
});

app.listen(3000); // Running forever

// getPatient.js - Only runs when needed
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB.DocumentClient();

exports.handler = async (event) => {
  const { id } = event.pathParameters;
  
  try {
    const result = await dynamodb.get({
      TableName: 'patients',
      Key: { patientId: id }
    }).promise();
    
    return {
      statusCode: 200,
      headers: {
        'Access-Control-Allow-Origin': '*'
      },
      body: JSON.stringify(result.Item)
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: error.message })
    };
  }
};

Phase 2: Database Migration (The Tricky Part)

Moving from RDS MySQL to DynamoDB was the scariest part. Here's exactly how we did it:

# Found that 94% of queries were simple key-value lookups
SELECT * FROM patients WHERE patient_id = ?    -- 67%
SELECT * FROM appointments WHERE date = ?       -- 18%
SELECT * FROM medications WHERE patient_id = ? -- 9%
Complex JOINs                                  -- 6%

{
  "TableName": "healthcare-app",
  "PartitionKey": "PK",      // PATIENT#12345
  "SortKey": "SK",           // PROFILE or APPT#2024-01-15
  "GSI1": {
    "PartitionKey": "GSI1PK", // DATE#2024-01-15
    "SortKey": "GSI1SK"        // APPT#12345
  }
}

🚀 Step 4: Performance Optimization (Week 5)

The Unexpected Performance Gains

Optimization Techniques We Used:

1. Lambda Memory Tuning: Started at 128MB, tested up to 3GB. Found sweet spot at 512MB (best cost/performance).
2. Connection Pooling: Reused DynamoDB connections across invocations.
3. CloudFront Caching: Cached API responses for 60 seconds (reduced Lambda invocations by 40%).
4. Provisioned Concurrency: Set 2 warm instances for morning traffic spike.

💰 Step 5: Cost Optimization Tricks (Week 6)

aws s3api put-bucket-lifecycle-configuration \
  --bucket healthcare-uploads \
  --lifecycle-configuration file://lifecycle.json

# Saved $18/month on old patient files

aws logs put-retention-policy \
  --log-group-name /aws/lambda/patient-api \
  --retention-in-days 7

# Saved $12/month on log storage

🚨 The Mistakes We Made (So You Don't Have To)

📈 The Results: 6 Months Later

Unexpected Benefits:

• ✅ Developer productivity: Deployments went from 30 minutes to 30 seconds
• ✅ No more maintenance windows: Zero-downtime deployments
• ✅ Better monitoring: Lambda's built-in metrics are superior
• ✅ Compliance: Easier HIPAA compliance with serverless
• ✅ Team morale: Developers love not managing servers

📋 Your 30-Day Migration Checklist

🔑 Key Takeaways

🚀 Ready to Cut Your AWS Costs?

❓ FAQ

Q: How long did the migration really take?

6 weeks total: 2 weeks planning, 3 weeks migration, 1 week optimization. Could have been 4 weeks if we hadn't made the VPC mistake.

Q: What about vendor lock-in?

Yes, we're more locked into AWS now. But we're saving $4,968/year. That buys a lot of migration budget if needed.

Q: Did anything break during migration?

One pagination endpoint had a bug for 2 hours. That's it. The dual-write strategy prevented data issues.

Q: Is serverless always cheaper?

No. If CPU usage is consistently > 60%, EC2 might be cheaper. But that's rare - we've seen it in only 15% of applications.

Q: What about cold starts?

They affect < 1% of requests and add 1.2 seconds. For a 85% cost savings, the client gladly accepted this tradeoff.