Chapter 35: AWS Connectivity

AWS Connectivity

When people ask “what is AWS Connectivity?”, they usually mean:

all the different ways your users, your applications, your on-premise data centers, your branch offices, your partner systems, and even other cloud providers can securely and efficiently reach your AWS resources — and how your AWS resources can reach out to the internet, to each other, or back to your on-prem world.

In other words: AWS Connectivity = the complete set of networking paths & tools that move data in and out of your AWS environment.

It’s not one single service. It is a whole family of services and patterns that solve different connectivity problems.

Let me teach this like we’re sitting together looking at a big map of Hyderabad + India + the world — slow, clear, with everyday analogies, real startup examples from Hyderabad, current 2026 options, and exactly when to use which path.

1. The Four Big Categories of AWS Connectivity (2026 View)

2. Deep Dive – The Most Important Connectivity Paths (With Hyderabad Examples)

A. Internet → AWS (Public-Facing Connectivity)

Most apps start here — users need to reach your website/API.

Main tools:

• Internet Gateway (IGW) — attaches to VPC → allows public subnets to reach internet
• Application Load Balancer (ALB) / Network Load Balancer (NLB) — front door for your EC2 / ECS / Fargate / Lambda
• CloudFront + Edge Locations — CDN for static content & caching (videos, images, JS)
• API Gateway — managed API front door (REST, HTTP, WebSocket) + Lambda authorizer
• Route 53 — DNS + health checks + routing policies

Hyderabad example – food delivery app:

User in Uppal opens app → browser hits https://app.com → Route 53 resolves domain → points to CloudFront distribution → CloudFront checks Hyderabad Edge Location cache → If cached → serves instantly (<10 ms) → If not → fetches from ALB in ap-south-2 → ALB distributes to healthy ECS tasks across 3 AZs

B. Private Connectivity Inside AWS (Zero Internet Exposure)

Your database, queues, internal APIs should never be reachable from the public internet.

Main tools:

• Private Subnets — no route to Internet Gateway
• NAT Gateway / NAT Instance — private subnet resources reach internet (for updates, API calls) without being reachable
• VPC Endpoints (Interface & Gateway) — private connection to AWS services (S3, DynamoDB, SQS, SNS, Secrets Manager, etc.) → No data leaves your VPC → no internet data transfer charges
• AWS PrivateLink — privately expose your service to other VPCs / accounts

Example: Your orders-service (ECS Fargate in private subnet) needs to write to DynamoDB → You create VPC Endpoint for DynamoDB (Gateway type) → Orders-service talks to DynamoDB over private AWS network → zero public internet exposure → zero data transfer cost → more secure

C. AWS ↔ On-Premise / Data Center / Branch Office

You have servers in a Hyderabad data center, office in Banjara Hills, or branch in Vijayawada.

Main tools:

• AWS Direct Connect — dedicated 1–100 Gbps private fiber connection from your data center to AWS → Lowest latency (~5–10 ms), consistent, no internet variability → Very common for banks, fintech, large enterprises in India
• Site-to-Site VPN — encrypted tunnel over public internet → Cheaper, faster to set up, good for <1 Gbps needs
• AWS Transit Gateway — central hub to connect multiple VPCs + on-prem + Direct Connect + VPN

Hyderabad fintech example:

Head office in Financial District + data center in Madhapur → Direct Connect 10 Gbps link from data center to ap-south-2 → Transit Gateway in AWS connects VPCs + Direct Connect → Office laptops use Site-to-Site VPN to reach internal resources → Result: secure, low-latency access to RDS, S3, internal APIs — no public internet for sensitive traffic

D. Cross-Account & Cross-Region Connectivity

You have dev/staging/prod accounts, or partner accounts.

Main tools:

• VPC Peering — direct private connection between two VPCs (same or different accounts/regions)
• Transit Gateway — hub-and-spoke model for many VPCs + on-prem
• AWS PrivateLink — privately share service (e.g., your API) with another account without VPC peering
• Resource Access Manager (RAM) — share Transit Gateway, subnets, Route 53

Example: Your startup has separate AWS accounts for dev, staging, prod → Transit Gateway in shared networking account → All VPCs connect to Transit Gateway → private routing between environments → Partner fintech wants to call your payment API → you expose it via PrivateLink → they call privately without public endpoint

5. Quick Hands-On: Feel Basic Connectivity

1. VPC console → Your VPCs → see subnets (public/private)
2. Create VPC Endpoint for S3 → see how private subnet can reach S3 without NAT/IGW
3. Launch EC2 in private subnet → try curl s3.amazonaws.com → fails without endpoint
4. Add endpoint → curl works — private connectivity!

Summary Table – AWS Connectivity Cheat Sheet (2026)

Teacher’s final note: AWS Connectivity is the difference between “my app is running somewhere in the cloud” and “my app is fast, secure, compliant, and cheaply connected to users, databases, and my office”. Most production disasters in Hyderabad startups come from bad connectivity decisions (public database, no VPC endpoints, single-AZ, no Direct Connect for on-prem).

Got it? This is the “how everything actually talks to everything else” lesson.

Next?

• Step-by-step: Build secure VPC + private endpoints + NAT?
• Deep dive on Direct Connect vs VPN (when to pay for dedicated fiber)?
• Or CloudFront + ALB + PrivateLink full example?

Tell me — next whiteboard ready! 🚀🌐