Atlassian's edge platform — a deep dive on the architecture

Vasilios built Atlassian's broker as a Python web app. The first version used connexion, a library that reads an OpenAPI spec and wires up Flask routes for you. It later migrated to plain Flask, then to FastAPI, which is where it still lives.

The broker's internal architecture is the canonical async-job-queue setup:

When a developer asks for a load balancer, the FastAPI process doesn't try to do the work in-band. It drops a task onto SQS, records "pending" in DynamoDB, and returns immediately. A worker picks the task off SQS, does the side effects (DNS records, a CloudFront distribution, whatever), and writes the resulting state back to DynamoDB. The client polls the broker until the status flips to ready or error.

Nothing exotic here, and that's the point. The broker is a thin, boring control surface. The interesting work happens downstream.

At some point an architect proposed a bigger idea: rip out Atlassian's commercial, license-fee load balancers and replace them with a fleet of open-source proxies the platform team would own end to end.

They chose Envoy. If you've used Nginx, Envoy is in the same family but with one critical difference: it has a dynamic configuration API. You can stand a proxy up once and reconfigure it at runtime (new routes, new clusters, new TLS certs, new rate-limit rules) without a restart.

That is the entire reason self-service works. Without it, every developer change would mean a deploy of the proxy fleet, which means a ticket, which means it isn't self-service — it's just a self-service-flavoured ticket queue.

Atlassian's xDS control plane is its own Python service, also FastAPI. Vasilios open-sourced it on Bitbucket under the name Sovereign.

Sovereign's job is to translate the broker's view of the world into Envoy configuration. Three inputs, one output:

• Templates. Jinja-style descriptions of Envoy resources (clusters, routes, listeners) with placeholders for the parts that vary per service.
• Context. The dynamic data that fills those placeholders. Some of it comes from the broker's DynamoDB, some from S3, some from elsewhere.
• Polling. Sovereign periodically refreshes its context from those sources, re-renders templates, and serves the resulting Envoy resources over the xDS API.

When a developer's request flows through broker → SQS → worker → DynamoDB, Sovereign eventually picks up the new state and pushes a fresh config to the relevant Envoy proxies. The proxy starts routing the new traffic. No restart, no manual change, no ticket.

The full picture so far:

One thing worth flagging: a poll-based control plane sounds primitive next to xDS's streaming model, but it works, and it's easier to reason about than push-based reconciliation. I'd take this over a more clever design.

The Envoy fleet itself was provisioned with CloudFormation. Plain infrastructure-as-code, no surprises. The resources are the ones you'd guess: VPC, subnets, internet gateway, security groups, IAM role, key pair, Auto Scaling Group, an NLB in front (layer 4), ACM certs, Route 53 records.

The scale he mentions: roughly 2,000 proxies across ~13 regions. The ASG is the unit of fleet management. What makes the fleet identical and reproducible is the AMI those instances boot from.

The AMI is its own pipeline. Two tools:

• HashiCorp Packer drives the workflow. It launches a temporary EC2 instance in a dev account, runs a provisioning step, then snapshots the instance into an AMI.
• SaltStack, a configuration-management tool in the Ansible/Puppet/Chef family, does the provisioning step itself: install packages, drop config files, enable services, declaratively.

What goes onto the image:

• Envoy itself, installed and pre-configured
• Logging agents
• Security hardening
• Network tuning
• Container runtime
• Observability agents for logs, traces, and metrics
• The sidecar binaries (more on these below)

CloudFormation references the resulting AMI ID. When the ASG launches an EC2, the instance comes up with everything already on it; runtime parameters like secrets and keys are injected at boot. Within a minute or so it's accepting traffic.

Once the migration was done, the team had something powerful: every public request from every Atlassian customer flowed through the same Envoy fleet before it hit a service. Anything you implement there, you don't have to implement (badly, inconsistently, and a thousand times) inside every backend team.

So they pushed cross-cutting concerns to the edge:

• DDoS protection: CloudFront sitting in front of the NLB. Built by a colleague.
• Access logging: native to Envoy via its HTTP Connection Manager filter. A developer submits a tiny JSON config; the templates expand it into the full Envoy access-log setup.
• Authentication: a sidecar Vasilios wrote in Rust, running on the same instance as Envoy.
• Authorization: a sidecar built by another team, same pattern.
• Rate limiting: a sidecar built by yet another team, same pattern.

The mental model:

When a request lands, Envoy hands it to the auth sidecar to verify the user, the authz sidecar to check permissions, and the rate-limit sidecar to enforce quotas — all before the request reaches the backend. The backend just sees an authenticated, authorised, throttled request.