Seamless API management at global scale with Apigee X on Google Cloud.

Migrating from Apigee Edge to Apigee X is a significant undertaking, particularly in organisations that rely on API infrastructure for mission-critical workloads. With hundreds of APIs in production and thousands of consumers, any disruption can be costly. However, with the right strategy and tooling, it's possible to perform a migration without any downtime – while laying the foundation for a more scalable, secure and globally distributed API platform. 

In this article, I share how we: 

• Transitioned from Apigee Edge to Apigee X without service disruption 
• Automated the deployment of API artefacts using GitHub pipelines, implemented advanced policies to improve performance and built a globally available architecture 
• Used Apigee’s flexibility to integrate with AWS API Gateway using mutual TLS (mTLS) 

Migrating from Apigee Edge to Apigee X without downtime 

When preparing for the migration, one of our primary concerns was maintaining uninterrupted API availability. Our Edge environment had accumulated a wide range of configurations – API proxies, developer apps, API products, key-value maps (KVMs) and more. Simply lifting and shifting all of that to Apigee X manually would be error-prone and slow. 

We adopted a dual-deployment strategy, setting up Apigee X in parallel with our existing Edge instance. This allowed us to replicate and validate all functionality in the new environment without impacting users. During the cutover, instead of modifying client configurations, we simply switched the DNS entry to point to Apigee X. Google Cloud Load Balancer (GLB) played a crucial role in this transition by enabling fast and reliable DNS routing. Since Apigee X provides regionalised endpoints, we also started leveraging geographic load balancing from day one. 

For migrating artefacts, we built automation scripts to export proxies and shared flows from Edge and re-import them into Apigee X. These scripts also recreated API products and developer apps, ensuring that all API keys and entitlements remained intact. We used the Apigee Admin APIs extensively, wrapping them in scripts and pipeline jobs that could be triggered via GitHub Actions. 

Automating artefact deployment via GitHub Pipelines 

To ensure a sustainable and developer-friendly workflow, we set up a Git-based CI/CD pipeline. Internal API producers only needed to maintain a Git repository containing their API proxy code and configuration metadata. Upon pushing changes to the main branch, GitHub Actions would kick off a series of jobs to validate, deploy, and configure the proxy in Apigee X. 

The pipeline supports the deployment of: 

• API proxy bundles 
• Key-Value Maps (KVMs) 
• API products and their associated scopes 
• Assignments of proxies to products 

Each artefact is versioned in Git, ensuring full traceability. Peer reviews and automated tests guarantee that changes meet our internal standards. This automation allowed teams to focus on building APIs rather than managing deployments, significantly reducing time-to-market. 

Leveraging advanced policies for performance and security 

One of Apigee X's strengths is its rich policy framework, which we used extensively to enhance security, scalability and performance.  

For example, many of our APIs rely on OAuth 2.0 tokens issued by external identity providers. Token verification on each request could have introduced latency and increased dependency on external systems. To mitigate this, we implemented token caching using Apigee's built-in cache policies. 

The VerifyJWT and OAuthV2 policies verify tokens, while PopulateCache and LookupCache  policies reduce redundant validations. This token cache is keyed by the token’s hash and expires based on the token’s lifetime. As a result, we reduced backend calls related to token verification by more than 95% without compromising security. 

We also used SpikeArrest and Quota policies to implement rate-limiting and prevent abuse. Additionally, AssignMessage and RaiseFault were combined to introduce dynamic rate limiting that adapts based on backend response health, helping us protect fragile systems during peak loads. 

We configured all sensitive parameters and environment-specific values using encrypted KVMs. This included keystores and truststores for target services, credentials, feature flags and other configuration data. This approach allowed us to manage multiple environments securely without needing to redeploy proxies when updating values. 

Flexibility in backend authentication and integration 

Another reason we love Apigee X in our projects is its ability to integrate with virtually any backend, regardless of the authentication mechanism. We encountered a variety of backends: 

• Modern cloud services like AWS Lambda via API Gateway, using mTLS 
• Azure Functions secured with Azure AD tokens 
• On-premises systems requiring mutual TLS or basic authentication 
• Legacy services needing custom headers or HMAC signatures 

With Apigee’s rich policy framework, we were able to create service callouts to fetch tokens, generate custom signatures using Java callouts or simply add the required headers. The configuration is decoupled from the proxies, making the proxies themselves reusable across environments and integration patterns. 

Designing a globally distributed Apigee setup 

Our consumers are distributed globally, so we needed a platform that could scale horizontally across regions. Apigee X allowed us to deploy proxies in multiple Google Cloud regions. Using Google Cloud Load Balancer and geo-DNS routing, we exposed different regional endpoints under a unified custom domain. 

Consumers automatically connect to the nearest regional endpoint, reducing latency and improving availability. Each regional Apigee instance connects to backend systems that might be running on Google Cloud, AWS, Azure or on-premises. Apigee X supports secure connectivity via VPC sharing and Partner Interconnects, allowing us to reach even legacy backend systems without exposing them to the internet. 

Example: Apigee connecting to AWS API Gateway with mTLS 

One of our use cases involved invoking an API behind AWS API Gateway, protected via mTLS and a custom domain.  

Here’s how we set it up: 

On AWS, the API Gateway was configured with a custom domain and required mTLS using client certificates. We uploaded our Apigee client certificate to AWS’ truststore, ensuring only authorised calls were accepted. 

Store the truststore of your certificate authority on AWS S3 and allow API Gateway to access the S3 bucket. Set up a custom Domain Name in AWS API Gateway and set up mutual TLS authentication. 

On the Apigee side, we stored the client certificate and private key in a keystore and the AWS CA certificate in a truststore. We then configured a TargetServer in Apigee referencing this mTLS configuration and pointed our proxy’s TargetEndpoint to use this server. The result was a secure, mutually authenticated channel—set up in just a few steps. 

<TargetEndpoint name="aws"> 
  <HTTPTargetConnection> 
    <LoadBalancer> 
      <Server name="aws-mtls"/> 
    </LoadBalancer> 
  </HTTPTargetConnection> 
</TargetEndpoint> 

The simplicity and security of this integration highlighted one of Apigee X’s most powerful capabilities: flexible connectivity across clouds.

Migrating to Apigee X has transformed how we manage, secure and scale our APIs 

By leveraging automation, rich policy configuration and global infrastructure, we’ve built a platform that’s both developer-friendly and enterprise-ready. 

Our journey involved: 

• Zero-downtime migration 
• GitOps workflows for producer teams 
• Policy-driven performance optimisation 
• Seamless backend integrations across cloud and on-prem environments  

Whether you're planning your own migration or looking to modernise your API stack, Apigee X offers the building blocks to help you succeed at a global scale.