A finance director sits in a meeting where one team talks about "moving the S3 buckets" and another about "the Blob containers in the media subscription". It sounds like two different worlds. In practice both teams are describing the same idea: cheap, durable storage for files, reached over the internet with access controls. The words are different because two companies built similar products independently and named them differently.
A large share of cloud confusion in leadership conversations is vocabulary of this kind. It matters, because people who cannot follow the vocabulary cannot challenge the decisions made in it. It also hides something more useful: the places where Amazon Web Services and Microsoft Azure really are different, which are fewer than the jargon suggests and more important than most service comparisons admit.
CloudNala's view is that leaders should learn the handful of shared ideas once, in plain language, then spend their attention on the genuine differences: how each platform organises accounts, identity, billing and governance. That is where migrations, mergers and multicloud plans succeed or stall.
This is Part 1 of Cloud in Plain English, a short series for South African decision-makers who need to understand cloud choices without vendor slogans.
The running example
Nyala Media is fictional, and its systems and figures are illustrative. Nyala is a Johannesburg digital publisher with a news site, a video platform and an advertising business. Its website and video platform have run on AWS for several years. Its staff use Microsoft 365, so its identity directory already lives in Microsoft Entra ID. Nyala has just agreed to buy a podcast studio whose small platform runs on Azure.
At the first integration meeting, Nyala's chief executive asked a reasonable question: are we now running two of everything? The honest answer was "partly, and less than it sounds". Getting there needed a translation table.
Eight ideas, two vocabularies
Microsoft publishes a comparison of AWS and Azure services for exactly this purpose, last updated in September 2026. It is careful to say the services are "roughly comparable" and that matched services do not have feature-for-feature parity. With that caution, the core ideas line up like this.
In plain language:
Virtual machines are computers you rent by the hour or second. AWS calls them EC2 instances; Azure calls them Virtual Machines. You choose the size, install software and are responsible for patching what runs on them.
Object storage holds files of any kind (images, video, backups, documents) at low cost and very high durability. Amazon S3 and Azure Blob Storage are the respective services. Files sit in "buckets" on AWS and "containers" inside a storage account on Azure.
A private network is your own address space inside the cloud, divided into subnets, with rules about what may talk to what. AWS calls it a VPC (Virtual Private Cloud); Azure calls it a VNet (Virtual Network). Our Cloud Networking 101 series explains both in depth.
Functions run small pieces of code in response to events, without you managing a server. AWS Lambda and Azure Functions do this, and both charge mainly by the number of executions and the compute time they use.
Managed Kubernetes runs containerised applications on a cluster the provider partly manages: Amazon EKS and Azure Kubernetes Service (AKS).
Identity and access decides who and what may do which actions. This is where the mapping starts to bend, as the next section explains.
DNS turns names such as nyala.example into addresses: Amazon Route 53 and Azure DNS.
Monitoring and tracing collects metrics, logs and traces: on AWS, typically CloudWatch together with X-Ray; on Azure, Azure Monitor, including Application Insights.
For Nyala's leadership, this table removed most of the alarm. The podcast platform used the same handful of ideas as the news site. Moving it, or running it alongside, was a decision about cost, skills and contracts, not about learning a new kind of technology.
Where the platforms genuinely differ
The services map closely. The containers around them do not. This is the part of the comparison that most service tables skip, and it is the part that decides how hard a merger, migration or multicloud operation will be.
Accounts and subscriptions. On AWS, the account is the main boundary for permissions and billing. Larger organisations group accounts under AWS Organizations, arranged into organisational units. On Azure, the equivalent boundary is the subscription, and subscriptions are grouped into management groups. Microsoft's own guidance says subscriptions are "similar to AWS accounts", which is a fair starting point.
Resource groups. Azure adds a layer AWS does not have as a mandatory concept. Every deployed Azure resource, such as a virtual machine or storage account, must belong to exactly one resource group, a container that usually holds everything belonging to one application or environment. Teams often use resource groups to apply permissions, policies and deletion as a unit. On AWS, resources are commonly grouped with tags instead, which is more flexible and easier to get inconsistent.
Identity. On AWS, IAM (and IAM Identity Center for people signing in across accounts) is part of the platform. On Azure, identity lives in a Microsoft Entra ID tenant, the same directory that usually serves Microsoft 365, and permissions on Azure resources are granted through Azure role-based access control (RBAC). For an organisation like Nyala, whose staff already sign in through Entra ID, that makes Azure access easy to tie to existing joiner and leaver processes. It also means a mistake in the Microsoft 365 directory can affect cloud access, which raises the importance of protecting that tenant.
Governance tooling. Both platforms let you enforce rules across many accounts or subscriptions: AWS through features such as service control policies and AWS Config, Azure through Azure Policy. The ideas are similar; the policy languages, defaults and reporting are not. Policies do not translate automatically from one to the other.
Infrastructure as code. AWS CloudFormation and the AWS CDK on one side; Azure Resource Manager templates and Bicep on the other. Both clouds also support widely used third-party tools such as Terraform. Native templates are not portable between clouds, so the choice of tooling affects how hard a later move will be.
What this meant for Nyala
The vocabulary table answered "are we running two of everything?" The organising differences answered "what will actually take work?" Nyala's integration plan ended up with four decisions, none of which was about servers or storage:
- Identity first. Podcast staff would move into Nyala's Entra ID tenant, and access to both clouds would be granted from that one directory. That covered joiners, leavers and multi-factor authentication in one place.
- One cost view. AWS and Azure bills would be brought into a single monthly cost report with the same tags (product, environment, owner), so the board saw one number per product rather than one per cloud.
- Policies written twice, deliberately. A small set of rules (no public storage without approval, encryption on, mandatory tags) would be written in both policy languages and checked monthly.
- No migration yet. The podcast platform would stay on Azure for at least a year. Moving it would save little and distract the team. The decision would be revisited with real usage and cost data.
For a structured way to make the "which cloud for which workload" decision, see Choose the workload before the cloud.
The South African detail
Region availability is where service names stop being the whole story. As of October 2026, AWS has one South African region, Africa (Cape Town), which must be opted in to before use. Microsoft has South Africa North (Johannesburg), with availability zones, and South Africa West (Cape Town), which has restricted access and no availability zones. Not every service, size or AI model is offered in every region, and offerings change. Our guide to Azure in South Africa and the reference article AI models available in South Africa cover how to check what is actually available before committing.
A short glossary to keep
| If someone says | They mean |
|---|---|
| Instance or VM | A rented virtual computer |
| Bucket or container (storage) | A named place to keep files |
| VPC or VNet | Your private network in the cloud |
| Account or subscription | The main boundary for billing and permissions |
| Resource group | Azure's container for related resources |
| Tenant | The Entra ID directory that holds your organisation's identities |
| Region | A group of data centres in one geography |
| Availability zone | A separate data centre (or group) within a region, for resilience |
Next: Part 2, The six kinds of data centre executives should understand. All parts are on the series page.
How CloudNala can help
We help leadership teams and architects understand their cloud estate in plain language, then focus on the decisions that matter: identity, account and subscription structure, cost visibility, policy and region availability. Where an organisation runs both AWS and Azure, we help design a single operating view instead of two parallel ones.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Review or write to us at consult@cloudnala.co.za