Azure Fundamentals

Concept Overview A resource group's practical value shows up in three places. First, lifecycle management: a staging environment made of a VM, a database, and a storage account can be torn down completely with one az group delete, rather than remembering and deleting each piece individually -- and forgetting one of them, which is how orphaned resources quietly accumulate cost. Second, access control: granting a contractor or a CI pipeline access to exactly one resource group, rather than the whole subscription, limits the blast radius of a compromised credential to just that application's infrastructure. Third, cost visibility: Azure Cost Management can filter spend by resource group, making 'how much is the staging environment costing us this month' a direct query rather than a manual reconciliation exercise.

A common mistake for teams new to Azure is putting everything into one giant resource group, which works at small scale but makes it impossible to tear down just one application's environment without affecting others, and makes cost attribution require tags instead of group-level filtering. The general guideline is one resource group per application per environment -- myapp-production-rg, myapp-staging-rg -- rather than one per resource type or one for an entire organization.

Internal Working

• Moving a resource between resource groups is supported for most resource types via az resource move, but not universal -- some resource types (certain networking resources, for instance) can't be moved and must be recreated in the target group.
• Resource groups themselves don't incur direct cost -- cost is attached to the resources inside them -- but a resource group left behind with forgotten resources inside is the classic source of a surprise bill.
• az group list --query "[?tags.environment=='staging']" is a typical pattern for finding every resource group matching a particular tag, useful once a subscription has accumulated many groups.
• Azure Policy can be scoped to a resource group to enforce rules (like 'no VM larger than a certain size') on exactly the applications that need that constraint, without applying it subscription-wide.

Why It Matters Treating the resource group as the real unit of application lifecycle -- not the individual VM or database -- is what keeps a growing Azure footprint tidy, auditable, and cheap to tear down when something is no longer needed.

Concept Overview For anyone who already has AWS experience, the fastest way to get oriented in Azure is a direct service-to-service comparison -- the underlying cloud computing concepts (virtual machines, object storage, managed databases, identity) are the same, and most of the learning curve is really just new names and a different console layout rather than genuinely new ideas. A few areas are worth calling out specifically: Azure's compute PaaS offering (App Service) is more prominent and more commonly reached-for in Azure-centric teams than Elastic Beanstalk tends to be in AWS-centric ones. Azure Active Directory (now branded Microsoft Entra ID) is more deeply integrated into enterprise identity than IAM typically is, because so many organizations already run Windows/Active Directory environments that Entra ID extends into the cloud.

Internal Working

• The naming is not always a perfect one-to-one match in scope -- Azure Blob Storage's tiers map closely to S3 storage classes, but Azure Resource Manager templates and AWS CloudFormation, while conceptually equivalent, have meaningfully different syntax and object models.
• Networking concepts transfer almost directly: an Azure Virtual Network (VNet) is a VPC, an Azure Network Security Group is a Security Group, and Azure Load Balancer / Application Gateway split the same way ELB / ALB do in AWS.
• Azure Cosmos DB doesn't have a single clean AWS equivalent -- it overlaps with DynamoDB for key-value workloads but also supports document, graph, and column-family APIs in one service, which is a genuinely different design point worth understanding on its own rather than purely by analogy.
• Pricing models, free-tier limits, and regional availability differ enough between the two providers that the comparison is a starting orientation, not a substitute for checking each service's actual current documentation before an architecture decision.

Why It Matters This comparison table collapses most of the initial 'which Azure service do I even want' confusion for anyone coming from AWS, turning what would otherwise be a slow service-by-service discovery process into a quick lookup.