🧭 Visual Summary Table Networking Scope

Service	Traffic Type	Scope	Direction / Flow
VPC Endpoints	AWS Service Access	Internal VPC	Your VPC → AWS Service (privately)
VPC Endpoint Services	PrivateLink Service Sharing	Cross-VPC	External VPC → Your VPC (privately)
VPC Service Networks	Microservices Management	Cross-VPC / Multi-account	Logical grouping of services
VPC Lattice Services	App-level Service Mesh	Cross-VPC / Multi-account	VPC-A ↔ VPC-B services (via Lattice)
VPC Target Groups	Load Balancing Targets	Internal VPC	Load Balancer → EC2/Containers/Lambda
Resource Configurations	Shareable Resource Metadata	Your VPC	Defines what can be accessed
Resource Gateways	Access Point to Resources	Cross-VPC	External VPCs → Resource in your VPC

1. Introduction: Navigating the AWS Cloud Network

The Amazon Web Services (AWS) cloud offers a vast array of resources and services, and at the heart of any effective cloud deployment lies robust networking. Networking in AWS is the fundamental framework that allows your various resources and applications to communicate with each other, with users, and with the outside world. However, the intricacies of cloud networking can often present a challenge, with a multitude of concepts and services that might seem complex at first glance. Understanding these concepts is crucial for building scalable, secure, and efficient cloud solutions. This report aims to simplify some of the key AWS networking concepts related to Virtual Private Clouds (VPCs), providing clear and accessible explanations of AWS VPC Endpoints, VPC Endpoint Services, VPC Service Networks, VPC Lattice Services, VPC Resource Configurations, VPC Resource Gateways, and VPC Target Groups. By demystifying these terms, this guide intends to provide a solid foundation for anyone seeking to navigate the AWS cloud network with greater clarity.

2. Deconstructing AWS VPC Endpoints: Your Private Gateway to AWS Services

At its core, an AWS VPC Endpoint provides a private connection between your Virtual Private Cloud (VPC) and supported AWS services. This private connection ensures that the traffic between your VPC and the AWS service remains entirely within the AWS network, avoiding the need to traverse the public internet. This offers significant advantages in terms of security, as it reduces the attack surface by keeping your data within the confines of the AWS infrastructure. Imagine your VPC as your private office building, and various AWS services as essential suppliers. A VPC Endpoint acts as a dedicated, private road directly connecting your office to a specific supplier’s warehouse, bypassing the potentially insecure public highway of the internet.

There are two primary types of VPC Endpoints, each designed for different use cases and offering distinct functionalities.

• Gateway Endpoints: These endpoints serve as specialized exits on your VPC’s network, specifically designed for accessing Amazon Simple Storage Service (S3) and Amazon DynamoDB. They function by adding a route to your VPC’s route table. This route directs any traffic destined for the IP address prefixes associated with S3 or DynamoDB through the Gateway Endpoint.¹ The analysis indicates that Gateway Endpoints are tailored for high-volume data storage and retrieval services, which are often fundamental to cloud applications. This specialization likely stems from their integration at the routing layer of the VPC. Furthermore, Gateway Endpoints do not utilize AWS PrivateLink technology. This suggests that they might rely on an older or fundamentally different method for establishing the private connection compared to Interface Endpoints.
• Interface Endpoints: These endpoints offer a more versatile solution, leveraging AWS PrivateLink to provide private connectivity to a broader range of AWS services. This includes services such as Amazon CloudWatch, the Amazon Elastic Compute Cloud (EC2) API, Amazon Simple Queue Service (SQS), and many others. Think of Interface Endpoints as establishing a private network cable directly from your server room within the VPC to various other AWS service hubs. When you create an Interface Endpoint, AWS provisions an Elastic Network Interface (ENI) within a subnet of your VPC.¹ This ENI is assigned a private IP address from your subnet’s IP address range and acts as the entry point for traffic destined for the supported AWS service.¹ The extensive support for a wide array of AWS services through Interface Endpoints underscores the growing need for private connectivity to various components of the AWS ecosystem, extending beyond just storage and databases. Unlike Gateway Endpoints, Interface Endpoints do incur a cost based on their usage.² This suggests a trade-off where the increased flexibility and broader service support come with associated operational expenses.¹

VPC Endpoints operate as virtual devices that are inherently highly available and scalable within the AWS infrastructure.³ When your resources within the VPC attempt to communicate with a supported AWS service, the traffic is intelligently routed to the private IP address of the VPC Endpoint within your network.⁴ This ensures that the communication path remains within the AWS network. For Interface Endpoints, the standard DNS resolution process within your VPC is enhanced. When your instances resolve the public endpoint of an AWS service, the AWS DNS resolver will return the private IP address of the Interface Endpoint, allowing seamless private communication without requiring changes to your application’s service access patterns.⁴

Utilizing VPC Endpoints offers several key benefits for your AWS environment ¹:

• Enhanced Security: By ensuring that traffic to supported AWS services remains within the AWS network, VPC Endpoints significantly reduce the exposure of your data to the public internet, thereby bolstering your overall security posture.²
• Improved Performance: The private connections established by VPC Endpoints can often provide lower latency and higher bandwidth compared to routing traffic over the public internet, leading to improved application performance and faster data transfers.²
• Simplified Network Architecture: VPC Endpoints can simplify your network design by reducing or eliminating the need for traditional internet access mechanisms like Internet Gateways, NAT devices, or VPN connections when communicating with supported AWS services.²
• Cost Optimization: For Gateway Endpoints, access to S3 and DynamoDB is free of charge. While Interface Endpoints do have associated costs, they can potentially eliminate data transfer charges related to public internet traffic, especially for high-volume data exchanges.²

In conclusion, AWS VPC Endpoints are a fundamental tool for establishing secure and efficient communication between your VPC-based resources and a wide range of AWS services, ensuring that your critical data remains within the private AWS network.

3. Unpacking AWS VPC Endpoint Services: Offering Your Own Private AWS Services

AWS VPC Endpoint Services provide a mechanism for you to host your own services privately within your Virtual Private Cloud (VPC) and grant secure access to these services to other AWS accounts and VPCs.⁶ This is achieved without exposing your services to the public internet, offering a secure and controlled way to share resources. Imagine you’ve developed a specialized application within your organization’s AWS environment. VPC Endpoint Services allow you to offer this application privately to other business units or partner organizations (represented by different AWS accounts or VPCs) through a secure, internal connection, much like offering a service within a private business park.

The process of offering private services through VPC Endpoint Services involves several key steps ⁷:

• As the service provider, you first create a VPC Endpoint Service within your AWS account.⁷ This service needs to be associated with one or more Network Load Balancers (NLBs).⁷ The NLBs are crucial as they distribute the incoming traffic from the service consumers to the backend instances or services that constitute your private offering.⁸ The reliance on Network Load Balancers suggests that services intended for private consumption through this mechanism should be designed to handle network traffic efficiently and at scale.⁸
• Next, you need to explicitly grant permissions to specific AWS principals (which can be AWS accounts, IAM roles, or IAM users) that you want to authorize to connect to your service.⁸ This granular permission control is managed through the “Allow principals” settings of your Endpoint Service.⁸ You can add or remove permissions as needed, providing flexibility in managing access to your private service.⁸
• On the consumer side (the AWS users who want to access your service), they create an Interface VPC Endpoint within their own VPC.⁷ During the creation of this endpoint, they will specify the name of your VPC Endpoint Service.⁷ This action initiates a connection request to your service.
• As the service provider, you have control over whether to accept or reject these connection requests.⁸ You can configure your Endpoint Service to automatically accept all connection requests from authorized principals, or you can opt for a manual approval process, providing a higher degree of control over who can access your service.⁸

VPC Endpoint Services offer several compelling features ⁶:

• Private Connectivity: Access to your services is exclusively through private IP addresses, ensuring that the traffic does not traverse the public internet.⁶
• Granular Permissions: You leverage the robust AWS Identity and Access Management (IAM) system to precisely control who can access your service.⁸
• Scalability and High Availability: By associating your Endpoint Service with Network Load Balancers, you benefit from the inherent scalability and high availability that NLBs provide.⁸
• Optional Private DNS: You have the option to associate a private DNS name with your Endpoint Service.⁸ This allows service consumers to access your service using a familiar and user-friendly DNS name, improving usability.⁸ However, you need to verify ownership of this domain.⁸

The ability to offer services privately through VPC Endpoint Services creates a secure and controlled environment for building and providing Software-as-a-Service (SaaS) solutions or shared services within the AWS ecosystem.⁶ It allows different parts of an organization or external partners to collaborate and consume services without the security risks associated with public internet exposure.⁶

4. Simplifying AWS VPC Service Networks: Connecting Services Across Your AWS Landscape

AWS VPC Service Networks (VSNs), often referred to in the context of VPC Lattice, provide a unified and logical boundary for a collection of services and resource configurations.¹⁰ These networks simplify the way services discover and securely connect with each other, regardless of whether they reside in different Virtual Private Clouds (VPCs) or even different AWS accounts.¹⁰ Envision a VSN as a private, organization-wide network, akin to a company intranet, that enables various departments (representing services in different VPCs) to communicate seamlessly and securely, irrespective of their specific office location or even if they belong to different branches.

The operation of a VPC Service Network involves a few key steps ¹⁰:

• First, you establish a Service Network, which serves as a central, managed hub for your services.¹¹
• Next, you associate your individual services, which might be running in diverse VPCs or accounts, with this central Service Network.¹⁰ You can also associate VPC Resource Configurations, representing TCP-based resources, with the Service Network.¹²
• For client applications (services or users needing to consume the services within the network) to access the Service Network, the VPCs containing these clients must also be connected to the Service Network. This connection can be achieved either through a direct association of the VPC with the Service Network or by utilizing VPC Endpoints of the type “Service Network”.¹⁰ A crucial point to note is that a VPC can have only one direct association with a single Service Network.¹⁰ For connecting a VPC to multiple Service Networks, VPC Endpoints are the appropriate mechanism.¹⁰
• The underlying network connectivity, the process of services discovering each other through DNS, and the enforcement of access and observability policies are all handled by VPC Lattice, the fully managed application networking service that powers VPC Service Networks.¹¹

VPC Service Networks offer several significant benefits for managing complex cloud environments:

• Simplified Connectivity: They automate the often intricate process of service discovery and connectivity across a multitude of VPCs and AWS accounts, reducing the manual configuration required.
• Centralized Policy Management: They allow you to define and apply access control and monitoring policies at the Service Network level, providing a consistent and efficient way to manage security and observability across your interconnected services.¹⁰
• Inter-Application Connectivity: They facilitate seamless communication between applications using common protocols such as HTTP, HTTPS, and gRPC within a VPC.
• Handling Overlapping IP Addresses: A key advantage is their ability to abstract away the complexities that arise from managing IP addresses across different networks, particularly when dealing with overlapping IP address ranges in different VPCs or accounts.

The architecture of VPC Service Networks directly addresses the challenges inherent in modern, distributed microservices architectures, where numerous independent services might be deployed across various VPCs. By providing a centralized and managed networking layer, VSNs simplify the operational overhead and enhance the security posture of such complex environments. The primary support for protocols like HTTP, HTTPS, and gRPC indicates that VPC Service Networks are particularly well-suited for modern, API-driven applications that rely on these protocols for inter-service communication.

5. Understanding AWS VPC Lattice Services: Application Networking Made Easy

Within the framework of AWS VPC Lattice and its Service Networks, individual applications or microservices are represented as VPC Lattice Services. If you consider the VPC Lattice Service Network as the overarching company intranet, then each VPC Lattice Service is akin to a specific application or function accessible on that intranet, such as an internal messaging system or a project management tool.

Each VPC Lattice Service is composed of several key components that define its behavior and how it interacts with the network:

• Listeners: These are processes that are configured to listen for incoming connection requests on a specific protocol (such as HTTP, HTTPS, or TLS) and a designated port number. The supported protocols include common web protocols like HTTP/1.1, HTTP/2, and secure HTTPS, as well as gRPC, a high-performance, open-source universal RPC framework. It’s important to note that VPC Lattice does not currently offer native support for WebSockets.
• Rules: Once a listener detects a connection request, rules come into play to determine how that request should be routed to the backend resources. These rules can be based on various criteria, including the path in the URL, the HTTP method used (like GET or POST), or even specific headers present in the request.
• Target Groups: These are collections of compute resources, known as targets, that are actually running your application or service. VPC Lattice offers flexibility by supporting a wide range of target types, including Amazon EC2 instances, individual IP addresses (specifically private IPs from within the VPC subnet or from defined RFC ranges), AWS Lambda functions (with a limitation of one function per target group), Application Load Balancers (specifically single, internal ALBs), Amazon ECS tasks (when using the IP target type), and even Kubernetes Pods (when integrated with the AWS Gateway API Controller). It is worth noting that Network Load Balancers (NLBs) are not supported as direct targets for VPC Lattice Services.

VPC Lattice Services provide several core functionalities:

• Each service is automatically assigned a DNS name, which facilitates service discovery within the network. Additionally, service owners have the option to configure their own custom domain names for their services.¹³
• VPC Lattice supports advanced traffic management capabilities, including request-level routing based on the rules you define and the ability to implement weighted targets. Weighted targets are particularly useful for deployment strategies like blue/green deployments (where you gradually shift traffic from an old version to a new one) and canary deployments (where you release a new version to a small subset of users before a full rollout).
• Security is a paramount concern, and VPC Lattice allows you to apply security policies, specifically Auth Policies based on AWS Identity and Access Management (IAM), directly at the individual service level. This enables fine-grained control over who can access and interact with each specific service within your network.

The architecture of VPC Lattice Services, with its listeners, rules, and target groups, bears a strong resemblance to the familiar structure of AWS Application Load Balancers (ALBs).¹⁴ This similarity likely aims to make the adoption of VPC Lattice easier for users who are already acquainted with the concepts and configurations of ALBs.¹⁴ Furthermore, the broad support for a diverse set of target types underscores the flexibility of VPC Lattice in accommodating various compute platforms, allowing organizations with heterogeneous infrastructure to integrate their services into a unified application network.¹⁴

6. Explaining AWS VPC Resource Configurations: Representing Your TCP-Based Resources in VPC Lattice

AWS VPC Resource Configurations offer a way to represent TCP-based resources, such as relational databases, domain names, or specific IP addresses, that reside within your Virtual Private Cloud (VPC).¹⁵ These configurations allow you to make these resources accessible to clients located in other VPCs and AWS accounts in a secure and private manner.¹⁵ Imagine you have a critical database server housed within your organization’s AWS environment. A VPC Resource Configuration allows you to define this database and the specific rules for accessing it, enabling a partner company to gain limited, secure access without needing to know the intricate details of your entire network.

There are several types of VPC Resource Configurations to suit different needs ¹⁵:

• Single Resource Configuration: This type represents a single resource, which can be either an individual IP address or a specific domain name. It can be shared independently.¹⁵
• Group Resource Configuration: This acts as a container for a collection of child resource configurations. It’s useful for representing a group of related DNS or IP address endpoints, and the entire group can be shared independently.¹⁵
• Child Resource Configuration: This is a member of a Group Resource Configuration and also represents either an IP address or a domain name. It cannot be shared on its own; it can only be accessed as part of the group it belongs to.¹⁵
• ARN Resource Configuration: This type represents a supported AWS resource that is provisioned by another AWS service, identified by its Amazon Resource Name (ARN). Currently, the primary supported resource of this type is Amazon RDS databases. AWS automatically manages any underlying child resources associated with the ARN.¹⁵ It’s important to note that you cannot create a resource configuration for an RDS database that is publicly accessible.¹⁵

Each VPC Resource Configuration must be associated with a VPC Resource Gateway.¹⁵ The Resource Gateway serves as the point of entry for all traffic destined for the resource configuration and acts as the ingress point into the VPC where the resource is located.¹⁵

Currently, VPC Resource Configurations support only the TCP protocol.¹⁵ When defining a resource configuration, you can also specify the particular port ranges on which the resource will accept incoming requests.¹⁵ This allows for fine-grained control over the network traffic to your resources.

Clients can access VPC Resource Configurations in two primary ways ¹⁵:

• They can establish a direct connection by creating an AWS PrivateLink VPC Endpoint of type “resource” within their own VPC. This creates a private and secure connection directly to your configured resource.¹⁵
• Alternatively, your Resource Configuration can be associated with a VPC Lattice Service Network. Clients can then connect their VPC to this Service Network, either through a direct VPC association or by using a VPC Endpoint of type “Service Network,” and subsequently access the resource.¹⁵

When you share a Resource Configuration with another AWS account using AWS Resource Access Manager (RAM), you have the ability to control whether that receiving account can further add your resource configuration to service networks that they might share with other accounts.¹⁶ This feature helps prevent unintended transitive sharing of your valuable resources.¹⁶

The introduction of VPC Resource Configurations signifies an expansion of VPC Lattice’s capabilities beyond the initial focus on HTTP/HTTPS and gRPC traffic. By enabling the representation and sharing of TCP-based resources, VPC Lattice can now support a broader spectrum of application dependencies, including critical components like databases. The concept of the Resource Gateway underscores the security-conscious design of resource sharing within VPC Lattice, providing a controlled and monitored ingress point into the VPC that owns the resource.¹⁵

7. Demystifying AWS VPC Resource Gateways: The Entry Point for Your Shared Resources

AWS VPC Resource Gateways serve as the crucial entry point for network traffic into the Virtual Private Cloud (VPC) that hosts the resources you intend to share with other AWS accounts or VPCs via VPC Lattice.¹⁷ Think of a Resource Gateway as the dedicated reception area in your office building that specifically handles all visitors who have been granted access to certain departments or services within.

Resource Gateways offer the following key functionalities ¹⁷:

• They are designed to span across multiple Availability Zones (AZs) within an AWS region, ensuring high availability and resilience.¹⁷
• Every resource that you intend to share using VPC Lattice must be associated with a Resource Gateway.¹⁶ A single Resource Gateway can be associated with multiple VPC Resource Configurations, and each of those configurations can represent one or more actual resources.¹⁷
• When a client from another VPC or AWS account successfully accesses a resource within your VPC, the resource itself perceives the incoming traffic as originating locally from the IP address of the Resource Gateway within its own VPC.¹⁷ The actual source IP address of the client is effectively masked by the gateway’s IP address.¹⁷

To enhance the security of your shared resources, you can attach up to five security groups to a VPC Resource Gateway.¹⁷ The rules defined within these security groups govern the outbound traffic originating from the Resource Gateway and destined for the actual resources within your VPC.¹⁷ For instance, if you are sharing a database, you would configure the security group associated with the Resource Gateway to allow outbound TCP traffic on the specific port used by your database (e.g., port 3306 for MySQL) to the IP address range of your database instances.¹⁷

VPC Resource Gateways support different types of IP addresses to accommodate various networking scenarios ¹⁷:

• IPv4: You can assign IPv4 addresses to the gateway’s network interfaces if all the subnets selected for the gateway have IPv4 address ranges, and the resource you are sharing also has an IPv4 address.¹⁷
• IPv6: Similarly, you can assign IPv6 addresses if all the selected subnets are IPv6-only, and the resource also has an IPv6 address.¹⁷
• Dual-stack: If your selected subnets have both IPv4 and IPv6 address ranges, and your resource has either type of address, you can configure the gateway to use both IPv4 and IPv6 addresses.¹⁷

There are a few important considerations when working with VPC Resource Gateways ¹⁷:

• To ensure that your resources are accessible from all Availability Zones where your clients might be located, it is recommended to create Resource Gateways that span across as many AZs as possible.¹⁷
• For a successful connection, at least one Availability Zone of the client’s VPC Endpoint and the Resource Gateway must have an overlap.¹⁷
• A single VPC is limited to a maximum of 100 Resource Gateways.¹⁷
• Resource Gateways cannot be created within subnets that are shared with other AWS accounts.¹⁷

The requirement for a Resource Gateway in the resource-owning VPC underscores the unidirectional nature of resource sharing facilitated by VPC Lattice.¹⁵ The resource owner maintains control over the entry point for any external access to their resources.¹⁵ Furthermore, the capability to associate security groups with Resource Gateways provides a crucial additional layer of security for the shared resources, enabling granular control over the network traffic allowed to reach them.¹⁷

8. Clarifying AWS VPC Target Groups: Grouping Resources for Efficient Traffic Management

AWS VPC Target Groups serve as logical groupings of compute resources, known as targets, that are intended to receive network traffic from a VPC Lattice Service.¹⁹ Think of these target groups as the various teams or departments within a company that are responsible for handling specific types of requests routed by the main switchboard, which in this analogy is the VPC Lattice Service.

VPC Target Groups support a diverse range of target types:

• Amazon EC2 instances
• Individual IP addresses (specifically private IP addresses from within the VPC subnet or from defined RFC 1918 and RFC 6598 ranges)
• AWS Lambda functions (with a limitation of one function registered per target group)
• Application Load Balancers (specifically a single, internal ALB can be registered as a target)
• Amazon ECS tasks (when the target group’s target type is set to IP)
• Kubernetes Pods (when integrated with the AWS Gateway API Controller)

It is important to note that Network Load Balancers (NLBs) are not supported as direct target types for VPC Lattice Target Groups.

The primary function of VPC Target Groups is to provide a destination for traffic that is routed by the rules defined within a VPC Lattice Service’s listener.²⁰ When you create a rule for a listener, you specify a particular target group, and when the conditions of that rule are met, the incoming traffic is forwarded to the resources registered within that target group.²⁰ You can even specify the same target group in multiple listeners that belong to the same VPC Lattice Service.²¹

To ensure that traffic is only directed to healthy and responsive resources, VPC Lattice supports health checks for targets within a target group (health checks are not available for Lambda functions).²⁰ VPC Lattice continuously monitors the health status of all registered targets within a target group. If a target is deemed unhealthy, VPC Lattice will cease sending traffic to it until it recovers.²⁰

By default, VPC Lattice employs a round robin routing algorithm to distribute incoming requests evenly across all the healthy targets within a target group.²⁰ This ensures that no single resource becomes overwhelmed with traffic. Routing decisions are made independently for each target group, even if a particular resource happens to be registered with multiple target groups.²⁰

VPC Target Groups share conceptual similarities with the target groups used in traditional Elastic Load Balancers (both ALBs and NLBs).¹⁹ This consistency provides a familiar way for users to manage the backend resources that power their applications, whether those applications are accessed through traditional load balancers or through the newer VPC Lattice infrastructure.¹⁹ However, it is crucial to understand that VPC Lattice Target Groups and ELB Target Groups are not interchangeable.²

When creating a target group with the target type set to IP, you have the option to specify whether the target group will use IPv4 or IPv6 addresses for communicating with the registered targets.²⁰ The IP addresses you register must correspond to the chosen IP address type and must fall within the allowed IP address ranges.

In situations where all the targets within a target group become unhealthy, VPC Lattice exhibits a “fail-open” behavior by default. This means that even if no targets are passing their health checks, VPC Lattice will continue to route requests to all targets within the group, regardless of their health status.

The concept of Target Groups provides a valuable layer of abstraction in managing backend resources.²² Services can be configured to route traffic to a logical group of resources without needing to be aware of the specific IP addresses or individual instances that make up that group.²² This abstraction simplifies the configuration of services and also facilitates the dynamic scaling of backend resources as needed.²²

9. Conclusion: Embracing Simplified Networking in AWS

AWS provides a comprehensive suite of networking services to facilitate connectivity, security, and management of cloud applications. VPC Endpoints offer secure, private connections to AWS services, enhancing both security and performance. VPC Endpoint Services enable the private offering of your own services to other AWS accounts, fostering secure collaboration. VPC Service Networks, powered by VPC Lattice, simplify the complexities of connecting services across multiple VPCs and accounts, particularly beneficial for microservices architectures. VPC Lattice Services represent the individual applications within this network, offering granular control over routing and security. VPC Resource Configurations and Resource Gateways extend these capabilities to TCP-based resources, allowing for secure and private sharing of databases and other critical components. Finally, VPC Target Groups provide a consistent mechanism for grouping backend resources, streamlining traffic distribution and health management across both VPC Lattice and traditional load balancers. By understanding and leveraging these concepts, organizations can build more secure, scalable, and efficient applications in the AWS cloud, with VPC Lattice playing a crucial role in simplifying complex networking scenarios across diverse AWS environments.