{"id":307,"date":"2026-04-13T14:23:20","date_gmt":"2026-04-13T14:23:20","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-vpc-lattice-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-content-delivery\/"},"modified":"2026-04-13T14:23:20","modified_gmt":"2026-04-13T14:23:20","slug":"aws-amazon-vpc-lattice-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-content-delivery","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-vpc-lattice-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-content-delivery\/","title":{"rendered":"AWS Amazon VPC Lattice Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking and content delivery"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking and content delivery<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Amazon VPC Lattice is an AWS application networking service that helps you connect, secure, and monitor service-to-service communication across multiple VPCs and AWS accounts\u2014without building and operating complex VPC routing, peering meshes, or per-service ingress patterns.<\/p>\n\n\n\n<p><strong>Simple explanation:<\/strong> You create a \u201cservice network\u201d and publish services into it. Any VPC associated with that service network can call those services using AWS-managed discovery\/DNS, with centralized access controls and observability.<\/p>\n\n\n\n<p><strong>Technical explanation:<\/strong> Amazon VPC Lattice provides an AWS-managed data plane for HTTP\/HTTPS (and related L7 patterns) between clients and targets across VPC boundaries. You define <em>services<\/em>, <em>listeners<\/em>, <em>rules<\/em>, and <em>target groups<\/em>, then associate them with a <em>service network<\/em>. You can apply IAM-based authorization policies, optionally configure TLS, and enable centralized logging\/metrics. It integrates with AWS resource sharing to enable cross-account consumption and supports patterns common in microservices and multi-VPC environments.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> As environments grow (multiple VPCs, accounts, teams, microservices), service connectivity and governance become hard:\n&#8211; Routing: VPC peering\/Transit Gateway design and operations become complex.\n&#8211; Discovery: Clients need a consistent way to find services across VPCs.\n&#8211; Security: Fine-grained, centralized authorization is difficult with only security groups\/NACLs.\n&#8211; Observability: You want uniform access logs and metrics for east-west traffic.<\/p>\n\n\n\n<p>Amazon VPC Lattice addresses these by providing a managed layer for application connectivity and policy across VPCs and accounts.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Amazon VPC Lattice?<\/h2>\n\n\n\n<p><strong>Official purpose (in practical terms):<\/strong> Amazon VPC Lattice helps you connect services across VPCs and accounts, apply consistent access controls, and gain visibility into service-to-service traffic. For the canonical definition and latest protocol\/feature list, verify in the official documentation: https:\/\/docs.aws.amazon.com\/vpc-lattice\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service discovery across VPCs\/accounts<\/strong> using AWS-managed DNS names for Lattice services.<\/li>\n<li><strong>Application-layer routing<\/strong> via listeners and rules (for example, by path or header\u2014verify rule conditions supported in your region in official docs).<\/li>\n<li><strong>Centralized authorization<\/strong> using IAM-based auth policies (resource policies) to control which principals can call which services.<\/li>\n<li><strong>Operational visibility<\/strong> through metrics and access logs (delivery destinations vary by region\/features\u2014verify in official docs).<\/li>\n<li><strong>Simplified multi-VPC connectivity<\/strong> by associating VPCs to service networks rather than building large peering\/route-table topologies per service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service network<\/strong>: A logical boundary\/mesh where services live and where VPCs are associated as consumers and\/or producers.<\/li>\n<li><strong>VPC association<\/strong>: Attaches a VPC to a service network so workloads in that VPC can resolve\/reach services in the network.<\/li>\n<li><strong>Service<\/strong>: A Lattice construct representing an application endpoint exposed to consumers.<\/li>\n<li><strong>Listener<\/strong>: The port\/protocol entry point for a service (for example, HTTP on 80 or 8080; HTTPS with TLS).<\/li>\n<li><strong>Rules<\/strong>: Define request matching and forwarding behavior to one or more target groups (capabilities depend on supported protocols and feature availability).<\/li>\n<li><strong>Target group<\/strong>: Where requests are forwarded\u2014typically compute targets such as instances, IP addresses, or Lambda functions. (Verify currently supported target types in your region in official docs.)<\/li>\n<li><strong>Auth policy<\/strong>: An IAM resource policy attached to a service network or service to control access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed AWS networking and application connectivity service<\/strong> (control plane in AWS; data plane managed by AWS).<\/li>\n<li>Primarily for <strong>east-west<\/strong> (service-to-service) traffic, not internet-facing traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional\/global\/etc.)<\/h3>\n\n\n\n<p>Amazon VPC Lattice is a <strong>regional<\/strong> service (you create and use resources in a specific AWS Region). Some usage patterns span multiple accounts via sharing, but they are still region-scoped. Always confirm region availability here: https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/ (filter for Amazon VPC Lattice).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>Amazon VPC Lattice sits between:\n&#8211; <strong>Compute<\/strong>: Amazon EC2, containers (ECS\/EKS), and serverless (Lambda targets where supported)\n&#8211; <strong>Networking<\/strong>: Amazon VPC, security groups, AWS Resource Access Manager (RAM) for sharing, and optionally Transit Gateway\/peering for other connectivity needs\n&#8211; <strong>Identity &amp; Security<\/strong>: IAM principals\/policies, CloudTrail auditing, ACM for certificates (HTTPS), AWS WAF is not the primary control here (verify any integration options in official docs)\n&#8211; <strong>Observability<\/strong>: CloudWatch metrics\/logs (and potentially log delivery integrations\u2014verify exact destinations)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Amazon VPC Lattice?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster platform delivery<\/strong>: Platform teams can offer standardized service connectivity to many app teams.<\/li>\n<li><strong>Reduced operational overhead<\/strong>: Less bespoke VPC routing and per-service connectivity work.<\/li>\n<li><strong>Consistency at scale<\/strong>: Central policies for who can call what, even across accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Multi-VPC service connectivity<\/strong> without building per-service networking primitives.<\/li>\n<li><strong>Standardized service exposure<\/strong>: Services are published once and consumed from many VPCs.<\/li>\n<li><strong>L7 routing<\/strong> (depending on protocol\/features): Enables patterns that are awkward with only NLB\/PrivateLink.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralized visibility<\/strong>: Uniform metrics\/logging patterns across services.<\/li>\n<li><strong>Decoupled growth<\/strong>: Add consumers or producer VPCs by association rather than redesigning routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM-based authorization<\/strong>: Enforce access using IAM principals and conditions.<\/li>\n<li><strong>Clear boundaries<\/strong>: Service networks provide a governance boundary aligned to environments (dev\/stage\/prod), domains, or business units.<\/li>\n<li><strong>Auditability<\/strong>: CloudTrail for control plane actions; access logs for requests (verify log types\/destinations in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Designed for service-to-service<\/strong>: Avoids \u201cspaghetti connectivity\u201d as services and VPCs increase.<\/li>\n<li><strong>Managed scaling<\/strong>: AWS manages the underlying data plane.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You have <strong>multiple VPCs and\/or accounts<\/strong> and want <strong>consistent service connectivity<\/strong>.<\/li>\n<li>You want <strong>central authorization policies<\/strong> for service invocation (beyond security groups).<\/li>\n<li>You want a <strong>platform approach<\/strong>: publish services; let internal consumers discover and call them.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You only need <strong>simple connectivity<\/strong> between a small number of VPCs (VPC peering may be enough).<\/li>\n<li>Your primary need is <strong>internet-facing load balancing<\/strong> (use ALB\/NLB, CloudFront, API Gateway).<\/li>\n<li>You require <strong>full service mesh features<\/strong> (mTLS everywhere, deep traffic shaping, sidecar-level telemetry) and are already standardized on <strong>App Mesh \/ Istio<\/strong>\u2014though you can still use Lattice in some architectures, you should evaluate overlaps carefully.<\/li>\n<li>You need <strong>pure L4 connectivity<\/strong> for many arbitrary ports\/protocols (verify protocol support; Lattice is commonly positioned at L7).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Amazon VPC Lattice used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Fintech and banking (segmented accounts\/VPCs, strict access control)<\/li>\n<li>Healthcare (regulated environments, auditability)<\/li>\n<li>SaaS and tech (microservices, multi-tenant internal platforms)<\/li>\n<li>Retail\/e-commerce (many internal services, environment separation)<\/li>\n<li>Media\/gaming (service sprawl, multi-account)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building internal developer platforms (IDPs)<\/li>\n<li>SRE\/operations teams standardizing east-west connectivity<\/li>\n<li>Security engineering teams enforcing service-level access control<\/li>\n<li>Application teams that need simple \u201ccall another service\u201d connectivity across VPCs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices (ECS\/EKS\/EC2)<\/li>\n<li>Multi-account landing zone deployments (AWS Organizations)<\/li>\n<li>Shared services architectures (central auth, billing, telemetry, CI\/CD services)<\/li>\n<li>Hybrid is possible but evaluate carefully; Lattice is designed for VPC-based workloads (verify any hybrid connectivity patterns in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-VPC microservices with shared services<\/li>\n<li>Domain-based service networks (payments, identity, ordering)<\/li>\n<li>Environment-based segmentation (dev\/test\/prod service networks)<\/li>\n<li>Cross-account \u201cproducer\/consumer\u201d models using AWS RAM sharing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: Great for quickly connecting services across sandbox VPCs without building peering.<\/li>\n<li><strong>Production<\/strong>: Works well when you define strong governance: naming, tagging, policies, logging, and change control.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic, common scenarios where Amazon VPC Lattice fits well.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Multi-VPC microservices connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Services are spread across many VPCs (EKS clusters, ECS clusters, EC2 groups). Connectivity becomes a mesh of peering\/TGW routes.<\/li>\n<li><strong>Why Lattice fits:<\/strong> Publish each service once; associate consumer VPCs to the service network.<\/li>\n<li><strong>Example:<\/strong> \u201corders\u201d in VPC A calls \u201cinventory\u201d in VPC B and \u201cpricing\u201d in VPC C using Lattice DNS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Cross-account shared services (central platform)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A central platform account provides \u201cauth\u201d, \u201clogging\u201d, \u201cfeature flags\u201d to many application accounts.<\/li>\n<li><strong>Why Lattice fits:<\/strong> Share service networks and services via AWS RAM and control access via IAM.<\/li>\n<li><strong>Example:<\/strong> App accounts consume <code>auth.service<\/code> exposed by platform account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Environment segmentation with consistent connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You want dev\/stage\/prod isolation but still consistent patterns.<\/li>\n<li><strong>Why Lattice fits:<\/strong> Separate service networks per environment; consistent policies\/logging.<\/li>\n<li><strong>Example:<\/strong> <code>prod-sn<\/code> and <code>dev-sn<\/code>, each with their own services and VPC associations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Incremental migration from monolith to services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You are splitting a monolith into services across multiple VPCs\/accounts.<\/li>\n<li><strong>Why Lattice fits:<\/strong> New services can be exposed and consumed without redesigning networking.<\/li>\n<li><strong>Example:<\/strong> Monolith calls new <code>payments<\/code> service in another VPC through Lattice.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Centralized authorization for service-to-service calls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Security groups handle reachability but not \u201cwhich workload is allowed to call which API.\u201d<\/li>\n<li><strong>Why Lattice fits:<\/strong> IAM auth policies can restrict invocations by principal\/role.<\/li>\n<li><strong>Example:<\/strong> Only the <code>OrderServiceRole<\/code> can call <code>inventory<\/code> endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Simplified service discovery across VPCs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Cloud Map\/private DNS across accounts becomes complicated, or teams create inconsistent DNS patterns.<\/li>\n<li><strong>Why Lattice fits:<\/strong> Services get AWS-managed DNS names in the service network.<\/li>\n<li><strong>Example:<\/strong> <code>curl http:\/\/&lt;service-dns-name&gt;\/health<\/code> from any associated VPC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Shared EKS cluster services consumed by other VPCs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You run shared EKS services in one VPC and need many VPCs to consume them privately.<\/li>\n<li><strong>Why Lattice fits:<\/strong> Expose the service via Lattice targets (verify best practice integration for Kubernetes ingress targets in official docs).<\/li>\n<li><strong>Example:<\/strong> Central \u201cinternal API\u201d is called from multiple app VPCs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Blue\/green or weighted rollout across target groups<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need safer rollouts across new versions.<\/li>\n<li><strong>Why Lattice fits:<\/strong> Some Lattice routing features can forward to multiple target groups (verify weighting\/canary support in official docs).<\/li>\n<li><strong>Example:<\/strong> 90% to v1 targets, 10% to v2 targets, then gradually shift.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Domain-based governance boundaries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Different business domains want autonomy, but the org needs consistent guardrails.<\/li>\n<li><strong>Why Lattice fits:<\/strong> One service network per domain with domain-specific policies\/logging.<\/li>\n<li><strong>Example:<\/strong> A \u201cpayments\u201d service network shared to selected app accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Reducing load balancer sprawl<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Each internal service uses its own internal ALB\/NLB, increasing cost\/ops overhead.<\/li>\n<li><strong>Why Lattice fits:<\/strong> Lattice provides a managed entry layer for services (still validate target requirements and health checks).<\/li>\n<li><strong>Example:<\/strong> Replace per-service internal ALBs for certain services with Lattice service fronting EC2\/ECS targets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Internal API platform for multiple teams<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Many teams publish internal APIs, but discovery, access, and logging are inconsistent.<\/li>\n<li><strong>Why Lattice fits:<\/strong> Standard publish\/consume model with consistent logs and policies.<\/li>\n<li><strong>Example:<\/strong> \u201cdeveloper platform\u201d team provides a template to onboard any internal API to Lattice.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on important current features, with practical implications. When a detail is region- or release-dependent, it\u2019s called out.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Service networks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> A logical grouping where Lattice services live and where consumer VPCs associate.<\/li>\n<li><strong>Why it matters:<\/strong> It becomes your primary governance boundary.<\/li>\n<li><strong>Practical benefit:<\/strong> A single VPC association can grant access to many services.<\/li>\n<li><strong>Caveats:<\/strong> Treat service networks like environments\/domains; avoid mixing unrelated trust zones.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">VPC association to a service network<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enables workloads in a VPC to resolve and reach services in the service network.<\/li>\n<li><strong>Why it matters:<\/strong> It replaces per-service routing\/peering complexity with a single association.<\/li>\n<li><strong>Practical benefit:<\/strong> Onboard a whole VPC as a consumer in minutes.<\/li>\n<li><strong>Caveats:<\/strong> Security groups used in association matter for traffic enforcement; design them deliberately.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lattice services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Represents a reachable endpoint with listeners and routing to target groups.<\/li>\n<li><strong>Why it matters:<\/strong> Standardizes how consumers call producers.<\/li>\n<li><strong>Practical benefit:<\/strong> You can publish a service backed by multiple targets and update targets without changing clients.<\/li>\n<li><strong>Caveats:<\/strong> Understand protocol support (HTTP\/HTTPS and related options). Verify supported protocols and features in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Target groups<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines the set of backends for a service.<\/li>\n<li><strong>Why it matters:<\/strong> Enables dynamic membership and health-based routing.<\/li>\n<li><strong>Practical benefit:<\/strong> Register instances\/IPs\/Lambda (supported types vary by region\/feature set).<\/li>\n<li><strong>Caveats:<\/strong> Ensure target security groups allow traffic from Lattice association security groups (common gotcha).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Health checks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Determines whether targets are eligible to receive traffic.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents sending traffic to unhealthy backends.<\/li>\n<li><strong>Practical benefit:<\/strong> Improves reliability for rolling updates and failures.<\/li>\n<li><strong>Caveats:<\/strong> Ensure your service responds correctly on the health check path\/port.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Listeners (HTTP\/HTTPS) and routing rules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Accepts requests and routes them based on conditions to target groups.<\/li>\n<li><strong>Why it matters:<\/strong> Enables clean URL-based routing and versioning patterns (where supported).<\/li>\n<li><strong>Practical benefit:<\/strong> <code>\/api<\/code> to one target group, <code>\/admin<\/code> to another.<\/li>\n<li><strong>Caveats:<\/strong> Rule match capabilities vary; verify supported condition types (path, header, method, query string, etc.) in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM authentication and authorization policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Controls which IAM principals can invoke a service.<\/li>\n<li><strong>Why it matters:<\/strong> Security groups alone cannot express \u201conly this role can call that API.\u201d<\/li>\n<li><strong>Practical benefit:<\/strong> Enforce least privilege at the service layer.<\/li>\n<li><strong>Caveats:<\/strong> Requires clients to sign requests (SigV4) when IAM auth is enforced; this impacts client implementation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">TLS\/HTTPS support (via ACM)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Encrypts traffic to the Lattice endpoint using TLS certificates managed in AWS Certificate Manager.<\/li>\n<li><strong>Why it matters:<\/strong> Protects data in transit and supports compliance requirements.<\/li>\n<li><strong>Practical benefit:<\/strong> Standard HTTPS endpoints for internal services.<\/li>\n<li><strong>Caveats:<\/strong> Certificate lifecycle, domain naming, and client trust must be handled carefully. Verify current HTTPS listener requirements in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Access logs and metrics<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides request-level logs and service metrics.<\/li>\n<li><strong>Why it matters:<\/strong> Critical for operations, security investigations, and debugging.<\/li>\n<li><strong>Practical benefit:<\/strong> Centralized visibility across many services.<\/li>\n<li><strong>Caveats:<\/strong> Log destinations and fields vary by feature\/region\u2014verify in official docs. Logging can add cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cross-account sharing (AWS RAM)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you share service networks and\/or services across accounts.<\/li>\n<li><strong>Why it matters:<\/strong> Enables producer\/consumer patterns in AWS Organizations.<\/li>\n<li><strong>Practical benefit:<\/strong> Central teams can publish, app teams can consume.<\/li>\n<li><strong>Caveats:<\/strong> You still need strong IAM policies and governance to avoid over-sharing.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level:\n1. A <strong>producer<\/strong> VPC hosts application targets (instances\/IPs\/Lambda).\n2. You create a <strong>Lattice service<\/strong> with a listener and rules that forward to <strong>target groups<\/strong>.\n3. You create a <strong>service network<\/strong> and associate the service with it.\n4. A <strong>consumer<\/strong> VPC associates to the same service network.\n5. Clients in consumer VPC resolve the service through <strong>Lattice-managed DNS<\/strong> and send HTTP\/HTTPS requests.\n6. Lattice enforces <strong>auth policy<\/strong> (if configured) and routes to healthy targets.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> You create\/modify service networks, services, listeners, rules, target groups, and policies (via console\/API\/CLI). These actions are logged in AWS CloudTrail.<\/li>\n<li><strong>Data plane:<\/strong> Requests flow from clients to the Lattice endpoint, then to selected targets. Health checks and routing decisions happen in the managed data plane.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related AWS services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>IAM<\/strong>: auth policies and principal-based access.\n&#8211; <strong>ACM<\/strong>: TLS certificates for HTTPS listeners.\n&#8211; <strong>CloudWatch<\/strong>: metrics and (depending on configuration) logs.\n&#8211; <strong>CloudTrail<\/strong>: audit of Lattice API calls.\n&#8211; <strong>AWS RAM<\/strong>: resource sharing across accounts.\n&#8211; <strong>VPC security groups<\/strong>: control which traffic can reach targets (especially via association security groups).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Network reachability<\/strong> is governed by:<\/li>\n<li>VPC association to the service network<\/li>\n<li>security groups used by the association<\/li>\n<li>target security groups<\/li>\n<li><strong>Authorization<\/strong> can be enforced using <strong>IAM auth policies<\/strong> (service-level or service-network-level).<\/li>\n<li>If IAM auth is enabled, <strong>clients must sign requests<\/strong> (SigV4). Non-signed curl calls will fail.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Clients access Lattice services <strong>privately<\/strong> from associated VPCs.<\/li>\n<li>Targets remain in their own VPCs; you don\u2019t have to expose them publicly.<\/li>\n<li>You typically configure target security groups to allow inbound from the <strong>Lattice association security group<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define standard:<\/li>\n<li>naming\/tagging for service networks\/services<\/li>\n<li>access logging settings<\/li>\n<li>CloudWatch alarms on error rates\/latency (metrics availability varies\u2014verify in docs)<\/li>\n<li>policy-as-code workflow for Lattice resources (CloudFormation\/Terraform support depends on resource coverage\u2014verify your chosen IaC provider)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  C[Client in Consumer VPC] --&gt;|HTTP request| L[Amazon VPC Lattice Service\\n(DNS name)]\n  L --&gt; TG[Target Group]\n  TG --&gt; T1[Target: EC2\/IP\/Lambda\\nin Producer VPC]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[AWS Organization]\n    subgraph NetAcct[Networking\/Platform Account]\n      SN[Service Network: prod-sn]\n      POL[Auth Policy\\n(IAM resource policy)]\n      LOG[Access Logs \/ Metrics\\n(CloudWatch, etc.)]\n      SN --&gt; POL\n      SN --&gt; LOG\n    end\n\n    subgraph ProdAcctA[Prod Account A - Producer]\n      VPCP[Producer VPC]\n      SVC1[Lattice Service: orders]\n      LST1[Listener :443 (HTTPS)]\n      RULES1[Rules: \/v1, \/v2]\n      TG1[Target Group v1]\n      TG2[Target Group v2]\n      APP1[Orders v1 targets]\n      APP2[Orders v2 targets]\n      VPCP --&gt; APP1\n      VPCP --&gt; APP2\n      SVC1 --&gt; LST1 --&gt; RULES1\n      RULES1 --&gt; TG1 --&gt; APP1\n      RULES1 --&gt; TG2 --&gt; APP2\n    end\n\n    subgraph ProdAcctB[Prod Account B - Consumer]\n      VPCC[Consumer VPC]\n      CL1[Microservice Client]\n    end\n  end\n\n  SN --&gt; SVC1\n  VPCC --- SN\n  CL1 --&gt;|HTTPS + SigV4| SVC1\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">AWS account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An AWS account with permissions to use <strong>Amazon VPC Lattice<\/strong>, <strong>Amazon VPC<\/strong>, and <strong>Amazon EC2<\/strong>.<\/li>\n<li>If you will test cross-account sharing: multiple AWS accounts and <strong>AWS Organizations<\/strong> is helpful (optional for this tutorial).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>Minimum recommended for the lab:\n&#8211; VPC Lattice full management for the lab user\/role (for example, an admin role in a sandbox).\n&#8211; EC2 permissions to launch instances, create security groups, and read instance IPs.\n&#8211; IAM permissions if you enable IAM authentication policies (optional for this lab).<\/p>\n\n\n\n<p>In production, you should create scoped IAM policies rather than using broad access.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A billable AWS account. Amazon VPC Lattice is not generally \u201cfree.\u201d<\/li>\n<li>EC2 instance costs apply.<\/li>\n<li>CloudWatch log ingestion\/storage costs may apply if you enable access logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Console access<\/li>\n<li>Optional but helpful:<\/li>\n<li>AWS CLI v2 (https:\/\/docs.aws.amazon.com\/cli\/)<\/li>\n<li>SSH client (or EC2 Instance Connect)<\/li>\n<li><code>curl<\/code> on a client instance<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<p>Amazon VPC Lattice is not in every region. Confirm availability before you start:\n&#8211; Region list and service availability: https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/\n&#8211; Amazon VPC Lattice docs landing page: https:\/\/docs.aws.amazon.com\/vpc-lattice\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Service quotas exist for service networks, services, target groups, associations, and rules. Check current quotas in:\n&#8211; Service Quotas console\n&#8211; Official quotas documentation for VPC Lattice (verify in official docs)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon VPC (two VPCs for this lab)<\/li>\n<li>Amazon EC2 (two small instances for a simple producer\/consumer test)<\/li>\n<li>(Optional) ACM if you want HTTPS in the lab<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Amazon VPC Lattice pricing is <strong>usage-based<\/strong> and depends on how many Lattice resources you run and how much traffic you process.<\/p>\n\n\n\n<p>Because pricing varies by <strong>Region<\/strong> and may evolve, do not rely on static numbers in a tutorial. Use the official pricing page and the AWS Pricing Calculator.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/aws.amazon.com\/vpc\/lattice\/pricing\/<\/li>\n<li>AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical pricing dimensions (verify exact dimensions on the pricing page)<\/h3>\n\n\n\n<p>Common cost drivers for managed application networking services like Lattice include:\n&#8211; <strong>Hourly charges<\/strong> for running Lattice constructs (for example, per service, per association, or similar)\n&#8211; <strong>Per-request<\/strong> charges (requests processed)\n&#8211; <strong>Data processing<\/strong> charges (GB processed through the service)\n&#8211; <strong>Logging costs<\/strong> (CloudWatch log ingestion\/storage, if enabled)<\/p>\n\n\n\n<p><strong>Verify the exact dimensions for Amazon VPC Lattice<\/strong> on the official pricing page above.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>As of many AWS networking services, there may be <strong>no free tier<\/strong> for Lattice beyond limited-time promotions. Verify on the pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Number of <strong>services<\/strong> and <strong>service networks<\/strong><\/li>\n<li>Number of <strong>VPC associations<\/strong><\/li>\n<li>Total <strong>requests<\/strong> and <strong>data processed<\/strong><\/li>\n<li><strong>Access logging<\/strong> volume<\/li>\n<li>EC2\/Lambda backend costs behind the service<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>EC2 data transfer<\/strong>: Inter-AZ and inter-VPC data transfer can apply depending on architecture. Lattice-related data processing is separate from standard VPC data transfer charges. Always validate with billing estimates.<\/li>\n<li><strong>CloudWatch Logs<\/strong>: High request volume can generate large logs quickly.<\/li>\n<li><strong>NAT gateways<\/strong> (if your instances need outbound internet from private subnets)<\/li>\n<li><strong>ACM certificates<\/strong> are usually no-cost for public certs in many cases, but integrations and private CA can add costs (verify for your scenario).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Minimize unnecessary services<\/strong>: consolidate where appropriate; avoid one-service-per-endpoint explosion.<\/li>\n<li><strong>Use fewer VPC associations<\/strong>: prefer shared VPCs or centralized egress\/ingress patterns when it makes governance sense.<\/li>\n<li><strong>Be deliberate with logs<\/strong>: enable access logs where needed; define retention policies.<\/li>\n<li><strong>Right-size backends<\/strong>: Lattice doesn\u2019t remove the need to scale EC2\/ECS\/EKS targets appropriately.<\/li>\n<li><strong>Use tagging<\/strong>: allocate and monitor costs per environment\/team\/application.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (method, not numbers)<\/h3>\n\n\n\n<p>A small lab setup typically includes:\n&#8211; 1 service network\n&#8211; 2 VPC associations (producer + consumer VPC)\n&#8211; 1 service with 1 listener and 1 target group\n&#8211; Low request volume\n&#8211; 2 small EC2 instances (producer + consumer)<\/p>\n\n\n\n<p>Estimate by entering these items in:\n&#8211; AWS Pricing Calculator (search for \u201cVPC Lattice\u201d and EC2)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, costs can scale with:\n&#8211; Hundreds of services and dozens of VPCs\n&#8211; High RPS + large payloads (data processing)\n&#8211; Access logs for compliance (high log ingestion)\n&#8211; Multiple environments (dev\/stage\/prod duplication)<\/p>\n\n\n\n<p>A good practice is to run a <strong>cost model review<\/strong>:\n&#8211; expected RPS and payload size per service\n&#8211; expected number of VPC associations\n&#8211; log retention and sampling strategy<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a private, cross-VPC service-to-service connection using <strong>Amazon VPC Lattice<\/strong>:\n&#8211; A <strong>producer<\/strong> VPC runs a simple HTTP server on an EC2 instance.\n&#8211; A <strong>consumer<\/strong> VPC runs a client EC2 instance that calls the producer through <strong>Amazon VPC Lattice<\/strong>.\n&#8211; You will validate traffic flow and then clean up all resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build:\n&#8211; 2 VPCs (ProducerVPC, ConsumerVPC), each with 1 public subnet (for easy SSH\/EC2 connect).\n&#8211; 1 EC2 instance in each VPC:\n  &#8211; Producer instance runs a simple web server on port 8080.\n  &#8211; Consumer instance uses <code>curl<\/code> to call the service through Lattice.\n&#8211; 1 Amazon VPC Lattice Service Network\n&#8211; 1 Lattice Service + Listener + Target Group pointing to the producer instance\n&#8211; VPC associations for both VPCs<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> From the consumer instance, you can <code>curl<\/code> the Lattice service DNS name and receive a response from the producer instance.<\/p>\n\n\n\n<blockquote>\n<p>Notes before you start:\n&#8211; This lab uses public subnets to simplify connectivity to the instances. The service call itself is intended to be private inside AWS.\n&#8211; UI labels in the console can change; follow the intent of each step.\n&#8211; If you prefer IaC (CloudFormation\/Terraform), verify current resource support for VPC Lattice in your toolchain.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose a supported Region and set naming<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Choose an AWS Region where <strong>Amazon VPC Lattice<\/strong> is available.<\/li>\n<li>Decide a short prefix to tag everything, for example: <code>lattice-lab<\/code>.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a region selected and a consistent naming prefix.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create two VPCs (Producer and Consumer)<\/h3>\n\n\n\n<p>Create <strong>ProducerVPC<\/strong>:\n1. Open the <strong>VPC Console<\/strong> \u2192 <strong>Your VPCs<\/strong> \u2192 <strong>Create VPC<\/strong>.\n2. Create a VPC with:\n   &#8211; Name: <code>lattice-lab-producer-vpc<\/code>\n   &#8211; IPv4 CIDR: <code>10.10.0.0\/16<\/code> (example)\n3. Create a <strong>public subnet<\/strong> in one AZ:\n   &#8211; Name: <code>lattice-lab-producer-public-subnet<\/code>\n   &#8211; CIDR: <code>10.10.1.0\/24<\/code>\n4. Create and attach an <strong>Internet Gateway<\/strong>:\n   &#8211; Name: <code>lattice-lab-producer-igw<\/code>\n5. Create a <strong>route table<\/strong> for the public subnet and add:\n   &#8211; <code>0.0.0.0\/0<\/code> \u2192 Internet Gateway\n6. Enable <strong>auto-assign public IPv4<\/strong> on the public subnet (or do it at instance launch).<\/p>\n\n\n\n<p>Create <strong>ConsumerVPC<\/strong> similarly:\n&#8211; Name: <code>lattice-lab-consumer-vpc<\/code>\n&#8211; CIDR: <code>10.20.0.0\/16<\/code>\n&#8211; Public subnet: <code>10.20.1.0\/24<\/code>\n&#8211; Internet gateway + public route<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have two VPCs, each with one public subnet and internet access for EC2 administration.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create security groups (Producer instance, Consumer instance, and Lattice association SGs)<\/h3>\n\n\n\n<p>You will create:\n&#8211; A <strong>ProducerInstanceSG<\/strong> allowing port 8080 <em>only<\/em> from the Lattice association security group (recommended).\n&#8211; A <strong>ConsumerInstanceSG<\/strong> allowing SSH from your IP (and all outbound).\n&#8211; <strong>Two Lattice association security groups<\/strong>, one in each VPC, that Lattice will use within the VPC association.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">3A) Producer VPC security groups<\/h4>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>In <strong>EC2 Console<\/strong> \u2192 <strong>Security Groups<\/strong> \u2192 <strong>Create security group<\/strong>:\n   &#8211; Name: <code>lattice-lab-producer-lattice-assoc-sg<\/code>\n   &#8211; VPC: ProducerVPC\n   &#8211; Inbound rules: none (you typically don\u2019t need inbound here)\n   &#8211; Outbound rules: allow all (default)<\/p>\n<\/li>\n<li>\n<p>Create the producer instance SG:\n   &#8211; Name: <code>lattice-lab-producer-instance-sg<\/code>\n   &#8211; VPC: ProducerVPC\n   &#8211; Inbound:<\/p>\n<ul>\n<li>TCP 22 from <strong>your public IP<\/strong> (optional; if using EC2 Instance Connect, adjust accordingly)<\/li>\n<li>TCP 8080 <strong>from security group<\/strong>: <code>lattice-lab-producer-lattice-assoc-sg<\/code><\/li>\n<li>Outbound: allow all<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h4 class=\"wp-block-heading\">3B) Consumer VPC security groups<\/h4>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Create Lattice association SG in ConsumerVPC:\n   &#8211; Name: <code>lattice-lab-consumer-lattice-assoc-sg<\/code>\n   &#8211; VPC: ConsumerVPC<\/p>\n<\/li>\n<li>\n<p>Create consumer instance SG:\n   &#8211; Name: <code>lattice-lab-consumer-instance-sg<\/code>\n   &#8211; VPC: ConsumerVPC\n   &#8211; Inbound:<\/p>\n<ul>\n<li>TCP 22 from <strong>your public IP<\/strong><\/li>\n<li>Outbound: allow all<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> Security groups exist and the producer allows inbound 8080 only from the Lattice association SG in ProducerVPC.<\/p>\n\n\n\n<blockquote>\n<p>Common gotcha: If you allow inbound 8080 from the consumer VPC CIDR instead of from the Lattice association SG, it may not work because traffic can arrive from Lattice-managed infrastructure in the producer VPC, not directly from the client CIDR.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Launch EC2 instances (Producer and Consumer)<\/h3>\n\n\n\n<p>Launch <strong>Producer EC2<\/strong>:\n1. EC2 Console \u2192 <strong>Instances<\/strong> \u2192 <strong>Launch instances<\/strong>\n2. Name: <code>lattice-lab-producer-ec2<\/code>\n3. AMI: Amazon Linux 2023 (or Amazon Linux 2)\n4. Instance type: <code>t3.micro<\/code> (or smallest eligible for your account; stay within free tier where applicable, though Lattice itself may not be free)\n5. Network settings:\n   &#8211; VPC: ProducerVPC\n   &#8211; Subnet: producer public subnet\n   &#8211; Auto-assign public IP: enabled\n   &#8211; Security group: <code>lattice-lab-producer-instance-sg<\/code>\n6. Key pair: select\/create one (unless using EC2 Instance Connect\/SSM)<\/p>\n\n\n\n<p>Launch <strong>Consumer EC2<\/strong> similarly:\n&#8211; Name: <code>lattice-lab-consumer-ec2<\/code>\n&#8211; VPC: ConsumerVPC\n&#8211; Subnet: consumer public subnet\n&#8211; SG: <code>lattice-lab-consumer-instance-sg<\/code><\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Two running instances with public IPs for administration.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Install and run a simple HTTP server on the Producer instance<\/h3>\n\n\n\n<p>Connect to the producer instance (SSH or EC2 Instance Connect), then run:<\/p>\n\n\n\n<p>For <strong>Amazon Linux 2023<\/strong>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo dnf -y install python3\ncat &gt; server.py &lt;&lt;'PY'\nimport http.server\nimport socketserver\nimport json\n\nclass Handler(http.server.SimpleHTTPRequestHandler):\n    def do_GET(self):\n        body = json.dumps({\n            \"service\": \"lattice-lab-producer\",\n            \"path\": self.path\n        }).encode(\"utf-8\")\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application\/json\")\n        self.send_header(\"Content-Length\", str(len(body)))\n        self.end_headers()\n        self.wfile.write(body)\n\nPORT = 8080\nwith socketserver.TCPServer((\"0.0.0.0\", PORT), Handler) as httpd:\n    print(f\"Serving on port {PORT}\")\n    httpd.serve_forever()\nPY\n\nnohup python3 server.py &gt; server.log 2&gt;&amp;1 &amp;\n<\/code><\/pre>\n\n\n\n<p>Verify locally on the producer:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s http:\/\/127.0.0.1:8080\/health\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You receive JSON from the producer instance:<\/p>\n\n\n\n<pre><code class=\"language-json\">{\"service\":\"lattice-lab-producer\",\"path\":\"\/health\"}\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create an Amazon VPC Lattice service network<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open <strong>Amazon VPC Lattice<\/strong> console (search \u201cVPC Lattice\u201d in AWS console).<\/li>\n<li>Create a <strong>Service network<\/strong>:\n   &#8211; Name: <code>lattice-lab-sn<\/code>\n   &#8211; (Optional) Tags: <code>Project=lattice-lab<\/code>, <code>Env=dev<\/code><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> A service network exists.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Associate both VPCs with the service network<\/h3>\n\n\n\n<p>You must associate:\n&#8211; ProducerVPC (so it can host service targets within the service network)\n&#8211; ConsumerVPC (so it can resolve and call services in the service network)<\/p>\n\n\n\n<p>In the service network:\n1. Add <strong>VPC association<\/strong> for ProducerVPC:\n   &#8211; VPC: <code>lattice-lab-producer-vpc<\/code>\n   &#8211; Security groups: select <code>lattice-lab-producer-lattice-assoc-sg<\/code><\/p>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Add <strong>VPC association<\/strong> for ConsumerVPC:\n   &#8211; VPC: <code>lattice-lab-consumer-vpc<\/code>\n   &#8211; Security groups: select <code>lattice-lab-consumer-lattice-assoc-sg<\/code><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> Both VPC associations show as active\/available.<\/p>\n\n\n\n<blockquote>\n<p>If association takes time, wait until the console indicates it is ready before proceeding.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a target group pointing to the Producer instance<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In VPC Lattice console, create a <strong>Target group<\/strong>:\n   &#8211; Name: <code>lattice-lab-tg<\/code>\n   &#8211; Target type: <strong>Instance<\/strong> (or <strong>IP<\/strong> if you prefer; choose what your console supports)\n   &#8211; Protocol: HTTP\n   &#8211; Port: 8080\n   &#8211; VPC: ProducerVPC (or per the UI requirements)<\/li>\n<li>Register targets:\n   &#8211; Select the producer instance <code>lattice-lab-producer-ec2<\/code>\n   &#8211; Port: 8080<\/li>\n<li>Configure health check:\n   &#8211; Path: <code>\/health<\/code> (or <code>\/<\/code>)\n   &#8211; Healthy threshold \/ interval: keep defaults for the lab<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> Target group contains the producer instance and eventually shows it as <strong>healthy<\/strong>.<\/p>\n\n\n\n<blockquote>\n<p>If the target stays unhealthy, see the Troubleshooting section (security group and health check path are the top issues).<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Create a Lattice service with an HTTP listener<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create a <strong>Service<\/strong>:\n   &#8211; Name: <code>lattice-lab-svc<\/code><\/li>\n<li>Add a <strong>Listener<\/strong>:\n   &#8211; Protocol: HTTP\n   &#8211; Port: 80 (or 8080; 80 is typical for clients, while targets can still be 8080)<\/li>\n<li>Default action:\n   &#8211; Forward to target group: <code>lattice-lab-tg<\/code><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> A service exists with a listener forwarding to your target group.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Associate the service with the service network<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open the service network <code>lattice-lab-sn<\/code><\/li>\n<li>Add a <strong>service association<\/strong>:\n   &#8211; Associate <code>lattice-lab-svc<\/code> with the service network<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> The service is now part of the service network and can be consumed from associated VPCs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 11: Find the service DNS name and test from the Consumer instance<\/h3>\n\n\n\n<p>In the VPC Lattice console, open your service <code>lattice-lab-svc<\/code> and locate the <strong>DNS name<\/strong> (the console shows the exact name to use from associated VPCs).<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Connect to the consumer instance.<\/li>\n<li>Run:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">curl -s http:\/\/&lt;PASTE-THE-LATTICE-SERVICE-DNS-NAME&gt;\/health\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You receive a JSON response from the producer:<\/p>\n\n\n\n<pre><code class=\"language-json\">{\"service\":\"lattice-lab-producer\",\"path\":\"\/health\"}\n<\/code><\/pre>\n\n\n\n<p>If you get a timeout, 503, or DNS issues, use the troubleshooting checklist below.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist to confirm everything is working:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Producer instance local test works<\/strong>\n   &#8211; <code>curl http:\/\/127.0.0.1:8080\/health<\/code> returns JSON.<\/p>\n<\/li>\n<li>\n<p><strong>Target group health is healthy<\/strong>\n   &#8211; Target registered and shows <strong>healthy<\/strong>.<\/p>\n<\/li>\n<li>\n<p><strong>Consumer can resolve DNS<\/strong>\n   &#8211; From consumer:<br\/>\n<code>bash\n     getent hosts &lt;LATTICE-SERVICE-DNS-NAME&gt; || nslookup &lt;LATTICE-SERVICE-DNS-NAME&gt;<\/code>\n   &#8211; You should see IPs returned.<\/p>\n<\/li>\n<li>\n<p><strong>Consumer gets HTTP 200<\/strong>\n   &#8211; <code>curl -i http:\/\/&lt;dns&gt;\/health<\/code> returns HTTP 200.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Target is unhealthy<\/h4>\n\n\n\n<p>Most common causes:\n&#8211; Producer instance SG does not allow inbound <strong>8080 from the ProducerVPC Lattice association SG<\/strong>.\n&#8211; Your server is not listening on <code>0.0.0.0:8080<\/code>.\n&#8211; Health check path mismatch (<code>\/health<\/code> vs <code>\/<\/code>).\n&#8211; Wrong target registration port.<\/p>\n\n\n\n<p>Fix:\n&#8211; Confirm on producer:\n  <code>bash\n  sudo ss -lntp | grep 8080<\/code>\n&#8211; Confirm SG inbound rule: TCP 8080 from <code>lattice-lab-producer-lattice-assoc-sg<\/code>.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Consumer curl times out<\/h4>\n\n\n\n<p>Most common causes:\n&#8211; Consumer VPC not actually associated to the service network (or association not active yet).\n&#8211; Service not associated with the service network.\n&#8211; DNS name copied incorrectly.<\/p>\n\n\n\n<p>Fix:\n&#8211; Re-check:\n  &#8211; Service network has both VPC associations active.\n  &#8211; Service is associated to the service network.\n  &#8211; Use the exact DNS name shown in the service details.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: HTTP 403\/401 (authorization)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you enabled IAM authentication on the service\/network, unsigned curl requests will fail.<\/li>\n<\/ul>\n\n\n\n<p>Fix:\n&#8211; For the lab, keep auth open (no IAM auth), or use an AWS SDK\/client that signs requests (SigV4).<br\/>\n  If you need IAM auth, verify the required client signing approach in official docs.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: 503 Service Unavailable<\/h4>\n\n\n\n<p>Common causes:\n&#8211; No healthy targets\n&#8211; Health checks failing\n&#8211; Listener\/rule not forwarding to a valid target group<\/p>\n\n\n\n<p>Fix:\n&#8211; Ensure at least one healthy target.\n&#8211; Confirm listener default action points to the correct target group.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete resources in this order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>VPC Lattice<\/strong>\n   &#8211; Disassociate service from service network\n   &#8211; Delete service listener\/service\n   &#8211; Delete target group\n   &#8211; Delete VPC associations\n   &#8211; Delete service network<\/li>\n<li><strong>EC2<\/strong>\n   &#8211; Terminate both EC2 instances<\/li>\n<li><strong>Networking<\/strong>\n   &#8211; Delete security groups (instance SGs and Lattice association SGs)\n   &#8211; Delete route tables (if created)\n   &#8211; Detach and delete internet gateways\n   &#8211; Delete subnets\n   &#8211; Delete both VPCs<\/li>\n<li><strong>CloudWatch logs<\/strong> (if enabled)\n   &#8211; Delete log groups or adjust retention<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Design service networks as trust boundaries<\/strong>: Align with environments (prod\/dev) or domains (payments\/identity).<\/li>\n<li><strong>Prefer stable service naming<\/strong>: Treat Lattice service names as contract surfaces.<\/li>\n<li><strong>Plan for multi-account<\/strong>: Use AWS RAM with clear producer\/consumer separation and documented onboarding.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use least privilege<\/strong>: Separate roles for \u201cmanage Lattice\u201d vs \u201cconsume services.\u201d<\/li>\n<li><strong>Use service-level auth policies<\/strong> for sensitive services; avoid overly broad service-network policies.<\/li>\n<li><strong>Avoid anonymous access by default<\/strong> in production; require IAM auth where appropriate (and ensure clients can sign).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control resource sprawl<\/strong>: Standardize when to create a new service vs reuse routing rules.<\/li>\n<li><strong>Centralize logging intentionally<\/strong>: Define retention and sampling strategy.<\/li>\n<li><strong>Tag everything<\/strong>: <code>App<\/code>, <code>Owner<\/code>, <code>Env<\/code>, <code>CostCenter<\/code>, <code>DataSensitivity<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use health checks tuned to your SLOs<\/strong>: Avoid overly aggressive intervals that can cause churn.<\/li>\n<li><strong>Keep backends responsive<\/strong>: Lattice won\u2019t fix slow applications; monitor target latency.<\/li>\n<li><strong>Use appropriate scaling<\/strong> on EC2\/ECS\/EKS targets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Multi-AZ targets<\/strong>: Place targets across multiple AZs for resilience.<\/li>\n<li><strong>Graceful deployments<\/strong>: Use target group registration changes and health checks to roll safely.<\/li>\n<li><strong>Automate validation<\/strong>: Synthetic canaries from consumer VPCs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standard dashboards<\/strong>: error rate, latency, healthy target count.<\/li>\n<li><strong>Centralized change management<\/strong>: Treat listener\/rule changes as high impact.<\/li>\n<li><strong>Use CloudTrail + alerts<\/strong>: detect unauthorized changes to policies\/associations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming pattern example:<\/li>\n<li>Service network: <code>sn-&lt;env&gt;-&lt;domain&gt;<\/code><\/li>\n<li>Service: <code>svc-&lt;app&gt;-&lt;api&gt;<\/code><\/li>\n<li>Target group: <code>tg-&lt;service&gt;-&lt;version&gt;<\/code><\/li>\n<li>Require tags on creation using SCPs or tag policies (AWS Organizations), where applicable.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane access<\/strong>: IAM permissions to create\/modify Lattice resources.<\/li>\n<li><strong>Data plane access<\/strong>: Auth policies can enforce which IAM principals can call a service (if IAM auth is enabled).<\/li>\n<li>Use <strong>resource policies<\/strong> thoughtfully\u2014broad principals (like <code>*<\/code>) can unintentionally allow too much.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>In transit<\/strong>: Use HTTPS listeners (TLS) for sensitive data. Manage certificates with ACM.<\/li>\n<li><strong>At rest<\/strong>: Access logs stored in CloudWatch Logs\/S3 (destination-dependent) require proper encryption and retention controls. Verify log destination options in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Lattice is generally for <strong>private<\/strong> connectivity from associated VPCs.<\/li>\n<li>Avoid placing sensitive services into broadly shared service networks.<\/li>\n<li>Use security groups to tightly control traffic reaching targets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not put secrets into headers or URLs that may be logged.<\/li>\n<li>Use AWS Secrets Manager or Parameter Store for credentials.<\/li>\n<li>If using IAM auth, prefer short-lived credentials (STS) on clients.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>CloudTrail<\/strong> for resource changes.<\/li>\n<li>Enable access logs where needed for investigations (balance with cost).<\/li>\n<li>Ensure logs are immutable where required (for example, S3 with Object Lock\u2014architecture-dependent).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define service boundaries and policies to match compliance scope (PCI, HIPAA, SOC2).<\/li>\n<li>Document who can publish services and who can consume them.<\/li>\n<li>Ensure certificate policies, encryption standards, and log retention meet your obligations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Over-sharing a service network to many accounts without strict auth policies.<\/li>\n<li>Relying only on security groups and not using IAM authorization for sensitive APIs.<\/li>\n<li>Logging sensitive data (tokens\/PII) in access logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Separate service networks per environment and sensitivity tier.<\/li>\n<li>Require IAM auth for privileged internal APIs.<\/li>\n<li>Use HTTPS\/TLS for sensitive data even inside a VPC.<\/li>\n<li>Use AWS Organizations guardrails (SCPs) to prevent accidental public exposure patterns in related services.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Amazon VPC Lattice evolves, always confirm details in official docs. Common limitations\/gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Region availability<\/strong>: Not supported in all AWS Regions.<\/li>\n<li><strong>Protocol\/feature coverage<\/strong>: Routing rules and conditions depend on protocol support; verify supported protocols and rule conditions in official docs.<\/li>\n<li><strong>Client changes when enabling IAM auth<\/strong>: Clients must sign requests (SigV4). This is a real adoption hurdle for some legacy clients.<\/li>\n<li><strong>Security group design<\/strong>: Targets often must allow inbound from the <strong>Lattice association security group<\/strong>, not from consumer CIDRs.<\/li>\n<li><strong>Quota limits<\/strong>: Limits on number of services, listeners, rules, and associations can surprise large organizations\u2014check Service Quotas early.<\/li>\n<li><strong>Logging cost growth<\/strong>: Access logs at high RPS can become expensive quickly.<\/li>\n<li><strong>Migration planning<\/strong>: Moving from internal ALBs\/PrivateLink\/mesh solutions requires careful DNS and client-cutover planning.<\/li>\n<li><strong>Cross-account complexity<\/strong>: Sharing via AWS RAM is powerful but requires governance (who can associate VPCs, who can publish services).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Amazon VPC Lattice overlaps with several AWS networking and application connectivity options. The right choice depends on your goals: L7 routing vs private endpointing vs full mesh vs simple connectivity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Amazon VPC Lattice<\/strong><\/td>\n<td>Multi-VPC \/ multi-account service-to-service connectivity with centralized policy<\/td>\n<td>Managed service discovery\/connectivity, IAM policy, simplified onboarding, centralized visibility<\/td>\n<td>Clients may need SigV4 for IAM auth; feature set differs from full service meshes; region\/quotas<\/td>\n<td>You need a governed internal service network across VPCs\/accounts<\/td>\n<\/tr>\n<tr>\n<td><strong>VPC Peering<\/strong><\/td>\n<td>Simple VPC-to-VPC connectivity<\/td>\n<td>Simple, low overhead for small graphs<\/td>\n<td>Does not scale well to many VPCs; no service-level auth<\/td>\n<td>Few VPCs, basic routing needs<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Transit Gateway<\/strong><\/td>\n<td>Hub-and-spoke network connectivity at scale<\/td>\n<td>Scales to many VPCs, centralized routing<\/td>\n<td>Still network-level; no service-level discovery\/auth<\/td>\n<td>You need broad network connectivity beyond HTTP services<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS PrivateLink<\/strong><\/td>\n<td>Private, endpoint-based access to specific services<\/td>\n<td>Strong private access model; common for SaaS<\/td>\n<td>Per-service endpoint management; not L7 routing; can be heavy at scale<\/td>\n<td>You need private endpoints for specific services, often producer\/consumer<\/td>\n<\/tr>\n<tr>\n<td><strong>Elastic Load Balancing (ALB\/NLB)<\/strong><\/td>\n<td>Load balancing within a VPC (or across via routing)<\/td>\n<td>Mature L7\/L4 LB features<\/td>\n<td>Doesn\u2019t solve cross-VPC discovery\/governance by itself<\/td>\n<td>Single VPC or straightforward internal\/external load balancing<\/td>\n<\/tr>\n<tr>\n<td><strong>Amazon API Gateway (Private APIs)<\/strong><\/td>\n<td>Managed API front door (often north-south)<\/td>\n<td>Auth, throttling, API management<\/td>\n<td>Typically not used as east-west mesh; can add latency\/cost<\/td>\n<td>You need API management features for clients<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS App Mesh \/ Istio (service mesh)<\/strong><\/td>\n<td>Deep mesh features (mTLS, traffic shifting, telemetry)<\/td>\n<td>Rich service mesh controls<\/td>\n<td>Operational complexity; sidecars; cluster-centric<\/td>\n<td>You require full mesh features and can operate it<\/td>\n<\/tr>\n<tr>\n<td><strong>HashiCorp Consul (self-managed)<\/strong><\/td>\n<td>Service discovery and service mesh (multi-platform)<\/td>\n<td>Flexible, multi-cloud<\/td>\n<td>Operational overhead<\/td>\n<td>You want cloud-agnostic discovery\/mesh and can operate it<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Private Link (other cloud)<\/strong><\/td>\n<td>Private endpoint connectivity in Azure<\/td>\n<td>Strong endpoint model<\/td>\n<td>Not AWS<\/td>\n<td>You\u2019re in Azure and need private endpoints<\/td>\n<\/tr>\n<tr>\n<td><strong>GCP Traffic Director \/ Service Directory (other cloud)<\/strong><\/td>\n<td>Service discovery\/traffic mgmt in GCP<\/td>\n<td>GCP-native<\/td>\n<td>Not AWS<\/td>\n<td>You\u2019re in GCP<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Multi-account internal API governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A large enterprise runs 200+ microservices across 30+ AWS accounts. Teams use inconsistent internal DNS and ad-hoc VPC peering. Security wants centralized control over which services can call \u201ccustomer-data\u201d and \u201cpayments.\u201d<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Service networks per environment (<code>sn-prod<\/code>, <code>sn-nonprod<\/code>) and domain (<code>sn-prod-payments<\/code>, <code>sn-prod-customer<\/code>).<\/li>\n<li>Services published by domain owner accounts.<\/li>\n<li>Consumer VPCs associated via AWS RAM.<\/li>\n<li>IAM auth policies: only approved roles from specific accounts can invoke sensitive services.<\/li>\n<li>Central logging\/metrics and CloudTrail-based change monitoring.<\/li>\n<li><strong>Why Amazon VPC Lattice was chosen:<\/strong><\/li>\n<li>Scales better than a peering mesh for service-level consumption.<\/li>\n<li>Central governance via policies.<\/li>\n<li>Consistent consumption model across many teams.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced onboarding time for new consumers.<\/li>\n<li>Fewer networking tickets and reduced routing complexity.<\/li>\n<li>Stronger least-privilege enforcement and audit trails.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Fast microservices expansion across VPCs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup split workloads into separate VPCs for data, app, and security reasons. They need private connectivity for internal APIs without spending weeks on networking redesign.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>One service network for production.<\/li>\n<li>Each service published as a Lattice service.<\/li>\n<li>VPC associations for app VPC and data VPC.<\/li>\n<li>Access logs enabled only on sensitive services to control cost.<\/li>\n<li><strong>Why Amazon VPC Lattice was chosen:<\/strong><\/li>\n<li>Quick setup and simple mental model: publish \u2192 associate \u2192 call.<\/li>\n<li>Easy to expand as they add more VPCs and services.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster releases with fewer connectivity blockers.<\/li>\n<li>Cleaner separation of concerns and simpler service discovery.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Amazon VPC Lattice a service mesh?<\/strong><br\/>\nNot exactly. It provides managed service-to-service connectivity, discovery, policy, and observability, but it is not the same as a sidecar-based service mesh with full mTLS and deep traffic controls. Evaluate overlap with AWS App Mesh\/Istio for your requirements.<\/p>\n\n\n\n<p>2) <strong>Is Amazon VPC Lattice internet-facing?<\/strong><br\/>\nIt\u2019s primarily designed for private, internal connectivity from associated VPCs. For internet-facing traffic, typically use ALB\/NLB, API Gateway, or CloudFront.<\/p>\n\n\n\n<p>3) <strong>Do I need VPC peering or Transit Gateway if I use Lattice?<\/strong><br\/>\nOften, Lattice reduces the need for complex peering just to connect HTTP services. But you may still need peering\/TGW for non-HTTP connectivity, shared databases, admin access, hybrid networks, or other routing needs.<\/p>\n\n\n\n<p>4) <strong>How do clients discover services?<\/strong><br\/>\nClients use the <strong>DNS name<\/strong> provided by Amazon VPC Lattice for the service when their VPC is associated with the service network.<\/p>\n\n\n\n<p>5) <strong>Can I restrict which VPCs can call a service?<\/strong><br\/>\nYes. You can control which VPCs are associated with the service network, and you can enforce authorization using IAM auth policies.<\/p>\n\n\n\n<p>6) <strong>What happens if I enable IAM authentication?<\/strong><br\/>\nClients must sign requests using AWS SigV4. This improves security but requires compatible clients (SDKs or signing proxies).<\/p>\n\n\n\n<p>7) <strong>Does Lattice support HTTPS?<\/strong><br\/>\nYes, HTTPS is supported with certificates typically managed by ACM. Verify current listener and certificate requirements in official docs.<\/p>\n\n\n\n<p>8) <strong>Can I do path-based routing (e.g., \/v1 vs \/v2)?<\/strong><br\/>\nRouting rules commonly support request matching (such as paths\/headers). Exact rule conditions can vary\u2014verify in official docs for your region.<\/p>\n\n\n\n<p>9) <strong>What backends can I route to?<\/strong><br\/>\nCommon target types include instances, IP addresses, and Lambda functions, but supported types can vary by region\/features. Verify in official docs.<\/p>\n\n\n\n<p>10) <strong>How do I log requests?<\/strong><br\/>\nAmazon VPC Lattice provides access logs and metrics options. Configure logging for your service network\/services and send logs to supported destinations. Verify destination options in official docs.<\/p>\n\n\n\n<p>11) <strong>Is traffic encrypted by default?<\/strong><br\/>\nNot necessarily. Use HTTPS listeners for TLS in transit. For compliance, prefer encryption in transit even for internal traffic.<\/p>\n\n\n\n<p>12) <strong>How is Amazon VPC Lattice different from PrivateLink?<\/strong><br\/>\nPrivateLink is endpoint-based private connectivity to a service, commonly using NLB and endpoint services. Lattice is service-network-based, with service discovery, routing, and IAM policy at the service layer.<\/p>\n\n\n\n<p>13) <strong>Can multiple accounts share a service network?<\/strong><br\/>\nYes, using AWS Resource Access Manager (RAM). Governance is critical to prevent over-sharing.<\/p>\n\n\n\n<p>14) <strong>How do I avoid breaking clients during migration?<\/strong><br\/>\nUse DNS strategy and phased cutovers. Consider running old and new paths in parallel, validate health and latency, then switch clients gradually.<\/p>\n\n\n\n<p>15) <strong>What\u2019s the most common deployment mistake?<\/strong><br\/>\nMisconfigured security groups\u2014especially forgetting to allow inbound from the Lattice association security group to the target.<\/p>\n\n\n\n<p>16) <strong>How do I estimate cost accurately?<\/strong><br\/>\nUse the official pricing page and AWS Pricing Calculator. Model by number of services, associations, requests, and GB processed, plus logging volume.<\/p>\n\n\n\n<p>17) <strong>Does it work with Kubernetes (EKS)?<\/strong><br\/>\nYes in common architectures, but how you register targets depends on your ingress\/controller patterns. Verify current recommended patterns in AWS docs and reference architectures.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Amazon VPC Lattice<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official Documentation<\/td>\n<td>Amazon VPC Lattice User Guide \u2014 https:\/\/docs.aws.amazon.com\/vpc-lattice\/<\/td>\n<td>Authoritative source for concepts, components, quotas, and configuration steps<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>Amazon VPC Lattice Pricing \u2014 https:\/\/aws.amazon.com\/vpc\/lattice\/pricing\/<\/td>\n<td>Current pricing dimensions and regional pricing references<\/td>\n<\/tr>\n<tr>\n<td>Pricing Tool<\/td>\n<td>AWS Pricing Calculator \u2014 https:\/\/calculator.aws\/#\/<\/td>\n<td>Build scenario-based cost estimates<\/td>\n<\/tr>\n<tr>\n<td>Service Availability<\/td>\n<td>Regional product services list \u2014 https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/<\/td>\n<td>Confirm which regions support Amazon VPC Lattice<\/td>\n<\/tr>\n<tr>\n<td>Official Blog (search)<\/td>\n<td>AWS Blog \u2014 https:\/\/aws.amazon.com\/blogs\/aws\/<\/td>\n<td>Launch posts and feature updates (verify recency per post date)<\/td>\n<\/tr>\n<tr>\n<td>Architecture Guidance<\/td>\n<td>AWS Architecture Center \u2014 https:\/\/aws.amazon.com\/architecture\/<\/td>\n<td>Patterns for multi-account networking and governance (useful context for Lattice)<\/td>\n<\/tr>\n<tr>\n<td>Security Guidance<\/td>\n<td>AWS CloudTrail docs \u2014 https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/<\/td>\n<td>Audit control-plane changes to Lattice resources<\/td>\n<\/tr>\n<tr>\n<td>Identity Guidance<\/td>\n<td>IAM docs \u2014 https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/<\/td>\n<td>Understand IAM policies\/principals used by Lattice auth policies<\/td>\n<\/tr>\n<tr>\n<td>Certificates<\/td>\n<td>AWS Certificate Manager \u2014 https:\/\/docs.aws.amazon.com\/acm\/<\/td>\n<td>TLS certificates for HTTPS listeners<\/td>\n<\/tr>\n<tr>\n<td>Resource Sharing<\/td>\n<td>AWS RAM docs \u2014 https:\/\/docs.aws.amazon.com\/ram\/latest\/userguide\/<\/td>\n<td>Cross-account sharing model for Lattice resources<\/td>\n<\/tr>\n<tr>\n<td>Community Learning<\/td>\n<td>re:Post (AWS community Q&amp;A) \u2014 https:\/\/repost.aws\/<\/td>\n<td>Practical troubleshooting and \u201chow others did it\u201d (verify against official docs)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following training providers may offer courses or corporate training related to AWS Networking and content delivery topics and Amazon VPC Lattice. Confirm current course outlines on their websites.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, cloud engineers<\/td>\n<td>AWS networking fundamentals, platform engineering practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students, engineers, managers<\/td>\n<td>DevOps\/SCM foundations, cloud delivery practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops practitioners<\/td>\n<td>Operations, monitoring, cloud governance<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations, reliability engineers<\/td>\n<td>Reliability patterns, monitoring, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams adopting automation<\/td>\n<td>AIOps concepts, automation, monitoring analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites may list trainers or provide training services. Verify specific Amazon VPC Lattice coverage and credentials directly on each site.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content<\/td>\n<td>Engineers seeking hands-on guidance<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training<\/td>\n<td>Beginners to intermediate practitioners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps services\/training<\/td>\n<td>Teams needing practical coaching<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and enablement<\/td>\n<td>Ops teams and startups<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These organizations may provide consulting related to AWS networking, platform engineering, and DevOps practices. Verify exact service offerings and statements of work directly with each company.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>Architecture, migrations, operational readiness<\/td>\n<td>Multi-account AWS networking design; service connectivity strategy<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps &amp; cloud consulting\/training<\/td>\n<td>Platform enablement, CI\/CD, cloud operations<\/td>\n<td>Implement governance for multi-team AWS networking; operational dashboards<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting<\/td>\n<td>Cloud adoption, automation, SRE practices<\/td>\n<td>Standardize IaC and access control for internal platforms<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Amazon VPC Lattice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS fundamentals<\/strong>: accounts, regions, IAM basics<\/li>\n<li><strong>Amazon VPC<\/strong>: subnets, route tables, IGW\/NAT, security groups, NACLs<\/li>\n<li><strong>DNS basics<\/strong>: private DNS and resolution concepts<\/li>\n<li><strong>Load balancing basics<\/strong>: ALB\/NLB fundamentals<\/li>\n<li><strong>Observability<\/strong>: CloudWatch metrics\/logs, CloudTrail<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Amazon VPC Lattice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Multi-account governance<\/strong>: AWS Organizations, SCPs, AWS RAM sharing models<\/li>\n<li><strong>Advanced networking<\/strong>: Transit Gateway design, hybrid connectivity (VPN\/Direct Connect)<\/li>\n<li><strong>Zero trust patterns<\/strong>: strong identity-based auth, short-lived credentials, policy automation<\/li>\n<li><strong>Service mesh (optional)<\/strong>: App Mesh\/Istio if you need deeper traffic controls<\/li>\n<li><strong>IaC and GitOps<\/strong>: Terraform\/CloudFormation\/CDK and policy-as-code<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Network Engineer<\/li>\n<li>Solutions Architect<\/li>\n<li>Platform Engineer<\/li>\n<li>DevOps Engineer \/ SRE<\/li>\n<li>Security Engineer (cloud governance \/ service-to-service authorization)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>There is no \u201cAmazon VPC Lattice certification\u201d specifically. Relevant AWS certifications typically include:\n&#8211; AWS Certified Solutions Architect (Associate\/Professional)\n&#8211; AWS Certified Advanced Networking \u2013 Specialty\n&#8211; AWS Certified Security \u2013 Specialty<\/p>\n\n\n\n<p>(Confirm current certification availability and exam guides on AWS Training &amp; Certification.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a <strong>producer\/consumer<\/strong> multi-account demo with AWS RAM sharing and IAM auth.<\/li>\n<li>Create a <strong>multi-environment service network<\/strong> model (dev\/stage\/prod) with automated policies.<\/li>\n<li>Implement <strong>centralized access logging<\/strong> and build a CloudWatch dashboard for errors\/latency.<\/li>\n<li>Design a <strong>migration<\/strong> from internal ALB-based services to Lattice-backed services with minimal DNS changes.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Amazon VPC Lattice<\/strong>: AWS service for application networking across VPCs\/accounts with service discovery, routing, policy, and observability.<\/li>\n<li><strong>Service network<\/strong>: Logical boundary where services are published and VPCs associate as consumers\/producers.<\/li>\n<li><strong>VPC association<\/strong>: Connects a VPC to a service network so workloads can resolve and access services.<\/li>\n<li><strong>Service<\/strong>: A Lattice construct that exposes an application endpoint to consumers.<\/li>\n<li><strong>Listener<\/strong>: Defines protocol\/port for incoming requests to a service (e.g., HTTP :80).<\/li>\n<li><strong>Rule<\/strong>: A routing configuration that matches request attributes and forwards to a target group.<\/li>\n<li><strong>Target group<\/strong>: Group of backends (instances, IPs, Lambda\u2014verify supported types) receiving forwarded traffic.<\/li>\n<li><strong>Health check<\/strong>: Probes targets to determine if they should receive traffic.<\/li>\n<li><strong>Auth policy (resource policy)<\/strong>: IAM policy attached to a Lattice service or service network controlling who can invoke it.<\/li>\n<li><strong>SigV4<\/strong>: AWS Signature Version 4 signing process used for authenticated requests to AWS services.<\/li>\n<li><strong>ACM<\/strong>: AWS Certificate Manager, used for managing TLS certificates for HTTPS listeners.<\/li>\n<li><strong>AWS RAM<\/strong>: AWS Resource Access Manager, used for sharing resources across AWS accounts.<\/li>\n<li><strong>CloudTrail<\/strong>: Records AWS API calls for auditing and governance.<\/li>\n<li><strong>CloudWatch<\/strong>: Metrics\/logging platform for monitoring and alerting.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Amazon VPC Lattice (AWS) is a <strong>Networking and content delivery<\/strong> category service focused on <strong>private application networking<\/strong>: connecting services across VPCs and accounts with consistent <strong>service discovery<\/strong>, <strong>routing<\/strong>, <strong>authorization<\/strong>, and <strong>observability<\/strong>.<\/p>\n\n\n\n<p>It matters because it reduces the operational and security burden of scaling service-to-service communication in multi-VPC and multi-account environments. Instead of building and maintaining complex peering\/routing and ad-hoc DNS, you publish services into a governed service network and let consumers connect through a standardized model.<\/p>\n\n\n\n<p>Key points to remember:\n&#8211; <strong>Cost<\/strong> is driven by the number of Lattice resources, request volume, data processed, and logging.\n&#8211; <strong>Security<\/strong> improves significantly when you use IAM auth policies and TLS, but IAM auth requires <strong>SigV4-signed<\/strong> clients.\n&#8211; <strong>Operational success<\/strong> depends on quotas, logging strategy, and correct security group design (especially allowing targets from Lattice association SGs).<\/p>\n\n\n\n<p>Use Amazon VPC Lattice when you need a <strong>scalable, governed internal service network<\/strong> across VPCs\/accounts. Next step: read the official docs and map your organization\u2019s domains\/environments into a service network strategy, then automate it with IaC and policy guardrails.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking and content delivery<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,36],"tags":[],"class_list":["post-307","post","type-post","status-publish","format-standard","hentry","category-aws","category-networking-and-content-delivery"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=307"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/307\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}