u/FamousRun538

I've spent a fair amount of time working with AWS and Azure in enterprise environments, including looking at cloud infrastructure from both the architecture and cost-optimization side.

One thing that keeps bothering me:

Despite all the native recommendations and FinOps tools available today, there still seems to be a huge amount of cloud spend that could be optimized.

And I'm not convinced the problem is simply a lack of visibility.

We already have things like Azure Advisor, AWS Compute Optimizer, Cost Management, Cost Optimization Hub, Reservations/Savings Plans, and a long list of commercial FinOps platforms.

So I'm starting to think about building an open-source GitHub repository focused specifically on actionable cloud cost optimization.

But before I decide what to build, I want to start with a simple question:

If you could have one tool deeply analyze your Azure environment, what would you want it to optimize?

Would it be:

Compute / VM rightsizing?

Managed disks and storage?

Databases?

Network / egress?

Kubernetes?

Reservations / Savings Plans?

Idle resources?

Storage tiers?

Non-prod scheduling?

Something much more specific?

And for those already using Azure Advisor or other FinOps tools:

What do you feel they get wrong, miss, or make difficult to act on?

I wish I had a subscription to these to understand gaps 3rd party FinOps tool have.

I'm particularly interested in the gap between:

"The tool says you could save $X"

and

"Here's why you can actually save $X safely in this specific workload."

I don't want to build another dashboard full of recommendations.

I'd like to build something where the community can contribute optimization rules, workload signals and validation logic over time.

So if you could wave a magic wand and eliminate one category of cloud waste from your environment, what would it be?

I'm going to use the responses here to decide what the first version of the GitHub project should actually solve.

This is another post where I feel learning goes across boundry and to learn cloud you must learn few differences across major CSPs

I’ve spent a fair amount of time with AWS as Cloud Support Engineer before transitioning to Solutions Architect role, and when I started working at Microsoft Azure, the confusing part wasn't the services.

EC2 → Azure VM

S3 → Blob Storage

VPC → VNet

Those are easy.

The real difference is how Azure organizes the cloud.

The mental model I use now is:

AWS Organization

↓

Organizational Units

↓

AWS Accounts

↓

Resources

versus

Azure

Microsoft Entra Tenant

↓

Management Groups

↓

Subscriptions

↓

Resource Groups

↓

Resources

Microsoft's own AWS-to-Azure guidance describes subscriptions as broadly analogous to AWS accounts, while Azure adds the resource-group layer as a fundamental organizational unit.

And this creates some interesting differences.

1. AWS Account ≈ Azure Subscription

This is probably the most important translation.

An AWS account is a strong boundary for things like billing, permissions and isolation.

An Azure subscription plays a similar role: billing, quotas, access and resource boundaries.

But Azure doesn't stop there.

You can have:

Subscription

├── Resource Group A

│

├── VM │

├── Disk │

└── NIC

│

├── Resource Group B

│

├── Storage Account

│

└── App Service

And RBAC can be inherited down the hierarchy.

2. Azure Resource Groups are much more important than AWS Resource Groups

This was probably my biggest conceptual adjustment.

In AWS, resource groups are primarily an organizational mechanism.

In Azure, a resource must belong to a resource group, and the resource group becomes an actual management boundary.

And deleting an Azure resource group deletes the resources inside it. That's very different from how AWS resource groups work.

3. Azure is much more hierarchical

This is probably the easiest way I'd describe the philosophical difference:

AWS tends to make the Account the big boundary.

Azure gives you several hierarchical scopes.

Management Group, Subscription, Resource Group, Resource

You can apply policy/RBAC at different levels and let it inherit downward.

So instead of thinking:

"Which AWS account is this resource in?"

you often end up thinking:

"At which Azure scope should this policy or permission apply?"

4. IAM feels different because the hierarchy is different

Azure RBAC can be assigned at management-group, subscription, resource-group or resource scope.

This is also why someone coming from AWS can initially find Azure permissions either much easier or much more confusing, depending on what they're used to.

5. Don't map AWS Organization = Azure Tenant too literally

This is where a lot of AWS → Azure comparison diagrams become misleading.

The tenant is primarily an identity boundary in Azure.

Management Groups are closer to the organizational/governance hierarchy.

So I'd mentally keep:

AWS Organization ≈ Azure Management Groups + Tenant context AWS Account ≈ Azure Subscription AWS resource grouping/tags ≠ Azure Resource Group

The equivalence isn't perfect; the two clouds evolved their resource models independently. Microsoft explicitly calls out these organizational differences in its AWS-professional guidance.

The funny thing is that once this clicks, Azure becomes much easier to understand.

Instead of learning 100 Azure services individually, first understand:

Tenant → Management Group → Subscription → Resource Group → Resource

Then start putting services inside that model.

That's the Azure mental model I wish someone had explained to me when I first started comparing it with AWS.