From Networking to Service Networking

Well, we have always talked about Networking in the context of L2, and L3 Protocols, SDN Fabrics and as workloads moved to the Cloud we started seeing Cloud Networking which varies between Public Clouds. So what is this service networking?

I think the best way to describe service networking is networking for application owners or developers. It is an abstraction of all the intricacies of the L3/L4 networking with primal focus on the application or service you are providing. Another reason Service Networking became a thing is the advent of micro-services. Historically in a monolith all the components run as services on the same hardware or virtual machine making the communicating between components internal to the node. In a micro-services environment each component can live on a different node but we still need to visualize, monitor, optimize and secure the component to component communication.

Now that we have introduced service networking, some of the advantages that service networking brings:

• Application Centricity in terms of monitoring and deep visibility

• Provides Improved resiliency with Advanced Load Balancing techniques (Blue/Green deployments)

• Zero Trust with Service to Service or client to Service Authentication & Authorization

• Some solutions provides additional capabilities to inject failures & delays providing better robustness and resiliency of your services and applications

Now that we have introduced service networking, we will move on to focus on AWS VPC Lattice.

VPC Lattice Constructs

VPC Lattice is AWS's answer to service networking. It is made up of 3 basic components:

• Service: This is a component or a micro-service within your uber application. Some examples could be: Checkout service, location service, authentication service..etc You can think about a service in Lattice similar to a Load Balancer VIP that abstracts and exposes a number of workloads which could be VMs, K8 Pods..etc A service is composed of 3 different elements:

  • Listener: Similar to a LB, the listener defines the protocol, port & hostname(s) the service is listening to.

  • Rules: The idea here is when traffic hits the listener you can have host based or path based rules by which you decide where to send this traffic. For example:

    • Path based:

      • acme.com/prod: Routes users to the production stable page

      • acme.com/latest: Routes users to the latest update that is under testing

    • Host based: Ability to publish multiple applications

      • app1.acme.com

      • app2.acme.com

You can also have a combination of Host and Path based routing.

• Target Group: Similar to an ALB or NLB Target Group, this references the backend workloads where traffic needs to be forwarded when matching a particular rule.

• Service Network: Services can be placed in one or more service networks. On another hand, VPCs (containing clients) to those services can also be associated to a single Service Network. Thus, a service network marries the services that are available within a service network and VPCs that need access to those services.

This figure shows the different target types supported by a VPC Lattice service. The interesting part here is that VPC Lattice works across all compute types (Virtual Machines, Kubernetes & Serverless)

This is an example of a service where for a particular rule (path or host based) we send 90% of the traffic towards the production target group (nginx-production-tag) and 10% of the traffic towards the new release (nginx-new-tg).

The association of services and VPCs to a service network provides high level security and scoping (similar to a VRF in networking). In the figure below, based on Service Network A, the only 3 services that can be accessed are S1, S2 and S3 and only VPC-1, VPC-2 and VPC-3 can access them. This means based on the example that VPC-1 can't access service S4 and VPC-4 can't access services S1,S2, or S3.

The VPC Lattice Advantage

I will use this section to explain the architecture of VPC Lattice and highlight its unique points.

1. Parallel Network: One of the major benefits of VPC Lattice is that it runs as a parallel network under the hood i.e. there isn't any change required for the existing network. You can see the figure below where there is a TGW connecting two VPCs and there is another path that goes through VPC Lattice. Another advantage of VPC Lattice is that it connects services across VPCs and Accounts without requiring any underlying networking changes via this parallel network.

2. VPC Lattice leverages DNS: So now that we have the two different paths, the decision on which path to take depends on DNS. When a service is created within VPC lattice, it gets allocated a DNS Name or you can specify your own name for that matter. The resolution of the DNS name maps to the Proxy represented by the Lattice icon on the top path. Any other traffic or DNS resolution continues to run in the same manner. It is worth noting that VPC lattice or these proxies operate within the link local range of 169.254.171.0/24 so that they don't interfere with your existing address space.

3. Solves overlapping address Problem: VPC Lattice by default will SNAT to the "Proxy IP" within the 169.254.171.0/24 range when sending the traffic to the service thus the service will always see the request coming from that range.

VPC Lattice Security

There are many aspects of VPC Lattice Security that can be highlighted:

• Service to Service vs Network Connectivity: When you connect two VPCs (A&B) via TGW or VPC peering for instance, all workloads in VPC-A can communicate with VPC-B unless you are using some form of firewalling (Security Groups, Network Firewall..etc).VPC lattice improves on this model by narrowing down the list of services that can communicate within the service network as well as the list of VPCs that need to communicate with those limited set of services.

• Security Groups: It is interesting that VPC Lattice respects the security groups of the ENIs across the path from the client to the server (member of the service target group). In addition, when going to VPC Lattice there is also an associated Security Group that can also be used to enforce which workloads within the VPC can access the services within the service network. In reality, I couldn't see the Lattice ENI but it just helps to put a mental model around it.

• Authentication & Authorization: The Auth type (Authentication and Authorization) in VPC Lattice can be set to None or AWS IAM. None basically doesn't take into account authenticating and authorizing the client. The idea with AWS IAM is that when a client makes a request to a service regardless if the client is another service or a non service, the client needs to have an identity. VPC Lattice leverages Sigv4 which is the process to add authentication information to requests and is heavily leveraged in AWS for instance when you send a request to AWS services (e.g. S3), before the request is fulfilled AWS has to figure out the user identity, check the Identity Policy attached to the user and the resource policy on the S3 bucket and based on all of this either accept or reject the request.

  VPC Lattice follows the same logic where it needs to identify the identity of a client, if it has the identity based policies to Invoke Lattice, in addition to the resource based policies which in Lattice are Service Network Policy & Service Policy. The Service Network Policy gets associated with the Service Network affecting the level of acceptable access to all services within the service network and is generally a coarse grained Authorization policy where for instance you can allow traffic from particular VPCs or Organization ID and that all requests have to be authenticated. The Service policy is associated with a particular service and provides fine grained least privilege access to the service.

  • This is not the easiest part of VPC Lattice due to:

    • IAM Dependency: IAM is not the the easiest AWS service to wrap your head around at least for me.

    • Application Changes: The client or client application will need to be modified to send a Sigv4 request for Lattice to allow or deny the request.

Closing Thoughts

In this blog post, I tried to introduce the need for VPC Lattice, its constructs, as well as its architecture and benefits. We ended this blog post by touching upon VPC Lattice Security.

I will be working on a part 2 on VPC Lattice where I will run a small demo, discuss Kubernetes Integration and external access to VPC Lattice.