For most enterprises, when it comes to public cloud service providers, it’s often a choice between AWS and Azure. Once the choice has been made, it’s then up to the cloud administrators and architects to set the ball rolling on the selected platform.
However, there are staggering differences between AWS and Azure from a user experience and management perspective.
Since I started working on Azure, the portal has gone through many makeovers, especially in response to the major shift in the deployment model from classic to ARM. The predecessor to the classic portal was a fairly basic UI which gave way to the classic portal and eventually to the latest ARM portal.
The transformation was quite a welcome change as more and more features were added on to the UI to make our lives easier. For Azure administrators who have spent years accustomed to the cheerful blue interface of Azure, using the AWS management console could turn out to be a roller coaster ride for sure!
The AWS console could appeal to users inclined towards minimalistic configurations, but others may find it frustrating to jump through so many hoops for a configuration. This post is a light-hearted take on how AWS differs from Azure–from a UI and management perspective.
“All Resources” View
In Azure, there is a very handy “All Resources” option on the left-hand side of the portal landing page that helps you search for any existing resource that was provisioned earlier, be it VMs, storage, SQl, web apps, etc. You can search for any of these resources from the same page without navigating away to different pages dedicated to each instance type. This makes life so much easier for a newbie administrator trying to find his way around the Azure environment.
The same search experience, however, is different in the AWS management console. While there is a search option on the AWS management console home page, it’s for different AWS service types and not for the provisioned resources. So, having a resource name is not enough to find a resource in AWS management console as there is no consolidated “all that is provisioned” view here. You need to know what resource type you are looking for, select the resource type (EC2, for instance) and search from the view of that specific resource type. You should know in advance the region where the resource is deployed, as only resources in a selected region are listed even if you browse to the EC2 dashboard. Fair warning for AWS newbies: You are expected to do your homework and know what you are looking for before playing around with the management console! Hopefully, this tip will help!
Resource Configuration
The configuration experience of individual components is different in AWS than it is in Azure. In Azure, all configuration settings can be navigated from the same pane and you can also return to the parent setting using the slider in the portal.
Let’s say you want to make some changes to your VM configuration. If you click on network settings of the VM, you can open the properties of the VNET to which the VM is connected and it opens up on the right hand side. You close the pane or move the slider back and you can work on the VM configuration.
In AWS, though, the configuration details are shown in the bottom panel. Clicking on the VPC of the VM would open up a new window of the VPC management console, as opposed to what happens in Azure where the network configuration appears as an extension of the VM configuration on the same page.
There are no specific pros and cons to be highlighted here. (Unlike the case of the “All resource” search where Azure definitely provides a better experience.) It’s rather a case of convenience or user preference.
Cloud Shell
A vast majority of IT folks swear by their black command line consoles. It’s a way of living for most of us, and a faster way of getting things done. Though we’ve transitioned from on-premises to cloud, our love for “black consoles” persists.
Both AWS and Azure provide command line options for ease of management and automation. Azure CLI and Azure PowerShell can be installed on your on-premises machines, configured to accept Azure credentials to connect to your subscription, and then run relevant management commands. AWS CLI and AWS tools for PowerShell offer a similar CLI and a Powershell-based management experience for AWS.
Azure, however, has gone one step further and created a browser-based command line tool called Azure Cloud Shell which has a number of command line tools pre-installed, including Azure CLI, PowerShell, Kubectl, and AzCopy. Cloud Shell can be directly accessed from the Azure portal and you don’t need any specific machine dedicated to run these tools. It also offers a Bash as well as PowerShell-based experience so that users can choose the option they’re most comfortable with. AWS doesn’t offer such a browser-based command line experience. The closest is AWS-shell, but it is not integrated with the AWS management console.
Are you a tech marketing professional seeking Azure or AWS experts to contribute expert-based content to your company blog? Contact us to see about hiring this writer (or others) to create content like this for you!
Region Selection
When you log in to the Azure portal, you’re able to browse through all resources in the subscriptions linked to the Azure AD, irrespective of the region where they’re deployed. You simply do a filter of the resources in the “All Resources” view to see the resources in a specific Azure region. Similarly during deployment, you can select a region from the available regions in a dropdown menu. All regions where the resource can be deployed will be listed, unless restricted by an administrator using Azure policy. Here subscription or resource groups are used as an administrative boundary for deployment experience and not regions.
In the case of AWS, except for global resources such as Route53 and CloudFront, users are expected to first select the region in the AWS management console from the top right corner and then proceed with the provisioning. The experience is the same for listing the existing resources, as well. Unlike Azure, AWS uses region as a logical boundary for deployment and management experience.
Dashboard and Resource Groups
Cloud administrators often have to switch between multiple resource types and drill down to specific resources as part of day-to-day work. Shortcuts/Dashboards/Favorites can help ease up the workload here.
From the Azure portal, you can search for a specific resource and mark it as your favorite so that it’s listed in the left pane of the portal. It will be available every time you log in until manually removed from favorites. For example, if you work mostly on storages, you can mark that as your favorite and be able to easily click on the “Storage Account” option in the portal list. Or choose“resource type” as your favorite so to view all storage accounts you have access to. You can also pin the resource type or even specific resources to your personalized Azure dashboard. This dashboard also can be shared with other Azure portal users. For example, all members of the team working on provisioning or managing specific resources can share a customized dashboard. You can also group together multiple Azure resources in a logical container called “Resource group” and pin the resource group to Azure dashboard.
With AWS, users are able to add shortcuts on the navigation bar of the AWS management console. First, click on the pushpin icon and then drag and drop the selected service. You might try addingS3 or EC2 to the navigation bar to create the shortcut. However, AWS does not have a service similar to the Azure dashboard where you can pin individual resources for easy and quick access. Instead, the resource type can be pinned to the navigation bar and then you must search for the listed resources for reaching the individual resource. AWS also has a logical grouping of resources called “Resource groups” where multiple resources in the same region can be added for ease of management. These resource groups are directly accessible from the AWS management console landing page and can act as a direct link to these grouped resources.
Conclusion
This post covered a few first-hand observations that I’ve come across while playing around in AWS, purely from UI and management perspectives. Of course, my observations and experiences may be different from yours. So, please feel free to share them as I am sure it would spark some interesting discussions.
