{"id":306,"date":"2026-04-13T14:17:34","date_gmt":"2026-04-13T14:17:34","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-vpc-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-content-delivery\/"},"modified":"2026-04-13T14:17:34","modified_gmt":"2026-04-13T14:17:34","slug":"aws-amazon-vpc-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-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-content-delivery\/","title":{"rendered":"AWS Amazon VPC 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<h3 class=\"wp-block-heading\">What this service is<\/h3>\n\n\n\n<p>Amazon VPC (Amazon Virtual Private Cloud) is the AWS service that lets you create an isolated virtual network inside AWS. You control IP address ranges, subnets, routing, and network security\u2014similar to building a small data center network, but delivered as a managed cloud construct.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph simple explanation<\/h3>\n\n\n\n<p>If you want to run AWS resources (like Amazon EC2, Amazon RDS, or Amazon EKS) in a private network where you decide what is public, what is private, and how traffic flows, you use Amazon VPC. You create a VPC, split it into subnets, attach internet access if needed, and use security controls to limit who can talk to what.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph technical explanation<\/h3>\n\n\n\n<p>Technically, Amazon VPC is a regional, logically isolated network boundary in AWS where you define IPv4\/IPv6 CIDR blocks, create subnets mapped to Availability Zones (AZs), and manage traffic using route tables, gateways (Internet Gateway, NAT Gateway, egress-only Internet Gateway), and private connectivity constructs (VPC endpoints\/PrivateLink). You enforce network security with security groups (stateful) and network ACLs (stateless), and you can observe traffic with VPC Flow Logs and analyze connectivity with tools like Reachability Analyzer.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What problem it solves<\/h3>\n\n\n\n<p>Amazon VPC solves the problem of safely and predictably networking your cloud workloads:\n&#8211; Isolation between environments (dev\/test\/prod) and between applications\/tenants\n&#8211; Controlled inbound and outbound access to the internet\n&#8211; Private connectivity to AWS services without sending traffic over the public internet\n&#8211; Consistent network governance (routing, segmentation, logging) at scale<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Amazon VPC?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Amazon VPC provides a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. (See official docs: https:\/\/docs.aws.amazon.com\/vpc\/)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Amazon VPC enables you to:\n&#8211; Define IP address space (IPv4 and optional IPv6)\n&#8211; Create subnets per Availability Zone\n&#8211; Control traffic routing (route tables, gateways)\n&#8211; Control network security (security groups and network ACLs)\n&#8211; Connect networks (VPC peering, AWS Transit Gateway integration, VPN, AWS Direct Connect integration)\n&#8211; Access AWS services privately (VPC endpoints \/ AWS PrivateLink)\n&#8211; Monitor and troubleshoot networking (VPC Flow Logs, Reachability Analyzer)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<p>Common Amazon VPC building blocks include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC<\/strong>: Top-level network boundary within a region.<\/li>\n<li><strong>Subnets<\/strong>: Segments of the VPC CIDR, each placed in exactly one AZ.<\/li>\n<li><strong>Route tables<\/strong>: Control where traffic goes (local within VPC, internet, VPN, peering, endpoints, etc.).<\/li>\n<li><strong>Internet Gateway (IGW)<\/strong>: Enables internet connectivity for resources that have public IPs and proper routes.<\/li>\n<li><strong>NAT Gateway<\/strong>: Enables outbound internet access for private subnets (without inbound internet exposure).<\/li>\n<li><strong>Egress-only Internet Gateway<\/strong>: IPv6-only outbound internet gateway for private IPv6 resources.<\/li>\n<li><strong>Security groups<\/strong>: Stateful instance\/ENI-level firewall rules.<\/li>\n<li><strong>Network ACLs (NACLs)<\/strong>: Stateless subnet-level rules.<\/li>\n<li><strong>VPC endpoints<\/strong>: Private connectivity to AWS services (gateway endpoints and interface endpoints\/PrivateLink).<\/li>\n<li><strong>Elastic Network Interfaces (ENIs)<\/strong>: Virtual network cards attached to resources (not only EC2).<\/li>\n<li><strong>DHCP options \/ DNS settings<\/strong>: Control DNS resolution and hostname behavior.<\/li>\n<li><strong>Flow logs<\/strong>: Capture metadata about network traffic for auditing\/troubleshooting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<p>Amazon VPC is a foundational <strong>networking control-plane service<\/strong>. You define virtual networking constructs; workloads (EC2, RDS, EKS, etc.) attach to them.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional\/global\/zonal)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPCs are regional<\/strong>: A VPC exists within one AWS Region.<\/li>\n<li><strong>Subnets are zonal<\/strong>: Each subnet maps to exactly one Availability Zone.<\/li>\n<li><strong>Many VPC constructs are regional<\/strong> (e.g., route tables, IGWs), but are used to build multi-AZ architectures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>Amazon VPC is the default network boundary for most AWS compute and data services:\n&#8211; <strong>Amazon EC2<\/strong>, <strong>Amazon EKS<\/strong>, <strong>Amazon ECS<\/strong>, <strong>AWS Lambda (VPC-enabled)<\/strong> attach to subnets\/ENIs.\n&#8211; <strong>Amazon RDS<\/strong>, <strong>Amazon ElastiCache<\/strong>, <strong>Amazon OpenSearch Service<\/strong> typically live in private subnets.\n&#8211; <strong>AWS PrivateLink (VPC endpoints)<\/strong> enables private access to AWS services (and many partner\/SaaS services).\n&#8211; <strong>AWS Transit Gateway<\/strong> and <strong>AWS Direct Connect<\/strong> integrate to connect multiple VPCs and on-premises networks.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Amazon VPC?<\/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>Environment isolation<\/strong>: Separate business units, applications, or environments with clear boundaries.<\/li>\n<li><strong>Faster delivery with governance<\/strong>: Standardized VPC patterns enable teams to launch workloads safely and quickly.<\/li>\n<li><strong>Hybrid readiness<\/strong>: VPC designs can accommodate VPN\/Direct Connect connectivity to on-premises.<\/li>\n<li><strong>Vendor ecosystem<\/strong>: Many enterprise network\/security patterns are natively supported (firewalls, segmentation, logging).<\/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>Network segmentation<\/strong>: Use subnets and routing to separate public, private, and restricted tiers.<\/li>\n<li><strong>Controlled internet access<\/strong>: Enable\/disable inbound and outbound paths with gateways and routes.<\/li>\n<li><strong>Private service access<\/strong>: Use endpoints\/PrivateLink to keep traffic off the public internet.<\/li>\n<li><strong>Scalable connectivity<\/strong>: Expand address space and connect multiple VPCs using hub-and-spoke patterns.<\/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>Repeatable architectures<\/strong>: Standard VPC modules (Terraform\/CloudFormation) reduce drift.<\/li>\n<li><strong>Observability<\/strong>: Flow logs and AWS CloudTrail provide auditability; Reachability Analyzer helps troubleshooting.<\/li>\n<li><strong>Change management<\/strong>: Central network teams can manage shared VPCs and enforce policies.<\/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>Least-privilege networking<\/strong>: Security groups and NACLs can restrict traffic to only what is needed.<\/li>\n<li><strong>Reduced exposure<\/strong>: Keep databases and internal services in private subnets with no direct internet route.<\/li>\n<li><strong>Audit trails<\/strong>: Track API changes via CloudTrail; record traffic metadata using Flow Logs.<\/li>\n<li><strong>Regulatory alignment<\/strong>: Supports segmentation and logging patterns common in compliance frameworks (verify exact compliance requirements with your auditor and AWS Artifact 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>Multi-AZ design<\/strong>: Spread workloads across AZs for resilience and throughput.<\/li>\n<li><strong>High-bandwidth AWS backbone<\/strong>: Intra-region traffic can stay on AWS\u2019s private network; PrivateLink can avoid internet paths.<\/li>\n<li><strong>Elastic growth<\/strong>: Add subnets and routing as applications grow.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Amazon VPC when you need:\n&#8211; Any non-trivial AWS workload with network segmentation\/security needs\n&#8211; Private subnets for databases or internal services\n&#8211; Hybrid connectivity (VPN\/Direct Connect)\n&#8211; Centralized governance over routing and access<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When they should not choose it (or when to keep it minimal)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you are using <strong>AWS services that do not require VPC<\/strong> (some managed services are accessed over public endpoints and can be secured with IAM and service-level controls). Still, most production environments end up using VPC.<\/li>\n<li>If your use case is purely edge delivery, consider <strong>Amazon CloudFront<\/strong> (same \u201cNetworking and content delivery\u201d category family) and keep VPC only for origins\/workloads.<\/li>\n<li>If you\u2019re over-segmenting too early: overly complex VPC designs can slow delivery and increase operational risk.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Amazon VPC used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Amazon VPC is used broadly across:\n&#8211; Financial services (segmentation, audit, hybrid connectivity)\n&#8211; Healthcare\/life sciences (access control, logging, data residency patterns)\n&#8211; SaaS and internet companies (multi-tenant patterns, private service connectivity)\n&#8211; Media\/gaming (multi-AZ throughput, controlled ingress\/egress)\n&#8211; Manufacturing\/IoT (hybrid connectivity to plants and devices)<\/p>\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 standard \u201clanding zones\u201d<\/li>\n<li>Cloud\/network engineering teams owning routing, IPAM, and connectivity<\/li>\n<li>DevOps\/SRE teams deploying services into standardized VPCs<\/li>\n<li>Security teams defining segmentation, inspection, and logging requirements<\/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>2-tier\/3-tier web applications<\/li>\n<li>Microservices on EKS\/ECS<\/li>\n<li>Databases (RDS\/Aurora) in private subnets<\/li>\n<li>Batch and analytics workers with controlled egress<\/li>\n<li>Internal tools reachable only via VPN\/SSO\/bastion\/zero-trust access<\/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>Public\/private subnet architectures<\/li>\n<li>Hub-and-spoke (Transit Gateway)<\/li>\n<li>Shared services VPC (central DNS, directory services, CI\/CD)<\/li>\n<li>Multi-account landing zone architectures (AWS Organizations + RAM sharing)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single account: small teams, simpler governance<\/li>\n<li>Multi-account: enterprise governance, blast-radius reduction, delegated admin<\/li>\n<li>Hybrid: on-premises core network with AWS VPC extensions<\/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>Production<\/strong>: multi-AZ subnets, strict routing, centralized logging, least-privilege security groups, private endpoints, egress control, change control.<\/li>\n<li><strong>Dev\/test<\/strong>: smaller CIDRs, fewer subnets\/AZs, simplified routing; still benefit from templates and guardrails to match production patterns.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Amazon VPC is the central enabler.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Public web app with private database<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Expose a web tier to users but keep the database unreachable from the internet.<\/li>\n<li><strong>Why Amazon VPC fits<\/strong>: Public subnets for load balancers\/web; private subnets for DB; security groups restrict DB access.<\/li>\n<li><strong>Example<\/strong>: ALB in public subnets \u2192 EC2\/ECS in private subnets \u2192 RDS in isolated private subnets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Microservices platform on Amazon EKS<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Run many services with controlled east-west traffic and safe egress.<\/li>\n<li><strong>Why it fits<\/strong>: Subnets per AZ, security groups, endpoints, optional network firewall insertion patterns.<\/li>\n<li><strong>Example<\/strong>: EKS nodes in private subnets, NAT for controlled outbound, VPC endpoints for ECR\/S3\/CloudWatch.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Hybrid connectivity to on-premises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Connect AWS workloads to corporate data centers.<\/li>\n<li><strong>Why it fits<\/strong>: Integrates with Site-to-Site VPN and Direct Connect; route propagation and segmentation.<\/li>\n<li><strong>Example<\/strong>: On-prem \u2192 VPN\/Direct Connect \u2192 Transit Gateway \u2192 multiple VPCs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Multi-account shared network model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple teams need VPCs but networking must be centrally governed.<\/li>\n<li><strong>Why it fits<\/strong>: VPC sharing via AWS Resource Access Manager (RAM) and centralized inspection.<\/li>\n<li><strong>Example<\/strong>: Central network account shares subnets; workload accounts deploy EC2\/EKS into shared subnets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Private access to AWS services (no public internet)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Prevent workloads from using the public internet while still accessing AWS APIs.<\/li>\n<li><strong>Why it fits<\/strong>: VPC endpoints\/PrivateLink; gateway endpoints for S3\/DynamoDB; interface endpoints for many AWS services.<\/li>\n<li><strong>Example<\/strong>: Private subnets without IGW\/NAT; interface endpoints for SSM\/CloudWatch; gateway endpoint for S3.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Multi-tier segmentation for compliance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Separate regulated data systems from general application tiers.<\/li>\n<li><strong>Why it fits<\/strong>: Layered subnets, route control, NACLs, security groups, centralized logging and inspection.<\/li>\n<li><strong>Example<\/strong>: \u201cRestricted\u201d subnets with no egress except to specific inspection appliances\/endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Controlled outbound (egress) with auditing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Applications must reach the internet only to approved destinations and all egress must be logged.<\/li>\n<li><strong>Why it fits<\/strong>: NAT Gateway + routing + security tools; Flow Logs for metadata.<\/li>\n<li><strong>Example<\/strong>: Private subnets route 0.0.0.0\/0 to NAT; combine with DNS filtering\/proxy or firewall (verify exact product choices per requirement).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) SaaS private connectivity using PrivateLink<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Connect to a SaaS provider without internet exposure.<\/li>\n<li><strong>Why it fits<\/strong>: Interface endpoints support private connectivity to endpoint services.<\/li>\n<li><strong>Example<\/strong>: Consumer VPC creates an interface endpoint to a partner\u2019s PrivateLink endpoint service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Blue\/green network cutovers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Migrate applications with minimal downtime.<\/li>\n<li><strong>Why it fits<\/strong>: Parallel subnets\/routes and controlled switching (often with load balancers and DNS).<\/li>\n<li><strong>Example<\/strong>: Build new private subnets and route tables; gradually shift traffic via ALB target groups and DNS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Centralized DNS and shared services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Many VPCs need consistent DNS resolution for internal domains.<\/li>\n<li><strong>Why it fits<\/strong>: Integrates with Route 53 Resolver endpoints and shared architectures.<\/li>\n<li><strong>Example<\/strong>: Shared services VPC hosts Resolver endpoints; other VPCs forward queries to on-prem DNS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) IP address management at scale (IPAM)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Avoid CIDR conflicts and manage IP allocations across multiple regions\/accounts.<\/li>\n<li><strong>Why it fits<\/strong>: VPC IP Address Manager (IPAM) provides governance, planning, and visibility.<\/li>\n<li><strong>Example<\/strong>: Enterprise IPAM pools enforce standardized CIDR allocation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Security inspection VPC with traffic steering<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Insert inspection (firewall\/IDS) into network paths.<\/li>\n<li><strong>Why it fits<\/strong>: Routing patterns with Transit Gateway and appliance subnets enable inspection architectures.<\/li>\n<li><strong>Example<\/strong>: Spoke VPCs route egress to Transit Gateway \u2192 inspection VPC \u2192 NAT\/IGW.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">VPC and CIDR management (IPv4\/IPv6)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you define IPv4 address ranges (CIDR blocks) and optionally IPv6.<\/li>\n<li><strong>Why it matters<\/strong>: Your CIDR plan drives scalability, segmentation, and hybrid compatibility.<\/li>\n<li><strong>Practical benefit<\/strong>: Predictable IP allocation for subnets and workloads.<\/li>\n<li><strong>Caveats<\/strong>: CIDR sizing mistakes are hard to unwind later. Plan for growth and mergers. Verify current CIDR association limits in <strong>Service Quotas<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Subnets across Availability Zones<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Divides your VPC into subnets, each mapped to a single AZ.<\/li>\n<li><strong>Why it matters<\/strong>: AZ mapping is fundamental to high availability.<\/li>\n<li><strong>Practical benefit<\/strong>: Place redundant instances across AZs while keeping routing\/security consistent.<\/li>\n<li><strong>Caveats<\/strong>: Subnets do not span AZs. Design per-AZ subnet pairs (public\/private) for resilient architectures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Route tables and routing targets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controls where traffic goes: within VPC (\u201clocal\u201d), to IGW, NAT, Transit Gateway, peering, endpoints, etc.<\/li>\n<li><strong>Why it matters<\/strong>: Routing defines reachability and segmentation.<\/li>\n<li><strong>Practical benefit<\/strong>: Build patterns like \u201cprivate subnets with outbound-only internet\u201d.<\/li>\n<li><strong>Caveats<\/strong>: Overlapping routes and incorrect associations are a common cause of outages. Changes propagate quickly\u2014use change control.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Internet Gateway (IGW)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables internet connectivity for resources in public subnets (with public IPs and correct routes).<\/li>\n<li><strong>Why it matters<\/strong>: It\u2019s the simplest way to support public inbound\/outbound.<\/li>\n<li><strong>Practical benefit<\/strong>: Public-facing ALBs, bastions (if used), and some workloads need it.<\/li>\n<li><strong>Caveats<\/strong>: Attaching an IGW doesn\u2019t automatically make things public. You still need routes + public IP + security rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">NAT Gateway<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows instances in private subnets to initiate outbound internet connections without being reachable from the internet.<\/li>\n<li><strong>Why it matters<\/strong>: Many workloads need patching, package downloads, or external API calls without inbound exposure.<\/li>\n<li><strong>Practical benefit<\/strong>: Keeps private subnets private while enabling outbound.<\/li>\n<li><strong>Caveats<\/strong>: NAT Gateway typically has <strong>hourly and per-GB processing<\/strong> charges (region-dependent). Also requires an Elastic IP and is AZ-scoped; for HA, use one per AZ and route accordingly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Egress-only Internet Gateway (IPv6)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides outbound-only internet access for IPv6 resources.<\/li>\n<li><strong>Why it matters<\/strong>: IPv6 addresses are globally routable; you need a way to prevent inbound while allowing outbound.<\/li>\n<li><strong>Practical benefit<\/strong>: IPv6 adoption with controlled exposure.<\/li>\n<li><strong>Caveats<\/strong>: IPv6 security posture needs careful security group\/NACL design; verify current IPv6 feature behavior in your region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security groups (stateful)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Firewall rules at the ENI\/resource level; return traffic is automatically allowed.<\/li>\n<li><strong>Why it matters<\/strong>: Primary control for workload-to-workload and inbound access.<\/li>\n<li><strong>Practical benefit<\/strong>: Strong segmentation without complex subnet ACLs.<\/li>\n<li><strong>Caveats<\/strong>: Misconfigured security groups are a top cause of outages. Keep rules minimal; use referencing (SG-to-SG) where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network ACLs (stateless)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Subnet-level allow\/deny rules; you must explicitly allow return traffic.<\/li>\n<li><strong>Why it matters<\/strong>: Adds an extra layer of subnet boundary control.<\/li>\n<li><strong>Practical benefit<\/strong>: Useful for coarse-grained controls (e.g., block known-bad ranges).<\/li>\n<li><strong>Caveats<\/strong>: Operationally tricky at scale; easy to break return paths. Many teams keep NACLs simple and rely on SGs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">VPC endpoints (AWS PrivateLink and gateway endpoints)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides private connectivity from your VPC to AWS services:<\/li>\n<li><strong>Gateway endpoints<\/strong>: route-table targets for supported services (notably S3 and DynamoDB).<\/li>\n<li><strong>Interface endpoints (PrivateLink)<\/strong>: ENIs in your subnets that connect privately to a service.<\/li>\n<li><strong>Why it matters<\/strong>: Reduce internet exposure and simplify compliance.<\/li>\n<li><strong>Practical benefit<\/strong>: Private subnets can access AWS APIs without NAT\/IGW.<\/li>\n<li><strong>Caveats<\/strong>: Interface endpoints have hourly and per-GB charges (region-dependent). Also consider DNS, endpoint policies, and security groups.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">VPC peering<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Private routing connectivity between two VPCs.<\/li>\n<li><strong>Why it matters<\/strong>: Simple point-to-point connectivity for small-scale network graphs.<\/li>\n<li><strong>Practical benefit<\/strong>: Low operational overhead for a few VPCs.<\/li>\n<li><strong>Caveats<\/strong>: No transitive routing. For many VPCs, Transit Gateway is usually more scalable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">DHCP options and VPC DNS settings<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controls DNS resolution\/hostnames and DHCP-provided options.<\/li>\n<li><strong>Why it matters<\/strong>: DNS is foundational to application reliability.<\/li>\n<li><strong>Practical benefit<\/strong>: Consistent domain suffix and resolver behavior.<\/li>\n<li><strong>Caveats<\/strong>: DNS settings impact many services. Test changes carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Elastic Network Interfaces (ENIs) and secondary IPs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: ENIs attach networking to instances and some managed services; support multiple IPs.<\/li>\n<li><strong>Why it matters<\/strong>: Enables advanced networking patterns (multiple NICs, appliances, IP failover designs).<\/li>\n<li><strong>Practical benefit<\/strong>: Flexible architecture for inspection or multi-homed workloads.<\/li>\n<li><strong>Caveats<\/strong>: ENI limits depend on instance type; check quotas\/instance docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">VPC Flow Logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Captures traffic metadata (source\/destination, ports, action, etc.) for ENIs, subnets, or VPCs.<\/li>\n<li><strong>Why it matters<\/strong>: Essential for troubleshooting and audit trails.<\/li>\n<li><strong>Practical benefit<\/strong>: Detect unexpected traffic, confirm security group behavior, support incident response.<\/li>\n<li><strong>Caveats<\/strong>: Flow logs are metadata, not packet payloads. Costs depend on destination (CloudWatch Logs\/S3\/Kinesis) and volume.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Traffic Mirroring<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Mirrors network traffic from ENIs to security appliances for deep inspection.<\/li>\n<li><strong>Why it matters<\/strong>: Useful for IDS\/IPS and advanced threat detection.<\/li>\n<li><strong>Practical benefit<\/strong>: Packet-level visibility for selected traffic.<\/li>\n<li><strong>Caveats<\/strong>: Additional cost and operational complexity; ensure privacy\/compliance approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reachability Analyzer (connectivity troubleshooting)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Analyzes network paths between source and destination and explains why traffic is or isn\u2019t reachable.<\/li>\n<li><strong>Why it matters<\/strong>: Faster troubleshooting than manual route\/SG\/NACL inspection.<\/li>\n<li><strong>Practical benefit<\/strong>: Pinpoints misconfigured routes\/security groups.<\/li>\n<li><strong>Caveats<\/strong>: Scope and pricing\/availability can evolve\u2014verify current details in official docs for your region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">VPC IP Address Manager (IPAM)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Helps plan, allocate, and track IP space across accounts\/regions.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents CIDR overlap and enables structured growth.<\/li>\n<li><strong>Practical benefit<\/strong>: Governance for large enterprises and multi-region deployments.<\/li>\n<li><strong>Caveats<\/strong>: Typically has its own pricing. Adopt when IP sprawl becomes a real risk.<\/li>\n<\/ul>\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\">Service architecture at a high level<\/h3>\n\n\n\n<p>Amazon VPC is primarily a <strong>control plane<\/strong> where you define:\n&#8211; Address space (CIDR)\n&#8211; Segmentation (subnets)\n&#8211; Reachability (route tables and gateways)\n&#8211; Security policy (security groups and NACLs)\n&#8211; Observability (flow logs)<\/p>\n\n\n\n<p>Your workloads attach to the VPC through <strong>ENIs<\/strong>. Data-plane traffic flows according to routes and security rules. Many managed AWS services create ENIs in your subnets (for example, RDS in a DB subnet group, interface endpoints, and some VPC-enabled Lambda functions).<\/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 use the AWS Management Console, AWS CLI, SDKs, CloudFormation, or Terraform to create and modify VPC resources. These API calls are logged in <strong>AWS CloudTrail<\/strong>.<\/li>\n<li><strong>Data plane<\/strong>: Packets flow between ENIs according to:\n  1. Local VPC routing\n  2. Subnet route table rules (including gateway\/endpoint targets)\n  3. Security group and NACL evaluation\n  4. Gateway\/attachment behavior (IGW, NAT, peering, Transit Gateway, VPN)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Amazon EC2<\/strong>: Instances and ENIs live in subnets.\n&#8211; <strong>Elastic Load Balancing (ALB\/NLB)<\/strong>: Load balancers are deployed in subnets (typically public for internet-facing).\n&#8211; <strong>Amazon RDS\/Aurora<\/strong>: Database subnet groups use private subnets; access controlled via security groups.\n&#8211; <strong>Amazon EKS\/ECS<\/strong>: Nodes and tasks\/pods use VPC networking.\n&#8211; <strong>AWS Transit Gateway<\/strong>: Central routing hub for many VPCs and VPN\/DX attachments.\n&#8211; <strong>VPC endpoints\/PrivateLink<\/strong>: Private access to AWS services and third parties.\n&#8211; <strong>Amazon Route 53 Resolver<\/strong>: Inbound\/outbound endpoints for hybrid DNS.\n&#8211; <strong>AWS Network Firewall<\/strong> (separate service) often used with VPC routing for inspection patterns.\n&#8211; <strong>Amazon CloudWatch<\/strong> \/ <strong>CloudWatch Logs<\/strong>: Flow logs and operational telemetry.\n&#8211; <strong>AWS Config<\/strong>: Configuration governance and drift detection.\n&#8211; <strong>AWS Organizations \/ Control Tower<\/strong>: Multi-account governance (not required, but common in enterprises).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Amazon VPC itself is a base AWS service, but practical deployments often depend on:\n&#8211; IAM (permissions, instance roles)\n&#8211; CloudTrail (audit)\n&#8211; CloudWatch Logs\/S3 (for flow logs storage)\n&#8211; EC2 (to test connectivity)\n&#8211; Optional: Transit Gateway, Route 53, Network Firewall, Direct Connect, VPN<\/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>API access<\/strong>: IAM policies govern who can create\/modify VPC resources (<code>ec2:*<\/code> actions for VPC-related APIs).<\/li>\n<li><strong>Network access<\/strong>: Enforced at multiple layers:<\/li>\n<li>Security groups (stateful)<\/li>\n<li>NACLs (stateless)<\/li>\n<li>Route tables (reachability)<\/li>\n<li>Optional centralized inspection (Network Firewall, appliances)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (how packets are decided)<\/h3>\n\n\n\n<p>At a high level:\n1. A resource sends traffic from its ENI.\n2. Security group egress rules must permit it.\n3. Subnet route table determines next hop:\n   &#8211; Another subnet (local)\n   &#8211; IGW (internet)\n   &#8211; NAT Gateway (private outbound)\n   &#8211; VPC endpoint (private AWS service access)\n   &#8211; Transit Gateway \/ peering \/ VPN attachment\n4. NACL rules are evaluated at subnet boundary (inbound\/outbound).\n5. Return traffic is allowed automatically for security groups but must be explicitly allowed for NACLs.<\/p>\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><strong>CloudTrail<\/strong>: Logs VPC API changes (who changed routes, SGs, etc.).<\/li>\n<li><strong>VPC Flow Logs<\/strong>: Logs traffic metadata to CloudWatch Logs\/S3\/Kinesis.<\/li>\n<li><strong>Reachability Analyzer<\/strong>: Helps confirm why a path is reachable\/unreachable.<\/li>\n<li><strong>AWS Config<\/strong>: Track configuration changes and enforce rules (e.g., \u201cno 0.0.0.0\/0 to SSH\u201d).<\/li>\n<li><strong>Tagging<\/strong>: Essential for cost allocation and ops ownership (VPC, subnets, route tables, gateways, endpoints).<\/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 TB\n  Internet((Internet))\n  IGW[Internet Gateway]\n  VPC[VPC (Region)]\n  PubSubnet[Public Subnet (AZ-a)]\n  EC2Web[EC2 Instance]\n  RT[Route Table: 0.0.0.0\/0 -&gt; IGW]\n  SG[Security Group]\n\n  Internet --- IGW --- VPC\n  VPC --- PubSubnet --- EC2Web\n  PubSubnet --- RT\n  EC2Web --- SG\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 LR\n  Users((Users))\n  Internet((Internet))\n  ALB[ALB (Public)]\n  VPC[VPC (Region)]\n  PubA[Public Subnet AZ-a]\n  PubB[Public Subnet AZ-b]\n  PrivA[Private App Subnet AZ-a]\n  PrivB[Private App Subnet AZ-b]\n  DataA[Private DB Subnet AZ-a]\n  DataB[Private DB Subnet AZ-b]\n  NATa[NAT GW AZ-a]\n  NATb[NAT GW AZ-b]\n  IGW[Internet Gateway]\n  AppA[ECS\/EKS\/EC2 App]\n  AppB[ECS\/EKS\/EC2 App]\n  RDS[(RDS\/Aurora)]\n  S3[S3]\n  VPCEndpoint[Gateway Endpoint (S3)]\n  FlowLogs[VPC Flow Logs -&gt; CloudWatch\/S3]\n\n  Users --&gt; Internet --&gt; ALB\n  Internet --&gt; IGW --&gt; VPC\n  VPC --- PubA --- ALB\n  VPC --- PubB --- ALB\n\n  PubA --&gt; NATa --&gt; IGW\n  PubB --&gt; NATb --&gt; IGW\n\n  ALB --&gt; AppA\n  ALB --&gt; AppB\n  AppA --&gt; RDS\n  AppB --&gt; RDS\n\n  AppA --&gt; VPCEndpoint --&gt; S3\n  AppB --&gt; VPCEndpoint --&gt; S3\n\n  VPC --&gt; FlowLogs\n  VPC --- PrivA --- AppA\n  VPC --- PrivB --- AppB\n  VPC --- DataA --- RDS\n  VPC --- DataB --- RDS\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>AWS account<\/strong> with billing enabled.<\/li>\n<li>Ability to create IAM roles and networking resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>Minimum recommended permissions for the lab:\n&#8211; VPC and EC2: <code>ec2:CreateVpc<\/code>, <code>ec2:CreateSubnet<\/code>, <code>ec2:CreateRouteTable<\/code>, <code>ec2:CreateRoute<\/code>, <code>ec2:CreateInternetGateway<\/code>, <code>ec2:AttachInternetGateway<\/code>, <code>ec2:RunInstances<\/code>, <code>ec2:CreateSecurityGroup<\/code>, <code>ec2:AuthorizeSecurityGroupEgress<\/code>, etc.\n&#8211; IAM for instance role: <code>iam:CreateRole<\/code>, <code>iam:AttachRolePolicy<\/code>, <code>iam:CreateInstanceProfile<\/code>, <code>iam:AddRoleToInstanceProfile<\/code>\n&#8211; Flow logs to CloudWatch: permissions to create log groups and roles\/policies, plus <code>ec2:CreateFlowLogs<\/code><\/p>\n\n\n\n<p>If you are in an enterprise environment, these may be controlled by platform teams. Use least privilege and follow your organization\u2019s change process.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon VPC itself has no \u201cVPC creation\u201d charge, but the lab uses:<\/li>\n<li>Amazon EC2 instance (compute)<\/li>\n<li>Potential CloudWatch Logs ingestion\/storage for flow logs<\/li>\n<li>If you enable NAT gateways or interface endpoints, costs can increase quickly (we keep them optional).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<p>Choose one:\n&#8211; <strong>AWS Management Console<\/strong> (web browser), or\n&#8211; <strong>AWS CLI v2<\/strong> (recommended for repeatability): https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/p>\n\n\n\n<p>Optional but useful:\n&#8211; AWS CloudShell (browser-based shell with AWS CLI preinstalled)\n&#8211; SSH client (not required if using AWS Systems Manager Session Manager)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<p>Amazon VPC is available in all standard AWS regions. Specific features (or quotas) can vary by region\u2014verify in official docs if you are using newer features (IPAM, certain endpoints, etc.).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Amazon VPC has multiple quotas (VPCs per region, subnets per VPC, route tables, routes, security group rules, etc.).\n&#8211; Check <strong>Service Quotas<\/strong> in the AWS console for authoritative values in your account\/region:\n  &#8211; Service Quotas \u2192 Amazon Virtual Private Cloud (VPC)\n&#8211; Some quotas can be increased by request.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For the hands-on lab we will use:\n&#8211; Amazon EC2\n&#8211; AWS IAM\n&#8211; Amazon CloudWatch Logs\n&#8211; AWS Systems Manager (Session Manager) for instance access (uses SSM agent and IAM role)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (accurate, usage-based)<\/h3>\n\n\n\n<p>Amazon VPC has a mixed cost model:\n&#8211; Many VPC constructs are <strong>free to create<\/strong> (VPC, subnets, route tables, security groups, NACLs, IGW attachment).\n&#8211; Costs typically come from <strong>data processing<\/strong>, <strong>hourly-managed networking components<\/strong>, and <strong>logging<\/strong>.<\/p>\n\n\n\n<p>Always confirm in the official pricing pages because pricing is region-dependent and changes over time.<\/p>\n\n\n\n<p>Official pricing starting points:\n&#8211; Amazon VPC pricing: https:\/\/aws.amazon.com\/vpc\/pricing\/\n&#8211; Data transfer pricing: https:\/\/aws.amazon.com\/ec2\/pricing\/on-demand\/#Data_Transfer\n&#8211; AWS Pricing Calculator: https:\/\/calculator.aws\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key pricing dimensions<\/h3>\n\n\n\n<p>Common cost dimensions in VPC-centered architectures:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>NAT Gateway<\/strong>\n   &#8211; Typically charged per hour and per GB processed.\n   &#8211; Often one NAT Gateway per AZ for high availability.<\/p>\n<\/li>\n<li>\n<p><strong>VPC interface endpoints (PrivateLink)<\/strong>\n   &#8211; Typically charged per endpoint-hour and per GB processed.\n   &#8211; You may need multiple endpoints across AZs\/subnets for resilience.<\/p>\n<\/li>\n<li>\n<p><strong>VPC gateway endpoints<\/strong>\n   &#8211; Commonly used for S3\/DynamoDB and generally do not have the same hourly pricing model as interface endpoints; verify current pricing and any data processing considerations in official docs.<\/p>\n<\/li>\n<li>\n<p><strong>Site-to-Site VPN<\/strong>\n   &#8211; Typically charged per VPN connection-hour and data transfer.<\/p>\n<\/li>\n<li>\n<p><strong>Traffic Mirroring<\/strong>\n   &#8211; Charges can apply (data processing\/collection). Verify current rates.<\/p>\n<\/li>\n<li>\n<p><strong>VPC Flow Logs<\/strong>\n   &#8211; The cost depends mainly on the destination:<\/p>\n<ul>\n<li>CloudWatch Logs ingestion + storage + queries (Logs Insights)<\/li>\n<li>S3 storage and retrieval<\/li>\n<li>Kinesis Data Firehose ingestion\/delivery<\/li>\n<li>High-traffic environments can generate large log volumes.<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Inter-AZ and inter-region data transfer<\/strong>\n   &#8211; Architectures that spread traffic across AZs can incur inter-AZ data charges (depending on traffic direction and service).\n   &#8211; Inter-region traffic is typically charged and can be significant.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Free Tier generally applies to certain EC2 usage and other services, not \u201cAmazon VPC\u201d itself.<\/li>\n<li>Some labs can fit in Free Tier, but <strong>networking add-ons (NAT, endpoints, logs)<\/strong> are often not fully covered. Verify Free Tier details for your account: https:\/\/aws.amazon.com\/free\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what usually surprises teams)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NAT Gateway per-GB processing<\/strong>: frequent large downloads (patching, container pulls) can be costly.<\/li>\n<li><strong>Interface endpoints sprawl<\/strong>: many endpoints across many VPCs\/AZs becomes an hourly bill line item.<\/li>\n<li><strong>CloudWatch Logs ingestion<\/strong>: flow logs at scale can be expensive without sampling\/filters or S3-based pipelines.<\/li>\n<li><strong>Cross-AZ traffic<\/strong>: chatty microservices or misbalanced load can create cross-AZ transfer costs.<\/li>\n<li><strong>Egress to the internet<\/strong>: outbound traffic charges add up for media-heavy apps or data exports.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (practical tactics)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize NAT usage:<\/li>\n<li>Prefer <strong>VPC endpoints<\/strong> for AWS services (S3, DynamoDB, ECR, CloudWatch, SSM endpoints as needed).<\/li>\n<li>Keep workloads that need heavy internet egress in public subnets only if security posture allows (often it doesn\u2019t).<\/li>\n<li>Control flow logs:<\/li>\n<li>Enable where needed (critical subnets\/ENIs), not everywhere by default.<\/li>\n<li>Consider S3 for long-term retention and use lifecycle policies.<\/li>\n<li>Design for AZ locality:<\/li>\n<li>Keep dependent tiers in the same AZ when possible and safe (while maintaining HA).<\/li>\n<li>Consolidate endpoints:<\/li>\n<li>In multi-account environments, consider shared endpoint patterns (when supported) and standardized endpoint sets.<\/li>\n<li>Tag everything:<\/li>\n<li>Use cost allocation tags for NAT, endpoints, flow logs, and gateways.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A minimal learning setup can be low cost if you:\n&#8211; Create a VPC + subnet + IGW (no direct cost)\n&#8211; Run a single small EC2 instance briefly (compute cost)\n&#8211; Enable limited VPC Flow Logs for a short time (CloudWatch Logs ingestion\/storage)<\/p>\n\n\n\n<p>Because exact prices vary by region and change over time, use the <strong>AWS Pricing Calculator<\/strong> for your region and expected runtime.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, typical recurring networking costs often include:\n&#8211; NAT Gateways (per AZ) + data processing\n&#8211; Interface endpoints (multiple services \u00d7 AZs)\n&#8211; Flow logs at VPC\/subnet\/ENI scope + retention\n&#8211; VPN\/Direct Connect port charges (for hybrid)\n&#8211; Inter-AZ data transfer due to load balancing or service-to-service traffic<\/p>\n\n\n\n<p>For a production estimate, model:\n&#8211; Number of AZs\n&#8211; Expected egress GB\/month (internet, endpoints, NAT)\n&#8211; Expected log GB\/day\n&#8211; Endpoint count per region\n&#8211; Hybrid bandwidth and uptime<\/p>\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>Build a basic Amazon VPC with a public subnet and internet routing, launch a small EC2 instance, connect securely using AWS Systems Manager Session Manager (no inbound SSH), enable VPC Flow Logs to CloudWatch Logs, generate traffic, and validate that logs are captured.<\/p>\n\n\n\n<p>This lab teaches:\n&#8211; VPC + subnet + route table + Internet Gateway fundamentals\n&#8211; Security group basics (no inbound required for SSM)\n&#8211; VPC Flow Logs for visibility\n&#8211; Safe cleanup to avoid ongoing charges<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will create:\n&#8211; 1 VPC (IPv4 CIDR)\n&#8211; 1 public subnet in one AZ\n&#8211; 1 Internet Gateway and route table association\n&#8211; 1 security group (minimal)\n&#8211; 1 EC2 instance with an IAM role for SSM\n&#8211; 1 CloudWatch log group and VPC Flow Log<\/p>\n\n\n\n<p>You will verify:\n&#8211; Instance has internet egress (via IGW route and public IP)\n&#8211; You can connect through Session Manager\n&#8211; Flow logs show traffic records<\/p>\n\n\n\n<blockquote>\n<p>Cost note: This lab avoids NAT Gateway and interface endpoints to keep costs low. EC2 and CloudWatch Logs may still incur charges.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose region, set naming, and confirm identity<\/h3>\n\n\n\n<p>If using AWS CLI (recommended), open CloudShell or your terminal and run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws sts get-caller-identity\naws configure get region\n<\/code><\/pre>\n\n\n\n<p>Set a region explicitly if needed:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AWS_REGION=\"us-east-1\"   # change to your preferred region\n<\/code><\/pre>\n\n\n\n<p>Define a naming prefix for resources:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PREFIX=\"vpc-lab\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You see your AWS account ID and principal.\n&#8211; You have a region selected.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create the VPC and enable DNS<\/h3>\n\n\n\n<p>Create a VPC (example CIDR <code>10.20.0.0\/16<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export VPC_CIDR=\"10.20.0.0\/16\"\n\nVPC_ID=$(aws ec2 create-vpc \\\n  --region \"$AWS_REGION\" \\\n  --cidr-block \"$VPC_CIDR\" \\\n  --tag-specifications \"ResourceType=vpc,Tags=[{Key=Name,Value=${PREFIX}-vpc}]\" \\\n  --query \"Vpc.VpcId\" --output text)\n\necho \"VPC_ID=$VPC_ID\"\n<\/code><\/pre>\n\n\n\n<p>Enable DNS support and DNS hostnames (helps with instance DNS names):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 modify-vpc-attribute --region \"$AWS_REGION\" --vpc-id \"$VPC_ID\" --enable-dns-support\naws ec2 modify-vpc-attribute --region \"$AWS_REGION\" --vpc-id \"$VPC_ID\" --enable-dns-hostnames\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A new VPC exists and has DNS enabled.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 describe-vpcs --region \"$AWS_REGION\" --vpc-ids \"$VPC_ID\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a public subnet in one Availability Zone<\/h3>\n\n\n\n<p>Pick one AZ in your region:<\/p>\n\n\n\n<pre><code class=\"language-bash\">AZ=$(aws ec2 describe-availability-zones --region \"$AWS_REGION\" \\\n  --query \"AvailabilityZones[0].ZoneName\" --output text)\n\necho \"AZ=$AZ\"\n<\/code><\/pre>\n\n\n\n<p>Create a subnet (example <code>10.20.1.0\/24<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">SUBNET_ID=$(aws ec2 create-subnet \\\n  --region \"$AWS_REGION\" \\\n  --vpc-id \"$VPC_ID\" \\\n  --availability-zone \"$AZ\" \\\n  --cidr-block \"10.20.1.0\/24\" \\\n  --tag-specifications \"ResourceType=subnet,Tags=[{Key=Name,Value=${PREFIX}-public-${AZ}}]\" \\\n  --query \"Subnet.SubnetId\" --output text)\n\necho \"SUBNET_ID=$SUBNET_ID\"\n<\/code><\/pre>\n\n\n\n<p>Enable auto-assign public IPv4 addresses for this subnet (so instances get public IPs by default):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 modify-subnet-attribute \\\n  --region \"$AWS_REGION\" \\\n  --subnet-id \"$SUBNET_ID\" \\\n  --map-public-ip-on-launch\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; One subnet exists in a specific AZ and auto-assigns public IPs.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 describe-subnets --region \"$AWS_REGION\" --subnet-ids \"$SUBNET_ID\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create and attach an Internet Gateway, then add routes<\/h3>\n\n\n\n<p>Create an Internet Gateway:<\/p>\n\n\n\n<pre><code class=\"language-bash\">IGW_ID=$(aws ec2 create-internet-gateway \\\n  --region \"$AWS_REGION\" \\\n  --tag-specifications \"ResourceType=internet-gateway,Tags=[{Key=Name,Value=${PREFIX}-igw}]\" \\\n  --query \"InternetGateway.InternetGatewayId\" --output text)\n\necho \"IGW_ID=$IGW_ID\"\n<\/code><\/pre>\n\n\n\n<p>Attach it to the VPC:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 attach-internet-gateway \\\n  --region \"$AWS_REGION\" \\\n  --internet-gateway-id \"$IGW_ID\" \\\n  --vpc-id \"$VPC_ID\"\n<\/code><\/pre>\n\n\n\n<p>Create a route table:<\/p>\n\n\n\n<pre><code class=\"language-bash\">RTB_ID=$(aws ec2 create-route-table \\\n  --region \"$AWS_REGION\" \\\n  --vpc-id \"$VPC_ID\" \\\n  --tag-specifications \"ResourceType=route-table,Tags=[{Key=Name,Value=${PREFIX}-public-rtb}]\" \\\n  --query \"RouteTable.RouteTableId\" --output text)\n\necho \"RTB_ID=$RTB_ID\"\n<\/code><\/pre>\n\n\n\n<p>Add a default route (<code>0.0.0.0\/0<\/code>) to the IGW:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 create-route \\\n  --region \"$AWS_REGION\" \\\n  --route-table-id \"$RTB_ID\" \\\n  --destination-cidr-block \"0.0.0.0\/0\" \\\n  --gateway-id \"$IGW_ID\"\n<\/code><\/pre>\n\n\n\n<p>Associate the route table with the subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 associate-route-table \\\n  --region \"$AWS_REGION\" \\\n  --route-table-id \"$RTB_ID\" \\\n  --subnet-id \"$SUBNET_ID\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The subnet has a route to the internet through the IGW.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 describe-route-tables --region \"$AWS_REGION\" --route-table-ids \"$RTB_ID\"\n<\/code><\/pre>\n\n\n\n<p>You should see:\n&#8211; a <code>local<\/code> route for <code>10.20.0.0\/16<\/code>\n&#8211; a <code>0.0.0.0\/0<\/code> route to the Internet Gateway<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create a security group (minimal inbound)<\/h3>\n\n\n\n<p>Create a security group with no inbound rules (SSM does not require inbound access):<\/p>\n\n\n\n<pre><code class=\"language-bash\">SG_ID=$(aws ec2 create-security-group \\\n  --region \"$AWS_REGION\" \\\n  --group-name \"${PREFIX}-sg\" \\\n  --description \"Minimal SG for SSM lab\" \\\n  --vpc-id \"$VPC_ID\" \\\n  --tag-specifications \"ResourceType=security-group,Tags=[{Key=Name,Value=${PREFIX}-sg}]\" \\\n  --query \"GroupId\" --output text)\n\necho \"SG_ID=$SG_ID\"\n<\/code><\/pre>\n\n\n\n<p>By default, security groups allow <strong>all outbound<\/strong>. That\u2019s fine for this lab. In production you often restrict egress.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You have a security group ready to attach to the instance.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 describe-security-groups --region \"$AWS_REGION\" --group-ids \"$SG_ID\"\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 IAM role for Session Manager (SSM)<\/h3>\n\n\n\n<p>Create a trust policy file:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; \/tmp\/ec2-trust-policy.json &lt;&lt; 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": { \"Service\": \"ec2.amazonaws.com\" },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create the role:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ROLE_NAME=\"${PREFIX}-ec2-ssm-role\"\n\naws iam create-role \\\n  --role-name \"$ROLE_NAME\" \\\n  --assume-role-policy-document file:\/\/\/tmp\/ec2-trust-policy.json\n<\/code><\/pre>\n\n\n\n<p>Attach the AWS-managed policy required for SSM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam attach-role-policy \\\n  --role-name \"$ROLE_NAME\" \\\n  --policy-arn \"arn:aws:iam::aws:policy\/AmazonSSMManagedInstanceCore\"\n<\/code><\/pre>\n\n\n\n<p>Create an instance profile and add the role:<\/p>\n\n\n\n<pre><code class=\"language-bash\">PROFILE_NAME=\"${PREFIX}-ec2-profile\"\n\naws iam create-instance-profile --instance-profile-name \"$PROFILE_NAME\"\naws iam add-role-to-instance-profile --instance-profile-name \"$PROFILE_NAME\" --role-name \"$ROLE_NAME\"\n<\/code><\/pre>\n\n\n\n<p>Wait briefly for IAM propagation (often needed):<\/p>\n\n\n\n<pre><code class=\"language-bash\">sleep 15\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; An EC2 instance profile exists that grants SSM access.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam get-instance-profile --instance-profile-name \"$PROFILE_NAME\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Launch an EC2 instance in the public subnet<\/h3>\n\n\n\n<p>Find a current Amazon Linux AMI via SSM Parameter Store (recommended approach because AMI IDs vary by region). For Amazon Linux 2023, AWS publishes parameters; verify the exact parameter name in official docs if needed.<\/p>\n\n\n\n<p>Common approach:<\/p>\n\n\n\n<pre><code class=\"language-bash\">AMI_ID=$(aws ssm get-parameter \\\n  --region \"$AWS_REGION\" \\\n  --name \"\/aws\/service\/ami-amazon-linux-latest\/al2023-ami-kernel-default-x86_64\" \\\n  --query \"Parameter.Value\" --output text)\n\necho \"AMI_ID=$AMI_ID\"\n<\/code><\/pre>\n\n\n\n<p>Launch a small instance (choose an instance type available to you, e.g., <code>t3.micro<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">INSTANCE_ID=$(aws ec2 run-instances \\\n  --region \"$AWS_REGION\" \\\n  --image-id \"$AMI_ID\" \\\n  --instance-type \"t3.micro\" \\\n  --subnet-id \"$SUBNET_ID\" \\\n  --security-group-ids \"$SG_ID\" \\\n  --iam-instance-profile Name=\"$PROFILE_NAME\" \\\n  --tag-specifications \"ResourceType=instance,Tags=[{Key=Name,Value=${PREFIX}-ec2}]\" \\\n  --query \"Instances[0].InstanceId\" --output text)\n\necho \"INSTANCE_ID=$INSTANCE_ID\"\n<\/code><\/pre>\n\n\n\n<p>Wait for it to become running:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 wait instance-running --region \"$AWS_REGION\" --instance-ids \"$INSTANCE_ID\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; EC2 instance is running with a public IP and can reach AWS SSM endpoints via the internet route.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 describe-instances --region \"$AWS_REGION\" --instance-ids \"$INSTANCE_ID\" \\\n  --query \"Reservations[0].Instances[0].{State:State.Name,PublicIp:PublicIpAddress,Subnet:SubnetId,Vpc:VpcId}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Connect using Session Manager and generate traffic<\/h3>\n\n\n\n<p>In the AWS Console:\n1. Go to <strong>EC2<\/strong> \u2192 <strong>Instances<\/strong>\n2. Select the instance <code>${PREFIX}-ec2<\/code>\n3. Click <strong>Connect<\/strong>\n4. Choose <strong>Session Manager<\/strong>\n5. Click <strong>Connect<\/strong><\/p>\n\n\n\n<p>Run a few commands to generate outbound traffic:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I https:\/\/example.com\ncurl -I https:\/\/aws.amazon.com\n<\/code><\/pre>\n\n\n\n<p>(Optional) Confirm your instance has DNS working:<\/p>\n\n\n\n<pre><code class=\"language-bash\">getent hosts example.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You successfully open a shell without SSH.\n&#8211; <code>curl<\/code> requests succeed (HTTP headers returned).<\/p>\n\n\n\n<p>If Session Manager doesn\u2019t work, see <strong>Troubleshooting<\/strong> below.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Enable VPC Flow Logs to CloudWatch Logs<\/h3>\n\n\n\n<p>Create a CloudWatch log group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">LOG_GROUP=\"\/aws\/vpc\/${PREFIX}-flowlogs\"\naws logs create-log-group --region \"$AWS_REGION\" --log-group-name \"$LOG_GROUP\" || true\n<\/code><\/pre>\n\n\n\n<p>Create an IAM role for flow logs to publish to CloudWatch Logs.<\/p>\n\n\n\n<p>Trust policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; \/tmp\/flowlogs-trust-policy.json &lt;&lt; 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": { \"Service\": \"vpc-flow-logs.amazonaws.com\" },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create the role:<\/p>\n\n\n\n<pre><code class=\"language-bash\">FLOWLOGS_ROLE=\"${PREFIX}-flowlogs-role\"\n\naws iam create-role \\\n  --role-name \"$FLOWLOGS_ROLE\" \\\n  --assume-role-policy-document file:\/\/\/tmp\/flowlogs-trust-policy.json\n<\/code><\/pre>\n\n\n\n<p>Attach permissions. AWS provides guidance on the required permissions; the policy typically allows <code>logs:CreateLogStream<\/code> and <code>logs:PutLogEvents<\/code> on the log group. Create an inline policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)\n\ncat &gt; \/tmp\/flowlogs-policy.json &lt;&lt; EOF\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"logs:CreateLogStream\",\n        \"logs:PutLogEvents\",\n        \"logs:DescribeLogGroups\",\n        \"logs:DescribeLogStreams\"\n      ],\n      \"Resource\": [\n        \"arn:aws:logs:${AWS_REGION}:${ACCOUNT_ID}:log-group:${LOG_GROUP}:*\",\n        \"arn:aws:logs:${AWS_REGION}:${ACCOUNT_ID}:log-group:${LOG_GROUP}\"\n      ]\n    }\n  ]\n}\nEOF\n\naws iam put-role-policy \\\n  --role-name \"$FLOWLOGS_ROLE\" \\\n  --policy-name \"${PREFIX}-flowlogs-to-cw\" \\\n  --policy-document file:\/\/\/tmp\/flowlogs-policy.json\n<\/code><\/pre>\n\n\n\n<p>Create the flow log for the VPC (capture ALL traffic; in production you may choose ACCEPT\/REJECT or specific subnets\/ENIs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">FLOW_LOG_ID=$(aws ec2 create-flow-logs \\\n  --region \"$AWS_REGION\" \\\n  --resource-type VPC \\\n  --resource-ids \"$VPC_ID\" \\\n  --traffic-type ALL \\\n  --log-destination-type cloud-watch-logs \\\n  --log-group-name \"$LOG_GROUP\" \\\n  --deliver-logs-permission-arn \"arn:aws:iam::${ACCOUNT_ID}:role\/${FLOWLOGS_ROLE}\" \\\n  --query \"FlowLogIds[0]\" --output text)\n\necho \"FLOW_LOG_ID=$FLOW_LOG_ID\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Flow logs are enabled and will start delivering records to CloudWatch Logs.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 describe-flow-logs --region \"$AWS_REGION\" --flow-log-ids \"$FLOW_LOG_ID\"\n<\/code><\/pre>\n\n\n\n<p>Now generate a bit more traffic from your instance (repeat <code>curl<\/code>), wait ~1\u20133 minutes, then check logs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Query Flow Logs in CloudWatch Logs Insights<\/h3>\n\n\n\n<p>In the AWS Console:\n1. Go to <strong>CloudWatch<\/strong> \u2192 <strong>Logs<\/strong> \u2192 <strong>Log groups<\/strong>\n2. Open the log group: <code>\/aws\/vpc\/vpc-lab-flowlogs<\/code> (or your prefix)\n3. Click <strong>Logs Insights<\/strong>\n4. Use a query similar to:<\/p>\n\n\n\n<pre><code class=\"language-text\">fields @timestamp, srcAddr, dstAddr, srcPort, dstPort, protocol, action\n| sort @timestamp desc\n| limit 50\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>The exact fields depend on the flow log format\/version used by AWS. If fields differ, inspect a raw log event and adjust the query accordingly.<\/p>\n<\/blockquote>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You can see ACCEPT\/REJECT records showing your instance\u2019s outbound connections.<\/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:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Routing<\/strong>\n   &#8211; Public subnet route table has <code>0.0.0.0\/0<\/code> \u2192 IGW<\/li>\n<li><strong>Instance connectivity<\/strong>\n   &#8211; EC2 has a <strong>public IP<\/strong>\n   &#8211; <code>curl https:\/\/example.com<\/code> works inside Session Manager<\/li>\n<li><strong>Flow logs<\/strong>\n   &#8211; CloudWatch log group contains flow log events\n   &#8211; Logs Insights query returns recent traffic entries<\/li>\n<\/ol>\n\n\n\n<p>Optional CLI checks:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 describe-internet-gateways --region \"$AWS_REGION\" --internet-gateway-ids \"$IGW_ID\"\naws logs describe-log-streams --region \"$AWS_REGION\" --log-group-name \"$LOG_GROUP\" --max-items 5\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Session Manager \u201cNot connected\u201d \/ instance not showing as managed<\/strong>\n   &#8211; Ensure the instance has the IAM role with <code>AmazonSSMManagedInstanceCore<\/code>.\n   &#8211; Ensure the instance can reach the internet (IGW route + public IP + outbound SG).\n   &#8211; Confirm SSM Agent is installed\/running (Amazon Linux usually includes it).\n   &#8211; Verify your user has permissions for SSM Session Manager (<code>ssm:StartSession<\/code>, etc.).<\/p>\n<\/li>\n<li>\n<p><strong>No internet from instance<\/strong>\n   &#8211; Check subnet route table association is correct.\n   &#8211; Confirm <code>0.0.0.0\/0<\/code> route targets the IGW.\n   &#8211; Confirm instance has a public IPv4 address (or Elastic IP), and the subnet maps public IPs on launch.\n   &#8211; Check security group outbound rules allow traffic.\n   &#8211; Check NACL isn\u2019t blocking outbound\/return traffic.<\/p>\n<\/li>\n<li>\n<p><strong>Flow logs created but no events<\/strong>\n   &#8211; Wait a few minutes; delivery is not instant.\n   &#8211; Generate traffic again (curl, yum\/dnf update metadata).\n   &#8211; Ensure the flow logs role policy includes the correct log group ARN.\n   &#8211; Confirm the log group exists in the same region.\n   &#8211; Check <code>describe-flow-logs<\/code> for errors in delivery status (if shown).<\/p>\n<\/li>\n<li>\n<p><strong>CLI AMI parameter not found<\/strong>\n   &#8211; Parameter names can differ by architecture\/region.\n   &#8211; Use the AWS console to pick an Amazon Linux AMI, or verify the correct SSM public parameter in official docs.<\/p>\n<\/li>\n<\/ol>\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 reverse order:<\/p>\n\n\n\n<p>1) Terminate EC2 instance:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 terminate-instances --region \"$AWS_REGION\" --instance-ids \"$INSTANCE_ID\"\naws ec2 wait instance-terminated --region \"$AWS_REGION\" --instance-ids \"$INSTANCE_ID\"\n<\/code><\/pre>\n\n\n\n<p>2) Delete flow logs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 delete-flow-logs --region \"$AWS_REGION\" --flow-log-ids \"$FLOW_LOG_ID\"\n<\/code><\/pre>\n\n\n\n<p>3) Delete CloudWatch log group (optional; do this to avoid log storage costs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws logs delete-log-group --region \"$AWS_REGION\" --log-group-name \"$LOG_GROUP\"\n<\/code><\/pre>\n\n\n\n<p>4) Detach and delete Internet Gateway:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 detach-internet-gateway --region \"$AWS_REGION\" --internet-gateway-id \"$IGW_ID\" --vpc-id \"$VPC_ID\"\naws ec2 delete-internet-gateway --region \"$AWS_REGION\" --internet-gateway-id \"$IGW_ID\"\n<\/code><\/pre>\n\n\n\n<p>5) Delete route table (only if it\u2019s not the main route table and has no associations):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># You may need to disassociate first if you created extra associations\n# Find association IDs if needed:\naws ec2 describe-route-tables --region \"$AWS_REGION\" --route-table-ids \"$RTB_ID\"\n\naws ec2 delete-route-table --region \"$AWS_REGION\" --route-table-id \"$RTB_ID\"\n<\/code><\/pre>\n\n\n\n<p>6) Delete subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 delete-subnet --region \"$AWS_REGION\" --subnet-id \"$SUBNET_ID\"\n<\/code><\/pre>\n\n\n\n<p>7) Delete security group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 delete-security-group --region \"$AWS_REGION\" --group-id \"$SG_ID\"\n<\/code><\/pre>\n\n\n\n<p>8) Delete VPC:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ec2 delete-vpc --region \"$AWS_REGION\" --vpc-id \"$VPC_ID\"\n<\/code><\/pre>\n\n\n\n<p>9) Delete IAM instance profile and roles:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam remove-role-from-instance-profile --instance-profile-name \"$PROFILE_NAME\" --role-name \"$ROLE_NAME\"\naws iam delete-instance-profile --instance-profile-name \"$PROFILE_NAME\"\n\naws iam detach-role-policy --role-name \"$ROLE_NAME\" --policy-arn \"arn:aws:iam::aws:policy\/AmazonSSMManagedInstanceCore\"\naws iam delete-role --role-name \"$ROLE_NAME\"\n\naws iam delete-role-policy --role-name \"$FLOWLOGS_ROLE\" --policy-name \"${PREFIX}-flowlogs-to-cw\"\naws iam delete-role --role-name \"$FLOWLOGS_ROLE\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; All lab resources are removed, minimizing the chance of ongoing charges.<\/p>\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>Use a standard VPC pattern<\/strong>: Most orgs use:<\/li>\n<li>Public subnets (ingress\/egress components like ALB, NAT)<\/li>\n<li>Private application subnets<\/li>\n<li>Private data subnets (more restricted)<\/li>\n<li><strong>Design multi-AZ from the start<\/strong> for production:<\/li>\n<li>At least two AZs<\/li>\n<li>Duplicate subnets per AZ<\/li>\n<li>AZ-aligned NAT Gateways if using NAT<\/li>\n<li><strong>Avoid overly large blast radius<\/strong>:<\/li>\n<li>Use multiple VPCs or accounts for strong isolation (especially for prod vs dev).<\/li>\n<li><strong>Plan IP addressing<\/strong>:<\/li>\n<li>Avoid overlapping CIDRs if hybrid or multi-VPC connectivity is expected.<\/li>\n<li>Reserve space for future subnets and expansion.<\/li>\n<li>Consider IPAM if you operate at enterprise scale.<\/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>Least privilege for VPC changes<\/strong>:<\/li>\n<li>Restrict who can modify route tables, IGWs, peering, and security groups.<\/li>\n<li>Use permission boundaries or separate \u201cnetwork admin\u201d roles.<\/li>\n<li><strong>Use AWS Config and SCPs<\/strong> (in AWS Organizations) for guardrails:<\/li>\n<li>Prevent public exposure patterns when not allowed (e.g., restrict IGW creation in certain accounts).<\/li>\n<li><strong>Security groups over NACL complexity<\/strong>:<\/li>\n<li>Keep NACLs simple unless you have a specific requirement.<\/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>Reduce NAT reliance<\/strong> via VPC endpoints where appropriate.<\/li>\n<li><strong>Right-size logging<\/strong>:<\/li>\n<li>Enable Flow Logs strategically (critical subnets\/ENIs).<\/li>\n<li>Use retention policies in CloudWatch Logs or lifecycle rules in S3.<\/li>\n<li><strong>Watch cross-AZ traffic<\/strong>:<\/li>\n<li>Keep chatty services AZ-local when possible.<\/li>\n<li><strong>Tag NAT gateways, endpoints, and log groups<\/strong> for cost attribution.<\/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>Keep traffic inside the AWS network<\/strong> where possible:<\/li>\n<li>Use VPC endpoints\/PrivateLink instead of internet routes for AWS service access.<\/li>\n<li><strong>Avoid unnecessary hops<\/strong>:<\/li>\n<li>Overly complex routing (multiple appliances) can add latency and failure modes.<\/li>\n<li><strong>Use correct load balancer placement<\/strong>:<\/li>\n<li>Internet-facing ALBs in public subnets; internal ALBs in private subnets.<\/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>No single AZ dependencies<\/strong>:<\/li>\n<li>If you use NAT, deploy one per AZ and configure route tables accordingly.<\/li>\n<li>Ensure both subnets and routing exist per AZ.<\/li>\n<li><strong>Change control for routing<\/strong>:<\/li>\n<li>Route changes can cause instant widespread outages. Use staged rollouts and review.<\/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>Centralize observability<\/strong>:<\/li>\n<li>Use Flow Logs + CloudTrail; aggregate to a security\/observability account when feasible.<\/li>\n<li><strong>Use Reachability Analyzer for troubleshooting<\/strong>:<\/li>\n<li>Make it part of incident response runbooks.<\/li>\n<li><strong>Document subnet intent<\/strong>:<\/li>\n<li>Clearly label (and tag) subnets: <code>public<\/code>, <code>private-app<\/code>, <code>private-db<\/code>, <code>inspection<\/code>, etc.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<p>Adopt consistent tags:\n&#8211; <code>Name<\/code>\n&#8211; <code>Environment<\/code> (dev\/test\/prod)\n&#8211; <code>Owner<\/code> or <code>Team<\/code>\n&#8211; <code>CostCenter<\/code>\n&#8211; <code>DataClassification<\/code>\n&#8211; <code>Application<\/code><\/p>\n\n\n\n<p>Use consistent names:\n&#8211; <code>vpc-prod-us-east-1<\/code>\n&#8211; <code>subnet-prod-public-use1a<\/code>\n&#8211; <code>rtb-prod-private-use1a<\/code><\/p>\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>Amazon VPC resources are controlled by IAM permissions on EC2\/VPC APIs.<\/li>\n<li>Use:<\/li>\n<li>Separate roles for <strong>network admins<\/strong> vs <strong>application deployers<\/strong><\/li>\n<li>CloudTrail to monitor changes<\/li>\n<li>AWS Config rules to detect drift and risky configurations<\/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>VPC networking itself is about routing and segmentation, not data-at-rest encryption.<\/li>\n<li>Use:<\/li>\n<li>TLS for data in transit at application level<\/li>\n<li>Service-level encryption for storage (EBS, RDS, S3, etc.)<\/li>\n<li>VPN\/Direct Connect MACsec where applicable (verify service capability and region)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<p>Key security levers:\n&#8211; <strong>Route tables<\/strong>: If a subnet has a default route to IGW and instances have public IPs, it is effectively \u201cpublic.\u201d\n&#8211; <strong>Security groups<\/strong>: Avoid <code>0.0.0.0\/0<\/code> inbound to administrative ports.\n&#8211; <strong>NACLs<\/strong>: Use carefully; they can block or permit broad ranges.<\/p>\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 store secrets in user data or AMIs.<\/li>\n<li>Use AWS Secrets Manager or SSM Parameter Store (with encryption) and tight IAM policies.<\/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><strong>CloudTrail<\/strong> for control-plane changes (routes, SGs, IGW attachments, endpoints).<\/li>\n<li><strong>VPC Flow Logs<\/strong> for traffic metadata.<\/li>\n<li>Consider central log retention and access controls.<\/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>Segmentation and logging requirements often map to common compliance controls, but the exact mapping depends on your framework.<\/li>\n<li>Verify required configurations and retention with your compliance team and AWS documentation.<\/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>Public subnets accidentally used for databases<\/li>\n<li>Overly permissive security groups (\u201callow all\u201d inbound)<\/li>\n<li>No egress control (malware can call home)<\/li>\n<li>No flow logs (harder to investigate incidents)<\/li>\n<li>CIDR overlap preventing future connectivity or forcing risky workarounds<\/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>Default to private subnets for compute where possible.<\/li>\n<li>Use inbound entry points (ALB\/API Gateway) rather than exposing instances.<\/li>\n<li>Prefer SSM Session Manager over SSH\/bastions where feasible.<\/li>\n<li>Use VPC endpoints for AWS services to reduce internet dependency.<\/li>\n<li>Implement guardrails with Config\/SCPs and continuous monitoring.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon VPC has many quotas: VPCs per region, subnets per VPC, routes per route table, SG rules, ENIs per instance type, etc.<\/li>\n<li>Quotas vary and can change\u2014use <strong>Service Quotas<\/strong> as the source of truth.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPC is regional; subnet is AZ-specific.<\/li>\n<li>Some advanced networking capabilities (or specific endpoint availability) may vary by region\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>NAT Gateway hourly + per-GB processing is a frequent surprise.<\/li>\n<li>Interface endpoints (PrivateLink) add hourly costs that scale with AZ count and number of services.<\/li>\n<li>Flow logs to CloudWatch Logs can generate significant ingestion costs at scale.<\/li>\n<li>Inter-AZ data transfer can become significant in microservices architectures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CIDR overlap can block:<\/li>\n<li>VPC peering<\/li>\n<li>Transit Gateway routing<\/li>\n<li>Hybrid connectivity<\/li>\n<li>Some managed services require subnets in multiple AZs for high availability (service-specific).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Security group changes are immediate\u2014good for response, risky for mistakes.<\/li>\n<li>Route table changes can instantly cut off connectivity for many resources.<\/li>\n<li>NACL stateless behavior causes \u201cit should work but it doesn\u2019t\u201d scenarios (return traffic blocked).<\/li>\n<li>DNS settings affect many services; misconfiguration can mimic \u201cnetwork outages.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Expanding or changing CIDR plans after the fact is complex.<\/li>\n<li>Migrating between VPCs often requires:<\/li>\n<li>Re-IP or dual-stack changes<\/li>\n<li>DNS migration<\/li>\n<li>Load balancer and endpoint updates<\/li>\n<li>Connectivity changes (peering\/TGW)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS networking is built around ENIs, security groups, and route tables\u2014similar concepts exist in other clouds, but behavior differs. Avoid assuming Azure\/GCP semantics are identical.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Amazon VPC is the core AWS network boundary, but there are adjacent options for different scopes.<\/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<\/strong><\/td>\n<td>Isolated networking for AWS workloads in a region<\/td>\n<td>Mature primitives (subnets, routes, SGs), deep AWS integration, strong patterns<\/td>\n<td>Requires good IP\/routing\/security design; can become complex at scale<\/td>\n<td>Any workload needing controlled networking in AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Transit Gateway<\/strong><\/td>\n<td>Connecting many VPCs and on-prem networks<\/td>\n<td>Scalable hub-and-spoke routing, centralized control<\/td>\n<td>Added cost and design complexity<\/td>\n<td>When VPC peering becomes unmanageable or you need transitive routing<\/td>\n<\/tr>\n<tr>\n<td><strong>VPC endpoints (PrivateLink)<\/strong><\/td>\n<td>Private access to AWS services\/SaaS<\/td>\n<td>Reduce internet exposure, strong security posture<\/td>\n<td>Interface endpoint costs; endpoint sprawl<\/td>\n<td>For private subnets and compliance-focused architectures<\/td>\n<\/tr>\n<tr>\n<td><strong>Site-to-Site VPN<\/strong><\/td>\n<td>Encrypted connectivity to on-prem<\/td>\n<td>Fast to set up, good for dev\/backup<\/td>\n<td>Internet-based variability, throughput limits<\/td>\n<td>Quick hybrid connectivity or backup to Direct Connect<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Direct Connect<\/strong><\/td>\n<td>Dedicated connectivity to AWS<\/td>\n<td>More consistent performance, private connectivity<\/td>\n<td>Lead time, port costs, operational coordination<\/td>\n<td>Enterprise hybrid with predictable bandwidth\/latency needs<\/td>\n<\/tr>\n<tr>\n<td><strong>Amazon CloudFront<\/strong><\/td>\n<td>Content delivery and edge caching<\/td>\n<td>Global edge network, DDoS protection integration<\/td>\n<td>Not a replacement for VPC networking<\/td>\n<td>When serving content globally; VPC hosts origins<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Virtual Network (VNet)<\/strong><\/td>\n<td>Networking in Microsoft Azure<\/td>\n<td>Similar constructs, deep Azure integration<\/td>\n<td>Different routing\/security semantics<\/td>\n<td>When your workloads are on Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud VPC<\/strong><\/td>\n<td>Networking in Google Cloud<\/td>\n<td>Global VPC design (provider-specific), GCP integration<\/td>\n<td>Different model than AWS regional VPC<\/td>\n<td>When workloads are on GCP<\/td>\n<\/tr>\n<tr>\n<td><strong>On-prem VLAN\/VRF + firewalls<\/strong><\/td>\n<td>Traditional data center segmentation<\/td>\n<td>Full control of hardware<\/td>\n<td>CapEx, slower provisioning, scaling limits<\/td>\n<td>When workloads stay on-prem or require specialized hardware control<\/td>\n<\/tr>\n<tr>\n<td><strong>OpenStack Neutron (self-managed)<\/strong><\/td>\n<td>Private cloud networking<\/td>\n<td>Customization, open ecosystem<\/td>\n<td>High operational burden<\/td>\n<td>When running private cloud and you accept the ops cost<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\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 regulated platform with centralized inspection<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA regulated enterprise runs dozens of applications with strict separation between prod and non-prod, requires centralized logging, controlled egress, and hybrid connectivity to on-premises services (identity, SIEM, legacy databases).<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; AWS Organizations with separate accounts:\n  &#8211; Network account (shared services and connectivity)\n  &#8211; Security\/logging account\n  &#8211; Workload accounts per application\/team\n&#8211; Amazon VPC per environment (prod, non-prod), multi-AZ:\n  &#8211; Public subnets: ALBs, NAT Gateways (per AZ)\n  &#8211; Private app subnets: EKS nodes \/ ECS tasks\n  &#8211; Private data subnets: RDS\/Aurora, internal datastores\n&#8211; Connectivity:\n  &#8211; Transit Gateway as hub\n  &#8211; VPN and\/or Direct Connect attachments\n&#8211; Private access:\n  &#8211; VPC endpoints for S3, ECR, CloudWatch, SSM, etc. (service set depends on workloads)\n&#8211; Observability\/governance:\n  &#8211; VPC Flow Logs to centralized S3\/CloudWatch\n  &#8211; CloudTrail org trail\n  &#8211; AWS Config rules + SCP guardrails<\/p>\n\n\n\n<p><strong>Why Amazon VPC was chosen<\/strong>\n&#8211; Strong isolation boundary and mature primitives\n&#8211; Integrates with Transit Gateway, endpoints\/PrivateLink, and enterprise governance tooling\n&#8211; Supports security segmentation patterns and auditability<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Reduced internet exposure (more private traffic paths)\n&#8211; Faster onboarding of new workloads via standardized VPC templates\n&#8211; Easier audits with centralized logs and controlled network change permissions<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Two-tier SaaS with minimal ops<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA startup needs a simple, secure network for an API service and a managed database, with minimal administrative overhead and a clear path to scale.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; One Amazon VPC in a single region, two AZs\n&#8211; Public subnets:\n  &#8211; Internet-facing ALB\n&#8211; Private subnets:\n  &#8211; App tier (ECS on Fargate or EC2)\n  &#8211; Database (RDS) in DB subnet group\n&#8211; Security:\n  &#8211; Security groups tightly scoped (ALB \u2192 app; app \u2192 DB)\n  &#8211; No direct instance exposure; use SSM Session Manager if EC2 is used\n&#8211; Observability:\n  &#8211; Basic VPC Flow Logs on critical subnets\n&#8211; Cost management:\n  &#8211; Avoid NAT if possible by using endpoints for AWS services and limiting internet egress needs (or use NAT carefully)<\/p>\n\n\n\n<p><strong>Why Amazon VPC was chosen<\/strong>\n&#8211; It\u2019s the default secure networking boundary for AWS workloads\n&#8211; Simple public\/private subnet architecture supports secure-by-default designs<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Clear separation of public ingress from private data\n&#8211; Straightforward scaling by adding services and AZ capacity\n&#8211; Reduced operational risk by avoiding ad-hoc networking changes<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is Amazon VPC free?<\/h3>\n\n\n\n<p>Creating a VPC, subnets, route tables, security groups, and attaching an Internet Gateway is generally not charged directly. Costs usually come from NAT Gateways, interface endpoints, VPN, traffic mirroring, flow logs destinations, and data transfer. Confirm on the official pricing page: https:\/\/aws.amazon.com\/vpc\/pricing\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Is a VPC global?<\/h3>\n\n\n\n<p>No. A VPC is <strong>regional<\/strong>. Subnets are <strong>Availability Zone\u2013specific<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) What makes a subnet \u201cpublic\u201d?<\/h3>\n\n\n\n<p>A subnet is typically considered public if:\n&#8211; Its route table has a route to an Internet Gateway (e.g., <code>0.0.0.0\/0 -&gt; igw-...<\/code>), and\n&#8211; Instances have public IPs (or Elastic IPs), and\n&#8211; Security rules allow the traffic.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) What makes a subnet \u201cprivate\u201d?<\/h3>\n\n\n\n<p>A private subnet has no direct route to an Internet Gateway. It may still have outbound access via NAT Gateway, VPN, Direct Connect, or private endpoints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) Do security groups block outbound traffic by default?<\/h3>\n\n\n\n<p>By default, new security groups usually allow all outbound and deny all inbound. You can (and often should) restrict outbound in production.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) What\u2019s the difference between a security group and a network ACL?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Security groups<\/strong>: stateful, applied at ENI\/resource level.<\/li>\n<li><strong>NACLs<\/strong>: stateless, applied at subnet level; must allow return traffic explicitly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) When should I use NAT Gateway?<\/h3>\n\n\n\n<p>Use NAT Gateway when private subnet workloads must reach the public internet (patching, external APIs) but must not accept inbound internet connections. Be mindful of cost and AZ design.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) How can private subnets access S3 without NAT?<\/h3>\n\n\n\n<p>Use a <strong>VPC gateway endpoint for S3<\/strong> and update route tables and policies accordingly. This keeps S3 traffic private within AWS networking.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) What is AWS PrivateLink?<\/h3>\n\n\n\n<p>AWS PrivateLink uses <strong>interface VPC endpoints<\/strong> to provide private connectivity to supported AWS services and third-party endpoint services without exposing traffic to the public internet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) Can I connect two VPCs together?<\/h3>\n\n\n\n<p>Yes. Common options:\n&#8211; VPC peering (simple, non-transitive)\n&#8211; Transit Gateway (scalable, transitive)\n&#8211; VPN between VPCs (less common)\nChoose based on scale and routing needs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) What happens if my VPC CIDR overlaps with another network?<\/h3>\n\n\n\n<p>Overlapping CIDRs can prevent peering, Transit Gateway routing, and hybrid connectivity. Avoid overlap by planning your IP space (or use IPAM at scale).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Are VPC Flow Logs packet captures?<\/h3>\n\n\n\n<p>No. Flow logs capture traffic <strong>metadata<\/strong> (5-tuple-ish data and action), not payload. For packet-level visibility, consider Traffic Mirroring (with cost and compliance review).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) How do I see who changed a route table or security group?<\/h3>\n\n\n\n<p>Use <strong>AWS CloudTrail<\/strong> to audit API calls and see the actor, time, and change.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) Do I need a VPC for AWS Lambda?<\/h3>\n\n\n\n<p>Not always. Lambda can run without VPC attachment. If you attach a Lambda function to a VPC, it gets ENIs in your subnets, and you must consider subnet routing and egress carefully.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) How do I design VPCs for multiple environments?<\/h3>\n\n\n\n<p>Common approaches:\n&#8211; Separate VPCs per environment (and often separate AWS accounts)\n&#8211; Standardized CIDR blocks and subnet layouts\n&#8211; Centralized connectivity and logging (for enterprises)\nThe right approach depends on governance and blast-radius requirements.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) What is the safest way to access EC2 instances?<\/h3>\n\n\n\n<p>Prefer <strong>AWS Systems Manager Session Manager<\/strong> (no inbound ports), plus IAM\/MFA controls, logging, and least privilege. If SSH is required, restrict by source IP and consider using a dedicated access path.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) How do I prevent accidental public exposure?<\/h3>\n\n\n\n<p>Combine:\n&#8211; Guardrails (SCPs\/Config rules)\n&#8211; Minimal IAM permissions for route\/IGW changes\n&#8211; Security group standards (no <code>0.0.0.0\/0<\/code> to admin ports)\n&#8211; Automated scanning and continuous monitoring<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Amazon VPC<\/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 Docs \u2014 https:\/\/docs.aws.amazon.com\/vpc\/<\/td>\n<td>Authoritative reference for concepts, APIs, and features<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Amazon VPC Pricing \u2014 https:\/\/aws.amazon.com\/vpc\/pricing\/<\/td>\n<td>Explains cost model for endpoints, NAT, VPN, etc.<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>AWS Pricing Calculator \u2014 https:\/\/calculator.aws\/<\/td>\n<td>Build region-specific cost estimates<\/td>\n<\/tr>\n<tr>\n<td>Official data transfer pricing<\/td>\n<td>EC2 On-Demand Pricing (Data Transfer section) \u2014 https:\/\/aws.amazon.com\/ec2\/pricing\/on-demand\/#Data_Transfer<\/td>\n<td>Understand network transfer charges that affect VPC architectures<\/td>\n<\/tr>\n<tr>\n<td>Getting started<\/td>\n<td>Getting started with Amazon VPC \u2014 https:\/\/docs.aws.amazon.com\/vpc\/latest\/userguide\/what-is-amazon-vpc.html<\/td>\n<td>Good entry point and navigation into subtopics<\/td>\n<\/tr>\n<tr>\n<td>Official workshops<\/td>\n<td>AWS Workshops (search VPC) \u2014 https:\/\/workshops.aws\/<\/td>\n<td>Hands-on labs maintained by AWS and the community; validate lab freshness<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>AWS Architecture Center \u2014 https:\/\/aws.amazon.com\/architecture\/<\/td>\n<td>Reference architectures and best practices (search for networking\/VPC patterns)<\/td>\n<\/tr>\n<tr>\n<td>Security best practices<\/td>\n<td>AWS Security Documentation \u2014 https:\/\/docs.aws.amazon.com\/security\/<\/td>\n<td>Broader security patterns including network controls<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>VPC Flow Logs Docs \u2014 https:\/\/docs.aws.amazon.com\/vpc\/latest\/userguide\/flow-logs.html<\/td>\n<td>Deep dive into flow logs formats, destinations, and use<\/td>\n<\/tr>\n<tr>\n<td>Troubleshooting tool<\/td>\n<td>Reachability Analyzer Docs \u2014 https:\/\/docs.aws.amazon.com\/vpc\/latest\/reachability\/<\/td>\n<td>Connectivity analysis concepts and workflows<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>AWS YouTube Channel \u2014 https:\/\/www.youtube.com\/user\/AmazonWebServices<\/td>\n<td>Talks and re:Invent sessions on VPC, PrivateLink, TGW, etc.<\/td>\n<\/tr>\n<tr>\n<td>Reference implementations<\/td>\n<td>AWS Samples on GitHub \u2014 https:\/\/github.com\/aws-samples<\/td>\n<td>Look for VPC, PrivateLink, and networking IaC examples (verify relevance)<\/td>\n<\/tr>\n<tr>\n<td>Community (reputable)<\/td>\n<td>Well-Architected Framework \u2014 https:\/\/docs.aws.amazon.com\/wellarchitected\/latest\/framework\/<\/td>\n<td>Principles and reviews that influence VPC design decisions<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\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 URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Beginners to experienced engineers<\/td>\n<td>DevOps\/cloud fundamentals, AWS networking basics, hands-on 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 and early-career professionals<\/td>\n<td>Software engineering\/DevOps learning paths including cloud basics<\/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>Cloud operations, infrastructure, and operational readiness<\/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, DevOps, platform teams<\/td>\n<td>Reliability engineering, operations, observability, 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 and platform teams<\/td>\n<td>AIOps concepts, automation, monitoring-oriented practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\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 URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify current offerings)<\/td>\n<td>Individuals seeking guided training<\/td>\n<td>https:\/\/www.rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring (verify course catalog)<\/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 guidance and services (verify scope)<\/td>\n<td>Teams or individuals needing practical help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources (verify scope)<\/td>\n<td>Engineers needing troubleshooting and enablement<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\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 URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact services)<\/td>\n<td>Platform setup, automation, cloud operations<\/td>\n<td>VPC landing zone design, IaC modules, migration planning<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training<\/td>\n<td>Enablement, process, and implementation support<\/td>\n<td>Standard VPC patterns, security group baselines, CI\/CD for IaC<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify current scope)<\/td>\n<td>DevOps transformation and ops support<\/td>\n<td>Network governance workflows, observability setup, cost controls<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\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<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Basic networking:<\/li>\n<li>IPv4 CIDR, subnets, routing, NAT<\/li>\n<li>DNS fundamentals<\/li>\n<li>TCP\/UDP and common ports<\/li>\n<li>AWS foundations:<\/li>\n<li>IAM basics (users\/roles\/policies)<\/li>\n<li>AWS Regions and Availability Zones<\/li>\n<li>EC2 basics (instances, security groups)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Amazon VPC<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced AWS networking:<\/li>\n<li>VPC endpoints\/PrivateLink design<\/li>\n<li>Transit Gateway architectures<\/li>\n<li>Hybrid connectivity (VPN, Direct Connect)<\/li>\n<li>Route 53 Resolver and hybrid DNS<\/li>\n<li>Security:<\/li>\n<li>AWS Network Firewall (where appropriate)<\/li>\n<li>Zero-trust access patterns (SSM, identity-aware proxies)<\/li>\n<li>Centralized logging and threat detection workflows<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>CloudFormation\/CDK or Terraform modules for standardized VPCs<\/li>\n<li>Operations:<\/li>\n<li>Flow logs pipelines, CloudWatch Logs Insights, incident runbooks<\/li>\n<li>AWS Config compliance-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 Engineer \/ Cloud Administrator<\/li>\n<li>DevOps Engineer \/ Platform Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Network Engineer (Cloud)<\/li>\n<li>Security Engineer \/ Cloud Security Engineer<\/li>\n<li>Solutions Architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>Amazon VPC appears heavily in AWS certifications. Common paths:\n&#8211; AWS Certified Cloud Practitioner (foundation)\n&#8211; AWS Certified Solutions Architect \u2013 Associate (strong VPC coverage)\n&#8211; AWS Certified SysOps Administrator \u2013 Associate\n&#8211; AWS Certified Advanced Networking \u2013 Specialty (deep networking focus)<\/p>\n\n\n\n<p>Verify current certification names and exam guides on the official AWS certification site: https:\/\/aws.amazon.com\/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 2-AZ VPC with public\/private subnets and ALB \u2192 app \u2192 RDS<\/li>\n<li>Add VPC endpoints for S3 and SSM; remove NAT and validate private operation<\/li>\n<li>Implement Flow Logs to S3 with lifecycle policies and query with Athena (requires additional services)<\/li>\n<li>Build hub-and-spoke networking using Transit Gateway (multi-VPC lab)<\/li>\n<li>Create a shared VPC model using RAM (multi-account lab)<\/li>\n<\/ul>\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<\/strong>: AWS service for creating isolated virtual networks in a region.<\/li>\n<li><strong>CIDR<\/strong>: Classless Inter-Domain Routing; notation for IP ranges (e.g., <code>10.0.0.0\/16<\/code>).<\/li>\n<li><strong>Subnet<\/strong>: A slice of a VPC CIDR in one Availability Zone.<\/li>\n<li><strong>Availability Zone (AZ)<\/strong>: A physically separate location within an AWS region.<\/li>\n<li><strong>Route table<\/strong>: Set of rules that determines where network traffic is directed.<\/li>\n<li><strong>Internet Gateway (IGW)<\/strong>: Gateway that enables internet connectivity for a VPC.<\/li>\n<li><strong>NAT Gateway<\/strong>: Managed service enabling outbound internet for private subnets.<\/li>\n<li><strong>Egress-only Internet Gateway<\/strong>: IPv6-only outbound internet gateway.<\/li>\n<li><strong>Security group (SG)<\/strong>: Stateful firewall rules applied to ENIs\/resources.<\/li>\n<li><strong>Network ACL (NACL)<\/strong>: Stateless subnet-level network rules.<\/li>\n<li><strong>ENI<\/strong>: Elastic Network Interface; virtual network card in a VPC.<\/li>\n<li><strong>VPC endpoint<\/strong>: Private connection to AWS services; includes gateway endpoints and interface endpoints (PrivateLink).<\/li>\n<li><strong>PrivateLink<\/strong>: AWS technology for private service connectivity using interface endpoints.<\/li>\n<li><strong>VPC Flow Logs<\/strong>: Traffic metadata logs for VPC\/subnet\/ENI.<\/li>\n<li><strong>Reachability Analyzer<\/strong>: Tool to analyze network paths and explain reachability.<\/li>\n<li><strong>Transit Gateway (TGW)<\/strong>: Service for connecting multiple VPCs and networks with central routing.<\/li>\n<li><strong>Site-to-Site VPN<\/strong>: Encrypted tunnel between AWS and on-premises or other networks.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Amazon VPC is AWS\u2019s foundational service in the <strong>Networking and content delivery<\/strong> category for building private, controlled networks in the cloud. It provides regional network isolation with subnets per AZ, routing primitives, and layered security controls (security groups and NACLs). It matters because nearly every production AWS workload depends on predictable segmentation, safe internet access, and private connectivity to AWS services and other networks.<\/p>\n\n\n\n<p>Cost is typically driven not by \u201chaving a VPC,\u201d but by add-ons and traffic patterns\u2014especially NAT Gateways, interface endpoints\/PrivateLink, flow logs storage\/ingestion, and data transfer (including cross-AZ and internet egress). Security success depends on strong IAM control of network changes, careful route design, least-privilege security groups, and logging (CloudTrail + Flow Logs).<\/p>\n\n\n\n<p>Use Amazon VPC whenever you need secure, auditable networking for AWS workloads. Start next by learning VPC endpoints\/PrivateLink and multi-VPC connectivity (Transit Gateway) and by implementing your VPC patterns with infrastructure as code for repeatability and governance.<\/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-306","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\/306","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=306"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/306\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=306"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=306"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=306"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}