What “Managed” vs “Self-Managed” Means in Practice
When beginners compare API gateway options, the most important first split is operational responsibility.
Managed gateway: the cloud provider runs the control plane and data plane (or most of it). You configure APIs, policies, and integrations; the provider handles patching, scaling, and much of the reliability work.
Self-managed gateway: you run the gateway software yourself (VMs, Kubernetes, containers). You gain portability and deeper control, but you own upgrades, scaling, security patching, and incident response.
In this chapter, AWS API Gateway and Azure API Management (APIM) represent managed options. Kong and NGINX represent self-managed options (though both also have managed/hosted offerings in the market; the comparison here focuses on the self-managed model).
Beginner Evaluation Categories (Decision Checklist)
1) Setup effort
Managed: faster “first API” time; less infrastructure to provision.
Continue in our app.
You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.
Or continue reading below...
Download the app
Self-managed: requires networking, TLS certificates, scaling strategy, and upgrade process.
2) Policy features
Look for built-in policy language, reusable policy sets, and environment-specific overrides (dev/test/prod).
Also check how policies are tested and promoted (UI vs GitOps).
3) Auth integrations
Check native integrations with your identity provider (IdP), support for enterprise SSO, and ease of configuring multiple auth methods per API.
For B2B/B2C, consider developer portal and subscription workflows.
4) Transformation capabilities
Verify whether transformations are declarative (policy-based) or require custom code/plugins.
Confirm support for common needs: header mapping, query rewriting, JSON/XML mapping, and request/response templates.
5) Rate limiting and traffic controls
Check granularity (per key, per user, per route), burst handling, and whether limits are enforced at edge or region.
For self-managed, confirm whether limits are local-only or require shared state (Redis/DB) for consistent enforcement across replicas.
6) Observability
Evaluate how easily you can export logs/metrics/traces to your existing tools, and whether correlation IDs are supported consistently.
For self-managed, ensure you can standardize access logs and metrics across environments.
7) Deployment model
Cloud-native: integrates tightly with cloud services and IAM.
Hybrid: can run close to on-prem systems while still being centrally managed.
Multi-cloud: consistent gateway behavior across providers.
8) Cost drivers
Managed: typically priced per request, per unit, or per capacity tier; costs rise with traffic and advanced features.
Self-managed: infrastructure + operations time; licensing may apply for enterprise features.
9) Vendor lock-in and portability
Managed services often tie you to provider-specific integrations and policy formats.
Self-managed gateways can be more portable, especially when configured via code and deployed on Kubernetes.
AWS API Gateway (Managed): Strengths, Limits, Typical Use Cases
Where it tends to fit best
Serverless and AWS-native backends where you want minimal ops and tight integration with AWS services.
Teams that prefer “configure and deploy” over running gateway infrastructure.
Spiky traffic where autoscaling without capacity planning is valuable.
Strengths beginners notice quickly
Fast setup: create an API, connect routes to AWS services, deploy stages.
Deep AWS integration: IAM-based access patterns, CloudWatch integration, and common AWS service integrations.
Managed scaling and availability: you don’t manage nodes, clusters, or patching.
Limits and “gotchas” to plan for
Policy and configuration portability: configuration is AWS-specific; migrating later may require re-implementing policies elsewhere.
Cost sensitivity at scale: per-request pricing can become a major driver for high-volume APIs, especially when combined with additional features.
Advanced gateway behaviors: some patterns may require combining multiple AWS services (for example, additional components for specialized edge routing or complex mediation).
Typical use cases
Public APIs for mobile/web apps hosted on AWS.
Serverless backends (Lambda) and event-driven APIs.
Internal APIs where AWS IAM alignment is a priority.
Practical step-by-step: a beginner decision test for AWS API Gateway
Use this quick test to decide if AWS API Gateway is a strong default for you:
Step 1: List your backends. If most are AWS-native (Lambda, AWS services, workloads in AWS), mark “strong fit”.
Step 2: Estimate traffic. If you expect high sustained RPS, do a rough cost estimate early and compare to self-managed options.
Step 3: Identify portability needs. If you must run the same gateway config on-prem or in another cloud, mark “risk”.
Step 4: Decide your ops posture. If you cannot commit to running gateway infrastructure, mark “strong fit”.
Azure API Management (Managed): Strengths, Limits, Governance Features
Where it tends to fit best
Enterprise and regulated environments that need strong governance, consistent policy enforcement, and a managed developer experience.
Organizations standardizing on Azure with centralized API programs.
Hybrid scenarios where you want a managed control plane with flexible connectivity to internal systems.
Strengths beginners notice quickly
Governance and API program features: strong support for organizing APIs, products, subscriptions, and onboarding.
Policy-driven configuration: a consistent policy model that can be applied at different scopes (global, API, operation).
Developer portal and lifecycle workflows: useful when you need a “front door” for internal/external consumers.
Limits and “gotchas” to plan for
Complexity of tiers and capacity: selecting the right tier/capacity can be confusing at first, and scaling choices affect cost and performance.
Azure-centric model: while it can front any HTTP backend, the operational model and integrations are optimized for Azure.
Change management: enterprise governance is a strength, but it can slow down teams if you don’t define lightweight processes.
Governance features to look for (and why they matter)
Products and subscriptions: package APIs for different consumer groups (internal teams, partners) with separate access controls.
Central policy enforcement: apply consistent rules across many APIs without duplicating configuration.
Environment separation: support for dev/test/prod with repeatable deployments (important for auditability).
Practical step-by-step: choosing APIM for an “API program”
Step 1: Identify whether you need a developer portal/subscriptions. If yes, APIM moves up the list.
Step 2: List governance requirements (approval flows, consistent policies, auditability). If these are strong requirements, APIM is often a better fit than lightweight gateways.
Step 3: Map your network reality (on-prem backends, private endpoints, hybrid connectivity). If hybrid is central, validate the deployment model early.
Step 4: Pick a tier based on expected traffic and features, then run a small pilot with 1–2 representative APIs before migrating everything.
Kong (Self-Managed): Gateway + Plugin Ecosystem
Where it tends to fit best
Kubernetes and multi-cloud environments where you want a consistent gateway across clusters/providers.
Teams comfortable operating infrastructure and wanting extensibility via plugins.
Organizations prioritizing portability and avoiding deep coupling to a single cloud gateway.
Strengths beginners notice quickly
Extensibility: a rich plugin model for adding gateway behaviors without rewriting the gateway.
Deployment flexibility: run on VMs or Kubernetes; place gateways close to services (east-west) or at the edge (north-south).
GitOps-friendly: configuration can be managed as code, which helps with repeatability.
Limits and “gotchas” to plan for
Operational overhead: you must manage scaling, upgrades, security patches, and capacity planning.
Stateful dependencies: some setups depend on a database/control plane components; you must design for HA and backups.
Plugin governance: plugin sprawl can happen; you need standards (approved plugins, version pinning, testing).
Practical step-by-step: evaluating Kong with a “plugin-first” pilot
Step 1: Choose one API that needs at least 2–3 gateway behaviors (for example: auth integration, request shaping, and rate control) so you can validate plugin coverage.
Step 2: Decide your deployment target (Kubernetes vs VM). If Kubernetes, plan ingress/service networking and horizontal scaling.
Step 3: Define a configuration workflow (Git repository + CI) and a promotion path (dev → staging → prod).
Step 4: Establish plugin standards: which plugins are allowed, how they are configured, and how changes are reviewed.
Step 5: Load test early to validate latency overhead and scaling behavior under your expected traffic patterns.
NGINX (Self-Managed): High-Performance Reverse Proxy That Can Act as a Gateway
Where it tends to fit best
Performance-sensitive routing where you want a lean, fast data plane.
Simple-to-moderate gateway needs where configuration-based routing and controls are sufficient.
Existing NGINX expertise in the team (ops familiarity can be a major advantage).
Strengths beginners notice quickly
Speed and efficiency: widely used for high-throughput reverse proxying and load balancing.
Flexible configuration: powerful routing, header manipulation, TLS termination, and upstream controls.
Deployment simplicity: easy to run on VMs or containers; fits well in front of monoliths or microservices.
Limits and “gotchas” to plan for
Gateway “product” features aren’t automatic: compared to managed gateways, you may need to assemble capabilities using modules, additional components, or custom configuration patterns.
Policy management at scale: large configurations can become hard to govern without strong conventions and automation.
Developer portal and API program features: typically not the focus; you may need separate tooling if you require subscriptions, onboarding, and catalog features.
Practical step-by-step: using NGINX as a lightweight gateway baseline
Step 1: Start with a single reverse-proxy route to one backend and enable TLS termination.
Step 2: Add standard headers and consistent request IDs (so downstream services can correlate requests).
Step 3: Introduce environment templating (for example, separate upstreams for dev/staging/prod) and store config in Git.
Step 4: Add controls incrementally (limits, allow/deny rules, caching where appropriate) and validate behavior with automated tests.
Step 5: Define an upgrade and reload strategy (zero-downtime reloads, rollback plan) before production rollout.
Side-by-Side Comparison by Category (Beginner-Focused)
Setup effort
AWS API Gateway: lowest infra effort; mostly configuration.
Azure APIM: low infra effort, but more concepts (products, subscriptions, policies) to learn.
Kong: moderate-to-high; you run it and its dependencies.
NGINX: moderate; simple to start, but you own everything around it (standards, automation, governance).
Policy features
AWS API Gateway: strong for AWS-centric patterns; policy model is service-specific.
Azure APIM: strong, centralized policy model with good governance alignment.
Kong: policy behaviors commonly implemented via plugins; flexible but requires standardization.
NGINX: configuration-driven; powerful but can become “handcrafted policy” unless you build reusable patterns.
Auth integrations
AWS API Gateway: best when identity and access are AWS-aligned.
Azure APIM: strong enterprise identity integration patterns and subscription-based access models.
Kong: broad support via plugins; good when you need to integrate with varied IdPs across environments.
NGINX: possible via modules/side components; may require more engineering for complex auth flows.
Transformation capabilities
AWS API Gateway: good for common mapping/templating; deeper mediation may require additional AWS components.
Azure APIM: strong policy-based transformations and mediation patterns.
Kong: plugin-based; flexible for custom needs if you can manage plugin lifecycle.
NGINX: supports many header/route transformations; complex payload transformations may require extra tooling or scripting approaches.
Rate limiting and traffic controls
AWS API Gateway: managed enforcement; easy to apply consistently.
Azure APIM: strong policy-based controls; good for product/subscription-based limits.
Kong: strong capabilities via plugins; confirm distributed enforcement design.
NGINX: strong primitives; distributed consistency is your responsibility in multi-instance setups.
Observability
AWS API Gateway: integrates naturally with AWS monitoring/logging ecosystem.
Azure APIM: integrates naturally with Azure monitoring/logging ecosystem.
Kong: flexible exporters/integrations; you assemble the pipeline and standards.
NGINX: excellent access logs and metrics options; you design dashboards, tracing propagation, and retention.
Deployment model
AWS API Gateway: AWS-managed; best for AWS-first architectures.
Azure APIM: Azure-managed with strong enterprise/hybrid patterns.
Kong: portable across clouds and on-prem; strong Kubernetes story.
NGINX: portable everywhere; often used as a universal front proxy.
Cost drivers
AWS API Gateway: request volume, features, and data transfer patterns.
Azure APIM: tier/capacity selection, scale units, and feature set.
Kong: compute + ops time; enterprise licensing if needed.
NGINX: compute + ops time; commercial licensing if using advanced modules/support.
Vendor lock-in
AWS API Gateway: higher; configuration and integrations are AWS-specific.
Azure APIM: higher; policy model and ecosystem are Azure-centric.
Kong: lower-to-moderate; portable, but plugin choices can create “ecosystem lock-in”.
NGINX: low-to-moderate; configuration is portable, but you may build custom patterns that are hard to migrate.
Choosing Based on Your Environment and Team
If you are cloud-native in one provider
AWS-first: AWS API Gateway is often the simplest operational choice when most backends and identity live in AWS.
Azure-first: Azure APIM is often the best choice when you need an API program with governance and a managed developer experience.
If you are hybrid (cloud + on-prem)
Azure APIM: commonly chosen when governance and centralized management are required across environments.
Kong or NGINX: strong when you need the same gateway runtime deployed near on-prem systems and also in cloud, with consistent behavior.
If you are multi-cloud or portability is a hard requirement
Kong: a strong default when you want a gateway “platform” with extensibility and consistent deployment across clusters.
NGINX: a strong default when you want a lightweight, universal reverse proxy/gateway and you can accept building some higher-level API program features separately.
If your team’s operations maturity is limited
Prefer managed (AWS API Gateway or Azure APIM) when you cannot commit to patching, scaling, and 24/7 operations for gateway infrastructure.
Use self-managed only if you can define: ownership, on-call, upgrade cadence, security patch SLAs, and automated deployments.
Practical step-by-step: a simple selection workflow for beginners
Step 1: Pick your “home” environment. If 80%+ of workloads are in AWS, start with AWS API Gateway; if in Azure, start with APIM. If neither, start with Kong or NGINX.
Step 2: Decide if you need an API program. If you need a built-in developer portal, subscriptions, and strong governance, prioritize Azure APIM (or plan additional tooling with self-managed gateways).
Step 3: Decide your portability requirement. If you must be able to move clouds/on-prem with minimal rework, prioritize Kong/NGINX and keep configuration in Git.
Step 4: Run a 2-API pilot. Choose one simple API and one “realistic” API with multiple policies. Measure setup time, change workflow, latency impact, and operational burden.
Step 5: Document cost and ops assumptions. For managed: estimate request-based costs at expected traffic. For self-managed: estimate compute plus the human cost of operating and upgrading.
Concrete “Typical Choice” Patterns
Pattern A: Startup on AWS with serverless backends
Common choice: AWS API Gateway to minimize ops and integrate tightly with AWS services.
Pattern B: Enterprise on Azure with many internal consumers
Common choice: Azure APIM for governance, products/subscriptions, and centralized policy management.
Pattern C: Platform team running Kubernetes across environments
Common choice: Kong for a consistent gateway runtime and plugin-based extensibility.
Pattern D: Need a fast, reliable front proxy with minimal “API program” needs
Common choice: NGINX as a high-performance gateway baseline, with additional tooling added only when needed.
