How the different DNAs of Amazon, Microsoft and Google influence their Cloud Platforms.

Disclaimer: This is an opinionated post. The views and platitudes are solely based on my own experience and observations.

Recently I was searching for a document and bounced into a presentation I did in November 2011 about Microsoft Azure in a local Microsoft meetup, it was Windows Azure then.

When I look back, it is almost 11 years gone. Microsoft officially launched Azure in February 2011. During that time Google’s App Engine was famous among students. That was a time the current leading cloud providers were evaluating the market and making their first steps. Amazon was little ahead.

When I started Azure, it had only three services with a Silverlight portal. Virtual Machines, Storage (with Blob, Tables, Queues) and Cloud Services. Oh man! Tables existed ever since. It is still one of the powerful yet underrated services in Azure. I remember using Google App Engine for Google Summer of Code competitions.

Lot had happened in the cloud market from then. Amazon has defined a clear leading edge. Azure has become a serious contender especially among the enterprises. AWS and Azure are like the Android and iOS in the mobile world. When it comes to market leaders now it is AWS, Azure and GCP often known as AAG.

AAG – AWS, Azure & GCP

AWS, Azure and GCP are respectively from Amazon, Microsoft, and Google. They all have different roots and values. Each of them has a different DNA, which influences their cloud services in diverse ways.

AWS – The Retail DNA

AWS has the retail DNA from the roots of Amazon’s e-commerce business culture. Few notable key traits of the retail DNA are shipping fast to be the first, more focus on volume than margins and packaging under own brands known as private labeling.

AWS is clearly the market leader by revenue. Amazon made APIs to communicate between its own teams, later those APIs were exposed outside the corporate firewall eventually paving the way to AWS.

Early adapters and open-source folks went with AWS, this includes successful startups who were catching up during 2008-2013. Microsoft launched Azure later that period in 2011, Though Azure was catching up fast it was less matured compared to AWS. Also, Microsoft did not have a good repo with open-source communities during that period. Being the first to market and without a serious competition, AWS took the whole advantage of the situation during that period.

AWS follows a continuous innovation cycle and keeps on releasing new cloud services even if those services are less popular or only useful to a smaller set of customers. AWS does this to be the first in the market, not worrying about the bottom-line. Nevertheless, this trait comes with a risk, it may give a leverage to the competitors, especially when the competitor has the competence to learn quickly. Competitors can take the first mover’s failures as learnings with no expense and produce a better product. But so far AWS has been managing this risk very well.

Another interesting character of AWS is private labeling, a direct trait from the retail DNA. Private labeling is a business technique used by retail players to package common goods from suppliers under their own label with few value additions. AWS uses this technique very cleverly. AWS has an inherent weakness of not having any established software or operating systems of its own (Microsoft has an advantage here). This does not play well for AWS when it comes to cloud lock-in or giving generous discounts. However, using private labeling AWS has been successfully battling this challenge by creating its own services. Few examples are Aurora DB which is a private label of MySQL/Postgres and Redshift is another successful example.

Azure – The Modern Enterprise DNA

Azure has the modern enterprise DNA. Modern Enterprise DNA has the old traits like bottom line focus, partner ecosystem and speaking the corporate lingo, combined with the modern traits of innovation, openness, and platform strategy. Microsoft learnt the modern traits in a hard way however Microsoft has become the coolest enterprise now.

The modern enterprise DNA has made Azure a clean winner in the enterprise space. Microsoft achieved this not only because of the great enterprise relationships but also Azure is a great cloud platform.

Azure is not a laggard in innovations, Azure has its own share of innovative services focused with developer productivity and enterprise adaption, notably the robust cloud-based Identity and Access Management service, Azure Cosmos Database, Functions and many more. Azure also made new partnerships with leading players like Databricks and Open AI, thanks to the openness Microsoft has developed lately, and being one of the top open-source contributors.

Generally, Azure targets its innovations at stable markets where they anticipate greater adaption, they do not invest much on niche areas just to appear cool. This is because of the traditional bottom-line focused business orientation. This characteristic reflects in their service portfolio very well, there are few services Azure had shut down from public beta without moving to General Availability (GA), in Azure terms production. My take on this, do not count on any services that are not in GA for your next project.

Partner ecosystem is one of the key strengths of Microsoft. This has given an unbeatable position for Azure in Hybrid cloud market with its Azure Stack suite. This is only possible by Microsoft because of its long-standing partner ecosystem and OEM partner network.

Also, the customers who have concerns about the similar interests of Amazon prefer moving with Azure than AWS. Recent Netflix partnership with Microsoft for the ad enabled service model is a good example of this. Also, e-commerce players often choose Azure because of the same concern.

GCP – Internet Services DNA

GCP has the Internet Services DNA from Google. Google leads the Internet based consumer services, starting from the Search, email services, personal cloud storage, YouTube, Maps and more. We all use Google services in our day-to-day life. Internet services DNA prioritizes individual services than the whole platform. This DNA has B2C orientation than B2B.

GCP is the third largest cloud provider by revenue, but the difference between GCP and Azure is big. Also, GCP has serious competition from Ali Cloud. Particularly the recent regional polarization has boosted Ali Cloud adaption in Southeast Asia.

GCP has all the required foundational building blocks of a modern cloud, but they lack the rich portfolio of services compared to what AWS or Azure has. GCP tries to sell the same thing under different packaging. One example is API management service is listed New Business Channels using APIs and Unlocking Legacy Applications using APIs. Those are two use cases of the same service. It does not do harm, but it does not help much either.

Google is a successful Internet services company; Google should have been the leader in cloud computing. Ironically, it did not happen because Google did not believe in enterprise businesses earlier. When they realized big corporates are the big customers for the cloud computing, it was bit too late, and they had to bring the leadership from outside to get that thinking.

Google’s Internet service DNA has made GCP fragmented, the perception about GCP as one solid platform is vastly missing. We all use GCP services without much attention to the whole platform. We use Google Maps in applications, Firebase has become a necessity for mobile development, we use Google search APIs, but we see them as individual service not as single cloud platform. The single platform thinking is essential to win the enterprise customers. Not having such perception is a major downside of GCP.

However, it is not all bad for GCP, amongst these odds the leadership came from Oracle is somewhat doing the justice. Also, Google seems happy with what they are doing, selling Internet based services and aggregating the revenue in the P&L under GCP.


AAG are the leading cloud providers now and as said do not underestimate the Ali Cloud, it is a close competitor to GCP. As a closing note, I want to highlight another trend happening in the cloud world.

World is closing the doors.

This is a real issue. In my experience so far, I have worked in three cases, where customers (big ones) went back to local data centers from public cloud. All three of them are EU customers. One was due to the concerns of cloud provider becoming the competitor, and other two cases were purely based on concerns of using US based cloud providers and data sovereignty related concerns.

Compared to how number of customers moving with the cloud, this is a small number, but I do not want to avoid those three cases as extreme outliers. I see the trend is somewhat getting popular.

Microsoft’s announcement in reduced sales in Russia and scaling down due to the ongoing war between Ukraine and Russia has triggered an alarm among some customers (although they are not based in Russia). They are concerned about Microsoft’s stance at a similar event happening in their country. Customers have begun to develop concerns whether Microsoft would do the same to them at an event of their countries having any conflict of opinion with USA policies. This includes EU customers as well.

Another reason customers are pulling off from public cloud providers is the ongoing economic reasons and USD appreciations against their local currency. Customers have either slowed down their cloud adaption or looking for ways to cut down spending. I have seen this trend much in Southeast Asia. Another trend Chinese cloud providers mainly Ali Baba is capturing the customers of this region due to the increasing regional polarization.

Decision making tables can easily become political or too technical. It is CTO/CIO’s job to balance both and navigate through the noise to make clear decisions.

AWS Best login practice – IAM Policies

This post explains the best practice that highly recommended to be followed in AWS account and the Identity Access Management (IAM) policies in login process.

First the user account that is used to create the AWS account is the Root Account. (the composite credential of email address and password). For example if I go to AWS portal and submit email address and the password along with credit card payment details, this account or the credential holder becomes the Root Account.

It is not recommended to use the Root Account for any purposes even to login to AWS portal. (unless required in very specific scenarios like changing core account details and payment methods)

The best practice is to create an IAM user with administrator privileges. IAM administrator has all the privileges except the core account privileges mentioned above. You can use the built it IAM administrator template for this.

Follow these steps.

  • First login to the portal as AWS Root User (as in the beginning Root User is the only one who has privileges to create Administrators). Root user will go to and enter email and password to login to the portal. You can note that this is a global URL for all AWS users all over the world.
  • In the portal go to under Administration & Security section click on IAM image
  • Go to users and click create users. Name the user (ex – admin) and you can generate key for the user in order to access AWS services via APIs. It’s not recomended to use admin account for development purposes so better not to generate keys for admin. Click create to create the user.image
  • By default the users do not get any permissions. In order to assign permission, click on admin (the user created in the above step will appear in the users grid). Under the permission tab click on attach policy.image
  • First option is Administrator Access policy. Click on that to assign it and click Attach Policy button.image
  • Then back in the page under Security Credentials section click on Manage Password to create a password for the admin.image
  • There you can auto assign a password or can assign a custom password. You also get the option to make the user to change the password in the first login.
  • You also have the option to specify MFA (will post a separate blog on this topic)
  • Now go back to the IAM Dashboard and you will see a section like this.image
  • This is the IAM user sign-in link. You can click customize and replace the number in the URL to some alias (your organization name). And this URL should be used by IAM users including the admin in order to access AWS web console.







Root user account and the global sign-in URL should be untouched unless a specific requirement.

Creating and connecting to SQL Server in AWS RDS

Amazon Web Services (AWS) offers Relational Database Service (RDS) with the following RDMSs. 

  • Microsoft SQL Server
  • MySQL
  • PostgreSQL
  • Oracle

In order to create a AWS Managed RDS click on the RDS link in the management console under the Database section.

image This will lead to the following screen, and here you can begin creating a SQL Server in AWS managed RDS.


Fill the below details.


In the above form I selected micro instance as it gets qualified for the free tier service,  and Multi-AZ Deployment is disabled. Multi-AZ Deployment helps you to scale up the instances and works as a failover mechanism. Scaling the storage after the database engine has been provisioned is not supported by the SQL Server in AWS. Note that scaling the instances and scaling the storage are two different things.


After filling the details you can launch the DB Instance. You will see the following information about the DB instance you created.



Connecting to AWS SQL Server from SSMS

Notice that in this instance SQL Server is running in its default port. In order to connect to the DB Instance from any client tool like SSMS you have to enable the inbound rule for the security group in which your DB instance lives. In order to perform this action quickly from the above screen click on the exclamation mark icon beside the underlined section.



In this case I put the DB instance in the default security group. Click on the default link and it will take you to the Networks and Security section.  Click the Inbound tab, select Edit and configure the SQL Server port and assign IP rule. (You have the options to select a specific IP, or your current IP and All IP). In this example I added the rule connect from anywhere (All IPs). But mostly for your production server you will not do this.


Save the settings for the security group.

Now the inbound port TCP:1433 is enabled and you can connect from the SSMS. Copy the underlined endpoint name of the server without the port number, that is your SQL Server name.


Enter the password and you will be connected to the DB Instance.