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

This isn't a copy‑paste tutorial. It's a behind‑the‑scenes look at why I chose a specific shape— hexagonal micro‑orchestrator on SNS → SQS —for a cross‑channel notification pipeline, and the trade‑offs I wrestled with along the way. Problem Statement Our platform publishes domain action events whenever users have opted in to notifications through certain channels. We needed to convert those raw events into user‑specific notifications (email, SMS, push) without coupling every producer to every delivery channel. Goal : 1‑second p95 latency, zero duplicate messages, and the ability to bolt on new event types in a week (not a quarter, lol). Solution Overview The orchestrator is a AWS Spring Boot microservice deployed as a container (ECS/Fargate or Kubernetes) that enriches each event with user preferences, then sends it out to an SQS queue to be consumed and fanned out by the notification (micro)service. Key Architectural Decisions <table <thead <tr <td Decision</td <td Why I picked it</td <td What I gave up</td </tr </thead <tbody <tr <td <strong SNS → SQS → NotificationService fan out</strong </td <td Built‑in reliability &amp; inexpensive at our scale; dead‑simple IAM; millisecond latency</td <td regional only</td </tr <tr <td <strong FIFO SQS Queue to Notification microservice</strong </td <td Allows notification service to delegate how to handle the destinations. That is not an orchestrator's job.</td <td Speedy, but may congest due to a little more things the notification service has to do at once. Possibly slows down throughput</td </tr <tr <td <strong Hexagonal (Ports &amp; Adapters)</strong </td <td Keeps core <em "enrich &amp; route"</em pure; swap SQS for Kafka with a new adapter</td <td More boilerplate wrappers; devs need pattern literacy</td </tr <tr <td <strong Keycloak for user profiles</strong </td <td Already our source of truth; avoids another DB</td <td Adds network hop; Keycloak SDK is verbose</td </tr <tr <td <strong Kotlin + Spring</strong for adapters</td <td First‑class coroutines, familiar to the team</td <td Cold‑start heavier than Node Lambda</td </tr <tr <td <strong Single Orchestrator</strong vs. per‑channel Lamdas</td <td Centralised logic; easier A/B testing</td <td Risk of god‑service—needs guardrails</td </tr </tbody </table Trade‑offs & Alternatives Considered EventBridge Pipes Pros: Managed transform stage, fewer lines of code. Cons: At announcement time lacked FIFO target; enrichment limited to Lambda only. SaaS Routers (Knock, Courier) Pros: Off‑the‑shelf routing & templates. Cons: Per‑message cost × our volume → non‑starter; vendor lock‑in. Full ESB (Kafka + ksqlDB) Pros: Decoupled replay, SQL‑style transforms. Cons: Operability tax; overkill for < 10 K msg/min. DB Triggers + Event Sourcing Pros: Bypasses need for SNS, low latency consumer api calls Cons: overkill for <10k/min; reconciliation overhead Lessons Learned Validate cardinality early. Encapsulating a notification, with a unique account id and embedded destinations allowed us to not bloat our infra with more SQS queues to handle Central isn't evil—just measured. One orchestrator is fine if it's ruthlessly scoped to enrichment + routing. Observability before prod. With notifications coming from both the consumer and scheduled events, distributed tracing becomes more necessary. This was setup early since the need for modularity and intention when starting out with microsrevices. Conclusion A notification pipeline looks deceptively simple until edge‑cases—missing preferences, duplicate events/notifications, out‑of‑order SMS—bite you. By leaning on AWS primitives and a hexagonal core, I get the flexibility of an old‑school ESB without the bloat—and I can add any consumer with a small PR. Next up (if there's interest): updating the api suite to save notification subscription history as an audit trail. Appendix — Minimal Code & Diagram Fragments <table <thead <tr <td Port</td <td Responsibility</td <td Adapter Example</td </tr </thead <tbody <tr <td <code UserManagementPort</code </td <td Fetch user profile</td <td <code KeycloakUserManagementServicePortAdapter</code </td </tr <tr <td <code NotificationPreferencesRepositoryPort</code </td <td Load notif prefs</td <td <code NotificationPreferencesRepositoryPortAdapter</code </td </tr <tr <td <code NotificationServicePort</code </td <td Emit enhanced request</td <td <code SqsNotificationServicePortAdapter</code </td </tr </tbody </table

Building a notification orchestrator: a decision log

I like to write stories to better explain problems I have or concepts I want to share. I still want the message to be clear, concise, and easy to digest , so I'll give you a glossary to refer back to when reading the story if it it doesn't click the first time. Prologue: Because configuring shit is honestly 90% of it Alright, let's get one thing straight. Setting up cloud infrastructure, wrestling with configurations, deciphering cryptic error messages – sometimes it feels less like software engineering and more like trying to assemble IKEA furniture in the dark during an earthquake while someone shouts jargon at you. I've read the manuals, I've stared at the diagrams, and often, my brain just goes... static . See, my mind doesn't always click with purely technical terms dropped like anvils from Mount Olympus. It likes stories. It needs analogies, maybe slightly weird ones, to make things stick. I figure, if the core concept makes sense, the fancy names will follow (or at least be Google able). If I have to imagine mobsters using a secret pigeon network to understand AWS SNS, then so be it. So, we're taking a detour from the usual dry tech talk. We're heading to Mama Rosa's Pizza in New York City. Why? Because sometimes, explaining secure, asynchronous messaging feels a lot like navigating the delicate communication needs of a family... business . Is this the official AWS documentation? Absolutely not. Is it slightly ridiculous? Probably. But maybe, just maybe, translating configuration hell and debugging cloud services into the language of pizza, pigeons, and wiseguys will actually make it clearer. At the very least, it might be more fun than reading another spec sheet. Grab a metaphorical slice, keep your wits about you, and let's dive into how John tried to keep The Boss happy without ending up wearing concrete shoes. The scene Mama Rosa's Pizza, NYC. Best slice in the tristate? Eh. Also, the nerve center for this neighborhood's… let's call it "import/export consulting". I'm John, I sling dough, wipe tables, and sometimes, I make the computers do stuff The Boss wants. 💡 Before we get lost in this beautiful pizza parlor story, I want to note that there, all the way down to the bottom, is a glossary of terms. If you need any help with understanding what something is—I'm not going to assume I can walk through complex concepts like James Baldwin—do not hesitate to take a peek. The problem: Getting the word out (quietly) Imagine this: The Boss walks in, smelling of garlic and authority. "Johnny", he says, polishing his pinky ring. "We need a new way. Tony's in the kitchen finishing the… baconeggandcheese… he needs to tell Sal out front with the delivery car. Now. No phones, no pagers, too risky. Make it happen." Right. Baconeggandcheese. So, I, ol John, need a secure, instant message from the Kitchen Crew (one system) to the Delivery Crew (another system). Untraceable. My bright idea? We set up a private Pigeon Coop Network. It's slick. The kitchen sends a coded message: extra garlic on 12 to a specific Handler at the coop. Only the Lofts registered with that guy — like Sal's lookout post — get the pigeon. Fast, reliable, no digital trail. What could go wrong? The rule: Don't test on live pigeons Now, The Boss has one rule thicker than a snicker: you don't mess up a live run. Sending a test "baconeggandcheese" signal before the actual baconeggandcheese is ready? That's a one way ticket to swimming lessons over near Dumbo. 💡 Before you say anything, 'cause I have no doubt in my mind you feel like saying something,YES, we also sell baconeggandcheese. Can't just be a one trick pony, right? Don't think about it. Just accept it. So, now I'm looking for a practice area. Where the hell am I going to find a practice area? I requisition the dusty back room and build a Model Pizza Kitchen & Fake Street Corner . It's a perfect replica—fake ovens, cardboard delivery car, the works. It even has its own Model Pigeon Coop (I call it model because it's not real) that works just like the real one, but it's totally self contained. No messages get out. To make setup and teardown faster (The Boss hates clutter), I use my Pop Up Crime Scene Kit . I made it myself (or at least I tell myself I did). It's this neat box—pop it open, boom , instant model kitchen and fake street corner. Close it, poof , it's gone. Keeps the real operation clean. My first attempts: ay ay ay I rig up the kit, get the model kitchen running, set up a fake Delivery Crew receiver, and try sending a test message. "PINEAPPLE BELONGS ON PIZZA"—something guaranteed not to be real code. 💡 Carl (the author) speaking. I'm from Hawaii, New York, and California. I enjoy pineapple on pizza. Result: nada. Sal's cardboard cutout counterpart hears nothing. The pigeons ain't flying. Shit. Why? Grab an espresso, Johnny, it's gonna be a long night. (Full glossary and detailed walkthrough preserved from the original post.)

Tag: AWS

Migrating from Kong to AWS API Gateway

Building a notification orchestrator: a decision log

The pigeon coop & the back room: A wiseguy's guide to not screwing up the message