Credits:
Most of the pictures in this blog are screenshots from various AWS blogs and ReInvent events. All credit to the original content creators (listed in References at the end of the blog).
Purpose of this post:
Unlike some of my other blog posts, this is a collection of my notes as I was learning Amazon VPC Lattice. Many peers found these useful which motivated me to share them here. Hopefully you will also find them useful and it may reduce the time you would otherwise have to spend in getting 101/201 level familiarity with VPC Lattice.
TL;DR:
Amazon VPC Lattice aims to provide network connectivity for applications without using traditional networking configurations. VPC Lattice leverages AWS underlay routing via technologies similar to PrivateLink without needing standard VPC Networking. In Amazon VPC Lattice, administrators define a Service Network which connects application services being offered and VPCs of the consumers of these services. In addition to connectivity, Service Network also adds authorization to make sure the consumer is authorized to access the service as well.
App owners create application based services (currently HTTP & HTTPS) and authorization policies in their VPCs and offer these service in an administrator created Service Network. App consumers then associate their VPCs to the same Service Network. Once services and consumers are connected to the same Service Network and consumers have correct authorization, consumers will have IP connectivity provisioned using AWS underlay (using a version of Amazon PrivateLink, but bi-directional).
Overview
Amazon VPC Lattice is an application networking service designed to consistently connect, monitor, and secure communications between your services without explicitly building connected networks. It provides a consistent way to manage service-to-service communication within AWS, without requiring any prior networking expertise.
Key Components
Service
A Service is defined much like a Load Balancer Target Group.
Service Network
You can group Services in a Service Network to apply common connectivity monitoring and access control. You can think of this as a new way to create an application layer boundary that complements (overlays on top of) your existing Network boundaries with VPCs and Accounts. You can share Service Networks and Services across accounts using Resource Access Manager. This lets you create a boundary that actually maps to how your applications are deployed and not how networks are connected.
Auth Policies
Auth policies define an access level and policy for the associated resource.
Auth policies can be applied both to the Service and to the Service Network.
Service Directory
Service Directory is an account level view of all the services you created or were shared with you via Resource Access Manager.
Workflows
Admin Workflow
As an admin, you will create the Service Network and define its access, authentication, logging, etc. policies. You then associate the newly created Service Networks with the VPCs where Services live. This works easily in a single account setup but for multi account, you need to leverage Resource Access Manager to share the service network with appropriate accounts.
Service Owner Workflow
Service Owner will create the service and the Target Groups inside it. For ex, the Service could be Parking and the Target Groups would be a EC2 or K8s service hosting the front-end application.
How it works?
VPC Lattice creates a logical application layer network called a service network, which abstracts the underlying network complexity. It simplifies inter-application communication between clients (consumers) and services (providers) throughout the service network across different AWS accounts and Amazon VPCs.
The service is designed to help you effectively discover, secure, connect, and monitor all of the services within it. Each component within VPC Lattice communicates unidirectionally or bi-directionally within the service network based on its association with the service network and its access settings.
Service owners in their own VPCs create Services and share with the admin account.
The Admin have already created Service Networks as needed. For ex, a generic Shared Services and a very restrictive PCI Services Network.
Now the Admin shares the Service Network with the accounts using Resource Access Manager and associates the Service Networks with the VPCs.
Important Notes and Limitations:
Each VPC can only associate with a SINGLE Service Network
A Service can associate with multiple Service Networks
Services only have access to the services in their service network
Underneath it uses AWS PrivateLink
Support Overlapping IP
Currently supports HTTP and gRPC. TCP support is on roadmap
VPC lattice offers 10Gbps bandwidth per service per AZ at this time, Quotas for Amazon VPC Lattice provide more up to date details.
Example Scenario
The following diagram uses an example scenario to explain the flow of information and direction of communication between the components within VPC Lattice. There are two services associated with a service network. Both services and all three VPCs were created in the same account as the service network.
EKS Support
Example Usecases
Multi-Cluser and Multi-VPC K8s
Cross-VPC Connectivity
Traffic Management
Visibility Support
Demo
Amazon VPC Lattice Pricing:
Three dimensions determine the cost of using Amazon VPC Lattice: number of services provisioned, data processing charges for traffic to and from each service, and number of requests that each service receives.
Pricing dimension per service:
Per hour charge: $0.025-$0.0325/hr
Note this is higher then AWS Transit Gateway data processing charges of $0.02/GB
Charge per GB data processed: $0.025-$0.0325 per GB
Charge per requests per hour: $0.10-$0.13 per 1 million requests (300K per hour is free)
Comments