Notifications
Clear all
Topic starter
24/06/2026 7:36 pm
TL;DR: Shared state, regional caching, and centrally governed policy are now core design concerns for API and AI gateways spanning AWS, Azure, and GCP, according to Kong. The identity lesson is that stateful governance, not just request enforcement, becomes the control plane problem when access, quotas, and agent interactions cross clouds.
NHIMG editorial — based on content published by Kong: Configuring Kong Dedicated Cloud Gateways with Managed Redis in a Multi-Cloud Environment
Questions worth separating out
Q: How should security teams govern shared state in multicloud gateways?
A: Security teams should first identify which controls depend on shared state, such as rate limiting, session management, and token accounting.
Q: Why does multicloud architecture make gateway governance harder?
A: Multicloud increases the number of places where policy can drift and state can diverge.
Q: When should organisations use regional caches instead of a global cache?
A: Use regional caches when the control depends on low latency or when the gateway must make local decisions that cannot tolerate cross-cloud round trips.
Practitioner guidance
- Map every gateway policy to its required state dependency Document which controls rely on counters, cache entries, sessions, or token usage data so you can see where regional state is mandatory and where stateless enforcement is sufficient.
- Place enforcement data in the same region as the gateway Keep rate limiting, cache, and quota state close to the data plane that consumes it to avoid latency spikes and inconsistent decisions across clouds.
- Test policy drift across cloud regions Simulate the same request path in AWS, Azure, and GCP to confirm that centralized policy produces the same outcome when regional caches and counters are involved.
What's in the full article
Kong's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Konnect workflow for creating Dedicated Cloud Gateways across AWS and Azure.
- Exact Redis add-on configuration examples, including the API payload used to provision managed caches.
- Terraform-oriented deployment patterns for replicating gateway environments across cloud providers.
- Plugin-level configuration details for rate limiting, response caching, and AI token governance.
👉 Read Kong's guide to multicloud gateway configuration with managed Redis →
Multicloud gateway shared state: what IAM teams need to know?
Explore further
25/06/2026 4:57 am
Multicloud gateway governance now depends on state, not just policy. A centrally managed gateway can only enforce identity and traffic rules consistently if the state behind those rules is synchronized across regions. That shifts the security conversation from configuration alone to the reliability of counters, cache entries, and session data. Practitioners should treat distributed state as part of the control plane, not as an implementation detail.
A few things that frame the scale:
- 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to The 2024 Non-Human Identity Security Report.
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
A question worth separating out:
Q: How do AI gateways change identity and access governance?
A: AI gateways turn request governance into a runtime identity problem because token quotas, routing rules, and filtering decisions can change by session and region. Teams need to manage the state behind those decisions, not just the access policy itself, or they will lose visibility into how agentic or model traffic is actually controlled.
👉 Read our full editorial: Multicloud gateway state management needs regional shared caches
