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.

AAG – AWS, Azure & GCP

AWS, Azure and GCP are respectively from Amazon, Microsoft, and Google. These companies have different roots, values strengths and weaknesses. Each of them has a different DNA, which influences their cloud services in diverse ways. This article shows a completely different perspective about how the different DNAs of these organizations have been shaping their cloud market.  

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.

Amazon launched AWS in 2006. Early adapters and open-source folks went ahead with AWS, this includes many current successful startups who were catching up during 2008-2013. Although Microsoft launched Azure later that period in 2011, it was less matured, and Microsoft did not have a good repo with open-source communities then. Being the first to market 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 services although those services are either 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.

Another interesting trait of the retail DNA is Private Labeling. Private labeling is a business technique used by retail players to package common goods from suppliers under their own labels with some 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. This does not play well for AWS when it comes to cloud lock-in or giving generous discounts to the customers on software licenses. 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 DNA of a modern enterprise. Modern Enterprise DNA has old traits like bottom line focus, partner ecosystem and speaking the corporate lingo combined with modern traits such as innovation, openness, and platform strategy.

Azure is not a laggard when it comes to innovations, Azure has its own share of innovative services with more focus on developer productivity and enterprise adaption. Azure Active Directory, Azure Cosmos Database, Azure Functions and Azure Lighthouse are few of those several enterprise-focused innovative services.

Generally, Azure targets its innovations at stable markets where they anticipate greater adaption, they do not invest much on niche market areas just to appear cool. This may be because of the traditional bottom-line focused business orientation. Because of this trait, sometimes we can notice that Azure terminates few services at their beta stage without releasing in General Availability, thus focusing on stable high reach bottom-line focused innovations over diversity of the service portfolio.

Having a rich partner ecosystem is another key strength of Microsoft. This has given an unbeatable position for Microsoft in hybrid cloud market with its Azure Stack suite. Azure Stack is a portfolio of products that extends the Azure capabilities to any environment. It has three products Azure Stack Edge, Azure Stack HCI and Azure Stack Hub. In other terms, Azure Stack is Azure in different versions, loaded in different hardware and bundled together for customers having different hybrid cloud demands. This is only possible by Microsoft because of its long-standing partner ecosystem and OEM partner network.

GCP – Internet Services DNA

GCP has the DNA of an Internet services company; in fact, there is no surprise as it is coming from Google. Google leads the Internet based consumer services; we all use Google services in our day-to-day life. Internet services DNA prioritizes individual services over a whole platform, and it prioritizes B2C over B2B.

GCP is the third largest cloud provider by revenue, but the gap between GCP and Azure is big. Also, GCP has a serious competition from Ali Cloud.

GCP has all the required foundational building blocks of a modern cloud, but it lacks the rich portfolio of services what AWS or Azure has. GCP tries to sell the same thing under different packaging, one example – API management service is listed as ‘New Business Channels using APIs’ and ‘Unlocking Legacy Applications using APIs’. Those are two different use cases of the same product, but not two different services. Though some may debate, this is an approach to attract customers with two different needs, other cloud providers do not do the same trick under their list of products.

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. They were so focused on Internet based services and generating revenue by content advertisements. Individual users were more important than big businesses. When they realized big corporates are the big customers for the cloud business 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. Most of us 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 services, 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 Google seems happy with what they are doing. They are showing upward trend in the revenue, and recently won few notable enterprise customers.


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.