Why Cloudflare has changed the way I build infrastructure

I am Sam Roberts, a DevSecOps engineer, and I joined the team at RADAPEX a little over a month ago. At that time, as my first contribution, I was asked to architect a multi account strategy for AWS in order to lay the foundations for designing and building infrastructure to self host multiple services which would be used exclusively by our team.

Early on in planning and discovery, I came across Cloudflare and it has completely reshaped how I think about building production systems.

The internal platform I briefly mentioned, which I’ll refer to as “project 1” for the rest of this blog, is an environment for RADAPEX that runs multiple docker container services from a single EC2 instance, to be used solely by our internal team. This is therefore not available to the public, access needs to be locked down, the infrastructure must be reliable and secure. I have also built and hosted a static website for a small local business, free of charge, as a way of giving something back to the community. I did this in my own time using Astro. It is the first time I have used Astro too, but that is a story for another day. Whilst the latter is not a RADAPEX asset it is worth mentioning for reasons that will become clear shortly. I’ll refer to this as “project 2”.

Both are live.

Both are production grade.

Both are now running comfortably behind Cloudflare.

We have all heard a lot about them recently in the news, but what services do cloudflare offer?

Cloudflare is essentially one large global reverse proxy. Yes, they offer a broad catalogue of products and services, some of which I will touch on in this blog, but once you start thinking of it as a reverse proxy it becomes a fantastic, low maintenance way to secure entry to online endpoints. Project 1 and project 2 are very different but the same set of cloudflare building blocks works for both a multi container internal platform and a small public website.

It means the complexity that usually comes with scaling up infrastructure can often be handled in exactly the same way as a simple project.

PROJECT 1

For project 1, I rely heavily on Cloudflare Tunnel. At a high level Cloudflare Tunnel works by establishing an outgoing connection from your private infrastructure (either on premises or cloud) to Cloudflare’s edge infrastructure. All of our services in project 1 live on a single EC2 instance in a single private subnet. There is no inbound access except traffic that comes through the tunnel. Cloudflare handles the secure outbound connection and presents the services externally without me ever needing to expose an inbound port/ open a security group. Our AWS VPC stays completely private. The platform stays secure. The whole thing feels far simpler than the traditional set up which would usually involve a costly site to site VPN and significantly more complex terraform configurations including a load balancer and additional networking components. When you work in an environment where cost, simplicity and reliability matter this makes a real difference.

PROJECT 2

Project 2 sits at the opposite end of the scale in terms of complexity and impact. It does not have multiple moving parts. It does not have internal docker networks, database connections or strict access restrictions. It is a single static website hosted on an S3 bucket in London. Yet it benefits from the same Cloudflare features which reduce operational overhead, brings down cost and improves page loading speed. One such feature is Cloudflares caching layer which can be configured with surprising granularity. With just a few tweaks of the caching rules the S3 bucket barely gets touched and Cloudflare serves almost everything directly from edge locations, for free. I have also configured a firewall rule within Cloudflare to prevent anyone (or any “thing”) from hitting the S3 endpoint directly. Everything now HAS to go through Cloudflare. As well as reducing cost, this improves security, because cloudflare absorbs and filters DDoS attacks, blocking malicious traffic long before it gets near the S3 bucket. For something so modest in size it now behaves like a site with a fully optimised and globally distributed infrastructure. Building that out with only native AWS tooling would come with huge additional cost and additional maintenance (think cloudfront, WAF, shield advanced etc).

Both projects also take advantage of Cloudflare DNS (the fastest in the world according to cloudflare) and Cloudflare managed TLS certificates. This keeps everything consistent and easy to manage. Perhaps more importantly, every feature I have used is included in the free plan which only strengthens my view that Cloudflare will be at least my first thought, if not my last, for almost every architectural decision going forward.

I used Cloudflare on project 2 as a direct result of how easy it made project 1. Seeing how much I now depend on it after such a short period of time has made the global fallout from their recent outages feel far more understandable. When parts of the internet briefly disappear it seems dramatic from the outside. After working with Cloudflare it is obvious why the impact is so wide. So many people rely on it in so many different ways. In my case I will continue to use it confidently. The benefits far outweigh the occasional disruption.

One thing I did consider carefully is that Cloudflare decrypts traffic before forwarding it through the tunnel. I discussed this at length with our team of senior engineers and documented the pros and cons. For most workloads this is perfectly acceptable and is conceptually no different to what happens when you push code to GitHub, where your traffic must be inspected and routed. I am merely mentioning it because it is a design detail worth acknowledging when you have strict compliance requirements.

Both of these projects look and behave as if far more time and money went into them. Project 1 is secure and simple from a documentation POV. Project 2 is fast, resilient and practically free (we’re talking pennies each month at most).

Cloudflare has made all of this possible with far less effort than I expected and for a fraction of the cost.

I went into this month trying something new, desperate to make an impact for my new employer.

I have come out of it with a set of tools that I plan to use for years and a spring in my step, thanks to delivering everything outlined in the spec for significantly less than the expected cost.