Int-API-External

Inbound Flow (External Consumption):

1. External Caller: A third-party client initiates an HTTPS request over the public internet.
2. Edge Protection (WAF): The traffic hits a public-facing cloud edge where a Web Application Firewall inspects for malicious signatures (e.g., OWASP Top 10) and enforces rate limits.
3. API Gateway: The sanitized request reaches the API Gateway, which authenticates the caller (e.g., OAuth 2.0 / OIDC), terminates TLS, and routes the traffic to the private subnet.
4. Backend Workload: The internal microservice receives the request, processes the business logic, and returns the response.

Outbound Flow (Internal Egress):

1. Backend Workload: The internal service initiates a secure HTTPS request to a partner API.
2. Egress Gateway / NAT: Because the workload sits in a private subnet with no direct Public Internet access, the traffic routes through a Managed NAT/Egress Gateway. This gateway enforces outbound FQDN whitelisting and performs network address translation.
3. External Target: The partner system receives the request originating from a static, whitelisted cloud egress IP.

• Strong perimeter security and centralized governance vs the added latency and single-point-of-failure risk of routing all traffic through gateway hops.
• Static, whitelistable egress IPs and outbound filtering vs the operational cost of maintaining highly available NAT/Egress infrastructure.
• Decoupled, versioned API contracts vs the discipline required to manage lifecycle, deprecation, and backward compatibility for external consumers.
• Backend workloads shielded in private subnets vs increased network complexity and more components to configure, monitor, and secure.

Consider a global hotel group that exposes a room-availability and booking API to online travel agencies and metasearch partners. Their inbound HTTPS calls strike a Web Application Firewall that screens for OWASP Top 10 signatures and throttles abusive traffic before the API Gateway validates each partner via OAuth 2.0, terminates TLS, and routes the request to a reservations microservice locked inside a private subnet. When that same service confirms a corporate rate against an airline's loyalty API, it egresses through a managed NAT gateway enforcing FQDN whitelisting, so the airline sees a single static, pre-approved IP. Versioned URI contracts shield agency integrations from breaking changes, gateway configs ship via GitOps pipelines, and OpenTelemetry traces on both hops give the group end-to-end visibility across the perimeter.

• Protocol & Format: The backend workload providing the API endpoint should use modern synchronous protocols (REST, GraphQL, or gRPC) or legacy protocols (SOAP) over HTTPS. Use standard data formats such as JSON, XML, or Protobuf.

• API Design & Documentation: Describe the API using standard machine-readable specifications (e.g., OpenAPI Specification/Swagger, WSDL). Information objects exchanged must be based on a common vocabulary or industry-standard data models.

• API Management & Lifecycle: Implement a strict versioning strategy (e.g., URI or Header-based) for inbound APIs to avoid breaking changes for external consumers. Treat API Gateway configurations as code (IaC/GitOps) deployed via CI/CD pipelines.

• Pattern Delegation: If the APIs exposed by the provider system require complex data transformations, protocol translation, or multi-step orchestration, delegate these responsibilities to the Middleware-External pattern rather than building complex logic into the API Gateway.

• Outbound Rules: If the internal application initiates the connection, it must not possess direct Public Internet access. The outbound connection must be routed through a highly available Egress Gateway or NAT gateway for centralized egress filtering.

• Observability: Enable centralized logging, metrics (latency, error rates, traffic), and distributed tracing (e.g., OpenTelemetry) on both the API Gateway and Egress Gateway to track cross-boundary request lifecycles.