Simplify Service Communication Across VPC Using Amazon VPC Lattice | Cloud Native Now 2023
There are a number of use cases where customer development teams need to rely on Network Engineering teams when working with cross dependencies of services across organizations. Each sub-team develops and manages services in its own VPC and carries out the release lifecycle. Network Engineering teams need to work with all teams to make sure teams are set up with the right controls and they are not using overlapping CIDRs, and connectivity is established using VPC Peering, AWS transit gateway, or AWS private link. Communication and dependency between teams increase significantly as the number of applications are migrated and needed to communicate. Upgrades of applications become complex as well.
Transcript
Hello guys. My name is API sha and I'm going to be talking to you today, uh, on Amazon V P C letters, which is, uh, just launched in April. Uh, we did the, uh, preview in December at our reinvent, and we are going to be talking about the VPC ladder.
And, uh, I'm going to first introduce myself. So I'm aha, uh, working for a w s as a senior cloud infrastructure architect. My specialization is networking, and I work with the global financial services customers.
So these are the financial services, uh, organization who have global presence. Yep. And I work with most of them, uh, as part of our a w s Professional Services.
So getting into the detail, um, what we are going to be doing today. So first slide. So, um, my first question, if you want to gimme an answer in the chat that, have you heard of Amazon V PC letters?
Because this is a new service, which we have just launched, um, in December, it was a preview, and in April we have gone, um, to all of our customers. It's been enabled now. So first question, have you heard of Amazon V VPC letters?
If you have heard of it, say yes into the chat. If not, um, you can say no. 10 seconds.
Great. Fantastic. So let's move on.
So what we are going to talk today, um, we are going to talk about the modern applications. So from where we have come down and where we are heading towards, into the, uh, application landscape, what is Amazon vpc Latice, what it's bringing to the table, um, in terms of the networking and what it's enabling, the application team, uh, why Amazon VPC Lattice, what is the benefits of it, uh, common use cases, what we have learned from the customers and why they need these kind of a services. And towards the end, I'll demo across, um, as to how you can build the service to communicate in the different V VPCs, uh, and how we can leverage on the E K s as well with respect to the A W S A P I controller, uh, service, which has been launched.
So without delay, let's go into, so the first question, why, what is the challenge which we're trying to solve? So with the AWS vpc, Amazon VPC letters, um, it's, it's the networking is really hard, uh, for our developers. That's what we were look looking into.
So how many of you think that networking is really hard for the developers on the aws and it shouldn't be? So, uh, again, in the chat, if you can say, yes, it's hard, or No, it's not hard, that will be great. Um, five to 10 seconds.
Fantastic. So this is what it looks like when the developer starts to talk about and administrator starts talking about the a w s, so many connections. You have private links starting from the left.
Uh, you have the global load balancers for your firewalls. You have the p n, you have the outpost. Then within the regions you have lot of network firewalls, which is required.
You have the S3 gateway endpoint, you have internet gateway. And within the V VPC to V VPC connectivity, if you want to have the calls just within the aws, then you require VPC bearing. You require either transit gateway or if you require to connect to the on-premises, you require the virtual gateway.
But this all requires the siders to be unique. Um, and if you don't want the VPC siders to be unique, then you need to use the private gateway, um, uh, private links. Um, uh, so it's a lot of complex things, which is there.
And on top of this, administrators wants to know that who has been accessing the service from where, and they want to have the controls around it. They want to see that whether we are operating into the safe environment, um, whether we have all the logs of the different services, which has been operating into and so on. And at the same time, developer wants to connect to another services quickly, rapidly, and wants to deliver it.
So that's the kind of, uh, uh, things which has been coming around. And the developer says, I don't want to know the network. Yeah, networking is really challenging.
I don't want to be the research. I want to leave that to the administrators, but at the same point of time, I want to do things quicker. So what, what is heading into it?
So as we see that we were in a monolithic environment, monolithic applications we were developing, and the complexities was really low, you build the applications, just put a load balancer and expose it to the word with a few firewalls and ddo, tech protectors and so on. And it was there. We moved on to the containerization.
We said, make it small, because when you make it small, you can scale it easily. And all the 12 factors of the applications, which comes into picture with the modern architectures, you get the benefit out of it. But then what brings the complexity?
Now you require how the applications will be communicating to the outward internet, how you will be doing the intercom interservice communication. So because it was one monolithic application, it was easier. Now it is many services.
So hence we brought the proxies and service mesh and app mesh. But in all this, the network complexity started getting bigger and bigger. So developers are spending more time now to understand how to use different services.
Developers are spending more time to say, oh, but what is required from the cloud administration perspective, cost borrow point. Um, everyone wants to keep the cost low and then wants to deliver it as a quick pace. So all these are the challenges which we are seeing in the modern applications, which is coming out as we move towards the modernization from monolith to microservices.
Uh, we have a higher developer productivity, but at the same time, we want to also make sure that we enable the developers to just worry about the functionality, what they want to deliver, nothing more to worry about. Yeah, uh, um, VPC siders overlapping networking complexity. We want to leave that to the administrators and we want to give the power to the application developers to develop that application in a fast pace.
And at the same time, we want to have the administrators who wants to manage the infrastructure, the controls and all this governance, uh, things which needs to be done around the cloud applications. So, um, for service to service communication, we had the, uh, side cars. And what we introduced with the side cars was you have anto, you have the app mesh and so on.
So there is a control plane. You run a sidecar proxies, you put some um, uh, containers, which are running within the same ports. And then you have the control plane, which manages which service should communicate to where and what are the controls and how they communicated.
And, uh, it still requires the interv VPC communication. So if you are having an e a s, which is running within different network, and you have another E A s, which is running in another V P C and you want to communicate with them, then you still require your v PC pairings and so on. So it was still complex, but we solve a partial problem.
But this was only for if the applications are running more clean to the container world. If the applications are running in Lambda, if they're running onto the e c two instances, most of the companies have no options right now. They put the API gateways and so on, but it doesn't solve the problem of service to service communication.
With the sidecar proxy, obviously it comes an overhead. Uh, you need a compute, which, uh, even though how small it is, you still require to have the compute to run that you need to make sure you patch regularly, you upgrade regularly. There are still the maintenance overhead, which you need to do.
And obviously with every hop you have a latency, how much small it is, whether it's in milliseconds and so on. It always exists. Yep.
So, um, when we talk with our customers, they say that my developers wants to have the communication we between the services in a seamless way. We don't want to have a transit gateway to be put or VP appearing to be put just for a service to service communication. Um, we want something really lightweight, which enables us to do the things fast.
And hence we are here in introducing Amazon V P C letters. Uh, it is built for the developers, but with the whole tools and controls, which the administrators can have as well, uh, to make sure they, they have the full control and audit capabilities of the infrastructure, which the applications are running into, and they provide all the, uh, conformance suits. If you're running within the, say payments and so on, you have all the governance criteria has been satisfied.
So how does it work? Uh, so first of all, we have the, um, we had the complexity of cross account cross VPCs, which was required to be connected between the services you no longer require. Now the, um, uh, transit gateway or VPC peering or going over the internet gateway or the private link that has been completely remote from the service to service communication perspective, you can have an overlapping cider.
So what does we mean by that? You can have a cider, one of the VPC one, which is same 10 0 0 slash 16, and you can have another V vpc, which is having the same cider, and you can still communicate, because what we are doing over here with the VPC letters is using the link IP addresses. Yeah, link local addresses.
Um, you can use any of the compute services. You can use e C two, you can use e c s, you can use e k s, Lambda, um, any of the other, uh, uh, OpenShift Rosa, if you're running on two, the plate forms as well. Uh, it is all been supported.
So observative, observability and traffic control. So, um, we have, as with all of our a W S services, you can have the logs and metrics exported to s3, or you can leverage the CloudWatch or data fire hose if you want to do something real time. Uh, looking into, there is a load balancing.
So you can have either path based rout routine, uh, you can have the host based routine, um, or you can have the, um, uh, percentage of traffic going to EGAs, and if you want percentage of traffic going to the Lambda, then those kind of load balancing are also supported. Uh, we will go through it when we look into the demo. Yeah.
And from the security perspective, it is all built into the functionality. So I am provides all of the controls, uh, as to what is required, uh, for the architecture. Uh, you can control what traffic is coming in, what traffic is going out from into the v vpc, enhanced to your services from the central, uh, management perspective.
So there are policies, I am policies which you, uh, introduce into it. So how does this all work together? So what is the, uh, uh, structure looks like, or what are the objects, uh, which needs to be created?
So really what you do is, uh, you create a service network. Um, that service network is nothing but, uh, kind of a logical boundaries that which all VPCs you want to connect. Yeah.
So that's something which you put it into. And as part of that service network service network will have many services. So you can have V VPC one having service a VPC two, having service B and v, vp C, C having another service.
Now they can all run as it's been shown. You can run into E K s, you can run into e c two or you can run into Lambda. Yep.
So it is interchangeable. Uh, service is the unit of application, as I was saying around, and then you have the service directory. Each of these services, a, B, and C, they will be listed into the list of services, uh, which I'll show you on to the demo.
And then we have the AU policies, um, where you can create the policies as to what you want to do with service to be allowed to talk with, with service and, um, uh, what controls you need to have in place. For example, you can say all these services within the principle org are allowed to talk, or you want to say, I want to only allow service A to be talking with service B, but only for the CAT operations. Whereas service C should be allowed all of the operations.
So you have that level of granular, uh, control using DM policies. So why Amazon VPC ladders? Um, so as you can see, there are different services.
They have different teams, different products, and you want to have the managed control plane. That means customers don't need to manage about now any of the, uh, control plane, like what we were having in East Year and so on. That's all been managed by the AWS and provides the backbone for managing it.
Um, in terms of the communication between the services, no more V P C peering, which we require the customer to do before, or the transit gateway, uh, where you need to have the attachments and so on. This comes as a seamless perspective. So what are the benefits?
Obviously we talk about the developer productivity. It has gone high now. Um, security posture, everything has been controlled through the Im, so, uh, as we will see in the demo, um, uh, you can control what you want to give the access to its service.
Yep. Uh, compute choice, uh, obviously as we were saying, easy two Ks, lambda, anything you can use it. Um, any service which you want to, uh, call over the S G D P S G D P S G R pc you can call it.
Yeah. Um, and improved scale and resilience. So if you want to have a service calling on e C two, but during the failover you want to move it to Lambda, you can do that as well.
Yeah. So it, it is providing that kind of a scalability as well. By having the target based routing and reduce day two operations, you don't need to worry about.
Now the sidecar proxies, which was running around and the upgrade of the sidecar proxies, that has all been eliminated now. So, um, what are the use cases which we are seeing from our customers? So, um, as we were saying that the customer used to have an application A, which was running into the V pc, for example, a key clock.
So key clock is a service which is used for, um, uh, authentication and authorization of the services by some of our customers. Um, and they were running into one vpc. And what they wanted to do was that they wanted to make sure that that central VPC in which they are hosting their key clock is been accessed by the other VPCs, uh, either in the same account or across the account, and they can verify it.
They didn't want it to have any complexity of putting into the VPC pairing because they wanted it to be scalable and they didn didn't wanted to introduce the transit gateway because this was something which was used and cached by the application as required. Uh, granular access to services, as I was saying, you can control whether you want to have the, uh, GA operations, uh, uh, denominator or you want to have the host. It's all the IM policies.
Whatever is supported into the IM policies, you can control that. You can say that I don't want to allow another principle org or another v VPC to access my services and a particular type of operations, uh, traffic management and streamlined service to service operations. So these are some of the, quite a lot of use cases which we are seeing.
Um, an example. So, um, if an instance is running into the E C two, you have the VPC letters, link, local addresses, uh, which will be created, um, as a, uh, in, into that, um, uh, account. And then you communicate with the other, um, V P C, uh, using the V PC LA network.
Yeah. As a, as a backbone, you, uh, you, it's a seamless for the customers. These link local IP addresses are being created as a prefix list within the a w s, uh, as a manage, uh, pre fixx list, just like an S3 one.
Um, you can have the granular secure access, so you can say that I want my VPC one billing to be able to communicate, uh, with a specific kind of a service, but not with the inventory. So you can have now those kind of a controls as well, using the service to service networking. As I was saying, you can have the, uh, load balancing, you can have weighted targets, uh, you can do the service discovery, um, and you can do the health checks as well.
Uh, it's all been supported. So you can have either host based or method based routing, however you want. You can have that kind of a, uh, support for the S G D P, uh, kind of a routine and G G R P C.
Cool. So we are here, I'll just quickly show you the demo, um, as to how these things work. So let me minimize it and go to the browser.
So we are into the Amazon console, uh, and I have just created for this demo purpose one of the AWS account, uh, which will be deleted, um, after the demo. So I went into the V vpc, and you will see at the bottom of the V PC there is something called new, which is V P C la. Yeah.
Uh, you can see, uh, getting started as to what needs, what does it mean, 50 of the documentation. But then the key important things are service networks, services and target groups. So it works from bottom to up, basically.
Yeah. Um, so what does it do? So let's see around.
So I have an e k S cluster. Um, let me just show it across. So I have an E K S clusters on which I have deployed a service, which is, uh, key clock service.
So key clock service has been deployed, uh, onto my E K S cluster. And, um, uh, what I'm trying to do is expose this key clock services, uh, over the, uh, uh, uh, over the v PC letters, uh, to the e C two instances, which is running, uh, into a different V pc. So this E K S cluster is running into one V pc, and we are going to have another v PC in which, uh, we are, I have created an e c two instance from where it's going to be accessed.
So if I go back to the V P C, and if I go back to the, um, target, so what I've done is I have created a target, uh, called Key Clock, um, as a target target group. So in that click clock target group, uh, as you can see, we can have the target type, which is of instances or IP address or Lambda, or application load balancer. I created the application load balancer because when I deployed the key clock application, I used the a w S controller, uh, to create the application load balancer, which can be pointed, uh, from my application.
And once you create the application, so let me just give a target name, I do next. Uh, you can see that the, uh, load balancer can be selected because I have created one. It is not showing me.
But let me just go back and I'll show you what I have created over here. So as you can see, it is pointing to one of the application load balancer, which has been created for the key clock. And, uh, uh, it's been the target group, SG DP one protocol, uh, application load balancer as the target type.
And it has been pointing to the application load balancer on the Port 4 43. So what I do after that, so I have created the, uh, target group. I created a service.
So key clock service, uh, based upon the target group, I created a key clock service. And, um, uh, as you can see that by default it gives the, it requires a unique name for the as a as a service name. So key clock service is the service name, which I give, and AWS assign a domain name, but what if I need a custom domain name?
org chart, xyz, which is my own custom domain. And then I created a subdomain out of it, and I used the ACM for the certificate, uh, to create one for this, uh, uh, services, which is exposed. So my container is running a self-signed, um, certificate, and my, um, services is been created and exposed using the custom SSL certificate on the custom domain.
Yep. Um, and I have associated, uh, service here. Now, once we have done that, o obviously one thing to highlight over here is the sharing.
Uh, so you can share across using the ram, uh, which is our resource access manager to another account as well. But for the purpose of this demo, I have got it into the same account. Yeah.
Um, and the access, so you can have the access policy for the simplicity. I have not created any access policies, but let me just quickly show you. So if you go down to the, uh, instead of none, if you want to have the IM policies, uh, you can apply the authenticated policies.
So you can say that I want to allow principle type of anonymous, um, and it should be able to access, uh, my services. But there are a couple of examples if you want to see it across that, uh, shows that only a certain principle orgs, um, only a specific type of a request method. If you want to give the access to, uh, all the specific v PC from where you want to allow the access to a service, you can have that level of control.
Um, that's what the dev, that's what the developers will require to configure if they want to have the access control onto their services as to who can access it. The last one, so, um, if we go back from the services, it comes the service network. So we created the target groups.
Target groups are, uh, communicating with your services key clock, which was running onto the E K S. Then we created the services, and now we are creating the service network, that big box, which we saw on our P P T. So what does it does?
So first of all, the service network has got a service association. So the service which we created Key Clock service, it's been associated with that. We have got the V PC association.
So we said, I want one V vpc, which is where my E K S is running, and another VPC where my e c two instance is running to be able to access the service. Yeah. And again, from the administrator purpose, we can put tax access policies.
So where the administrator's policies is different to the service policies, the administrators can say that I want only production VPCs to be able to talk with production, uh, VPCs, I don't want their VPC to be able to talk with the production VPCs. And similarly, the developers can have the control on to their s GTP methods. They want to say that I only want to get calls to be invoked my specific V PC application.
I don't want to post md, uh, post to create the resource and so on. So network level control administrators have it, uh, application level control, the developers have it. That's how it's been looked upon.
And with respect to the monitoring, so you can have the access log, which can go into the CloudWatch logs, and you can see all the, uh, access, who is accessing the service and where it's going out and so on. So that's what it's next what we are going to do is we are going to log in onto the E C two instance. So these are the three EGAs managed notes, which has been created on which our application is running.
And this is a simple e C two instance, which I have created in another V vpc. Um, so as you can, uh, see that this V VPC networking, uh, yeah, here it is. So key clock client v, PC in where this one, uh, the C two instance is running.
And if I go to this one, you can see the, um, in the networking, it is running into the EEGs key cluster, V P C, which is a different V P C. And I'll connect to this one session manager connect, And I, if I do a call on my service and I say the custom domain name, which I gave, the custom domain name is been, uh, mapped into the Route 53, uh, service to the domain name, which the, uh, services has been given by the, uh, W S V PC Matters service. You can see we can access it now.
So, um, if I show you this certificate as well, um, it is using the, uh, custom certificate, which has been issued by the, uh, a W s. And, uh, it has been saying it's been valid certificate. And, uh, it is talking from the VBC service to the target group, to the self-signed, uh, key clock application.
So that was the, uh, example, uh, one, uh, let me just walk through very quickly, uh, onto what we did. So we had an C two instance, uh, which had the security group. So as I was saying that we have the prefix list to which, uh, is been used by the PC latice.
Uh, so this is the IP address range which has been used. So when we associate, uh, the service network, uh, and create the services, we need to have a security group. Uh, so this easy two instance should allow the egress to the VPC la, um, uh, link local addresses, uh, so that the, uh, egress is allowed, uh, and it can, uh, communicate with the V PC letters.
And similarly, when it goes down to the ingress, the ingress needs to allow the, uh, IP addresses of the V P C letters. So, uh, we do the V PC association to the service network services has been associated with the service network. Um, and then the routing is easy to intern, security group goes to the services target groups, and then to the A L B to the application port.
So that's how, uh, it works. The second most common, uh, use case, uh, this is very briefly I'm going to touch upon, uh, we have the, uh, AWS VPC lattice, um, uh, workshop, which I'll show you the URL in a moment, uh, which you can of course, uh, uh, create the environment for yourself. But, uh, as you are, might be aware of that, uh, there is a Kubernetes Gateway, a p i, which is, uh, uh, been used as a framework now to expose the services, um, and, uh, to create the resources.
So a w s has come up with the a w S gateway, a p I CAN controller, which you install first onto the E K s. And when you, when you install that AWS A p I controller Gateway, a p I controller, then when you create the gateway, it create the service network by default on the AW snet. Similarly, if you create the DP route, it create the services.
Um, and as you know that the services allows the custom name and S S L T L S combination, uh, and the Kubernetes service has been mapped to the target group, and the port is mapped to the target. So now when you create from the E K S A gateway object, it automatically creates a service network. When you create the GTP route, it creates the service.
Yeah. So, uh, it's been tightly integrated into the AWS gateway, a p i controller, uh, as well, which is the implementation of the Kubernetes GA A P I gateway. And, uh, if you want to, uh, see the, um, uh, workshop, so this is, uh, hands-on with V VPC letters, which we have got the workshop.
And, uh, you can see that there are step-by-step guide onto how and what needs to be done, basically. So as you can say, we are using the cloud console, cloud nine console. It goes through, it creates the EEKS cluster.
Um, it installed the security group as we were talking about because, uh, lettuce needs to have the ingress, um, which will be allowed from the application. And then we installed the gateway controller. Uh, once the gateway controller has been installed, uh, any of the, uh, next steps, um, uh, which we do in order to create the gateway or the SGP route, uh, as you can see, the, uh, the metadata file, the YAML files, which is required as the e k s object.
When you create the gateway, it creates the service network. And when you create dash DB route, it creates the services. So, um, it's, it's, it's all been available over here.
Uh, if you want to go through it yourself and do certain hands-on, uh, it's quite a good, uh, learning, which has been there, uh, step by step, which you can go through and have a look into, uh, and it'll, uh, go through the exact steps of what needs to be carried out. Yeah. Uh, feel free to ask many questions into the chat.
Um, uh, and, and any questions which you have, uh, around this topic, um, uh, and let me know, uh, any questions which you have. Okay. So again, the screen sharing is fair.
Uh, yeah, the session feedback, the most important part. I hope you liked my presentation. Um, as a w s we always believe in the data.
Um, so please, please, please provide us your feedback. Did you learn something new? Did you came across to learn something today?
Which you will planning to use it. Uh, if you need any help around, say you are already on a aws, uh, and you want to use this feature, or you want to do the workshop as a customer, uh, get in touch with the AWS account team and we'll be there to schedule a workshop or to walk through in more detail. Um, and yeah, uh, get started with VPC letters.
It's an absolutely fantastic feature, uh, uh, which has come across. And, uh, I hope, uh, you like the presentation. Thanks a lot, everyone.
Have a nice day, um, wherever you are. And, uh, enjoy the rest of the day. Cheers.
Thank you. Bye.





