As our platform evolved, so did our needs around scalability, security, and operational efficiency. Kong served as our go-to API gateway for years—flexible, reliable, and cost-effective—but as we leaned more heavily into AWS-native services, migrating to AWS API Gateway became a clear move.

Why Migrate?

Kong did the job well, but a few key reasons pushed us towards AWS. It provided a more seamless integration with AWS Lambda, IAM, VPCs, and AWS's native monitoring (who would’ve thought). And let’s be honest, maintaining separate Kong clusters, plugins, and configurations across multiple environments for many different services became overly cumbersome. Transitioning would reduce overall operational hassle, to say the least.

Planning the Migration

Migrating an API gateway isn’t trivial. Here’s how we tackled it: taking inventory, feature mapping, utilizing IaC (Infrastructure-as-Code), and doing some incremental cutover. We documented all existing Kong routes, plugins, and upstream services and matched Kong functionalities with AWS API Gateway counterparts. It wasn’t bad at all. After that, it was a no-brainer to use Terraform to utilize an openapi standard in defining our gateway resources, paving the way to eventual adoption of AWS CDK (no more serverless [I have nothing against serverless]). Finally, we migrated services one domain at a time since you always gotta be careful. Can’t just transition something with high traffic and turn it up to 100% on a completely different path. Madness!

How We Did It

Before the migration, our Kong setup involved:

A cluster of EC2 instances behind an AWS ELB, serving as a single API traffic entry point.
ELB distributing traffic to handle fault tolerance and scaling.
Kong clusters hosted in dedicated VPCs, ensuring private, secure API traffic.
Kong handling all proxy routing and traffic logic.

Limitations with Kong:

Heavy operational overhead due to EC2 cluster management, scaling, patching, and scattered configurations.

Transition to AWS API Gateway:

We streamlined our infrastructure with:

Removal of EC2 and ELB dependencies (with ELB temporarily in use during the transition).
Internal API Gateway for private APIs.
AWS API Gateway authorizers for secure header-based routing.

Why This Matters

The migration significantly boosted efficiency, security, and scalability. Here's what improved:

Automatic Scaling: Less manual intervention and better response to traffic spikes.
Simpler Routing: Declarative routing with clearer configurations.
Enhanced Security: AWS-native security and comprehensive monitoring.
Lower Maintenance: Freed up engineering resources from routine tasks.

Lessons Learned

Here's what we learned along the way:

Inventory Matters: Knowing exactly what you have in Kong is crucial.
Automate Everything: Infrastructure as Code (IaC) minimizes errors and speeds up deployments.
Test Frequently: Constantly validate migration steps in staging before going live.
Documentation Is Key: Clear documentation speeds up onboarding and troubleshooting.

Conclusion

Migrating from Kong to AWS API Gateway modernized our API infrastructure, enhanced our security posture, and allowed our engineers to focus on more impactful work. Despite the complexity, the benefits clearly outweighed the challenges.

If you're eyeing a similar move—start small, automate relentlessly, and leverage AWS’s managed services for the smoothest experience IF you are already quite cloud-native.

Migrating from Kong to AWS API Gateway