Getting Started with AWS When You Already Know Azure

TLDR

Moving from Azure to AWS isn't hard — it's disorienting. The concepts map, but the defaults, naming, and mental models are different enough to trip you up. Expect a week of confusion, then rapid progress. Tag everything from day one, set up billing alerts immediately, and stop looking for resource groups.

I've been teaching Azure for years. I hold multiple Microsoft certifications, I'm an MCT, and I've trained hundreds of students on Azure infrastructure. I earned my AWS Cloud Practitioner certification back in 2020, so I'm not new to AWS — but Azure has always been my primary platform. When I decided to go deeper on AWS and start producing content about both platforms, I assumed the transition would be smooth.

It wasn't.

Not because AWS is harder — it's not. But because my Azure muscle memory kept getting in the way. Things that should have been straightforward took longer because I kept reaching for the "Azure equivalent" instead of working with AWS on its own terms.

Here's what the experience actually looked like.

The Console Is a Different Philosophy

The first thing you notice opening the AWS Management Console is that it feels... different. Azure's portal is designed like an enterprise admin tool — everything is grouped by resource groups, there's a unified search, and Entra ID sits at the top of everything.

AWS feels more like a service catalogue. Each service has its own console, its own navigation, its own personality. There's no "resource group" concept forcing everything together. Resources exist independently, and you tie them together through IAM policies and tags.

This threw me off for about a week. I kept looking for a resource group to put things in. In AWS, you just... create things. Tags become your organizational tool, and if you don't tag from day one, you'll regret it by month two.

My advice: Set up a tagging strategy before you create your first resource. Seriously. Environment, Project, Owner at minimum.

Pro Tip

Create a tagging policy on day one with at least Environment, Project, and Owner tags. AWS Resource Groups let you find and manage resources by tag — without tags, you'll be scrolling through unorganised lists by month two.

Identity: Where the Real Culture Shock Hits

In Azure, identity starts with Entra ID (formerly Azure AD). You have a tenant, you have users, you assign RBAC roles. It makes sense if you come from an Active Directory background, which most Azure admins do.

AWS IAM is a completely different animal.

There's no tenant concept. There's no directory sitting on top. Instead, you have an AWS account that acts as both your billing boundary AND your security boundary. Users, groups, and roles all exist within that account, and permissions are granted through JSON policy documents.

The first time I saw an AWS IAM policy, I stared at it for a solid five minutes:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Coming from Azure RBAC where you assign a pre-built role to a scope, writing explicit JSON policies felt like going from a GUI to a command line. More control, but more rope to hang yourself with.

The mental model shift: Azure thinks in "who has what role on what scope." AWS thinks in "what actions are allowed on what resources by what principal." Same destination, different routes.

If you're making this same jump, I'd recommend spending time in CloudLearn's AWS IAM labs where you can break things safely. IAM is the foundation of everything in AWS, and getting it wrong early means pain later.

Regions and Availability Zones: Mostly the Same, Subtly Different

Both platforms have regions and availability zones, and the concepts map pretty directly. But there are subtle differences that caught me:

AWS regions are opt-in by default for newer regions. In Azure, most regions are available automatically. In AWS, you might need to explicitly enable a region before you can use it.
AWS has more regions. As of late 2025, AWS has 30+ regions compared to Azure's 60+ — but AWS regions tend to have more services available per region.
The naming conventions are different. Azure uses friendly names ("East US", "UK South"). AWS uses codes ("us-east-1", "eu-west-2"). I actually prefer the AWS approach — less ambiguous.

One thing AWS does better: CloudShell is available everywhere and it just works. Azure Cloud Shell requires a storage account, which always felt unnecessarily complicated for what's essentially a browser-based terminal.

The Billing Dashboard Moment

About two weeks in, I checked my billing dashboard. Even though I was trying to stay within the free tier, I had already accumulated $4.37 in charges. Nothing dramatic, but it was a wake-up call.

The charges came from:

An Elastic IP I allocated but didn't attach to a running instance ($0.005/hour adds up)
NAT Gateway running in a VPC I set up for testing ($0.045/hour — nearly $33/month if you forget about it)
CloudWatch log storage from all the default logging

In Azure, I know exactly where the cost traps are. In AWS, I was rediscovering them in a fresh account.

Warning

Set up billing alerts before you create your first resource. Go to AWS Budgets, create a zero-spend budget for the free tier, and attach SNS notifications. NAT Gateways alone cost ~$33/month just to exist — and the VPC wizard creates them by default.

CloudFormation vs ARM Templates: Familiar Pain

AWS CloudFormation is their infrastructure-as-code service, and if you've written ARM templates in Azure, you'll feel right at home — in the sense that you'll feel the same frustration with verbose JSON/YAML templates.

Both platforms have this in common: the native IaC tooling works but isn't fun to write. This is exactly why Terraform became the industry standard for multi-cloud teams.

That said, CloudFormation has one genuinely nice feature: drift detection. You can check if someone manually changed a resource that CloudFormation manages. Azure... doesn't really have an equivalent for ARM templates. Bicep is better, but drift detection remains a gap.

What's Genuinely Better in AWS

I want to be honest about this, even as someone who teaches Azure for a living:

S3 is easier to use than Azure Blob Storage. The API is simpler, the console experience is cleaner, and storage classes are more straightforward.
The documentation is better. AWS docs are more consistent, have more examples, and are easier to navigate. Microsoft Learn is great for structured learning, but AWS docs win for "I need to figure out this one thing right now."
Lambda is more mature than Azure Functions. More language support, better cold start times, and the ecosystem around it (SAM, CDK) is more developed.
Global infrastructure options. CloudFront + S3 static hosting is simpler to set up than Azure CDN + Blob Storage static websites.

What Azure Does Better (After Seeing the Other Side)

And the reverse is true too:

Entra ID is a proper identity platform. AWS IAM is powerful but it's not a directory service. If you need enterprise identity management, Azure's approach is still miles ahead.
Resource groups are underrated. The ability to group all resources for a project and manage lifecycle, RBAC, and cost together is something I miss in AWS.
Azure DevOps is more integrated than CodePipeline/CodeBuild/CodeDeploy (which feel like three separate products duct-taped together).
Hybrid cloud with Azure Arc is genuinely better than AWS's hybrid story.

The Things Nobody Tells You About Switching

Your muscle memory is wrong. You'll keep reaching for Azure concepts that don't exist in AWS. Let go of resource groups. Let go of Entra ID being the centre of the universe. AWS has its own centres of gravity.
Multi-account strategy is essential in AWS. In Azure, you use subscriptions and management groups. In AWS, the equivalent is AWS Organizations with multiple accounts. This isn't optional for production — it's how AWS is designed to work.
The community is massive. AWS re:Invent videos, AWS blogs, community forums, r/aws on Reddit — the volume of community content is enormous. Use it.
Certifications transfer faster than you think. If you know AZ-104 concepts, the AWS Cloud Practitioner will feel like a review. The Solutions Architect Associate maps closely to AZ-305. Your Azure knowledge is an asset, not a limitation.

What I'm Doing Next

I'm going to keep sharing what I find as I go deeper. Over the coming months, I'll be diving into specific AWS services — IAM policies, S3 patterns, VPC networking, CloudWatch monitoring — and writing practitioner-level comparisons. Working across both platforms gives me a perspective that I think is useful for the growing number of engineers who need to be multi-cloud.

The cloud industry is increasingly multi-cloud whether we like it or not. Being a single-cloud specialist isn't enough anymore.

If you're an Azure engineer thinking about expanding to AWS — just start. The first week feels disorienting, the second week things start clicking, and within a few weeks you'll wonder why you didn't do this sooner.

Resource

Next: AWS IAM for Azure Admins

Deep dive into the service that confuses every Azure engineer — IAM policies, roles, and the mental model shifts.