From Network Plumbing to Application Intent: What AWS Networking Reveals About Infrastructure's New Role

Rob Kennedy, AWS Vice President of Network Services, opened his re:Invent 2025 keynote with a simple metaphor: atoms bond into molecules, molecules combine into structures, and those structures become complex organisms. The implication was clear, networking is no longer about connectivity. It’s about intent.

For the last two decades, we’ve built AWS infrastructure with network topology in mind: VPCs, subnets, routing tables, security groups. We managed how data moved through our systems. But something shifted this year, and if you missed it in the keynote announcements, it matters more than you probably realize for how you architect going forward.

The real story isn’t about faster fiber optics or bigger AI clusters. It’s about a fundamental reimagining of who owns networking decisions and I believe it’s going to change how infrastructure leaders think about their role.

The Old Model: You Own the Network Topology

For years, infrastructure teams lived in a specific world: we designed network architectures. We agonized over CIDR blocks, planned route tables, configured network ACLs, and worried about IP overlap when connecting VPCs.

This made sense when applications were simpler. A three-tier architecture lived mostly in one place. You created a VPC, sliced it into subnets, attached a few security groups, and called it done.

But the complexity crept in. As organizations grew, they needed more VPCs, one per team, one per environment, one per compliance domain. Connecting them meant choosing between VPC peering (which doesn’t scale), Transit Gateway (which works but requires careful route planning), or building custom networking middleware. None of these felt natural.

And then came the real pain point: your developers didn’t care about any of it. They wanted their front-end service to talk to their API, their API to talk to their database. They didn’t want to think about security group rules, NACLs, or whether traffic was flowing across an inter-AZ boundary.

Yet we kept building networks from the infrastructure down. “Here’s your VPC. Figure out your services within it.”

The New Model: Applications Define Network Intent

This year, AWS pivoted. Look at what they announced:

VPC Lattice eliminates the need to think about network topology at all. Instead of designing your VPC architecture, you define service networks. Services join networks. They automatically discover each other. Traffic is encrypted by default. Zero-trust security policies are built in. Your application says “I want to talk to the database service,” and Lattice figures out the networking.

No subnets. No route tables. No CIDR planning. The application’s intent drives the network, not the other way around.

AWS Interconnect Multi-Cloud extends this further. You no longer manually negotiate cross-cloud connectivity. You say “I want a private, secure connection to my Google Cloud data lake,” and AWS handles the plumbing. The network becomes an implementation detail, not an architectural decision.

This isn’t just a feature release. It’s a strategic shift in who owns networking and I think infrastructure teams need to recognize what this means.

Why This Matters: The Abstraction Stack

AWS has always been about abstraction. EC2 abstracted away physical servers. RDS abstracted away database operations. VPC abstracted away traditional network appliances.

But we hit a wall with VPC. The abstraction was incomplete. You still had to think like a network engineer, topology, routing, CIDR blocks to use it effectively. Most developers stopped trying and outsourced networking decisions to infrastructure teams.

Lattice completes the abstraction. It says: stop thinking about how traffic flows through your network. Think about what should be allowed to connect.

The implications are profound:

For Developers: No more waiting on infrastructure teams for network configuration. Join a service network, and you’re connected. Iterate faster. Build faster.

For Infrastructure Teams: You shift from designing network topology to defining network policy. Instead of “how should these services be connected,” you ask “what are the security and compliance boundaries these services need to respect.”

For Your Architecture: You move from network-centric design to application-centric design. Your architecture diagram looks different. Instead of “subnets in AZ-a, subnets in AZ-b,” it’s “database service, API service, frontend service, and here are the trust boundaries between them.”

That’s a fundamental shift in how you think.

The Cost of Abstraction: What You’re Trading Away

Here’s the uncomfortable part: abstraction always has trade-offs.

With VPC, you had low-level control. You could route specific traffic patterns, implement complex network policies, and optimize packet flows. With Lattice, you’re accepting a level of abstraction that hides those details.

For most organizations, this is the right trade-off. Lattice’s zero-trust model and automatic encryption are likely better security outcomes than hand-crafted VPC security groups anyway. The performance penalty from hidden routing decisions is negligible compared to the flexibility gains.

But if you’re operating at the scale where microsecond latencies matter in large-scale AI training or high-frequency trading, you might still need fine-grained control. And AWS knows this. That’s why EC2 Ultra instances and the new Trainium 2 servers include explicit network topology controls. If you’re pushing to the boundaries of what’s possible, you get control. If you’re building a typical application, Lattice abstracts away the complexity.

The sophistication here is that AWS is offering both models. It’s not “VPC is old, use Lattice.” It’s “use the abstraction level that matches your actual needs.”

What This Means for Your Architecture Decisions

If you’re leading infrastructure, here’s what I’m watching:

1. Rethink Your VPC Strategy

If you’re still managing dozens of VPCs manually, with Transit Gateway as the connection point, ask yourself: are you managing topology because it’s necessary, or because it’s how you’ve always done it?

For many organizations, Lattice could consolidate that entire architecture. You could move to fewer VPCs (or even one) and let Lattice handle the application-level connectivity and security. The operational simplification alone is worth investigating.

2. Shift from “Topology Design” to “Policy Definition”

The best infrastructure teams I know are moving toward infrastructure-as-policy rather than infrastructure-as-topology. Instead of “which VPC should this service live in,” you define “this service talks to these other services with this level of trust.”

That’s a different mental model. Your infrastructure documentation becomes cleaner. Your security review process becomes simpler. And your developers stop being blocked on network configuration.

3. Plan for Multi-Cloud Carefully

AWS Interconnect Multi-Cloud is genuinely interesting, but it’s not “use AWS and Google Cloud identically.” It’s “establish a private, secure connection between AWS and Google Cloud, and manage them as distinct networks with defined handoff points.”

If you’re considering multi-cloud, Interconnect makes it operationally feasible. But strategically, ask yourself: am I going multi-cloud because it solves a real business problem (regulatory requirement, best-of-breed services), or because it sounds modern?

The network cost and complexity of multi-cloud is real. Interconnect reduces it, but doesn’t eliminate it.

The Bigger Picture: Infrastructure’s New Role

I find myself thinking about what this shift means for infrastructure teams more broadly.

For years, infrastructure was about control. We controlled how systems were built, how they were connected, how they were secured. We were the gatekeepers of architecture decisions.

Lattice and similar services are stripping away that gatekeeping role. And I think that’s healthy.

Good infrastructure should enable application teams to move faster, not constrain them. Lattice does that. It gives developers the connectivity they need without needing to wait on infrastructure approvals.

For infrastructure teams, that means our role evolves. Instead of designing network topology, we define the policies that make the network secure and compliant. Instead of managing connectivity, we monitor it. Instead of saying “no, you can’t connect those services,” we say “yes, here’s how services connect securely within our trust boundaries.”

It’s a shift from builders to architects. From managing infrastructure artifacts to managing infrastructure policy.

Hope Someone Else Finds This Useful

AWS Interconnect Multi-Cloud is a solid feature. VPC Lattice is genuinely useful for most organizations. But the real insight from Rob Kennedy’s keynote is the direction they’re pointing: toward a model where network infrastructure becomes less about topology and more about intent.

If you’re making architecture decisions now, think about whether you’re designing for how things connect or for what should be allowed to connect. The difference between those two questions is going to define your infrastructure strategy for the next few years.

I’d be curious to hear how your organization is thinking about this shift. Are you moving toward application-centric networking? Or are you finding that the abstraction model still requires more control than Lattice provides?

Want to explore further? Check out Amazon VPC Lattice documentation and the AWS Interconnect multi-cloud announcement.

Sources:

• Amazon VPC Lattice - AWS
• AWS Interconnect - Multicloud - AWS
• AWS Interconnect Multi-Cloud Documentation
• AWS VPC Lattice: Application-Centric Networking - AWS Blog
• Google Cloud Extending Cross-Cloud Interconnect