{"id":6884,"date":"2024-04-12T11:46:35","date_gmt":"2024-04-12T09:46:35","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6884"},"modified":"2024-04-12T11:49:36","modified_gmt":"2024-04-12T09:49:36","slug":"vpc-lattice-yet-another-connectivity-option-or-a-game-changer","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/vpc-lattice-yet-another-connectivity-option-or-a-game-changer\/","title":{"rendered":"VPC Lattice: yet another connectivity option or a game-changer?"},"content":{"rendered":"\n
\n“Live as if you were to die tomorrow. Learn as if you were to live forever” <\/p>\n– Mahatma Gandhi<\/cite><\/blockquote>\n\n\n\n
I like learning new things, and I am lucky because a significant part of my work involves learning new technologies and evaluating how to use them to solve new and existing problems.<\/p>\n\n\n\n
In the past few years, we described many connectivity options to connect our workloads running on AWS (Transit Gateways<\/a>, Load balancing, Shared VPCs<\/a>, PrivateLink and Endpoint Services<\/a>, and VPC peering…) <\/p>\n\n\n\n
Last year, VPC Lattice<\/strong> reached General Availability, offering a new option for us to explore.\u00a0You may be wondering why we should learn how to use another service when we already have so many options to choose from… Well, let’s find out!<\/p>\n\n\n\n
In this article, we’ll see that we needed to add another thing… Let’s see what this service offers, how it differs from the other connectivity options we already know, and a simple use case.<\/p>\n\n\n\n
So, without any further ado, let’s dig in!<\/p>\n\n\n\n
Where VPC Lattice stands<\/h2>\n\n\n\n
As we saw in previous articles, microservices are an architectural approach that allows developers to build and deploy software faster. However, it introduces challenges: single applications now consist of numerous individual components that can be distributed in different AWS accounts and must communicate with each other, and various technologies can be used together: Lambdas, EKS, ECS, and EC2.<\/p>\n\n\n\n
We must face tasks like service discovery, traffic routing, authorization, security, and detailed metrics. There are scenarios where a strict microservice communication and authorization policy is complex to implement using “classical” network approaches. <\/p>\n\n\n\n
Think about allowing communication only between two microservices in different AWS accounts, blocking every other traffic without implementing custom solutions and authentication.<\/p>\n\n\n\n
VPC Lattice aims to help organizations overcome these challenges while keeping a secure and manageable approach. <\/p>\n\n\n\n
It enables developers to manage microservices definition, authorization, and configuration, while administrators can manage infrastructure, network, communication policies, and governance;<\/strong> we’ll see more in the following sections.<\/p>\n\n\n\n
VPC Lattice Components<\/h2>\n\n\n\n
VPC Lattice has some key components: <\/p>\n\n\n\n
\n
- Service<\/strong>: a VPC Lattice service represents an application and its resources: computational (such as lambdas, EKS pods, EC2 instances), listeners (port and protocols involved), and routing rules to address traffic (weighted routing, path routing, and so on). The application team typically manages these aspects and can be autonomously defined. A service can be shared using AWS Resource Access Manager with other AWS accounts, even outside an organization.<\/li>\n\n\n\n
- Service Network<\/strong>: a service network is a new concept because it’s a logical grouping of services that facilitates connectivity. It can also be shared using AWS Resource Access Manager. This kind of resource is usually defined by infrastructure or network administrators.<\/li>\n\n\n\n
- Service Directory: <\/strong>the list of service networks that can be used, shared with AWS RAM<\/li>\n\n\n\n
- Auth Policies: <\/strong>IAM documents that can define access to resources. Auth policies differ from IAM policies because they aren’t attached to users, groups, or roles but are used with services and service networks. They can allow a IAM user, a IAM Role, or other services access to the attached service. They define new specific conditions, such as <\/li>\n<\/ul>\n\n\n\n
vpc-lattice-svcs:RequestMethod<\/pre>\n\n\n\nto filter allowed methods. For a complete list, you can have a look at the documentation<\/a>. <\/p>\n\n\n\n
Let’s see which steps are required to set up VPC Lattice.<\/p>\n\n\n\n
Putting all together<\/h2>\n\n\n\n
Let’s briefly look at the roles and steps involved in setting up the communication. <\/p>\n\n\n\n
\n
- The infrastructure admin defines a Service Network<\/strong> <\/li>\n\n\n\n
- The infrastructure admin shares the Service Network using AWS RAM<\/strong><\/li>\n\n\n\n
- The service owner defines a VPC Lattice Service<\/strong> and its authorization policies<\/li>\n\n\n\n
- The service owner associates the Service<\/strong> with the Service Network<\/li>\n\n\n\n
- The infrastructure admin associates<\/strong> the Service Network with the VPCs<\/strong> <\/li>\n<\/ol>\n\n\n\n
As you can see, there is a certain degree of independence in managing services, so dependencies between teams and operations are reduced. <\/p>\n\n\n\n
A practical example of VPC Lattice usage<\/h2>\n\n\n\n
For our example, we will use the sample infrastructure and applications from this URL<\/a> and analyze the key components deployed on the AWS Console. <\/p>\n\n\n\n
You can deploy the reference architecture using the instructions contained in the ReadMe<\/em> file in the repository.<\/p>\n\n\n\n
You can also use three different VPCs belonging to a single account to ease the deployment process (as we’ll do in this article).<\/p>\n\n\n\n
You’ll end with this sample infrastructure:<\/p>\n\n\n\n
<\/p>\n\n\n\n