Transit Gateway vs API Gateway — and a Reference Architecture with NGINX

Key Differences

Aspect AWS Transit Gateway (TGW) API Gateway
Primary purpose Network-level hub to connect VPCs, on‑prem, SD‑WAN (L3 routing). Application/API front door to publish, secure, throttle, and monitor APIs (L7).
OSI layer Layer 3 (IP routing). Layer 7 (HTTP/HTTPS, WebSocket).
Traffic type Any IP traffic between networks/subnets. API requests/responses (REST/HTTP/WebSocket).
Controls Route tables, attachments, segmentation; relies on SGs/NACLs & firewalls for L4/L7. AuthN/Z (IAM, Cognito/JWT, Lambda authorizers), WAF, throttling, usage plans, transforms.
Typical use Hub‑and‑spoke between multiple VPCs and on‑prem; inter‑VPC segmentation. Expose internal/external APIs, per‑method policies, metering, dev portal.
Visibility/metrics VPC Flow Logs + TGW Flow Logs. Per‑route metrics, latency, errors, access logs.

Architecture Diagram

External APIs: Internet → WAF → API Gateway → (private integration via VPC Link) → ALB/NLB → NGINX → services.
Internal APIs: Internal clients → Corp Edge → Transit Gateway → (Internal VPC) → NGINX (internal) → services.

 

Security Policies

1) API Gateway (External)

  • Edge protections: WAF (OWASP, bot control, geo/IP blocks).
  • Auth: JWT (Cognito/OIDC), IAM SigV4, or Lambda authorizers.
  • Resource policies: Restrict by VPC Endpoint/CloudFront Distribution.
  • Threat controls: Throttling, quotas, usage plans, API keys.
  • Data protection: TLS 1.2+, request/response validation, payload limits, sensitive header redaction.
Example resource policy 
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "execute-api:Invoke",
    "Resource": "arn:aws:execute-api:us-east-1:123456789012:abcde12345/*/*/*",
    "Condition": {
      "StringNotEquals": {
        "aws:SourceVpce": "vpce-0abc123def4567890",
        "aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123ABC456DEF"
      }
    }
  }]
}

2) NGINX (Reverse Proxy)

  • Transport: Enforce TLS; mTLS for service-to-service.
  • Identity: Validate JWT (OIDC) or client certs.
  • Access control: Path/host routing, IP allow/deny for admin paths, tenant scoping.
  • Rate limiting: Per IP/token; connection/request limits.
  • Hygiene: Header normalization, body size caps, method allowlists.
  • Observability: Structured logs, correlation IDs.
Example NGINX snippet 
# mTLS
ssl_verify_client on;
ssl_client_certificate /etc/nginx/ca_bundle.pem;

# JWT validation (auth_jwt or OpenResty)
auth_jwt "closed api";
auth_jwt_key_file /etc/nginx/jwks.pem;

# Rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
server {
  listen 443 ssl http2;
  server_name api.example.com;

  limit_req zone=api burst=40 nodelay;
  client_max_body_size 5m;

  location /service-a/ {
    proxy_set_header Authorization $http_authorization;
    proxy_pass http://svc-a:8080;
  }
}

3) Transit Gateway (L3)

  • Segmentation: Separate TGW route tables per environment/domain.
  • Least-route: Propagate/associate only where needed; deny east‑west by default.
  • Inspection: Force inter‑VPC traffic via an inspection VPC/NVA firewall.
  • Adjacencies: Complement with Security Groups/NACLs; use VPC endpoints for private API consumption.
  • Observability: TGW + VPC Flow Logs for anomalous inter‑VPC flows.

Layered Security Summary

  1. Edge: WAF + API Gateway throttling/authorizers.
  2. VPC: NGINX enforces mTLS/JWT, routing, rate limits.
  3. Network Hub: Transit Gateway confines routes, funnels inspection.
  4. Workloads: SG/NACL and app‑level authorization/validation.