The question "AWS or Azure?" often comes too early, asked as a matter of principle. It is better settled from what you already have: your applications, your directory, your licences, your teams' skills and where your data has to stay. Both platforms cover the same business needs. What separates them, for a managed platform, is what they cost to operate in your particular context.
This post sets out the criteria we use to steer that choice, then what a managed-services contract must cover, whichever cloud you pick.
The criterion that weighs most: what already exists
The directory. If your company already lives in a Microsoft directory, Azure starts with a head start: access management is designed from Entra ID and flows down to the subscriptions. On AWS, the same directory connects without difficulty to centralised identity management, but it is a connection to design and maintain, not a starting point.
Licences. Windows Server and SQL Server environments carry a licensing dimension that Linux environments do not. The rights you already hold, and how they carry over into the cloud, can weigh more on the bill than the price gap between two virtual machines. It is a point to cost before you choose, with your contracts in front of you.
Applications. A .NET application tied into the Microsoft ecosystem, or a hybrid estate that has to keep talking to on-premises servers, is naturally run on Azure. An application built around managed services, serverless architectures or global delivery finds the broadest catalogue on AWS. These are tendencies, not rules: most business applications run perfectly well on either.
The criteria that break the tie
Data location. Both providers have regions in France and in Switzerland. The useful question is not "where are the datacentres?" but "which of the services I need are available in the region I am bound to?". The answer varies from one service to the next, and is checked service by service.
Your teams' skills. A managed platform does not make your internal team disappear: it still deploys, develops and decides. Choosing the cloud your developers already know reduces the hidden cost of every change.
Billing structure. On Azure, the split into subscriptions and resource groups determines how readable your costs are. On AWS, it is the account structure. In both cases, a split made in a hurry at the start makes cost tracking hard later, and fixing it means moving resources. This criterion does not separate the two clouds; it says the question must be dealt with on day one.
The commercial relationship. Depending on your size, your existing agreement with Microsoft or your consumption commitments with AWS may steer the choice. Put them into the calculation, without letting them decide on their own.
What should not decide
- A comparison of unit prices. The price of a virtual machine matters less than sizing, switching off non-production environments, and licences.
- Multi-cloud on principle. Running two clouds doubles the tooling, the skills and the procedures to maintain. It is justified by a real constraint, regulatory, contractual or technical, not by general caution.
- The provider's preference. A managed-services provider that can only run one cloud will recommend that one. Ask on what criteria they would point you to the other.
What the contract must cover, whichever cloud
The choice of cloud sets the tooling; the contract sets the quality of operations. The points below apply on AWS as much as on Azure.
- The exact scope. What the provider operates, what stays with you, and who decides when in doubt. A vague scope produces incidents nobody picks up.
- Monitoring and on-call. The hours covered, what triggers an intervention, and the expected response time. If 24/7 managed services are needed, the contract must say so.
- Backups and restores. A backup that has never been restored is an assumption. The contract must provide for regular restore tests.
- Changes. How an update or a version upgrade is prepared, approved and, when needed, rolled back.
- Cost tracking. A regular report leadership can read, and cost-reduction work built into operations rather than billed separately after costs have drifted.
- Reversibility. The documentation, the access and the infrastructure code belong to you, and the exit from the contract is described before you need it.
How to decide in practice
Start from the inventory: applications, dependencies, directory, licences, data-location constraints. For each application, note what ties it to one cloud or the other. If a clear majority leans one way, the decision is made. If the inventory does not settle it, pick the cloud your teams know, and refuse to pay to run two without a reason.
That is exactly what our cloud audit, free and with no commitment, does: it compares the options on your real case, before the choice locks you in for years. And if the underlying question is what you will pay each month, our page on managed-services costs sets out the billing models.