AWS Infrastructure

EC2 — Instance Selection & Strategy

Why t3/t3a for Node.js?

• t3.medium (2 vCPU, 4GB RAM): ideal for Node.js I/O-bound workloads. Node is single-threaded; you rarely saturate 2 vCPUs except under heavy CPU work (crypto, image processing).
• Burstable CPU: t3 instances accumulate CPU credits during low traffic, spend them during peaks. Perfect for a commerce platform with evening delivery spikes.
• t3a = AMD chips, ~10% cheaper than t3 (Intel), same performance for Node.js.
• AMI strategy: custom AMI with Node.js, PM2, and app dependencies pre-installed. Launch time: ~60s vs 3-5min if installing at boot. Faster auto-scaling response.

NGINX — Reverse Proxy Configuration

# /etc/nginx/sites-available/app
upstream nodejs {
    server 127.0.0.1:3000;
    keepalive 64;  # keep upstream connections alive — avoids TCP handshake per req
}

server {
    listen 443 ssl http2;
    server_name api.zoober.in;

    # SSL termination here — Node.js handles plain HTTP internally
    ssl_certificate     /etc/letsencrypt/live/api.zoober.in/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.zoober.in/privkey.pem;

    # Gzip compression for JSON responses
    gzip on;
    gzip_types application/json text/plain;
    gzip_min_length 1000;

    # Rate limiting (token bucket) — 100 req/s per IP, burst 200
    limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;

    location /api/ {
        limit_req zone=api burst=200 nodelay;
        proxy_pass http://nodejs;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;    # WebSocket upgrade
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 86400;  # WebSocket long-lived connections
    }

    # Static files served directly by NGINX — bypasses Node.js entirely
    location /public/ {
        root /var/www/app;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

CloudFront — CDN & Cache Strategy

What CloudFront does in this architecture

• Static assets: JS/CSS/images served from edge locations, TTL=1 year. Cache hit = ~5ms vs 100-300ms to origin.
• API caching: Store catalog endpoints cached at edge with Cache-Control: max-age=300. Reduces backend load during traffic spikes.
• Origin group for HA: primary origin = ALB, failover origin = S3 static site. If ALB is down, static error page served from S3.

Cache behaviors by path

• /api/* → TTL=0 (no cache), forward all headers, forward cookies
• /public/* → TTL=31536000s (1 year), compress=true
• /catalog/* → TTL=300s (5 min), Vary: Accept-Encoding

Invalidation strategy

When a store updates their catalog, the backend calls CloudFront.createInvalidation({ paths: ['/catalog/store-id/*'] }). Wildcard invalidations cost $0.005 each, so they're triggered only on catalog updates, not on every order.

Signed URLs for private content

// Generate a pre-signed URL for a private S3 object via CloudFront
const { getSignedUrl } = require('@aws-sdk/cloudfront-signer');

const url = getSignedUrl({
  url: `https://cdn.zoober.in/uploads/${filename}`,
  keyPairId: process.env.CF_KEY_PAIR_ID,
  privateKey: process.env.CF_PRIVATE_KEY,
  dateLessThan: new Date(Date.now() + 15 * 60 * 1000), // 15min expiry
});

WAF — Web Application Firewall

Rule groups in use

• AWS-AWSManagedRulesCommonRuleSet: OWASP Core — blocks LFI, XSS, RCE, scanner probes
• AWS-AWSManagedRulesSQLiRuleSet: SQL injection patterns
• Custom rate rule: 100 requests per 5 minutes per IP per path — triggers 429 before NGINX rate limiter
• Geo-blocking: optional, blocked suspicious regions during a scraping incident

S3 — Storage Architecture

Bucket structure

• zoober-public-assets: product images, store logos — public read via CloudFront OAC (Origin Access Control), no direct public URL
• zoober-private-uploads: rider documents, payment receipts — private, accessed only via pre-signed URLs
• zoober-logs: ALB access logs, CloudFront logs — lifecycle policy: move to S3 Glacier after 30 days

Presigned URL upload flow

// Client requests upload URL from backend
// Backend generates presigned URL (never exposes S3 credentials to client)
const { S3Client, PutObjectCommand } = require('@aws-sdk/client-s3');
const { getSignedUrl } = require('@aws-sdk/s3-request-presigner');

const url = await getSignedUrl(s3Client, new PutObjectCommand({
  Bucket: 'zoober-private-uploads',
  Key: `riders/${riderId}/${filename}`,
  ContentType: 'image/jpeg',
}), { expiresIn: 300 }); // 5 min

// Client uploads directly to S3 using presigned URL — zero load on our server
// Backend then updates DB with S3 key after client confirms upload

SES — Transactional Email

Use cases

• Order confirmation emails (with itemized receipt)
• OTP delivery for phone verification
• Rider assignment notifications
• Admin alerts for payment failures

Deliverability setup

• DKIM: SES-generated 2048-bit key, DNS TXT record
• SPF: v=spf1 include:amazonses.com ~all
• DMARC: v=DMARC1; p=quarantine; rua=mailto:dmarc@zoober.in
• Bounce handling: SNS topic → Lambda → marks email as invalid in DB. Prevents sending to bounced addresses (affects SES reputation score).

Auto-Scaling

ASG configuration

• Target tracking policy: CPU utilization target = 60%. ASG adds instances when CPU > 60% sustained for 2 minutes.
• Scale-out cooldown: 300 seconds — prevents flapping (adding then immediately removing instances)
• Scale-in protection: instances with active WebSocket connections have a termination hook that waits for connections to drain (max 30s)
• Min/max: min=2 (HA, survives AZ failure), max=10

Blue-Green Deployments