How Compiler Explorer Runs on AWS in 2026
- ID: 39f035de
- Original URL: https://xania.org/202608/how-compiler-explorer-runs-on-aws
- Author(s): Matt Godbolt
- Date: 2026-08-06
- Category: infra
- Source type: article
- Tags: compiler-explorer, aws, spot-instances, cefs, developer-tools
- Quality score: 4/5
- Fetched at: 2026-08-06T15:43:42+00:00
- Obsidian evidence: OpenClaw定时任务/AK-RSS-Digest（89源精选）/2026-08-06-AK-RSS-Digest.md
中文导读
Matt Godbolt 更新 Compiler Explorer 在 AWS 上的十年架构：CloudFront/WAF 到 ALB 多舰队，生产几乎全靠 spot 与蓝绿部署；编译器存储从 EFS 到 SquashFS，再到内容寻址 CEFS + autofs 按需挂载，解决几千个编译器版本的启动和存储成本。文中公开七月约 523 万次编译、约 3600 美元月费和约 0.0007 美元/次编译，是少见的公共开发者工具运维复盘。
为什么值得关注
高密度 infra / operator 笔记，可作为开发者工具站点运维样本。
English Summary
Matt Godbolt details Compiler Explorer’s AWS architecture in 2026: CloudFront/WAF, ALB fleets for multiple target classes, mostly spot instances, blue-green deployment, CEFS content-addressed compiler storage, and public traffic/cost figures.
原文摘要 / Source Excerpt
How Compiler Explorer Runs on AWS in 2026
原文链接: https://xania.org/202608/how-compiler-explorer-runs-on-aws
How Compiler Explorer Runs on AWS in 2026
Written with LLM assistance. Details at end.
I’ve been meaning to write an update on how Compiler Explorer actually runs on Amazon’s cloud, and it’s been sat on my list for a good while now, somewhere behind the other random things that take up what laughably I refer to as my spare time1.
The last time I wrote about this was 2016, when the whole site was a load balancer, a couple of instances and some Docker containers I built on my laptop. I wrote a much longer how it works last summer, but that one is mostly about Compiler Explorer and only incidentally about the cloud it sits on.
It’s no secret that we run on AWS, and none of it is hidden: the infra repository has all the terraform, the install scripts and the ce command line tool we drive the whole thing with, so if you’d rather read the real thing than my description of it, help yourself. So this one goes the other way round, through the Amazon services we lean on, roughly in the order your compile request runs into them.
Getting your code as far as our servers
Your browser talks to CloudFront, Amazon’s CDN. We run two separate CloudFront distributions. The one in front of godbolt.org mostly just hands requests on to our load balancer, caching what it sensibly can and compressing things on the way back out2. The bulky static stuff lives in an S3 bucket behind a second distribution at static.ce-cdn.net: the compiled JavaScript, the images, the web fonts. Much the largest part of that is Monaco, the editor component out of Visual Studio Code, which is what gives you the syntax highlighting and the squiggly underlines and the rest of it. It’s a lot of JavaScript to send someone who only wants to look at some assembly, so it’s worth having it cached near them.
Sitting in front of that is WAF, doing our rate limiting. Our limits are _very_ simple and _very_ high, mostly because we used to be stricter and it kept catching C++ trainers: a whole classroom behind a conference’s NAT looks like a single very keen IP address. We could probably do something cleverer with fingerprinting, but raising the limit was easier and it hasn’t been a problem since.3
Rather a lot of fleets behind one load balancer
Behind CloudFront is a single Application Load Balancer. It works out from the path which cluster a request is for, and then picks a healthy instance in that cluster to send it to. Almost everything has no special prefix at all and goes to the production fleet, which is where the overwhelming bulk of the traffic ends up. /beta* and /staging* go to the beta and staging fleets4. /winprod* goes to a fleet of Windows instances running MSVC, /aarch64prod* to Graviton machines that run ARM code natively rather than under emulation, and /gpu* to machines with real NVIDIA cards in them5.
Each of those is an Auto Scaling Group, and these days each one is doubled up: a blue and a green. To deploy, we bring up the other colour, wait for it to go healthy, point the load balancer’s target group at it and drain the old one. If it’s wrong, we point it back. Before that, deploying meant a rolling restart of the fleet with our ce command line tool, one instance at a time. That worked well enough, but backing out a bad release meant rolling the whole fleet forward again onto the previous version, which is a bit slow when you’ve just broken the site.
The scaling itself is simple: we just try and keep the average CPU load below a threshold. We’ve kicked around more sophisticated ideas but this one is supported out of the box6.
Renting the b
...[excerpt truncated, fetched body length=25816 chars]...