← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

⚖️ NAT gateway vs NAT instance — lesson 03

⏮️ Before the managed gateway (2015)

Everyone ran a NAT instance: an EC2 with source/destination check turned off and iptables masquerade; when it died, every private server lost the internet.

✅ फायदे

  • gateway: managed, redundant in its AZ, 5 Gbps growing to 100 Gbps
  • instance: can have security groups, port forwarding, no per-GB fee

❌ तोटे

  • gateway: per-hour + per-GB charges add up
  • instance: you patch, size, monitor and fail it over; it is a single point of failure

👍 वापरा जेव्हा

  • gateway: production, almost always
  • instance: tiny labs or when you need tricks a gateway cannot do

👎 दोनदा विचार करा जेव्हा

  • a t3.micro NAT instance carrying production traffic
  • a NAT gateway for a dev VPC that runs two hours a week

🏢 One NAT per AZ vs one shared NAT — lesson 04

⏮️ Before per-AZ design

One NAT in AZ-a served the whole VPC — fine until AZ-a had a bad day.

✅ फायदे

  • per AZ: an AZ failure only affects that AZ; no cross-AZ data charges
  • shared: one hourly charge instead of three

❌ तोटे

  • per AZ: three hourly charges
  • shared: one AZ failure cuts off every AZ, and every byte from other AZs pays cross-AZ transfer

👍 वापरा जेव्हा

  • production: one per AZ, each private route table points at its own AZ's NAT
  • dev/test: one shared NAT is an acceptable saving

👎 दोनदा विचार करा जेव्हा

  • production on one NAT
  • private route tables that all point at the same NAT by copy-paste

📌 IP allow-listing vs real authentication — lesson 05

⏮️ Before stable egress IPs

Partners could not allow-list you: your servers' public addresses kept changing.

✅ फायदे

  • the NAT's Elastic IP is fixed — partners can allow-list it
  • easy to explain to a partner's firewall team

❌ तोटे

  • every workload behind the NAT shares that IP — allow-listing trusts all of them
  • an IP is not an identity

👍 वापरा जेव्हा

  • partner firewalls, as one layer
  • together with mTLS, signed requests or API keys + auth

👎 दोनदा विचार करा जेव्हा

  • IP allow-listing as the only protection
  • rotating Elastic IPs without telling partners

🚇 NAT vs VPC endpoints — lessons 06, 07

⏮️ Before endpoints

All AWS API and S3 traffic from private subnets went through the NAT and paid its per-GB fee.

✅ फायदे

  • gateway endpoints for S3 and DynamoDB are free
  • interface endpoints keep traffic on AWS's network

❌ तोटे

  • endpoints only reach AWS services, not the internet
  • interface endpoints cost per hour per AZ

👍 वापरा जेव्हा

  • add S3 and DynamoDB gateway endpoints on day one
  • interface endpoints when NAT GB for a service is large, or no internet is allowed

👎 दोनदा विचार करा जेव्हा

  • pulling container images through the NAT at scale
  • a NAT just for S3

6️⃣ NAT for IPv4 vs egress-only internet gateway for IPv6 — lesson 07

⏮️ Before IPv6

IPv4 addresses ran out; NAT let many private addresses share one public one.

✅ फायदे

  • IPv6 addresses are globally unique — no translation needed
  • the egress-only IGW gives the same 'out only' rule, with no per-GB NAT fee

❌ तोटे

  • IPv6 needs dual-stack subnets and apps that speak IPv6
  • not every destination is on IPv6 yet (NAT64 + DNS64 help)

👍 वापरा जेव्हा

  • new VPCs: plan dual-stack
  • IPv6-only workloads: egress-only IGW

👎 दोनदा विचार करा जेव्हा

  • assuming an IPv6 subnet is private because it has no NAT
  • forgetting security groups for IPv6 rules