AWS vs Azure vs Google Cloud: What 3 Years of Multi-Cloud Architecture Taught Me About Choosing the Right Provider

Last year, my team at a mid-sized SaaS company made what seemed like a straightforward decision: migrate our monolithic application from AWS to a multi-cloud architecture spanning AWS, Azure, and Google Cloud. We thought we'd gain redundancy, avoid vendor lock-in, and optimize costs by cherry-picking the best services from each provider.

Eighteen months and $240k in cloud spend later, I can tell you that choosing a cloud provider is one of the most consequential technical decisions you'll make—and almost nobody gets it right the first time.

Here's the thing: every comparison article you've read probably lists features, pricing tiers, and service counts. That's not useless, but it's also not how you actually make this decision in production. When you're running 50 million requests per day, serving users across six continents, and debugging why your Kubernetes pods are getting OOM-killed at 3 AM, you care about completely different things than what the marketing pages show you.

I'm going to share what we learned the hard way. This isn't a feature checklist—it's a battle-tested guide based on real production workloads, actual cost breakdowns, and the kind of gotchas that only surface when you're running serious traffic. I'll show you our benchmarks, explain why we chose specific services from each provider, and be brutally honest about where each platform falls short.

By the end of this post, you'll understand not just which provider to choose, but how to make that decision based on your specific workload, team expertise, and business constraints. Because here's what I've learned: there's no universally "best" cloud provider. There's only the right provider for your specific situation.

The Real Question Nobody Asks: What Are You Actually Optimizing For?

Before I dive into the technical comparison, let me save you from the mistake we made initially. We spent three weeks comparing compute pricing, storage costs, and egress fees. We built elaborate spreadsheets. We ran POCs on all three platforms.

And we completely missed the most important question: What are we actually optimizing for?

Our CTO, Sarah, finally asked this during a heated architecture review meeting. "Are we optimizing for cost, developer velocity, operational simplicity, or something else?" The room went silent. We'd been so focused on technical details that we hadn't aligned on our actual business constraints.

Here's what we eventually figured out matters most when choosing a cloud provider:

Developer Velocity: How fast can your team ship features? This includes learning curve, documentation quality, SDK maturity, and local development experience. We measured this by tracking how long it took new engineers to deploy their first production change. On AWS, it averaged 8 days. On GCP, 5 days. On Azure, 12 days.

Operational Complexity: How much time do you spend keeping the lights on versus building new features? We tracked this through our PagerDuty metrics and on-call burden. AWS required about 15 hours/week of DevOps time. GCP needed 10 hours. Azure demanded 20 hours.

Total Cost of Ownership: Not just the cloud bill, but engineering time, training costs, and opportunity cost of complexity. Our monthly AWS bill was $42k, but when we factored in engineering time at $150/hour, our true cost was closer to $52k/month.

Vendor Lock-In Risk: How painful would it be to migrate away? We learned this the hard way when we tried to move a Lambda-heavy application off AWS. It took six months and cost us $180k in engineering time.

Ecosystem and Integrations: What third-party tools work well with each provider? For us, this was huge—our monitoring (Datadog), CI/CD (GitHub Actions), and security scanning (Snyk) all had first-class AWS support, decent GCP support, and mediocre Azure support.

Let me break down each provider through these lenses, starting with where we began: AWS.

AWS: The 800-Pound Gorilla (And Why We Still Use It for 60% of Our Infrastructure)

We started on AWS in 2019 because, frankly, that's what everyone used. Our first architecture was pretty standard: EC2 instances behind an Application Load Balancer, RDS PostgreSQL, ElastiCache Redis, and S3 for object storage. Nothing fancy.

Then we scaled. And that's when AWS both shined and showed its rough edges.

What AWS Gets Right: Maturity and Breadth

AWS has been around since 2006, and it shows. When you need to do something—anything—there's probably an AWS service for it. Need to transcode video? There's MediaConvert. Need to run machine learning inference at the edge? There's Greengrass. Need to... honestly, I've lost count of AWS services. Last I checked, there were over 200.

This breadth is both AWS's greatest strength and its biggest weakness. Let me explain with a real example.

Last quarter, we needed to implement a job queue for processing user uploads. On AWS, we had multiple options:

1. SQS (Simple Queue Service): Dead simple, fully managed, cheap. We went with this initially.
2. Amazon MQ: Managed RabbitMQ or ActiveMQ if you need more advanced features.
3. EventBridge: Event-driven architecture with routing rules.
4. Kinesis: For streaming data at massive scale.
5. Step Functions: For orchestrating complex workflows.

We chose SQS because it was the simplest option. Here's what our implementation looked like:

import boto3
import json

sqs = boto3.client('sqs', region_name='us-east-1')
queue_url = 'https://sqs.us-east-1.amazonaws.com/123456789/upload-processing'

def enqueue_upload(user_id, file_key, file_size):
    message = {
        'user_id': user_id,
        'file_key': file_key,
        'file_size': file_size,
        'timestamp': datetime.utcnow().isoformat()
    }
    
    response = sqs.send_message(
        QueueUrl=queue_url,
        MessageBody=json.dumps(message),
        MessageAttributes={
            'Priority': {
                'StringValue': 'high' if file_size > 100_000_000 else 'normal',
                'DataType': 'String'
            }
        }
    )
    
    return response['MessageId']

This worked great... until we hit about 50,000 uploads per day. Then we discovered SQS's quirks:

Gotcha #1: Message Visibility Timeout When a consumer picks up a message, it becomes invisible to other consumers for a configurable timeout (default 30 seconds). If your processing takes longer and you don't extend the timeout, the message becomes visible again and another consumer might pick it up. We had duplicate processing for about 2% of our uploads before we figured this out.

The fix:

import time

def process_upload_with_visibility_extension(message, receipt_handle):
    start_time = time.time()
    
    while True:
        # Do some processing
        process_chunk()
        
        # If we've been processing for more than 20 seconds, extend visibility
        if time.time() - start_time > 20:
            sqs.change_message_visibility(
                QueueUrl=queue_url,
                ReceiptHandle=receipt_handle,
                VisibilityTimeout=30  # Extend by another 30 seconds
            )
            start_time = time.time()
        
        if processing_complete:
            break
    
    # Delete message when done
    sqs.delete_message(QueueUrl=queue_url, ReceiptHandle=receipt_handle)

Gotcha #2: Message Size Limits SQS has a 256KB message size limit. We hit this when trying to include thumbnail data in our messages. The workaround is to store the payload in S3 and pass a reference:

def enqueue_large_upload(user_id, file_key, metadata):
    # Store large metadata in S3
    s3_key = f"queue-payloads/{uuid.uuid4()}.json"
    s3.put_object(
        Bucket='my-queue-payloads',
        Key=s3_key,
        Body=json.dumps(metadata)
    )
    
    # Send S3 reference through SQS
    message = {
        'user_id': user_id,
        'file_key': file_key,
        'payload_s3_key': s3_key
    }
    
    sqs.send_message(QueueUrl=queue_url, MessageBody=json.dumps(message))

This pattern of "use S3 as extended storage" comes up constantly in AWS. It works, but it adds complexity and cost (S3 PUT requests aren't free).

AWS Pricing: Death by a Thousand Cuts

Here's our actual AWS bill breakdown for November 2024 (we were running about 45M requests/day):

• EC2 Compute: $18,400 (mix of t3.large, c5.xlarge, r5.large instances)
• RDS PostgreSQL: $8,200 (db.r5.2xlarge Multi-AZ with 2TB storage)
• ElastiCache Redis: $3,600 (cache.r5.large cluster mode)
• Application Load Balancer: $1,800 (2 ALBs + LCU charges)
• S3 Storage: $2,400 (8TB of data + 200M requests)
• Data Transfer: $4,800 (this was the killer—1.2TB egress)
• CloudWatch Logs: $1,200 (we log everything)
• NAT Gateway: $900 (3 NAT gateways across AZs)
• Route53: $200 (DNS queries)
• Misc (KMS, Secrets Manager, etc.): $1,500

Total: $43,000/month

The thing that shocked us was data transfer. AWS charges $0.09/GB for data transfer out to the internet. When you're serving images, videos, and API responses to users worldwide, this adds up fast. We were transferring about 1.2TB/month, which cost us nearly $5,000.

We eventually put CloudFront (AWS's CDN) in front of our S3 buckets, which reduced our egress from S3 to CloudFront to $0.02/GB (internal AWS transfer). This saved us about $2,800/month. But it took us four months to realize we should do this.

Here's the CloudFront config that saved us money:

# CloudFormation template for our CloudFront distribution
Resources:
  MyCloudFrontDistribution:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        Origins:
          - DomainName: !GetAtt MyS3Bucket.DomainName
            Id: S3Origin
            S3OriginConfig:
              OriginAccessIdentity: !Sub 'origin-access-identity/cloudfront/${CloudFrontOAI}'
        DefaultCacheBehavior:
          TargetOriginId: S3Origin
          ViewerProtocolPolicy: redirect-to-https
          AllowedMethods: [GET, HEAD, OPTIONS]
          CachedMethods: [GET, HEAD]
          ForwardedValues:
            QueryString: false
            Cookies:
              Forward: none
          MinTTL: 86400  # Cache for 24 hours minimum
          DefaultTTL: 604800  # Default 7 days
          MaxTTL: 31536000  # Max 1 year
          Compress: true
        PriceClass: PriceClass_100  # Use only US/Europe edge locations (cheaper)
        Enabled: true

The PriceClass_100 setting was key—it uses only North America and Europe edge locations instead of global, which cut our CloudFront costs by 40%.

AWS Lambda: Serverless Done Right (Mostly)

We use Lambda extensively for background jobs, API endpoints, and event processing. It's genuinely great for many use cases, but it's also where we've had some of our worst production incidents.

Here's a Lambda function we use to resize images when they're uploaded to S3:

import boto3
import os
from PIL import Image
import io

s3 = boto3.client('s3')

def lambda_handler(event, context):
    # Get the uploaded file info from the S3 event
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    # Download the image
    response = s3.get_object(Bucket=bucket, Key=key)
    image_data = response['Body'].read()
    
    # Resize
    image = Image.open(io.BytesIO(image_data))
    image.thumbnail((800, 800))
    
    # Upload thumbnail
    buffer = io.BytesIO()
    image.save(buffer, format='JPEG')
    buffer.seek(0)
    
    thumbnail_key = key.replace('uploads/', 'thumbnails/')
    s3.put_object(
        Bucket=bucket,
        Key=thumbnail_key,
        Body=buffer,
        ContentType='image/jpeg'
    )
    
    return {'statusCode': 200}

This worked perfectly in testing. Then we deployed to production and immediately hit Lambda cold starts. The first invocation after a period of inactivity would take 3-5 seconds because AWS had to spin up a new container, load our code, and initialize the PIL library.

Our users were uploading images and waiting 5 seconds to see their thumbnails. Not acceptable.

We tried several solutions:

1. Provisioned Concurrency: Keep Lambda containers warm. This worked but cost us $150/month extra for just this one function.

2. Smaller deployment packages: We switched from PIL to pillow-simd and reduced our package from 50MB to 15MB. Cold starts dropped to 1-2 seconds.

3. Warming pings: We set up CloudWatch Events to invoke our Lambda every 5 minutes to keep it warm. This felt hacky but worked.

Here's the CloudWatch Event rule:

Resources:
  LambdaWarmingRule:
    Type: AWS::Events::Rule
    Properties:
      ScheduleExpression: rate(5 minutes)
      State: ENABLED
      Targets:
        - Arn: !GetAtt ImageResizeFunction.Arn
          Id: WarmingTarget
          Input: '{"warming": true}'

And we modified our Lambda to detect warming pings:

def lambda_handler(event, context):
    # Ignore warming pings
    if event.get('warming'):
        return {'statusCode': 200, 'body': 'warmed'}
    
    # Normal processing...

The Real Lambda Gotcha: Memory = CPU

This took us forever to figure out. In Lambda, you configure memory (128MB to 10GB), but AWS doesn't let you configure CPU directly. Instead, CPU allocation scales linearly with memory. At 1,792MB, you get one full vCPU. Below that, you get a fraction.

We had a Lambda function that did CPU-intensive video processing. It was configured with 512MB of memory and was taking 45 seconds to process a 30-second video. We bumped it to 3GB (roughly 2 vCPUs) and processing dropped to 8 seconds.

The cost increase was minimal because Lambda charges by GB-second. We went from:

• 512MB × 45 seconds = 23,040 MB-seconds
• 3,072MB × 8 seconds = 24,576 MB-seconds

Slightly more expensive, but 5.6x faster. Worth it.

AWS RDS: Managed Databases with Surprising Limitations

We run PostgreSQL on RDS, and for the most part, it's been solid. Multi-AZ failover works as advertised (we've had two unplanned failovers in three years, both completed in under 60 seconds). Automated backups are reliable. Performance Insights helped us identify slow queries.