Lab 4: Networking & Content Delivery

"VPC and more" wizard do minute mein sab kuch bana deta hai, lekin tab tumhe pata hi nahi chalta ki kya-kya bana aur kyun. Isliye ek baar sab kuch haath se banao. Production mein yahi kaam baad mein Infrastructure as Code se hota hai, jo tum Lab 5 mein seekhoge.

1. VPC console mein Your VPCs → Create VPC kholo aur VPC only chuno. Naam deepdive-vpc rakho, IPv4 CIDR 10.0.0.0/16 daalo, IPv6 mat chuno aur Create dabao.
2. VPC select karo, Actions mein Edit VPC settings kholo aur Enable DNS hostnames pe tick lagao (DNS resolution pehle se chalu hota hai), phir Save karo. Private hosted zones aur kai doosri services iske bina theek se kaam nahi karti.

• deepdive-vpc 10.0.0.0/16 ke saath bana hai, aur DNS hostnames aur DNS resolution dono chalu hain.
• Tumne dekha ki VPC ke saath ek "main" route table, ek default NACL aur ek default security group apne aap ban gaye.

PL-065 course se — asli console reference

VPC create karne ka wahi form — CIDR range yahan alag hai (course mein 14.0.0.0/16, is lab mein 10.0.0.0/16).

VPC console mein Subnets → Create subnet kholo, VPC mein deepdive-vpc chuno, aur "Add new subnet" dabake ek hi screen pe neeche ke chaaron subnets banao:

Is waqt yeh chaaron subnets bilkul ek jaise hain. Koi subnet apne naam se public ya private nahi banta; woh apni route table se public ya private banta hai, jo tum agle step mein karoge.

Do AZs isliye chahiye kyunki ek to isse high availability milti hai, aur doosra, Application Load Balancer banane ke liye kam se kam do AZs mein subnets hona zaroori hai. Agar sirf ek AZ ho, toh ALB banega hi nahi.

• Chaar subnets bane hain, har AZ mein ek public aur ek private, aur har subnet mein "Available IPv4 addresses" 251 dikh raha hai.

PL-065 course se — asli console reference

Subnet create karne ka wahi form.

1. Internet gateways → Create kholo, naam deepdive-igw rakho aur Create dabao. Phir Actions mein Attach to VPC chun ke use deepdive-vpc se jodo.
2. Route tables → Create kholo, naam deepdive-public-rt rakho, VPC mein deepdive-vpc chuno aur Create dabao.
3. Is route table ke Routes tab mein Edit routes dabao aur ek route jodo: destination 0.0.0.0/0 aur target Internet Gateway mein deepdive-igw. Phir Save karo.
4. Subnet associations tab mein Edit dabao, public-a aur public-b pe tick lagao aur Save karo.
5. Subnets mein public-a kholo, Actions mein Edit subnet settings chuno, Enable auto-assign public IPv4 address pe tick lagao aur Save karo. public-b ke liye bhi yahi karo.

• Internet Gateway deepdive-vpc se "Attached" hai.
• deepdive-public-rt mein 0.0.0.0/0 → igw-... route hai aur do subnets us se jude hain.

PL-065 course se — asli console reference

Internet Gateway banake VPC se attach karna, aur route table mein 0.0.0.0/0 → IGW daalna.

Private subnet ke servers ko bhi bahar jaana padta hai, jaise dnf install ke liye, OS updates ke liye, aur AWS APIs (Session Manager, ECR) tak pahunchne ke liye. NAT Gateway in servers ke bahar jaane wale traffic ko apne Elastic IP ke peeche chhupa deta hai, jabki bahar se koi naya connection andar nahi aa sakta. NAT Gateway khud public subnet mein rehta hai, kyunki use Internet Gateway tak pahunchna hota hai.

1. NAT gateways → Create NAT gateway kholo. Naam deepdive-nat rakho, subnet mein deepdive-public-a chuno, connectivity type Public rakho, agar "Availability mode" ka option dikhe toh Zonal chuno, Allocate Elastic IP dabao aur Create karo.
2. Status ke "Available" hone tak ruko, jisme 1–2 minute lagte hain, aur NAT ka Elastic IP note kar lo.
3. Route tables → Create kholo aur naam deepdive-private-rt rakho. Iske Routes mein 0.0.0.0/0 → NAT Gateway (deepdive-nat) jodo, aur Subnet associations mein private-a aur private-b jodo.

• NAT Gateway Available hai, public-a mein hai, aur uske paas Elastic IP hai.
• deepdive-private-rt mein 0.0.0.0/0 → nat-... route hai aur private-a aur private-b us se jude hain.

PL-065 course se — asli console reference

NAT Gateway create karna — public subnet mein, Elastic IP ke saath.

Is design mein suraksha ki layers hain: internet sirf ALB tak pahunch sakta hai, aur web servers sirf ALB se aane wala traffic lete hain. Web servers ke rule ka source koi IP range nahi, balki ALB ka security group hai. ALB ke IP addresses samay ke saath badalte rehte hain, lekin security group ka reference kabhi nahi badalta, isliye yeh tareeka zyada bharosemand hai.

EC2 console mein Security Groups → Create kholo aur VPC mein deepdive-vpc chun ke neeche ke do security groups banao:

Web servers ke security group mein SSH (port 22) ka koi rule nahi hai, kyunki un tak pahunchne ke liye tum Session Manager use karoge.

• deepdive-web-private-sg ke inbound rule ka source sg-... hai, koi IP address nahi.

Lab 2 wali userdata.sh file use karo, jo nginx install karke instance ID aur AZ wala page banati hai. EC2 console mein Launch instances se neeche ke do instances banao:

Dono ke liye baaki settings ek jaisi rakho: Amazon Linux 2023 AMI, free-tier instance type, koi key pair nahi, VPC deepdive-vpc, security group deepdive-web-private-sg, IAM instance profile deepdive-ec2-role, aur user data mein userdata.sh ka content.

Kram yahan bahut zaroori hai: instances launch karne se pehle NAT Gateway ka "Available" hona zaroori hai, kyunki user-data ka dnf install nginx boot hote hi NAT ke through internet pe jaata hai.

• Dono instances chal rahe hain, kisi ka bhi public IP nahi hai, aur dono alag-alag AZs mein hain.

web-1 select karo, Connect dabao aur Session Manager se connect karo. Server ke paas public IP nahi hai, phir bhi connection ho raha hai, kyunki SSM agent NAT ke through AWS se juda hua hai. Andar yeh commands chalao:

curl -s localhost                       # nginx page
curl -s https://checkip.amazonaws.com   # yeh IP = tumhare NAT ka Elastic IP!
ip -4 addr show | grep inet             # 10.0.11.x — sirf private IP

Ab apne laptop se web-1 ke private IP pe curl ya ping karke dekho; kuch nahi hoga. Server bahar ja sakta hai, lekin bahar se koi andar nahi aa sakta. NAT Gateway ka poora maqsad yahi hai.

• checkip ka output NAT Gateway ke Elastic IP se match karta hai.
• Laptop se private IP tak pahunchna possible nahi hai.

1. EC2 console mein Target Groups → Create kholo. Target type mein Instances chuno, naam deepdive-web-tg rakho, protocol HTTP aur port 80 rakho, aur VPC mein deepdive-vpc chuno.
2. Health checks mein protocol HTTP aur path / rakho. Advanced settings mein healthy threshold 2, unhealthy threshold 2, interval 10 second aur timeout 5 second rakho, taaki demo mein natije jaldi dikhein.
3. Next dabao, web-1 aur web-2 select karo, Include as pending below dabao aur Create karo.

• Target group mein do targets register ho gaye hain. Abhi woh "unused" dikhenge, kyunki woh kisi ALB se jude nahi hain.

1. EC2 console mein Load Balancers → Create → Application Load Balancer kholo. Naam deepdive-alb rakho, scheme Internet-facing aur IP type IPv4 chuno.
2. Network mapping mein VPC deepdive-vpc chuno, aur us-east-1a ke liye deepdive-public-a aur us-east-1b ke liye deepdive-public-b chuno.
3. Security groups mein default wala hata do aur deepdive-alb-sg lagao.
4. Listener HTTP:80 ka default action "forward to deepdive-web-tg" rakho aur Create dabao. ALB lagbhag 3 minute "Provisioning" mein rehta hai aur phir "Active" ho jaata hai.

ALB ka DNS naam console se copy karo aur neeche wala loop chalao, jo das requests bhej ke ginta hai ki kaunse instance ne kitni requests ka jawab diya:

ALB_DNS=<DNS name from console>
for i in $(seq 1 10); do curl -s http://$ALB_DNS | grep -o 'i-[0-9a-f]*'; done | sort | uniq -c

• Target group mein dono targets "healthy" hain.
• curl wale loop mein dono instance IDs aaye, yaani ALB traffic ko baant raha hai.

PL-065 course se — asli console reference

Load balancer types compare karna aur ALB listener/routing banane ka console.

1. web-1 ke Session Manager shell mein sudo systemctl stop nginx chalao.
2. Lagbhag 20–30 second mein target group ke Targets tab mein web-1 unhealthy dikhega, aur reason mein "Health checks failed" likha hoga.
3. curl wala loop dobara chalao; ab sirf web-2 ka ID aayega, aur users ko koi error nahi dikhega.
4. web-1 pe sudo systemctl start nginx chalao. Kuch second mein web-1 phir healthy ho jaayega aur traffic dobara dono servers pe jaane lagega.

• Ek server down hone pe bhi site chalti rahi.
• Tum 502, 503 aur 504 errors ka farak samjha sakte ho.

Security group instance ya uske network interface (ENI) ke level pe lagta hai, stateful hota hai, aur usme sirf allow rules hote hain. Network ACL (NACL) poore subnet ke level pe lagta hai aur stateless hota hai, yaani jawab wale traffic ke liye bhi alag rule chahiye hota hai. NACL mein allow aur deny, dono rules ho sakte hain, aur rules number ke kram mein check hote hain: sabse chhota number pehle, aur jo pehla rule match karta hai wahi laagu hota hai. NACL ka asli kaam kisi khaas kharab IP ko poore subnet se block karna hai, jo security group kar hi nahi sakta kyunki usme deny rule nahi hota.

1. Apna public IP pata karo: curl -s https://checkip.amazonaws.com.
2. VPC console mein Network ACLs kholo aur deepdive-vpc ka default NACL select karo. Uske inbound rules dekho: rule 100 sab kuch ALLOW karta hai, aur rule * sab kuch DENY karta hai.
3. Edit inbound rules dabao aur ek naya rule jodo: rule number 90, type All traffic, source <TUMHARA_IP>/32, aur action Deny. Phir Save karo.
4. Ab curl -m 5 http://$ALB_DNS chalao; yeh timeout ho jaayega. Security group abhi bhi 0.0.0.0/0 ko allow kar raha hai, lekin NACL subnet ki seema pe hi traffic ko rok deta hai, isliye traffic security group tak pahunchta hi nahi.
5. Rule 90 ko delete karo, aur curl phir se chalne lagega.

• Deny rule lagne pe ALB tak pahunchna band ho gaya, aur hatane pe wapas chalu ho gaya.
• Tum samjha sakte ho ki custom NACL mein outbound "ephemeral ports 1024-65535" wala rule kyun chahiye hota hai. (Kyunki NACL stateless hai aur jawab wala traffic in ports pe jaata hai.)

PL-065 course se — asli console reference

NACL banake numbered allow/deny rules lagane ka wahi console.

Jab koi connection kaam nahi karta, toh sabse bada sawal hota hai ki traffic kahan ruk raha hai: security group pe, NACL pe, ya woh pahunch hi nahi raha. Flow logs har network interface pe hone wali har connection ki koshish ko record karte hain, jisme source, destination, port aur ACCEPT ya REJECT ka nateeja hota hai. Yeh security investigations aur connectivity debugging, dono ke liye bahut kaam aate hain.

Pehle ek IAM role banao jo Flow Logs service ko CloudWatch Logs mein likhne de, aur phir poore VPC ke liye flow log chalu karo:

VPC_ID=$(aws ec2 describe-vpcs --filters Name=tag:Name,Values=deepdive-vpc --query 'Vpcs[0].VpcId' --output text)

cat > fl-trust.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"vpc-flow-logs.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
cat > fl-perms.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["logs:CreateLogGroup","logs:CreateLogStream","logs:PutLogEvents","logs:DescribeLogGroups","logs:DescribeLogStreams"],"Resource":"*"}]}
EOF
FL_ROLE=$(aws iam create-role --role-name deepdive-flowlogs-role --assume-role-policy-document file://fl-trust.json --query Role.Arn --output text)
aws iam put-role-policy --role-name deepdive-flowlogs-role --policy-name write-logs --policy-document file://fl-perms.json
sleep 10

aws ec2 create-flow-logs --resource-type VPC --resource-ids $VPC_ID --traffic-type ALL \
  --log-destination-type cloud-watch-logs --log-group-name /deepdive/vpc/flowlogs \
  --deliver-logs-permission-arn $FL_ROLE --max-aggregation-interval 60

Ab E1 wala NACL deny rule apne IP ke liye dobara lagao, 5–6 baar curl -m 5 http://$ALB_DNS chalao, aur phir rule hata do. 5–10 minute baad CloudWatch mein Logs Insights kholo, log group /deepdive/vpc/flowlogs chuno aur yeh query chalao:

parse @message "* * * * * * * * * * * * * *" as ver, acct, eni, src, dst, sport, dport, proto, pkts, bytes, start, end, action, status
| filter action = "REJECT"
| stats count(*) as rejected by src, dport
| sort rejected desc
| limit 20

Nateeje mein tumhara IP port 80 ke saath REJECT hota dikhega. Saath hi tumhe internet ke kuch anjaan IPs bhi dikhenge jo port 22, 3389 ya 23 pe connect karne ki koshish kar rahe hain. ALB aur NAT ke public IPs pe har waqt aisi scanning hoti rehti hai, aur tumhare security groups unhe rok rahe hain.

• Flow log Active hai aur log group mein records aa rahe hain.
• Query ke nateeje mein tumhara IP REJECT ke saath dikha.
• Tumne kam se kam ek anjaan internet IP ka rejected scan dekha.

1. Route 53 mein Hosted zones → Create hosted zone kholo. Domain name deepdive.internal rakho, type Private hosted zone chuno, region us-east-1 aur VPC deepdive-vpc chuno, aur Create dabao.
2. Create record dabao aur naam app rakho. Type A rakho, Alias ko on karo, "Route traffic to" mein Alias to Application and Classic Load Balancer chuno, region us-east-1 aur load balancer deepdive-alb chuno, aur Create karo.
3. Ek aur record banao jiska naam web1 ho, type A ho, value mein web-1 ka private IP (10.0.11.x) ho aur TTL 60 ho.
4. Teesra record banao jiska naam www ho, type CNAME ho aur value app.deepdive.internal ho.

Ab web-2 ke Session Manager shell mein yeh commands chalao aur har jawab ko samjho:

sudo dnf install -y bind-utils
dig +short web1.deepdive.internal        # 10.0.11.x
dig +short app.deepdive.internal         # ALB ke public IPs
dig www.deepdive.internal                # ANSWER section: CNAME → app.deepdive.internal → A records
curl -s -m 5 http://web1.deepdive.internal   # web-1 seedha, VPC ke andar (web SG sirf ALB allow karta hai → yeh TIMEOUT hoga!)
curl -s http://app.deepdive.internal     # ALB ke through → chalega

Kya web1 wala curl timeout hua? Yeh bilkul sahi hai. deepdive-web-private-sg port 80 sirf ALB ke security group se allow karta hai. web-2 khud us security group mein hai, lekin woh rule ke source mein nahi hai, isliye use bhi andar nahi aane diya gaya. Isse samajh aata hai ki security groups VPC ke andar ke traffic pe bhi lagte hain. Aur agar tum apne laptop pe dig app.deepdive.internal chalaoge, toh kuch nahi milega, kyunki yeh private zone hai.

• dig ne A, Alias aur CNAME, teeno records resolve kiye.
• app.deepdive.internal se nginx ka page mila, jabki web1 pe seedha curl timeout hua, aur tum samjha sakte ho ki aisa kyun hua.

PL-065 course se — asli console reference

Hosted zone create karna aur pehla A record banana.

Is step mein tum ek hi naam canary.deepdive.internal ke do records banaoge, jinme se ek 90% traffic web-1 pe aur doosra 10% traffic web-2 pe bhejega.

Jab naya version release karna ho, toh use pehle sirf 10% users ko dikhaya jaata hai, aur sab theek rahe toh dheere-dheere weight badhaya jaata hai. Yahi tareeka multi-region migrations aur blue/green cutovers mein bhi use hota hai.

1. Hosted zone deepdive.internal mein Create record dabao. Naam canary, type A, value mein web-1 ka private IP, TTL 0, routing policy Weighted, weight 90 aur Record ID stable rakho.
2. "Add another record" dabao aur doosra record banao: naam canary, type A, value mein web-2 ka private IP, TTL 0, routing policy Weighted, weight 10 aur Record ID canary. Phir Create records dabao.

Ab web-2 ke Session Manager shell mein 200 DNS queries chala ke jawab gino:

for i in $(seq 1 200); do dig +short canary.deepdive.internal; done | sort | uniq -c

Tumhe lagbhag 180 aur 20 ka baantwara dikhega. Ab canary record ka weight 50 kar do aur loop dobara chalao. Kisi record ka weight 0 karne se uska traffic turant band ho jaata hai, jo ek instant rollback ka kaam karta hai.

• 200 queries mein lagbhag 90/10 ka baantwara dikha.
• Weight 50 karne pe baantwara badal gaya.

PL-065 course se — asli console reference

Weighted routing policy — wahi console, tumhara split 90/10 hoga is lab mein.

Failover ka matlab hai ki primary server down hote hi DNS apne aap secondary server ka jawab dene lage. Route 53 ke normal health checkers internet se check karte hain, isliye woh private IPs tak nahi pahunch sakte. Lekin ek health check CloudWatch alarm ki state pe bhi aadharit ho sakta hai, aur private resources ke liye yahi standard tareeka hai.

Pehle ek custom metric aur uske upar ek alarm banao. Real life mein yeh metric koi monitoring script ya Lambda function publish karta; yahan tum use haath se publish karoge:

# "web-1 zinda hai" signal (real life mein koi monitoring script/Lambda yeh publish karta)
aws cloudwatch put-metric-data --namespace DeepDive/Health --metric-name Web1Up --value 1
aws cloudwatch put-metric-alarm --alarm-name deepdive-web1-down \
  --namespace DeepDive/Health --metric-name Web1Up --statistic Minimum \
  --period 60 --evaluation-periods 1 --threshold 1 --comparison-operator LessThanThreshold \
  --treat-missing-data notBreaching

1. Route 53 mein Health checks → Create health check kholo. Naam web1-health rakho, "What to monitor" mein State of CloudWatch alarm chuno, region us-east-1 aur alarm deepdive-web1-down chuno, aur insufficient data ki halat ke liye Last known status chuno. Phir Create karo. Health check ka charge lagbhag $0.50 per month hai, isliye lab ke baad ise delete karna.
2. Hosted zone mein naya record banao: naam app2, type A, value mein web-1 ka IP, TTL 0, routing policy Failover, record type Primary, health check web1-health, aur Record ID primary. "Add another record" se doosra record banao: naam app2, type A, value mein web-2 ka IP, routing policy Failover, record type Secondary, aur Record ID secondary. Phir Create karo.

Ab web-2 ke shell mein ek loop chala ke DNS ka jawab dekhte raho, aur laptop se web-1 ko "down" ghoshit karo:

# web-2 shell:  watch the answer
while true; do printf "%s " "$(date +%T)"; dig +short app2.deepdive.internal; sleep 15; done

# laptop: web-1 ko "down" declare karo
aws cloudwatch put-metric-data --namespace DeepDive/Health --metric-name Web1Up --value 0
# 2-4 min: alarm ALARM → health check Unhealthy → dig answer web-2 IP
aws cloudwatch put-metric-data --namespace DeepDive/Health --metric-name Web1Up --value 1
# wapas web-1

• Healthy rehne pe web-1 ka IP aaya, "down" hone pe web-2 ka IP aaya, aur recovery ke baad phir se web-1 ka IP aaya.
• Tum samjha sakte ho ki private IPs ke liye alarm-based health check kyun chahiye hota hai.

PL-065 course se — asli console reference

Failover routing record — primary/secondary dropdown.

Ek naya bucket banao aur usme ek chhoti si HTML file upload karo:

export SITE_BUCKET=deepdive-site-$ACCOUNT_ID
aws s3 mb s3://$SITE_BUCKET
cat > index.html <<EOF
<!doctype html><html><body style="font-family:sans-serif">
<h1>DEEPDIVE via CloudFront</h1><p>Version 1 — $(date)</p>
</body></html>
EOF
aws s3 cp index.html s3://$SITE_BUCKET/index.html --content-type text/html

Yeh bucket private hi rahega, yaani Block Public Access chalu rahega, aur tumhe static website hosting chalu nahi karni hai.

• Browser mein https://<SITE_BUCKET>.s3.amazonaws.com/index.html kholne pe AccessDenied aata hai.

CloudFront duniya bhar mein 600 se zyada edge locations pe content cache karta hai, isliye Mumbai ke user ko Mumbai ki edge se aur US ke user ko US ki edge se content milta hai. Origin Access Control (OAC) ka matlab hai ki bucket ko sirf CloudFront padh sakta hai, aur seedha S3 URL kaam nahi karta. Isse users CDN ko bypass nahi kar paate, aur tumhe bucket public bhi nahi karna padta.

1. CloudFront console mein Create distribution dabao. Agar pricing plan ke baare mein poocha jaaye (Free ya Pay-as-you-go), toh lab ke liye Free ya Pay-as-you-go chuno.
2. Origin mein Amazon S3 chuno aur apna deepdive-site-... bucket select karo. Origin access mein Origin access control (recommended) ya "Allow private S3 bucket access to CloudFront" chuno, aur ek naya OAC banao ya maujooda chuno.
3. Default cache behavior mein viewer protocol policy Redirect HTTP to HTTPS rakho aur cache policy CachingOptimized chuno. Lab ke liye WAF chalu mat karo. Default root object mein index.html likho aur Create dabao.
4. Agar console "S3 bucket policy update" karne ka option de, toh use apply kar do. Agar nahi deta, toh "Copy policy" dabao aur S3 mein bucket ke Permissions tab mein Bucket policy wale hisse mein paste kar do. Policy kuch aisi dikhegi:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::deepdive-site-<ACCOUNT_ID>/*",
    "Condition": { "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::<ACCOUNT_ID>:distribution/<DISTRIBUTION_ID>"
    } }
  }]
}

Is policy ki Condition dhyan se padho. Iske hisaab se sirf tumhara distribution hi bucket padh sakta hai, kisi aur ka CloudFront distribution nahi. Distribution ke deploy hone mein lagbhag 3–5 minute lagte hain.

• https://dxxxx.cloudfront.net/ pe Version 1 wala page dikh raha hai.
• Seedha S3 wala URL abhi bhi AccessDenied de raha hai.

Neeche ke commands pehle cache ka MISS aur HIT dikhate hain, phir file badal ke dikhate hain ki purana content cache se aata rehta hai, aur ant mein invalidation se naya content laate hain:

CF=dxxxxxxxxxxxx.cloudfront.net
curl -sI https://$CF/ | grep -iE 'x-cache|age|x-amz-cf-pop'    # Miss from cloudfront
curl -sI https://$CF/ | grep -iE 'x-cache|age|x-amz-cf-pop'    # Hit from cloudfront, Age: N

sed -i.bak 's/Version 1/Version 2/' index.html
aws s3 cp index.html s3://$SITE_BUCKET/index.html --content-type text/html
curl -s https://$CF/ | grep Version       # abhi bhi Version 1! (cached, TTL 24h tak)

DIST_ID=$(aws cloudfront list-distributions --query "DistributionList.Items[?DomainName=='$CF'].Id" --output text)
aws cloudfront create-invalidation --distribution-id $DIST_ID --paths "/index.html"
# 1-2 min baad:
curl -s https://$CF/ | grep Version       # Version 2

x-amz-cf-pop header batata hai ki kaunsi edge location ne jawab diya; jaise BOM ka matlab Mumbai hai. Production ke liye ek achhi salaah yeh hai ki invalidation ki jagah file ke naam mein version ya hash daalo, jaise app.3f9a1c.js. Har naye deploy pe URL naya hoga, aur cache ki problem hi nahi aayegi.

• Pehli request pe Miss aur doosri pe Hit dikha.
• Nayi file upload karne ke baad bhi purana content aaya (TTL ki wajah se), aur invalidation ke baad naya content aaya.

Lambda console mein Create function dabao, naam deepdive-api-fn rakho, runtime Python 3.13 chuno, basic execution role rehne do, aur neeche wala code deploy karo:

import json
from datetime import datetime, timezone


def lambda_handler(event, context):
    # HTTP API (payload v2.0) event format
    method = event["requestContext"]["http"]["method"]
    path = event["rawPath"]
    params = event.get("queryStringParameters") or {}
    name = params.get("name", "cloud learner")

    body = {
        "message": f"Hello, {name}!",
        "method": method,
        "path": path,
        "source_ip": event["requestContext"]["http"]["sourceIp"],
        "time": datetime.now(timezone.utc).isoformat(),
    }
    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps(body),
    }

• Function deploy ho gaya hai.

1. API Gateway console mein Create API → HTTP API → Build kholo. Integrations mein Lambda chuno aur deepdive-api-fn select karo. API ka naam deepdive-http-api rakho aur Next dabao.
2. Routes mein method GET aur path /hello rakho, integration mein deepdive-api-fn chuno aur Next dabao. Stage ka naam $default rehne do, Auto-deploy chalu rakho aur Create karo.
3. API ka Invoke URL copy kar lo.

Ab alag-alag requests bhej ke dekho ki API kaise jawab deta hai:

API=https://xxxxxxxx.execute-api.us-east-1.amazonaws.com
curl -s "$API/hello?name=Asha" | python3 -m json.tool
curl -s -X POST "$API/hello"          # route defined nahi → {"message":"Not Found"}
curl -s "$API/other"                  # Not Found

• GET /hello JSON lauta raha hai aur name parameter sahi kaam kar raha hai.
• POST aur /other pe Not Found aaya, yaani API Gateway ne in requests ko Lambda tak jaane hi nahi diya.

Rate limiting tumhare backend ko teen cheezon se bachati hai: jaan-boojh ke kiya gaya misuse, bugs (jaise kisi client ka anant retry loop), aur achanak bada bill. Rate batata hai ki har second kitni requests lagataar aa sakti hain, aur burst batata hai ki ek saath kitni requests jheli ja sakti hain. Yeh "token bucket" naam ke tareeke se kaam karta hai.

1. API mein Protect → Throttling kholo, stage $default chuno, "Edit default route throttling" dabao, rate 2 aur burst 2 rakho aur Save karo.

Ab ek saath 30 requests bhejo aur gino ki kitni requests kis status code ke saath lautiin:

# 30 requests ek saath bhejo aur status codes gino
( for i in $(seq 1 30); do curl -s -o /dev/null -w "%{http_code}\n" "$API/hello" & done; wait ) | sort | uniq -c

Tumhe kuch 200 aur kaafi saare 429 Too Many Requests dikhenge. Test ke baad throttling ko hata do ya uski limit badha do.

• Burst ki limit ke upar 429 responses aaye.
• Tum samjha sakte ho ki har customer ke liye alag quota (API keys aur usage plans) chahiye ho toh REST API kyun chuni jaati hai.

1. EC2 console mein Security Groups → Create kholo, naam deepdive-nlb-sg rakho, VPC deepdive-vpc chuno, aur inbound mein TCP 80 ko 0.0.0.0/0 se allow karo.
2. deepdive-web-private-sg mein ek naya inbound rule jodo: HTTP 80, source deepdive-nlb-sg.
3. Target Groups → Create kholo, type Instances rakho, naam deepdive-nlb-tg rakho, protocol TCP aur port 80 chuno, VPC deepdive-vpc chuno, health check HTTP path / rakho, aur web-1 aur web-2 ko register karo.
4. Load Balancers → Create → Network Load Balancer kholo. Naam deepdive-nlb rakho, Internet-facing aur IPv4 chuno, VPC deepdive-vpc mein public-a aur public-b subnets chuno, aur security group deepdive-nlb-sg lagao (NLB pe security group sirf banate waqt hi lagaya ja sakta hai). Listener TCP 80 ko deepdive-nlb-tg pe forward karo aur Create dabao.

NLB ka DNS naam copy karo, dekho ki woh kaunse IPs pe resolve hota hai, aur phir requests bhej ke dekho ki dono servers jawab de rahe hain:

NLB_DNS=<NLB DNS name>
dig +short $NLB_DNS          # har AZ ka ek fixed IP (chaaho toh apne Elastic IPs de sakte ho)
for i in $(seq 1 10); do curl -s --no-keepalive http://$NLB_DNS | grep -o 'i-[0-9a-f]*'; done | sort | uniq -c

Agar targets unhealthy hon ya requests timeout ho rahi hon, toh yaad rakho ki client IP preservation ki wajah se packets tumhare laptop ke IP se aate hain. Pehle check karo ki web security group mein NLB security group wala rule maujood hai. Agar phir bhi kaam na kare, toh test ke liye web security group mein thodi der ke liye HTTP 80 ko 0.0.0.0/0 se allow kar do; kyunki servers private subnet mein hain, isliye internet se unhe phir bhi seedhe nahi chhua ja sakta.

• NLB active hai, dono targets healthy hain, aur curl se dono instance IDs aaye.
• dig ne har AZ ke liye ek IP diya, aur kuch minute baad dobara chalane pe bhi wahi IPs aaye.

web-1 pe nginx ke access log se dekho ki requests kis IP se aa rahi hain:

sudo tail -n 20 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c

ALB se aayi requests ka source ALB node ka private IP (10.0.1.x ya 10.0.2.x) hota hai, kyunki ALB Layer 7 pe kaam karta hai aur server se ek naya connection banata hai; asli client ka IP X-Forwarded-For header mein hota hai. NLB se aayi requests ka source tumhara public IP hota hai, kyunki NLB Layer 4 pe kaam karta hai aur packet ko aage bhej deta hai (ise client IP preservation kehte hain). Isi wajah se firewall jaise apps, gaming servers aur aise backends jo client IP ki whitelist rakhte hain, NLB pasand karte hain.

Header dekhne ke liye tum nginx ke log format mein $http_x_forwarded_for jod sakte ho. Ya ek simple test karo: curl -s http://$ALB_DNS -H "X-Test: 1" aur NLB pe bhi aisi hi request bhejo, aur dono ke logs compare karo.

• Access log mein ALB wala traffic private IP se aur NLB wala traffic tumhare public IP se aata dikha.

TLS termination ka matlab hai ki certificate ALB pe rakha jaata hai aur ALB hi HTTPS ko decrypt karta hai; ALB se targets tak traffic HTTP pe jaata hai. Asli setup mein ACM ka muft public certificate use hota hai, jiske liye domain aur DNS validation chahiye. Agar tumhare paas domain nahi hai, tab bhi poora tareeka practise kiya ja sakta hai: ek self-signed certificate bana ke use ACM mein import karke.

Pehle laptop pe ek self-signed certificate banao aur use ACM mein import karo:

openssl req -x509 -newkey rsa:2048 -nodes -days 30 \
  -keyout lab-key.pem -out lab-cert.pem -subj "/CN=app.deepdive.internal"
CERT_ARN=$(aws acm import-certificate --certificate fileb://lab-cert.pem --private-key fileb://lab-key.pem \
  --tags Key=Project,Value=deepdive --query CertificateArn --output text); echo $CERT_ARN

1. deepdive-alb-sg mein ek inbound rule jodo: HTTPS 443 from 0.0.0.0/0.
2. deepdive-alb ke Listeners tab mein Add listener dabao. Protocol HTTPS aur port 443 rakho, action "Forward to deepdive-web-tg" rakho, security policy default (recommended) rehne do, certificate source mein From ACM chuno aur apna imported certificate select karo, phir Add dabao.
3. HTTP:80 listener ko Edit karo aur default action ko Redirect to URL kar do, jisme protocol HTTPS, port 443 aur status code 301 ho. Phir Save karo.

Ab redirect, certificate error aur certificate ki details test karo:

curl -sI http://$ALB_DNS | grep -iE 'HTTP/|location'        # 301 → https://...
curl -s  https://$ALB_DNS                                   # FAIL: self-signed certificate
curl -sk https://$ALB_DNS | head -3                         # -k = trust skip → page
openssl s_client -connect $ALB_DNS:443 -servername $ALB_DNS </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Browser mein bhi page kholo; wahan "Not secure" ya "certificate not trusted" ki warning dikhegi. Iski do wajah hain: certificate kisi bharosemand Certificate Authority ne sign nahi kiya, aur uska naam ALB ke DNS naam se match bhi nahi karta. Agar tumhare paas asli domain hai, toh ACM mein Request public certificate chuno, app.yourdomain.com likho, DNS validation chuno aur "Create records in Route 53" dabao. Kuch minute mein certificate Issued ho jaata hai; use listener pe lagao, aur ACM use khud renew karta rahega. Dhyan rakho ki CloudFront ke liye certificate hamesha us-east-1 region mein banta hai.

• HTTP pe 301 aaya aur request HTTPS pe redirect hui.
• curl bina -k ke certificate error diya, aur -k ke saath page dikhaya.
• openssl ke output mein subject CN = app.deepdive.internal aur 30 din ki validity dikhi.

1. VPC console mein Endpoints → Create endpoint kholo. Naam deepdive-s3-gw rakho, AWS services mein com.amazonaws.us-east-1.s3 type Gateway chuno, VPC deepdive-vpc chuno, route table mein deepdive-private-rt chuno, policy Full access rakho aur Create dabao.
2. deepdive-private-rt ke Routes dekho; wahan ek nayi entry dikhegi: pl-xxxx (com.amazonaws.us-east-1.s3) → vpce-....
3. deepdive-vpc mein deepdive-endpoint-sg naam ka security group banao, jo inbound mein HTTPS 443 ko 10.0.0.0/16 se allow kare.
4. Ab teen Interface endpoints banao: com.amazonaws.us-east-1.ssm, ...ssmmessages aur ...ec2messages. Har ek ke liye VPC deepdive-vpc chuno, subnets mein private-a aur private-b chuno, security group deepdive-endpoint-sg lagao, aur Enable private DNS name pe tick lagao. Teeno ka kul charge lagbhag $0.06 per ghanta hai, isliye is part ke baad inhe delete kar dena.

• Private route table mein S3 prefix-list wala route dikh raha hai.
• Teeno interface endpoints Available hain.

1. deepdive-private-rt se 0.0.0.0/0 → NAT wala route delete kar do.
2. web-1 pe Session Manager ka naya session kholo. Is baar connection interface endpoints ke through banega. Andar yeh commands chalao:

export AWS_DEFAULT_REGION=us-east-1
curl -m 5 -s https://checkip.amazonaws.com || echo "internet: NO (NAT gone)"
aws s3 ls | head -3                                   # chalega — gateway endpoint
aws sts get-caller-identity --cli-connect-timeout 5 || echo "STS: NO endpoint → fail"
getent hosts ssm.us-east-1.amazonaws.com             # 10.0.x.x — private DNS se endpoint ENI ka IP

Is test se yeh saaf hota hai ki har AWS service ko apna alag endpoint chahiye. Humne STS ka endpoint nahi banaya tha, isliye STS wali command fail ho gayi. Bahut niyantrit companies, jaise bank, apne private subnets mein NAT rakhti hi nahi; woh sirf VPC endpoints ke through AWS services use karti hain.

3. Endpoint policy (optional): deepdive-s3-gw ki Policy ko Custom karo aur sirf arn:aws:s3:::deepdive-* aur arn:aws:s3:::deepdive-*/* pe s3:* allow karo. Ab is VPC se kisi aur bucket tak pahunchna band ho jaayega, jo data ko chupke se bahar le jaane (data exfiltration) ke khilaaf ek achha control hai.
4. Test ke baad NAT wala route wapas jod do.

• NAT ke bina internet fail hua, jabki S3 aur Session Manager chal gaye, aur STS fail hua.
• getent hosts ssm... ne ek private IP diya.

PL-065 course se — asli console reference

Session Manager NAT ke bina bhi chalta hai — yehi is proof ka core idea hai.