How Superhuman reduced AWS cross-AZ traffic by 50% with Linkerd

Superhuman’s evolving AI and global footprint 

Superhuman (formerly Grammarly) is the AI productivity platform on a mission to unlock the superhuman potential in everyone. The company was founded in 2009 as Grammarly, and recently changed its name to Superhuman after bringing together Grammarly, Coda, and Superhuman Mail and introducing its newest product, Superhuman Go.

While this has resulted in a unified productivity suite for Superhuman customers, this expanded product vision brings significant engineering complexity. Superhuman's platform engineering team is responsible for the reliable infrastructure supporting over 40 million users worldwide, spanning multiple products with different architectures and cloud regions.

Platform engineering at scale: Four specialized teams managing clusters across AWS and GCP

Superhuman's platform engineering function has grown into four specialized teams, each owning a distinct layer of the engineering lifecycle. The engineering org is structured into the following teams:

• The production engineering team is responsible for infrastructure operations, GitOps workflows, observability, and runtime management. This team was the driving force behind the Kubernetes migration and Linkerd adoption.
• The SRE team was brought in through the Coda acquisition that now integrates closely with Production Engineering
• The developer experience team focused on tooling and workflows for software engineers
• The release engineering team owns CI/CD pipelines and build systems

For their technical environment, Superhuman operates a large and growing multi-cloud, multi-region infrastructure. The core Grammarly and Superhuman platforms run on AWS, with a multi-region expansion currently underway. Docs (formerly Coda) also runs on AWS, while Mail (formerly Superhuman Mail) runs on GCP. Across all of this, the team manages 20+ Kubernetes clusters, thousands of nodes and pods, and well over 100 microservices. As the company integrates acquired companies onto the shared platform, their footprint will continue to expand.

Before the migration to EKS, the team operated hundreds of ECS services spread across hundreds of separate AWS accounts. Each of these required its own application load balancer. and custom networking configuration. Managing connectivity across these different accounts was a significant and ongoing operational burden.

The business case for EKS and a service mesh 

When the Production Engineering team built the business case for moving to Kubernetes, implementing a service mesh was a core requirement from the start. The specific requirements going into the evaluation were clear: 

• Mutual TLS for encrypted service-to-service communication
• Access control to define which services can talk to other services
• Built-in observability, including metrics and topology mapping
• Embedded load balancing to reduce reliance on costly external load balancers
• Enterprise-grade support for what would become a critical piece of infrastructure at a significant scale

Resource consumption, performance, and operational simplicity

The team ran a structured POC comparing both Linkerd and another solution. After evaluating both tools, the team decided to put it to a vote, with Linkerd as the clear winner.

The technical case was strongly in Linkerd’s favor, with the team noting that Linkerd had lower resource consumption, faster performance, and an operational model that made it easy for them to get started right away. Two additional factors helped confirm the choice for Linkerd. 

The first was HAZL, Buoyant's High-Availability Load Balancing feature. HAZL enables same-zone traffic routing, keeping traffic within the same AWS Availability Zone whenever possible and directly reducing inter-AZ data transfer costs. The team learned that most customers with large Kubernetes estates save thousands in monthly AWS cloud costs after implementing it, and they were eager to use it in their environment. 

The second determining factor was support. The team also appreciated that Buoyant and the open source Linkerd project share the same team, so the process for feature requests and escalations is straightforward and without competing priorities.

We valued Linkerd's clear vision and the enterprise support behind it. That was the decisive factor for Linkerd, alongside the technical capabilities." — Dima Shevchuk, Technical Lead, Production Engineering

Nine months of collaborative hardening and enterprise partnership

Superhuman signed a Buoyant Enterprise for Linkerd (BEL) contract nine months before formally going live, using that time to fully learn the technology, test it thoroughly, and work through issues alongside the Linkerd team.

"Working with the Linkerd team has been great. I can write anytime and get a prompt, knowledgeable reply. That support is really worth what we signed for, and I would recommend it to anyone operating at our scale." — Oleksandr (Alex) Zakhariash, Senior Production Engineer

Superhuman deploys and manages Linkerd via Helm charts, integrated into Superhuman's GitOps workflows. This is a significant improvement over the CLI-only deployment methods available when the project started. Linkerd multicluster is configured across logical "Control Plane" and "Data Plane" clusters, mTLS is enforced across all services, and metrics flow into shared dashboards used across the entire organization. Migrations for services from acquired companies are ongoing, with the team working to unify infrastructure across the expanded Superhuman platform.

The outcome: same-AZ traffic routing, mandatory mTLS, and simplified cross-cluster networking 

For an organization of Superhuman’s scale, the move to Kubernetes can be an extremely daunting process with many operational hurdles. Luckily, the team was able to quickly see results thanks to the use of the enterprise distribution of Linkerd. Some of these results include:

• mTLS is now enforced across all services, satisfying Superhuman's security requirements out of the box. 
• Service-level access control is self-service for engineering teams, configured through a simple merge request process.
• Cost savings via HAZL that allowed Superhuman to reduce AWS cross-AZ traffic by 50% and drastically cut the number of AWS Application Load Balancers, resulting in significant cost savings overall.
• Standardized dashboard for visibility into service health, traffic, and error rates the moment they onboard to Kubernetes
• Service topology mapping that provided great value during the migration, making it straightforward to understand which services were communicating and quickly identify the source of issues
• Simplified inter-service communication without requiring manual security configurations to connect services across AWS accounts. With Linkerd multicluster, teams now wire up cross-cluster communication by specifying a service name and submitting a merge request for access permissions.
• Reliability and operational confidence now that rolling upgrades are handled service by service, allowing Superhuman to update without coordinating mass restarts or risking disruption at scale.

“The move to Kubernetes was greatly improved by Linkerd, and we would absolutely recommend Buoyant for anyone looking to modernize their infrastructure.” — Dima Shevchuk, Technical Lead, Production Engineering

The roadmap: multi-region scaling, canary deployments, and advanced traffic management

Superhuman's infrastructure roadmap is ambitious, with the team actively working on multi-region expansion in AWS. They're continuing to optimize AWS costs with HAZL and exploring granular traffic splitting and canary deployments for safer production experimentation. Rate limiting and other Linkerd traffic management features are being expanded across more services and teams as migrations continue from acquired companies onto Superhuman’s unified infrastructure. Learn more about migrating to Amazon EKS with Linkerd.

‍