Hello everyone, thanks for joining the session. AWS AWS AWS Networking simplified a comprehensive tour key features my goal today is of course to cover some of the key components on networking. Because time is limited, I won't be able to cover all the network components, but I will try to focus on the core networking component. So just to set expectation for the talk today, we are not going to go in depth into application architecture. We're mostly going to be talking about how can you understand some of the core networking fundamentals and some of the features that you can use for your organization or your personal use. To use the best of AWS. So quick Introduction my name is Samuel Barufi. I am a senior solutions architect here with AWS and I focus on supporting global financial services customers on their cloud journey. So without further ado, let's get started. Quick agenda. We're going to quickly talk about global infrastructure on AWS, some of the components, then we're going to dive deep into VPC. We're going to talk about VPC security. After that you're going to actually go to the meat of the presentation talking about empowering endpoints, gateways and global connectivity. What are the things you can use to really extend the capabilities of your AWS network and also potentially into your hybrid cloud? And to finalize, we're going to talk about a new service that was introduced last year, which is very exciting to simplify service to service connectivity. This is the one that will talk most about application connectivity and we're going to end the presentation talking about some of the tools that can help you operationalize your network, such as how can you have visibility into tour traffic and how can you monitor your traffic. So let's quickly talk about global infrastructure on AWS. So the global infrastructure on AWS is a forever growing footprint as of today, and this is very important. This might change in a couple of days, weeks and months. We have launch and available for you as a customer to consume 32 different regions across the globe. AWS you can see on this screen with a total of 102 availability zones and more than 450 points of presence for cloudfront distribution. The latest region that was made available a couple weeks ago was Israel. So how does AWS backbone infrastructure treats fault tolerance? So it's really important to understand that all regions are compromised of multiple availability zones for high availability and scalability. So if you look on this slide, you have a region within a region, you have multiple availability zones that are interconnected. So each region has two independent, fully redundant transit centers. So that's where the traffic goes. The transit center connects your region and the AZ that the region are part of to the bigger AWS ecosystem network. And each availability zone is highly redundant, connected to each other within the region. And then within each availability zone you might have one or more data centers that has independent power, networking and connectivity capacity. The data center this is a completely abstract scenario, but this is just to paint the picture on how, when you actually get to the real data center, how we are abstracting that for you as a customer. So now that we know about the regions, the global infrastructure, let's talk about the first component, which is Amazon Virtual private cloud, also known as VPC. So when you're building a VPC, VPC is the original construct. So you go to a region, in this example, go to region us east one, and then you create a VPC. VPC stands for virtual private cloud. It's your own private cloud. Nobody else has access other than you and your account within the VPC you are actually going to be, because VPC is a regional construct, you are going to choose different availability zones that your VPC are going to be spanning across. So in this case, just for demonstration, there are two availability zones, and you see that each availability zone, we have a specific id for your account. Then once you have the vpcs and you have the specific availability zones, you can create subnets within those availability zones and you can have public subnets and private subnets. Public subnets means you can actually have connectivity, both ingress and egress to the outside world. Private subnets means likely you are not going to have access to inbound connectivity from the Internet. So if you have a database, you might want to put that there. Once you deploy a specific resource, like in this picture on the public subnet, of course that resource. Let's talk about EC two. Elastic cloud compute, which is the virtual machine instance that you have on the cloud, is actually going to be hosted on a specific data center, on a specific rack on a specific host. But that is completely abstract from you, so you don't need to worry about it. You just know that that EC two is now running on a specific subnet and that subnet is part of a specific availability zone. And then of course you're going to have an elastic network interface that connects the EC two to the network on the subnet and on the VPC. Now when we talk about an important aspect of networking, which is IP addressing, let's start with IPV four. How does that work? So I'm going back to the scenario, or you have a VPC with two availability zones and two public subnets and two private subnets. The first thing you need to do is associated a cider rank. So an IP address block to the VPC. This case 100 zero is like 16. Now you go and you slice that big subnet from the VPC and you decide smaller subnets that are part of that big VPC subnet into your small subnet. So public subnet you're going to have a slash 24 and then the private subnet you're going to have a slash 24. If you're not familiar with subnets on IP addresses, the slash after that just mean the amount of bits that you're going to have available to actually consume within the subnet. So every single cider block that you see on the subnets are part of the bigger VPC cider block. Then when you create specific resources, in this case demonstrating on the public subnet, on both public subnets you're going to have a resource and you're going to have what we call EnI elastic network interface. That Eni will get an IP that is part of that specific subnet. So in the first example on the left, 100 138 is the IP address that your ECQ has been received. And on the other side 100 200, you can have multiple IP address in an ENI. And there is some limits that we're not going to talk today, but you can also have two different enis on an ECQ and they can have different private IP address. So software we are talking about private IP address. Another aspect that is important is vpcs can have secondary cider blocks. So in this case, let's say we have consumed most of the first cider block. Because VPC cider blocks, the primary cider blocks cannot be changed. You can only add new, so you can have secondary cider blocks into your VPC. So we've added a new one. And when you look here, it's interesting to know that when you create subnets you have IP addresses that are reserved. So the way it works is the first IP address is also going to be the network address. So we're not going to be able to use the first zero network address. The second one will always be your gateway, the VPC router gateway. The two and three are reserved. Maybe AWS will use that for other capabilities in the future. So AWs reserves that it cannot be consumed by your resources. And the two five five is always the network broadcast. And it doesn't matter. Each subnet will follow the same aspect because each subnet requires these five IP address to be reserved, and each one will have a specific purpose. Now, when we talked about public IP address, you can have public IP address associated, and when I mean public IP address, I'm talking about IP addresses that are routable on the Internet different than the IP address we've talked so far. So we see here on this slide, you have an IP address that have been associated to an EC two. You can also have elastic IP addresses where you can reserve a specific IP address for your account, and the difference is on the public subnet on the left side. If you're just requesting an IP address on your instance, but you don't have an elastic IP address association, it just means that if the instance is terminated, you are not guaranteed to keep the same IP address. If you create another instance or you restart that instance, maybe the IP address might change. But if you have an elastic IP address, that IP address is reserved for your account and you can always associate to a specific EC two instance or change in the future. So highly recommend that we use elastic IP address. And like I said here, you can just move okay, I want the IP address this time to be on this interface. If in the future you want that to be associated to another elastic network interface, you can definitely do it. So now let's talk about I-P-V six addressing. So as we know, I-P-V four s, especially public ipv four s are very limited, and I-P-V six have been kind of comes in to provide that solution for the limit amount of ips we have available. So AWS is highly supported and provides a lot of recommendations for customers. To use ipv six, you can run I-P-V six and I-P-V four s at the same time, also known as global. So in this scenario we're just going to look how you can add ipv six into this architecture. So you can go on your VPC and associated an ipv six block, which is a 56. Because now instead of only having 32 bits for your subnet as I-P-V four have, you have 128. And instead of just being numeric, it's actually hexadeximal. So you have many many more IP address. So associate to your VPC, you'll then associate it to the subnet, you do these lights again to the subnet, and then what you can actually do, you can see that some subnets can only have ipv four address, some subnets might have both. In this case, you want a private subnet to actually have an ipv six address, but the other subnet to not have there might be use cases why you want to do that. Then when you create an instance you can actually, if you see here on the left side, the instance can also receive an ipv six address that is local to tour subnet and the same reserved IP addresses that we talked on I-P-V four are also valid for ipv six. You can see here the demonstration that will be reserved from the specific 32 will be reserved. 64 is the VPC router and you can see the example on the right here. So continuing here, how does intravpc routing works? So within the VPC itself, right, intravPC means just within that single VPC. In this case, every time you add a specific subnet to your VPC, by default the route table that you're going to be associated, that is showing here on the screen is going to create a local target, meaning it doesn't need to route any traffic, it's already know because it's within the VPC and you're going to point all those subnets into this routing table. So if you need to talk from subnet one to private subnet one, assuming you have specific security permissions to do that, route wise you are fine. Network wise you are fine. Now let's talk about some of the VPC security components, which is important, right? We talked about the network layer. Let's talk about what the security network features of VPC are made available. So by default security groups are attached to resources like Ectus and it's very important way for you to decide what it's allowed for inbound and outbound. So by default the default security groups will always be that no traffic from outside, no traffic will be able to come into resource, but always traffic will be able to go out of the resource. So that is the default group rule for a security group. When you want to provide a web server example, let's say you have an EC two that is part of a subnet and you want to have maybe internal or external, whatever that may be, you want to provide access from a specific port. In this case we are allowing TCP port 80, which is the HTTP port. And when you see the source, zero zero means everybody. Unless you know what you're doing, you should always avoid to do zero zero because everyone, even if you have a public, especially when you have a public IP address associated to that security group, it means everyone will have access to that. So be careful when you do that. But then you can also have reference other groups in your security groups. And this is something not a lot of people are familiar, but it's a very nice way. So here, let's assume you have a EC two instance that is a web server and you have a database that EC two instance that is a database. Each EC two has a different security group. So we have a web server security group and you have a database security group. Let's assume you want to give access from the web server EC two to actually communicate with the database EC two. Sorry, yeah, exactly. With the database EC two, what you do here, instead of actually allowing from everything, and you could potentially just put the private IP address of the database security group. But then if the IP address change or if increase more instances, it's hard to maintain. What you can do is aws the source. So if you look on the right here where it says database security group inbound rules, you are saying please allow the port three three six on the protocol on the TCP protocol from the source security group web server. So whatever resources have this security group associated to will actually have access to talk to your database. So instead of putting IP addresses, you can put security groups, references. And this is very, very helpful. Another example is self referencing rules. So let's say you have multiple resources, ecqs that are using the same security group, and you actually want to give access across these resources for them to talk to each other. You can actually do a self reference on the same group and decide what is the inbound port that is allowed. So in this case, you just put port 80 and every single resource within this security group will be able to consume port 80 across this security group resources. One thing that is important to be aware with security groups, it means they are stateful. You only need to open the port that you require access. You don't need to think about the port that is coming back. And the reason why I'm talking about that is you also have another aspect of security on your network that is talked about network access control, also known as necklace NeCOs. Instead of actually being associated to a resource like an EC two, they are associated at a specific subnet and different than security groups. Necos network access control lists are stateless, meaning if you're allowing something to be accessed, you need to think about the traffic both ways. So there is something called the thermal ports. So if you're allowing something to go on port 80, you need to allow the thermal ports to be outbound as well. Just a small gotcha that I want you to know. But with knuckles, you can actually have inbound and outbound rooms similar to the security groups that are going to be evaluated at the subnet level. So you can actually both security groups and network access control lists work at the same time simultaneously. One is at the resource level and one is at the subnet level. So be careful when you're using necklace. You just want to make sure you know what you're doing. So we talked about VPCs, VPC securities. Let's just get a little bit more advanced here on peering endpoints, gateways and global connectivity. So first we are going to talk about net Gateway and Internet gateway. What are the differences between them? So going back to the example where you have a VPC and you have a VPC with duoistack, so you have ipv four and a pv six. Every time you want to have any instance to communicate to the outside, you need to deploy an Internet gateway. The Internet gateway is just a resource that easily you create and you associate to a VPC. So in this case we have an Internet gateway, it's associated to the VPC. Then you just have a routing table that says everything that it needs to go, everything that is not specific. So zero, zero or column column zero for ipv six, forward that traffic to the Internet gateway. So everything that needs to go outside will go to the right Internet gateway route. So in these cases, because you have IP addresses that are public, in this case you have ipv six on the left, private Subnet will go through the Internet gateway. Now you can also have net gateway and NATS stands for network address translations. Net are specific for ipv six, sorry, ipv four, mostly ipv four. What net does is allows private subnets that don't have public IP address to have outbound. So traffic going out, connectivity to the ward. So if you look here, this is the configuration we currently have, right? And you have deployed. Net gateway. So the net gateway you deploy in a public subnet because the net gateway needs to have a public IP address to communicate with the Internet gateway. What you can do is on your private subnet, you can say everything that needs to go out to the Internet instead of talking to the Internet gateway because it cannot talk to the Internet gateway because the resources on the private subnet do not have public IP address. I want you to forward the traffic to the Nat gateway and you deploy Nat gateway across subnets into different availability zones for redundancy reasons. And once the traffic goes to the NaT gateway, Nat gateway, because it has a public IP address, will send the traffic to the Internet gateway. So in this case, the private subnets are only able to go outbound, connectivity because the private subnets here on the right don't have a public IP address. They don't have the ability to actually receive inbound traffic, which is good because you want to have security. Let's say you have a database, you don't want the database to have a public IP address. So another scenario here, another type of Internet gateway, and this is very specific, it's called the egress only Internet gateway because on IPV six we are not doing that. And you can see that on my left, Private subnet, I have an IPV six address. If I only want that IPV six to be able to send traffic outbound. So egress rather than inbound, I can create an egress only and then I can associate it into this private subnet. I can associate it a routing table that says if you need to go out, use the egress only Internet gateway. What this will do is block the ability of this IPV six to receive traffic from the Internet. So you can only initiate traffic to the Internet, but not traffic coming from the Internet to your IPV six. This is a very recommended way once you want to have IPV six on your private subnets and you can just associate it. So in this case the full solution will kind of be this, right, you have some subnets, in this case the public subnets will talk directly to the Internet gateway, but then you have some subnets in case the private subnets that in the IPV six will talk to the egress only Internet gateway. And I-P-V four will talk to the net gateway specifically. So you can use a combination of these tools to achieve the specific use case you are trying to do. Now, we talked about peering and then we talked about net gateways and Internet gateways. Let's talk about peer with transit gateway endpoints and other types of empowering. So let's talk first about VPC empowering. Let's assume you have a scenario, you have two vpcs, right? And those vpcs need to talk to each other. So you have maybe resources that are across vpcs and you want to connect them together. You can use what we call the VPC peering connection. You literally just choose a specific VPC and the other VPC, you link them together, always a one to one relationship. And then on your routing table on both sides you specify the IPV four or IPV six and I-P-V six address that is on the other side and how you can get there. So in this case, if you want to go from the VPC on the right and you want to access the VPC on the left. The IPV four on the VPC on the left is 100, zero is like 16. And how you get there is going through the peering connection. In this case it's PCX 1234 address. So very simple. There is no additional cost, only the data transfer cost that is associated with VPC peering. Now there is a challenge with VPC peering. Let's assume you have one, two, three tour, five vpcs created. And let's assume each VPC needs to be able to talk to each other. Now you're getting to the sense that because VPC peerings are one to one relationship and they cannot hop over, you need to create. So if you have each VPC, in this case you need to have four empowering connections attached to it. That becomes really hard when you have a lot of vpcs and really hard to maintain. And that's why AWS released a service called Transit Gateway instead of having that complexity network of multiple peers. What you can do, you can create a specific AWS transit gateway on a specific region. So we're talking about a regional construct here. And then you can create a single attachment for each VPC. So you have attachment one goes to VPC one, attachment three goes to VPC three within a single region. Then you have different routing tables on the AWS transit gateway saying that, okay, if VPC one wants to talk to VPC four, the way it's guest to that traffic is going by attach number four, or if it wants to talk to VPC five, it goes to attach number five and so forth. So you can see here where you can have a centralized routing table that can aggregate everything together and you can exponentially add more vpcs and it's just going to be an entry on your routing table and an attachment. You don't need to have multiple managements of VPC peering, AWS you had with the VPC example before. Now, the cool thing about transit is it also supports multiregion, which is very exciting. So in the example here, let's assume you have, let's say you have four regions, you have region one, region two, region three and region four, and you have a couple of vpcs within the region and you already have maybe transit gateway deployed within the region. How about if maybe for a multi region architecture or maybe Dr. Purpose, the resources across regions needs to talk to each other. It's not that hard. With transit gateway, you can create transit gateway peering attachments, so you can have different transit gateways across the region that are peered with each other. And then in this scenario and this diagram that I'm showing, you are actually able to consume across different regions. So kind of moving into another aspect is every time you need to consume. So let's say you have, in this example, you have this EC two that is sitting on the private subnet. If I need to access services, AWS services API, let's say I want to talk to a specific kms key API. The way it works is by default is you are going to have an Internet gateway in your VPC because this is a private resource you need, not gateway. And the traffic will go as follow. We're going to have the routing tables. The routing tables will tell, okay, if you want to talk to anything in the Internet, go through not gateway, not where to go through Internet gateway, then go through the Internet and then talk to the public API of these services, let's say the public API of kms. This is okay and this is the default behavior. The challenge here is you're sending traffic over the Internet even though these API calls are encrypted in transit, it's going through the Internet. There are occasions you do not want to use the Internet. How can you do that? Well, you can use something called the VPC endpoints. So what the VPC endpoints is in the same scenario, you have some services here that you want to consume. In this example here, some list. Now what you can do, you can create an interface. There are two types. First, we're going to talk about the interface endpoint. When you create an interface endpoint, you choose what service that interface is going to be able to allow consumption for you. So let's say this is KMs what the interface endpoint will do. You create a specific elastic network interface within your subnet and you can associate your interface endpoint through multiple subnets. And let's give the example. You want to go to kms again, but you don't want to use the Internet. You want to use the AWS backbone connectivity that never touches the Internet. With interface endpoint, every time you have a resource that wants to talk to a specific API or a specific resource on AWS, you go directly. So the error that you see here is using the AWS backbone connectivity, you're not going through the Internet. And in this case here, you don't even need a net gateway or an Internet gateway because let's assume this EC two does not require Internet connectivity. It just requires some API services. On AWS connectivity, like talking to kms or maybe grabbing a file from S three. You don't need to do that. So the solution behind the scenes using private link, which we will talk in a moment, what private link does, but it's pretty much doing a magic every time you call a AWS API, there will be a DNS and you automatically resolve the DNS into a private IP address rather than resolving it to a public IP address. But there is a second type of endpoint that is called the VPC gateway endpoint. The VPC gateway endpoint only supports two services, s three and DynamDB. And the main difference is instead of being an interface endpoint, meaning creating an elastic network interface on your subnet, it's deployed at a gateway level of your subnet. So if you need to talk to S three and Dynamo, you actually have a routing table. The routing table send the traffic direct, your gateway endpoint and then the gateway endpoint to talk to S three. There are some pros and cons on using one another. Interface endpoints has vast support of services, but there is a cost associated gateway endpoints have just limited two services and there is no cost associated. So your miles might vary depending on your use case. So the cool thing is you can also create specific endpoint policies. So on your VPC endpoints you can create a policy to secure what type of connectivity you want to allow. This is also known as a resource policy, in this case VPC endpoint policy. It's following the same JSON policy, AWS tour identity, IAM policy. In this example I'm restricting only once I created an endpoint. And with this specific JSON policy. What I'm saying is this allows for any actions, any resources, but only if the role that is trying to invoke this specific endpoint is the role that is associating here. But you can have very fine granular details on how you actually decide this. So it's just hopefully you can arm your tool set of more things that you can do to secure your environment. Now, private link, right? So private link is the technology that runs on top of the VPC interface endpoint. The cool thing about private link is you can create specific solutions for your like using the same backbone network private connectivity of AWS if you have consumers that want know consume services from you. So let's say you are a company, a SaaS company, whatever it is that you are providing a service and tour customers which are the vpcs on the left. Once you consume your service into a private way within AWS, but you have your account and they have their own account and you have different vpcs. What you can do is you can create a private link service which deploys an interface endpoint on the consumer vpcs, similar as we've seen, the endpoint VPC interface that I just talked about it. And then you can deploy your application and the way you do, you just deploy a network cloud balancer and you put your application behind the network load balancer. So when the consumer VPC is talking to your application, you actually be using the interface endpoints and using the private backbone of AWS to talk to your application. So hopefully you can use this to really provide better private connectivity for your customers. So now we're going to talk. There is one more thing that I'm going to talk about. It is once you have a global connectivity, maybe hybrid cloud, what are the options available for you to consume? So let's talk about hybrid connectivity and DNS. So first we are going to talk about direct Connect site to site client VPN and then browse 53. Let's start with direct connect. Direct Connect allows you to connect your data centers or offices by literally having a direct cable connecting you and AWS. So you have a region on AWS and you have your data center. Then you choose a specific direct location. There are partners direct connect locations and there are AWS direct connect locations. There is literally a cable, a fiber cable, a private fiber cable that will be connected between your customer router on your data center and the direct connect router. Then you have resources on your region and you can actually access privately from your data center going through the private cable that you run into direct connect. And then direct connect will connect your specific AWS account. This is very commonly used when you have a hybrid connectivity for your specific. And you know, here you have a direct connect gateway and you can also with direct Connect gateway you can use one thing here. What this picture is saying. Like you can have different types of direct connect. One type of direct connect is just allowing your data center or corporate office to access a specific AWS APIs in a private scenario. But you can also have a direct connect gateway that allows the traffic from your on premise data centers to connect to the resources that exist on your AWS account. So you can see here how this gets together, right? Like it kind of connects them together. And then in this case, if you want to encrypt, you can actually put a VPN on top of that. Because by default the traffic between your data center and the reconnect, even though they are private, they are not encrypted by default. So you can put a Ipsec VPN which this is showing for you that you can achieve. But now if you don't have a lot of resources and you don't have a lot of time and you don't require a lot of bandwidth, you can just use a site to site VPN. With site to site VPC you have your on premise network, you have your own router. Then you create a virtual private cloud. On the cloud you create an iPsec VPN which is using the Internet. So rather than have a private connectivity, even though it's secure and encrypt, is actually using the Internet as a way to talk to your resources. So how would use. You can actually now put together everything that I just talked about with transit. So you can have a transgender that has VPC attachments and then you can have VPAN connectivity across multiple on premise networks. Let's say you have multiple private branches or data centers. Instead of having to connect to each VPC, you can have the transit gateway being the centralization. So apologies. So the transit gate will not only solve your problem internally within AWS, but also for your hybrid cloud. Now there is another type of VPN which is very specific. It's called the client VPN. Let's assume you have developers that want to have access, private access to tour AWS network running on their laptop. So maybe they are working remote and you want to provide them the ability to consume resources that are available within your AWS. So you deployed a service called the client VPC endpoint. You can install a software on developers client laptop and they're going to connect to the client VPN endpoint and then they're going to have access to tour VPC endpoint. In this case the ten 10 is 60. I'm just going to take up a sip of water. So this is a way you can achieve that. So it's fully managed, you don't need to do anything. It supports splitting. So it means that if you only want to send traffic for the IP address from specific subnets or the whole VPC, you can support that. Or you can send all the traffic, even Internet traffic to your account. And you can also do client authentication using active directory or other types of federation. And in dance you provide client to client connectivity. Even like you can actually talk to each other if you deem necessary. So how do we bring all together? So in this case we have a region multiple VPC and you have maybe a couple of data centers. So here you have a nag gateway. We talked about the Internet gateway egress only. For IPV six you have transit gateway connecting different maybe vpcs. Or you can choose to have a VPC peering endpoint. You can have specific endpoints if you are consuming specific services, but then you can have direct connect from your on premise branch or maybe data center. You can also have direct connect gateway if you want to access those resources. Or you can choose to have a VPN site to site connectivity. So I know this is a lot, but this is to show you that the capabilities and choices are here for you to choose. One thing I want to talk about it is DNS quickly. So Amazon route 53 is the DNS service on AWS and Amazon Route 53 resolver allows domain name resolutions to be done internally, kind of super transparently. So all the Amazon provide dnss, which is the VPC plus two are done automatically if you choose when you're deploying your architecture. So you can support DNS host names, you can have private host names. So when you create an EC two you can have this private hostname. The reason why your VPC know how to resolve this is because route 53, so these specific DNS can be resolved to a specific IP address because the route 53 resolver for VPC is available. You can also support resource based private VPC. So in this case it's using the resource based IP address, not the DNS with the IP address itself. You can also resolve public DNS names and it's as simple as on the VPC you can just decide if you have DNS host names and DNS resolution enabled. By default those are enabled. So let's talk about the simplified. So we talked about a lot of things that are not very specific to application, but I just want to present to you again to have that on your toolbox is a service that can simplify server to service connectivity. The name of this service is VPC lattice VPC lattice allows you to have a service mesh for cross account cross VPC connections without having to managing peers transit gateways or like being worrying about overlapping cider ranges with IP address or maybe ipv six address. It supports a consistent number of services, compute services like eks, EC two lambda and elastic compute service elastic container service. Sorry. By default it works at a layer seven protocol so you know how to do proper HTTP routing and so forth. And there is a lot of security being made available for you so you can centralize the control of your inbound and outbound traffic for internal communication. How does that work? Right, so let's say you have two vpcs and you have a VPC where that VPC, you have a service that is the parking service and then you have another VPC that runs. It could be cross account or it cloud be in the same account and you actually don't want to create a VPC peering connectivity. You don't want to create a net a transit gateway, you don't want to create the routings. You just literally want to give the parking service access to the billing service. What you can do, you can easily have the VPC lattice service network deployed across these two VPC and connect the instance to the VPC lattice service network that will allow simple cross VPC connectivity without needing to manage anything that I just talked about previously. So this is kind of literally a mindset change on how you can architect your solutions. Let me give you more examples. Let's say you want to have different HTTP APIs and you want to decide specific path basis rules. So let's say you have a service, again that is a billing service and you have resources on the VPC and you want to send that depending on the path you go. So let's say you go with API parking, you want to send that to a specific VPC that have its own resources that are managing the parking. Or when you go to API inventory, you want to send to another VPC. You don't need to do anything other than creating the routing rules on the VPC lattice service network. So every time the service billing will go and talk to API inventory, the VPC Lida service network will know what to forward to, in this case the VPC tree. Another example is granular ways to secure access to service to service. So you can actually specify who are the consumers. In this case the billing. You can say like you can have multiple services on your service network and you can decide for example the billing service can only talk to the parking service, it shouldn't be able to talk to the inventory. You can create those rules and you can have a lot of specific rules configured on the VPC lattice service network saying the billing service only talks to the parking, not through the inventory. And you can have very complex and fine grained permissions to achieve what we call zero trust. So another thing here that I want to show is to kind of end the presentation is how can you achieve traffic visibility and monitoring. So first is VPC flow log. VPC flow logs. Here you just have an example. Provides all the VPC data like the traffic. If you enable the traffic that is going on, your VPC can be logged on a very specific format so you can have the version, the account where it's going, what is the IP address, what is the region, what is the availability, so on and so forth. And then you can actually query that can be saved on Cloudwatch or can be saved on s three and you can actually query to see specific. In this example, it's like, hey, can I tell the connectivity between these two address, how much bytes have been transferred on this specific time frame? So you can do that with VPC follow ups. Highly recommend everyone to enable VPC follow ups because that gives you the security and ability to inspect what type of network connectivity have been enabled on your account. Another interesting feature that you can enable on VPC is called the traffic mirroring. So traffic mirroring is really important if you want to do like traffic inspection or any type of security real time capability, but you don't want to impact the performance of your current architecture. So what you can do, you can literally go and enable. In this case, there is no traffic enabled, but you can enable now a traffic. And once you enable, so you click to enable the traffic. What did you do? Every single packet that has been sent tour specific VPC work properly. But once you enable VPC traffic mirroring, you can create a monitoring instance. So you can create your own traffic analyzer using open source traffic analysis or using AWS traffic mirroring partners. Every single packet that is sent to your VPC will be replicated and mirrored into that specific ENi. And then you can create a lot of specific security inspections in real time. And that concludes my presentation. I hope you were able to learn some of the key components. I know there was a lot that I covered and I kind of went little bit quickly. If you have any questions, feel free to connect with me on LinkedIn. My name is Samuel Baruffi. I appreciate your time, thank you so much and bye.