{"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
<\/figure>\n\n\n\n
Image source: https:\/\/github.com\/aws-samples\/build-secure-multi-account-vpc-connnectivity-applications-with-amazon-vpc-lattice<\/a><\/em><\/p>\n\n\n\n
<\/p>\n\n\n\n
In our example, App1 and App2 will need to communicate bidirectionally, and App3 will be consumed by App1, App2, and App4.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
Image source: https:\/\/github.com\/aws-samples\/build-secure-multi-account-vpc-connnectivity-applications-with-amazon-vpc-lattice<\/a><\/em><\/p>\n\n\n\n
<\/p>\n\n\n\n
The deployment process will take about 10 – 15 minutes, and you will see that our microservices can communicate. <\/p>\n\n\n\n
Bug Alert: <\/strong>there’s a missing step in the deployment instructions; these two lines will make the deployment fail:<\/p>\n\n\n\n
export TARGETCLUSTER1={TARGET_GROUP_ARN}\nexport TARGETCLUSTER2={TARGET_GROUP_ARN}\n<\/pre>\n\n\n\nYou need to change these exports using values from the VPC lattice target groups. <\/p>\n\n\n\n
For TARGETCLUSTER1, use the k8s-frontend-default arn; for TARGETCLUSTER2, use the arn for k8s-backend-default. This is a sample from our deployment:<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n
When the CloudFormation deployment finishes, you should have these CloudFormation stacks:<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Let’s see the resources created to describe them. First, the service network:<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n
As you can see, four services are associated; you can also see VPCs associated with the service network:<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Now VPC Lattice target groups: <\/p>\n\n\n\n
Our Lambda, Autoscaling group, and EKS are added as targets, and like ELB target groups, you can see metrics and define health checks.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Note that to register our targets managed by EKS clusters, we had to deploy the Gateway API Controller Class into the cluster and register the service using the configuration deployed with the commands:<\/p>\n\n\n\n
kubectl config use-context cluster1\nkubectl apply -f .\/vpc-lattice\/routes\/frontend-export.yaml\n\nkubectl config use-context cluster2\nkubectl apply -f .\/vpc-lattice\/routes\/backend-export.yaml\n<\/pre>\n\n\n\nLast but not least, let’s see the defined services. You can access them using the DNS domain name defined by VPC Lattice<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n
You can find the complete list of domain names defined by looking at the Outputs of the CloudFormation stack named “lattice-services”:<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Each service also has its routing; in this case, you can see that \/backend path for service3 forwards to cluster2, while \/lambda forwards requests to the lambda application:<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Now that you have a deployed infrastructure, feel free to experiment and modify the behaviour of your application and environment (why don’t you try IAM authentication between services? ). <\/p>\n\n\n\n