An AWS Primer for Azure Developers

Even though AWS has been around for much longer, as is the norm for a lot of people coming from the .NET/Microsoft side of things, my cloud experience started with Azure. I got into AWS when I was a few years into Azure. I remember thinking at that point it would be nice to have something like this primer that would give me a very high-level introduction to AWS based on what I knew of Azure. So here it is.

Obviously everything can’t be covered- I’ve kept this very high level so you have a starting point based on your needs, plus the services covered are geared more towards general-purpose application development as opposed to specialized cases like machine learning, IoT, big data or data warehousing.

Here is what I cover:

• Accounts, Subscriptions & Resources
• Administration
• Security
• Provisioning and Infrastructure as Code (IaC)
• Infrastructure as a Service (IaaS) and Networking
• Platform as a Service (PaaS)- includes Applications and Serverless, Containers and Kubernetes, Database, Cache, Messaging, Storage, Observability, and SCM/CI/CD.

Accounts, Subscriptions & Resources

The major difference here is the concept of Subscriptions in Azure which does not exist in AWS. When you create an account in AWS, that is already at the level of what you would call a subscription in AWS. So, if you are an organization that has multiple subscriptions in Azure, the corresponding experience in AWS would be to just have multiple accounts. To ease the management overhead this would cause, AWS has an offering called Organizations.

The other difference is the concept of Resource Groups in Azure which, again, does not exist in AWS (or rather exists but in a very different way). Whereas resource groups are a first-class deployment-level construct in Azure, AWS resource groups are just a tagging mechanism. Locations in Azure correspond to Regions in AWS as you would expect - but the role that resource groups play in resource structuring in Azure are for the most part played by AWS regions.

Resources in Azure get a Resource Identifier; the equivalent concept in AWS is the ARN.

Administration

While there are multiple modes of administration for both, the common modes are that both have a CLI and a web-based GUI. The CLIs operate similarly - you login and get a context and then all your operations are against that context. The account/subscription/resource group/region difference mentioned above plays into this as well. Practically, though, Azure CLI and AWS CLI are pretty similar in how they work.

The major difference can be seen in the web GUI experience. With Azure Portal, you pick an account and then within that account, you get the blade-based UI that shows you all resources/resource groups in one place, and as you get deeper into various settings, the blades pile on - but for the most part it’s one unified UI. As of this writing, it has Dark Mode support whereas AWS Console does not.

AWS Console is much more segmented - you first sign in to an account, then you pick a region, then you pick a service and a standalone Console opens up specific to only that service with a UI that is tailored for that service. Since when you initially get started with either Azure or AWS, the web GUI will be your most likely landing spot, this causes some disorientation. This has been a long-standing complaint against AWS Console - the lack of a way to look at all your resources in one place regardless of service type or account. On the other hand, once you start getting deep into a specific service’s configuration, some think the Azure blade UI has a tendency to get “out of hand” - so pros and cons on both sides.

Security

The repository that drives security and access control in Azure is Azure Active Directory (AAD). All role-based access control (RBAC) is driven off AAD. This aspect on AWS is served by Identity and Access Management (IAM). Both have similar security constructs in the way of users, groups, roles, policies and permissions. There are significant differences in implementation and how it applies to resource access for administration as well as for consumption - so this is a fundamental aspect of both that is worth getting to know in depth before jumping in.

Provisioning and Infrastructure as Code (IaC)

Of course, we would all rather be using Terraform or Pulumi - but that may not always suit your needs in which case you do have to deal with the native IaC system provided by each. The counterpart to Azure Resource Manager in AWS is CloudFormation. Like you author ARM Templates in Azure, you author CloudFormation Stacks in AWS. CloudFormation supports both JSON and YAML whereas ARM only supports JSON.

Infrastructure as a Service (IaaS) and Networking

Azure VMs and VM Scale Sets allow you to provision and scale VMs on the cloud. AWS does this via Elastic Compute Cloud (EC2). You can define virtual networks and subnets where your VMs run (as well as some PaaS services) in Azure with Azure VNET, and in AWS with Virtual Private Cloud (VPC). Both Azure and AWS provide DNS and DNS based traffic routing services (Azure with Azure DNS and Traffic Manager, and AWS with Route 53). Load balancing is available on Azure with Load Balancer and on AWS with Elastic Load Balancing. The corresponding service on AWS for Azure’s Front Door is Global Accelerator. Both Azure and AWS have CDN services- with Azure CDN and AWS CloudFront.

Platform as a Service (PaaS)

If you stick to IaaS, once you have set up your VM and networking, a VM is a VM is a VM. Not much else to it - it gets more interesting when you get into PaaS with all the different services and offerings and, of course, fancy names (more of those on the AWS side). Again, keeping with the “just general-purpose application development” theme, I’ve covered the following “service categories” if you will:

• Applications and Serverless
• Containers and Kubernetes
• Database
• Cache
• Messaging and Event Processing
• Storage and Secrets
• Observability
• SCM and CI/CD

Applications and Serverless

If you want to get an application (or a bunch of them) up and running without worrying about infrastructure, you would use App Service on Azure. This purpose is served by Elastic Beanstalk in AWS. Both support all the major mainstream languages. To define and orchestrate workflows, whereas you would use Logic Apps on Azure, you could use either Simple Workflow Service on AWS. Fully serverless, spin-up-on-demand-via-triggers compute is available on Azure as Functions and on AWS as Lambda. You can string up a bunch of Lambdas to implement workflows on AWS using Step Functions.

Containers and Kubernetes

Serverless container management is available in Azure with Container Instances. Between Elastic Container Service (ECS) and Fargate, AWS has this covered. Both have their versions of a container registry- Azure with Azure Container Registry (ACR) and AWS with Elastic Container Registry (ECR). If you want to be on Kubernetes, Azure has a managed offering with Azure Kubernetes Service (AKS). The corresponding AWS service is Elastic Kubernetes Service (EKS).

Database

Azure supports SQL Server, MySQL and PostgreSQL all as PaaS services. The corresponding service offering on AWS is Relational Database Service (RDS). As far as purpose-built/NoSQL databases are concerned, AWS seems to have more offerings, but a lot of that is also owing to a lot of these in Azure being bundled within Cosmos DB. The closest thing to native Cosmos DB as well as Table Storage on Azure is DynamoDB in AWS.

Another common pattern with databases on both Azure and AWS is proprietary database engines that then have compatibility with some standard API. For example, you can set up Cosmos DB with MongoDB compliance (the AWS counterpart being DocumentDB) or with Cassandra compliance (the AWS counterpart being Keyspaces). In the same vein, switching back to relational, AWS has Aurora - which is a proprietary database engine atop RDS that has compatibility either with MySQL or PostgreSQL.

Cache

Azure has a managed Redis Cache offering. The corresponding service in AWS is ElastiCache which supports both Redis as well as Memcached.

Messaging and Event Processing

As far as message queues are concerned, Azure Storage has a Queue Storage option. For more advanced usage, Azure Service Bus has Queues as well. The closest equivalent on AWS to these is Simple Queue Service (SQS). The closest equivalent to Topics on Azure Service Bus on AWS is Simple Notification Service (SNS). On more of the event processing side, Azure Service Bus has Event Hub and there’s also Azure Event Grid - the AWS counterpart to these is the Kinesis set of services. You can’t talk events without talking about Kafka- whereas Azure has Kafka support as part of HDInsight, AWS has Managed Streams for Kafka (MSK).

Since we brought up HDInsight, even though not technically messaging or event processing, HDInsight supports both Hadoop and Spark. The AWS equivalents for these would be EMR and Glue, respectively. Finally, only slightly related to all these- Azure does not have a dedicated email service- it promotes SendGrid as a marketplace option. AWS does have Simple Email Service (SES) - so there’s that.

Storage and Secrets

Setting aside Queue Storage (which is a queue more than storage) and Table Storage (which is a database more than storage) which I mentioned above, Azure Storage groups two pure storage services- BLOB Storage (the AWS counterpart being Simple Storage Service or S3) and File Storage (the AWS counterpart being Elastic File System or EFS). In terms of block level storage, Azure has Managed Disks whereas AWS has Elastic Block Store (EBS).

For secret management, Key Vault is the Azure one-stop-shop. AWS has a bunch of services that deal with secrets and keys- such as KMS, CloudHSM and Secrets Manager. There’s also Parameter Store which is a general-purpose configuration data storage service but also supports encrypted secrets.

Observability

Between Azure Monitor and Application Insights, your logging, tracing and monitoring needs should be covered on Azure. The corresponding services in AWS are CloudWatch and X-Ray.

SCM and CI/CD

Azure DevOps is a set of tools to support SCM and CI/CD (including Azure Repos for source control and Azure Pipelines for CI/CD). AWS has its own source control service in CodeCommit along with CI/CD provided by CodeBuild and CodePipeline.

In conclusion, I hope this helps someone. It is very high level and barely scratches the surface of anything, really. I felt the need for something like this especially when I was building software that needed to run natively on both cloud platforms or when I was building abstractions for cross cutting functionality. In any case, I hope it orients you in the right direction if you are at a similar position.