Apigee / API Gateway
Apigee and API Gateway are two different Google Cloud products that both market themselves around "API management" — and which one you pick differs by an order of magnitude in cost, capability, and operational weight. This is the same shape as the Looker / Data Studio confusion from Chapter 6: similar names, very different products, the right choice depends on what the team actually needs. The cardinal mistake in this chapter is treating them as synonyms.
Apigee X is Google's enterprise API management platform, originally acquired from the company called Apigee in 2016 and substantially rewritten on top of GCP. Full lifecycle management, developer portals, monetization, advanced policies, sophisticated analytics. API Gateway is a much lighter-weight managed service: an OpenAPI spec, a Cloud Run / Cloud Functions / App Engine backend, basic auth and rate limiting at the edge, a few clicks in the console. Both have a place; they almost never have the same place.
Two Different Products under One Label
The disambiguation pattern by now should be familiar. Both products handle HTTPS traffic to a backend service. Both terminate TLS, authenticate requests, enforce some kind of rate limit. Beyond that surface similarity, they diverge:
- Apigee is a platform — runtime gateway plus management plane plus developer portal plus analytics plus monetization. The team using it operates an internal API program with a dedicated owner, treats APIs as products, has external partners or developers consuming them.
- API Gateway is a thin layer — an HTTPS front door in front of one or a few backend services, mostly to enforce authentication and rate limits. The team using it has a few APIs, needs them online, does not run an "API program" as a business function.
If the team is asking "should we use Apigee or API Gateway", the answer is almost always API Gateway. Apigee is the right call only when its specific enterprise capabilities are concrete requirements, not nice-to-haves.
Apigee X — Enterprise API Management
What Apigee actually provides beyond a basic gateway:
- Policies — declarative mediation steps that transform requests and responses (rewrite headers, transform XML to JSON, enrich responses with cached data, enforce schema validation, route to different backends based on request content). The catalog of available policies is large.
- Developer portal — self-service registration for developers consuming your APIs, automatic API key issuance, documentation hosted with the API, sandbox endpoints for testing. The right tool when you have a public or partner-facing API program.
- Monetization — usage-based billing for API consumers, rate plans, quota enforcement linked to plans. For companies whose APIs are a product line, this is the differentiator.
- Analytics — detailed traffic and consumer behavior reporting, with dimensions Cloud Monitoring does not natively model (per-API-product traffic, per-developer consumption, latency by version).
- Threat protection — OWASP rules, schema validation, payload inspection. Distinct from Cloud Armor in that the rules live inside the API definition rather than at the LB layer.
API Gateway — Lightweight Managed Gateway
API GatewayTLS · validate OpenAPI · API key / JWT · rate limit
BackendCloud Run / Functions / App EngineAPI Gateway is much simpler. You write an OpenAPI specification describing the API's paths, parameters, and backend, deploy it, and Google provisions a managed HTTPS endpoint that terminates TLS, checks paths and parameters against the spec (request bodies are not schema-validated), authenticates via API keys or JWTs, enforces basic rate limits, and forwards to the backend service (Cloud Run, Cloud Functions, App Engine, or any HTTPS URL). The OpenAPI spec is the source of truth — changes are deployed by updating the spec and pushing a new version.
What API Gateway does not have: a developer portal with self-service registration, monetization, complex mediation policies, sophisticated per-consumer analytics. Most teams do not need those features for most APIs. When a team does need them, the gap is substantial enough that Apigee is the right move, not API Gateway with custom add-ons.
When to Choose Apigee vs API Gateway
Apigee X — enterprise API platform. The right choice when the organization runs an API program: external developers consume your APIs, you publish a developer portal, you monetize usage, you need complex mediation policies, you have a dedicated team responsible for the API platform.
API Gateway — lightweight managed front door. The right choice for almost everyone else: a few internal or partner APIs that need authentication and rate limiting, OpenAPI as the source of truth, and minimal operational surface. The default in 2026 for new GCP-native APIs.
The cost difference is roughly an order of magnitude. Apigee is priced for enterprise programs; API Gateway is priced per million requests at a small multiple of Cloud Run's own egress charge.
Apigee Monetization and Developer Portals
The two Apigee features that genuinely have no API Gateway equivalent. The developer portal is a hosted experience where third-party developers register, accept terms, receive API keys, browse documentation, and test endpoints — all without a human in the loop on the API provider side. Monetization turns API consumption into a billable line item: rate plans (free tier, pro tier, enterprise), per-call billing, prepaid quotas, integrated invoicing. For companies where APIs are sold as products (payment APIs, ML model APIs, data APIs), this is what Apigee is for.
If neither monetization nor a developer portal is on the requirements list, Apigee is probably overkill.
Gateway vs Direct LB+Cloud Armor
A third option that gets overlooked: sometimes no gateway is the right answer. An internal API consumed only by internal services can sit behind an external Application Load Balancer with Cloud Armor for WAF and rate limiting, plus IAP for authentication, without any of API Gateway or Apigee in the path. The LB does TLS termination, Cloud Armor does WAF and rate limits, IAP does auth, and the backend sees what it would have seen anyway. Adding a gateway in this case is operational overhead without benefit. Choose a gateway when you need OpenAPI-driven contract enforcement, API-key-based auth, or any of the gateway-specific features — not as a reflex for every API.
- Treating Apigee and API Gateway as the same product under different names. The cost and capability difference is huge; getting the name wrong leads to mis-scoped projects.
- Apigee chosen for simple HTTP fronting of a handful of internal services. The bill arrives; the developer portal sits unused; the monetization features are off; an API Gateway would have done the work at a fraction of the cost.
- API Gateway chosen when the team genuinely needs Apigee features — a partner developer portal, complex mediation, monetization. Custom add-ons accumulate until the team is rebuilding Apigee badly.
- Custom API gateway service running on GKE because "we wanted control". The team operates a stateful, security-critical proxy for years; a managed alternative would have done the work with less surface area.
- No rate limiting or quota at the gateway level. Backend services bear the load of misbehaving clients directly; a misbehaving downstream caller takes the API down.
- OpenAPI spec not used as the source of truth for API Gateway. The configuration lives only in the console; review and rollback become awkward.
- API Gateway as the default for new GCP-native APIs. Apigee only when its specific enterprise features are concrete requirements.
- OpenAPI specification in git as the source of truth. The console is for inspection; deploys go through the spec.
- Cloud Armor in front of the gateway for WAF and DDoS protection. Cloud Armor handles edge threats; the gateway handles API contracts and auth.
- Audit logging at the gateway layer. Every API call records identity, quota state, response — a single place to query during incidents.
- Rate limiting and quota configured before public traffic arrives. Tuning under attack is hard; tuning during testing is easy.
- When neither gateway is right (internal-only API with no contract enforcement need), be willing to skip both and front the backend with LB+Cloud Armor+IAP directly.
Knowledge Check
What is the principal difference between Apigee and API Gateway?
- They are two names for the same managed product, billed and configured identically against one shared SKU and one rate card, presented under different console labels chosen at project creation purely for different team sizes, with the label deciding only which dashboard theme and onboarding wizard the project happens to see
- They are two different products — Apigee X is an enterprise API management platform with developer portals, monetization, and complex policies; API Gateway is a lightweight OpenAPI-driven managed gateway. Cost and capability differ by roughly an order of magnitude.
- Apigee is the legacy on-prem version retained only for existing maintenance-contract customers; API Gateway is the modern cloud-native replacement that Google now steers all new projects toward, with the older product frozen at its final release and slated for shutdown once migrations complete
- Apigee handles REST and SOAP APIs only; API Gateway is the dedicated front door for gRPC and bidirectional streaming protocols, so the split is fundamentally about which wire protocols each one terminates rather than about scale or feature depth
When does Apigee genuinely earn its place over API Gateway?
- For any API sustaining more than 100 requests per second, since API Gateway is documented to hard-throttle and fall over above that threshold while Apigee is the only option Google certifies for sustained high-throughput production traffic at that rate
- When the organization runs an API program — external developers consume the APIs, a developer portal handles self-service onboarding, monetization is part of the business model, complex mediation policies are required
- Whenever the API needs OpenAPI-driven request and response schema validation enforced at the edge before traffic reaches the backend, since only Apigee can reject malformed payloads against the published contract and API Gateway passes everything straight through unchecked
- When the team prefers a single product brand across every API so dashboards, billing line items, and on-call runbooks all reference one tool, since standardizing on the enterprise platform everywhere is treated as a procurement requirement rather than a per-API technical decision
What is the source of truth for an API Gateway deployment?
- The Cloud Console UI; routes, backends, and auth rules are stored there as the canonical record, every edit flows through the graphical editor, and the rendered spec is merely a read-only export generated from that live database on demand
- The OpenAPI specification — paths, parameters, backends, auth, and rate limits live in the spec, which should sit in git so deploys are reviewable and rollbackable
- A managed Cloud SQL database that backs the gateway's configuration plane and holds every route, backend mapping, and policy row, which you query and patch with SQL statements to change how the gateway behaves at runtime
- A Terraform module that generates the gateway entirely at apply time, deriving routes, backends, and auth purely from resource blocks and leaving no persisted definition file anywhere, so the only record of the config is the state snapshot
When is no gateway at all the right answer for an API?
- Never — every public-facing API requires either Apigee or API Gateway sitting in the request path, because direct exposure of a backend service is blocked by an org-level GCP policy that refuses to route external traffic to anything without a managed gateway in front
- For internal APIs consumed only by internal services, where an external Application LB with Cloud Armor for WAF and IAP for auth covers what a gateway would do — without the extra hop and operational surface
- Only when the API serves fewer than 10 requests per minute; above that throughput a gateway becomes mandatory to absorb the connection load, because backends cannot hold open enough concurrent sockets to answer clients directly past that point
- When the backend runs on Cloud Run, which rejects API Gateway traffic by design and must always be fronted by a plain load balancer instead, since the gateway and Cloud Run are documented as mutually incompatible request targets
What is the most expensive mistake teams make when adopting Apigee?
- Failing to enable Apigee Sense for threat detection, leaving bot traffic and credential-stuffing attacks to reach the backend unchecked, so the platform's headline security analytics sit dark while attackers probe the unprotected origin freely
- Choosing it for simple HTTP fronting where API Gateway would have done the work at a small fraction of the cost — the developer portal sits unused, the monetization features are off, and the bill is enterprise-sized
- Deploying Apigee in a single region, when multi-region deployment is a hard production requirement and a single-region setup is rejected at launch, forcing an expensive re-architecture once the first regional outage takes the whole API program offline
- Using OpenAPI specs to define APIs, since Apigee ignores them in favor of its own proprietary definition format that must be authored by hand in the console, so any team that brings an existing spec wastes effort re-keying every endpoint
You got correct