Meet Expel: The security operations leader and its cloud-native infrastructure

Expel is a security operations company on a mission to make security more effective for organizations of all sizes. They offer security services for managed detection and response (MDR), phishing, and threat hunting, as well as a Security Operations Center platform and additional technology that enables the SOC. Their unique approach to MDR has propelled them to the Leader category in the Forrester Wave for Managed Detection and Response Services, placing them on lists like “The 20 Coolest Endpoint and Managed Security Companies of 2026” by CRN.

The engineering team at Expel is made up of ~80 engineers, including a platform team of twelve. Expel runs a sophisticated, cloud native infrastructure built on Kubernetes, managing hundreds of microservices across two clusters in both production and development environments.

A strategic cloud expansion and the focus on inter-service security

Running services in AWS

After spending four to five years building its platform on Google Cloud Platform (GCP), Expel made the strategic decision to expand cloud partnerships and run workloads in AWS. The primary driver was a desire to become an AWS Marketplace partner, which required establishing a meaningful AWS footprint beyond their existing CloudTrail log ingestion. AWS also offered services and features that would benefit Expel's growing platform.

Solving challenges through a service mesh  

The need for a service mesh was not new at Expel. Engineers had been discussing it for years before the expansion to AWS began.

Furthermore, teams requiring advanced capabilities like gRPC load balancing had been forced to build and maintain custom solutions. This pattern of creating one-off components was unsustainable as the platform scaled. To address these issues, the team defined a clear set of requirements for their new service mesh:

• mTLS encryption 
• Network policy enforcement 
• Traffic shaping capabilities
• A standardized, automatic metrics layer for out-of-the-box observability without extra configuration

Risk assessment: Why Linkerd's operational simplicity outweighed Istio

With this list of requirements and an ambitious timeline for expansion, they decided to evaluate both Linkerd and Istio. Technical reputation weighed in Linkerd's favor. An engineer who had attempted an Istio migration in a previous role reported that activating Istio had immediately broken services, requiring a rapid rollback. Not only had things gone wrong during this engineer's time testing Istio, but the process to undo what had broken was also extremely tedious. The performance documentation Istio provided during the evaluation did not help Istio’s case. The team at Expel felt Istio’s materials were thin on technical specifics and not the kind of evidence that would convince a team of rigorous engineers.

"Talking to the sales teams at Buoyant was a totally different experience. With Istio [vendors], it was very much a challenge to get direct technical answers from their team. With Buoyant, we were able to get the answers we needed around cost, time for a POC, and the technical documentation needed to get started quickly. The Buoyant team was made up of people we were excited to work with, and the environment just felt really collaborative." — Adam Glenn, Engineering Manager at Expel

More broadly, the Expel engineering team had heard that Istio is extremely hard to get right the first time. Linkerd, by contrast, had an internal reputation for just working. During the Buoyant evaluation, they clearly saw a path to get Linkerd working promptly and with less operational overhead.  

Go-live in a hackathon: Implementing Linkerd in three hours

During a team offsite, the implementation of Buoyant Enterprise for Linkerd (BEL) started as a hackathon and yielded real progress for the team. With no mission-critical workloads yet running in AWS, the stakes were low enough to “just try it." Engineers pulled up Linkerd's public documentation, and within three hours, BEL was running. The team did hit one issue when a configuration change in Kubernetes briefly impacted their Kong API gateway. However, the nature of the problem was immediately understandable from the documentation. The team diagnosed it within ten minutes, rolled back, addressed the root cause, and moved forward again with confidence. Rather than shaking anyone's trust in Linkerd, the incident reinforced it.  "That was when the team was won over,” said Adam Glenn. “They knew that if something went wrong with the service mesh, Linkerd actually made it comprehensible and fixable.”

From that point on, onboarding followed the pace of the AWS expansion itself. As services were deployed to AWS, they were brought onto the mesh. Expel also extended the mesh across cloud boundaries. GCP-resident data services were connected to AWS workloads through Linkerd-managed proxies and forwarding services, enabling encrypted, mesh-managed communication across cloud environments during the transition period.

Developer adoption required minimal effort. Expel's teams were already accustomed to applying labels to Kubernetes workloads for other purposes, and adding Linkerd proxy injection followed the same familiar pattern. Engineers working alongside platform team members needed only one or two pairing sessions before they could operate independently.

Securing AWS: Default encryption, real-time visibility, and standardized observability

1. Security and peace of mind: Encrypted service-to-service traffic is in place by default.
2. Real-time Service Topology Visibility: Buoyant Cloud's topology map became an instant go-to across the engineering org because it enables real-time traffic visualization and visibility into which services are communicating with other services. 
3. Improved Policy Enforcement: The topology map has also created a pathway toward improved network policy enforcement. With a clear visual representation of service communication, the team can now thoughtfully define and tighten policies with an informed approach.
4. Standardized Metrics and Alerting: Observability that was once scattered across GCP metrics and Datadog is now centralized in Buoyant Cloud's UI. Additionally, engineers can deploy a service and automatically get standard metrics.

What’s next for Expel?

As the expansion to AWS continues, the Expel team anticipates additional benefits across its organization from Linkerd.

• Reduced cloud spend: As Expel expands its footprint across multiple availability zones within AWS, they expect Linkerd's ability to intelligently balance HTTP and gRPC traffic with built-in zone awareness (through a feature called HAZL) will substantially reduce data transfer costs. 
• Offloading costly tools: Previously, the team had built and maintained a costly gRPC load balancer, costing thousands of dollars a month. With Linkerd, the team is expected to significantly reduce costs associated with cross-AZ traffic.
• Organic Demand for Broader Adoption: Perhaps the strongest indicator of Linkerd's value at Expel is the demand from teams that aren't yet on the mesh. Engineers whose services are still running in GCP are actively asking to be onboarded in Linkerd. "There's a hunger for the metrics and the UI,” said Glenn. “People who aren't even deploying their stuff to AWS right now are asking how soon they can use BEL just from the positive feedback from their colleagues.” 

Linkerd, the proven service mesh for a complex multi-cloud expansion project

For Expel, Buoyant Enterprise for Linkerd has delivered exactly what they have needed and has built a lot of internal trust. In a complex multi-cloud environment, one that demands precision, security, and operational stability. Linkerd has proven to be the best service mesh for AWS. Learn more about getting started with Linkerd with AWS.

"Some things, you want them to just run. They don't make a lot of noise. They're easy and do the job well, and you don't even have to think about them. That's how Linkerd is. It just works." — Adam Glenn, Engineering Manager at Expel