API Management self-hosted gateway

Architecture context

Security: Security requires treating the self-hosted gateway as production infrastructure, not just an API Management setting. The container needs outbound connectivity to its API Management configuration endpoint, secure authentication to the service, TLS settings, protected secrets, and controlled network placement near backends. Custom domains, certificates, image versions, and configuration backup need review. Because traffic may stay outside Azure, local firewall rules, Kubernetes access, logging, and certificate handling become critical. Operators should avoid rolling tags in production unless they deliberately accept automatic gateway image changes. Security reviewers should confirm the approved scope, identity path, and logging behavior before production release. Temporary exceptions should have owners, expiration dates, and evidence of removal. Reliability: Reliability depends on gateway replicas, container health, local network stability, configuration backup, and connectivity back to the API Management management plane. If Azure connectivity is interrupted, running gateways can continue with in-memory configuration, and backup can help stopped gateways restart with saved configuration. Teams should monitor heartbeat, configuration-sync status, pod restarts, CPU, memory, and backend latency. High availability requires more than enabling the feature; it needs replica placement, persistent backup storage where used, version-pinning, and tested recovery from node, network, and configuration failures. Reliable teams test the setting in nonproduction, document rollback values, and monitor the first production signals after change. Operations: Operations teams manage self-hosted gateways like both API infrastructure and container workloads. They deploy images, pin versions, configure environment variables, rotate secrets or tokens, monitor heartbeat, review policy synchronization, and coordinate APIM configuration changes with platform releases. Kubernetes operators should watch pod health, ingress rules, persistent volumes for backup, and network policies. API owners still use API Management for products, operations, and policies, while platform teams own runtime placement. Clear ownership is essential because gateway failures can look like backend failures to consumers. Runbooks should include owners, commands, expected outputs, review cadence, and the first checks to perform during incidents. Cost: Self-hosted gateways can reduce data-transfer or latency-related costs when APIs and clients are near local backends, but they add infrastructure costs where the gateway runs. Kubernetes nodes, container runtime, logging, persistent storage, monitoring, and support effort all count. API Management tier requirements also matter. Cost reviews should compare managed-gateway traffic through Azure with local gateway hosting, especially for high-volume internal APIs. Overprovisioned replicas, excessive telemetry, and unnecessary gateways in every environment can erase expected savings, so capacity should match measured request volume and resilience needs. Cost owners should review usage, diagnostics, and duplicated environments whenever the setting changes or traffic grows. Performance: Performance improves when the gateway is placed close to backend APIs or clients that would otherwise route through a distant Azure region. Local placement can reduce latency and data transfer, but container sizing, policy complexity, TLS termination, DNS, and backend proximity still determine real throughput. Operators should benchmark native backend calls, managed-gateway calls, and self-hosted-gateway calls under realistic load. Scaling replicas, pinning versions, reducing heavy policies, and monitoring local network constraints help. A self-hosted gateway should be measured as a runtime component, not assumed faster by design. Performance reviews should compare before-and-after telemetry and separate gateway, identity, network, and backend effects.