The cloud comparison chart lied to you (a little)

Shane — Fri, 17 Jul 2026 08:43:10 +0000

Every "AWS to Azure to GCP" cheat sheet does the same thing: it gives you a table. S3 equals Blob Storage. EC2 equals Compute Engine. Done, ship it.

Except it's not done. The table tells you where to start, not where you'll get burned.

Where it actually breaks

Take storage. S3 is flat: bucket, then objects. Azure inserts a Storage Account above the container, and that account is where networking rules, access keys, and replication settings actually live. Port an S3-shaped Terraform module over without accounting for that layer, and you'll spend an afternoon figuring out why your access policies don't apply where you expect.

Or take networking. An AWS VPC is regional. A GCP VPC is global by default. "Just create a VPC" means two completely different blast radii depending on which cloud you're standing in.

The one that actually matters for security people: aws_iam_role doesn't map to an Azure resource at all. Azure's permission model is structurally different, role assignments work differently, service principals aren't IAM roles wearing a different name. Treating them as equivalent is where real misconfigurations come from, not typos.

Why I built Cloud Rosetta

I work in cloud infrastructure day to day, and I kept hitting these gaps mid-project, usually the expensive way. So I built a dictionary that does what the comparison charts don't: for each concept, it names the equivalent across AWS, Azure, and GCP, explains specifically where the analogy breaks, and links the actual Terraform resource for each provider so you can go verify instead of trusting me.

It's a single self-contained HTML file, no tracker, works offline, and the dictionary itself is open to PRs, especially from people with production scars on whichever cloud is the "minority" one in a given entry.

Live site: https://edeak54.github.io/cloud-rosetta/
Source: https://github.com/edeak54/cloud-rosetta

If you've been burned by an analogy that didn't hold, open an issue, that's exactly the kind of entry this needs more of.

Decoupling & Securing Web App Storage: Building a Zero-Trust S3 Perimeter with Terraform

Shane — Fri, 10 Jul 2026 08:31:54 +0000

When hosting a scalable, multi-AZ 3-tier web application (like WordPress), storing media files locally on the EC2 instances is an architectural dead end. The moment your auto-scaler destroys an instance, your user uploads vanish.

The standard fix is offloading media to Amazon S3. But this introduces a massive security risk: if your instance profile or an IAM key leaks, your entire storage layer is exposed to the public internet.

The Security Risk: If your instance profile or an IAM key leaks, your entire storage layer is exposed to the public internet. IAM permissions alone are often not enough for high-stakes production data.

In this post, we’ll build a production-ready, highly available media storage layer that implements a Zero-Trust Network Perimeter around S3 using Terraform. Even if someone steals your IAM credentials, they cannot access the data unless they are sitting inside your private VPC.

The Strategy: Network-Level Isolation

Instead of relying solely on identity (who is asking?), we enforce network-level isolation (where are they asking from?). Even if someone steals your IAM credentials, they cannot access the data unless they are sitting inside your specific VPC.

1. The Infrastructure

A highly available network across multiple Availability Zones (AZs) with isolated private subnets where our application servers live.

2. The Gateway

An AWS VPC Endpoint (S3 Gateway) configured inside our route tables so traffic to S3 never traverses the public internet.

3. The Lock

A restrictive S3 Bucket Policy that explicitly denies any API calls (s3:GetObject, s3:PutObject) unless the request originates from our specific VPC Endpoint ID.

## Create the VPC Endpoint for S3 ##
resource "aws_vpc_endpoint" "s3" {
  vpc_id       = var.vpc_id
  service_name = "com.amazonaws.${var.aws_region}.s3"
  vpc_endpoint_type = "Gateway"

  route_table_ids = var.private_route_table_ids

  tags = {
    Name = "s3-gateway-endpoint"
  }
}

## Enforce the Zero-Trust Bucket Policy ##
resource "aws_s3_bucket_policy" "secure_perimeter" {
  bucket = aws_s3_bucket.media_assets.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "AccessFromVpceOnly"
        Effect    = "Deny"
        Principal = "*"
        Action    = "s3:*"
        Resource = [
          aws_s3_bucket.media_assets.arn,
          "${aws_s3_bucket.media_assets.arn}/*"
        ]
        Condition = {
          StringNotEquals = {
            "aws:sourceVpce" = aws_vpc_endpoint.s3.id
          }
        }
      }
    ]
  })
}

When implementing this pattern, there is a common sequencing trap that trips up engineering teams.

If you apply this strict bucket policy before your application servers are fully configured or before your CI/CD runner is granted a specific exception, you will instantly lock yourself out of your own bucket. The Deny block in AWS is absolute.

Always verify your VPC Endpoint route tables are fully propagated before attaching the explicit network deny statement to the bucket policy.

Conclusion

By shifting our security model from identity-only to identity + network perimeter, we eliminate entire classes of credential-theft attacks. It doesn't matter if an attacker finds an exposed AWS key on GitHub—if they aren't executing code from within your specific VPC subnets, the data remains dark.

DEV Community: Shane