The Hidden Costs of Cloud Provider "Free" Credits

Pavel from TurboCloud — Fri, 08 Nov 2024 09:35:41 +0000

When I see posts like this one, I don't understand why people still believe in this tale about "free" credits. They say "We got $100K in free credits from AWS" or "We just got $500K in free credits from Google Cloud," and spend the whole year locking their project into a single cloud provider. After 12 months of free credits, the first bill arrives, and suddenly it's thousands of dollars for a project with just 100 unpaid users. By then, you can't easily migrate to another cloud or dedicated server that would cost just $10-80 per month, because you're not just locked into services like Lambda, Route 53, and Google Cloud Run—you also have already active users and can't pause everything for a month-long migration. This is how big cloud providers hook new customers. Sure, $250K in free credits sounds much better than $100 in DigitalOcean credits, even if your project only needs two 8 vCPU servers that cost around $20 each.

Nothing is truly free when it comes to hyperscalers (AWS, Google, Azure). Someone who has already used their "free" credits pays for your "free" credits. After your credits expire, you'll pay 3-10 times more (somebody should pay for "free" credits of new customers) than what you'd pay using cloud computing from providers like Hetzner, Scaleway, DigitalOcean, or Vultr.

A Real-World Example

A few years ago, while working on a streaming service, we received free credits and startup support from AWS. It felt amazing that AWS would give us credits for development. We paid nothing during that year of free credits, but in the 13th month, we got a $6K bill for a project with just a handful of users. Why so much? Simple: users were streaming content, and bandwidth costs were high. We also paid for managed DBs, WAF, Route53, containers, and Lambda functions.

The management board said, "That's fine, we have a grant, so we're ready to pay for AWS because many enterprises use it, and VCs recommend it." The entire infrastructure (or "chaos-structure") could have been replaced by a few open-source services deployed on a dedicated server with 8 CPUs and 32GB of memory, but nobody listened to us that time. As a result, we paid around $100K for the first year after our "free" credits expired and spent more time fixing Terraform files than doing productive work.

Most engineers accept spending 10, 20, or even 30 minutes waiting for deployments because they work regular hours from 9 to 17 and receive a salary. But as a founder, you should optimize every moment during development and avoid overengineering.

The Struggle to Scale Down

Let's return to our story. When we had just a few months left on our grant, the management board started asking us to stop and remove everything we weren't using on AWS to reduce costs. With one month remaining, we began migrating everything to Hetzner and Scaleway to eliminate AWS costs because even after three months of optimization, we still had $4.5K monthly bills. The end of the story? I believe the founder of that project still pays AWS because we couldn't stop all resources. AWS is like registering an LLC in the EU—easy to start but incredibly difficult and expensive to close.

Recommendations

Instead of applying for free credits, create accounts with providers that focus on dedicated and cloud servers/VPS like Hetzner, DigitalOcean, Vultr, and Scaleway. Check out our guide, "Choosing the Right Cloud Provider" for ideas on which cloud provider to use. Most SaaS, IoT, or web projects need just one or a few cloud servers. There are many guides on deploying runtimes, databases, and other tools on basic cloud servers with IP addresses and SSH access. For example, a server with 8-16 vCPUs can easily handle thousands of active monthly users. When you need more capacity, you can add more vCPUs or servers.

If you don't want to read guides, try our TurboCloud deployment toolkit. It can:

Deploy almost any project with Dockerfile
Provide native support for different runtimes
Work with most cloud providers
Create a virtual private cloud between all servers and local machines located in different locations
Set up WAF with predefined rules and rate limiting
Provide server statistics monitoring out of the box

All of this can be done with a single command on your server:

curl https://turbocloud.dev/deploy | sh -s -- -i server_ip

For more details about TurboCloud, check our documentation. Feel free to contact us at hey@turbocloud.dev with your feedback and questions.

Deploy static websites and web apps anywhere in minutes with TurboCloud

Pavel from TurboCloud — Tue, 28 May 2024 21:05:41 +0000

Big cloud providers want you to think that the cloud is super complicated so they can sell their services. But that's not true at all - the cloud is just remote machines connected together. We at LocalCloud want to simplify deployments and show that the cloud industry is overengineered nowadays.

That's why we developed what's probably the lightest and simplest way to deploy web projects anywhere - VPS, cloud server, dedicated server, or even on-premise. No configuration, no Git required, not even CLI setup - just go to the project's root folder and run one command. Meet TurboCloud - https://github.com/localcloud-dev/turbo-cloud

Main Advantages

Zero dependencies - your project will be available as long as your cloud provider is live
Daemonless
Unbelievably lightweight - one script, less than 10KB
HTTPS for custom domains
Works with WebSocket services (ws:// and wss://)
TurboCloud itself uses very few resources
Fully predictable cloud costs (with cloud providers from "Recommended Cloud Providers" below)
Zero DevOps knowledge required
Only one command to deploy from your local machine
Works with virtually any cloud provider
No Docker registry required
Zero downtime deployments

A few examples how it works

How to Deploy Static Websites

Order a VPS, cloud server, or dedicated server with a public IP address, fresh Ubuntu 22.04, and SSH access from any cloud provider (see Recommended Cloud Providers section below).
Add an A record with the IP address of your new server to your custom domain (DNS A record: your_domain.com or subdomain.your_domain.com -> IP address of the server created in step 1)
In the root folder of your static website project, run the following command (replace ip_address_of_server, expose_port_from_dockerfile, and your_domain_without_http_https with the real values):

curl https://raw.githubusercontent.com/localcloud-dev/turbo-cloud/main/turbocloud | sh -s -- -i ip_address_of_server -d your_domain_without_http_https -t static -p expose_port_from_dockerfile

Open the URL you set with the -d flag in step 3 in your browser

How to Deploy projects with Dockerfile

Order a VPS, cloud server, or dedicated server with a public IP address, fresh Ubuntu 22.04, and SSH access from any cloud provider (see Recommended Cloud Providers section below).
Add an A record with the IP address of your new server to your custom domain (DNS A record: your_domain.com or subdomain.your_domain.com -> IP address of the server created in step 1)
In the root folder of your project with Dockerfile (Dockerfile should be in the project's root folder), run the following command (replace ip_address_of_server and your_domain_without_http_https with the real values):

curl https://raw.githubusercontent.com/localcloud-dev/turbo-cloud/main/turbocloud | sh -s -- -i ip_address_of_server -d your_domain_without_http_https -t dockerfile

Open the URL you set with the -d flag in step 3 in your browser

Full documentation can be found at turbocloud.dev

Forem: Pavel from TurboCloud