Gateway API Isn’t About Ingress Anymore: Building Service Networks on AWS
What if Kubernetes networking didn’t stop at the cluster boundary? Based on a hands-on workshop at AWS Community Day CEE 2026, I explore how Gateway API and Amazon VPC Lattice can turn Kubernetes resources into a common interface for building service networks across applications, VPCs, and accounts.
Series: Workshops (2 articles)
- 1Gateway API Isn’t About Ingress Anymore: Building Service Networks on AWS This article
When I first started working with Kubernetes Gateway API , I looked at it mainly as the successor to Ingress. It offered more expressive routing, better separation of responsibilities, and a cleaner API. All good reasons to use it, but after spending more time with Gateway API, I think that description is too limiting.
The question that changed my perspective was surprisingly simple:
What if a Gateway doesn't create a load balancer at all?
This became the starting point for my workshop at AWS Community Day CEE in Budapest: Gateway API Isn’t About Ingress Anymore: Building Service Networks on AWS with Amazon VPC Lattice. During the workshop, we used Kubernetes Gateway API to build private service-to-service connectivity with Amazon VPC Lattice, without putting an ALB or NLB in front of every application, using a
Service of type LoadBalancer, or adding sidecars.For me, this is where Gateway API becomes much more than a replacement for Ingress.
Gateway API is the interface
One thing I wanted people to take away from the workshop is that Gateway API doesn't define what the underlying network has to look like. It gives us an API.
GatewayClass, Gateway, HTTPRoute and the other resources describe networking intent, but what happens with that intent depends on the controller implementing the API. This sounds obvious, but it changed how I look at Gateway API.With one controller, creating a
Gateway can result in a load balancer. With the AWS Gateway API Controller and Amazon VPC Lattice , those same Kubernetes resources can describe something quite different: a service network.It is the same API, but the infrastructure underneath can be very different. That is why I no longer think about Gateway API only in terms of getting traffic into Kubernetes.
What happens when the network doesn't stop at the cluster?
Kubernetes service discovery works very well when everything lives inside the same cluster. Real environments don't always look like that. Applications can be spread across multiple clusters, VPCs or AWS accounts, and some services might run on Kubernetes while others don't.
At that point, the Kubernetes cluster itself isn't necessarily the right networking boundary. This is the problem I wanted to explore in the workshop.
We start with two applications running on Amazon EKS and build the connectivity between them using Gateway API and Amazon VPC Lattice. The important part is not that the applications can talk to each other. There are many ways to achieve that. What matters here is how we describe that connectivity.
Instead of creating the VPC Lattice configuration separately and then trying to connect it back to Kubernetes, we describe the application networking from Kubernetes. The controller takes that intent and creates the corresponding AWS resources.
Conceptually, the relationship looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Kubernetes AWS
GatewayClass
│
│
Gateway ─────────────────────► VPC Lattice Service Network
│
├── HTTPRoute ──────────► VPC Lattice Service
│ │
│ └── Kubernetes workloads
│
└── HTTPRoute ──────────► VPC Lattice Service
│
└── Kubernetes workloadsThis was one of my favorite parts of the workshop to demonstrate. You apply Kubernetes resources on one side and then inspect what appears in AWS on the other. Seeing the two together makes the controller model much easier to understand.
A different way to think about the networking boundary
We often start Kubernetes networking discussions with the entry point: How does traffic enter the cluster? Should we use ALB or NLB? Where should TLS terminate?
Those are valid questions, but they already assume that the cluster is the important boundary. For service-to-service communication, I think there is a more useful question:
Who needs to talk to this service?
Once you start there, the architecture can look quite different.
With VPC Lattice, the service network becomes the boundary connecting applications. Those applications can live across different VPCs and accounts, while access can be controlled at the service-network and service level. Amazon EKS becomes one participant in that network rather than the boundary of the network itself.
That distinction is important to me, especially when I look at this from a platform engineering perspective.
Gateway API as a platform API
This is probably the part I find most useful from a platform engineering perspective. Platform teams spend a lot of time trying to provide developers with useful abstractions without hiding so much that nobody understands what is actually happening. Networking is particularly difficult.
We can ask every application team to understand load balancers, target groups, VPC connectivity, DNS, IAM policies and all the infrastructure behind their service. Or the platform can provide an API for expressing what the application needs.
Gateway API gives us a good foundation for that because it is not specific to AWS. It is a Kubernetes project maintained by SIG Network, with a role-oriented model designed to separate infrastructure concerns from application routing. The implementation underneath can still be AWS-specific, and I think that distinction matters.
The developer works with Kubernetes resources while the platform team chooses how those resources are implemented. The infrastructure can then evolve without necessarily forcing every application team to adopt a completely different networking interface.
To me, that is a much more useful way to think about Gateway API than simply replacing
Ingress with HTTPRoute.Traffic splitting without changing the model
I also wanted the workshop to show that moving beyond ingress doesn't mean giving up the traffic-management capabilities we expect from modern application networking. One of the exercises introduces two versions of an application and splits traffic between them.
The configuration is standard Gateway API:
1
2
3
4
5
6
7
8
backendRefs:
- name: catalog-v1
port: 80
weight: 80
- name: catalog-v2
port: 80
weight: 20There is nothing particularly surprising about a 80/20 traffic split. What matters is that the application team is still describing it using the same API, while the implementation happens underneath.
This separation between intent and implementation is, in my opinion, one of the strongest ideas behind Gateway API.
Does this mean we don't need ALBs, NLBs or service meshes anymore?
No, and I think treating these technologies as direct replacements for each other leads to the wrong architecture discussions.
I still use ALBs when an application needs HTTP or HTTPS ingress. NLBs solve a different set of Layer 4 requirements. Service meshes can provide capabilities much closer to the workload and are useful when that level of control is required.
VPC Lattice solves another problem. It provides application networking across services, VPCs and accounts, and AWS supports integrating EKS workloads into that model using Kubernetes Gateway API.
I wouldn't start an architecture discussion with which technology should replace the others? I would start with a different question:
Where does the application network actually need to exist?
Sometimes the answer is one cluster. Sometimes it isn't.
Try the workshop yourself
I built the workshop to be reproducible outside the conference, so the complete material is available in the eks-lattice-gateway-api-workshop repository on GitHub. The repository contains the infrastructure, Kubernetes manifests, setup automation and the lab instructions used during AWS Community Day CEE 2026.
If you go through it, I recommend paying attention to the relationship between the Kubernetes resources and the AWS resources rather than just trying to reach the end of the lab. Create the resources from Kubernetes and then inspect both sides:
1
2
kubectl get gateway
kubectl get httproute -ALook at what Kubernetes knows about, and then look at what the controller created in VPC Lattice. That relationship is the part I want people to understand.
Once you see it, Gateway API starts looking less like another ingress API and more like an abstraction that can sit in front of very different networking implementations.
That was also the main reason I wanted to turn the workshop into this article. A 90-minute workshop gives you enough time to build something and see it working, but it doesn't always give you enough time to stop and discuss what that model could mean for the way we design Kubernetes platforms.
There is another story behind this workshop
The technical side of the workshop is only part of why AWS Community Day CEE was important to me. Earlier this year, I participated in the AWS New Voices 2026 program.
I joined because I wanted to become a better speaker. What I didn't expect was how much it would affect the way I structure technical content. As engineers, I think we have a tendency to add more: one more diagram, one more edge case, one more slide because the implementation detail is interesting. I definitely do this.
New Voices pushed me to think more about what I actually want the audience to remember when the session is over. Meridith Grundei and Gary Grundei coached us through the program, with a strong focus on audience, clarity, storytelling and delivery.
That influenced this workshop more than I initially expected. The goal wasn't for everyone to remember every VPC Lattice resource we created. I wanted them to leave questioning one assumption:
Why do we keep thinking about Gateway API only as ingress?
AWS Community Day CEE also gave me the opportunity to finally meet Meridith in person. She closed the conference with The human latency problem, an interactive keynote about something very different from Kubernetes networking: what happens when we know we should say something but hesitate to say it.
After spending weeks learning from her through New Voices, seeing her closing keynote and getting the chance to meet her in Budapest was a special way to finish the event. It also reminded me of something I had been working on throughout the program: having a technical idea is one thing; being able to explain why someone else should care about it is another.
I'm still working on the second one.
So, is Gateway API about ingress?
It can be, but I don't think that's the most useful way to look at it anymore.
Gateway API gives Kubernetes a common language for application networking, while the controller decides what infrastructure implements that language. Today, that could mean an ALB handling traffic entering an EKS cluster. It could also mean VPC Lattice connecting services across application boundaries.
I expect that distinction to become increasingly important as Kubernetes platforms stop being isolated environments and become one part of a larger application network.
So the question I would leave you with is the same one behind the workshop:
What happens when Gateway API stops at the cluster boundary, but your services don't?
That's where things get interesting.
Series: Workshops (2 articles)
- 1Gateway API Isn’t About Ingress Anymore: Building Service Networks on AWS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article