If you need to route API traffic across multiple clouds and on-prem, with decisions based on region and tenant, you should evaluate an API gateway as more than just a proxy. You want a platform that can act as a global traffic control plane and a policy enforcement point.

Here’s the checklist I’d use.

1) Traffic routing capabilities

Make sure it can route on more than just host/path.

Look for:

• Geo/region-aware routing
• Tenant-aware routing based on:
  • JWT claims
  • API keys
  • mTLS client certs
  • headers
  • request context
• Weighted routing / canary / blue-green
• Failover routing across regions and clouds
• Latency-based routing if you want nearest or fastest backend
• Health-check-based routing
• Sticky sessions only if your APIs truly need them

Ask:

• Can I send tenant A in EU to EU-West, but tenant B in EU to a private datacenter?
• Can routing decisions use identity claims, not just URL rules?
• Can I define fallback behavior if a region is down?

2) Multi-cloud and hybrid deployment model

You’ll want to know whether the gateway is:

• Centralized control plane + distributed data planes
• Per-region gateways with shared policy
• Managed SaaS
• Self-managed / Kubernetes-native
• Runs on-prem and in all target clouds

Evaluate:

• Ease of deploying in AWS, Azure, GCP, and on-prem
• Whether the same config/policies work everywhere
• Support for Kubernetes, VM, bare metal
• Ability to keep traffic/data regional for compliance
• Whether it needs a central controller that could become a dependency

Ask:

• Can I run the data plane locally in each region?
• Can policies be pushed from one control plane to many runtimes?
• Does the platform support disconnected or air-gapped environments?

3) Tenant isolation and multi-tenancy

This is critical if different tenants have different routing, auth, quotas, or backends.

Look for:

• Tenant-specific routing rules
• Namespace/project/org isolation
• Per-tenant:
  • quotas
  • auth policies
  • rate limits
  • SLAs
  • certificates/secrets
• Config inheritance with overrides
• Strong separation of:
  • admin access
  • logs
  • metrics
  • secrets

Ask:

• Can tenants share the same gateway cluster safely?
• Can one tenant’s policy change impact another tenant?
• Can I delegate management to teams without full platform access?

4) Policy and authentication flexibility

Since tenant and region routing often depend on identity, policy engine matters.

Evaluate support for:

• OAuth2 / OIDC
• JWT validation and claim-based routing
• mTLS
• API keys
• External auth / OPA / custom authorizers
• Header manipulation and enrichment
• Schema validation
• Threat protection and WAF integration

Ask:

• Can I route by JWT tenant_id, region, or entitlement claim?
• Can I call out to an external policy engine?
• Can I combine authN, authZ, and routing in one policy flow?

5) Resilience and high availability

Across clouds and regions, the gateway itself must not be a single point of failure.

Check for:

• Active-active support
• Cross-region failover
• Automated backend health checks
• Control plane redundancy
• Local enforcement when control plane is unavailable
• Graceful degradation
• Timeouts, retries, circuit breaking, bulkheads

Ask:

• If the gateway management plane is unavailable, does traffic keep flowing?
• Can I fail over between cloud regions without manual intervention?
• Can I prevent retry storms during partial outages?

6) Performance and scalability

Routing logic for tenant/region can add overhead.

Measure:

• Latency added by the gateway
• Throughput at peak
• Horizontal scaling behavior
• Connection pooling / HTTP2 / gRPC support
• TLS termination performance
• Rate limit enforcement efficiency
• Impact of custom scripts/plugins

Ask:

• What is p95/p99 latency overhead?
• How does performance change with policy complexity?
• Can it handle east-west and north-south traffic if needed?

7) Observability and traceability

You need to know where traffic went and why.

Ensure support for:

• Centralized logs
• Metrics
• Distributed tracing
• Per-tenant reporting
• Route decision auditing
• Correlation IDs
• Export to OpenTelemetry / Prometheus / SIEM

Ask:

• Can I trace why tenant X was sent to region Y?
• Can I audit policy changes and routing decisions?
• Can I break down traffic, errors, and latency by tenant and region?

8) Security and compliance

In hybrid/multi-cloud, security model matters a lot.

Evaluate:

• Secrets management integration: Vault, cloud KMS, HSM
• Certificate rotation
• Encryption in transit and at rest
• Data residency controls
• IAM integration
• Private networking support
• WAF / DDoS integration
• Compliance certifications if needed

Ask:

• Can secrets stay in-region or on-prem?
• Can I enforce that EU tenant data never leaves EU?
• Can admins be scoped by team, region, or tenant?

9) Configuration management and GitOps

You’ll likely need many policies and routes.

Look for:

• Declarative config
• GitOps support
• Versioning / rollback
• Policy testing / dry-run
• Promotion between environments
• Environment-specific overlays
• IaC support: Terraform, Helm, CRDs, APIs

Ask:

• Can I promote routing rules from dev to prod safely?
• Can I diff and roll back gateway config?
• Can I validate policies before applying them?

10) Extensibility

Real-world routing often needs custom logic.

Check for:

• Custom plugins
• Scripting
• Event hooks
• External decision services
• Header-based enrichment
• Support for bespoke metadata or tenant catalogs

Ask:

• If tenant routing needs a lookup in an internal service, can I do it safely?
• Are plugins sandboxed?
• Will custom logic break upgradeability?

11) Operational model and team fit

A platform can be technically capable but painful to run.

Consider:

• Managed vs self-hosted
• Day-2 operations
• Upgrade path
• Policy debugging tools
• RBAC and delegation
• Support quality and ecosystem
• Ease of training for platform/app teams

Ask:

• Who will own the gateway day to day?
• How hard is it to troubleshoot a bad routing rule?
• Can app teams self-service within guardrails?

12) Integration with edge, DNS, and service mesh

Sometimes the gateway isn’t the only routing layer.

Check compatibility with:

• Global DNS traffic steering
• CDN / edge compute
• Ingress controllers
• Service mesh
• Service discovery
• Internal load balancers
• Private links / peering

Ask:

• Should region selection happen at DNS, edge, or gateway?
• Does the gateway integrate with mesh policies, or conflict with them?
• Can it route both external and internal API traffic?

---

Key architecture question: where should region selection happen?

For your use case, the best design is often:

1. Global traffic steering at DNS/edge
2. API gateway in each region/cloud
3. Tenant-aware routing inside the gateway
4. Policy and auth centralized, but enforced locally

That gives you:

• low latency
• regional isolation
• resilience
• consistent policy

---

Practical scorecard

When comparing platforms, score them on:

• Hybrid/multi-cloud deployment
• Tenant-aware routing
• Claim/header-based policy
• Active-active failover
• Policy-as-code / GitOps
• Observability
• Security/compliance
• Extensibility
• Operational simplicity
• Performance under load

---

Red flags

Be cautious if the platform:

• only routes by host/path
• assumes one cloud
• lacks per-tenant policy isolation
• requires a single central data plane
• cannot operate during control-plane outages
• has poor auditability
• makes custom logic hard or unsafe
• can’t do regional residency enforcement

---

Short recommendation

For your scenario, prioritize an API gateway that supports:

• distributed regional deployment
• identity-based routing
• multi-tenant policy isolation
• active-active failover
• declarative configuration
• strong observability

If you want, I can turn this into a vendor evaluation template or a feature checklist matrix you can use in an RFP.