A persistent challenge arises as businesses adopt multicloud architectures and agentic AI: the need for state synchronization. API and AI gateways require a robust persistence layer to synchronize data, whether it's for governing AI token usage, facilitating agent-to-agent communication, or boosting performance through caching.
The Managed Redis cache add-on for Kong Dedicated Cloud Gateways (DCGW) is now generally available (GA) in AWS and Azure. This offering provides enterprises with a fully managed, high-performance shared state layer directly within Kong Konnect, facilitating intelligent, stateful governance across multi-cloud deployments. It functions as a turnkey solution, delivering the speed of an in-memory data store with the simplicity of a Software as a Service (SaaS) product. Crucially, customers gain all these benefits without the burden of infrastructure management.
Modern architectures rarely live in a single cloud. You might deploy an AWS region for primary production traffic, an Azure region for European workloads, and a Google Cloud region for your analytics and AI services. Kong Dedicated Cloud Gateways (DCGW) provide a fully managed data plane that runs in your cloud account while remaining controlled through Kong Konnect. This model enables enterprises to deploy gateways across providers while maintaining centralized governance.
This post walks through configuring Dedicated Cloud Gateways across multiple clouds and regions. It also shows how to enable shared state capabilities using managed caching powered by Redis.
A multicloud DCGW architecture typically contains three main layers.
1. Konnect Control Plane
The SaaS control plane manages configuration, plugins, and policies. All gateways connect securely to this layer.
2. Dedicated Cloud Gateway Data Planes
Each cloud environment hosts its own gateway cluster. These run inside the customer's cloud account and process traffic locally.
3. Regional Shared State
Optional managed Redis instances provide caching, rate limiting counters, or AI token governance close to the gateway.
A typical deployment might include:
Each environment runs its own DCGW cluster while sharing governance from Konnect.
Fig. Multicloud Dedicated Cloud Gateways Architecture Overview
Before deploying Dedicated Cloud Gateways in multiple clouds, ensure the following prerequisites are met.
Accounts in each provider where gateways will run:
Each environment should include:
Multicloud deployments are easier to manage using the following:
Kong Dedicated Cloud Gateways provide fully managed, single-tenant infrastructure that abstracts away the operational overhead while giving you control over size and location. Behind the scenes, every DCGW runs in an individual single-tenant cloud environment, ensuring consistent performance, tenant isolation, and strong security boundaries, while the Konnect Control Plane remains multi-tenant.
Start by creating a gateway deployment from the Konnect control plane.
Example configuration:
Gateway Name: prod-billing-svcs
Description: Gateway for Billing services in production
This is an example topology configuration to cover a couple of common scenarios:
Fig. Example Topology
Once created, Konnect provisions the infrastructure inside your cloud environment.
Even though each gateway runs in a different cloud, they share configuration through Konnect.
This means:
Note: Currently only AWS and Azure are enabled to create managed caches.
Each gateway must connect to upstream services running in its cloud environment.
Typical patterns include:
Each gateway routes to services deployed in the same cloud.
Example:
AWS Gateway → AWS microservices
Azure Gateway → Azure workloads
GCP Gateway → AI inference services
Benefits:
Sometimes services live in different clouds.
Example:
Azure Gateway → AWS backend
This can be achieved through:
Multicloud systems often require shared state across gateway instances.
Examples include:
Dedicated Cloud Gateways can enable managed Redis directly from Konnect.
Managed caches are configured at the control plane level and must be associated with a control plane when they are created. Currently, the size available is small (approximately 1 GiB), but larger sizes are planned for future support. If you require a larger cache immediately, please contact your account team. Managed caches are available across all regions, which facilitates multi-region configurations.
curl -X GET "https://global.api.konghq.com/v2/control-planes?filter%5Bcloud_gateway%5D=true" \
--no-progress-meter --fail-with-body \
-H "Authorization: Bearer $KONNECT_TOKEN"
You should get a response similar to the following:
{
"meta": {
"page": {
"total": 3,
"size": 100,
"number": 1
}
},
"data": [
{
"id": "uuuidnumber",
"name": "prod-billing-svcs",
"description": "Gateway for billing services in production",
"labels": {},
"config": {
"control_plane_endpoint": "https://uuuidnumber.us.cp0.konghq.com",
"telemetry_endpoint": "https://uuuidnumber.us.tp0.konghq.com",
"cluster_type": "CLUSTER_TYPE_CONTROL_PLANE",
"auth_type": "pinned_client_certs",
"cloud_gateway": true,
"proxy_urls": []
},
"created_at": "2026-03-11T22:44:08.466Z",
"updated_at": "2026-03-11T22:44:08.466Z"
}
]
}
export CONTROL_PLANE_ID='YOUR CONTROL PLANE ID'
curl -X POST "https://global.api.konghq.com/v2/cloud-gateways/add-ons" \
--no-progress-meter --fail-with-body \
-H "Authorization: Bearer $KONNECT_TOKEN" \
--json '{
"name": "managed-cache",
"owner": {
"kind": "control-plane",
"control_plane_id": "'$CONTROL_PLANE_ID'",
"control_plane_geo": "us"
},
"config": {
"kind": "managed-cache.v0",
"capacity_config": {
"kind": "tiered",
"tier": "small"
}
}
}'
It should have a response similar to the following:
{
"id": "uuuidnumber",
"name": "managed-cache",
"owner": {
"kind": "control-plane",
"control_plane_id": "uuuidnumber",
"control_plane_geo": "us"
},
"config": {
"kind": "managed-cache.v0",
"capacity_config": {
"kind": "tiered",
"tier": "small"
},
"data_plane_groups": [
{
"id": "uuuidnumber",
"cloud_gateway_network_id": "uuuidnumber",
"provider": "aws",
"region": "us-east-1",
"state": "initializing",
"state_metadata": {}
},
{
"id": "uuuidnumber",
"cloud_gateway_network_id": "uuuidnumber9",
"provider": "azure",
"region": "germanywestcentral",
"state": "initializing",
"state_metadata": {}
},
{
"id": "uuuidnumber",
"cloud_gateway_network_id": "uuuidnumber",
"provider": "aws",
"region": "us-west-1",
"state": "initializing",
"state_metadata": {}
}
],
"state_metadata": {
"cache_host": "{vault://env/ADDON_MANAGED_CACHE_HOST}",
"cache_port": "{vault://env/ADDON_MANAGED_CACHE_PORT}",
"cache_username": "{vault://env/ADDON_MANAGED_CACHE_USERNAME}",
"cache_config_id": "uuuidnumber",
"cache_server_name": "{vault://env/ADDON_MANAGED_CACHE_SERVER_NAME}",
"cloud_authentication": {
"aws_region": "{vault://env/ADDON_MANAGED_CACHE_AWS_REGION}",
"auth_provider": "{vault://env/ADDON_MANAGED_CACHE_AUTH_PROVIDER}",
"aws_cache_name": "{vault://env/ADDON_MANAGED_CACHE_AWS_CACHE_NAME}",
"azure_tenant_id": "{vault://env/ADDON_MANAGED_CACHE_AZURE_TENANT_ID}",
"aws_assume_role_arn": "{vault://env/ADDON_MANAGED_CACHE_AWS_ASSUME_ROLE_ARN}"
}
},
"state": "ready",
"entity_version": 1,
"created_at": "2026-03-12T02:11:46.797Z",
"updated_at": "2026-03-12T02:11:46.797Z"
}
Konnect automatically:
As Redis is a regional service, each cloud environment will be provisioned with its own dedicated, high-performance cache. Please note that we will pause briefly here, as the deployment of these resources may take up to 15 minutes.
After the managed cache is ready, Konnect automatically creates a [Redis partial](https://developer.konghq.com/gateway/entities/partial/)Redis partial configuration for you. [Use the Redis configuration](https://developer.konghq.com/gateway/entities/partial/#add-a-partial-to-a-plugin)Use the Redis configuration to set up Redis-supported plugins by selecting the automatically created Konnect-managed Redis configuration.
You should be able to check it under Redis Configurations
Fig. Redis Configuration with Konnect managed cache configuration
Once Redis is enabled, it can support several Kong plugins. Some plugins in Kong Gateway share common Redis configuration settings that often need to be repeated. Partials, like the one created in the previous step, allow you to reuse shared Redis configurations across [plugins](https://developer.konghq.com/gateway/entities/plugin/)plugins.
Fig. Redis Configuration in Kong Konnect
Common examples include:
Example configuration:
name: rate-limiting-advanced
partials:
- id: a07fb159-162c-430d-b4ff-fb09f22c8c3b
config:
strategy: redis
throttling:
enabled: false
interval: 5
queue_limit: 5
retry_times: 3
window_type: sliding
This ensures traffic limits remain consistent across all gateway instances within that region.
Example configuration:
plugin: proxy-cache
config:
strategy: redis
cache_ttl: 300
Benefits:
AI gateways often enforce usage limits for models and agents.
Plugins such as AI rate limiting or token quotas can store counters in Redis to track usage across requests.
This is particularly useful when gateways front model providers such as:
Note: For those plugins that can’t use Redis partial configuration, you can use [env referenceable fields](https://developer.konghq.com/gateway/entities/vault/#store-secrets-as-environment-variables)env referenceable fields directly using the information from the managed cache state_metadata.
Infrastructure automation makes it easier to replicate gateway environments across clouds.
Example Terraform workflow:
Example structure:
modules/
dcgw/
main.tf
variables.tf
environments/
aws-prod/
azure-eu/
gcp-ai/
A pipeline can then deploy gateways across providers consistently.
Benefits include:
With multiple gateways deployed, policies should be applied centrally.
Examples:
All policies are defined once in Konnect and synchronized automatically to each gateway.
Monitoring becomes critical in distributed environments.
Recommended telemetry includes:
Konnect provides centralized analytics while gateways continue to process traffic locally.
This allows teams to identify issues across clouds without operating separate monitoring stacks.
A production architecture might look like this:
Characteristics of this architecture:
Route traffic to services within the same cloud whenever possible to reduce latency.
Deploy Redis per region rather than a single global instance to maintain performance.
Use infrastructure automation to avoid configuration drift across clouds.
Use dedicated gateways for:
This prevents configuration changes from impacting live traffic.
Dedicated Cloud Gateways allow organizations to combine the benefits of SaaS management with the performance and control of running gateways directly in their own cloud environments.
By deploying gateways across providers such as AWS, Azure, and Google Cloud, teams can create resilient multicloud architectures while maintaining consistent governance.
With the addition of managed Redis caching, gateways can evolve from stateless proxies into intelligent infrastructure capable of enforcing rate limits, caching responses, and governing AI workloads.
To get started:
From there, your API and AI infrastructure can scale across clouds while remaining centrally managed and operationally simple.
Bring Financial Accountability to Enterprise LLM Usage with Konnect Metering and Billing Showback and chargeback are not the same thing. Most organizations conflate these two concepts, and that conflation delays action. Understanding the LLM showb
[](https://konghq.com/blog/enterprise/llm-cost-management-ai-showback-and-chargeback)
Managed Redis cache is a turnkey "Shared State" add-on for Kong Dedicated Cloud Gateways. It is designed to combine the performance of an in-memory data store with the simplicity of a SaaS product. When you spin up a Dedicated Cloud Gateway in Kong
[](https://konghq.com/blog/product-releases/multicloud-cloud-gateways-managed-redis-cache)
The Shifting Economic Landscape: The AI token economy in 2026 is evolving, and enterprise leaders must distinguish between low-cost input tokens and high-premium output tokens to maintain profitability. Agentic AI Financial Risks: The transition t
[](https://konghq.com/blog/enterprise/ai-input-vs-output-cost-management)
Traditional agreement processes were slow and heavily manual. Documents were often created in office tools, shared through email, printed, signed physically, and stored across multiple systems. Tracking the status of agreements required manual follo
[](https://konghq.com/blog/engineering/automating-agreement-workflows-kong-konnect-and-docusign-for-developers)
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
[](https://konghq.com/blog/engineering/monetize-ai-apis)
Running Kong in front of your Solace Broker adds real benefits: Authentication & Access Control – protect your broker from unauthorized publishers. Validation & Transformation – enforce schemas, sanitize data, and map REST calls into event topics.
[](https://konghq.com/blog/engineering/smarter-event-driven-apis-kong-solace)
The goal of Integration Platform as a Service (iPaaS) is to simplify how companies connect their applications and data. The promise for the first wave of iPaaS platforms like Mulesoft and Boomi was straightforward: a central platform where APIs, sys
[](https://konghq.com/blog/engineering/kong-and-polyapi)