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

Key Differences

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.

{
  "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.

# 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.

The post API Gateway versus Transit Gateway appeared first on AWS Security Architect.