The Key Factor Behind TablePlus's DDoS Resiliency

TablePlus published a blog post on how they did nothing to handle a DDoS attack. Their blog post titled “We are under DDoS attack and we do nothing” - published at the end of March 2024 - caught my eye when it quickly reached the top of Hacker News.

It explained the simplicity and effectiveness of their setup—a simple monolith web application written in Rust/Golang and hosted on a VPS server. Nothing fancy—no WASM, Docker, Kubernetes, or other buzzwords (not even LLM/AI-powered 😅).

TablePlus didn’t disclose a lot of technical details. I had no clue what API endpoints were attacked or the flow of the DDoS attack. All the blog post mentioned was: “In the last 5 days alone, [attackers] tried to download it more than 800K times - our setup file is approximately 200MB per download … They have attempted to download the setup file millions of times (800,126 times in the last 5 days, totaling approximately 6 million times in the latest 30 days)”.

Recreating the attack flow

While collecting the technical breadcrumbs in the blog post, I stumbled upon a Hacker News comment suggesting attackers might be downloading their Windows app (around ~183 MB in size) multiple times. Downloading Windows binary matches the blog post’s description, “our setup file is approximately 200MB per download.”

Let’s look at the happy flow to download the Windows TablePlus binary.

We visit the website. Since I’m using a MacBook, I click on “Other Downloads” and then on “Download for Windows.”

This button makes a GET request to the URL https://tableplus.com/release/windows/tableplus_latest, which redirects to the Windows binary’s location in the https://files.tableplus.com/ subdomain.

That’s it.

Each IP in the DDoS attack might have hit the tableplus.com URL, got the redirected URL to files.tableplus.com, and downloaded the file.

Devil in the details - Cloudflare

You’ll find the following statement in the middle when reading the blog post.

We prefer Cloudflare R2 and its CDN over Amazon CloudFront + S3 for both cost savings and protection.

What if I told you the DDoS situation was handled just because they decided to go with Cloudflare?

Remember the subdomain files.tableplus.com where the Windows binary was stored? It’s just a DNS record pointing to Cloudflare R2. 🤦

What’s the real problem with DDoS, again?

DDoS attacks are nothing new. It has been there for decades now.

During the pre-cloud era, the problem with DDoS was majorly exhaustion of server-side resources. If you had ten servers unable to handle traffic during an attack, your site would go down, and you would lose business from genuine customers.

The most significant damage from DDoS attacks was just a loss of business. Maybe you also experienced a slight increase in your IT bill due to increased bandwidth usage.

But now, with almost every company locked onto a cloud platform, the problem with DDoS is more than server-side resource exhaustion. It also includes excessive resource (aka auto-scaling) and bandwidth usage.

Will backend infra auto-scales prevent downtime? In most cases, the answer is still No.

Even with autoscaling and high resource usage during a DDoS attack, multiple reasons can cause downtime, ultimately leading to business loss.

Your EC2s autoscale until they hit your AutoScalingGroup’s Maximum capacity. Your concurrent execution of lambda functions gets throttled after hitting the max quota of 1000 executions. Your app might scale well, but your database connectivity becomes a bottleneck, or vice versa. There can be many ways DDoS leads to downtime.

What if your app is entirely built on abstracted cloud services (S3, DynamoDB, etc) that autoscales based on load?

DDoS attacks leading to server-side exhaustion are no longer valid with abstracted cloud services. Even if DDoS occurs, the cloud services will handle the load to a great extent before the cloud provider’s security team kicks in.

Abstracted services might prevent downtime when configured correctly and usage is under the allocated quota. But remember the elephant in the room—bandwidth usage. Cloud providers are infamous for their data egress costs. Even if you toss a DDoS attack, your cloud bill will bite you back.

Okay. In short, DDoS attacks can significantly increase your cloud bills along with possible downtime, which may be worse for many early-stage startups than losing a few customers.

What if TablePlus did it differently?

Was choosing Cloudflare the critical factor in DDoS resiliency?

Let’s experiment. What if TablePlus’s infra was hosted on AWS? What’s the impact of similar DDoS? Can TablePlus enjoy “doing nothing” during DDoS?

A small note before continuing.

TablePlus.com is a relatively static website. Also, TablePlus’s blog post always mentions the phrase “attempted to download.” A million attempted downloads doesn’t mean a million successful downloads. For the price calculations ahead, let’s stick to the following TablePlus screenshot: 7.8 TB of bandwidth was transferred to DDoS IPs in the UK and Germany.

For simplicity’s sake, let’s:

• ignore the cost of the EC2 instance and any of its egress costs
• assume that TablePlus performant Golang/Rust binary can handle 1000s of requests without the need for EC2 autoscaling
• ignore the number of requests mentioned in the screenshot to AWS services like CloudFront and S3.

The following is just an estimation of monetary loss. It will not be accurate as the blog post doesn’t disclose the total requests and bandwidth transferred during DDoS.

What if TablePlus hosted files on S3?

Storing a 200 MB binary file on an S3 bucket is quite negligible. Let’s look at S3’s data transfer charges.

Assuming the S3 bucket is in the us-east-1 region, the data transfer cost for the first 10 TB is $0.09 per GB.

So, 7.8 TB of data transfer translates to 7800 GB * 0.09 = 702 USD burnt due to DDoS.

In case the bucket was in a different region, the cost would be different:

• Jakarta (ap-southeast-3) - $0.132 per GB (1029.6 USD cash burnt)
• Singapore (ap-southeast-1) - $0.12 per GB (936 USD cash burnt)
• Melbourne (ap-southeast-4) - $0.114 per GB (889.2 USD cash burnt)

What if TablePlus hosted files on S3 and added CloudFront in front of it?

CloudFront data transfer cost is dependent on the region where the downloads occur. If a user downloads a file from the US, it’s $0.085 per GB.

If another user downloads the same file from Japan, it’s $0.114 per GB.

If a user downloads from Europe, it costs $0.085 per GB.

Let’s recalculate the cost: 7.8 TB * $0.085 per GB = 663 USD cash burnt due to DDoS.

If they were on AWS, TablePlus might burn at least 650 USD in data transfer charges because of this DDoS attack, given that they are using CloudFront on top of S3. This rate can get even higher in AWS if you have creative solutions (Lambda invocations, Lambda@Edge, etc.).

TablePlus saved all this money because of one critical decision - using Cloudflare - R2 for distributing binaries and CDN for caching.

Cloudflare R2 does not charge for egress bandwidth. If you host a 1 GB file on Cloudflare R2 and download it a few thousand times, you will have $0 in egress charges. So, a 7.8 TB data transfer to DDoS IPs from the UK and Germany is still $0.

You can configure Cloudflare CDN to cache most static content (images, JS files, etc.) so the bandwidth provided by your VPS/cloud provider isn’t exhausted during a DDoS attack.

While using Cloudflare (R2 and CDN) was the critical factor that allowed TablePlus to stay calm during a DDoS attack, the blog post covers many more tips, like indexing your database, keeping the central database separate from the logs/usage database, etc.

While I agree with those best practices, I can’t endorse them. They never mentioned that DDoS didn’t affect their DBs only because of the suggested tweaks. The blog doesn’t even say if the DDoS attack abused their database-interacting APIs in the first place. Despite these performance tweaks, if their infra were on AWS, their cost would have increased because they did nothing.

What would I do differently?

TablePlus.com majorly looks like a static site. I wonder if the webpages interact with some database in the backend before rendering.

If I need to host such a static website, I’ll use static website builders like Hugo or Jekyll and host it on Cloudflare Pages (instead of a VPS server). Cloudflare pages can handle unlimited requests and unlimited bandwidth at just $0. Cloudflare will take care of a DDoS attack.

PS: With Cloudflare R2, you can safely ignore Class A and Class B operations, as their costs are minimal. Class B operations that occur when downloading objects are charged at just $0.36 / million requests only after you use the free 10 million requests/month.

Talking about the limitations of Cloudflare Pages - if I exhaust the number of builds in the free plan, I’ll look at cost-friendly hacks like hosting the static website on Cloudflare R2.

Hope you liked my blog post. Please share this blog post with others who would find this useful.

If you have any doubts, feel free to reach out on LinkedIn.