Optimizing cloud spendings, practical guide

When it becomes expensive?

There are many factors that contribute to increased budget. We'll cover a few most significant ones.

High volume of traffic

It should be obvious that when your website experiences a surge in traffic, the number of requests to your backend services, API calls to 3rd party vendors, and database queries also increases. This in turn leads to spiking costs for related services such as Content Management Systems (CMS), video hosting, or polling services, for example.

Unoptimized functionality

Usually website hosting providers charge backend workload resources separately, on per second basis. Heavy functionality, or slow API calls to 3rd party vendors will always contribute to the cost of compute resources. It is one of the most "popular" reasons for a blown budget. Especially for younger companies, which move fast and break things.

Too much of the edge

Edge computing is a service which offers CDN edge servers for running your workload (which is required to be very limited in functionality). The upside is obvious — the results of the workload reach the end user much faster than if it was run in traditional data center. The caveat is the cost. Running too many edge functions will definitely soon become expensive.

Graphical assets

Serving heavy, high-resolution images without optimization is a silent budget killer. Apart from impacting website load times, it also increases the data transfer volume over CDN network. Some cloud providers offer automated tools for image compression, but if not leveraged effectively, the cost of compute resources required to resize and optimize images on the fly will start draining the budget.

Having questions? Talk to us.

Get in touch

Common ways to optimize

There are a few of them. Cache as much as you can, monitor and tune up your workload, switch to bigger general purpose cloud provider (e.g. AWS or Google Cloud Platform), pick a website hosting platform which suits you best. Let's dive into each one of these methods.

Cache everything!

Caching is one of the simplest and most impactful ways to reduce server load and cut the costs. In case of a typical website, where business logic is not that complicated, developing a caching strategy should not be a difficult task. It could be as simple as this:

• Cache at the CDN level: A request served by CDN caching layer does not touch your website at all, and can eventually be a huge budget saver. However, be careful with full-page caching, as it may require some invalidation tactics.
• Database calls: Database queries are slow and consume resources of your DB. Caching DB queries is the best way to reduce load on DB.
• Vendor requests: API calls to 3rd party vendors are usually much slower than queries to your DB, which in turn increase duration of running your workload. Try to come up with some reasonable caching interval, and do more than a few vendors API calls per hour.

Monitor and optimize your workloads

Optimizing your business logic code is a more complex, and resource consuming process. It would be a good idea to set up the cache first, as it's a much simpler task.

However before optimizing anything you need to know where your bottlenecks are. Set up observability tools to monitor your resources and identify bottlenecks. Usually these are slow http requests (to vendors or database), but there might be other reasons as well — something specific to your business logic.

Pre-build assets

Very often deploying a website means building its assets, such as images, or scripts, or entire static pages. You need a deployment pipeline in order to do this. Pipelines offered by niche providers may become expensive as your team grows. Such vendors as GitHub, or GitLab, or even AWS with its CodePipeline service offer a more competitive prices compared to niche web hosting players.

For example, GitHub charges $4 per user, and $0.008 per minute for Linux runners. It also offers 3000 minutes per month for free. On the other hand Netlify charges $19 per user, $0,014 per minute of a build runner, and offers 25000 minutes for free. I think it's clear that as the dev team grows Netlify becomes less and less appealing from a budget perspective.

Switch to a large cloud provider

Web hosting providers rely on larger providers like AWS or Google Cloud Platform (GCP) for their infrastructure. If your team is proficient enough, consider switching directly to AWS or GCP to eliminate middleman costs. Another benefit of running web workload in your cloud is security. So, if your website or web app performs critical tasks for your business, it's better to have full control over permissions and data.

Idea of running web workload in the cloud instead of website hosting providers is not that bad. You can even find frameworks in different programming languages which assist in it. For example, have a look at SST . It is ideal for a website, or even a web app with broader requirements to resources.

Choose the right vendor for your needs

Your team might have different requirements for build and runtime environments. You should consider these requirements while choosing a vendor for the website or web app. While choosing the vendor compare pricing, as well as the features offering. Here are solid options for different use cases:

• Vercel - edge-based websites with zero-config deployment, the easiest way to publish a website.
• Netlify - the closest competitor of Vercel.
• Render - best for flexible app hosting with competitive scaling options.
• Surge - a lightweight option for static web publishing.
• AWS Amplify - excellent for scalable, full-stack applications that integrate seamlessly with AWS services.

Carefully evaluate each vendor based on your long-term goals before making your choice.