🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - AWS Networking Fundamentals: Connect, secure and scale (NET208)
In this video, Rohit Aswani and Dave DeRicco present AWS Networking Fundamentals, covering AWS global infrastructure with 38 regions and 146+ Direct Connect locations. They explain Amazon VPC fundamentals including IPv4/IPv6 addressing, VPC IPAM for IP management, subnets, route tables, and security controls like NACLs and security groups. The session covers connectivity options: internet connectivity via Internet Gateway and NAT Gateway with DNS64 support, hybrid connectivity through AWS Direct Connect and Site-to-Site VPN, and VPC-to-VPC connectivity using VPC Peering, Transit Gateway, and AWS Cloud WAN. Application networking is demonstrated through AWS PrivateLink, VPC Resources, and Amazon VPC Lattice. Load balancing options include Application Load Balancer, Network Load Balancer, and Gateway Load Balancer. DNS capabilities are explained via Route 53 Resolver, private hosted zones, and Route 53 Profiles. Traffic inspection architectures use AWS Network Firewall and Gateway Load Balancer in distributed or centralized models. Remote access solutions include AWS Client VPN and AWS Verified Access. Monitoring tools covered are VPC Flow Logs, Network Manager, CloudWatch Internet Monitor, VPC Reachability Analyzer, and Network Access Analyzer for comprehensive network observability and troubleshooting.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Welcome to NET208: AWS Networking Fundamentals Session
Welcome to Reinvent 2025. Thank you for joining us for our session. This is the first session of the day, so thank you for coming in and I appreciate you starting your day with us. This is NET208: AWS Networking Fundamentals—Connect, Secure and Scale. My name is Rohit Aswani. I'm a Principal Solutions Architect for Networking Specialist within Worldwide Public Sector at AWS, and I'm excited to be joined by my colleague. Hey folks, my name's Dave DeRicco. I'm a Senior Specialist Technical Account Manager for Networking, which is a mouthful, but I'm part of our Enterprise Support team here at AWS. Thanks, Dave.
So the agenda for today's session is we will start with global infrastructure, then we'll dive into the fundamentals of Amazon Virtual Private Cloud. Once we understand those fundamentals, we will go into the different connectivity options. We'll cover internet connectivity, hybrid connectivity, application networking, and remote access connectivity. Then we'll dive into the DNS piece of it, followed by how you can do traffic inspection with various types of firewalls on AWS, and finally how you can monitor your network along with observability.
Before we begin, this is a 200-level session designed to give you the basic building blocks of networking on AWS Cloud. We expect that you have some familiarity with fundamental constructs such as CIDR notation, DNS, IP routing, and so on. You can take pictures along the way, but we will be posting these slides on the AWS Event Content page, so you will have access to them later as well.
AWS Global Infrastructure: Regions, Availability Zones, and Virtual Private Cloud
With that, let's start with a view of the AWS global infrastructure. AWS's global infrastructure includes 38 regions. We have 45 or more local zones and we have over 146 Direct Connect points of presence. All of this global infrastructure is connected with the AWS backbone that we have built. It is the most secure and reliable backbone network that we have built, and you can scan this QR code that will take you to the page on the AWS Global Network that you can look at afterwards.
Now let's zoom in a bit more into the construct of a region. AWS has the construct of a region, which is a physical location around the world where we cluster data centers. All of these data centers are interconnected with each other with high-speed, high-bandwidth throughput and low-latency links. We encrypt traffic when it leaves our secured facilities. A cluster of these data centers is what we call an availability zone. Here you can see there are three availability zones that I'm showing, and all of these availability zones are also connected with high bandwidth and low-latency links. We also encrypt traffic when it leaves these availability zones.
Now, having talked about regions and availability zones, you then create what we call an Amazon Virtual Private Cloud, which is a logically isolated part of your network that you get to define, similar to your data center. Now within this region, you have availability zones, and availability zones have data centers. Within these data centers, we have different racks, and your Amazon EC2 instances live on one of these racks here.
IPv4 and IPv6 Addressing Options on AWS
Now, with this understanding of global infrastructure, let's start to understand the IPv4 and IPv6 addressing options that we have on AWS. But before we do that, let's define how AWS thinks about public and private IP addressing on AWS. The way we define this is in terms of advertisement. AWS considers public IP addresses as those advertised on the internet, whereas private IP addresses are the ones that are not and cannot be advertised on the internet from AWS.
Now with this definition, there are different options that you can think about. On the left-hand side, we have IPv4 and IPv6, and at the top you have public and private IP addresses. Let's start with public IPv4. You can get a public IPv4 address space directly from Amazon or you can bring your own. You can follow the Bring Your Own IP process to advertise that from AWS. You can also get a contiguous IP block from AWS as well. In case of private IPv4, this is something that you must already be familiar with. This is the RFC 1918 range, which is 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and so on and so forth.
We also have the CIDR range that you can use for your private IPv4 addresses, and you can also choose to use a public IPv4 address space and assign it to the VPC. However, we will treat that as private in this case. In case of public IPv6, these are global Unicast addresses that you can use, and you can get this either from Amazon or you can bring your own. In case of private IPv6, these are similar to your RFC 1918 range because these are not advertised on the internet, and you have the option of using unique local addresses. You can also use a public IP space for your VPC CIDR, and you can also use private IPv6 UA space for your VPC CIDR as well.
So far we have talked about IPv4 and IPv6, and we will be showing IPv6 throughout the session. What I'm going to do is define how IPv6 on AWS is supported. You have IPv6 configuration that you can define in two different modes: dual stack as well as IPv6 only. Then we have AWS public service endpoints that you use to access AWS services, and the last one is the private service endpoints powered by AWS PrivateLink, which we are going to see in the following slides as well. As of today, we support 150 plus AWS services that support IPv6.
Amazon VPC Fundamentals: Building and Securing Your Virtual Network
Now you may be asking where do I go find all these 150 services. Here's a QR code that takes you to a central page where we list all the AWS services that support IPv6. Now let's dive into the fundamentals of Amazon VPC. So now you want to build your first VPC. We talked about a region and region has availability zones. Here I'm showing two availability zones. Your VPC is a regional construct, and you define a CIDR range for a VPC. Here I'm choosing a 10/16, and an IPv4 CIDR range for your VPC. When you do that, this makes your VPC a dual stack VPC.
But now you might be thinking, this is a single VPC, single region. What if I'm operating in multiple accounts and multiple regions? How do I do this at scale? To do that, you can use Amazon VPC IP Address Manager that allows you to automate IP address assignments. You can plan and track your IP addresses on AWS. We'll start with an example of private IPv4. So we talked about the IP addressing options on AWS, which is public and private for both IPv4 and IPv6. We'll take an example of private IPv4. When you integrate with Amazon VPC IP Address Manager, also known as VPC IPAM, we define two scopes: a private and a public scope. A scope is nothing but a container. Within a private scope, since it's private IPv4, you define this into the private scope. You create a top-level pool. Here I'm showing a /12 as an example, and then I'm operating in three regions, for example, and each region has a /14.
The way I'm dividing this IP address space is based on my organizational rules. For example, you have a dev pool and a prod pool, and you can have many other pools like staging and test as well. Here I'm showing a /16. If you're operating across multiple accounts and multiple regions, you can integrate with AWS Organizations and you can share these environment pools such as dev and prod with different accounts. Then each application owner can go ahead and request a /24, for example, to get that IP address space, and you can do this across all different regions as well.
Now, what about IPv6? Here's another example. I'm showing an example of bring your own IPv6 with GUA, which is an advertised space. As I mentioned, you have different scopes, you put that in the public scope and you can have the rest of the hierarchy the same. Now, let's bring our dual stack VPC that we just built before and apply these constructs. You get this IP address range now from IPAM and assign it to your VPC. Within a VPC, then you create different subnets. Since we have IPv4 and IPv6 supported, you can have an IPv4 only subnet. You can have a dual stack subnet, and you can also have an IPv6 only subnet as well.
Now for IPv4, we support creating a subnet size of /28 to /16. In case of IPv6, we support anything from /44 to /64 in increments of 4. Once you define these subnets, subnets are tied to a specific availability zone, as you can see, and you can have many subnets that can reside within the VPC.
Now each subnet has a route table associated with it. When you have both IPv4 and IPv6 CIDR assigned to your VPC, by default we add a local route within the VPC that allows you to connect with resources within the VPC. You can see here a route table with other things that we will explore, such as how you can enable connectivity to the internet, hybrid connectivity, and so on. We will talk about examples of how those route tables will look.
Once you define that, you can then create and launch your resources such as Amazon EC2 instances, RDS, load balancers, and so forth. Here I'm showing an example with dual stack and IPv6 on the subnet. Each instance gets an elastic network interface, and it gets an IP address range from the subnet in which it is created. Once we create these instances, they also have some local services available to them. For example, we have Amazon EC2 Instance Metadata Service, Amazon Time Sync Service, and Route 53 Resolver service. These services are available to your instances locally, and you can use Amazon EC2 Instance Metadata Service to get user data and so forth.
Keep in mind that we have both IPv4 and IPv6 endpoints supported for these services. For IPv6, you can access this using Nitro-based instance types. Now let's look at Amazon VPC DNS. Every VPC comes with a purpose-built DNS resolver at the VPC CIDR range plus 2, and we also have the IPv6 address space. We will see examples of VPC DNS when we discuss this further in the session.
Now let's talk about the fundamental security that you get on AWS. We'll start with network access control lists, which we also call NACLs. Network access control lists are stateless in nature and are defined at the subnet level. When you define rules at the subnet level, you can create both allow and deny rules. Based on how you define your rules, your traffic will be either allowed or denied. The second option is to use security groups. Security groups are stateful in nature, functioning like a firewall that you can apply at the elastic network interface or EC2 instance level. You can control access with security groups, which can only have allow rules. By default with security groups, if you have an egress rule that allows traffic to access a database, for example, the inbound traffic is automatically allowed as well.
Internet Connectivity: Public Subnets, NAT Gateways, and IPv6 Translation
Now we are talking about IPv6-only subnets, but we are living in a world where we have both IPv4 and IPv6. How do we ensure backwards compatibility in that case? Here I have an IPv6-only subnet with an instance within it. If that instance makes a query to an IPv4-only domain, it goes to the Amazon VPC DNS server that every VPC gets, which performs a recursive lookup to Route 53 and gets a response back with an IPv4 address space. Now you have an instance that is IPv6-only, but the IP address it's getting is IPv4. How does the backward translation happen here?
To do that, we support DNS64. It is a setting that you can enable on the IPv6-only subnet. What this does is when the instance makes a query to the Route 53 DNS resolver, it gets a synthesized IPv6 address space in hexadecimal format. Here you see a hexadecimal format of the same IPv4 address space that the instance got from that query. DNS64 is just for getting that address space that the instance can then reach out to. We will see in further slides how you can apply these constructs when you want to actually enable connectivity to an IPv4 destination.
With that, we will transition into talking about how you can establish connectivity to the internet from your VPC. We will start with public subnets. A public subnet is something that has a route table pointing to an internet gateway. You create an internet gateway and associate it with your VPC. The internet gateway does the translation of private IPv4 to the public or elastic IP of that instance, and you add a route into the VPC route table pointing to the IPv4 default route.
With this route in place, your IPv4 instances can establish connectivity to IPv4 destinations. Similarly, in a dual stack subnet, you add a default route for IPv6 , and then it can also connect to IPv4 destinations. The Internet Gateway supports both IPv4 and IPv6 traffic. Keep in mind that the 1-to-1 NAT translation that the Internet Gateway performs is for IPv4.
We also discussed public IPv6-only subnets. In this case, the Internet Gateway can connect to both IPv4 and IPv6 destinations. However, for IPv4, you can create a NAT gateway, which is an AWS network address translation service that allows you to translate traffic from private IPv4 to internet destinations. You can enable DNS64 since it's an IPv6-only address space, and you specify the well-known prefix 64:ff9b::/96, which points to the NAT gateway. When the NAT gateway sees traffic coming from this well-known prefix, it knows that it needs to translate from IPv6 to IPv4 automatically. This can be done on your existing NAT gateways without creating any new ones.
Keep in mind that I mentioned a zonal NAT gateway, but a couple of weeks ago we also launched a regional NAT gateway that you can use for these purposes. Now, what about private subnets? In the case of private subnets, you have to create a public NAT gateway that can then route via Internet Gateway to reach IPv4 destinations. The same approach works from a dual stack subnet for IPv4, but for IPv6, you can use what we call an egress-only Internet Gateway that allows you to initiate outbound connectivity from your VPC to IPv6 destinations. Similarly, for private IPv6-only subnets, you define an egress-only Internet Gateway to communicate with IPv6 destinations, and again you can use the well-known prefix via NAT gateway to communicate with IPv4 destinations. This provides backwards compatibility with IPv6-to-IPv4 translation.
So far we have discussed having internet access, but you may have a requirement where you want to block that internet connectivity. You can block this using what we call Amazon VPC Block Public Access. It comes in two different modes: bidirectional and ingress-only. In bidirectional mode, we block both internet ingress and egress, and in ingress-only mode, we block only ingress. You can apply this at the AWS account, Organizations, or organizational unit level. If you want to create exclusions, you can do that as well, including for your egress inspection.
VPC-to-VPC Connectivity: Peering, Transit Gateway, and AWS Cloud WAN
We have talked about Amazon VPC so far, and this Amazon VPC is tied to an AWS account, but you have different subnets within that VPC. What you can do is share your subnets that are part of the same VPC with different accounts using AWS Resource Access Manager. Those shared subnets can then allow the participants to create resources within them. This is helpful if you want to conserve your IPv6 address space and you have separation of duties between the networking and security teams. You can still control access between different subnets using security groups and network ACLs that we discussed, or by putting a firewall between them, which Dave will discuss later.
Now that we have covered connectivity to the internet, what about connectivity to AWS services? You can use gateway endpoints to access AWS services such as Amazon S3 and Amazon DynamoDB. What you do is create a gateway endpoint, and we support dual stack, IPv4-only, and IPv6-only options. What this does is automatically add a prefix list for that service within your VPC route table. You can do this for both IPv4 and IPv6 now, and this allows connectivity from your EC2 instances to S3 and DynamoDB over the AWS backbone. It is private and secure, and you do not have to create any other gateways to establish that connectivity.
What about other AWS services? We also have interface VPC endpoints for AWS services. What you can do here is create what we call an interface endpoint, also known as a PrivateLink endpoint, which creates an elastic network interface within the VPC. We support both IPv4 and IPv6 and dual stack options. The instances then send traffic to these AWS services privately and securely, and you can access these services.
We support over 170 plus services . Let's talk about VPC to VPC connectivity. The simplest way to connect two VPCs in a region is to use Amazon VPC peering. Here you can see you have two VPCs that are non-overlapping. We create and update the VPC route table pointing to the peering connection ID of the other VPC, and the instances can communicate with each other.
Is this traffic encrypted? To address that, we just introduced VPC encryption controls. This is a new capability that you can use to audit and enforce encryption in transit for all of your traffic within the VPC and across VPCs in a single region. It comes in two modes: monitor and enforce mode. In monitor mode, you can monitor your traffic within the VPC and look at resources that are not encrypting traffic. You can use VPC flow logs which will help identify those resources. In enforce mode, you can enforce which services and resources encrypt traffic, and you can also create exclusions if you want to allow internet destinations and some other destinations as well.
So how does this work with VPC encryption controls? You create an enforce encryption policy on your VPCs that then encrypts the traffic between two Nitro-supported instances over that VPC peering connection. You also have peering that supports across regions as well. Everything works the same way. But what if you want to have VPCs that need to scale more than what VPC peering supports, and you want to have transitive routing as well? You can do that with Transit Gateway.
Transit Gateway is a layer 3 routing virtual router service that allows you to connect multiple VPCs, and you can define your VPC route tables and point to the Transit Gateway as the next hop for both IPv4 and IPv6 traffic. You can have transit gateways in one region or in another in the same region, and you can peer them together, or they can be in different regions and you can peer them. However, in this case we only support static routing. With static routing, if you add another region or a VPC, then you have to statically add routes across all your network, and that can become cumbersome.
To address that challenge, you can use AWS Cloud WAN and build global WAN connectivity. Here I'm showing a three-region deployment where you can manage this network using a JSON policy document across your three regions. What it does is create a transit gateway managed by AWS, and we support dynamic routing across this network. AWS Cloud WAN also has a concept of segments, which is similar to a VRF that you might be familiar with. You can have these segments either globally or you can have regional segments as well. Resources that are VPCs connected to the same segment enable connectivity, but you can prevent that communication by setting this flag. Your VPCs can attach to the Cloud WAN by attaching the policy, and you can define rules saying that if there is a specific tag, go ahead and associate to the specific segment.
Hybrid Connectivity: AWS Direct Connect, Site-to-Site VPN, and SD-WAN Integration
How do you share routes? You can do segment route sharing, and this is also controlled through the policy as well. Now let's talk about hybrid connectivity. The first option is to use AWS Direct Connect, which is a private dedicated connection from your corporate data center to AWS bypassing the internet. The way it supports that is you connect to one of our AWS Direct Connect locations. You can either have a dedicated connection or a hosted connection. It comes in different speeds. At this location you have an AWS router, and you may either have your own router or you can work with a partner that has their own router and create a cross-connect between them. You can extend connectivity to your corporate network through that partner network. That's your physical connection.
Now, what about the logical connection? You create logical connectivity using virtual interfaces. You can create a public VIF to access public services, and when you do that, we set up an EBGP which supports both IPv4 and IPv6, and we advertise all AWS prefixes back to your on-premises network. You can also connect to a VPC using a construct called a Direct Connect gateway and a virtual private gateway. The Direct Connect gateway is a global construct which is highly available and highly redundant. It allows you connectivity to multiple VPCs in different regions as well. In this case, Direct Connect gateway has a construct called allowed prefixes where all the VPCs that are connected through that Direct Connect gateway via a virtual private gateway, we advertise those prefixes back to your on-premises network.
What about Transit Gateway? You can create a transit VIF connecting to the Direct Connect gateway, which then connects to the Transit Gateway, and then on the Direct Connect gateway you specify what we call allowed prefixes
on the Direct Connect gateway. These are all the prefixes of your VPCs that you want to advertise back to your on-premises network.
Cloud WAN also supports integration with a transit interconnect with Direct Connect Gateway. Now let's talk about site-to-site VPN. A site-to-site VPN connection allows you to create IPSec encrypted tunnels from your corporate data center to AWS. On the AWS side, you can terminate this VPN connection on a virtual private gateway, and when you do that, we create two tunnels. Each tunnel is 1.25 gigabits, and only one tunnel is active at any given point in time. We do not support ECMP in this case, and we support both static and dynamic routing.
What if you want to connect to multiple VPCs? You can terminate that VPN connection on the transit gateway instead. With Transit Gateway, you get additional benefits such as IPv6 support. We recently announced larger bandwidth tunnels where you can have up to 5 gigabits of bandwidth on each tunnel. The same thing works for AWS Cloud WAN as well, where you can have multiple VPN connections that are supported and you can do ECMP in this phase along with the other features I just talked about.
What if you now want to integrate your SD-WAN appliances? Here you have VPCs connected to the transit gateway or Cloud WAN, and you have a corporate data center. You can deploy these SD-WAN appliances within the VPC with the VPC attachment as the underlay. On top of it, you create a GRE tunnel and exchange BGP prefixes from these SD-WAN appliances with either transit gateway or Cloud WAN, and you can further extend connectivity to your corporate data center with either virtual private gateway or internet.
What if you don't want to have those tunnels to manage and you want to get the full bandwidth? You can do that on Cloud WAN where you don't have to manage those tunnels and you can get tunnel-less connectivity with Cloud WAN.
Application Networking with Load Balancers, AWS PrivateLink, and Amazon VPC Lattice
Let's talk about Elastic Load Balancing now. The first option in Elastic Load Balancing is Application Load Balancer. This is a Layer 7 load balancer that allows you to load balance incoming traffic on HTTP and HTTPS to your applications. On the Application Load Balancer, we support advanced request routing. You can do things such as path-based routing, host-based routing, query string, and so on. We recently announced a couple of months ago header modification where you can modify these headers before they get sent to the targets. The Application Load Balancer can then load balance traffic across these instances, and you can use different types of load balancing algorithms that we support.
The second option is to use a Network Load Balancer. With Network Load Balancer, the beauty here is that it supports static IP addressing, which means that you can use these static IP addresses to either allow list your specific firewalls or specific clients that you want to do that. We support both TCP, UDP, and TLS, and we recently announced support for QUIC protocol as well on Network Load Balancer. Once the load balancer receives that traffic, it can load balance traffic across your targets, and we support both IPv4 and IPv6 targets. With the target group, we recently announced weighted targets with Network Load Balancer as well.
So far we've been focusing on Layer 3 connectivity between our VPCs, but there's another way we can think about connecting our applications together, and that's with application networking. Application networking is a little bit different if you're not super familiar with it. Essentially we focus on connectivity between resources and applications instead of networks. To do that we'll create an endpoint in our client VPC, and then that endpoint will be configured with listeners appropriate to our applications that we've got over on the provider side.
Now those applications are going to appear native to that local VPC. So for example, when my client here does a DNS lookup, they're going to get an IP address for that endpoint local to that VPC. There are two services we'll talk about that can provide this kind of connectivity: AWS PrivateLink and Amazon VPC Lattice. Regardless of which one of these we use, this will allow us to use identity-based access controls alongside network controls like things like route tables and network ACLs. This brings us into a position where we can start to talk about zero trust as well.
Essentially, it's the idea where we use identity-based controls alongside network controls to improve our security posture. I mentioned there are two services, so let's start with AWS PrivateLink. With PrivateLink, we can access AWS services, as Rohit mentioned earlier, but we can also access custom-defined services, whether that's for our own internal consumption or perhaps we're sharing those out with a third party.
To do that, we'll need a network load balancer to start, and then we'll define target groups based on the different types you see here. These can support different listener types from TCP or UDP, with a callout that if you're going to do UDP, it does need to have an IPv6 target. Then we'll use a VPC interface endpoint to access that service from the client side. These clients can be IPv4, they can be IPv6, or they can be dual stack as well. That allows us to not only communicate across different types but also have those endpoints be in different IPv4 and IPv6 configurations as well.
From a consideration here, you'll notice that I've deliberately highlighted these overlapping IPv4 subnets. If you're in a situation where you have overlapping IPv4 subnets, PrivateLink allows you to still have that connectivity between them. These clients and services can be in different regions, and they can also be in different accounts. From a security perspective, the first thing you should know about PrivateLink is that this is unidirectional connectivity. Providers cannot initiate connections to client resources.
As a consumer or as a client, I can connect to those resources through PrivateLink, but the provider cannot initiate a connection back to me. They can only respond to traffic that I've started. Additionally, from the provider side, I have some additional controls. First, I can define service permissions, which are basically IAM policies saying which principals can access my service. I can also then, when someone tries to connect to my service, allow or block access to that service when they try to create that endpoint.
From a DNS perspective, PrivateLink is going to create an endpoint-specific DNS hostname for each service that we have. It'll look something like what you have on the screen, and when our client goes to resolve that, they'll get an IP address local to that VPC using that long custom DNS name. But what if you don't want to use that? Well, in that case, you could also specify a custom DNS name for your endpoint service. So in this case, I'm going to use app1.example.com. I need to validate that I actually own app1.example.com before I can use that, but once I do that validation process, I can then use it. When my clients go to look up app1.example.com, that'll now resolve to those PrivateLink IP addresses within the VPC.
All of that requires having a network load balancer, though, and you might have some resources like these that don't require a network load balancer. If that's the case, that's where you could use VPC Resources. This is slightly newer—we launched these last year at re:Invent—and these provide that same kind of secure, private, unidirectional connectivity without needing a network load balancer. Instead, we'll have a construct called a resource gateway, and with this resource gateway, we can then define what are called resource configurations for each type of resource that we want to use. The supported types are up there on the screen. We support FQDNs, IP addresses, and you can also specify resources by ARN, and we support RDS on that today.
Once I do that, I'll create a resource endpoint in my client VPC, and I will be able to access those resources that way. A couple of callouts here because this differs a little bit from PrivateLink. First, these are regional constructs. You're not going to do these across regions today. You can, however, share them across accounts using AWS Resource Access Manager to create that resource configuration and share it with other accounts. Each resource, just like with PrivateLink, is going to have its own unique endpoint with a unique DNS name, and it's going to look something like that on the screen here.
Just like with PrivateLink, if you don't want to use that, you can create a custom domain name for these resources as well. We just announced support for that fairly recently, so if I want to use resource1.example.com here, I can now use that from my client's side, and that will resolve to my endpoint. Now, one other callout here. We've got a bunch of resources. As I add additional resources or want to access additional resources, I'm going to need to create additional endpoints for each one of these because this is functionally point-to-point connectivity. That works at maybe a small scale or if I've only got a few resources I need to access, but if I want to manage this at scale or if I have a lot of resources and services I want to connect to, well, that's where Amazon VPC Lattice is going to come in.
Now with Lattice, not only can we use those same resource configurations we just looked at, but we can also create constructs called services. I'm going to take a quick moment and talk about services here. Services, you can think of these as Layer 7 constructs. They're very similar to what we talked about when Rohit covered Application Load Balancer a few minutes ago. They're Layer 7, HTTP, HTTPS, TLS. So we'll configure these services with listeners and target groups.
And then we'll take those services and we'll associate them with a construct called a service network, and that service network makes those services accessible from clients, and I'll talk about how that works in a moment. And we can also apply auth policies, and these auth policies are functionally IAM policy documents that we can apply either broadly at the service network level or at the individual service level instead. Now from a client perspective, this is going to look pretty similar to what we saw before. I've got two client VPCs here. My first option is going to be a service network association. I can only have one service network association with a given VPC, but if I've only got one service network, that's a good way to go. And this works with route tables. So just like with a gateway endpoint where it adds those routes into your route table automatically, the service network association works the same way. Otherwise you can do a service network endpoint, and this endpoint is going to again use an IPv4 or an IPv6 address right out of your VPC there. Either one of those will allow you to connect to your service network and you can apply those additional controls like security groups and network ACLs on top of that.
So between the auth policies and these additional constructs, you're again going back to that idea of zero trust where you're layering these additional ideas on top of each other. And both of these, like I said, will give you access to your service network. And finally, using those same resource configurations we looked at earlier, we can now tie all of this together into a single service network so we can access our services and our resources, and both will be accessible via that service network endpoint and that service network association. So for scale, this is going to be your better option.
DNS Management with Route 53 Resolver and Private Hosted Zones
Now I've started talking a little bit about DNS as well. And earlier Rohit had explained how the Route 53 Resolver works within a VPC. You've got that .2 address and that V6 address. Using the Route 53 Resolver is going to give us access to some additional capabilities. First one being Resolver DNS Firewall. Now with DNS Firewall, we can create either blocklists, so domains that we explicitly want to block. Or we can create allow lists where we take the opposite approach and say we only want to allow DNS resolution to these domains, taking that walled garden type of approach. So we'll define those, we'll define any actions we want to take on that. We can define if we only want these rules to apply to specific types like A records, AAAA records, and so on, and we'll associate all of these rules to our VPC. And then we can optionally use some additional controls to prevent against things like DNS tunneling and domain generation algorithms. We can then start to use Resolver query logging separately or in conjunction with this as well, and like the name implies, this is just going to log your DNS queries that go to that Route 53 Resolver in the VPC, so it'll include source, destination, any responses, but it'll also give you any information about rule actions or any effects that were taken as a result of your firewall rule groups. So you take that, apply it to your VPC. And this can be super useful not only for just understanding what DNS traffic you have, but also if you're trying to troubleshoot any kind of firewall rules that you may have created that maybe you're having some unintended consequences.
I'm going to put those aside for a moment. What if you want private DNS like you might have in your data center today? For that, we have this idea of a private hosted zone. So I'll create a zone here, in this case for app1.example.com, and I'll define records within that zone. I'll then take that zone and I can associate it with a VPC. Now as the name private hosted zone implies, this is a private hosted zone. If it is not associated with that VPC, nothing in that zone will be resolvable. So in this case, when I've got my instance, I'm going to query foo.app1.example.com because of that association, I can successfully resolve that. I can also associate multiple private hosted zones to a single VPC. I can also take those same private hosted zones and associate them with multiple VPCs, that'll give me a multi-VPC view of my DNS. Now what about our data center? We don't want our data center to feel left out of all the DNS fun, right? So for that, what we can do is we're going to take these private hosted zones, we'll associate them with our VPC, and then we're going to create what's called an inbound resolver endpoint. And that endpoint will allow us to resolve those private hosted zones from our data center. So to do that, we'll create a forwarder in our on-premises DNS server. And as long as we have some kind of private connectivity path, so like Direct Connect or Site-to-Site VPN like we talked about earlier, we'll then be able to resolve those, and we can optionally choose to encrypt that with DNS over HTTPS as well. So from a flow perspective, we've got our DNS server. It's got our forwarder. That server receives a query for foo.app1.example.com and then that will now go to our inbound resolver endpoint so we can resolve those private hosted zones.
Now what about the opposite direction? Well, we had an inbound endpoint. Now we've got an outbound endpoint. The same idea here—before we had a forwarder in our on-premises server. Now we're going to create forwarding rules instead, and these forwarding rules will point to our on-premises data center, in this case for corp.example.com. We'll take those forwarding rules, we could also choose to delegate if we want, and we'll associate them with our VPC. Once we do that, we can again optionally choose to encrypt those queries, so from a flow perspective, it'll look something like this. We'll query in this case for bar.corp.example.com. We'll see that we have that forwarding rule associated with our VPC. And then that will send it to the outbound resolver endpoint and then to our DNS server on premises for resolution.
There's a lot of associations here. There's a lot of constructs here. There's a lot of resources. How do we manage all of this at scale, especially if you're operating in a large environment where you've got a lot of VPCs? So for that you can take all of these and put them into what's called a Route 53 Profile. We actually just added support for resolver query logging like you can see there. Once you do that, instead of having to manage each of these separately, you can take this one profile and associate it with many VPCs either within your same account or across multiple accounts using AWS Resource Access Manager, giving you that complete multi-account view of your DNS.
Traffic Inspection Architectures: AWS Network Firewall and Gateway Load Balancer
We talked about DNS Firewall and earlier Rohit was talking about some of the basic security concepts, but when we think about our environment too, we'll probably want to think about adding a firewall in somewhere. So there's a couple of different places we might do that. We might want to add a firewall to inspect traffic between VPCs, maybe between subnets. Maybe on premises in or out to or from our data center or out to the internet.
Now with the internet, let's use that as an example. It would probably look something like this. I've got a workload in a private subnet. I've got a NAT gateway in a public subnet and ideally I want to place my firewall right in the middle there in some kind of an inspection subnet. Now there are two approaches we can take, depending upon what we want to use to actually do that traffic inspection. So to get things started, if you're using third-party firewall appliances, you could use AWS Gateway Load Balancer. Rohit had talked about two types of load balancers earlier. This is a third one, but this is specifically designed for third-party appliances to provide native load balancing.
How it works—we've got our load balancer. We'll take our firewalls and we'll create them and define them as targets for this gateway load balancer. And then we'll use an endpoint powered by AWS PrivateLink, a gateway load balancer endpoint, and this will give us a bump in the wire traffic inspection. It's transparent to the source. It's transparent to the target. We're using route tables to steer traffic to that endpoint to the gateway load balancer. Load balancers will do what load balancers do best. They'll send it to the targets. If that's allowed, the traffic will return to the gateway load balancer back to the endpoint, and then route out to the internet.
Now the consideration here is that even though we are using native load balancing capabilities, we still have to manage these firewall appliances themselves. If we don't want to do that, instead we could use AWS Network Firewall, and with Network Firewall this is a fully managed native firewall service that gives us the same basic capabilities where we can allow and block traffic, we could do logging, things like that, but it gives us all these additional capabilities as well, including some recently launched features like managed rules from AWS partners and a managed proxy which is currently in preview.
Architecturally this is going to look exactly the same way. Instead of a gateway load balancer endpoint, we have a firewall endpoint. We'll route our traffic to the firewall endpoint which will pass it to our firewall service. That traffic is allowed through, it will return to that endpoint and then go out to the internet. Now the key takeaway here, regardless of which one you use, is that both Gateway Load Balancer and the appliances and AWS Network Firewall will support the same inspection architectures.
What do I mean by inspection architectures here? Well, here's an example using that one we were looking at. That's an example of a distributed model where we have an endpoint in the VPC that's doing the actual inspection right there. And we could do that for on-premises in or out if we're connecting directly to a VPC, and we could also use that for traffic between subnets. But we didn't really talk about how to do traffic inspection between VPCs yet, so for that we're going to need a different type of model, and this is going to be a centralized inspection model, and this is going to use either AWS Transit Gateway or AWS Cloud WAN. And once we start to think about centralizing our inspection, well, we can centralize our on-premises inspection, as well as centralizing our internet ingress or our internet egress as well.
Let me show you what I mean. Taking AWS Transit Gateway as an example, I have some VPCs connected to my transit gateway. I can choose one of two approaches with Transit Gateway. Either I can create a dedicated inspection VPC that has the firewall endpoint in it, and if I do that, I want to configure appliance mode to make sure my traffic is symmetrical. Or with Transit Gateway, you have the ability to create an AWS Network Firewall native attachment, and that will basically remove the need for you to create that inspection VPC. I'm going to use the network firewall attachment for this, but you can do the same thing here. With the inspection VPC functionally from the VPC's perspective, you route traffic to the transit gateway. The transit gateway passes it to the network firewall attachment. The network firewall attachment returns it to the transit gateway if it has been inspected and allowed through, and then routed back to the destination VPC.
For on-premises, assuming we have some kind of private connectivity here, the flow is going to look very similar. Instead of sending it back to a destination VPC, we're going to send it to our on-premises data center. From the VPC's perspective, it still has that route to the transit gateway, and the transit gateway handles that routing for us. Now Internet egress is a little bit different. This is my personal opinion here. You could go through the network firewall attachment and then go through a centralized egress VPC. I think it's a little easier to do this. So we'll take our inspection VPC and we'll add in that gateway and we'll add an internet gateway so we have a path out to the internet.
Once we do that, our VPCs can send traffic to the transit gateway like they did before, but instead of having to go through the transit gateway twice, we inspect and we egress in the same VPC. Now that was with Transit Gateway. AWS Cloud WAN is pretty much the same thing. So with AWS Cloud WAN, earlier we talked about how you can have different segments. We'll attach our VPCs and our connectivity to our segments. And then we'll create what's called a Network Function Group, and this is a special kind of segment specifically designed to manage the routing for these firewall appliances for us. And we'll attach that inspection VPC to the Cloud WAN network function group. We don't have the native attachment available today. But from a flow perspective, it's going to look largely the same.
So again, we send our traffic in this case to our Cloud WAN core network. That core network routes it to the inspection VPC, gets inspected by that endpoint, returns back to the core network, and then routes it to the destination VPC. For on-premises, the same thing applies. We're going to go through our core network, the inspection endpoint takes care of the inspection for us, and then routes it back to our on-premises data center. Then finally for Internet egress, the same concept applies. We're going to use that same inspection VPC where we're inspecting and we're egressing all in the same VPC.
Remote Access Solutions: AWS Client VPN and AWS Verified Access
So the takeaway here is whether you are using AWS Cloud WAN or Transit Gateway, whether you use third-party appliances, whether you use AWS Network Firewall, these concepts will apply the same, giving you that flexibility that you want for this kind of inspection. Let's take a quick moment to detour and talk about remote access. Earlier we talked about this idea of accessing networks versus applications and resources, and the same concept applies here when we talk about remote access. So for network access, you could use AWS Client VPN. This is a fully managed remote VPN solution. It automatically scales up or down based on how much you use it and how many users are connecting.
And how this works, you can define multiple authentication options including certificate-based authentication, and then once you do that, you can create authorization rules. These rules will allow you access to specific networks based on the authentication information that the VPN receives. You'll notice here in this case I'm connecting. The engineering group can connect to this particular CIDR block. Once I do that, I can configure other things like connection logging and client route enforcement to prevent route leaks. And then from the target side, a couple of things here. First, my clients can be IPv4, IPv6, or dual stack, and my targets can be IPv4, IPv6, or dual stack. And in addition to accessing resources in that one VPC, I can also connect to resources in that same VPC or outside of that VPC again as long as I have some kind of a routable path to those.
Now, what if I don't want access to networks, but I want that different approach, a more application networking-based approach? Well, for that I could use AWS Verified Access. With AWS Verified Access, similar to what we saw with Amazon VPC Lattice, we're providing access to applications and resources without requiring a full VPN connection, and we can add additional group and app level policies on top of that as well. This will support HTTP and HTTPS applications and TCP resources, very similar to what we saw with Lattice earlier. Now for the first one, HTTP and HTTPS applications, we will configure AWS Verified Access with trust providers, and these trust providers will include not only identity information, but we can also use device information. So is my laptop up to date? Do I have all of the
right security patches, things like that? Do I have any software that shouldn't be on there? I can configure all of that, and then based on that information from those trust providers, I can now craft policies, and I can do these policies per group, or I can do them per application or per endpoint. Configure access logging and because these are layer 7 constructs I can also choose to optionally integrate AWS WAF as well. From a target perspective, I can connect to elastic network interfaces attached to an EC2 instance or load balancers, and these do need to be private load balancers. And then once I do that, I can define those per app policies as well. So remember, thinking back to what we saw with Lattice, the same concepts apply here, broad at the group level and more granular at the individual application level. And that will allow me to provide that connectivity, and those policies will then be used by Verified Access to provide that continuous authentication in real time.
TCP resources are going to be pretty much the same thing. Only in this case, instead of using HTTP HTTPS we're connecting to resources via TCP, SSH, RDP, things like that. My targets will be the same, I can apply resource policies on those as well, but I've got now the ability to connect to two additional resource types. One is going to be an RDS database, which I can connect to directly, or a network CIDR, and a network CIDR is going to be super useful if I have autoscaling resources that are very ephemeral. They scale up, they scale down. I don't want to have to manage connectivity to all of those. Verified Access will make it so I don't have to manage that. I can just connect into each one of those as they appear and disappear. It'll take care of that for me automatically.
Network Monitoring and Observability: Flow Logs, CloudWatch Tools, and Troubleshooting
Ultimately I can use the same construct to access both of these, whether it's HTTP HTTPS or TCP resources. Now we've covered quite a bit here. How do we have an understanding of this? How do we reason about all of these network constructs? Well, the first is, and Rohit had mentioned this earlier, so I wanted to make sure we came back to it first, is flow logs. Now flow logs you can apply them at a VPC, at a subnet within a VPC, or at a network interface, as well as on a transit gateway, and this will give you flow level visibility, essentially metadata about your flows. This is not a packet capture. This is metadata about those specific flows, so it includes things like source and destination, port, protocol, bits, and then any actions taken as a result of network ACLs and security groups. And then all of that will get emitted into our logging destinations, Amazon CloudWatch Logs, S3 or Data Firehose.
We've also, sticking with Transit Gateway, we can register our transit gateways in Network Manager or if we're using AWS Cloud WAN, we can use Network Manager to get some additional metrics and events from these two services, and this will include things like topology changes, so as we add or remove attachments, routing updates as routes are added or removed, and for SD-WAN and VPN, any status updates, so if they go up or down, all of those will get emitted into the same logging destinations as flow logs. Network Manager also is going to give us visibility into infrastructure performance, and these are metrics that we at AWS publish that give you insight into network latency and performance between regions, between availability zones within a region or within an availability zone, so think back to that graphic we saw earlier where an availability zone consists of multiple data centers. This gives you that visibility. Now these metrics will be available on the console, but you can also publish them to a CloudWatch subscription and then action off of those accordingly.
Now speaking of CloudWatch, CloudWatch has a number of tools that we can use here. So for starters, let's say I've got some public internet resources, a CloudFront distribution, Workspaces, a public facing VPC. I've got users who are accessing that. I want to understand what's impacting their connectivity to those resources. For that, I could use Amazon CloudWatch Internet Monitor, and this is going to give me internet performance and availability metrics by ISP and location. So functionally, it'll give me something like this, a map of the internet weather that would be affecting connectivity to my applications.
Now that's for the internet. What about hybrid connectivity to my data center? So for that, we can use Network Synthetic Monitor. And this will give us metrics like round trip time and packet loss for either site-to-site VPN or Direct Connect. So in this example here, I'm using Direct Connect. I'll set up probes in these VPCs in the source subnet, and as part of that configuration, I'll specify the type of probe that I want. I can do TCP or ICMP, and I can also specify the port and packet size for TCP. And then I can specify an IPv4 or an IPv6 destination on premises, and this will give me that round trip time and packet loss. And for Direct Connect, this will also include a network health indicator metric, which is a probabilistic value that gives you insight into whether network degradation is occurring within AWS or external to AWS.
Sticking with CloudWatch, we also have VPC Flow Logs Network Monitor, which is designed for traffic within AWS and provides performance and availability metrics about specific network flows. By installing agents on EC2 instances or applying them to your EKS clusters, you can specify local or remote resources, which could be any of the resources shown here: a region, a VPC, an availability zone, a subnet within a VPC, a remote region, or AWS services like DynamoDB and Amazon S3. This gives you TCP metrics, a network health indicator just like we had with Direct Connect, as well as bytes transferred so you can see what that flow looks like.
Now, what about troubleshooting? We have many components in our infrastructure. If we take this example where we have a load balancer targeting an elastic network interface on a VPC, there are many things that could go wrong in the path, including route tables, security groups, and network ACLs. If we want to troubleshoot this, we can use a tool called VPC Reachability Analyzer, which gives you hop-by-hop visibility of the path between a source and a destination that you specify. Crucially, it also tells you if anything in the path is blocking connectivity from that source to the destination. In this case, it's a security group on the Application Load Balancer that is not allowing that traffic through. In addition to load balancers, VPC Reachability Analyzer supports all of these intermediary components like network firewall, transit gateways, and peering connections, making it the best tool in your toolkit for fine-grained troubleshooting when you have a specific case to solve.
Stepping back a bit more, if you want to understand whether there are any unintended paths to access your network, you can use Network Access Analyzer, which allows you to define what are called network access scopes. Examples include situations where you have turned on VPC Block Public Access and want to understand the impact, or where you want your instances to only be reachable via a load balancer but not publicly facing in any other way. You define this intent, and Network Access Analyzer takes that intent and uses automated reasoning to determine whether there are any unintended or non-compliant paths that do not align with that access scope. This tool is best for broad evaluation within an account or within a region.
We are just about at time, and we have covered a lot in the last hour. We could easily have spent a whole hour on each one of these topics. Fortunately, there are many sessions running this week. If you are catching this later or somewhere else, you might be able to catch some of these on YouTube as well. Please take a moment and grab a photo of this. These sessions are ones that Rohit and I picked out specifically because they dive deeper into additional networking topics that we have started and covered here today. You can find all of the information about these sessions, including where they are and their times, in the session catalog. I will leave this up for just another moment to give everyone a chance to grab a photo. With that, I want to say thank you all so much for joining us. Thank you for starting your re:Invent week with us. I hope you have a wonderful rest of the week, and if you have any questions, we will be around. Thank you so much.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)