AWS vs Azure: The 5-Criteria Choice

AWS or Azure: Тhe 5-Criteria Choice

DISCLAIMER: This document is a promotion of my work. I discuss the differences between AWS and Azure in my own experience, and what I like and dislike about both providers. This post is not intended for any general reader, but companies that seek my assistance with their cloud migrations / architecture solutions.

Post Structure

• Is the Comparison Possible
• The 5 Key Criteria to Help You Choose
• Additional Criteria
• Case Studies
• Wrap-Up

Introduction

Deciding whether you should use AWS or Microsoft Azure for your project is a crucial step for any business. No matter your organization size, this question has been troubling a lot of decision makers throughout the years and is most-likely one of the first questions that appear in every project manager, solutions architect, or even higher executives' heads at the start of every new project.
Taking in mind what is already available on the web, this post is going to uplift the discussion of AWS vs Azure one more layer by providing not only the general comparison of the two providers, but also include a theoretical and use-case sections. You are going to get a glimpse of how I made decisions while working as a DevOps engineer and maybe use the post contents to get inspiration for your next decision!

How to Best Compare AWS and Azure

A comparison between AWS and Azure is best conducted when looking at how they differ in their ways of operating. The 5 key criteria are often discussed in interviews and are the focus point of every cloud engineer. They lie in the core of the Well-Architected Framework * an ideology following 5 principles, forming today’s cloud experience:

• Cost
• Performance
• Security
• Availability/Reliability
• Operation

While these 5 criteria are a good base, I believe that there are a lot more valuable questions to ask yourself when going for the decision. I look at it as the “soft” part of the decision:

• Are my AWS engineers as good as my Azure engineers?
• Do I want to have a dedicated person from AWS/Azure to help me in building and maintaining my solution?
• Do I want to make use of Serverless?
• Do I want to have an easier integration with 3-rd party technologies such as Terraform / Packer / etc.?
• Do I want to have an easier experience in the web portal?

With that in mind, let’s take a deeper look at the base part - 5 key criteria to help you choose.

The 5 Key Criteria to Help You Choose

Cost
Most of the time the discussion shifts to points like “how to optimize costs” or “how to prevent unwanted costs”. For this, I will have to get into the way AWS and Azure operate and what they do differently to help business keep costs to minimum (or maybe, just maybe, hope that business will make a mistake and pay a 10x bill next month wink).

Starting with the most basic form of cost operation - cost tracking tools, Microsoft Azure and AWS’s out-of-the-box tools are identical in use. They output almost the same results with the core difference being that in AWS you have to filter the Cost Explorer by Tags and in Azure’s Cost Management + Billing you filter by Resource Groups or Subscription.

Very important detail here is that Microsoft Azure forces its users to create resource groups to be able to deploy resources, while AWS still allows you to deploy resources if untagged. This helps AWS use unskilled and untrained engineers as an “attack vector”, as if not correctly managed, an AWS account could very fast turn into an unmanageable nightmare.

With the enforcement of using resource groups being one of the best cloud providers’ decisions of all time, one point goes to Microsoft.

Performance
Both cloud providers provide standalone VMs, databases, and storage solutions. The services provided (EC2, Virtual Machines, RDS, Managed Databases, etc), could help any small business with their workload if they are not looking for a complex architecture solution but as businesses evolve, they will inevitably be forced to scale up in one way or another. And here, I personally believe AWS makes a bigger impact on the market by providing services such as:

• OpsWorks
• EC2 Auto Scaling
• AWS App Runner
• AWS Elastic Beanstalk
• AWS Lambda
• Amazon ECS

Also, when it comes to options, AWS has a lot more Compute products than Azure. A simple example of how AWS exceeds in computing options is the Lambda service they offer. It is more advanced than Microsoft’s Azure functions in programming languages availability and operational simplicity. In general, AWS provides a lot more space for business owners to choose how to tackle a specific solution, while Azure has some well-defined services that, if followed, result in excellent performance.

Speaking of well-defined practices, let’s jump into security.

Security
Security is, of course, a must-have discussion, no matter small, mid, or high-scale project you are leading or architecting for. AWS and Azure are both leaders in the industry therefore there is no room for error here. And this is exactly how things have been going for both providers throughout the years. When it comes to comparison,

I, as a consultant, am always with best security practices in mind (for my clients, and for my own projects). And while I want to be as objective as possible, here comes the thin line that separates providers’ best practices and internal company policies. It is important to have people who are not only know-hows of cloud security but networking and on-prem (if applicable) as well.

Without spending too much time on my personal thoughts, here are some comparisons of their services in different security domains, only with my experience in mind:

Access Management
AWS provides their own IAM service called AWS IAM, which resonates with the whole platform, while on the other side Microsoft Azure is making use of Azure AD. Azure AD, however, can be integrated with AWS services, while IAM can’t be used as a base for access management throughout different platforms. I personally believe Azure AD is more powerful having in mind the integrations with 3-rd parties it provides.

Secret Management
For secret management, again, AWS provides more flexibility having different services for key, secret, and certificate management, while Azure provides the Azure KeyVault service which centralizes the hassles of having to deal with this side of security.

Monitoring
I personally think that, again, Azure provides centralized service - Azure Monitor, while AWS has decentralized their services into AWS Cloudwatch, and AWS CloudTrail.

And on closing notes for this section, when it comes to comparison of the security of both of the providers, it is quite straight-forward - the provider takes on responsibility for the security OF the cloud and the customers using the provider’s services have the responsibility of security IN the cloud.

As a conclusion, I grant both providers a point when it comes to security since my experience with both has been quite good.

Availability/Reliability
Both AWS and Azure provide the highest-class availability and reliability. As it is only natural, there are instances where outages in data centers happen and it is important to keep a close eye on how both of these providers are reacting in such critical situations. From my experience, AWS has the edge here as they communicated their outages a lot more successfully through their dedicated support.

In terms of downtime, from my expertise, Microsoft Azure’s web navigation services have been inaccessible a lot more frequently than AWS’s. There have been times where Azure’s DevOps board is not working. There have also been times where I could not access Azure’s web portal at all. However, from an operational point of view, I have a strong opinion that my clients’ services have been up and running pretty much the same way throughout both providers.

And what about availability services? From a technical point of view, the two providers tackle the high availability cases differently in a way that they don’t go too far from the conventional ways of doing it. For example, in Azure there are Availability Sets, and Scale Sets. Both of these services work hand-in-hand with Azure’s Load Balancer Service. In AWS, there is once a single service named Elastic Load Balancing which in most use cases, is a standard load balancer (with the options to be a network, or application one). To keep it simple, both of the providers work with a load balancer as their core way of providing high availability.

To close this section, based mainly on my expertise, and not on promotional documents from both of the cloud providers, I assign a point to AWS due to its overall operational availability being higher (again, in my own experience) than Azure’s.

Operation
Here you are on the 5-th and last criteria - Operation. To explain the operational difference, I first have to start with the similarities. There are native ways of doing cloud that are shared not only between our two clashing opponents but all the rest of the providers. This is being reflected in methods like the usage-based billing (businesses paying only for what they use, rather than upfront commitment). On the other hand you have the reserved capacity option - for when companies know what computing power they need for the next few years. Forcing MFA and reading through cloud providers’ handbooks are also practices considered cloud-native. So in terms of working with the clouds themselves, AWS and Azure are identical. The difference comes in the details that can only be seen by engineers and people working with the specific cloud on a daily basis.

The Difference
The most outstanding difference in how our competitors operate, is without a doubt Azure’s Resource Groups and Subscriptions VS AWS’s Tagging model. Microsoft Azure forces you to put your resources in certain resource groups, which reside in certain subscriptions. This makes a huge difference in the final outcome of organizations as with this being forced, the junk resources are far less, and far easier to deal with. With our other competitor (AWS), one can only group up resources by tagging them with specific key-value pairs. This is not forced in any way upon account creation and makes it necessary to enforce a policy so that it becomes a must. This is, however, often disregarded as people tend to forget about the final state of their cloud, or even that there are other applications than theirs (developers). This can quickly turn a business owner’s AWS account into a living nightmare because the Cost Explorer will not show relevant information regarding where your money is going.

To share a practical example, I encountered such a problematic account at the time I worked at my previous company. Me and my team agreed and managed to clean-up most of their cloud by removing ghost resources, enabled services such as Control Tower, tagged resources, and shifted the communication model in the development teams towards a more communicate-first approach. This allowed for the whole organization to be a step closer to what the right way of doing cloud is. But all of this, NON-TECHNICAL job, took months of meetings with development teams, managers, AWS dedicated support and heads of departments.

To round this final point up, I am strongly standing with Azure’s way of doing resource management and I strongly advise you if your engineers are not skilled enough to not spawn ghost resources, to shift towards Azure. Speaking of skilled engineers, let’s jump into the next section, where I shift the comparison towards a little more non-conventional direction.

Additional Criteria

To be honest, I think the questions that follow are far more important in making the decision which cloud to use, than all the “theory” from the points above.

Let’s start with a few thought-provoking questions:

• Do I have people who are good enough AWS engineers or do I only have Azure engineers?
• Do I want to integrate hybrid-cloud in my solution?
• Do I want to have an easier experience in the web portal to gather data?
• Do I want to have a dedicated support representative from the cloud provider?

Do I have people who are good enough AWS engineers or do I only have Azure engineers?
Okay, let’s imagine you have the required knowledge of all the services the providers you are split between offer. You know what you want to use and the architecture design is complex enough to get funding for your project. You also have this really promising consultancy firm that you have been working with for years already. You make the call and ask for X number of engineers to carry-out the task. However, the consultancy firm can only offer 1 engineer that they are certain have all the necessary skills you asked for. The consultancy firm explains they have the X number of engineers you asked for but for the other cloud provider. They assure you their engineers are the best of the best and can definitely deliver top-quality work. Does that change the direction of your decision? In a lot of the cases the answer is “yes”. And this is natural. If you think about it, at the end of the day, the quality of work and the capability of the engineers defines what is possible and what not.
Do I want to integrate hybrid-cloud in my solution?
Companies are now utilizing hybrid cloud - making use of on-prem servers in addition to cloud services. There are tools, both of the providers offer, but there is one that precedes the other here. Microsoft Azure has been focusing on hybrid cloud a lot more successfully throughout the years with services in the family of Arc Data Services, Stack HCI, and their edge services (IoT edge, SQL edge, etc.).

On the contrary, AWS offers services like Snowball, which is a case with storage that can move terabytes to petabytes of data easily from your on-prem to wherever you want.

Do I want to have an easier experience in the web portal and have an easier way to keep track of my resources?
There are hundreds of stories of people with enormous AWS bills and unexpected taxes. There are hundreds of stories also of people who say their experience with structuring their resources in Azure has been as easy as 1, 2, 3. How do these two totally different segments of the cloud (cost & structure) connect so that I am writing about it? Listen up - this is how it goes! The easier it is to find something in your cloud, the easier it is to track it. Resources cost money. The harder finding a resource, the easier it is for your engineers to forget about it and therefore the easier it is for your bill to raise gradually (or skyrocket in a month).

The key difference between the two providers in this regard are again - Azure’s Resource Groups and Subscriptions. As mentioned previously in this post, this makes the experience in the web portal a lot easier and it helps you and your engineers keep track of resources a ton.

It is that simple. Azure forces you to make your life easier. Ah, how I hate it when someone does something good for me - said no one ever.

Do I want to have a dedicated support representative from the cloud provider?

Look, there are people that are invested in fields they don’t work in. For example, some of my tech friends are really good writers. And by really good, I mean this-post-good. However, these colleagues are not professional writers and haven’t spent every single day of their lives writing the way we sometimes want them to. The same goes for cloud providers’ support engineers. Sometimes as good as your consultancy firm of choice’s engineers can get, they are not as good as a person who is working for your provider of choice full-time. All that inside information, all these hours spent chatting in internal chat systems, just to find the correct way of doing something, or fast-track your problem is irreplaceable. Having all of these weekly meetings just to make sure everything with your project is going smoothly! This right there, is the value.

Here, I can say that AWS’s ways of doing support has been a lot better than Azure’s. The processes the dedicated support engineers utilize and the way they go above and beyond their limits to help organizations, are plausible. But every great thing comes with a price. And the price for this… is a confusing plans page in AWS’s website - https://aws.amazon.com/premiumsupport/plans/. From my experience, the company I worked with, has been paying from $10.000 to $14.000 for premium support. Makes you think. But then again… everything good comes with a price.

Case Studies

Trust is in the core of almost everything out there. And how can you trust this post, if I don’t share my expertise - with case studies of course! I am going to go over two of my most successful stories and share some insights of the challenges I faced along the way. One for AWS and one for Azure.

AWS
I will be referring to the client as “the client” so as to not forward any unwanted attention to the client.

The client in need, trusted us (the company I worked with, at the time) with 3 DevOps people to help within the Center of Excellence team. We were introduced to an account with resources split all over the place. Bills that could be lowered by 30-40%, which in any right-minded person’s head sounds ludacris. Funny or not, this was the reality. We started out doing simple tasks to get our engineers to understand the environment more. Once we established a good communication base with the different teams and the premium AWS support, we worked together with the support in creating a plan to resolve the messed up situation the client’s cloud was in.

The plan included deploying Control Tower and dividing the projects within the client organization into single accounts within the Control Tower. We then started a communication flow with all of the teams needed and started preparing for migrations. We used services for near-zero downtime to ensure the client’s applications are in as good health as possible. Speaking of health, these migrations enabled for an improvement in the teams’ infrastructure. We managed to cut costs in a lot of different ways and improving the teams’ applications was one of them. Upgrading instance types to newer versions and decommissioning unused EC2 instances, S3 buckets, and EKSes are just a portion of our efforts in reducing costs and creating structure.

The company is, to this day, continuing to work with this client and the team has grown to 10+ people.

Azure
For our (the company I worked with, at the time) Azure client in question, I did a lot more technical tasks, than what I did in the uptop mentioned AWS one. This allowed me to expand on my experience in domains such as hybrid cloud and GitOps. I will share how we tackled specific operational and technical problems. I will also share what my experience with Azure support was.

The scale of the Azure client is a big company of more than 200 employees. For the sake of preventing information gathering, this is not an absolute number and might be between 200 and 5000. My DevOps engagement with the company consisted of 1 contract containing 1 person (me). I supported, in the beginning, a single project with the main technologies being Terraform, Kubernetes, and key Azure services such as Virtual Machines, Managed SQL, SQL server, Kubernetes, Load Balancer.

In this phase of the contract, I had the opportunity to understand the overall structure of the company on a deeper level, which allowed the client to expand the contract into other fields such as general DevOps, GitOps implementation and Kubernetes support. This marked the beginning of an extended contract which turned me into a dedicated DevOps for the whole organization. With the organization in question giving their trust into me, tasks shifted from supporting a single application into supporting the whole infrastructure as code of the organization, as well as the Kubernetes workloads.

I started proactively looking for ways to improve the overall company cloud experience, while delivering on necessary tasks from the lead solutions architect. This included me being part of architecture discussions, documentation writing, automating GIT workflows & implementing more of the GitOps model.

Having worked for this particular client, I can easily and happily say that both sides gained tremendous value in many areas. And with this, I think Microsoft Azure plays an important part in providing its services, as the trust and work done in the way it was done, was not going to be possible if the underlying cloud was AWS. It is a good time for me to reference the previous section - Additional Criteria, where I discussed exactly this - how well does an engineer fit in a project and how does the chosen cloud work for you and your engineers.

Wrap-Up: With Great Business Plan Comes Great Cloud Risks

In the conclusion to our adventure, I hope you are at least a step closer to your decision. I hope this post was helpful for anyone that read it in its entirety. If you haven’t read the full post though I strongly advise that you go ahead and give it a read or two - just to populate your mind palace with enough information for your decision - AWS vs Azure.

With this out of the way, I am closing this post on a promotional note and a hot take.

Capable engineers. This is what every company hopes for. And as my mission guides me towards reaching my vision, I always strive to exceed expectations and provide answers to the real questions. I focus on providing value and solutions rather than pointing out the problems. This is exactly what I think separates me from the rest of my competitors - the sheer will to help and succeed in my work even if it means to go over the “must-do’s”.

Whatever cloud problems may occur, HAARP is not the solution - engineers are. And I have just the right engineer for you wink!