# Guidance for External Connectivity to Amazon VPC Lattice ## Overview This Guidance demonstrates how to configure a proxy in a virtual private cloud (VPC) to connect external services to your Amazon VPC Lattice service network, enabling public, hybrid, or cross-Region access. While VPC Lattice simplifies service-to-service consumption within an AWS Region, if your applications reside outside that Region, you'll need to create and manage a proxy solution. By following this Guidance to build an ingress VPC and configure appropriate DNS resolution, you can easily establish connectivity to your external resources from your VPC Lattice service network. ## How it works ### Overview This architecture diagram shows how to configure a proxy in a virtual private cloud (VPC) to connect external services to Amazon VPC Lattice. There are three ways to use Amazon VPC Lattice for public, hybrid, or cross-Region access. Each are outlined further are in the corresponding tabs. [Download the architecture diagram](https://d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/solutions/approved/documents/architecture-diagrams/external-connectivity-to-amazon-vpc-lattice.pdf)Step 1This Guidance will deploy a virtual private cloud (VPC) in multiple Availability Zones (AZs), with both public and private subnets containing internal and external Network Load Balancers.Step 2AWS PrivateLink VPC endpoints (interface and gateway) are created to reach AWS services privately.Step 3AWS CodePipeline orchestrates the build and delivery of this Guidance. The code is pulled from GitHub to an AWS CodeCommit repository.Step 4AWS CodeBuild builds containers that run an open-source version of NGINX. The container image is stored in Amazon Elastic Container Registry (Amazon ECR).Step 5The deployment stage in the pipeline uses AWS CloudFormation to build an Amazon Elastic Container Service (Amazon ECS) cluster, task definition, and service, using AWS Fargate as the capacity provider.Step 6Four target groups are used to pass traffic to the backend compute solution. Each Network Load Balancer configures two TCP listeners for ports 80 (HTTP) and 443 (HTTPS). The Amazon ECS tasks therefore service both internal and external traffic.### Public access This architecture diagram shows how placing a proxy solution in an associated VPC enables external consumption of VPC Lattice services by adjusting the DNS resolution. [Download the architecture diagram](https://d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/solutions/approved/documents/architecture-diagrams/external-connectivity-to-amazon-vpc-lattice.pdf)Step 1The consumer application located outside AWS tries to resolve service1's domain name publicly. An Amazon Route 53 public hosted zone resolves to the Network Load Balancer domain name.Step 2Traffic is sent to the Network Load Balancer public IPs (obtained after the DNS resolution), and the request is forwarded to the Fargate proxy fleet.Step 3Inside the ingress VPC, the proxy fleet resolves service1's domain name by using the VPC DNS resolver. A Route 53 private hosted zone is used to map the custom domain name with the domain name generated by Amazon VPC Lattice.Step 4The DNS resolution provides VPC Lattice with link-local addresses. Traffic is sent using the VPC Lattice VPC association.Step 5A service policy allows traffic between the AWS service network account and the AWS provider account if there is an association between the VPC Lattice service and the VPC Lattice service network. This can then be associated with the ingress VPC.Step 6This request is redirected to an AWS Lambda function.### Hybrid access This architecture diagram shows how placing a proxy solution in an associated VPC enables on-premises applications to have external consumption of VPC Lattice services by adjusting the hybrid DNS resolution. [Download the architecture diagram](https://d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/solutions/approved/documents/architecture-diagrams/external-connectivity-to-amazon-vpc-lattice.pdf)Step 1The on-premises consumer application tries to resolve service1's domain name locally. The on-premises DNS server forwards the DNS request to a Route 53 resolver inbound endpoint, located on AWS. You can make use of any hybrid connectivity solution with AWS.Step 2The Route 53 resolver inbound endpoint queries a Route 53 private hosted zone to resolve the Network Load Balancer domain name.Step 3A hybrid connectivity solution can be used for the connectivity between on-premises applications and AWS. Traffic is sent to the Network Load Balancer private IPs (obtained after the DNS resolution), and the request is forwarded to the Fargate proxy fleet.Step 4Inside the ingress VPC, the proxy fleet resolves service1's domain name by using the VPC DNS resolver. A Route 53 private hosted zone can be used to map the custom domain name with the domain name generated by VPC Lattice.Step 5The DNS resolution provides VPC Lattice with link-local addresses. Traffic will be sent using the VPC Lattice VPC association.Step 6A service auth policy allows traffic between the AWS service network account and the AWS provider account if there is an association between the VPC Lattice service and the VPC Lattice service network. This can then be associated with the ingress VPC.Step 7This request is redirected to a Lambda function.### Cross-Region access This architecture diagram shows how placing a proxy solution in an associated VPC enables cross-Region consumption of VPC Lattice services by adjusting the hybrid DNS resolution. [Download the architecture diagram](https://d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/solutions/approved/documents/architecture-diagrams/external-connectivity-to-amazon-vpc-lattice.pdf)Step 1Consumer applications in the consumer VPC from AWS Region 1 use their local DNS VPC resolver for service1's domain name resolution by using a Route 53 private hosted zone.Step 2Configure the DNS resolution to point to the proxy solution in the ingress VPC in Region 2.Step 3Any inter-Region connectivity option* enables communication between the consumer VPC in Region 1 and the ingress VPC in Region 2.Step 4Inside the ingress VPC, the Fargate proxy fleet will resolve service1's domain name by using the VPC DNS resolver. A Route 53 private hosted zone can be used to map the custom domain name to the domain name generated by VPC Lattice.Step 5DNS resolution will provide VPC Lattice with link-local addresses. Traffic will be sent using the VPC Lattice VPC association.Step 6A service auth policy allows traffic between the AWS service network account and the AWS provider account if there is an association between the VPC Lattice service and the VPC Lattice service network. This can then be associated with the ingress VPC.Step 7This request is redirected to a Lambda function.## Deploy with confidence Everything you need to launch this Guidance in your account is right here. - **Let's make it happen**: Ready to deploy? Review the sample code on GitHub for detailed deployment instructions to deploy as-is or customize to fit your needs. [Go to sample code](https://github.com/aws-solutions-library-samples/guidance-for-external-connectivity-amazon-vpc-lattice) ## Well-Architected Pillars The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible. ### Operational Excellence CodePipeline enables you to use a pipeline to make controlled and auditable changes through an artifact repository for the NGINX proxy solution, helping you avoid undesired updates. In addition, CloudFormation uses infrastructure as code to deploy all resources, giving you visibility and control over the created resources. [Read the Operational Excellence whitepaper](/wellarchitected/latest/operational-excellence-pillar/welcome.html) ### Security VPC Lattice handles authentication and authorization by using optional auth policies, both in the VPC Lattice service network and services. AWS Identity and Access Management (IAM), which uses the Zero Trust on AWS security model, establishes secure authentication and authorization mechanisms for service-to-service communication. IAM security credentials generate AWS Signature Version 4 signatures, which are passed to VPC Lattice. Common network security measures for the VPC and application add a second layer of security control. For example, you can use security groups and network access control lists, and the NGINX configuration enables you to define an allowlist of the source IPs that can connect to the proxy targets. [Read the Security whitepaper](/wellarchitected/latest/security-pillar/welcome.html) ### Reliability This Guidance deploys resources in three AZs, providing high availability for your proxy solution, made using a Network Load Balancer and an Amazon ECSon Fargate fleet. Additionally, CodePipeline uses managed AWS services—including CodeCommit, CodeBuild, and CloudFormation—that are built to be highly available within a Region by default. Note: This Guidance has been built on the assumption that it will automatically scale and contract using average CPU metrics for the Amazon ECS service as the dimension. Load testing revealed that the Guidance is CPU-bound as the load increases, based on the specifications of the chosen task sizes. You can adjust this Guidance to use a metric that best suits your application’s profile and load. [Read the Reliability whitepaper](/wellarchitected/latest/reliability-pillar/welcome.html) ### Performance Efficiency This Guidance uses a combination of AWS native services and customizable options. It uses a Network Load Balancer as the entry point because it provides high throughput, flexibility in protocol, and feature support when connecting to VPC Lattice. An Amazon ECS on Fargate proxy fleet provides flexibility in resolving the domain name generated by VPC Lattice to the link-local addresses (which might vary). The fleet uses Fargate to gain the scalability of serverless technologies and to simplify container management. [Read the Performance Efficiency whitepaper](/wellarchitected/latest/performance-efficiency-pillar/welcome.html) ### Cost Optimization This Guidance automatically scales the Amazon ECS on Fargate tasks as required, depending on CPU utilization. This automatic scalability of Amazon ECS means that the proxy solution only uses the required compute capacity, so you do not have to pay for unnecessary compute. [Read the Cost Optimization whitepaper](/wellarchitected/latest/cost-optimization-pillar/welcome.html) ### Sustainability Amazon ECS on Fargate handles scaling automatically so that your proxy solution has an optimal compute footprint based on CPU load. Additionally, the tasks use a lightweight version of NGINX to minimize the computational load when sending requests to VPC Lattice. By using configured and tested workload elasticity, this Guidance helps you efficiently match your cloud resource utilization to demand and avoid overprovisioned capacity, ultimately lowering your carbon footprint. [Read the Sustainability whitepaper](/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html) [Read usage guidelines](/solutions/guidance-disclaimers/)