Whether for profit or nonprofit, not every organization will need to “go to the cloud” and utilize a dedicated cloud platform.  Some organizations will learn to trust and rely on depending on cloud platforms more than others.

The information below and the prices quoted are as of August 1st, 2025 but are also subject to change at any time.  I have used all three major cloud platforms, GCP (Google Cloud Platform), AWS (Amazon Web Services) and Azure (Azure Dev Ops – Microsoft).  I have migrated  companies from completely on-premises to a hybrid  blend of on-premises, cloud-based SaaS like Salesforce Marketing Cloud or HuBspot, and cloud-based platforms that hosted a variety of different customized apps including ephemeral cloud functions, virtual machines that served multiple websites, database storage, CDNs, and long-term cold storage.

Moving your websites from a hosting service provider to a self-managed Kubernetes cluster in GCP means that you are taking the responsibility of the infrastructure for hosting your own websites.  This may not be the best use of your limited tech team and dev resources. 

Not one cloud platform offers everything a business needs.  It is likely you will find that one is more ideal than another to fit your individual company’s skillsets, culture, software language preferences, and other factors.  For instance if you are mostly a Microsoft shop, in your systems are written in .NET, ASP, C++ or C sharp, Microsoft’s azure devops would likely be a better fit – at least for hosting those parts.

The Pitfalls of Putting All Your Eggs in One Cloud Platform Basket

There are definite pitfalls in becoming too dependent on one platform  and I am a big proponent of spreading out one’s reliance on these systems.  I think the best way to use these cloud platforms is based on the individual solutions each platform offers.  Allowing your Tech teams and other tech savvy personnel to explore and choose the best solutions that apply  at the time of application and need will protect your organization from getting too comfortable with just one solution. By encouraging your employees to gain experience and knowledge in each cloud platform, your business will be in a better position to Pivot and migrate systems, data, apps, Cloud functions and databases more quickly, causing Less pain in business interruptions into the future.

This is akin to promoting a responsive, proactive attitude, that fosters redundancies and innovation towards your tech and mitigating an over reliance on one provider that could subject you to possible pricing or security vulnerabilities.  In fact, I would recommend just out of security concerns that it makes a lot of sense to spread out your presence on different cloud platforms which will mitigate your risk in case of a hack or data breach.

Cost Overruns Can Happen Fast

Even though these Cloud platforms offer free usage tiers, I must warn you that it only takes a little bit of carelessness when experimenting to encounter massive cost overruns.   I personally witnessed a $1,600 overcharge due to releasing a proof of concept in production that ran up useless error log counts by the millions.  Even though this was thoroughly tested prior to release, the production environment had one small configuration change that could not have been tested prior to release.

You can set up budget limitations in each of these cloud platforms, but be warned this is not a guarantee that you won’t have to pay more than what you set up and in some cases it can be a lot more. this is where when you set up say calls to a cloud function that you also set up call limits.   I have seen it happen first hand  that an architect assumed the budget limitations would limit API calls but Cloud functions could easily get hammered and quickly outpace your logger’s ability to store the errors into logs  and there is nothing worse than paying for useless error logs whose source you already know the cause.

I have seen an interdependency where one Cloud function, when triggered would call on another Cloud function to fire off a new process and this would cause a circular dependency that would accelerate the number of requests until your rate limit is reached. These rate limits are typically set astronomically high by default, which is absurd. as if a cloud function you are setting up for testing needs to handle 500 concurrent calls per second?

Sometimes setting up what one would consider to be a simple thing like a new server for a website is not as simple to achieve in the cloud due to default permission and security constraints.  This of course makes sense for a company that wants to exist in the cloud in such a litigious world but these kinds of safeguards do not seem to apply by default to limit our exposure to excessive requests that  could quickly run up your Cloud bill. one of the first things I recommend doing is setting up rate limits that are modest and then if your Dev team needs to open them up, insist on them  raising the limits slowly and carefully.

Besides limiting your calls across a certain period of time is also helpful for debugging and simulating real world scenarios where apis or interconnectivity between different systems are never 100% reliable. 

These kind of horror stories aside, I would highly recommend exploring using these platforms based on prioritizing each solution your business needs that will best address your organization and operational pain points.